这是一个创建于 802 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2022-10-09 17:43:35 +08:00
过了有点久了，能力有限，捣腾了好几个版本了。头疼。今天更新下
几个自身原因并且很明显会导致猜测错误的原因
1. 取值错误，只用自己的样本数据推出的规律并不靠谱。大概有 200 条
2. iOS ，mac 在未验证过证书的情况下，会导致取值偏大。
3. 网络问题，丢包、乱序等情况，这个数量还挺多了。感觉无法解决
更新内容：
1. 增加一个 302 跳转补充数据
如果用 curl 等工具需要支持 302 跳转；访问链接需改为:
https://bjun.tech/demo/proxy_guess/proxy_guess.php?token=自己写个值
curl -L https://bjun.tech/demo/proxy_guess/proxy_guess.php?token=自己写个值
2. 增加任性的评分猜测代理
增加握手时间和增加 302 跳转经过简单的过滤去异常后，按感觉写了个评分去猜测代理使用，也不知道靠不靠谱。就这样先
几个自身原因并且很明显会导致猜测错误的原因
1. 取值错误，只用自己的样本数据推出的规律并不靠谱。大概有 200 条
2. iOS ，mac 在未验证过证书的情况下，会导致取值偏大。
3. 网络问题，丢包、乱序等情况，这个数量还挺多了。感觉无法解决
更新内容：
1. 增加一个 302 跳转补充数据
如果用 curl 等工具需要支持 302 跳转；访问链接需改为:
https://bjun.tech/demo/proxy_guess/proxy_guess.php?token=自己写个值
curl -L https://bjun.tech/demo/proxy_guess/proxy_guess.php?token=自己写个值
2. 增加任性的评分猜测代理
增加握手时间和增加 302 跳转经过简单的过滤去异常后，按感觉写了个评分去猜测代理使用，也不知道靠不靠谱。就这样先
第 2 条附言 · 2022-11-24 18:17:06 +08:00
最后一附言了：
1. 一开始的思路简单记录下，结论是单个指标不太靠谱。可以移步 https://bjun.tech/blog/xphp/192 。
2. 引入了 302 图片，也简单记录下，https://bjun.tech/blog/xphp/196
3. 引入 ws without message ，和 302 图片差不多，只是做了些测试。
4. 引入 ws with message ，主要测试 ws 获取 rtt ，也只是做测试对比
5. 302 图片和 ws with message 都有一个直观的 rtt 做判断，这个就看着玩，不太行。没用于 proxy guess
6. 引入 MTU\MSS 协助识别 vpn ，数据库来自 p0f 。好像有点旧，后面再想办法
1. 一开始的思路简单记录下，结论是单个指标不太靠谱。可以移步 https://bjun.tech/blog/xphp/192 。
2. 引入了 302 图片，也简单记录下，https://bjun.tech/blog/xphp/196
3. 引入 ws without message ，和 302 图片差不多，只是做了些测试。
4. 引入 ws with message ，主要测试 ws 获取 rtt ，也只是做测试对比
5. 302 图片和 ws with message 都有一个直观的 rtt 做判断，这个就看着玩，不太行。没用于 proxy guess
6. 引入 MTU\MSS 协助识别 vpn ，数据库来自 p0f 。好像有点旧，后面再想办法
 |
1
SingeeKing 2022-09-12 17:16:42 +08:00 via iPhone
我试了下，然后你猜错了（
|
 |
2
Jirajine 2022-09-12 17:18:18 +08:00
意义何在？不明白延迟和代理有什么关系。移动网络、卫星网络、垃圾线路跨国连接、严重拥塞的网络都可以产生较长的握手时间。代理协议也可以通过 Mux 链路共享、多倍发包的传输层协议来降低握手延迟。
|
 |
3
xxxbin OP @SingeeKing 哈哈哈 有点丢人 加了个 ip ，看看有没有走代理？
|
 |
4
SunsetShimmer 2022-09-12 17:19:26 +08:00
猜错了 +1
|
|
5
xxxbin OP |
|
6
xxxbin OP @SunsetShimmer 留个类型呗？
|
|
7
xxxbin OP 哦 对 你们出海的要挂全局。 链接服务器在国内。看我还能嘴硬多久。哈哈哈
|
|
8
Jirajine 2022-09-12 17:33:53 +08:00  2
@xxxbin 误判率过高以至于没有意义。非代理用户可能因为各种各样的原因导致握手延迟较高，代理用户也可以通过各种方法降低握手延迟。
mux 多路复用是用一条连接承载多条连接，除第一条连接需要握手外后续连接用已有连接承载，无额外的 客户端到代理服务器的握手开销。以 v2 为例 https://www.v2fly.org/developer/protocols/muxcool.html 任何代理都可以轻易实现相同的机制。 另外 wireguard 等基于 udp 的 VPN 协议也能起到相同的效果，cloudflare 的代理产品 1.1.1.1 的主要卖点就是降低响应延迟。 多倍发包就是通过更激进的拥塞控制算法和大量发包以对抗丢包，从而减少可能需要的重传以降低延迟，例如 kcp 和 hysteria ，其实 quic 也有类似效果。 |
|
9
SunsetShimmer 2022-09-12 17:38:53 +08:00
@xxxbin vmess
|
|
10
xxxbin OP |
|
11
xxxbin OP @SunsetShimmer 纯 vmess? 还是有套 tls ？ 。香港的？
|
 |
