无聊撸了点检测代理的代码，主要是通过握手时间判断的，来试试?

我试了下，然后你猜错了（

意义何在？不明白延迟和代理有什么关系。移动网络、卫星网络、垃圾线路跨国连接、严重拥塞的网络都可以产生较长的握手时间。代理协议也可以通过 Mux 链路共享、多倍发包的传输层协议来降低握手延迟。

@SingeeKing 哈哈哈 有点丢人 加了个 ip ，看看有没有走代理？

猜错了 +1

@Jirajine
1. 开始想找个法子去发现住宅代理。
2. 较长的握手时间似乎不会改变使用代理的特征。较低时间只是会让特征区分识别
3. 后面那部分能力之外，看不懂。按我理解应该和我想的特征没关系

@SunsetShimmer 留个类型呗？

哦 对 你们出海的要挂全局。 链接服务器在国内。看我还能嘴硬多久。哈哈哈

@xxxbin 误判率过高以至于没有意义。非代理用户可能因为各种各样的原因导致握手延迟较高，代理用户也可以通过各种方法降低握手延迟。
mux 多路复用是用一条连接承载多条连接，除第一条连接需要握手外后续连接用已有连接承载，无额外的 客户端到代理服务器的握手开销。以 v2 为例 https://www.v2fly.org/developer/protocols/muxcool.html 任何代理都可以轻易实现相同的机制。
另外 wireguard 等基于 udp 的 VPN 协议也能起到相同的效果，cloudflare 的代理产品 1.1.1.1 的主要卖点就是降低响应延迟。
多倍发包就是通过更激进的拥塞控制算法和大量发包以对抗丢包，从而减少可能需要的重传以降低延迟，例如 kcp 和 hysteria ，其实 quic 也有类似效果。

@xxxbin vmess

@Jirajine 只针对握手的情况 ，后续的我无能为力。握手才有我说的特征。
误判率过高我暂时也没办法，能力有限。
只是突然想到的点子撸出来试试看。

@SunsetShimmer 纯 vmess? 还是有套 tls ？ 。香港的？

这个还更靠谱些 https://www.etherdream.com/proxy-detect/tcpwin.html

应该是这个 https://github.com/EtherDream/web-frontend-magic

@illl 好 学习下

@xxxbin 我这里说的，都是针对握手延迟的方式。其实除了简单的 1:1 tcp 代理外，有各种各样的方法消去这种额外的开销。客户端不需要每个 tcp 连接都进行一次完整的客户端到代理服务器再到目标服务器的握手，只需要通过其他方式告诉代理服务器直接向目标服务器发起握手，然后开始传输数据就完事了。

肉身国内的，上 V2 的大部分都代理了吧~

@xxxbin 香港没错，具体细节不清楚，机场不是我的。

@SunsetShimmer 有设置一个阈值 ，低了不认。我分不清是设备导致的还是代理导致的。手里的 iphone 直连都会有个代理都高的数，不确定产生的原因

@Jirajine 嗯 确实是这样 暂时还没想到这部分的情况

@xxxbin 测试 url 在国外？我用绕过大陆还是 guess proxy true...
不过话说回来，用的 redir-host ，所以访问的 ip 是假的过了一层，虽然可能没走代理，会不会是这个原因……
算误伤么？也可能不算吧……

wireguard 翻墙，判断错误

@yankebupt 广州的机子 ，有可能"绕过大陆”错了呢。有返回 ip 、看是你自己的还是机器的。

@yanqiyu VPN 的都没试过，不确定

猜错了（

通握手判不如通 MTU 。。。

肉身国外，你猜错了……

@yangzhaofeng MTU 的怎么说，手里倒是有个 tcp mss 判断 vpn 。我这个主要是为了验证想法，我也不确定行不行。看评论区还是挺惨的

@yanqiyu 在试次 加了个 vpn 值（这个不是我写的），能发现么？如果可以 那 vpn 确实没有这个特征。不确定那个日志是不是你的

猜错了+n

补了个 ip 地址，协助判断是否走了代理。有成功的哥们回复一个呗。鼓励下。
另外补充下：
1. 如果可以，开个无痕，能和域名触发 https 握手才是设想的工作环境。（上方 Jirajine 说的情况，目前都没考虑）
2. vpn 的可以跳过，应该无能为力
3. 目前阈值事 50ms ，与代理服务器之间小于该值跳过。（类似的，本地的 socks 代理更不行）
4. 目前判断的部分只有 3 行，有些情况肯定是无法覆盖的。能否改善，个人也存疑。

无语 人在海外说我用了代理……

哈哈哈，发现 bug 一处，当 x-forwarded 为 127.0.0.1 直接白屏。

@xxxbin 依然不行，这个 VPN 增加的延迟不到 40 ，所以大概能逃过这类判断

