XHTTP: Beyond REALITY

[RPRX]

中文 | Русский

XHTTP: Beyond REALITY

开发简述：2024 年中，@mmmray @ll11l1lIllIl1lll 等人基于 @RPRX 所述的“分包上行、流式下行”原理及实现细节开发出了 SplitHTTP，首次实现了不牺牲下行效率的同时穿透绝大多数支持 HTTP 的中间盒，并首次大规模实现了 QUIC H3 过 CDN，开启了一个崭新的时代，浏览器转发 Broswer Dialer 支持、减少特征的 header padding、控制复用的 XMUX、解锁 REALITY 也相继被安排上。随后 @RPRX 接手开发，实现了真正的上下行分离并更名为 XHTTP，比如上下行可以分别是 IPv6 CDN H3、IPv4 REALITY H2（源 IP 都可以不同），这下又开启了一个崭新的时代，紧接着开发了不牺牲上行效率的流式上行 stream-up 模式、可以分享全部细节配置的 extra 方案，并给 stream-up 模式加上了默认的 gRPC header 伪装，实现了 H2 流式上行过 CDN，取代了传统的 gRPC 传输层，当初发现这也行就不会有它了，最后将 HTTP 传输层作为 stream-one 模式并入 XHTTP，使其也拥有了 header padding、XMUX、gRPC header 伪装等特性。至此，我们有了完全体 XHTTP：各种姿势穿透中间盒、上下行分离、丝滑的 XMUX 等应有尽有，XHTTP 全场景通吃的时代正式到来。

原为导剪版文档，不小心写成了文章。这篇文章旨在帮助你透彻地理解 XHTTP 的原理、设计，以便更好地使用它。

如果你要捐助 Xray 项目、收藏 NFT，相关介绍在文末，感谢支持！

快速上手指南

别看 XHTTP 的参数较多，其实都调好了默认值，如果你只是想用 XHTTP 的话，只需遵循六步：

1. 无论是 TLS 还是 REALITY，一般来说 XHTTP 配置只需填 path，其它不填即可
2. 服务端支持 QUIC H3 的话，客户端 alpn 选 "h3" 即可使用 QUIC
3. CDN 优选 IP 的话，客户端 address 填 IP，serverName（SNI）填域名即可
4. 连不上 CF 的话，启用 CF 面板内的 gRPC 支持
5. 无法穿透 Nginx 的话，把 Nginx 的 proxy_pass 改为 grpc_pass
6. 无法穿透其它 CDN 或反代软件的话，建议 mode 选 "packet-up"，兼容性最强

XHTTP 默认有多路复用，延迟比 Vision 低但多线程测速不如它，除非测速前设了 "maxConcurrency": 1，参考 XMUX 小节。

此外 v2rayN&G 客户端有全局 mux.cool 设置，用 XHTTP 前记得关闭，不然连不上新版 Xray 服务端。

这篇文章可以当增强版文档用，它基本上涵盖了关于 XHTTP 你想要了解的所有内容，对每个参数都有解释，文末也有一份涵盖了所有参数的配置示例，并且标注了每个参数的使用场景，如果你对哪个参数不清楚，文内搜索参数名即可找到该参数的详细解释。

两个底层逻辑

正如 REALITY 可以伪装成别人的网站，反审查的根本逻辑就是增加审查者执行封锁时的“附带伤害”，使审查者不敢贸然封锁，我当年看好 TLS 以及 TLS 上流量的时序、长度特征混淆也是同理。多年经验告诉我们 GFW 不会永久封锁大型 CDN 的整个 IP，否则会波及太多常规网站，那么对于 XHTTP，我们最初的目标就是把它隐藏在众多各种各样的 CDN 后面。然而 CDN 为了防止源站遭受攻击，除了有特殊支持的 WS、gRPC 外，一般会缓存完整个 HTTP 请求再发给源站，许多 HTTP 中间盒默认也是这样的行为。据此，Tor 的 Meek 协议把往返流量包装为了一个个 HTTP 请求以穿透这些中间盒，但速率惨不忍睹，因为它没有采用 XHTTP 的“流式下行”。什么是“流式下行”呢？想象一下你正在一个网站上下载一个很大的文件，CDN 没击中缓存于是回源拿，但显然它不太好像上行一样先缓存完整个文件让你干等，而是源站发来多少数据，CDN 就即时转发给你，这就是 XHTTP “流式下行”的基础，也保证了最重要的下行速率可以拉满。至于上行，出于兼容性考虑，XHTTP 首先实现的是“分包上行”，即把上行流量包装为一个个 POST 请求，它的效率显然会打折扣，但好在对于一般的代理需求而言上行流量极少。此后我加了“流式上行”，并且我们发现加上 gRPC header 伪装后还能 H2 流式上行穿透 CF，而我几轮优化”分包上行“后速率甚至直追”流式上行“。

顺便谈一下最近又比较火的套 CDN 是否属于“滥用”的问题：显然不支持流式上行的 CDN 其本意并非让你用来搭建代理服务，但我们为了对抗 GFW，不断探索、开发、利用尽可能多的新路是合理且必要的，是不得已而为之，且增加审查者的“附带伤害”就是要求我们混入“正常”服务，这也是不可避免的。举个最简单的例子：哪天 IP 白名单了而 CDN 的 IP 在里面，你用还是不用？反审查这一领域并不适用现实世界的一些规则，这么简单的道理却一直都有人想不明白。 如果还是没想通，那像 WebSocket 这样的传输层现在仅为了套 CDN 而存在，作为开发者可以删掉它，作为用户可以建议开发者删掉它，以自身的实际行动来证明“滥用 CDN”并不只是为了眼红攻击 Xray 这一为满足某些病态心理的日经无聊行为而找出的又一个借口罢了，与此同时身体却很诚实，与此同时不难窥见，有些人的虚伪本质已经暴露无遗。

PACKET-UP

这一小节技术细节太多，非开发者可以只看粗体部分。

对于 XHTTP 兼容性最强的“分包上行、流式下行”，即 packet-up 模式，我们是这样设计的：

1. 客户端 POST /yourpath/sameUUID/seq 以发送上行数据：

   • UUID 是随机生成的，等下启动下行时的 UUID 与它相同，以便服务端关联，若服务端未在 30 秒内成功关联，将终止会话
   • seq 从 0 开始，必须发完上一个 POST 的 body（但无需等响应）再发下一个
   • 多个 POST 有小概率乱序到达服务端，服务端会按 seq 进行重组，默认最多缓存 30 个，超限断连
   • 注意 UUID 和 seq 都设计在 path 里而非 query string，以避免遇到奇怪的问题

2. 客户端 GET /yourpath/sameUUID 启动下行，服务端响应头包含：

   • X-Accel-Buffering: no 以告知中间盒禁用缓冲
   • Cache-Control: no-store 以告知中间盒无需缓存
   • Content-Type: text/event-stream 以伪装成 server-sent events（兼容性更好，可以设置 noSSEHeader 以关闭）
   • 若为 HTTP/1.1 还需包含 Transfer-Encoding: chunked，H2/H3 则不需要

3. 为了避免浏览器转发 Browser Dialer 遇到跨域限制，服务端针对所有 GET、POST 的响应头都会包含：

   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST

4. 为了解决 HTTP 请求头和响应头的固定长度特征：

   • 客户端发的 path 均默认带上 ?x_padding=000...（放 query string 是为了防止 Browser Dialer 产生不必要的 OPTIONS 请求），默认长度为 100-1000，每次请求随机，服务端默认会检查它是否在服务端允许的范围内
   • 服务端发的响应头均默认包含 X-Padding: 000...，默认长度为 100-1000，每次响应随机
   • 这便是我多次提及的 header padding，对应设置项为 xPaddingBytes

分包上行、?x_padding=000... 会产生较多、较长的日志，你可以在反代软件中设置不记录它们。

此外，和 Xray 的其它传输层一样，服务端也接受 X-Forwarded-For header 以取得客户端的真实 IP，也会依据服务端设置的 host 来检查客户端发来的 host（个人建议是没事别设，毕竟已经隐藏在 path 后面了）。

以上就是 packet-up 模式的最简化、必要流程，不过此时还有个小问题：如何具体实施、限制 POST 请求？有三个专属参数：

• scMaxEachPostBytes：客户端每个 POST 最多携带多少数据，默认值 1000000 即 1MB，该值应小于 CDN 等 HTTP 中间盒所允许的最大值，服务端也会拒绝大于该值的 POST
• scMinPostsIntervalMs：仅客户端，基于单个代理请求，客户端发起 POST 请求的最小间隔，默认值 30 毫秒
• scMaxBufferedPosts：仅服务端，基于单个代理请求，服务端最多缓存多少个 POST 请求，默认值 30 个，超限断连

“基于单个代理请求”的意思是每个代理请求各自计数、互不影响，即使它们在同一条 H2 / H3 连接内，这便是 sc 即 sub-connection 的含义。为了减少指纹，前两个值可以设为范围的形式，比如分别为字符串 "500000-1000000"、"10-50"，每次随机。这些参数都可以通过 extra 下发给客户端，文末有说明。此外值得一提的是，Xray 最新版优化了 packet-up，速率甚至直追 stream-up，主要利好 QUIC H3 过 CDN。

H1 / H2 / H3

既然我们有了几乎能穿透所有 HTTP 中间盒的 packet-up 模式，让我们来讨论一个有趣的东西：QUIC H3 过 CDN，即当初 SplitHTTP 那个崭新的时代，理解这一小节对于灵活使用 XHTTP 尤为重要。

很多 HTTP 中间盒的一个特性就是会进行 HTTP 版本的转换，比如 CDN、Nginx 会将收到的 H3 流量转为 H1 或 H2 流量回源，也就是说我们的 XHTTP 服务端可以仅监听 H1 和 H2，无需监听 H3，但 XHTTP 客户端却可以使用 H3。

这也是 XHTTP 服务端的默认行为：仅监听 TCP 端口并处理 H1 和 H2 流量。 当启用 TLS 并在 alpn 处仅设置一个元素 "h3" 时，服务端将仅使用 quic-go 监听 UDP 端口并处理 H3 流量，但是目前不建议你这样做，而应将 XHTTP 隐藏在真正的 Nginx、Caddy 后面以减少指纹特征，这也是 XHTTP 相较于其它 QUIC 类代理的重要优点之一，另一个当然是能过 CDN。 此外 H3 的拥塞控制为应用层实现，理论上你可以修改这些反代软件的 QUIC 拥塞控制算法并编译，以实现有些人想要的暴力发包。

对于 XHTTP 客户端：

1. 启用 TLS/REALITY 时，默认使用 H2，否则使用 HTTP/1.1
2. 启用 TLS 时，若 alpn 仅有 "http/1.1" 则使用 HTTP/1.1（但 Xray 并不会允许它修改 uTLS 浏览器指纹伪装）
3. 启用 TLS 时，若 alpn 仅有 "h3" 则使用 quic-go H3
4. 不过当你使用 Browser Dialer 时，具体的 HTTP 版本就由浏览器决定了（整个 tlsSettings 都会失效）

如果你要确认 Xray 客户端实际使用的 HTTP 版本、host，以及 XHTTP mode、上下行分离等信息，将日志调至 "info" 级别即可。

代理的 QUIC H3 过 CDN，至少 XHTTP 是首个大规模实现的，开了条新路，毕竟有的地区、有的运营商对 H3 审查不严，不过也有的会 Q 死。即使后来我们开发了 stream-up 模式并发现了加上 gRPC header 伪装就能穿透 CF，也只作用于 H2，看来这个崭新的时代的含金量还在不断上升。

XMUX

