呼叫 OpenAI 與 Claude API 時，VPN 推薦不能只看網頁能否開啟。瀏覽器聊天通常是單一前台工作階段，而程式呼叫會連續建立連線、重複使用連線池、等待串流回應，也可能由任務佇列同時送出請求。線路出口切換、代理只接管瀏覽器、DNS 與資料流向不一致，都會造成「網頁正常但 API 失敗」的錯覺。
本次核對聚焦固定出口、並發傳輸、長請求維持與用戶端分流，不採用脫離裝置、地區及請求內容的單一測速數值。頻寬峰值高不代表串流生成穩定，短連線回應快也不代表長請求不會被中間設備提前回收。開發者應記錄完整請求鏈路，而不是只保留一次延遲截圖。
先區分網頁存取與 API 呼叫
網頁聊天的請求由瀏覽器送出，通常會經過系統代理或瀏覽器繼承的代理設定。開發腳本則可能執行於終端機、容器、編輯器外掛、背景服務或持續整合環境。它們是否讀取系統代理，取決於執行環境、網路函式庫與啟動參數。瀏覽器已顯示線路出口，並不能證明命令列程序也走相同路徑。
驗收時應分別檢查瀏覽器、終端機程式、容器與遠端執行環境。若腳本在遠端主機執行，本機桌面用戶端不會自動接管遠端流量；若程式位於容器內，主機的系統代理也未必會被繼承。此時需要在應用程式網路函式庫中明確設定代理，或讓容器透過受控閘道轉送。
- ✅ 分別核對瀏覽器與實際執行 API 程式的程序出口。
- ✅ 檢查 SDK 使用的網路函式庫是否讀取系統代理與環境設定。
- ✅ 分開測試串流與非串流請求，不以短回應取代長連線驗收。
- ✅ 分別保存容器、遠端任務與本機終端機的網路路徑記錄。
- ❌ 不要把網頁聊天成功直接等同於 API 網域與程式程序都已經過代理。
還要區分網路失敗與伺服器拒絕。連線建立失敗、網域解析失敗、憑證交握中斷與讀取逾時屬於網路鏈路問題；帳戶權限不足、專案額度限制、請求格式錯誤、模型無法使用與伺服器限流則屬於 API 層。兩類問題的處理方向完全不同。應先保留錯誤類型、回應標頭與 SDK 原始例外，再決定是否切換線路。
固定出口要看節點池，而不是協定名稱
固定出口是指同一條已選線路在正常重新連線、用戶端恢復與連線重複使用過程中，外部服務看到的出口位址保持一致。它由伺服器節點、出口閘道與調度策略決定，不是由 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 這些協定名稱直接決定。同一種協定既可以連接固定出口，也可以連接會輪換出口的節點池。
為什麼 API 呼叫更在意出口一致性？開發工作階段可能包含金鑰驗證、長時間任務、回呼設定與伺服器風控判斷。出口在同一項任務中途變更，容易讓問題表現為偶發交握失敗、工作階段重建或請求被重新評估。這並不是說出口變更必然觸發錯誤，而是會額外增加一個難以重現的變數。
實測固定性時，不要連續重新整理查詢頁面就結束。應涵蓋冷啟動、用戶端主動重新連線、裝置休眠恢復、網路介面切換及訂閱更新後重新選線。每次記錄出口位址、節點名稱、連線時段與異常類型。若節點名稱不變但出口發生變化，應向服務提供方確認該節點是否接入動態出口池。
| 核對面向 | 直連線路 | 中轉線路 | IEPL 專線 | API 情境判斷 |
|---|---|---|---|---|
| 路徑結構 | 裝置直接連接境外節點 | 先到入口，再轉送至出口 | 入口與跨境段使用專線承載 | 路徑越少越容易排查，但不代表波動較低 |
| 本地網路影響 | 跨境路徑直接受到本地電信網路影響 | 入口段通常更靠近本地網路 | 重點是降低公共跨境路徑的不確定性 | 應在實際辦公網路與部署網路分別驗收 |
| 出口固定性 | 取決於所選伺服器 | 取決於最終出口節點 | 仍取決於最終出口與調度策略 | 不能只憑線路標籤下結論 |
| 故障排查 | 鏈路較直接 | 需區分入口與出口 | 需區分本地接入、專線段與出口 | 保留分段記錄比單次測速更有用 |
| 適用傾向 | 路徑穩定時可用於日常開發 | 適合直連跨境波動明顯的網路 | 適合重視長連線持續性的任務 | 最終以相同環境的重複請求結果為準 |
IEPL 專線、中轉與直連描述的是傳輸路徑，不是固定出口承諾。IEPL 的價值主要在於跨境段路徑可控；中轉透過較近的入口承接本地連線，再將流量送往出口；直連結構簡單，但公網跨境段更依賴當時的路由狀態。開發者選擇時，應將「跨境段是否穩定」與「出口是否固定」拆成兩個欄位核對。
並發實測要排除伺服器限流
並發測試最容易誤判。API 伺服器限流、帳戶配額、SDK 連線池、用戶端代理核心、線路入口與最終出口都可能成為瓶頸。若只看到請求失敗就歸因於 VPN，結論通常不可靠。正確做法是固定模型、請求內容、逾時策略與出口，只改變任務佇列的工作方式，並分開統計網路錯誤與伺服器限流回應。
先以序列請求建立基準，確認解析、交握、請求傳送與回應讀取都正常。接著讓佇列逐步增加同時執行的任務，但不要在測試過程中切換模型、出口或 SDK 版本。觀察重點包括連線是否頻繁重建、等待佇列是否持續堆積、串流回應是否在輸出途中停止，以及失敗後重試是否造成更多同時請求。
部分 SDK 預設啟用連線重複使用。連線池正常時，後續請求可以重複使用已建立的安全連線，減少重複交握。若代理用戶端不支援穩定重複使用，或分流規則讓同一網域在不同路徑之間來回切換，程式可能不斷建立新連線。表面上看似「並發一增加就變慢」，實際耗用可能發生在重複解析與交握階段。
自動重試也需要謹慎。若網路函式庫在讀取逾時後立即重試，而上一個請求仍在伺服器執行，就可能讓並發壓力持續上升。對於可能產生費用或寫入結果的任務，應確認介面是否支援冪等控制，並使用帶有退避機制的重試策略。線路測試的目的不是用密集重試掩蓋中斷，而是找出連線在哪個階段失去連續性。
長請求逾時要分清哪一層先中斷
OpenAI 與 Claude API 都可能透過串流方式持續回傳內容。串流回應建立後，連線會維持較長時間，並持續接收片段。位於用戶端與 API 服務之間的任何環節，都可能設定閒置回收或讀取逾時，包括應用程式網路函式庫、本機代理核心、中轉入口、出口閘道與企業網路設備。
「請求逾時」並不是單一故障。連線逾時表示尚未完成連線建立；讀取逾時表示連線已建立，但程式等待後續資料時超過自身門檻；任務主動取消則可能來自應用程式內容、使用者操作或佇列調度。若只列印一行通用例外，就無法判斷線路是否真正中斷。
對於串流呼叫，應確認 SDK 的讀取策略允許持續接收片段，並在應用程式層記錄最後一次收到資料的時間。若每次都在相近階段停止，請檢查本機網路函式庫與代理入口的連線回收設定；若停止位置無規律且伴隨網路介面變化，應重點檢查裝置休眠、無線網路切換與用戶端背景狀態。
非串流請求也可能長時間等待完整結果。它沒有持續片段作為連線活躍訊號，更容易遇到中間環節的閒置判斷。開發環境中可分別驗收串流與非串流模式，比較異常發生在回應開始前還是回應傳輸中。正式任務則應依據業務是否需要即時輸出、能否恢復及是否允許重試來選擇模式。
- ✅ 將連線建立、等待回應與完整任務時限分開設定並記錄。
- ✅ 對串流回應記錄最後一次收到片段的位置。
- ✅ 核對裝置從休眠恢復後，代理通道是否仍由系統維持。
- ✅ 失敗後先確認伺服器是否仍在處理，再決定是否重試。
- ❌ 不要透過無限延長逾時來掩蓋可穩定重現的鏈路中斷。
協定選擇：穩定路徑比名稱更新更重要
Shadowsocks 是輕量代理協定，用戶端支援度高，適合結構明確的轉送情境。VMess 是 V2Ray 生態中較早採用的協定，可搭配不同傳輸方式。VLESS 簡化了協定本身的加密職責，通常與安全傳輸層及不同承載方式組合使用。Trojan 以安全傳輸層連線為基礎，常見於需要相容標準網路環境的部署。
Hysteria2 與 TUIC 基於 QUIC 和 UDP，重點處理高延遲、封包遺失與連線遷移等情況。在允許 UDP 穩定通過的網路中，它們可能更快恢復傳輸；但部分企業網路、公用網路或路由設備會限制 UDP，此時體驗可能不如基於 TCP 的方案穩定。協定選擇必須在實際接入網路中驗證。
協定名稱無法回答固定出口、節點負載、跨境路徑與 API 網域可達性。相同的 VLESS 或 Trojan 設定，接入直連、中轉或 IEPL 路徑後，表現可能明顯不同。對 API 開發而言，更有價值的記錄是：出口是否變化、連線能否重複使用、串流請求是否完整、UDP 是否可用，以及用戶端在休眠或網路切換後如何恢復。
如果辦公網路只穩定允許 TCP 通行，應優先選擇能在該環境中持續工作的傳輸方式，而不是為了追求協定名稱強行使用 UDP。反過來，在行動網路頻繁切換的環境中，可以測試基於 QUIC 的方案是否更容易恢復。任何結論都應綁定網路環境，不應把某種協定寫成適用於所有地區、電信網路與裝置的答案。
訂閱匯入、DNS 與分流核對
訂閱連結通常由伺服器產生，用戶端匯入後會取得節點與分組設定。它本質上是存取設定的憑證，不應貼到公開日誌、問題截圖或線上解析頁面。匯入後先執行訂閱更新，再核對節點名稱、線路類型與所選策略組，避免用戶端仍使用舊設定或自動選到另一個出口。
在分流模式下，API 網域、身分驗證網域與相關資源網域可能命中不同規則。若主要 API 請求走代理，而驗證或解析請求走直連，故障會表現得不穩定。除錯階段可先使用一致路徑完成基準驗收，再依業務需求細化規則。完成分流後，應重新檢查每類請求的實際出口，而不是只看用戶端介面中的目前節點。
DNS 洩漏是指網域解析請求沒有依預期經過指定解析路徑，向本地網路暴露存取的網域，或使解析結果與出口地區不一致。用戶端採用虛擬位址映射時，查詢工具看到的合成結果不一定代表洩漏；判斷重點應放在解析請求最終由誰處理、真實連線如何還原，以及資料流是否使用同一套規則。
若系統同時存在多個網路介面，應用程式可能繞過用戶端指定的解析器。系統代理模式通常只接管明確支援代理的應用程式流量，而 TUN 模式更接近系統級接管，但仍要留意排除規則、本地網路與用戶端實作差異。修改模式後，應清除舊連線與解析快取，再重新測試，避免把舊工作階段結果當成新設定的表現。
各平台用戶端差異與部署邊界
Windows 與 macOS 桌面用戶端通常同時提供系統代理與 TUN 接管方式。系統代理對瀏覽器較直接，但命令列工具是否讀取代理取決於執行環境；TUN 可以涵蓋更多程式，卻需要正確處理本地網路、開發伺服器與虛擬化介面。切換模式後要重新啟動待測程序，因為連線池可能繼續使用切換前建立的連線。
iOS 用戶端透過系統網路延伸功能建立通道，裝置鎖定、網路切換與低電量狀態會影響長時間背景任務。行動裝置適合進行介面串接測試與狀態檢查，不宜讓需要持續執行的批次任務依賴前台應用程式的生命週期。Android 用戶端通常提供依應用程式分流的代理功能，可以只讓終端機、開發工具或測試應用程式進入線路，但新安裝的應用程式是否自動納入規則仍需再次確認。
Linux 與伺服器環境更適合使用可稽核的服務程序、明確的路由規則或受控閘道。正式任務不應依賴某台開發者電腦上的桌面用戶端長期轉送。持續整合環境還要區分建置任務所在網路與開發者本地網路；金鑰、訂閱網址與代理憑證應透過受控的秘密管理方式注入，不要寫入儲存庫與建置日誌。
編輯器外掛也可能使用獨立的網路程序。編輯器本身能存取擴充功能市集，不代表外掛呼叫 API 時會繼承相同設定。遇到外掛可以登入但生成中斷，或終端機腳本正常而外掛失敗時，應查看外掛主程序的代理設定、憑證信任與錯誤日誌，不要先假設 API 服務異常。
可重現的實測與最終選線
線路比較應使用相同裝置、相同接入網路、相同 SDK、相同請求內容與相同帳戶條件。先建立不經過候選線路的可用基準，再逐一測試直連、中轉與 IEPL 節點。若所在網路無法建立基準，至少保留本地解析、連線階段與伺服器回應的分層記錄，避免把多個變數混在一起。
- 固定環境：停止自動選路，關閉會改變出口的故障轉移，只保留待測節點。
- 核對出口：在實際執行程式的程序路徑中確認出口，並涵蓋冷啟動與重新連線。
- 驗證序列：分別執行串流與非串流請求，記錄交握、回應開始與完成狀態。
- 驗證佇列：逐步增加同時執行的任務，區分網路異常、伺服器限流與應用程式主動取消。
- 檢查恢復：模擬網路介面變化、裝置休眠恢復與用戶端重新連線，觀察長請求如何結束。
- 複核分流：恢復日常規則後，重新檢查 API、驗證與 DNS 是否仍走預期路徑。
最終記錄不必追求單一綜合分數。固定出口、串流完整性、連線重複使用、錯誤可診斷性與網路恢復能力應分別給出結論。開發環境可以更重視切換便利與日誌可見性；背景任務應更重視出口一致與故障恢復；持續整合則需要明確的憑證管理與無人值守能力。
如果直連節點在實際網路中的路徑穩定，結構簡單且便於排查；如果公網跨境段波動明顯，中轉通常更值得測試；如果任務依賴持續輸出與長連線連續性，可以優先核對 IEPL 路徑。無論使用哪種線路，都要單獨確認最終出口是否固定。線路類型與固定出口是兩個問題，不能互相取代。