DeepSeek Harness 账号资料卡显示不可用：带与不带 WAF cookie 的对照

「账号资料暂不可用」，但下面余额 ¥32.74 好好地显示着——这个组合本身就排除了账号问题。 资料查询与余额查询打的是两个不同端点，只有前者被边缘 WAF 间歇拦住（#11016）。三组请求对照把差别缩到了一个 cookie 上。

DeepSeek Harness 实验一：同一路径，换 User-Agent

不带浏览器 UA 时，请求可能被 CloudFront 直接挡住。

1. 用 node 作为 UA 请求资料接口：curl -A node https://platform.deepseek.com/auth-api/v0/users/current。
2. 报告者在 15:51Z 观察到 403，响应是 CloudFront 的「Request blocked」。
3. 同一台机器、同一 UA，在 16:55Z 变成 200，body 是 {"code":40002,"msg":"Missing Token"}——说明边缘行为本身在变。
4. 换成浏览器 UA 再请求，返回 202，并带 x-amzn-waf-action: challenge。
5. 结论：这一步只是「被挑战」，还不是通过。

DSH插件 实验二：同机对照余额端点

余额端点没有这层挑战，所以它能正常返回。

1. 请求 https://platform.deepseek.com/api/v0/users/get_user_summary。
2. 即使不带凭据也返回 200，body 是 {"code":40002,"msg":"Missing Token"}。
3. 说明这条路径不经过 WAF 挑战。
4. 于是「余额正常、资料不可用」成为可解释现象，而不是矛盾。
5. 这一步也顺带排除了「整站不可达」这类猜测。

DeepSeek Harness 实验三：带上 WebView 的 aws-waf-token

同一请求、同样头，只多一个 WAF cookie，就从不通过变成 200。

1. 登录弹窗是在 WebView 里完成的，之后 WebKit 的 cookie 存储里就有 .deepseek.com 的 aws-waf-token。
2. 也就是说：挑战其实已经通过过，凭据就在 WebView 里。
3. 但宿主进程发请求时没有带上它，所以每次都要重新被挑战一次。
4. 这是整条链上唯一缺的东西。
5. 因此「转发这个 cookie（含过期与刷新处理）」或「在渲染进程的浏览器上下文里读取账号信息」都能让资料稳定返回。

DeepSeek插件 为什么 UI 看起来像坏了

失败态与「资料里没有联系人」被渲染成同一句话，而且没有重试入口。

1. 状态判断是 profile?.contact ?? (details.profile === undefined ? 'loading' : 'profileUnavailable')。
2. 于是 { status: 'failed' } 与 contact: null 都显示成「账号资料暂不可用」。
3. lastProfile 只存在内存里，每次启动都是空缓存。
4. 结果就是：启动后先显示占位，第一次拉取失败就一直占位。
5. 报告者建议区分「读取失败」与「没有联系人」，并给一个重试按钮。

DeepSeek Harness 对照结论与处置建议

这不是账号被限制，是宿主请求缺少边缘挑战凭据；能改的层在请求侧与 UI 侧。

1. 请求侧：把 WebView 已有的 aws-waf-token 转发给宿主请求，并处理过期与刷新。
2. 或者：把账号资料读取放到渲染进程的浏览器上下文里执行。
3. 错误分类：把 403 / 202 归为「WAF 挑战失败」，而不是 network，方便用户与支持判断。
4. UI 侧：失败态给独立文案与重试按钮；缓存改为持久化（仍绑定授权令牌）。
5. 不要在客户端尝试绕过 WAF，报告者明确表示不寻求这种方案。

DSH插件 一分钟判定：是不是这一条

三个特征同时出现，基本可以收工：余额正常、资料不可用、过一段时间自己恢复。

1. 看余额：能显示说明授权与网络都通。
2. 看资料：不可用但文案是「暂不可用」而不是「未登录」。
3. 看时间：等十分钟到一小时再打开，可能自己回来。
4. 看登录：重新登录能短暂恢复，但过一阵又出现。
5. 三条以上命中，就不要再查账号状态了。

如果你要报问题

给维护者的信息越具体，越容易定位到请求侧。

1. 附上资料接口的响应码与响应头，尤其是 x-amzn-waf-action。
2. 说明同一时刻余额接口是否正常。
3. 说明客户端版本与平台（桌面端还是 Web）。
4. 注明是否在 WebView 里登录过、cookie 里是否有 aws-waf-token。
5. 不要附带账号标识、令牌或任何凭据。

注意事项

1. 别把余额正常当成账号健康的全部证据。两个端点走不同路径。
2. 别急着重装或重新登录。报告者的资料在一小时后自行恢复。
3. 登录要点多次也同源。auth_init 同样会遇到 202 挑战。
4. 别把 WAF cookie 当作可长期保存的凭据。它有有效期，需要刷新逻辑。
5. 报问题时带上响应头。x-amzn-waf-action 比错误文案更能说明问题。

如果你的资料卡是「一直不可用」而不是偶发，那更可能是登录态问题，先去查授权令牌而不是 WAF。相关排查见 DeepSeek Harness 报「获取可用模型」401：API Key 或 Base URL 不匹配的修复。