開發者遇到 GitHub clone 慢、Docker Hub 拉取中斷，或 npm、pip 安裝停滯時，問題不一定出在同一處。VPN 只能改變部分網路請求的傳輸路徑，無法保證來源站、DNS、套件鏡像或 CI 執行環境都會一起變快。有效的排查方式，是先確認請求由哪個程式發出、該程式是否經過代理，再分別測試連線、解析與下載；不要一遇到逾時就不斷切換節點或同時更改多項設定。
本文整理一套適用於 GitHub、Docker Hub、npm、pip 與 CI 建置的檢查思路，並說明系統代理、TUN 模式與命令列代理設定的差異。不同作業系統及用戶端的選單名稱可能不同，請以目前版本的設定為準；需要先匯入訂閱或確認基本連線時，可參考使用教程。
先定位請求從哪裡出去
桌面瀏覽器能開啟 GitHub，不代表終端機裡的 Git、Docker Engine 或 CI runner 也使用相同路徑。系統代理通常會被部分圖形化應用程式讀取，但命令列工具可能只讀取自己的代理設定或環境變數；Docker Desktop 的 Engine 又可能在虛擬化環境中執行，與主機終端機不是同一個網路請求來源。
開始排查前，先寫下發生問題的程式、目標網域、錯誤訊息，以及失敗是在連線、驗證、解析還是下載階段。接著確認目前使用的是用戶端的系統代理、TUN，還是應用程式個別設定。Windows、macOS、iOS、Android 與 Linux 均有相應的使用方式，但支援的代理接管方式與設定入口會因官方用戶端或相容用戶端而異。
90+
國家覆蓋
200+
線路數
不限台數
同時在線設備
5 種平台
Windows、macOS、iOS、Android、Linux
節點地區和線路可以作為測試變因，但節點名稱本身不能證明實際出口或特定網站的速度。若要比較結果，保持同一台裝置、同一個工具與同一個下載來源，只改變一項設定，再觀察錯誤是否改變。也可先用站內的IP 檢測確認瀏覽器目前看到的出口；命令列程式是否走相同路徑，仍要另外驗證。
按工具設定代理，而非一律全域修改
Git 與 GitHub
Git 的 HTTP(S) 傳輸可以讀取代理設定，但 SSH remote 使用的是另一種傳輸方式，單純設定 HTTP 代理不會自動改變 SSH 連線。先用 git remote -v 查看遠端位址：若網址以 HTTPS 開頭，才優先檢查 Git 的 HTTP(S) 代理；若使用 SSH，應檢查 SSH 用戶端與目前 VPN 路由是否支援該連線，不要把兩種問題混為一談。
可在目前終端機設定暫時性的環境變數，再執行一次 clone 或 fetch 測試。以下以佔位值表示本機代理位址，必須替換成用戶端實際顯示的 HTTP 代理端點，不要直接照抄：
export HTTPS_PROXY="http://127.0.0.1:PORT"
export HTTP_PROXY="http://127.0.0.1:PORT"
git ls-remote https://github.com/OWNER/REPOSITORY.gitWindows PowerShell 可使用 $env:HTTPS_PROXY 與 $env:HTTP_PROXY 設定目前工作階段的環境變數。暫時設定適合判斷代理是否有作用；若考慮用 git config --global http.proxy 長期保存，先確認這台裝置上的所有 Git 專案是否都應使用同一代理。完成測試後，移除不再需要的設定，避免離開 VPN 後仍向不存在的本機代理送出請求。
Docker Hub 與套件管理器
docker pull 的網路請求通常由 Docker Engine 發出，不一定由目前輸入命令的終端機發出。因此，在 shell 設定 HTTPS_PROXY 後，Docker Hub 仍可能無法連線。Docker Desktop 應檢查其提供的代理或網路設定；Linux 上的 Docker Engine 則應依目前安裝方式，檢查 daemon 的代理環境與服務管理器設定。修改 daemon 設定可能需要重新載入或重啟服務，操作前先確認對其他容器工作的影響。
npm 和 pip 通常可以讀取代理環境變數，也各自提供設定方式。先在單一終端機測試環境變數，比立即寫入全域設定更容易回復。若團隊使用私有套件來源或經覈准的鏡像，請確認該網域在分流規則中走正確路徑；不要為了讓安裝通過而關閉 TLS 憑證驗證，也不要把含有帳號密碼的代理網址提交到程式碼庫。
VPN 節點、代理端點與分流規則是不同層次：選擇節點不代表每個程式都已接管；設定代理也不代表所有網域都應經由代理。Clash Verge、sing-box 等相容用戶端可提供系統代理、TUN 或規則分流等模式，但可用選項取決於用戶端與作業系統。瞭解匯入訂閱與模式差異，可參考排查手冊。
動手測試：逐層縮小範圍
以下流程適合在本機重現問題時使用。每次只改一個條件，保留原始錯誤訊息；如果同時換節點、改 DNS、改代理和切換 TUN，就很難判斷是哪個改動有效。
- 確認目標與傳輸方式。查看 Git remote 是 HTTPS 還是 SSH，確認 Docker 操作由本機 Engine 或 Docker Desktop Engine 執行，並記下 npm、pip 使用的套件來源。不要只記「下載很慢」，要記錄是哪一個命令、哪個來源和哪一段出錯。
- 先驗證基礎連線。確認 VPN 用戶端已連線，檢查所選模式是否會接管相關應用程式。瀏覽器可以作為初步參考，但應再透過原本出錯的程式執行一次測試。
- 為單一工具暫時指定代理。使用用戶端實際提供的代理端點設定目前終端機環境變數，測試 Git 或套件下載。若問題只在 Docker 出現，將注意力轉到 Engine 或 Desktop 的代理設定，而不是反覆修改 shell。
- 分別測試解析、連線與下載。解析失敗通常要檢查 DNS 或網域規則；連線逾時要檢查代理接管、出口路由或防火牆；已連線但傳輸中斷，則應比較來源服務狀態、傳輸持續性與用戶端日誌。
- 恢復設定並留存結果。記下有效的模式、節點與工具設定，移除臨時代理變數或不再需要的全域設定。若切回直連後故障消失，可再逐項恢復，找出實際差異。
- ✅ 先確認 Git 使用 HTTPS 還是 SSH，再選擇相應排查方向。
- ✅ Docker Hub 拉取失敗時，檢查 Engine 或 Desktop 的網路設定，不只檢查命令列。
- ✅ 套件管理器優先使用暫時設定測試，並核對套件來源與分流規則。
- ❌ 不要同時啟用多個代理用戶端或堆疊多組互相衝突的代理設定。
- ❌ 不要把代理憑證、訂閱連結或私有套件來源密鑰寫入公開日誌和程式碼庫。
用錯誤表象區分常見原因
| 觀察到的情況 | 優先檢查 | 下一步 |
|---|---|---|
| 瀏覽器可用，Git 命令失敗 | Git remote 類型、終端機代理環境變數、Git 個別設定 | 以 HTTPS remote 測試代理；若為 SSH，轉查 SSH 路徑與設定 |
| GitHub 可用，Docker Hub 拉取失敗 | Docker Engine 或 Desktop 是否使用主機代理 | 確認 daemon 的代理設定、DNS 與 Docker 錯誤日誌 |
| 網域無法解析或解析結果不一致 | DNS 接管方式、分流規則、套件來源網域 | 確認目標網域由預期的 DNS 路徑解析，再重試原始命令 |
| 可以連線，但下載中途停住 | 來源服務狀態、線路穩定性、傳輸是否經代理 | 用相同來源比較另一條可用線路，並查看工具日誌中的具體錯誤 |
| 本機成功，CI 建置失敗 | runner 所在網路、祕密變數、daemon 與容器網路設定 | 在 runner 端獨立驗證，不假設本機 VPN 設定會自動傳入 CI |
「連線逾時」、「名稱解析失敗」、「驗證拒絕」和「下載速度不穩」代表的故障階段不同。遇到 GitHub 權限或 token 錯誤時，先檢查帳戶授權與憑證；遇到 Docker Hub 登入限制時，則檢查帳戶狀態和映像名稱。VPN 不會修正錯誤的 repository 名稱、已失效的 token 或套件版本設定。
CI 與日常使用的安全做法
CI 建置的 runner 可能位於雲端、公司網路或自架主機，其網路路由與開發者筆電並不相同。即使本機透過 VPN 能下載映像與依賴，runner 仍可能因為出站政策、DNS、代理變數或容器網路不同而失敗。應在 runner 執行環境中檢查實際請求路徑，並由管理者覈准所需的網域與代理憑證；不要把個人訂閱或含密鑰的代理位址複製到公開 CI 設定。
依賴下載可優先使用團隊覈准的套件來源、快取或內部鏡像，並保留鎖定檔與依賴校驗流程。更換下載路徑不應改變對套件來源可信度的要求。Docker 映像也應核對登錄站、標籤與摘要，避免因為拉取失敗而改用來源不明的鏡像。
日常設定以可回復、範圍明確為原則：先用單一終端機的環境變數驗證，再考慮工具級設定；先確認系統代理與 TUN 的差別，再決定是否需要調整分流。問題排除後，移除多餘代理設定，並妥善保管訂閱連結、存取 token 與私有 registry 憑證。