VLESS + XHTTP + Reality + XMUX-技术实现

摘要：VLESS + Reality 已经是公认的优秀方案，但它仍有一个潜在弱点 —— 长时间保持的 TLS 隧道本身就是一种流量特征。XHTTP 把代理流量进一步伪装成标准 HTTP 请求，配合 XMUX 多路复用降低连接开销，构成了当前代理技术栈的较高水准组合。本文解析 XHTTP 的设计原理、与其他传输方式的核心区别、完整配置方案，以及实际部署中的注意事项。

本文属于 VPS 网络与代理链路系列，该系列共六篇，可从此页查看完整阅读顺序与全部索引。

一、XHTTP 是什么

XHTTP 是 Xray-core 在 2024 年推出的一种全新传输方式（transport）。它的核心思路很直接：把代理流量封装成普通的 HTTP 请求体（PUT / POST body），而不是通过 WebSocket 升级或 gRPC 流来传输数据。

设计动机

在 VLESS + Reality 的经典配置中，代理流量通过一条持久 TLS 隧道传输。虽然 Reality 让这条隧道在 TLS 层面完美伪装成访问真实网站，但隧道本身的行为模式 —— 长时间保持连接、双向持续传输数据 —— 与普通用户浏览网页的行为存在差异。

流量分析系统可以通过统计连接持续时间、数据包大小分布、传输时序等特征来标记可疑连接。

XHTTP 的解法是改变传输形态：不再使用持久隧道，而是把每一段代理数据包装成一个独立的 HTTP 请求。从网络层面看，这就是一系列标准的 HTTP PUT / POST 请求 —— 与用户上传文件、提交表单、调用 API 的行为完全一致。每个请求都有明确的开始和结束，没有长连接特征。

三种工作模式

packet-up：上行数据通过多个短 HTTP 请求发送，下行通过一条长连接流式返回。兼容性最好，是最基本的模式
stream-up：上行也使用流式传输，双向都走长连接。性能更好，但要求中间网络设备支持流式上传
stream-one：上下行合并在同一个 HTTP 流中双向传输。性能最优，但对网络环境要求最高，需要完整的 HTTP/2 双向流支持

二、为什么比 WebSocket 和 gRPC 更好

这个问题要从检测视角来回答 —— 每种传输方式都有自己的协议层特征，而这些特征正是被用来识别和标记代理流量的依据。

2.1 WebSocket 的弱点

WebSocket 需要一个从 HTTP 到 WebSocket 的协议升级过程，请求头里会带上 Upgrade: websocket 和 Connection: Upgrade 这两个特殊字段。

虽然 WebSocket 是合法的 Web 技术，但在实际互联网流量中，使用 WebSocket 的站点占比并不高。当看到大量到同一个 IP 的 WebSocket 连接时，这本身就是一个值得关注的信号。

更关键的是：升级完成后会建立一条持久的双向通信通道，其流量模式（大量小包、双向交替传输）与代理行为高度吻合。协议升级头 + 流量行为模式的组合，足以精准标记 WebSocket 代理。

2.2 gRPC 的弱点

gRPC 基于 HTTP/2，但它使用特定的 content-type: application/grpc 头部。这是一个非常明确的协议指纹 —— gRPC 主要用于微服务间通信和 API 调用，普通用户浏览器几乎不会产生 gRPC 流量。

当在一个看似普通的 HTTPS 连接中检测到 gRPC 特征时，基本可以确定这不是正常的网页浏览行为。此外，gRPC 的流式传输有独特的帧结构（以 5 字节长度前缀开头的消息帧），在流量分析中可以作为额外的识别依据。

2.3 XHTTP 的优势

XHTTP 发出的就是标准的 HTTP PUT / POST 请求，使用 application/octet-stream 等通用 content-type：

❌ 没有协议升级头
❌ 没有特定的 content-type 指纹
❌ 没有特殊的帧结构

从检测视角看，这就是用户在上传文件或调用 RESTful API —— 互联网上最常见的合法行为之一。

三、XMUX：多路复用

XHTTP 解决了「传输形态」问题，但每次请求都新建连接会带来额外开销。XMUX 就是为此设计的连接复用层。

它的作用是把多个逻辑数据流复用在同一批 HTTP 连接上，并在连接达到一定寿命后平滑轮换，避免单条连接存活过久形成新的特征。

