网站老弹安全验证？多半是误伤了

最近后台收到好几位站长的私信，说访客反馈打开网站先弹一个页面，中间一个勾选框，写着「请完成安全验证」或者「正在验证您是否是真人」，转几秒才进得去，有的人干脆卡在那儿无限循环。第一反应千万别当成浏览器那种红色安全警告，两码事。红色警告是证书过期或者 HTTPS 配置不对，浏览器直接把页面拦下来，标题栏还会挂着不安全三个字；而这个弹框是人机验证，说明请求已经打到了你站点前面的那一层防护上，被判定成疑似机器人，让你先证明一下自己是活人再放行。搞清这一点很关键，方向对了再动手，不然你去重新申请证书，纯属白折腾一场。

先认症状：弹的是人机验证，不是浏览器安全警告

这两个东西长得像，处理思路完全不同，先把症状对清楚。人机验证的页面元素很固定，要么是一个可以拖动的滑块，要么是勾选我不是机器人，要么干脆就是一句请稍候等它自己转圈，页面通常做得挺素，域名栏还是你自己的域名；浏览器安全警告则是在进入站点之前就弹出来，页面一片灰白，写着您的连接不是私密连接，还会带错误代码。前者是防护在放行前多问一句，后者是加密层没谈拢。还有一种容易混淆的，是服务器直接返回 403，页面只有一行 Forbidden，那属于权限拦截，跟人机验证也不是同一回事。先分清楚是哪一种，后面的排查才不会跑偏。

来源一：CDN 或 WAF 的 CC 防护，这是最常见的元凶

做了这么多年站，我遇到的安全验证弹框，十次里有七八次都是这一层惹的。CDN 和 WAF 服务商为了防止别人用大量请求把源站压垮，会挂一层 CC 防护，原理不复杂：短时间内来自同一个 IP 的请求太多，或者请求特征像脚本，就先丢一个验证页面过去筛一遍。最常见的触发场景有这么几个，一是开了 Cloudflare 的 Under Attack 模式，这个模式一开，所有访客都得先过验证，哪怕你站点安安静静；二是百度云加速这类国内加速产品，人机验证是它防护套餐里的默认动作；三是宝塔面板自带的网站防火墙，里面也有一个人机验证开关，装完默认参数偏严。

这三种都属于服务商提供的防护，位置在控制台里，不在你的服务器上，所以你去翻 nginx.conf 是找不到答案的。顺便说一句，各家 CC 防护的触发阈值松紧差得很远，有的默认请求量上万才动手，有的几千次就开始弹验证，你按经验判断的正常访问量，在它眼里可能已经是异常。所以别一上来就怀疑服务器配置，先把控制台里的防护参数翻一遍，心里有个底，再决定从哪里下手。

来源二：站点自己装的验证插件，往往被忘在脑后

第二类来源就更好排查了，只是很多人自己都忘了装过。WordPress 这类程序里，防垃圾评论和防爆破的插件一抓一大把，装的时候为了图省事，把全站验证的开关一起勾上了，于是所有访客连首页都得先过一遍。还有一类是安全插件里的登录保护，本来只想护住登录页，结果规则写成了全站生效。判断方法很直接：从后台插件列表里挨个回想，最近有没有动过安全类、验证类、防采集类的插件，把可疑的临时停用，然后用无痕窗口访问首页看看还弹不弹。如果关掉插件立马恢复正常，那答案就摆在这儿了。

另外主题里也有人手写过验证逻辑，翻一下 functions.php 有没有相关代码。还有一种特别隐蔽的情况，是插件装了以后后台开关显示是关的，但缓存里还存着旧规则，你在后台怎么点都没用，得把插件缓存和页面缓存一起清掉才生效。碰上这种情况，先清缓存再复测，别急着把插件整个卸了。

来源三：公司网关或运营商拦截，跟你网站没什么关系

第三类最容易背锅，也最容易被误解成自己网站出问题。有些公司内网会在出口装一层上网行为管理设备，员工访问外部站点时会被重定向到认证页，看着也像人机验证；部分公共 WiFi 更是如此，连上以后必须先看广告或者点一下同意才能上网。有些运营商在特定线路上也会做类似的流量清洗和验证。这种情况的典型特征是，只有某一条线路上的访客喊打不开，换成手机流量、换成家里宽带就一切正常，你自己怎么测都没毛病。

遇到这种反馈别急着改配置，先问一句同事的手机流量能不能开。如果只有公司网络不行，那要解决的是网关那边的事，跟你的网站没关系。把这句话回给访客，比瞎折腾一晚上管用得多。还有个小技巧，让访客在手机热点下用无痕窗口打开一次，两个环境一对比，是不是自家网站的锅，几分钟就能说清楚，不用再来回扯皮。

