验证码无法使用：2026 年为何失效以及如何修复

你点进表单，本该出现复选框的地方却是一片灰色的空白。所谓验证码无法使用，指的是验证不加载、不渲染，或者渲染出来之后依然不放你通过。验证码是网站用来区分真人和机器人的自动化测试，而它的代码由另一家公司的服务器提供——问题大多就出在这里。这和"验证失败"不是一回事：后者发生在你提交之后，服务器拒绝了你的令牌。

下文依次讲症状、各家服务商的差异、2026 年的具体原因，以及浏览器端、手机端和网站端的修复方法。

"验证码无法使用"具体是什么样子

验证码出问题大致有五种表现，而你屏幕上看到的那一种，能把原因范围缩小很多。

• 控件区域空白或一片灰。页面留出了位置，却什么都没渲染出来。脚本被拦截、根本没被请求，或者被页面的安全策略拒绝了。
• 复选框或图片验证始终加载不出来。reCAPTCHA 加载不出来时，你会看到一直转圈的加载图标、只显示一半的框架，或者一个空盒子：加载开始了，连接却中断了。为无法完成图片九宫格的用户准备的音频验证也会以同样的方式失败，因为它来自同一个域名。
• 陷入无限循环。你选完图片，验证重新加载，然后又让你再来一遍，没完没了。这通常是会话、cookie 或系统时间的问题，而不是答错了。
• "Cannot contact reCAPTCHA"或连接错误。浏览器打开了页面，却连不上服务商的服务器。首先要怀疑的是网络过滤、DNS 或 VPN。
• 复选框打上了勾，表单却仍然提交不了。控件本身是正常的；令牌没有被附加上，或者在提交时被拒绝。reCAPTCHA 的答案也只有两分钟有效期：一旦过期，勾看起来还在，背后的隐藏字段却已经被清空，于是表单提交时什么都没带上。

无论你搜的是验证码加载不出来、验证码控件不显示、reCAPTCHA 不显示，还是干脆就是验证码坏了，这些情况都能落到上面的清单里，本文余下的部分会逐条讲原因。

验证码无法使用、验证失败、invalid captcha：三者的区别

这三种说法描述的是不同的故障，本文只讨论第一种。

无法使用或加载不出来属于客户端问题：控件渲染不出来，或者不让你完成验证。这正是本文的主题。

验证失败意味着验证本身跑通了，但服务器拒绝了令牌。令牌过期和重复提交也属于这一类：所有服务商签发的令牌都是一次性的，而且有效期很短——reCAPTCHA 和 hCaptcha 是两分钟，Turnstile 是五分钟。reCAPTCHA v3 风险分数过低同样属于服务端这一类。关于这条路径，请参见我们的 reCAPTCHA 验证失败的常见原因与解决办法。

Invalid captcha是网站自己的校验提示，通常出现在验证码输错，或者表单一直开着直到验证过期之后。你的答案已经送达并被拒绝，控件本身并没有坏。如果你看到的正是这条提示，可以看看 "invalid captcha"提示到底意味着什么。

reCAPTCHA、hCaptcha 和 Cloudflare Turnstile：快速对比

每家服务商加载代码的方式略有不同，这会改变你首先应该怀疑的对象。

Google reCAPTCHA（v2 复选框 / v3 隐形）

reCAPTCHA v2 就是那个"我不是机器人"的复选框，当 Google 需要更多证据时，背后还会出现图片九宫格。v3 什么都不显示，而是在后台给你打分。两者都从 Google 的主机拉取代码，所以 reCAPTCHA 无法使用通常可以追溯到对 www.google.com/recaptcha 或 www.gstatic.com 的请求被拦截、site key 来自另一个域名，或者标记里指向了旧的脚本 URL。v3 没有可观察的控件，所以你只有在表单拒绝提交时才会发现问题。

