CoinSalve · 独立运营的第三方排障资料站,非 OKX 官方网站
CoinSalve欧意 / 欧亿 / ouyi · 账号与客户端排障
2026 年 9 月
官方域名怎么辨认 见防伪指南
首页 / 故障排查 / 验证器的码总提示错误

验证器的码是手机按时间算出来的,时钟一偏平台就认不出

作者:老盐 · CoinSalve 编辑组 更新:2026 年 10 月 7 日 ✓ 算法对照 RFC 6238,菜单名对照苹果、安卓与谷歌身份验证器的帮助页
身份验证器的 6 位动态码由手机本地密钥和系统时间算出,手机时钟不准时平台校验不通过

身份验证器上那 6 位数由手机自己算:拿绑定那天存下的密钥,加上手机此刻的时间,跑一遍公开的算法。平台那边用同一段密钥和它自己的时钟再算一遍,两个结果相同才放行。中间没有谁把数字发给谁,所以码被拒的时候,先看手机的时间,再看你读的是哪一条。

动手顺序很短。到系统设置里把日期与时间改回自动,回到验证器等数字换成下一组,再输一次。还是被拒,就往下分清自己是四种情况里的哪一种。这里只讲码为什么对不上;手机丢了、条目没了要怎么找回,在两步验证换手机、丢手机、恢复码没了怎么办里。

身份验证器的码按什么算,平台允许时间差多少

这套算法叫 TOTP,写在 IETF 的公开文档 RFC 6238 里。它把时间切成等长的小段,每段叫一个时间步长,默认 30 秒。手机取当前的 Unix 时间,除以 30,只留整数部分,得到「现在是第几段」;再把这个序号和密钥一起算,截出几位数字显示给你。同一段里不管算多少次,结果都是同一个数。

平台收到你输的码时,并不知道你的手机是在哪一秒算出它的,只能按自己时钟所在的那一段去比。考虑到输入和网络都要花时间,文档对校验一侧给了两条建议,平台可以照着设,也可以设得更严或更松。

RFC 6238 里的参数文档给的值或建议对你意味着什么
时间步长默认 30 秒验证器上的数字 30 秒换一次
传输延迟建议最多容许一个时间步长码刚换掉时输上一组,有的平台还收,有的不收
时钟漂移建议校验方设一个步数上限,往前往后都可以设,超出就拒绝手机时钟偏出这个范围,输哪一组都不对
同一个码用两次校验成功后,同一个码的第二次提交必须拒绝刚用过的那组不能接着再用

漂移那一条,文档自己举了个例子:步长 30 秒、校验方只往回接受两个步长时,能容下的时间差大约是 89 秒,也就是当前这一段里的 29 秒,加上往回两段的 60 秒。这是示范算法的例子,你登录的那个平台到底往前往后各收几段,由它自己定。可以确定的只有方向:手机时钟偏得越多,越容易落到范围外面。

为什么看一眼状态栏不够状态栏默认只显示到分钟。手机慢了 20 秒,每一分钟里有 40 秒它和准的钟显示的是同一个分钟数,看上去没有任何差别,而 20 秒已经是一个步长的三分之二。要比就打开带秒针的时钟界面,和另一台设了自动时间的设备并排看。

验证码一直错误时,先分清是这四种里的哪一种

谷歌身份验证器的帮助页在「解决验证码错误的问题」下面列了四项检查:码没过期、是这个应用或服务的码、是这个账号的码、设备时间已同步并且和所在时区一致(见「使用 Google 身份验证器获取验证码」)。下面按四种情况分开查。

1
连着输了几组,组组都被拒

码每次都是刚刷新就输的,也没有看错行,那就先怀疑时间。带秒比一下手机和另一台设备的时钟,两边对不齐就按后面的入口改回自动。改完不用重新绑定,密钥没有变,时间对上以后同一个条目算出来的码就能用。

2
验证器里有两条名字差不多的条目

同一个平台有两个账号,或者同一个账号前后绑过两次,列表里就会有两条长得很像的。验证器只管照着各自的密钥算,它不知道平台那边现在认的是哪一份密钥,所以两条都会照常跳数字。看条目名字下面的账号(邮箱或用户名)是不是你正在登录的那个;两条连账号都一样,就挨个试。确认哪条有效以后,把另一条改个名字标成旧的,先别急着删。

3
有时能过有时不过,换一组就好了

这是踩在两段的交界上:看的时候还是上一组,按下确认时已经进了下一段。平台肯不肯收上一组,取决于它有没有留那一个步长的余地。做法很简单,等数字刚换完再输,手上留足时间。另一种情况是刚用某一组码登录成功,紧接着又拿同一组去做第二步验证,这一次会被拒,等下一组出来再输。

4
换了新手机以后才开始错

条目是从旧手机导出、或者登录同一个云端账号同步过来的,密钥和原来相同,那就先查新手机的时间,按第 1 种处理。换机时在平台的安全设置里重新绑过一次的,平台换了新密钥,旧手机上那一条从此算出来的数字都不作数,只能用重新扫码生成的那一条。分不清手上这条是哪次绑的,就看旧手机还在不在:在的话,两台手机时间都准时,同一时刻显示的数字应该相同,不同就说明两条用的密钥不一样。平台认的是最后一次绑定生成的那一条。

