官方文档：Xray-core 讨论区长文《XHTTP: Beyond REALITY》 · XHTTP 配置文档 · 作者图文教程：3X-UI XHTTP 上下行分离教程（Joey Blog） · 在线填写器：joeyblog.net/xhttp.html · 视频教程：Joey blog（见文末）

先把这篇的定位说清，免得和本站前几篇搞混：CFNext、CFnew 在 Cloudflare Workers 里发的 XHTTP 节点，是 Workers 侧的简化实现（cfnew 的 XHTTP 写死 stream-one 模式）；而 XHTTP 的「完全体」是 VPS 上 Xray-core 的玩法——尤其是它的招牌能力上下行分离（上传走一条路、下载走另一条路），靠客户端的 downloadSettings 实现，Workers 侧做不了。本文按 Joey blog 官方图文（2026-11-02，含双机实测）把原理、三种模式、双 VPS 中转与分离的完整配置步骤写全。提醒：本项目供学习与网络技术研究，请遵守当地法律法规。

在 YouTube 打开原视频 ↗

（说明：原站图文对程序化抓取有限制，步骤截图未能取用，本文配图为官方视频封面；逐步界面可对照文末图文原文与视频。）

XHTTP 是什么，和 WebSocket 有什么区别

XHTTP 是 Xray-core 的新一代传输协议，把代理流量装进 HTTP 请求里。相比老牌的 WebSocket（WS）传输：

  • 原生上下行分离：上传和下载可以走不同的连接、不同的路径甚至不同的机器（靠 downloadSettings 指定下行），WS 做不到
  • 三种工作模式（见下表），从「兼容一切」到「最简单粗暴」可选
  • 带 XMUX 多路复用、header padding（头部填充）等设计；原生支持 HTTP/3（QUIC）
  • 按 Joey 视频的口径：Xray 官方已提示 WebSocket 将被逐步淘汰，过 CDN 的主流传输正在转向 XHTTP——这也是 CFNext/cfnew 都主推 XHTTP 的原因

三种模式（先选对，再填参数）

模式工作方式兼容性与适用场景
packet-up上行分包 POST（一个个小包发）+ 下行流式 GET兼容性最高，几乎能过所有 CDN / 反代
stream-up上行流式 POST + 下行流式 GETTLS + HTTP/2 场景、过 CDN 常用
stream-one单个 POST 连接双向流最简单、兼容性最低；过 Cloudflare 需开 gRPC，过 Nginx 需 grpc_pass

mode 填 auto（默认）时 Xray 自动选：TLS + HTTP/2 → stream-up；REALITY → stream-one；其它 → packet-up。一般只需要填好 path（路径），其余参数留空用默认即可。一个高频踩坑点：path 末尾要带 /（如 /joey-xhttp-demo/），两端不一致就连不上——服务端、客户端、下载连接三处 path 必须逐字相同。

三种组网方案（本篇实操的主线）

准备两台 VPS：一台做入口 A（离你近、线路好，只做转发），一台做落地 B（真正出口，跑 VLESS + XHTTP + REALITY）。三种用法的数据路径：

方案上传路径下载路径
直连客户端 → BB → 客户端
整条中转客户端 → A → BB → A → 客户端
上下行分离客户端 → B（直达）B → A → 客户端

分离的关键原理：客户端主连接直达 B 上传，同时额外经 A 向 B 建立一条下载连接；两条连接必须以同一 path 抵达 B 的同一个 XHTTP 入站才属于同一个会话。所以 A 只做 Tunnel（隧道）透传转发，不需要另一套 VLESS 用户和 REALITY 参数。入口地址变了，最终出口仍是 B 的 IP。

准备工作

本篇对应作者实测版本（新版本字段可能微调，以官方文档为准）：

软件版本
3X-UI（官方）v3.11.0
服务端 Xrayv26.10.21
v2rayN（客户端）v7.23.4
  1. 两台 VPS 都装好 3X-UI。Debian / Ubuntu 新机器用 root 执行（固定本期版本）：
