進行 AI API 串接 VPN 實測比較時，先確認請求是否經過預期出口，再比較並發與逾時。網頁版能開啟，不代表開發環境也使用相同線路。選線應依據實際 API 呼叫結果、串流回應是否連續及錯誤類型，而不是只看節點測速。
本文提供可重複使用的測試方法與判斷標準，不提供未經測量的效能排名，也不將特定線路名稱視為存取保證。目標平台的地區政策、帳戶權限與呼叫額度仍須另外確認；網路連線無法取代這些條件。
固定出口：先區分地址穩定與專用
固定出口是指在一段使用期間內，請求對外顯示的公網 IP 位址維持穩定；專用出口則關乎該位址是否與其他使用者共用。兩者並不相同。共用位址可能長期不變，專用位址也可能因維護或調整而更換。節點名稱沒有變，也不能證明公網出口未變。
對於需要維護來源 IP 白名單的業務，出口變更會直接影響呼叫。一般互動式開發未必需要專用位址，但頻繁切換地區可能讓問題排查更加複雜。如果請求在不同地區的出口之間來回切換，就難以判斷失敗是來自線路、帳戶政策，還是目標平台的地區限制。
實際檢查時，先選擇節點並關閉自動切換，再透過與 API 請求相同的執行環境及代理設定檢查出口。記錄網路重新連線、用戶端重新啟動及重新選擇節點後的變化。瀏覽器中的 IP 檢測只能顯示該瀏覽器請求的出口，不能直接證明容器、終端機或遠端伺服器使用相同路徑。
線路比較：中轉、直連與專線該看什麼
直連通常是指用戶端直接連線至境外節點；中轉則是在路徑中加入轉送入口；IEPL 專線通常描述特定跨境傳輸區段的承載方式。這些方式會影響網路路徑，但不會直接決定目標平台所見的出口位址屬性，也不保證在所有電信業者、時段及目的地都呈現相同效能。
下表比較的是測試項目，並非測速結果。比較時應維持模型、請求內容、輸出限制及執行環境一致，只更換線路。否則，較短的回答、較輕量的模型或本機快取，都可能被誤認為線路較快。
| 比較對象 | 主要觀察項目 | 無法直接推論的結論 |
|---|---|---|
| 直連線路 | 本機至節點的連線建立、封包遺失及時段變化 | 跳數較少不代表實際呼叫較快 |
| 中轉線路 | 入口可連線性、中轉壅塞及長連線連續性 | 有中轉不代表出口固定 |
| 標示 IEPL 的線路 | 承載範圍、繁忙時段的表現及實際 API 完成情況 | 專線標示不代表專用位址或 API 必定可用 |
| 同一地區的不同節點 | 出口是否變更、API 回應及錯誤類型 | 位於同一地區不代表出口或上游路徑相同 |
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 是用戶端與節點之間使用的代理協定或傳輸方案，不是 AI API 本身的協定。協定名稱不能取代端對端測試，實際相容性則以訂閱提供的節點設定及用戶端支援情況為準。請勿為了比較協定而自行猜測節點參數。
實測步驟：先循序測試，再逐步增加並發
循序測試用來建立基準，並發測試則用來找出負載開始造成影響的位置。開始前請關閉無關下載，並記錄本機網路、節點名稱、用戶端模式、SDK 版本及模型名稱。測試內容應使用可公開的範例，避免將業務資料寫入除錯記錄。
- 確認 API 使用資格。核對 API 金鑰、專案權限、帳戶額度及地區政策。先讀取錯誤回應；驗證失敗時，請勿連續更換節點。
- 確認代理設定生效。檢查 SDK 是否接受明確指定的代理設定，或是否讀取目前程序的代理環境變數。開啟系統代理不代表所有命令列程式都會遵循。
- 完成循序請求。使用相同輸入，分別觀察非串流呼叫是否完整回傳、串流呼叫是否正常結束，並保存目標平台回傳的請求識別碼。
- 逐步增加並發。透過應用程式內的並發佇列限制同時進行中的請求數，其他條件維持不變。出現錯誤後先停止增加負載，區分 API 限流與本機連線池等待。
- 更換線路後重新測試。維持測試條件一致，並在實際工作時段重複檢查。記錄成功、失敗及主動取消的結果，避免只保留成功樣本。
建議記錄連線各階段耗時、收到回應標頭的時間、第一段有效內容抵達的時間，以及完整結束時間。這些並非相同指標。第一個網路位元組可能只是回應標頭或串流心跳，不代表模型已開始輸出內容；工具呼叫事件也不應直接視為使用者可讀文字。
增加並發後，如果回應明確指出速率或額度限制，應依平台文件安排請求，而不是將問題歸咎於線路。如果請求尚未送出就長時間等待，請檢查應用程式佇列、連線池上限及連線釋放情況。只有出現連線建立失敗、連線重設或串流中斷等證據時，才應進一步排查網路。
逾時設定：分開處理連線、讀取與總截止時間
連線逾時控制建立連線時的等待時間；讀取逾時通常限制等待下一段資料的間隔；總截止時間則限制整個工作可持續的時間。具體定義取決於 SDK 與底層 HTTP 函式庫；有些介面只提供統一的逾時設定，有些則另外區分連線池等待時間。不同函式庫中名稱相似的參數，不能直接照搬。
串流生成時尤其要區分「持續收到資料」與「工作已完成」。模型推論、工具執行或上游排隊都可能造成間隔；讀取逾時設得太短會中斷正常請求，但無限延長逾時又會占用連線與並發名額。應依據實測間隔、業務可接受的等待時間及平台說明設定，而不是套用通用秒數。
讀取串流時，應依照所用 API 的事件格式解析，不能假設每次網路讀取都會剛好取得完整事件。伺服器傳送事件串流可能橫跨多個資料區塊，也可能將多個事件放在同一區塊。用戶端必須正確串接資料、辨識協定定義的結束狀態，並在完成、發生錯誤或取消後釋放回應物件。
僅針對適合重試的暫時性錯誤重試，採用加入隨機抖動的退避策略，並遵守伺服器提供的等待提示。驗證失敗、參數不合法及不支援該地區等問題，無法靠重複傳送解決。串流內容已部分顯示後，也不能直接把重試結果接在後面，否則可能出現重複文字或重複執行工具操作。
分流與環境：為何瀏覽器可用，終端機卻失敗
常見原因是瀏覽器遵循系統代理，但 SDK 所在的程序沒有使用代理。環境變數只會影響能讀取這些變數的程式；已在執行中的程序也未必會取得之後的變更。遠端開發環境、容器及持續整合工作各自有獨立的網路環境，本機用戶端不會自動接管遠端伺服器的流量。
先確認實際執行 API 呼叫的是哪個程序，再檢查該程序的代理設定。容器中的本機迴圈位址指向容器本身，不一定能連上主機的代理。若需開放代理監聽，應限制存取範圍並設定必要的驗證，避免本機代理成為外部可任意使用的入口。
依網域分流時，至少要核對 API 網域的比對結果；驗證、上傳及工具資源若使用其他網域，也應依實際需求檢查。請勿長期將整個開發環境切換至全域模式來掩蓋規則問題，也不要用過於寬泛的規則涵蓋內部業務網域。
- ✅ 在實際執行 SDK 的環境中檢查出口，不要只檢查瀏覽器。
- ✅ 查看規則命中情況及連線記錄，確認 API 請求選用了預期節點。
- ✅ 檢查 DNS 解析路徑；代理連線與網域解析可能使用不同路徑。
- ✅ 核對直連例外設定，避免目標網域被代理排除規則略過。
- ❌ 不要關閉 TLS 憑證驗證來避開連線錯誤，也不要將金鑰寫入公開記錄。
DNS 洩漏是指網域查詢透過非預期的解析路徑送出，不等同於 API 明文洩漏，也不一定代表請求繞過代理。應搭配用戶端解析設定、遠端解析能力及連線記錄判斷。若出現憑證錯誤，請檢查系統時間、憑證鏈及受管理網路的代理要求，不要直接略過驗證。
選線結論：依故障證據與業務需求決定
互動式開發應優先觀察第一段有效內容的等待時間及串流連續性；批次工作應優先檢查完成情況、限流後的恢復能力及佇列穩定性；使用來源 IP 白名單的業務則應先確認出口條件。下載測速只能作為參考，無法取代實際 API 測試，也無法判斷長時間生成是否會中斷。
使用 VPNGift 時，可先登入控制台取得訂閱，再匯入支援該訂閱格式的用戶端、更新設定並選擇節點。訂閱連結包含存取憑證，不應提交至程式碼儲存庫或附在公開客服單中。用戶端安裝與匯入方式可參考使用教學，線路資訊以線路清單及控制台為準。
VPNGift 不限制同時上線的裝置台數，但這不代表 AI 平台允許無限並發，也不會改變平台的請求或 Token 額度。選擇方案時，請依實際請求與回應流量評估：月訂閱流量每月於開通日重設，流量包用完為止，永久不過期。請勿將節點數量、裝置政策或方案流量直接換算成 API 吞吐量。