如果你的服务要调海外 API、或者要跑国际业务，多半遇到过这类问题：

• 接 Stripe / Shopify / PayPal 这类海外 SaaS 的 API，本地测好的代码部署到国内服务器之后，调用 timeout 频发
• 给 OpenAI / Claude / Anthropic 发请求，偶发性 503、connection reset、SSL 握手失败
• 跑外贸电商业务的服务，调亚马逊 SP-API、Shopify Admin API、Lazada Open Platform，吞吐上不去
• 海外拉日志、海外同步数据库、海外对象存储拉文件，性能远低于带宽理论值

这些问题平时被各种 retry、circuit breaker、timeout 调长这类"软兜底"掩盖了，但根因其实指向同一个东西——国际公网链路的不稳定。

这件事最近被推到台前，是因为业务侧的一个明显变化。

一、为什么"国际调用"这件事突然变成性能瓶颈

国际业务以前是小众场景。但 2024-2026 这一波，外贸电商和 AI 国际调用的体量起来了。

举一个最近的行业例子。韩国老牌电商平台 Gmarket 借助 Lazada 拓展东南亚——目前约 8000 名 Gmarket 卖家在 Lazada 上销售商品达 700 万个，两个月内销售额增长 150%。韩国外贸出口电商一季度整体规模达到 1.06 万亿韩元，同比增长 24.4%。阿里巴巴国际站数据显示，海外买家对韩国卖家的采购询盘量近期增长 128%。

这组数字翻译成技术语言就是：一个 Gmarket 卖家如果同时在 Lazada 的 6 个国家做生意，背后的 IT 系统每天产生的国际 API 调用，从几年前的几千次量级飙升到了几十万次量级。对接 Lazada 各国站点的订单 webhook、库存同步、价格调整、物流回写、客户消息——全部都是国际网络请求。

中国外贸电商企业的情况类似。一个中等规模的卖家可能同时在亚马逊全球十几个站点、Shopify、TikTok Shop、Temu 上跑业务，再叠加用 AI 写 listing、做客服自动回复、生成多语言营销文案——技术栈里几乎每一层都在国际调用。

业务体量起来之后，国际网络这条链路从"偶尔慢一点"变成了"成本和稳定性的核心变量"。

二、国际公网链路的真实性能问题

如果你的服务部署在国内，调海外 API 实际经历了什么？

第一，RTT 天然高。国内到美西机房（Stripe、OpenAI 等主要服务的核心区域）公网 RTT 通常在 200-300ms，糟糕的时候 400ms 以上。国内到东南亚（Lazada、Shopee、TikTok Shop 服务器集中区域）通常 100-200ms。每一次 HTTP 请求要乘上这个 RTT 才能拿到响应，HTTPS 还要再加一个 TLS 握手的开销。

第二，TCP 拥塞窗口起不来。国际公网链路的丢包率比国内高一个数量级，TCP 的拥塞控制反复触发——窗口减半、慢启动。你的带宽理论上够，但实际吞吐被压到峰值的 1/5 都不奇怪。批量同步几 GB 数据这种场景体感最差。

第三，BGP 绕路。公网路由不一定走最优路径。从北京到东京理论上一跳就能到，实际可能绕到香港、新加坡再回东京——每多一跳就多一道延迟和丢包概率。更糟的是国际段链路抖动时，BGP 路由切换可能让你的连接突然变到一条完全不同的路径上，连接稳定性瞬间崩塌。

第四，缺少质量监控。你的服务调用海外 API 失败的时候，几乎拿不到证据证明是公网链路的问题。运营商一句"我们这边没问题"，你这边没有任何数据反驳，最后只能"应用层加 retry、调大 timeout、加 circuit breaker"——这些是补丁，不是根治。

三、应用层的常见补救，以及它们的天花板

工程师在国际调用这件事上想了不少办法：

重试 + 指数退避。大部分场景的兜底。问题是连续 5xx 或 timeout 时，retry 反而会放大延迟——客户等 30 秒才拿到一个失败响应，体验比直接报错还差。而且重试对计费 API（比如 Claude / OpenAI 的 token 计费）意味着一次请求被算了好几遍钱。

