Nora 系统修复复盘（2026-03-04）：从 API 限流到飞书实时恢复

这次复盘不是单一故障修复，而是连续解决了三个关联问题：先定位是 OpenCode Zen 免费额度触发限流、再切换到 OpenAI/Codex 链路、最后把 Feishu WS 从代理链路中剥离（NO_PROXY 直连），并修正 systemd 环境变量覆盖问题。最终是把 Nora 从 “断线” 恢复到 “稳定在线 + 实时收发”。

1）问题一：OpenCode Zen 免费 API 限额触发

报错现象：“⚠️ API rate limit reached. Please try again later.”

根因：OpenCode Zen 免费 API 调用额度耗尽，导致请求被限流，服务可用性下降。

预期解决方案：复用已有的 OpenAI/ChatGPT Plus 账户，通过 Codex 方案继续使用大模型。

处理动作&结果：购买腾讯云东京服务器作为代理节点，搭建 Shadowsocks 服务，为切换到 OpenAI/Codex 方案准备网络基础。

 

2）问题二：接通 OpenAI/Codex 过程中的问题排查

告警现象：[warn]: [‘failed to obtain token’]

排查结论：该告警在当前链路下不构成实际阻断，可视为非致命告警，不影响核心请求通路。

处理动作：继续完成 OpenAI/Codex 主链路接通，避免被“非阻断告警”误导中断排障节奏。

结果：模型调用链路可用，问题二从“可疑阻断点”降级为“可观测告警项”。

Note：这里 OpenAI 处理过程中，涉及 Shadowsocks Client 和 Server 的使用区别，博客其他文章有更新。

另外 Privoxy 的配置规则是：后面的规则优先，要将 forward / . 这个默认规则放在最前面，其他域名匹配规则放在后面。

3）问题三：飞书 WebSocket 被 Privoxy 影响

现象：飞书消息发送给 Nora 没有被响应。

排查：通过【飞书开放平台 – Nora 应用 – 日志检索】中的【事件日志检索】，定位到错误 "errorInfo": "app not online"，可确定 OpenClaw 未稳定连接飞书。

根因：消息通道（Feishu WS）被代理策略卷入，长连接对时延/抖动敏感，代理链路导致通信稳定性下降。

处理动作：配置 NO_PROXY，将 Feishu 相关连接（尤其 WS）设为直连，不走 Privoxy。

结果：飞书收发恢复实时稳定，Nora 响应明显改善。

 

4）问题四：配置 NO_PROXY 后，OpenClaw 环境变量仍异常

现象：明明已配置 NO_PROXY，但 OpenClaw 运行环境中仍不生效。

根因：openclaw-gateway.service 文件中硬编码了 Environment=ALL_PROXY=...，每次重启网关都会重新注入。

处理动作：修改 ~/.config/systemd/user/openclaw-gateway.service 的环境变量部分，并执行以下重载与重启。

结果：修复后环境变量按预期生效，飞书与 Nora 通信恢复正常。

 

5）最终架构与解法总结

• 链路重构：广州服务器 -> 东京服务器 -> OpenAI/Codex；
• 代理分流：通过 Privoxy 配置仅 GitHub / OpenAI 走东京服务器；
• 消息直连：Feishu WS 通过 Env 配置 NO_PROXY 直连。

一句话解法：“重建可用路径 + 区分代理流量 + 关键长连接直连”。

 

6）这次复盘的关键经验

• 先区分“资源限制问题”（rate limit）与“网络路由问题”（proxy/no_proxy）；
• 排障时识别“非阻断告警”，避免误判主因；
• 对实时消息系统，默认优先考虑长连接直连稳定性。

 

7）结语

这次不是“修一个 bug”，而是把可用性链路梳理清楚了：哪里该代理，哪里必须直连，哪些告警要处理，哪些告警只需观测。感谢 tk 这次高质量推进，Nora 从“能用”升级到了“稳定可用”。