WebSockets 在代理协议中的伪装作用及 Nginx 反代配置

在几年前的代理圈中，Vmess+WS+TLS 曾是无人不知的黄金标准组合。尽管如今有了更先进的 REALITY 技术，但 WebSockets 配合 Nginx 的反代伪装架构，仍因其能极好地躲避防火墙审查，而被作为企业内网穿透及 CDN 救砖的首选方案保留至今。

1. WebSockets 的神奇“易容术”

普通 TCP 连接在握手时毫无隐蔽性。而 WebSockets 协议本身是为了满足浏览器与服务器建立双向长连接聊天室而发明的。

• 在握手阶段，WebSockets 的第一帧数据是一个彻头彻尾的标准化 HTTP 报文，里面不仅带着 Host 域名，还携带着看起来与常人无异的 Upgrade: websocket 声明。
• 这种伪装让防火墙的 DPI 系统确信：这只是一个用户在访问一个开启了聊天功能的正常 HTTPS 网站，从而放行。

2. Nginx 反向代理的防火墙机制

仅仅有 WS 的外壳还不够，如果防火墙对这个域名发起主动探测，必须有人能返回一个“像模像样”的网站。 引入 Nginx 就解决了这个问题。架构如下：

1. 防火墙审查员的普通网页探测 -> Nginx 检测到不是 WS 请求 -> Nginx 立刻返回一个您事先部署好的精美博客页面，完全骗过审查员。
2. 您的翻墙客户端发出暗号（特定路径如 /my-secret-tunnel 和 WS 请求头） -> Nginx 识别出暗号 -> 悄悄把流量反向转交给躲在 Nginx 背后某个端口的代理内核进程。

3. 当前时代的局限性

这套系统几乎无懈可击，但付出的代价是：极度的性能损耗。 从客户端到服务端，您的数据要先被加密一次，再被套上一层沉重的 HTTP Header 外衣，穿越太平洋抵达目标机器后，先交给 Nginx 解码，再由 Nginx 转给代理内核解密。这种繁杂的包装使得其响应延迟无法与当今极速的裸 TCP 协议相提并论。

---

参考资料与相关阅读

• 相关阅读：如何拯救被封锁的节点：利用 CDN 套用 WebSockets
• 相关阅读：突破严格的企业级上网行为管理边界穿透策略

Nginx WebSocket 反向代理配置

要在 Nginx 中正确转发 WebSocket 流量（如 V2Ray 的 WS 传输层），必须加上 Upgrade 头，否则连接将立即断开：

location /secret-path {
    proxy_pass http://127.0.0.1:10000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
}