12
illl 2022-09-12 17:46:42 +08:00 via iPhone
|
|
13
illl 2022-09-12 17:47:59 +08:00 via iPhone 1
|
|
15
Jirajine 2022-09-12 18:06:35 +08:00
@xxxbin 我这里说的，都是针对握手延迟的方式。其实除了简单的 1:1 tcp 代理外，有各种各样的方法消去这种额外的开销。客户端不需要每个 tcp 连接都进行一次完整的客户端到代理服务器再到目标服务器的握手，只需要通过其他方式告诉代理服务器直接向目标服务器发起握手，然后开始传输数据就完事了。
|
 |
16
raycool 2022-09-12 18:06:52 +08:00
肉身国内的，上 V2 的大部分都代理了吧~
|
|
17
SunsetShimmer 2022-09-12 18:06:59 +08:00
@xxxbin 香港没错，具体细节不清楚，机场不是我的。
|
|
18
xxxbin OP @SunsetShimmer 有设置一个阈值 ，低了不认。我分不清是设备导致的还是代理导致的。手里的 iphone 直连都会有个代理都高的数，不确定产生的原因
|
 |
20
yankebupt 2022-09-12 19:11:13 +08:00
@xxxbin 测试 url 在国外？我用绕过大陆还是 guess proxy true...
不过话说回来，用的 redir-host ，所以访问的 ip 是假的过了一层，虽然可能没走代理，会不会是这个原因…… 算误伤么？也可能不算吧…… |
 |
21
yanqiyu 2022-09-12 19:55:20 +08:00 via Android
wireguard 翻墙，判断错误
|
 |
24
vocaloid 2022-09-12 22:41:14 +08:00
猜错了（
|
 |
25
yangzhaofeng 2022-09-12 23:00:05 +08:00 via Android
通過握手時間來判斷還不如通過 MTU 。。。
|
 |
26
yaoyao1128 2022-09-12 23:03:29 +08:00 via iPhone
肉身国外，你猜错了……
|
|
27
xxxbin OP @yangzhaofeng MTU 的怎么说，手里倒是有个 tcp mss 判断 vpn 。我这个主要是为了验证想法，我也不确定行不行。看评论区还是挺惨的
|
|
28
xxxbin OP @yanqiyu 在试次 加了个 vpn 值（这个不是我写的），能发现么？如果可以 那 vpn 确实没有这个特征。不确定那个日志是不是你的
|
 |
29
phpfpm 2022-09-13 00:46:28 +08:00
猜错了+n
|
|
30
xxxbin OP 1
补了个 ip 地址，协助判断是否走了代理。有成功的哥们回复一个呗。鼓励下。
另外补充下： 1. 如果可以，开个无痕，能和域名触发 https 握手才是设想的工作环境。（上方 Jirajine 说的情况，目前都没考虑） 2. vpn 的可以跳过，应该无能为力 3. 目前阈值事 50ms ，与代理服务器之间小于该值跳过。（类似的，本地的 socks 代理更不行） 4. 目前判断的部分只有 3 行，有些情况肯定是无法覆盖的。能否改善，个人也存疑。 |
 |
31
fyw321451 2022-09-13 06:22:48 +08:00 via iPhone
无语 人在海外说我用了代理……
|
 |
32
piloots 2022-09-13 08:23:31 +08:00
哈哈哈，发现 bug 一处，当 x-forwarded 为 127.0.0.1 直接白屏。
|
 |
34
jazzg62 2022-09-13 08:39:17 +08:00
猜错了+1
|
 |
35
iSecret 2022-09-13 08:55:45 +08:00
歪个楼，话说淘宝的代理检测是通过什么方式？ IP 检测吗？
|
 |
36
joApioVVx4M4X6Rf 2022-09-13 09:03:19 +08:00
猜错了 +1
|
 |
37
iloveayu 2022-09-13 09:23:30 +08:00
猜错了 +1
|
 |
38
dzdh 2022-09-13 09:43:42 +08:00
猜错了 +1
|
 |
