为什么 2FA 验证码无法通过？

TOTP Authenticator 验证码只有在服务端和生成器使用同一个 secret、同一个时间窗口和同一组参数时才会通过。遇到 2FA 或 MFA 验证码被拒绝、过期、无效，或和另一个 Authenticator 应用显示不同，可以按这个清单排查。

最后更新: 2026-09-12

先检查时间同步

TOTP 使用当前 Unix 时间和时间步，通常是 30 秒。如果设备时间不准，或你在验证码即将过期时提交，服务端可能会拒绝这个验证码。

每个账号都应该有独立的设置 secret。来自错误账号、issuer、工作区或旧设置密钥的验证码，在生成器里看起来正常，但登录页面会验证失败。

大多数服务使用 SHA-1、6 位、30 秒，但也有服务使用 SHA-256、SHA-512、8 位或自定义周期。生成器必须和服务端设置一致。

TOTP Authenticator 验证码不是短信验证码、邮箱验证码、推送确认、Passkey 提示、备用码或恢复码。登录页面必须是在要求输入 Authenticator 应用验证码。

如果验证码快过期了，等下一个验证码再提交。有些服务还会拒绝重复使用已经成功验证过的一次性验证码。

如果设置 secret 丢失、删除，或在重新设置 2FA 时被替换，生成器无法重新创建正确验证码。请使用恢复码或服务商的账号恢复流程。

用这个表把失败现象对应到最可能的 TOTP 原因、应检查的内容和下一步修复方式。

现象	可能原因	检查什么	修复方式
快速复制后仍被拒绝	设备或浏览器时间不同步	对比设备时间和自动网络时间，并等到下一个 30 秒窗口	开启自动日期、时间和时区，然后刷新生成器
另一个 Authenticator 应用显示不同验证码	账号、issuer、工作区或 setup secret 不同	对比 issuer、账号标签、邮箱地址和原始 Base32 设置密钥	使用当前登录页面对应账号的设置密钥
密钥能识别但验证码始终无效	复制的设置密钥不完整或有错误字符	从账号设置页面重新复制 Base32 secret 或完整 otpauth URI	重新粘贴原始设置值，不漏掉任何字符
验证码位数或倒计时和服务不同	算法、位数或周期不匹配	在 otpauth URI 或设置页面中查找 SHA-1/SHA-256/SHA-512、6/8 位和周期	设置成和服务一致的算法、位数和周期
有时能用，但倒计时快结束时失败	验证码在验证前过期，或已经被使用过	检查剩余秒数，以及同一个验证码是否已经提交过	等待新的验证码，并在时间窗口前半段提交
登录页要求其他验证方式	页面要的是短信、邮箱 OTP、推送确认、passkey、硬件密钥、备份码或恢复流程	阅读登录页文案，确认它是否要求 Authenticator 应用验证码	使用页面要求的方法或账号恢复；TOTP 生成器不能创建这些验证码

在运行生成器的设备上开启自动日期、时间和时区，然后刷新页面或等待下一个 TOTP 时间窗口。

不要提交只剩几秒的验证码。等倒计时重置后，立刻复制新的验证码。

确认生成器名称、issuer、邮箱、工作区或服务标签，和正在拒绝验证码的登录页面一致。

如果仍然失败，重新粘贴原始 Base32 设置密钥或 otpauth://totp/ 链接，避免漏字符或复制错字符。

使用服务页面显示的同一组 algorithm、digits 和 period。常见默认值是 SHA-1、6 位、30 秒。

如果 2FA 被重置、迁移或删除，旧 secret 可能已经失效。请使用恢复码或联系服务管理员。

最常见原因是设备时间偏移、使用了错误账号的 secret、设置密钥复制错误，或 TOTP 参数和服务端不一致。

有影响。验证码在时间窗口末尾生成时，可能在服务端验证前已经过期。等待新的验证码通常能解决偶发失败。

通常不能。TOTP 验证码有效时间很短，而且许多服务会拒绝重复使用已经成功验证过的验证码。

它们可能使用了不同的设置 secret、账号标签、算法、位数、周期或设备时间。需要对照原始设置密钥和参数。

不能。有效的 TOTP 验证码必须有共享设置 secret。secret 丢失时，请使用备用恢复码或账号服务商的恢复流程。