VPN 加密解决的是“旁观者能否读懂内容”，抗封锁解决的是“旁观者能否判断这是一条需要阻断的隧道”。两者并不等价：即使每个载荷字节都无法解密，目标地址、握手形状、数据包长度和时间序列仍可能暴露协议身份。

第一阶段：封 IP 与封端口

最直接的封锁方式是维护 IP 或 IP:端口黑名单。它成本低、判断快，适合已知且较稳定的 VPN 网关。

应对方式也很直接：更换服务器地址、端口或入口域名。但这种方法没有改变协议特征。一旦新地址通过用户传播、扫描、DNS 记录或流量聚类重新暴露，又会进入黑名单。频繁换 IP 只是延长发现周期，不构成真正的协议级隐蔽。

共享云平台和 CDN 会提高封锁的附带成本：一个地址可能承载许多无关网站。但审查方也能结合 SNI、DNS、流量行为和云厂商地址段进行更精细的策略，不一定要封整个平台。

第二阶段：深度包检测识别协议

深度包检测（DPI）不必解密会话，只需寻找稳定指纹。早期协议往往有固定魔数、消息类型、字段位置或长度模式；现代加密协议也可能在握手阶段暴露可分类特征。

常见观察面包括：

  • 首包和后续握手包的固定长度；
  • 明文版本号、协议标识或错误响应；
  • TLS ClientHello 的扩展顺序、密码套件和指纹；
  • UDP/TCP 使用方式及连接持续时间；
  • 上下行包长分布与突发节奏；
  • 是否存在普通协议应有、而该实现缺少的行为。

把 OpenVPN、WireGuard 或其他隧道简单改到 TCP/UDP 443，并不会自动变成 HTTPS。443 只是端口；真正的 HTTPS 有 TLS 握手、证书链、ALPN、HTTP 语义和浏览器风格的交互。端口与内容不一致反而可能成为分类信号。

第三阶段：主动探测验证服务器

被动 DPI 可能误判，于是系统可以对可疑服务器主动发包。探测器模仿客户端握手、发送畸形消息或尝试不同协议，根据服务器是否响应、如何报错来确认其类型。

抗主动探测的核心原则是：未经认证的请求不应暴露协议身份。实现方式包括：

  • 首包携带只能由合法客户端生成的认证信息；
  • 认证失败时静默丢弃，而不是返回独特错误；
  • 或把失败连接转交给真实网页，让探测器看到合理的 HTTPS 行为；
  • 限制响应资源，避免认证前分配大量状态造成拒绝服务。

WireGuard 对未认证数据包保持静默，这有利于抗扫描，但其 UDP 消息尺寸和时序仍不是普通网页流量，因此“不可主动握手确认”不等于“无法被流量分类”。

第四阶段：把隧道包装成常见 TLS

TLS 伪装的目标不是“使用 TLS 就完成”，而是让外部观察者看到一个语法和行为都合理的 TLS 会话。典型方案让客户端连接一个看似正常的 HTTPS 域名，完成真实或接近真实的 TLS 1.3 握手，再在加密层内承载代理协议。

这类设计需同时处理三层一致性：

  1. 密码学一致性：握手和证书验证不能是可辨认的自造变体；
  2. 指纹一致性：ClientHello、扩展顺序和 ALPN 应接近真实浏览器或系统客户端；
  3. 行为一致性：连接失败、HTTP 回退、包长和时序不能长期呈现机器化的固定模式。

仅在外面再套一层 TLS 可能形成 TLS-in-TLS 特征，还会增加头部和状态机开销。如果内层承载 TCP，外层也用 TCP，还可能出现双重拥塞控制与重传干扰。

Reality 类设计解决什么

Reality 类方案不要求运营者为伪装域名持有传统证书，而是利用真实目标站点的 TLS 特征，并用额外认证信息区分合法客户端。未通过认证的连接可表现得像访问真实站点，减少探测器获得独特响应的机会。

它主要改善证书管理与主动探测问题，不意味着流量统计上完全等同浏览器。部署时选择的目标站、客户端 TLS 指纹、入口 IP 历史、用户规模和流量模式仍会影响可识别性。

第五阶段：QUIC/HTTP/3 类传输

