XHTTP: Beyond REALITY #4113

RPRX · 2024-12-05T04:45:06Z

RPRX
Dec 5, 2024
Maintainer

中文 | Русский

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 的话，只需遵循六步：

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

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

CF 会掐断下行 100 秒无实际数据的 HTTP，代理长连接需在应用层面保活，比如 SSH 需在 sshd 设置 ClientAliveInterval。

这篇文章可以当增强版文档用，它基本上涵盖了关于 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 模式，我们是这样设计的：

客户端 POST /yourpath/sameUUID/seq 以发送上行数据：
- UUID 是随机生成的，等下启动下行时的 UUID 与它相同，以便服务端关联，若服务端未在 30 秒内成功关联，将终止会话
- seq 从 0 开始，必须发完上一个 POST 的 body（但无需等响应）再发下一个
- 多个 POST 有小概率乱序到达服务端，服务端会按 seq 进行重组，默认最多缓存 30 个，超限断连
- 注意 UUID 和 seq 都设计在 path 里而非 query string，以避免遇到奇怪的问题
客户端 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 则不需要
为了避免浏览器转发 Browser Dialer 遇到跨域限制，服务端针对所有 GET、POST 的响应头都会包含：
- Access-Control-Allow-Origin: *
- Access-Control-Allow-Methods: GET, POST
为了解决 HTTP 请求头和响应头的固定长度特征：
- 客户端发的 request header 均默认包含 Referer: ...?x_padding=XXX...（放 Referer 是为了防止 Browser Dialer 产生不必要的 OPTIONS 请求），默认长度为 100-1000，每次请求随机，服务端默认会检查它是否在服务端允许的范围内
- 服务端发的 response header 均默认包含 X-Padding: XXX...，默认长度为 100-1000，每次响应随机
- 这便是我多次提及的 header padding，对应设置项为 xPaddingBytes
- 请求头的 padding 改为放到 Referer 由 @rPDmYQ 提出，选用 XXX 也是，X 在 huffman encoding 中为 8 bit

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

此外，和 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 客户端：

启用 TLS/REALITY 时，默认使用 H2，否则使用 HTTP/1.1
启用 TLS 时，若 alpn 仅有 "http/1.1" 则使用 HTTP/1.1（但 Xray 并不会允许它修改 uTLS 浏览器指纹伪装）
启用 TLS 时，若 alpn 仅有 "h3" 则使用 quic-go H3
不过当你使用 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：一条连接最多被复用几次，复用该次数后将不会被分配新的代理请求，将在内部最后一条代理请求关闭后断开。默认值 0，即不限制，支持填写范围，每次随机。
hMaxRequestTimes：@xqzr 发现 Nginx 默认最多允许每条 TCP/QUIC 连接累计承载 1000 个 HTTP 请求，XMUX 全为 0 时该项默认值为 "600-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。
hMaxReusableSecs：@xqzr 发现 Nginx 默认最多允许每条 TCP/QUIC 连接被复用一个小时，XMUX 全为 0 时该项默认值为 "1800-3000" 取随机，否则该项默认 0 即不限制。TCP/QUIC 连接持续该时间后将不会被分配新的 HTTP 请求，将在内部最后一个 HTTP 请求关闭后断开。其中 packet-up 上行循环 POST 时若超过该值会自动切换到另一个 TCP/QUIC 连接，占它一个 reuseTimes 但不占 concurrency。
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 即可，也有 Referer: ...?x_padding=XXX...
对于 stream-one，POST /yourpath/ 即可，响应即为下行，双向流式，请求头、响应头均有 header padding
注意 stream-one 如果填 /yourpath，实际请求的是 /yourpath/，若末尾没有 / 会自动补上
上行均默认有 Content-Type: application/grpc 以伪装成 gRPC（可以设置 noGRPCHeader 以关闭）
下行的服务端响应头与 packet-up 的 1 完全一致，stream-one 会出现以 SSE 回应 gRPC 的奇观，若遇到问题可尝试 noSSEHeader

#4113 (comment) 的相关测试发现 CF 会掐断下行 100 秒无实际数据的 HTTP，导致 stream-up 的上行方向被掐断，所以这个 PR 为服务端添加了 scStreamUpServerSecs，默认值 "20-80" 取随机，服务端每隔这段时间就会发 xPaddingBytes 个字节以保活

可以设置 "scStreamUpServerSecs": -1 以关闭该机制，此时服务端甚至不会及时发 response header，和以前版本的行为相同

那么经常使用 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
        "scStreamUpServerSecs": "20-80", // stream-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": 0,
            "hMaxRequestTimes": "600-900",
            "hMaxReusableSecs": "1800-3000",
            "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 "sockopt" the latter's "penetrate" is true
        }
    }
}

可以看出，downloadSettings 其实就是一套全新的 streamSettings，但是多了类似于 VLESS 出站中的 address 和 port 以指向另一个入口。显然其中 network 必须为 "xhttp"（不可省略），security 可以为 "tls" 或 "reality"。sockopt 项也可被分享，但接收方可以在上行的 sockopt 里将 penetrate 设为 true 以覆盖下行，适合打 mark 的情况。除该特例外，上下行分离时下行配置是完全独立的，不会继承上行的任何配置，而且比如，即使上下行均未填 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 到处都能用，可随意搭配出来的组合是无限的，唯一的问题是脑洞够不够大。

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

比如你可以再给上行设 "maxConnections": 1，给下行设 "maxConcurrency": 1，实现上行的少量数据都走同一条底层连接，而下行的大量数据分散到不同的底层连接上，同时兼具反审查、低延迟、高速度，有点像 Switch，搭配 Vision Seed 食用效果更佳。

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

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 · 2024-12-05T05:10:04Z

xcf13363175
Dec 5, 2024

先顶再看

0 replies

zzlinwq · 2024-12-05T05:26:17Z

zzlinwq
Dec 5, 2024

先顶再看，不明觉厉

0 replies

iambabyninja · 2024-12-05T05:26:31Z

iambabyninja
Dec 5, 2024

中文 | Русский

UPDATED 11.03.2025

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, следуйте этим шести шагам:

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

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

CF обрывает HTTP-соединения без передачи данных в течение 100 секунд. Для поддержания активности долговременных соединений через прокси необходимо реализовать keep-alive на уровне приложения. Например, для SSH необходимо установить ClientAliveInterval в sshd.

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

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

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

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

PACKET-UP

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

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

Клиент отправляет POST /yourpath/sameUUID/seq для передачи данных:
- UUID генерируется случайным образом и используется при запуске загрузки, чтобы сервер мог связать запросы. Если сервер не может связать запросы в течение 30 секунд, сеанс завершается.
- seq начинается с 0. Следующий POST-запрос можно отправлять только после отправки тела предыдущего (но не нужно ждать ответа).
- Несколько POST-запросов могут прийти на сервер в неправильном порядке. Сервер пересобирает их по seq. По умолчанию кэшируется до 30 запросов, превышение лимита приводит к разрыву соединения.
- Обратите внимание, что UUID и seq находятся в пути, а не в строке запроса, чтобы избежать странных проблем.
Клиент запускает загрузку с помощью 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 это не требуется.
Чтобы избежать ограничений междоменных запросов при перенаправлении браузера Browser Dialer, заголовок ответа сервера для всех GET и POST-запросов содержит:
- Access-Control-Allow-Origin: *
- Access-Control-Allow-Methods: GET, POST
Для решения проблемы фиксированной длины заголовков HTTP-запросов и ответов:
- Заголовок запроса клиента по умолчанию содержит Referer: ...?x_padding=XXX... (Referer используется для предотвращения ненужных OPTIONS-запросов от Browser Dialer). Длина по умолчанию составляет 100-1000 символов, генерируется случайным образом для каждого запроса. Сервер по умолчанию проверяет, находится ли длина в допустимом диапазоне.
- Заголовок ответа сервера по умолчанию содержит X-Padding: XXX.... Длина по умолчанию составляет 100-1000 символов, генерируется случайным образом для каждого ответа.
- Это то, что я неоднократно называл header padding, соответствующий параметр — xPaddingBytes.
- Размещение padding в Referer предложил @rPDmYQ, использование XXX также его идея. X в кодировке Хаффмана занимает 8 бит.

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

