关于参数tcponly='true'后仅代理tcp流量，QUIC/HTTP3 问题

[bluehj777]

cat ss-tproxy.comf

tproxy='true'
tcponly='true'
selfonly='false'
proxy_startcmd='start_multiple_proxy_exec 4'
proxy_stopcmd='kill -9 $(pidof ss-redir v2ray xray obfs-local chinadns-ng dns2tcp)  >/dev/null 2>&1'

dns_direct='119.29.29.29#53'
dns_direct6='240C::6666#53' 
dns_direct_white='true'
dns_direct6_white='true'
                                      
dns_remote='8.8.8.8#53' 
dns_remote6='2001:4860:4860::8888#53' 
dns_remote_black='true' 
dns_remote6_black='true' 

dns2tcp_enable='auto'   
dns2tcp_bind_port='65454'  

ipts_if_lo='lo'
ipts_rt_tab='233'  
ipts_rt_mark='0x2333'
ipts_set_snat='false' 
ipts_set_snat6='false' 
ipts_reddns_onstop='192.168.100.1#53'  
ipts_reddns6_onstop='240C::6666#53
ipts_proxy_dst_port='1:65000' 

设置 tcponly='true'仅代理tcp流量时.不管用global 还是chnroute 还是gfwlist 访问chat.openai.com都会被识别出是使用宽带的中国IP而禁止被访问了。访问其他网站GOOGLE,YOUTUBE等倒是没问题，可按所设模式预期处理。如果改成false代理tcp/udp则访问chatgpt没有此问题。

尝试处理cloudflare的IP段和opeanai.com,ai.com相关域名加入到gfwlist，也没有改善。

[zfl9]

难道是 openai 用了 quic？走了 UDP？

[zfl9]

试试在 ss-tproxy 主机添加如下 iptables 规则，将 udp 443 端口的流量给干掉（QUIC）

post_start() {
    iptables -t mangle -I SSTP_PREROUTING \
        -s 内网主机IP -p udp --dport 443 \
        -m addrtype ! --dst-type LOCAL \
        -j DROP
}

[bluehj777]

试试在 ss-tproxy 主机添加如下 iptables 规则，将 udp 443 端口的流量给干掉（QUIC）

post_start() {
    iptables -t mangle -I SSTP_PREROUTING \
        -s 内网主机IP -p udp --dport 443 \
        -m addrtype ! --dst-type LOCAL \
        -j DROP
}

这条mangle记录貌似有效果。我在再多试试

还有，其实不光chatgpt的这个网站有这问题，我发现一些套cloudflare保护的网站都有几率出现这个问题，比如ip.sb这个查询IP地址的网站，他也是套在cloudflare下的。在tcponly时，也会回显出本地IP而不是代理IP

[zfl9]

套了cf的也不一定就是要走代理的吧，我不认为这个是“问题”。

[bluehj777]

套了cf的也不一定就是要走代理的吧，我不认为这个是“问题”。

我的意思是套了CF的网站比如ip.sb这个，解出的IP是CF的IP地址段吧，CF的IP地址段不算CHNROUTE范围，所以应该去走代理而不是直连。不是这样吗？

上面代码，又测试了，使用后可以解决这个内网主机的问题。

[codecasex]

试试在 ss-tproxy 主机添加如下 iptables 规则，将 udp 443 端口的流量给干掉（QUIC）

post_start() {
    iptables -t mangle -I SSTP_PREROUTING \
        -s 内网主机IP -p udp --dport 443 \
        -m addrtype ! --dst-type LOCAL \
        -j DROP
}

这条mangle记录貌似有效果。我在再多试试

还有，其实不光chatgpt的这个网站有这问题，我发现一些套cloudflare保护的网站都有几率出现这个问题，比如ip.sb这个查询IP地址的网站，他也是套在cloudflare下的。在tcponly时，也会回显出本地IP而不是代理IP

老师 您好
小白用户再次向您请教 这个规则具体是在哪里添加的？

[zfl9]

ss-tproxy.conf 里面，钩子函数 post_start。

[zfl9]

套了CF的网站比如ip.sb这个，解出的IP是CF的IP地址段吧，CF的IP地址段不算CHNROUTE范围，所以应该去走代理而不是直连。

你使用的是什么分流模式，chnroute吗？

[bluehj777]

套了CF的网站比如ip.sb这个，解出的IP是CF的IP地址段吧，CF的IP地址段不算CHNROUTE范围，所以应该去走代理而不是直连。

你使用的是什么分流模式，chnroute吗？

是的，主要测试的是chnroute情况

[bluehj777]

如果不加post_start之前，在gfwlist和global里情况也是一样

[zfl9]

我整理下，你是说这样吗？