QUIC 运行在 UDP 上，把 TLS 1.3 集成到传输握手，并支持连接迁移和多路复用。基于 QUIC 的隧道通常具备几个工程优势：

  • 不受 TCP 队头阻塞在所有流上的连带影响；
  • 用户态实现便于快速调整拥塞控制和丢包恢复；
  • 网络切换时可用 Connection ID 维持逻辑连接；
  • 与日益普遍的 HTTP/3 流量共享部分外观。

但“用了 QUIC”同样不等于“像浏览器 HTTP/3”。QUIC 版本、传输参数、包长、请求行为和连接目标都可能形成指纹。某些网络会直接限制 UDP；此时协议需要 TCP/TLS 回退，否则理论上的低延迟没有意义。

Hysteria2 等方案更强调在高丢包和高延迟路径上的吞吐，通过自定义拥塞控制、认证和可选 HTTP/3 外观改善体验。它们解决的是“受损链路上的可用性 + 一定程度的伪装”，而不是消除所有可观察特征。

第六阶段：流量分析从单包转向序列

当握手被加密、字段被随机化后，分类仍可利用流量序列。例如视频播放表现为持续大下行，交互式网页表现为短突发，固定频率保活则可能暴露长期隧道。

抵抗统计分类可以采用：

  • 填充数据，使包长落入常见分布；
  • 对发送时序增加扰动；
  • 多路复用多个逻辑连接，改变单流特征；
  • 生成掩护流量，隐藏真实空闲和活跃周期。

这些方法都有真实成本。填充和掩护流量消耗带宽，时序扰动增加延迟，过度随机本身也可能不自然。抗流量分析不是“加越多噪声越好”，而是在目标网络的观测能力、性能预算和用户行为之间折中。

前置与中继：隐藏最终入口

另一条路线是让审查方只能看到大型云/CDN/普通服务入口，再由中间层转发到真实代理服务器。域前置曾利用 TLS SNI 与 HTTP Host 路由差异实现这种效果，但主流云平台已大多限制传统域前置。

现代替代思路包括受支持的 CDN Worker、中继网络、可插拔传输和短生命周期入口。它们把封锁成本从“封一个小型服务器”提高到“影响共享基础设施”，但也增加：

  • 对第三方平台的信任；
  • 额外一跳的延迟和费用；
  • 平台规则变化导致的可用性风险；
  • 流量和账户被平台关联的可能。

因此前置不是免费隐身，而是用架构和运营复杂度交换封锁成本。

为什么没有“永不封锁协议”

抗封锁系统至少有四个暴露面：

暴露面观察内容常见缓解
地址IP、ASN、域名、证书历史多入口、中继、快速轮换、共享基础设施
协议握手格式、响应、传输参数真实协议栈、认证前静默、合理回退
行为包长、时序、连接周期填充、复用、时序调整
运营配置传播、用户规模、支付与域名分散部署、最小暴露、快速响应

只解决其中一项，整体仍可能从其他维度被识别。协议代码也只是系统的一部分：服务器部署模板高度一致、所有节点使用相同端口、客户端版本长期不更新，都可能抵消协议设计的优势。

选择技术时应问什么

与其问“哪个协议最隐蔽”，不如检查：

  1. 未认证探测会得到什么响应？
  2. 客户端握手与哪种常见流量相似，相似到什么层级？
  3. UDP 不可用时是否有独立回退路径？
  4. 节点地址暴露后，控制面能多快替换并安全下发？
  5. 协议是否有公开规范、独立实现或安全审查？
  6. 伪装增加了多少延迟、带宽和运维复杂度？

这些问题能区分真正的系统能力与营销标签。VPN 的基础封装与密钥流程可参考现代 VPN 技术架构；如果需要理解不同产品形态，参见机场和商业 VPN 怎么选。

下一阶段会发生什么

未来抗封锁不会只依赖单一专用协议，而会更多借用标准 Web 传输、可编程中继和多路径连接，同时用自动化控制面快速更换入口。但标准协议能提升兼容性，不能自动保证不可识别；后量子密码也只保护密钥建立，不会解决流量指纹。更完整的趋势分析见VPN 的未来。

主要技术资料