Кроме того, как и другие транспортные уровни 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, способный проходить практически через все промежуточные устройства, давайте обсудим кое-что интересное: 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:

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

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

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

XMUX

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

maxConcurrency: максимальное количество одновременных прокси-запросов в каждом TCP/QUIC-соединении. Когда количество прокси-запросов в соединении достигает этого значения, ядро устанавливает новое соединение, чтобы вместить больше прокси-запросов. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра — "16-32", выбирается случайным образом.
maxConnections: максимальное количество одновременных соединений. До достижения этого значения каждый новый прокси-запрос открывает новое соединение. После этого ядро начинает повторно использовать существующие соединения. Этот параметр конфликтует с maxConcurrency, можно использовать только один из них. Значение по умолчанию — 0, то есть без ограничений. Поддерживается указание диапазона, значение выбирается случайным образом.
cMaxReuseTimes: максимальное количество раз, которое соединение может быть повторно использовано. После достижения этого количества соединение больше не будет использоваться для новых прокси-запросов и будет закрыто после завершения последнего прокси-запроса. Значение по умолчанию — 0, то есть без ограничений. Поддерживается указание диапазона, значение выбирается случайным образом.
hMaxRequestTimes: @xqzr обнаружил, что Nginx по умолчанию разрешает максимум 1000 HTTP-запросов на каждое TCP/QUIC-соединение. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра — "600-900", выбирается случайным образом. В противном случае значение по умолчанию — 0, то есть без ограничений. Этот параметр основан на подсчете HTTP-запросов. Обычно stream-one генерирует один HTTP-запрос, stream-up — два, а packet-up — N. Подсчет не является точным, и GET-запросы Golang имеют автоматический повтор, поэтому не рекомендуется устанавливать максимальное значение. CDN и другие провайдеры нужно тестировать. Если при циклической отправке POST-запросов в режиме packet-up это значение превышено, происходит автоматическое переключение на другое TCP/QUIC-соединение, которое занимает один reuseTimes, но не занимает concurrency. Фактически, при значениях XMUX по умолчанию stream-* не превышает лимит, только packet-up, который является режимом по умолчанию для H3. Поэтому добавление этого параметра снова в основном выгодно для H3.
hMaxReusableSecs: @xqzr обнаружил, что Nginx по умолчанию разрешает повторное использование каждого TCP/QUIC-соединения в течение одного часа. Если все параметры XMUX равны 0, значение по умолчанию для этого параметра — "1800-3000", выбирается случайным образом. В противном случае значение по умолчанию — 0, то есть без ограничений. TCP/QUIC-соединение, существующее в течение этого времени, больше не будет использоваться для новых HTTP-запросов и будет закрыто после завершения последнего HTTP-запроса. Если при циклической отправке POST-запросов в режиме packet-up это значение превышено, происходит автоматическое переключение на другое TCP/QUIC-соединение, которое занимает один reuseTimes, но не занимает concurrency.
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. Также используется Referer: ...?x_padding=XXX....
Для stream-one используется POST /yourpath/. Ответ является выгрузкой, двунаправленный поток. Заголовки запроса и ответа имеют header padding.
Обратите внимание, что если для stream-one указан /yourpath, фактический запрос отправляется на /yourpath/. Если / в конце отсутствует, он добавляется автоматически.
Загрузка по умолчанию имеет Content-Type: application/grpc для маскировки под gRPC (можно отключить с помощью noGRPCHeader).
Заголовки ответа сервера для выгрузки идентичны заголовкам packet-up из пункта 1. В stream-one может возникнуть необычная ситуация, когда gRPC отвечает с помощью SSE. Если возникнут проблемы, попробуйте noSSEHeader.

В ходе тестов, связанных с #4113 (comment), было обнаружено, что CF обрывает HTTP-соединения без передачи данных в течение 100 секунд, что приводит к обрыву загрузки stream-up. Поэтому этот PR добавил scStreamUpServerSecs на сервер со значением по умолчанию "20-80" (выбирается случайным образом). Сервер каждые этот интервал отправляет xPaddingBytes байт для поддержания активности соединения.

Можно установить "scStreamUpServerSecs": -1, чтобы отключить этот механизм. В этом случае сервер даже не будет отправлять заголовки ответа своевременно, как в предыдущих версиях.

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

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

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

Разделение загрузки и выгрузки

И, наконец, еще одна новая эра: разделение загрузки и выгрузки. Мы примерно знаем, что сейчас GFW обнаруживает такие характеристики трафика, как TLS in TLS, на основе одного соединения. Таким образом, если мы разделим загрузку и выгрузку на разные соединения, например, загрузка будет идти по TCP через IPv4, а выгрузка — по UDP через IPv6, 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, только сервер
        "scStreamUpServerSecs": "20-80", // stream-up, только сервер
        "xmux": { // в основном h2/h3, только клиент
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": 0,
            "hMaxRequestTimes": "600-900",
            "hMaxReusableSecs": "1800-3000",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // только клиент
            "address": "", // другой домен/IP
            "port": 443,
            "network": "xhttp",
            "security": "tls",
            "tlsSettings": {
                ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // должен быть одинаковым
                ...
            },
            "sockopt": {} // будет заменено на "sockopt", если в последнем "penetrate" равно true
        }
    }
}

Как видно, downloadSettings — это, по сути, новый набор streamSettings, но с добавлением address и port, аналогичных исходящему VLESS, для указания другого входа. Очевидно, что network должен быть "xhttp" (нельзя опускать), security может быть "tls" или "reality". Параметр sockopt также можно передавать, но принимающая сторона может установить penetrate в значение true в sockopt загрузки, чтобы переопределить выгрузку, что подходит для использования mark. За исключением этого особого случая, при разделении загрузки и выгрузки конфигурация выгрузки полностью независима и не наследует никакие настройки загрузки. Более того, например, даже если 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, главное, чтобы в итоге трафик с одним и тем же путем попадал на один и тот же входящий XHTTP на одном и том же VPS. В общем, поскольку XHTTP можно использовать везде, количество возможных комбинаций бесконечно. Единственный вопрос — насколько развита ваша фантазия.

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

Например, вы можете установить "maxConnections": 1 для загрузки и "maxConcurrency": 1 для выгрузки, чтобы небольшой объем данных загрузки шел по одному и тому же базовому соединению, а большой объем данных выгрузки распределялся по разным базовым соединениям, одновременно обеспечивая защиту от цензуры, низкую задержку и высокую скорость. Это похоже на Switch, и лучше всего работает в сочетании с Vision Seed.

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