既然我们提到了 H2 和 H3，就不得不提它们的多路复用：均为 0-RTT，区别是 H3 没有 H2 的 TCP 队头阻塞问题，并且支持连接迁移，客户端换网也不会断。那么经常研读 RFC 的朋友就会问了：如何具体控制它们的多路复用？我们设计了一个简洁而强大的接口，即 XMUX：

• maxConcurrency：每条 TCP/QUIC 连接中最多同时存在多少代理请求，连接中的代理请求数量达到该值后 core 会建立新的连接，以容纳更多的代理请求。XMUX 全为 0 时该项默认值为 "16-32"，每次随机。

• maxConnections：最多同时存在多少条连接，连接数达到该值前每个新的代理请求都会开启一条新的连接，此后 core 会开始复用已有的连接。该值与 maxConcurrency 冲突，只能二选一。默认值 0，即不限制，支持填写范围，每次随机。

• cMaxReuseTimes：一条连接最多被复用几次，复用该次数后将不会被分配新的代理请求，将在内部最后一条代理请求关闭后断开。XMUX 全为 0 时该项默认值为 "64-128"，每次随机。

• cMaxLifetimeMs：一条连接最长“存活”多久，存活该时间后将不会被分配新的代理请求，将在内部最后一条代理请求关闭后断开。默认值 0，即不限制，支持填写范围，每次随机。

• hMaxRequestTimes：@xqzr 发现 Nginx 默认最多允许每条 TCP/QUIC 连接累计承载 1000 个 HTTP 请求，XMUX 全为 0 时该项默认值为 "800-900" 取随机，否则该项默认 0 即不限制。该项基于 HTTP 请求计数，一般来说 stream-one 只产生一个 HTTP 请求，stream-up 是两个，packet-up 则是 N 个。该项计数不严谨，且 Golang 的 GET 请求有自动重试，故不建议顶格填写，那些 CDN 什么的要试出来。其中 packet-up 上行循环 POST 时若超过该值会自动切换到另一个 TCP/QUIC 连接，占它一个 reuseTimes 但不占 concurrency。 其实按 XMUX 的三项默认值，stream-* 不会超限，就 packet-up 会超，而它是 H3 的默认 mode，所以新增该项又主要是利好了 H3。

• hKeepAlivePeriod：H2 / H3 连接空闲时客户端每隔多少秒发一次保活包，默认 0，即 Chrome H2 的 45 秒，或 quic-go H3 的 10 秒。它是 XMUX 里唯一不允许填范围（该项取随机才是特征）且允许填负数（比如填 -1 关掉空闲保活包）的项，建议留 0。

XMUX 提供的这些参数可以组合出各种用法，比如多线程测速前需要设 "maxConcurrency" 1，而“无限”复用可以设 "maxConnections" 1。即使你懒得研究也没事，当这些值全为 0 时就会取到上面写的三个默认值，相当于隔段时间就换个新的 H2/H3 主连接，相当丝滑，不会有 gRPC、HTTP 传输层始终复用同一条连接导致的“断流”体验。同样，这些参数都可以通过 extra 下发给客户端。

注：全不填也相当于全为零，会取到三个默认值，但若填了任一项，其它项就没有默认值了，全都要自己填，除前两项外其它项均可同时填。

此外，使用 XHTTP 时不要启用 mux.cool，并且新版 Xray 服务端已有检查，只接受纯 XUDP。

关于 XMUX 的默认值，一些摘录：

• 我特地选了两个在 TLS 外不太能看出来的选项即 maxConcurrency 加 cMaxReuseTimes（而不是 maxConnections 加 cMaxLifetimeMs），并且这两个选项的默认值都是 range 取随机，最大程度上消除了潜在特征。
• 我选择 maxConcurrency 而不是 maxConnections，就是为了防止连接数成为 fixed pattern，当然如果你喜欢后者也可以手动设置

• XMUX 和 Nginx 的计数对象不同，maxConcurrency 和 cMaxReuseTimes 都是基于“被代理连接”计数的，只有 stream-one 会产生一个 HTTP 请求，而 stream-up 一个上行一个下行是两个，packet-up 则是 N 个
• 不过我不确定 stream-one 会不会在某些情况下自动多产生一个 HTTP 请求，还有我觉得追求一条连接复用到底没有太大的意义，因为你是运营商的话你也会限速、清理旧的连接，不然资源都被旧连接慢慢占完了，所以 XMUX 的默认参数就是限制复用+定期换连接

文章下方还有讨论一些 Nginx 参数。

STREAM-UP/ONE

终于轮到 XHTTP 的另一个重要模式了：“流式上行、流式下行”的 stream-up，顾名思义这种模式的上行也是流式的，从而不会牺牲上行效率。 它本来是为 REALITY 而开发的，直到我们发现加个 gRPC header 伪装 H2 就能穿透 CF（需要在面板中开启 gRPC 支持），并且 Nginx 等反代软件的支持也不错（Nginx 推荐 grpc_pass，简单省事），所以 mode 默认值 "auto" 的行为是：

• 客户端：TLS H2 时 stream-up，REALITY 时 stream-one（有 downloadSettings 时 stream-up），否则 packet-up
• 服务端：默认同时接受三种模式，若设为具体的模式就是仅接受它，"stream-up" 是例外，它还接受 stream-one

stream-up 比 stream-one 兼容性好一些，有群友说 CFT 开了流式上行就能用 stream-up，但还得再开个选项才能用 stream-one（可能是 SSE 伪装的锅？），还看到有个 CDN（忘了啥名字）用 stream-one 会被严重限速，但用 stream-up 不会

它们的实现方式是（非开发者可以跳过）：

• 对于 stream-up，把 packet-up 的分包上行改为流式的 POST /yourpath/sameUUID 即可，也有 ?x_padding=000...
• 对于 stream-one，POST /yourpath/ 即可，响应即为下行，双向流式，请求头、响应头均有 header padding
• 注意 stream-one 如果填 /yourpath，实际请求的是 /yourpath/，若末尾没有 / 会自动补上
• 上行均默认有 Content-Type: application/grpc 以伪装成 gRPC（可以设置 noGRPCHeader 以关闭）
• 下行的服务端响应头与 packet-up 的 1 完全一致，stream-one 会出现以 SSE 回应 gRPC 的奇观，若遇到问题可尝试 noSSEHeader

那么经常使用 gRPC 的朋友就会问了：stream-up 比 gRPC 传输层有什么优势呢？

• 前者无需任何 gRPC 库，性能更好
• 前者的下行流量是独立的 GET 请求，不会受到 CDN 对 gRPC 的流量限制
• 前者还有 header padding、XMUX、上下行分离 等增强，且已经引入了 extra 机制，所有参数均可分享，更成熟

当然，XHTTP 相较于 WebSocket、HTTPUpgrade 的优势，除了“没有 ALPN 为 http/1.1 的显著特征”外，相信你都看到这里了，心里也早已有了答案，我就不一一列举了，主要是太多了也不好列。

上下行分离

压轴登场的当然是又一个崭新的时代：上下行分离。 我们大概知道，现在 GFW 针对 TLS in TLS 等流量特征的检测是基于单条连接，那么如果我们把上下行拆分到不同的审查系统，比如上行跑 IPv4 的 TCP，下行跑 IPv6 的 UDP，GFW 就会一时反应不过来。而由于 XHTTP 服务端仅基于 path 中随机生成的 UUID 关联上下行，packet-up 和 stream-up 天生就具有真正的上下行分离能力，且由于 XHTTP 可以穿透各种 CDN、可以搭配 REALITY 等，可选姿势也无限多。对于客户端，需要设置 downloadSettings：

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // must be the same
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, client only
        "noSSEHeader": false, // server only
        "scMaxEachPostBytes": 1000000, // packet-up only
        "scMinPostsIntervalMs": 30, // packet-up, client only
        "scMaxBufferedPosts": 30, // packet-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": "64-128",
            "cMaxLifetimeMs": 0,
            "hMaxRequestTimes": "800-900",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // client only
            "address": "", // another domain/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // must be the same
                ...
            },
            "sockopt": {} // will be replaced by upload's when in "extra"
        }
    }
}

可以看出，downloadSettings 其实就是一套全新的 streamSettings，但是多了类似于 VLESS 出站中的 address 和 port 以指向另一个入口。显然其中 network 必须为 "xhttp"（不可省略），security 可以为 "tls" 或 "reality"。sockopt 项不存在时会继承上行，且由于其中有些参数只作用于本地、分享后会出问题，若处于 extra 中（可去掉）则为强制继承上行。除该特例外，上下行分离时下行配置是完全独立的，不会继承上行的任何配置，而且比如，即使上下行均未填 XMUX 从而取默认值时，它们分别在 range 内 roll 出的确定值也是相互独立、无关的，这样随着时间的推移，上下行的复用完全不对称，切换主连接的时间点也不同，反分析效果更好。因为 GFW 若要对上下行分离动手，“主连接发起的时间点相同”肯定是最重要的切入点，所以以后 XHTTP 还会允许一开始就以不同的时间点发起上下行连接。

其实如果你套了 CDN，甚至不需要修改服务端配置就可以玩转上下行分离，比如你可以优选出一个 IPv4 跑 TLS H2，再优选出一个 IPv6 跑 QUIC H3。而且 CDN 基本都支持“同域域前置”，比如上行 serverName 填 "a.example.com"，下行 serverName 填 "b.example.com"，上下行 host 均填 "c.example.com"，实现外部 SNI 看起来也不同，当然如果你本来就有两个域名就更好了。如果你没有任何域名的话，也可以开两台 VPS、开两个 REALITY 玩上下行分离：无论是 CDN 加反代，还是 REALITY 加回落，只要最终以同一 path 抵达同一 VPS 上的同一 XHTTP 入站即可。总之由于 XHTTP 到处都能用，可随意搭配出来的组合是无限的，唯一的问题是脑洞够不够大。

比如上下行分离问世后，很多人的用法其实是把上行分给去程优的线路、把下行分给回程优的线路，这样也挺实用的。

上面贴出了一份涵盖了所有参数的配置示例，主要是为了让大家知道每一项应该写在哪，并说明一下前文中没怎么解释的参数：

• extra 是 host、path、mode 以外的所有参数的原始 JSON 分享方案，当 extra 存在时，只有该四项会生效。且分享链接中只有这四项，GUI 一般也只有这四项，因为 extra 中的参数都相对低频，且应当由服务发布者直接下发给客户端，不应该让客户端随意改。
  补充说明：“下发”的意思是“人去下发”，就是服务发布者写好 extra 后整个放进分享链接，客户端直接作为自己的 extra 就可以用。

• host 的行为与 Xray 其它基于 HTTP 的传输层一致，客户端发送 host 的优先级为 host > serverName > address。服务端若设了 host，将会检查客户端发来的值是否一致，否则不会检查，建议没事别设。host 不可填在 headers 内。

如果你要确认 Xray 客户端实际使用的 HTTP 版本、host，以及 XHTTP mode、上下行分离等信息，将日志调至 "info" 级别即可。

Beyond REALITY

去年初我回归并写了秒天秒地秒空气的 REALITY，一举解决了多个痛点，然后就天天泡夜店没怎么管了，连文章都鸽到了现在还没完成，XUDP UoT Migration 更可惜，去年文章快写完了都没发，不知不觉 REALITY 已悄然成长为直连主力，经常能看到 XX 被封了下面的评论是推荐换 REALITY，口碑是有目共睹的，甚至因为过于稳定，这里都没以前热闹了。虽然 Xray 也为其它 transports 做出过大量优化、改进，但 XHTTP 是第一个 Xray 原生的传输层，第一个就整了波大的，当你看完这篇文章，也清楚 XHTTP 可以和 REALITY 一起用：

