寫程式最影響效率的不是速度慢，而是時好時壞：上午補全秒出，晚上同一個工具轉圈半天。這個現象在跨境網路裡幾乎總能找到解釋，也幾乎總能透過換一種線路類型解決。
長連線與網頁瀏覽，難點不在同一個地方
網頁瀏覽是短連線：開啟一個頁面，瀏覽器並行幾十個請求，每個請求幾百毫秒內結束。中途丟一兩個封包，TCP 重傳補上，使用者感覺只是慢了一點。
AI 程式開發工具不是這個模式。Cursor 的補全、Copilot 的對話、各類命令列助手，走的都是 HTTPS 長連線加串流回應（SSE）：伺服器端把結果一個 token 一個 token 推回來，一條連線要持續數十秒甚至幾分鐘。這條連線中途抖動，表現不是慢，而是補全停在半句、對話沒有下文、只能重新生成。
更麻煩的是丟包會被協定放大。TCP 一旦判定丟包，就把壅塞視窗砍半，串流輸出的節奏立刻掉下來；等視窗重新漲回去，這次補全已經結束了。所以判斷一條線路適不適合寫程式，看的不是峰值速度，而是抖動與丟包。
還有兩件常被忽略的事：
- 編輯器在背景持續連網：程式碼索引、外掛同步、模型檔案下載都在佔用同一條出口，和補全請求搶頻寬。
- 拉套件與建置是大量小檔案並行：npm、pip、Go modules、Docker 映像層，每個都要單獨建立連線，對丟包與握手速度同樣敏感。
這次實測怎麼看：三個面向、一組可重現的檢查
先說清楚實測的含義。本文不給一組固定延遲數字——數字今天好看，明天晚高峰就未必，參考價值有限。這裡給的是三個面向，以及你自己就能重現的檢查方法。
- 連線維持：連續發起串流請求，看單條連線能維持多久，中斷後用戶端能不能自動重連。
- 命令列代理：終端機、Git、套件管理器、Docker 是不是真的走了代理，而不是只有瀏覽器生效。
- 晚高峰表現：把同一組操作放到 19:00–23:00 再做一遍，比較中斷與重傳情況。
三個面向裡，前兩個決定能不能用，第三個決定能不能一直用。多數「這個工具不好用」的抱怨，最後都落在其中一項上。
連線維持：長連線通常斷在哪三步
第一步：建立連線——DNS 解析與 TLS 握手
走公共網際網路直連時，網域名稱解析和 TLS 握手都要多繞幾個來回，首位元組時間被拉長。在編輯器裡的體感就是：點了補全，先轉兩秒，然後才開始出字。如果解析還交給本地電信業者，可能拿到一個離目前出口很遠的位址，白白多等一段。
第二步：閒置——心跳與逾時回收
中間設備會按閒置時間回收連線。用戶端心跳間隔太長，連線表面還在，實際已經失效，下一次請求必須重新握手。這也是離開一會兒回來、第一次補全特別慢的常見原因。
第三步：壅塞——丟包與視窗收縮
晚高峰的跨境公網是共享頻寬，丟包與抖動同時上升。這一段是線路品質差距最明顯的地方，也是專線和中轉、直連拉開距離的位置。
| 線路類型 | 資料怎麼走 | 丟包與抖動 | 長連線表現 | 適合的開發場景 |
|---|---|---|---|---|
| IEPL 專線 | 跨境段走電信業者專線通道，不經過公共網際網路出口 | 低 | 維持時間長，晚高峰波動小 | AI 補全、即時對話、遠端桌面 |
| 中轉 | 先接入中轉節點，再由中轉節點接上跨境段 | 中等 | 比直連穩，成本低於專線 | 拉套件、建置、同步儲存庫、查文件 |
| 直連 | 直接走公共網際網路出口 | 高，晚高峰明顯 | 短請求夠用，長連線容易中斷 | 臨時查資料、對延遲不敏感的任務 |
命令列代理：終端機、Git、套件管理器怎麼走
編輯器裡的代理開關和終端機是兩套東西。很多人卡在「瀏覽器能開啟，終端機一直逾時」，原因就在這裡：用戶端只開了系統代理，而命令列工具預設不讀系統代理設定。
讓命令列走代理有三種做法：
- 環境變數：只對目前終端機視窗生效，最輕量，適合臨時用；新開視窗要重新設定，圖形介面應用程式也讀不到。
- 用戶端的 TUN / 虛擬網卡模式：接管系統全部流量，終端機、Docker、SSH、背景程序一起涵蓋，代價是需要更高的系統權限。
- 分流規則：把 AI 工具網域和程式碼託管走代理，把套件管理器來源、公司內網直連——省流量，也避免內網服務被繞出去。
環境變數的寫法（下面以本機混合埠 7890 為例，實際埠號以用戶端裡顯示的為準）：
# 只對目前終端機視窗生效
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
# 讓 Git 也走代理
git config --global http.proxy http://127.0.0.1:7890
# 用完取消
unset http_proxy https_proxy
git config --global --unset http.proxy配完一定要驗證：在終端機裡開啟站內的我的 IP頁面，看出口地區是不是和用戶端裡選的一致。如果瀏覽器顯示日本、終端機還顯示本地電信業者，說明終端機的流量根本沒進代理。
訂閱連結是什麼：用戶端用來拉取線路設定的一串位址。匯入一次，用戶端會按裡面的線路清單自動更新；換裝置時把同一個訂閱連結貼進新用戶端的訂閱欄即可，不需要逐條抄伺服器位址。訂閱與協定的對應關係，可以看線路與協定；各平台用戶端的匯入步驟在教學頁。
晚高峰與 DNS：容易被忽略的兩件事
晚高峰：把檢查放在 19:00–23:00
跨境公網的壅塞有明顯的時間規律。白天測著很順的線路，晚上可能開始丟包，因為大家都在用同一段公共出口。判斷一條線路適不適合寫程式，就看晚高峰這個時段：如果補全在這幾個小時裡頻繁卡頓，要換的是線路類型，而不是編輯器。
DNS 洩漏：解析走了本地，請求就繞遠路
如果網域名稱解析仍然交給本地電信業者，即使流量走了代理，也可能拿到離出口很遠的位址，首位元組時間被白等一段。檢查方法很簡單：在代理開啟的狀態下存取任意 DNS 洩漏檢測頁面，看解析伺服器是否跟著出口地區走。不是的話，在用戶端裡把 DNS 查詢也交給代理來解析。
只檢查瀏覽器是不夠的。編輯器、終端機、Docker 可能各自走不同的出口，DNS 洩漏檢測要在真正跑 AI 工具的那個環境裡做一遍。
分流規則：先寫三類就夠用
常見規則類型有三種：按網域後綴（DOMAIN-SUFFIX）、按 IP 段（IP-CIDR）、按地區庫（GEOIP）。開發場景下先把這三類寫好，大部分問題就解決了：
- AI 工具與程式碼託管網域 → 走專線；
- 套件管理器來源、鏡像站 → 直連，省流量，速度也更快；
- 公司內網與本地網段 → 直連，保證內網服務可達。
依場景選線：開發者最常用的四種組合
| 使用場景 | 建議線路 | 為什麼這樣選 |
|---|---|---|
| 補全與對話（Cursor、Copilot、命令列助手） | IEPL 專線，日本或新加坡 | 長連線對丟包最敏感，專線的抖動更小 |
| 拉套件、建置、同步儲存庫 | 中轉或直連，挑頻寬大的地區 | 吞吐優先，偶發重傳不影響最終結果 |
| 遠端桌面、視訊會議 | IEPL 專線，就近地區 | 抖動比速度更影響體感，畫面卡頓最難忍 |
| 查文件、搜資料 | 任意穩定線路 | 短連線容忍度高，不必佔用專線頻寬 |
線路資源方面，KimiVPN 覆蓋 110+ 國家、150+ 線路，具體到每個地區有哪些線路類型，可以在線路頁按國家篩一遍再決定。用戶端覆蓋 Windows、Android、iOS、macOS、Linux 五個平台，同一帳號不限台數——筆電、桌機、平板可以同時在線，不用為多裝置另外付費。
下單前確認這幾件事
開發場景對用戶端和線路資訊的要求比日常瀏覽高，下面幾條可以逐項對照：
- ✅ 有桌面用戶端，支援系統代理和 TUN 兩種模式——編輯器、終端機、Docker 都能涵蓋
- ✅ 支援自訂分流規則，能把套件管理器來源和公司內網直連
- ✅ 線路清單標清國家、城市和線路類型（專線 / 中轉 / 直連），而不是只寫「高速節點」
- ✅ 註冊只要使用者名稱，不需要電子郵件地址，少留一條個人痕跡
- ✅ 隱私政策寫清楚記錄什麼、不記錄什麼——本服務為匿名無日誌
- ✅ 付款方式涵蓋支付寶、微信、USDT；退款政策寫得明確，本服務是 7 天無理由退款
- ✅ 流量包永久不過期，用不完可以留著以後繼續用
- ❌ 只有瀏覽器外掛，命令列完全沒辦法設定
- ❌ 訂閱連結不能手動更新，換裝置要重新找客服
- ❌ 線路數量寫得很大，點進去卻看不出地區與線路類型
價格方面，月付 ¥9.9 起，按流量分成幾檔；不確定一個月會用多少，先按月付試，不夠再補流量包，流量包永久不過期。
常見問題
Cursor 補全卡住，先查線路還是先查工具？
先看時間規律。只在晚高峰出現，多半是線路問題，換成 IEPL 專線再看一遍；整天都卡，先確認終端機和編輯器是不是真的走了代理，再檢查 DNS 解析有沒有跟著出口地區走。
一個帳號能同時登入幾台裝置？
本服務不限台數。日常用的筆電、桌機、平板可以同時在線，不需要為多裝置額外付費。
換裝置要重新設定線路嗎？
不用。把同一個訂閱連結匯入新用戶端的訂閱欄，更新一次就能拿到全部線路，分流規則也會跟著同步過來。
需要一直開著嗎？
不必。配合分流規則，直連的流量本來就不經過代理；只在用 AI 工具、查資料的時候開啟也可以。