本地 API 代理看起来恢复以后，我又检查了切换器、客户端配置和进程重载，最后用一条真实请求确认首段输出。
local-sub2api/recovery-workflow
本地 API 服务坏掉时，最容易做的事是反复看容器状态。
容器在跑，健康检查是绿的，端口也能访问，于是很自然地以为问题已经修好了。不过接入客户端后，还是可能继续报错。原因通常不是“服务没启动”，而是整条本地链路里有一段没有对齐。
我现在处理这种问题，会把“服务活着”和“客户端真的能用”分开验证。
容器健康只是第一层
本地服务恢复的第一步当然是看运行时：
- 容器是否启动。
- 端口是否监听。
- 健康检查是否返回正常。
- 日志里有没有启动失败或迁移错误。
这些检查能排除最低级的问题，但客户端实际调用时还可能卡在后面的配置或路由上。
很多本地代理服务的真实链路是这样的：
client -> switcher -> local provider config -> local API service -> upstream account容器只覆盖其中一段。只要切换器、客户端配置、密钥、模型名或进程重载有一处没同步，健康检查再绿也没用。
配置要看两边
本地代理常常同时有两套配置：
- 客户端自己的 provider 配置。
- 切换器或路由工具保存的 provider 状态。
修复时只改其中一边，很容易出现“配置文件看着对，但实际请求还走旧地址”的问题。尤其是已经运行中的客户端进程，未必会热加载新配置。
所以我会检查三件事：
- 当前选中的 provider 是不是本地 provider。
- provider 的地址和密钥是否与本地服务一致。
- 需要重启的客户端进程是否真的重启过。
这里别靠印象。配置路径、当前 provider 名称、实际 base URL 都要明确看一遍。
先复现用户报错的接口
如果用户报的是某个真实接口失败，我会先把这个接口复现出来，健康检查只作为背景信息。
比如真实请求走的是响应接口，健康检查只说明服务能回答一个简单状态；响应接口还会经过模型路由、账号选择、上游连接和流式输出。这些路径都可能出错。
我的做法是直接构造一条最小真实请求：
- 输入尽量短。
- 输出要求固定。
- 不依赖复杂上下文。
- 只验证链路能否走通。
这样失败时日志更干净，成功时也更容易确认结果不是偶然。
首段输出是很好的验收信号
对流式 API 来说，最后状态码不够。最影响体验的是第一段输出什么时候出现，以及内容是否符合预期。
所以我喜欢用“首段输出”做验收。我会让它返回一个很短的固定结果，再看第一段里有没有预期字符。
这类检查有几个好处：
- 能证明请求进入了真实响应路径。
- 能证明上游账号或模型实际工作。
- 能暴露流式响应卡住的问题。
- 能避免把空响应或错误包装误判成成功。
健康检查只能说明服务还在，首段输出能说明这次调用真的走到了响应路径。
进程重载要当成单独步骤
配置修好了，但旧进程还在，这是本地工具最常见的坑之一。
很多命令行客户端、切换器或后台助手启动后会缓存 provider 列表。你改了配置文件，它不一定马上生效。此时继续测试，只是在验证旧配置。
所以修复流程里要明确写出重载步骤：
write config -> select provider -> restart client -> make real request少了最后两步，很容易以为修好了，其实客户端还在走旧配置。
我现在的恢复清单
遇到本地 API 代理失败，我会按这个顺序做：
- 确认容器或本地进程在跑。
- 访问健康检查，只确认基础服务状态。
- 检查切换器当前 provider。
- 检查客户端 provider 配置。
- 确认地址、密钥和模型名一致。
- 重启需要重载配置的客户端进程。
- 发一条最小真实请求。
- 检查首段输出和服务日志。
这个流程比“重启一下试试”慢一点，但下次再坏时，能少猜很多。
最后还是要跑真实请求
本地工具链的问题往往不是一个大故障，而是一串小状态没有对齐。
容器健康、配置正确、provider 选中、客户端重载、真实请求成功，分别对应不同检查点。把它们都说成“已经修好了”，后面迟早会返工。
对我来说，完成标准很简单：最后必须跑一次真实请求，并看到预期的首段输出。
继续读