国内网络接入大模型 API：连接优化完整指南

国内直连 OpenAI 等境外 API 不稳定是开发者最常遇到的拦路虎：ConnectionError、超时、丢包……本文给出三种可落地的解决方案，按适用场景选用。

我见过最典型的场景是这样的：本地开发环境一切正常，curl 测试也能通，结果一部署到公司内网服务器或者某些云厂商的国内节点，requests.exceptions.ConnectionError 或者 httpx.ConnectTimeout 就开始间歇性冒出来——不是每次都挂，是那种”十次里两三次超时”的折磨人的概率性故障。这种问题最难缠的地方在于它不稳定复现，你没法靠单次测试就判断到底是代码写错了还是网络的锅。排查思路应该反过来：先用 curl -v 直接测底层连接，把 SDK 这层先剥离出去，确认是网络层还是应用层出的问题，再决定往下怎么修。

三种方案对比

方案	原理	适用场景	稳定性	成本
境外服务器代理	在海外 VPS 转发请求	个人开发/小团队	中，依赖 VPS 质量	低（VPS 费用）
聚合中转 API	使用国内已合规接入的中转平台	快速启动、团队使用	高（平台保障）	按 token 计费
自建 HTTP 代理	本地/CI 配置 HTTP_PROXY 环境变量	本地开发调试	中，需本地代理软件	低

推荐路径：个人学习可用本地代理；团队/生产环境直接用聚合中转（如力达云），省去运维成本，稳定性更高。

怎么选，说说我的判断依据。核心看三个指标：谁对连接质量负责、你能不能接受多一跳的延迟、以及你的团队有没有余力维护一套代理基础设施。个人写小工具、自己调试，本地代理最快——十分钟能配好，不用碰任何代码。团队做产品要上线，我不建议再让每个人各自配 Clash：一旦某个同事的代理挂了，线上请求跟着挂，这种”依赖某个人电脑”的架构本身就是隐患。中转平台的价值恰好在这里：把连接质量的责任转移给平台方，你只管调用接口。至于自建境外代理，我只在两种情况下推荐：一是对数据出境路径有强合规要求，必须自己掌控出口机器；二是调用量大到中转平台按 token 计费比自建 VPS 更贵的临界点——这个临界点因请求量而异，把你的月度 token 消耗成本和 VPS 月租算一笔账就清楚了。

方案一：聚合中转 API（最省事）

直接把 base_url 改为国内可用的兼容中转平台，无需任何代理配置：

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-lidayun-key",          # 中转平台 key
    base_url="https://api.lidayun.com/v1",  # 国内可达
)

优点：代码层面零改动，无网络配置负担，平台负责连接质量。

中转平台到底做了什么

别把它想得太玄乎，中转本质上是个反向代理集群：请求先打到平台在国内可访问的节点（域名走正常的国内 DNS 解析，不需要你自己折腾网络），节点再通过平台自己维护的出口链路把请求转发到 OpenAI、Anthropic 等真实的上游服务。你少做的事情，是平台在背后做了——选路由、测速、故障切换、多节点容灾。这也是为什么它的稳定性能打到”高”：平台会同时维护多条出口线路，一条挂了自动切到另一条，你这边完全无感。

代价也要看清楚：一是多一跳网络路径，延迟会比你自己搭一条专线略高（具体量级看平台节点部署位置，几十毫秒的差异很常见）；二是你的 API Key 经手了第三方，务必确认平台的日志留存政策——不留存请求正文、只留调用元数据（时间、token 数、状态码）的平台才算及格。这两点谈不上是缺点，是你选中转平台之前应该问清楚的问题，问清楚了再签合同或者充值。

方案二：配置 HTTP 代理（本地开发）

如果本地已有代理软件（如 Clash、V2Ray），可通过环境变量让 SDK 走代理：

# macOS / Linux
export HTTPS_PROXY="http://127.0.0.1:7890"
export HTTP_PROXY="http://127.0.0.1:7890"

openai-python SDK（底层用 httpx）会自动读取这两个变量，无需代码改动。

Windows PowerShell：

$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:HTTP_PROXY  = "http://127.0.0.1:7890"

验证代理生效：

curl -x http://127.0.0.1:7890 https://api.openai.com/v1/models \
  -H "Authorization: Bearer sk-xxx"

代理协议选错了，SDK 根本不认

Clash、V2Ray 背后的协议五花八门（Shadowsocks、VMess、Trojan、SOCKS5……），但 HTTPS_PROXY/HTTP_PROXY 这两个环境变量只认 HTTP 代理。如果你的代理软件对外暴露的是纯 SOCKS5 端口，直接把它塞进 HTTPS_PROXY 是不会生效的——httpx 会报 httpx.ProxyError，或者干脆连不上，报错信息还经常语焉不详，排查起来很容易怀疑到别的地方去。

