C/S都是v25.3.6，xhttp使用stream-up/one过cf会发生断流

[CharlesWou]

完整性要求

• 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我提供了完整的配置文件和日志，而不是出于自己的判断只给出截取的部分。
• 我搜索了 issues, 没有发现已提出的类似问题。
• 问题在 Release 最新的版本上可以成功复现

描述

C/S都是v25.3.6
xhttp使用stream-up/one过cf会发生断流，使用packet-up过cf则不会发生断流
直连的话，使用stream-up/one/packet-up都正常

重现方式

服务端：xray前置监听vless+tcp+tls，回落到caddy，caddy再将h2转回xray处理xhttp
客户端：xhttp+stream-up/one+cf

v2rayN客户端（Windows），连续测试真连接延迟多次后会出现延迟显示为-1
v2rayNG客户端（Android），连续点击最下方测试连接后，日志会出现Get “https://www.google.com/genereate_204”：net/http: TLS Handshake timeout

客户端配置

Details

  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "xxxxxxxxxxxxxxxxxx",
            "port": 443,
            "users": [
              {
                "id": "xxxxxxxxxxxxxxxxxx",
                "email": "t@t.tt",
                "security": "auto",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "tls",
        "tlsSettings": {
          "allowInsecure": false,
          "fingerprint": "safari"
        },
        "xhttpSettings": {
          "path": "/xxxxxxxxxxxxxxxxxx",
          "mode": "auto"
        }
      },
      "mux": {
        "enabled": false,
        "concurrency": -1
      }
    }

服务端配置

Details

  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "xxxxxxxxxxxxxxxxxx",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none",
        "fallbacks": [
          {
            "dest": "@udsh2.sock",
            "xver": 1
          }
        ]
      },
      "streamSettings": {
        "network": "raw",
        "rawSettings": {
          "acceptProxyProtocol": false
        },
        "security": "tls",
        "tlsSettings": {
          "certificates": [
            {
              "ocspStapling": 3600,
              "certificateFile": "xxxxxxxxxxxxxxxxxx",
              "keyFile": "xxxxxxxxxxxxxxxxxx"
            }
          ],
          "rejectUnknownSni": true,
          "minVersion": "1.2"
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic"
        ]
      }
    },
    {
      "listen": "@udsxhttp.sock",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "xxxxxxxxxxxxxxxxxx"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "path": "/xxxxxxxxxxxxxxxxxx"
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic"
        ]
      }
    }
  ]

客户端日志

Details

Xray 25.3.6 (Xray, Penetrates Everything.) 2cba2c4 (go1.24.1 windows/amd64)
A unified platform for anti-censorship.
2025/03/21 20:16:05.530869 [Info] infra/conf/serial: Reading config: &{Name:configTest5476010959613915098.json Format:json}
2025/03/21 20:16:05.531920 [Debug] app/log: Logger started
2025/03/21 20:16:05.544971 [Debug] app/proxyman/inbound: creating stream worker on 127.0.0.1:10829
2025/03/21 20:16:05.544971 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10829
2025/03/21 20:16:05.544971 [Warning] core: Xray 25.3.6 started
2025/03/21 20:16:06.001145 [Info] [2365538489] proxy/socks: TCP Connect request to tcp:www.google.com:443
2025/03/21 20:16:06.001145 [Info] [2365538489] app/dispatcher: taking detour [proxy10829] for [tcp:www.google.com:443]
2025/03/21 20:16:06.001145 from tcp:127.0.0.1:59172 accepted tcp:www.google.com:443 [socks10829 -> proxy10829]
2025/03/21 20:16:06.001374 [Debug] [2365538489] transport/internet/splithttp: XMUX: creating xmuxClient because xmuxClients is empty
2025/03/21 20:16:06.001374 [Info] [2365538489] transport/internet/splithttp: XHTTP is dialing to tcp:test.example.com:443, mode stream-up, HTTP version 2, host test.example.com
2025/03/21 20:16:06.001374 [Debug] [2365538489] transport/internet: dialing to tcp:test.example.com:443
2025/03/21 20:16:06.141853 [Info] [2365538489] proxy/vless/outbound: tunneling request to tcp:www.google.com:443 via test.example.com:443
2025/03/21 20:16:16 测试完成
2025/03/21 20:16:49.695218 [Info] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: connection ends > proxy/vless/outbound: failed to transfer response payload > proxy/vless/encoding: failed to read packet length > stream error: stream ID 1; INTERNAL_ERROR; received from peer
2025/03/21 20:16:49.695218 [Info] transport/internet/udp: failed to handle UDP input > io: read/write on closed pipe

