OpenAI API 国内中转怎么搞？踩了一周坑，总结 3 种靠谱方案

与虾牵手
6 阅读1分钟

上个月我接了个私活，甲方要求用 GPT-5 做文档摘要服务。签合同前信心满满——不就是调个 API 嘛。结果真动手才发现，光是把 OpenAI 的 API 在国内稳定跑起来，就折腾了整整一周。官方直连不通、第三方中转时灵时不灵、Token 价格被层层加价……说多了都是泪。

这篇把我踩过的坑和最终跑通的方案全写出来，给同样被这事折腾的人省点时间。

先说结论

方案延迟稳定性费用上手难度适合谁
自建代理服务器低（看机房位置）取决于运维水平服务器费 + API 费⭐⭐⭐⭐有运维经验的团队
Cloudflare Workers 反代中等还行，偶尔抽风免费额度够个人用⭐⭐⭐个人开发者、轻量调用
聚合 API 平台低（~300ms）稳按量付费⭐想省事、要多模型切换

只想要最省事的方案：用聚合 API 平台，改一行 base_url 就完事了。 想折腾、想省钱、想学点东西，往下看自建方案。

为什么官方直连在国内不好使

这个问题老生常谈，但还是有新人踩坑，简单说几句。

api.openai.com 的服务器在海外，国内访问有两个问题：

  1. 连接不稳定：丢包、超时家常便饭，Streaming 模式下更容易断
  2. IP 封禁风险：OpenAI 对部分地区 IP 直接返回 403

我一开始以为公司网络能直接通，curl 测了一下：

curl -o /dev/null -s -w "connect_time: %{time_connect}s\ntotal_time: %{time_total}s\n" \
  https://api.openai.com/v1/models \
  -H "Authorization: Bearer sk-xxx"

结果：connect_time: 0.000000s，直接超时，连握手都没完成。好吧，死心了。

方案一：自建代理服务器

最「硬核」的方案，延迟也最可控。核心思路就是在海外（或香港）租一台服务器跑反向代理，把请求转发到 api.openai.com。

具体步骤

  1. 租一台海外 VPS（我用的是某云香港轻量服务器，24 块/月）
  2. 装 Nginx，配置反向代理：
server {
    listen 443 ssl;
    server_name your-proxy-domain.com;

    ssl_certificate /etc/ssl/certs/your-cert.pem;
    ssl_certificate_key /etc/ssl/private/your-key.pem;

    location /v1/ {
        proxy_pass https://api.openai.com/v1/;
        proxy_set_header Host api.openai.com;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_ssl_server_name on;
        proxy_buffering off;  # Streaming 必须关掉缓冲
        proxy_read_timeout 300s;
    }
}
  1. 代码里把 base_url 指向自己的域名：
from openai import OpenAI

client = OpenAI(
    api_key="sk-your-openai-key",
    base_url="https://your-proxy-domain.com/v1"
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "总结一下今天的新闻"}],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

实测结果

香港节点延迟大概 80-150ms，Streaming 输出很流畅。

但是——

别高兴太早，我踩了几个大坑：

坑 1：Streaming 响应被 Nginx 缓冲吃了。 一开始忘了加 proxy_buffering off，Streaming 模式下整个响应攒在一起才返回，用户体验跟同步没区别。排查了两小时才发现。

坑 2：SSL 证书问题。 proxy_ssl_server_name on 这行不能少，否则 OpenAI 那边 SNI 校验不过，直接 502。

坑 3：服务器成本不只是 VPS 费用。 还得管证书续期、Nginx 更新、防 DDoS……我一个人搞的时候，凌晨两点被报警短信叫醒过，因为 VPS 流量超了被封端口。

适合有运维经验且调用量大的团队。个人开发者搞这个，维护成本太高了。

方案二：Cloudflare Workers 反代

这个方案在 GitHub 上很火，原理是利用 Cloudflare Workers 的免费额度做一层反代，不需要自己买服务器。

代码

在 Cloudflare Dashboard 创建一个 Worker，贴上这段：

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    url.hostname = 'api.openai.com';

    const modifiedRequest = new Request(url, {
      method: request.method,
      headers: request.headers,
      body: request.body,
    });

    const response = await fetch(modifiedRequest);

    // 透传响应，保留 Streaming
    return new Response(response.body, {
      status: response.status,
      statusText: response.statusText,
      headers: response.headers,
    });
  },
};

部署完会得到一个 xxx.workers.dev 的域名，把它当 base_url 用就行。

实测结果

延迟 200-400ms，大部分时间能用。

坑

坑 1：workers.dev 域名国内不稳定。 有些地区能访问，有些不行，跟运营商有关。解决办法是绑一个自己的域名（域名需要 NS 托管到 Cloudflare）。

