跳到主要内容

VLESS-XHTTP

VLESS-XHTTP 是 Xray-core 于 2024 年 10 月引入的一种新型传输方式，全称为 XHTTP Transport。它将代理流量分拆为多个独立的 HTTP 请求来传输，使整体流量行为模式更接近普通的 Web 浏览，从而规避基于长连接特征的流量检测。该方案在伊朗、俄罗斯等对持续性加密流量管控较严格的网络环境中被社区验证具有一定的实际效果。

设计背景​

传统的基于 WebSocket 或 gRPC 的代理方案，虽然流量被 TLS 加密，但连接本身的生命周期特征非常明显：

  • 客户端建立一个 WebSocket 连接后，该连接会持续存在数分钟甚至数小时
  • 在此期间，大量数据双向持续流动
  • 这种"单一长连接 + 持续双向大流量"的模式在 TLS 加密之外仍然可以通过流量统计被识别
WebSocket 代理的连接模式：
[TLS 握手] → [WebSocket 升级] → [持续双向流量 10 分钟] → [连接关闭]

正常 HTTPS 浏览的连接模式：
[TLS 握手] → [GET 请求] → [响应 200KB] → [GET 请求] → [响应 50KB] → ...
（大量短暂的请求/响应交换，无持续长连接）

XHTTP 的核心思路是将代理流量的传输模式改造得接近后者。

核心设计​

HTTP 分流传输​

XHTTP 将上行（客户端→服务端）和下行（服务端→客户端）流量分别通过不同的 HTTP 请求传输：

  • 上行：通过 HTTP POST 请求（或 HTTP/2 流）携带，每个请求承载一段数据后结束
  • 下行：通过 HTTP GET 请求以流式响应（如 HTTP Chunked Transfer Encoding 或 Server-Sent Events）接收
客户端
  |
  | POST /path?session=xxx  (携带上行数据，请求完成后关闭)
  | POST /path?session=xxx  (下一批上行数据，新的 HTTP 请求)
  |
  | GET  /path?session=xxx  (接收下行数据流，使用 SSE 或 Chunked)
  v
服务端

对于流量观察者而言，看到的是一系列普通的 HTTP POST 和 GET 请求，而非一个持续数分钟的 WebSocket 长连接，行为模式与正常的 Web 应用（如聊天应用、实时推送服务）高度相似。

会话标识​

XHTTP 通过 URL 参数中的 session ID 将属于同一代理连接的多个 HTTP 请求关联起来，服务端据此将分散的请求重新组合为完整的代理数据流。

与 SplitHTTP 的关系​

XHTTP 在早期讨论中也被称为 "SplitHTTP"，两者指的是同一传输方式。Xray-core 的正式实现命名为 XHTTP，部分第三方实现和文档中仍使用 SplitHTTP 的叫法。sing-box 中的对应实现也采用了 SplitHTTP 的命名。

与 WebSocket 传输的对比​

对比维度WebSocket + TLSXHTTP（VLESS-XHTTP）
连接模式单一持续长连接多个短暂 HTTP 请求
流量行为模式持续双向大流量类似正常 Web 请求模式
CDN 兼容性广泛支持支持（部分 CDN 需配置）
连接建立开销低（单次握手）较高（多次 HTTP 请求）
抗长连接检测弱强
延迟低较低（多请求有一定开销）
传输效率高中等（HTTP 分帧有额外开销）
客户端支持极广泛较新，支持正在扩展

传输模式​

XHTTP 支持多种底层 HTTP 传输模式，适应不同的网络环境：

HTTP/1.1 模式​

使用 HTTP/1.1 的 Chunked Transfer Encoding 进行数据流传输。兼容性最好，对 CDN 和反向代理的要求最低。

HTTP/2 模式​

使用 HTTP/2 的流（Stream）机制传输。在支持 HTTP/2 的 CDN 和服务器上，多路复用带来更好的并发性能。

HTTP/3（QUIC）模式​

实验性支持，在 UDP 可用的环境下可以利用 QUIC 的特性。目前成熟度不如 HTTP/1.1 和 HTTP/2 模式。

XHTTP 与 CDN​

