跳到正文
不翻车专注 VPN 软件评测

XHTTP 是什么？Xray 劝你别用 WebSocket 和 gRPC，换它要不要

不翻车编辑部 · 更新于

XHTTP 科普封面：3x-ui 传输里多了个 XHTTP，它是什么，要不要换

先说结论：XHTTP 是 Xray 自家的一种传输方式（2024 年 6 月以 SplitHTTP 的名字发布，10 月底改名），它把代理流量装成一个个普通的网页请求，好处是能藏进 CDN、Nginx 这些中转后面，也能和 REALITY 搭着直连。它不是加速器：你现在用 VLESS + REALITY 直连得好好的，不用急着换；服务器 IP 被墙、想套 CDN 的，才是它最合适的场景。下面的抓包是 2026 年 10 月 18 日在我们的测试服务器上做的（Xray v26.3.27，只看请求长什么样，不测速度），原理和数字来自 Xray 官方文章《XHTTP: Beyond REALITY》、源码和发布说明，出处列在文末。

Xray 自己在劝你换

同一台服务器、同一个 Xray v26.3.27，我们先后用 WebSocket、gRPC、XHTTP 三份配置启动。前两份，日志里都跳出同一句警告：这个功能已经弃用（deprecated），不推荐再用，以后可能会被删除，请尽快迁移到 XHTTP。换成 XHTTP，这条警告就没有了。

测试服务器上启动 Xray v26.3.27：WebSocket 和 gRPC 配置都打出 is deprecated 警告，XHTTP 没有

源码里也写得清楚：gRPC、WebSocket、HTTPUpgrade 用的是“近期不会删除”那一档弃用提示（PrintNonRemovalDeprecatedFeatureWarning），原来的 HTTP、QUIC 两种传输方式已经直接删除，合并进了 XHTTP。所以手上的 WebSocket、gRPC 节点现在照样能连，只是开发者不再往它们身上花力气。gRPC 这条提示是什么时候加上、什么时候改成“近期不删”的，gRPC 那篇有时间线。

Xray v26.3.27 源码 transport_internet.go：gRPC、WebSocket 是 NonRemoval 弃用，HTTP、QUIC 已删除

另外，xray run -test 只检查配置，不会打出这条警告，要实际启动才看得到。

协议和传输方式，先分清

拿寄快递打比方：

  • 协议（VLESS、Trojan 这些）管的是快递单怎么填：寄给谁、要去哪个网站。
  • 传输方式管的是包裹怎么运：RAW 就是直接装车送到服务器门口；WebSocket、gRPC、XHTTP 是把包裹打扮成别的样子，混在普通网站的流量里送过去。

在 3x-ui（v3.10.2）里添加入站，协议选 VLESS，再点开“传输”，下拉框里就有 XHTTP：

3x-ui v3.10.2 添加入站的传输下拉：RAW、mKCP、WebSocket、gRPC、HTTPUpgrade、XHTTP、XDRIVE

选中以后多出一个“模式”，有 auto、packet-up、stream-up、stream-one 四个选项，Padding 字节默认 100-1000。这几个词下面一个一个讲。

3x-ui 选中 XHTTP 后：路径、模式（auto、packet-up、stream-up、stream-one）、Padding 字节 100-1000

为什么要藏进 CDN

CDN 可以理解成大网站开在各地的中转仓库：你打开一个网站，连上的其实是离你最近的仓库，仓库再去源站拿东西。全世界大量正常网站都在用 CDN，所以一个 CDN 的 IP 后面站着成千上万个网站。

官方文章开头写了 XHTTP 的底层逻辑：反审查的根本，是增加封锁时的“附带伤害”，让审查者不敢随便封；多年经验是，GFW 不会永久封锁大型 CDN 的整个 IP，否则误伤太多正常网站。

问题在于，CDN 为了保护源站，一般会把整个 HTTP 请求收完再转给源站。普通代理流量是一条长长的双向连接，等它收完再转，网页早就超时了。所以以前想过 CDN，基本靠 WebSocket 和 gRPC，因为很多 CDN 专门支持这两种。

官方文章：反审查的根本逻辑是增加附带伤害；GFW 不会永久封锁大型 CDN 的整个 IP；CDN 一般会缓存完整个 HTTP 请求再发给源站

