DeepSeek Harness 公网部署怎么下线？反代、TLS、cookie 与端口回收

公网部署下线不是“把 dsh 进程关掉”，而是把外部入口、认证凭据、证书与专用端点逐项撤回。 只停进程，反代还在、DNS 还指向、webhook 还在投递；外部看到的是 502，不是“已下线”。正确顺序是先把流量入口关掉，再停服务，最后清凭据与残留。

DeepSeek Harness：先列入口清单

下线前先写清楚“有哪些门”，否则总会有漏掉的入口。 一张清单：（来源）

清单里最容易被忽略的是“隧道”和“webhook”。隧道停了但面板里映射还在，下次启动可能又自动连上；webhook 不删，GitHub 会持续重试投递。

DeepSeek Harness：四条回收命令

不要靠“我记得关过”，用命令确认每个入口都不在了。 四条：（来源）

1. 查监听端口 — lsof -i :3080 与 lsof -i :3081。预期：没有 DSH 进程。
2. 查外部可达 — 从非本机网络 curl -I https://app.example/。预期：连接失败或域名不存在，不是 502。
3. 查反代与隧道 — 检查站点配置、隧道面板与系统服务。预期：没有指向 DSH 的 upstream 或自启项。
4. 查 webhook — 回 GitHub 仓库 Settings → Webhooks 确认订阅已删。预期：没有最近投递。

四条都过，再处理证书与凭据文件；顺序反了，容易在入口还开着时就删掉排障所需的凭据。

DeepSeek Harness：三步下线顺序

顺序错了会增加暴露窗口：先断入口，再停服务，最后撤凭据。 按下面做：（来源）

1. 断外部流量 — 删除 DNS 记录、停反代站点或关闭隧道映射。预期：外部访问域名直接失败，而不是 502。
2. 停 DSH 进程 — 正常停止 dsh web，确认 3080 端口释放。预期：lsof -i :3080 没有残留监听。
3. 撤认证凭据 — 清理或轮换用于签名会话 cookie 的凭据，删除不再需要的 provider key。预期：旧浏览器 cookie 无法继续通过验证。
4. 清 TLS 文件 — 证书与私钥移出 DSH 读取路径，确认没有遗留副本。预期：下次启动不会误用旧证书。

第 3 步要谨慎：凭据文件可能同时保存模型 provider 的 key。只下线 Web 访问、仍要用模型时，不要整文件删除；应只轮换与 Web 会话相关的部分，或按官方凭据结构处理。

DeepSeek Harness：三种部署形态的下线差异

反代、隧道、原生 TLS 的下线动作不同，别用同一套步骤套所有情况。 对比如下：（来源）

1. 反向代理终止 TLS — 先停反代站点，再停 DSH。注意：代理配置里可能还有 upstream 指向 3080，删站点时一并清掉。
2. 隧道访问 — 先停隧道客户端并删除面板映射，再停 DSH。注意：隧道可能配置了开机自启，检查系统服务。
3. dsh web 原生 TLS — 停进程即停止监听，但证书文件仍在磁盘。注意：删除或移走 --tls-cert 与 --tls-key 指向的文件，避免下次误用。

如果同时用了反代和原生 TLS，按“外层先关、内层后关”的顺序：先停反代，再停 DSH。

DeepSeek Harness：GitHub 评审专用端点

GitHub 评审是第二个监听器，默认在 3081，只注册 POST /github；它不会随主 Web UI 一起被“关掉”而不留痕。 下线步骤：（来源）

1. 删 GitHub 订阅 — 在仓库 Settings → Webhooks 删除对应条目。预期：GitHub 不再投递。
2. 停 overlay 进程 — 不再用 --patch 加载 github-review 配置。预期：3081 不再监听。
3. 移除实验包 — 用 dsh plugin --profile web remove 卸掉 webhook 与 GitHub 适配器。预期：profile 依赖里不再有它们。
4. 清环境变量 — 删除 DSH_GITHUB_WEBHOOK_SECRET、DSH_GITHUB_REVIEW_WORKSPACE 等变量。预期：重启不会重新启用旧配置。

注意：webhook 密钥只验证入站 GitHub 数据，不会给规则代码或 Agent 授予出站 GitHub 访问权。下线时不要以为删了密钥就等于撤销了 Agent 的 GitHub 权限，后者要单独检查。

DeepSeek Harness：残留检查

下线完成后，从外部和内部各查一遍，确认没有“看不见的入口”。 检查项：（来源）

1. 外部访问 — 从非本机网络访问域名、IP 与旧端口。预期：全部不可达。
2. 本机监听 — lsof -i :3080 与 lsof -i :3081。预期：没有 DSH 进程。
3. 反代与隧道 — 检查站点配置、隧道面板、系统服务。预期：没有指向 DSH 的 upstream 或自启项。
4. webhook — 回 GitHub 仓库确认订阅已删。预期：没有最近投递记录。
5. 证书与备份 — 确认私钥没有留在临时目录、下载目录或旧备份。预期：敏感文件已清理或归档到受控位置。

如果第 1 步仍能打开页面，先别继续删文件，回到入口清单找漏项；很可能是 DNS 缓存、云负载均衡或另一个隧道。

重新上线时不要复用旧配置

下线后再次上线，应按新部署处理，而不是把旧参数原样拷回来。 三点：

1. 换新令牌与证书 — 旧启动令牌已失效，旧证书可能已过期或泄露。预期：重新生成并验证链完整。
2. 重配 trusted-host — 域名或端口变化后，旧名单不再匹配。预期：按当前 authority 重新写。
3. 重新评估 webhook 密钥 — 旧密钥可能已出现在日志或备份里。预期：生成新密钥并更新 GitHub 订阅。

重新上线前，先用一台测试机验证 /api 不返回 403，再切正式流量。测试机最好从外部网络访问，避免被本机回环地址误导。

如果测试机仍然 403，先查 --trusted-host，不要急着换证书；403 是信任栅栏，不是 TLS 握手失败。

DeepSeek Harness 常见问题

Q：只停 DSH 进程，外部还能访问吗？ 会看到 502 或连接失败，但入口仍然存在。对于公网部署，这不算下线；应先撤入口。

Q：下线后还能用同一个域名重新部署吗？ 可以。重新部署时换新的启动令牌与证书，并重新配置 --trusted-host 与 --public-url；不要复用旧 cookie 或旧密钥。

Q：本地开发用的 DSH 也要按这套下线吗？ 不需要。只监听 loopback、没有反代与 webhook 的本地实例，停进程即可；本文针对的是有外部入口的部署。

一句话收束： 公网下线的判断标准不是“进程没了”，而是“外部再也到不了、旧凭据不再有效、专用端点不再投递”；按入口清单逐项销账，才算干净。