“只有我这台超时，别人正常”：一次 OpenClash / 代理故障的边界排查 作者: zhaoyang 更新: 2026年09月10日 1,781 字 约 5 分钟阅读 分类: 系统运维 最近我碰到一个很烦但并不罕见的问题：访问 Codex 会不断超时。 一开始看起来像是节点不稳定。后来又发现，ChatGPT、Gemini、Grok 的表现也不完全一致；有时无痕窗口能打开，登录后又不行；本地开代理能临时恢复，但家里不止一台设备，不能把“我的电脑能用”当成问题已经解决。 <!--more--> 这次排查让我重新认识了一件事： > 代理问题最怕的不是配置复杂，而是还没搞清影响范围，就开始到处改规则。 ## 一开始，我把问题想得太简单了 我的第一反应是：给 Codex 换个节点。 后来发现事情没那么单纯： - Codex 超时，不代表账号额度有问题； - 某个节点“解锁”了，不代表它适合长期跑某个 AI 服务； - 无痕模式短暂正常，也不能直接判定是 Cookie 的锅； - 本地代理恢复，只说明本机绕开了某段链路； - 路由器上的代理恢复，才是真正对全网设备生效的修复。 当时我甚至一度把可用节点收缩到几个地区，结果策略组仍可能回落到一个不合适的出口。表面上看，配置没错；实际上，流量根本没有按我以为的方式走。 问题不在“有没有节点”，而在“这条流量最终走了哪个策略组、哪个节点”。 ## 我后来先画了一条最简单的链路 ```text 浏览器 / Codex 客户端 ↓ 本机网络与 DNS ↓ 路由器规则匹配 ↓ OpenClash 策略组 ↓ 具体代理节点 ↓ 目标服务的登录、接口与长连接 ``` 超时发生在任何一层，前端表现都可能只是“加载很慢”或者“请求超时”。 所以后来我不再盯着某个节点测速，而是先回答几个更有用的问题： 1. 是只有 Codex 不行，还是 ChatGPT、Gemini 也异常？ 2. 是只有我的电脑不行，还是同一网络下其他设备也不行？ 3. 同一台电脑换无痕模式、换登录状态，现象是否变化？ 4. 本地代理能否恢复？如果能，说明问题大概率落在网关侧。 5. 路由器日志里，这条流量实际命中了哪个策略组、最终选了哪个节点？ 这些问题并不直接修复故障，但能把“网络好像有问题”收敛成一个可验证的范围。 ## “本地能用”只是应急，不是修复 后来我临时在本机启用了代理，Codex 能恢复工作。但这只是让我能先把事情做下去，并没有解决根因。 因为网络里不止一台设备。 如果每台电脑、手机、平板都各自配代理，短期确实快，长期一定乱：有人走路由器，有人走本地；有人切了节点，有人没切；问题出现时，连“当前请求经过了哪里”都说不清。 所以我最后还是回到路由器侧处理 iStoreOS / OpenClash。目标不是让某一台电脑恢复，而是让网关重新成为一个可预测的出口。 ## 我把 AI 服务从“大杂烩策略组”里拆了出来 以前最省事的做法，是让所有海外流量进入一个自动选择的策略组。 这种配置平时没问题，但 AI 服务很挑：登录页、接口请求、流式输出、文件上传，可能会经过不同域名和不同连接。一个“测速不错”的节点，也可能在其中某一段不稳定。 这次之后，我单独建立了面向 AI 服务的策略组，把 Codex / OpenAI、Gemini、Grok 等流量从泛用代理组里拆出来。 思路很简单： - 常规海外流量继续走通用策略； - AI 服务走独立策略组； - 独立组内只保留我实际验证过的节点； - 不让它悄悄跳到一个“看起来可用、实际不适配”的出口； - 留一个明确的备用节点，而不是无限依赖自动测速。 这里最关键的不是“哪个地区一定可用”。节点质量、服务策略和网络环境都会变。真正有价值的是：我知道某个服务此刻走哪条规则、哪个组、哪个出口。 ## 无痕模式给我的提醒：别太早认定是浏览器问题 有一次，Gemini 在普通窗口不正常，无痕窗口看起来能访问。直觉上很容易把锅甩给 Cookie 或浏览器缓存。 但继续验证后发现，登录账号后问题又出现了。 这类现象更像一个线索，而不是结论。它至少说明： - 浏览器本地状态可能参与了问题； - 账号登录后的请求链路可能和未登录状态不同； - 但不能因此跳过路由、策略组和出口节点的检查。 我现在会把“普通窗口 / 无痕窗口 / 登录前后”当作对照实验，而不是修复动作。 ## 我现在会这样做一次最小排查 遇到类似超时，我会按这个顺序来： - [ ] 用同一网络下另一台设备测试，先判断是单机还是全网。 - [ ] 对比 Codex、ChatGPT、Gemini 等服务，确认是单服务还是策略层问题。 - [ ] 查看路由器流量日志，确认请求实际命中的规则、策略组和节点。 - [ ] 将目标服务暂时固定到一个已验证节点，排除自动选择带来的变量。 - [ ] 本地代理只作为应急手段，不把它当作网关已经修好的证据。 - [ ] 用登录前后、普通窗口和无痕窗口做交叉测试，判断浏览器状态是否影响结果。 - [ ] 记录“服务—策略组—节点—结果”，下次不用从头猜。 我后来给自己留了一张很小的表： | 服务 | 命中策略组 | 当前出口 | 登录后表现 | 结论 | |---|---|---|---|---| | Codex | AI 独立组 | 已验证节点 | 正常 | 保留 | | ChatGPT | AI 独立组 | 备用节点 | 偶发超时 | 继续观察 | | Gemini | 独立规则 | 指定出口 | 登录后异常 | 检查登录链路与节点适配 | 它不高级，但比“我记得上次好像是这个节点能用”可靠得多。 ## 这次真正留下来的经验 这次故障最后让我放弃了一个习惯：一遇到超时，就去改节点、改全局模式、清缓存、重启服务。 这些动作有时能碰巧解决问题，但很难留下可复用的判断。 现在我更愿意先问一句： > 这次到底是谁坏了——某台设备、某个浏览器、某条规则、某个策略组，还是某个出口节点？ 边界一旦划清，配置通常没那么难改。真正难的是，在“能临时用”和“整个网络恢复稳定”之间，别太早宣布胜利。 标签: 网络技术, OpenClash, 代理配置, 网络故障排查, AI服务, 软路由