有两个细节能省不少时间。Google 提供了 www.recaptcha.net，在 www.google.com 不可达的场合可以直接替换使用——这是在过滤 Google 的网络里解决"cannot contact reCAPTCHA"的最佳办法。reCAPTCHA 还会设置自己的 cookie _GRECAPTCHA，用于风险分析，不要把它误认成跟踪器。Enterprise 版本通过 enterprise.js 从同样的主机加载，所以上面关于加载的建议依然适用，但验证走的是 reCAPTCHA Enterprise API，而不是传统的 siteverify 端点。

hCaptcha

hCaptcha 先显示一个复选框，如果还想再确认一次，就给出图片任务——多见于注重隐私的网站。脚本来自 js.hcaptcha.com，静态资源和 API 调用则分布在 hcaptcha.com 的其他子域上，hCaptcha 要求你不要把这些子域写死，因为它们会随地区和时间变化。

如果什么都没渲染出来，先怀疑内容拦截器过滤了这些主机，或者嵌入脚本被复制过来时漏掉了容器——也就是一个带 h-captcha 类和你的 data-sitekey 的空元素。通常不是问题的地方：hCaptcha 的 sitekey 默认在任何域名上都能用，因为域名白名单是按 sitekey 选择性开启的——在追查主机名这条线之前，先确认它到底有没有被打开过。宿主页面上禁止服务商 iframe 的框架策略，同样会让你什么都看不到。

Cloudflare Turnstile

Turnstile 是 Cloudflare 的验证，通常是一个不用做题就能完成验证的小控件。它从 challenges.cloudflare.com 加载，而且 Cloudflare 要求直接访问该主机，不能走代理或打包。它失效的情形有：扩展或防火墙拦截了这个主机；主机名没有包含在 Cloudflare 控制台中该控件的主机名配置里；或者控件是在脚本运行完之后才被注入的。

令牌有效期为 300 秒，且只能兑换一次；表单填得慢或者重复提交会返回 timeout-or-duplicate，此时需要调用 turnstile.reset()，而不是简单重试。没有令牌就无法提交，所以一个卡住的控件会把整个表单拖住。托管式验证在最终通过前短暂显示一个过渡页面，这不是故障。

验证码为什么无法使用：2026 年的常见原因

把 reCAPTCHA 无法使用，或者任何验证码故障往回倒推，最后都会落到三个地方之一：脚本、网络，或者密钥。

JavaScript 被禁用或被拦截

你会遇到的验证码基本上全都依赖 JavaScript，所以脚本一关，就没有任何东西可渲染。无论你是全局禁用了它、给这个站点单独拦截过后来忘了，还是处在企业策略之下，结果都一样。NoScript 这类扩展是选择性拦截：文字和图片照常加载，于是故障看起来只针对这个站点。其实不是。

有一个例外能解释为什么偶尔还有站点能用：reCAPTCHA v2 提供了一个官方文档中的 <noscript> 回退方案，会在一个普通 iframe 里渲染验证。很少有集成会加上它，所以在没有 JS 的情况下还能用的验证，应当视为例外。

广告拦截器、隐私扩展和跟踪保护

内容拦截器按黑名单过滤请求，而有几份名单把验证脚本归到了跟踪器里。拦掉 google.com/recaptcha、 hcaptcha.com 或 challenges.cloudflare.com，控件区域就会一片空白。严格的脚本拦截器、杀毒软件的防护模块和 DNS 层面的拦截器也是同样的效果。这里的取舍是真实存在的：凡是切断跨站跟踪的手段，都容易连带弄坏第三方验证控件，所以请只把这一个站点加入白名单，而不是卸载任何东西。

第三方 cookie 限制与跨站状态

这一部分是过时最快的。Google 在 2025 年 10 月 17 日终止了 Privacy Sandbox，弃用了剩下的十个 API；Chrome 从 2026 年 1 月的 Chrome 144 开始逐步废弃它们，计划在 Chrome 150 彻底移除。第三方 cookie 从未被 Chrome 移除，而且会无限期保留下去。这就是为什么 2024 年那批把问题归咎于"cookie 即将淘汰"的指南，和你手上的浏览器对不上。

