通义灵码报错401解决方案

401 到底在说什么

401 是 HTTP 标准状态码，含义是 Unauthorized（未通过身份认证）。它表达的是「服务端收到了你的请求，但不认可你的身份凭据」，而不是」服务挂了「或」网络不通」。这个区分很重要，因为它直接决定排查方向：

所以看到 401，九成情况在「凭据链路」上，而不在插件本体。

根因一：登录态已失效（最高频）

登录凭据有有效期，长期不重登、换过密码、在其他设备登出过，都会导致本地缓存的凭据失效。表现是：插件面板看起来仍是登录状态，但每次请求都 401。

处理：

1. 在插件面板中执行退出登录。
2. 完整重启 IDE（不要只关闭窗口）。
3. 重新登录并完成浏览器授权。
4. 随便触发一次补全验证。

注意顺序：一定是「先登出、再重启、后登录」。直接点重新登录往往仍复用了旧的失效缓存。

根因二：代理或安全网关改写了请求

企业环境里的 HTTPS 解密代理、零信任客户端、抓包工具都会重写请求头或替换证书链。凭据头被剥离或篡改后，服务端自然返回 401。

处理：

1. 临时关闭代理与抓包工具，直连网络复测。若直连正常，问题定位在代理。
2. 确认 IDE 与插件读取的代理配置是否与系统代理一致（IDE 常有独立代理设置，容易两边不一致）。
3. 需要保留代理时，请网络管理员为官方接口域名配置放行与不解密（bypass），例如 lingma-api.tongyi.aliyun.com 与 devops.aliyun.com。

根因三：本机系统时间偏差

凭据校验对时间敏感。系统时间与真实时间偏差过大（常见于虚拟机、长期休眠的笔记本、双系统切换后）会导致凭据被判定为无效。

处理：开启系统自动同步时间，或手动校准到正确时区与时间后重新登录。这一条经常被忽略，但在虚拟机场景里命中率不低。

根因四：多账号 / 多环境串了

同一台机器上同时装了插件与独立 IDE、或者在多个 IDE 里用了不同阿里云账号，容易出现凭据互相覆盖。表现是某个 IDE 正常、另一个持续 401。

处理：统一确认各 IDE 中登录的是同一个账号；把不用的那份登出，避免凭据竞争。

根因五：网络可达但被中途拦截

DNS 污染、host 文件残留、公司防火墙策略都可能让请求打到错误的地址，返回的 401 其实来自拦截设备而不是官方服务。

处理：

1. 用 ping lingma-api.tongyi.aliyun.com 与 ping devops.aliyun.com 确认解析结果是否正常。
2. 检查本机 hosts 文件是否有相关域名的残留指向。
3. 换网络环境（例如手机热点）复测，用来快速区分是本机问题还是网络环境问题。

标准排查顺序（照着走，不要跳）

1. 看日志确认状态码确实是 401，而不是把超时误认为 401。VS Code 看输出面板，JetBrains 用 Help → Show Log。
2. 登出 → 重启 IDE → 重新登录 → 复测。
3. 关代理与抓包工具直连复测。
4. 校准系统时间后复测。
5. 换网络环境（手机热点）复测。
6. 确认多 IDE / 多账号没有串号。
7. 以上都排除后，再考虑卸载重装插件——重装是最后一步，不是第一步。

怎么记录问题以便求助

如果需要提交工单或求助，带上这些信息能大幅缩短来回：使用的是插件还是独立 IDE、宿主 IDE 名称、复现步骤、日志中包含状态码的原始报错行、是否在代理环境、直连与换网络的复测结果、系统时间是否已校准。不要只说「报 401"。

典型使用场景

• 公司内网首次使用：大概率是代理与域名放行问题，直接从根因二入手。
• 长期没用突然报错：优先按根因一处理登录态失效。
• 虚拟机 / 远程开发机：先查系统时间与 DNS，再查凭据。
• 多 IDE 混用：先统一账号，避免凭据互相覆盖。

本页信息来源

• 通义灵码官方站点与文档：https://lingma.aliyun.com/
• HTTP 状态码语义标准（401 Unauthorized / 403 Forbidden / 429 Too Many Requests）

本页只给排查方法与状态码语义，不提供版本号、许可证、发布日期与配置要求等易过期数据。若官方文档给出了针对特定报错的最新处理指引，以官方文档为准。