DeepSeek API 返回 404 时，先不要重置密钥或反复充值。404 的排查重点是“请求发到了哪里”：核对最终主机、SDK 的 base_url、实际接口路径和模型名。最有效的方法是退回官方最小请求，成功后再逐项加回代理、框架和业务参数。
先保存不含密钥的诊断信息
- HTTP 状态码和错误正文。
- 请求方法，例如 POST。
- 最终主机和路径，但不要记录查询中的敏感数据。
- 使用的模型名、SDK 名称与版本。
- 是否经过公司代理、API 网关或第三方中转。
如果错误正文是公司网关、Nginx 或第三方网站的 HTML 页面，说明 404 可能在到达 DeepSeek 官方接口前就产生了，应先查代理路由。
按顺序核对四个位置
- 主机：官方 OpenAI 兼容示例使用
https://api.deepseek.com作为base_url。 - 路径：让 SDK 按接口方法拼接路径，不要同时在网关和客户端重复追加同一段。
- 模型：用官方当前列出的模型名。核验时快速开始示例使用
deepseek-flash；旧模型名可能被替换或退役。 - 代理：确认代理没有改写主机、删掉路径前缀或把请求转到网页地址。
用最小脚本复现
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEEPSEEK_API_KEY"],
base_url="https://api.deepseek.com",
)
try:
result = client.chat.completions.create(
model="deepseek-flash",
messages=[{"role": "user", "content": "只回复 OK"}],
stream=False,
)
print(result.choices[0].message.content)
except Exception as exc:
print(type(exc).__name__)
print(str(exc)) # 分享前删除密钥、请求头和敏感内容在不使用第三方代理的受控环境运行一次。本文没有密钥，也没有真实发送此请求；脚本用于缩小问题范围，不是实测成功证明。
怎样判断修复成功
- 同一最小请求不再返回 404，并得到非空回答。
- 错误正文来自预期 API，而不是网页或代理的 404 页面。
- 用量记录中能找到这次请求，且模型名与代码一致。
- 重新启用业务框架后仍成功；若再次失败，差异就在新增的配置中。
验证时一次只恢复一项：先代理，再框架，再业务参数。多项一起改会掩盖真正原因。
仍然 404 时的分界线
| 测试结果 | 下一步 |
|---|---|
| 官方最小请求成功，业务程序失败 | 比较两边最终 URL、模型名和代理配置 |
| 直连失败，换网络后成功 | 检查原网络的 DNS、代理、证书和出口策略 |
| 官方模型名更新后成功 | 把模型改成可配置项，并增加启动时检查 |
| 所有环境都失败 | 保存时间、请求 ID 和脱敏错误，向官方支持查询 |
不要这样处理
- 不要把 API Key 发给所谓“代排查”人员。
- 不要在不知道结果的情况下无限重试。
- 不要用第三方中转成功来证明官方端点正常，两条链路并不相同。
- 不要把 404 自动归因于余额、地区或封号；没有错误正文和请求路径时无法下结论。
截至 2026 年 10 月 1 日，端点和模型仍可能变化，本文未在读者网络与账号中实测。
官方来源
官方 base_url、模型名与 Python 请求结构参考 DeepSeek API 官方快速开始，资料核验日期为 2026 年 10 月 1 日。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/32837.html