核心参数：

maxConcurrency：单条连接上允许的最大并发流数，不建议设得过高
cMaxLifetimeMs：连接的最大存活时间，控制轮换频率

四、完整协议栈：四层架构

这套方案的分层结构如下：

┌─────────────────────────────────────────────┐
│  应用层     代理数据（用户实际访问的流量）      │
├─────────────────────────────────────────────┤
│  传输层     XHTTP（封装为 HTTP 请求体）        │
│             + XMUX（连接复用与轮换）           │
├─────────────────────────────────────────────┤
│  安全层     Reality（TLS 伪装，借用真实站点证书）│
├─────────────────────────────────────────────┤
│  协议层     VLESS（轻量代理协议，无加密开销）   │
└─────────────────────────────────────────────┘

客户端与真实站点的交互流程（示意）：

C ->> S: 发起 TLS 连接（Client Hello）
S ->> T: 转发 Client Hello 到伪装目标站点
T ->> S: 返回真实证书 + Server Hello
S ->> C: 转发真实证书

Note over G: TLS 证书验证通过 ✓（看起来就是访问真实网站）

C ->> S: HTTP PUT /upload    ← XHTTP 封装的代理数据
Note over G: 看到：普通文件上传请求
S ->> C: HTTP 200

C ->> S: HTTP POST /api      ← 更多代理数据
Note over G: 看到：普通 API 调用
S ->> C: HTTP 200

Note over C,S: XMUX：所有请求复用同一条 HTTP/2 连接

五、服务端配置示例

Xray-core 的 config.json（参考 Xray 官方文档）：

{
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "your-uuid-here", "flow": "" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "mode": "auto",
          "path": "/your-custom-path"
        },
        "security": "reality",
        "realitySettings": {
          "dest": "www.microsoft.com:443",
          "serverNames": ["www.microsoft.com"],
          "privateKey": "your-private-key-here",
          "shortIds": ["6ba85179e30d4fc2"]
        }
      }
    }
  ],
  "outbounds": [
    { "protocol": "freedom", "tag": "direct" }
  ]
}

配置要点

network 设为 xhttp，启用 XHTTP 传输
mode 设为 auto，让 Xray 根据网络环境自动选择最优工作模式，也可手动指定
path 是 HTTP 请求的路径前缀，客户端和服务端必须一致，建议用不易猜到的随机路径
flow 必须留空 —— XHTTP 不支持 xtls-rprx-vision（vision 仅支持 TCP 传输）。这是从 VLESS + Reality（TCP）迁移时最容易犯的错误
Reality 参数（dest、privateKey、shortIds）的配置原则与纯 VLESS + Reality 完全一致

六、客户端配置示例

Clash / mihomo 的 YAML 配置：

proxies:
  - name: "vless-xhttp-reality"
    type: vless
    server: your-server-ip
    port: 443
    uuid: your-uuid-here
    network: xhttp
    udp: true
    tls: true
    servername: www.microsoft.com
    xhttp-opts:
      mode: auto
      path: /your-custom-path
    reality-opts:
      public-key: your-public-key-here
      short-id: 6ba85179e30d4fc2
    client-fingerprint: chrome

注意事项

客户端不要配置 flow: xtls-rprx-vision，XHTTP 传输下该选项不可用
path 必须与服务端完全一致
client-fingerprint 推荐 chrome，与 Reality 的最佳实践一致
并非所有 Clash 分支都支持 XHTTP，确认你使用的客户端版本支持此配置

七、与其他传输方式的对比

对比维度	TCP（裸）	WebSocket	gRPC	H2	XHTTP
协议特征	无伪装	升级头暴露	content-type 暴露	特征较少	无明显特殊特征
多路复用	不支持	不支持	支持	支持	支持（XMUX）
CDN 兼容性	不兼容	兼容	部分兼容	部分兼容	兼容
抗流量分析	弱	中等	中等	较强	强
连接轮换	不支持	不支持	不支持	不支持	支持（XMUX）
性能开销	最低	低	低	低	中等
配置复杂度	简单	简单	中等	中等	较复杂
flow(vision)	支持	不支持	不支持	不支持	不支持
推荐搭配	Reality	CDN 中转	CDN 中转	Reality	Reality