顺带区分一下:短信发来的 6 位数和验证器里的 6 位数是两回事。登录页要的是短信码,你输验证器的码,结果同样是被拒。页面上那一行小字写的是「身份验证器」还是「短信验证码」,输之前看一眼;卡在短信收不到的,看短信验证码为什么会丢。

安卓和 iPhone 在哪里把日期与时间改回自动

iPhone 和 iPad。打开设置 > 通用 > 日期与时间,把「自动设置」打开。时区要跟着走,还得在设置 > 隐私与安全性 > 定位服务里滚到底部,点进「系统服务」,把「设定时区」打开。这两步出自苹果支持页「如果无法在 Apple 设备上更改时间或时区」。同一页还解释了开关发灰点不动的两个原因:设备设了屏幕使用时间密码,或者装了带访问限制的公司描述文件。前一种到屏幕使用时间里处理,后一种要找发这个描述文件的公司管理员。

安卓。谷歌的安卓帮助页「设置时间、日期和时区」给的入口在时钟应用里:打开「时钟」,点「更多」> 设置 > 更改日期和时间,打开「自动确定日期和时间」,再在「时区」下面打开「自动确定时区」。页面带一句提示:只有部分设备支持自动设置时区。各家定制系统的菜单名字不一样,找不到同名开关时,在系统设置顶部的搜索框里搜「日期和时间」,进去以后找「自动」两个字。

开关本来就是开着的,而时间仍然不对,可以关掉再打开一次,让手机重新取一遍时间,然后带秒再比一次。

验证器 App 自带的时间校正。谷歌另有一页帮助「关于 Android 上的 Google 身份验证器的时间同步功能」,讲的是安卓版应用内的入口:更多 > 设置 > 校正用来生成验证码的时间 > 立即同步。它只改应用内部用的时间,系统的日期和时间不动。而前面那篇「使用 Google 身份验证器获取验证码」里有一条重要提示:版本 7.0 已不再支持时间校正设置,应用改用操作系统的时间设置。两页对起来看,在 7.0 以后的版本里翻不到这个菜单是正常的,能改的只剩系统时间这一处。别家的验证器有没有类似开关,到它自己的设置里看一眼,没有的话同样以系统时间为准。

RFC 6238 发布于 2011 年 5 月。菜单名这一头,苹果那一页标注的发布日期是 2026 年 1 月 27 日,安卓和谷歌身份验证器的三篇帮助页是 2026 年 10 月打开时的写法;系统升级后菜单挪了位置,照手机上看到的走。

时间和条目都对了还提示验证码错误,找谁、带什么

找你正在登录的那个平台的客服,走它 App 内或网站内的帮助入口。验证器的开发方帮不上这件事:密钥的另一份存在平台那边,收不收、收几段也是平台定的,只有平台看得到你这次提交为什么被拒。

提交之前把下面几样备齐:

  • 账号的注册邮箱或手机号,以及卡在哪一步(登录、改安全设置,还是别的需要验证的操作)。
  • 被拒的时间,精确到分钟,写上时区。
  • 页面提示的完整文字和错误代码,截图时别把状态栏裁掉。
  • 手机型号、系统版本,验证器 App 的名字和版本号。
  • 系统「日期与时间」页面的截图,能看出自动设置是开着的。
  • 已经做过的检查:时间带秒比过、条目核对过、换过几组码。
这三样不要发给任何人绑定时的二维码、那串备用密钥、验证器当前显示的数字。验证器列表的截图也别发,上面的数字在这 30 秒里是有效的。平台核实身份用不着这些,开口要的人不管自称是谁,都按冒充处理。

工单里每一段写什么、哪些证据有分量,申诉工单怎么写才有用里有完整的写法。在客服回复之前,建议不要自己去点「解绑」或「重置两步验证」:重置会换掉密钥,旧条目全部作废,动静比改时间大得多,等对面看过记录再决定。

出国换了时区,验证器的码会不会跟着错?
时间设成自动的话不会。算法用的是 Unix 时间,从同一个起点数秒,全世界同一刻是同一个数,时区只影响屏幕上显示成几点。会出错的是另一种做法:时区没改,手动把钟拨成当地的钟点,这样底层时间就差出了几个小时,码就对不上了。到了新地方让日期与时间、时区都保持自动,不要手动拨表。
平台为什么不把允许的时间差放宽一些?
放宽等于让每一组码有效得更久。RFC 6238 在讲校验的部分提到,可接受的延迟窗口越大,留给攻击的窗口也越大,所以建议传输延迟最多容许一个时间步长,时钟漂移也要设一个明确的步数上限。平台收得严,和这个思路是一致的,手机这边把时间对准更省事。
电脑浏览器扩展或密码管理器里的动态码,也会受时间影响吗?
会。只要是按 TOTP 算的码,用的都是「密钥加当前时间」,在哪台设备上算,就看哪台设备的时钟。电脑上的码被拒时,检查的是这台电脑的系统时间有没有设成自动同步,和手机的时间无关。