猜错了+1

歪个楼，话说淘宝的代理检测是通过什么方式？ IP 检测吗？

猜错了 +1

猜错了 +1

猜错了 +1

@iSecret 应该是的吧，我挂代理有时候他会检测到，有时候又检测不到

代理猜对了，但是使用的是 adguard 透明代理用来去广告，ip 猜错了，因为使用了 adguard 的隐身模式，vpn by mss 返回的是 false ，但是话说，我这样的算是暴露了吗，会被盯上吗

不准确，要不加个 ja3 看看？

猜错了 +1

看成了无撸点，心想无撸点怎么还要特意说明。。。

猜错了+1

猜的很好，直接走路由规则直连了

http 代理卒

直连猜测为了代理。
北京联通有线

@kera0a
补充一下，将代理软件关闭后，识别为了直连。
似乎是对的，代理 APP 设为直连也走了本机的代理。

5g 网络，非代理，但是是 nat64 ，识别非代理
之后 openvpn 回家，也识别非代理……

猜错了哈哈哈

既然这么多猜错的，那我把楼主的条件取个反岂不是正确率很高 :doge:

@Pastsong 就算取反不还是一样的错误率吗，无非 1 变 0 ，0 变 1 ，反正都是错的

"guess use proxy": true

猜错了，人在国外

猜错了

猜错了 + n

猜错了 人在美国 刚下飞机

老哥要做什么，我搞逆向的，只要是你能想到的识别方法，都有对应的破解方法，说说你的目的，你要干什么，如果网站被攻击，应该还有很多其它解决方案

猜错了 + n ，"guess use proxy": false,

@r00tt 有 但没配合使用 目前只想知道我说的特征有没有用。

@cy1027 无聊啊 发现有这个特征就拉出来试试啊

@Pastsong 有道理 狗头

@yaoyao1128 似乎隧道代理的才有效

@xxxbin https://www.yalala.com/ 不知道这些你都试过没有，应该是管点用

搞错了，再来！

@cy1027 WebRTC ip 泄露 这个知道的 其他就没啥看到的了

@okrfuse 我这个方法 应该服务端 才知道 走到代理前应该看不出来

@newmlp 评论区不和谐 换批人来 就这么搞

@newmlp 有发现一篇阿里的文章是和我想的差不多 他们可能处理得更好 或者综合其他因素吧 我这个就孤单的一个特征做指标

@yanqiyu 那有可能，这么新的工具 估计也有做些特别处理 这类型的不太了解

@piloots 哈哈哈 geoip 报错了估计 没做过滤

@kera0a 本地代理应该猜不出来才对 哈哈哈

@yanqiyu win 10 ip 位数 41.67 ？ 如果是 按目前的阈值和 3 行确实发现不了
看了下特质数值，与其他的也是有些不同

@yanqiyu 按特征值来推算 能看的是那个机器 ping 我服务器应该是 10ms 左右 你 ping 那个机器是 40ms 左右。

补了猜测延迟，看看就好 错误率应该更离谱。

挂全局你也猜错了:)，VPN 地址倒是没错

@Jirajine 请教一下 是不是有些工具设置直连实践上不是跳过工具与目标机器直连 而是工具与目标机器直连？像 20 层的情况。

@xxxbin 那要看是怎么分流的。pac/iptables+ipset/nftables/策略路由等方式直连的流量肯定是直连，clash/v2 等用户侧路由直连的那当然是工具发起连接。
不过这种情况不太可能对你的检测结果产生影响，这种代理工具通常运行在局域网甚至 localhost 上，最多开销一些 CPU 罢了，延迟影响忽略不计。

@Jirajine 我是看包发现的，延迟确实看不出。但推测是工具处理后的包有了自己的特征，只是推测，感觉也挺难实锤

楼主，能具体说说是怎么检测代理的吗？？？
我自己用 Java 写了个 http 代理用来翻墙，

@kwh 一些代理不会转发 tcp 头，导致握手之类的包会出现不一样的延迟。大概这么一回事。

@cy1027 楼上有人说 MTU ，这种怎么破？

@yangzhaofeng 了解了一些，关于 MTU 有个疑问，ipv6 的网络有效么？如果用户到代理机器之间都是 ipv6 ，代理机器转成 ipv4 ，MTU 是不是就不行了

@xxxbin 这玩意识别准确性都保证不了，需要破吗？

@cy1027 他提的通过 MTU 判断的方法也很不靠谱？

@kwh 我认为的原理在附言更新了，可以看看。

@xxxbin 好的谢谢

@illl 突然想起你这条评论，发现这个页面可以运行了。然后发现，ios 上面似乎无效。而且好像和网速有关，chrome 中通过 devtools 限制网速后会影响结果。