DeepSeek 在 Cursor 中怎么配置：API 地址、代理和排障
在 Cursor 中配置 DeepSeek 自定义 API Key 和 Base URL 后，分别验证本机网络、Cursor 请求及服务端响应；实际路径和模型名称需按当前版本核对。
在 Cursor 使用 DeepSeek 自定义 API Key 时，需要配置服务地址和凭据，并分别检查本机网络、Cursor 的请求路径及模型服务端响应。Cursor BYOK 请求不一定与本机 curl 走同一条端到端链路，因此终端测试不能单独证明 Cursor 请求成功。具体界面和路径应按当前 Cursor 与 DeepSeek 文档核实。
用状态码和终端请求区分模型配置与代理故障
模型接入错了，表现是 401、404 或"model not found"；网络出口错了，表现是超时、连接被重置、流式输出卡住。前者看 key 和地址，后者看代理和兼容模式，混着查只会来回改配置。顺带说清一个常见混淆：业务场景里代理和 VPN 的差别决定了你要的是固定出口还是临时改道。
本机 curl 可用于检查本机到 API 端点的连通性及该请求的凭据响应；Cursor 内失败时，还要核对 Cursor 的请求记录和服务端日志，不能据此排除 Cursor 到模型服务之间的问题。
在 Cursor 中填写 DeepSeek API Key 和 Base URL
打开 Cursor Settings > Models，在 OpenAI API Key 一栏填入 DeepSeek 的 key（不是 Cursor 自己的 key），再打开 Override OpenAI Base URL 填 https://api.deepseek.com/v1。
基础地址可使用 https://api.deepseek.com；是否在 Base URL 中包含 /v1，取决于当前 Cursor 版本如何拼接最终请求路径。配置前核对最终 URL，避免路径重复或缺失导致 404。模型名称也应以 DeepSeek 当前模型目录及 Cursor 实际请求为准，不要仅凭旧别名判断接入成功。
让 Cursor 通过系统代理发送模型请求
Cursor 没有单独的"代理地址"输入框，它跟随系统代理或环境变量（HTTPS_PROXY）。在需要经过代理的网络里，还要处理流式传输：
- Cursor 默认用 HTTP/2 双向流拿响应，部分代理会缓冲这种流，表现为回复长时间空白然后一次性出现
- 遇到这种情况，去 Cursor Settings > Network，把 HTTP Compatibility Mode 切到 HTTP/1.1，重启 Cursor
- 官方会在 HTTP/2 不通时自动回退到 HTTP/1.1 的 SSE，但回退不是瞬时的，手动切换更快
以上行为以 Cursor 网络配置文档 为准；界面文案和默认值会随版本变化，以当前设置页为准。
代理本身的接入方式（主机、端口、账号密码）见帮助中心的代理设置 页面，各客户端写法不同，但出口是同一个。
从 API 连通性到 Cursor 对话逐步验证
依次检查 API 凭据、代理出口和 Cursor 对话
按顺序做，每一步都能独立判断：
1. 在终端请求当前 DeepSeek 文档列出的端点，记录最终 URL、状态码和响应体；这只验证该终端请求。
2. 如需测试代理，可对同一条终端请求添加代理参数，并记录连接阶段、状态码和响应；这不能代表 Cursor 使用了相同链路。
3. 在 Cursor 内发起一次请求，记录 Cursor 版本、设置项、时间及界面错误；不要把逐字输出或 UI 模型标签当作服务提供方证明。
4. 如能查看自定义服务端日志，使用脱敏 request ID、时间戳、实际 model 字段和用量核对是否收到 Cursor 请求。
对照返回结果确认每一步是否通过
每一步的通过标准可以对照下表，避免"看起来能连"就往下走：
| 步骤 | 要确认的东西 | 通过标准 |
|---|---|---|
| 终端验 key | key 是否有效、端点路径是否正确 | 返回 JSON 模型列表，无 401/404 |
| 终端验代理 | 代理能否到 api.deepseek.com | 与直连结果一致，延迟稳定 |
| Cursor 请求 | Cursor 是否成功提交并收到响应 | 记录实际错误、时间和请求 ID（如可用） |
| 服务端核对 | 自定义服务是否收到请求 | 对照脱敏 request ID、实际 model 字段及用量 |
| 网络路径 | 哪一段连接失败 | 分开记录本机网络、Cursor 到服务端和服务端上游日志 |
主机、端口和出口 IP 不是一回事，三者的对应关系见代理主机、端口和出口 IP 有什么区别。
如怀疑网络变化与连接重置有关，记录对应请求时间、连接阶段及代理日志，再检查 Cursor 与服务端各自的链路；仅看到出口 IP 变化不能证明故障由此造成。代理认证方式见代理白名单和账号密码怎么选。
根据 401、404、超时和流式输出异常排查
| 现象 | 最可能原因 | 检查动作 |
|---|---|---|
| 401 Unauthorized | 凭据无效、权限或请求配置问题 | 检查服务端错误体、凭据来源和权限；勿在日志暴露密钥 |
| 404 Not Found | 最终路径、模型或端点不匹配 | 记录实际请求 URL，并按客户端文档核对路径拼接 |
| 402 或额度报错 | 余额、额度或模型计费条件 | 查看账户状态和响应体的具体错误字段 |
| 请求超时 | 可能发生在本机、Cursor 或上游链路 | 对照请求阶段、Cursor 诊断信息、服务端日志和代理日志 |
| 回复延迟或中断 | 流式协议、网络、中间层或服务端处理 | 比较兼容模式并查看对应阶段日志，不预设唯一原因 |
| 偶发连接重置 | 连接路径或服务端/中间层异常 | 记录时间、request ID、连接阶段和相关日志 |
超时、连接被拒和证书错误要分开判断：前者看链路，后两者看端口和中间设备。只想确认链路通不通，可以打开帮助中心的智能检测助手。
FAQ
Base URL 到底要不要带 /v1
不一定。按当前 Cursor 版本确认它会如何拼接路径，并以最终请求 URL 为准；若客户端已自动添加 /v1，Base URL 再包含它可能造成重复路径。
代理开着，Cursor 还是报错怎么办
终端 curl 只能验证该终端请求。记录 Cursor 的错误和版本，并核对代理日志、Cursor 诊断信息及自定义服务端是否收到请求；各段结果对照后再定位故障。
自定义 key 和 Cursor 订阅额度是什么关系
两套计费：用自定义 key 时走 DeepSeek 账户余额，Cursor 的请求额度不参与；反过来，Cursor 自带模型的额度也抵扣不了 DeepSeek 的费用。
若日志确认出口切换造成连接中断，可按实际会话要求评估静态住宅代理 IP；这不能解决 Cursor 服务端、API 地址或鉴权问题。