DeepSeek Harness 代理配了却不生效怎么排查？七条永远直连的请求路径逐条盘点

“代理配了，但有一半请求没走代理”在 DeepSeek Harness 里不一定是故障，很多是设计使然。 官方明确列出了一些保持直连的路径：本机、模型编写的代码、遥测、私网抓取等。排查时先把这些路径划掉，再去查环境变量、SOCKS 与证书，才不会在错误的方向上反复改配置。

DeepSeek Harness：七条保持直连的路径

先对照这张清单，确认你观察的请求本来就不该走代理。 七条：（来源）

1. loopback — localhost、127.0.0.0/8、::1、0.0.0.0 始终直连。预期：Web UI 与本地服务不会被代理绕成回环。
2. Workflow worker — 模型编排的 worker 不接收代理配置。预期：脚本读不到代理 URL。
3. Node PTC runtime — 程序化工具执行进程同样不接收代理。预期：模型写的代码不会带出代理凭据。
4. 遥测 OTLP — 导出器用 Node 自带 HTTP 客户端，不走代理。预期：禁止直连出网时它只会失败，不影响主流程。
5. 私网 web_fetch — 形如 http://10.0.0.5/ 的字面量私网地址会被拒绝，而不是交给代理。预期：不会借代理绕过私网限制。
6. 操作系统代理设置 — DSH 不读系统代理。预期：浏览器走、终端不走是正常现象。
7. 旧版 Node 子进程 — Node 22.21 以下不遵循代理变量。预期：同一台机器上不同子进程行为可能不同。

清单之外才是“应该走代理”的请求：模型调用、web 搜索、页面抓取、HTTP MCP 服务器等。

DeepSeek Harness：NO_PROXY 的四个规则

NO_PROXY 只认主机名，不认网段；写错格式等于没写。 四条：（来源）

1. 条目是主机名 — example.com 会连同其子域名一起匹配。预期：api.example.com 也直连。
2. 前缀 . 或 *. 等价 — 两种写法含义相同。预期：不用纠结写法。
3. 可带端口 — 例如 internal.example.com:8080。预期：只对该端口直连。
4. CIDR 不生效 — 把 10.0.0.0/8 复制进来不会匹配。预期：需要直连的域名要逐个写。

loopback 不需要列；DSH 始终绕过它，否则自己的 Web UI 与本地服务会形成回环。

DeepSeek Harness：SOCKS 与 ALL_PROXY

SOCKS 不被支持；写了也会被跳过，对应协议转为直连。 行为：（来源）

• socks5:// 被报告并跳过 — 启动时能看到提示。预期：该 scheme 直连。
• 不会借用 HTTP 代理 — 即使同时设置了 HTTP_PROXY，https: 仍保持直连。预期：不要以为“配一个就能兜底”。
• ALL_PROXY 可作为兜底 — 只设它也能为两种协议提供代理。预期：显式设 HTTPS_PROXY 更清楚。

想用 SOCKS 代理，正确做法是找代理软件的 HTTP 端口，把变量指向它，而不是继续用 socks5://。

DeepSeek Harness：子进程与证书

代理变量会被 DSH 运行的工具继承，但这不等于每个子进程都会遵守。 三点：（来源）

1. bash、git、gh、MCP 子进程继承变量 — 它们读标准环境变量。预期：命令行走代理。
2. Node 子进程需要 22.21+ — 更旧版本直连。预期：检查子进程的 Node 版本。
3. TLS 拦截要装 CA — 代理可达但仍报证书错误时，设置 NODE_EXTRA_CA_CERTS 指向企业 CA，并在启动前导出。预期：证书链校验通过。

另外，代理 URL 里的密码会作为普通环境变量传到子进程，模型编写的命令也能读到。需要保密时，用无凭据入口或 URL 之外的认证方式。

DeepSeek Harness：三种验证方法

不要只看“代理软件有没有开”，要看你关心的那条请求走了哪。 三种：（来源）

1. 让 Agent 抓页面 — dsh --profile headless "fetch https://example.com"，同时看代理连接日志。预期：该请求出现在日志里。
2. 查环境 — env | grep -i proxy。预期：变量在启动 DSH 的环境里可见。
3. 换 TUN 模式 — 对不读环境变量的程序透明。预期：如果 TUN 下能走，说明问题在变量继承而不是网络。

如果三种方法结果不一致，以“实际请求路径”为准；不要用浏览器能打开来证明 DSH 会走代理。

DeepSeek Harness：从现象到路径的判断树

先按现象分叉，能快速排除一半“代理没生效”的误判。 判断顺序：（来源）

1. 只有浏览器能走 — 系统代理与终端变量是两套，先导出 HTTPS_PROXY 或开 TUN。预期：终端命令开始走代理。
2. 模型调用能走、工具不能 — 看工具是不是 Node 子进程、版本是否低于 22.21。预期：升级子进程 Node 或改用 TUN。
3. 页面抓取被拒 — 看 URL 是否是字面量私网地址；这类请求会被拒绝而不是交给代理。预期：不会误判成代理故障。
4. 代理日志完全没有该请求 — 对照七条直连路径，确认它本来就不该走代理。预期：不再改无用的变量。
5. 代理有连接但报证书错误 — 走 TLS 拦截，补 NODE_EXTRA_CA_CERTS。预期：证书链校验通过。

判断树走完仍不通，再看代理软件本身的认证、端口与上游规则；不要一开始就重装。

还有一个容易忽略的细节：代理 URL 里的密码会进入子进程环境，模型编写的命令也能读到。如果排查时打印过环境，记得把输出里的凭据清掉。

需要长期保密时，给代理一个无凭据入口，或改用 URL 之外的认证方式；不要依赖“变量只在 DSH 进程里可见”。

三套代理机制对照

“浏览器能走、终端不走”不是 DSH 的 bug，而是三套机制互不相通。 对照：

所以排查前先问：你改的是哪一套？改系统代理不会影响 DSH；改环境变量不会影响已经启动的进程；TUN 模式则绕开变量，直接接管流量。

DeepSeek Harness 常见问题

Q：为什么设置了 HTTPS_PROXY，模型调用还是超时？ 先看代理是否支持该协议、是否需要认证、证书是否被信任；再看变量是否在启动环境里。SOCKS 与 CIDR 是两个高频坑。

Q：能不能让遥测也走代理？ OTLP 导出器使用 Node 自带 HTTP 客户端，不走代理；需要隔离时关闭遥测，而不是指望代理。

Q：NO_PROXY 写了 * 会怎样？ 全部直连。它适合临时排障，不适合长期配置。

一句话收束： 代理排查先分清“本来直连”和“应该代理”；七条直连路径划掉后，再查变量、SOCKS、证书与子进程版本。