apt update
apt install -y curl
curl -fL https://raw.githubusercontent.com/MHSanaei/3x-ui/v3.11.0/install.sh -o /tmp/3x-ui-install.sh
bash /tmp/3x-ui-install.sh v3.11.0

跟着提示设面板账户、端口、登录路径与 HTTPS。已有面板的先备份配置，别把安装命令当新增面板重跑。

  1. 客户端用 v2rayN（官方项目下载），必须支持 XHTTP 与 downloadSettings、能保留 XHTTP Extra（扩展参数）的 Xray 内核，只会导入普通 VLESS 节点不够
  2. 防火墙/安全组放行：入口 A 的节点端口、落地 B 的节点端口都要对客户端可达（分离时 B 的端口必须允许客户端直达，不能只放行 A）
  3. 示例参数（文中统一口径，实际换成你自己的）：A 地址 192.0.2.10、端口 24443；B 地址 198.51.100.20、端口 26443；XHTTP path /joey-xhttp-demo/（文档示例 IP 不能连接）

第一步：在落地 B 建 XHTTP 入站

打开 B 的 3X-UI →「入站」→「添加入站」，按标签依次填：

基础配置

字段填法
备注写清用途，如 XHTTP 落地
协议VLESS
地址0.0.0.0（监听所有网卡；客户端连的是 B 的公网 IP/域名，别把 0.0.0.0 填到客户端）
端口26443 或你的空闲端口

传输标签

字段填法
传输XHTTP
路径 path/joey-xhttp-demo/（末尾带 /，后面处处对齐）
模式 modeauto
Host本例留空
缓冲 / Padding / XMUX先保留默认，跑通再调

安全标签：选 REALITY，配目标（dest）与 SNI——本期用 www.microsoft.com:443、SNI www.microsoft.com（换目标要选符合 REALITY 要求、从 B 可达的站点，SNI 同步给客户端）；生成密钥后私钥留服务器、公钥给客户端，记下 Short ID。再给入站加一个 VLESS 用户并记录 UUID；flow 留空，不要带入 TCP+REALITY 节点的 xtls-rprx-vision。

保存后，先把这个落地节点导入 v2rayN 直连 B 测试：网页能开、出口显示为 B，再往下走。直连不通时不要加中转和分离。

第二步：在入口 A 建 Tunnel 转发

切到 A 的 3X-UI，新建 Tunnel 入站，端口 24443，「协议」标签填：

字段填法
重写地址落地 B 的公网 IP 或域名（示例 198.51.100.20）
重写端口B 的节点端口 26443
允许的网络本方案选 TCP 即可（XHTTP + REALITY 底层走 TCP）

A 不需要建 VLESS 用户、不需要 REALITY 参数——它只把数据转给 B，由 B 完成认证与处理。

第三步：客户端先跑通「整条中转」

  1. 复制第一步已测通的落地节点，备注改成「入口中转」
  2. 只改两处：address → A 的地址；port → 24443
  3. UUID、SNI、公钥、Short ID、XHTTP path 全部沿用落地节点；传输仍是 xhttp、模式 auto、flow 留空
  4. 切到该节点验证：网页可开，且出口仍是 B（直连与中转出口必须一致）

到这里双机中转已完整可用。速度满意的话可以先停在这一步，分离是下一步的进阶选项，不是必修课。

第四步：上下行分离（用在线填写器生成）

分离从落地直连节点改起：主连接保持去 B，只把下载连接指向 A。

  1. 打开在线填写器（生成在浏览器本地完成，不上传、不保存参数；页面提供离线版下载）
  2. 填两组信息：落地地址/端口、入口地址/转发端口；以及落地节点的 UUID、REALITY 公钥、SNI、Short ID、XHTTP path
  3. 点「生成节点和 Extra」→「复制节点」，在 v2rayN 里从剪贴板导入
  4. 导入后逐项核对（最容易填反的是主地址）：