Beyond REALITY 的意思并非是取代 REALITY，而是流行程度超越 REALITY。毫不夸张地说，正如 Xray 一贯的风格，XHTTP 的出现使得其它基于 HTTP 的传输层全部黯然失色，这就是 XHTTP 全场景通吃的时代。它将会比上一个成功的协议 REALITY 更加流行，因为 XHTTP 的特性就已经决定了它的覆盖面会更广。

最后，希望 XHTTP 的出现能够给大家带来一点小小的震撼，正如 Xray 历史上多次做到的那样：变革、推陈出新，始终是 Xray 的信仰。

若本文对你有所帮助，支持一个 REALITY NFT：

• 总数一千个，首发一百个的售价为 0.01 ETH，此后的售价会涨，抢到首发就是纯捡漏
• 一篇介绍 REALITY 的文章将于接下来几天发布 变成了介绍 XHTTP
• 持有 REALITY NFT 可获得一个新的 Xray 客户端的早期内测资格，以及下一个 NFT 的空投，就像
• 2025.1.1 时持有 Project X NFT 将获赠两个 REALITY NFT

在大家的支持下，Project X NFT 已翻五六倍，对于 Project X NFT 首发时观望的朋友，这是一次弥补遗憾的好机会。

当然若你有余力，能支持个 Project X NFT 就更感谢了：

• ETH/USDT/USDC：0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT：Announcement of NFTs by Project X #3633
• REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
• 有时 ETH 的 gas 费高得离谱，你可以先点个 favorite，等 gas 费相对正常时再买

若还有哪里不清楚请在下方留言，我会更新文章，建议不要过早出翻译版。

[xcf13363175]

先顶再看

[zzlinwq]

先顶再看，不明觉厉

[iambabyninja]

中文 | Русский

XHTTP: За гранью REALITY

Краткое описание разработки: В середине 2024 года, @mmmray @ll11l1lIllIl1lll и другие, основываясь на принципе "раздельная пакетная отправка, потоковая загрузка" и деталях реализации, описанных @RPRX, разработали SplitHTTP, впервые добившись обхода большинства промежуточных устройств, поддерживающих HTTP, без ущерба для эффективности загрузки, и впервые массово реализовали QUIC H3 через CDN, открыв новую эру.

Впоследствии были реализованы: Broswer Dialer, добавление отступов в заголовки для уменьшения сигнатуры (header padding), управление мультиплексированием (XMUX) и разблокировка REALITY. Затем разработку взял на себя @RPRX, реализовав настоящее разделение исходящего и входящего трафика и переименовав проект в XHTTP. Например, исходящий и входящий трафик могут быть IPv6 CDN H3 и IPv4 REALITY H2 соответственно (даже исходные IP-адреса могут различаться), и вот снова началась новая эра. Далее был разработан потоковый режим отправки (stream-up), не жертвующий эффективностью исходящего трафика, схема extra, позволяющая делиться всеми деталями конфигурации, и добавлена маскировка заголовков gRPC по умолчанию для режима stream-up, что позволило реализовать потоковую отправку H2 через CDN, заменив традиционный транспортный уровень gRPC, если бы мы знали, что это возможно, то не стали бы его создавать. Наконец, транспортный уровень HTTP был включен в XHTTP как режим stream-one, получив также header padding, XMUX, маскировку заголовков gRPC и другие функции. Таким образом, мы получили полноценный XHTTP: обход промежуточных устройств различными способами, разделение исходящего и входящего трафика, XMUX и все остальное, что только можно пожелать. Наступила эра всеобщего господства XHTTP.

Эта статья призвана помочь вам полностью понять принцип и дизайн XHTTP, чтобы вы могли лучше его использовать.

Если вы хотите пожертвовать проекту Xray или собираете NFT, соответствующая информация находится в конце статьи, спасибо за поддержку!

Руководство по быстрому старту

Несмотря на большое количество параметров у XHTTP, для них уже настроены значения по умолчанию. Если вы просто хотите использовать XHTTP, достаточно выполнить шесть шагов:

1. Независимо от того, используется TLS или REALITY, обычно в конфигурации XHTTP достаточно указать только path, остальные параметры можно не заполнять.
2. Если сервер поддерживает QUIC H3, выберите "h3" в параметре alpn на клиенте, чтобы использовать QUIC.
3. Для приоритетного использования IP-адреса CDN на клиенте укажите IP-адрес в address и доменное имя в serverName (SNI).
4. Если не удается подключиться к CF, включите поддержку gRPC в панели управления CF.
5. Если не удается обойти Nginx, измените proxy_pass на grpc_pass в настройках Nginx.
6. Если не удается обойти другие CDN или обратные прокси-серверы, рекомендуется выбрать "packet-up" в параметре mode для наилучшей совместимости.

XHTTP по умолчанию использует мультиплексирование, что обеспечивает меньшую задержку по сравнению с Vision, но многопоточное тестирование скорости может показать худшие результаты, если не установить "maxConcurrency": 1 перед тестированием. Подробнее см. раздел XMUX.

Кроме того, в клиентах v2rayNG есть глобальная настройка mux.cool, которую следует отключить перед использованием XHTTP, иначе не удастся подключиться к серверу Xray новой версии.

Эту статью можно использовать как расширенную версию документации, поскольку она охватывает практически всё, что вы хотели бы знать о XHTTP, с объяснением каждого параметра. В конце статьи также приведен пример конфигурации, включающий все параметры с описанием сценариев их использования. Если вам неясен какой-либо параметр, найдите его название в тексте, чтобы найти подробное объяснение.

Два базовых принципа

Так же, как REALITY может маскироваться под чужой веб-сайт, основная идея противодействия цензуре заключается в увеличении "сопутствующего ущерба" для цензоров при блокировке, что делает их менее склонными к необдуманным действиям. По той же причине я в свое время сделал ставку на TLS и запутывание временных и длиновых характеристик трафика TLS. Многолетний опыт показывает, что GFW не будет постоянно блокировать весь пул IP-адресов крупного CDN, так как это затронет слишком много обычных сайтов. Таким образом, наша первоначальная цель для XHTTP заключалась в том, чтобы скрыть его за множеством различных CDN. Однако, чтобы предотвратить атаки на исходный сервер, CDN, за исключением специально поддерживаемых WS и gRPC, обычно кэшируют весь HTTP-запрос, прежде чем отправить его на исходный сервер. Многие промежуточные HTTP-устройства по умолчанию также работают таким образом. Исходя из этого, протокол Meek от Tor упаковывает исходящий и входящий трафик в отдельные HTTP-запросы для обхода этих промежуточных устройств, но скорость при этом крайне низка, поскольку он не использует "потоковую загрузку" XHTTP.
Что же такое "потоковая загрузка"? Представьте, что вы загружаете большой файл с веб-сайта, и CDN не находит его в кэше, поэтому обращается к исходному серверу. Но, очевидно, он не будет кэшировать весь файл, как при отправке, заставляя вас ждать. Вместо этого CDN немедленно пересылает вам данные по мере их поступления с исходного сервера. Это основа "потоковой загрузки" XHTTP, которая гарантирует максимальную скорость загрузки. Что касается отправки данных, то из соображений совместимости XHTTP сначала реализовал "пакетную отправку", которая упаковывает исходящий трафик в отдельные POST-запросы. Ее эффективность, очевидно, снижается, но, к счастью, для обычных прокси-потребностей объем исходящего трафика очень мал. Позже я добавил "потоковую отправку", и мы обнаружили, что с маскировкой заголовков gRPC можно реализовать потоковую отправку H2 через CF. После нескольких раундов оптимизации "пакетной отправки" ее скорость даже приблизилась к скорости "потоковой отправки".

Кстати, о недавно ставшей популярной теме "злоупотребления" CDN: очевидно, что CDN, не поддерживающие потоковую отправку, не предназначены для создания прокси-сервисов. Однако в борьбе с GFW мы считаем разумным и необходимым постоянно исследовать, разрабатывать и использовать как можно больше новых путей. Это вынужденная мера, и увеличение "сопутствующего ущерба" для цензоров требует от нас смешиваться с "нормальными" сервисами, что также неизбежно. Простейший пример: если в один прекрасный день будет введен белый список IP-адресов, и IP-адрес CDN окажется в нем, будете ли вы его использовать? В области антицензуры не действуют некоторые правила реального мира, но этот простой принцип почему-то многие не могут понять. Если вы все еще не понимаете, то такие транспортные уровни, как WebSocket, сейчас существуют только для обхода CDN. Как разработчик, вы можете удалить его, а как пользователь, вы можете предложить разработчику удалить его, чтобы своими действиями доказать, что "злоупотребление CDN" - это не просто очередной предлог для атаки на Xray, вызванный завистью и удовлетворением каких-то болезненных психологических потребностей, в то время как тело действует совершенно иначе. В то же время легко увидеть, что некоторая лицемерная сущность уже полностью раскрыта.

PACKET-UP

Этот раздел содержит много технических деталей. Обычные пользователи могут читать только выделенный текст.

Для режима packet-up в XHTTP, обеспечивающего наилучшую совместимость ("пакетная отправка, потоковая загрузка"), мы выбрали следующую схему:

1. Клиент отправляет POST /yourpath/sameUUID/seq для передачи исходящих данных:

   • UUID генерируется случайным образом и используется при запуске загрузки, чтобы сервер мог связать запросы. Если сервер не сможет связать запросы в течение 30 секунд, сеанс будет прерван.
   • seq начинается с 0. Следующий POST-запрос можно отправлять только после отправки тела предыдущего (но не нужно ждать ответа).
   • Несколько POST-запросов могут с небольшой вероятностью поступить на сервер в неправильном порядке. Сервер пересортирует их по seq, по умолчанию кэшируя до 30 запросов. При превышении лимита соединение разрывается.
   • Обратите внимание, что UUID и seq находятся в пути (path), а не в строке запроса (query string), чтобы избежать непредвиденных проблем.

2. Клиент запускает загрузку с помощью GET /yourpath/sameUUID. Заголовки ответа сервера содержат:

   • X-Accel-Buffering: no, чтобы сообщить промежуточному устройству отключить буферизацию.
   • Cache-Control: no-store, чтобы сообщить промежуточному устройству не кэшировать данные.
   • Content-Type: text/event-stream для маскировки под server-sent events (лучшая совместимость, можно отключить с помощью noSSEHeader).
   • Для HTTP/1.1 также необходимо включить Transfer-Encoding: chunked, для H2/H3 это не требуется.

3. Чтобы избежать проблем с междоменными ограничениями при использовании Browser Dialer, заголовки ответа сервера для всех GET и POST запросов содержат:

   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST

4. Для решения проблемы фиксированной длины заголовков HTTP-запросов и ответов:

   • Клиент по умолчанию добавляет ?x_padding=000... к пути (в строку запроса, чтобы предотвратить ненужные OPTIONS-запросы от Browser Dialer). Длина по умолчанию составляет 100-1000 символов, генерируется случайным образом для каждого запроса. Сервер по умолчанию проверяет, находится ли длина в допустимом диапазоне.
   • Заголовки ответа сервера по умолчанию содержат X-Padding: 000.... Длина по умолчанию составляет 100-1000 символов, генерируется случайным образом для каждого ответа.
   • Это и есть header padding, о котором я неоднократно упоминал, соответствующий параметр настройки - xPaddingBytes.

Пакетная отправка и ?x_padding=000... создают много длинных записей в журнале. Вы можете настроить обратный прокси-сервер так, чтобы он не регистрировал их.