用 curl -I 摸清底细，再看 403 和那几个响应头

分来源靠猜不行，得有个客观手段。我的习惯是先不碰任何配置，直接在服务器或者本地终端上敲命令，curl -I 后面跟上你的域名，只看响应头不看正文，几秒钟就能拿到关键线索。先看状态码，如果返回的是 403，那基本可以确认请求是被防护层挡下来的，而不是程序报错；如果返回 200 却仍然弹验证，说明拦你的是页面里注入的脚本，方向要转到插件那条线。再看响应头里有没有身份标记，Cloudflare 在触发托管质询时往往会带上 cf-mitigated 之类的头部字段，Server 那一行也能看出请求到底落在谁家的节点上。把这几行记下来，谁在拦你就一目了然了，比坐在那儿翻日志猜半天快得多。

光看域名那一侧还不够，想彻底锁死结论，就用源站 IP 对比测一次。做法是 curl -I 后面直接写源站 IP，再加上 Host 请求头指定域名，把请求绕过 CDN 直接打到源站。如果这样测出来是干净的 200，访问域名却弹验证，那就百分之百确定是边缘那层防护干的，源站清白无辜。反过来，如果绕过去也照样被拦，那问题就在源站自己身上，要么是面板防火墙，要么是程序里的插件或者安全模块。这一步花不了两分钟，却能省掉大量来回试错，尤其是域名前面挂了两三层加速的站点，不做对比根本理不清是谁在动手。

把验证级别从高降到中，别一刀切关掉整个防护

确定是 CDN 或 WAF 在拦之后，下一步就是进服务商控制台调参数。各家面板叫法不一样，一般都在安全、防火墙、CC 防护这几个菜单底下，有的还单独分了站点级的开关。进去之后找到验证级别或者防护等级，把当前的高、严格降成中，多数情况下这一下就能把误伤消掉一大半。这里我要念叨一句，千万别图省事直接把防护整个关掉，那是从一个坑跳到另一个坑，前面挡着的自动化攻击和采集脚本立马全涌进来，服务器负载蹭蹭往上跑。还有个细节，Under Attack 模式如果还开着，记得先关掉它，它是最高优先级的强制验证，级别调了它也不认。改完用无痕窗口实测一遍，别只看控制台提示改成功了就完事。

加白名单：搜索引擎 IP 段和自己的办公 IP 一个都别落下

级别降下来只是缓解，真正要稳当还得靠白名单。第一件事是把搜索引擎的蜘蛛放行，国内站点最要紧的就是百度，它有自己的 IP 段，具体范围和更新情况以百度搜索资源平台的官方页面说明为准，把整段填进白名单，别只加一个 IP，蜘蛛的出口地址是会变的。做法上，有些控制台提供一键放行主流搜索引擎的选项，有就直接勾，没有就手动填 CIDR 段。第二件事是把自己和同事的办公 IP、家里固定 IP 加进去，还有监控和拨测的地址，免得自己调试时被拦在里面，那种感觉相当憋屈。写白名单时注意格式，很多控制台要求 CIDR 写法，带斜杠和掩码位，直接粘个裸 IP 可能不生效还会报格式错误。改完等一两分钟让规则下发，再翻一下拦截日志看看还有没有蜘蛛被挡的记录。

最后一步：让访客清 cookie、换个网络再复测一次

防护调完了，你以为就结束了？还没有，得让访客配合复测，不然反馈还会继续来。原因是验证状态通常会用一个 cookie 记住，访客之前被判定过可疑，浏览器里那枚 cookie 一直存着，防护规则放松了他也未必马上恢复。所以第一步是让他清一遍该站点的 cookie，或者干脆用无痕窗口访问，无痕窗口不继承旧的验证状态，最能反映真实情况。第二步是换个网络试，用手机热点替代原来的 WiFi，换一条出口线路，如果两条线路表现不一样，那问题多半出在线路那边的网关，跟你的网站无关。第三步是隔几个小时再问一次，规则生效和缓存刷新都需要一点时间，刚改完就催着要结果，容易把正常的过渡期当成没修好。

几句老话：防护要开着，但别把自家门焊死

把整件事捋一遍其实就五步：先确认弹的是人机验证而不是浏览器安全警告；用 curl -I 看状态码有没有 403、响应头有没有 cf-mitigated 这类标记；再拿源站 IP 加 Host 头对比测出拦截层；然后进控制台把验证级别从高降到中；最后把搜索引擎 IP 段和办公 IP 加进白名单，让访客清 cookie 换网络复测。还有一条经验，级别放宽之后别撒手不管，盯两三天访问日志，看看有没有人趁机乱刷，真出问题再往回收紧，等到收紧时先把常用 IP 加白，免得下一轮误伤自己。