the right xhttp stream up configuration for CDNs

[shakibamoshiri]

I ran many tests with the latest xray version (xray-26.7.28 and older ones) to figure out the proper setup for "stream-up" mode but I am unsatisfied with the speed. All the tests were run in reverse-mode (portal and bridge setup)

setups

# connection 
freedom ====> bridge ===> middleware ====> portal 

# flow 
freedom <==== bridge <=== middleware <==== portal 

# download ? limited to 5Mpbs ~ 7Mbps
# upload ? no limit

---

here are the test steps

xray (with tls) to xray (tls enabled)

no problem no overhead

xray (with tls) to haproxy (tls offloaded) to xray

With haproxy mode tcp paththrough there is no issue
With haproxy mode http and h2 enabled download speed stays near 5Mbps (bridge side test)

xray (with tls) to CDN to haproxy (tls offloaded) to xray

With haproxy mode tcp paththrough , it does not work , CDN error
With haproxy mode http and h2 enabled , download speed stays near 5Mbps (bridge side test)

• CDN grpc has been enabled

xray (with tls) to CDN to xray (tls enabled)

it does not work , CDN error

• CDN grpc has been enabled
• the CDN required h2 be advertised by the web-server (not sure if xray does this?)

---

sample bridge side

  "outbounds": [
    {
      "tag": "to-portal",
      "protocol": "vless",
      "settings": {
        "address": "PUBLCI_IP",
        "port": PORT,
        "id": "UUID",
        "flow": "",
        "encryption": "none",
        "alpn": [
          "h2"
        ],
        "reverse": {
          "tag": "reverse-in",
          "sniffing": {}
        }
      },
      "streamSettings": {
        "security": "tls",
        "network": "xhttp",
        "xhttpSettings": {
          "path": "/PATH",
          "host": "my.domain.name",
          "mode": "stream-up"
        },
        "tlsSettings": {
          "serverName": "my.domain.name",
          "alpn": [
            "h2"
          ]
        },
        "finalmask": {
          "tcp": []
        }
      }
    },

and portal side sample (this is behind haproxy)

    {
      "tag": "vless-in",
      "listen": "127.0.0.1",
      "port": PORT,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "UUID",
            "email": "bridge",
            "reverse": {
              "tag": "reverse-out"
            }
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "none",
          "xhttpSettings": {
          "path": "/PATH"
        }
      },

      "sniffing": {
        "enabled": true
      }
    }

I should mention I have tried other objects like

• xmux

                  "xmux": {
                    "maxConcurrency": 1,
                    "hMaxRequestTimes": 1000,
                    "hMaxReusableSecs": 3600
                  }

• downloadSettings

            "downloadSettings": {
              "address": "PUBLIC_IP",
              "port": PORT,
              "id": "UUID",
              "flow": "",
              "encryption": "none",
              "alpn": [
                "h2"
              ],
              "reverse": {
                "tag": "reverse-in",
                "sniffing": {}
              },

• nginx with grpc_pass h2 enabled

---

here is a sample iperf test (bridge side), haproxy in between

download stays near 5Mbps
upload has no limit

iperf3 --client 127.0.0.1 --port PORT --time 5 --reverse

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec
[  5]   1.00-2.00   sec   384 KBytes  3.15 Mbits/sec
[  5]   2.00-3.00   sec   384 KBytes  3.15 Mbits/sec
[  5]   3.00-4.00   sec   512 KBytes  4.20 Mbits/sec
[  5]   4.00-5.00   sec   512 KBytes  4.19 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-5.52   sec  12.8 MBytes  19.4 Mbits/sec    3            sender
[  5]   0.00-5.00   sec  1.88 MBytes  3.15 Mbits/sec                  receiver

nginx could only handle near 512Kbps

---

portal side log when iperf is run

2026/08/30 20:21:16.576336 [Info] [3959241084] proxy/dokodemo: received request for 127.0.0.1:50562
2026/08/30 20:21:16.576756 [Info] [3959241084] app/dispatcher: taking detour [reverse-out] for [tcp:127.0.0.1:10321]
2026/08/30 20:21:16.576819 [Info] [3959241084] common/mux: dispatching request to tcp:127.0.0.1:10321
2026/08/30 20:21:16.576336 from 127.0.0.1:50562 accepted tcp:127.0.0.1:10321 [ipef3 -> reverse-out]
2026/08/30 20:21:16.659041 [Info] [939711489] proxy/dokodemo: received request for 127.0.0.1:50564
2026/08/30 20:21:16.659084 [Info] [939711489] app/dispatcher: taking detour [reverse-out] for [tcp:127.0.0.1:10321]
2026/08/30 20:21:16.659091 [Info] [939711489] common/mux: dispatching request to tcp:127.0.0.1:10321
2026/08/30 20:21:16.659047 from 127.0.0.1:50564 accepted tcp:127.0.0.1:10321 [ipef3 -> reverse-out]
2026/08/30 20:21:21.915572 [Info] [939711489] common/mux: failed to fetch all input > read tcp 127.0.0.1:10123->127.0.0.1:50564: read: connection reset by peer
2026/08/30 20:21:21.915702 [Info] common/mux: failed to write to downstream. closing session 3 > write tcp 127.0.0.1:10123->127.0.0.1:50564: write: broken pipe

birdge side log when iperf is run

2026/08/30 20:21:16.562284 [Info] common/mux: received request for tcp:127.0.0.1:10321
2026/08/30 20:21:16.562402 [Info] app/dispatcher: taking detour [direct] for [tcp:127.0.0.1:10321]
2026/08/30 20:21:16.562438 [Info] transport/internet/tcp: dialing TCP to tcp:127.0.0.1:10321
2026/08/30 20:21:16.562456 [Debug] transport/internet: dialing to tcp:127.0.0.1:10321
2026/08/30 20:21:16.562513 from tcp:127.0.0.1:50562 accepted tcp:127.0.0.1:10321 [reverse-in -> direct]
2026/08/30 20:21:16.562850 [Info] proxy/freedom: connection opened to tcp:127.0.0.1:10321, local endpoint 127.0.0.1:38832, remote endpoint 127.0.0.1:10321
2026/08/30 20:21:16.562879 [Debug] proxy: CopyRawConn (maybe) readv
2026/08/30 20:21:16.645144 [Info] common/mux: received request for tcp:127.0.0.1:10321
2026/08/30 20:21:16.645392 [Info] app/dispatcher: taking detour [direct] for [tcp:127.0.0.1:10321]
2026/08/30 20:21:16.645428 [Info] transport/internet/tcp: dialing TCP to tcp:127.0.0.1:10321
2026/08/30 20:21:16.645448 [Debug] transport/internet: dialing to tcp:127.0.0.1:10321
2026/08/30 20:21:16.645455 from tcp:127.0.0.1:50564 accepted tcp:127.0.0.1:10321 [reverse-in -> direct]
2026/08/30 20:21:16.645822 [Info] proxy/freedom: connection opened to tcp:127.0.0.1:10321, local endpoint 127.0.0.1:38836, remote endpoint 127.0.0.1:10321
2026/08/30 20:21:16.645852 [Debug] proxy: CopyRawConn (maybe) readv
2026/08/30 20:21:21.910794 [Info] common/mux: session 2 ends. > io: read/write on closed pipe
2026/08/30 20:21:22.371489 [Info] common/mux: session 3 ends. > io: read/write on closed pipe

---

what can be the cause of this bandwidth limit ? and how to fix it?

Regards

[shakibamoshiri]

the head of line blocking in h2 link
and haproxy issue prior to version 3.2 to properly handle h2

[Anderhar]

Also faced a somewhat similar downlink/uplink asymmetry when trying to pass XHTTP Reverse tunnel through Nginx to xray-core placed behind it (the speed difference was ~15 times!).
Moving xray-core in front of Nginx in the Reality self-steal mode solved the problem for me.