排查方法：打开你的代理软件设置，确认它有没有开”HTTP(S) 代理”或”混合端口（mixed-port）“模式（Clash 的 mixed-port 同时支持 HTTP 和 SOCKS5，V2Ray 需要单独配一个 HTTP 入站）。如果你的代理只有 SOCKS5，两个选择：改代理软件配置加一个 HTTP 入站，或者装 pip install httpx[socks] 后把 base_url 换成 socks5://127.0.0.1:1080 格式——但这条路径兼容性不如老老实实开个 HTTP 端口省心。

验证代理生效后，你应该看到类似这样的返回（而不是卡住或者报错）：

{
  "object": "list",
  "data": [
    {"id": "gpt-4o", "object": "model", "owned_by": "openai"}
  ]
}

如果 curl 卡住十几秒后报 Failed to connect，先确认代理软件本身有没有正常运行——很多人踩的坑是代理软件在后台被系统杀掉进程了，界面看着开着，实际端口没监听，重启一下代理软件往往就好了。

方案三：境外服务器反向代理

在境外 VPS（香港/新加坡延迟较低）部署 Nginx 转发：

server {
    listen 443 ssl;
    server_name your-proxy-domain.com;

    # SSL 证书配置（略）

    location /v1/ {
        proxy_pass https://api.openai.com/v1/;
        proxy_set_header Authorization $http_authorization;
        proxy_set_header Content-Type $http_content_type;
        proxy_buffering off;          # 关键：流式输出不缓冲
        proxy_read_timeout 120s;
    }
}

下游只需把 base_url 改为 https://your-proxy-domain.com/v1。

注意：确保 VPS 的出口流量合规，日志不记录请求内容，并限制访问来源 IP。

proxy_buffering off 为什么是生死线

这一行最容易被忽略，但漏配的后果很直观：你会发现流式接口”看起来”能用，返回内容也对，但完全没有打字机效果——前端卡住不动，等个几秒到十几秒，然后一整段文字唰地全部弹出来。这是因为 Nginx 默认会把上游响应先攒在缓冲区里，等攒够一定大小或者上游结束才转发给客户端，SSE 依赖的”边生成边推送”就被这层缓冲吃掉了。加上 proxy_buffering off 之后，Nginx 收到一个 chunk 就立刻转发一个 chunk，流式效果才算真正打通。

VPS 选址上，别只看”香港/新加坡离得近”这种直觉判断，实际延迟取决于你所在地区到 VPS 机房之间走的国际出口线路——同样标注”香港节点”的两家 VPS，一个走 CN2 GIA 专线一个走普通线路，延迟能差出两三倍。买之前先用免费试用或者按小时计费的机型跑一次真实测试，别只信商家宣传的”低延迟”：

# 测试到目标服务器的真实链路质量（Linux/Mac）
mtr -rw -c 100 your-vps-ip
# 或者用 curl 的详细计时，分段看 DNS/连接/首字节各耗时多少
curl -o /dev/null -s -w "DNS:%{time_namelookup}s 连接:%{time_connect}s TLS:%{time_appconnect}s 首字节:%{time_starttransfer}s 总耗时:%{time_total}s\n" https://your-proxy-domain.com/v1/models

这条 curl -w 命令我基本每次排查代理延迟问题都会先跑一遍——它能把耗时拆成 DNS 解析、TCP 连接、TLS 握手、首字节四段，一眼看出瓶颈卡在哪一段。如果”连接”耗时就已经两三百毫秒，那是链路本身的问题，换节点比优化代码有用得多；如果卡在”TLS”，多半是握手环节被运营商干扰，可以试试换个端口或者协议。

流式输出连接稳定性优化

流式请求（SSE）对网络稳定性要求更高，遇到中途断流时：

import httpx
from openai import OpenAI

# 增大超时，适合长流式响应
client = OpenAI(
    api_key="sk-xxx",
    base_url="https://api.lidayun.com/v1",
    http_client=httpx.Client(
        timeout=httpx.Timeout(
            connect=10.0,    # 连接超时 10s
            read=120.0,      # 读取超时 120s（长流式）
            write=10.0,
            pool=5.0,
        )
    ),
)

重试要防的坑：流式响应不是幂等的

超时之后要不要自动重试？普通 REST 接口重试没什么心理负担，但大模型的流式生成接口有个容易被忽略的风险：如果服务端已经把请求转发给上游、上游已经开始计费生成内容，只是网络在传回给你的路上断了，这时候客户端一重试，等于让模型把同一个问题又生成了一遍——钱花了两份，用户还可能看到两段不一样的回答。

稳妥的做法是区分”重试安全”的失败阶段：