服务端日志

Details

2025/03/21 20:16:02.468789 [Info] [1201649152] proxy/vless/inbound: firstLen = 24
2025/03/21 20:16:02.468832 [Info] [1201649152] proxy/vless/inbound: fallback starts > proxy/vless/encoding: invalid request version
2025/03/21 20:16:02.468837 [Info] [1201649152] proxy/vless/inbound: realName = test.example.com
2025/03/21 20:16:02.468843 [Info] [1201649152] proxy/vless/inbound: realAlpn = h2
2025/03/21 20:16:02.498618 [Info] [3699439340] proxy/vless/inbound: firstLen = 24
2025/03/21 20:16:02.498645 [Info] [3699439340] proxy/vless/inbound: fallback starts > proxy/vless/encoding: invalid request version
2025/03/21 20:16:02.498649 [Info] [3699439340] proxy/vless/inbound: realName = test.example.com
2025/03/21 20:16:02.498652 [Info] [3699439340] proxy/vless/inbound: realAlpn = h2
2025/03/21 20:16:02.499502 [Info] [1838405692] proxy/vless/inbound: firstLen = 442
2025/03/21 20:16:02.499540 [Info] [1838405692] proxy/vless/inbound: received request for tcp:www.google.com:443
2025/03/21 20:16:02.499613 [Info] [1838405692] app/dispatcher: sniffed domain: www.google.com
2025/03/21 20:16:02.499635 [Info] [1838405692] app/dispatcher: taking detour [IPv6-out] for [tcp:www.google.com:443]
2025/03/21 20:16:02.499654 [Debug] app/dns: domain www.google.com will use DNS in order: [localhost]
2025/03/21 20:16:02.500287 [Info] app/dns: Localhost got answer: www.google.com -> [2404:6800:4004:810::2004]
2025/03/21 20:16:02.500306 [Info] [1838405692] proxy/freedom: dialing to tcp:[2404:6800:4004:810::2004]:443
2025/03/21 20:16:02.500313 [Info] [1838405692] transport/internet/tcp: dialing TCP to tcp:[2404:6800:4004:810::2004]:443
2025/03/21 20:16:02.500317 [Debug] [1838405692] transport/internet: dialing to tcp:[2404:6800:4004:810::2004]:443
2025/03/21 20:16:02.501685 [Info] [1838405692] proxy/freedom: connection opened to tcp:www.google.com:443, local endpoint [xxxxxxxxxxx]:45022, remote endpoint [xxxxxxxx]:443
2025/03/21 20:16:02.501703 [Info] [1838405692] proxy: CopyRawConn readv
2025/03/21 20:16:03.028683 [Info] [1838405692] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > stream error: stream ID 37; CANCEL
2025/03/21 20:16:06.468972 [Info] [1044116248] proxy/vless/inbound: firstLen = 24
2025/03/21 20:16:06.469006 [Info] [1044116248] proxy/vless/inbound: fallback starts > proxy/vless/encoding: invalid request version
2025/03/21 20:16:06.469011 [Info] [1044116248] proxy/vless/inbound: realName = test.example.com
2025/03/21 20:16:06.469015 [Info] [1044116248] proxy/vless/inbound: realAlpn = h2
2025/03/21 20:16:16.171597 [Info] [2013400899] proxy/vless/inbound: firstLen = 0
2025/03/21 20:16:16.171625 [Info] [2013400899] app/proxyman/inbound: connection ends > proxy/vless/encoding: failed to read request version > EOF
2025/03/21 20:16:49.766073 [Info] [3273299670] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > proxy/vless/encoding: failed to read packet length > stream error: stream ID 3; NO_ERROR

