DeepSeek API 返回 401 怎么办？先用 1 条 curl 定位问题
简答：DeepSeek API 返回 401，先把问题缩小到三类：Key 或 Authorization 错误、程序没有加载正确的 Key、Base URL 与凭证不属于同一平台。先使用官方 Base URL 和一个最小 curl 请求；如果 curl 也返回 401，优先检查 Key，如果 curl 成功而 SDK 失败，优先检查环境变量与 SDK 配置；如果只有兼容网关失败，则检查网关自己的认证规则。
定义：DeepSeek API 的 HTTP 401 表示认证失败；DeepSeek 官方错误码文档将原因说明为 API Key 错误，并建议检查或创建 API Key。
30 秒速查：先判断 401 出在哪一层
截至 2026-10-30，DeepSeek 官方文档将 401 定义为认证失败，常见原因是 API Key 错误；余额不足对应 402，达到速率、并发或 QPS 限制对应 429。认证方式是 HTTP Bearer Auth，官方 OpenAI 兼容 Base URL 为 https://api.deepseek.com。可先查看 DeepSeek API 认证说明、官方首次调用文档 和 官方错误码说明。
| 现象 | 下一步 | 优先检查 |
|---|---|---|
| 官方 curl 也返回 401 | 先不要重试，检查凭证 | Key 是否完整、Bearer 格式是否正确、是否使用了官方接口对应的 Key |
| 官方 curl 成功，Python 或 Node.js 返回 401 | 比较两边的实际配置 | 环境变量、SDK 的 api_key、base_url 和请求路径 |
| 官方接口成功，第三方兼容网关返回 401 | 按网关规则单独排查 | 网关 Key、网关 Base URL、模型名和认证头是否匹配 |
成功判定：最小请求不再返回 HTTP 401，并返回 JSON 响应。若出现其他状态码，通常说明请求已经进入后续校验阶段，但兼容网关可能自行改写状态码，仍应结合响应体和实际服务端判断。
本站是第三方 AI API 接入指南站，不是 DeepSeek 官方站点；本文只使用公开官方文档确认的接口、认证方式和模型信息。
先用官方 curl 验证 Key、Bearer 和 Base URL
DeepSeek 官方 API 使用 Bearer 认证，请求头的形式是 Authorization: Bearer <API_KEY>。官方首次调用文档当前列出 deepseek-flash 和 deepseek-v4-pro，并将 deepseek-flash 用作示例模型；如果你从其他平台调用，模型名仍应以目标平台的模型列表为准。
先把下面的 YOUR_DEEPSEEK_API_KEY 替换为真实 Key，不要把尖括号或占位文字原样发送：
curl -i https://api.deepseek.com/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer YOUR_DEEPSEEK_API_KEY" -d '{"model":"deepseek-flash","messages":[{"role":"user","content":"Hello"}],"stream":false}'
接口路径和请求字段可对照 DeepSeek Chat Completions API 文档。如果你担心把 Key 直接写进命令历史，可以改用操作系统的密钥管理工具或 CI/CD 的 secret 注入机制；不要把完整 Key 放在公开脚本、截图、日志、命令历史或公开仓库中。
如果必须使用环境变量，可在当前终端临时设置，并在测试完成后清理：
export DEEPSEEK_API_KEY='替换为你的真实 Key'
curl -i https://api.deepseek.com/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" -d '{"model":"deepseek-flash","messages":[{"role":"user","content":"Hello"}],"stream":false}'
unset DEEPSEEK_API_KEY
不要用 echo $DEEPSEEK_API_KEY 打印完整密钥。安全的存在性检查可以只输出长度和脱敏前缀，例如：
python -c 'import os; k=os.getenv("DEEPSEEK_API_KEY", ""); print({"set": bool(k), "length": len(k), "prefix": k[:6] + "..." if k else ""})'
按顺序排查 Key、环境变量和 SDK
- 确认凭证属于同一个平台。DeepSeek 官方 API 的 Key 应与
https://api.deepseek.com配套使用。第三方 API Router 或兼容网关的 Key 不应直接拿去请求官方地址，反过来也一样。 - 检查请求头格式。确认请求头名称是
Authorization，值是Bearer加一个空格，再接 Key。不要把 Key 放在 URL 查询参数中，也不要把引号、尖括号或变量名一起发送。 - 检查复制内容。重新复制 Key，排除前后空格、换行和不可见字符。不要通过打印完整 Key 来确认内容，只检查是否存在、长度和少量前缀。
- 确认程序读取了正确变量。终端、IDE、容器、服务进程和 CI 任务可能使用不同环境。程序若读取的是
OPENAI_API_KEY，而你只设置了DEEPSEEK_API_KEY，就可能得到空值或旧 Key。 - 比较实际请求目标。记录请求发往哪个主机和路径，但不要记录完整 Authorization 值。官方地址、第三方网关地址和自建代理地址应分别核对，不能只替换 Key 或只替换 Base URL。
Python 最小验证示例：
import os
from openai import OpenAI
key = os.getenv("DEEPSEEK_API_KEY")
if not key:
raise RuntimeError("DEEPSEEK_API_KEY 未设置")
client = OpenAI(
api_key=key,
base_url="https://api.deepseek.com",
)
response = client.chat.completions.create(
model="deepseek-flash",
messages=[{"role": "user", "content": "Hello"}],
stream=False,
)
print(response.choices[0].message.content)
如果 curl 成功但 Python 返回 401，重点比较 Python 进程实际读取的 Key、base_url 和模型配置。如果两者都返回 401，再回到 Key 是否创建正确、是否被撤销以及目标平台是否一致等问题。
只有代理或兼容网关返回 401时怎么查
如果同一个 Key 请求官方接口成功，但经过代理、API Router 或兼容网关后返回 401，不能直接把原因归于 DeepSeek 官方接口。此时应使用网关提供的 Base URL、Key、模型名和认证规则，并检查网关是否要求自定义请求头。
- 在代理入口仅记录“Authorization 请求头是否存在”，不要记录完整值。
- 在代理出口用同样方式记录请求头是否仍存在，比较入口与出口的存在性。
- 如果入口存在、出口不存在，检查代理转发规则是否删除或覆盖了
Authorization。 - 如果入口和出口都存在但仍返回 401，比较网关要求的 Key 来源、认证头名称、Base URL 和模型名。
- 保留 HTTP 状态码、目标主机、路径和服务端返回的非敏感错误信息，方便与网关文档或支持渠道核对。
不要为了排查而把完整 Key 写进反向代理日志。若只有浏览器前端请求失败，应停止在前端代码中保存长期 API Key，改由后端或受控的服务端密钥管理方案发起请求。
如果你是在兼容客户端中配置接口，完成认证验证后，还需要核对客户端的 Base URL、模型名和环境变量字段。可继续参考本站的Continue OpenAI 兼容接口配置教程或Cline OpenAI 兼容接口配置与排错。
401、402、403、404、422、429 怎么区分
下表仅适用于 DeepSeek 官方错误码文档所描述的接口语境；第三方兼容网关可能返回不同状态码、包装不同错误信息或增加自己的规则。
| 状态码 | 官方文档中的含义 | 处理方向 |
|---|---|---|
| 401 | 认证失败，API Key 错误 | 检查 Key、Bearer、环境变量和目标平台 |
| 402 | 余额不足 | 检查账户余额，不要把余额问题当成 Key 失效 |
| 403 | 请求被安全策略拒绝 | 查看响应体和对应接口的安全限制 |
| 404 | 请求的资源或路径不存在 | 检查 Base URL、接口路径和资源名称 |
| 422 | 请求参数无效 | 检查请求体字段、参数值和模型支持范围 |
| 429 | 达到速率、并发或 QPS 限制 | 降低请求频率，并按服务端提示处理临时限流 |
| 500 | 服务端错误 | 短暂等待后按官方建议重试，持续出现时联系支持 |
| 503 | 服务端过载 | 等待后再试，不要把它当成认证失败 |
DeepSeek 官方错误码页面明确区分了 401、402、422、429、500 和 503；处理确定性 4xx 时，不应盲目重复发送同一请求，而应先改变凭证、地址或请求参数。
401 持续出现：撤销旧 Key 并重新验证
如果你确认 Authorization 格式、环境变量和 Base URL 都没有问题，但官方最小请求仍返回 401，可以按当前控制台提供的流程检查 Key 是否仍有效。无法从公开文档确认具体控制台按钮名称时，不要依赖固定界面路径。
- 停止继续使用疑似错误或泄露的旧 Key。
- 在对应平台控制台撤销、删除或停用旧 Key，具体操作名称以当前页面为准。
- 创建新 Key，并只写入本地密钥管理工具、服务器 secret 或 CI secret。
- 更新本地环境变量、容器配置、部署平台变量和后端服务配置。
- 重新执行最小 curl 请求，再执行 Python 或客户端测试。
- 检查旧 Key 是否出现在仓库、日志、截图、构建输出或命令历史中，并按平台能力清理或轮换相关凭证。
如果新 Key 仍返回 401，保留时间、状态码、目标主机、请求路径和脱敏后的错误信息，向对应平台支持渠道核对；不要提交完整 Key 或包含完整 Authorization 值的日志。
常见问题
DeepSeek API 返回 401，是不是余额不足？
通常不是。DeepSeek 官方错误码文档将 401 定义为认证失败，将余额不足列为 402。先检查 API Key、Authorization 请求头、环境变量和目标平台。
Authorization 请求头应该怎么写？
使用 Authorization: Bearer <API_KEY>，Bearer 与 Key 之间需要空格。不要把尖括号、引号或变量名作为实际内容发送，也不要把 Key 放在 URL 查询参数中。
curl 成功但 Python 仍然返回 401，怎么办？
比较 curl 和 Python 实际使用的 Key、Base URL、请求路径及模型配置，重点确认 Python 进程是否加载了正确环境变量，并显式设置 api_key 和 base_url。
第三方兼容网关返回 401，可以直接换成 DeepSeek 官方 Key 吗？
不能直接假定可以。应按照该网关的文档使用同一平台的 Base URL、Key、模型名和认证规则，避免跨平台混用凭证。
如何确认环境变量存在而不泄露 Key？
只输出是否存在、长度和少量脱敏前缀，不要打印完整值。测试完成后清理临时环境变量，并避免把命令和输出写入公开日志。
Key 可能泄露了，应该怎么处理？
立即停止使用疑似泄露的 Key，按对应平台流程撤销或删除旧 Key，创建新 Key，更新部署环境变量，并清理公开仓库、日志和截图中的敏感内容。
相关阅读
参考资料
- DeepSeek API Docs：Error Codes（api-docs.deepseek.com）
- DeepSeek API Docs：DeepSeek API 认证说明（api-docs.deepseek.com）
- DeepSeek API Docs：Your First API Call（api-docs.deepseek.com）
- DeepSeek API Docs：Chat Completions API（api-docs.deepseek.com）
- DeepSeek API Docs：Lists Models（api-docs.deepseek.com）