同一條線路,網頁打得開、API 卻逾時,是開發者回報最多的一類情況。原因通常不在「通不通」,而在「撐不撐得住」:網頁請求很快結束,一次 API 呼叫卻可能持續輸出很久;網頁失敗使用者會重新整理,API 失敗程式只會重試或報錯。所以判斷一條線路適不適合跑 API,要看的不是峰值速度,而是抖動、出口穩定性與長連線的維持能力。

本文不給測速截圖。線路表現隨時段與地區變化,別人截圖裡的數字對你沒有參考價值;下面給的是可重現的測法與判斷標準,你可以直接在自己的網路環境跑一遍。

網頁能開、API 逾時,差在哪三步

把一次 API 呼叫拆開,鏈路上有四段:網域名稱解析、TCP 連線、TLS 握手、等待首個位元組與後續資料。網頁存取這四段都短,而且靜態資源通常有就近接入;API 端點往往只有一個網域,不做就近,四段全部壓在你連出去的那條線路上。任何一段出現排隊,用戶端看到的結果都是先逾時。

串流回傳會把這個問題放大。SSE 把一次回應拆成很多小段陸續送出,中間任何一跳做了緩衝,用戶端看到的就是「卡住不動」,直到讀取逾時。所以判斷這類問題,要看首個位元組時間與兩次資料之間的間隔,而不是總耗時。

先把「能不能通」和「穩不穩」分開測:一次請求只說明當下通,連續多次取樣才說明線路的性格。記錄時把解析、連線、握手、首個位元組、總耗時分成五項,出問題才知道卡在哪一段。

三種線路形態:直連、中轉與專線

同樣寫著「加速」,底下的實體路徑可能完全不同。常見的三種形態如下,這裡只做定性比較,不含測速數字:

三種線路形態的差別(定性比較,不含測速資料)
形態 流量大致怎麼走 抖動與丟包 固定出口 適合的呼叫方式
直連 本地直接連到海外節點,全程走公網國際出口 晚高峰波動明顯 看節點分配方式 除錯、輕量請求
中轉 先到就近入口,再經隧道出境到節點 比直連平穩,取決於入口品質 多數可以固定 一般 API 呼叫
IEPL 專線 本地到入口後走專用鏈路出境,不經過公網國際出口的壅塞點 通常更小 容易固定 長連線、串流輸出、批次併發

直連最省成本,也最看運氣:整條路徑都走公網國際出口,晚高峰的壅塞會直接傳導到 API 呼叫上。中轉把「最後一哩」換成就近入口,出境這一段走隧道,穩定性取決於入口品質與隧道本身。IEPL 專線是第二層專線,不走公網國際出口的壅塞點,抖動通常更小,代價是價格更高、可選地區更少。

下單前值得問清四件事:入口在哪個城市、出口位址是否固定、你買的那個方案具體屬於哪種形態、線路故障時怎麼切換。很多「加速」說法經不起這四問。

小結:路徑決定抖動與出口穩定性,協定只決定握手開銷與弱網表現。先定路徑,再談協定。

固定出口:API 呼叫最先要確認的一項

網頁瀏覽不在乎出口位址變不變,API 呼叫很在乎。原因有四類:

  • 白名單。不少平台支援把呼叫來源位址加進白名單,出口一變,請求直接被拒。
  • 工作階段一致性。部分服務把工作階段和來源位址綁定,位址漂移會觸發二次驗證或限流。
  • 排障。出口固定,日誌裡「這條請求從哪出去」才有唯一答案;出口亂跳,對齊日誌就是體力活。
  • 團隊共用。多台開發機各自連出去,出口是散的;換成一台海外閘道加一條穩定隧道,出口收斂成一個,規則也好寫。

固定出口不等於獨享出口。共享出口上如果還有別的高頻請求,目標網站的限流可能落到你頭上,表現是一段時間內 API 頻繁回傳限流錯誤,而你的程式什麼都沒改。

對穩定性敏感的呼叫,下單前問清兩件事:出口是共享還是獨享,重新連線之後位址會不會變。這兩個答案比任何速度描述都重要。

併發與逾時:兩個最容易設錯的地方

併發按「同時開啟的流」算,不是按 QPS 算

HTTP/2 的多工讓多個請求共用一條連線,看起來可以隨意併發。但伺服器與中間節點都有併發流上限,超過之後請求在佇列裡排隊,首個位元組時間被拉長,最後一樣表現成逾時。串流 API 更要注意:一個請求在輸出結束前一直佔著連線,併發數要按同時開啟的流來算。

用戶端的連線池也不要開太大。連線池的意義是重複使用,不是堆數量;連線數超過線路承載,只會讓每條連線都變慢。批次任務用佇列加限速,把併發控制在「能穩定拿到首個位元組」的範圍內,比事後調逾時更有效。

逾時分三層設,不要一個數字管到底

  • 連線逾時涵蓋 TCP 與 TLS 握手。這一段失敗代表路徑不通,應該換線路,而不是把時間加長。
  • 首個位元組逾時涵蓋伺服器排隊與準備時間,要給足餘裕;它和連線逾時是兩回事。
  • 讀取逾時對串流回應要按「兩次資料之間的間隔」算,不要用總時長卡死長輸出。
  • 重試只對冪等請求或明確未受理的錯誤做;生成類請求盲目重試會重複消耗額度。
  • 退避用指數退避加隨機抖動,避免整批任務在同一秒一起重連。

