reality h2模式切换网络断连，必须客户端重启服务

[lhbdhr]

服务端：xray 1.8.3 客户端：安卓，v2rayNG客户端，最新版本 wifi和数据流量切换后，无法访问外网，客户端必须重启服务。

大佬们，是我配置出错还是怎样？

看到有两个人遇到类似的问题，这个是h2不能避免的问题吗？

h2传家宝式bug ，同一wifi多ap，ap之间切换，或者wifi/移动数据之间切换也出这个问题。tcp就不会 主要是Xray与v2ray的h2传输方式无自动恢复连接或保持。一旦网络短暂断开，需要客户端再手动连接恢复。 https://github.com/XTLS/Xray-core/issues/289#issuecomment-783337941

"inbounds": [
    {
      "listen": null,
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "xxxxxxxxxxxxxxxxxxxxxxxxx",
            "email": "xxxxxxxxxxxxxxxxxx",
            "flow": ""
          }
        ],
        "decryption": "none",
        "fallbacks": []
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.bestbuy.com:443",
          "xver": 0,
          "serverNames": [
            "www.bestbuy.com"
          ],
          "privateKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
          "publicKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
          "minClient": "",
          "maxClient": "",
          "maxTimediff": 120000,
          "shortIds": [""]
        }
      },
      "sniffing": {
        "enabled": false,
        "destOverride": ["http", "tls"]
      }
    }
  ],

[chika0801]

你配置没问题。

类似现象，h2/grpc一直都有，你了解用这种配置组合它就有这问题，就释然了。

一些建议 https://github.com/chika0801/Xray-examples/tree/main/VLESS-H2-uTLS-REALITY#%E6%B3%A8%E6%84%8F

[RPRX]

我都不知道有这 bug，早给我说不就早解决了

经调查是 Golang net/http 实现上的 bug，TCP 卡住后没有自动重连，同一 client 的后续请求都会失败：https://github.com/golang/go/issues/30702 要么健康检查，或者，我想了想，可以在 client.Do(request) 失败后扔掉 client（下次请求会自动建新的）：https://github.com/XTLS/Xray-core/commit/51769fdde1ca663dcb08d942618e480bee13109f 我觉得后者更优雅，健康检查像是科技树点歪了，不过还是得实测看一下效果，麻烦你先在电脑上试一下最新的 commit

---

https://github.com/XTLS/Xray-core/issues/289#issuecomment-783337941 是另一个问题，早已修复：https://github.com/XTLS/Xray-core/issues/289#issuecomment-787060604

---

gRPC 看起来没这个问题： https://github.com/XTLS/Xray-core/blob/51769fdde1ca663dcb08d942618e480bee13109f/transport/internet/grpc/dial.go#L86-L88

[lhbdhr]

感谢R大修复，但是我不会编译啊。。。。
而且，电脑端怎么切换网络啊？ 手机端就更麻烦了，涉及到v2rayng

[chika0801]

感谢R大修复，但是我不会编译啊。。。。 而且，电脑端怎么切换网络啊？ 手机端就更麻烦了，涉及到v2rayng

xray文件在这找， https://github.com/XTLS/Xray-core/actions 问题是ng没人会编译使用这些测试版本的apk。

你电脑用v2rayN要模拟你的问题环境如切换网，是不方便，所以你干脆不复测得了233333

[RPRX]

感谢R大修复，但是我不会编译啊。。。。 而且，电脑端怎么切换网络啊？ 手机端就更麻烦了，涉及到v2rayng

笔记本电脑，从家庭 WiFi 切换到手机热点即可测试，或者在群里拉别人测试

我看 @Fangliding 方力丁 先生在尝试编译 NG 了

[TheValkyrja]

这就是祖传的”断流“问题吗？ 那gRPC也有的吧，断流。

[RPRX]

那gRPC也有的吧，断流。

gRPC 似乎已无断流问题，有的话请发 issue，我会优先解决

[TheValkyrja]

那gRPC也有的吧，断流。

gRPC 似乎已无断流问题，有的话请发 issue，我会优先解决

在使用Telegram的时候偶尔会遇到无限connecting（gRPC），重启代理就好了，不确定具体是哪个环节有问题，也没特地尝试过复现，大概率找不到源头，所以就单纯一提。

[reza04899]

Then gRPC also has it, cut off the flow.

gRPC seems to have no interruption problem, if there is, please send an issue, I will give priority to solving it

When using Telegram, I occasionally encounter infinite connecting (gRPC). Just restart the agent. I am not sure which link has the problem, and I have not tried to reproduce it. There is a high probability that the source cannot be found, so I will simply mention it.

i have this problem too

[IConfigYou]

I've pulled latest h2 transport changes. However, it still hangs on client.Do(request). after investigation, I've noticed that request body reader (breader) never is closed, as a result end-point still waiting for new stream data. Therefore, no error is thrown and no response because everything looks correct.

I am not sure if breader intentionally is kept open for next sequences of data or not (stateful connection as the same as TCP).

Edit: 2023-8-6

I've done some comprehensive tests such as fixed body length/different http methods/stream data/different http libraries and etc. all tests were successful. However, breader doesn't work. I logged what is written into it, I saw that nothing is written into breader. I don't know why nothing is written into breader. However, I am sure client.Do(request) hanging is caused by breader

[RPRX]

你们看一下这个 https://github.com/XTLS/Xray-core/issues/2232#issuecomment-1694585839 ，测一下 https://github.com/XTLS/Xray-core/commit/d92002ad127f64bc1e740cb350eafd693ffadd6d 的 REALITY gRPC 还有没有（复现概率较低的）无限 connecting

*ray 的代码里都不调用 HandshakeContext，也就是说 TLS 握手阶段大概率没超时时间，如果卡住了，对于 gRPC、H2 就是都在等

https://github.com/XTLS/Xray-core/commit/d92002ad127f64bc1e740cb350eafd693ffadd6d 的 REALITY 调用 uTLS 是 HandshakeContext，看代码 gRPC 是 5 秒，H2 可能是默认不设限，暂不确定哪里设 dial 超时

[RPRX]

又看了看，gRPC 的普通 TLS、uTLS 可能是有超时的，ClientHandshake() 内调用普通 Handshake 并监测 ctx。。。无论有没有实际生效（它收到的这个 ctx 会不会被 cancel），这写法都挺迷的。。。以后全改成 REALITY 的写法，我感觉研究这屎山真不如重开