企业官网建设流程全解析

一、先给结论：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 ▼ Client

HTTP 规范负责定义：

• Request Method；
• URL；
• Header；
• Body；
• Status Code；
• Cache；
• Content Negotiation；
• Connection Reuse；
• Streaming；
• HTTP/2 Multiplexing；
• HTTP/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

这样理解之后，很多概念就不会再混淆：

所以：

VLESS + XHTTP + REALITY

不是三个互相竞争的协议，而是三层组合。

四、为什么 XHTTP 不直接使用“一条普通 HTTP 连接”？

代理流量和普通 Web 请求有一个天然区别：

普通 Web 请求往往具有明确边界：

Request → Response → Done

代理连接却可能持续很久：

TCP Connection ──────────────────────────────> 持续上传 <────────────────────────────── 持续下载

例如：

• SSH；
• WebSocket；
• 视频流；
• 下载；
• API 长连接；
• 数据库连接；
• 游戏连接。

因此，一个代理 transport 必须解决：

1. 如何持续上传；
2. 如何持续下载；
3. 如何穿过 HTTP 反向代理/CDN；
4. 如何处理 HTTP 请求缓冲；
5. 如何处理多路复用；
6. 如何避免某一条长连接永久占用；
7. 如何支持 H1/H2/H3；
8. 如何在需要时把上下行拆成两个独立链路。

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 Download

packet-up 为什么有意义？

很多 HTTP 中间层对上传请求的处理方式比较保守。

例如某些：

• CDN；
• WAF；
• Reverse Proxy；
• HTTP Gateway；
• Load 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 Header；
• Request Scheduling；
• 请求管理；
• 中间层处理；
• CPU 开销。

于是 XHTTP 又提供：

stream-up

stream-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-up = 小块上传 + 大流下载 stream-up = 大流上传 + 独立大流下载 stream-one = 一个 Request/Response 完成双向流

九、mode=auto 到底会怎么选择？

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 ↓ UDP

QUIC 自己提供：

• Encryption；
• Multiplexing；
• Loss Recovery；
• Congestion Control；
• Connection Migration。

H3 的优势之一是：

不同 Stream 不再全部依赖一个 TCP 字节流。

但这并不意味着：

H3 永远比 H2 快

真实网络性能仍受：

• UDP QoS；
• NAT；
• ISP；
• CDN；
• RTT；
• Packet Loss；
• QUIC 实现；
• CPU；
• MTU；

影响。

十一、一个非常有意思的地方：H3 可以在中间被转换成 H2/H1

假设：

Client ↓ HTTP/3 ↓ CDN

CDN 到 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

理论上就可以分别优化：

• 上传路径；
• 下载路径；
• IPv4；
• IPv6；
• H2；
• H3；
• CDN；
• Origin。

这个设计理念和传统的：

一个 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: 1000000

Header 长度永远近似固定，就会形成比较机械的通信模式。

XHTTP 提供 Header Padding 机制。

核心思路：

Request Header Length

不总是固定。

例如：

100 bytes 387 bytes 810 bytes 241 bytes ...

对应配置中常见：

{"xPaddingBytes":"100-1000"}

设计目标可以概括成：

减少过于稳定、机械的 Header 长度模式。

这里不建议为了“越随机越好”盲目扩大。

例如：

100-100000

显然可能给：

• CDN；
• WAF；
• Nginx；
• 网关；

带来额外问题。

默认值或合理范围通常更稳妥。

十六、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

而不是传统意义上的“开一个 mux=true”。

十七、为什么不建议 XHTTP 再叠加传统 mux.cool？

因为：

H2 / H3

本身已经具有 Multiplexing。

XHTTP 又有：

XMUX

如果上面再套一层传统代理 Mux：

Application ↓ 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 ↓ TCP

XHTTP：

VLESS ↓ XHTTP ↓ H1 / H2 / H3 ↓ TLS / REALITY ↓ TCP / QUIC

从能力范围看，XHTTP 更宽。

这也是当前 Xray 官方文档在 gRPC transport 页面中建议迁移/优先考虑 XHTTP 的原因之一。

十九、XHTTP 和 WebSocket 有什么区别？

WebSocket：

HTTP/1.1 ↓ Upgrade: websocket ↓ 长期双向连接

握手成功以后，后面不再是普通 HTTP Request/Response，而是 WebSocket Frame。

结构：

VLESS ↓ WebSocket ↓ TLS ↓ TCP

XHTTP：

VLESS ↓ XHTTP ↓ H1/H2/H3 ↓ TLS/REALITY

XHTTP 可以更加充分地利用：

• H2；
• H3；
• HTTP Stream；
• CDN 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？

最可靠的方法不是看：

我配置里写了什么

而是看实际连接。

Linux：

ss-ntp

如果是 TCP 443：

TCP

通常意味着：

H1/H2

如果看到：

ss-nup

存在 UDP 443：

UDP

则可能涉及：

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 至少应该记录：

测试时间最好至少包括：

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 句话

1. HTTP 是标准 Web 协议，XHTTP 是 Xray Transport Method。
2. XHTTP 和 HTTP/2 不在同一个抽象层。
3. VLESS 是代理协议。
4. REALITY/TLS 是传输安全层。
5. XHTTP 可以利用 H1/H2/H3。
6. packet-up = 分包上行 + 流式下行。
7. stream-up = 流式上行 + 独立流式下行。
8. stream-one = 一个 Request/Response 双向流。
9. packet-up 与 stream-up 可以支持上下行分离。
10. 生产环境优先从最小配置 + auto + 实测开始，而不是堆参数。

最终，可以把它记成一句非常形象的话：

HTTP 是公路。 VLESS 是货物规则。 XHTTP 是运输系统。 HTTP/2、HTTP/3 是不同规格的高速公路。 REALITY/TLS 是运输过程的安全保护。 TCP/QUIC 才是真正负责把数据从 A 送到 B 的底层交通工具。

当你真正建立这个分层模型以后：

VLESS XHTTP REALITY Vision H2 H3 QUIC XMUX

这些名词就不会再混在一起了。

参考资料

本文技术机制主要依据：

1. Project X / Xray 官方 Transport Configuration；
2. Project X / Xray 官方 REALITY 文档；
3. Project X / Xray 官方 gRPC Transport 文档；
4. XTLS/Xray-core 官方 XHTTP: Beyond REALITY Discussion #4113；
5. Xray-core 当前 XHTTP / SplitHTTP 配置实现。

Xray Core 仍在持续演进，字段名、默认值和客户端封装可能变化。生产部署请优先核对当前 Core 版本的官方文档与配置检查结果。