Кроме того, как и другие транспортные уровни Xray, сервер принимает заголовок X-Forwarded-For для получения реального IP-адреса клиента и проверяет host, отправленный клиентом, на основе значения host, установленного на сервере (рекомендуется не устанавливать его без необходимости, так как он уже скрыт в пути).

Это упрощенный, необходимый процесс работы режима packet-up. Однако остается небольшой вопрос: как конкретно реализовать и ограничить POST-запросы? Для этого есть три специальных параметра:

• scMaxEachPostBytes: максимальный объем данных в каждом POST-запросе клиента. Значение по умолчанию - 1000000 (1 МБ). Это значение должно быть меньше максимального значения, разрешенного CDN и другими промежуточными HTTP-устройствами. Сервер также будет отклонять POST-запросы, превышающие этот размер.
• scMinPostsIntervalMs: только для клиента. Минимальный интервал между POST-запросами клиента для одного прокси-запроса. Значение по умолчанию - 30 миллисекунд.
• scMaxBufferedPosts: только для сервера. Максимальное количество POST-запросов, кэшируемых сервером для одного прокси-запроса. Значение по умолчанию - 30. При превышении лимита соединение разрывается.

"Для одного прокси-запроса" означает, что каждый прокси-запрос считается отдельно и не влияет на другие, даже если они находятся в одном H2/H3 соединении. Это и есть значение sc (sub-connection). Чтобы уменьшить сигнатуру, первые два значения можно задать в виде диапазона, например, "500000-1000000" и "10-50" соответственно, с случайным выбором значения в каждом запросе. Эти параметры можно передать клиенту через extra, как описано в конце статьи. Также стоит отметить, что в последней версии Xray был оптимизирован packet-up, и его скорость теперь почти достигает скорости stream-up, что особенно полезно для QUIC H3 через CDN.

H1 / H2 / H3

Теперь, когда у нас есть режим packet-up, способный обходить практически все промежуточные HTTP-устройства, давайте обсудим кое-что интересное: QUIC H3 через CDN, то есть ту самую новую эру, которую открыл SplitHTTP. Понимание этого раздела особенно важно для гибкого использования XHTTP.

Особенностью многих промежуточных HTTP-устройств, таких как CDN и Nginx, является преобразование версии HTTP. Например, они могут преобразовывать полученный H3-трафик в H1 или H2 при обращении к исходному серверу. Это означает, что наш XHTTP-сервер может прослушивать только H1 и H2, без необходимости прослушивания H3, в то время как клиент XHTTP может использовать H3.

Это также поведение XHTTP-сервера по умолчанию: прослушивание только TCP-порта и обработка трафика H1 и H2. При включении TLS и указании только одного элемента "h3" в alpn, сервер будет использовать quic-go для прослушивания UDP-порта и обработки H3-трафика, но в настоящее время это не рекомендуется. Вместо этого следует скрывать XHTTP за реальными Nginx или Caddy для уменьшения сигнатуры. Это одно из важных преимуществ XHTTP по сравнению с другими QUIC-прокси, другое, конечно же, это возможность работы через CDN. Кроме того, управление перегрузкой в H3 реализовано на уровне приложения, теоретически вы можете изменить алгоритмы управления перегрузкой QUIC в этих обратных прокси-серверах и скомпилировать их, чтобы добиться агрессивной отправки пакетов, которую некоторые так хотят.

Для клиента XHTTP:

1. При включении TLS/REALITY по умолчанию используется H2, в противном случае используется HTTP/1.1.
2. При включении TLS, если alpn содержит только "http/1.1", используется HTTP/1.1 (но Xray не позволит изменить маскировку отпечатка браузера uTLS).
3. При включении TLS, если alpn содержит только "h3", используется quic-go H3.
4. Однако при использовании Browser Dialer конкретная версия HTTP определяется браузером (весь tlsSettings игнорируется).

Если вам нужно узнать фактически используемую версию HTTP, host, а также режим XHTTP, разделение исходящего и входящего трафика и другую информацию на стороне клиента Xray, установите уровень логирования "info".

Проксирование QUIC H3 через CDN, по крайней мере, XHTTP был первым, кто реализовал это в массовом масштабе, открыв новый путь, поскольку в некоторых регионах и у некоторых провайдеров цензура H3 не так строга, хотя у некоторых она может привести к "Q-смерти". Даже после того, как мы разработали режим stream-up и обнаружили, что маскировка заголовков gRPC позволяет обходить CF, это работает только для H2, похоже, ценность этой новой эры продолжает расти.

XMUX

Поскольку мы упомянули H2 и H3, нельзя не упомянуть и их мультиплексирование: в обоих случаях это 0-RTT. Разница лишь в том, что у H3 нет проблемы блокировки заголовка TCP, которая есть у H2, и H3 поддерживает миграцию соединения, поэтому при смене сети на клиенте соединение не разрывается. Тогда те, кто часто изучает RFC, спросят: как конкретно управлять их мультиплексированием? Мы разработали простой и мощный интерфейс, называемый XMUX:

• maxConcurrency: максимальное количество одновременных прокси-запросов в каждом TCP/QUIC-соединении. Когда количество прокси-запросов в соединении достигает этого значения, ядро устанавливает новое соединение, чтобы вместить больше запросов. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра - "16-32", выбирается случайным образом.

• maxConnections: максимальное количество одновременных соединений. До достижения этого значения каждый новый прокси-запрос открывает новое соединение. После этого ядро начинает повторно использовать существующие соединения. Этот параметр конфликтует с maxConcurrency, можно использовать только один из них. Значение по умолчанию - 0, что означает отсутствие ограничений. Поддерживается указание диапазона, значение выбирается случайным образом.

• cMaxReuseTimes: максимальное количество раз, которое соединение может быть повторно использовано. После достижения этого значения соединение больше не будет использоваться для новых прокси-запросов и будет закрыто после завершения последнего прокси-запроса. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра - "64-128", выбирается случайным образом.

• cMaxLifetimeMs: максимальное время "жизни" соединения. После истечения этого времени соединение больше не будет использоваться для новых прокси-запросов и будет закрыто после завершения последнего прокси-запроса. Значение по умолчанию - 0, что означает отсутствие ограничений. Поддерживается указание диапазона, значение выбирается случайным образом.

• hMaxRequestTimes: @xqzr обнаружил, что Nginx по умолчанию допускает не более 1000 HTTP-запросов на одно TCP/QUIC-соединение. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра - "800-900", выбирается случайным образом, в противном случае значение по умолчанию - 0, что означает отсутствие ограничений. Этот параметр основан на подсчете HTTP-запросов. Обычно stream-one генерирует один HTTP-запрос, stream-up - два, а packet-up - N запросов. Подсчет не является строгим, и GET-запросы Golang имеют автоматический повтор, поэтому не рекомендуется указывать максимальное значение. Параметры для CDN и других провайдеров нужно определять экспериментально. В режиме packet-up, если количество POST-запросов превышает это значение, происходит автоматическое переключение на другое TCP/QUIC-соединение, которое занимает один reuseTimes, но не занимает concurrency. Фактически, с учетом трех параметров XMUX по умолчанию, stream-* не превысит лимит, только packet-up может его превысить, а это режим по умолчанию для H3, поэтому добавление этого параметра снова в основном выгодно для H3.

• hKeepAlivePeriod: интервал в секундах, через который клиент отправляет keep-alive пакеты, когда H2/H3 соединение простаивает. Значение по умолчанию - 0, что соответствует 45 секундам для Chrome H2 или 10 секундам для quic-go H3. Это единственный параметр в XMUX, который не допускает указание диапазона (случайный выбор создаст сигнатуру) и допускает отрицательные значения (например, -1 отключает keep-alive пакеты при простое). Рекомендуется оставить значение 0.

XMUX предоставляет параметры, которые можно комбинировать различными способами. Например, перед многопоточным тестированием скорости необходимо установить "maxConcurrency": 1, а для "неограниченного" повторного использования можно установить "maxConnections": 1. Даже если вы не хотите вникать в детали, при установке всех значений в 0 будут использоваться три значения по умолчанию, описанные выше, что равносильно периодической смене основного H2/H3 соединения, что обеспечивает плавную работу и предотвращает "прерывания" соединения, которые могут возникать при постоянном повторном использовании одного соединения для gRPC или HTTP. Эти параметры также можно передать клиенту через extra.

Примечание: отсутствие параметров эквивалентно установке всех значений в ноль, и будут использоваться три значения по умолчанию. Однако, если указан хотя бы один параметр, остальные параметры не будут иметь значений по умолчанию и должны быть указаны явно, за исключением первых двух параметров. Все остальные параметры можно указывать одновременно.

Кроме того, при использовании XHTTP не следует включать mux.cool, и новая версия сервера Xray проверяет это, принимая только чистый XUDP.

Некоторые выдержки о значениях по умолчанию для XMUX:

• Я специально выбрал два параметра, которые не слишком заметны вне TLS, а именно maxConcurrency и cMaxReuseTimes (а не maxConnections и cMaxLifetimeMs), и значения по умолчанию для этих параметров - это диапазон со случайным выбором, что максимально устраняет потенциальные сигнатуры.
• Я выбрал maxConcurrency вместо maxConnections, чтобы предотвратить появление фиксированного шаблона в количестве соединений, но если вам нравится второй вариант, вы можете установить его вручную.

• XMUX и Nginx считают разные объекты. maxConcurrency и cMaxReuseTimes основаны на подсчете "проксируемых соединений". Только stream-one генерирует один HTTP-запрос, stream-up - два (один для отправки, один для загрузки), а packet-up - N запросов.
• Однако я не уверен, что stream-one не будет генерировать дополнительные HTTP-запросы в некоторых случаях. Кроме того, я считаю, что стремление к максимальному повторному использованию одного соединения не имеет особого смысла, поскольку операторы связи также ограничивают скорость и очищают старые соединения, чтобы ресурсы не были полностью заняты старыми соединениями. Поэтому параметры XMUX по умолчанию ограничивают повторное использование и периодически меняют соединения.

Ниже в статье также обсуждаются некоторые параметры Nginx.

STREAM-UP/ONE

Наконец, мы добрались до другого важного режима XHTTP: stream-up ("потоковая отправка, потоковая загрузка"). Как следует из названия, в этом режиме отправка данных также потоковая, что не снижает ее эффективность. Изначально он был разработан для REALITY, пока мы не обнаружили, что с маскировкой заголовков gRPC под H2 можно обходить CF (необходимо включить поддержку gRPC в панели управления), и обратные прокси-серверы, такие как Nginx, также хорошо его поддерживают (для Nginx рекомендуется grpc_pass - просто и удобно). Поэтому поведение mode со значением по умолчанию "auto" следующее:

• Клиент: stream-up для TLS H2, stream-one для REALITY (stream-up при наличии downloadSettings), в остальных случаях packet-up.
• Сервер: по умолчанию принимает все три режима. Если задан конкретный режим, принимается только он. "stream-up" является исключением - он также принимает stream-one.

stream-up немного более совместим, чем stream-one. Некоторые пользователи сообщают, что CFT с включенной потоковой отправкой работает с stream-up, но требует включения дополнительной опции для работы со stream-one (возможно, проблема в маскировке под SSE?). Также замечено, что один CDN (забыл название) сильно ограничивает скорость stream-one, но не stream-up.

Способы их реализации (обычные пользователи могут пропустить):

• Для stream-up пакетная отправка в packet-up заменяется потоковой POST /yourpath/sameUUID. Также используется ?x_padding=000....
• Для stream-one используется POST /yourpath/. Ответ является загрузкой, двунаправленный поток. Заголовки запроса и ответа имеют header padding.
• Обратите внимание, что для stream-one, если указан /yourpath, фактический запрос отправляется на /yourpath/. Если / в конце отсутствует, он добавляется автоматически.
• По умолчанию для отправки данных используется Content-Type: application/grpc для маскировки под gRPC (можно отключить с помощью noGRPCHeader).
• Заголовки ответа сервера для загрузки аналогичны packet-up (пункт 1). В stream-one может возникнуть необычная ситуация, когда gRPC отвечает с SSE. Если возникнут проблемы, попробуйте noSSEHeader.

Тогда те, кто часто использует gRPC, спросят: какие преимущества у stream-up по сравнению с транспортным уровнем gRPC?

• Первому не нужны никакие библиотеки gRPC, производительность выше.
• Входящий трафик для первого - это отдельные GET-запросы, на него не распространяются ограничения CDN для gRPC-трафика.
• Первый также имеет header padding, XMUX, разделение исходящего и входящего трафика и другие улучшения. Кроме того, уже внедрен механизм extra, позволяющий делиться всеми параметрами, что делает его более зрелым.

Конечно, преимущества XHTTP по сравнению с WebSocket и HTTPUpgrade, помимо "отсутствия явной сигнатуры ALPN как http/1.1", вы, дочитав до этого места, уже наверняка поняли сами, поэтому я не буду их перечислять, в основном потому, что их слишком много.

Разделение исходящего и входящего трафика

И, наконец, кульминация - еще одна новая эра: разделение исходящего и входящего трафика. Мы знаем, что сейчас GFW обнаруживает такие характеристики трафика, как TLS in TLS, основываясь на одном соединении. Таким образом, если мы разделим исходящий и входящий трафик на разные системы проверки, например, исходящий трафик будет идти через IPv4 TCP, а входящий - через IPv6 UDP, GFW не сможет сразу среагировать. А поскольку сервер XHTTP связывает исходящий и входящий трафик только на основе случайно сгенерированного UUID в пути, packet-up и stream-up изначально обладают возможностью настоящего разделения трафика, и благодаря тому, что XHTTP может проходить через различные CDN и использоваться с REALITY, существует бесконечное количество вариантов. На клиенте необходимо настроить downloadSettings:

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // должно совпадать
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, только клиент
        "noSSEHeader": false, // только сервер
        "scMaxEachPostBytes": 1000000, // только packet-up
        "scMinPostsIntervalMs": 30, // packet-up, только клиент
        "scMaxBufferedPosts": 30, // packet-up, только сервер
        "xmux": { // в основном h2/h3, только клиент
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": "64-128",
            "cMaxLifetimeMs": 0,
            "hMaxRequestTimes": "800-900",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // только клиент
            "address": "", // другой домен/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // должно совпадать
                ...
            },
            "sockopt": {} // будет заменено на sockopt из upload, если находится в "extra"
        }
    }
}

Как видите, downloadSettings — это, по сути, новый набор streamSettings, но с добавлением address и port, аналогичных исходящим настройкам VLESS, для указания другого входа. Очевидно, что network должен быть "xhttp" (нельзя опускать), а security может быть "tls" или "reality". Если параметр sockopt отсутствует, он наследуется от исходящих настроек. Поскольку некоторые параметры sockopt действуют только локально и могут вызвать проблемы при передаче, если они находятся в extra (можно удалить), то они принудительно наследуются от исходящих настроек. За исключением этого случая, при разделении трафика настройки загрузки полностью независимы и не наследуют никаких настроек отправки. Более того, например, даже если XMUX не указан ни для отправки, ни для загрузки, и используются значения по умолчанию, конкретные значения, выбранные случайным образом из диапазона, будут независимыми друг от друга. Таким образом, со временем повторное использование исходящего и входящего трафика становится полностью асимметричным, моменты переключения основного соединения также различаются, что улучшает защиту от анализа. Если GFW захочет бороться с разделением трафика, "одинаковое время запуска основного соединения" определенно будет наиболее важной точкой входа, поэтому в будущем XHTTP позволит запускать исходящее и входящее соединения в разное время с самого начала.

Если вы используете CDN, вы можете управлять разделением трафика, даже не изменяя настройки сервера. Например, вы можете выбрать один IPv4 для TLS H2 и один IPv6 для QUIC H3. Большинство CDN поддерживают "префикс домена", например, serverName для отправки — "a.example.com", serverName для загрузки — "b.example.com", а host для обоих — "c.example.com", чтобы внешние SNI также выглядели по-разному. Конечно, еще лучше, если у вас есть два домена. Если у вас нет доменов, вы можете использовать два VPS и два REALITY для разделения трафика: будь то CDN с обратным прокси, или REALITY с fallback, главное, чтобы трафик в конечном итоге достигал одного и того же пути (path) на одном и том же VPS с одним и тем же входящим соединением XHTTP. В общем, поскольку XHTTP можно использовать везде и комбинировать как угодно, возможности безграничны, единственный вопрос — насколько богато ваше воображение.

Например, после появления разделения трафика многие используют его для разделения исходящего трафика по каналам с лучшим исходящим соединением, а входящего — по каналам с лучшим входящим соединением, что также весьма практично.

Выше приведен пример конфигурации, включающий все параметры, главным образом для того, чтобы показать, где должен быть указан каждый параметр, и объяснить параметры, которые не были подробно рассмотрены ранее:

• extra — это схема обмена исходными JSON-данными для всех параметров, кроме host, path и mode. Если extra существует, действуют только эти четыре параметра. Ссылка для обмена содержит только эти четыре параметра, как и большинство графических интерфейсов, поскольку параметры в extra используются относительно редко и должны предоставляться клиенту непосредственно издателем сервиса, а не изменяться клиентом произвольно. Дополнение: "предоставляться" означает, что издатель сервиса записывает extra и помещает его в ссылку для обмена, клиент использует его непосредственно как свой extra.

• host ведет себя так же, как и другие транспортные уровни Xray, основанные на HTTP. Приоритет отправки host на клиенте: host > serverName > address. Если на сервере задан host, он проверяет, совпадает ли значение, отправленное клиентом. В противном случае проверка не выполняется. Рекомендуется не устанавливать его без необходимости. host нельзя указывать в headers.

Если вам нужно узнать фактически используемую версию HTTP, host, а также режим XHTTP, разделение исходящего и входящего трафика и другую информацию на стороне клиента Xray, установите уровень логирования "info".

Beyond REALITY

В начале прошлого года я вернулся и написал всемогущий REALITY, решив сразу несколько проблем, а потом все время тусовался в ночных клубах и почти не занимался проектом, даже статью отложил до сих пор, еще более жаль XUDP UoT Migration, в прошлом году статья была почти готова, но так и не вышла. Незаметно REALITY стал основной технологией для прямого подключения. Часто можно увидеть комментарии под сообщениями о блокировке XX с рекомендацией перейти на REALITY, репутация говорит сама за себя, даже здесь стало не так оживленно, как раньше, из-за чрезмерной стабильности. Хотя Xray также внес множество оптимизаций и улучшений в другие транспортные протоколы, XHTTP - это первый нативный транспортный уровень Xray, сразу начал с чего-то грандиозного, и, прочитав эту статью, вы понимаете, что XHTTP можно использовать вместе с REALITY:

Beyond REALITY не означает замену REALITY, а означает превзойденную популярность. Без преувеличения, как это всегда бывает с Xray, появление XHTTP затмило все остальные транспортные уровни на основе HTTP. Это эра всеобщего господства XHTTP. Он станет более популярным, чем предыдущий успешный протокол REALITY, потому что характеристики XHTTP определяют более широкий охват.

Наконец, надеюсь, что появление XHTTP немного вас поразит, как это неоднократно бывало в истории Xray: инновации и постоянное обновление — это кредо Xray.

Если эта статья была вам полезна, поддержите REALITY NFT:

• Всего тысяча штук, первые сто продаются по цене 0.01 ETH, последующие будут дороже. Успеть купить из первой партии — это просто удача.
• Статья с описанием REALITY будет опубликована в ближайшие дни превратилась в статью о XHTTP.
• Владельцы REALITY NFT получат ранний доступ к бета-тестированию нового клиента Xray, а также airdrop следующего NFT, как и
• 1 января 2025 года владельцы Project X NFT получили два REALITY NFT.

Благодаря вашей поддержке, цена Project X NFT выросла в пять-шесть раз. Для тех, кто колебался при первоначальной продаже Project X NFT, это хороший шанс наверстать упущенное.

Конечно, мы будем еще более благодарны, если вы сможете поддержать Project X NFT:

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Анонс NFT от Project X #3633
• REALITY NFT: https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
• Иногда комиссия за газ в сети ETH бывает чрезмерно высокой, вы можете сначала добавить в избранное и купить, когда комиссия станет более приемлемой.

[RPRX]

原文有了一些更新

[zengzhengkevin]

顶

[hkfires]

学习中...

[fodhelper]

It's rumored that some CDNs are acting against using their services for proxy (not at a large scale yet)
maybe they had some agreements with governments

As someone who don't want to get banned by CDNs, i prefer WebSocket or gRPC w/o '/Tun', but not XHTTP with static URL Pattern and xPaddingBytes query string with many 0 data
And i had hope you add Xmux to gRPC, but instead you flagged it as deprecated

[fodhelper]

First, the response from the Cloudflare team is that their new firewall automatically blocked the Iranian IP, which was manually lifted, and they did not target the proxy.

You are very optimistic about them, but i believe it was the test phase of targeting proxies by the CF.

Second, WebSocket and gRPC do not prevent you from getting banned

What else is their problem except the static Early-Data header key of WebSocket and static '/Tun' path of gRPC? i am all ears

Countermeasures should be studied when the CDN starts to target agents, and there is no point in fighting in advance or excessively.

It's better to be prepare for SHTF, not to wait until shit happens and then start thinking about it and finding solutions
when it's possible to not have clear characteristics for CDN (or for GFW if user wanted to not use TLS), there is no reason not to

[RPRX]

我说提前对抗没有意义，是因为若 CDN 要封锁代理，无论你提前准备得多么精心，它都要基于你仍有的特征来封锁你，而这些特征是消除不完的，比如未加密时的代理协议头、加密时的全随机数、整体流量特征不正常等，同理过度对抗也是没有意义的。

[fodhelper]

@RPRX have you heard the news? isn't it time to act?

to hide proxy protocol headers VMESS exist, and for abnormal overall traffic characteristics split upload and download of XHTTP is there (Although i think removing obvious characteristics of transports is enough)
This options are needed to hide obvious characteristics of transports :

1. option to set custom Early-Data header key name for WebSocket
2. option to change XHTTP SessionId, Sequence Number and xPaddingBytes position to URL, Query-String or Headers (or even next to proxy protocol headers?)
   option to set a custom key name for each one of them
   option to change xPaddingBytes value from static numbers to full random data

[RPRX]

@fodhelper 现在仍为时过早，日后如果有证据/实验表明是这些因素触发了对账号的封禁，我们当然会引入规避措施

[fodhelper]

It's something like 'server: nginx' response header of nginx
but alright, let see if CDNs can detect proxies using this obvious characteristics or no

[namebuhtig]

笔记本上：嗯嗯嗯，好好好，嗯嗯嗯，好好好，嗯嗯嗯，好好好

[dcdebug]

Six,Six,Six...

[xqzr]

希望“无限”复用，可以将 maxConnections 设为 1。

尝试过 maxConnections: -1 其他 xmux 不配置，Nginx 1000 次复用（也可能是因为默认 cMaxReuseTimes: 64-128），用完并且旧连接还有子连接，新连接就“卡住”（开不了）
未配置任何 xmux，可见以下“错误”

