AI API 调用用什么 VPN,判断标准不是「哪个节点测速最快」,而是三件事:出口 IP 是否固定、并发连接是否稳定、失败之后能不能干净地重试。网页聊天里一次卡顿只是转圈两秒,脚本里一次超时可能让整批任务重跑;而为了重试随手换一个节点,出口 IP 一变,又可能触发对方的风控。下面把这三件事拆开讲,再给一份可以直接抄的配置。

网页聊天和 API 调用,网络需求不一样

在网页里和模型对话,客户端通常维持一到两条长连接,断线由前端自动重连,人对几百毫秒的抖动几乎没有感知。脚本调用是另一套模型:每次请求都要走一遍域名解析、TCP 握手、TLS 握手,拿到响应后连接可能立刻被回收;一批任务里几十上百次请求同时发生,任何一次建连失败都会以异常的形式落到代码里,而不是变成界面上的一个转圈动画。

对比维度 网页聊天 代码调用 API
连接模式 少量长连接,SSE / WebSocket 流式返回 大量短连接,反复建连
失败感知 界面转圈,由前端自动重连 抛异常或超时,由重试逻辑决定结果
出口要求 能连上、能保持即可 常要求出口 IP 稳定,便于白名单与排查
敏感指标 首字节时间 建连成功率与延迟抖动
典型任务 一问一答 批量生成、向量化、定时任务

这张表解释了一个常见困惑:同一台机器上网页能打开,脚本却频繁超时。网页走的是一条已经建好的长连接,脚本每次都要重新建连,后者对线路抖动的暴露面大得多。所以「能打开网页」不足以证明一条线路适合跑 API。

三类线路怎么挑:专线、中转与直连

把线路按路径粗分,常见三类:IEPL 专线、中转、直连。名字只是标签,路径才决定表现:数据从哪里出境、中间经过几跳、是否和普通流量挤同一个出口。

线路类型 路径特征 表现 适合的 API 场景
IEPL 专线 国际专线直连,不绕公网出口 延迟稳定、抖动小 流式输出、交互式对话、长连接任务
中转 先接入中转节点,再由中转出境 质量取决于中转节点,波动中等 可重试的批量任务、离线作业
直连 本地网络直接出境 受本地出口影响大,晚高峰明显 备用线路、低频调用

分流思路是「按域名分配线路」:把 api.openai.comapi.anthropic.com 这类接口域名固定走专线,把拉依赖、同步镜像这类大流量留给直连;两条线路互为备份,主线路连续失败时才切换。VPNEM 的线路按地区归档,覆盖 110+ 国家、210+ 条线路,选节点时优先挑标注了 IEPL 的入口,再用实测抖动决定是否降级到中转。

  • 110+覆盖国家与地区
  • 210+已上线线路
  • 60 天无理由退款窗口
  • 不限台数同时在线设备

结论:交互式请求与批量任务分开走。流式对话、需要低抖动的调用放 IEPL 专线;离线批处理放中转或直连;再留一条备用线路,只在主线路连续失败时接管,避免每次重试都换出口。

固定出口、并发连接与超时重试

出口 IP 固定,比「最快」更重要

对方服务端看到的是你的出口 IP。同一个账号在几分钟内从多个出口发出请求,轻则被要求二次验证,重则被限流;而且日志里的来源对不上,排查时无法判断是线路问题还是代码问题。做法很直接:客户端里不要开「自动选择延迟最低节点」,手动固定一个节点;团队多人共用一个订阅时,约定同一个出口,或者干脆按项目拆开账号。

并发连接:连接池比带宽更关键

每次请求都新建 TLS 连接,等于把握手成本乘以请求数,并发一上来,瓶颈往往出现在建连而不是带宽上。打开 keep-alive、把连接池上限设到并发量的 1.2~2 倍、让客户端启用 HTTP/2 多路复用,通常比换一条「更快」的线路更有效。监控上也应该看建连成功率与握手耗时,而不是只看峰值带宽。

超时与重试:两类超时分开设

连接超时和读取超时要分开配置。连接超时设短一点(几秒),线路不通就尽快失败,把时间留给重试;读取超时设长一点,因为流式响应本来就要持续输出几十秒。重试只对幂等请求和 5xx、超时生效,4xx 重试只是浪费配额;退避要带随机抖动,否则一批 worker 会在同一秒一起重试,把刚恢复的线路再打满。

# 只对当前终端会话生效,避免污染整机环境
export HTTPS_PROXY="http://127.0.0.1:7890"
export HTTP_PROXY="http://127.0.0.1:7890"
# 本地与内网地址不经过代理
export NO_PROXY="localhost,127.0.0.1,::1,10.0.0.0/8,.internal.example.com"

HTTPS_PROXY 这类环境变量会被 curl、Python requests、Go 标准库等直接读取;Node 默认不读,需要显式给 undici 设置 ProxyAgent,较新的 Node 版本也可以用 NODE_USE_ENV_PROXY=1 打开实验性的环境变量代理支持。

import httpx
from openai import OpenAI

# 连接池:上限 32、常驻 16;连接超时与读取超时分开
http_client = httpx.Client(
    timeout=httpx.Timeout(30.0, connect=8.0),
    limits=httpx.Limits(max_connections=32, max_keepalive_connections=16),
)

client = OpenAI(http_client=http_client, max_retries=3)

