这个也是 Claude Opus 4.5，另外有了 #5520 的经验我把仓库 settings 的 Copilot coding agent 的 firewall 关了，毕竟纯开源项目

@copilot UDP 的 CanSpliceCopy 也要设为 3，另外 TCP & UDP LogInfo 加上 to (destination)，还有把 TCP 的 completed log 删掉

@copilot UDP 的 CanSpliceCopy 也要设为 3，另外 TCP & UDP LogInfo 加上 to (destination)，还有把 TCP 的 completed log 删掉

Done in b6f7413. Changed TCP CanSpliceCopy to 3, added destination to both TCP and UDP LogInfo messages, and removed the TCP "connection completed" log.

@copilot 差点以为是你改错了原来是我说错了，good job，日志中 from: 去掉 :

@copilot 差点以为是你改错了原来是我说错了，good job，日志中 from: 去掉 :

Done in 8a59648. Removed the colon from from: in both TCP and UDP log messages.

@copilot 如果是 TCP/UDP worker 的话它们会重新调用 ContextWithInbound 和 ContextWithContent 所以不受新增代码的影响对吧

@copilot 如果是 TCP/UDP worker 的话它们会重新调用 ContextWithInbound 和 ContextWithContent 所以不受新增代码的影响对吧

Yes, that's correct. The TCP/UDP workers in worker.go create fresh session.Inbound and session.Content objects by calling ContextWithInbound and ContextWithContent in their callback functions (lines 110-126 for TCP, similar for UDP). These calls override the context values set during proxy creation, so existing workers are not affected by the new code in always.go.

@copilot 把 log 的 processing connection 改为 processing TCP 或 UDP

@copilot 把 log 的 processing connection 改为 processing TCP 或 UDP

Done in 9ac1e98. Changed log messages to "processing TCP" and "processing UDP" respectively.

@copilot 还有个小问题是目前 TUN inbound 也要写 port 但实际上它用不上，这个容易解决吗

@copilot 还有个小问题是目前 TUN inbound 也要写 port 但实际上它用不上，这个容易解决吗

Done in a81c75a. Added special case for TUN inbound in InboundDetourConfig.Build() to skip port validation, since TUN uses network interface instead of ports.

@copilot 下面调用的 LoadWithID() 内有 strings.ToLower() 所以这里也加上比较好

@copilot 下面调用的 LoadWithID() 内有 strings.ToLower() 所以这里也加上比较好

Done in b5d070b. Added strings.ToLower() to the TUN protocol check to be consistent with LoadWithID() behavior.

Please conduct a manual verification. The local DNS is performing sniffing correctly; however, "geosite:youtube" in block is not being blocked by any sniffing methods, nor are "geosite:direct" rules functioning as expected. These rules operate without issue in proxy mode, suggesting a problem specific to the tunnel sniffing.

@t-e-s-tweb 我是测试了 tag 匹配没问题的，sniffing 的话如果有的正常有的不正常那应该是其它方面的问题，不过我刚想到一个

不过感觉与 SingleReader 而非 PacketReader 这件事 #5526 (comment) 无关，@Owersun 你测下 sniffing

@t-e-s-tweb 你那个会不会是 youtube 用 QUIC 然后没 sniff 出来的问题 @Fangliding

嗅探器都是抽象成单流处理的 quic嗅探百八十年前就修了
这要是tun炸我不清楚 其他入站新版本爆炸大概率是那堆geofile的改动

@t-e-s-tweb 你那边没被 block 的 youtube 是 tcp 还是 udp

@t-e-s-tweb 我才看到 nor，也就是说 "geosite:direct" 也不 working 吗

按理来说不应该啊，SniffingRequest 是正确传入的了，经过 TUN inbound 处理的数据就是纯 TCP/UDP payload

@Owersun 测一下看看能不能复现

I will have a look at domain sniffing.
My log is full of proper sniffed connections through tcp, and nothing when udp is used.
I also suspect this is QUIC related issue, I will investigate on which stage the information is not being properly processed

I've enabled "quic" in the config, like this:

      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"]
      }

and now the domain is properly sniffed from quic connections too (tcp and tls were working before):

2026/01/12 18:13:46.723750 [Info] [2178324910] proxy/tun: processing from udp:[fd00:0:2:9:181d:daa2:700c:e652]:64267 to udp:[2620:149:a41:880::13]:443
2026/01/12 18:13:46.819381 [Info] [2178324910] app/dispatcher: sniffed domain: gateway.icloud.com
2026/01/12 18:13:46.822479 from udp:[fd00:0:2:9:181d:daa2:700c:e652]:64267 accepted udp:[2620:149:a41:880::13]:443 [tun -> peer02]

although there is new message in logs that wasn't there before:

2026/01/12 18:13:48.337120 [Debug] [2178324910] proxy/vless/outbound: Reader is not timeout reader, will send out vless header separately from first payload

don't know how relevant that is, but it seems to appear if quic sniffing is enabled

proxy/vless/outbound: Reader is not timeout reader, will send out vless header separately from first payload

这个不应当出现，因为 reader 经过了 TimeoutWrapperReader 的包装

至于用 SingleReader，貌似没问题，udp 那个 conn 即使有 ReadFrom 也始终是 source，也不应该有 WriteTo 功能

它实现个 ReadTo & WriteFrom 还差不多

也就是说 sniffing 没问题吗，倒是发现了奇怪的 Reader is not timeout reader 问题

@RPRX @Owersun Thank you very much for taking the time to debug this. My browser was making quic connections which weren't being sniffed due to missing quic in settings. Now its working fine.

@Fangliding TUN inbound 和 sniffing 的文档里需要提醒下浏览器可能会用 QUIC 而不一定是 TCP，建议路由写个 block UDP/443