extra — это оригинальное решение для передачи всех параметров, кроме host, path и mode, в формате JSON. Когда extra присутствует, действуют только эти четыре параметра. И в ссылке для общего доступа есть только эти четыре параметра, как и в большинстве GUI, потому что параметры в extra используются относительно редко и должны предоставляться клиенту непосредственно поставщиком услуг, а не изменяться клиентом произвольно.
Дополнение: «предоставляться» означает «предоставляться человеком», то есть поставщик услуг записывает extra и помещает его в ссылку для общего доступа, клиент использует его непосредственно как свой extra.
Поведение host аналогично другим транспортным уровням Xray, основанным на HTTP. Приоритет отправки host клиентом: host > serverName > address. Если на сервере установлен host, он проверяет, совпадает ли значение, отправленное клиентом. В противном случае проверка не выполняется. Рекомендуется не устанавливать его без необходимости. host нельзя указывать в headers.

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

Beyond REALITY

В начале прошлого года я вернулся и написал REALITY, одним махом решив несколько проблем, ~~а потом все время тусовался по ночным клубам и почти не занимался им~~, даже статью забросил и до сих пор не закончил, ~~XUDP UoT Migration еще жальче, в прошлом году статья была почти готова, но не опубликована~~, незаметно REALITY вырос в основную технологию для прямого подключения. Часто можно увидеть комментарии под сообщениями о блокировке XX с рекомендацией перейти на REALITY, репутация говорит сама за себя, ~~даже здесь стало не так оживленно, как раньше, из-за чрезмерной стабильности~~. Хотя Xray также внес множество оптимизаций и улучшений в другие транспортные протоколы, 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, например,
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 непомерно высока, вы можете сначала добавить в избранное и купить, когда комиссия за газ будет относительно нормальной.

1 reply

RPRX Dec 8, 2024
Maintainer Author

原文有了一些更新

zengzhengkevin · 2024-12-05T05:26:47Z

zengzhengkevin
Dec 5, 2024

顶

0 replies

hkfires · 2024-12-05T06:23:26Z

hkfires
Dec 5, 2024

学习中...

0 replies

fodhelper · 2024-12-05T06:52:38Z

fodhelper
Dec 5, 2024

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

6 replies

fodhelper Dec 5, 2024

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 Dec 6, 2024
Maintainer Author

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

fodhelper Dec 17, 2024

@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 :

option to set custom Early-Data header key name for WebSocket
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 Dec 18, 2024
Maintainer Author

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

fodhelper Dec 18, 2024

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 · 2024-12-05T07:58:55Z

namebuhtig
Dec 5, 2024

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

0 replies

dcdebug · 2024-12-05T08:00:48Z

dcdebug
Dec 5, 2024

Six,Six,Six...

0 replies

xqzr · 2024-12-05T11:25:34Z

xqzr
Dec 5, 2024

希望“无限”复用，可以将 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

30 replies

xqzr Dec 14, 2024

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

RPRX Dec 14, 2024
Maintainer Author

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

xqzr Dec 14, 2024

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 Dec 14, 2024

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

RPRX Dec 14, 2024
Maintainer Author

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

fireme1on · 2024-12-05T12:02:04Z

fireme1on
Dec 5, 2024

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

0 replies

simplerick-simplefun · 2024-12-05T15:20:51Z

simplerick-simplefun
Dec 5, 2024

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

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

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

2 replies

RPRX Dec 5, 2024
Maintainer Author

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

RPRX Dec 5, 2024
Maintainer Author

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

Smallthing · 2024-12-06T02:23:18Z

Smallthing
Dec 6, 2024

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

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

7 replies

lxhao61 Dec 6, 2024

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

RPRX Dec 7, 2024
Maintainer Author

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

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

ssmetall Dec 12, 2024

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 Dec 15, 2024

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

RPRX Dec 18, 2024
Maintainer Author

@Smallthing 文章已更新：

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

drsanwujiang · 2024-12-06T02:25:10Z

drsanwujiang
Dec 6, 2024

Look good to all

0 replies

tomxiang1 · 2024-12-06T03:04:18Z

tomxiang1
Dec 6, 2024

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

6 replies

tomxiang1 Dec 6, 2024

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

iopq Dec 10, 2024

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 Dec 12, 2024

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 Jan 7, 2025

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 Jan 8, 2025

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 · 2024-12-06T07:55:15Z

MossAndMaurice
Dec 6, 2024

尝试理解下我们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访问动作。

1 reply

tomxiang1 Dec 6, 2024

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

Saleh-Mumtaz · 2025-01-15T21:33:46Z

Saleh-Mumtaz
Jan 15, 2025

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

1 reply

kuraudowelle Jan 17, 2025

agreed

JarmoHu · 2025-01-19T07:46:40Z

JarmoHu
Jan 19, 2025

cloudfront可以用吗

0 replies

Alceatraz · 2025-01-20T09:44:30Z

Alceatraz
Jan 20, 2025

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

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

8 replies

Alceatraz Jan 21, 2025

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

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

单Node直接network=xhttp security=reality是可以的
基于1，外边套一个nginx grpc-pass是可以的
单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 Jan 21, 2025
Maintainer

双 node 应该是要在 client 配置 dialerProxy

Alceatraz Jan 22, 2025

双 node 应该是要在 client 配置 dialerProxy

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

我又试了：

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

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

我的猜测：

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

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

尝试用xray-wg替换系统wg

用dokodemo接受fallback，再用freedowm-dialProxy:wg从out-wg发给downNode
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 Jan 22, 2025
Maintainer

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

Alceatraz Jan 23, 2025

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

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

Smallthing · 2025-01-20T17:36:08Z

Smallthing
Jan 20, 2025

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

0 replies

sshcomm · 2025-01-20T18:10:22Z

sshcomm
Jan 20, 2025

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

3 replies

yuhan6665 Jan 20, 2025
Maintainer

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 Jan 20, 2025

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.

sshcomm Jan 26, 2025

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

As shown in the video, the uplink link is with the IP 45.135 and our downlink is 188.114, but when downloading, it still makes post requests with the same downlink link and the same for the uplink.
I thought this separation would be all download requests with the downlink stream and all uploads with the uplink stream.

Video_250126111453.mp4

Urliuo · 2025-01-25T15:46:31Z

Urliuo
Jan 25, 2025

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

0 replies

kabo00os · 2025-01-26T03:00:28Z

kabo00os
Jan 26, 2025

In packet-up mode, when alpn is set to http/1.1, it displays the following error

transport/internet/splithttp: failed to GET https:// example . com /path/7c40dcf9-f713-4007-a85b-b786dfa7895f?x_padding=000 > Get "https:// example . com /path/7c40dcf9-f713-4007-a85b-b786dfa7895f?x_padding=000": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x12\x04\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x80\x00\x04\x00\x01\x00\x00\x00\x05\x00\xff\xff\xff\x00\x00\x04\b\x00\x00\x00\x00\x00\x7f\xff\x00\x00\x00\x00\b\a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01"

1 reply

CrazyBoyFeng Feb 11, 2025

The use of http/1.1 is not recommended for this project at this time, as the alpn feature is more typical.
Most modern browsers run on h2 and h3, and very few applications (e.g. websocket and websocket-based httpupgrade) need to specify an alpn of h1. Firewalls can easily tell that you're using websocket by looking at the alpn and the connection pattern, and modern web services rarely use websocket, they usually use alternatives such as h2 push, webrtc and webtransport.
So if you have a lot of h1 traffic, this will make you look suspicious to censors. While censors may not blocking h1 and websocket across the board, it is advisable not to use h1 if h2 and h3 are available.

If you do want to use h1, note that xhttp's h1 running in packet-up mode is a little different from websocket and httpupgrade in that it should not contain the following code in its nginx configuration

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";

moh3nasiyat · 2025-01-30T00:52:45Z

moh3nasiyat
Jan 30, 2025

Greetings to all core developers except @RPRX.

This person is an example of a violation of personal privacy, as they published a text and made a serious accusation against the developer of @3X-UI.

Meanwhile, based on my usage and that of my friends in Iran, China, and Russia, 3X-UI is the most complete panel available.

Due to their extremely inappropriate behavior in this matter, I request an apology from them on behalf of this entire community.

If they fail to apologize, I call upon the great communities of China, Russia, and Iran to boycott RPRX.

We have grown up under authoritarian governments, but we will not allow an individual in this community to insult and accuse others.

Power does not belong to a single person—you are not in control. Do not forget that.

@RPRX

3 replies

kuraudowelle Jan 30, 2025

Go ahead. Please suit yourselves; you only think about yourselves, and you are a group of ignorant and selfish people. You are just looking for an excuse to stop developing projects for your collapsing firewall. Without the core, you are nothing. Please do not cause trouble in the territory of the Chinese people.

中文版：

请自便，你们只为自己考虑，就是一群无知且自私的人。你们只是为你们即将崩塌的防火墙寻找不再继续发展项目的理由罢了。没有内核你们一无是处，请不要到中国人的地盘上撒野。

无聊……一群不自知的人……

Smallthing Jan 30, 2025

make me LMAO

RPRX Jan 30, 2025
Maintainer Author

Dup #3884 (comment), from an ignorant guy who hasn't even read #3884 (comment)

arrgti · 2025-02-01T17:46:09Z

arrgti
Feb 1, 2025

after upgrading from 25.1.1 to 25.1.30 stream-up with CF stopped working, packer-up running normal. Is it only for me?

5 replies

RPRX Feb 2, 2025
Maintainer Author

v25.1.30 版本专门针对 CF 修复了 stream-up 长连接断线的问题且经过了测试，所以大概是 only for you，尝试排查：

xPaddingBytes 不再能被设为 -1
path 的 x_padding 被移至了 Referer header

This comment has been hidden.

Sign in to view

RPRX Feb 3, 2025
Maintainer Author

双端均为 v25.1.30 时，stream-up 上行方向上下都有数据，可能 proxy_pass 的 h1 不支持这种，需要用 grpc_pass

arrgti Feb 3, 2025

双端均为 v25.1.30 时，stream-up 上行方向上下都有数据，可能 proxy_pass 的 h1 不支持这种，需要用 grpc_pass

Daaamn, you're right, man! I forgot about grpc. Added h2c to the reverse proxy, and it works like a charm! (idk why stream-up worked for me before, but it has been working since the very first release of xhttp)

RPRX Feb 3, 2025
Maintainer Author

v25.1.30 的 stream-up 上行方向就像 stream-one 是双向流式，h1 标准不支持这种，h2 和 h3 支持

lxhao61 · 2025-02-02T15:02:34Z

lxhao61
Feb 2, 2025

@RPRX REALITY Vision 回落 XHTTP 应用使用 UDS 连接，服务端与客户端都 v25.1.1 升级为 v25.1.30 后，原正常的 REALITY XHTTP 应用无法使用(连接测试超时)。
经测试此修复引入了新的 BUG，希大神核实及修复。

5 replies

RPRX Feb 3, 2025
Maintainer Author

#4325 这个 PR 应该不会引入新 bug，你确定 5679d71 没问题吗

lxhao61 Feb 3, 2025

是的，己测试过确定 5679d71 没问题。

RPRX Feb 3, 2025
Maintainer Author

但我感觉那个 PR 只是区分新旧两套代码，可能是你配置写法问题？要不你开个 issue 和风扇研究下吧

lxhao61 Feb 5, 2025

经过反复测试，发现我服务端路由配置中若配置了 source 参数就出如上报告问题，其配置如下：

      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "source": [
          "geoip:!cn"
        ],
        "outboundTag": "direct"
      },

删除如上 source 参数，即使使用 v25.1.30 版本也正常了。

RPRX Feb 5, 2025
Maintainer Author

@Fangliding

HKXSWJ · 2025-02-12T06:52:23Z

HKXSWJ
Feb 12, 2025

感谢楼主的付出

0 replies

apollogeek · 2025-02-12T11:33:08Z

apollogeek
Feb 12, 2025

Do I need add this option: "scStreamUpServerSecs": "20-80" to my server config.json or not?

1 reply

RPRX Feb 13, 2025
Maintainer Author

不需要，v25.1.30+ 服务端默认有的

iopq · 2025-02-17T12:25:57Z

iopq
Feb 17, 2025

I'm still confused about stream-up and stream-one

what are the differences? Which one should I use with TLS XHTTP3?

0 replies

dongjuanyong · 2025-03-03T12:52:58Z

dongjuanyong
Mar 3, 2025

因为找了一个略微丢包（2%左右）的vps，于是尝试xhttp+h3看看走udp的话能不能让连接状况好一些，不过发现了难受的地方，不知是nginx的问题还是xray的问题（或是vps的？）
配置用的XTLS/Xray-examples中的VLESS-XHTTP3-Nginx，基本没动。
测试时发现，短时间内发起代理请求，走h3和h2的响应都没有问题。但空闲的时间一长（超过5m），h3就会报错，马上重试又能连上。出错的错误是这样的：
2025/03/03 20:18:18.590864 [Info] [3717366876] transport/internet/splithttp: failed to GET https://******/06f8100c-a00f-4267-8ae9-4fd4169dd8ae?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Get "https://******/06f8100c-a00f-4267-8ae9-4fd4169dd8ae?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX": Application error 0x100 (remote): keepalive timeout
找了一圈发现nginx中的配置keepalive_timeout 5m;正好与这个错误有直接关系，改成几分钟，空闲的时间过长会出错的时间就变成几分钟。
于是抓包看了一下，xray很兢兢业业的按照10s的间隔发包keepalive，nginx也都有回包。直到keepalive_timeout设置的时长之后，nginx主动发了一个包给xray，xray于是停止发送keepalive包，client和server间通信停止。
此时再发起代理请求的话，xray的client和server间没有任何通信，而client直接甩出上面的错误。此时整个流程结束，之后发起代理请求client又重新恢复和server的通信。
感觉似乎nginx和xray有点沟通问题，xray的keepalive nginx不认，依旧按照自己的配置时间中止空闲连接。而xray接到nginx中止连接的包以后，直到下次代理请求才重置连接的状态，而且也没能自动重新发起连接。
说实话，这vps和我的网络也可能有点问题，ssh连接空闲超过5m也必然断开。

暂时没有更多的时间来测试，等忙完周末再看看

23 replies

RPRX Mar 6, 2025
Maintainer Author

但问题在于时间，nginx发送了断开包，xray收到之后不是马上处理（记录在日志），而是在收到下级程序发来新的代理请求后再抛出错误，并且没有重新连接（事实上抓包看从收到断开包之后没有任何网络通信），这时下级程序(curl)只能得到一个连接错误

