桌面版启动约 72 次后打不开：dsh-auth-* cookie 每次启动多存一条，Cookie 头涨过 16 KiB 后被 431 拒绝

[xian-yun-qing-cheng]

桌面版 DSH 每次启动新建一个不同名字的本地 cookie，约 72 次后打不开（HTTP 431）

• 版本：DSH Desktop 0.2.2-rc.1（Windows，安装在 C:\Deepseek Har）
• 日期：2026-11-11
• 提交人环境：Windows 11，单机日常使用，30 天内启动约 70+ 次（实测 5 天 64 次）

现象

用同一份配置启动约 70 多次之后，DSH 桌面版彻底打不开：窗口起来但界面加载失败，本地服务返回
431 Request Header Fields Too Large。删掉 cookie 库后立刻恢复，之后从 0 重新累积。

根因

DSH 桌面版在每次启动时给本地服务（127.0.0.1，端口每次启动随机）下发一条新的登录 cookie：

name        = dsh-auth-<30 位随机串>     ← 每次启动名字都不同
path        = /
HttpOnly    = 1
persistent  = 1（带 expires）
value       ≈ 171~173 字节
source_port = 每次启动的随机端口，64 条里 64 个不同的值

Chromium 的 Cookie 唯一索引是：

CREATE UNIQUE INDEX cookies_unique_index ON cookies(
  host_key, top_frame_site_key, has_cross_site_ancestor,
  name, path, source_scheme, source_port);

名字每次都变、端口每次都变，所以任何两条都不会撞键，旧记录永远不会被覆盖，库里的行数单调增长。
每条占 Cookie 请求头约 227 字节；Node 的 http 默认 maxHeaderSize 是 16 KiB，于是：

72 × 227 B ≈ 16.3 KB → 请求头超限 → 431

实测数据（2026-11-11 21:21，清空前）

host         rows   bytes   oldest              newest
127.0.0.1      64   14516   2026-11-06 19:12:52  2026-11-11 20:57:07

• 64 条，host_key 全是 127.0.0.1，name 64 个全不相同，source_port 64 个全不相同
• Cookie 头合计 14516 字节 = 16 KiB 上限的 88.6%
• 平均 227 字节/条，5 天 64 条 ≈ 12.8 次/天，因此这台机器约 5~6 天就会撞墙，不是 30 天

影响

撞到 431 之后，普通用户看到的现象就是“DSH 永远打不开”，而且：

1. 界面里没有任何提示说明是 cookie 太多；
2. cookie 库在运行期间被独占锁住（Copy-Item、FileShare::ReadWrite、esentutl /y 全部 sharing violation），不彻底退出进程就连备份都做不了；
3. 唯一自救办法是彻底退出后删库，等于丢掉所有 webview 登录。

建议（任一即可）

1. 别把端口写进 cookie 身份里：现在的名字是 dsh-auth- + sha256(authority)，而 Host 用
   --port 0 启动、端口每次不同，于是每次启动都是一条新 cookie。如果 authority 只用于绑定
   签名、不用于区分 cookie 身份，可以让 cookie 名固定、把 authority 放进签名载荷；
2. 或把这条 cookie 设为 session cookie（不写盘），它本来就是每次启动重新签发的；
3. 或换票时顺手让旧的 dsh-auth-* 过期：在 303 那条响应里追加
   Set-Cookie: <旧名>=; Max-Age=0; Path=/; HttpOnly; SameSite=Strict（这条能被插件做到，
   但由官方做更干净）；
4. 附带建议：启动时如果发现 dsh-auth-* 行数/头部大小超阈值，主动清理一条并给可读提示，
   而不是让用户只看到 431；16 KiB 是 Node 解析器层的默认值，超过之后任何 handler（包括
   DSH 自己的）都不会运行，所以提示只能从「更早一步」发出。

附：本地绕过（仅供理解现象，不是修复）

启动前把 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies 里 dsh-auth-* 的旧行裁掉
（只留最新几条），每次启动前跑一次即可永不撞墙 —— 但这只是绕过，行数仍会继续增长。

[5777-wq]

独立复现 + 两点补充证据（0.2.2-rc.1 → 0.2.2-rc.2，Windows x64）：

1. 症状签名与帖内机制吻合，并补一个定位细节

同一晚三次确定性启动失败（UTC 13:48:12 / 13:48:21 / 13:56:03，crash-*-host.log），错误均为：

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (lib/main.js:16856:31)  // if (!authenticated.ok) throw

细节：启动序列里第一步 authenticateWebHost（Node 原生 fetch，redirect: "manual"，期待 303+Set-Cookie）是成功的——本地服务本身在正常应答；失败的是第二步 net.fetch(ready.url, { credentials: "include" })，即带 Cookie jar 的那一路返回非 2xx。这与「Cookie 头超限 → 431」完全自洽：不带 jar 的裸请求不受影响，带 jar 的请求超 16 KiB 被拒。

2. rc.2 旁证已含修复

未清理 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（同一份已积累的 cookie 库），直接升级 0.2.2-rc.2 后启动正常。若官方确认 rc.2 已包含 93bef27（或等效修复），#12953 可以关单了。

备注：当晚机器上还叠加了 #9994 的完整性标签复发（两个问题同时在场，症状互相掩护，容易误判方向），留此记录供后来人对症。

[xian-yun-qing-cheng]

再补一个反例：rc.2 装上了但起不来，已经回退 rc.1。

环境：Windows x64，Electron 44.7.0，Node 24.21.0，zh-CN；profile 里有自定义 bundle（command-guard、browser-skill、computer-use、cookie-sweep 等），profile 的 @deepseek-ai/* 依赖是 0.2.2-rc.1。

升级到 0.2.2-rc.2 后每次启动都失败（三次，其中一次点了「禁用第三方插件」），错误一致：

DesktopHostFatalError: dsh: startup failed: 1 required plugin did not activate

Plugins waiting for services (18):
  webserver (required)      webStartup
  ...

crash 日志里对得上的是：

• include:webserver（@deepseek-ai/dsh-host-webserver）：pending，missing ["webStartup"]，version 0.2.2-rc.1；
• 提供者 include:web-startup（@deepseek-ai/dsh-web-app/startup）：disabled，version 0.2.2-rc.1。

也就是组合是 rc.2 的 app + rc.1 的 profile 包，web-startup 没挂上，必需的 webserver 一直等。禁用第三方插件后等待列表从 18 个降到 14 个，但仍然死在同一个 webStartup，所以不是第三方插件不兼容。

想确认两点：

1. 从 rc.1 升级到 rc.2，profile 里的 @deepseek-ai/* 是否需要手动升到 0.2.2-rc.2 再 pnpm install？桌面端本应自动做这一步吗（这台机器上升级后 package.json 里依赖仍是 rc.1）？
2. 如果升级路径确实有这个问题，rc.2 的 15% 灰度是否就是在挡它？

回退 0.2.2-rc.1 后一切正常。需要的话我可以把三次 crash 日志（crash-2026-11-12T05-20-19-237Z-host.log 等）整理出来。