OpenAI / Anthropic API 总超时,网页却正常,该怎么排查

表现:网页聊天很正常,API调用却总报错

如果你是直接拿官方SDK或者一段简单的Python/Node脚本去调用OpenAI或者Anthropic的接口,大概率见过这几种报错:APIConnectionError、Connection error,或者干脆是Request timed out。奇怪的是,打开浏览器,登录网页版聊天界面,输入同样的问题,回复照样能正常出来,一点问题都没有。

这种一边能用一边不能用的表现,很容易被误判成账号异常或者是被平台限制了访问,于是花大量时间去查账号状态、查计费、查是不是被封,结果查了一圈发现账号本身完全正常。真正值得先弄清楚的,是网页版和API走的到底是不是同一条路。

实际发生的事一:聊天网页和调用接口,走的根本不是同一条路

网页版聊天界面和用于调用模型的API接口,几乎总是挂在不同的主机名下,请求的形态也完全不一样:网页那一路往往是浏览器发起的、带着完整会话状态的长连接或流式推送,中间可能还经过一层专门给网页用的加速或缓存节点;而直接调用API,走的是SDK发出的独立HTTPS请求,没有浏览器那一整套额外链路帮忙扛连通性。

正因为两条路的主机名、协议细节和中间经过的节点都不一样,一条路能通完全不能保证另一条路也能通。网页版能正常打开,只能证明访问聊天页面这件事目前是通的,不能反过来推出调用接口这件事也一定是通的,这是判断这类问题最容易踩的第一个坑。

实际发生的事二:SDK的超时,往往比一次长回答需要的时间短得多

调用API还有一个不容易被注意到的细节:大多数SDK都有自己的默认超时设置,而这个超时设置的初衷是防止脚本永远卡住,并不是按照一次内容较长的回答需要多久来设计的。如果模型正在生成一段比较长的内容,又恰好赶上链路某个环节稍微慢一点,很容易在还没收到完整回复之前,就先撞上SDK自己设的超时。

更容易让人摸不着头绪的是,流式(stream)调用和非流式调用在同样的网络条件下,表现经常完全不同。流式调用会不断吐出一小块一小块的内容,链路上的中间设备很少会把这种一直有数据流动的连接当成空闲连接掐断;非流式调用则要等模型把整段内容生成完,才会一次性把结果发回来,这段看起来什么都没发生的等待时间,一旦超过某个环节的超时阈值,就会直接报错,哪怕模型那边其实正在正常工作。所以同一份代码,把非流式改成流式测试一遍,往往能看出问题到底出在哪一段。

一分钟自查:先辨清是连不通,还是等太久

不用急着改代码,先做一个简单到十秒钟就能出结果的测试:打开终端,直接用curl请求API对应的域名,完全不经过SDK里任何超时或重试设置。

如果curl本身也直接连不上,或者卡很久一点响应都没有,那基本可以确定问题出在链路连通性上,跟SDK的参数没多大关系,继续调大超时时间也没用。如果curl这边能陆陆续续收到数据,只是感觉比预期慢一些,那问题更可能出在SDK或者客户端自己设置的超时时间太短,链路本身其实是通的。这一步测试的价值在于,它能在动手改代码之前,先把网络问题和超时设置问题这两种完全不同的方向分开,避免在错误的方向上反复折腾。

处理次序:按这个次序一步一步来

确认过上面两个实际发生的事之后,建议按这个顺序排查,而不是东一下西一下地乱试:

1. 先用curl直接测试API域名的基础连通性,不带任何客户端设置。
2. 确认浏览器里配置的代理或者插件,是不是只对浏览器生效——本机终端和后台脚本默认走的是完全独立的另一条路,不会因为网页能打开就自动跟着通。
3. 把同一个请求分别用流式和非流式各测一次,看看是不是只有非流式才会超时,借此判断问题是不是出在等待太久这一类原因上。
4. 检查代码里给SDK设置的超时数值,是不是明显短于一次正常长回答需要的时间。
5. 如果确认是链路本身不稳定,换一条对整台机器都生效的通道再完整测一次,而不是只在浏览器里换。
6. 换通道之后,如果网页和API都能稳定跑通,基本可以确认之前的问题出在链路连通性上,不是账号或者代码逻辑的问题;如果换了通道问题依旧,再回头检查代码里的超时和重试逻辑。