为什么每个网站都在弹验证码?成因与解决办法
频繁出现验证码,几乎总是源于你的网络线路、浏览器设置,或者二者互相矛盾。按常见程度排列的成因,以及对应的解决办法。
频繁的验证码通常意味着同一件事:你访问网站的方式看起来像机器,或者像一群人共用同一扇门,于是网站抬高了准入门槛,直到获得更清晰的信号为止。验证只是症状,根源在于你的网络线路、你的浏览器设置,或者这两者向网站讲述了不同的故事。
请按下面的顺序逐项排查。前三项远比其他原因常见,而且都出在同一个地方:你的流量所使用的出口地址。
先查地址,因为多半就是它
地址是共享的,或者有不良记录
大多数连接并不会给你一个专属地址。移动运营商和许多家庭宽带服务商会让大量用户共用一小批公网地址;办公室、校园和共享办公空间也是如此。这个地址背后的任何人今天早上做了什么,你下午就要承担后果。
廉价的代理池也一样,而且风险更大。共享的住宅代理池会把同一个地址租给那个小时里任何购买的人,如果网站之前见过从该地址发起的一波登录尝试,对下一个来访者自然格外谨慎。
解决办法是先弄清楚你实际呈现的是哪个地址,然后实际测试,而不是轻信卖家的描述。在 PowerOps 中,代理会先加入代理库并经过测试,然后才会接近任何账号,测试结果会报告实际观测到的地址。如果发现线路是共享的,就把配置文件换到不共享的线路上。
它是数据中心地址
属于托管服务商的地址段是公开的、有目录可查的,查询起来毫不费力。数据中心地址本身没有问题,大量正常流量也来自这里。但对于已登录的个人账号来说,出现在这种地址上并不寻常,网站也会据此加权判断。
解决办法是:数据中心地址只用于不涉及个人登录的工作,账号会话则使用住宅或移动地址。成本会上升,摩擦会下降,整个取舍就在于此。
你用的是人人都在用的 VPN 出口
消费级 VPN 会把海量用户集中到寥寥几个出口地址上。这正是产品的设计方式,也是为什么在 VPN 后面的会话会遇到别处遇不到的验证。并不是你做了什么让这个地址受到审视,而是单纯的流量规模所致。
解决办法是为每个配置文件使用独立线路,并选择提供粘性地址的服务商。如果你出于其他原因需要 VPN,请不要让它出现在进行账号操作的机器或配置文件上,更不要把它叠加在代理之上。
会话进行到一半时地址发生了变化
轮换端点会按请求或按时间间隔给你换一个新地址。对于采集公开数据,这很有用;对于已登录的会话,这是你自己制造的麻烦。一个会话从某个城市开始,几分钟后又从另一个城市继续,描述的是没有任何真人会做出的行为。
这种成因有鲜明的特征:最初几分钟一切正常,随后每次跳转页面都出现验证,中途往往还会被意外登出。
解决办法是把端点切换为粘性或会话保持模式,保持时长要超过你的工作会话。请在首次登录之前就分配好线路,因为第一次会话决定了该账号“正常”是什么样子。
然后检查浏览器讲述的故事是否一致
时区、语言和地址互相矛盾
一个经由法兰克福路由的配置文件却报告洛杉矶时区,等于用两种方式回答了同一个问题。同样,呈现巴西地址的同时浏览器语言列表里只有越南语,也是如此。单独看,这些值都不起眼;放在一起,就是网站最容易查到的矛盾。
解决办法是让配置文件的时区和语言列表与其线路所在国家保持一致,并且每次更换线路后一并检查。这是清单上最常见的自找麻烦的原因,而修正只需大约十秒钟。
请求节奏看起来像自动化
页面加载间隔精确到四秒。表单瞬间填完,中间没有任何聚焦事件。浏览全程没有任何滚动。十几个配置文件在同一秒、从同一子网做着完全相同的事。这些都不被禁止,但都不寻常,而“不寻常”正是抬高准入门槛的原因。
解决办法是控制节奏。错开配置文件的启动时间,而不是一次全部启动;让脚本任务使用可变的延迟,并等页面稳定后再执行下一步操作;减小每批的规模。如果脚本在网站上移动的速度超过真人,网站有权问一句屏幕另一端是谁。
再看浏览器保留了什么、拦截了什么
Cookie 已过期、缺失,或每晚被清除
大多数验证会记录自己的结果。通过一次之后,网站会存下一条记录,表明这个浏览器已经回答过,验证便会暂时不再出现。如果每次退出都清除 Cookie、使用无痕窗口浏览,或者每次都新建临时配置文件,这条记录就会在每次会话结束时被丢掉,下次访问又从零开始。
解决办法是使用拥有独立持久目录的配置文件,并正常关闭它,让状态得以写入。会话中途被强行终止的配置文件,可能会丢失刚刚赢得的那条记录。
有东西拦截了验证所需的脚本
验证以脚本形式运行,通常从安全服务商的域名加载,而不是你正在访问的网站的域名。激进的内容拦截器、脚本拦截器、强化隐私的扩展,以及被禁用的第三方存储,都可能导致加载失败。验证无法完成,于是不断重试。在你看来,就像无限循环,或者一个一直转圈却永远不会通过的验证框。
请按以下顺序排查:
- 在完全没有扩展的配置文件中打开同一页面。如果循环消失,原因就在某个扩展。
- 逐个重新启用扩展,直到问题再次出现。内容拦截器和隐私强化类扩展是最常见的元凶。
- 在拦截它的工具中放行验证服务商的域名,而不是整体关闭拦截器。
- 确认该网站的 JavaScript 和第三方存储没有被禁用。
- 检查系统时钟。时钟相差几分钟就会使验证所依赖的签名令牌失效,而故障表现看起来完全不像时钟问题。
从症状到成因
请对照左列找到你看到的现象,并从右列的办法开始尝试。
| 你看到的现象 | 最可能的原因 | 首先尝试 |
|---|---|---|
| 所有网站、所有配置文件从第一个请求起就有验证 | 地址本身:共享、繁忙,或属于数据中心地址段 | 测试线路,并查询该地址的归属 |
| 只有一个配置文件出问题,其他正常 | 该配置文件的线路或其已存储的状态 | 先换上一条确认良好的线路,再改动其他内容 |
| 前几分钟正常,之后每次跳转都出现验证 | 轮换端点在会话中途更换了地址 | 将端点切换为保持时间较长的粘性模式 |
| 通过验证后,同一个验证立刻又出现 | 通过记录没有被保存,或所需脚本被拦截 | 停止在退出时清除 Cookie,然后关闭扩展重试 |
| 验证框一直转圈,永远无法完成 | 拦截器阻止了验证脚本加载 | 放行服务商的域名,然后检查系统时钟 |
| 登录前网站就以错误的语言加载 | 区域设置与线路不一致 | 让配置文件的语言和时区与线路所在国家一致 |
| 刚更换代理就开始出现 | 新端点的历史记录 | 测试该端点,并请服务商换一个 |
| 刚更新某个扩展就开始出现 | 该扩展 | 针对该网站禁用它并重新加载 |
不要这样做
有几种条件反射式的做法,只会让情况更糟。
- 不要为了摆脱验证而随机化配置文件的身份。每次访问都变化的设备,是比你所担心的任何事都更响亮的信号,而且还会丢弃你已通过的所有验证留下的证据。
- 不要一上来就清除 Cookie。这些 Cookie 正是你已通过验证的记录,清除它们就保证下次访问从零开始。
- 不要把 VPN 叠加在代理之上。你会得到两条对你所在位置各执一词的线路,外加足以让正常时序显得异常的额外延迟。
- 不要疯狂刷新。同一地址反复失败的尝试,正是验证所要衡量的行为。
- 不要在会话中途把账号切换到全新的线路。先结束会话,再更换线路,然后重新登录。
还有一件我们不会协助的事。自动破解这些验证,超出了 PowerOps 的范围,也超出了本博客会讲解的范围。市面上有出售此类服务的商家,我们不与其集成,不为其撰写文档,产品的任何部分也不是为了绕过安全验证而构建的。以上所有内容,都是在消除网站首先要发问的那些理由。替你回答问题是另一门生意,我们不做。
如果都没有用
有时验证与你毫无关系。遭受攻击的网站会对所有人提高阈值,整个国家的流量可能会有一两天处于更严格的规则之下。在花一下午排查之前,先用普通连接、不经过任何代理和配置文件加载同一页面。如果验证同样在那里等着你,答案就是等待。
其余情况归结起来就是一份简短的清单:带有不良记录的线路;无法保持稳定的线路;互相矛盾的值;无法保留自己所赢得记录的浏览器。解决这四点,验证就会回到偶尔的小麻烦,而不再是你工作日的常态。