40
okrfuse 2022-09-13 09:51:52 +08:00
代理猜对了，但是使用的是 adguard 透明代理用来去广告，ip 猜错了，因为使用了 adguard 的隐身模式，vpn by mss 返回的是 false ，但是话说，我这样的算是暴露了吗，会被盯上吗
|
 |
41
r00tt 2022-09-13 09:54:52 +08:00
不准确，要不加个 ja3 看看？
|
 |
42
silk 2022-09-13 09:57:14 +08:00
猜错了 +1
|
 |
43
yunyuyuan 2022-09-13 09:59:12 +08:00
看成了无撸点，心想无撸点怎么还要特意说明。。。
|
 |
44
MinQ 2022-09-13 11:13:31 +08:00
猜错了+1
|
 |
45
docx 2022-09-13 11:47:44 +08:00 via iPhone
猜的很好，直接走路由规则直连了
|
 |
46
kwh 2022-09-13 12:18:43 +08:00
http 代理卒
|
 |
47
kera0a 2022-09-13 12:24:35 +08:00
直连猜测为了代理。
北京联通有线 |
|
49
yaoyao1128 2022-09-13 12:30:51 +08:00 via iPhone
5g 网络，非代理，但是是 nat64 ，识别非代理
之后 openvpn 回家，也识别非代理…… |
 |
50
Fred0410 2022-09-13 12:37:59 +08:00
猜错了哈哈哈
|
 |
51
Pastsong 2022-09-13 12:44:28 +08:00
既然这么多猜错的，那我把楼主的条件取个反岂不是正确率很高 :doge:
|
 |
53
zw1one 2022-09-13 13:53:20 +08:00
"guess use proxy": true
|
 |
54
yuzuhi 2022-09-13 14:37:39 +08:00
猜错了，人在国外
|
 |
55
toby1902 2022-09-13 14:40:37 +08:00
猜错了
|
 |
56
brucedone 2022-09-13 14:55:45 +08:00
猜错了 + n
|
 |
57
Areym 2022-09-13 14:57:23 +08:00
猜错了 人在美国 刚下飞机
|
 |
58
cy1027 2022-09-13 15:38:46 +08:00
老哥要做什么，我搞逆向的，只要是你能想到的识别方法，都有对应的破解方法，说说你的目的，你要干什么，如果网站被攻击，应该还有很多其它解决方案
|
 |
59
leega0 2022-09-13 16:02:52 +08:00
猜错了 + n ，"guess use proxy": false,
|
|
63
xxxbin OP @yaoyao1128 似乎隧道代理的才有效
|
|
64
cy1027 2022-09-13 16:30:47 +08:00
@xxxbin https://www.yalala.com/ 不知道这些你都试过没有，应该是管点用
|
 |
65
yulgang 2022-09-13 16:35:00 +08:00
搞错了，再来！
|
|
69
xxxbin OP @newmlp 有发现一篇阿里的文章是和我想的差不多 他们可能处理得更好 或者综合其他因素吧 我这个就孤单的一个特征做指标
|
|
73
xxxbin OP @yanqiyu win 10 ip 位数 41.67 ？ 如果是 按目前的阈值和 3 行确实发现不了
看了下特质数值，与其他的也是有些不同 |
|
74
xxxbin OP @yanqiyu 按特征值来推算 能看的是那个机器 ping 我服务器应该是 10ms 左右 你 ping 那个机器是 40ms 左右。
|
|
75
xxxbin OP 补了猜测延迟，看看就好 错误率应该更离谱。
|
 |
76
klight 2022-09-13 18:27:31 +08:00
挂全局你也猜错了:)，VPN 地址倒是没错
|
|
77
xxxbin OP @Jirajine 请教一下 是不是有些工具设置直连实践上不是跳过工具与目标机器直连 而是工具与目标机器直连？像 20 层的情况。
|
|
78
Jirajine 2022-09-16 12:19:57 +08:00
@xxxbin 那要看是怎么分流的。pac/iptables+ipset/nftables/策略路由等方式直连的流量肯定是直连，clash/v2 等用户侧路由直连的那当然是工具发起连接。
不过这种情况不太可能对你的检测结果产生影响，这种代理工具通常运行在局域网甚至 localhost 上，最多开销一些 CPU 罢了，延迟影响忽略不计。 |
|
80
kwh 2022-10-03 17:08:16 +08:00
楼主，能具体说说是怎么检测代理的吗？？？
我自己用 Java 写了个 http 代理用来翻墙， |
|
83
xxxbin OP @yangzhaofeng 了解了一些，关于 MTU 有个疑问，ipv6 的网络有效么？如果用户到代理机器之间都是 ipv6 ，代理机器转成 ipv4 ，MTU 是不是就不行了
|
Select Language