quic sniffer 失效

[dudylan]

完整性要求

• 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我搜索了issues，没有发现已提出的类似问题。

版本

1.8.11

描述

在使用xray 访问http3 的网站时 无法通过sniffer 得出域名

重现方式

{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": [
"www.baidu.com",
"www.taurusxin.com"
],
"outboundTag": "blackhole",
"inboundTag": [
"proxy2"
]
},
{
"type": "field",
"outboundTag": "direct",
"inboundTag": [
"proxy2"
]
}
]
},
"stats": {},
"inbounds": [
{
"port": 2809,
"protocol": "socks",
"listen": "127.0.0.1",
"settings": {
"auth": "password",
"accounts": [
{
"user": "ABC",
"pass": "ABC"
}
],
"udp": true
},
"tag": "proxy2",
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"settings": {},
"tag": "direct"
},
{
"protocol":"Blackhole",
"tag" : "blackhole"
}
],
"log": {
"loglevel": "debug",
"dnsLog": true
}
}
以上是我的配置文件。
我使用的是netch源码进行的测试。 我把原本netch 启动xray的关掉。然后使他指向我手动启动的xray

我访问百度会出现连接已重置的页面。（因为我通过route把他转到了黑洞中）
我访问https://www.taurusxin.com/http3-enabled/时却可以正常访问
我也在日志中清晰的看到
2024/05/15 11:58:27 [Info] [773605411] app/dispatcher: sniffed domain: www.baidu.com
baidu 有sniffed成功

但是我访问www.taurusxin.com时
xray.log
文件是我的日志
有一行
udp:127.0.0.1:64005 accepted udp:61.170.88.242:443 [proxy2 -> direct]
我确信这就是http3 的流量记录

日志

No response

[dyhkwong]

QUIC 的 crypto frame 可以被分片到多个 UDP 包（例如 Chromium 的 quiche 所谓的“Chaos Protection”）。与仅需判断放行与拦截的防火墙不同，对于 UDP，代理软件需要仅凭第一个包来决定将其路由到哪个出站，而通常不能先藏着第一个包不转发出去、等第二个（或甚至更多）包到达再决定如何路由并转发。 以 *ray 的架构，甚至连能不能做到后者都是个问题。

[Fangliding]

也不是完全不能不过得弄一个sniff超时顺便还会增加延迟 em 问题是挺大的

[dudylan]

我很早就遇到了这个问题。但是当 看到1.8.1 更新记录后 升级版本尝试了一下。 当时是可以的。 但是又不行了。

[dyhkwong]

你不抓包就别说什么可以不可以了，先确认你遇到的是不是这种问题，浏览器发 QUIC 的方式也不是一成不变的。当时修的是同一个包里拆分开的 crypto frame，不等于拆分到多个包的 crypto frame 就能嗅探了。

…

我很早就遇到了这个问题。但是当 看到1.8.1 更新记录后 升级版本尝试了一下。 当时是可以的。 但是又不行了。

[Fangliding]

实在不行可以用用fakedns()

[dudylan]

Fakedns 是需要自己指定IP的吧。

[dudylan]

为什么要抓包去看呢，日志里应该比较清楚的吧。
#3363 (comment)

[dyhkwong]

为什么要抓包去看呢，日志里应该比较清楚的吧。

日志又看不出来嗅探失败的包是长什么样子的，现在单纯是在算命

我很早就遇到了这个问题。 当时是可以的。 但是又不行了。

你连自己碰到的是不是两个不同的问题都看不出来

[SciFiDevSan]

基于Chromium的实现，在QUIC握手过程中，crypto frame可以被分片到多个UDP包中。这在Edge和Chrome等浏览器中表现明显，导致Xray无法正确处理QUIC流量。firefox遵循标准的QUIC实现，能够成功嗅探和处理QUIC流量，可以考虑使用firefox缓解一下。

不过是否有计划修复Xray中的QUIC嗅探问题，以确保与这些浏览器的兼容性？

[dyhkwong]

导致Xray无法正确处理QUIC流量

只会导致无法嗅探出域名，并不会导致无法正确处理

firefox遵循标准的QUIC实现

Chromium 的实现虽然恶心但也是标准允许的，并没有不遵循标准

修复Xray中的QUIC嗅探问题

修肯定是可以修，问题是收着一堆包不发出去等 sni (理论上 sni 可以过很久之后才到来或者甚至不会到来）的行为是否合适，会不会造成问题（虽然 *ray 似乎本来就有这种行为）