2024/12/05 04:40:11 [Info] [3934265271] transport/internet/splithttp: failed to open https://s3.*.net:443/*/ > Post "https://s3.*.net:443/*/": H3_NO_ERROR: reached maximum number of requests

配置 xmux maxConnections: -1 时，也许也有，但没发现😇

https://t.me/projectXray/4100166?thread=4100095

[xqzr]

reload nginx 会“断流”，因为现有的”连接“不再允许创建”流“。但 *ray 似乎没有感知到，继续尝试创建”流“...
https://t.me/projectXray/4099760

[RPRX]

@xqzr 我已经写好了一个 cMaxRequestTimes，正在加”感知“，reload nginx 后客户端收到的是什么报错？

[xqzr]

reload nginx 后客户端收到的是什么报错？

“断流” 75 秒后，http3: parsing frame failed: timeout: no recent network activity
但似乎没有帮助...

2024/12/14 21:31:31 [Debug] [3059208966] proxy/socks: Not Socks request, try to parse as HTTP request
2024/12/14 21:31:31 [Info] [3059208966] proxy/http: request to Method [CONNECT] Host [cp.cloudflare.com:443] with URL [//cp.cloudflare.com:443]
2024/12/14 21:31:31 [Info] [3059208966] app/dispatcher: taking detour [s3-out] for [tcp:cp.cloudflare.com:443]
2024/12/14 21:31:31 [Info] [3059208966] transport/internet/splithttp: dialing splithttp to tcp:s3.*.net:443
2024/12/14 21:31:31 [Info] [3059208966] transport/internet/splithttp: XHTTP is using mode: stream-one
2024/12/14 21:31:31 [Info] [3059208966] proxy/vless/outbound: tunneling request to tcp:cp.cloudflare.com:443 via s3.*.net:443
2024/12/14 21:32:46 [Info] [3059208966] transport/internet/splithttp: failed to open https://s3.*.net:443/*/ > Post "https://s3.*.net:443/*/": http3: parsing frame failed: timeout: no recent network activity
2024/12/14 21:32:47 [Info] [3059208966] app/proxyman/inbound: connection ends > proxy/http: connection ends > context canceled

[xqzr]

读到这个 https://trac.nginx.org/nginx/ticket/2528 ，看来我需要 quic_bpf off;

[RPRX]

#4163 加了 hMaxRequestTimes 和 Abandon on non-200，@xqzr 你试试

[fireme1on]

奈何本人没文化，一句牛逼行天下🥰

[simplerick-simplefun]

建议文中优化下"extra"的说明：
一个月没追更新，完全不知道extra是干什么的，读完全篇还在考虑“服务器怎么下发extra部分的配置给客户端？”
然后又去找前面的release说明，读了一遍extra相关的文档 #4000 ，才搞明白extra是分享链接相关的配置。
可以把extra文档的链接放进正文，便于读者理解。

---

对于mode配置，也建议文中增加链接：#3994 #4071
同时在 #3994 文中中增加 stream-one。
修改：根据RPRX回复修改

---

如果正文没修改，读者对extra或mode有疑问，可以读这个回复里的链接

[RPRX]

其实这篇文章的宗旨就是尽量避免链接，一篇文章内说完，不然链接不完，而且我觉得 #4000 的有效信息也不多
话说文中 extra 整段加粗了，而且也提到了原始 JSON、分享链接，再结合 GUI 上看到的，应该没问题吧

[RPRX]

PR 主要是描述所提交的代码，所以不好改旧 PR 的说明，关于 mode 最新的是 #4071

[Smallthing]

    "mux": {                                                          
                "enabled": true,                                   
                "concurrency": -1,                                 
                "xudpConcurrency": 1,                              
                "xudpProxyUDP443": "reject"                        
               }    

这种配置算“关闭了mux.cool(我理解是tcp的mux)纯xudp”吗？如果不是最佳实践 应该是怎样
还是说现有版本中,只要xmux工作正常 xudp这些都不再需要再手工设置

[lxhao61]

我实际使用发现 mux 不开启，xmux 不配置（使用本链接文章中参数）连接最稳定。

[RPRX]

我实际使用发现 mux 不开启，xmux 不配置（使用本链接文章中参数）连接最稳定。

双层 mux 肯定不合适，准备在 XHTTP 服务端禁掉了，XMUX 选那些参数是有原因的，也准备在文章中说明

[sssagsag]

I found that the connection is most stable when mux is not enabled and xmux is not configured (using the parameters in this linked article).

The double-layer mux is definitely not suitable, and I plan to disable it on the XHTTP server. There are reasons for choosing those parameters in XMUX, and I plan to explain them in the article.

There are problems with using xhttp in the iOS operating system. I will give you an example. When mux is enabled in the web socket configurations, communication is established without any problems. However, in xhttp, the tunnel is disconnected every 5 minutes and memory problems occur. xmux does not help the situation. How can we find out if xmux is working properly?

[Smallthing]

今天一个小白问我XHTTP相关，我让他来看文档 ，讨论后感觉有几个表述不清的地方
1.XMUX这里，或者说很多地方 ，“填0”是否等于无此参数，因为在他的认知中 0 和 不存在是两个东西
2.那两个默认值是绑定的，XMUX 四项中若有任一项被手动填了，其它项就会默认全取 0 ------ 这句话我其实也没有很懂，这4项是互斥的吗，还是说，不填不启用，只要至少有一项就是启用。那么如果全默认应该填什么最标准。

[RPRX]

@Smallthing 文章已更新：

注：全不填也相当于全为零，会取到三个默认值，但若填了任一项，其它项就没有默认值了，全都要自己填，除前两项外其它项均可同时填。

[drsanwujiang]

Look good to all

[tomxiang1]

可否考虑在跑H3时，配置启用了cMaxLifetimeMs连接过期时间参数后，能把过期的主连接中的子连接迁移到新连接中，这样规避对UDP的Qos。

[RPRX]

这个问题回答过了 #3955 (comment) ，我感觉这特征挺明显的，类似于修改反代软件的 QUIC 拥塞控制以实现暴力发包

[tomxiang1]

还有其他好的方法规避UDP Qos吗？
在xhttp中配置多个CDN地址，或者多个目标主机地址，定时跳跃，迁移子连接，这样会不会特征不太明显。

[iopq]

Are there any other good ways to circumvent UDP Qos? Configuring multiple CDN addresses or multiple target host addresses in xhttp, jumping regularly, and migrating sub-connections will make the characteristics less obvious.

Why not just pretend it's TCP and exchange some handshakes and in reality deliver UDP payload? This is what udp2raw and phantun do

[tomxiang1]

Are there any other good ways to circumvent UDP Qos? Configuring multiple CDN addresses or multiple target host addresses in xhttp, jumping regularly, and migrating sub-connections will make the characteristics less obvious.

Why not just pretend it's TCP and exchange some handshakes and in reality deliver UDP payload? This is what udp2raw and phantun do

HTTP/3 based on QUIC is being supported by more and more websites and CDN, and should not return to TCP.

[MossAndMaurice]

尝试理解下我们XTLS旗下一系列协议的关注点和逻辑，如果错了请 @RPRX 指正。

XTLS初代splice/direct/origin等----解决性能：
传统的 TLS over TLS 会有两层加密开销，而 XTLS 则将内层 TLS 数据直接无损嵌入/拼接到外层的 TLS 流中，使得表面上仍是单层 TLS，但实际上隐藏了代理流量。减少重复的加解密过程。在不牺牲安全性的前提下显著降低了 CPU 负载和加解密成本，从而提升性能。

VISION----解决TLS in TLS特征：
在多层 TLS 叠加（TLS in TLS）时，内层 TLS 握手与外层 TLS 存在两次交互，这个时序存在明显特征，可被GFW精准识别。VISION 的意义在于通过模拟时延与消息交换顺序，抹平这种不自然的时序特征，让多层 TLS 握手过程在外观上更接近真实的互联网流量，降低被识别的风险。

REALITY----解决SNI封锁问题：
大陆的SNI无法加密，因此GFW可以通过SNI进行识别和封锁。
REALITY 在 TLS 握手和证书传递等环节进行伪装，通过在双方握手中返回看似真实网站的证书和初始数据，让整个 TLS 连接和访问“大厂”HTTPS 网站的连接真假难辨。GFW若想封锁，需要冒着误伤真实网站的风险。

XHTTP----解决翻墙协议普遍存在的“单一隧道”特征：
传统协议（如 Shadowsocks、Vmess、Trojan等）通常只是把数据加密后通过特定端口连续传输，从外观上可以呈现出“稳定长时间加密流”的特征；审查者可以通过统计分析、长连接特征、数据传输模式来怀疑它是代理流量。
因此XHTTP 此次聚焦在应用层，对已加密的传输进一步包装成真实 HTTP 请求和响应。通过将上行数据拆分为多个看似正常的 POST 请求和参数随机化的 URL，下行数据伪装为大文件流式下载或 SSE（Server-Sent Events）的持续输出，它使流量行为与普通用户浏览、下载的模式非常接近。与传统的“加密隧道”相比，XHTTP 不再是一个稳定持续的数据管道，而是表面上由多个独立、零散且自然的 HTTP 交互组成，更像再常见不过的WEB访问动作。

[tomxiang1]

REALITY还解决了服务器指纹问题，可引用大厂的服务器指纹，让GFW不敢轻易封锁。

[Ahmad-2213]

A specific question!
for those who are using Vless on workers/pages via WebSocket , is this possible to implement this protocol similarly on workers?
or cf just supports WebSocket?

[RPRX]

据说 stream-one 可能可以

[TheLordOfTheKings]

Hi @RPRX, is it possible to have Vision Seed with XHTTP+REALITY in future?

[RPRX]

这就是 Seed 的意义

[iamtrazy]

A proper english translated version of this article would be much appreciated.

[dukeduffff]

比如上下行分离问世后，很多人的用法其实是把上行分给上行优的线路、把下行分给下行优的线路，这样也挺实用的。

读到这里大受震撼

[zzlinwq]

XHTTP是不是一定要域名证书啊？ 如果要域名证书，大伙是用啥申请证书好？

[xqzr]

XHTTP是不是一定要域名证书啊？ 如果要域名证书，大伙是用啥申请证书好？

IP 证书也可以

[zzlinwq]

IP 证书是啥？用啥申请IP证书好？

[xqzr]

ZeroSSL

[RPRX]

我觉得这里的上行对于使用者来说叫做去程，下行叫回程这样更好理解。去程分给去程优的线路、把回程分给回程优的线路，这样也挺实用的。如果去程用V6优，就用V6；回程V4优，回程就用V4的线路

下一版改成“把上行分给去程优的线路”

[iopq]

Is it possible to split UDP and TCP connections? For example, I want UDP connections to go to a certain port, and TCP connections to go 443

[RPRX]

路由

[GreatMichaelLee]

老大厉害，但是参数多得的确让我这个用了reality一两年的用户眼花缭乱，能否整理几个使用场景的user case（比如套cdn的，不套cdn的，来回程合流的，来回程分流的）对每个场景给个C端和S端的配置模板，然后这个模板里建议用户哪些参数需要根据自己的服务器名称和ip进行自己配置调整，哪些建议用户不用自己配置，这样用起来的会有信心一点？作为还不算那么小白的用户，我现在upgrade到xhttp的最大的焦虑就是，我不知道改了或者配错了哪个参数，可能C/S两侧不一致就会导致不通，因为自己不知道怎么排查

[RPRX]

对于小白用户，文章开头的“快速上手指南”已经足够，基本上只要填个 path、alpn，而上下行分离复杂些不适合小白

[okfine9527]

[RPRX]

我感觉没 Seed 的话两者半斤八两，虽然有 Seed 的话也还是旗鼓相当

[RPRX]

不过上下行分离倒像是超越了当前版本的东西

[AmirReza2012]

Does XHTTP work with traditional fallbacks? If we want it to mimic a real website when using CDN what options do we have?

[freize]

Very interesting but completely incomprehensible.

[gcf1243690236]

有配置例子么

[clcc2019]

xhttp多线程测速延迟时tcp+reality的2倍，maxConcurrency=1

[xqzr]

@xqzr 你测试也存在这个问题吗

没有。但我认为，这符合预期

[RPRX]

@xqzr 这不符合预期，延迟本应是一样的，你测一下

[xqzr]

懒（
我不用 CF CDN。
maxConcurrency=1 我理解的是：经常要发起 TCP/QUIC 连接（不会复用现有连接），所以延迟相对来说“较高”

测试了多种xmux

愿闻其详

[RPRX]

@clcc2019 说的是延迟是 Vision 的两倍，这不对，而且我测的首次连接延迟正常，他不会是一个 CDN 一个直连吧

[zzlinwq]

xhttp多线程测速延迟时tcp+reality的2倍，maxConcurrency=1

测试了多种xmux，h2,h3都测试了，最后还是xtls-rprx-vision+raw+tls上传下载延迟最低

你这什么线路啊？延迟17ms? 哪里的服务器啊？有点夸张...... 稳定性如何？

[sixbyter]

这样做流量特征与互联网中的主流流量相差甚远，反而容易被识别？

[RPRX]

你是怎么得出这个结论的？packet-up 的 POST 包较多但都有 padding，上下行分离会表现出上行流量多，对应上传为主的业务

[solopasha]

Why every POST request returns 400 code? I have configs like in https://github.com/chika0801/Xray-examples/tree/main/VLESS-SplitHTTP-TLS (I also log $status) and the status is always 400 or 499 (everything works fine though). It only happens when alpn is h2(client), when it's h3, post returns 200.

[xqzr]

#4163 (comment)

[RPRX]

目前的代码，准确来说是 stream-up 的 POST 没被服务端即时返回，最后被打断就返回 4xx 了

[shuiliu11]

对这个"CDN 优选 IP 的话，客户端 address 填 IP， serverName（SNI）填域名即可"不理解，请教
1、我有一个免费域名，没有在VPS上配置网站，单纯的域名，在CLOUDFLARE上添加了DNS记录，如图，这个域名能直接用吗，还是必须像小小白文章中那样配置一个网站，申请一个证书？
2、如图"content"里面是添加记录后自动生成的IP，这个IP能填到address中吗？还是需要优选的IP（不论速度，单纯讲可行性），或者VPS的IP？
3、“proxy status”需要关闭吗？

[xiaoxiaomolimicha]

1、域名是给你绑定ip的，跟你有没有配置网站没有关系，能直接用
2、能填，填了就是直连
3、proxy status是cdn的开关
最后，你的基础太薄弱了，xhttp对你难度太高，不是你现在能接触的，建议你先巩固基础，要不然怎么看怎么解释你都理解不了

[MHSanaei]

中文 | Русский | English

XHTTP: Beyond REALITY

Development Overview:
Around mid-2024, building upon the “split upstream, streaming downstream” principles and implementation details described by @RPRX, @mmmray, @ll11l1lIllIl1lll and others developed SplitHTTP. For the first time, it achieved the ability to tunnel through most HTTP-supporting middleboxes without sacrificing downstream efficiency, while also pioneering large-scale QUIC H3 via CDN, ushering in a brand-new era. Subsequent support was added for features like Browser Dialer (browser-based forwarding), reduced fingerprint headers via padding, and controlling multiplexing via XMUX. REALITY unlocking was also put into the pipeline.

Afterwards, @RPRX took over development, achieving a true bidirectional split and renaming the project to XHTTP. With this innovation, the upstream and downstream connections can be totally independent—for example, upstream can be IPv6 CDN H3, while downstream can be IPv4 REALITY H2 (even using different source IPs)—once again heralding a new era. Following that, a streaming-up mode was developed, delivering upstream streaming efficiency without compromise. Additionally, the new extra configuration format made it possible to share all detailed configuration parameters. The streaming-up mode even introduced a default gRPC header disguise, enabling H2 streaming upstream through CDNs and replacing the traditional gRPC transport. “If only we had known this trick back then, the old solution wouldn’t have existed in the first place.” Finally, the standard HTTP transport layer became the stream-one mode within XHTTP, inheriting features such as header padding, XMUX, and gRPC header masking. At this point, we have a fully evolved XHTTP: it can tunnel through all kinds of middleboxes with various approaches, supports fully separated upstream and downstream, and offers smooth XMUX. The era of XHTTP dominating all scenarios has officially begun.

Originally, this was meant to be a “Director’s Cut” version of documentation, but it accidentally turned into a full-blown article. This article aims to help you thoroughly understand the principles and design of XHTTP so you can make better use of it.

If you wish to donate to the Xray project or collect NFTs, related information is at the end of the article. Thank you for your support!

Quick Start Guide

Don’t be intimidated by the many parameters of XHTTP. Most have sensible defaults. If you just want to use XHTTP, follow these six steps:

1. Whether using TLS or REALITY, generally you only need to set the path in the XHTTP configuration. Leave other parameters empty.
2. If the server supports QUIC H3, simply set alpn to "h3" on the client side to use QUIC.
3. When optimizing CDN IPs, set the client address to that IP and serverName (SNI) to the domain name.
4. If you can’t connect to Cloudflare (CF), enable gRPC support in the CF dashboard.
5. If you can’t penetrate Nginx, change proxy_pass to grpc_pass in your Nginx configuration.
6. If you can’t penetrate other CDNs or reverse proxies, try setting mode to "packet-up" for maximum compatibility.

XHTTP comes with multiplexing by default. Its latency is lower than Vision, but multi-threaded speed tests might be less favorable unless you set "maxConcurrency": 1 beforehand, as explained in the XMUX section.

Also, if you are using v2rayN or v2rayNG clients, they have a global mux.cool setting. Turn it off before using XHTTP, otherwise you won’t be able to connect to the new Xray server.

You can treat this article as an enhanced documentation. It covers basically everything you might want to know about XHTTP and explains every parameter in detail. At the end, there’s a configuration example covering all parameters and their usage scenarios. If you’re unsure about any parameter, just search for it in this article.

Two Fundamental Logics

Just like REALITY can masquerade as another website, the fundamental logic of anti-censorship is to increase the “collateral damage” that censors incur if they choose to block you, thereby deterring them from rash actions. My support for TLS and the timing/length obfuscation of TLS-based traffic back in the day shares the same rationale. Years of experience tell us that the GFW (Great Firewall) will not permanently block entire IP ranges of large CDNs, as that would affect too many regular websites. Thus, for XHTTP, our initial goal was to hide behind all sorts of CDNs. However, since most CDNs and other HTTP middleboxes (unless specially configured for WS or gRPC) tend to buffer the entire HTTP request before forwarding to the origin, tunneling data through them wasn’t straightforward.

Tor’s Meek protocol packages traffic into separate HTTP requests to penetrate these middleboxes, but the speed is painfully slow since it doesn’t adopt XHTTP’s “streaming downstream.” What is “streaming downstream”? Imagine you’re downloading a large file from a website. The CDN, missing a cache hit, must fetch from the origin. It obviously can’t buffer the entire file before sending it to you. Instead, as the origin sends data, the CDN streams it to you immediately. This property—realtime downstream streaming—is the foundation of XHTTP’s “streaming downstream” and guarantees maximum downstream speed. For upstream, to maintain compatibility, XHTTP first implemented “packet-based upstream,” splitting data into POST requests. This reduces efficiency but upstream traffic is typically minimal for common proxy usage. Later, I added “streaming upstream.” With a gRPC header disguise, it can even penetrate CF over H2. Moreover, after rounds of optimization, the speed of packet-up mode can come close to stream-up.

Regarding the debate on whether using CDNs in this manner constitutes “abuse”: obviously, a CDN that doesn’t support streaming upstream didn’t intend for you to set up a proxy this way. But we must keep exploring and employing as many methods as possible to combat censorship. We do this out of necessity. Increasing the censor’s “collateral damage” means mixing with “normal” services, which is inevitable. To put it simply: if one day an IP becomes whitelisted—and a CDN’s IP is inside that whitelist—would you use it or not? Anti-censorship doesn’t follow everyday rules; some people fail to understand this simple truth. If you still don’t get it, consider that transports like WebSocket now mainly exist to be tunneled through CDNs. If you believe this is abuse, as a developer you can remove it from the code; as a user you can request its removal. Take real action to prove that “abusing CDNs” isn’t just another excuse conjured up to attack Xray out of some twisted mindset.

PACKET-UP

This section is highly technical. Non-developers may focus only on the bold parts.

The most compatible mode for XHTTP—“packet-up” (packet-based upstream, streaming downstream)—is designed as follows:

1. The client sends POST /yourpath/sameUUID/seq to upload upstream data:

   • UUID is randomly generated. The downstream connection will later use the same UUID to associate with this upstream session. If the server doesn’t successfully associate within 30 seconds, the session ends.
   • seq starts from 0. You must finish sending the previous POST body (though not necessarily wait for a response) before starting the next.
   • Multiple POST requests might arrive out of order at the server. The server reassembles them by seq, caching up to 30 by default. Exceeding this limit triggers disconnection.
   • Note that UUID and seq are placed in the path rather than the query string to avoid strange issues.

2. The client initiates GET /yourpath/sameUUID for downstream data. The server’s response headers include:

   • X-Accel-Buffering: no instructs the middlebox to disable buffering.
   • Cache-Control: no-store informs the middlebox not to cache the content.
   • Content-Type: text/event-stream disguises the content as server-sent events (SSE) for better compatibility. You can disable this by setting noSSEHeader.
   • For HTTP/1.1, Transfer-Encoding: chunked is added. This is not needed for H2/H3.

3. To avoid cross-origin issues with Browser Dialer (browser-based forwarding), the server adds these headers to all GET and POST responses:

   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Methods: GET, POST

4. To mitigate fixed-length signatures in HTTP request and response headers:

   • The client’s paths include ?x_padding=000... by default (query strings used to avoid unnecessary OPTIONS requests from Browser Dialer). The length ranges from 100 to 1000 bytes, randomized each request. The server checks if it falls within an allowable range.
   • The server’s response headers always include X-Padding: 000..., also randomized between 100 and 1000 bytes per response.
   • This is the so-called header padding, controlled by xPaddingBytes.

Packet-up and ?x_padding=000... may generate lengthy logs. You can configure your reverse proxy not to log them.

Like other Xray transports, the server accepts X-Forwarded-For headers to obtain the client’s real IP, and it will validate the host header if configured (it’s recommended not to configure host unless necessary, as the path already provides sufficient hiding).

That’s the simplified and essential packet-up flow. However, we still need to restrict or define the POST requests, which is achieved by three special parameters:

• scMaxEachPostBytes: Maximum payload per POST request on the client side, default 1MB. This should be less than the maximum allowed by CDN/middlebox. The server also rejects POST bodies larger than this.
• scMinPostsIntervalMs: Client-only. The minimum interval between POST requests per proxy session, default 30ms.
• scMaxBufferedPosts: Server-only. Maximum number of buffered POST requests per proxy session, default 30. Exceeding this disconnects the session.

“Per proxy session” means these limits count separately for each proxied connection, even if they share the same H2/H3 connection. That’s what ‘sc’ (sub-connection) means. To reduce fingerprints, you can set ranges like "500000-1000000" or "10-50" so it picks a random value within that range each time. These parameters can be distributed via extra to the client. The full config example at the end shows how. Also, thanks to recent optimizations, packet-up speed nearly matches stream-up, especially beneficial for QUIC H3 over CDN scenarios.

H1 / H2 / H3

With packet-up mode allowing tunneling through almost any HTTP middlebox, let’s discuss a fascinating aspect: QUIC H3 via CDN. Understanding this is crucial for mastering XHTTP.

Many HTTP middleboxes convert HTTP versions—e.g., a CDN or Nginx might receive H3 and convert it to H1 or H2 when forwarding to the origin. This means our XHTTP server can just listen for H1 and H2 traffic without directly handling H3. Yet the XHTTP client can still use H3!

This is the default behavior: the XHTTP server, by default, only listens on a TCP port and handles H1 and H2. When you enable TLS and set alpn to only "h3," the server uses quic-go to listen on a UDP port and handle H3. Currently, this isn’t recommended. Instead, place XHTTP behind a real Nginx or Caddy to reduce fingerprints. That’s one of XHTTP’s advantages over other QUIC proxies, and of course, there’s the CDN compatibility. H3 congestion control is implemented at the application layer; theoretically, you could tweak your reverse proxy’s QUIC congestion algorithm—if you’re into that.

For the XHTTP client:

1. If TLS/REALITY is enabled, it uses H2 by default; otherwise, it uses HTTP/1.1.
2. If TLS is enabled and alpn is "http/1.1" only, it uses HTTP/1.1 (Xray won’t allow altering uTLS browser fingerprints though).
3. If TLS is enabled and alpn is "h3" only, it uses quic-go H3.
4. If using Browser Dialer, the browser decides the HTTP version (thus tlsSettings is ignored).

If you want to verify the actual HTTP version, host, mode, upstream/downstream separation, etc., just set the log level to "info."

We were the first to implement widespread proxying of QUIC H3 over CDN—SplitHTTP era opened a new path. Even after discovering that stream-up plus gRPC headers can penetrate CF over H2, this doesn’t diminish the pioneering value of H3 over CDN. Different regions and ISPs may treat H3 differently. If some become lenient, you win; if others block it, well, at least you have options.

XMUX

Since we mentioned H2 and H3, we must talk about their multiplexing: both are 0-RTT. H3 avoids TCP head-of-line blocking and supports connection migration, so changing client networks doesn’t break the connection. XMUX is a simple but powerful interface designed to control and enhance multiplexing.

• maxConcurrency: Maximum concurrent proxied sessions per TCP/QUIC connection. Once a connection hits this limit, core opens a new connection to handle more sessions. If all XMUX parameters are zero, this defaults to "16-32" randomly.
• maxConnections: Maximum simultaneous connections. Until this limit is reached, each new proxy request opens a new connection. After that, core starts reusing existing connections. This conflicts with maxConcurrency; choose one or the other. Default is 0 (no limit), can be a range.
• cMaxReuseTimes: Each connection’s max reuse count. After reaching this count, no new proxy requests are assigned to it. Once all existing sessions inside it close, the connection ends. If all XMUX values are zero, this defaults to "64-128" randomly.
• cMaxLifetimeMs: Maximum lifetime of a connection in milliseconds. After this time, no new requests are assigned. When the existing sessions close, the connection ends. Default 0 (no limit), supports ranges.
• hMaxRequestTimes: As discovered by @xqzr, Nginx often limits each TCP/QUIC connection to about 1000 total HTTP requests. If all XMUX values are zero, this defaults to "800-900" randomly; otherwise, default is 0 (no limit). This counts HTTP requests. Generally, stream-one uses one HTTP request, stream-up uses two (one for upstream and one for downstream), packet-up uses multiple. If this limit is exceeded, packet-up mode automatically switches to another TCP/QUIC connection, using up one reuseTimes but not concurrency. We introduced this primarily for H3.
• hKeepAlivePeriod: For H2/H3 connections, how often does the client send a keep-alive packet during idle times? Default 0, meaning Chrome’s default of 45s for H2 or quic-go’s 10s for H3. Don’t randomize this (it would be a fingerprint). You can set it to -1 to disable keep-alives. Suggest leaving it at 0.

With XMUX parameters, you can craft various scenarios. For instance, to improve latency in multi-threaded speed tests, set "maxConcurrency" : 1. For “infinite” reuse, set "maxConnections" : 1. If you don’t care and leave them all at 0, you get the default behavior mentioned above, which periodically rotates to a new H2/H3 main connection, resulting in smoother performance than gRPC or simple HTTP transports that stick to one connection forever.

Do not enable mux.cool when using XHTTP. The new Xray server checks this and only allows pure XUDP.

A note on defaults:

• I chose maxConcurrency and cMaxReuseTimes as defaults because they’re less externally visible and both pick random values from a range, reducing potential fingerprints.
• I didn’t choose maxConnections because a fixed connection count might become a signature. If you prefer it, you can set it manually.

In summary, XMUX offers flexible multiplexing controls. If you don’t specify anything, you get a balanced default. Otherwise, configure as needed. These parameters can also be distributed to clients via extra.

STREAM-UP/ONE

Now we get to another key feature: the “streaming upstream, streaming downstream” mode, called stream-up. As the name suggests, it also streams upstream data, achieving high upstream efficiency. Initially developed for REALITY, we discovered that adding a gRPC header disguise allows it to penetrate CF over H2. Nginx and other proxies also support it well (Nginx recommends grpc_pass), so when mode defaults to "auto," the behavior is:

• Client: If TLS H2 is enabled, use stream-up. If REALITY is enabled, use stream-one (if downloadSettings is present, also stream-up). Otherwise, use packet-up.
• Server: By default, accepts all three modes. If set to a specific mode, only that mode is accepted. Exception: specifying "stream-up" also accepts stream-one.

Some have reported that with CFT enabled, they can use stream-up, but an extra step is needed to use stream-one. Another CDN (forgot which) heavily throttles stream-one but not stream-up.

Implementations (for developers):

• For stream-up: Replace packet-up’s multiple POSTs with a single POST /yourpath/sameUUID (still includes ?x_padding=000...).
• For stream-one: POST /yourpath/ and get a downstream response in the same request. Bi-directional streaming in a single request. Request and response headers both have padding.
• Upstream is always disguised with Content-Type: application/grpc by default (set noGRPCHeader to disable).
• Downstream headers match packet-up except for the request/response differences. Stream-one might yield scenarios like SSE responses to gRPC requests; if issues arise, try noSSEHeader.

Comparing stream-up with gRPC transport:

• No gRPC libraries needed, better performance.
• Downstream is a separate GET request, no CDN traffic limit on gRPC applies.
• Has features like header padding, XMUX, upstream/downstream separation, and extra configuration sharing. It’s more mature.

XHTTP’s advantages over WebSocket or HTTPUpgrade transports are numerous—no visible ALPN: http/1.1 signature and much more. By now, you’ve likely formed your own opinion.

Upstream-Downstream Separation

The grand finale: true upstream-downstream separation. Currently, GFW detection of TLS-in-TLS and other patterns focuses on a single connection. If we separate upstream and downstream into distinct paths—e.g., upstream over IPv4 TCP and downstream over IPv6 UDP—the GFW might be thrown off. Because XHTTP’s packet-up and stream-up modes were born with separate upstream and downstream channels associated via a UUID, they naturally enable genuine separation.

On the client side, you set downloadSettings:

"xhttpSettings": {
    "host": "example.com",
    "path": "/yourpath", // must be the same
    "mode": "auto",
    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, client only
        "noSSEHeader": false, // server only
        "scMaxEachPostBytes": 1000000, // packet-up only
        "scMinPostsIntervalMs": 30, // packet-up, client only
        "scMaxBufferedPosts": 30, // packet-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": "64-128",
            "cMaxLifetimeMs": 0,
            "hMaxRequestTimes": "800-900",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // client only
            "address": "", // another domain/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // must be the same
                ...
            },
            "sockopt": {} // will be replaced by upload's when in "extra"
        }
    }
}

