一、先给结论HTTP 和 XHTTP 不是一个层级把整个链路拆开会清楚很多。普通 Web 访问通常可以抽象为Browser / App ↓ HTTP/1.1 / HTTP/2 / HTTP/3 ↓ TLS ↓ TCP / QUIC ↓ IP而 Xray 中常见的VLESS XHTTP REALITY更准确的分层是应用流量 ↓ VLESS ← 代理协议 Proxy Protocol ↓ XHTTP ← 传输方式 Transport Method ↓ HTTP/1.1 / H2 / H3 ← HTTP 承载 ↓ REALITY / TLS ← 传输安全 ↓ TCP / QUIC ↓ IP所以最重要的一句话是XHTTP ≠ HTTP/2也不是 HTTP 的替代品。XHTTP 更像是建立在 HTTP 能力之上的“代理数据运输系统”。二、普通 HTTP 到底在解决什么问题HTTP 的主要职责是定义客户端和服务器如何交换 Web 资源。例如浏览器请求GET /api/user HTTP/1.1 Host: example.com Accept: application/json服务端返回HTTP/1.1 200 OK Content-Type: application/json {id:1,name:Alice}这个模型非常清晰Client │ │ HTTP Request ▼ Server │ │ HTTP Response ▼ ClientHTTP 规范负责定义Request MethodURLHeaderBodyStatus CodeCacheContent NegotiationConnection ReuseStreamingHTTP/2 MultiplexingHTTP/3 over QUIC。但是 HTTP 并不会告诉你“如何把 SOCKS/TUN 接收到的任意 TCP/UDP 代理流量映射到 HTTP 请求和响应里。”这恰恰是 XHTTP 所做的事情之一。三、XHTTP 到底是什么在 Xray 的配置体系中XHTTP 属于Transport Method。也就是说一条完整代理链路可以拆成Proxy Protocol Transport Method Transport Security Network Transport例如VLESS XHTTP REALITY TCP或者VLESS XHTTP TLS HTTP/3 / QUIC这样理解之后很多概念就不会再混淆技术所属层级作用VLESSProxy Protocol描述代理连接、用户、目标地址等XHTTPTransport Method把代理数据映射到 HTTP 传输模型HTTP/2HTTP Protocol提供 HTTP 流、多路复用等能力HTTP/3HTTP Protocol基于 QUIC 的 HTTPTLSTransport Security标准 TLS 加密REALITYTransport SecurityXray 的 TLS 派生安全机制TCPTransport可靠字节流QUICTransport基于 UDP 的现代传输协议所以VLESS XHTTP REALITY不是三个互相竞争的协议而是三层组合。四、为什么 XHTTP 不直接使用“一条普通 HTTP 连接”代理流量和普通 Web 请求有一个天然区别普通 Web 请求往往具有明确边界Request → Response → Done代理连接却可能持续很久TCP Connection ────────────────────────────── 持续上传 ────────────────────────────── 持续下载例如SSHWebSocket视频流下载API 长连接数据库连接游戏连接。因此一个代理 transport 必须解决如何持续上传如何持续下载如何穿过 HTTP 反向代理/CDN如何处理 HTTP 请求缓冲如何处理多路复用如何避免某一条长连接永久占用如何支持 H1/H2/H3如何在需要时把上下行拆成两个独立链路。XHTTP 的三种主要模式就是围绕这些问题设计出来的。五、packet-up分包上行 流式下行packet-up 是理解 XHTTP 最重要的一步。它的设计可以概括成上传 POST POST POST POST POST 下载 一个持续返回数据的 Response Stream假设当前会话 ID 为abcdef123456客户端可能通过多个请求发送数据POST /api/x/abcdef123456/0 POST /api/x/abcdef123456/1 POST /api/x/abcdef123456/2 POST /api/x/abcdef123456/3其中0 1 2 3相当于 sequence。服务端收到以后根据session id sequence重新恢复原来的上行字节流。与此同时下行可以建立类似GET /api/x/abcdef123456服务器保持响应HTTP Response ──────────────────────────────────── data data data data data data ...这就是Packet Upload Streaming Downloadpacket-up 为什么有意义很多 HTTP 中间层对上传请求的处理方式比较保守。例如某些CDNWAFReverse ProxyHTTP GatewayLoad Balancer。可能倾向于Client POST ↓ 完整读取 Request Body ↓ 再发送给 Origin如果上传是无限流POST Body ──────────────────────────────中间层可能无法很好处理。但是POST 300 KB POST 500 KB POST 800 KB就是普通 HTTP 请求。因此 packet-up 的核心思想是把难以兼容的“无限上传流”转换成多个具有边界的普通 HTTP 请求。为什么下载不也切成很多包因为下载方向通常可以很好地利用 HTTP Streaming。例如下载一个 20GB 文件时CDN 不需要先把 20GB 全部下载完 再发给用户更常见的做法是Origin ↓ data CDN ↓ data Client边收到边发送。因此 XHTTP 可以保留下行的流式效率。六、stream-up流式上行 流式下行packet-up 很兼容但毕竟会产生多个 HTTP 请求。如果持续上传量较大例如100 MB 500 MB 2 GB不断拆成POST POST POST POST ...会产生额外的HTTP HeaderRequest Scheduling请求管理中间层处理CPU 开销。于是 XHTTP 又提供stream-upstream-up 可以理解成上行 Client Server 下行 Client Server但它不是 stream-one。stream-up 中上下行仍然是相互独立的逻辑方向。典型理解POST /path/session ↓ 持续上传 GET /path/session ↓ 持续下载这带来一个非常重要的能力上下行可以进一步拆成不同网络路径。这也是downloadSettings能工作的基础。七、stream-one一个 HTTP 请求完成双向通信第三种模式是stream-one它更加容易理解。可以抽象为POST /path/ Request Body Client Server Response Body Client Server也就是一个 HTTP 请求同时承担上行和下行。这种方式结构非常漂亮1 个 Request 1 个 Response 1 条双向代理流与 packet-up 相比它没有大量独立 POST。与 stream-up 相比它又不需要另外维护一个独立下行请求。因此如果不需要上下行分离网络环境支持CDN/反代兼容stream-one 通常是非常自然的模式。需要特别注意stream-one本身已经把上行和下行绑定在同一个请求/响应中因此不能再通过downloadSettings把下行拆出去。八、三种模式放在一起比较特性packet-upstream-upstream-one上行多个 HTTP 请求流式流式下行流式独立流式Response 流HTTP 请求数量较多中等最少上传效率较好高高中间层兼容性很高高取决于链路上下行分离支持支持不支持H3/CDN 灵活性很强视环境视环境典型用途CDN/兼容优先高上传/分离简洁直连可以简单记忆成packet-up 小块上传 大流下载 stream-up 大流上传 独立大流下载 stream-one 一个 Request/Response 完成双向流九、modeauto 到底会怎么选择XHTTP 提供{mode:auto}这不是第四种传输模式。auto的意思是根据当前连接条件选择 packet-up、stream-up 或 stream-one。按照当前 XHTTP 设计逻辑可以大致理解为REALITY │ ├─ 没有 downloadSettings │ └─ stream-one │ └─ 有 downloadSettings └─ stream-up而 TLS H2 场景通常会优先考虑stream-up其它不满足相应流式条件的环境则可能回到packet-up因此对于普通用户mode:auto是一个非常重要的起点。不要一开始就堆几十个所谓“优化参数”。正确做法通常应该是先跑通 ↓ 测延迟 ↓ 测下载 ↓ 测上传 ↓ 看日志 ↓ 再针对问题调整十、XHTTP、HTTP/1.1、HTTP/2、HTTP/3 到底是什么关系这是第二个高频误区。很多人会问XHTTP 和 HTTP/2 哪个快这个问题本身就不完全成立。因为XHTTP是 Xray transport。而HTTP/2是 HTTP 协议版本。更加准确的问题应该是XHTTP 使用 H2 和 XHTTP 使用 H3有什么区别HTTP/1.1底层HTTP/1.1 ↓ TCP特点历史最久兼容性非常广每条连接上的并发能力不如 H2/H3某些代理链路仍大量存在。HTTP/2底层HTTP/2 ↓ TCP核心能力Multiplexing Header Compression Stream多个逻辑 HTTP Stream 可以复用同一个 TCP 连接。对于 XHTTP 而言H2 是非常重要的承载方式。HTTP/3底层HTTP/3 ↓ QUIC ↓ UDPQUIC 自己提供EncryptionMultiplexingLoss RecoveryCongestion ControlConnection Migration。H3 的优势之一是不同 Stream 不再全部依赖一个 TCP 字节流。但这并不意味着H3 永远比 H2 快真实网络性能仍受UDP QoSNATISPCDNRTTPacket LossQUIC 实现CPUMTU影响。十一、一个非常有意思的地方H3 可以在中间被转换成 H2/H1假设Client ↓ HTTP/3 ↓ CDNCDN 到 Origin 不一定也是 H3。完全可能Client │ │ H3 / QUIC ▼ CDN │ │ H2 / TCP ▼ Origin甚至H3 ↓ CDN ↓ H1因此整个链路可能是XHTTP Client ↓ HTTP/3 ↓ CDN ↓ HTTP/2 ↓ Reverse Proxy ↓ XHTTP Server这也是为什么分析 XHTTP 时不能只看客户端配置写的是 h3你必须同时看Client → CDN CDN → Origin Reverse Proxy → Xray三段链路。十二、XHTTP 最有特色的能力之一上下行分离传统代理通常是Client ⇅ Connection ⇅ Server上传和下载共享一个网络路径。XHTTP 的 packet-up / stream-up 可以做到Upload Client ───────────────→ Server Download Client ←─────────────── Server进一步可以Upload: IPv4 → H2 → Route A Download: IPv6 → H3 → Route B在 XHTTP 中客户端可以通过downloadSettings为下行定义另一套连接配置。概念上{xhttpSettings:{path:/api/v1/data,mode:auto,extra:{downloadSettings:{address:download.example.com,port:443,network:xhttp,security:tls}}}}注意这只是帮助理解结构的简化示例实际字段请以当前 Xray Core 与客户端支持的配置 schema 为准。十三、为什么上下行分离在工程上很有价值先不谈任何特殊网络环境只从正常网络工程角度看。现实网络经常存在A → B 很好 B → A 很差也就是去程 ≠ 回程例如用户 → 新加坡 延迟 40ms 新加坡 → 用户 绕路 延迟 180ms如果能够上行走 Route A 下行走 Route B理论上就可以分别优化上传路径下载路径IPv4IPv6H2H3CDNOrigin。这个设计理念和传统的一个 TCP 连接包办全部明显不同。十四、XHTTP 中的 Session 是怎么把上下行重新关联起来的假设Upload Connection和Download Connection已经不是同一个连接。那么服务端怎么知道这两个属于同一个代理会话答案是Session ID概念上Upload: POST /path/{session_id}/... Download: GET /path/{session_id}服务器┌─ Upload session_id ───────┤ └─ Download最终恢复为Bidirectional Proxy Stream因此 XHTTP 真正做的是在 HTTP Request/Response 之上实现一套代理 Session 与数据流重组机制。这就是为什么简单说XHTTP HTTP是不准确的。十五、Header Padding 是干什么的如果每一个请求都长得非常固定例如POST /abcdef/session/0 Content-Length: 1000000Header 长度永远近似固定就会形成比较机械的通信模式。XHTTP 提供 Header Padding 机制。核心思路Request Header Length不总是固定。例如100 bytes 387 bytes 810 bytes 241 bytes ...对应配置中常见{xPaddingBytes:100-1000}设计目标可以概括成减少过于稳定、机械的 Header 长度模式。这里不建议为了“越随机越好”盲目扩大。例如100-100000显然可能给CDNWAFNginx网关带来额外问题。默认值或合理范围通常更稳妥。十六、XMUX 是什么XHTTP 还有一个很重要的机制XMUX先回忆 H2/H3。一个底层连接H2 Connection可以同时承载Stream 1 Stream 2 Stream 3 Stream 4 ...如果无限复用同一连接Connection A ├── Proxy 1 ├── Proxy 2 ├── Proxy 3 ├── Proxy 4 ├── Proxy 5 └── ...虽然连接数少但是可能产生单连接生命周期过长某条连接故障影响较大服务端资源长期占用中间网络清理长连接某些场景断流后恢复不理想。XMUX 的思路并不是简单追求连接越少越好而是控制一个连接可以复用多少次 活多久 承载多少并发 什么时候换新连接因此它更接近Connection Pool Multiplexing Policy Lifecycle Management而不是传统意义上的“开一个 muxtrue”。十七、为什么不建议 XHTTP 再叠加传统 mux.cool因为H2 / H3本身已经具有 Multiplexing。XHTTP 又有XMUX如果上面再套一层传统代理 MuxApplication ↓ Proxy Mux ↓ XHTTP XMUX ↓ HTTP/2 Multiplexing ↓ TCP会出现Mux on Mux on Mux这种设计未必提高性能反而可能增加 Head-of-Line 影响增加队列增加复杂度放大某条底层连接失败的影响。因此不要看到Mux就默认开启 更快代理优化最忌讳这种思路。十八、XHTTP 和 gRPC 有什么区别gRPC transport 的典型结构VLESS ↓ gRPC ↓ HTTP/2 ↓ TLS ↓ TCPXHTTPVLESS ↓ XHTTP ↓ H1 / H2 / H3 ↓ TLS / REALITY ↓ TCP / QUIC从能力范围看XHTTP 更宽。项目gRPCXHTTPHTTP/2是是HTTP/1.1否可HTTP/3非典型可专用 gRPC Library是不依赖 gRPC transport 实现packet-up否是stream-up类似流式能力是stream-one否是上下行分离否是XMUX否是Header Padding非 XHTTP 机制是这也是当前 Xray 官方文档在 gRPC transport 页面中建议迁移/优先考虑 XHTTP 的原因之一。十九、XHTTP 和 WebSocket 有什么区别WebSocketHTTP/1.1 ↓ Upgrade: websocket ↓ 长期双向连接握手成功以后后面不再是普通 HTTP Request/Response而是 WebSocket Frame。结构VLESS ↓ WebSocket ↓ TLS ↓ TCPXHTTPVLESS ↓ XHTTP ↓ H1/H2/H3 ↓ TLS/REALITYXHTTP 可以更加充分地利用H2H3HTTP StreamCDN HTTP 基础设施独立上下行多连接策略。所以两者不是简单的WS 新 XHTTP 更新区别在于整个 transport 思路已经发生变化。二十、XHTTP、RAW、WebSocket、gRPC 怎么选可以按照需求选择。场景 1纯直连追求简单优先考虑VLESS RAW REALITY优点链路短配置简单额外 HTTP 开销少。场景 2需要 HTTP/CDN/反代能力考虑VLESS XHTTP TLS或者VLESS XHTTP REALITY场景 3现有系统已经是 gRPC没有必要因为看到 XHTTP 就立刻全部迁移。先做A/B Test比较Latency Throughput Upload Packet Loss CPU RAM Disconnect Rate再迁移。二十一、VLESS XHTTP REALITY 应该怎么理解最推荐的理解方式VLESS 负责“代理” XHTTP 负责“怎么运输” REALITY 负责“传输安全” H2/H3 负责“HTTP 承载” TCP/QUIC 负责“真正发包”因此VLESS XHTTP REALITY并不是一个巨大黑盒协议。它实际上是┌─────────────────────┐ │ VLESS │ ├─────────────────────┤ │ XHTTP │ ├─────────────────────┤ │ H2 / H3 │ ├─────────────────────┤ │ REALITY │ ├─────────────────────┤ │ TCP / QUIC │ ├─────────────────────┤ │ IP │ └─────────────────────┘这就是做网络架构时最应该建立的思维方式永远分层分析。二十二、一个简化的 XHTTP 配置不同 Xray Core 版本、客户端以及管理面板对字段封装可能存在差异。因此这里重点展示XHTTP 的结构而不是鼓励机械复制。服务端核心部分{inbounds:[{listen:0.0.0.0,port:443,protocol:vless,settings:{clients:[{id:YOUR-UUID}],decryption:none},streamSettings:{network:xhttp,security:reality,xhttpSettings:{path:/api/v1/assets,mode:auto},realitySettings:{target:TARGET.example:443,serverNames:[TARGET.example],privateKey:YOUR_PRIVATE_KEY,shortIds:[YOUR_SHORT_ID]}}}]}客户端概念配置{outbounds:[{protocol:vless,settings:{vnext:[{address:SERVER_IP,port:443,users:[{id:YOUR-UUID,encryption:none}]}]},streamSettings:{network:xhttp,security:reality,xhttpSettings:{path:/api/v1/assets,mode:auto},realitySettings:{serverName:TARGET.example,fingerprint:chrome,password:SERVER_X25519_PUBLIC_KEY,shortId:YOUR_SHORT_ID}}}]}一个重要版本提示你会在不同版本文档、代码与客户端封装里看到传输字段写法存在差异。当前 Xray Core 源码配置结构仍可见network:xhttp而新的官方文档页面也展示了method:xhttp因此不要只凭博客里的字段名判断你的客户端一定支持哪一种写法应以实际 Core 版本的配置 schema 为准。REALITY 客户端认证字段也经历过命名调整当前官方文档使用password保存服务端 X25519 公钥对应的客户端认证材料旧资料中常见的publicKey已被重命名。因此生产环境不要从旧博客直接复制完整 JSON。正确流程确认 Xray Core 版本 ↓ 查看该版本官方配置 Schema ↓ 确认客户端 Core 版本 ↓ 生成密钥/UUID ↓ 先做最小配置 ↓ 运行 xray run -test ↓ 再上线二十三、配置检查Xray 配置修改完成后建议先执行配置测试。例如xray run-test-config/usr/local/etc/xray/config.json如果 Core 或安装路径不同请按实际路径执行。不要直接systemctl restart xray然后才去看为什么服务挂了正确步骤xray run-test-config/usr/local/etc/xray/config.json systemctl restart xray systemctl status xray journalctl-uxray-n100--no-pager二十四、怎么判断实际跑的是 H2 还是 H3最可靠的方法不是看我配置里写了什么而是看实际连接。Linuxss-ntp如果是 TCP 443TCP通常意味着H1/H2如果看到ss-nup存在 UDP 443UDP则可能涉及QUIC / H3还可以结合tcpdump例如tcpdump-ieth0 port443观察TCP 443还是UDP 443二十五、不要把“协议先进”直接等价成“速度更快”一个非常典型的错误HTTP/3 比 HTTP/2 新 ↓ 所以一定快真实情况是Speed RTT Packet Loss Congestion Control ISP QoS CDN CPU Route MTU NAT Server Load Client Implementation例如在一个0.1% 丢包 20ms RTT 高质量 TCP环境里H2 完全可能表现很好。而在移动网络 频繁切换 一定丢包环境里QUIC/H3 可能更有优势。所以真正正确的方法是Benchmark而不是看协议名字判断性能二十六、推荐的测试指标测试 XHTTP 至少应该记录指标意义TCP/QUIC Connect Time建连TLS/REALITY Handshake安全层握手TTFB首字节RTT基础延迟Download Mbps下载Upload Mbps上传P95 Latency尾延迟Packet Loss丢包CPUCore 开销RAM内存Reconnect Count重连次数Long Connection Stability长连接稳定性测试时间最好至少包括10 秒 60 秒 5 分钟 30 分钟因为Speedtest 跑 10 秒很快不代表连续看视频 2 小时稳定二十七、生产环境不要一上来就堆参数很多配置教程喜欢这样{xPaddingBytes:...,scMaxEachPostBytes:...,scMinPostsIntervalMs:...,scMaxBufferedPosts:...,scStreamUpServerSecs:...,xmux:{...:...}}看起来很专业。但工程上最危险的就是不知道参数解决什么问题却把所有参数全部写上。正确方法第一步{path:/your-path,mode:auto}跑通。第二步记录延迟 上传 下载 掉线 日志 CPU 内存第三步只有出现明确问题才修改对应参数。例如上传差 → 研究 packet-up / stream-up H3 → 检查 UDP / QUIC CDN 请求体限制 → 调整每个 POST 大小 长连接问题 → 查看 XMUX / Keepalive 需要不同回程 → downloadSettings这才是工程化调优。二十八、我更推荐哪种模式如果目标是生产稳定 配置可维护 PC / Android / iOS 多端建议第一阶段从VLESS XHTTP REALITY mode auto开始。如果确认直连 无需上下行分离 stream-one 稳定可以单独测试stream-one如果持续上传较多 需要上下行独立重点测试stream-up如果CDN / 中间层兼容优先 需要 H3 上传不是主要瓶颈重点测试packet-up二十九、最终架构建议一个比较清晰的生产思路是┌──────────────────┐ │ User App │ └────────┬─────────┘ │ SOCKS/TUN │ ┌────────▼─────────┐ │ Xray Client │ │ VLESS │ └────────┬─────────┘ │ XHTTP │ ┌────────▼─────────┐ │ H2 / H3 │ │ REALITY / TLS │ └────────┬─────────┘ │ Internet │ ┌────────▼─────────┐ │ Xray Server │ │ VLESS XHTTP │ └────────┬─────────┘ │ Freedom │ ┌────────▼─────────┐ │ Destination │ └──────────────────┘如果后续需要CDN则演进Client ↓ XHTTP H2/H3 ↓ CDN ↓ Reverse Proxy ↓ Xray如果需要上下行优化再升级Upload Client → Route A → Xray Download Client ← Route B ← Xray不要一开始直接使用最复杂架构。三十、总结只记住这 10 句话HTTP 是标准 Web 协议XHTTP 是 Xray Transport Method。XHTTP 和 HTTP/2 不在同一个抽象层。VLESS 是代理协议。REALITY/TLS 是传输安全层。XHTTP 可以利用 H1/H2/H3。packet-up 分包上行 流式下行。stream-up 流式上行 独立流式下行。stream-one 一个 Request/Response 双向流。packet-up 与 stream-up 可以支持上下行分离。生产环境优先从最小配置 auto 实测开始而不是堆参数。最终可以把它记成一句非常形象的话HTTP 是公路。 VLESS 是货物规则。 XHTTP 是运输系统。 HTTP/2、HTTP/3 是不同规格的高速公路。 REALITY/TLS 是运输过程的安全保护。 TCP/QUIC 才是真正负责把数据从 A 送到 B 的底层交通工具。当你真正建立这个分层模型以后VLESS XHTTP REALITY Vision H2 H3 QUIC XMUX这些名词就不会再混在一起了。参考资料本文技术机制主要依据Project X / Xray 官方 Transport ConfigurationProject X / Xray 官方 REALITY 文档Project X / Xray 官方 gRPC Transport 文档XTLS/Xray-core 官方 XHTTP: Beyond REALITY Discussion #4113Xray-core 当前 XHTTP / SplitHTTP 配置实现。Xray Core 仍在持续演进字段名、默认值和客户端封装可能变化。生产部署请优先核对当前 Core 版本的官方文档与配置检查结果。