香港服务器接的海外API挂了三小时怎么办？超时、重试与降级怎么定

栏目里 8 月 19 日那篇讲的是"你的香港服务器自己挂了"，8 月 24 日那篇讲的是"挂在你前面的 CDN 挂了"。这两篇都是入向的——用户进不来。这篇补上第三种，也是最容易被忽略的一种：机器好着，线路好着，用户也进得来，但你的程序要调的那个海外接口没反应。

9 月 3 日给了一个足够典型的样本。

三家互为对手的供应商，同一个上午一起不可用

按 The Register 的报道，OpenAI 方面的说法是太平洋时间 9 月 3 日 7:43 起一次路由错误导致 ChatGPT 和 Codex 对部分用户不可用，约 8:17 修复生效。Anthropic 状态页记录的这次故障持续 3 小时 6 分钟，覆盖 Claude.ai、Claude Code、Claude Cowork 和 API；Axios 当天引用状态页的信息是，多数模型已回落到基线错误率，Opus 4.8 和 Opus 5 仍在故障中。综合 9to5Google 等媒体的记录，各家从 8:49 前后陆续恢复，到 12:38 才全部回正常。Downdetector 上仅 OpenAI 一侧的报告量就是数万级。

有意思的是根因这件事。因为三家都或多或少用着 Azure，当天流传最广的推测是"共同根因在微软"。但三家自己的口径彼此不重合：OpenAI 说路由错误，Anthropic 说基础设施问题，xAI 则明确把 Grok 的故障归因于自家孟菲斯算力中心的一次中断，并向受影响的算力合作方致歉。截至目前，没有任何一家确认过共同根因。

所以更稳妥的读法不是"Azure 挂了导致三家一起挂"，而是：三家互为竞争对手、根因可能各不相同的 API 供应商，在同一个上午一起不可用了。这个事实对做业务的人更难受——如果你按"多供应商就是冗余"的思路同时接了其中两家做主备，那天早上你的备也是哑的，而且事后你甚至找不到一个共同原因来解释为什么。

未来 12 个月，故障形态更可能是"半死不活"而不是"整体宕机"

把同一周的另外两条消息放进来看，会更清楚这类依赖的走向。

9 月 2 日，Equinix 联合 NVIDIA 与 Together AI 宣布 Equinix Inference Exchange，把推理服务放进自家全球机房、通过 Fabric 就近连到企业数据和用户。方向是对的，但要注意它给出的可用时间是 2027 年第一季度——这是趋势信号，不是今天能拿来用的方案。同一份公告里那句判断值得记下来：推理跑在哪里，已经是战略问题。

另一条是 Anthropic 8 月底到 9 月初接连被报道的算力协议：与 Lambda 约 350 亿美元、六年，容量来自 Hut 8 在得州建的数据中心；与 Nscale 约 450 亿美元、六年，约 460 兆瓦，位于西弗吉尼亚。加上今年早前对 AWS、Azure、Fluidstack、SpaceX 等的承诺，2026 年内公开报道的总额已在 1350 亿美元以上。

数字本身对开发者没用，时间点有用。Nscale 那批容量按报道要到 2027 年下半年才开始承载业务。也就是说，签约解决的是 2028 年的问题，而眼下这一年多，供需是紧的。紧的时候，你收到的不一定是干净的 5xx，更可能是：429 限流、排队导致的首字节时间拉长、个别模型不可用而其他模型正常——9 月 3 日恢复过程里"多数模型已回基线、Opus 系列仍在故障"就是这个形态。

这一点很关键，因为它决定了你的防护要挡的是什么。挡"整体宕机"，一个 try/catch 就够了；挡"忽快忽慢、部分可用、限流反复"，要的是超时、退避、熔断和降级语义这一整套。

同样的逻辑不只适用于 AI 接口。香港服务器上常见的出向依赖还有 Stripe、PayPal 这类支付，Twilio、AWS SNS 这类短信推送，Google Maps、汇率、物流查询这类数据接口。共同点是三个：在你机房之外、不受你的 SLA 约束、会在你没准备的时刻变慢或变哑。

上游故障不该变成你的故障

香港到美西的物理条件再好，也管不到接口那一端。能管的只有自己这一侧怎么调用。下面几条按"投入产出比"排序，前两条几乎是当天就能改完的。

超时不是一个数，AI 接口尤其是

