Invalid Captcha：这个报错是什么意思，以及如何修复
invalid captcha 报错的意思是验证没有通过。网站无法确认你给出的答案，也无法确认浏览器交回的令牌——也就是证明你已通过验证的那个一次性代码。验证码是网站用来区分真实访客和自动化脚本的一道检查，而令牌就是通过这道检查后签发的一次性代码。原因分两类：一类出在你的浏览器和网络连接上，另一类出在网站自己的验证码配置上——后者你自己无论如何都解决不了。
本文接下来会讲：这个报错的含义、哪些提示看起来与它很像、常见原因、按顺序排列的十种修复方法，以及什么时候该停止自己排查、直接给网站管理员发邮件。
“invalid captcha”是什么意思？
invalid captcha 意味着网站的验证服务器拒绝了你的浏览器提交上去的结果。这台服务器就是裁判：它给每一次验证尝试打分，并决定表单能不能提交成功。验证码这部分你早就见过——识读图片里的字符、勾选一个方框，有时甚至不需要任何可见的操作。通过之后，验证码控件会不声不响地把一个令牌交给你的浏览器。网站再把这个令牌送去核验，而“invalid”就是回传的那个答案。
回传什么内容，取决于网站用的是哪套系统。在 reCAPTCHA v2 上，答案确实只有通过和不通过。在 reCAPTCHA v3 上，服务器除了给出通过/不通过的标记，还会返回一个 0.0 到 1.0 的风险评分，而多少分算合格由网站自己决定——所以“invalid”也可能只是说，你的风险评分低于了这个网站设定的阈值。
这个答案并不自动等于你答错了。可能是令牌在你提交表单之前就过期了；可能是绘制控件的脚本没能加载；可能是你的 IP 地址看起来可疑；也可能是网站自己在提交你的令牌时附上了错误的凭据。最后这一种你在自己这边修不了，无论清理什么、重装什么都没用。
与“invalid captcha”相近的报错（以及它们通常代表什么）
同样一次失败，各家网站的措辞并不一样，所以屏幕上出现的具体那句话，是判断问题出在哪一侧的有用线索。
如果报错把责任指向网站的配置——也就是上面任意一条带“site owner”的提示——请直接跳到讲网站侧问题的那一节。其余情况都值得先把修复步骤走一遍。
“invalid captcha”为什么会出现？（常见原因）
这些原因大多与环境有关——在你敲键盘和验证服务器之间，有什么东西干扰了这次检查。
网络不稳定、VPN 或代理
VPN 或代理——也就是把你的流量转发到另一台服务器的服务——会让你用上一个与许多人共享的 IP 地址。验证系统给这个地址的权重很高；在一次很短的访问里，可供观察的行为本来就少，IP 声誉往往就是最主要的信号。比如在 reCAPTCHA v3 上，被标记的地址会一路拉低你的评分，直到网站拒绝提交。在 v2 上你看到的则是它的实际后果：更难的图片验证，或者干脆被拒。快速判断：关掉 VPN、改用移动数据之后，报错是不是就停了？
JavaScript 被禁用或被拦截
验证码控件几乎完全用 JavaScript 写成，也就是在浏览器里驱动交互元素的那种代码。它被禁用之后，控件通常根本不会渲染，也不会签发令牌，表单提交上去的是一个空值。症状：本该出现验证控件的位置只有一片空白，或者一个显示异常的方框。
浏览器扩展与隐私工具
广告拦截、脚本拦截和反跟踪类扩展经常把验证脚本判定为跟踪器并加以拦截。结果是控件只加载了一半，或者令牌根本到不了网站。快速判断：在 Chrome、Edge、Firefox 或 Safari 的隐私窗口里报错消失了——那里的扩展默认是关闭的。
浏览器版本过旧或设备不兼容
旧版浏览器缺少当前控件所依赖的安全标准和 API，因此验证要么无法初始化，要么悄无声息地生成一个不可用的令牌。这在已停止支持的手机、电视浏览器和长期不打补丁的办公电脑上很常见。一个常见症状：控件一直转圈，永远加载不完。
Cookie 与损坏的浏览器配置文件
验证依赖 Cookie，也就是网站存在你机器上、用来识别会话的小文件——reCAPTCHA 会写入自己的 Cookie，而严格拦截第三方 Cookie 有可能把整个流程打断。如果 Cookie 被阻止，或者你的会话数据已经错位，令牌就会和它所属的会话对不上。控件脚本在缓存里留下过期副本也有可能，但并不常见，因为这类脚本的缓存有效期设得很短。症状：同一台电脑上，报错在某个浏览器里反复出现，换另一个就没有了。
DNS 与 IP 声誉问题
DNS 就是把域名换成服务器 IP 地址的那本“电话簿”。如果你的解析服务器很慢、出故障或者被过滤，控件要加载的那些域名就永远不会应答，验证在到达页面之前就已经死了。声誉同样重要：一个和被感染机器共用的家庭 IP 地址，会背上并非你造成的历史包袱。快速判断：换一个网络，同一个页面还有问题吗？
杀毒软件 / 防火墙的 HTTPS 扫描
HTTPS 扫描是一项安全功能：它把加密流量拆开、检查内容，再重新签名。这种改写可能破坏控件自己的加密请求，让验证始终无法完成。症状：同一台机器上的多个浏览器都过不了验证，而且只有这台机器如此。
如何修复“invalid captcha”（分步操作）
请按顺序逐条尝试，每做完一步都重新试一次表单——靠前的几步就能解决大多数情况。
1. 刷新验证码并重新加载页面
点击控件上的刷新图标，或者重新加载页面，然后一口气把验证做完、中间不要停顿。这样会签发一个新令牌，凡是令牌过期或脚本加载不全导致的问题都能解决。表单能正常提交，就说明这一步生效了。
如果你使用屏幕阅读器，可以点音频验证按钮换成语音形式（前提是它存在）。需要注意的是，一旦你的请求被标记为可疑，音频选项本身也会被收走。
2. 更新浏览器（Chrome、Firefox、Edge）
打开浏览器的“关于”或“帮助”菜单，装上所有待更新的内容，然后重启浏览器。Chrome 和 Edge 会自动更新，所以打开这些页面主要是为了强制触发一次检查。只有当前版本才支持控件所需的标准。成功的标志是勾选框立刻出现，而不是卡住不动。如果你的设备已经收不到浏览器更新，请直接跳到第 10 步。
3. 启用 JavaScript
打开浏览器的网站设置，确认 JavaScript 处于允许状态——全局和这个具体网站都要确认。没有它，控件既画不出自己，也生成不了令牌。启用后重新加载页面：原本空白的位置出现了可以正常交互的验证，就说明修好了。
4. 关闭扩展（或改用隐私窗口）
打开隐私窗口或无痕窗口，在里面提交表单试试。如果能成功，再把扩展一个一个重新打开，找出那个拦截者——广告拦截和反跟踪工具是老熟人。找到之后，把这个网站加进它的白名单就行，不必把整个扩展关掉。
5. 清除该网站的 Cookie
在浏览器的隐私设置里，只清除 这个具体网站的 Cookie，不要一次清空全部，然后重新加载页面并再次登录。这样能删掉错位的会话数据，正是它让一个有效的令牌看起来像是错的。
有一点值得知道：在基于评分的系统里，Cookie 历史正是把你标记为“老资格真人”的信号之一。把整个配置文件清空，可能让你接下来的几次尝试显得 更可疑，而不是更清白。精准清理胜过全部清空。
6. 关闭 VPN / 代理
断开 VPN 或代理，或者换一个服务器位置，然后重新提交表单。这样你的流量就来自一个有自己声誉的地址，而不是与成千上万用户共享的那一个。断开后第一次就通过，基本可以确认问题出在共享 IP 上。
7. 更换 DNS
在网卡或路由器设置里，把当前的 DNS 服务器换成公共解析服务——Google Public DNS 的 8.8.8.8和 8.8.4.4、Cloudflare 的 1.1.1.1，或者 Quad9 的 9.9.9.9。一个正常工作的解析服务能够连上控件所需的域名。
有个坑：如果你的浏览器启用了 DNS-over-HTTPS，它可能会完全忽略系统里的设置。请顺便检查浏览器自身的安全设置，否则这个改动不会有任何效果。
8. 重置 IP / 重启路由器
重启路由器，或者断开再重新连接，向运营商申请一个新的 IP 地址。如果先前那个地址已经背上了不好的声誉，这么做 可能有帮助——但并不保证。DHCP 租约还在有效期内时，往往会拿回同一个地址；而如果运营商用的是 CGNAT，你的公网 IP 本来就和其他用户共享，根本不会变。要是毫无变化，第 10 步的移动数据测试能说明更多。
9. 检查杀毒软件 / 防火墙的脚本过滤
在安全软件里找到 HTTPS 扫描、网页防护或脚本过滤，短暂关闭它做一次测试。如果验证码随后就正常了，请把这个网站加为例外，而不要让防护一直处于关闭状态。拿到结论后立刻把功能重新打开。
10. 换一台设备或换一个网络
用手机的移动数据打开同一个页面，或者换一台电脑试试。这是决定性的测试：如果在别处能通过验证，原因就在本地；如果处处都失败，问题就不在你的环境。这种情况下，请看下一节。
当问题出在网站（或验证码集成）一侧
有一部分 invalid captcha 报错，访客根本无从下手，因为问题出在网站接入验证的方式上。
site key 无效 / 域名不匹配
一个控件需要两个密钥。site key（站点密钥）是公开的，就写在页面里，用来标识它背后的账户。secret key（私密密钥）留在网站的服务器上。两者必须配对，而且域名要在为它们登记的名单里。这里出任何差错——把两个密钥装反、漏掉一个字符，或者从旧项目里粘过来一个——每一位访客都会撞上同一面墙： "ERROR for site owner: Invalid site key."域名未登记则会给出它自己的变体，那句提示里点名的是域名，而不是密钥。
令牌校验错误
网站的服务器必须把你的令牌发到验证接口，并正确读取回复。当这个请求格式错误、发得太晚，或者拿一个已用过的令牌重复提交时，回复就是拒绝。比如，Google 的 siteverify 明确记录了六个错误码，而且它们按责任在哪一侧分得很清楚：
- missing-input-response —— 根本没有发送令牌。
- invalid-input-response —— 令牌格式有误。
- timeout-or-duplicate —— 令牌本身有效，但太旧了，或者已经被用过。
- missing-input-secret / invalid-input-secret —— 网站的 secret key 缺失或填错。
- bad-request —— 验证请求本身格式错误。
你明明通过了验证，表单却依然拒绝你。
验证码不加载 / 一片空白 / 无限循环
控件始终空白、显示错误框，或者一张接一张地换图片却从不接受答案，通常说明集成有问题，或者服务本身出现故障。判断规则很简单：如果同一个报错跟着你换设备、换网络也不消失，责任就在网站。请联系网站管理员或该服务的技术支持，并把报错原文一字不差地附上。
如果你站在这个报错的另一侧——你是网站的所有者，或者正在检查自己的集成——那么每一次自动化测试运行同样要通过这道验证。CapMonster Cloud 用于在你拥有或已获授权测试的资源上做测试自动化，具体配置可以参考 入门指南，以及 reCAPTCHA 识别 API 的文档。
FAQ: invalid captcha
结语
先弄清这个报错在告诉你什么，再拿那些原因对照自己的环境，然后按顺序把十个步骤走一遍。大多数 invalid captcha 报错都与环境有关——一个 VPN、一段被拦截的脚本、一个过期的 Cookie——在前几步里就会消失。如果换了设备、换了网络这条提示依然存在，那大概是网站的集成有问题，只有它的管理员能修好。
给网站所有者和测试人员的说明。 如果你在维护一个表单，或者为测试目的去填写表单，那么每一次自动化测试运行同样必须通过验证。CapMonster Cloud 是一项商业验证码识别服务，正是用在这种场景里；它的 API 参考和 验证码文档介绍了如何配置，而我们的 reCAPTCHA v2、v3 与 Enterprise 对比讲清了这款常见验证码各版本之间的差别。请仅在你拥有或已获得合法授权测试的网站上使用它。它不会解决上面提到的访客侧报错，也不是绕过你无权控制的防护的途径。