VLESS-XHTTP 的一个重要应用场景是配合 CDN 使用。由于流量表现为普通的 HTTPS 请求，CDN 对其的处理与普通 Web 流量相同，不会触发针对 WebSocket 的特殊处理逻辑。

这在部分对 WebSocket 流量有额外检测或限制的 CDN 和网络环境中具有优势。

客户端
  |
  | HTTPS（HTTP POST / GET）
  v
CDN 节点（如 Cloudflare）
  |
  | 回源 HTTPS
  v
源站服务器（Xray / sing-box）
  |
  v
目标服务器

适用场景​

推荐使用 VLESS-XHTTP 的场景：

  • 网络环境对持续长连接有专项检测（如伊朗、俄罗斯等）
  • 需要 CDN 中转，但希望比 WebSocket 更不易被识别为代理流量
  • 现有 WebSocket + TLS 方案频繁中断，怀疑被长连接特征检测影响
  • 已有 TLS 证书和域名，希望在 WebSocket 方案之外增加一个备选
  • 配合 Cloudflare Workers 进行额外的流量处理

需要考虑替代方案的场景：

  • 网络条件良好且无长连接检测问题（直接用 VLESS + Reality 性能更优）
  • 对延迟极为敏感（XHTTP 的多次 HTTP 请求会增加一定延迟）
  • 客户端兼容性要求高（XHTTP 是 2024 年引入的新特性，老旧客户端不支持）
  • 不使用 CDN 且没有域名（此时应优先选择 VLESS + Reality）
关于抗检测能力的说明

协议总览表格中，VLESS-XHTTP 的抗检测能力标注为 "?（伊朗/中国大陆）"，意思是：在伊朗和中国大陆的实际使用中，有社区反馈表明该协议具有一定的抗检测效果，但尚无系统性的大范围验证，结论仍带有不确定性。请结合实际网络环境和社区最新反馈判断是否适合使用。

服务端部署参考​

前置条件​

  • 一台公网 VPS，已开放 TCP 443 端口（HTTPS）
  • 一个指向服务器 IP 的域名
  • 有效的 TLS 证书（可使用 acme.sh 或 Caddy 自动申请）
  • 已安装支持 XHTTP / SplitHTTP 的 Xray-core、sing-box 或其他服务端实现

安装 Xray-core​

bash <(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh) install

验证版本，并确认当前版本支持 xhttp 传输：

xray version

申请 TLS 证书​

curl https://get.acme.sh | sh
~/.acme.sh/acme.sh --issue -d your.domain.com --webroot /var/www/html
~/.acme.sh/acme.sh --install-cert -d your.domain.com \
  --cert-file /etc/ssl/certs/your.domain.com.crt \
  --key-file /etc/ssl/private/your.domain.com.key \
  --reloadcmd "systemctl restart xray"

生成 UUID​

xray uuid

Xray 服务端配置（VLESS + XHTTP + TLS）​

创建或修改 /usr/local/etc/xray/config.json：

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "your-uuid-here",
            "flow": ""
          }
        ],
        "decryption": "none",
        "fallbacks": [
          {
            "dest": 8080
          }
        ]
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "tls",
        "tlsSettings": {
          "minVersion": "1.2",
          "certificates": [
            {
              "certificateFile": "/etc/ssl/certs/your.domain.com.crt",
              "keyFile": "/etc/ssl/private/your.domain.com.key"
            }
          ]
        },
        "xhttpSettings": {
          "path": "/your-secret-path",
          "host": "your.domain.com",
          "mode": "auto"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ]
}

xhttpSettings 字段说明：

字段说明
path请求路径，客户端配置必须一致，建议使用随机字符串
host请求的 Host 头部，通常设置为你的域名
mode传输模式，auto 自动选择，也可指定 stream-up、stream-down、packet-up 等
关于 mode 字段
  • auto：根据当前 HTTP 版本自动选择最合适的模式（推荐）
  • stream-up：上行使用持续流模式（适合 HTTP/2）
  • packet-up：上行使用分包请求模式（适合 HTTP/1.1 经 CDN 中转）
  • stream-down：下行使用持续流模式（几乎所有场景都使用此模式）

在配合 CDN 使用时，由于 CDN 通常不支持 HTTP/1.1 的持续上行流，应选择 packet-up 模式。