"给外部调用设 2 到 5 秒超时"这种一刀切的建议，用在流式大模型接口上会直接把业务改坏——一次长回答的整体耗时轻松过 30 秒，整体超时设 5 秒等于永远拿不到完整结果。

要拆成三个值分别设：

• 连接超时：TCP + TLS 建连，香港到美西 1 到 3 秒足够，握不上手就是网络问题，等下去没意义。
• 首字节超时（TTFB）：上游有没有开始干活，这是最有诊断价值的一个。上游排队、限流、过载，都表现为 TTFB 变长。
• 整体/空闲超时：流式接口用"空闲超时"（连续 N 秒没有新 token 就断）比用总时长更合理；非流式接口才用总时长。

具体数值别拍，去看自己的历史分布：取过去两到四周该接口的 P99，再留 1.5 到 2 倍余量。没有埋点的话，这件事就是先埋点——出向调用耗时不单独打点，后面所有阈值都是猜的。

真正致命的是没有超时。HTTP 客户端默认超时往往是几十秒甚至不限，没有超时的调用会把工作线程或连接一个个吃掉，最后应用假死：上游只是慢，你却是彻底挂了。

重试之前先问一句：这个请求能重放吗

重试要有上限和退避，这是常识。指数退避 + 随机抖动 + 最多 2 到 3 次，遇到 429 主动放慢而不是加速——上游一抖动所有客户端同时重试，等于给正在恢复的接口再叠一层压力。

但比退避更容易出事的是幂等性。GET 和大多数查询类接口重试无害，创建订单、扣款、发短信这类写操作重试一次可能就是重复扣款、重复发送。这里唯一靠得住的做法是幂等键：客户端生成一个唯一 ID 随请求带上，同一个键的重复请求上游只执行一次。支付类接口基本都支持（Stripe 是 Idempotency-Key 头），支持就一定要用；上游不支持幂等的写操作，宁可不重试，让它失败并进人工或异步队列。

另外，超时之后的状态是"未知"，不是"失败"。请求超时了不代表上游没执行成功，这一点在对账逻辑里必须体现出来，否则重试和补偿会双重下单。

熔断的价值在于"快速失败"

连续失败到一定比例后，在本地直接快速失败一段时间，不再发请求，过一会放少量流量试探（半开）。参数上给一个能用的起点：滚动窗口内至少 20 次请求、失败率超过 50% 打开、打开后 30 秒进半开、半开放行 5 到 10 个请求全部成功才关闭。

它的收益很直白：把"每个请求都在那儿等 5 秒超时"变成"每个请求立刻返回降级结果"。前者会在几分钟内耗尽线程池并把故障扩散到本来无关的接口，后者只是某个功能不可用。熔断要按依赖分组隔离，别所有外部调用共用一个池——一个慢接口拖垮整个应用，多半是这里没隔离。

降级语义要提前定义，故障当天没有时间开会

每个依赖都要有一句写下来的答案：

• AI 接口不可用：返回缓存过的历史结果、退回规则引擎，还是明确告诉用户"智能功能暂时不可用"？
• 支付接口不可用：切备用通道，还是先生成待支付订单、稍后补扣？
• 短信不可用：邮件顶上，还是延长验证码有效期并允许重发？

降级方案不需要完美，但必须提前定好，而且要让产品和客服知道，否则前台文案对不上、工单也答不上来。

顺带一条经验：降级要能手动强制开启。有些故障不是"完全不通"而是"慢得没法用"，熔断器未必判得出来，这时需要有人一键把某个依赖切到降级态。

主备接口要先查故障域，查不到就换思路

9 月 3 日的教训主要在这里。两家 AI 供应商如果跑在同一家云、同一个区域，作为主备的意义就打了折。

问题是这件事很难查——多数厂商不公开自己的算力落在哪家云的哪个区域。能做的有限：看双方状态页历史事件的时间相关性（同时出故障超过一两次就要警惕）、直接在售前问清楚、留意公开报道里的合作关系。查不到的时候，务实的替代思路是让主备走不同类型的方案，而不是找第二家同类 API：比如主用托管 API、备用自己托管的开源模型。两者的故障原因几乎不可能相同，这比"再接一家 API"可靠。

放到香港服务器上，有三处容易踩

香港出国际线路不绕道，调美国、欧洲接口的基础延迟本身不高，这是实打实的优势。但有几点常被忽略。