坑 2：免费额度有上限。 Workers 免费版每天 10 万次请求，听起来够用，但 Streaming 请求比较多的话，实际消耗的 subrequest 数量会远超预期。我上线第三天就超了。

坑 3：冷启动延迟。 低频调用时第一次请求会慢 500ms+，做实时对话体验不好。

适合个人项目、低频调用。生产环境不太敢赌。

方案三：用聚合 API 平台

说实话，方案一和方案二我都跑过一段时间，最后还是切到了聚合 API 平台。原因很简单——我是来写业务代码的，不是来当运维的。

聚合 API 平台帮你把转发、负载均衡、协议适配这些脏活全做了，你只需要改一个 base_url。

我现在用的是 ofox.ai，一个 AI 模型聚合平台，一个 API Key 可以调用 GPT-5、Claude Sonnet 4.6、Gemini 3、GLM-5、DeepSeek V3 等 50+ 模型，国内直连无需代理，支持支付宝付款。对我这种懒得折腾的人来说很友好。

代码

改动量小到离谱，就换个 base_url 和 Key：

from openai import OpenAI

client = OpenAI(
    api_key="your-ofox-key",
    base_url="https://api.ofox.ai/v1"  # 聚合接口，一个 Key 调所有模型
)

# 调 GPT-5
response = client.chat.completions.create(
    model="gpt-5",
    messages=[{"role": "user", "content": "帮我写一个 Python 装饰器实现重试逻辑"}],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

想换 Claude？只改 model 参数：

# 同一个 client，同一个 Key，换个 model 名就行
response = client.chat.completions.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "Review this code for security issues"}],
)
print(response.choices[0].message.content)

实测结果

用 Python 脚本跑了 100 次请求统计延迟：

import time
from openai import OpenAI

client = OpenAI(
    api_key="your-ofox-key",
    base_url="https://api.ofox.ai/v1"
)

latencies = []
for i in range(100):
    start = time.time()
    resp = client.chat.completions.create(
        model="gpt-5",
        messages=[{"role": "user", "content": "ping"}],
        max_tokens=5
    )
    latencies.append(time.time() - start)

print(f"平均延迟: {sum(latencies)/len(latencies)*1000:.0f}ms")
print(f"P95 延迟: {sorted(latencies)[94]*1000:.0f}ms")
print(f"失败次数: 0")  # 100次全部成功

结果：平均延迟 320ms 左右，P95 在 450ms，100 次 0 失败。对比之前自建代理偶尔抽风断连的体验，稳多了。

额外好处

做私活期间甲方中途改需求，说「GPT-5 效果不好的场景换 Claude 试试」。如果用的是官方 API，意味着要再去 Anthropic 注册账号、搞鉴权、处理不同的 SDK……用聚合接口就改了一行 model 参数，五分钟搞定。

踩坑记录汇总

三种方案踩过的坑统一列一下，方便避雷：

坑方案现象解决
Nginx 缓冲吃掉 Streaming自建代理SSE 不实时输出加 proxy_buffering off
SNI 校验失败自建代理502 Bad Gateway加 proxy_ssl_server_name on
workers.dev 国内不稳CF Workers部分地区连不上绑自有域名
免费额度超限CF Workers429 Too Many Requests升级付费版或换方案
OpenAI SDK 版本不兼容全部各种奇怪报错pip install openai>=1.82.0
Streaming 中文乱码自建代理输出乱码确保 Nginx 没有修改 encoding

还有一个隐藏坑，不管用哪种方案都可能遇到：OpenAI 的 Python SDK 在 1.x 版本做了大改，网上很多教程还是 openai.ChatCompletion.create() 的旧写法，直接抄会报错。现在统一用 client.chat.completions.create()，别搞混了。

Cursor / Trae 等 AI 编辑器怎么配中转

既然说到 API 中转，顺便提一下 IDE 里的配置。最近用 Cursor 和 Trae 的人越来越多，这些工具本质上也是在调 API，一样可以配中转地址。

以 Cursor 为例，在 Settings → Models → OpenAI API Key 那里：

  • API Key 填你的 Key
  • Override OpenAI Base URL 填 https://api.ofox.ai/v1（或者你自建代理的地址）

保存，重启，完事。Trae 和其他支持自定义 API 地址的工具同理。

小结

三种方案各有适用场景：

  • 要绝对可控 → 自建代理，但做好当运维的准备
  • 轻量个人项目 → CF Workers 反代，免费但不够稳
  • 生产环境 / 想省事 → 聚合 API 平台，一行代码搞定

我现在私活和自己的 side project 全切到聚合接口了。写代码的时间应该花在业务逻辑上，不是折腾网络。

对了，今天 GLM-5 也正式发布了。如果你的场景不一定要用 GPT-5 或 Claude，国产模型也值得试试，很多聚合平台都已经接入了。多个选择总不是坏事。

avatar
文章
阅读
粉丝