请求转圈/超时的定位方法：先分网络侧还是服务端，再逐层排查。
能切换网络（如手机热点）和至少两个浏览器。
用一个简单动作判断问题在哪一层，并按顺序解决，不再盲目重试。
结论先给：第一步永远是做一次对照实验——换个网络（比如切到手机热点）或换个浏览器再试。如果两边都一样转圈，问题多半在服务端，你这边怎么折腾都没用，等一会儿再试即可；如果换了就好，问题在网络或浏览器侧，按下面第二、三层处理。
第一步：一次对照实验
换网络试
从 Wi-Fi 切到手机热点，或反过来，再发一次同样的请求。
换浏览器试
换一个浏览器或开无痕窗口，再试一次。
看结论
两边都转圈 → 服务端侧；只有某一种组合转圈 → 网络或浏览器侧。
第二层：网络侧
- 当前出口不稳定：换成更稳的网络重试。
- 出口类型不合适：部分服务对出口类型敏感，参考 IP 干不干净怎么判断。
- 代理或节点抖动：临时关掉再试，确认是不是它导致的。
第三层：浏览器侧
- 清缓存或换无痕窗口，排除旧的页面状态。
- 禁用可能干扰的扩展（广告拦截、脚本类）。
- 换一个浏览器内核再试（如从某浏览器换到系统自带浏览器）。
第四层：服务端侧
若对照实验显示「换什么都一样」，那就是服务端繁忙或临时故障。此时：等几分钟到几十分钟再试；避免高频重发（高频反而可能触发 限流）；关注官方状态或社区是否有同时间的反馈。
另外，如果是通过第三方客户端（如 OpenCode）接入，问题也可能在中间层，见 OpenCode 接入说明。
一张决策树走完
把上面的顺序串起来：转圈 → 换网络/浏览器 → 都一样则等服务端 → 只有一种组合则查网络或浏览器。完整的流程分支见 全流程排错决策树。
常见问题
一直转圈是账号被封了吗？
一般不是。转圈更像网络或服务端问题；账号受限通常会有明确提示文案。
换网络就好，说明什么？
说明问题与当前网络环境有关；以官方页面提示与支持渠道为准。
是不是重试越多次越好？
不是。高频重试可能触发限流，反而更难成功，间隔一下再试。
第三方客户端里超时算谁的问题？
可能是客户端到上游之间的中间层，先看客户端日志与说明。
相关页
先分清是哪一层在等
| 表现 | 可能的层 | 先做的一件事 |
|---|---|---|
| 页面白屏不动 | 本地网络 / DNS | 换个网络重开 |
| 转圈后提示超时 | 出口网络 | 换一个网络后重试一次 |
| 能打开但回答很慢 | 上游负载 | 等几分钟，或换短问题 |
| 只有某个功能卡 | 该功能本身 | 避开它，用别的方式完成 |
排查时别同时改多个变量
- 一次只换一样（网络、浏览器、账号），否则分不清是谁起的作用。
- 记录「改了什么 → 结果如何」，两三次就能定位。
- 连续超时超过 10 分钟，先去做别的，过一阵再试。
一次超时排查的完整过程
- 先记下现象：是白屏、转圈、还是转完提示超时？三种指向不同的层。
- 只换一样：先换网络（比如从移动网络切到固定宽带），其余不动，重试一次。
- 记录结果：好了 → 是网络；没好 → 把网络换回去，再换浏览器重试。
- 两三次就能定位。如果换了网络、浏览器都不行，那多半不是你这边的问题，先做别的。
最忌讳的是「网络、浏览器、账号一起换」——这样即使好了，你也不知道是哪一步起的作用，下次还会踩同一个坑。
一次改多个变量，最后不知道是谁的问题。
不记录报错原文，无法对照。
把网络问题和上游问题混在一起。
自检清单
最后核对：2026-10-08。内容来自公开分享与我们的核对；具体报错文案随版本变化。
出处：分两类——① 我们自己注册走通的步骤（实测）；② 网上的说法（转述）。涉及金额、时限的数字一律按「社区口径」处理，官方未公开，最终以 App 内为准。核对时间 2026-09～10。
这些会变：入口位置、额度、政策。以页面顶部的「最后核对」日期为准，日期旧了就当参考。
下一步：全流程排错决策树。如果想回头看整条路径，回教程目录。
邀请码来自网络公开分享：HUZM98，不填也能用，填了双方各得额度。以注册后 48 小时内、App 内显示为准。