‹ 返回《代理与远程协助》目录

🌊 第01章 · VLESS + WS 原理

Xray 协议与 WebSocket 伪装

VLESS + WS 原理

这一章不碰任何键盘命令，只讲清楚一件事：为什么在现代网络环境下，VLESS + WebSocket 会成为"翻墙"这条链路里最常用的一套组合。把它的每一个部分——VLESS、UUID、WebSocket、TLS、反向代理——都拆开看透，后面第 2 到第 4 章的所有配置命令，本质都是在把这些概念落成一行行可运行的文本。

一句话概括：VLESS 是"身份卡片"，WebSocket 是"普通卡车的伪装"，TLS 是"密封保险箱"，Nginx 是"前台门卫"。 你拿身份卡片通过门卫，把保险箱塞进普通卡车里，混在正常车流里开出去，谁也看不出这台车在运什么。

我们为什么需要"翻墙"这套东西

假设你在海外有一台 VPS（虚拟服务器），本机在国内。国内到这台 VPS 之间，中间可能有一层"检查站"，它会看你在访问什么。

  • 直接 SSH、ping、或走裸 TCP 端口，特征很明显，容易被针对性阻断；
  • 走 HTTPS（443 端口）就正常得多——因为全网大量正常网站就长这样，检查站不能把 443 都封了。

所以思路自然长成：把要隐藏的流量，装进一个看起来像"正常 HTTPS 网页访问"的壳子里。 这就是"代理"与"翻墙"的本质。

VLESS 是什么

VLESS 是 Xray（及其前身 V2Ray）家族里的一个传输协议。要理解它，先看它"不管什么"：

VLESS 自身不带加密。它不是用来"加密封装"的，而是用来识别身份的——它只负责确认"你是谁，我要把流量送谁去"。

概念 作用 类比
VLESS 传输协议，负责身份认证 + 转发指令 快递单上的收件人信息
UUID 一串唯一的 ID 值，相当于"口令" 快递单上的唯一快递单号
flow 流控方案（如 xtls-rprx-vision），控制数据流向 分拣路线
decryption none 表示不解密（解密交给 TLS 层） 不用自己的锁，锁在下一层

VLESS 相比老协议有几个优点： 1. 无状态、无额外加密开销，额外加一层解密都是在浪费； 2. 服务端配置简单，只要一对 UUID 即可； 3. 配合 XTLS 的 flow 可以做到"一跳直通"，即加密只做一次，性能更好。

在真实环境里，配置文件里就一行身份信息：

"settings": {
  "clients": [
    {
      "id": "72f6b462-da16-41cb-8370-d737f34d1710",
      "flow": ""
    }
  ],
  "decryption": "none"
}

这串 72f6b462-da16-41cb-8370-d737f34d1710 就是这台服务器的 UUID，后面第 4 章客户端要靠它连进来。它存在服务器磁盘与客户端的配置文件里。

UUID 有多重要

安全提示（务必记住）：UUID 与 WebSocket 路径 path 是这套系统的两把"钥匙"。任何人只要同时拿到这两样，再配上服务器地址，就能完全模拟你的客户端把流量穿过去，等于把你的代理白嫖甚至用于非法用途。所以：绝不要把 UUID 和 ws 路径贴到公开论坛、截图、或者任何能被人看到的聊天里。 服务器上的 /root/.deploy/xray_uuid 与 /root/.deploy/xray_wspath 两个文件权限是 600，就是为防别人偷看。

本机这两个文件的真实内容（你部署时要替换成你自己的，这里只是示例结构）：

# UUID（身份口令）
cat /root/.deploy/xray_uuid
72f6b462-da16-41cb-8370-d737f34d1710

# WebSocket 伪装路径（门牌号）
cat /root/.deploy/xray_wspath
/ws-f033eda368eb1b99f9d79a4f

WebSocket：让流量"看起来像网页"

WebSocket（简称 WS）本身是一个 Web 标准协议，初衷是让网页能和服务端保持一个长连接、双向通信。它比普通 HTTP 请求的"一问一答"更轻，适合实时聊天、在线游戏、即时推送这类场景。

WS 的特点正好被利用： - 它跑在 HTTP(S) 之上，前几个字节长得和普通 HTTP 请求一模一样（GET /ws-xxxx HTTP/1.1）； - 经过 Upgrade: websocket 头进行一次"升级握手"后，保持一条长链接； - 对检查站而言，这就是一条普通的网页长连接，只是"打开了好久"。

