[feature request] XHTTP Support packet down & retransmission

[hyperion-cs]

Problem

A few weeks ago, a new method of blocking (especially on mobile networks) was introduced in Russia by the censor.
It works as follows. So, if:

1. The client connects to the server via TCP using HTTPS and TLS 1.3 (Reality actually mimics HTTPS with TLS 1.3);
2. The IP address of the server is “suspicious” (it is located outside (i.e. not in Russia), is part of the subnet AS which is owned by foreign data centers like Hetzner, Digital Ocean, etc.);
3. Within one TCP connection (not within one HTTP request/response - this is important) the data size received from the server to the client is more than ≈15-20KB (the value varies depending on the provider) — the MAIN thing.

This connection is "frozen" (i.e. TCP packets from the server within this connection stop arriving after the specified limit on the size of transmitted data has been reached). It is curious to note that, as a rule, the censor (under the pretence of a response from the server) does not send, for example, an RST packet - instead, it simply “freezes” the TCP connection (from the client's point of view), and thus the client simply waits for an error on the timeout of waiting for a response from the server and everything stops working.

IMPORTANT: It doesn't matter whether it's "legitimate" HTTPS traffic or whether someone is mimicking it. They don't pay attention to that now.

Do I have these limitations?

You can check your "home" ISP with the RU :: TCP 16-20 checker from this repository. Works right from your browser, VPN should be disabled during the check.

Proposed Solution

The good news is that if you fragment the responses from the server into several ≈15-20KB data bundles (if it is large enough) in different TCP connections, everything will work fine. This is the option I propose to add to Reality (where the size of the data bundle will be set by a parameter), which would be compatible with VLESS.

It is important not to confuse this with fragmentation of TCP packets within one connection or splitting of transmitted data into several HTTP requests/responses (in one connection) - this is different and it won't help.

By the way, the same rules will probably apply to client-to-server traffic (if not already done by the censor) - so the fragmentation option described is worth adding on both server and client. And support for fragmented data, of course.

Notes

Yes, it will work noticeably slower than a single connection (especially if we're going to upload/download a large file). For example, it would take ~2560 TCP connections to download a 50MB file - that's a lot and quite suspicious. But it's clearly better than not working at all. Anyway, this issue will help to publicize the problem and maybe someone will think of better solutions.

---

Some links to related issues:

• https://blog.cloudflare.com/russian-internet-users-are-unable-to-access-the-open-internet/
• BurstObservatory: add option to set http method for burst check #4835 (comment)
• [Russia] Censor has a new method of blocking net4people/bbs#490
• https://ntc.party/t/09062025-%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8F-%D0%BF%D0%BE-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B5-cloudflare-ovh-hetzner-digitalocean/17013

[hyperion-cs]

❗ For those who are in Russia and suffer from the problem (VLESS/Reality): at the moment the only way I know of to get around this problem (without implementing the functionality above) is to use an intermediate server in Russia, which itself is not analyzed by the censor under the “new” rules. Probably, large data centers connected directly to the main communication channels ("магистральные каналы связи") would be suitable.

This intermediate server should be configured as a transparent TCP proxy to the server with VLESS/Reality (which will already be out of the country, abroad). For this purpose you can use iptables, HAProxy, etc. Clients will have to change the host to the intermediate server (leave the other settings the same).

upd: TLS 1.2 is also blocked (sometimes there is a different data size limit per TCP connection). However, SSH works without restrictions (it seems you can use SSH tunnel or mimic it).

[Fangliding]

20 kb就双向丢弃和被屏蔽了没有区别 这没有意义再去捞了
你们需要的可能是发明一个只会在一条tcp连接上传输20kb的新协议而不是修改现有协议 不过即使是这样效率也会低到令人发指

[RPRX]

最近有点无聊，想给 XHTTP 的下行也搞出上行那种流量聚合了，反正客户端 hub 可以大量复用上行的代码

[Fangliding]

虽然有packet down是好的 但是xhttp现在的上行机制至少也可以利用h2 mux h1.1 keepalive
20kb只有xhttp默认最大post长度的2％ 太小了 1MB的数据传下来要切成50个小部分还得通过50个独立的tcp连接接收 更别说xhttp无法从错误中恢复 这50个tcp连接任何一个被稍微阻断连接直接断开

[RPRX]

其实我只是想给 XHTTP 加上聚合不同线路下载速度的能力，就像 mptcp，mekya 那些，但非常简单，具体效果几何需要实测，就像我说过的，如果单连接限速不明显，或者本来就是多线程下载，那就没什么提升，不过叠不同线路会不会对单线程有惊喜，可以试试

就叫“多路径下行”吧，不光 TCP，还能叠上 UDP，实现这个 issue 所述的目标只是顺带的，如果不小心实现了 PLUX 也是顺带的

[RPRX]

还有，一旦有了自定义的下行包装格式，HTTP 下行就可以保活了，不会被 CDN 100s 不活跃掐断，虽然我觉得这 100s 挺合理的

还有玩得更花的，总是有人提“迁移现有连接”，以后再看看要不要补上 ACK 机制吧

所以 XHTTP 终究还是不需要 mux.cool 了，XUDP 除外

[zzlinwq]

支持大佬 大佬比起马斯克有过之而无不及

[RPRX]

https://t.me/projectXray/4386271

[Sebulba46]

❗ For those who are in Russia and suffer from the problem (VLESS/Reality): at the moment the only way I know of to get around this problem (without implementing the functionality above) is to use an intermediate server in Russia, which itself is not analyzed by the censor under the “new” rules. Probably, large data centers connected directly to the main communication channels ("магистральные каналы связи") would be suitable.

This intermediate server should be configured as a transparent TCP proxy to the server with VLESS/Reality (which will already be out of the country, abroad). For this purpose you can use iptables, HAProxy, etc. Clients will have to change the host to the intermediate server (leave the other settings the same).

upd: TLS 1.2 is also blocked (sometimes there is a different data size limit per TCP connection). However, SSH works without restrictions (it seems you can use SSH tunnel or mimic it).

So I'm trying to replicate idea with proxy server in Russia but I want to connect to proxy server through wireguard and then route traffic using iptables to the vless client config accepting connections on port 1080.
My wireguard setup:

[Interface]
PrivateKey = ***
Address = 10.20.10.1/24
ListenPort = 51820
PostUp = iptables -t nat -A PREROUTING -i wg0 -p tcp -j REDIRECT --to-port 1080
PostUp = iptables -t nat -A PREROUTING -i wg0 -p udp -j REDIRECT --to-port 1080
PostUp = iptables -t nat -A POSTROUTING -o ens1 -j MASQUERADE
PostDown = iptables -t nat -D PREROUTING -i wg0 -p tcp -j REDIRECT --to-port 1080
PostDown = iptables -t nat -D PREROUTING -i wg0 -p udp -j REDIRECT --to-port 1080
PostDown = iptables -t nat -D POSTROUTING -o ens1 -j MASQUERADE
DNS = 9.9.9.9


[Peer]
PublicKey = ***
AllowedIPs = 10.20.10.2/32

xray config:

{
  "inbounds": [
    {
      "port": 1080,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": ***,
            "port": 443,
            "users": [
              {
                "id": ***,
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "publicKey": ***,
          "fingerprint": "chrome",
          "serverName": "www.github.com",
          "shortId": "aabbccdd"
        }
      }
    },
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ],
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Using this setup i can connect to the proxy server through wireguard, but forwarding is not working. And xray itselft is working fine: i can curl https://medium.com. Could you please help me?