Connection Pool + Keep-Alive。减少 TLS 握手次数确实有效。但国际长连接面对的真实挑战是——空闲连接经常被中间网络设备半小时悄悄回收，下次复用时直接 RST。

应用层 cache。能解决一部分读场景，但对国际写入、国际实时同步无效。

改用海外服务器中转。最常见的方案。在新加坡或东京租一台 VPS 做反向代理，所有国际流量先到这台 VPS 再出。问题是——你引入了一个单点（VPS 挂了整个国际业务停摆）、引入了运维负担（需要专人盯）、合规上也存在灰色（用消费级 VPS 跑企业业务）。

专线。最稳的方案，但贵——单条国际线路一年几十万起步，中小企业用不起。

协议层优化。HTTP/2 多路复用、HTTP/3 over QUIC 在弱网下表现确实比 TCP 好，但这些优化是在公网基础上做的，公网基础烂的话上层做得再好也有上限。

这些方案的共同问题：要么是补丁性质，要么贵到只有头部公司用得起。中间地带一直是空的——直到 SD-WAN 这类企业级国际网络方案的成本下来了。

四、SD-WAN 在国际 API 场景的工程价值

SD-WAN（软件定义广域网）原本是大企业用来连接多分支的技术，这两年开始在国际 API 场景里发挥作用。它解决国际调用问题的思路有三层：

第一层 · 链路层路径优化。服务商在全球部署 POP 节点，你的出海请求不再走公网国际链路，而是先就近接入服务商的 POP，再走预选过、监控过的骨干线路出海。RTT 通常能比公网降低 30%-60%，丢包率显著下降。对调用频次高的服务，这种基础链路的改善是乘性收益——每一次请求都受益。

第二层 · 多链路冗余与智能选路。同时纳管多条底层链路（不同运营商、不同出海路径），通过 BFD / 健康检查持续探测每条链路的实时质量（延迟、抖动、丢包）。任意一条质量劣化或中断，秒级切换到健康链路。这对"长时间运行的国际任务"特别重要——大批量数据同步、训练数据集传输、海外直播这类场景，一次链路抖动可能让小时级的任务白跑。

第三层 · 应用层加速与协议优化。部分方案在加速节点上做 TCP 参数调优、应用层协议复用、压缩传输。对 git pull、跨境对象存储、跨境数据库同步这类"多次往返 + 大对象流式传输"的场景效果尤其明显。业内有反馈过具体数据：同一个 5GB 仓库，走公网 40 分钟，走加速链路 4 分钟——这是十倍的差距。

五、什么时候该考虑这个

不是所有国际调用都需要这套基础设施。如果你的服务国际调用频率低、对延迟不敏感、业务非核心，公网 + 应用层补丁够用。

但只要符合下面任一情况，国际网络的工程价值就会显著：

• 国际调用是业务核心链路（电商订单、支付、客户消息、AI 推理）
• 国际业务在快速增长，调用频次和数据量都在指数增长
• 国际 SLA 跟业务损失强挂钩（每分钟国际断流直接对应订单损失或客户流失）
• 国际长任务多（大批量同步、模型训练数据传输、跨境直播）
• 海外站点 / 海外仓 / 海外分公司有持续接入需求
• 团队需要一个"集中可观测、可管理"的国际网络，而不是各业务自己折腾代理

满足这些条件的工程团队，把国际网络当成基础设施一部分来规划，长期回报远高于反复打补丁。

六、写在最后

回到开头那条 Gmarket 的资讯。Gmarket 在 Lazada 上的 8000 卖家两个月销售额涨 150%、整个东亚跨境电商进入扩张周期——这不是一家公司的故事，是一整个行业的技术挑战正在被推到台前。

业务规模跨越某个临界点之后，比拼的就是基础设施。一个跨 6 国销售、几十万 SKU、卖家几万到几十万的平台，每天的国际 API 调用是天文数字——任何一个基础环节没跟上，都会变成增长的天花板。国际网络是这样的基础环节。它平时看不到、想不起来，业务规模大了之后每一次掉链子都是真金白银的损失。

如果你的服务正在或即将面对大规模国际调用，国际网络这一层值得花时间认真规划——比反复打补丁、调 timeout、加 retry 划算得多。