99% 命中率被识破：50 毫秒的裂缝，连最顶级的住宅代理也藏不住

我们转售 hellworld.io 的全线产品——14 个住宅代理品牌、3 个移动代理池、Static ISP 以及 2 个无限量套餐。所以当我们写住宅代理检测这个话题时，立场必须坦诚：每一位依赖住宅出口的客户，都和这篇论文有着实实在在的利害关系，我们不打算假装没这回事。本文的目的不是要吓得谁不敢用住宅代理，而是讲清楚一种服务器端的检测方法——它低调，却异常精准——以及它对 2026 年这类工具的实际使用方式，到底意味着什么、不意味着什么。

对大多数跑爬虫、抢购机器人、广告核验或价格情报的团队来说，住宅代理是感觉上最稳妥的选择。源 IP 看起来就是某个普通 ISP 上的普通家庭宽带用户——不是数据中心，也不是已知的代理服务商——而这恰恰能击穿绝大多数 IP 信誉名单。

直到它失灵的那一天。2022 年的一篇学术论文——BADPASS：机器人如何利用「代理即服务」（BADPASS: Bots Taking ADvantage of Proxy as a Service，ISPEC 2022，作者来自 EURECOM、KAUST 和 Amadeus）——证明了只靠一个小技巧，就能以 99.01% 的准确率识别出住宅代理连接：在握手过程中，于服务器端直接对比同一条 HTTPS 连接的 TCP RTT 和 TLS RTT。

不用 JavaScript，不用 IP 信誉库，不用指纹库。只需要服务器手头早就有的两个时延数字。

如果你运营的是一个正被爬取的高价值站点，这是已公开发表的检测方法里最干净利落的一种。如果你跑的是爬虫，那也值得了解——因为你今天信赖的那些服务商，很可能全都有这个问题。

住宅代理为什么变得这么难封

数据中心代理很好过滤。AWS、GCP、Azure、DigitalOcean——它们的 ASN、IP 段、主机名规律、TLS 协议栈特征以及历史滥用数据，全都是公开已知的。大多数商用反机器人服务会自动标记来自这些段位的流量。

住宅代理则完全是另一码事。出口 IP 是一条真实的家庭宽带线路、一台移动设备，或是某个被招募进代理服务商资源池的消费级硬件（有时是通过捆绑在免费 App 里的 SDK 拉进来的）。在目标服务器看来，它和俄亥俄、东京或圣保罗某个正常付费用户毫无二致。

正因如此，电商、票务、旅游和航司平台在与爬虫的猫鼠游戏中节节败退——而并非巧合的是，这篇论文的作者之一就任职于 Amadeus，全球旅游 IT 基础设施的巨头。这些可不是躲在象牙塔里空想「假如机器人用了代理会怎样」的研究者。多年来，他们一直被这件事实打实地折磨着。

传统反机器人检测严重依赖 IP 信誉、请求频率、设备指纹和行为轨迹。而住宅代理几乎把 IP 信誉这个信号彻底搅浑了。于是一个很自然的问题浮现出来：服务器能不能根本不看 IP，仅凭连接本身就判断出这是个代理？

论文的答案是：能，只要测量两个 RTT。

核心洞见：住宅代理切断了 TCP，却没切断 TLS

这是整篇论文里最精彩的部分。

当用户直连一个网站时，情形很简单。浏览器直接向服务器开一条 TCP 连接，然后在这条 TCP 连接上协商 TLS。TCP 三次握手和 TLS 握手都发生在同一对端点之间。服务器测得的 TCP 往返时延和 TLS 往返时延应该几乎一致——它们丈量的是同一条路径。

**住宅代理不是这么干的。**大多数住宅代理采用「反向连接」（backconnect）架构：客户端先连到服务商的超级代理（superproxy），超级代理再调度一个住宅网关（gateway），由网关向目标服务器开 TCP 连接。从服务器的视角看，TCP 对端是网关——而不是最初那个客户端。

但 HTTPS 代理通常会把 TLS 会话当作一条不透明的隧道整段转发，而不是把它终结后再重新建立。这就意味着 TLS 会话仍然是在最初的客户端和目标服务器之间端到端协商的。网关只是来回倒腾加密字节。

