截至 2026 年 8 月 19 日，DeepSeek Harness 官方 README 仍确认 Web UI 默认监听 http://127.0.0.1:3080。因此本周的建议很直接：个人或少量固定成员访问，保持回环监听并使用 SSH 隧道；只有团队入口已经具备独立身份认证、TLS、访问审计和来源限制时，才考虑非回环监听。 trustedHosts 只能约束 Host authority，不能代替用户登录。

官方启动方式和默认地址可在DeepSeek Harness 官方运行说明与 Web UI 使用指南中核对。官方项目目前仍处于开发预览阶段，配置和启动参数可能发生不兼容变化。(github.com)

这篇适合谁：

  • 个人开发者：偶尔从另一台设备安全访问远程 Web UI。
  • 平台工程师：需要为固定小组或正式团队提供稳定入口。
  • 安全负责人：需要确认反向代理、主机信任和应用权限是否形成完整控制链。
01

先按访问规模确定入口级别

你不应该先复制一条“监听到 0.0.0.0”的命令，再考虑安全问题。DeepSeek Harness 远程 Web UI 的入口选择，首先取决于访问人数、入口持续时间和能否撤销成员权限。

访问规模 推荐入口 监听策略 适用边界
个人访问 SSH 隧道 保持 127.0.0.1 临时、单人、无需公开地址
少量固定成员 受控内网或 SSH 跳板 优先回环监听；必要时限制内网来源 成员固定，能维护 SSH 账号
正式团队 HTTPS 反向代理 非回环监听，但前置独立认证、TLS、审计和来源限制 有责任人、变更记录和撤销流程

回环监听解决的是“谁能在网络层触达服务”。它不等于完成身份认证。非回环监听只是把服务绑定到更多网卡或地址，也不自动提供登录、会话、角色和权限撤销。

官方 README 说明，dsh web 默认将 Web UI 服务在 127.0.0.1:3080。这个数字是截至 2026 年 8 月 19 日核对官方 master 文档所得，不应当被视为未来版本的永久默认值。(raw.githubusercontent.com)

个人案例：远程 Mac 上只给自己使用

假设你把 DeepSeek Harness 跑在一台长期在线的远程 Mac 租赁环境中，平时从笔记本或平板查看任务状态。你只有一个访问者，也不需要把页面交给同事。

此时公网入口会额外带来：

  • 防火墙端口管理；
  • TLS 证书续期；
  • 登录组件或反向代理认证；
  • 失败访问日志；
  • 成员撤销和密钥轮换；
  • 版本升级后的代理回归测试。

这些工作不会让单人访问更快，却会增加长期维护面。SSH 隧道更适合这种“远程可达，但服务本身仍保持本机可见”的模式。

02

SSH 隧道与公网入口的暴露面

SSH 隧道的核心是把你本地的一个端口转发到远程 Mac 的回环地址。例如，在 2026 年 8 月 19 日核对过官方默认地址后，个人访问可以使用：

ssh -N -L 3080:127.0.0.1:3080 user@remote-mac

然后在本地浏览器访问：

http://127.0.0.1:3080

-L 转发的监听端口默认只绑定本地使用；OpenSSH 手册也明确区分了 localhost 与空地址、通配地址的可达范围。不要随意加 0.0.0.0:，否则你可能把本地转发端口再次暴露给同一局域网中的其他设备。(man.openbsd.org)

SSH 隧道的优点：

  • ✅ DeepSeek Harness 继续监听回环地址。
  • ✅ 不需要为 Web UI 单独开放公网端口。
  • ✅ 访问者由 SSH 密钥、账号和服务器侧策略控制。
  • ✅ 关闭 SSH 会话即可撤销本次访问链路。
  • ✅ 适合个人开发、临时排查和一两个固定成员。

SSH 隧道的缺点：

  • ❌ 团队成员需要维护 SSH 账号或密钥。
  • ❌ 浏览器访问和 SSH 身份之间没有天然的应用级用户会话。
  • ❌ 隧道断开后，网页可能停留在旧状态。
  • ❌ 共享同一远程账号时，审计粒度不足。
  • ❌ 它不是团队权限系统，不能自动区分“只读”“可编辑”和“可执行任务”。

公网入口的暴露范围更大。你需要明确四件事：入口域名或地址、允许来源、认证方式和关闭路径。只设置监听地址，不算完成部署。

当 Web UI 绑定到非回环地址后，至少要从外部设备检查：

curl -I http://服务器地址:3080
nc -vz 服务器地址 3080

在服务器侧检查实际监听状态：

lsof -nP -iTCP:3080 -sTCP:LISTEN

这些命令只能说明端口是否可达，不能说明访问者是否已经被认证。页面能打开，也不能作为“安全验收通过”。

公网暴露的适用边界

技术上，非回环监听可以扩大网络可达范围；但不建议把它理解成“改完监听地址就能公网使用”。正式公网入口至少要在前面增加独立身份认证、HTTPS、来源限制、访问日志和撤销机制。

如果你无法回答下面 5 个问题，就不要开放：

  1. 谁可以登录？
  2. 如何区分不同成员？
  3. 如何立即撤销某个成员？
  4. 如何看到失败登录和异常来源？
  5. 关闭公网入口后，如何退回 SSH 隧道或回环访问？

没有这些答案时，公网入口只是扩大攻击面，并没有形成完整的访问控制链。

03

trustedHosts 的作用边界

HTTP 请求中的 Host 头用于携带目标主机和端口信息。HTTP 标准将它视为请求路由的重要组成部分；服务器可以据此区分不同主机名对应的资源。(rfc-editor.org)

因此，trustedHosts 更适合被理解为“允许哪些 Host authority 被 Web UI 接受”。它解决的是主机信任边界，例如：

  • 浏览器使用域名访问时，服务是否接受该域名；
  • 反向代理转发后，Host 是否仍然匹配；
  • 未授权的 Host 值是否被拒绝；
  • 代理、浏览器和服务之间是否对目标地址有一致认知。

它不负责确认“这个人是谁”。即使 trustedHosts 配置正确，仍然可能出现以下情况：

  • 页面可以被任何知道地址的人打开；
  • 所有成员共用一个浏览器会话；
  • 没有独立账号、密码或单点登录；
  • 没有会话过期和主动注销；
  • 没有按成员撤销权限；
  • Harness 内部仍然给每个访问者相同的工作区权限。

OWASP 将身份认证、会话管理和访问控制视为相互关联但不同的安全能力。认证用于确认身份，会话用于持续识别请求，授权用于限制用户能做什么。只配置 Host 白名单，无法覆盖这三层。(cheatsheetseries.owasp.org)

trustedHosts 与登录认证的边界

因为两者验证的对象不同。

  • trustedHosts 验证的是请求中的主机权威是否被接受。
  • 登录认证验证的是访问者是否持有有效凭据。
  • 会话管理验证的是后续请求是否属于已认证用户。
  • Harness 内部权限验证的是该用户能否读取工作区、修改文件或执行任务。

你可以把它们拆成一条验收链：

网络可达
→ Host 被接受
→ 用户完成认证
→ 会话保持有效
→ 用户拥有正确的 Harness 权限

缺少任意一环，都不能只用“浏览器能打开”来证明部署完成。

公网团队入口还应具备：

  • 每个成员独立账号；
  • 最小权限角色；
  • 会话过期和主动注销；
  • 成员离职或变更时的立即撤销；
  • 登录失败、来源地址和高风险操作日志；
  • 代理层与应用层的责任边界记录。

如果当前 Harness 版本没有官方确认的内置认证能力，就应把认证放在受控的外部入口层，并把代理具体行为纳入实测。不要把社区配置样例当成官方保证。

04

TLS、API Key 与浏览器链路

SSH 隧道和 HTTPS 反向代理都可以保护传输，但责任不同。

SSH 隧道的主要责任在 SSH 服务端、用户密钥、跳板机权限和本地端口绑定。浏览器看到的通常仍是本地 http://127.0.0.1:3080，但远端链路由 SSH 加密承载。

HTTPS 入口的责任则分散在：

  • TLS 证书和私钥；
  • 反向代理的加密配置；
  • 代理到 Harness 的内部链路；
  • Host 与代理头处理；
  • Cookie、会话和跨域策略；
  • API Key 与环境变量保护；
  • 日志脱敏。

官方 Web UI 指南要求你在 Settings → Models 中配置 DeepSeek API Key，并说明保存后模型路由即可使用。不要把 API Key 放进浏览器 URL、截图、公共日志或提交到代码仓库。(raw.githubusercontent.com)

如果你使用 HTTPS 反向代理，应确认：

  1. 外部访问始终使用 HTTPS。
  2. HTTP 请求是否被强制跳转，跳转过程中没有泄露敏感参数。
  3. 代理日志是否记录了 Authorization、Cookie 或 API Key。
  4. 代理到回环服务的连接是否符合你的威胁模型。
  5. TLS 证书更换后，浏览器和客户端是否仍能正常访问。
  6. 代理传递的 Host 是否与 trustedHosts 的实际配置一致。

OWASP 建议完整 Web 会话都使用 TLS，而不是只在登录页面加密；会话 Cookie 也应具备安全属性。(cheatsheetseries.owasp.org)

05

审计与维护成本

长期团队入口最容易被低估的，不是首次启动，而是成员、版本和故障变化。

SSH 隧道的维护重点：

  • SSH 用户是否一人一账号；
  • 公钥是否有负责人；
  • 成员离开后是否立即删除授权；
  • 是否限制端口转发范围；
  • 隧道断开后谁负责恢复；
  • 是否能区分不同成员的访问记录。

公网入口的维护重点更多：

  • 认证系统是否独立；
  • 代理访问日志是否持续保留；
  • 是否限制来源网络或地址段；
  • 证书是否有续期责任人；
  • 入口变更是否记录；
  • Harness 升级后 Host、WebSocket、静态资源和代理头是否重新验收；
  • 失败登录和异常请求是否能被识别。

OWASP 的日志建议覆盖认证失败、会话创建、续期、注销、权限变化和异常会话行为。对 DeepSeek Harness 这类能够读写工作区、运行命令的 Web UI，只记录“页面访问成功”远远不够。(cheatsheetseries.owasp.org)

如果你只是偶尔查看一个远程 Mac 上的开发工作区，公开入口的证书、代理、认证和审计维护，很可能比任务本身更复杂。此时 SSH 隧道不是“低级方案”，而是把暴露范围压缩到实际需要。

06

端到端验收步骤

无论你选择 SSH 隧道还是公网入口，都建议按下面步骤完成一次完整验收。

1．记录版本和启动参数

记录 DeepSeek Harness 的版本、启动命令、工作目录、监听地址和端口。本文中的默认地址 127.0.0.1:3080按 2026 年 8 月 19 日官方 master 文档核对；升级后重新确认，不要继续沿用旧笔记。

2．确认实际监听状态

在远程 Mac 上运行：

lsof -nP -iTCP:3080 -sTCP:LISTEN

检查输出是否为回环地址、局域网地址或所有接口。配置文件写了什么不够，必须以实际监听结果为准。

3．从外部设备做端口检查

从你的笔记本、手机热点或另一台网络环境不同的设备测试：

nc -vz 服务器地址 3080
curl -I http://服务器地址:3080

SSH 隧道方案中，公网侧端口通常不应直接可达；公网方案中，则应确认只有预期入口可达。

4．验证 Host 行为

使用正式域名、错误域名和直接 IP 分别访问。记录：

  • 正式入口是否返回页面；
  • 未信任 Host 是否被拒绝；
  • 代理转发后 Host 是否改变；
  • 浏览器重定向是否跳到错误地址。

这一步只验收 Host 信任，不验收用户身份。

5．验证独立身份认证

用两个不同成员账号进行登录。确认每个成员的会话是否独立，注销一个成员后，另一个成员是否仍然有效。再撤销其中一个账号，确认旧会话是否被终止。

如果团队入口没有这一步，trustedHosts 只能算配置检查通过，不能算安全验收通过。

6．执行受控任务

让低权限成员访问工作区，并尝试执行一个明确受控的操作。确认 Harness 内部权限是否真正生效，而不是只有代理层登录。

不要使用“能看到页面”作为权限测试。页面访问、读取文件、修改文件和执行命令应分别验证。

7．测试断线和恢复

关闭 SSH 会话，或临时停止代理，再观察浏览器提示和任务状态。重新连接后确认：

  • 会话是否需要重新认证；
  • 未完成任务是否继续、暂停或失败；
  • 浏览器是否显示旧数据；
  • 入口日志是否记录断开和恢复；
  • 回退到 SSH 隧道后是否能重新访问。

8．保留证据

最低限度保留三类记录：

  • 监听状态截图或命令输出；
  • 入口访问和失败请求日志；
  • 成员认证、权限与撤销结果。

这些记录比一份“已配置完成”的文本说明更有价值，因为它们能证明实际链路发生了什么。

07

最终选择条件

你可以用下面的条件做最后判断。

继续使用 SSH 隧道：

  • 访问者不超过少量固定成员；
  • 访问时间是临时或间歇性的；
  • 远程 Mac 已有稳定 SSH 管理方式；
  • 你不需要浏览器级多人会话；
  • 你希望 DeepSeek Harness 始终保持回环监听。

建设受控公网入口：

  • 团队需要统一域名和浏览器入口；
  • 已经有独立身份认证；
  • 已经配置 HTTPS 和证书续期；
  • 能限制来源并记录访问；
  • 能独立撤销成员和终止会话；
  • 有人负责版本升级后的回归验证。

退回回环访问：

  • 只有端口开放，没有认证；
  • trustedHosts 能放行，但没有登录机制；
  • 代理日志无法脱敏；
  • 不能确认 API Key 和会话是否会出现在日志中；
  • 无法验证成员权限；
  • 入口出了故障，也没有明确关闭和恢复路径。

如果你现在是把 DeepSeek Harness 部署在一台远程 Mac 上做个人开发，公网入口通常有几个真实缺点：暴露范围更大、维护 TLS 和认证、需要持续审计，还会增加升级后的故障点。对临时算力、异地开发和持续运行任务来说，先保持回环监听，再通过 SSH 隧道访问，往往比搭建一个没有完整治理能力的公开 Web UI 更稳妥。

如果你需要长期运行环境，可以先了解 DeepSeek Harness 云端 Mac 的交付方式，再结合远程 Mac 方案选择判断是继续使用 SSH 隧道，还是建设带认证、TLS 和审计的团队入口。若你只是临时测试，也可以优先选择更容易关闭和回退的远程访问路径，而不是提前承担公网服务的长期维护成本。