真正还会咬人的是普通的 cookie 限制，而各家浏览器的做法并不相同。Chrome 默认允许第三方 cookie，在无痕模式下拦截，也可以用一个开关在所有场合都拦截。Safari 直接拦截。Firefox 的 Total Cookie Protection 在标准模式下默认开启，它不是拦截，而是按站点把 cookie 隔进各自独立的容器；严格模式则完全拦截跨站 cookie。验证控件是在第三方框架里加载的，所以过于激进的限制会让它一直转圈或者陷入循环。

两个具体细节。Chrome 限制第三方 cookie 时，会在地址栏显示一个眼睛图标；点它就能为这一个站点开一个例外，这比全局关闭保护要好。对开发者来说，Storage Access API 是嵌入式框架申请跨站状态的官方途径，比依赖那些已经被分区隔离的 cookie 更可靠。

内容安全策略（CSP）拦截脚本

CSP 是 Content Security Policy 的缩写，指网站发送的一个响应头，用来声明它在脚本、框架和样式方面信任哪些主机。如果服务商没有被写进 script-src 或 frame-src，浏览器就会拒绝请求、记录一条违规，并且什么都不画。访问者无法绕开它；这是站点所有者的事。具体指令写在下面的开发者章节里，而最常被漏掉的主机并不是脚本主机，而是 recaptcha.google.com，它属于 frame-src。

VPN、代理、DNS 和防火墙过滤

VPN 或代理会改变你的出口 IP 地址，这可能触发额外的验证。更麻烦的是，VPN 客户端自带的广告拦截、私人 DNS 配置、企业防火墙和校园网经常会过滤服务商的域名，于是你看到的是连接错误，而不是一个控件。

浏览器版本过旧、缓存/cookie 以及系统时间不准

旧版本浏览器缺少控件需要的 API 和 TLS 支持。缓存里过期的脚本和损坏的 cookie 只会弄坏某一个站点的会话，其他站点照常工作。

时间的问题值得单独拿出来说，因为流行的说法夸大了它的影响。差几分钟并不会破坏 TLS：证书的有效期是按天算的，而证书颁发机构通常会把生效时间往前挪，正是为了吸收这种偏差。几分钟的偏差破坏的是令牌的时效——reCAPTCHA 的令牌只有两分钟有效期，一台时间偏慢的设备提交的令牌，在服务器看来已经过期，表现出来就是验证一遍遍让你重试。偏差达到几小时或几天，就会出现证书错误，验证根本连不上。

HTTP/HTTPS 混合内容与过旧的 api.js

如果一个 HTTPS 页面通过 HTTP 请求验证脚本，浏览器会以混合内容为由拦截它，控件就无声无息地消失了。页面仍然引用已废弃的脚本路径、而不是当前的 api.js 端点，或者同时加载两个互相冲突的版本，结果也一样。

网站配置错误（site key 无效、域名不匹配）

site key 是密钥对中公开的那一半。在 reCAPTCHA 和 Turnstile 里，它与所有者注册的主机名绑定；在 hCaptcha 里，这项限制是选择性开启的。打错一个字符、粘贴了另一个项目的密钥，或者忘了把当前提供服务的主机名加进去，服务商就什么都不会画。密钥或域名无效的报错，就在控制台里等着你。

如何在浏览器里修复验证码（分步操作）

请按给出的顺序来做；大多数人根本走不到第四步。这就是访问者视角下"如何修复验证码"的实操答案，尤其适用于"验证码在 Chrome 里不工作"这种情况。

1. 强制刷新，排除页面缓存过期

Windows 上按 Ctrl+F5，macOS 上按 Cmd+Shift+R，可以在不复用缓存的情况下重新加载页面，把那个只加载了一半或者已经过期的脚本丢掉——很多空白控件框背后就是它。这是成本最低的原因，所以在动任何设置之前，先把它排除掉。

2. 启用 JavaScript