我看了下 quic Config 貌似没有相关的选项，可能要作为 issue 报告给 quic-go 仓库

倒是看到了 EnableDatagrams，我不确定这个是否能被 CDN 转译 h2 支持

xqzr Mar 6, 2025

reload Nginx 也会“断流”（在现有“连接”中，无法“创建”新流）。需要重启客户端，或者等待 1 分钟左右
https://t.me/projectXray/4099760
https://t.me/projectXray/4204986

xqzr Mar 6, 2025

我们的家用路由器中，udp 超时一般都是 5 分钟。但是，运营商各级网关的 udp 超时时间则是不固定的，它们使用动态的 qos。

Linux 的 ct（连接跟踪）对于 UDP 默认超时是 120s；TCP 是 5d（没看错）。但一般不会采用（修改它）。
这是 openwrt 的

net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_ignore_invalid_rst = 0
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 7440
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 60
net.netfilter.nf_conntrack_udp_timeout_stream = 180

ISP 的 CGN 在我看来，对于 TCP/UDP 一般都是 300s。

zzlinwq Mar 10, 2025

因为找了一个略微丢包（2%左右）的vps，于是尝试xhttp+h3看看走udp的话能不能让连接状况好一些，不过发现了难受的地方，不知是nginx的问题还是xray的问题（或是vps的？）配置用的XTLS/Xray-examples中的VLESS-XHTTP3-Nginx，基本没动。测试时发现，短时间内发起代理请求，走h3和h2的响应都没有问题。但空闲的时间一长（超过5m），h3就会报错，马上重试又能连上。出错的错误是这样的： 2025/03/03 20:18:18.590864 [Info] [3717366876] transport/internet/splithttp: failed to GET https://******/06f8100c-a00f-4267-8ae9-4fd4169dd8ae?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Get "https://******/06f8100c-a00f-4267-8ae9-4fd4169dd8ae?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX": Application error 0x100 (remote): keepalive timeout 找了一圈发现nginx中的配置keepalive_timeout 5m;正好与这个错误有直接关系，改成几分钟，空闲的时间过长会出错的时间就变成几分钟。于是抓包看了一下，xray很兢兢业业的按照10s的间隔发包keepalive，nginx也都有回包。直到keepalive_timeout设置的时长之后，nginx主动发了一个包给xray，xray于是停止发送keepalive包，client和server间通信停止。此时再发起代理请求的话，xray的client和server间没有任何通信，而client直接甩出上面的错误。此时整个流程结束，之后发起代理请求client又重新恢复和server的通信。感觉似乎nginx和xray有点沟通问题，xray的keepalive nginx不认，依旧按照自己的配置时间中止空闲连接。而xray接到nginx中止连接的包以后，直到下次代理请求才重置连接的状态，而且也没能自动重新发起连接。说实话，这vps和我的网络也可能有点问题，ssh连接空闲超过5m也必然断开。

暂时没有更多的时间来测试，等忙完周末再看看

有再测试吗？是啥问题呢

fish4terrisa-MSDSM Mar 15, 2025

类似的问题我使用caddy而并非nginx也有遇到。空闲时间长后会断流，但是很快又会自动恢复。

12Kilowatt · 2025-03-20T11:21:30Z

12Kilowatt
Mar 20, 2025

我正在用谷歌翻译用中文写文章。如果我的文字不正确，请原谅。

上下文 | Context

最近，我开始测试 XHTTP+TLS+CDN，同时考虑放弃旧的 REALITY 设置。这是为了实现更好的可靠性（nginx+CDN）、速度（HTTP3）并使用 subscriptions。但你可以说主要目标是 HTTP3。

我听说 HTTP3 在处理不稳定的互联网连接方面略胜一筹。虽然有线互联网通常提供稳定的连接，没有数据包丢失，但移动互联网并非如此。在农村或地下地区，或在高峰时段，当 4G 连接峰值速度不超过每秒 2 兆比特时，RTT 可能会从平均 150 毫秒随机飙升至 1100 毫秒。在这种情况下，HTTP2 Head-of-line blocking 可能成为一个问题。如果 HTTP3 可以改善这种情况，那么它值得一试。

问题描述 | Problem description

虽然 BEYOND REALITY 中没有明确说明这一点，但我认为 h3 不适用于 stream 模式，所以当我提到 h3 时，我指的是 packet-up 模式。

我从 #4118 中获取了配置文件。经过一些故障排除（#4478）后，它工作正常，但 packet-up 模式下的 h3 在使用一段时间后性能不佳。它一开始工作正常，但随后速度减慢到固定速度，或完全停止。它似乎……拥塞？受限？packet-up 和 stream-one 模式下的 h2 工作正常，没有这样的问题。

我将使用 Youtube 进行演示，但这可能发生在任何网站上，随时。当你在 Youtube 视频中跳转太多时，你的下载速度会下降到某个固定值，或者如果你跳转过度，则会降至 0。它会保持不变。如果你暂停视频足够长的时间或重新加载 V2RayN，拥塞就会消失。虽然这种状态是由我对 Youtube 的操作引起的，但它是自发发生的，并影响整个互联网连接。一切都变慢或停止工作，甚至 domain resolving。Connection Timeout、context deadline exceeded、EOF。

我认为这是因为 V2RayN -> CloudFlare -> VPS 链的请求太多，无法处理，所以我向下滚动 Youtube 搜索网页，试图对其进行 DDOS，但什么也没发生。我还下载了 800MB file，并没有发生拥塞。似乎不是由流量大小引起的。

我将附上版本、日志和演示此问题的视频示例。您可以看到速度从自然的 50 兆比特下降到人为的 8 兆比特。我没有按太多，所以互联网连接保持工作状态。

example.mp4

这个问题在 V2RayNG 上比 V2RayN 更严重。它经常自发发生，不需要我手动触发。一切都突然停止或减慢太多。网站组件加载速度有限，网页被剥离 CSS 并变成 WEB 1.0。不幸的是，我无法提供 V2RayNG 日志，因为 E/com.v2ray.ang(16440): Not starting debugger since process cannot load the jdwp agent。我使用的网络和 PC 上的网络一样。

P.S. 我想尝试上下行分离，但 V2RayN 在恢复备份时似乎会忽略客户端配置。我不知道如何将其输入到 XHTTP Extra raw JSON, format: { XHTTPObject } 中。

P.P.S 在我重现拥堵以收集日志并将速度降至零后，拥堵在大约五分钟后自行缓解。我再次重现拥堵，这次既没有缓解拥堵，也没有 V2RayN 重新加载帮助。我切换到 h2，它起作用了。

程序版本 | Versions

Xray 25.3.6
nginx 1.22.1

Debian 12 VPS, IPv4+IPv6
6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64

V2RayN 7.10.5
V2RayNG 1.9.39 (Lib v30, Xray-core v.25.3.6)

Xray error.log normal

