V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xxxbin
V2EX  ›  程序员

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

  •  2
     
  •   xxxbin · 82 天前 · 6459 次点击
    这是一个创建于 82 天前的主题,其中的信息可能已经有所发展或是发生改变。

    链接在这里

    http 、socks 、vmess 自测都能检测到,也发现似乎不同工具的实现方法还有些不同。

    客户端和代理之前的延迟比较低的情况,大概率发现不了。

    第 1 条附言  ·  55 天前
    过了有点久了,能力有限,捣腾了好几个版本了。头疼。今天更新下

    几个自身原因并且很明显会导致猜测错误的原因
    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 条附言  ·  9 天前
    最后一附言了:
    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 。好像有点旧,后面再想办法
    87 条回复    2022-11-24 20:00:20 +08:00
    SingeeKing
        1
    SingeeKing  
       82 天前 via iPhone
    我试了下,然后你猜错了(
    Jirajine
        2
    Jirajine  
       82 天前
    意义何在?不明白延迟和代理有什么关系。移动网络、卫星网络、垃圾线路跨国连接、严重拥塞的网络都可以产生较长的握手时间。代理协议也可以通过 Mux 链路共享、多倍发包的传输层协议来降低握手延迟。
    xxxbin
        3
    xxxbin  
    OP
       82 天前
    @SingeeKing 哈哈哈 有点丢人 加了个 ip ,看看有没有走代理?
    SunsetShimmer
        4
    SunsetShimmer  
       82 天前
    猜错了 +1
    xxxbin
        5
    xxxbin  
    OP
       82 天前
    @Jirajine
    1. 开始想找个法子去发现住宅代理。
    2. 较长的握手时间似乎不会改变使用代理的特征。较低时间只是会让特征区分识别
    3. 后面那部分能力之外,看不懂。按我理解应该和我想的特征没关系
    xxxbin
        6
    xxxbin  
    OP
       82 天前
    @SunsetShimmer 留个类型呗?
    xxxbin
        7
    xxxbin  
    OP
       82 天前
    哦 对 你们出海的要挂全局。 链接服务器在国内。看我还能嘴硬多久。哈哈哈
    Jirajine
        8
    Jirajine  
       82 天前   ❤️ 2
    @xxxbin 误判率过高以至于没有意义。非代理用户可能因为各种各样的原因导致握手延迟较高,代理用户也可以通过各种方法降低握手延迟。
    mux 多路复用是用一条连接承载多条连接,除第一条连接需要握手外后续连接用已有连接承载,无额外的 客户端到代理服务器的握手开销。以 v2 为例 https://www.v2fly.org/developer/protocols/muxcool.html 任何代理都可以轻易实现相同的机制。
    另外 wireguard 等基于 udp 的 VPN 协议也能起到相同的效果,cloudflare 的代理产品 1.1.1.1 的主要卖点就是降低响应延迟。
    多倍发包就是通过更激进的拥塞控制算法和大量发包以对抗丢包,从而减少可能需要的重传以降低延迟,例如 kcp 和 hysteria ,其实 quic 也有类似效果。
    SunsetShimmer
        9
    SunsetShimmer  
       82 天前
    @xxxbin vmess
    xxxbin
        10
    xxxbin  
    OP
       82 天前
    @Jirajine 只针对握手的情况 ,后续的我无能为力。握手才有我说的特征。
    误判率过高我暂时也没办法,能力有限。
    只是突然想到的点子撸出来试试看。
    xxxbin
        11
    xxxbin  
    OP
       82 天前
    @SunsetShimmer 纯 vmess? 还是有套 tls ? 。香港的?
    illl
        12
    illl  
       82 天前 via iPhone
    illl
        13
    illl  
       82 天前 via iPhone   ❤️ 1
    xxxbin
        14
    xxxbin  
    OP
       82 天前
    @illl 好 学习下
    Jirajine
        15
    Jirajine  
       82 天前
    @xxxbin 我这里说的,都是针对握手延迟的方式。其实除了简单的 1:1 tcp 代理外,有各种各样的方法消去这种额外的开销。客户端不需要每个 tcp 连接都进行一次完整的客户端到代理服务器再到目标服务器的握手,只需要通过其他方式告诉代理服务器直接向目标服务器发起握手,然后开始传输数据就完事了。
    raycool
        16
    raycool  
       82 天前
    肉身国内的,上 V2 的大部分都代理了吧~
    SunsetShimmer
        17
    SunsetShimmer  
       82 天前
    @xxxbin 香港没错,具体细节不清楚,机场不是我的。
    xxxbin
        18
    xxxbin  
    OP
       82 天前
    @SunsetShimmer 有设置一个阈值 ,低了不认。我分不清是设备导致的还是代理导致的。手里的 iphone 直连都会有个代理都高的数,不确定产生的原因
    xxxbin
        19
    xxxbin  
    OP
       82 天前
    @Jirajine 嗯 确实是这样 暂时还没想到这部分的情况
    yankebupt
        20
    yankebupt  
       82 天前
    @xxxbin 测试 url 在国外?我用绕过大陆还是 guess proxy true...
    不过话说回来,用的 redir-host ,所以访问的 ip 是假的过了一层,虽然可能没走代理,会不会是这个原因……
    算误伤么?也可能不算吧……
    yanqiyu
        21
    yanqiyu  
       82 天前 via Android
    wireguard 翻墙,判断错误
    xxxbin
        22
    xxxbin  
    OP
       82 天前
    @yankebupt 广州的机子 ,有可能"绕过大陆”错了呢。有返回 ip 、看是你自己的还是机器的。
    xxxbin
        23
    xxxbin  
    OP
       82 天前
    @yanqiyu VPN 的都没试过,不确定
    vocaloid
        24
    vocaloid  
       82 天前
    猜错了(
    yangzhaofeng
        25
    yangzhaofeng  
       82 天前 via Android
    通過握手時間來判斷還不如通過 MTU 。。。
    yaoyao1128
        26
    yaoyao1128  
       82 天前 via iPhone
    肉身国外,你猜错了……
    xxxbin
        27
    xxxbin  
    OP
       82 天前
    @yangzhaofeng MTU 的怎么说,手里倒是有个 tcp mss 判断 vpn 。我这个主要是为了验证想法,我也不确定行不行。看评论区还是挺惨的
    xxxbin
        28
    xxxbin  
    OP
       82 天前
    @yanqiyu 在试次 加了个 vpn 值(这个不是我写的),能发现么?如果可以 那 vpn 确实没有这个特征。不确定那个日志是不是你的
    phpfpm
        29
    phpfpm  
       82 天前
    猜错了+n
    xxxbin
        30
    xxxbin  
    OP
       82 天前   ❤️ 1
    补了个 ip 地址,协助判断是否走了代理。有成功的哥们回复一个呗。鼓励下。
    另外补充下:
    1. 如果可以,开个无痕,能和域名触发 https 握手才是设想的工作环境。(上方 Jirajine 说的情况,目前都没考虑)
    2. vpn 的可以跳过,应该无能为力
    3. 目前阈值事 50ms ,与代理服务器之间小于该值跳过。(类似的,本地的 socks 代理更不行)
    4. 目前判断的部分只有 3 行,有些情况肯定是无法覆盖的。能否改善,个人也存疑。
    fyw321451
        31
    fyw321451  
       81 天前 via iPhone
    无语 人在海外说我用了代理……
    piloots
        32
    piloots  
       81 天前
    哈哈哈,发现 bug 一处,当 x-forwarded 为 127.0.0.1 直接白屏。
    yanqiyu
        33
    yanqiyu  
       81 天前 via Android
    @xxxbin 依然不行,这个 VPN 增加的延迟不到 40 ,所以大概能逃过这类判断
    jazzg62
        34
    jazzg62  
       81 天前
    猜错了+1
    iSecret
        35
    iSecret  
       81 天前
    歪个楼,话说淘宝的代理检测是通过什么方式? IP 检测吗?
    v2exblog
        36
    v2exblog  
       81 天前
    猜错了 +1
    iloveayu
        37
    iloveayu  
       81 天前
    猜错了 +1
    dzdh
        38
    dzdh  
       81 天前
    猜错了 +1
    newmlp
        39
    newmlp  
       81 天前
    @iSecret 应该是的吧,我挂代理有时候他会检测到,有时候又检测不到
    okrfuse
        40
    okrfuse  
       81 天前
    代理猜对了,但是使用的是 adguard 透明代理用来去广告,ip 猜错了,因为使用了 adguard 的隐身模式,vpn by mss 返回的是 false ,但是话说,我这样的算是暴露了吗,会被盯上吗
    r00tt
        41
    r00tt  
       81 天前
    不准确,要不加个 ja3 看看?
    silk
        42
    silk  
       81 天前
    猜错了 +1
    yunyuyuan
        43
    yunyuyuan  
       81 天前
    看成了无撸点,心想无撸点怎么还要特意说明。。。
    MinQ
        44
    MinQ  
       81 天前
    猜错了+1
    docx
        45
    docx  
       81 天前 via iPhone
    猜的很好,直接走路由规则直连了
    kwh
        46
    kwh  
       81 天前
    http 代理卒
    kera0a
        47
    kera0a  
       81 天前
    直连猜测为了代理。
    北京联通有线
    kera0a
        48
    kera0a  
       81 天前
    @kera0a
    补充一下,将代理软件关闭后,识别为了直连。
    似乎是对的,代理 APP 设为直连也走了本机的代理。
    yaoyao1128
        49
    yaoyao1128  
       81 天前 via iPhone
    5g 网络,非代理,但是是 nat64 ,识别非代理
    之后 openvpn 回家,也识别非代理……
    Fred0410
        50
    Fred0410  
       81 天前
    猜错了哈哈哈
    Pastsong
        51
    Pastsong  
       81 天前
    既然这么多猜错的,那我把楼主的条件取个反岂不是正确率很高 :doge:
    newmlp
        52
    newmlp  
       81 天前
    @Pastsong 就算取反不还是一样的错误率吗,无非 1 变 0 ,0 变 1 ,反正都是错的
    zw1one
        53
    zw1one  
       81 天前
    "guess use proxy": true
    yuzuhi
        54
    yuzuhi  
       81 天前
    猜错了,人在国外
    toby1902
        55
    toby1902  
       81 天前
    猜错了
    brucedone
        56
    brucedone  
       81 天前
    猜错了 + n
    Areym
        57
    Areym  
       81 天前
    猜错了 人在美国 刚下飞机
    cy1027
        58
    cy1027  
       81 天前
    老哥要做什么,我搞逆向的,只要是你能想到的识别方法,都有对应的破解方法,说说你的目的,你要干什么,如果网站被攻击,应该还有很多其它解决方案
    leega0
        59
    leega0  
       81 天前
    猜错了 + n ,"guess use proxy": false,
    xxxbin
        60
    xxxbin  
    OP
       81 天前
    @r00tt 有 但没配合使用 目前只想知道我说的特征有没有用。
    xxxbin
        61
    xxxbin  
    OP
       81 天前
    @cy1027 无聊啊 发现有这个特征就拉出来试试啊
    xxxbin
        62
    xxxbin  
    OP
       81 天前
    @Pastsong 有道理 狗头
    xxxbin
        63
    xxxbin  
    OP
       81 天前
    @yaoyao1128 似乎隧道代理的才有效
    cy1027
        64
    cy1027  
       81 天前
    @xxxbin https://www.yalala.com/ 不知道这些你都试过没有,应该是管点用
    yulgang
        65
    yulgang  
       81 天前
    搞错了,再来!
    xxxbin
        66
    xxxbin  
    OP
       81 天前
    @cy1027 WebRTC ip 泄露 这个知道的 其他就没啥看到的了
    xxxbin
        67
    xxxbin  
    OP
       81 天前
    @okrfuse 我这个方法 应该服务端 才知道 走到代理前应该看不出来
    xxxbin
        68
    xxxbin  
    OP
       81 天前
    @newmlp 评论区不和谐 换批人来 就这么搞
    xxxbin
        69
    xxxbin  
    OP
       81 天前
    @newmlp 有发现一篇阿里的文章是和我想的差不多 他们可能处理得更好 或者综合其他因素吧 我这个就孤单的一个特征做指标
    xxxbin
        70
    xxxbin  
    OP
       81 天前
    @yanqiyu 那有可能,这么新的工具 估计也有做些特别处理 这类型的不太了解
    xxxbin
        71
    xxxbin  
    OP
       81 天前
    @piloots 哈哈哈 geoip 报错了估计 没做过滤
    xxxbin
        72
    xxxbin  
    OP
       81 天前
    @kera0a 本地代理应该猜不出来才对 哈哈哈
    xxxbin
        73
    xxxbin  
    OP
       81 天前
    @yanqiyu win 10 ip 位数 41.67 ? 如果是 按目前的阈值和 3 行确实发现不了
    看了下特质数值,与其他的也是有些不同
    xxxbin
        74
    xxxbin  
    OP
       81 天前
    @yanqiyu 按特征值来推算 能看的是那个机器 ping 我服务器应该是 10ms 左右 你 ping 那个机器是 40ms 左右。
    xxxbin
        75
    xxxbin  
    OP
       81 天前
    补了猜测延迟,看看就好 错误率应该更离谱。
    klight
        76
    klight  
       81 天前
    挂全局你也猜错了:),VPN 地址倒是没错
    xxxbin
        77
    xxxbin  
    OP
       78 天前
    @Jirajine 请教一下 是不是有些工具设置直连实践上不是跳过工具与目标机器直连 而是工具与目标机器直连?像 20 层的情况。
    Jirajine
        78
    Jirajine  
       78 天前
    @xxxbin 那要看是怎么分流的。pac/iptables+ipset/nftables/策略路由等方式直连的流量肯定是直连,clash/v2 等用户侧路由直连的那当然是工具发起连接。
    不过这种情况不太可能对你的检测结果产生影响,这种代理工具通常运行在局域网甚至 localhost 上,最多开销一些 CPU 罢了,延迟影响忽略不计。
    xxxbin
        79
    xxxbin  
    OP
       78 天前
    @Jirajine 我是看包发现的,延迟确实看不出。但推测是工具处理后的包有了自己的特征,只是推测,感觉也挺难实锤
    kwh
        80
    kwh  
       61 天前
    楼主,能具体说说是怎么检测代理的吗???
    我自己用 Java 写了个 http 代理用来翻墙,
    xxxbin
        81
    xxxbin  
    OP
       55 天前
    @kwh 一些代理不会转发 tcp 头,导致握手之类的包会出现不一样的延迟。大概这么一回事。
    xxxbin
        82
    xxxbin  
    OP
       10 天前
    @cy1027 楼上有人说 MTU ,这种怎么破?
    xxxbin
        83
    xxxbin  
    OP
       10 天前
    @yangzhaofeng 了解了一些,关于 MTU 有个疑问,ipv6 的网络有效么?如果用户到代理机器之间都是 ipv6 ,代理机器转成 ipv4 ,MTU 是不是就不行了
    cy1027
        84
    cy1027  
       9 天前
    @xxxbin 这玩意识别准确性都保证不了,需要破吗?
    xxxbin
        85
    xxxbin  
    OP
       9 天前
    @cy1027 他提的通过 MTU 判断的方法也很不靠谱?
    xxxbin
        86
    xxxbin  
    OP
       9 天前   ❤️ 1
    @kwh 我认为的原理在附言更新了,可以看看。
    kwh
        87
    kwh  
       9 天前
    @xxxbin 好的谢谢
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1388 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 64ms · UTC 18:48 · PVG 02:48 · LAX 10:48 · JFK 13:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.