import time
from openai import OpenAI, APIConnectionError, APITimeoutError

client = OpenAI(api_key="sk-xxx", base_url="https://api.lidayun.com/v1")

def call_with_backoff(messages, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model="gpt-4o",
                messages=messages,
                timeout=30.0,
            )
        except (APIConnectionError, APITimeoutError) as e:
            # 只重试"确认没有拿到任何响应"的连接类失败
            # 已经开始接收流式数据后中断的，不要无脑重试，先记录已生成内容
            if attempt == max_retries - 1:
                raise
            wait = 2 ** attempt  # 指数退避：1s → 2s → 4s
            print(f"第 {attempt + 1} 次失败（{type(e).__name__}），{wait}s 后重试")
            time.sleep(wait)

关键在注释里那句话：只有在完全没有建立连接、没有收到任何数据的阶段失败，重试才是安全的。一旦流式响应已经开始吐字符，中途断掉的重试逻辑应该走”续写”而不是”重新生成”——把已经拿到的内容存下来，重试时告诉模型”接着刚才的内容继续写”，而不是把原始问题再问一遍。这个细节在低并发的个人项目里可能感觉不到，但线上流量一大，重复计费和内容不一致的投诉会找上门。

常见错误与排查

错误信息	可能原因	排查步骤
ConnectionError: [Errno 111]	直连被拦截或代理未启动	检查代理软件状态
ReadTimeout	网络延迟过高或响应过长	增大 read 超时，或改用中转
SSLError: certificate verify failed	代理软件的 MITM 证书未信任	导入代理 CA 证书，或设置 verify=False（仅开发）
ProxyError	代理配置格式错误	确认格式 http://host:port，勿漏协议

我还踩过一个更隐蔽的坑：ConnectionError 报的是”连接被拒绝”，但用 curl -v 单独测发现 DNS 解析出来的 IP 地址根本不对——不是 OpenAI 真实的服务器 IP，而是被污染返回的一个无效地址或者内网地址。这种情况下无论怎么调超时参数都没用，因为请求从一开始就发错了地方。排查方法很简单，用 nslookup api.openai.com 8.8.8.8 换一个境外公共 DNS 解析对比一下，如果和本地 DNS 解析出来的结果不一致，基本可以确认是 DNS 层被动了手脚，这时候换代理或者中转平台是唯一靠谱的解法，改 hosts 文件只能临时顶一顶（上游 IP 会变，顶不了多久）。

常见问题

Q：CI/CD 流水线中如何配置代理？ 在 GitHub Actions 等 CI 平台的 Secret 中存储代理地址，通过 env 注入 HTTPS_PROXY，或直接在 CI 机器所在地区（如境外 Runner）运行，避免代理依赖。

Q：使用中转平台数据安全吗？ 选择有明确隐私政策、不存储请求内容的平台。如有敏感数据，优先自建境外代理或选择具备数据合规证明的商业服务。

Q：streaming 流式请求比非流式更容易超时吗？ 是的，流式请求占用连接时间更长。建议为流式场景单独配置更大的 read_timeout，并在代理/Nginx 层关闭响应缓冲（proxy_buffering off）。

Q：怎么判断我现在的连接慢，到底是代理的锅还是模型本身生成慢？ 用前面 curl -w 的分段计时先测一次裸连接（不带模型调用，测 /v1/models 这种轻量接口）。如果这个都要一两秒，问题在网络链路；如果裸连接很快，调用 chat.completions 才慢，那多半是模型生成 token 本身耗时（尤其长上下文或者复杂推理），跟代理没关系，这时候该优化的是 prompt 长度或者换更快的模型，而不是继续折腾代理配置。

Q：手头有多个境外节点，该按什么顺序切换？ 别按”哪个免费”排序，按你实测的真实延迟和丢包率排。自己写个几行的健康检查脚本，每隔几分钟对每个候选节点跑一次 curl -w 计时，把结果记下来，一周之后你会发现某个”听起来很快”的节点其实延迟波动很大，反而是不起眼的节点更稳。生产环境宁可选延迟稍高但抖动小的线路，也别选延迟低但时不时抽风的。

这三条路没有绝对的对错，只有当下最匹配你处境的选择。手头紧、就自己一个人写代码，配置本地代理十分钟搞定；要对团队和用户负责、经不起某个人代理掉线的风险，中转平台把这份责任转移出去更划算；数据合规卡得死、必须自己掌控出口机房，就沉下心把境外代理这条路走扎实。真到了拿不准的时候，先把 curl -w 那行命令跑一遍再做决定，数字不会骗你。

---

延伸阅读：大模型 API 接入完全指南 · 接入教程 Hub · 改 base_url 切换 OpenAI 兼容接口 · 国内大模型平台横向对比