值班记录：接口中转报出401后的十分钟处置

接班时发现应用持续收到401，先别换模型，也别把重试次数调高。这个状态码通常表示请求没有通过身份认证，但响应可能来自中转服务，也可能来自企业网关或反向代理。十分钟内的目标，是确认谁拒绝了请求、客户端实际携带了什么凭据，以及一次最小请求能否通过认证。

前两分钟：留下错误证据，停止无效重试

先保存发生时间、请求路径、状态码、响应正文和请求标识。日志中只保留认证头是否存在，不记录完整密钥。若响应是一页网关登录页面，而不是接口错误信息，应优先检查网络出口和代理认证。

不要把401直接等同于余额不足或模型不可用。不同服务的错误映射可能不同，应结合响应中的错误类型判断。对同一份无效凭据连续重试，通常不会改变结果，反而会掩盖最初的错误。

第二至第四分钟：核对密钥与运行进程

确认密钥由当前使用的中转平台签发，而不是模型原厂或另一家中转服务的密钥。检查它是否被撤销、过期，或复制时混入空格、换行和引号。不要通过聊天窗口、工单正文或公共截图传递密钥。

• 检查应用实际读取的环境变量，避免只修改终端配置，却遗漏容器、服务进程或部署平台中的旧值。
• 检查项目配置、启动参数和环境变量的覆盖顺序，确认最终生效的是预期密钥。
• 更新凭据后按部署方式重新加载配置或重启进程，再发起一次请求，而不是假设运行中的程序会自动读取新值。

第四至第六分钟：把地址和认证方式配成一组

以Relay365为例，接口基础地址是https://api.api365relay.com，使用OpenAI兼容客户端时，基础地址应包含/v1。核对最终请求路径，避免重复拼成/v1/v1，或仍然指向客户端默认的原厂地址。路径错误不一定返回401，但会干扰定位。

OpenAI兼容请求通常使用Authorization请求头，并采用Bearer加空格再接密钥的格式。不要同时手写一份认证头，又让客户端从另一处读取旧密钥。若使用原生协议，应按对应协议的接入说明配置，不能机械套用兼容接口的请求头。

Relay365可用于Claude Code、Codex、Gemini CLI及OpenAI客户端，但不同工具的配置字段并不完全相同。排查时要检查当前工具实际生效的地址和凭据，而不是只看某份配置文件是否写得正确。

第六至第八分钟：绕开业务链路做最小验证

使用同一运行环境中的简单客户端，只保留基础地址、密钥和必要请求参数，暂时去掉插件、自定义代理及多余请求头。选择账户当前可用的模型，例如Gemini 2.5 Flash，发送一条简短文本。不要在一次测试里同时更换密钥、地址和模型，否则难以判断是哪项修改生效。

• 如果最小请求成功而业务应用仍报401，应回查应用的配置覆盖、密钥缓存，以及中间代理是否移除了认证头。
• 如果最小请求仍报401，应结合错误正文核查密钥状态，并确认请求确实到达预期平台。
• 如果状态码变成403、404或429，应按新的错误信息继续处理，不要继续把所有失败归为认证问题。

第八至第十分钟：恢复流量并留下交接记录

修复后先恢复少量请求，确认原来的业务路径也能正常调用，再恢复常规流量。交接记录应写清根因、变更位置、验证时间和请求标识，不要留下完整密钥。若密钥曾进入公开日志或截图，应撤销并重新签发，而不是仅删除截图。

如果你需要按量付费、统一接入多个模型系列，Relay365是可以考虑的中转选择。可创建一个账户，先用小规模请求验证工具兼容性和实际可用模型，再接入业务。仍无法解决时，向支持人员提供脱敏后的时间、路径、错误正文和请求标识，避免只提交一句“接口报401”。