回落 Web 服务（Nginx）​

server {
    listen 8080;
    server_name your.domain.com;
    root /var/www/html;
    index index.html;
}

启动服务​

systemctl enable xray
systemctl start xray
systemctl status xray
journalctl -u xray -f

开放防火墙​

ufw allow 443/tcp

sing-box 服务端配置​

sing-box 将该传输方式命名为 splithttp（与 Xray 的 xhttp 对应同一设计）：

{
  "inbounds": [
    {
      "type": "vless",
      "tag": "vless-in",
      "listen": "::",
      "listen_port": 443,
      "users": [
        {
          "uuid": "your-uuid-here"
        }
      ],
      "tls": {
        "enabled": true,
        "certificate_path": "/etc/sing-box/cert.crt",
        "key_path": "/etc/sing-box/private.key"
      },
      "transport": {
        "type": "splithttp",
        "path": "/your-secret-path",
        "host": "your.domain.com"
      }
    }
  ],
  "outbounds": [
    {
      "type": "direct"
    }
  ]
}

客户端配置参考​

Xray / v2rayN 客户端配置​

在 v2rayN 等基于 Xray 的客户端中，新建 VLESS 节点时将传输方式选择为 xhttp，并填写对应的路径和域名。

对应的 JSON 出站配置：

{
  "type": "vless",
  "address": "your.domain.com",
  "port": 443,
  "users": [
    {
      "id": "your-uuid-here",
      "encryption": "none"
    }
  ],
  "streamSettings": {
    "network": "xhttp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "your.domain.com"
    },
    "xhttpSettings": {
      "path": "/your-secret-path",
      "host": "your.domain.com",
      "mode": "auto"
    }
  }
}

sing-box 客户端配置​

{
  "type": "vless",
  "tag": "vless-xhttp",
  "server": "your.domain.com",
  "server_port": 443,
  "uuid": "your-uuid-here",
  "tls": {
    "enabled": true,
    "server_name": "your.domain.com",
    "utls": {
      "enabled": true,
      "fingerprint": "chrome"
    }
  },
  "transport": {
    "type": "splithttp",
    "path": "/your-secret-path",
    "host": "your.domain.com"
  }
}

Mihomo（Clash Meta）客户端配置​

Mihomo 在较新版本中加入了对 VLESS xhttp 传输的支持：

proxies:
  - name: "vless-xhttp"
    type: vless
    server: your.domain.com
    port: 443
    uuid: your-uuid-here
    tls: true
    servername: your.domain.com
    network: xhttp
    xhttp-opts:
      path: /your-secret-path
      host: your.domain.com
      mode: auto
关于 Mihomo 的命名

Mihomo 配置中通常使用 network: xhttp。如果配置无法识别，请先升级 Mihomo，并以当前版本文档为准。

配合 Cloudflare CDN 使用​

VLESS-XHTTP 配合 Cloudflare CDN 是其一个有价值的使用场景。

服务端调整​

当流量经过 Cloudflare CDN 时，Cloudflare 与源站之间的连接方式会影响 XHTTP 的传输模式选择。推荐将 mode 设置为 packet-up，因为 Cloudflare 免费版不支持 HTTP/1.1 长连接上行：

"xhttpSettings": {
  "path": "/your-secret-path",
  "host": "your.domain.com",
  "mode": "packet-up"
}

Cloudflare 设置​

  1. 将域名的 DNS 记录添加到 Cloudflare，并开启"橙色云"（Proxied）
  2. 在 SSL/TLS 设置中，将加密模式设置为 Full（Strict）（而非 Flexible）
  3. 确认代理路径可正常回源，必要时检查缓存、WAF 和请求体限制
  4. 推荐在 Cloudflare 的防火墙规则中添加针对代理路径的保护，防止路径被扫描发现

路径安全建议​

无论是否使用 CDN，XHTTP 的路径（path）应当足够随机，避免使用容易猜到的路径（如 /v2ray、/proxy 等）：

# 生成一个随机路径
cat /proc/sys/kernel/random/uuid | tr -d '-'

与其他 WebSocket 类方案的选型建议​

