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 选那些参数是有原因的，也准备在文章中说明

[arian9999]

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。

[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.

[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

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

I just tried it and upon switching on h3 with XHTTP/TLS I got blocked after a few minutes of using it

h2 just works, but that means I'm using UDP inside TCP as far as I understand

[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

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

I just tried it and upon switching on h3 with XHTTP/TLS I got blocked after a few minutes of using it

h2 just works, but that means I'm using UDP inside TCP as far as I understand

worked today, so I don't know what happened before

[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不敢轻易封锁。

[yuhan6665]

因为 GFW 若要对上下行分离动手，“主连接发起的时间点相同”肯定是最重要的切入点

这个想法有点意思 那么是否可以说 UDP（H3）抓不到连接头 所以理论上更安全？

[RPRX]

倒是可以先让前几个包走另一个代理，不过 GFW 抓不到连接头的话可以记录 QUIC CID 第一次出现的时间

[supechicken]

上下行分離的部分能在xtls之類的現有協議啟用嗎？（還是說是xhttp獨有的）

[RPRX]

目前是 XHTTP 独有的

[supechicken]

好的感謝，那之後有下放到xtls的計畫嗎？這樣的話xtls的反偵查能力應該能再增強

[RPRX]

@supechicken XTLS 裸奔+上下行分离这种暂无计划，不过确实挺有趣的 @yuhan6665

[simplerick-simplefun]

"maxConnections：该值与 maxConcurrency 冲突，只能二选一。默认值 0，即不限制，支持填写范围，每次随机。"
请问，如果客户端和服务端都填写了maxConnections/maxConcurrency，并且客户端和服务端的值互相冲突，会怎么处理？
例如，服务端填写maxConnections=1，客户端填写maxConcurrency=1

[xqzr]

xmux 参数在服务端，不起作用

[gcf1243690236]

为啥感觉xhttp 有时候连不上了 是tcp断了么

[gcf1243690236]

报Remote host closed connection during handshake

[nouman8]

does anyone know how to make h3 mode work on cloudfront cdn ?

[xqzr]

packet-up

[nouman8]

packet-up works with h3 on cloudflare but not on h3 cloudfront for me, maybe some headers need to be added to the distribution ? in the nginx log i get status code 400 when cloudfront sends request

[nouman8]

only h2 stream-one mode is working on cloudfront for me

[alphax-hue3682]

Hi
Can someone please share the latest and most updated xhttp extra json Raw configuration?!

[crzidea]

Have you any benchmark for traffic load? How much throughput can you achieve with Cloudflare? Under the same baseline conditions, how does the speed compare to other solutions?

[kevinamiri]

XHTTP: Beyond REALITY

Development Overview:
In mid-2024, developers like @mmmray and @ll11l1lIllIl1lll, building on the "packetized upstream, streaming downstream" principles outlined by @RPRX, introduced SplitHTTP. This innovation allowed for efficient penetration of most HTTP-supporting middleboxes without sacrificing downstream performance. It also marked the first large-scale implementation of QUIC H3 over CDN, opening a new chapter in proxy technology. Features like Browser Dialer support, header padding to reduce traffic fingerprints, XMUX for multiplexing control, and REALITY integration were added soon after.

Later, @RPRX took over development, achieving true upstream and downstream separation and renaming the protocol to XHTTP. This allowed upstream and downstream traffic to use entirely different configurations, such as IPv6 CDN H3 for upstream and IPv4 REALITY H2 for downstream, even with different source IPs. This innovation marked another leap forward.

Subsequent developments included the stream-up mode, which improved upstream efficiency, and the extra configuration scheme, enabling users to share detailed settings. The stream-up mode was further enhanced with gRPC header camouflage, enabling H2 streaming upstream through CDNs, effectively replacing traditional gRPC transport layers. Finally, the HTTP transport layer was integrated into XHTTP as stream-one mode, inheriting features like header padding, XMUX, and gRPC header camouflage.

With these advancements, XHTTP became a complete solution: capable of bypassing middleboxes in various ways, supporting upstream and downstream separation, and offering smooth multiplexing. The era of XHTTP as a universal, all-scenario proxy solution had officially begun.

---

Quick Start Guide

Although XHTTP offers many configuration options, its default settings are optimized for most use cases. To get started, follow these six steps:

1. For both TLS and REALITY, you generally only need to configure the path. Leave other fields blank.
2. If the server supports QUIC H3, set the client’s alpn to "h3" to enable QUIC.
3. For optimized CDN IPs, set the client’s address to the IP and serverName (SNI) to the domain name.
4. If you cannot connect to Cloudflare (CF), enable gRPC support in the CF panel.
5. If Nginx blocks the connection, change proxy_pass to grpc_pass in the Nginx configuration.
6. If other CDNs or reverse proxies block the connection, set the mode to "packet-up" for maximum compatibility.

By default, XHTTP supports multiplexing (XMUX), which reduces latency compared to Vision. However, multi-threaded speed tests may show lower performance unless you set "maxConcurrency": 1 before testing. Refer to the XMUX section for details.

Additionally, if you are using the v2rayN&G client, disable the global mux.cool setting before using XHTTP. Otherwise, it may fail to connect to the latest Xray server.

This article serves as an enhanced guide, covering everything you need to know about XHTTP. It explains each parameter in detail and includes a comprehensive configuration example at the end, with usage scenarios for each parameter. If you are unsure about a parameter, search for its name in this document to find a detailed explanation.

---

Core Principles

The fundamental logic of anti-censorship technologies like XHTTP is to increase the "collateral damage" for censors when implementing blocks. This makes them hesitant to block traffic indiscriminately. For example, REALITY disguises proxy traffic as legitimate website connections, forcing censors to risk blocking real websites if they attempt to block the proxy.

Similarly, XHTTP leverages the fact that the Great Firewall (GFW) is unlikely to permanently block the entire IP range of a major CDN, as doing so would disrupt too many legitimate websites. The goal of XHTTP is to blend proxy traffic into the vast pool of normal CDN traffic.

However, CDNs are designed to protect origin servers from attacks. Unless specifically configured (e.g., for WebSocket or gRPC), most CDNs cache the entire HTTP request before forwarding it to the origin server. Many HTTP middleboxes behave similarly.

Protocols like Tor’s Meek wrap traffic into discrete HTTP requests to bypass these middleboxes, but this approach sacrifices speed. Meek lacks XHTTP’s "streaming downstream" capability, which ensures high downstream performance.

What is "Streaming Downstream"?

Imagine downloading a large file from a website. If the CDN doesn’t have the file cached, it fetches it from the origin server. Instead of waiting to cache the entire file, the CDN forwards the data to you as it receives it. This real-time forwarding is the foundation of XHTTP’s streaming downstream, ensuring maximum downstream speed.

What about Upstream?

For compatibility, XHTTP initially implemented "packetized upstream", which splits upstream traffic into discrete POST requests. While this approach is less efficient, upstream traffic is typically minimal for most proxy use cases.

Later, streaming upstream was introduced, allowing real-time upstream data transfer. By adding gRPC header camouflage, XHTTP enabled H2 streaming upstream through Cloudflare (CF). After several optimizations, the speed of packetized upstream now rivals that of streaming upstream.

---

PACKET-UP Mode

Packet-up mode is XHTTP’s most compatible configuration, combining packetized upstream with streaming downstream. Here’s how it works:

Upstream (Client to Server):

1. The client sends upstream data via POST /yourpath/sameUUID/seq:
   • UUID is randomly generated and reused for downstream traffic to associate the session. If the server cannot associate the session within 30 seconds, it terminates the connection.
   • seq starts at 0. The client must finish sending the body of one POST before starting the next (though it doesn’t need to wait for a response).
   • Multiple POSTs may arrive out of order. The server reassembles them based on seq, caching up to 30 requests by default. If the limit is exceeded, the connection is terminated.
   • Both UUID and seq are included in the path (not the query string) to avoid compatibility issues.

Downstream (Server to Client):

2. The client starts downstream by sending GET /yourpath/sameUUID. The server responds with:
   • X-Accel-Buffering: no to disable buffering by middleboxes.
   • Cache-Control: no-store to prevent caching by middleboxes.
   • Content-Type: text/event-stream to disguise the response as server-sent events (SSE). This improves compatibility but can be disabled with the noSSEHeader setting.
   • For HTTP/1.1, the response includes Transfer-Encoding: chunked. This is unnecessary for H2/H3.

Cross-Origin Compatibility:

To avoid cross-origin restrictions when using Browser Dialer, the server includes the following headers in all GET and POST responses:

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

Header Padding:

To address the fixed-length characteristics of HTTP headers:

• The client appends ?x_padding=000... to the path. The padding length is randomized (100–1000 characters by default) for each request.
• The server includes a X-Padding: 000... header in its responses, with randomized padding of similar length.

---

Key Parameters for Packet-Up Mode

1. scMaxEachPostBytes:

   • Maximum data per POST request (default: 1MB). This should be less than the maximum allowed by the CDN or middlebox.

2. scMinPostsIntervalMs:

   • Minimum interval between POST requests (default: 30ms).

3. scMaxBufferedPosts:

   • Maximum number of POST requests the server can buffer (default: 30).

These parameters can be randomized to reduce traffic fingerprints. For example, scMaxEachPostBytes can be set as "500000-1000000", and scMinPostsIntervalMs as "10-50".

---

H1 / H2 / H3

Now that we have the packet-up mode, which can penetrate almost all HTTP middleboxes, let's discuss something interesting: QUIC H3 over CDN, the new era that SplitHTTP initially ushered in. Understanding this section is crucial for using XHTTP effectively.

A characteristic of many HTTP middleboxes is that they perform HTTP version conversion. For example, CDNs and Nginx may convert incoming H3 traffic to H1 or H2 traffic when forwarding to the origin. This means our XHTTP server can listen only for H1 and H2, without needing to listen for H3, but the XHTTP client can still use H3.

This is also the default behavior of the XHTTP server: it listens only on TCP ports and handles H1 and H2 traffic. When TLS is enabled and only one element, "h3", is set in alpn, the server will only use quic-go to listen on UDP ports and handle H3 traffic. However, it is currently not recommended to do this. Instead, you should hide XHTTP behind a real Nginx or Caddy to reduce fingerprint characteristics. This is one of the important advantages of XHTTP compared to other QUIC-based proxies. Another advantage, of course, is the ability to go through CDNs. In addition, H3's congestion control is implemented at the application layer. In theory, you can modify the QUIC congestion control algorithm of these reverse proxy software and compile them to achieve the aggressive packet sending that some people want.

For the XHTTP client:

• When TLS/REALITY is enabled, H2 is used by default; otherwise, HTTP/1.1 is used.
• When TLS is enabled, if alpn only has "http/1.1", then HTTP/1.1 is used (but Xray will not allow it to modify the uTLS browser fingerprint camouflage).
• When TLS is enabled, if alpn only has "h3", then quic-go H3 is used.
• However, when you use Browser Dialer, the specific HTTP version is determined by the browser (the entire tlsSettings will be invalid).

If you want to confirm the HTTP version, host, XHTTP mode, upstream and downstream separation, and other information actually used by the Xray client, set the log level to "info".

At least for large-scale implementation of proxying QUIC H3 over CDN, XHTTP is the first. It opened a new path, as some regions and operators do not strictly censor H3, although some may block it. Even though we later developed the stream-up mode and found that adding gRPC header camouflage can penetrate Cloudflare (CF), it only works for H2. It seems that the value of this new era is still rising.

XMUX

Since we mentioned H2 and H3, we have to talk about their multiplexing: both are 0-RTT. The difference is that H3 does not have the TCP head-of-line blocking problem of H2, and it supports connection migration, so the client will not disconnect when switching networks. Those who often read RFCs may ask: how to specifically control their multiplexing? We designed a concise and powerful interface, XMUX:

• maxConcurrency: The maximum number of proxy requests that can exist simultaneously in each TCP/QUIC connection. When the number of proxy requests in a connection reaches this value, the core will establish a new connection to accommodate more proxy requests. When all XMUX values are 0, this item defaults to "16-32", randomized each time.
• maxConnections: The maximum number of connections that can exist simultaneously. Before the number of connections reaches this value, each new proxy request will open a new connection. After that, the core will start to reuse existing connections. This value conflicts with maxConcurrency and only one can be chosen. The default value is 0, which means no limit. It supports filling in a range, randomized each time.
• cMaxReuseTimes: The maximum number of times a connection can be reused. After being reused this many times, it will not be assigned new proxy requests and will be disconnected after the last internal proxy request is closed. When all XMUX values are 0, this item defaults to "64-128", randomized each time.
• cMaxLifetimeMs: The maximum "lifespan" of a connection. After this time, it will not be assigned new proxy requests and will be disconnected after the last internal proxy request is closed. The default value is 0, which means no limit. It supports filling in a range, randomized each time.
• hMaxRequestTimes: @xqzr found that Nginx by default allows each TCP/QUIC connection to carry a total of 1000 HTTP requests. When all XMUX values are 0, this item defaults to a random value between "800-900"; otherwise, it defaults to 0, which means no limit. This item is based on HTTP request counting. Generally, stream-one generates only one HTTP request, stream-up generates two, and packet-up generates N. This item's counting is not strict, and Golang's GET requests have automatic retries, so it is not recommended to fill it to the maximum. You need to test those CDNs. When packet-up's upstream loop POST exceeds this value, it will automatically switch to another TCP/QUIC connection, occupying one of its reuseTimes but not concurrency. Actually, according to the three default values of XMUX, stream-* will not exceed the limit, only packet-up will, and it is the default mode of H3, so adding this item mainly benefits H3.
• hKeepAlivePeriod: When the H2/H3 connection is idle, the client sends a keep-alive packet every few seconds. The default is 0, which is Chrome H2's 45 seconds or quic-go H3's 10 seconds. It is the only item in XMUX that does not allow filling in a range (randomizing this item is a characteristic) and allows filling in a negative number (for example, filling in -1 turns off idle keep-alive packets). It is recommended to leave it at 0.

The parameters provided by XMUX can be combined in various ways. For example, set "maxConcurrency": 1 before a multi-threaded speed test, and set "maxConnections": 1 for "infinite" reuse. Even if you are too lazy to study, it's okay. When these values are all 0, the three default values mentioned above will be taken, which is equivalent to changing to a new H2/H3 main connection after a period of time. It's very smooth, and there will be no "stuttering" experience caused by gRPC and HTTP transport layers always reusing the same connection. Similarly, these parameters can be distributed to the client through extra.

Note: If you don't fill in anything, it is equivalent to all zeros, and the three default values will be taken. But if you fill in any item, the other items will not have default values, and you need to fill them all yourself, except for the first two items, which can be filled in simultaneously.

In addition, do not enable mux.cool when using XHTTP, and the new version of the Xray server has a check to accept only pure XUDP.

Regarding the default values of XMUX, some excerpts:

• I specifically chose two options that are not easily detectable outside of TLS, namely maxConcurrency plus cMaxReuseTimes (instead of maxConnections plus cMaxLifetimeMs), and the default values of these two options are both ranges taken randomly, eliminating potential characteristics to the greatest extent.
• I chose maxConcurrency instead of maxConnections to prevent the number of connections from becoming a fixed pattern. Of course, if you like the latter, you can also set it manually.
• XMUX and Nginx count different objects. maxConcurrency and cMaxReuseTimes are both based on the "proxied connection" count. Only stream-one will generate one HTTP request, while stream-up has two, one upstream and one downstream, and packet-up has N.
• However, I am not sure if stream-one will automatically generate an additional HTTP request under certain circumstances. Also, I think there is not much point in pursuing the reuse of a connection to the end because if you are an operator, you will also limit the speed and clean up old connections, otherwise, resources will be slowly occupied by old connections. Therefore, the default parameters of XMUX are to limit reuse + periodically change connections.

There is also a discussion of some Nginx parameters below the article.

STREAM-UP/ONE

Finally, we come to another important mode of XHTTP: stream-up, which is "streaming upstream, streaming downstream". As the name suggests, the upstream of this mode is also streaming, so it will not sacrifice upstream efficiency. It was originally developed for REALITY until we found that adding a gRPC header to disguise H2 can penetrate Cloudflare (CF) (gRPC support needs to be enabled in the panel), and the support of reverse proxy software such as Nginx is also good (Nginx recommends grpc_pass, which is simple and convenient). So the behavior of the default value "auto" of mode is:

• Client: stream-up for TLS H2, stream-one for REALITY (stream-up when there is downloadSettings), otherwise packet-up.
• Server: By default, it accepts all three modes. If set to a specific mode, it only accepts that mode. "stream-up" is an exception, it also accepts stream-one.
• stream-up has better compatibility than stream-one. Some users said that they can use stream-up when CFT enables streaming upstream, but they need to enable another option to use stream-one (maybe it's the fault of SSE camouflage?). I also saw a CDN (forgot the name) that severely limits the speed of stream-one but not stream-up.

Their implementation methods are (non-developers can skip):

• For stream-up, change the packetized upstream of packet-up to streaming POST /yourpath/sameUUID, also with ?x_padding=000....
• For stream-one, POST /yourpath/ is enough, the response is downstream, bidirectional streaming, both request headers and response headers have header padding.
• Note that if stream-one fills in /yourpath, it actually requests /yourpath/. If there is no / at the end, it will be automatically added.
• Upstream defaults to Content-Type: application/grpc to disguise as gRPC (can be turned off by setting noGRPCHeader).
• The server response header for downstream is exactly the same as 1 of packet-up. stream-one will have the spectacle of responding to gRPC with SSE. If you encounter problems, you can try noSSEHeader.

Those who often use gRPC may ask: what are the advantages of stream-up over the gRPC transport layer?

• The former does not require any gRPC library and has better performance.
• The downstream traffic of the former is an independent GET request and is not subject to the traffic restrictions of CDN on gRPC.
• The former also has enhancements such as header padding, XMUX, and upstream and downstream separation, and has introduced the extra mechanism. All parameters can be shared and are more mature.

Of course, the advantages of XHTTP over WebSocket and HTTPUpgrade, in addition to "no significant characteristics of ALPN being http/1.1", I believe you have read this far, and you already have the answer in your heart. I will not list them one by one, mainly because there are too many to list.

Upstream and Downstream Separation

A groundbreaking advancement in XHTTP is upstream and downstream separation. The Great Firewall (GFW) typically analyzes traffic characteristics based on single connections. By splitting upstream and downstream traffic across different inspection systems, such as using IPv4 TCP for upstream and IPv6 UDP for downstream, the GFW's detection capabilities can be hindered.

XHTTP natively supports true upstream and downstream separation because it associates upstream and downstream traffic based on a randomly generated UUID in the path. This capability, combined with XHTTP's ability to penetrate CDNs and integrate with REALITY, offers a wide range of configuration possibilities.

To enable upstream and downstream separation on the client-side, configure 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 new set of streamSettings, but it includes address and port to specify a different entry point, similar to VLESS outbound.

• network must be set to "xhttp" (required).
• security can be "tls" or "reality".
• If sockopt is not specified, it inherits the upstream settings. Some sockopt parameters are specific to the local environment and may cause issues when shared. Therefore, if sockopt is in extra, it will be forced to inherit the upstream settings.

Except for this sockopt behavior, the downstream configuration is entirely independent and does not inherit any upstream settings. For example, even if both upstream and downstream use default XMUX values, the randomized values within the specified ranges will be independent. This results in asymmetrical multiplexing and different timings for switching main connections, further enhancing anti-analysis capabilities.

To counter upstream and downstream separation, the GFW would likely focus on the timing of main connection initiations. Future versions of XHTTP may allow initiating upstream and downstream connections at different times to address this.

---

Leveraging CDNs for Upstream and Downstream Separation

You can implement upstream and downstream separation even without modifying the server configuration if you are using a CDN. For example, you can use one optimized IPv4 for TLS H2 upstream and another optimized IPv6 for QUIC H3 downstream.

CDNs generally support "same-domain domain fronting". For instance:

• Upstream serverName: "a.example.com"
• Downstream serverName: "b.example.com"
• Both upstream and downstream host: "c.example.com"

This makes the external SNI appear different while still using the same domain. If you have two domains, it's even better.

If you don't have any domains, you can use two VPSs and two REALITY configurations for upstream and downstream separation. Whether using a CDN with a reverse proxy or REALITY with fallback, the key is to ensure that both upstream and downstream traffic reach the same XHTTP inbound on the same VPS using the same path.

XHTTP's versatility allows for countless combinations. The only limitation is your imagination.

A common use case for upstream and downstream separation is to route upstream traffic through a path with optimized outbound routing and downstream traffic through a path with optimized inbound routing.

---

Configuration Example and Explanation

The provided configuration example demonstrates the placement of each parameter:

• extra: A raw JSON sharing scheme for all parameters except host, path, and mode. When extra is present, only these four parameters are effective. Sharing links and GUI configurations typically only include these four parameters because extra parameters are less frequently used and should be provided directly by the service provider.
• "Distribution" means that the service provider configures the extra and includes it in the sharing link. Clients can then use the entire extra as their own.
• host: The client sends the host header in the following priority: host > serverName > address. If the server sets host, it checks if the client's value matches. Otherwise, no check is performed. It is generally recommended not to set host on the server. host cannot be placed in headers.

---

Beyond REALITY

REALITY, introduced last year, addressed several pain points and quickly became the primary choice for direct connections. Its stability and effectiveness have been widely recognized. While Xray has made numerous optimizations and improvements to other transports, XHTTP is the first native transport layer for Xray, and it's making a significant impact.

"Beyond REALITY" does not mean replacing REALITY but rather surpassing its popularity. XHTTP's versatility and comprehensive features make it a superior choice compared to other HTTP-based transport layers. It is poised to become even more popular than REALITY due to its broader applicability.

XHTTP continues Xray's tradition of innovation and transformation, bringing a powerful new tool to the anti-censorship arsenal.

---

Support the Project

If you find this information helpful, consider supporting the project by purchasing a REALITY NFT:

• There are 1,000 NFTs in total, with the first 100 priced at 0.01 ETH. Subsequent prices will increase.
• An article introducing REALITY will be released in the coming days.
• Holding a REALITY NFT grants early access to a new Xray client and an airdrop of the next NFT.
• Project X NFT holders as of January 1, 2025, will receive two REALITY NFTs.

Project X NFTs have already increased five to six times in value. This is an excellent opportunity for those who missed the initial Project X NFT offering.

If you have the means, supporting the project with a Project X NFT is also greatly appreciated:

• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: Announcement of NFTs by Project X #3633
• REALITY NFT: https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

If ETH gas fees are high, you can favorite the NFT and purchase it when gas fees are lower.

If you have any further questions, please leave a comment below, and I will update the article accordingly. It is recommended not to translate this article prematurely.

---

User Comments on This Discussion

---

fodhelper on Dec 5, 2024
It's rumored that some CDNs are acting against using their services for proxy (not on a large scale yet), maybe they had some agreements with governments.

As someone who doesn't want to get banned by CDNs, I prefer WebSocket or gRPC without /Tun, but not XHTTP with static URL patterns and xPaddingBytes query string with many 0s.
And I had hoped you would add XMUX to gRPC, but instead, you flagged it as deprecated.

---

RPRX on Dec 5, 2024
Your statement has some inaccuracies. First, the Cloudflare team responded that their new firewall automatically blocked Iranian IPs, which was done manually, and they did not target the proxy.
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 the 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 preparing for SHTF, not to wait until things go wrong and then start thinking about it and finding solutions. When it’s impossible to not have clear characteristics for CDN (or for GFW if the user wanted to not use TLS), there is no reason not to.

---

RPRX on Dec 6, 2024
I think the situation is not that simple, because the management of the proxy is very complex, and it requires you to prepare for many factors. These characteristics are inherently specific, such as the randomness of the number of connections, the overall flow characteristics, etc.

---

fodhelper on Dec 6, 2024
@RPRX, have you heard the news? Isn’t it time to act?
To hide proxy protocol headers, VMESS exists, and for abnormal overall traffic characteristics, split upload and download of XHTTP is there (Although I think removing obvious characteristics of transports is enough).
These options are needed to hide obvious characteristics of transports:

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

---

RPRX on Dec 18, 2024
@fodhelper, now that it’s early, if it’s proven that these factors have led to targeting, we will certainly attract measures.

---

fodhelper on Dec 18, 2024
It's something like "server: nginx" response header of nginx.
But alright, let’s see if CDNs can detect proxies using these obvious characteristics or not.

---

MossAndMaurice on Dec 6, 2024

Trying to understand the focus and logic behind the XTLS series of protocols. If there are any inaccuracies, please @RPRX for corrections.

XTLS (Initial Versions: splice/direct/origin, etc.) – Solving Performance Issues:

Traditional TLS over TLS introduces the overhead of double encryption. XTLS embeds or splices the inner TLS data directly and losslessly into the outer TLS stream, making it appear as a single-layer TLS on the surface while hiding proxy traffic. This reduces redundant encryption and decryption processes. Without compromising security, it significantly lowers CPU load and encryption/decryption costs, thereby improving performance.

VISION – Addressing TLS-in-TLS Characteristics:

In multi-layered TLS (TLS-in-TLS), the inner and outer TLS handshakes involve two separate interactions, creating a timing pattern that can be precisely identified by the GFW. VISION works by simulating delays and adjusting the message exchange sequence to smooth out these unnatural timing characteristics. This makes the multi-layered TLS handshake process appear more like genuine internet traffic, reducing the risk of detection.

REALITY – Solving the SNI Blocking Problem:

In mainland China, SNI (Server Name Indication) cannot be encrypted, allowing the GFW to identify and block traffic based on SNI. REALITY disguises the TLS handshake and certificate exchange process by returning certificates and initial data that appear to belong to legitimate websites during the handshake. This makes the entire TLS connection indistinguishable from a connection to a major HTTPS website. For the GFW to block such traffic, it risks mistakenly blocking real websites.

XHTTP – Addressing the "Single Tunnel" Characteristics of Proxy Protocols:

Traditional protocols (e.g., Shadowsocks, Vmess, Trojan) typically encrypt data and transmit it continuously through specific ports, creating a "stable, long-duration encrypted stream" characteristic. Censors can use statistical analysis, long connection patterns, and data transmission modes to suspect proxy traffic. XHTTP focuses on the application layer, further wrapping encrypted transmissions into what appear to be legitimate HTTP requests and responses. It splits upstream data into multiple seemingly normal POST requests with randomized parameters in the URLs, while downstream data is disguised as large file downloads or continuous SSE (Server-Sent Events) outputs. This makes traffic behavior closely resemble ordinary user browsing or downloading patterns. Unlike traditional "encrypted tunnels," XHTTP no longer appears as a stable, continuous data pipeline but as a series of independent, scattered, and natural HTTP interactions, mimicking common web access actions.

---

tomxiang1 on Dec 6, 2024

REALITY also solves the problem of server handshake negotiation, making it easy to disguise as a major server, so the GFW is hesitant to block it.

---

Ahmad-2213 on Dec 8, 2024

A specific question!
For those who are using Vless on workers/pages via WebSocket, is it possible to implement this protocol similarly on workers? Or does CF just support WebSocket?

---

RPRX on Dec 9, 2024

It seems that stream-one might work.

---

TheLordOfTheKings on Dec 8, 2024

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

---

RPRX on Dec 9, 2024

That's the purpose of Seed.

---

RPRX on Dec 5, 2024

When discussing upstream and downstream separation, many people's approach is to prioritize upstream routes for upstream traffic and downstream routes for downstream traffic. This is quite practical.

---

zzlinwq on Dec 9, 2024

I think this is more understandable if you think of upstream as the process of going and downstream as the process of returning. Prioritize routes for going and returning separately. This is also practical. If it's IPv6 going, then return via IPv6; if it's IPv4 going, then return via IPv4.

---

zzlinwq on Dec 9, 2024

Does XHTTP require a domain certificate? If so, which one is better to apply for?

---

xqzr on Dec 9, 2024

IP certificates are also acceptable.

---

zzlinwq on Dec 10, 2024

Really? Which one should I apply for?

---

xqzr on Dec 10, 2024

ZeroSSL.

---

RPRX on Dec 10, 2024

I think this analogy of upstream as going and downstream as returning is more understandable. Prioritize routes for going and returning separately. This is also practical. If it's IPv6 going, then return via IPv6; if it's IPv4 going, then return via IPv4.

The next version will change to "prioritize upstream routes for upstream traffic."

iopq on Dec 10, 2024

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 to 443.

---

RPRX on Dec 10, 2024

Routing.

---

iopq 3 weeks ago

Wait, does reality even support QUIC?
Also, if I set the client alpn to "h3," will it use QUIC? Does QUIC have any advantage for proxying UDP traffic (since it is based on UDP)?

---

GreatMichaelLee on Dec 10, 2024

I'm a bit confused, but I think this is a good feature for reality—users with complex needs. Can you organize a few user cases (like with CDN, without CDN, different configurations, etc.) for different scenarios and provide configuration examples? Then users can adjust based on their server and IP. Some users may not be able to configure it themselves, so having examples would be helpful. Is there a public group for users? I'm currently struggling with the biggest confusion about upgrading XHTTP. I don't know which to change or keep, and if two configurations conflict, I don't know how to arrange them.

---

RPRX on Dec 10, 2024

For small users, the "Quick Start Guide" in the article is enough. Basically, you only need to adjust path, alpn, and upstream and downstream separation is too complex for small users.

---

[Saleh-Mumtaz]

stream-up performance is much better. But it has a long way to reach tcp reality xtls-rprx-vision.

[kuraudowelle]

agreed

[JarmoHu]

cloudfront可以用吗

[Alceatraz]

XHTTP 能用 xray 自己做接入层吗，不用CDN的情况下。还是必须nginx？ 比如以下设想

Client -> up -> REALITY+XHTTP -> node2 -> VMESS/RAW -> node1
Client <- REALITY+XHTTP <- node1

[Alceatraz]

No problem, just to make sure one thing, the xhttp up and down going to the same inbound of one node.

我做了些实验，但是遇到了一个问题请教下：

1. 单Node直接network=xhttp security=reality是可以的
2. 基于1，外边套一个nginx grpc-pass是可以的
3. 单Node直接vless-reality配合fallback-xhttp是可以的（参考）

但是双Node时，downNode作为主(out=freedom)，downNode用基于3的配置。但是upNode：

首先upNode不能有@xhttp因为会这个节点不是freedom，不符合same inbound的要求
其次如果想要对端inputfallback，必须用vless，所以upNode的组合是 vless-reality -> vless-tls
但是这么做会出现 invalid request version 也就是说 upNode 把请求给解析了而不是直接原样通过out发给downNode

请问如何能把fallback-@xhttp这个行为传递下去？甚至更多中间节点，比如bridge？

PS：upNode不能用nginx+grpc，因为那样没法REALITY

[yuhan6665]

双 node 应该是要在 client 配置 dialerProxy

[Alceatraz]

双 node 应该是要在 client 配置 dialerProxy

能麻烦大佬写个demo吗(实验整理完我一定去发个 Nature Guide 回馈社区)
实在时有点玩不懂了,文档里很多只有一句话的解释根本支撑不起来这么复杂的拓扑🤦‍♂️

我又试了：

1. VLESS的fallback直接发给downNode的network:raw+security:none。成功，但是这是裸奔的。
2. 使用kernel-wg把两个机器连接起来，fallback到对端。成功。

虽然成功了，但是upNode并不是以一个正常的in-out对数据处理，而是靠hack操作把XRay当成了Reality卸载。

我的猜测：

1. HTTP/SOCK/DOKO接受原始数据，network:XHTTP第一层包装拆分成两条流，security:REALITY第二层包装成假的TLS数据流
2. upNode卸载Reality以后校验失败，走fallback变成端口映射。此时路由和outbound根本没有在工作。
3. fallback相当于把XHTTP流直接甩给downNode，再用VLESS的一次fallback终于把数据甩给了xhttp-inbounds
4. 但是xhttp的same-inbound的要求，是否意味着xhttp流必须在这个inbound合并，其他节点必须是"卸载"而非“in-out流过”？

问题1: 我的理解是否正确，即无论什么拓扑，不是freedom的node一律只能让数据“卸载+回落”而不能“处理”？

尝试用xray-wg替换系统wg

1. 用dokodemo接受fallback，再用freedowm-dialProxy:wg从out-wg发给downNode
2. dokodemo的目标写downNode的wg0，失败，提示
   from tcp:0.0.0.0:0 accepted tcp:172.16.1.101:8080 (downNode是172.16.1.101)
   app/proxyman/inbound: connection ends > proxy/vless/inbound: fallback ends > proxy/vless/inbound: failed to fallback request payload > read tcp xxxxxx:xxxx -> xxxx:xxxx: read: connection reset by peer

问题2: 看上去x-wg对数据的处理和wg很不一样，不支持site-to-site，本地网络栈也不可使用，x-wg有没有办法把流量直接甩给别的inbound？毕竟不是VLESS有回落

dialProxy：一个出站代理的标识。当值不为空时，将使用指定的 outbound 发出连接。 此选项可用于支持底层传输方式的链式转发。

问题3：文档实在是太简单了。功能且只能是把一个outbound套到另一个outbound里边吗？那接收端该如何卸载，因为非VLESS是没有回落的

BTW 从问题2开始已经实在是没有办法通过文档和搜example来研究了。比如x-wg配置文档实有，但是具体的工作逻辑完全没提到

[yuhan6665]

对于中转方案 我之前提到的 dialerProxy 适合使用无控制权（比如机场）的情况 如果你可以控制中转节点 不如简化一下 直接在中转节点使用端口转发即可

[Alceatraz]

对于中转方案 我之前提到的 dialerProxy 适合使用无控制权（比如机场）的情况 如果你可以控制中转节点 不如简化一下 直接在中转节点使用端口转发即可

所以其实fallback + kernel-wg 能跑通就没有对错。我这就去搞个教程，能提PR吗（example仓库接受这种奇怪的东西吗🤣）

[Smallthing]

请问一下xhttp的reality设置里面的dest是什么时候改成target的
一直没发现。。搞的很卡顿

[sshcomm]

@RPRX I had a question : Doesn't xray round robin load balancing with multiple links perform a similar function to download/upload separations in xhttp? Because I see countless similarities between xhttp upload/download separation and load balancer.

[yuhan6665]

Load balancing does not change the character of a client TCP connection is carried by one single proxy connection.
On the other hand xhttp break single client connection into two or more proxy connections

[sshcomm]

Load balancing does not change the character of a client TCP connection is carried by one single proxy connection. On the other hand xhttp break single client connection into two or more proxy connections

Yes, in practice, this is how it should be, but I repeat, I see similarities between the two, I will report the results and post them here.

[Urliuo]

经实验，部分CDN不支持流式下行，无论是否关闭缓存（例如 Azure CDN Standard 会直接卡住，直到超时）。想问能否考虑提供分包下行的降级机制，以便在特殊情况下保留高兼容性的保底手段？