一是跨境延迟的方差比均值大得多。到美西接口平时 130ms 上下，晚高峰跳到 300ms 以上并不罕见。超时阈值按平时的均值设，结果就是每天晚高峰误触熔断、功能自己降级。这也是前面强调"按 P99 加余量"而不是按经验值拍的原因。

二是出向 DNS 要本地缓存。外部接口域名每次都走公共 DNS，解析本身就成了一个故障点，跨境场景下这一跳的抖动还不小。在服务器上跑一个本地缓存解析器（dnsmasq、systemd-resolved、unbound 都行），或至少让运行时正确遵守 TTL 缓存，成本极低。注意别把 TTL 缓存得过长，上游切换 IP 时你会跟不上。

三是连接复用比想象中重要。跨境每建一次连接要付一个 RTT 的 TCP 握手加一到两个 RTT 的 TLS 握手，130ms 的链路上就是几百毫秒，全花在还没开始传数据的阶段。确认 HTTP 客户端开了 keep-alive 和连接池，池子大小别小于并发峰值，能上 HTTP/2 就上。这一条在国内机房不明显，跨境调用上收益直接可见。

如果出向调用散落在十几个服务里，可以考虑收敛到一个出向网关或 sidecar 上，超时、重试、熔断、限流只配一处，也方便统一打点。中小规模团队没必要为此上一整套服务网格，一个薄代理层就够。

怎么第一时间知道是上游的问题

我们在工单里见过不少这样的排查过程：客户报"服务器很慢"，查 CPU、内存、带宽、磁盘全部正常，最后发现是应用里某个第三方接口超时把线程池占满了。服务器没问题，问题在调用方式，但这个结论往往要几个小时才浮出来。

要缩短这几个小时，需要的埋点其实不多：

• 每个外部依赖单独记录调用耗时（P50/P99）、错误率、超时率、429 计数，按依赖名分维度；
• 线程池、连接池的饱和度，这是"假死"最早的先兆指标；
• 熔断器状态变化打成事件，而不是只写日志；
• 关键上游的状态页订阅，接到告警群里。

判断顺序建议固定成：先看自己的资源曲线是否正常 → 再看出向调用耗时和错误率是否集中在某一个依赖 → 最后去看该依赖的状态页和社群。第一步正常、第二步集中，基本就能定性，不用再去重启服务器。

关于兜底部署

超时、重试、熔断、降级这四件事做完，通常不需要改架构，也不需要加机器，是一次性的代码与配置工作。对把关键业务放在 香港服务器 或 香港云服务器 上、同时依赖海外 AI 与支付接口的团队，这项工作的优先级应该排在"加带宽""升配置"之前——上游慢的时候，加带宽一点用都没有。

如果业务对某个模型接口的依赖已经到了"它挂了就没法交付"的程度，可以评估在 香港 GPU 服务器 上跑一个小参数开源模型作为兜底。但这件事要说实在的：兜底模型的输出质量和线上模型不是一个水平，指望它无缝替代不现实。它的价值在于让业务在那三个小时里还能往前走，前提是你提前定义好了降级后的输出要求（比如只保留分类、摘要、模板填充这类容错度高的能力，把开放生成关掉），并且真的做过一次切换演练。没演练过的兜底，故障当天大概率也是启动不了的。

FAQ

只接一家 AI 接口，是不是一定要再接第二家？

不一定，先算清代价。多接一家意味着两套 SDK、两套 prompt 调优、两份限流额度和两份账单，输出风格差异还可能影响业务效果。如果你的 AI 功能是辅助性的（摘要、标签、推荐话术），做好降级比做双供应商划算得多；只有当它在核心链路上、缺了就无法成单时，才值得付双活的成本。而且如前所述，第二家如果和第一家共享故障域，这笔钱花得未必值。

超时设短了会不会把本来能成功的请求砍掉？

会，这是一个明确的取舍：超时越短，误杀越多但线程占用越少。所以要按 P99 加余量来定，而不是凭感觉设小；对写操作配合幂等键做有限重试，可以把误杀的代价降下来。判断标准不是"有没有误杀"，而是"误杀带来的损失是否小于线程池被打满带来的损失"——后者是全站级的。

上游返回 429，除了退避还能做什么？

三件事：一是把请求分优先级，额度紧张时先保交易链路，把批量任务、离线分析降级或推迟；二是给非实时任务加队列，削峰而不是硬打；三是核对配额本身，很多 429 不是上游故障，而是自己的用量涨到了套餐上限，看一眼账单和配额页比调代码快。