由此产生了一个结构性的错配：

• TCP RTT 测的是从网关到服务器的距离。
• TLS RTT 测的是从真实客户端经由超级代理和网关、再到服务器的距离。

对于直连，这两个数字是一样的。而对于住宅代理连接，TLS RTT 几乎总是明显大于 TCP RTT，因为 TLS 握手报文要走完整条代理链路，TCP 握手却不用。

一句话概括：住宅代理把传输层一切为二，但 TLS 仍然假装自己是端到端的，而这个谎言带有一个可以测量出来的时延代价。

这套检测方法为什么格外危险

服务器端的时延测量有四个特性，让它对代理用户来说极其难缠：

**1. 它完全在服务器上跑。**不需要客户端配合，不需要弹同意框，不需要执行 JavaScript。只要你能在负载均衡器或源站上捕获报文时序，就能实现它。

**2. 屏蔽 JavaScript 没用。**很多反机器人方案在浏览器端塞探测脚本——WebRTC、尝试连本地回环地址、利用 performance API 的各种怪癖。老练的机器人会禁用 JavaScript、跑无头模式，或把这些探测剥掉。而这套方法绕开了所有这些，因为关键信号在任何 HTML 被送出之前就已经采到了。

**3. 它根本不在乎 IP 信誉。**住宅 IP 一直在轮换，每天都有新的冒出来。任何靠把特定 IP 标记为「坏」来检测的方案，都在打一场注定输的追逐赛。这套方法完全无视 IP——它只看连接的结构。

4. 检测发生在响应之前。RTT 差值在 TLS 握手过程中就显现出来了。你可以在送出第一个 HTML 字节之前就决定拒绝、拖延或限速这条连接。从防御视角看，这一点意义重大——你在拿主意的同时，没有让爬虫窃走任何东西。

实验内幕

作者们并不满足于停留在理论。他们搭建了一套全球测试床，来证明这个差值是真实且稳定存在的：

• 采购了 4 家商用住宅代理服务商：Bright Data（前身为 Luminati）、Oxylabs、ProxyRack 和 Smartproxy。每家每月 40–50 GB 带宽。
• 22 台服务器通过 Amazon Lightsail（16 台）和 Azure（6 台）分布在全球各地。地点涵盖印度、澳大利亚、日本、德国、爱尔兰、加拿大、美国东/西部、南非、阿联酋和巴西。
• 每台服务器既当客户端又当服务器。从每一台服务器出发，团队向其他每一台服务器发送 HTTPS GET 请求：一次直连，外加分别经由四家代理服务商各一次——每对服务器之间共五条路径。
• 整个测试跑了 110 天（2022 年 1 月 12 日至 5 月 1 日）。服务器端的 TLS 版本每天在 TLS 1.2 和 TLS 1.3 之间交替，因此数据集对两者都有覆盖。

在剔除了损坏的抓包、扫描器噪声和短暂宕机之后，他们保留了 92,712,461 条完整的连接记录——约占发起的近 9800 万次连接的 95%。这是一个相当有分量的数据集。

两个 RTT 是怎么测出来的

TCP RTT 很直接。服务器发出 SYN-ACK，然后等待客户端最后的 ACK。两者之间的时间，就是服务器所见的 TCP RTT。在直连上，这是客户端到服务器；在住宅代理连接上，这是网关到服务器。

TLS RTT 略微棘手一些。作者挑选了一对 TLS 握手记录：服务器在其中发出了某些它必须等客户端回应才能继续的内容。对 TLS 1.2 来说，大致是 ServerHelloDone → ClientKeyExchange；对 TLS 1.3 来说，则是在 ServerHello 及加密握手消息之后 → 客户端的 change_cipher_spec / 第二轮报文。具体是哪几条记录并不是重点——原则在于「找到一个服务器发出内容、且必须等回复才能继续的点」。

无论 TLS 版本如何，这次往返都走完了完整的 TLS 路径：客户端 → 超级代理 → 网关 → 服务器。而在直连上，这只是客户端 → 服务器。

然后你算出一个数字：TLS RTT − TCP RTT。值小，说明是直连；持续地大，说明存在一个 TCP 层看不见的额外跳数。