• chnroute 模式，并且没有 drop QUIC 流量
• tcponly='false' 时，访问 ip.sb，走了代理
• tcponly='true' 时，访问 ip.sb，走了直连

---

然后如果把 QUIC 给阻止了，就是都走代理（无论tcponly是什么值）

[zfl9]

如果说是上面说的这种情况，那可以推测，ip.sb 也是使用了 QUIC(HTTP/3)，也就是走了 UDP 协议。

因为 tcponly='true' 时，UDP 没有走代理。

[zfl9]

我自己测试了下，访问 ip.sb，然后 chrome F12 看了，确实是 h3，也就是 quic，也就是 udp。

[codecasex]

ss-tproxy.conf 里面，钩子函数 post_start。

收到
谢谢大佬
晚上回去试试

[bluehj777]

• chnroute 模式，并且没有 drop QUIC 流量
• tcponly='false' 时，访问 ip.sb，走了代理
• tcponly='true' 时，访问 ip.sb，走了直连

是这样
global 模式，
tcponly='false' 时，访问 ip.sb，走了代理 访问 chatgpt，走了代理
tcponly='true' 时，访问 ip.sb，走了代理 访问 chatgpt，走了直连

chnroute 模式，
tcponly='false' 时，访问 ip.sb，走了代理 访问 chatgpt，走了代理
tcponly='true' 时，访问 ip.sb，走了直连(这个不确定好像比较随机，可能和我清理浏览器cache不干净有关) 访问 chatgpt，走了直连

[bluehj777]

如果说是上面说的这种情况，那可以推测，ip.sb 也是使用了 QUIC(HTTP/3)，也就是走了 UDP 协议。

因为 tcponly='true' 时，UDP 没有走代理。

又测了gwwlist模式，也是一样的结果，是QUIC 的影响，CF没啥关系。只要加了kill quic的代码，就可以解决访问CHATGPT这类网站的问题

[bluehj777]

可以在原来代码里修改，在条件为 tcponly='true' 时启用kill quic 部分。

[zfl9]

嗯，待会处理下，加个配置控制下，是否丢弃 quic 流量。

[cattyhouse]

youtube.com google.com 在你使用 chrome 浏览器的时候, 都会默认用 quic, 除非设置下 chrome. 丢弃 quic 杀伤力有点大.

[zfl9]

tcponly='true'时（也就是只代理tcp），丢弃quic，应该没问题。

比如：代理本身不支持udp，或者代理的udp性能/体验差，还是有用处的。

[bluehj777]

youtube.com google.com 在你使用 chrome 浏览器的时候, 都会默认用 quic, 除非设置下 chrome. 丢弃 quic 杀伤力有点大.

国内的udp环境不好，感觉纯用TCP，chrome浏览速度有提升啊

[icy37785]

youtube.com google.com 在你使用 chrome 浏览器的时候, 都会默认用 quic, 除非设置下 chrome. 丢弃 quic 杀伤力有点大.

就是因为youtube google默认quic，所以更需要丢弃quic呀。

[zfl9]

想了下，quic 不止国外网站在使用（Google、Youtube、Cloudflare），国内也很多网站、APP 在使用，比如抖音这些。

所以，最好还是只 drop 黑名单列表的 quic 流量（udp 443），白名单的不要 drop 掉。

---

大家怎么看？

[xtccc]

想了下，quic 不止国外网站在使用（Google、Youtube、Cloudflare），国内也很多网站、APP 在使用，比如抖音这些。

所以，最好还是只 drop 黑名单列表的 quic 流量（udp 443），白名单的不要 drop 掉。

---

大家怎么看？

我只想说下我是准备用quic代理的
hysteria2是用quic的 ，希望这个drop做成参数可选的

[zfl9]

可选是肯定的，不会一刀切。

[bluehj777]

想了下，quic 不止国外网站在使用（Google、Youtube、Cloudflare），国内也很多网站、APP 在使用，比如抖音这些。

所以，最好还是只 drop 黑名单列表的 quic 流量（udp 443），白名单的不要 drop 掉。

大家怎么看？
可选 "黑名单"或 “非国内” 喜欢用udp443的就开tcponly=false吧

[zfl9]

新增配置：ipts_drop_quic='tcponly'，丢弃发往"黑名单"的QUIC:

• 留空: 不丢弃，主要是用于兼容之前的旧配置
• tcponly: tcponly='true'时丢弃 (也就是此贴讨论的情况)
• always: 总是丢弃 (比如代理的udp体验差，导致油管测速不高)

这里说的“黑名单”，是指在“分流”时，被判定为“要走代理的目标IP/域名”。

另外，此处的 drop 不会影响 $proxy_group 的进程（比如本机代理进程）。

[zfl9]

见 v4.7.4 版本，ipts_drop_quic。