方案抗长连接检测CDN 兼容配置复杂度客户端支持适用场景
VLESS + WebSocket + TLS弱好低极广普通 CDN 中转场景
VMess + WebSocket + TLS弱好低极广兼容老旧客户端
VLESS + gRPC + TLS中较好中广对 WebSocket 有限制的网络
VLESS-XHTTP强好中较新长连接检测严格的环境
VLESS + Reality极强不支持中广无 CDN 需求的最优直连方案

选型建议：

  • 如果你的网络环境没有针对长连接的专项检测，WebSocket + TLS 通常已经足够，且客户端兼容性最好
  • 如果你所在的网络（如伊朗或部分受限环境）对持续长连接有检测，VLESS-XHTTP 是值得尝试的替代方案
  • 如果你有域名和证书，且对 CDN 中转有需求，VLESS-XHTTP 是比 WebSocket 更接近正常 Web 流量的选项
  • 如果不需要 CDN 且有最高抗检测需求，仍然优先推荐 VLESS + Reality

客户端支持​

平台客户端支持状态备注
Windows / macOS / LinuxXray / v2rayN支持需使用支持 XHTTP 的 Xray-core 版本
Windows / macOS / Linuxsing-box支持命名为 SplitHTTP / splithttp
Windows / macOS / LinuxMihomo支持较新版本
iOSShadowrocket需确认取决于当前版本
iOSStash需确认取决于当前版本
iOSLoon需确认取决于当前版本
iOSQuantumult X不支持—
iOS / macOSSurge不支持（原生 XHTTP）—
AndroidNekoBox支持sing-box 内核
AndroidHusi支持sing-box 内核
AndroidExclave需确认取决于当前版本和核心实现
Linuxdae支持需要较新版本
关于版本要求

VLESS-XHTTP 是 2024 年底才正式引入的传输方式，需要客户端和服务端均升级到支持该功能的版本。如果连接失败并提示传输方式不支持，请首先确认双端版本均满足最低要求，并尝试升级到最新版本。

常见问题​

Q：XHTTP 和 SplitHTTP 是同一个东西吗？

大体上是同一类设计。Xray-core 将其命名为 XHTTP（"network": "xhttp"），而 sing-box 和部分第三方文档称之为 SplitHTTP（"type": "splithttp"）。不同实现的字段、模式和默认行为可能不完全一致，跨核心互通前需要用实际版本测试。

Q：XHTTP 和 HTTPUpgrade（也叫 UpgradeHTTP）有什么区别？

两者都是 HTTP 类传输方式，但设计有所不同：

  • HTTPUpgrade：模拟 HTTP Upgrade 请求（类似 WebSocket 升级的握手模式），建立后同样是一个长连接
  • XHTTP：将流量分拆为多个独立的 HTTP 请求，不维持单一长连接

XHTTP 在抗长连接检测方面优于 HTTPUpgrade。

Q：使用 XHTTP 后延迟是否会明显增加？

相比 WebSocket 方案，XHTTP 在上行方向需要多次 HTTP 请求交互，会有少量额外的连接建立开销。在良好的网络条件下，这个开销通常在几毫秒到十几毫秒之间，日常使用中不会有明显感知。在高延迟线路上，多次握手的累积延迟会更明显，此时需要权衡是否值得为了抗检测能力接受这个开销。

Q：服务端配置中的 path 路径需要在 Nginx 或 Caddy 中单独配置吗？

如果 Xray 直接监听 443 端口并处理 TLS，则不需要额外的 Nginx/Caddy 配置。如果使用反向代理架构（Caddy/Nginx 在前，Xray 在后），则需要在 Caddy/Nginx 中将对应路径的请求代理到 Xray 监听的本地端口：

Nginx 配置示例：

location /your-secret-path {
    proxy_pass http://127.0.0.1:10086;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_buffering off;
    proxy_request_buffering off;
}

注意 proxy_buffering off 和 proxy_request_buffering off 是必要的，否则 Nginx 的缓冲机制会破坏 XHTTP 的分流传输逻辑。

Q：XHTTP 模式下 flow 字段应该设置什么？

在 WebSocket 或 gRPC 等传输方式下，VLESS 不支持 XTLS flow，因此 flow 字段应留空或不填。XHTTP 模式同理——XTLS-Vision 仅支持在 TCP 传输模式下使用。

延伸阅读​