HTTP 从诞生起就有一个朴素的属性：明文——走代理IP时数据要过多个环节，明文与否直接决定内容在链路里的可见性：请求与响应的内容在网络里以原始形式传输，沿途经过的每个环节都能直接读到——像寄一张没有信封的明信片，谁经手谁就能看见。这个属性在 HTTP 诞生的年代不是问题，在今天却成了必须补的短板。
明文意味着隐私与安全都无从谈起：登录密码、聊天内容、支付信息，若直接走 HTTP 传输，沿途都可能被读取。正因如此，今天的网站几乎都改用 HTTPS——在 HTTP 外面套一层加密，内容先加密再传输。代理IP链路中访问的站点是 http 还是 https，直接决定了内容在链路里是否可见。
这篇讲 HTTP 的明文属性：它为什么是明文的、明文的风险在哪、以及 HTTPS 是怎么给它补课的。
为什么当年是明文
HTTP 诞生于学术网络时代，当时的诉求是方便共享文档，传输的内容多为公开资料，加密并非刚需；同时加密需要额外算力，在当年会拖慢速度。于是协议设计选择了简单直接——明文传输，把加密留给需要的人自己处理。
明文的风险在哪里
风险在传输路径上的每一环：本地网络里的其他人可能看到、运营商与中间设备可能看到、代理与转发环节可能看到。敏感数据走明文等于把密码写在明信片上寄出，任何一环泄露都无从防备——这也是所有涉及账号与支付的操作必须走 HTTPS 的原因。
补课的方式是 HTTPS：在 HTTP 与 TCP 之间加一层加密（SSL/TLS）——代理IP链路里数据加密与否，正是在这一层决定的：内容先加密成密文再交给 TCP 传输，沿途看到的是乱码，只有通信两端能解开。HTTP 的语义完全保留，只是运输时穿上了铠甲。
对使用者来说，识别是否「补课成功」只看地址栏：网址以 https 开头、有锁形标识，说明传输已加密；仍停留在 http 的站点，敏感操作要格外谨慎。代理IP链路里这个判断同样重要——链路中间环节再多，只要走 HTTPS，内容始终是密的，这也是 HTTPS 站点在代理场景下更让人放心的原因。
HTTP 天生明文，像不封口的信；HTTPS 给它套上加密外壳——今天的网络几乎全程用 HTTPS，明文 HTTP 只适合无敏感内容的场景。
明文与加密的话题告一段落。HTTP 发展了几十年，早已不是最初的模样：从 0.9 到 3，每一代版本都在解决那个时代最痛的问题，下一篇看版本地图。
明文属性还有一层容易被忽略的影响：内容可以被沿途的缓存设备与转发环节「顺便看看」，也因此 HTTP 时代的很多优化手段（如内容缓存）都建立在内容可读的基础上。HTTPS 普及后这些手段需要重新设计——加密保护了隐私，也收紧了可读性，这正是安全与效率的永恒博弈。
判断一个站点是否全程加密，除了看地址栏，还可以留意浏览器对混合内容的提示：页面主体走 HTTPS 但部分资源仍走 HTTP 时，浏览器会给出警告。这类「半加密」状态同样有泄露风险，识别它也是网络素养的一部分，代理IP场景下对这类细节保持敏感没有坏处。
明文的教训还可以往前推一步：任何涉及账号、支付、个人资料的网站，都应默认要求 HTTPS；反过来，当你自己的服务要对外提供时，也应当主动启用加密而不是等用户来提醒。把加密当成默认项而非可选项，是今天做网络相关事情的基本素养，代理IP使用者在评估链路安全时，也应把「目标是否全程加密」纳入首要考量。