更新于

国内访问延迟优化实测

国内场景延迟优化网络诊断API 中转

国内开发者调用 OpenAI、Claude、Gemini 等海外大模型 API，十有八九第一反应是”慢”。但”慢”背后可能是四五种完全不同的原因：DNS 解析绕路、TCP 握手跨国往返、TLS 握手次数过多、出口带宽拥塞，或者纯粹是模型本身的推理耗时。本文按”先诊断、后优化”的顺序，给出一套可以直接照抄的排查方法，并给出实测数据参考。

一、延迟到底花在哪几段

一次完整的 API 请求耗时可以拆成五段：

阶段典型占比（跨国直连）说明
DNS 解析5%–15%国内 DNS 递归到海外权威服务器往返多次
TCP 握手10%–20%三次握手，RTT 直接翻倍计入
TLS 握手15%–25%TLS 1.3 也要 1–2 个 RTT，证书链校验又加一段
首字节等待（TTFB）30%–50%模型排队 + 推理，也受地理距离影响
流式传输10%–20%长响应下，跨国链路丢包重传会显著拖慢

如果连接是国内到国内的中转节点，DNS、TCP、TLS 这三段可以压缩到个位数毫秒；真正的跨国段被中转服务商挪到了它自己和上游模型厂商之间的专线或优化线路上，同样是跨国传输，但走的路径通常比国内普通宽带的默认路由更短、更稳定。

二、先用三个命令做基础诊断

不猜测，先测。以下命令在 macOS / Linux 终端都能跑：

# 1. DNS 解析耗时
dig +stats api.openai.com | grep "Query time"

# 2. 到目标的路由跳数与丢包（国内公网直连海外域名时最能看出问题）
mtr -rw -c 50 api.openai.com

# 3. TLS 握手全过程耗时
curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://api.openai.com/v1/models

mtr 的输出如果在某一跳后丢包率突然从 0% 跳到 30%+ 且后续所有跳都居高不下，基本可以判定是国际出口链路的问题，而不是你本地网络或代码的问题——这种情况下再怎么优化本地代码也没用，得换路径。

三、常见的四个延迟黑洞

1. DNS 污染或递归慢。 部分国内运营商的默认 DNS 对海外域名解析慢，甚至返回错误 IP。换成 1.1.1.1 或 8.8.8.8 有时能立竿见影，但稳定性因运营商而异，建议在应用层做 DNS 结果缓存，避免每次请求都重新解析。

2. 连接未复用。 很多 SDK 默认每次请求新建 TCP 连接，等于把 TCP+TLS 握手的延迟平白加了两次。用 requests.Session()（Python）或保持 http.Client 单例（Go/Node）做连接池复用，同一进程内的第二次及以后请求能省掉这两段。

3. 未开启流式响应。 非流式模式下，客户端要等模型生成完整响应才能拿到任何数据；流式模式下 TTFB 只到第一个 token 就返回，用户感知延迟能降低 60% 以上，即使总耗时不变。关于流式实现的坑，可以参考《流式响应（SSE）常见问题排查》。

4. 中转节点选错区域。 如果中转服务商在国内多地部署了接入点，但你的请求被路由到了离你物理距离更远的节点，延迟反而可能比直连还差。优先选择支持”就近接入”或明确标注国内多线 BGP 的服务商，并实测对比。

四、实测对比：直连、VPN、API 中转

以下是同一段 Prompt（约 300 token 输入）在三种链路下的 TTFB 中位数，测试环境为国内某二线城市家宽，取 20 次请求的中位数（不同网络环境结果会有差异，仅供参考量级）：

链路方案TTFB 中位数稳定性（P95/P50 比值）
直连海外 API3.2s2.8（波动大）
自建 VPN 转发2.1s1.9
国内多线 API 中转0.9s1.3（较稳定）

中转方案的优势不只在中位数更低,更在于波动更小——这对需要稳定响应时间的生产环境比单纯的”平均更快”更重要。直连和自建 VPN 的对比与选型思路，可以参考《API 中转 vs 自建 VPN 方案对比》。

五、模型选择本身也是延迟优化的一部分

网络层优化到极致后，剩下的延迟大头是模型推理本身。同样的任务用更快的模型能带来数倍的延迟下降，这部分不属于网络问题范畴，但同样值得纳入优化清单，详见《降低 LLM 延迟的 10 种实战方法》。如果用的是 OpenAI 的 service_tier 机制,不同档位对延迟的影响也不小,可参考《OpenAI service_tier 延迟与成本取舍》。

六、一份可直接执行的优化清单

  1. 用 curl -w 命令跑一遍基础诊断，先定位延迟在哪一段，不要凭感觉猜
  2. 检查 SDK 是否开启了连接复用（Session/Client 单例），避免重复握手
  3. 交互式场景一律开启流式响应，降低用户感知延迟
  4. 对比直连、VPN、中转三种链路的实测数据,再决定要不要换路径
  5. 选择中转服务商时，优先测试其国内多线接入点的实际延迟，而不是只看宣传文案
  6. 简单任务换用更快的模型，这往往是收益最高、成本最低的一步

七、相关阅读

如果诊断下来延迟大头确实在国际出口链路上，与其自己折腾 BGP 线路和证书链，不如直接测一下 YoTradeApi 的国内多线接入节点，通常几分钟就能看到实测数据是否符合预期。

相关阅读