这个检测方法不需要任何 ip 库,成本很低,还比较难绕过
原理的话,不是 ip 库,不是 tls 指纹,不是检测分流规则,不是 dns 泄露,不是 webrtc
根据我目前的了解,应该没有其他的 api 使用这个检测方法(可能是我见的少)
能检测 proxy ,但是有些 virtual private network 检测不到(比如 wireguard 等)
上面链接是个简单的前端 UI ,可以直接用 curl 访问:
curl https://api.proxychecker.yccd.cc:8443
# use http://127.1:7890 as http_proxy
curl https://api.proxychecker.yccd.cc:8443 -x http://127.1:7890
需要 curl 支持 http2 ,windows 默认的 curl 好像不支持,
也可以直接在浏览器访问这个 https://api.proxychecker.yccd.cc:8443
有些情况下检测不出来,但应该是少数情况,国内使用国内的 proxy 可能检测不到
用来检测一些使用 proxy
的爬虫应该效果不错
目前接口可能会需要 1-10s 响应,可以再优化一下,懒得搞了
只能检测是否使用代理,没法获取到真实 ip
代码已开源,在 /t/1066463
1
lovedoing 82 天前
|
2
lovedoing 82 天前
随便换了几个 ip 就检测不出了
|
3
XiLingHost 82 天前
透明代理好像检测不出来
|
4
Retas 82 天前
同一个 IP 刷新几次在 Yes 和 No 反复横跳,检测有点玄学成分
|
6
YCCD OP 有 5-10%的数据离临界值比较近
|
7
w88975 82 天前
原理是啥? IP 定位?
|
9
lisxour 82 天前
接口不太稳定,没法用啊,能稳定在 3 秒内就差不多了,偶尔会出现 7 、8 秒的情况,大部分 2 秒内。
|
10
cenyejinxi 82 天前
原理是往返时间么?
|
11
ciki 82 天前 5
你发这些有什么目的?谁指使你的?你的动机是什么?
|
13
alect 82 天前
我真实 ip 提示 proxy
|
14
pagxir 82 天前 via Android
#13 我估计测试 3 层时延跟 4 层的差,然后你机器性能比较差或者网络丢包重传了,然后被识别成。明显是不靠谱的评估方式
|
15
WorldlineChanger 82 天前
时间差?
|
16
montaro2017 82 天前
|
17
lambdaq 82 天前
阿里云的 ip 你告诉我不是代理。。
好吧。 |
18
LitterGopher 82 天前
|
19
GeekGao 82 天前
OS fingerprint + UA matching ?
|
20
nothspec 82 天前 via Android
高级呀,哥,我 N 个节点都对了
|
21
yanyao233 82 天前 via Android
蹲一个原理,后续会开源吗?
|
22
1423 82 天前
tcp 时间戳?
|
23
Bingchunmoli 82 天前 via Android
打不开
|
24
1423 82 天前 5
抓包看了下, 应该是对比 ack time 和 http2 ping time
有点东西 |
26
1423 82 天前
|
27
1rv013c6aiWPGt24 82 天前
打算开源吗?挺准的
|
30
kk2syc 82 天前
如果我写个脚本在落地机上先跑上 N 次并标记 no_proxy 呢?
|
32
qq316107934 82 天前
没试海外的节点准不准,但是国内正常的网络被误判的很严重
|
33
qq316107934 82 天前
好像找到原因了,4G 和 WiFi 下因为网络波动就会造成误判,有线连接效果会好一点,但也有。
|
34
YCCD OP 过滤异常数据的算法有点问题,等我改改
|
35
outtime 82 天前
感觉更像是网络质量测试,代理延迟低到一定水平就可以一直过检测
|
36
kk2syc 82 天前
@YCCD 不是,我是说如何突破你这个根据波动比例来判断的算法。问题在于你需要纠正算法误差,能纠正就很好搞了,标记 no_proxy 基数达到一个量,你的 proxy 判断也会被纠正
|
37
GeekGao 82 天前
受制于网络通讯的稳定性
|
38
XiLingHost 82 天前
对于工作在第三层和第四层的代理(策略路由和透明代理)似乎无效
|
39
pagxir 82 天前 via Android
@XiLingHost 不要说三层四层了,你机器慢一些就误判了,对一一个高负载的机器, 内核处理到应用层 58 毫秒延迟很平常
|
40
Masterlxj 82 天前
不如直接 ja4 啊
|
41
duzhuo 82 天前
怎么感觉以前看过类似的帖子
|
42
ztmzzz 81 天前
为啥有代理 rtt 时间会不一样,数据包的路径应该是相同的吧。难不成是代理协议处理的时间差别?
|
43
mintongcn 81 天前 via iPhone
等开源
|
44
mintongcn 81 天前 via iPhone
代理原来这么好检测,我给代理 tcp 加上延时 100ms ,是不是就不好检测了
不打游戏对延时不敏感。 |
45
frencis107 81 天前
|
46
xuwen 81 天前
这不是 tls over tls 检测吗
|
47
dode 81 天前
这个咋样
Hysteria 是一个功能丰富的,专为恶劣网络环境进行优化的网络工具(双边加速),比如卫星网络、拥挤的公共 Wi-Fi 、在中国连接国外服务器等。 基于修改版的 QUIC 协议。 |
48
Rehtt 81 天前 via Android
没有用代理,但 "is_proxy": true 🤣
|
49
andyC 81 天前
感觉是不错的, 等开源
|
50
8153 81 天前
这别人早就发布了,google 搜 通过 https 握手 rtt 识别 TCP 代理(SOCKS5/HTTP/HTTPS)
|
51
tianhehechu 81 天前
此 API 原理及其简单,已被我破解。他测试了源 IP 的访问延迟,在延迟大于 200ms 时,即判定为代理。所以评论区有的 V 友全中,有的 V 友遇到反复横跳的情况。
|
52
tianhehechu 81 天前
@tianhehechu 30~50ms 是判定值,并且多次检测取了平均值
|
53
YCCD OP @tianhehechu 源码放出来了,可以看看去
|
55
lypdarling 68 天前 via Android
@YCCD 准确率不错,但是感觉很容易被破。这个必须在前端去执行检测。爬虫可以在爬虫端设置本地服务 hosts 指向检测服务器域名,然后本地服务返回 is_proxy 为 false 就行了
|