AI API 呼叫要用哪種 VPN,判斷標準不是「哪個節點測速最快」,而是三件事:出口 IP 是否固定、並行連線是否穩定、失敗之後能不能乾淨地重試。網頁聊天裡一次卡頓只是轉圈兩秒,腳本裡一次逾時可能讓整批任務重跑;而為了重試隨手換一個節點,出口 IP 一變,又可能觸發對方的風控。下面把這三件事拆開來講,再給一份可以直接照抄的設定。
網頁聊天和 API 呼叫,網路需求不一樣
在網頁裡和模型對話,客戶端通常維持一到兩條長連線,斷線由前端自動重連,人對幾百毫秒的抖動幾乎沒有感覺。腳本呼叫是另一套模型:每次請求都要走一遍網域名稱解析、TCP 握手、TLS 握手,拿到回應後連線可能立刻被回收;一批任務裡幾十上百次請求同時發生,任何一次建連失敗都會以例外的方式落到程式碼裡,而不是變成介面上的一個轉圈動畫。
| 比較項目 | 網頁聊天 | 程式呼叫 API |
|---|---|---|
| 連線模式 | 少量長連線,SSE / WebSocket 串流回傳 | 大量短連線,反覆建連 |
| 失敗感知 | 介面轉圈,由前端自動重連 | 拋出例外或逾時,由重試邏輯決定結果 |
| 出口要求 | 能連上、能維持即可 | 通常要求出口 IP 穩定,方便白名單與排查 |
| 敏感指標 | 首位元組時間 | 建連成功率與延遲抖動 |
| 典型任務 | 一問一答 | 批次生成、向量化、排程任務 |
這張表解釋了一個常見困惑:同一台機器上網頁能打開,腳本卻頻繁逾時。網頁走的是一條已經建好的長連線,腳本每次都要重新建連,後者對線路抖動的暴露面大得多。所以「能打開網頁」不足以證明一條線路適合跑 API。
三類線路怎麼挑:專線、中轉與直連
把線路按路徑粗分,常見三類:IEPL 專線、中轉、直連。名字只是標籤,路徑才決定表現:資料從哪裡出境、中間經過幾跳、是否和一般流量擠同一個出口。
| 線路類型 | 路徑特徵 | 表現 | 適合的 API 情境 |
|---|---|---|---|
| IEPL 專線 | 國際專線直連,不繞公網出口 | 延遲穩定、抖動小 | 串流輸出、互動式對話、長連線任務 |
| 中轉 | 先接入中轉節點,再由中轉出境 | 品質取決於中轉節點,波動中等 | 可重試的批次任務、離線作業 |
| 直連 | 本地網路直接出境 | 受本地出口影響大,晚高峰明顯 | 備用線路、低頻呼叫 |
分流思路是「按網域分配線路」:把 api.openai.com、api.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.com、api.anthropic.com等走專線,其餘直連。 - ✅ DNS 與請求走同一條線路:開啟客戶端的遠端解析,避免網域被解析到就近節點。
- ✅ 兩類逾時分開設定:連線逾時幾秒,讀取逾時按串流回應的最長時間留足。
- ❌ 全域代理忘了
NO_PROXY:內網網域和本地服務也被繞出去,表現為「介面突然 502」。 - ❌ 用「自動選擇節點」:每次重連換一個出口 IP,伺服器看到的是多個來源。
- ❌ 用 ping 判斷線路好壞:ICMP 通不代表 TLS 握手能成功,要看
time_connect和time_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連跑十幾次,看 connect 與 tls 兩欄的波動,而不是看絕對值。波動很小,說明這條線路適合放互動式請求;如果偶爾出現幾秒的尖峰,基本可以判斷節點在切換或者本地出口在抖動,這類線路只適合放可重試的批次處理。
DNS 洩漏的典型症狀是「能連上但很慢」或者「同一個網域時快時慢」。如果客戶端只代理 TCP 流量、把 DNS 交給本地解析器,解析結果可能指向離你最近的節點,而不是離出口最近的節點。排查方式是在客戶端日誌裡確認網域解析是否走了代理,並把分流規則涵蓋到 DNS 查詢本身。
開發者常見問題速答
只在本機開發,也要專門配線路嗎?
要。開發機上的建連方式和線上沒有差別,差別只在並行量。本地就把分流規則和逾時參數調好,上線時才不會出現「本地一切正常、伺服器上全是逾時」的情況;反過來,如果本地是靠全域代理湊合跑通的,那套設定基本上沒辦法搬到伺服器上。
請求偶爾逾時,直接重試就好嗎?
先分清是哪一類逾時。連線逾時說明線路或連接埠有問題,重試大概率還是失敗,應該先換線路;讀取逾時往往是串流回應太長,先調大讀取逾時,再考慮重試。把兩類逾時的次數分別打點,比籠統記錄一個「失敗率」有用得多。
一個訂閱夠幾台機器用?
VPNEM 不限裝置數同時在線,開發機、測試機和 CI runner 可以共用同一個訂閱,前提是出口策略一致:要嘛都固定到同一個節點,要嘛按專案分開帳號,不要把多個出口混在同一個帳號上。
怎麼判斷一條線路是不是真的專線?
不看名字看數據。連續取樣 time_connect,專線的曲線應該接近一條水平線;如果晚高峰出現規律性抬升,那更接近直連或者品質一般的中轉。VPNEM 的線路頁標了每條線路的類型,可以拿實測曲線和標註互相印證。
如果正在挑服務,可以先把這幾項問清楚:是否不記錄日誌、退款期間有多長、開通是否需要電子郵件地址、付款方式是否順手。VPNEM 在這幾項上的做法是:不記錄日誌、60 天無理由退款、開通無需電子郵件地址,付款支援支付寶、微信與 USDT;線路與套餐明細可以直接對照線路頁和套餐頁。
結論:AI API 呼叫的線路選擇,順序是先定出口、再定協定、最後調逾時與重試。出口固定解決風控與白名單,協定決定能不能穩定建連,逾時與重試決定單次故障會不會放大成一批失敗。