原理：分包上行、流式下行

  • 下行（服务器发给你）：官方打了个比方，你在网站上下载一个很大的文件，CDN 手里没有就回源站拿，它不会等整个文件拿完才给你，而是源站发来多少就马上转多少。XHTTP 把服务器发给你的数据，装成一个一直在下载的长请求，下行速度不受影响。
  • 上行（你发出去）：切成一小段一小段，每段装进一个单独的 POST 请求，像在网页上提交一次表单。会慢一些，好在平时上网上传的数据本来就少。
  • 两个方向靠网址路径里同一串随机编号对上。

官方文章：想象一下你正在一个网站上下载一个很大的文件，源站发来多少数据，CDN 就即时转发给你

我们抓的包：它长什么样

为了看清内容，这次故意没有加 TLS，服务端和客户端放在同一台测试服务器上，只抓本机回环（127.0.0.1）的往来，然后访问一次 example.com。完整配置和原始记录在仓库的 docs/protocol-tests/2026-10-18-xhttp.md。

packet-up 模式下，抓到的是 1 个 GET 加 5 个 POST：

packet-up 抓包：先是 GET /bfc63/编号，接着 POST /bfc63/编号/0 到 /4

  • GET 是下行，路径是我们设的 /bfc63，后面跟一串随机编号。
  • POST 的编号和 GET 一样，末尾多了 0 到 4：上行被切成 5 段，服务器照编号拼回去。
  • 相邻两个 POST 间隔 30.6 到 31.0 毫秒，和官方默认的最小间隔（scMinPostsIntervalMs，30 毫秒）对得上。

服务器回给 GET 的响应头写着 Content-Type: text/event-stream（一个持续推送的事件流），还有 X-Accel-Buffering: no，告诉路上的中转别攒着、来了就转。

GET 请求和服务器响应头：User-Agent 自称 Windows 上的 Chrome；响应 Content-Type: text/event-stream、X-Accel-Buffering: no

随机填充

如果每个请求的头部都一样长，外面看几眼就能认出来。所以 XHTTP 在每个请求和响应里都塞了一段随机长度的填充（一串字母 X），官方默认 100 到 1000 个之间随机。这一次访问的 6 个请求，填充分别是 802、436、822、724、298、863 个，响应里是 403、437、755、341、811、333 个，没有两个一样。

同一次访问里每个请求、响应的填充长度

请求头里还写着自己是 Windows 上的 Chrome 151，浏览器平时会带的 Sec-CH-UA、Sec-Fetch-* 这些字段也都带着。正式使用时外面还套着 TLS，这些内容外人看不到，它们是演给 CDN 和中转服务器看的。

三种模式怎么选

模式 上行怎么走 抓包里看到的 适合
packet-up 一段一个 POST 1 个 GET + 多个 POST 兼容性最好，几乎所有 CDN、反向代理都能过
stream-up 一个一直开着的 POST 1 个 GET + 1 个 POST 上传不打折扣；请求头装成 gRPC，官方说能在 HTTP/2 上过 Cloudflare
stream-one 上下行都在同一个 POST 里 1 个 POST 最简单

stream-up 抓包：1 个 GET 加 1 个持续的 POST，Content-Type: application/grpc

stream-one 抓包：从头到尾一个 POST /bfc63/

拿不准就选 auto（默认）：用 TLS 时走 stream-up，用 REALITY 时走 stream-one，都没有就退回 packet-up。官方快速上手指南写的是：一般来说，XHTTP 配置只需填 path，其它不填即可。

官方文章：mode 默认 auto，客户端 TLS H2 时 stream-up，REALITY 时 stream-one，否则 packet-up

比 gRPC、WebSocket 好在哪

官方文章专门回答过 stream-up 比 gRPC 好在哪：

  1. 不需要 gRPC 的库，性能更好；
  2. 下行是单独的 GET 请求，不受 CDN 对 gRPC 的流量限制；
  3. 多了随机填充、XMUX、上下行分离这些功能。

官方文章：stream-up 比 gRPC 传输层的优势，性能更好、不会受到 CDN 对 gRPC 的流量限制、更成熟

XMUX 是它的“自动换连接”：默认一条连接上同时跑 16 到 32 个请求，用上一段时间就换一条新的。官方说这样就不会像 gRPC 那样始终复用同一条连接，用久了出现断流。WebSocket 的问题则写在弃用提示里：握手时写着 http/1.1，是个明显特征。

