1. 线上接口突然 401：JWT 验签失败的真实现场
上周排查一个老项目，前端登录正常，Token 也拿到了，可请求一到服务端就被拦下，日志里只有一行Signature verification failed。按经验先看exp，发现过期时间设的是 2 小时，浏览器端也确认没过期；再看Signature，代码逻辑和签发时一模一样，可服务端就是验不过。这种问题最折磨人——不是不会写 JWT，而是写对了却不知道在哪一步被悄悄改掉。
后来把验签代码、密钥生成方式、当前时间戳一起丢给 Codex，让它按Header、Payload、Signature三段的编码结果逐项比，很快定位到问题：签发时用的 secret 是旧配置，服务端加载的是新配置，一长串 HMACSHA256 算出来完全对不上。这里有个可以复用的排查方法，也顺带解决 Codex 本身连不上模型服务的问题：去 TaoToken 拿一把 Key，把 Codex 的 Base URL 指到 TaoToken 的兼容通道，同一个会话里既能查 JWT 源码问题，又能让 Codex 正常发起模型请求完成后续调试。
2. 先把 JWT 的 Signature 和 exp 拆开看
JWT 由三段用点号拼接的文本组成，每一段都有明确职责。Header声明令牌类型和签名算法，常见写法是{"alg":"HS256","typ":"JWT"}；Payload放用户身份和标准声明，比如sub、iat、exp；Signature则是对前两段做签名，防止内容被篡改。很多人验签失败，问题往往不在算法本身，而是对 Signature 的生成过程理解不够精确。
以 HS256 为例，签名公式是这样：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )这里有几个容易忽略的细节。第一，Base64Url 编码和标准 Base64 不一样，+要换成-，/要换成_，末尾的=要删掉；第二，签名输入是header.payload这个带点号的字符串，不是分别对两段签名再拼接；第三，secret 参与的是原始字符串，不是 Base64 之后的版本。任何一处不一致，服务端验签必挂。
exp的问题同样隐蔽。很多团队直接用System.currentTimeMillis()得到毫秒值塞进 Payload，而 JWT 标准要求的是秒；还有人用本地时间带时区偏移，服务端用 UTC 比，于是明明刚签发的 Token 也报过期。这两类错误在日志里都表现为 401，但成因完全不同，排查路径也不一样。
3. 用 Codex 排查 401 前，先让 Codex 能跑起来
排查这类问题最自然的方式，是把 Token、密钥、验签代码一起交给 Codex，让它按步骤对着算。但前提是 Codex 得先能正常发起模型请求，这就绕不开 API 通道。打开 TaoToken 注册并创建 API Key，然后把 Codex 指到兼容通道，过程只需要改一个配置文件。
这里要分清两个地址：官网落地页只用来注册、创建 Key、看模型广场和用量；填进 Codex 的 Base URL是接口地址，末尾不要加/v1。很多工具默认在 Base URL 后面补/v1，如果你填了带/v1的路径，反而会拼成/v1/v1导致 404。
打开~/.codex/config.toml，按下面的方式配置：
model = "你的模型ID" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" api_key_env_var = "TAOTOKEN_API_KEY"配置解释：
| 配置项 | 值 | 说明 |
|---|---|---|
base_url | https://taotoken.net/api | 兼容通道接口，末尾不加/v1 |
api_key_env_var | TAOTOKEN_API_KEY | 从环境变量读取 Key，避免写死在配置里 |
model | 以模型广场当时列表为准 | 不要凭记忆填版本号 |
随后把 Key 放进环境变量，不同终端写法略有差异：
# bash / zsh export TAOTOKEN_API_KEY="YOUR_API_KEY" # Windows PowerShell $env:TAOTOKEN_API_KEY="YOUR_API_KEY"这里的YOUR_API_KEY是占位符，需要到 TaoToken 控制台创建。环境变量设置好以后，重启 Codex 再试一次对话，如果仍然报 401，请回看这段配置，检查base_url是否被追加了/v1，以及环境变量名是否和配置文件里的api_key_env_var完全一致。
4. 让 Codex 按 signature、exp、jti 逐项查
通道就绪后，把问题描述得越具体，Codex 给出的结论越接近真相。我习惯按下面这个模板把信息一次性交给它：
我在做一个 JWT 登录接口，现在请求返回 401，错误信息是 Signature verification failed。 请帮我按以下顺序排查： 1. 检查 Signature：已知 Header 是 xxx，Payload 是 xxx，secret 是 xxx， 请用 HMACSHA256 重新计算签名，并与 Token 第三段逐字符比对； 2. 检查 exp：当前 Unix 时间戳是 xxx，Token 里 exp 的值是 xxx， 请确认单位是秒还是毫秒，以及是否存在时区问题； 3. 检查 jti：这个字段是否被服务端用于防重放，是否误把已使用的 jti 当作重复请求。 以下是完整代码和完整 Token： [粘贴代码] [粘贴Token]Codex 拿到之后，会真的把 Header 和 Payload 解出来重新编码，再算一遍 Signature 给你看。上次排查时，它发现我的 Header 里写的算法是HS256，但服务端代码实际操作的是HS512，密钥长度也不合规范，这两处叠加导致每次签名都不同。这个结论光靠肉眼盯代码很难发现，因为两边变量名都是secret，很容易默认它们值相同。
jti是 Payload 里的唯一标识，标准里用于防止重放攻击。有些实现会把jti存到 Redis 并设置过期时间，但如果你在本地测试时把 Redis 里的记录清掉了，同一个 Token 再次携带jti过来会被判定为已使用，同样返回 401。Codex 能帮你从代码里找出这一层逻辑，避免你在 Signature 上反复折腾。
还有一个常见的坑是密钥格式。有人把 secret 直接写在代码里，有人放在环境变量里，有人从配置中心拉取。只要有一处带引号、一处没有引号，算出来的签名就是两套结果。检查时可以要求 Codex 在代码里搜索secret的全部赋值点，列出所有不同值，这一步通常能直接命中问题。
5. 验证 Token 是否有效的三种快捷方式
改完代码后，建议先不急着发起完整请求，用最小化手段确认 JWT 本身是否合法。下面三个方法可以独立使用，也可以互相印证。
5.1 用 Codex 生成一段验签脚本
把下面这个 Node.js 脚本交给 Codex 补全运行逻辑，它可以独立于业务代码完成验签：
const crypto = require('crypto'); function base64url(input) { return Buffer.from(input) .toString('base64') .replace(/=/g, '') .replace(/\+/g, '-') .replace(/\//g, '_'); } function verifySignature(token, secret) { const [header, payload, signature] = token.split('.'); const data = `${header}.${payload}`; const expected = crypto .createHmac('sha256', secret) .update(data) .digest('base64') .replace(/=/g, '') .replace(/\+/g, '-') .replace(/\//g, '_'); return expected === signature; } // 请 Codex 根据你的算法（HS256/HS512）调整 createHmac 参数 // 并补上 exp 过期判断这段脚本的重点在于，它完全复刻了 JWT 签名的标准化流程。如果脚本里验签通过，但服务端验签失败，问题一定出在服务端加载的 secret 或者算法选择上；如果脚本里就验不过，直接对比 Header 和 Payload 的 Base64Url 编码结果，看看是不是哪一位字符被替换错了。
5.2 在 TaoToken 模型对话里做交叉验证
如果你的时间戳换算总是不放心，可以在 TaoToken 模型对话 里直接问当前 Unix 时间戳是多少，同时把你计算出的exp值贴进去，让模型帮你做一次单位换算。这样能得到一个独立于你本地环境的回答，尤其适合排查时区问题。
5.3 回控制台确认这次调用已计账
Codex 发起请求会消耗 Token 额度。验证完 JWT 之后，打开 TaoToken 控制台 API Keys 看一眼 Key 的调用记录，如果看到了刚才那次请求，说明 Base URL 和 Key 都配置正确，问题确实在 JWT 验签逻辑本身。
6. 把签证失败的根因转成可落地的修复清单
排查结束后，不要让结论停留在“签名不对”这个层面，要把根因拆成可执行的修正项。以最常见的几类问题为例：
| 根因 | 现象 | 修复动作 |
|---|---|---|
| 签发与验签 secret 不一致 | 每次验签都失败，但日志无异常 | 统一从同一环境变量读取密钥 |
| exp 用了毫秒值 | Token 刚发出来就报过期 | 改为Math.floor(Date.now() / 1000) |
| Base64Url 编码不规范 | 偶尔成功偶尔失败 | 统一用工具函数处理，不手动拼接 |
| 算法声明与实际不一致 | Header 写 HS256 实际用 HS512 | 两边统一使用同一常量 |
修复时建议一次只改一项，改完立刻用上面的 Node 脚本重验。Codex 可以在你修改后继续扮演代码审查者，帮你检查是否引入了新问题，比如把exp修正成秒之后，iat是否也相应调整了单位。
密钥管理这一块，强烈建议写入项目的环境变量模板文件，并备注格式要求：
JWT_SECRET=请填写与签发时完全一致的密钥 JWT_EXPIRE_SECONDS=3600服务端读取时统一走配置中心，业务代码里不要出现任何硬编码密钥。只要这种规范建立起来，后面再有人碰到验签失败，可以先自查密钥来源，不用每次从头查一遍。
7. 顺路把后续接口调试也跑通
Token 验签通过只代表身份认证这一关过了，后面的业务接口可能还会继续抛参数错误、权限不足等问题。此时 Codex 已经连着 TaoToken 的通道，你可以继续把接口返回的 JSON、报文头、甚至数据库查询语句丢给它做对照分析，不用再切换任何配置。
如果你接下来要高频使用 Codex 写代码、查接口，可以考虑先看一下 Coding Plan 的套餐是否更划算；如果只是偶尔调试，直接按量走就够。创建新 Key 可以随时到 TaoToken 控制台 操作，旧 Key 需要吊销时也在同一个页面处理。
整个过程走下来，最值钱的不是某一行修复代码，而是建立了一套排查路径：先确认通道可用，再把问题拆成 Signature、exp、jti 三个独立检查点，最后用脚本验证。下次再遇到 401，你不需要从零开始。
