Verify Steps
OpenClash Version
v0.47.116
Bug on Environment
Official OpenWrt
OpenWrt Version
OpenWrt 25.12.5
Bug on Platform
Linux-arm64
Describe the Bug
Bug 描述
在启用了 UDP 代理(TProxy)的情况下,disable_udp_quic 配置项虽然默认开启(值为 1),但无法阻止客户端的 QUIC 流量被代理。
具体表现为:YouTube 的 QUIC 连接(udp/443)仍然通过 TProxy 入口成功建立了代理连接,没有被 REJECT 掉。
根因分析
1. TProxy 在 PREROUTING 截获所有 UDP 流量
在 openclash_mangle 链(挂载在 PREROUTING/mangle)中,TPROXY 规则匹配所有 UDP 并重定向到本地代理:
line 1447
nft add rule inet fw4 openclash_mangle meta l4proto { udp } mark set "$PROXY_FWMARK" tproxy ip to 127.0.0.1:"$tproxy_port" counter accept
该链通过 mangle_prerouting 跳转执行 line 1448:
nft 'add rule inet fw4 mangle_prerouting meta nfproto {ipv4} ip protocol udp counter jump openclash_mangle'
2. INPUT 链规则顺序问题
非 TUN 模式下,QUIC REJECT 和 TPROXY Accept 都通过 insert position 0 插入 INPUT 链:
line 1496 (QUIC REJECT)
line 1504 (TPROXY Accept)
# 先执行(第1496行)- QUIC REJECT,insert position 0
nft insert rule inet fw4 input position 0 udp dport 443 ip daddr ... reject
# 后执行(第1504行)- TPROXY Accept,insert position 0,插入到更前面
nft insert rule inet fw4 input position 0 meta mark "$PROXY_FWMARK" accept
后执行的 insert position 0 会插入到链头,因此最终 INPUT 链顺序为:
[TPROXY Accept] → [QUIC REJECT] → ...
UDP 443 包带有 PROXY_FWMARK 进入 INPUT 链,TPROXY Accept 先匹配放行,QUIC REJECT 永不命中(packets 0)。
3. FORWARD 链同样无效
FORWARD 链也有 QUIC REJECT 规则 line 1497,但 UDP 443 包在 PREROUTING 就被 TPROXY 截获重定向到本地,根本走不到 FORWARD 链。
4. TUN 模式同样受到影响
TUN 模式的 QUIC REJECT 在 INPUT 和 FORWARD 链 line 1646-1647,同样存在 TPROXY Accept 在前的问题。
建议修复
将 QUIC REJECT 规则添加到 openclash_mangle 链(PREROUTING/mangle)中,在 TPROXY 规则之前执行。这样 QUIC 包在 PREROUTING 阶段就被 REJECT,不会走到 TPROXY 规则,客户端回退到 TCP。
To Reproduce
- OpenClash 设置中确保 disable_udp_quic 为开启状态(默认值 1)
- 开启 UDP 代理(enable_udp_proxy)
- 打开 YouTube,观察 OpenClash 连接信息,可以看到 QUIC + TProxy 入口的连接被成功代理
- 验证:nft list chain inet fw4 input,QUIC REJECT 规则计数器显示 packets 0
- 代码证据:
OpenClash Log
OpenClash Config
Expected Behavior
开启 disable_udp_quic 后,客户端的 QUIC 流量(UDP 443)应被防火墙在 PREROUTING/mangle 阶段 REJECT,使客户端回退到 TCP 协议。
Additional Context
开启 disable_udp_quic 后,客户端的 QUIC 流量(UDP 443)应被防火墙在 PREROUTING/mangle 阶段 REJECT,使客户端回退到 TCP 协议。
Verify Steps
OpenClash Version
v0.47.116
Bug on Environment
Official OpenWrt
OpenWrt Version
OpenWrt 25.12.5
Bug on Platform
Linux-arm64
Describe the Bug
Bug 描述
在启用了 UDP 代理(TProxy)的情况下,disable_udp_quic 配置项虽然默认开启(值为 1),但无法阻止客户端的 QUIC 流量被代理。
具体表现为:YouTube 的 QUIC 连接(udp/443)仍然通过 TProxy 入口成功建立了代理连接,没有被 REJECT 掉。
根因分析
1. TProxy 在 PREROUTING 截获所有 UDP 流量
在 openclash_mangle 链(挂载在 PREROUTING/mangle)中,TPROXY 规则匹配所有 UDP 并重定向到本地代理:
line 1447
该链通过 mangle_prerouting 跳转执行 line 1448:
2. INPUT 链规则顺序问题
非 TUN 模式下,QUIC REJECT 和 TPROXY Accept 都通过 insert position 0 插入 INPUT 链:
line 1496 (QUIC REJECT)
line 1504 (TPROXY Accept)
后执行的 insert position 0 会插入到链头,因此最终 INPUT 链顺序为:
UDP 443 包带有 PROXY_FWMARK 进入 INPUT 链,TPROXY Accept 先匹配放行,QUIC REJECT 永不命中(packets 0)。
3. FORWARD 链同样无效
FORWARD 链也有 QUIC REJECT 规则 line 1497,但 UDP 443 包在 PREROUTING 就被 TPROXY 截获重定向到本地,根本走不到 FORWARD 链。
4. TUN 模式同样受到影响
TUN 模式的 QUIC REJECT 在 INPUT 和 FORWARD 链 line 1646-1647,同样存在 TPROXY Accept 在前的问题。
建议修复
将 QUIC REJECT 规则添加到 openclash_mangle 链(PREROUTING/mangle)中,在 TPROXY 规则之前执行。这样 QUIC 包在 PREROUTING 阶段就被 REJECT,不会走到 TPROXY 规则,客户端回退到 TCP。
To Reproduce
OpenClash Log
OpenClash Config
Expected Behavior
开启 disable_udp_quic 后,客户端的 QUIC 流量(UDP 443)应被防火墙在 PREROUTING/mangle 阶段 REJECT,使客户端回退到 TCP 协议。
Additional Context
开启 disable_udp_quic 后,客户端的 QUIC 流量(UDP 443)应被防火墙在 PREROUTING/mangle 阶段 REJECT,使客户端回退到 TCP 协议。