[Warning] core: Xray 25.3.6 started
[Info] [2655310412] proxy/vless/inbound: firstLen = 2111
[Info] [2655310412] proxy/vless/inbound: received request for tcp:alive.github.com:443
[Info] [2655310412] app/dispatcher: sniffed domain: alive.github.com
[Info] [2655310412] app/dispatcher: default route for tcp:alive.github.com:443
[Info] [2655310412] transport/internet/tcp: dialing TCP to tcp:alive.github.com:443
[Debug] [2655310412] transport/internet: dialing to tcp:alive.github.com:443
[Info] [2655310412] proxy/freedom: connection opened to tcp:alive.github.com:443, local endpoint [[[IPv4 VPS]]], remote endpoint 140.82.112.26:443
[Info] [2655310412] proxy: CopyRawConn readv
[Info] [2521972159] proxy/vless/inbound: firstLen = 2405
[Info] [2521972159] proxy/vless/inbound: received request for tcp:rr2---sn-4g5ednkl.googlevideo.com:443
[Info] [2521972159] app/dispatcher: sniffed domain: rr2---sn-4g5ednkl.googlevideo.com
[Info] [2521972159] app/dispatcher: default route for tcp:rr2---sn-4g5ednkl.googlevideo.com:443
[Info] [2521972159] transport/internet/tcp: dialing TCP to tcp:rr2---sn-4g5ednkl.googlevideo.com:443
[Debug] [2521972159] transport/internet: dialing to tcp:rr2---sn-4g5ednkl.googlevideo.com:443
[Info] [2521972159] proxy/freedom: connection opened to tcp:rr2---sn-4g5ednkl.googlevideo.com:443, local endpoint [[[VPS IPv6]]], remote endpoint [2a00:1450:4001:29::7]:443
[Info] [2521972159] proxy: CopyRawConn readv
[Info] [283694165] proxy/vless/inbound: firstLen = 2497
[Info] [283694165] proxy/vless/inbound: received request for tcp:i.ytimg.com:443
[Info] [283694165] app/dispatcher: sniffed domain: i.ytimg.com
[Info] [283694165] app/dispatcher: default route for tcp:i.ytimg.com:443
[Info] [283694165] transport/internet/tcp: dialing TCP to tcp:i.ytimg.com:443
[Debug] [283694165] transport/internet: dialing to tcp:i.ytimg.com:443
2025/03/20 09:53:08.757797 [Info] [283694165] proxy/freedom: connection opened to tcp:i.ytimg.com:443, local endpoint [[[IPv6 VPS]]], remote endpoint [2a00:1450:4001:810::2016]:443
[Info] [283694165] proxy: CopyRawConn readv
[Info] [154478417] proxy/vless/inbound: firstLen = 200
[Info] [154478417] proxy/vless/inbound: received request for udp:1.1.1.1:53
[Info] [154478417] app/dispatcher: default route for udp:1.1.1.1:53
[Debug] [154478417] transport/internet: dialing to udp:1.1.1.1:53
[Info] [154478417] proxy/freedom: connection opened to udp:1.1.1.1:53, local endpoint [::]:36909, remote endpoint 1.1.1.1:53
[Info] [1661683332] proxy/vless/inbound: firstLen = 442
[Info] [1661683332] proxy/vless/inbound: received request for tcp:www.google.com:443
[Info] [1661683332] app/dispatcher: sniffed domain: www.google.com
[Info] [1661683332] app/dispatcher: default route for tcp:www.google.com:443
[Info] [1661683332] transport/internet/tcp: dialing TCP to tcp:www.google.com:443
[Debug] [1661683332] transport/internet: dialing to tcp:www.google.com:443
. . .

Xray error.log congested

2025/03/20 10:02:22.169047 [Warning] core: Xray 25.3.6 started
2025/03/20 10:02:25.933968 [Info] [4292671824] proxy/vless/inbound: firstLen = 98
2025/03/20 10:02:25.934008 [Info] [4292671824] proxy/vless/inbound: received request for udp:1.1.1.1:53
2025/03/20 10:02:25.934371 [Info] [4292671824] app/dispatcher: default route for udp:1.1.1.1:53
2025/03/20 10:02:25.934386 [Debug] [4292671824] transport/internet: dialing to udp:1.1.1.1:53
2025/03/20 10:02:25.934397 [Info] [4292671824] proxy/freedom: connection opened to udp:1.1.1.1:53, local endpoint [::]:53818, remote endpoint 1.1.1.1:53
2025/03/20 10:02:27.120088 [Info] [21297520] proxy/vless/inbound: firstLen = 164
2025/03/20 10:02:27.120147 [Info] [21297520] proxy/vless/inbound: received request for udp:1.1.1.1:53
2025/03/20 10:02:27.121671 [Info] [21297520] app/dispatcher: default route for udp:1.1.1.1:53
2025/03/20 10:02:27.121709 [Debug] [21297520] transport/internet: dialing to udp:1.1.1.1:53
2025/03/20 10:02:27.122501 [Info] [21297520] proxy/freedom: connection opened to udp:1.1.1.1:53, local endpoint [::]:43320, remote endpoint 1.1.1.1:53
2025/03/20 10:02:27.344914 [Info] [1118206648] proxy/vless/inbound: firstLen = 442
2025/03/20 10:02:27.344971 [Info] [1118206648] proxy/vless/inbound: received request for tcp:www.google.com:443
2025/03/20 10:02:27.347463 [Info] [1118206648] app/dispatcher: sniffed domain: www.google.com
2025/03/20 10:02:27.347507 [Info] [1118206648] app/dispatcher: default route for tcp:www.google.com:443
2025/03/20 10:02:27.347514 [Info] [1118206648] transport/internet/tcp: dialing TCP to tcp:www.google.com:443
2025/03/20 10:02:27.347521 [Debug] [1118206648] transport/internet: dialing to tcp:www.google.com:443
2025/03/20 10:02:27.349762 [Info] [1172794748] proxy/vless/inbound: firstLen = 1938
2025/03/20 10:02:27.349796 [Info] [1172794748] proxy/vless/inbound: received request for tcp:www.youtube.com:443
2025/03/20 10:02:27.350893 [Info] [1172794748] app/dispatcher: sniffed domain: www.youtube.com
2025/03/20 10:02:27.350920 [Info] [1172794748] app/dispatcher: default route for tcp:www.youtube.com:443
2025/03/20 10:02:27.350928 [Info] [1172794748] transport/internet/tcp: dialing TCP to tcp:www.youtube.com:443
2025/03/20 10:02:27.350934 [Debug] [1172794748] transport/internet: dialing to tcp:www.youtube.com:443
2025/03/20 10:02:27.389446 [Info] [1172794748] proxy/freedom: connection opened to tcp:www.youtube.com:443, local endpoint [[[IPv6 VPS]]], remote endpoint [2a00:1450:4025:c01::c6]:443
2025/03/20 10:02:27.389490 [Info] [1172794748] proxy: CopyRawConn readv
2025/03/20 10:02:27.411780 [Info] [1118206648] proxy/freedom: connection opened to tcp:www.google.com:443, local endpoint [[[IPv6 VPS]]], remote endpoint [2a00:1450:4001:831::2004]:443
2025/03/20 10:02:27.411858 [Info] [1118206648] proxy: CopyRawConn readv
2025/03/20 10:02:27.483802 [Info] [968076251] proxy/vless/inbound: firstLen = 1940
2025/03/20 10:02:27.483840 [Info] [968076251] proxy/vless/inbound: received request for tcp:alive.github.com:443
2025/03/20 10:02:27.484771 [Info] [968076251] app/dispatcher: sniffed domain: alive.github.com
2025/03/20 10:02:27.484796 [Info] [968076251] app/dispatcher: default route for tcp:alive.github.com:443
2025/03/20 10:02:27.484803 [Info] [968076251] transport/internet/tcp: dialing TCP to tcp:alive.github.com:443
2025/03/20 10:02:27.484809 [Debug] [968076251] transport/internet: dialing to tcp:alive.github.com:443
2025/03/20 10:02:27.633982 [Info] [968076251] proxy/freedom: connection opened to tcp:alive.github.com:443, local endpoint [[[IPv4 VPS]]], remote endpoint 140.82.112.26:443
2025/03/20 10:02:27.634056 [Info] [968076251] proxy: CopyRawConn readv