这段配置正好对应上面三点:连接池限制并发建连的数量,connect=8.0 让线路不通时快速失败,max_retries=3 把重试交给 SDK 而不是自己写循环。SDK 默认会对连接错误、408、409、429 和 5xx 做指数退避重试,不需要重复实现;自己再包一层重试,反而会把一次超时放大成三次。

协议与客户端:从 Shadowsocks 到 Hysteria2 的取舍

订阅链接里通常一次给出多个节点,协议不同,在客户端里的表现也不同。下面是常见几种的定位,选的时候记住一条:能稳定建连的协议,优先于理论上更快的协议。

协议 特征 更适合的情况
Shadowsocks 轻量,AEAD 加密,客户端支持广 CPU 吃紧的机器、配置项越少越好
VMess 需要 UUID,可搭配多种传输层 从已有配置迁移过来
Trojan 走标准 TLS,流量形态接近 HTTPS 网络环境对 TLS 友好的时候
VLESS 本身不加密,依赖 TLS / REALITY 想省掉一层加密开销
Hysteria2 基于 QUIC / UDP,拥塞控制激进 丢包高、抖动大的链路
TUIC 基于 QUIC,多路复用 网络频繁切换的移动场景

导入流程各家客户端大同小异:复制订阅链接,在客户端里选「从剪贴板导入」或粘贴到订阅设置里,再手动点一次「更新订阅」;节点列表出现在客户端里,导入才算成功。桌面端一般提供 TUN 模式(接管全局流量)和系统代理两种方式,跑脚本的机器建议用系统代理配合分流规则,不要把所有流量都塞进隧道;iOS 上导入后系统会弹出「允许添加 VPN 配置」,必须点允许才会生效。

订阅链接本身就等于一份凭据,不要提交到公开仓库,也不要贴进聊天记录。CI 里用 secret 变量注入,本地至少放进权限收紧的配置文件里。

上线前自查:超时、DNS 与分流规则

下面这份清单可以直接对着客户端和代码过一遍,每一条都对应一类真实故障。

  • ✅ 出口固定:同一个账号的请求始终从同一出口发出,方便对方白名单,也方便自己排查。
  • ✅ 分流规则只把需要的域名交给国际线路:api.openai.comapi.anthropic.com 等走专线,其余直连。
  • ✅ DNS 与请求走同一条线路:开启客户端的远程解析,避免域名被解析到就近节点。
  • ✅ 两类超时分开设置:连接超时几秒,读取超时按流式响应的最长时长留足。
  • ❌ 全局代理忘了 NO_PROXY:内网域名和本地服务也被绕出去,表现为「接口突然 502」。
  • ❌ 用「自动选择节点」:每次重连换一个出口 IP,服务端看到的是多个来源。
  • ❌ 用 ping 判断线路好坏:ICMP 通不代表 TLS 握手能成功,要看 time_connecttime_appconnect

验证线路不用装额外工具,一条 curl 就够:

curl -x http://127.0.0.1:7890 -sS --connect-timeout 8 -o /dev/null \
  -w 'http=%{http_code} connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n' \
  https://api.openai.com/v1/models

连跑十几次,看 connecttls 两列的波动,而不是看绝对值。波动很小,说明这条线路适合放交互式请求;如果偶尔出现几秒的尖峰,基本可以判断节点在切换或者本地出口在抖动,这类线路只适合放可重试的批处理。

DNS 泄漏的典型症状是「能连上但很慢」或者「同一个域名时快时慢」。如果客户端只代理 TCP 流量、把 DNS 交给本地解析器,解析结果可能指向离你最近的节点,而不是离出口最近的节点。排查方式是在客户端日志里确认域名解析是否走了代理解析,并把分流规则覆盖到 DNS 查询本身。

开发者常见问题速答

只在本机开发,也要专门配线路吗?

要。开发机上的建连方式和线上没有区别,区别只在并发量。本地就把分流规则和超时参数调好,上线时才不会出现「本地一切正常、服务器上全是超时」的情况;反过来,如果本地是靠全局代理凑合跑通的,那套配置基本没法搬到服务器上。

请求偶尔超时,直接重试就行吗?

先分清是哪一类超时。连接超时说明线路或端口有问题,重试大概率还是失败,应该先换线路;读取超时往往是流式响应太长,先调大读取超时,再考虑重试。把两类超时的次数分别打点,比笼统记录一个「失败率」有用得多。

一个订阅够几台机器用?

VPNEM 不限台数同时在线,开发机、测试机和 CI runner 可以共用同一个订阅,前提是出口策略统一:要么都固定到同一个节点,要么按项目分开账号,不要把多个出口混在同一个账号上。

怎么判断一条线路是不是真的专线?

不看名字看数据。连续采样 time_connect,专线的曲线应该接近一条水平线;如果晚高峰出现规律性抬升,那更接近直连或者质量一般的中转。VPNEM 的线路页标了每条线路的类型,可以拿实测曲线和标注互相印证。

如果正在挑服务,可以先把这几项问清楚:是否不记录日志、退款窗口有多长、开通是否需要邮箱地址、支付方式是否顺手。VPNEM 在这几项上的做法是:不记录日志、60 天无理由退款、开通无需邮箱地址,支付支持支付宝、微信与 USDT;线路与套餐明细可以直接对照线路页套餐页

结论:AI API 调用的线路选择,顺序是先定出口、再定协议、最后调超时与重试。出口固定解决风控与白名单,协议决定能不能稳定建连,超时与重试决定单次故障会不会放大成一批失败。