Caddy日志

Details

2025/03/21 20:16:03.028	WARN	http.handlers.reverse_proxy	aborting with incomplete response	{"upstream": "unix/@udsxhttp.sock", "duration": 0.000501203, "request": {"remote_ip": "172.68.225.90", "remote_port": "50130", "client_ip": "172.68.225.90", "proto": "HTTP/2.0", "method": "POST", "host": "test.example.com", "uri": "/xxxxxxxxxxx/7631f62f-b0c9-4888-a9d8-de395f4a50f3", "headers": {"Cf-Ray": ["923d60ce3c718553-HKG"], "Referer": ["https://test.example.com/xxxxxxxxxxx/7631f62f-b0c9-4888-a9d8-de395f4a50f3?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"], "Content-Type": ["application/grpc"], "Te": ["trailers"], "Accept-Encoding": ["identity"], "Cf-Ipcountry": ["CN"], "User-Agent": ["Go-http-client/2.0"], "Cf-Visitor": ["{\"scheme\":\"https\"}"], "X-Forwarded-Proto": ["http"], "Cdn-Loop": ["cloudflare; loops=1"], "X-Forwarded-For": ["172.68.225.90"], "Cf-Connecting-Ip": ["xxxxxxxxxxx"], "X-Forwarded-Host": ["test.example.com"]}}, "error": "reading: stream error: stream ID 1; CANCEL"}
2025/03/21 20:16:16.171	WARN	http.handlers.reverse_proxy	aborting with incomplete response	{"upstream": "unix/@udsxhttp.sock", "duration": 0.000356842, "request": {"remote_ip": "172.71.214.90", "remote_port": "54692", "client_ip": "172.71.214.90", "proto": "HTTP/2.0", "method": "GET", "host": "test.example.com", "uri": "/xxxxxxxxxxx/f4eff6e7-0cd6-449c-8fe8-ddbf3e7b8668", "headers": {"Referer": ["https://test.example.com/xxxxxxxxxxx/f4eff6e7-0cd6-449c-8fe8-ddbf3e7b8668?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"], "Accept-Encoding": ["gzip, br"], "Cf-Ipcountry": ["CN"], "X-Forwarded-Proto": ["http"], "X-Forwarded-Host": ["test.example.com"], "User-Agent": ["Go-http-client/2.0"], "Cf-Visitor": ["{\"scheme\":\"https\"}"], "Cf-Ray": ["923d60e72e11045f-HKG"], "Cdn-Loop": ["cloudflare; loops=1"], "Cf-Connecting-Ip": ["xxxxxxxxxxx"], "X-Forwarded-For": ["172.71.214.90"]}}, "error": "reading: context canceled"}
2025/03/21 20:16:49.764	WARN	http.handlers.reverse_proxy	aborting with incomplete response	{"upstream": "unix/@udsxhttp.sock", "duration": 0.001338808, "request": {"remote_ip": "162.158.193.21", "remote_port": "58828", "client_ip": "162.158.193.21", "proto": "HTTP/2.0", "method": "GET", "host": "test.example.com", "uri": "/xxxxxxxxxxx/d546aa24-7eac-4305-a318-4a756293dbab", "headers": {"Referer": ["https://test.example.com/xxxxxxxxxxx/d546aa24-7eac-4305-a318-4a756293dbab?x_padding=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"], "X-Forwarded-Proto": ["http"], "Cf-Connecting-Ip": ["xxxxxxxxxxx"], "Cdn-Loop": ["cloudflare; loops=1"], "X-Forwarded-Host": ["test.example.com"], "Accept-Encoding": ["gzip, br"], "X-Forwarded-For": ["162.158.193.21"], "User-Agent": ["Go-http-client/2.0"], "Cf-Visitor": ["{\"scheme\":\"https\"}"], "Cf-Ray": ["923d5f84592a03d7-HKG"], "Cf-Ipcountry": ["CN"]}}, "error": "reading: context canceled"}

[RPRX]