downloadSettings is essentially a separate streamSettings block. It includes address and port to point to another endpoint. network must be "xhttp," and security can be "tls" or "reality." If sockopt is missing, it inherits from the upstream’s sockopt. If sockopt is inside extra, it forcibly inherits from upstream. Apart from this special case, upstream and downstream configurations are independent.

Because XHTTP can pass through CDNs, you might not need to change the server configuration at all to experiment with upstream-downstream separation. For instance, choose an IPv4 route (TLS H2) for upstream, and IPv6 route (QUIC H3) for downstream. CDNs usually support “domain fronting,” so upstream serverName could be "a.example.com", downstream serverName could be "b.example.com", while both use host = "c.example.com". This results in external SNI looking different from the internal host—perfect for confusion. If you have multiple domains or even two separate VPS setups with REALITY, you can do all kinds of routing tricks. The possibilities are endless, limited only by your imagination.

Some people use upstream-downstream separation to pick upstream routes that are better for outbound traffic and downstream routes that are better for inbound traffic. It’s quite practical.

The example above includes all parameters to show where to place each. extra is a raw JSON sharing scheme for parameters other than host, path, mode, and downloadSettings. These four items can appear in the share link or GUI because they are frequently changed, while extra parameters are not. Typically, the server provider supplies extra parameters directly.