选择建议

追求最高隐蔽性 → XHTTP + Reality + XMUX
平衡性能与安全 → TCP + Reality + vision（经典方案，依然可靠）
需要 CDN 中转 → WebSocket（兼容性最好）或 XHTTP（隐蔽性更好）
简单部署 → TCP + Reality

八、性能考量

XHTTP 的 HTTP 封装不可避免地引入额外开销，但实际影响取决于使用场景。

开销来源

HTTP 头部字节开销：每个请求都附带标准 HTTP 头部，这些数据不携带代理流量但占用带宽
请求-响应模型的延迟：packet-up 模式下每段数据需等待服务端 HTTP 响应，增加一个 RTT
XMUX 连接管理开销：连接轮换、流调度需要额外 CPU 和内存

实际影响

日常网页浏览、视频流媒体：额外开销几乎不可感知。现代网页本身就包含大量 HTTP 请求，额外几十字节的头部可忽略
大文件下载、高带宽传输：用 stream-up 或 stream-one 模式可显著降低开销，性能接近传统 TCP
延迟敏感型应用（在线游戏等）：packet-up 的额外 RTT 可能有影响，建议这类场景仍用 TCP + Reality + vision

总的来说，XHTTP 用可接受的性能代价换取了显著更高的隐蔽性。在检测能力持续提升的背景下，这个权衡对大多数用户是值得的。

九、客户端支持情况

完整支持

Xray-core 原生支持（参考实现）
基于 Xray-core 的 GUI 客户端（v2rayN、v2rayA 等）通常可通过自定义配置使用

部分支持

部分 sing-box 版本已实现 XHTTP 基本支持，但 XMUX 进度可能落后于 Xray-core
mihomo（Clash.Meta）对 XHTTP 的支持取决于具体版本，建议关注项目更新日志

暂不支持

原版 Clash（已停止维护）
部分较旧的移动端客户端

使用前务必确认客户端和内核版本是否支持，建议直接使用最新版 Xray-core 以获得最完整的功能支持。

十、部署注意事项

flow 必须留空 —— 最常见的配置错误。XHTTP 不兼容 xtls-rprx-vision，从 TCP + Reality 迁移时一定要删掉 flow 配置
path 保持一致 —— 服务端和客户端的 path 必须完全一致，包括大小写和前缀斜杠
端口使用 443 —— 与标准 HTTPS 一致，避免非常规端口引起注意
XMUX 参数调优 —— 初始用默认值即可，后续根据实际情况调整 maxConcurrency 和 cMaxLifetimeMs，不要设得过高
mode 选择 —— 建议用 auto；如果确定网络支持，可手动指定 stream-one 获得最佳性能
监控连接质量 —— XHTTP 的 HTTP 封装对网络质量有一定要求，若频繁断连，尝试切换到 packet-up 模式或降低 XMUX 并发参数

十一、常见问题

Q：XHTTP 需要额外的 Web 服务器（如 Nginx）吗？

不需要。Xray-core 内置了对 XHTTP 的完整处理能力，不需要前置 Nginx 或 Caddy。Reality 本身就充当了 TLS 终端，Xray 直接处理解密后的 HTTP 请求。

Q：XHTTP 和 H2（HTTP/2）传输有什么区别？

H2 传输是利用 HTTP/2 的流机制传输代理数据，但它仍然是一条持久连接。XHTTP 则把数据封装为独立 HTTP 请求，可以用 packet-up 模式实现短连接特征；此外 XHTTP 支持 XMUX 连接轮换，H2 不具备这个能力。

Q：从 VLESS + Reality 迁移到 VLESS + XHTTP + Reality 复杂吗？

迁移本身不复杂，主要改三处：network 从 tcp 改为 xhttp、添加 xhttpSettings 配置、删除 flow 配置。但客户端也要同步更新并确认支持 XHTTP。

Q：是否所有用户都应该升级到 XHTTP？

不一定。如果当前 VLESS + Reality + vision 方案运行稳定且未受干扰，不必急于迁移。XHTTP 更适合这些场景：所在地区对长连接有针对性检测、需要通过 CDN 中转、追求极致的流量伪装效果。对大多数用户，经典的 TCP + Reality + vision 在当下仍是足够可靠的选择。