确认 JavaScript 在全局和这个域名下都被允许，因为按站点设置的例外，往往比你当初添加它的理由活得更久。在 Chrome 里，这一项藏在设置 → 隐私和安全 → 网站设置 → JavaScript。同时看一下 NoScript 之类的扩展是不是在拦着这个页面。

3. 试试无痕 / 隐私窗口（关闭扩展）

在 Chrome 和 Edge 里，隐私窗口是把扩展排除在外最快的办法，因为扩展在那里默认就是关闭的。Firefox 在隐私窗口里照样运行扩展，Safari 也可以，所以在这两个浏览器里需要手动关掉。注意无痕模式同时还会拦截第三方 cookie，也就是说你一次改了两件事：如果空白控件在隐私窗口里出现了，问题指向扩展；如果它渲染出来了却接着陷入循环，问题指向 cookie 限制，那么第五步才是你的解法。

Safari 的 阻止跨网站跟踪选项，在 macOS 上位于设置 → 隐私，在当前版本的 iOS 上位于设置 → 应用 → Safari 浏览器。关掉它是全局生效的，没有按站点的例外，所以填完表单之后记得重新打开。

4. 停用广告拦截器和隐私扩展

如果隐私窗口里一切正常，就一个一个把扩展装回去，直到再次出问题。大多数拦截器都支持按站点暂停，这比在其他所有网站上都失去保护要好。要特别注意严格名单和反跟踪名单，以及杀毒软件的浏览器插件——它们会不声不响地过滤这些主机。

5. 清除该站点的缓存和 cookie

只清这一个域名的数据。在 Chrome 里，点击地址栏左侧的调节图标——也就是 Chrome 117 里取代小锁的那个滑块图标——然后进入网站设置，再删除已存储的数据。如果问题不是数据过期而是第三方 cookie，同一栏里的眼睛图标可以为这个站点开一个例外。你清掉的，正是"答案明明选对了、验证却一直重新加载"背后那个过期的会话或者损坏的 cookie。

6. 关闭 VPN 或代理

断开 VPN，在系统网络设置里停用所有代理，然后重新加载。同时把 VPN 客户端自带的广告拦截或"威胁防护"关掉：这一层会独立过滤域名，即使隧道已经断开，它照样继续拦截验证。

7. 更换 DNS 或换一个网络

如果你的解析服务器过滤了服务商的域名，就在操作系统的网络设置里改用主流的公共 DNS 服务，或者用手机热点再试一次。只有在移动数据下才正常的验证，说明过滤发生在你的路由器、DNS 或防火墙上，而不是浏览器里。

8. 更新浏览器

装上最新的稳定版，重启，然后在"关于"页面上核对版本号，别只相信自动更新。过旧的引擎缺少控件需要的 API，而被放弃维护的版本还会积累证书问题，导致连不上服务商的服务器。受管理的浏览器可能需要由管理员推送更新。

9. 用自动同步校正系统日期和时间

打开日期、时间和时区的自动同步。几分钟的偏差会让两分钟有效期的令牌一到就过期，表现出来和"验证码一直让你重试"一模一样；偏差达到几小时或几天，则会产生证书错误，验证根本连不上。

10. 换一个浏览器或设备试试

在另一个浏览器或者手机上打开同一个页面。如果那边正常，说明问题在本地，上面的步骤能帮你缩小范围。如果在所有浏览器、所有网络下都失败，那就是网站配置有问题，请看开发者那一节。

手机端修复：Android 和 iPhone

验证码在手机上无法使用，原因通常在于页面是在哪里打开的，而不是手机本身。

离开应用内置浏览器。在社交或聊天应用里点开链接，页面会在 WebView 里打开——那是一个功能被削减、存储也独立的内嵌浏览器。关于验证码在手机上不工作的反馈，大部分都是从这里开始的。请通过应用的菜单在 Chrome 或 Safari 里打开链接，登录场景尤其要这样做。

检查私人 DNS 和 VPN 配置文件。Android：设置 → 网络和互联网 → 私人 DNS。iPhone：设置 → 通用 → VPN 与设备管理。带广告拦截的 DNS 配置会过滤服务商的域名，只留给你一个空白控件。