结果触目惊心

论文给出了直连连接与代理连接各自 TLS RTT − TCP RTT 的分布，这两个群体几乎不重叠。

• 97% 的直连连接，差值在 ≤ 20 ms。
• 而代理连接那一侧的同一坐标轴不得不画宽 100 倍——从 0 到 2000 ms——因为代理的差值动辄就是几百毫秒。

有些连接出现了负差值（TCP RTT 大于 TLS RTT）。这发生在 SYN-ACK 或最后的 ACK 恰好被抖动拖慢、而后续的 TLS 报文却没被拖慢的时候。这种情况很罕见：

• 直连：2.9% 为负
• Bright Data：0.9%
• Oxylabs：1.8%
• ProxyRack：0.2%
• Smartproxy：1.4%

抖动确实存在，但它并不会破坏两个群体的可分性。

50 ms：命中 99% 的那个阈值

作者最终把 50 ms 定为一个实用的阈值。他们是通过单独分析每条连接的 RTT 天然抖动幅度来挑出这个值的：在 53% 的连接中，单条连接内部 RTT 的最大值减最小值的波动 ≤ 50 ms。所以 50 ms 既容纳了正常抖动，又远低于典型的代理差值。

依照这条规则——「若 TLS RTT − TCP RTT > 50 ms，则标记为住宅代理」——结果如下：

指标	数值
误报率（假阳性）	0.04%
漏报率（假阴性）	1.93%
整体准确率	99.01%

0.04% 的误报率意味着几乎没有正常用户会被这张网误捕——这一点至关重要，因为错杀真实客户的代价，远比放过几个爬虫昂贵得多。而 1.93% 的漏报率意味着几乎没有代理流量能溜过去。

即便是最坏情况，也有 92.78%

爱质疑的研究者会反驳：万一某条连接上第一次测到的 TCP RTT 恰好就是这条连接的最大值呢？那会抬高 TCP RTT、压缩差值，从而放走一部分代理流量。

作者对这种最坏情况做了压力测试。约 29% 的连接，其第一次 TCP RTT 等于该连接的最大值。假如你把这些连接统统当成倒霉地被偏置了，那就该出现可能的最差检测表现。在同样的 50 ms 阈值下：

• 误报：0.01%
• 漏报：9.68%
• 准确率：92.78%

哪怕在如此悲观的抖动假设下，这依然是一个相当强的分类器。真实的生产部署不可能处处都撞上最坏情况；现实远比 92% 更靠近 99%。

「要是网关离服务器很近呢？」

代理服务商最自然的反制手段，就是把网关尽量调度到离目标近的地方，缩短网关到服务器的那段 TCP RTT。如果这一跳极小，差值不就塌缩了吗？

作者恰恰检验了这种本应最伤检测效果的场景。对于 Bright Data——它在 ARIN/RIPE 区域有大量网关——他们单独抽出弗吉尼亚 ↔ 弗吉尼亚的连接。对于 Oxylabs 和 Smartproxy——它们在 LACNIC 区域分布密集——他们看的是巴西境内的路由。对于 ProxyRack——它在 AFRINIC 池中体量可观——他们用的是南非境内的路由。

结果依然成立。在 50 ms 阈值下，在这些「最有机会逃逸」的子集中，漏报率反而降到了约 0.78%——因为即便网关在本地，客户端和超级代理却不在，TLS 路径仍然横跨整条链路。

一个理论上的攻击者，如果能把客户端、超级代理、网关和服务器全部控制在同一个都市圈内，确实能让差值塌缩。但商用住宅代理的调度逻辑根本不是这么运作的；它的轮换逻辑压根不在乎与目标的地理亲和度。

重点：这套方法抓不到 VPN 或 NAT

这里必须仔细读懂论文。它的检测对象明确是：在 TCP 层打断了端到端、却在 TLS 层保留了端到端的连接。反向连接式的住宅代理正符合这个模式，某些 SSH 风格的转发也符合。

而标准 NAT、IPsec VPN、WireGuard 及类似的 VPN 技术，通常并不终结 TCP 连接。它们改写 IP、封装报文、把报文路由进隧道——但 TCP 会话仍然是最初客户端与服务器之间端到端的。结果就是，TCP RTT 和 TLS RTT 会像直连时一样对齐。

如果你想检测的是泛泛的「这个用户是不是躲在某个隧道后面」，那这套方法是用错了工具。要做 VPN 和 NAT 检测，你需要 MTU 分析、IP 信誉、时延基线或协议指纹。

但针对特定的商用住宅代理市场——也就是那个对撞库、抢购和大规模爬取负有不成比例责任的市场——这套方法的有效性高得吓人。

值得知道的几点保留意见

这篇论文并非 USENIX/CCS/NDSS/IMC 那种顶级会议的出版物；ISPEC 是一个体面但属于第二梯队的安全会议。实验用的是作者自己的客户端和服务器基础设施，而非来自真实防御方的生产网站流量。检测对象也很狭窄——只针对那种「切 TCP、透传 TLS」的住宅代理。而且，如果某家服务商重新设计了架构（比如在网关处终结 TLS），检测信号就可能收窄。

但这些保留意见都没有推翻这个结论。它们只是告诉你：这套方法并非对每一种代理流量都通杀的银弹——它只对最流行的那一种有效。

如果你在防御一个站点，这意味着什么

如果你运营一个被攻击的目标站点，这是你能加上的、性价比最高的检测方法之一。实现上大致就是：在 SYN-ACK/ACK 以及选定的那几条 TLS 握手记录上打时间戳，算出差值，以 50 ms 为阈值，然后把它喂进你现有的风险评分。

你不必单凭它来做决策——把它和限速、设备指纹及行为信号结合起来，能进一步压低误报。但作为众多信号中的一个，「TLS RTT 减 TCP RTT 超过 50 ms」信号强度高、在客户端层几乎无法伪造，而且在每一条 TLS 连接上都可观测。

想了解 2026 年其他那些检测层长什么样，可以看我们的《2026 反机器人格局》实战指南，它拆解了六家最有可能挡在你目标站点前面的反机器人厂商。

如果你在用住宅代理，这意味着什么

一个不那么舒服的事实：每一家遵循标准「反向连接 + TLS 透传」架构的商用住宅代理服务商，都能被这套方法检测出来。这几乎囊括了所有的高端服务商，包括被测试的那四家。

可行的缓解路径很有限：

• **服务商层面的架构改造。**服务商可以在网关处终结 TLS，再向目标重新建立一条 TLS，从而抹掉这种结构性的不对称。但这要求代理充当中间人（man-in-the-middle），会破坏证书校验，认真的用户不会接受这种东西。
• **把整条链路凑到一起。**如果客户端、超级代理、网关和服务器都在同一个都市圈，差值会缩小。但基于资源池的商用调度不允许这么干。
• **改用这套方法看不见的连接类型。**基于 VPN 和 NAT 的出口不受影响。但有取舍——它们有自己的检测向量。
• **混用多种连接类型，并接受部分流量会被标记。**对大多数团队来说，这才是现实的答案。不是每个请求都需要住宅出口。有策略地把 Static ISP、移动和住宅代理混搭起来，降低每条连接的请求频率，并把工作流设计成：被标记的流量代价只是一次重试，而不是一次永久封禁。

这不是一篇「住宅代理已死」的文章。它们仍然有效，仍然能绕过当前大多数生产防御——因为大多数生产防御还没实现基于 RTT 的检测。重点在于：住宅代理那个结构性优势——看起来和真实用户一模一样——存在一道可测量的、根本性的裂缝，任何认真做防御的人都能利用它。

如果你想更深入地想清楚什么时候该用住宅、什么时候该用移动、ISP 或无限量，《代理层级决策树》按使用场景梳理了各种取舍。而想看各家服务商的原始性能数据，《14 家品牌实测》是我们发布过的最新基准测试。

从 2026 年起，任何认真构建反爬基础设施的人，都会学到这个技巧。请据此早做规划。

---

参考文献：Casino, F., Patsakis, C., Lecharlier, B., & Ricci, V. (2022). BADPASS: Bots Taking ADvantage of Proxy as a Service. ISPEC 2022.