代理协议
本页主要写一些有关“境外 IP 资源”的问题，从圈内的“代理协议”这个概念引入，逐步介绍 GFW 的一些情况。
由于本页的消息大多数来自机场圈子的实践结果，所以会有以下问题：
- 部分协议由于没什么机场用过，无实践数据，所以无记载，或者简单带过
- 与自用场景差别很大，例如有些协议自用不墙，机场墙，是很正常的
不加密类 / VPN 类
Socks / HTTP / Wireguard
GFW 很早就具有“穿透”并动态拦截这些明文代理/传统 VPN 的能力，直连是无法过墙的。
全加密类
某些时期的 GFW 可能会认为：
全加密 = 未知协议 = 可能翻墙，需要管控
Shadowsocks / VMess
多用户场景下性能 VMess 远大于 Shadowsocks AEAD。
VMess 协议标准混乱，客户端兼容性有问题。
有些地区会给未知流量分配超低 QoS 等级，导致速度很慢。
有些校园网会屏蔽全加密流量。
SS2022
最近有一些机场上了 SS2022 并且标榜解决了多用户场景下性能问题（其实这是 SS/Vmess 特有的问题，其他协议根本无需解决），而且握手延迟比 Trojan 低。
简单科普其“解决”的原理：全站统一一个密钥（也就是密码的前半部分），用这个密钥对称加密用户的密码和代理数据。因此解密后服务器可以直接匹配出用户密码，不再需要像 SS AEAD 一样暴力解密。
正常开发者应该使用 TLS 这种现成的加密套件，而不是使用固定的密钥。SS2022 握手延迟低的代价是什么呢？本题留作思考。
SSR
其实不是全加密，而是伪装 HTTP。伪装的全是 2016 年左右的软件，现在反而成为了特征。
老古董，曾经的多用户优化方案。新面板都不支持。
WS 类
众所周知，WS 传输是明文，大多数情况下 WS 只是一个 HTTP 头。因此 WS 被墙与否主要取决于运载的上层协议（如 Vmess）的客户端实现。
Host / Path
WS 中的 Host / Path 参数是明文的，请不要包含机场官网之类的信息。
放国内可能会抓备案。
TLS 类
此类协议显著特点是许多客户端不支持多路复用，因为 TLS 握手造成了额外的延迟开销以及一些奇怪的流量特征（俗称 TLS in TLS）。如果不通过修改协议，处理掉这些特征，以 Trojan 为例，是会被全自动无人值守地墙端口/IP的。
SNI
TLS 中的 SNI 参数是明文的，请不要包含机场官网之类的信息。
放国内可能会抓备案。
VLESS
VLESS 类协议试图通过 TLS ClientHello 指纹模仿和 XTLS-Vison 固定长度填充技术达成 "防墙" 效果，然而据某些直连机场测试，仍然有概率发生封禁。 图片： VLESS+Vision+Reality 运载 TLSv1.3 流量情况的抓包记录，上方部分为 C->S 方向，下方部分为 S->C 方向，标出 tls opaque size。 图片： Chrome H2 流量不经过代理的抓包记录，上方部分为 C->S 方向，下方部分为 S->C 方向，标出 tls opaque size。过往记录 2024.09
过往记录 2024.10
VLESS+WS+TLS/uTLS VLESS+Vision+Reality 等组合也开始被墙了。有关 TLS 流量墙的分析，以 VLESS 为例
VLESS+Vision 的初始包大小分布固定，且与普通 H2 差异巨大，这是最有可能造成被墙的原因（请看下方图片）。而 VLESS+TLS/Reality VLESS+WS+TLS 这类组合根本没有对包大小进行处理，在 TLS in TLS 问题场景等于是与 2017 年的 Trojan 相比毫无进步（自行抓包查看）。Vision 带有 TLS 流拼接功能（据原设计者描述，可以降低性能开销），根据近期的一些报告，有时甚至会拼接错，暴露出一些非常诡异的包。
REALITY
Xray-core 圈子推荐的捆绑组合的一部分，在实际配置中充当了“代替 TLS”的作用。
- 流量依赖“真实站点/向源站发起请求” → 造成 DoS 源站的问题
- 对上游 CDN/源站依赖强 → 生产环境稳定性差
伪装 SNI 需求 与 allowInsecure 与 REALITY
一、现实需求：用户真正想要什么
- SNI 伪装能力
- 配置越简单越好（不想理解证书体系）
- 尽量避免因证书问题导致失败
二、朴素解法
在网络工具整体生态里，这类需求一直有"低门槛解"：
- 跳过证书验证（如
allowInsecure） - 不理解证书链 / pin 机制也能连通
- 简单 SNI 伪装即可工作
👉 这些方法在"其他客户端/实现"里仍然存在。
三、Xray-core 移除 allowInsecure 导致的现实结果
Xray-core 近期渲染 allowInsecure 中存在的 MITM 风险并 移除 allowInsecure 这条路径
结果：用户被迫寻找"仍然简单可用"的替代方案.
- 不会配证书 → 更倾向 Reality
- 会配置 TLS → 使用 pin/verify 标准模型
AnyTLS
2025 年新出的协议，似乎可玩性较高，可以作为 VLESS+Vision Trojan 等生态位的补充/替代？
抓包发现包长度的问题仍然存在，只是没有 VLESS 那么严重，预计以后还是会被墙（据原设计者描述，该协议可以更改 Padding 策略缓解上述问题，这就只能交给时间检验了）。
2026.5
目前这类协议被墙和订阅关系较大，详情请看下方「订阅泄露问题」。
QUIC 类
QUIC 类协议多线程测速基本跑不上 100MB/s，但是没有用户需要这么高的速度，请不要以测速好看为终极目标。
此外，某三大运营商对待 UDP 流量的脑残规则也是影响 QUIC 类协议体验的重要因素。具体情况可参考原生UDP的介绍。 目前 GFW 已具备解密 QUIC SNI 的能力。但是还未对 hy2 直连下手。 三中全会期间封了一大批 Hy2 的 IP，然后又不封了？ 后注: 我记得这次封禁并没有按照 7 天的封禁时间，而是在大会结束后的某一天几乎全部释放了。结合后续 hy2 没有再被封的情况，可能是因为这次的识别方法仍然不靠谱？过往记录 2024.04
过往记录 2024.07
2025.11
Hysteria2 和 TUIC 协议似乎已经能被自动墙。~时隔一年多，GFW 的 QUIC 工作终于取得了显著胜利。~
后续发现这类协议被墙和订阅关系较大，详情请看下方「订阅泄露问题」。
CDN 类
CDN 套 WS / TLS 的用法本质上是利用了 Cloudflare / Cloudfront 的 IP 段【属于 CDN 段白名单】的特性，此类用法虽然不会造成 IP 封禁，但可能会造成【域名封禁】。
题外话：现代浏览器(Chrome/FireFox/Edge/Safari)早已开始灰度测试 ECH。ECH 配 CDN 现在可以让很多人直接打开原本被墙的网站（前提是 DNS 没有被污染）。ECH 可能继 QUIC 之后，GFW 下一个重点研究的方向？
自研协议
所谓自研私有协议，过墙优势基本来自小众和闭源，性能优势来自不同开发者的优化。
请以实际表现为准，勿听信某些不合实际的商业宣传。
Multiplex
包括 Nyanpass 的很多软件都支持。
一般作为一个叠加层存在（可选或强制开启）。降低延迟，同时降低测速，但是没有用户需要这么高的速度，请不要以测速好看为终极目标。
能显著减少 TCP 连接的创建，节约防火墙算力资源。
订阅泄露问题
这是容易被忽略的一个风险面。最近多发的“秒墙”大概率是因为订阅泄露的问题。
正如之前在通报问题所述：
微信 / QQ 等国内软件有监控，如果您的类人用户将订阅发到上面，就会被捕获引来爬虫。
越来越多的证据显示，与前几年相比，现在的“有关部门”越来越喜欢（或者说依赖）用 买订阅 的方法来获取机场入口 IP。
以上问题，在直连中依然存在，会导致墙 IP。
该爬虫会对你的订阅节点进行主动测活，截至 2026.5 它已经支持了 Vless+Vision / Anytls / Hy2 等常见协议。
由于公开该爬虫的具体行为特征可能导致其发生变种，若想处理这个问题，请自行分析日志，自行应对。
最后
关于网络协议的分析，不可避免地有很多遗漏。很多情况无法在一页内说明，否则这篇文章会特别长。
如果问我机场/跨境电商/Tiktok推荐用什么协议，只能得到一个答案：这都看不懂，尽快跑路吧。