WebSocket 的标准握手流程：

客户端 → 服务器： GET /ws-f033eda368eb1b99f9d79a4f  (带 Upgrade: websocket 头)
               （看起来像在访问这个网站的一个普通长连接页面）
服务器 → 客户端： 101 Switching Protocols
               （握手成功，之后这条连接就双向畅通了）
客户端 ⇄ 服务器： 这条连接里再跑我们的 VLESS 数据

接地气：可以把 WebSocket 想象成你在一栋写字楼的大楼正门，拿着一张访客证（UUID），坐普通电梯（WebSocket）上楼。保安看见你刷了一次门禁就上楼了，只觉得是普通访客，不会想到你怀里揣着一份机密文件（真实翻墙流量）——因为文件放在了密封档案袋（TLS）里。

TLS：装上"保险箱"

WebSocket + TLS 是这套组合的标准形态。TLS（通常就是 HTTPS 里那个加密层）负责三件事：

TLS 作用 说明
加密 真正的翻墙数据在 TLS 里加密，抓到包也看不懂
信任 用证书证明"我真是 bangdream.xyz"，不被冒充
伪装 让整条连接在外人看来就是一次正常的 HTTPS 访问

在真实配置里，Xray 的 streamSettings.security 是 none（Xray 自转不负责 TLS），因为 TLS 由外层 Nginx 终止——这就是下一节要解释的关键架构。

为什么把它藏进 Nginx 反向代理里

这是整个方案最核心的思路，很多新手在这里会转不过弯：

Xray 本身不直接暴露给公网，而是监听在本机内网地址 127.0.0.1:10086。真正对外提供 443 端口的是一个网站（Nginx），Nginx 只把特定的一个路径 /ws-f033eda368eb1b99f9d79a4f 转发到后端的 Xray。

这样带来的好处： 1. 外界访问你的服务器，看到的是一个正常网站（比如 bangdream.xyz），扫描 443 端口只会发现一个网站，而不会看到一个"代理服务"； 2. TLS 证书由 Nginx 统一管理（Certbot 自动续期），Xray 只需要处理纯 WS； 3. 只有恰好知道那个隐藏路径的请求才会被送进 Xray，其他人访问那个路径只会得到 404 或其它正常页面。

互联网访问者
   │ (443 HTTPS, 看起来是访问 bangdream.xyz 这个网站)
   ▼
Nginx (43 端口, 有 TLS 证书)
   │ location /ws-f033eda368eb1b99f9d79a4f  ──► 转发
   ▼
Xray (127.0.0.1:10086, 只监听本机)
   │ VLESS 身份校验 (UUID)
   ▼
freedom outbound (direct)  ──► 帮你访问你想访问的任何网站

上图就是这一整套系统的完整链路。把这个图印在脑子里，后面所有配置命令都是往链条上"接零件"。

为什么用"反向代理"而不是直接开 TLS

有人会问：为什么不干脆让 Xray 自己监听 443 并自己加 TLS？那样少一层。但坏处很明显：

  • 你的服务器如果还要正常跑网站（比如这里跑了个 Web 应用在 3000 端口、GitLab 在 8090），443 只能被一个程序占用——Nginx 正好可以把 443 分给多个"业务"；
  • Xray 自持 TLS 时，证书续期、配置管理都落在 Xray 上，和 Xray 升级耦合；
  • 用 Nginx 反代，代理和网站混在一起，"伪装性"最好——这正是这套方案的核心价值。
方案 443 端口占用 伪装性 证书管理 适用
Xray 直接监听 443 独占 中 Xray 自己搞 纯代理机
Nginx 反代 Xray Nginx 共享复用于多个站点 高 Certbot 统一 同一台机器还跑着网站

本章小结

关键点 一句话记忆
VLESS 只认身份，不负责加密
UUID 唯一的身份口令，绝不可泄露
WebSocket 让流量长得像网页长连接
TLS 负责真正的加密（这里是 Nginx 终止）
反向代理 把代理藏在正常网站后面
伪装路径 只有知道这个路径的请求，才会被转进 Xray

搞懂了这些，接下来第 2 章我们就把 Xray 这台"接收器"真正装起来、跑起来。

再次强调安全底线：UUID 和 ws 路径 是你的钥匙串，丢一把就等于把整个翻墙通道送人。在后面的章节里，涉及这两者时都请按你的实际情况替换，并且不要在公开渠道截图或粘贴。

Xray 安装与配置 ›