Closed dudylan closed 2 weeks ago
dyhkwong
commented
4 months ago QUIC 的 crypto frame 可以被分片到多个 UDP 包（例如 Chromium 的 quiche 所谓的“Chaos Protection”）。与仅需判断放行与拦截的防火墙不同，对于 UDP，代理软件需要仅凭第一个包来决定将其路由到哪个出站，而通常不能先藏着第一个包不转发出去、等第二个（或甚至更多）包到达再决定如何路由并转发。 以 *ray 的架构，甚至连能不能做到后者都是个问题。
Fangliding
commented
4 months ago 也不是完全不能不过得弄一个sniff超时顺便还会增加延迟 em 问题是挺大的
dudylan
commented
4 months ago 我很早就遇到了这个问题。但是当 看到1.8.1 更新记录后 升级版本尝试了一下。 当时是可以的。 但是又不行了。
dyhkwong
commented
4 months ago 你不抓包就别说什么可以不可以了，先确认你遇到的是不是这种问题，浏览器发 QUIC 的方式也不是一成不变的。当时修的是同一个包里拆分开的 crypto frame，不等于拆分到多个包的 crypto frame 就能嗅探了。
我很早就遇到了这个问题。但是当 看到1.8.1 更新记录后 升级版本尝试了一下。 当时是可以的。 但是又不行了。
Fangliding
commented
4 months ago 实在不行可以用用fakedns()
dudylan
commented
4 months ago Fakedns 是需要自己指定IP的吧。
dudylan
commented
4 months ago 为什么要抓包去看呢，日志里应该比较清楚的吧。 https://github.com/XTLS/Xray-core/issues/3363#issuecomment-2111973796
dyhkwong
commented
4 months ago 为什么要抓包去看呢，日志里应该比较清楚的吧。
日志又看不出来嗅探失败的包是长什么样子的，现在单纯是在算命
我很早就遇到了这个问题。 当时是可以的。 但是又不行了。
你连自己碰到的是不是两个不同的问题都看不出来
SciFiDevSan
commented
4 months ago 基于Chromium的实现，在QUIC握手过程中，crypto frame可以被分片到多个UDP包中。这在Edge和Chrome等浏览器中表现明显，导致Xray无法正确处理QUIC流量。firefox遵循标准的QUIC实现，能够成功嗅探和处理QUIC流量，可以考虑使用firefox缓解一下。
不过是否有计划修复Xray中的QUIC嗅探问题，以确保与这些浏览器的兼容性？
dyhkwong
commented
4 months ago 导致Xray无法正确处理QUIC流量
只会导致无法嗅探出域名，并不会导致无法正确处理
firefox遵循标准的QUIC实现
Chromium 的实现虽然恶心但也是标准允许的，并没有不遵循标准
修复Xray中的QUIC嗅探问题
修肯定是可以修，问题是收着一堆包不发出去等 sni (理论上 sni 可以过很久之后才到来或者甚至不会到来）的行为是否合适，会不会造成问题（虽然 *ray 似乎本来就有这种行为）
SciFiDevSan
commented
3 months ago 导致Xray无法正确处理QUIC流量
只会导致无法嗅探出域名，并不会导致无法正确处理
firefox遵循标准的QUIC实现
Chromium 的实现虽然恶心但也是标准允许的，并没有不遵循标准
修复Xray中的QUIC嗅探问题
修肯定是可以修，问题是收着一堆包不发出去等 sni (理论上 sni 可以过很久之后才到来或者甚至不会到来）的行为是否合适，会不会造成问题（虽然 *ray 似乎本来就有这种行为）
好吧，是我没有仔细阅读RFC文档；quic延迟等待sni是否可以做成一个配置项，让用户自己根据使用情况配置？
dyhkwong
commented
2 months ago 之前已经有人写过这个了，有这个需要的可以自己改改把这个糊进去 Vigilans/v2ray-core@8f33db0
Fangliding
commented
2 months ago 整挺好
完整性要求
版本
描述
在使用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