看看有没有别人能复现

[CharlesWou]

使用同一个结点，访问同一个网址，用Chrome浏览器F12监测Network，发现页面加载时间上有明显差异（每次测试完都是关闭浏览器重新打开，避免了缓存），stream-up/one加载中间会断流，加载要30s，而packet-up则在5s左右

网址1：

网址2：

[RPRX]

如果真有问题的话，可能和 ce6c0dc 有关

说实话我自己用的也是 packet-up，因为这个经过我几轮优化后表现已经不输 stream-up 了，况且 CDN 对单连接上行总量有限制

[RPRX]

你试试把双端都换成 v25.1.1，看看问题还存不存在

[CharlesWou]

C/S都换为25.1.1后测试stream-up没有断流

网址1：

网址2：

[wtfr-dot]

最近一段时间我wsl编译openwrt时经常在git代码的时候在进行连接时没反应，然后经过一段时间后提示tls错误，始终觉得xray哪里有点不对，看见这个帖子后我将服务器的日志改成debug后发现了大量与楼主一样的错误日志，我也是通过cf，然后再使用nginx反代。
2025/03/21 22:08:42.572596 [Info] [1557281591] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > stream error: stream ID 1; NO_ERROR
2025/03/21 22:08:45.076615 [Info] [2977085455] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > proxy/vless/encoding: failed to read packet length > stream error: stream ID 1; NO_ERROR
2025/03/21 22:08:45.081242 [Info] [3137603736] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > proxy/vless/encoding: failed to read packet length > stream error: stream ID 1; NO_ERROR

2025/03/21 22:10:17.832547 [Info] [1345978706] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > stream error: stream ID 1; NO_ERROR
2025/03/21 22:10:21.867495 [Info] [2539897702] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > stream error: stream ID 1; NO_ERROR

[RPRX]

@CharlesWou 两个版本的 stream-one 有区别吗，你确定测试了 v25.3.6 的 stream-one 吗

[CharlesWou]

刚才试了下，奇怪，原有故障现象全没有了，还原3.6后，stream-up/one也都又正常了，只能猜测，可能在CDN网络通路差的情况下，使用packet-up可靠性更高

[RPRX]

如果你网络状况良好，resp, err := c.client.Do(req) 就不会返回 err，就不会导致底层连接被标记为 closed

这个标记是有必要的，因为 Golang h2 库感知不到“切换网络”，不标记、只等健康检查的话可能会断流几十秒

[RPRX]

https://github.com/XTLS/Xray-core/commits/main/transport/internet/splithttp 其它 commit 看起来不可疑

[CharlesWou]

如果你网络状况良好，resp, err := c.client.Do(req) 就不会返回 err，就不会导致底层连接被标记为 closed

这个标记是有必要的，因为 Golang h2 库感知不到“切换网络”，不标记、只等健康检查的话可能会断流几十秒

你提到了切换网络，我想起一个疑问，就是我这个caddy日志里面的确同一时间收到了3个不同的remote_ip/client_ip。是不是由于cdn网络通路查，所以cdn到xray之间可能有些问题，所以cdn才尝试了3个ip

[i-eat-helicopter]

I can reproduce this issue with Cloudflare + vless/xhttp, using Caddy as a reverse proxy. The Xray version I'm currently on is 25.3.31, built from git.

I tested with httping 1.1.1.4 -t 2 and found that 50% of requests failed due to timeout. But, both tcdump and Xray logs on the server indicated that packets related to these requests were received.

I don't believe this is an issue with national firewall. Using a client from the US yielded the same behavior.

This doesn't happen when I use Packet-Up.

[wtfr-dot]

我也是将stream-up模式改为packet-up后网络恢复正常了，最明显的是虚拟机里git操作在改协议生效的瞬间就恢复通畅了，群里也有人反应使用stream-up断流，他是用grpc也发生断流，我用grpc在虚拟机里git操作时也有断流现象，而网页和视频都没明显问题。
使用packet-up模式在客户端log里有时会出现：protocol error: received DATA after END_STREAM这个信息，服务端nginx里会出现较多的0字节的200响应