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

Question

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

bluehj777 opened this issue a year ago · 28 comments

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，也没有改善。

Answer 1 · 2023-06-01T06:28:46.000Z

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

Answer 2 · 2023-06-01T06:56:28.000Z

试试在 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
}

Answer 3 · 2023-06-01T07:11:22.000Z

试试在 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

Answer 4 · 2023-06-01T07:13:40.000Z

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

Answer 5 · 2023-06-01T07:24:25.000Z

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

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

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

Answer 6 · 2023-06-01T07:24:42.000Z

试试在 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

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

Answer 7 · 2023-06-01T07:26:52.000Z

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

Answer 8 · 2023-06-01T07:29:36.000Z

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

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

Answer 9 · 2023-06-01T07:30:23.000Z

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

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

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

Answer 10 · 2023-06-01T07:31:40.000Z

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

Answer 11 · 2023-06-01T07:35:21.000Z

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

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

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

Answer 12 · 2023-06-01T07:38:59.000Z

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

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

Answer 13 · 2023-06-01T07:40:56.000Z

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

Answer 14 · 2023-06-01T07:41:31.000Z

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

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

Answer 15 · 2023-06-01T07:43:15.000Z

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，走了直连

Answer 16 · 2023-06-01T07:55:48.000Z

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

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

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

Answer 17 · 2023-06-01T07:59:02.000Z

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

Answer 18 · 2023-06-01T07:59:48.000Z

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

Answer 19 · 2023-06-01T08:31:32.000Z

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

Answer 20 · 2023-06-01T08:34:12.000Z

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

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

Answer 21 · 2023-06-01T09:00:47.000Z

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

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

Answer 22 · 2023-06-01T09:31:01.000Z

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

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

Answer 23 · 2023-06-01T12:46:26.000Z

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

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

大家怎么看？

Answer 24 · 2023-06-01T12:52:28.000Z

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

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

大家怎么看？

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

Answer 25 · 2023-06-01T12:53:13.000Z

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

Answer 26 · 2023-06-01T14:31:26.000Z

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

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

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

Answer 27 · 2023-06-05T10:11:32.000Z

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

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

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

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

Answer 28 · 2023-06-06T06:32:37.000Z

见 v4.7.4 版本，ipts_drop_quic。