DSH Desktop 431 启动故障排查

DeepSeek Harness Desktop 431：随机端口 Cookie 累积

作者
DeepSeekAgent.io 编辑部
发布
更新

DeepSeek Harness Desktop v0.2.1-rc.3 的一个 Windows 社区案例出现了非常稳定的启动崩溃：点击应用后没有窗口，主进程日志停在 desktop welcome: Web authentication failed，重启和重装都无法恢复。进一步检查发现，真正的 HTTP 状态是 431——请求头过大。

问题由 Desktop 的随机 GUI 端口、按 authority 生成的认证 Cookie 名称和三天有效期共同形成。每次 Host 端口改变，Electron Cookie Jar 都保留一枚新的 dsh-auth-* Cookie；旧 Cookie 不会被同名覆盖。积累到接近 Node.js 请求头上限后，带完整 Cookie Jar 的 Desktop Welcome 请求被拒绝，主进程随即退出。

为什么网页认证成功，Desktop 仍然失败

启动认证包含两个不同客户端：

  1. 浏览器完成 Web 端身份认证；
  2. Desktop 通过 Electron 网络栈携带自己的 Cookie Jar 连接本地 Host。

第一段请求没有携带 Electron 内保存的全部历史 Cookie，所以网页可以正常显示认证成功。第二段请求会为 127.0.0.1 带上符合路径和域规则的 Cookie；这些 Cookie 的名称虽然编码了不同端口，Cookie 作用域却按主机匹配。最终所有旧端口留下的认证数据被一起送往当前随机端口。

这就造成了看似矛盾的现象：账号、验证码和网页认证都正常，Desktop 仍在 Welcome 阶段报告认证失败。错误文字描述了失败位置，没有呈现底层的 431 原因。

71 枚 Cookie 如何越过 16 KiB

社区复现指出，认证 Cookie 名由 127.0.0.1:<port> 的哈希生成，每枚约 227 字节，并设置三天 Max-Age。频繁重启 Host、安装或卸载插件会产生新的随机 GUI 端口，旧 Cookie 在有效期内持续累积。

案例中共有 71 枚相关 Cookie，粗略体积达到 16.1 KiB，已经逼近 Node 默认 16,384 字节的请求头限制。实际请求还包括 Cookie 分隔符和其他 Header，因此服务端返回 HTTP 431。此后每次启动都复用同一 Cookie Jar，故障便从偶发积累变成稳定崩溃。

重新安装应用通常不会清除用户数据目录中的 Electron Network Cookies；单纯重启也只会再尝试同一请求。这解释了为什么两种常见恢复动作都无效。

如何确认是同一条故障链

排查时可以核对以下信号：

  • Desktop 版本为 rc.3，且近期频繁重启 Host 或操作插件；
  • 主进程日志稳定停在 desktop welcome: Web authentication failed；
  • Web 端认证可以完成，随后 Desktop 立即退出；
  • 本地 Host 返回 431，或请求 Cookie Header 已接近 16 KiB；
  • Electron Cookie 存储中存在大量面向 127.0.0.1 的 dsh-auth-* 项。

若没有 431 或 Cookie 体积证据，仍应检查系统时间、代理、账户状态和连接错误，不能把所有 Welcome 失败都归到这一案例。

恢复动作要精确限定范围

社区报告通过在应用完全退出后清理匹配 host_key='127.0.0.1' 且名称为 dsh-auth-* 的 71 条 Cookie 恢复启动。这个结果验证了根因，但用户不应在应用运行时直接编辑 SQLite 数据库，也不应删除整个 Desktop 数据目录。

安全顺序是：

  1. 完全退出 DSH Desktop，确认相关进程已结束；
  2. 备份 Desktop 的 Network/Cookies 数据库；
  3. 优先使用产品提供的登录状态重置或 Cookie 清理入口；
  4. 只有在明确确认 431 与目标 Cookie 后，才处理限定的 127.0.0.1、dsh-auth-* 记录；
  5. 重启后重新认证，并检查 Session、Profile 和 Workspace 是否仍在；
  6. 保留日志与 Cookie 数量，便于向上游提交可复现信息。

直接清空整个用户数据目录会连带影响其他状态，扩大恢复成本。

产品如何避免再次积累

修复可以从生命周期和认证设计两端推进：

  • 新端口启动成功后，删除同一主机的旧端口认证 Cookie；
  • 缩短本地一次性 Cookie 的有效期，并限制保留数量；
  • 将端口放入 Cookie 值或服务端会话映射，避免每个端口生成新名称；
  • 启动前测量 Cookie Header，接近上限时主动清理并展示原因；
  • 把 HTTP 431 映射为“本地认证 Cookie 过多”，不要只显示 Web authentication failed；
  • 对随机端口重启、插件反复启停和跨版本升级编写压力测试。

对普通用户而言，这也是一个可辨认的边界：Web 登录成功只能证明浏览器认证完成，Desktop 仍有独立的本地连接和 Cookie 状态。将两段链路分别记录，才能快速定位启动故障。

参考资料

常见问题

重装 Desktop 为什么没有恢复？

应用安装目录和 Electron 用户数据目录是两套状态。重装可能保留 Network Cookie 数据库，过大的请求头仍会在下一次启动时出现。

网页已经显示登录成功，为什么还会提示认证失败？

网页认证与 Desktop Welcome 使用不同的网络客户端。后者携带 Electron Cookie Jar，可能因历史 Cookie 过多收到 431。

可以直接删除整个 Cookies 文件吗？

先备份，并优先采用产品提供的重置入口。若必须处理数据库，应只针对已经确认的本地 DSH 认证记录，避免扩大影响范围。