先用命令列把五段時間量出來,再決定調哪個參數:

curl -o /dev/null -s \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  "$API_BASE/v1/models"

用戶端把連線與讀取分開設,是成本最低的一步:

import httpx

# 這裡的數值只是起點,請依自己的鏈路情況調整
timeout = httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=5.0)

with httpx.Client(timeout=timeout, http2=True) as client:
    with client.stream("POST", f"{base}/v1/chat/completions", json=payload) as resp:
        resp.raise_for_status()
        for line in resp.iter_lines():
            handle(line)

協定怎麼選:六種常見協定的差別

協定不是第一順位,但會決定握手開銷與弱網表現。下面這張表只講差別,不排誰「最強」:

常見協定的傳輸基礎與注意事項
協定 傳輸基礎 特點 需要注意
Shadowsocks TCP / UDP,類 SOCKS5 語意 輕量,握手開銷小 無內建多工,高併發時連線數偏多
VMess TCP,可套 TLS 或 WebSocket 生態成熟,設定項多 標頭開銷比 VLESS 大
VLESS TCP 加 TLS,可搭配 XTLS 或 uTLS 本身不做加密,開銷低 安全性完全依賴 TLS,設錯等於裸奔
Trojan TLS,偽裝成一般 HTTPS 流量 與 443 埠流量混同,不易被單獨識別 依賴憑證,憑證出問題會直接連不上
Hysteria2 QUIC,走 UDP 抗丟包,弱網下吞吐表現好 UDP 可能被限速,要能切回 TCP 系
TUIC QUIC,走 UDP 連線建立快,支援連線遷移 體驗取決於電信商對 UDP 的處理

幾條實用判斷:走 TCP 的協定對中間設備較友善,走 QUIC 的協定在丟包明顯的鏈路上體驗更好,但依賴 UDP,遇到限速要能切回 TCP 系。VLESS 本身不做加密,安全性完全交給 TLS;Trojan 依賴憑證,自動續期沒做好就會在某天突然連不上。選用戶端已經支援、維護活躍的那個,比追新更實際。

用戶端與訂閱:平台差異會直接影響排查

  • Windows 與 macOS:系統代理只涵蓋會讀取系統設定的程式。命令列工具和不少 SDK 不讀系統代理,要嘛設定 HTTPS_PROXY 環境變數,要嘛用 TUN 模式接管全部流量。
  • Linux:沒有系統代理這一層,靠環境變數或 TUN 加原則路由。在容器裡跑任務時注意代理變數不會自動帶進去。
  • 分流規則:給 API 網域單獨寫一條規則,避免被大範圍規則誤傷。DNS 解析方式要和分流一起看,否則網域解析結果和實際出口對不上,排障時會誤判。
  • 訂閱匯入:訂閱連結本質是一份節點清單,用戶端定時拉取更新。換用戶端時優先匯入同一份訂閱,不要手工抄節點,抄漏一個參數就會出現「連得上但跑不通」。

命令列工具不讀系統代理是常見的坑。先確認環境變數或 TUN 模式已經生效,再判斷是不是線路的問題,能省掉一半排查時間。

選型清單:先看能核對的,再看說法

選服務時,先看能核對、不依賴主觀感受的項目。下面四項是本站公開的參數,可以直接對照:

120+ 覆蓋國家
180+ 線路總數
7 天 無理由退款
不限 同時在線裝置數
  • ✅ 用命令列把解析、連線、握手、首個位元組、總耗時分開記錄,分時段取樣多次,看抖動而不是看最快的一次。
  • ✅ 反覆重新連線後請求一個回顯位址的 API,確認出口沒有變。
  • ✅ 連線逾時與讀取逾時分開設,串流 API 單獨放寬讀取逾時。
  • ✅ 批次任務走佇列,限制同時開啟的流數量。
  • ✅ 分流規則裡把 API 網域單獨列出,並確認 DNS 解析方式與規則一致。
  • ✅ 換用戶端時匯入同一份訂閱,並確認節點清單能正常更新。
  • ❌ 拿網頁開啟速度推斷 API 表現。
  • ❌ 用一個總逾時管住所有請求,尤其是串流回應。
  • ❌ 對生成類請求無腦重試。
  • ❌ 以為連上了就等於所有程式都走了這條線路。

還有兩點屬於常識、卻經常被忽略。退款條款要在下單前看清楚,本站是 7 天無理由退款,足夠跑完一輪自己的測試;付款方式上支付寶、微信、USDT 都支援,團隊採購走哪種都能對上帳。註冊只需要使用者名稱和密碼,不需要電子郵件地址,少填一項就少一層顧慮。

結論:順序比參數重要

結論:選 AI API 加速,順序是先確認出口是否固定,再看線路形態是否匹配你的併發模型,最後才調用戶端的逾時與重試。前三項錯了,後面怎麼調都是在補破洞。

如果只記一條:把「能不能通」和「穩不穩」分成兩次測試,把連線、首個位元組、讀取三段逾時分開設。這兩件事做完,大部分「API 總是逾時」的抱怨會自己消失。