dsh web authentication required？DeepSeek Harness 打不开、3080 端口

DeepSeek Harness 的 Web UI 每次启动都会生成一枚随机启动令牌，只通过首启打印的带 ?token= 地址换取浏览器 cookie；没有有效 cookie 的请求一律收到同一份最小 401，浏览器上就表现为 authentication required。 本文按「机制 → 三种恢复姿势 → 端口与绑定 → 两种 401 怎么分」讲清这个提示怎么来的、以及怎么把访问恢复回来。

DeepSeek Harness 网页认证：authentication required 是怎么来的

DeepSeek Harness 的 Host 进程每次启动生成随机启动令牌，只有 GET /?token=... 会把进程令牌换成 cookie 并重定向到干净的 /，API 路径与 Authorization header 都不接受该令牌（来源）。 一次完整的交换是这样发生的：

1. 启动 dsh web：终端打印并打开一次带令牌的根地址。预期结果：地址形如 http://127.0.0.1:3080/?token=...，且只打印这一次——令牌绝不持久化，进程重启就换新的。
2. 用该地址访问一次：GET /?token=... 把进程令牌换成 cookie，然后重定向到干净的 /。预期结果：浏览器地址栏变回 http://127.0.0.1:3080/，后续访问不再需要令牌。
3. 再不带凭据请求：缺少与无效凭据返回同一份最小 401。预期结果：浏览器显示 authentication required 一类的最小响应，而不是正常页面。
4. 来源校验失败的请求：Host / Origin 校验先执行，失败返回 403。预期结果：403 与 401 含义不同——403 是来源不被信任（DNS rebinding 与跨站请求防御），401 是来源可信但没有有效浏览器会话。

另外两点容易误判：非 index 的静态资源保持公开，所以「图片能打开」不代表认证通过；带令牌的 URL 属于进程凭据，要当成敏感输出，别贴到聊天窗口或 Issue 里。

DeepSeek Harness dsh web 打不开的三种恢复姿势

访问丢失时按代价从小到大恢复：先用重启后新打印的带令牌 URL 重新换 cookie，其次删凭据记录并重启撤销全部会话，最后才考虑换浏览器或换端口重新认证（来源）。 具体四步：

1. 重启进程，用新的带令牌 URL 打开一次：关掉再重新执行 npx @deepseek-ai/dsh web。预期结果：浏览器重新拿到 cookie、页面恢复正常；拿旧令牌 URL 访问时，只要还带有效 cookie，也会被重定向到干净的 /。
2. 需要撤销全部浏览器会话时，删凭据记录再重启：删除 $DSH_HOME/.credentials.yaml 里的 client-connection/browser-session 记录，然后重启进程。预期结果：全部既有 cookie 失效，必须用新的带令牌 URL 重新认证；注意当前运行中的进程仍持有已加载的密钥，删除记录后要重启才生效。
3. 换浏览器或换端口后重新认证一次：cookie 绑定 hostname 与 port。预期结果：新地址上要用新打印的带令牌 URL 再换取一次 cookie，旧 cookie 不会自动跟过去。
4. 没有 logout 可按：官方没有提供 logout 操作。预期结果：全局撤销只有「删凭据记录 + 重启进程」，只想踢掉单个浏览器会话则用浏览器的站点数据控制。

这类访问问题在 DSH Plugin Hub 的系统日志里也能对照：排查网页访问问题时按级别与类别看行级记录，能区分是启动阶段还是请求阶段出的问题。

DeepSeek Harness 的端口与绑定：默认 127.0.0.1:3080、拒绝 --host 0.0.0.0

dsh web 默认绑在 127.0.0.1:3080，CLI 只提供 loopback 选择并拒绝 --host 0.0.0.0——进程令牌与 cookie 认证并不扩大这个部署约定（来源）。 端口相关按三步做：

1. 确认访问地址：默认 http://127.0.0.1:3080，本机启动还会自动用默认浏览器打开；通过 SSH 启动时只打印宿主机 URL，因为本地转发地址由 SSH 客户端或编辑器持有。预期结果：终端有一行地址提示；没有浏览器弹出不等于没起来。
2. 换端口：--port 属于 web 应用参数，写在命令后面，如 dsh --profile web --port 8080（等价写法 dsh web --port 8080）。预期结果：服务在新端口起来，浏览器访问 http://127.0.0.1:8080；换端口后按上一节第 3 步重新认证一次。
3. 不要试着绑 0.0.0.0：dsh web 会拒绝 --host 0.0.0.0，因为绑定非回环地址会把带工具能力的 Host 直接暴露出去。预期结果：该参数以用法错误退出；远程访问改用 SSH 端口转发，地址与代理相关的排查见《127.0.0.1:3080 打不开》，界面本身的问题见《Web UI 打不开、白屏》。

DeepSeek Harness 两种 401 怎么分：网页认证与模型密钥

DeepSeek Harness 里的 401 有两种来源：网页层的 401 表示浏览器会话无效，模型层的 401 表示模型 API 的密钥或 endpoint 被拒——两者要查的地方完全不同（来源）。 按下面四步分流：

1. 看 401 出现在哪里：浏览器一打开页面就是 401，属于网页层；在会话里调用模型时才 401，属于模型层。预期结果：能立刻确定要不要动模型配置。
2. 网页层：重新换 cookie：按上一节第 1、2 步处理。预期结果：页面恢复；此时去改模型密钥不会有任何帮助。
3. 模型层：查密钥与 endpoint：到设置 → 模型核对密钥、基础 URL 与模型名。预期结果：模型调用恢复；完整排查见《模型配置 401》。
4. 403 不属于这两者：Host / Origin 校验失败说明请求来源不被信任。预期结果：换回本机地址访问即可，不用改密钥也不用清 cookie。

网页层的接入与界面导览见《DeepSeek Harness Web UI 配置》；如果你跑的不是 web 模式，本来就没有网页界面，各模式差别见《DeepSeek Harness 一条 dsh 命令多种模式》。

DeepSeek Harness 网页认证与端口的注意事项与局限

1. 带令牌的 URL 等于进程凭据：它是换取 cookie 的唯一凭据，运行时诊断不会重复打印它，所以丢了只能重启进程换新的。
2. cookie 跨重启有效、但绑定 authority：同一 hostname 与端口上的未过期 cookie 能继续用；换端口或换 hostname 就必须重新认证。
3. 撤销只有全局路径：没有 logout；删 client-connection/browser-session 记录并重启会撤销全部会话，单个会话靠浏览器站点数据。
4. 认证不等于可对外部署：官方明确不支持网络部署、TLS、转发 header 解释与代理配置；远程访问走 SSH 隧道。
5. 版本会变：DeepSeek Harness 处于开发者预览阶段，官方明确未来将有破坏兼容性的变更（来源），提示文案以当前版本为准。

来源：Agent Note：浏览器启动令牌认证、Agent Note：显式指定 Web 绑定地址、DeepSeek Harness README、dshplugin/dsh-plugin-hub