xhttp+nginx正常工作一段时间后断联，手动重启xray或nginx其中一方即恢复正常，回退2024.12.31版本一切正常 #4373
Comments
|
已补上日志 |
emiyalee1005
changed the title
|
|
On Sun, Feb 9, 2025 at 08:48 RPRX ***@***.***> wrote:
1. v25.1.1 几乎没有代码层面的改动，最相关的就是升级了 quic-go
2. 但是你客户端 alpn 同时写三个，*此时用到的是 h2 而非 h3*
3. 服务端 domain socket 还能 *too many open files*
，不太清楚是怎么回事，可能有巨量连接开了没关？内存或磁盘满了？
4. 因为这个一般常见于 TCP，*对于 DS 我还是第一次见*，你搜一下
5. 重启服务端 Xray / Nginx 会导致 socket 全部被释放，所以能恢复正常
—
Reply to this email directly, view it on GitHub
<#4373 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSMRD2BPGSAX74D43CAF32O2QV3AVCNFSM6AAAAABWYB3XBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWGAYDGOJVGE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
最主要之前版本都用得好好 升级了新版本就不行了 比较郁闷 只能回退了
|
|
我的看法是有很多人在用 Nginx+XHTTP 的组合，如果新版有问题早就有很多人说了 应该是你哪里配置比较奇怪，你应该把 Nginx 配置发出来让别人看看，在群里问问 |
|
服务端配置那里我已经把nginx贴出来了 我目前是加大了nginx侧的nofile再试下
…On Sun, Feb 9, 2025 at 09:42 RPRX ***@***.***> wrote:
我的看法是有很多人在用 Nginx+XHTTP 的组合，如果新版有问题早就有很多人说了
应该是你哪里配置比较奇怪，你应该把 Nginx 配置发出来让别人看看，在群里问问
—
Reply to this email directly, view it on GitHub
<#4373 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSMRFDQ2HCP33MVQXOFTL2O2W7JAVCNFSM6AAAAABWYB3XBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWGAYTMOJRGE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
有碰到类似的问题，版本2025.01.30，但是mode填的是auto，后面看了下是ng的连接数被打满(4进程，单进程2048连接数)，然后ng的错误日志里面刷了一堆的 ==== 使用auto的场景下，重启ng后，发现连接数会缓慢增长(中间也有减少的情况,但是整体上是一直增长的)，怀疑是部分异常case下连接用完后没有正常关闭 |
|
我升级到2025.1.30也出现了这个问题：[crit] 741#741: accept4() failed (24: Too many open files)，重启xray就恢复正常，然后过一阵又出现，再重启又正常 |
|
猜想可能是 stream-up 服务端的新行为（保活）导致连接没断开？不过按理说 POST 应该和 GET 同步断开才对 但 @emiyalee1005 提供的信息可能有误，因为 v25.1.1 服务端还没这个行为，你要说明 Xray 服务端、客户端分别是什么版本 你们试试双端均为 v25.1.30 时：
|
双端 v25.1.30 测试了下stream-up, 一秒一次curl, 隔一段时间后, nginx侧出现很多ESTABLISH状态的链接(client->ng, ng->server), 同时这些链接隔很长一段时间后还继续保持着, 在服务端重启后, ng->server链接立即被关闭, 但是client->ng方向的链接隔了一段时间才关闭。 服务端增加参数: 相关的配置客户端配置: {
"outbounds": [
{
"protocol": "vless",
"settings": {
"vnext": [
{
...
}
]
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"mode": "stream-up",
"host": "abc.test.com",
"path": "/path"
},
"security": "tls",
"tlsSettings": {
"serverName": "abc.test.com",
"fingerprint": "chrome"
}
},
"tag": "out-default"
}
]
}服务端配置: {
"log": {
"loglevel": "debug",
"access": "/tmp/xray-server/xray_access.log",
"error": "/tmp/xray-server/xray_error.log"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 10086,
"protocol": "vless",
"settings": {
"clients": [
{
...
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"path": "/path",
"scStreamUpServerSecs": -1
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
}
],
"routing": {}
}ng配置: |
|
@xxxsen packet-up 和 stream-one 呢？双端 v25.1.1 和 v24.12.31 呢？ |
其实严格来讲，我是这样的连接的： 服务器B如果用1.30就会死掉。至于25.1.1版本我记错了，我没装过，因为是pre-release。这个问题我试了3次，可以肯定切回12.31版本就没事，一升级立刻出事，期间其他所有东西都没动过。 目前我把服务器B的nginx的最大打开文件数和连接数加大后，1.30已经可以连续一天使用不挂掉了。 还有一个要提的是，我服务器B运行着一个网站（非代理，就正常静态页面），日活大概2-3k左右，这个也可能是造成 nginx连接数比较多的一个原因 |
|
其实我改了nginx配置，现在已经正常了，正准备close issue，但是看到其他用户反馈类似问题，所以先留着或者@RPRX你看要不要关闭此issue |
问题2：我这里h3跑不通，所以只能用h2，只是考虑全写了软件可以自动适配模式（期间切换其他网络万一又支持了），但是h2优先级会高于h3吗？有没类似auto模式能自适应？ |
|
@emiyalee1005 默认配置的 Nginx 仍会出问题？如果是的话则应当修复 按 @xxxsen 的说法只有新版的 stream-up 有这个问题，且与 我正在检查是否客户端没有同步关闭 stream-up 和 stream-down，服务端依赖于客户端的同步关闭行为，我看看能不能不依赖
防止引入未知 bug，尚未合并 #4320 |
是，模版里那个nginx配置会出错，但是不确定是不是和我的伪装网站本身流量比较大有关系（几年前只是为了伪装，却无心插柳柳成荫） |
补充三个不确定的问题：
|
|
https://github.com/XTLS/Xray-examples/blob/main/VLESS-XHTTP3-Nginx/nginx.conf 这个模板？没有写最大打开文件数和连接数，我的意思是不是 Nginx 缺省值会导致出错 还有我看了下客户端应该是有同时关闭 stream-up 上下行的，不过保险起见我准备给服务端也加一个，等下你测测 |
nginx.service里加上，ubuntu默认就1024打开数 然后nginx.conf error_log /var/log/nginx/error.log notice; events { |
|
我又看了下，服务端也有同步关闭，但是 stream-up 如果没有等到 stream-down 可能会无限等待，且服务端新行为还会保活 但我不解的是，即使是 v25.1.30，服务端加上 @emiyalee1005 你把 Nginx 恢复到以前的配置然后测试一下， |
|
又又又研究了一下，stream-up 服务端同步关闭的只是 request.Body，应该并不会导致 ServeHTTP() 被 return，正在修复 它并非 v25.1.30 新引入的问题，只是 stream-up 服务端的新行为放大了它，虽然客户端代码是同步关闭 POST 和 GET 所以尚不清楚为什么这个问题会被触发，也不清楚为什么 @xxxsen 测的是即使 但无论如何，这部分修复代码是有必要的 |
|
@emiyalee1005 @xxxsen 以默认配置的 Nginx 测试 dcd7e92 |
|
@KobeArthurScofield 似乎 GitHub 的自动构建全挂了？能编译，但后面的其它流程出错了 |
Actions Cache 不知何故清空了，到后面复制其它文件找不到路径就会直接报错 |
|
提了个 pr #4378，合并后应该可以手动更新 geodata 之类的 assets 来刷新 Cache，刷新后只要不清掉，依赖这些 assets 的 actions 就能正常运行。 |
频率降低了，半天出现了一次 |
|
@emiyalee1005 在此基础上试一下服务端配置 |
我改天试试 |
|
我发现上次改过之后还有一种情况，就是假如 stream-up 服务端只收到了 POST，由于 maybeReapSession 那里没有调用 s.uploadQueue.Close()，再加上 Read 没被调用导致 h.reader 仍为 nil 的话也 Close 不到，同理 Push 里的判断也是失效的，也就是说在这种情况下会不断允许单个 POST 连上 stream-up 服务端并被保活，我想这才是问题的关键，新的 commit 全修好了 顺便发现 XHTTP 服务端的机制允许前面的包是 packet-up、后面的包是 stream-up，当然来源也可以不同， |
…verConn instead of recover() #4373 (comment) #4406 (comment)
…verConn instead of recover() #4373 (comment) #4406 (comment)
…verConn instead of recover() #4373 (comment) #4406 (comment)
|
测试了半天，一切正常 |
|
@emiyalee1005 Great! |
完整性要求
描述
如题，实验了有半个月，配置是基于https://github.com/XTLS/Xray-examples/tree/main/VLESS-XHTTP3-Nginx
100%排除客户端到服务端的网络问题，切回2024.12.31版本可以一直正常使用，2025.01.30和2025.1.1版本在断联时在服务端日志会看到大量version invalid之类的信息，但是只要重启xray或nginx任意一方立刻恢复正常。
个人推测是新版本某个改动导致nginx和xray之间的socket通信出了问题？
服务器：oracle arm64
系统:ubuntu 24
nginx:1.26.3
重现方式
2025.1.1及以后的版本，使用一段时间后，最短的十几分钟后就出现断联，随后只要重启xray亦或nginx立刻恢复正常
客户端配置
服务端配置
客户端日志
服务端日志
The text was updated successfully, but these errors were encountered: