通过代理出现验证码 — 并不是对代理本身的惩罚，而是安全系统在判断「这是不是真人」。通过代理时验证码出现得更频繁，原因有三：地址与他人和其他程序共享、该地址已有历史记录，而浏览器的其他信号又常常与之矛盾。 完全消除验证码是不可能的 — 它本来就是为此而设计的 — 但可以让它出现的频率明显降低。下面我们来分析 Google、Yandex 和 Cloudflare 官方对此的说法、为什么代理会提高触发验证的概率，以及哪些措施真正有效、哪些只会让情况更糟。
各大服务商官方怎么说
Google：「来自您网络的不寻常流量」
当网络中出现对搜索的自动请求时，Google 会显示这个页面。在帮助文档中，它列出了以下原因：计算机上的恶意软件、学校或办公室的共享网络（有人从中发送自动请求）、VPN（其他用户也在做同样的事）、IPv6 隧道，以及用户共享地址的运营商。文档中给出的建议包括：完成 reCAPTCHA、检查计算机是否有恶意软件、联系网络管理员、删除或更换 VPN — 据 Google 称，某些 VPN 无法区分正常流量与滥用行为 — 以及联系您的运营商。
帮助文档中没有直接提到代理，但机制是一样的：您与他人共享地址，Google 看到的不是您，而是来自该地址的全部流量。
Yandex：「大量同类型请求」
在 Yandex 的帮助文档中，验证码的原因只有一个：服务收到大量同类型请求，想要确认这些请求是由人而非机器人发送的。对于代理来说，这意味着不仅您自己的请求频率重要，所有使用同一地址的人的频率也同样重要。
reCAPTCHA v3：用评分代替图片
第三代 reCAPTCHA 根本不显示任何任务：根据 Google 的文档，它从不打断用户，而是给出一个 0.0 到 1.0 的评分，其中 1.0 表示很可能是正常交互，0.0 表示很可能是机器人。Google 默认建议网站使用 0.5 作为阈值。至于如何处理低评分 — 显示验证、要求确认登录还是直接封禁 — 则由网站自行决定。
Cloudflare：评分与三种验证方式
Cloudflare 对每个请求按 1 到 99 的等级进行评分：1 表示请求是自动的，99 表示来自真人。评分依据包括启发式规则（与已知指纹库比对）、机器学习（大多数评分由它给出），以及用于识别无头浏览器和其他自动化工具的 JavaScript 检测。当防火墙规则、机器人防护模块或频率限制被触发时，访客就会收到验证。验证方式有三种：
- 非交互式 — 浏览器执行 JavaScript，通常不超过五秒，无需用户任何操作；
- 托管式 — Cloudflare 自行选择验证方式；大多数人会自动通过并看到「成功」；
- 交互式 — 需要用户操作；Cloudflare 自己建议网站改用托管式。
验证成功后，浏览器会获得 cf_clearance cookie，在一段时间内不会再被验证。这对代理来说很重要，下面就会明白为什么。
为什么通过代理时验证码出现得更频繁
- 地址是共享的，而且有历史记录。 与 Google 帮助文档中 VPN 的机制相同：如果在您之前有人从该地址发送过自动请求，那么所有使用该地址的人都会受到怀疑。廉价的共享代理最容易受此影响。
- 地址类型。 安全系统知道哪些地址属于主机服务商。对于搜索引擎或社交网络来说，服务器 IP 本身就是需要格外留意的理由：数据中心里的人不会坐在那里上网。关于地址类型的构成，请参阅文章 住宅代理、数据中心代理和移动代理。
- 频率。 「大量同类型请求」— 这是 Yandex 的原话。程序打开页面的速度比人快，无论从哪个地址都会收到验证码。
- 信号之间的矛盾。 IP 来自德国，而浏览器时区和语言却是莫斯科的；地址是移动的，指纹却是桌面浏览器的。每一个这样的矛盾都会降低评分。关于哪些信号会让安全系统产生怀疑，请参阅文章 反机器人系统如何工作 和 什么是 TLS 指纹。
- 没有历史和 cookies。 每次都以「全新状态」和新地址出现的浏览器，看起来就像每次访问都是新访客。它既会丢失
cf_clearance，也会丢失积累的信任。 - 自动化。 无头浏览器和由程序控制的浏览器会通过 JavaScript 暴露自己 — Cloudflare 明确将其列为一种独立的检测机制。
真正有效的措施
- 选择合适的地址类型。 对于防护严格的网站 — 使用住宅代理、移动代理或静态住宅（ISP）代理，而不是数据中心代理。运营商的移动地址由数千名用户共享，网站封禁它们并不划算。
- 不要使用共享代理。 独享地址只对您自己的行为负责，而不对别人的行为负责。
- 保持地址稳定，而不是每个请求都更换。 Sticky 会话会同时保留地址和通过验证后的 cookie。对于使用 Cloudflare 的网站，每个请求都轮换意味着每个请求都要重新验证（IP 轮换与 sticky 会话）。
- 降低请求速度。 在请求之间加入暂停并保持合理的并发量，可以消除 Yandex 所说的主要原因。通用规则请参阅文章 robots.txt、速率限制与礼貌采集。
- 让信号保持一致。 浏览器的时区、语言和地理位置应与 IP 所在国家相符，WebRTC 不应泄露您的真实地址。反检测浏览器会自动完成这些（什么是反检测浏览器）。
- 在会话之间保存 cookies。 带有历史记录的浏览器配置文件比每次都全新的更容易通过验证。
- 使用前先检查地址。 黑名单、数据库中的 IP 类型、泄露情况 — 检查顺序请参阅文章 如何检测代理。
哪些措施没有帮助
- 每次遇到验证码就更换地址。 来自同一地址池的新地址通常有相同的声誉，而频繁更换本身就显得可疑。
- 购买最便宜的「大容量」代理。 一千个共享服务器地址只会带来一千个验证码。
- 用绕过防护的方式自动解决验证码。 这类服务确实存在，但这是对网站防护的直接绕过，而且往往违反其规则：例如 Google 将未经许可的自动搜索请求列为禁止行为。如果网站如此坚持区分人与程序，那么对于自动化任务就应该寻找官方 API。
如果不用代理也出现验证码
Google 的帮助文档提示了排查方向：计算机上的恶意软件、工作或学习中的共享网络、VPN，或者让许多用户共用同一地址的运营商。移动互联网同样会让数千人共用地址，所以有时验证码是因为别人的活动而落到您头上。请检查计算机，关闭 VPN 和那些以您名义发送请求的扩展程序，并尝试换一个网络。
简要总结：症状、原因、应对措施
| 症状 | 可能原因 | 应对措施 |
|---|---|---|
| Google 立即显示「不寻常流量」 | 共享地址且声誉不佳 | 使用独享地址；更换代理类型 |
| Yandex 在几次请求后显示验证码 | 大量同类型请求 | 降低速度；分散请求 |
| Cloudflare 每次访问都验证 | 地址不断变化或 cookies 未保存 | 使用 sticky 会话；保存 cookies |
| 验证无法自动通过 | 信号矛盾或有自动化特征 | 让时区和语言与 IP 一致；使用普通浏览器 |
| 整个地址池的所有地址都出现验证码 | 整个地址池被标记（例如同一子网） | 更换服务商或使用不同子网的地址 |
关于网站会整体限制 IPv6 子网这一特殊情况，请参阅文章 IPv6 代理。
常见问题
为什么我只发了两三个请求，Google 就显示验证码？
因为 Google 评估的是来自您地址的全部流量，而不仅仅是您自己的。如果地址是共享的 — VPN、代理、办公网络、运营商 — 那么别人的自动请求也会算到您头上。Google 的帮助文档对此有明确说明。
更换 IP 能摆脱验证码吗？
偶尔一次性更换有时可以，但如果新地址来自同一地址池，通常声誉也一样。在使用 Cloudflare 的网站上，频繁更换地址还会重置已通过的验证。
哪种代理最少遇到验证码？
独享的住宅、移动和静态住宅地址，并保持会话稳定。数据中心代理和共享代理最容易遇到验证码。
为什么 Cloudflare 一次又一次地验证我？
验证通过后，Cloudflare 会发放 cf_clearance cookie。如果地址每个请求都变化，或者浏览器不保存 cookies，这个标记就会丢失，验证便会重复出现。
reCAPTCHA v3 的评分是什么意思？
这是一个 0.0 到 1.0 的数字：越接近 1.0，越像真人。Google 默认建议网站使用 0.5 作为阈值，而如何处理低评分则由网站自行决定。