清除该域名的网站数据。在 Chrome 里：设置 → 隐私和安全 → 清除浏览数据，然后勾选 cookie 和网站数据。在 iPhone 上，Safari 的相关开关在系统"设置"应用里：当前 iOS 的路径是设置 → 应用 → Safari 浏览器 → 高级 → 网站数据，然后只删掉那一个站点。

关闭省流量模式和精简模式。这类模式会延迟或代理后台请求，而部分手机浏览器在启用时会剥掉第三方脚本，控件区域于是一片空白。Chrome 的 Lite 模式早在 2022 年就已下线，所以这一条主要针对 Opera Mini、三星浏览器以及仍然带压缩模式的厂商浏览器。

如果你完全看不到验证码，请双指捏合缩小、横屏，或者请求桌面版网站。屏幕过窄时，控件有时会被渲染到可视区域之外，或者藏在固定定位的元素后面。

开发者侧修复：验证码控件在你自己的网站上加载不出来

如果验证码控件对所有访问者都不显示，或者 reCAPTCHA 只在某一个主机名上不显示，原因在你的配置，而不在他们的浏览器。

检查 site key、secret key 和允许的域名

确认标记里那个公开的 site key 与控制台中的项目一致，并且把 secret key 保留在服务端。域名范围的规则各家不同：

• reCAPTCHA 把一个密钥绑定到一份受支持域名的清单上，每个密钥最多 250 个； localhost 只有在你自己添加之后才有效。请把开发密钥和生产密钥分开，并且只在开发密钥上放行 localhost。
• hCaptcha 在你为某个 sitekey 启用域名白名单之前，会在任何域名上提供服务；同时它会直接拒绝 localhost 和 127.0.0.1。本地开发时，请在 hosts 文件里加一条类似 127.0.0.1 test.mydomain.com 的记录，然后用这个名字访问。hCaptcha 和 reCAPTCHA 都提供了测试密钥对——只能用于测试环境，因为它们不提供任何保护。
• Turnstile 在控制台里按控件管理主机名，其中还有一个"Any Hostname"选项，适用于白名单不合用的场合。

加载正确的脚本

使用当前的端点——reCAPTCHA 的 api.js（或 enterprise.js）、Turnstile 的 api.js，或者 hCaptcha 的 api.js，来自 js.hcaptcha.com——都只从服务商自己的域名加载一次，绝不要自托管、打包或走代理。检查它没有被延迟到你的代码调用 render 之后才执行，也要确认没有插件、主题或标签管理器又加了一份；两个版本会抢同一个容器。如果 www.google.com 对你的用户不可达，就把站点上所有 reCAPTCHA 的引用统一换成 www.recaptcha.net。

修正 CSP 与 script-src 等指令

如果你的站点发送了 Content Security Policy，请为服务商扩展它。官方公布的要求如下：

有三点需要确认。 frame-src 里缺条目，会留下一块空白，控制台里则是一条违规记录。hCaptcha 要求不要把资源子域写死，例如 newassets.hcaptcha.com，因为它们会随地区和时间变化——请使用通配符。另外，来自 CDN 或反向代理的策略并不会替换你的策略：浏览器会独立执行每一条策略，因此最终生效的是最严格的组合。只要代理那一层的响应头漏掉了服务商，你在应用响应头里放行也没有用。

用 HTTPS 提供页面，不留混合内容

整页都走 HTTPS，每一个资源引用都明确写成 https://——协议相对的 // 写法是 HTTP 时代的遗留。只要有一个脚本标签写死成 http://，浏览器就会把验证当作混合内容丢掉，而周围的一切照常渲染，所以这个毛病藏得很好。中途回落到 HTTP 的重定向链也是同样的效果。

在客户端处理过期，而不只在服务端