位置必须是什么
节点主 address / port落地 B / 26443（主地址留在落地！）
主连接传输 / 安全xhttp / reality
XHTTP Extra 最外层downloadSettings
downloadSettings.address / port入口 A / 24443
下载连接的 REALITY 参数B 的 SNI、公钥、Short ID
两条连接的 XHTTP path同一个值，与 B 的入站一致

已有落地节点时，也可以只把填写器生成的 Extra 粘到该节点的「XHTTP Extra」里——不要再包一层 extra，也不要把完整节点 JSON 塞进这个框。下载连接的传输仍是 XHTTP；拿普通 TCP+REALITY 的配置塞进来不会变成同一个 XHTTP 会话。

作者实测结果（如实引用，别当承诺）

同一台电脑、同一网络、相邻时段，用 FAST（fast.com）网页测速（测速服务器由 FAST 自动选择，三次出口均为 B）：

方案下载 Mbps上传 Mbps空载延迟 ms负载延迟 ms
直连落地44059270293
整条中转92052186209
上下行分离88057197208

作者的结论：这轮先选整条中转。分离能用、也比直连快，但没有超过中转；上传反而是直连更高。分离不是必然更快——它的价值在于「上行线路和下行线路质量不对称」时各走最优路径，你的网络是否受益，要用自己的三条节点实测对比，别照搬别人的数字。分离节点下实测 YouTube 2160p60（4K60）播放：实际分辨率 3840×2160@60、掉帧 0、缓冲 12 秒以上，可流畅播放。

常见问题与排查（三层定位）

一口气配完三层再排错最容易乱。保留一条已测通的节点，按层找起点：

现象先检查什么
落地直连就不通B 的入站监听、系统防火墙与云安全组；UUID、SNI、公钥、Short ID、path 五件套是否逐字一致；flow 是否留空
直连通、中转不通A 的入口端口是否可达；Tunnel 重写地址是否为 B、重写端口是否为 B 的节点端口
中转通、分离不通主地址是否仍为 B；Extra 是否被客户端保留；downloadSettings 是否在最外层；两条连接是否回到同一个 XHTTP 入站（path 是否一致）
能连但测速数字不对劲浏览器是否真走了当前节点；是否还有另一款客户端或 TUN 在接管流量；网页查到的出口是否确实为 B

补充：系统代理与 TUN 尤其要留意——切了 v2rayN 的节点，不代表浏览器一定跟着走，先看测试页显示的出口再记录速度。想撤回分离，切回保留的直连/中转节点最省事；在分离节点上清空 XHTTP Extra（主地址仍是 B）恢复的是落地直连。

视频教程

在 YouTube 打开原视频 ↗

  • 前作：纯 CloudFront 版 XHTTP——专讲两个坑：CloudFront 侧 SSL/TLS 必须设「完全」、网络里要开 gRPC

在 YouTube 打开原视频 ↗

和 CFNext / CFnew 里 XHTTP 的关系

  • 相同点：都是 XHTTP 传输、都用 path 区分入站、客户端侧（v2rayN 的 XHTTP 设置、mode 选择、path 对齐）的知识完全通用
  • 不同点：Workers 侧实现跑在 Cloudflare 上，cfnew 只做 stream-one、CFNext 面板直接发节点，胜在零成本零维护；但双机中转、downloadSettings 上下行分离、REALITY 直连落地都是 VPS 上 Xray-core 才有的能力
  • 选择建议：纯免费、轻量使用 → CFNext/cfnew；有 VPS 且追求线路优化与可控性 → 本篇的 Xray 玩法

资料来源

  • 作者图文教程（2026-11-02，含版本与实测数据）：https://joeyblog.net/3x-ui-xhttp-split.html
  • Xray-core 官方讨论长文：https://github.com/XTLS/Xray-core/discussions/4113
  • XHTTP 配置文档（官方文档镜像）：https://lcuwx2016.github.io/xtls/config/transports/xhttp.html
  • 双 VPS 分离踩坑讨论：https://github.com/XTLS/Xray-core/discussions/4271
  • 在线填写器：https://joeyblog.net/xhttp.html