[thrasher824]

问题

国际版端点收紧通道校验后，出现两类被混淆的错误：

1. 11-128 request illegal（通道校验失败，displayTips 明确提示“可能不是官方客户端发出”）与 11140 request illegal（账号被上游限制）的 msg 完全相同。现有实现按裸文案 "request illegal" 判定，把 11-128 误判成账号封禁，直接 Disable 健康账号——用户在官方客户端里同一账号可以正常对话，面板却显示 banned。
2. 请求没有会话 ID 时不发送 X-Conversation-ID，国际端点会返回 400 / 11-128（conversation id missing），即 fix(upstream): always send the conversation channel header trio #190 描述的问题。

修复

• 新增 ErrChannelRefused：11-128 判为通道校验失败，不罚账号（无冷却/熔断/错误计数），由轮转继续尝试。
• 11140 改为 code + 文案双条件（IsAccountRestricted）判定，仍走账号限制禁用；禁用提示改为“在 WorkBuddy 提交反馈申诉”，不再误导为重新登录。
• 11140 的模型级限流变体（rate-limiting 文案）保持 ErrSoftRate，不会被误判为账号故障。
• injectConversationHeaders 改为始终发送 X-Conversation-ID：入站带值则透传，否则生成 32 位 hex（与 request/message ID 的兜底同口径）。
• 补充分类/策略回归测试与会话头 wire-level 测试。

验证

• go build ./...、go test ./internal/upstream ./internal/server 通过。
• 实机：4 个国际版账号逐一强制路由实测，均返回 HTTP 200；/v1/chat/completions 与 /v1/messages 均正常。
• 修复前：同一请求对 4 个账号全部返回 400 / 11-128，且健康账号被误禁用；修复后账号池 4 个账号全部可用。

关联

• Closes trae自定义模型添加国际版模型global:deepseek-v4.1-flash失败 #187
• Closes 被拦截了 #188
• Closes fix(upstream): always send the conversation channel header trio #190

账号池实机截图（4 个账号全部可用）请见 PR 讨论区。

[thrasher824]

[misakano7545]

这个 PR 里两处修复我们 fork 上都已经有了，而且实现比这里更完整，所以没有整条合入（整条合会把这些更完整的部分降级掉）。只取了唯一有增量的一行。

逐项核对

1. 11-128 与 11140 分流 —— 已有，且更细

internal/server/handler.go（本仓）在 applyErrorPolicy 里按 code 三分：

body	处置
"request illegal" + 11-128	软冷却（channel verification blocked），不罚号
"request illegal" + 11140	硬禁用
14017	软冷却（trial 未激活，补完 register 后可自愈）

PR 把 11-128 移到 Classify 里判 ErrChannelRefused，功能等价，但 14017 这一档本仓单独处理了——合过来会丢。

已有回归用例：TestApplyErrorPolicyChannelVerificationKeepsAccount（11-128 不得永久禁用）、TestApplyErrorPolicyAuthForbiddenStillDisables（11140 仍硬禁用）。

2. X-Conversation-ID 始终发送 —— 已有，且多一层

internal/upstream/headers.go:injectConversationHeaders 的三路兜底：

1. 入站带值 → 透传
2. 有会话但没 ID → buildCacheKey(uid, src)（带 uid 段，防止同一客户端会话打在不同账号上共用同一个上游缓存槽）
3. 零值 ChatMeta（夜猫子对话、面板模型任务）→ 现造 32 hex

PR 的版本是「透传 or 生成 32 hex」，少了第 2 路，合并会退掉缓存槽隔离。

3. 11140 禁用提示文案 —— 唯一增量，已采纳

- account banned by upstream (11140 request illegal), re-login required
+ account restricted by upstream (11140 request illegal);
+ appeal in WorkBuddy (submit feedback) to lift the restriction

re-login required 确实是误导：11140 重登无效，只能申诉。这一行已单独提交（internal/server/handler.go），go build + internal/server、internal/upstream 测试通过。

建议

这个 PR 可以关掉了——两处功能修复在本 fork 已存在，剩下的一行文案已落地。如果上游要合，PR 本身对上游是有效的（上游还没这两处）。

[linguo2625469]

已合并（2d9e749），但合并时发现并修复了一个关键问题（d809396）：

你的提交里业务码字面量是 "11-128"（缺连字符，字节 49 49 49 50 56），实现与测试体的码值是同一个写法——双方自洽所以 go test 全绿，但上游真实业务码是 "11-128"（带连字符，见 #197 的真实响应体）。线上 isChannelRefused 永远命中不了，11-128 会落到 ErrClient：不罚号（核心痛点已解决），但通道拒绝的分流语义（hint、错误码、专门文案）全部失效。

已修正实现与全部测试体，并新增 TestClassifyRealChannelRefusedBody——业务码用字节构造（string([]rune{49,49,45,49,50,56})），不依赖手打字面量，专门防止「实现和测试一起写错」再次通过。

提醒：这类「测试与实现同错」的自洽盲区，建议本地验证时用 issue 里贴的原样响应体跑一次分类，而不是只看测试绿灯。多谢这份贡献，分流设计本身是对的。