注册过期回调。reCAPTCHA 和 hCaptcha 的答案在两分钟后失效，Turnstile 的令牌是五分钟；如果没有 expired-callback，控件看上去还是已完成的样子，背后的隐藏字段却是空的，于是你的服务器报的是"令牌缺失"，而不是"令牌过期"。请在用户真正执行操作的那一刻生成令牌，而不是在页面加载时，并且重置控件而不是重放旧令牌——所有服务商都会拒绝第二次兑换。

查看浏览器控制台和网络面板

打开开发者工具并重新加载。控制台会直接点明故障——密钥无效、域名无效、CSP 违规、混合内容。在网络面板里按服务商的域名过滤，就能看出请求是发出去了、被拦截了，还是返回了错误。请在关闭扩展的干净配置文件里做这件事，否则你会去追一个服务端的 bug，最后发现罪魁祸首是广告拦截器。

验证码排查清单

面向用户

• 先强制刷新页面
• 确认该站点允许 JavaScript
• 在隐私窗口里测试，Firefox 和 Safari 需要手动关闭扩展
• 只为这一个站点暂停拦截器
• 在 Chrome 里，通过地址栏的眼睛图标允许第三方 cookie
• 在 Safari 里取消勾选"阻止跨网站跟踪"，用完再打开
• 清掉该域名的 cookie 和缓存
• 断开 VPN、代理和带过滤的 DNS
• 更新浏览器；开启时间自动同步
• 在手机上离开应用内置浏览器
• 换一个网络重新测试

面向开发者

• 逐家核对 site key、secret key 和主机名范围
• 各家的本地开发方式：reCAPTCHA 开发密钥放行 localhost，hCaptcha 用 hosts 记录，测试密钥只用于测试环境
• 服务商脚本只加载一次，不走代理，直接来自其自有域名
• 在 script-src、 frame-src 里放行服务商域名，必要时再加上 style-src/connect-src
• 检查是否还有一条来自 CDN 或代理的 CSP——策略会叠加，最严格的那条生效
• 全站走 HTTPS，不留混合内容
• 接好过期回调，并在提交时生成令牌
• 在干净的配置文件里读控制台和网络面板
• 确认容器在 render 执行之前已经存在
• 在 Android、iOS 和 WebView 上都测一遍

什么时候该联系网站管理员

当证据指向服务端，而且任何浏览器层面的改动都不起作用时，就该把问题往上提了。

如果控制台在加载时报出 site key 或域名无效，请联系站点所有者；只有他们能改。如果验证在多个浏览器、多个网络和多台设备上对所有访问者都缺失，也一样——这已经排除了你自己的环境。CSP 来自服务器，所以拦掉服务商域名的策略同样是他们的活。请把报错原文、页面 URL、你的浏览器版本一并给他们，并说明你已经在关闭扩展的情况下测过。含糊的反馈只会排队等着，这样的反馈才会被修。

关于自动化测试：CapMonster Cloud

如果你自己在维护网站，那么确认修好的控件确实能加载、能完成验证，也是修复工作的一部分。CapMonster Cloud 支持 reCAPTCHA v2、v3 及其 Enterprise 版本，可用于你自己拥有或已获授权测试的站点上的自动化测试流程，并且能接入 Selenium 或 Puppeteer 测试套件。请求格式可以在 CapMonster Cloud 的 reCAPTCHA v2、 v3、 v2 Enterprise 以及 v3 Enterprise 等文档中找到。

法律提示：只测试你自己拥有或已获授权测试的站点，并遵守各站点的服务条款和适用法律。

结语

验证码无法使用是加载环节的问题，不是验证环节的问题。先从症状出发，把它对应到一个原因——脚本被拦截、隐私设置、网络过滤、浏览器过旧，或者网站配置有误——然后按顺序做一遍浏览器端的步骤。如果验证对所有访问者都是坏的，或者 site key 在加载时就被拒绝，那就带上你手上的证据，把问题提给网站管理员。

相关文章

• reCAPTCHA 验证失败怎么办：常见原因与解决办法
• "invalid captcha"提示到底意味着什么
• CapMonster Cloud 文档： reCAPTCHA v2、 v3、 v2 Enterprise、 v3 Enterprise