两个进阶用法

  • HTTP/3：客户端可以用 HTTP/3（走 UDP 的 QUIC）连 CDN，CDN 再换成普通 HTTP 转给你的服务器，服务器那头不用改。
  • 上下行分离：上传、下载各走一条路，比如上行走 IPv4 的 CDN，下行走 IPv6 或 REALITY。官方的理由是现在的检测基本盯着单条连接，拆开以后对方一时反应不过来。更实际的用法是上行交给去程好的线路、下行交给回程好的线路。

要不要换

  1. 你自己的节点是 VLESS + REALITY，IP 没被封，用着正常：不用换。官方原话：XHTTP 默认有多路复用，延迟比 Vision 低，但多线程测速不如它。
  2. 服务器 IP 被墙了，又不想三天两头换服务器：这是 XHTTP 最合适的场景，配上自己的域名和 TLS，藏到 CDN 后面。先知道两件事：
    • 官方提醒，Cloudflare 会掐断 100 秒没有数据的连接，长时间挂着的连接要自己保活（比如 SSH 设 ClientAliveInterval）。
    • Cloudflare 自助订阅协议第 2.2.1 条 (j) 项写着不能用它的服务提供 VPN 或类似的代理服务，账号有被封的风险，见 Cloudflare Workers 节点被封。
  3. 机场给的节点名字里写着 xhttp：你的客户端得支持它，看下一节。

官方文章：XHTTP 默认有多路复用，延迟比 Vision 低但多线程测速不如它

官方文章：CF 会掐断下行 100 秒无实际数据的 HTTP，代理长连接需在应用层面保活

哪些客户端能用

内核 支持 XHTTP 吗 常见客户端
Xray 支持 v2rayN、v2rayNG 等
mihomo v1.19.22（2026-04-01）起支持，只能配 VLESS Clash Verge Rev 等（看自带的内核版本）
sing-box 还不支持（核对到 v1.15.0-alpha.12） 用 sing-box 内核的客户端

用 sing-box 内核的客户端导入 XHTTP 节点用不了，这不是节点坏了，是客户端不认识这种传输方式。

mihomo 文档：仅 VLESS 支持 xhttp 传输层，请勿在其他协议上使用

自己搭：3x-ui 里协议选 VLESS，传输选 XHTTP，路径填一个别人猜不到的，模式留 auto。3x-ui 的完整搭法见 3x-ui 面板设置。

缺点

  1. 兼容性：sing-box 内核还不支持，老版本 mihomo 也不行，换之前先看客户端。
  2. packet-up 上传会慢一些：每段一个 POST，CDN 不支持流式上行时只能用它。
  3. 套 CDN 有代价：要自己的域名和 TLS；Cloudflare 有 100 秒断流和服务条款的限制，账号可能被封。
  4. 参数多：官方文章的配置示例里，XHTTP 自己的参数有二十个左右，日常只填路径就够，改别的之前先看清用途，不然容易两端对不上。

常见问题

XHTTP 和 SplitHTTP 是一个东西吗？ 是。2024 年 6 月 21 日的 v1.8.16 以 SplitHTTP 发布；2024 年 10 月 31 日的 v24.10.31 做出上下行分离、正式支持 REALITY，改名 XHTTP。配置里写 xhttp 或 splithttp 都认。

Xray v24.10.31 发布说明：正式将 SplitHTTP 升级为 XHTTP，XHTTP 也已正式支持 REALITY

XHTTP 能让网速变快吗？ 不能。它管的是藏不藏得住、过不过得了 CDN，快不快还是看服务器和线路。

XHTTP 要取代 REALITY 吗？ 不是。官方文章标题叫 Beyond REALITY，作者解释过：意思是流行程度超过 REALITY，而不是取代它，两个可以一起用（XHTTP + REALITY）。

官方文章：Beyond REALITY 的意思并非是取代 REALITY，而是流行程度超越 REALITY

我的 WebSocket / gRPC 节点会突然不能用吗？ 目前不会。它们是“近期不会删除”的弃用，Xray 照样能跑；新搭节点再选 XHTTP 就行。

XHTTP 能和 mux.cool（多路复用）一起开吗？ 官方说用 XHTTP 时不要启用 mux.cool，它自己有 XMUX。

资料来源