桌面端反复启动后 Web 认证失效：dsh-auth-* Cookie 随随机端口累积，请求头超 16 KiB 被 431 拒绝

[Zhang-Lingge]

环境

项	值
应用	DeepSeek Harness 桌面端 0.2.1-rc.2（Windows x64）
内置 dsh	@deepseek-ai/dsh 0.2.1-rc.2
Electron / Node / Chromium	44.7.0 / 24.21.0 / 152.0.7977.130
操作系统	Windows 11 家庭版 中文版，build 26200
安装形态	每用户安装（InstallLocation 可自定义）

现象

桌面端使用若干天后，重新打开时窗口报 "Web authentication failed"，界面无法加载。

此时：

• 登录状态并未过期（账号余额、凭据均正常）；
• 手工会话仍可正常完成 303 握手，Set-Cookie 也正确下发；
• 但带 Cookie 的后续请求被 Host 直接以 HTTP 431 Request Header Fields Too Large 拒绝。

也就是说：不是鉴权失败，是请求头在进入鉴权逻辑之前就被 HTTP 解析器拒掉了。

根因

@deepseek-ai/dsh-client-connection 的浏览器会话 Cookie 名称由完整的 authority（含端口） 派生：

// lib/types/browser-auth.js
const COOKIE_PREFIX = "dsh-auth-";
const DAY_MILLISECONDS = 1440 * 60 * 1e3;

function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

function sessionCookie(name, value, expiresAt, maxAgeSeconds, secure) {
  const attributes =
    `${name}=${value}; Max-Age=${String(maxAgeSeconds)}; Path=/; ` +
    `Expires=${new Date(expiresAt).toUTCString()}; HttpOnly; SameSite=Strict`;
  return secure ? `${attributes}; Secure` : attributes;
}

• 桌面端 Host 每次启动都绑定一个新的临时端口（--port 0），因此 authority（127.0.0.1:<port>）每次都变；
• Cookie 名是 authority 的 SHA-256，端口一变名字就变，浏览器只会新增而不会覆盖；
• 生命周期由 cookieMaxAgeDays 决定，默认 30 天：

const Config = z.object({
  recovery: ConnectionRecoveryConfigSchema.default({}),
  trustedHosts: z.array(String).default([]),
  cookieMaxAgeDays: z.natural().min(1).default(30),   // ← 默认 30 天
  maxRequestBodyBytes: z.natural().min(1).default(DEFAULT_MAX_REQUEST_BODY_BYTES)
});

• Cookie 属性为 Path=/、HttpOnly、SameSite=Strict，没有 Domain（host-only），因此 127.0.0.1 上的所有端口共用同一个 Cookie 罐；
• 没有任何清理逻辑：旧端口对应的 Cookie 会一直留在浏览器里直到自然过期。

于是 Cookie 罐里 127.0.0.1 下的 dsh-auth-* 条目单调增长，最终 Cookie 请求头超过 Node HTTP 服务端默认的 --max-http-header-size = 16384 字节，Host 在解析阶段就返回 431。

量化证据

实测 Cookie 库（%APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies）：

指标	值
总 Cookie 数	71
其中 dsh-auth-* / host_key=127.0.0.1	71（100%）
Cookie 名总长	3692 字节
Cookie 值总长	12179 字节
请求头体积（name + value + 2/条）	16013 字节
已过期条目	0
TTL	全部 720 小时（= 30 天）

单条 52（名）+ 171（值）+ 2 ≈ 225 字节；16384 / 225 ≈ 72.6，即约第 72 条就会越界。

阈值实测（手工启动 Host，逐步增大 Cookie 头）：

Cookie 请求头	Host 响应
15231 字节	200
16231 字节	200
16531 字节	431

边界正好跨过 16384，确认为 Node 默认头部上限，而非鉴权逻辑。

复现

1. 全新环境打开桌面端，记录 Network/Cookies 中的 dsh-auth-* 数量；
2. 反复关闭并重新打开桌面端 N 次；
3. 每次启动都会新增一条 dsh-auth-*（名字不同，端口不同），旧条目不被清理；
4. 累计约 72 条后，窗口报 "Web authentication failed"，Host 返回 431。

按本机实际使用频率（6 天 71 条 ≈ 11.8 次/天），约 6 天即可复现。

建议修复（按推荐度）

1. 客户端启动时清理陈旧 authority 的 Cookie（推荐）

修复应落在 Electron 主进程（dsh-desktop-host），而不是 Host 服务端——服务端无法删除浏览器 Cookie 罐里的条目，主进程可以：

const { session } = require('electron')
const jar = session.defaultSession
const current = `dsh-auth-${encodeBase64Url(sha256(`127.0.0.1:${port}`))}`
const stale = (await jar.cookies.get({ domain: '127.0.0.1' }))
  .filter((c) => c.name.startsWith('dsh-auth-') && c.name !== current)
for (const c of stale) {
  await jar.cookies.remove(`http://127.0.0.1${c.path}`, c.name)
}

在 app.whenReady() 之后、创建窗口之前执行一次即可根治，且不影响安全模型（端口仍然参与 Cookie 名与签名 audience，防止其他本地服务复用）。

2. 让 cookieMaxAgeDays 的默认值与失效速度匹配

30 天的有效期对一次性会话凭据明显过长。默认降到 1–3 天可把稳态条目数压到 12–36 条（约 2.7–8 KB），留足余量。Chromium 会在加载 Cookie 库时清理已过期条目，因此缩短 TTL 能真正限制累积。

3. 提高头部上限

为 Host 显式设置 --max-http-header-size（如 64 KiB）只能推迟问题，且 431 的表现对用户很不友好，建议作为兜底而非主解。

4. 复用稳定端口

若 Host 能落在固定端口，Cookie 名恒定，浏览器会原地覆盖，条目恒为 1 条。但 WebServer.Config 中 port 为必填且无回退值，端口被占用时会导致启动失败，因此不建议作为默认策略。

已采用的临时规避

1. 从 Network/Cookies 删除 host_key='127.0.0.1' AND name LIKE 'dsh-auth-%' 的行（应用必须完全退出，删除前备份）；
2. 在 ~/.dsh/profiles/desktop/cordis.patch.yml 覆盖 connection 行，把 cookieMaxAgeDays 降到 3：

- id: connection
  name: "@deepseek-ai/dsh-client-connection"
  config:
    cookieMaxAgeDays: 3

已验证该覆盖进入组合结果（--dump-config 中 config.cookieMaxAgeDays: 3）并能正常启动。

附：诊断线索

• 故障时窗口提示是 "Web authentication failed"，容易让人误判为登录过期；实际是 431。建议在客户端把 431 单独区分出来并提示"请求头过大"。
• Cookie 值以明文存放在 cookies.value 列（encrypted_value 长度 0），因此体积可直接统计。