. . .
. . .
. . .

2025/03/20 10:03:10.833286 [Info] [3537200014] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled
2025/03/20 10:03:35.114917 [Info] [968076251] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled
2025/03/20 10:03:36.285237 [Info] [1172794748] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled
2025/03/20 10:03:56.706699 [Info] [723832476] proxy/vless/inbound: firstLen = 2505
2025/03/20 10:03:56.706743 [Info] [723832476] proxy/vless/inbound: received request for tcp:www.youtube.com:443
2025/03/20 10:03:56.707715 [Info] [723832476] app/dispatcher: sniffed domain: www.youtube.com
2025/03/20 10:03:56.707735 [Info] [723832476] app/dispatcher: default route for tcp:www.youtube.com:443
2025/03/20 10:03:56.707742 [Info] [723832476] transport/internet/tcp: dialing TCP to tcp:www.youtube.com:443
2025/03/20 10:03:56.707757 [Debug] [723832476] transport/internet: dialing to tcp:www.youtube.com:443
2025/03/20 10:03:56.795050 [Info] [723832476] proxy/freedom: connection opened to tcp:www.youtube.com:443, local endpoint [[[IPv6 VPS]]], remote endpoint [2a00:1450:4025:c01::c6]:443
2025/03/20 10:03:56.795153 [Info] [723832476] proxy: CopyRawConn readv
2025/03/20 10:04:01.712845 [Info] [314810467] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer response payload > write unix /dev/shm/xhttp_client_upload.sock->@: write: broken pipe
2025/03/20 10:04:01.738249 [Info] [2401923821] proxy/vless/inbound: firstLen = 132
2025/03/20 10:04:01.738311 [Info] [2401923821] proxy/vless/inbound: received request for udp:8.8.8.8:53
2025/03/20 10:04:01.738681 [Info] [2401923821] app/dispatcher: default route for udp:8.8.8.8:53
2025/03/20 10:04:01.738700 [Debug] [2401923821] transport/internet: dialing to udp:8.8.8.8:53
2025/03/20 10:04:01.738715 [Info] [2401923821] proxy/freedom: connection opened to udp:8.8.8.8:53, local endpoint [::]:35168, remote endpoint 8.8.8.8:53
2025/03/20 10:04:01.777025 [Info] [4014026189] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer response payload > write unix /dev/shm/xhttp_client_upload.sock->@: write: broken pipe
2025/03/20 10:04:02.046401 [Info] [4042328374] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer response payload > write unix /dev/shm/xhttp_client_upload.sock->@: write: broken pipe
2025/03/20 10:04:02.165802 [Info] [1425870560] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer response payload > write unix /dev/shm/xhttp_client_upload.sock->@: write: broken pipe
2025/03/20 10:04:03.777134 [Info] [3039018458] proxy/vless/inbound: firstLen = 1974
2025/03/20 10:04:03.777172 [Info] [3039018458] proxy/vless/inbound: received request for tcp:rr2---sn-4g5ednkl.googlevideo.com:443
2025/03/20 10:04:03.778051 [Info] [3039018458] app/dispatcher: sniffed domain: rr2---sn-4g5ednkl.googlevideo.com
2025/03/20 10:04:03.778071 [Info] [3039018458] app/dispatcher: default route for tcp:rr2---sn-4g5ednkl.googlevideo.com:443
2025/03/20 10:04:03.778078 [Info] [3039018458] transport/internet/tcp: dialing TCP to tcp:rr2---sn-4g5ednkl.googlevideo.com:443
2025/03/20 10:04:03.778119 [Debug] [3039018458] transport/internet: dialing to tcp:rr2---sn-4g5ednkl.googlevideo.com:443
2025/03/20 10:04:03.810058 [Info] [3039018458] proxy/freedom: connection opened to tcp:rr2---sn-4g5ednkl.googlevideo.com:443, local endpoint [[[IPv6 VPS]]], remote endpoint [2a00:1450:4001:29::7]:443
2025/03/20 10:04:03.810099 [Info] [3039018458] proxy: CopyRawConn readv
2025/03/20 10:04:05.752782 [Info] [3849685554] proxy/vless/inbound: firstLen = 627
2025/03/20 10:04:05.752857 [Info] [3849685554] proxy/vless/inbound: received request for tcp:dns.google:443
2025/03/20 10:04:05.753637 [Info] [3849685554] app/dispatcher: sniffed domain: dns.google
2025/03/20 10:04:05.753680 [Info] [3849685554] app/dispatcher: default route for tcp:dns.google:443
2025/03/20 10:04:05.753742 [Info] [3849685554] transport/internet/tcp: dialing TCP to tcp:dns.google:443
2025/03/20 10:04:05.753754 [Debug] [3849685554] transport/internet: dialing to tcp:dns.google:443
2025/03/20 10:04:05.816951 [Info] [3849685554] proxy/freedom: connection opened to tcp:dns.google:443, local endpoint [[[IPv6 VPS]]], remote endpoint [2001:4860:4860::8888]:443
2025/03/20 10:04:05.816988 [Info] [3849685554] proxy: CopyRawConn readv
2025/03/20 10:04:07.844827 [Info] [723832476] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled
2025/03/20 10:04:09.106422 [Info] [1118206648] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled
2025/03/20 10:04:10.009407 [Info] [4169957325] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled

V2RayN log

. . . [Info] proxy/vless/outbound: tunneling request to udp:1.1.1.1:53 via CF CDN IP

[Info] [3245867330] app/proxyman/inbound: connection ends > proxy/http: connection ends > context canceled

[Info] app/dns: failed to lookup ip for domain www.youtube.com at server DOH//dns.google > context deadline exceeded

Info] features/routing/dns: resolve ip for www.youtube.com > app/dns: returning nil for domain www.youtube.com > multierr: context deadline exceeded | context deadline exceeded | context deadline exceeded |

[Info] [1117263667] app/dispatcher: taking detour [proxy] for [tcp:www.youtube.com:443]

[Error] app/dns: failed to retrieve response for www.youtube.com. > Post "https://dns.google/dns-query": context deadline exceeded

[Info] [1117263667] transport/internet/splithttp: XHTTP is dialing to udp:CF CDN IP, mode packet-up, HTTP version 3, host b.my.site

[Error] app/dns: failed to retrieve response for www.youtube.com. > Post "https://dns.google/dns-query": context deadline exceeded

from 127.0.0.1:4032 accepted //www.youtube.com:443 [socks -> proxy]

from DNS accepted https://dns.google/dns-query [xray.system.dd05e727-9e13-4286-8623-ce74efb9d867 -> proxy]

[Info] app/dispatcher: taking detour [proxy] for [tcp:dns.google:443]

[Info] [1117263667] proxy/vless/outbound: tunneling request to tcp:www.youtube.com:443 via CF CDN IP

[Info] transport/internet/splithttp: XHTTP is dialing to udp:CF CDN IP, mode packet-up, HTTP version 3, host b.my.site

[Info] proxy/vless/outbound: tunneling request to tcp:dns.google:443 via CF CDN IP

