DeepSeek Harness 代理怎么配：HTTP 代理、反向代理与 zcode 反代三种场景与排查

代理在 DeepSeek Harness 里有三个方向：出站、入站、接口层。 方向不同，配置位置与排查方法完全不同；混着叫「代理」，最容易改错地方。

三个方向

先分清请求往哪走。

出站代理解决「我出不去」。 网络受限时，客户端通过代理访问模型服务。

入站反代解决「别人进不来」。 外部访问你的 Web UI，需要在网关层加域名、TLS 与认证。

接口反代解决「请求发到别处」。 把模型请求转到另一个端点，或做协议转换；它只影响模型调用。

HTTP 代理：出站

出站代理的配置目标是「所有请求都走代理」。

1. 确认代理地址与端口，是否需要账号密码。
2. 在客户端或环境变量里配置 HTTP/HTTPS 代理。
3. 确认本地服务本身不走代理，避免环路。
4. 测试模型请求，确认能到达服务商。
5. 看代理日志，确认请求确实经过。

代理与直连要区分。 只给模型请求配代理，不要把本地回环也代理出去；否则会出现自己访问自己的环路。

证书问题最常见。 企业代理做 HTTPS 扫描时会替换证书；需要信任企业根证书，而不是关闭校验。

反向代理：入站

反向代理的配置目标是「安全地对外开放」。

1. 配置域名与 TLS 证书，指向本地 Web 服务。
2. 加认证层，至少一层登录或访问控制。
3. 配置来源限制，减少扫描面。
4. 转发 WebSocket 与长连接，避免页面断连。
5. 用外部网络测试，确认不依赖内网。

TLS 与认证是底线。 缺任何一条，公网访问都不安全；只靠端口不常见，不算防护。

WebSocket 容易被漏。 只转发普通 HTTP，页面能开但功能异常；需要显式配置升级头。

zcode 反代：接口层

接口反代只处理模型请求，不影响 Web UI。

1. 确认目标端点与协议：OpenAI 兼容还是自有协议。
2. 配置 base URL 与密钥，注意路径是否带版本段。
3. 确认模型名映射，避免上游改名导致 404。
4. 测试模型列表与对话两条链路。
5. 记录转发规则，便于回退。

协议不匹配会表现为 404 或解析失败。 接口反代不是简单转发，有时需要转换请求体；先看目标端点的文档（来源）。

模型名可能被映射。 反代层用自己的别名指向上游模型；填错别名，客户端看到的是「模型不存在」。

三种场景对照

按「方向、配置位置、验证方式」对号。

三种可以同时存在，但不要用一个「代理」概念覆盖三层。 出站代理 + 入站反代 + 接口反代，三层各管一段；排查时先确定请求走哪一层。方向不同，配置与日志都不同；混着改，问题会越来越多。

失败排查

四类失败覆盖大多数代理问题。

1. 完全连不上： 代理地址、端口或认证错误；先测代理连通性。
2. 证书错误： 中间证书缺失或被替换；补信任链，不要关闭校验。
3. 502/504： 反代转发失败或上游超时；看网关日志与上游状态。
4. 页面能开但功能异常： WebSocket、跨域或请求头未转发。

四类的排查入口是「先看请求到没到代理」。 没到是客户端配置，到了失败是上游或转发；这一步能分掉一半问题。

日志要分层看。 客户端日志、代理日志、上游日志，三层对照，才能定位。

安全边界

代理扩大了网络路径，安全要求更高。

1. 不裸暴露端口： 入站必须有 TLS 与认证。
2. 来源限制： 能按 IP 或网段限制就不要全开放。
3. 证书校验不关闭： 关闭校验等于放弃身份验证。
4. 代理凭据保护： 代理账号密码不要写进仓库或前端。
5. 日志脱敏： 代理日志可能含密钥与请求体，注意保存范围。

代理不是安全措施。 它转发流量，不替代认证与权限；把安全寄托在「地址不公开」上，风险很高。

下一步

先定方向，再配位置，最后看日志。 想看网络代理的基础配置，看《DeepSeek Harness 代理配置》；想看 Web 反代，看《DeepSeek Harness 反向代理》；想看 zcode 反代，看《dsh zcode 代理》。

来源：DeepSeek Harness 官方文档、dsh CLI README、deepseek-harness 仓库