host behaves like in other Xray HTTP-based transports. On the client side, host priority is host > serverName > address. If host is set on the server side, it checks that the client’s host matches. Otherwise, it doesn’t. It’s recommended not to set a host on the server side unless necessary. Do not put host in headers.

If you want to confirm what HTTP version, host, XHTTP mode, or upstream-downstream separation the client ends up using, set logs to "info."

Beyond REALITY

Last year, I returned and introduced REALITY, which solved multiple pain points in one go, and it quickly became a stable staple. People often recommend REALITY when other solutions are blocked. Meanwhile, Xray has continuously improved and optimized other transports too. But XHTTP is the first natively integrated Xray transport—and it starts off big. After reading this article, you know that XHTTP and REALITY can work together.

“Beyond REALITY” doesn’t mean to replace REALITY but to surpass its reach. As is always the style of Xray, XHTTP’s appearance leaves all other HTTP-based transports in the dust. It offers a comprehensive solution to all scenarios. It will likely become even more popular than REALITY, as its features inherently appeal to a broader range of use cases.

Finally, I hope the advent of XHTTP brings a small shock and awe, just as Xray has repeatedly done before: innovation and progress are always at the heart of Xray’s faith.

If you found this article helpful, please consider supporting by collecting a REALITY NFT:

• A total of 1000 NFTs, first 100 sold at 0.01 ETH. Later ones will be more expensive. Getting in first is a bargain.
• An article on REALITY will be released in the coming days turned into one introducing XHTTP.
• Holders of REALITY NFT gain early beta access to a new Xray client and will receive airdrops of the next NFT, similar to how…
• On 2025.1.1, holders of Project X NFT will get two REALITY NFTs.

With everyone’s support, the Project X NFT has already multiplied five to six times. If you missed out on Project X NFT’s initial offering, this is your chance to make up for it.

If you can, please also consider supporting the Project X NFT:

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Announcement of NFTs by Project X #3633
• REALITY NFT: [OpenSea link above]
• Sometimes ETH gas fees are ridiculously high. You can favorite it and wait until gas fees are normal to buy.

If anything remains unclear, leave a comment below. I will update this article. It’s suggested not to release translations too early.

[MHSanaei]

translate it with ChatGPT o1