外观
代理流量的加密层次：传输加密与端到端加密的区别
使用代理后，流量只在客户端到代理服务端这一段受代理协议加密保护，到服务端会被解封再转发。目标若是 HTTPS，浏览器与网站之间另有端到端加密，代理服务端看不到内容，但能看到目标域名与流量规模；若是明文 HTTP，内容在服务端之后就是明文。
使用代理后，流量只在客户端到代理服务端这一段被代理协议的加密信道保护，到了代理服务端会被解开封装再发往目标。目标站点若是 HTTPS，浏览器与网站之间另有一层端到端加密，代理服务端也无法读取内容，但能看到目标域名与流量规模；目标站点若是明文 HTTP，内容在代理服务端之后就是明文。DNS 查询是否在加密信道内取决于解析发生在哪里。理解这几段的边界，才能判断“代理加密”究竟保护了什么、没保护什么。
核心结论与适用条件
代理加密的结论可以浓缩为三句话：第一，代理协议提供的是传输加密，覆盖范围到代理服务端为止；第二，HTTPS 提供的是浏览器与网站之间的端到端加密，代理服务端只是中途转发者；第三，两层加密叠加时，中途任何一方都只能看到自己所在层次允许看到的信息。
这些结论适用于所有以 TLS 类方案为外层的代理协议，包括 VLESS over TLS、REALITY、Trojan 类，以及自带加密的 Shadowsocks 与 VMess。不适用的情况是没有外层加密的裸协议配置，这类配置在公网环境下没有机密性，本文不讨论其使用方式。关于各协议在加密发生位置上的差异，对照 VLESS、Trojan 与 Shadowsocks 的加密设计差别 有逐项对比；本文关注的是把这些协议放进完整链路后，每一段的加密状态。
本文不涉及任何品牌的实际配置，17 个品牌的传输方案字段均为待核实；也不提供任何加密开销、吞吐或延迟的数值。
五个环节的加密状态
把一次网页访问拆成五个环节，逐段看加密状态，比笼统地说“加密了”或“没加密”更有用。
环节一：设备内部
流量从浏览器或应用程序产生，经过操作系统网络栈，交给代理客户端。这一段在同一台设备内部完成，不经过网络，通常不讨论加密。但有两个例外需要注意：一是系统代理模式下，不走系统代理的应用会直接发往网络；二是 TUN 模式下，所有流量被虚拟网卡接管，客户端按规则决定哪些走代理、哪些直连。这两种模式决定了后续环节的流量是否全部进入加密信道。
环节二：设备到代理服务端
这是代理协议真正起作用的一段。客户端把原始流量封装进协议头，再用 TLS 或其变体加密后发往服务端。本地网络、运营商与中途路由器看到的，是一条指向代理服务端的加密连接。它们能观察到的信息限于连接的外部特征：服务端地址与端口、连接建立与结束时间、数据量、握手阶段的明文字段。真实目标地址与内容都在密文之内。
环节三：代理服务端
服务端解开外层加密，读取协议头中的目标地址，再把内层数据原样发往目标。这意味着代理服务端是传输加密的终点：它知道你要去哪，也能看到内层数据的原始形态。如果内层是 HTTPS，服务端看到的是另一层密文；如果内层是明文 HTTP、明文 DNS 或其他未加密协议，服务端看到的就是内容本身。
环节四：代理服务端到目标网站
这一段的加密状态完全由目标网站决定。HTTPS 站点在这一段仍是端到端加密；HTTP 站点在这一段是明文，路径上的任何设备都能读取。代理不会给这一段增加任何保护。
环节五：目标网站
网站解开 HTTPS 层，看到请求内容。网站看到的来源地址是代理服务端的出口地址，而不是你的本地地址。网站还能通过浏览器层面的接口获取其他信息，这属于浏览器设置范畴，理解 WebRTC 为何可能绕过代理暴露本地地址 讨论了其中最常见的一种。
逐段加密状态对照表
下表是本文的核心参照，每一行对应一个环节与一类流量的组合。所有行均为通用原理，不含任何品牌数据。
| 指标 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|
| 设备到代理服务端：外层加密 | 有/无 | TLS 类传输方案为“有”，裸协议为“无” | 通用技术资料 | 2026-10-18 |
| 设备到代理服务端：可见外部特征 | 字段列表 | 服务端地址、端口、时间、数据量、SNI、TLS 指纹 | 通用技术资料 | 2026-10-18 |
| 代理服务端：可见目标地址 | 是/否 | 任何代理协议均为“是”，转发所必需 | 通用技术资料 | 2026-10-18 |
| 代理服务端：可见 HTTPS 内容 | 是/否 | 证书校验开启且无额外根证书时为“否” | 通用技术资料 | 2026-10-18 |
| 代理服务端：可见 HTTP 内容 | 是/否 | 明文协议为“是” | 通用技术资料 | 2026-10-18 |
| 代理服务端到目标：加密状态 | 有/无 | 由目标站点协议决定，代理不增加保护 | 通用技术资料 | 2026-10-18 |
| DNS 查询：所在层次 | 信道内/信道外 | 远程解析为信道内，本地解析为信道外 | 通用技术资料 | 2026-10-18 |
| 目标网站：可见来源地址 | 地址类型 | 代理服务端出口地址 | 通用技术资料 | 2026-10-18 |
| 重复加密的运算开销 | 不适用 | 本站不提供数值，Not Tested | 本站口径 | 2026-10-18 |
| 品牌传输方案字段 | 文本 | 17 个品牌均未写明 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 品牌协议标注 | 文本 | 12 个标注 VLESS，5 个待核实 | 品牌公开资料/用户提供清单 | 2026-10-18 |
传输加密与端到端加密：两种模型
两种加密模型的区别不在算法，而在密钥归属与终点位置。
传输加密中，密钥由相邻两个节点协商，数据到达节点后被解开，节点读取或处理后再按需重新加密发往下一跳。代理协议的 TLS 层、企业内网的站点间加密都属于这种。它保护的是“一段路”，终点节点是可信前提。
端到端加密中，密钥只存在于通信的两端，中途所有节点都只能转发密文。HTTPS 中浏览器与网站之间的 TLS 会话是典型例子：代理服务端、运营商、CDN 边缘（在未终止 TLS 的情况下）都无法读取内容。它保护的是“整条路”，中途节点无需可信。
把两者叠加之后，各方能看到的信息范围就清楚了：本地网络只看到外层加密连接的外部特征；代理服务端看到目标地址与内层数据的形态；目标网站看到内容与代理出口地址。没有任何一方同时看到“你是谁”与“你看了什么”的全部，这是叠加结构的意义所在。但这个结论有前提，下一节讨论什么情况下前提会被破坏。
什么情况下加密边界会失效
证书校验被关闭
客户端若开启跳过证书校验，TLS 外层对中间人攻击的防护失效，处于路径上的设备可以用自签证书冒充代理服务端，解开外层加密并读取协议头与内层数据。这是最直接的边界破坏，详见 理解 allowInsecure 为什么会让传输加密形同虚设。
设备上存在额外根证书
如果你曾为调试、企业管理或某些软件安装过额外的根证书，持有对应私钥的一方可以对 HTTPS 做中间人解密，端到端加密在该设备上不再成立。这与代理无关，但会让“代理服务端看不到 HTTPS 内容”的结论失效，前提是代理服务端恰好持有该证书的私钥。日常使用中应定期检查系统与浏览器的受信根证书列表，移除来源不明的条目。
DNS 在信道外解析
如果域名解析发生在本地，域名列表以明文形式暴露给本地网络与运营商，即使后续连接走了加密信道。检测与处理方法见 按步骤检测 DNS 是否在代理信道之外解析。
部分流量未进入代理
系统代理模式下不遵循系统设置的应用、TUN 模式下被规则放行为直连的流量，都不经过加密信道。这不是加密失效，而是流量根本没进入加密范围。核对客户端的分流规则与模式设置，是确认覆盖范围的前提。
握手阶段的明文字段
即使外层加密正常，TLS 握手的 ClientHello 本身是明文，其中的 SNI 字段暴露了代理服务端的域名，字段布局构成 TLS 指纹。这不影响内容机密性，但构成可观察的外部特征，相关原理见 理解握手阶段的指纹为何不受加密保护。
一次完整访问的逐段示例
用一个假设化的示例口径把前面的内容串起来。假设你在咖啡馆的无线网络中，用 TUN 模式的客户端连接一个 VLESS over TLS 节点，然后在浏览器里打开一个 HTTPS 站点，客户端配置为远程解析。
浏览器先要解析域名。因为配置了远程解析，客户端不在本地查询，而是把域名原样写进协议头交给服务端处理，咖啡馆的路由器与运营商都看不到这个域名。随后浏览器与网站建立 HTTPS 会话，握手与后续数据全部被客户端封装进 VLESS 协议头，再用 TLS 加密发往服务端。此时咖啡馆路由器看到的只是一条指向服务端地址的 TLS 连接，外加握手阶段明文的 SNI 与指纹。
服务端解开 TLS，读取协议头得知目标域名，把内层的 HTTPS 字节转发出去。服务端能记录你连接了哪个域名、传了多少数据，但内层仍是浏览器与网站之间的密文。网站收到请求，来源地址是服务端的出口地址，解开 HTTPS 后看到页面请求并返回内容，整个路径反向重复一次。
如果把示例中的任何一个条件改掉，结论就会变化：把远程解析改成本地解析，域名在第一步就暴露给咖啡馆网络；把 HTTPS 站点换成 HTTP 站点，服务端与其后的路径都能读到内容；把证书校验关掉，咖啡馆网络中的任何设备都有机会冒充服务端。这就是为什么逐段核对比笼统的“加密了”更有意义。
加密不保护的部分：元数据
加密保护的是内容，不保护通信本身存在这个事实。无论加密多强，以下信息在相应环节都是可观察的：连接的时间点与持续时长、每个方向传输的数据量、连接的频率与节奏、外层连接的目标地址与端口。
这些信息统称元数据。对本地网络与运营商而言，元数据是“你在什么时间与某个服务端交换了多少数据”；对代理服务端而言，元数据是“你在什么时间访问了哪些域名、传了多少数据”。元数据无法通过加密消除，只能通过其他方式降低其可用性，例如流量填充、时序整形，这些不在本文范围内，相关原理在流量识别一文中讨论。
对普通用户来说，理解元数据的意义在于校正预期：代理加密能阻止中途各方读取内容，不能让通信行为本身不可见。选择代理服务时，服务方对元数据的处理方式是一个与加密强度无关、但同样重要的考量，品牌资料中没有任何品牌写明这一点，均为待核实。
协议封装如何影响加密结构
不同代理协议在加密结构上的差别，可以用“加密发生在哪一层”来概括。
Shadowsocks 用对称加密直接包裹数据，协议本身就是加密层，没有额外的 TLS。VMess 内置加密与认证，同样可以不依赖 TLS，但也常被包裹在 TLS 内。VLESS 完全不做加密，必须依赖外层 TLS、REALITY 或 XTLS；它的理由是避免内层 HTTPS 与外层代理加密的重复运算，并为流控方案留出空间。Trojan 则把自己设计成一个 HTTPS 服务，加密由标准 TLS 承担。
REALITY 在这个结构上做了一个特别的处理：它让服务端面对非目标访客时转发到一个真实网站，并借用该网站的证书完成握手外观，这意味着外层加密的“证书”不属于代理服务端自身。这个设计对加密强度没有削弱，但改变了证书校验的参照对象，理解它需要先理解普通 TLS 的证书链，详见 理解 REALITY 如何在不持有证书的情况下完成握手。
XTLS Vision 处理的是重复加密问题。它在识别出内层数据已是 TLS 加密后，减少外层对这部分数据的重复加密运算。这里需要强调，Vision 不是“去掉加密”，而是避免对已加密数据再做一次等价的加密，其原理与边界见 理解 Vision 流控在哪一段减少了重复加密。
决策树：我的流量在哪一段是明文
Decision Path
按配置与目标站点判断每一段的加密状态
text
客户端配置的传输方案是否为 TLS 类（TLS / REALITY / XTLS）或自带加密协议？
├─ 否（裸协议）→ 设备到代理服务端一段为明文，不应在公网使用，先修正配置
└─ 是 → 继续
├─ 证书校验是否开启？
│ ├─ 否 → 外层加密可被中间人解开，先关闭 allowInsecure 再继续
│ └─ 是 → 设备到代理服务端一段：加密正常
├─ DNS 解析发生在哪里？
│ ├─ 本地解析 → 域名列表在信道外明文暴露，需改为远程解析或代理侧 DNS
│ └─ 远程解析 → DNS 在信道内
├─ 目标站点是 HTTPS 吗？
│ ├─ 是 → 代理服务端与之后的路径：内容加密，仅目标域名与数据量可见
│ └─ 否 → 代理服务端与之后的路径：内容明文，避免在该站点提交敏感信息
└─ 所有应用的流量都进入了代理吗？
├─ 是（TUN 模式或全部遵循系统代理）→ 覆盖范围完整
└─ 否 → 未进入代理的流量不受任何代理加密保护，核对分流规则知识图谱：代理加密
实体定义
代理加密指代理协议在客户端与代理服务端之间建立的加密信道，属于传输加密，终点是代理服务端。端到端加密指通信双方之间的加密，中途节点无法读取，HTTPS 是网页访问场景下最常见的实例。两者在一次代理访问中叠加存在，各自保护不同范围。
相关概念
上游概念：TLS 握手、证书链、对称与非对称加密、密钥协商。平行概念：隧道、封装、分流规则、系统代理与 TUN 模式。下游概念：DNS 泄露（解析是否在信道内）、WebRTC 泄露（浏览器接口是否绕过代理）、证书校验（外层加密的前提）、TLS 指纹（握手阶段的明文特征）、流量识别（基于外部特征的分类，见 理解加密之外还有哪些特征可被观察）。
技术参数
可由用户核对的参数：传输方案字段、证书校验开关、DNS 解析位置、代理模式（系统代理或 TUN）、分流规则、目标站点协议。不可由用户直接核对的参数：代理服务端的日志策略、服务端出口到目标的路径。本站不提供的参数：任何加密开销、吞吐或延迟的数值。
适用场景
需要特别关注加密边界的场景：在公共网络环境使用、访问含账号信息的站点、使用明文协议的旧应用、多应用混合使用且部分不遵循系统代理。关注度较低的场景：仅访问 HTTPS 站点、客户端为 TUN 模式且证书校验开启、DNS 已确认远程解析。
对比依据
本站比较加密结构只依据各协议公开设计文档所述的加密发生位置与 TLS、HTTPS 的通用原理，不依据品牌宣传，不依据任何测速。品牌层面只呈现协议标注，传输方案全部待核实。协议维度在横向对比中的处理方式见 了解横向对比表中协议字段的口径。
常见问题指向
“代理服务端能看到什么”指向本文环节三；“DNS 走哪里”指向 DNS 泄露文章；“为什么不能跳过证书校验”指向 allowInsecure 文章；“哪些信息应该避免经过代理”指向 划定哪些账号与数据不应经过第三方服务。
方案关联：品牌协议标注与加密结构的关系
品牌资料中与加密结构相关的只有协议标注一项。下表按资料原文归纳，不做任何推断。
| 协议标注 | 品牌数 | 对加密结构的含义 | 仍需核对的字段 | 状态 |
|---|---|---|---|---|
| VLESS | 12 | 加密由外层 TLS 类方案承担，具体方案未写明 | 传输方案、证书配置、是否 REALITY 或 XTLS | Vendor Data |
| 待核实 | 5 | 无法判断加密结构 | 协议类型及全部传输参数 | 待核实 |
标注 VLESS 的 12 个品牌为光速云、U1S1、唯兔云、宇宙云、光年梯、一翻云、二猫云、SOGO云、可信云、速界、快狸、全球云；待核实的 5 个为微风网络、飞猫云、星岛梦、灵猫网络、极连云。这一标注只说明 VLESS 的加密依赖外层，不说明外层具体是什么。按协议标注查看品牌可从 按协议标注筛选品牌库条目 进入，对协议待核实的品牌，下单前的确认方式见 把协议与传输方案列入待核实字段清单。
优点、限制与风险提示
叠加加密结构的优点
本地网络与运营商只能看到外层连接的外部特征，看不到目标与内容；代理服务端看不到 HTTPS 内容；目标网站看不到你的本地地址。三方各自只掌握一部分信息，没有单一节点拥有完整画像。配置层面，只要传输方案是 TLS 类、证书校验开启、DNS 远程解析，这个结构就自动成立。
限制
代理服务端始终能看到目标地址与流量规模，这是转发所必需，无法通过配置消除；明文 HTTP 站点在代理之后的路径上没有任何保护；握手阶段的 SNI 与指纹是明文；重复加密带来额外运算，Vision 类方案只能部分缓解；加密不能防止代理服务端记录元数据，服务端的日志策略不在用户控制范围内。
风险提示
- 代理服务端是传输加密的终点，选择服务时应把服务方的可信程度视为与加密强度同等重要的因素，相关思路见 把服务方可信度纳入风险控制的考量。
- 不要在明文 HTTP 站点提交账号、密码或支付信息，代理不会为这一段提供保护。
- 不要为了解决连接问题开启跳过证书校验，这会让外层加密失去对中间人攻击的防护。
- 账号类信息即使经过加密信道，仍应遵循基本的账号安全实践，见 为代理账号与关联邮箱设置独立凭据。
- 本站不对任何品牌的服务端日志策略做判断，品牌资料中没有相关字段，均为待核实。
常见问题
开了代理之后，我的流量是不是全程加密的？
不是。代理协议提供的是传输加密，覆盖范围是从你的客户端到代理服务端这一段。流量在代理服务端被解开外层封装后，以原本的形式发往目标网站。如果你访问的是 HTTPS 站点，内容本身另有一层由浏览器与网站之间建立的加密，这一层代理服务端也解不开；如果访问的是明文 HTTP 站点，内容在代理服务端到目标网站这一段就是明文。
传输加密和端到端加密到底差在哪？
传输加密保护的是相邻两个节点之间的一段链路，到达节点后数据会被解开再处理，代理协议的 TLS 层就是这种。端到端加密保护的是通信双方之间的全部路径，中途任何节点都只能转发密文而无法读取，HTTPS 中浏览器与网站之间的 TLS、即时通讯软件的端到端加密都属于这种。两者可以叠加：代理的传输加密在外层，HTTPS 的端到端加密在内层。
代理服务端能看到我访问了什么？
能看到目标地址，包括域名或 IP 与端口，因为代理需要这些信息才能完成转发。对于 HTTPS 站点，代理服务端看不到页面内容、提交的表单与账号密码，因为这些在浏览器与网站之间的加密层内。对于 HTTP 明文站点，代理服务端可以看到全部内容。此外代理服务端还能看到连接时间、流量大小等元数据。
为什么说 VLESS 本身不加密还能安全使用？
因为 VLESS 的设计是把加密职责完全交给外层的 TLS 或其变体。VLESS 协议头只负责传递用户标识与目标地址，不做加密运算；当它被包裹在 TLS、REALITY 或 XTLS 之内时，整个 VLESS 数据流都处于加密信道中。安全性来自外层，而不是 VLESS 自身。反过来，如果配置成没有任何外层加密的裸 VLESS，流量就是明文，这种配置不应在公网使用。
HTTPS 网站的内容在代理服务端会被解密吗？
不会。浏览器与 HTTPS 网站之间的 TLS 会话是端到端建立的，密钥只存在于浏览器与网站两端，代理服务端只是把加密后的字节转发过去。代理服务端能看到你连接了哪个域名、传输了多少数据，但看不到请求路径、页面内容与表单字段。前提是你没有在设备上安装来源不明的根证书，也没有在客户端开启跳过证书校验。
DNS 查询在哪一层，会被加密吗？
这取决于解析发生在哪里。如果客户端把域名原样交给代理服务端去解析，查询就在代理的加密信道内完成，本地网络与运营商看不到。如果客户端或系统在本地先解析再连接，查询会以传统明文 DNS 的形式发往本地解析器，不经过代理加密。DNS 泄露就是后一种情况在不应发生时发生了。
重复加密会不会浪费性能？
会有额外的运算开销，因为 HTTPS 内容已经加密一次，外层代理 TLS 又加密一次。这正是 XTLS Vision 这类流控方案想解决的问题：在识别出内层已是 TLS 数据后，减少外层的重复加密。本站不提供任何关于这种开销大小的数值，它受设备性能、密码套件与数据类型影响，脱离具体环境没有参考意义。
本地网络和运营商能看到什么？
在客户端到代理服务端这一段，本地网络与运营商能看到的是你与代理服务端之间存在一条加密连接，包括服务端地址、端口、连接时间、流量大小，以及握手阶段的明文信息如 SNI 与 TLS 指纹。它们看不到被封装在加密信道内的真实目标地址与内容。如果 DNS 在本地明文解析，域名列表会额外暴露。
怎么逐段核对自己的加密覆盖范围？
分三步。第一步看客户端配置中的传输方案字段，确认外层是 TLS 类方案而不是裸协议，并确认证书校验处于开启状态。第二步在开启代理后访问 DNS 检测页面，确认解析器归属不是本地运营商。第三步看浏览器地址栏的锁形标识，确认目标站点是 HTTPS。三步都通过，说明两层加密与 DNS 都在预期范围内。
品牌资料里有写加密方式吗？
没有。本站 17 个品牌的资料只有协议标注一项与加密话题相关，其中 12 个标注 VLESS、5 个待核实；传输方案、是否使用 REALITY 或 XTLS、证书配置等字段全部未写明。协议标注只能说明可能的加密结构，实际覆盖范围需要在拿到订阅文件后对照本文逐段核对。
下一步
理解了每一段的加密状态之后，可以回到 从协议总览看各协议把加密放在哪一层 复核协议之间的差别；要把这些核对项落到具体客户端上，可从 进入客户端总览查看各平台的模式与分流设置入口 开始；若仍在选型阶段，协议与加密只是清单中的一项，完整流程见 回到选型流程看协议字段在清单中的位置。
Cluster · security
安全与隐私
- TLS 指纹与 uTLS：客户端指纹为何影响连接什么是 TLS 指纹，为什么客户端需要模拟浏览器指纹？
- 代理流量的加密层次：传输加密与端到端加密的区别使用代理后流量在哪些环节是加密的？
- DNS 泄露是什么：检测方法与客户端设置什么是 DNS 泄露，如何检测和避免？
- WebRTC 泄露与浏览器设置WebRTC 泄露是怎么发生的，浏览器怎么设置？
- 跳过证书校验（allowInsecure）的风险为什么不建议开启跳过证书校验？
- 客户端从哪里下载：来源校验与签名检查如何确认下载的代理客户端是安全的？
- 流量特征与识别：协议伪装的原理与边界代理流量为什么可能被识别，伪装能做到什么程度？
信息来源与更新日期
- 信息来源：通用技术资料（TLS 与 HTTPS 的通用原理、传输加密与端到端加密模型、VLESS、Trojan、Shadowsocks、VMess 协议设计文档所述加密位置、REALITY 与 XTLS Vision 的公开设计说明）；品牌公开资料/用户提供清单（协议标注）。
- 数据状态：全部品牌为 Vendor Data，测速 Not Tested，传输方案与证书配置字段全部待核实。
- 数据核实日期：2026-10-18。
- 最近更新时间：2026-10-18。
- 本页不构成推荐，不承诺任何平台的收录或排名；协议与客户端功能如有变更，以各自官方信息为准。