在多个中转站和多把密钥之间自动故障转移与负载均衡#

ThinkWatch Lite 把每个中转站的每把密钥建成一个上游，再把多个上游放进一个策略组。路由规则把请求转发至策略组，由策略决定成员的先后；某个上游在回答开始之前失败时，网关把请求交给下一个上游，客户端不会看到这次错误。提示缓存值得保留时，同一段对话继续使用上次回答它的上游。

准备#

• 已安装 ThinkWatch Lite，并已在客户端页接管客户端。本文按 2026.10.11 版编写。
• 各中转站的接口地址和 API 密钥。

步骤#

1. 在上游页选择「新建上游」，在「服务类型」中选择服务（中转站在「平台与中转」中选择对应的服务，或选「自定义」）。在「连接」中填写「名称」和一把「API 密钥」，服务要求时再填写「接口地址」，再依次选择「下一步」直到「创建」，第一次「下一步」时检测连接。每把密钥重复一次：一个上游只有一把密钥，故障转移和暂停都以上游为单位。
2. 在路由页的「策略组」标签中选择「新建策略组」。填写「名称」，选择「策略」，在「成员」中勾选上游并拖动排序，然后选择「创建」。策略为「轮询」时，还要填写每个成员的「权重」并选择「分配依据」。
3. 在「路由」标签中打开路由，对要使用该策略组的规则选择「编辑…」（通常是「全部请求（兜底）」那一条），在「转发至」中选择该策略组，并在两个对话框中各选择一次「保存」。
4. 「试算」可以检查结果，不会发出请求。在流量页打开请求，「路由」标签的「尝试链」列出尝试过的每个上游。

说明#

策略只决定顺序，所有成员都留作故障转移的后备。

• **何时换到下一个上游。**在尚未向客户端发出任何内容时，上游出现以下情况，网关即改用下一个成员：无法连接或读不到它的凭据；返回 5xx、429、401、403、402 或 404；返回 400 或 422，且错误信息说明余额不足、额度用完或模型不可用；流式回答在第一段内容之前报错，例如过载；在无响应超时内没有发出内容。其他 4xx，以及最后一个成员返回的 4xx（429 除外），原样返回客户端。
• 权重与分配依据。「轮询」策略组中，成员的权重（1 到 100）就是它长期分到的请求比例：权重 7 与 3 时，每十个请求中七个交给前者，与另外三个交错分配。「按比例」只看权重；「按速度」再乘以该上游开始回答比成员中位数快多少（首 token 时间之比的平方，限定在 0.1 到 10 之间）；「按稳定性」再乘以它 30 分钟内最近 50 次结果的成功率（取平方，最低 0.05）；「按速度和稳定性」两者都乘。样本不足的上游按平均水平计算；因对话延续而留在某个上游的请求计入它的份额；暂停中或并发已满的成员本轮不参与。
• **无响应。**上游连续「设置 › 故障转移」中的「无响应超时」（默认 300 秒，可设 30 到 3,600 秒）没有发出内容时，网关放弃这个上游。只有内容才计入：文字、推理或工具调用，保活心跳不算。计时从请求发给这个上游时开始，等待空位的时间不计入，每收到一段内容重新计时。尚未向客户端发出内容时，请求转到下一个上游，没有响应的上游计一次失败，按暂停规则处理；没有可用的上游时，客户端收到其自身格式的超时错误。回答已经开始时，以客户端能识别的错误事件结束。非流式回答同样最多等待这么久。流式回答最多压住 15 秒，此后客户端先收到响应头和保活注释（Gemini 客户端只收到响应头），因此不会在网关仍可转到下一个上游时自行放弃。没有响应的上游，首 token 时间按等待的全部时长记录，「延迟最低」与「按速度」因此把它排到后面。请求的「路由」标签把这次尝试标为「无响应超时 · 300 秒」，并标出上游可能已计费的输入。长时间思考而不发出任何内容的模型，可能需要更长的超时。
• **并发上限。**设置了「并发上限」的上游同时最多接收这么多请求。上游已满时，留在它上面的对话等待空位，等不到再换下一个，其他请求直接交给下一个成员；所有成员都满时，请求等待最先空出的位置，最长为「设置 › 故障转移」中的「最多等待空位」（默认 30 秒），仍无空位则返回 429 并带 Retry-After；此前已有尝试发出时，返回那次尝试的错误。密钥的分钟、小时用量上限共用这段等待；流量页会标出每一次跳过和排队时间。
• **暂停。**失败的上游按「设置 › 故障转移」暂停使用，默认值为：「连续失败」3 次后暂停 60 秒，此后每次加倍，最长 600 秒；「余额不足」暂停 30 分钟；「额度用完」暂停到重置时刻，未给出时暂停 60 分钟；「限流」按上游要求的等待时间暂停，最长 60 分钟。只有一个上游的规则不受暂停影响；所有成员都在暂停时，网关仍会逐个尝试。在流量页手动中止的请求不计入上游的失败。
• **会话与提示缓存。**同一轮之内（客户端回传工具结果期间），请求沿用这一轮开头确定的规则和回答它的上游。跨轮时，如果上次回答在五分钟以内、且读写了至少 1,024 个缓存 token，对话继续使用该上游，因为换到别处要按全价重建缓存；否则，或者该上游正在暂停时，由策略重新排序，「轮询」正是在这时轮到下一个成员。请求「路由」标签中的「对话延续」一行说明请求是否因此留在原上游。
• **模型名相同。**每个成员收到的都是客户端请求的模型名，或者规则改写之后的模型名。模型列表中没有该模型的成员会被跳过；没有模型列表的成员照常尝试，它返回 404 时请求换到下一个。成员能服务、却没有列进模型列表的模型，可以在上游页该成员的模型列表中选择「添加模型…」加上，也可以在它的编辑对话框的「模型」一节中添加。
• **回退到另一个模型。**添加一条规则：条件「选定上游」选择后备上游，「命中后」选择「继续匹配」，在「改写参数」的「模型改为」中填写它的模型。这样的规则在每次选定上游之后判断，故障转移之后同样适用。更换模型后已缓存的 prompt 不再命中，费用按发出的模型名计算。

相关文档：切换中转站、上游或模型，无需重启 Claude Code 与 Codex、功能详解、安装与更新。