代理协议组合完全手册：原理、拼法与选型
学习目的：这份文档只做一件事——把市面上五花八门的“节点协议”拆回零件，让你看到任何一个组合时，能说出它由哪几层拼成、为什么这样拼、代价是什么。
文中所有示例均为虚构占位：域名统一用 node.example.com 一类保留域名，端口统一用 443，UUID、密码、密钥全部写成占位符，不对应任何真实部署。配置片段是节选示意，用来看字段之间的关系，落地前请对照你所用核心（sing-box / Xray）的官方文档核对字段名与版本要求。
0. 阅读方法：任何组合都按四层拆
一个“节点”从来不是单个协议，而是四层拼装：
| 层 |
回答的问题 |
常见选项 |
| ① 代理内核 |
谁在说话、怎么认证、代理语义是什么 |
VLESS、VMess、Trojan、Shadowsocks、AnyTLS、Hysteria2、TUIC |
| ② 传输层 |
内核的字节装进什么载体送过网络 |
裸 TCP、WebSocket、HTTPUpgrade、HTTP/2、gRPC、XHTTP、QUIC |
| ③ 安全伪装层 |
怎么加密、在旁观者眼里像什么 |
真 TLS、REALITY、uTLS 指纹、ShadowTLS、无 |
| ④ 增强件 |
性能与形态的微调 |
Vision 流控、mux 多路复用、ALPN、端口跳跃、混淆插件 |
再叠加一个接入维度（不属于协议本身，但决定组合的实际形态）：直连 / CDN 前置 / Tunnel 穿透 / 中转机转发。同一个协议组合，换一种接入方式，优缺点会完全不同（见第 7 章）。
拼装不是自由组合：每层之间有硬约束。比如 VLESS 没有自带加密，第 ③ 层就不能空着；Hysteria2 把 ①②③ 打包成闭环，就没有可换的外衣。理解组合 = 理解约束。
1. 代理内核详解
1.1 VLESS
- 原理：极简代理协议。客户端用 UUID 表明身份，头部只带目标地址等最必要的信息，本身不做加密——出去的字节是否安全，完全取决于外层。
- 为什么这样设计：把加密交给 TLS 这类成熟协议，内核只管代理语义，于是开销最低、实现最干净，也最适合和各种传输/伪装层拼装。
- 代价：裸奔等于明文代理，特征与内容一起暴露，禁止单独使用。
1.2 VMess
- 原理：上一代全能协议。UUID + 时间戳派生动态认证，自带 AEAD 加密（AES-128-GCM / ChaCha20-Poly1305），不依赖外层 TLS 也能独立工作。
- 现状：设计年代早，协议特征多、心智负担重（时间同步、alterId 历史包袱），性能与隐蔽性都被 VLESS 全面替代。学习价值在于理解“自带加密型内核”的取舍，新部署不再选它。
1.3 Trojan
- 原理：密码校验藏在一条真正的 TLS 连接里。服务端先完成 TLS 握手，再检查流量开头是不是合法的 Trojan 请求；不是，就把连接当普通 HTTPS 请求回落到一个真实网站。
- 哲学：不模拟别人，自己就是一个能正常打开的网站。对探测者而言，它与普通站点的区别最小。
- 约束：与 TLS 共生，没有 TLS 就没有 Trojan；也因此不能再套 REALITY（见 3.2）。
1.4 Shadowsocks（含 2022 版）
- 原理：纯粹的加密转发。客户端与服务端共享一个密码，每个连接用盐派生会话密钥做 AEAD 加密，TCP、UDP 都能带。2022 版改用 BLAKE3 派生子密钥并引入时间窗，修掉了老版的重放与密钥派生问题。
- 性格：自带加密、不带伪装。流量在旁观者眼里就是一串高熵随机字节——内容安全，但“这是一条代理流”的嫌疑也最直白。
- 变体：靠插件加外衣，如 v2ray-plugin（套 WebSocket）、shadow-tls（套一层真 TLS 握手外观），见组合卡片 ⑮⑯。
1.5 AnyTLS
- 原理：较新的内核，跑在 TLS 之上，重点解决“TLS in TLS”的包长与时序特征：通过分片、填充与会话复用，让内层再跑 HTTPS 时不那么容易被指纹识别。
- 现状：生态还在铺开（sing-box 等已支持），属于值得观察的新选项，本手册把它列进组合表，但不列为保守首选。
1.6 Hysteria2
- 原理：基于 QUIC（UDP 之上的可靠加密传输，内含 TLS 1.3）的代理协议，①②③ 三层打包成一个闭环。招牌是 Brutal 拥塞控制：运维者显式告诉它“这条链路上下行各有多少带宽”，它就按接近这个速率发送，不理会丢包发出的降速信号。
- 为什么有效：跨国链路晚高峰的丢包多半来自拥塞与限速，TCP 系拥塞控制一见丢包就降速，越降越慢；Brutal 用“已知带宽”代替“猜带宽”，在烂线路上反而跑满。
- 代价：速率设得比真实带宽高会加剧丢包、设低了浪费；UDP 本身在某些网络会被限速或封锁；另有 salamander 混淆把 QUIC 的初始指纹抹平。
- 附带能力：端口跳跃（服务端监听一段端口范围，客户端随机切换），用来对付针对单端口的 UDP 限速。
1.7 TUIC
- 原理：同样基于 QUIC，但性格守规矩：用 BBR 等标准拥塞控制、原生 UDP 中继、连接迁移（客户端换网络/IP 时连接不中断）。
- 与 Hy2 的分工：Hy2 是“烂线路上用蛮力跑满”，TUIC 是“正常线路上低开销稳妥地跑”。线路不差时 TUIC 的自适应反而更省心。
1.8 参照系（不是代理内核，但常被混谈）
- WireGuard：VPN 协议，整机组网思维，UDP 直连、无伪装层概念。常被当“节点”用，但它解决的是组网，不是代理分流；流量特征就是 WireGuard。
- SOCKS5 / HTTP 代理：局域网与本机入口协议，无加密，是客户端软件的“本地门”，不承担公网段传输。
- MTProxy 等应用专用代理：为单一应用定制，不在通用组合体系内。
2. 传输层详解
2.1 裸 TCP
内核字节直接进 TCP 连接。开销最低、延迟最小，但协议特征毫无遮拦——只能配强安全层（TLS / REALITY）出门。
2.2 WebSocket（WS）
- 原理：先发一条普通的 HTTP 请求带
Upgrade: websocket，服务器同意后，这条连接“升级”为全双工管道，之后按 WS 帧格式传内核字节。
- 关键性质：升级之前与普通网页请求无异，所以 CDN 与 Tunnel 只认 HTTP 的基础设施都能放行。帧头与一次额外握手带来少量开销；实践中常配
early data（把首包塞进握手）削掉一个往返。
2.3 HTTPUpgrade
WS 的轻量近亲：同样借 HTTP Upgrade 起手，但升级后不再套 WS 帧，直接当管道用。少一层帧开销，生态位与 WS 大量重叠，新部署可作替代了解。
2.4 HTTP/2（H2）
直接拿 HTTP/2 的多路复用流当管道：一条 TCP 连接里开许多条 Stream 并行传不同目标的流量。性质与 gRPC 同源（gRPC 就跑在 H2 上），区别见下。
2.5 gRPC
- 原理：用 gRPC 框架的双向流方法承载内核字节。流量在外观上就是后端服务之间常见的 API 调用，多路复用由底层 HTTP/2 提供。
- 拼装要点：客户端与服务端要约定同一个
serviceName（相当于暗号路径）；经 CDN 时需要 CDN 放行 gRPC（HTTP/2 回源）。
2.6 XHTTP（SplitHTTP）
- 原理：新一代传输，上下行分离：上行用一串 POST 请求、下行用 GET 长连接流式返回，每一段单独看都是普通 HTTP 请求；还支持把上下行放到不同域名/不同 CDN 后面。
- 定位：为“经 CDN 的代理传输”重新设计，正在接替 WS/gRPC 的生态位。属 Xray 系主场特性，其它核心的支持情况以各自文档为准。
2.7 QUIC（作为传输）
Hysteria2 / TUIC 的地基：UDP 之上重建可靠、有序、加密的传输，自带连接迁移与 0-RTT。它是“传输+安全”一体件，不与 VLESS 等 TCP 系内核拼装（Xray 曾有 QUIC 传输，现已边缘化，了解即可）。
2.8 已退场的传输
KCP（UDP 模拟 TCP 提速）、DomainSocket、老式 HTTP 伪装头等，历史上都红过，现已被 QUIC 系与 XHTTP 取代。学习时认出名字即可，不必投入。
3. 安全伪装层详解
3.1 真 TLS（自己的域名与证书）
- 做法：给服务端域名签一张正经证书（Let's Encrypt 或云厂商 CA），内核跑在 TLS 之内；通常再放一个真网站做回落，探测者打开域名看到正常页面。
- 强项：一切都是真的——证书可查、网站可开。
- 软肋：元信息是自己的——SNI 是你的域名、证书是你的、IP 是你的机房。审查者不需要破解内容，光靠“这个域名+这个 IP 在传大量 TLS 流量”就能做判定与封锁。
3.2 REALITY
- 原理三步：
1. 客户端发起 TLS ClientHello，其中 sessionId 字段藏了一段基于 X25519 的认证数据；
2. 服务端认出自己人后，借一个真实大站的 TLS 握手素材完成加密协商——旁观者看到的证书、指纹都属于那个真站；
3. 没带有效认证的连接（包括主动探测），服务端把它们真的转发去那个大站，探测者拿到的是真站内容。
- 效果：不需要自己的域名与证书，SNI 指向大站，主动探测无从下手。
- 硬约束：握手必须客户端与源站直达，中途不能有 CDN 或 Tunnel 终结 TLS——所以 REALITY 与 CDN 互斥；借用的目标站要选网络上“近且稳”的，选远了握手延迟会露馅。
3.3 uTLS 指纹模拟
TLS 客户端的 ClientHello 有可识别的指纹（JA3 等）。uTLS 让代理客户端把这份指纹模拟成 Chrome 等真实浏览器，使握手第一眼不像代理软件。它是给 3.1/3.2 打补丁的配角，不能独立存在。
3.4 ShadowTLS
给 Shadowsocks 这类“裸加密流”套一层真 TLS 握手外观：前段字节是与真站完成的 TLS 握手，后段才是 SS 的加密流量。相当于给 SS 补上第 ③ 层，是插件式拼装的典型例子。
3.5 “无安全层”的适用面
只存在于：内核自带加密且场景低对抗（Shadowsocks 2022 直连）、或链路本身在可信网络内（内网、已组 VPN 之上）。公网直连 VLESS/VMess 裸奔不在此列——那是错误配置，不是组合。
4. 增强件
4.1 Vision（flow = xtls-rprx-vision）
- 解决什么：代理里跑 HTTPS 是“TLS 套 TLS”，双层加解密有开销，握手包的包长特征还很显眼。
- 做法：Vision 在 TLS 内识别内层 TLS 握手，给握手包加填充抹平长度特征；识别完成后对内层连接直通转发（splice），不再层层拆包。
- 约束：只适用于 VLESS + TCP + TLS/REALITY；与 mux 互斥（见 4.2）。
4.2 mux 多路复用
把多条逻辑连接塞进一条物理连接，省去反复握手。代价：一条连接承载一切，队头阻塞与流量特征都更集中；与 Vision 机制冲突（一个要合流拆包、一个要直通），同开必坏——这是最常见的“配置单里两个开关打架”案例。
4.3 ALPN 与版本细节
TLS 协商出的 ALPN（h2 / http/1.1）会写进流量外观，也决定某些传输能否成立（如 gRPC 需要 h2）。拼装时它是小字段、大影响：填错的表现往往不是报错，而是“连得上但特征不对”或“CDN 回源失败”。
4.4 端口跳跃与混淆（Hy2 系）
端口跳跃对付单端口 UDP 限速；salamander 混淆对付 QUIC 指纹识别。两者都是 Hy2 在敌意网络里的生存件，不改变协议本体。
4.5 回落（fallback）
Trojan 与部分 VLESS 部署会把“认证失败的流量”回落到一个真网站。回落不是加密，它买的是可探测性：让服务器在被试探时表现得像个普通站点。
5. 组合可行性总表
✓ = 主流可行 △ = 能拼但小众/有前提 ✗ = 机制上不成立
| 内核 \ 外层 |
裸 TCP 直连 |
+ 真 TLS |
+ REALITY |
+ WS |
+ H2/gRPC |
+ XHTTP |
经 CDN |
经 Tunnel |
| VLESS |
✗ 无加密 |
✓（可加 Vision） |
✓（可加 Vision） |
✓ 配 TLS |
✓ 配 TLS |
✓ 配 TLS 或 REALITY |
✓ 仅 HTTP 系传输 |
✓ 仅 HTTP 系传输 |
| VMess |
△ 自带加密、低对抗 |
✓ |
✗ |
✓ 配 TLS |
✓ 配 TLS |
✗ |
✓ |
✓ |
| Trojan |
✗ |
✓ 本体形态 |
✗ |
✓ Trojan+WS 变体 |
△ |
✗ |
✓ WS 变体 |
✓ WS 变体 |
| Shadowsocks 2022 |
✓ 自带加密 |
△ 经 ShadowTLS |
✗ |
✓ 经插件 |
△ |
✗ |
✓ WS 插件形态 |
✓ WS 插件形态 |
| AnyTLS |
✗ |
✓ 本体形态 |
△ 视实现 |
✗ |
✗ |
✗ |
✗ TLS 被终结则失效 |
✗ 同左 |
| Hysteria2 |
— 自成闭环（UDP 直连） |
内置 |
✗ |
✗ |
✗ |
✗ |
✗ |
✗ |
| TUIC |
— 自成闭环（UDP 直连） |
内置 |
✗ |
✗ |
✗ |
✗ |
✗ |
✗ |
读表要点：
- CDN / Tunnel 两列只跟传输层有关：外衣是 HTTP 系（WS/H2/gRPC/XHTTP）才进得去，与内核是谁无关。
- REALITY 一列只亮 VLESS：它是为“无自带加密的内核借握手”而生的拼法。
- Hy2/TUIC 整行是闭环：它们的“组合”体现在接入维度（直连/中转）和增强件（跳跃/混淆）上，不在外衣上。
6. 组合卡片
每张卡片统一结构：构成 → 连接流程 → 配置方法（思路+节选示意）→ 优点 → 缺点 → 适用场景。
① VLESS + TCP + REALITY + Vision —— 直连伪装天花板
- 构成：VLESS 内核 / 裸 TCP / REALITY 伪装 / Vision 流控。
- 流程：客户端向源站发起“看起来发往某个大站”的 TLS 握手（sessionId 藏认证）→ 服务端验明身份、借大站握手完成协商 → Vision 接管内层 TLS 的填充与直通 → 代理数据直达源站，全程无中间人。
- 配置方法（sing-box 系节选示意）：
// 服务端入站
{ "type": "vless", "listen": "::", "listen_port": 443,
"users": [{ "uuid": "00000000-0000-4000-8000-000000000000", "flow": "xtls-rprx-vision" }],
"tls": { "enabled": true, "server_name": "www.example.net",
"reality": { "enabled": true,
"handshake": { "server": "www.example.net", "server_port": 443 },
"private_key": "<服务端生成的 REALITY 私钥>",
"short_id": ["0123456789abcdef"] } } }
// 客户端出站与之对应：uuid 相同、flow 相同、tls.reality.public_key 填服务端公钥、short_id 选一个
- 优点：无自有域名/证书的心智负担；主动探测被真转发到大站；Vision 让性能接近裸 TCP 上限。
- 缺点：源站 IP 直接暴露在连接里，IP 被封即全灭；借用的大站要近、稳、支持 TLS 1.3 与 X25519，选错会慢或露馅；进不了 CDN/Tunnel。
- 场景：线路质量不差、主要防探测的自用直连。
② VLESS + TCP + TLS + Vision —— 有自己域名时的直连正装
- 构成：同 ①，但安全层换成自有域名的真 TLS。
- 差别：证书与 SNI 都是自己的，可配真网站回落，运维上更“正经”（证书自动续期、日志完整）；代价是域名与 IP 的绑定关系公开可查，抗封锁弱于 ①。
- 场景：域名不心疼、想要正规站点外观时。
③ VLESS + WS + TLS（直连） —— 最经典的入门组合
- 构成：VLESS / WebSocket / 真 TLS，域名直解析到源站。
- 流程：TLS 握手 → HTTP Upgrade 到约定路径（如
/assets）→ WS 帧承载 VLESS。
- 配置方法（节选示意）：
{ "type": "vless", "listen_port": 443,
"users": [{ "uuid": "<占位 UUID>" }],
"transport": { "type": "ws", "path": "/assets" },
"tls": { "enabled": true, "server_name": "node.example.com",
"certificate_path": "/path/to/cert.pem", "key_path": "/path/to/key.pem" } }
- 优点：实现简单、兼容性最好，几乎所有客户端都支持；路径、域名都可换。
- 缺点：直连时它只是“穿了件 HTTP 外套的直连”，IP 照样暴露；WS 帧与握手带来小额开销；路径特征若用默认值容易被指纹库收录（务必改路径）。
- 场景：学习拼装的第一课；也是 ④ 的前置形态。
④ VLESS + WS + TLS + CDN —— 抗封锁保险
- 构成：在 ③ 的基础上，把域名解析改经 CDN（小黄云），客户端连的是 CDN 边缘，CDN 再回源到源站的 WS 入站。
- 流程变化：TLS 在 CDN 边缘被终结，边缘→源站是第二段连接；源站 IP 不再出现在客户端视野里。
- 配置方法：服务端与 ③ 相同；额外三件事——域名 DNS 托管到 CDN 并开代理、CDN 侧 SSL 模式选 Full (Strict)、源站防火墙只放行 CDN 的回源 IP 段。客户端地址填域名（或优选后的边缘 IP），SNI/Host 保持域名。
- 优点：源站 IP 隐藏，IP 被封换 IP 不换域名即可续命；借 CDN 的 IP 池与信誉。
- 缺点：全组合里延迟与抖动最高的一档，速度取决于 CDN 免费网络的回源质量；多一层故障点；本质是可用性保险，不是加速器——直连线路好时它一定更慢。
- 场景：IP 频繁被封、或源站地址绝不能暴露时。
⑤ VLESS + gRPC + TLS（可经 CDN）
- 构成：VLESS / gRPC / 真 TLS。
- 配置方法：服务端
transport: { "type": "grpc", "service_name": "myservice" }，客户端填同一 serviceName；经 CDN 时确认 CDN 已开启 gRPC/HTTP2 回源支持。
- 优点：流量外观是正经 API 调用；HTTP/2 多路复用对多连接场景友好。
- 缺点：serviceName 用默认值等于自报家门；部分 CDN 免费档对 gRPC 的支持与超时策略不友好；生态热度正被 XHTTP 接替。
- 场景：想避开 WS 指纹、又需要 CDN 选项时。
⑥ VLESS + HTTP/2 + TLS
- 构成：VLESS 直接跑 H2 流。与 ⑤ 的区别是“用 H2 的管子”而不是“用 gRPC 的框架”。
- 优缺点：少一层 RPC 语义、实现更薄；但客户端支持面比 gRPC/WS 窄，社区经验也少。多数新部署会在 ⑤ 与 ⑧ 之间二选一，本组合更多是理解 H2 家族时的参照。
⑦ VLESS + XHTTP + TLS（可经 CDN）
- 构成：VLESS / XHTTP / 真 TLS。
- 流程：上行被拆成一串 POST、下行用 GET 长流返回；CDN 看到的是再普通不过的 HTTP 请求序列。
- 优点：为经 CDN 而生，抗探测与灵活性（上下行分离、可分域名）都是当代最强档；直连也可跑。
- 缺点：较新，客户端与面板的支持参差；参数（如分组模式）比 WS 多，调错了只剩“能连但慢”。
- 场景：今天新学“经 CDN 的传输”，优先学它，其次才是 WS。
⑧ VLESS + XHTTP + REALITY
- 构成：XHTTP 的传输 + REALITY 的握手，走直连。
- 要点：兼得上下行分离的形态与借握手的伪装；同样是较新组合，版本配套要求严（客户端/服务端核心版本要对齐）。适合进阶实验，不适合第一课。
⑨ VMess + WS + TLS + CDN —— 上一代经典（了解即可）
- 构成：VMess 自带加密，再套 WS+TLS 经 CDN。
- 历史地位：CDN 中转时代的开山组合，今天仍有大量存量。
- 为什么不选它了：内核特征与性能被 VLESS 取代；双层加密（VMess 自带 + TLS）纯属重复开销。学习价值：看懂它，就看懂了“自带加密型内核”的拼装逻辑。
⑩ VMess + TCP（自带加密直连）
- 最小形态的 VMess：不套任何外层。仅适合低对抗、可信网络的学习实验；公网高对抗环境不要用。
⑪ Trojan + TLS —— “我就是网站”
- 构成：Trojan 内核与真 TLS 一体，服务端同端口放一个真网站做回落。
- 配置方法（节选示意）：
{ "type": "trojan", "listen_port": 443,
"users": [{ "password": "<占位强密码>" }],
"tls": { "enabled": true, "server_name": "www.example.com",
"certificate_path": "/path/to/cert.pem", "key_path": "/path/to/key.pem" },
"fallback": { "server": "127.0.0.1", "server_port": 8080 } } // 回落到本机真网站
- 优点：探测者看到的是完整真站；结构简单，没有传输层可调参数。
- 缺点：域名、证书、IP 全是自有元信息，抗封锁靠“不被盯上”；密码即身份，没有 UUID 体系的多用户管理花样。
- 场景：低调自用直连；想要“打开域名是个正经网站”的形态时。
⑫ Trojan + WS + TLS（可经 CDN）
- Trojan 的变体（Trojan-Go 系与 sing-box 支持）：在 TLS 内再走 WS，于是能进 CDN/Tunnel。
- 取舍：换来 CDN 选项，代价是 Trojan“就是个网站”的纯粹性被 WS 路径特征稀释。需要 Trojan 又需要 CDN 时才选。
⑬ Shadowsocks 2022 直连 —— 轻量裸奔的正解
- 构成：SS 2022 内核单独工作，TCP+UDP 一把梭。
- 配置方法（节选示意）：
{ "type": "shadowsocks", "listen_port": 443,
"method": "2022-blake3-aes-128-gcm",
"password": "<服务端主密码（Base64 格式的密钥材料）>" }
- 优点：部署五分钟、开销极低、UDP 原生支持好，老设备也跑得动。
- 缺点：无伪装，高熵流量特征直白；密码体系简单，多用户要靠额外管理。
- 场景：低对抗、内网延伸、备用通道、给游戏/语音走 UDP。
⑭ Shadowsocks + v2ray-plugin（WS + TLS，可经 CDN）
- 构成：SS 流量塞进 WS 管道再套 TLS，结构上与 ③ 同构，只是内核换成 SS。
- 优缺点：老 SS 部署借此获得 CDN 续命能力；双层加密重复开销、插件维护状态参差。今天新部署一般直接选 ③/⑦，本组合主要为维护存量而学。
⑮ Shadowsocks + ShadowTLS v3
- 构成：SS 前面站一个 ShadowTLS：它先与“伪装目标站”完成一段真 TLS 握手，再把后续字节交给 SS。
- 优缺点：给裸 SS 补上了像样的第 ③ 层，且不需要自己的域名证书；但拼装件多一环，排障要分清坏在哪层。适合“就想要 SS、又怕它裸奔”的场景。
⑯ Hysteria2 直连（+ 跳跃 / 混淆） —— 烂线路蛮力档
- 构成：闭环协议，服务端一张证书（或自签+客户端填指纹/放行）、一个密码即可开跑。
- 配置方法（节选示意）：
{ "type": "hysteria2", "listen_port": 443,
"users": [{ "password": "<占位强密码>" }],
"tls": { "enabled": true, "server_name": "node.example.com",
"certificate_path": "/path/to/cert.pem", "key_path": "/path/to/key.pem" } }
// 客户端侧关键项：server_ports 写端口段做跳跃、bandwidth 按实测带宽填、obfs 选 salamander 并设口令
- 优点：晚高峰拥塞丢包环境里速度断层领先；UDP 原生；部署简单。
- 缺点：Brutal 带宽填错适得其反；UDP 在部分网络被限速/封锁时无外衣可换，只能换端口或换线路；机房 IP 暴露问题与一切直连相同。
- 场景：线路烂、延迟敏感、流量以 TCP 应用为主但被 TCP 拥塞控制拖垮时。
⑰ TUIC 直连 —— 守规矩的 QUIC 档
- 构成：闭环协议，UUID+密码认证，拥塞控制默认 BBR。
- 优缺点：比 Hy2 自适应、省心，移动端换网不断线；峰值吞吐在烂线路上不如 Brutal 蛮干，生态规模小于 Hy2。
- 场景：线路质量尚可、想要 QUIC 的低延迟与连接迁移时。
⑱ AnyTLS + TLS —— 新面孔观察档
- 构成：AnyTLS 内核跑在真 TLS 上，靠分片/填充/session 复用对抗 TLS-in-TLS 指纹。
- 优缺点：思路对症、实现轻；生态与客户端支持还在扩散期，版本间细节变动快。学习上适合拿来理解“为什么 TLS 套 TLS 会被识别”这个问题本身。
7. 接入维度：同一个组合的四种活法
协议组合决定“流量长什么样”，接入方式决定“流量从哪进”。两者相乘，才是部署全貌。
7.1 直连
客户端直达源站 IP。延迟最低、结构最简；源站 IP 完全暴露，抗封锁全靠协议伪装本身。①②⑪⑬⑯⑰ 的默认活法。
7.2 CDN 前置
域名经 CDN 代理，边缘终结连接再回源。隐藏源站、借 IP 池续命；代价是延迟、抖动与一层故障点。只有 HTTP 系传输（WS/H2/gRPC/XHTTP）能进，且 TLS 在边缘被终结，所以 REALITY 与一切 UDP 协议出局。重要提醒：CDN 加速的是“烂回源链路被骨干网替代”的那部分，对线路本来就好的直连，它只会更慢——它是保险，不是提速器。
7.3 Tunnel 穿透
机器主动向外建一条隧道（如 Cloudflare Tunnel 的 cloudflared），访客经隧道域名进来，流量顺隧道落到本机服务。解决“没有公网 IP / 在 NAT 后面”的机器发节点的问题（如免费主机、家里内网机）。限制与 CDN 相同：入口只认 HTTP 系；连接多绕一段，延迟高于直连。
7.4 中转机转发
在一台线路好的机器上做端口转发（iptables / realm / gost 等），客户端连中转机，中转机把 TCP/UDP 原样转给落地机。协议层对此无感，所以任何组合都能套，包括 Hy2/TUIC 与 REALITY。代价是多一台机器的钱与一跳延迟，换来的是线路质量（如优质回程线路）的跃升——这是“真加速”的常见来源：加速的是路由，不是协议。
四种接入横向对比
| 接入 |
延迟 |
隐藏源站 |
抗封锁 |
协议限制 |
成本 |
| 直连 |
最低 |
✗ |
靠伪装 |
无 |
最低 |
| CDN 前置 |
最高 |
✓ |
强（换 IP 续命） |
HTTP 系传输 |
低（有免费档） |
| Tunnel |
高 |
✓ |
强 |
HTTP 系传输 |
低 |
| 中转转发 |
中 |
△ 暴露中转机 |
中（中转 IP 可换） |
无 |
多一台机器 |
8. 选型决策线
按顺序问四个问题，答案自动收敛：
- 机器有公网 IP 吗？ 没有 → HTTP 系组合 + Tunnel（③⑤⑦ 的 Tunnel 版）。
- 源站 IP 经常被封、或绝不能暴露吗？ 是 → 经 CDN 的组合（④⑤⑦），接受它慢。
- 线路丢包/拥塞严重吗？ 是 → Hysteria2（⑯），先把 Brutal 带宽按实测设准；线路尚可但想低延迟 → TUIC（⑰）。
- 以上都不是，只是要一条干净的直连 → 防探测选 ①（REALITY+Vision），有正规站点需求选 ② 或 ⑪，图轻量选 ⑬。
反模式清单（新手最常见的拼错）
- VLESS 不套任何安全层：明文代理，不是“极简”，是错误。
- 给 VMess/Trojan 配 REALITY：机制不成立，配置可能能写、连接必然不对。
- mux 与 Vision 同开：两个开关互相打架，表现是“三端全灭”式的整组不可用。
- 指望 CDN 给好线路提速：方向反了，CDN 中转是拿速度换可用性。
- Hy2 的 Brutal 带宽照着宽带标称值填：要填的是“到这台服务器实测能跑到的带宽”，填高了丢包爆炸。
- 路径 / serviceName 用默认值：WS 路径、gRPC 服务名都是公开指纹，默认值等于挂牌。
- 拿 UDP 协议去套 CDN/Tunnel：入口根本不收，换多少配置都不行。
- 证书过期没人管：真 TLS 系组合最常见的“突然全灭”原因，自动续期要先于部署完成。
附录 A：学习实验建议（在自己的机器上做）
- 同一台服务器上并排部署 ③ 与 ①，用同一客户端测延迟与吞吐，亲手感受“外衣的成本”。
- 给 ③ 的域名开/关 CDN 代理各测一次，把 7.2 的结论变成自己的数据。
- Hy2 把 Brutal 带宽分别填实测值的 50% / 100% / 200%，看吞吐与丢包怎么变——这是理解拥塞控制最快的一课。
- 用抓包工具看 WS 升级握手与 REALITY 握手的前几个包，对照第 2、3 章的描述找字段。
附录 B：名词速查
- 回源：CDN 边缘没有内容时，向源站现取的那一趟请求；回源链路质量决定 CDN 形态的速度下限。
- SNI：TLS 握手里明文携带的目标域名，是伪装与审查共同盯着的字段。
- ALPN：TLS 协商出的应用层协议（h2 / http/1.1），影响传输成立与流量外观。
- splice（直通）：识别出内层加密流后不再逐层拆包，直接转发字节，Vision 的性能来源。
- 优选 IP：为 CDN 域名挑选对本地运营商路由最顺的边缘 IP，本质是给“访客→边缘”一段做人工选路。
- 回落：认证失败的连接被交给一个真网站处理，买的是抗探测性。
版本：学习整理稿。协议生态变化很快（尤其是 XHTTP、AnyTLS 这类新件），引用具体字段与支持情况时，请以你所用核心的官方文档为准。