企业代理已可连接，但 DeepSeek Harness 报 TLS 证书错误时，先确认实际请求路径和企业 CA 证书包，再在启动 DSH 前让 Node 读取该证书包。
DeepSeek Harness：证书错误能说明什么？
网络代理指南专门提到，拦截 TLS 的企业代理需要组织提供的证书。如果代理可达后请求仍报证书错误，文档给出的设置是 NODE_EXTRA_CA_CERTS，让它在启动前指向组织的 CA 证书包。Node 只在进程启动时读取该变量。
证书错误提示需要调查 TLS 连接，但错误消息本身不能确定缺少哪张证书、预期代理是否处理了请求，或目标地址是否正确。向组织获取批准使用的 CA 证书包，并核实目标与路径。浏览器请求成功也不能证明 DSH 进程使用相同的代理和信任设置。
| 观察 | 有价值的判断 | 仍需检查 |
|---|---|---|
| 浏览器成功而 DSH 失败 | 两者的网络设置可能不同 | DSH 启动环境和实际路由 |
| 代理看到请求 | 该次请求到达代理 | TLS 信任和目标地址 |
| 到达代理后出现证书错误 | 调查信任链 | 正确的企业证书包与进程重启 |
| 服务返回应用错误 | 请求到达了响应服务 | 提供方、模型与认证设置 |
DeepSeek Harness：先检查哪条请求路径？
代理指南说明，DSH 启动时读取标准代理变量，用于模型调用、网页搜索、页面抓取及 HTTP MCP 服务。已导出的变量优先于 $DSH_HOME/.env。项目 .env 不能设置代理变量：DSH 会拒绝启动，避免克隆的项目决定流量去向。浏览器可能使用操作系统代理设置，而 DSH 不读取该设置。
NO_PROXY 可让匹配主机及其子域名直连，DSH 总是绕过代理访问环回地址。因此企业模型主机与公共网页可能走不同路径。判断企业代理证书是否相关前，先将失败目标与预期绕过规则对应起来。指南还列出遥测、模型编写的 workflow worker 和 Node PTC 进程等直连路径；不能用这些路径的结果证明其他 DSH 请求使用了相同路由。
文档中的代理变量不支持 SOCKS URL：DSH 在启动时报告并跳过该值，对相应协议直连。这会改变实际看到的网络路径和证书。代理路由指南详细介绍路由规则；本文聚焦证书排查。
DeepSeek Harness：怎样测试 CA 配置？
- 记录受影响的 DSH 版本、请求目标、脱敏错误和启动方式。区分模型调用、页面抓取或其他路径；报告中不要包含密钥或代理密码。
- 确认预期代理可达，并在应该经过代理时检查该失败请求是否出现在连接日志中。核对绕过规则及进程继承的代理设置。
- 向负责代理的组织获取正确 CA 证书包，和管理员确认文件及信任策略。不要为了消除错误而随意使用未知证书。
在启动 DSH 的环境中设置文档给出的变量，将示例路径替换为组织提供的实际路径：
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem从该环境启动新的 DSH 进程，重试相同请求。Node 在进程启动时读取该变量，进程已启动后才修改不是文档给出的解决方式。比较前后错误时不要暴露敏感输出。
- 如果 TLS 错误消失但服务返回其他错误，另行检查提供方配置和响应。如果仍失败，向代理管理员提供脱敏后的路由、目标和准确错误；这些来源没有提供适用于所有证书问题的通用修复流程。
公共页面测试成功可以作为路由证据，却不能验证特定模型端点。还要使用预期的提供方与模型重试原始失败请求。条件允许时每次只改变一个条件，以便比较结果。
DeepSeek Harness：提供方仍然失败怎么办？
模型配置指南介绍了选择提供方和模型以及配置凭据，并指出模型修改在下一次请求时生效，不必重启服务器。这与 NODE_EXTRA_CA_CERTS 的读取边界不同：Node 在进程启动时读取后者。新的模型配置可以影响下一次请求，新导出的 CA 变量则需要新进程读取。
收到应用层响应后，按提供方说明检查当前选择的提供方、端点和模型，并在不公开秘密的情况下检查凭据状态。正确的 CA 包不能修复错误的 API 密钥或端点；反过来，修改凭据也不能证明证书链已经受信任。保留各阶段的实际错误，避免将所有问题都描述为“代理坏了”。
代理 URL 可以包含凭据。代理指南提醒，子命令继承代理变量，打印环境的命令可能把密码写入保留的输出。不要把原始环境变量转储或代理 URL 粘贴到问题单中。脱敏报告可以说明设置是否存在、预期路径和错误，而不公开值。
DeepSeek Harness：有哪些限制和注意事项？
使用组织批准的 CA 证书包并遵循其信任策略。不要为使请求成功而关闭证书验证。信任一个 CA 会影响进程的信任判断；连接成功只说明该次连接成功，不是全面安全保证。所引用的 DSH 指南没有给出所有 TLS 错误的通用修复，也没有证明每个子进程使用完全相同的运行时或信任库。
如果端点绕过企业代理，应检查直连路径和其证书，而不是假设发生了代理拦截。新进程仍然失败时，保留错误和路由证据，并联系负责代理或端点的管理员。只有接收方和渠道合适时才提供内部主机名、证书内容或其他敏感信息。
如何区分两个启动时机？
模型设置与 Node 信任设置的生效时机不同。模型指南说模型修改在下一次请求生效；代理指南说 Node 在进程启动时读取额外 CA 设置。因此先确认当前 DSH 是由哪个终端、服务或桌面启动流程启动，再确认新变量存在于该启动环境。仅在另一个终端中设置变量，不能证明已经运行的进程读取了它。重启后应重试相同目标并保存新的错误类别。
代理日志应该怎样解读？
代理日志出现某次连接只证明该连接到达了代理。它不证明 TLS 验证已经完成，也不证明后续请求使用相同端点。反过来，没有看到记录也可能是请求按规则直连，或该请求路径本来就不走 DSH 配置的代理。先结合目标主机和绕过规则判断，再请代理管理员核实连接；不要把每一种缺失记录都归因于证书。
DeepSeek Harness：相关术语是什么？
- TLS：用于建立经过认证的加密连接的协议。
- CA 证书包：进程验证证书时使用的证书颁发机构材料。
- TLS 拦截：代理终止并重新建立 TLS 连接的一种部署方式。
NODE_EXTRA_CA_CERTS：Node 启动时读取的额外 CA 证书设置。NO_PROXY：决定哪些主机连接绕过代理的规则。
相关阅读
本文首发于 DSH Plugin 社区（dsh-plugin.com），版权归属 DSH Plugin 社区。
原文地址：https://dsh-plugin.com/zh/blog/troubleshoot-tls-certificate-errors-with-a-corporate-proxy