[Error] app/dns: failed to retrieve response for alive.github.com. > Post "https://dns.google/dns-query": context deadline exceeded

[Info] app/dispatcher: taking detour [proxy] for [tcp:dns.google:443]

from DNS accepted https://dns.google/dns-query [xray.system.dd05e727-9e13-4286-8623-ce74efb9d867 -> proxy]

[Info] transport/internet/splithttp: XHTTP is dialing to udp:CF CDN IP, mode packet-up, HTTP version 3, host b.my.site

[Info] proxy/vless/outbound: tunneling request to tcp:dns.google:443 via CF CDN IP

[Info] [2432620260] app/proxyman/inbound: connection ends > proxy/http: connection ends > context canceled

[Info] app/dns: failed to lookup ip for domain alive.github.com at server UDP:1.1.1.1:53 > context deadline exceeded

[Debug] app/dns: UDP:8.8.8.8:53 querying DNS for: alive.github.com.

[Info] transport/internet/udp: establishing new connection for udp:8.8.8.8:53

[Debug] transport/internet/udp: dispatch request to: udp:8.8.8.8:53

[Info] app/dispatcher: taking detour [proxy] for [udp:8.8.8.8:53]

from DNS accepted udp:8.8.8.8:53 [xray.system.dd05e727-9e13-4286-8623-ce74efb9d867 -> proxy]

[Info] transport/internet/splithttp: XHTTP is dialing to udp:CF CDN IP, mode packet-up, HTTP version 3, host b.my.site

[Info] proxy/vless/outbound: tunneling request to udp:8.8.8.8:53 via CF CDN IP

[Info] app/dns: failed to lookup ip for domain alive.github.com at server UDP:8.8.8.8:53 > context deadline exceeded

. . .

[Debug] transport/internet/udp: dispatch request to: udp:1.1.1.1:53

[Info] [1757992469] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: connection ends > proxy/vless/outbound: failed to transfer response payload > H3_MESSAGE_ERROR

[Info] [1757992469] app/proxyman/inbound: connection ends > proxy/http: connection ends > io: read/write on closed pipe

[Info] [3057622213] app/proxyman/inbound: connection ends > proxy/http: connection ends > context canceled

. . .

access_xhttp.log

. . .

"POST b.my.site/MY PATH/6fff4591-6140-4a0c-a62d-9a3f4700096e/0 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.002ms 0.003ms
"POST b.my.site/MY PATH/6fff4591-6140-4a0c-a62d-9a3f4700096e/1 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.002ms 0.002ms
"GET b.my.site/MY PATH/0e9d3c61-b9c9-410a-ae43-cc7a970ec67f HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 71.088ms 71.087ms
"GET b.my.site/MY PATH/31def552-4c5a-4e88-9d66-dc66035a292e HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 60.260ms 60.260ms
"POST b.my.site/MY PATH/a23b23aa-a36f-49a9-a886-fe87c7b9827a/0 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.001ms 0.002ms
"POST b.my.site/MY PATH/a23b23aa-a36f-49a9-a886-fe87c7b9827a/1 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.001ms 0.002ms
"POST b.my.site/MY PATH/86f2a216-02d6-4685-b4b0-128a1aa6c299/0 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.004ms 0.003ms
"GET b.my.site/MY PATH/68312d53-a553-48a5-9806-fe645e532625 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 71.071ms 71.072ms
"POST b.my.site/MY PATH/32b44670-c587-41ee-a566-f2171e73fe6e/0 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.001ms 0.002ms
"POST b.my.site/MY PATH/6fff4591-6140-4a0c-a62d-9a3f4700096e/2 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.002ms 0.001ms
"POST b.my.site/MY PATH/6fff4591-6140-4a0c-a62d-9a3f4700096e/3 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.001ms 0.001ms
"POST b.my.site/MY PATH/3f6d6ab5-2e6b-4a23-b1e1-35167054d3fc/0 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.001ms 0.001ms
"POST b.my.site/MY PATH/58a1f7ff-3f9c-4a4e-b1a1-6119db98f3b4/0 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 0.001ms 0.001ms
"GET b.my.site/MY PATH/2a6dd3f5-50f5-418f-adee-c6aa6157598b HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 71.085ms 71.085ms
"GET b.my.site/MY PATH/59fc9c61-16d6-4509-acf7-9385756bdf74 HTTP/2.0" 200 0B "b.my.site" "quic-go HTTP/3" 71.120ms 71.119ms

. . .

1 reply

fish4terrisa-MSDSM Mar 25, 2025

这种拥堵我这边也有遇到过(我使用的是h2，对于stream-up和packet-up都存在），尤其是在git clone大型仓库，进行长时间下载或者上传时。一般情况我会在不同域名的服务器间进行切换
同时我发现一个奇怪的现象：
我有多台服务器，每个服务器上有多个xray outbound，每个服务器上的多个xray outbound走同一caddy反代，同一域名，但不同路径。
如果我出现拥堵（断流）后，切换至同一域名下的另一xray outbound，速度仍然十分缓慢。但是如果切换至另一域名的服务器，情况就大幅度缓解。
我个人也猜测是cdn的问题，值得注意的是这种拥堵似乎仅限一个二级域名，不会扩散到整个域中，因此如果可以让一个服务器使用多个域名，xray在多个域名之间进行轮询似乎可能解决这个问题(但是我不清楚这是否可能，v2rayNG目前没有这样的选项）。值得注意的是单纯的大量长时间上传或者下载就足以使阻断发生，因此上下载分流似乎无法解决这个问题。。。

XHTTP: Beyond REALITY #4113

RPRX Dec 5, 2024 Maintainer

中文 | Русский

XHTTP: Beyond REALITY

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

快速上手指南

两个底层逻辑

PACKET-UP

H1 / H2 / H3

XMUX

STREAM-UP/ONE

上下行分离

Beyond REALITY

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

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

Replies: 61 comments · 245 replies

中文 | Русский

XHTTP: За гранью REALITY

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

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

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

PACKET-UP

H1 / H2 / H3

XMUX

STREAM-UP/ONE

Разделение загрузки и выгрузки

Beyond REALITY

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

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

RPRX Dec 8, 2024 Maintainer Author

RPRX Dec 6, 2024 Maintainer Author

RPRX Dec 18, 2024 Maintainer Author

RPRX Dec 14, 2024 Maintainer Author

RPRX Dec 14, 2024 Maintainer Author

RPRX Dec 5, 2024 Maintainer Author

RPRX Dec 5, 2024 Maintainer Author

RPRX Dec 7, 2024 Maintainer Author

RPRX Dec 18, 2024 Maintainer Author

yuhan6665 Jan 21, 2025 Maintainer

yuhan6665 Jan 22, 2025 Maintainer

RPRX
Dec 5, 2024
Maintainer

Replies: 61 comments 245 replies

RPRX Dec 8, 2024
Maintainer Author

RPRX Dec 6, 2024
Maintainer Author

RPRX Dec 18, 2024
Maintainer Author

RPRX Dec 14, 2024
Maintainer Author

RPRX Dec 14, 2024
Maintainer Author

RPRX Dec 5, 2024
Maintainer Author

RPRX Dec 5, 2024
Maintainer Author

RPRX Dec 7, 2024
Maintainer Author

RPRX Dec 18, 2024
Maintainer Author

yuhan6665 Jan 21, 2025
Maintainer

yuhan6665 Jan 22, 2025
Maintainer