DeepSeek Harness 怎么部署到远程服务器？dsh web 只绑 127.0.0.1，用 SSH 隧道访问

把 DeepSeek Harness 部署到远程服务器，难点不在安装，而在「装完之后怎么安全地用」。 官方刻意让 dsh web 只绑定 127.0.0.1 并拒绝 --host 0.0.0.0，CLI 也不提供网络部署模式——所以正确做法不是开端口，而是用 SSH 本地端口转发把远端回环地址带到本机浏览器。

在服务器上先把 DeepSeek Harness 跑起来：Node.js 与两条启动路径

服务器侧只做一件事：让 dsh 在服务器上跑起来，地址仍然是服务器自己的 127.0.0.1:3080（来源）。

1. 准备运行环境 — 在服务器上安装 Node.js；用源码路径的还需要 pnpm。预期：node -v 能输出版本号。
2. 选一条启动路径 — 免安装路径执行 npx @deepseek-ai/dsh web；源码路径先 git clone 再 pnpm install、pnpm run build，最后 pnpm dsh web。预期：服务在服务器上监听 3080，终端打印访问地址。
3. 强制只跑服务器 — 加上 --no-open，避免在没有图形界面的机器上去尝试打开浏览器。预期：只启动服务、只打印地址，不在服务器上找浏览器。
4. 需要换端口时改应用参数 — 端口属于 web 应用参数，写成 dsh --profile web --port 8080。预期：启动器只解析自己的 flag，第一个不认识的参数交给应用处理。

服务器上没有图形界面不是问题——DeepSeek Harness 的服务端与浏览器本来就分开，纯服务器环境只会打印地址而不尝试打开页面。

为什么不能直接把 DeepSeek Harness 的 DSH web 开到公网：绑定 127.0.0.1 与拒绝 0.0.0.0

这是官方刻意的取舍，不是配置没找对：Web 应用可以以 Host 用户的权限执行命令，若提供全接口模式，就等于在没有 TLS 与代理约定的前提下暗示支持网络部署（来源）。

1. 绑定地址固定为回环 — dsh web 绑定 127.0.0.1，并拒绝 --host 0.0.0.0。预期：局域网内其他机器直接访问会连不上，这是预期行为。
2. CLI 不开放网络模式 — 不提供自定义接口、全接口或 IPv6 模式。预期：不要指望通过命令行参数把服务暴露出去。
3. 认证不等于允许远程部署 — 进程令牌与浏览器 cookie 认证不扩大这个部署约定。预期：即使有认证，官方也没有为远程部署提供 TLS、转发 header 解释或代理配置支持。
4. SSH 启动时的表现 — 通过 SSH 启动只打印宿主机 URL。预期：本地转发地址由 SSH 客户端或编辑器持有，所以服务端只报自己那侧地址。

端口访问与认证细节的排查，见《Web 访问与端口》与《Web UI 配置》。

三种安全访问 DeepSeek Harness 的做法：SSH 端口转发、仅本机使用与无界面模式

远程使用 DeepSeek Harness 有三条路，按「要不要界面」来选（来源）。

1. SSH 本地端口转发（推荐） — 在本地机器执行 ssh -L 3080:127.0.0.1:3080 <用户>@<服务器>，保持会话不断开。预期：本地 3080 被映射到服务器的 127.0.0.1:3080，流量走加密隧道，服务器不需要对外开放任何端口。
2. 拿到带令牌的地址再打开 — 从服务器终端复制打印出来的带 ?token= 的根 URL，在本地浏览器粘贴。预期：令牌被换成会话 cookie 并重定向到干净的根路径；进程重启后令牌会变，需要重新取一次。
3. 只在服务器本机用 — 干脆不转发，直接在服务器上用命令行模式。预期：适合只想跑任务、不想要界面的场景。
4. 无界面批处理 — 用 dsh --profile headless "任务" 跑一个全新会话并打印最终答案，或用 dsh --profile sdk 走 JSON-RPC 供客户端调用。预期：完全不暴露 Web 入口，适合定时任务与自动化。
5. 不要改用公网暴露替代转发 — 例如自行加反向代理把 3080 推上公网。预期：这越过了官方明确不支持的边界，认证机制也不是为这个场景设计的。

运行模式各自的适用场景，见《dsh 运行模式怎么选》。

远程排错与常驻：DeepSeek Harness 跑在服务器上怎么看问题

服务器上出问题，第一手证据是日志而不是界面——因为界面可能根本打不开（来源）。

1. 确认进程与端口 — 在服务器上查看进程是否还在、3080 是否在监听。预期：进程没了说明服务已退出，先看终端的报错输出。
2. 按类别与级别看日志 — 在系统日志里按安装、卸载、更新、诊断等类别与级别筛选。预期：异常能定位到具体环节，而不是只看到一句「起不来」。
3. 改动配置前先干跑一次 — 用 --dump-default-config 或 --dump-config 在不启动的情况下检查合成后的配置树。预期：配置写错时能立刻发现，不必反复重启服务。
4. 常驻需要自己托管 — 官方文档未提供服务化或守护进程方案。预期：想在服务器上长期运行，用 tmux、screen 之类的终端复用器或系统服务自行托管，并明确数据目录 $DSH_HOME 的归属用户。
5. 升级前先读日志 — 本体升级按安装方式选命令。预期：命令对照表见《更新命令速查表》。

远程部署 DeepSeek Harness 的注意事项与局限

1. 绑定地址不可改：127.0.0.1 与拒绝 --host 0.0.0.0 是官方决策，任何绕过都超出受支持范围。
2. 认证不是部署方案：令牌与 cookie 解决同机访问的凭据问题，不解决 TLS、反向代理与远程部署约定。
3. 令牌每次启动都变：远程访问需要重新从服务器终端取一次带令牌的地址，无法预先收藏。
4. 隧道断开即失去访问：SSH 会话结束时转发失效，界面会打不开，这不是服务挂了。
5. 数据目录要归属清楚：以哪个用户运行 dsh，就会用哪个用户的 $DSH_HOME，换用户运行等于换了一套配置与插件。

服务器上想装 DSH plugin，用免安装路径起服务后在 DSH Plugin Hub 的插件市场里按分类挑选即可，不需要在服务器上手动改依赖文件。

来源：DeepSeek Harness README（官方仓库）、dsh CLI README（官方仓库）、Agent Note：显式指定 Web 绑定地址、Agent Note：浏览器令牌认证