開發者遇到的網路問題，通常不只是 GitHub 網頁載入較慢。Git clone、Release 下載、Docker 映像拉取、npm 套件安裝、套件文件查詢、API 請求，以及 CI 建置時取得依賴，都可能使用不同的網域、連接埠與傳輸方式。只開啟 VPN 並不代表所有工具都會自動走同一條線路；終端機、Docker Engine、Node.js 套件管理器和 CI Runner 也可能各自使用獨立的 Proxy 設定。
比較可靠的做法，是先分辨「系統連線」、「應用程式代理」和「命令列環境變數」三個層次，再依照工作流程逐項驗證。本文以 VFVPN 可使用的官方用戶端與相容用戶端為基礎，整理 GitHub、Docker 與 npm 的常見設定方式，也說明哪些流量適合分流、哪些情況不應直接套用全域代理。Windows、macOS、Android、iOS 與 Linux 都可以先從官方用戶端取得連線設定；熟悉進階配置的使用者，也可使用 Clash Verge、sing-box 或 Shadowrocket 等相容用戶端。
開發者網路為什麼要分層處理
VPN 用戶端建立的是裝置層連線，通常會接管作業系統的部分或全部網路流量。當瀏覽器開啟 GitHub、下載網頁文件或呼叫一般 HTTPS API 時，系統層連線往往已經足夠。不過，Git、Docker 和 npm 並不一定完全遵循相同的系統設定。Git 可能讀取自己的 global config，Docker CLI 會把請求交給 Docker daemon，而 npm 則可能受到 npmrc、環境變數或企業網路設定影響。
因此，排查時不要一開始就同時修改所有設定。先確認 VPN 用戶端本身已匯入訂閱、線路能建立連線，而且一般瀏覽器能開啟需要的服務；接著再針對單一工具測試。若瀏覽器正常、Git 失敗，問題多半在 Git 的代理或憑證；若 Docker CLI 失敗但 Docker Desktop 其他功能正常，則要檢查 daemon 的 Proxy；若 npm 只有某個 registry 失敗，則應檢查 registry、TLS 或套件來源，而不是盲目更換全部線路。
| 工作物件 | 主要連線發起者 | 優先檢查位置 | 常見注意事項 |
|---|---|---|---|
| GitHub 網頁與 Release | 瀏覽器或系統網路 | VPN 狀態、線路與 DNS | 登入、下載與 API 可能使用不同網域 |
| Git clone / fetch | Git 命令列 | Git global config、環境變數 | HTTPS 與 SSH 的代理設定方式不同 |
| Docker pull | Docker CLI 或 Docker daemon | Docker Engine / Desktop Proxy | CLI 有代理不代表 daemon 一定有代理 |
| npm install | Node.js 與 npm | registry、npmrc、HTTPS Proxy | 要區分套件下載與企業內部 registry |
| CI 建置 | Runner、容器或建置工作程序 | CI Secret、Job 變數與執行環境 | 本機設定不會自動帶入遠端 Runner |
協定名稱也需要正確理解。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 WireGuard 並不是可以任意互換的設定欄位；用戶端必須支援相應協定，訂閱格式也要與用戶端解析能力匹配。Clash Verge 和 sing-box 通常適合需要規則分流的桌面環境，Shadowrocket 常用於 iPhone 或 iPad，但實際支援的設定格式仍應以服務面板及用戶端版本為準。若使用 IEPL、BGP 或 CN2 等線路標示，也應把它視為路由或線路類型，而不是某種可直接填入 Git 的代理協定。
GitHub 與 Git的穩定下載做法
先處理 HTTPS Git 操作
對多數開發流程而言，HTTPS Git 操作是較容易排查的起點。啟動 VPN 用戶端後，可以先在終端機執行基本的遠端連線測試，再嘗試列出遠端資訊或抓取一個需要使用的儲存庫。若瀏覽器能開啟 GitHub，但 Git 顯示連線逾時，表示 Git 可能沒有使用系統代理，或環境變數中存在失效的代理位址。
Git 可以透過自己的設定指定 HTTP 或 HTTPS Proxy。使用前先確認用戶端提供的本機代理連接埠與協定類型，HTTP Proxy、SOCKS5 和透明代理不是同一種輸入格式。不要把訂閱連結、節點密鑰或完整帳戶設定直接寫入公開儲存庫，也不要將含有認證資訊的指令貼到團隊聊天記錄中。若只需要暫時測試，可以使用目前 Shell 的環境變數；若要長期使用，則應將設定放在本機使用者環境，並避免提交到專案檔案。
SSH、Release 與 API 要分開看
GitHub 的 HTTPS 與 SSH 是不同的連線路徑。即使 HTTPS clone 已經可以使用，SSH 仍可能因為公司防火牆、連接埠限制或 SSH 本身沒有套用代理而失敗。此時可以選擇把遠端 URL 改為 HTTPS，或依照所用用戶端的文件設定 SSH ProxyCommand；不要把 HTTPS Proxy 的寫法直接套在 SSH 設定上。
Release 檔案、Raw 內容、套件下載和 API 請求也不一定使用完全相同的主機名稱。當 GitHub 主頁可開啟而 Release 下載中斷時，應在瀏覽器開發者工具、終端機輸出或 Git 的詳細日誌中辨識實際失敗的網域。對 API 呼叫則要留意請求程式是否擁有自己的 Proxy 選項，例如 Python、Go、Node.js 或 curl 可能分別讀取不同的環境變數。若 API 使用 Token，VPN 只負責網路路徑，不能替代 Token 權限與伺服器端的速率限制。
- ✅ 先確認 VPN 用戶端已連線，再測試 GitHub 網頁與 Git HTTPS。
- ✅ 為 Git 指定與本機用戶端相符的 HTTP 或 SOCKS5 代理格式。
- ✅ 將 GitHub Token 放在安全的認證管理機制中，不寫入公開腳本。
- ✅ HTTPS 與 SSH 分別驗證，不把其中一種協定的代理設定照搬到另一種。
- ❌ 不要把完整訂閱連結、代理密碼或含憑證的命令提交到 Git 儲存庫。
Docker 與 npm下載設定
Docker 要注意 CLI 與 daemon 的差異
執行 docker pull 時，命令列只是向 Docker Engine 發出請求，真正存取 registry 的可能是本機 Docker daemon。這也是常見的誤區：在 Shell 中設定了 HTTP_PROXY，docker 命令看似取得設定，Docker daemon 卻仍然無法連到映像 registry。Docker Desktop 的 Proxy 位置通常與 Docker Engine 的服務設定分開；Linux 上若使用 systemd 管理 Docker，則要依服務環境設定代理並重新載入服務，不能只改目前終端機的環境變數。
映像拉取還涉及 registry 網域、認證、manifest、不同架構的 layer，以及 TLS 憑證驗證。若只是一個映像失敗，先確認 registry 是否需要登入、帳戶是否有權限、映像名稱與 tag 是否正確。若所有公開映像都失敗，再檢查 daemon 的 DNS、代理和防火牆。不要為了排查方便而關閉 TLS 驗證，因為這會讓映像內容與認證暴露在不安全的路徑上。
npm registry 與專案設定
npm 安裝套件時，首先確認目前使用的 registry。公共套件、公司私有 registry、套件鏡像與專案內的自訂來源，可能需要不同的認證和代理規則。可以先讀取目前 npm 的有效設定，再測試單一套件的 metadata；如果 metadata 能取得但 tarball 下載失敗，表示問題可能發生在重新導向的下載主機，而不是最初的 registry 網址。
npm 常會讀取使用者目錄下的 npmrc，也可能受到 HTTP_PROXY、HTTPS_PROXY、NO_PROXY 等環境變數影響。企業內部 registry、私有套件和本機開發服務通常應放入 NO_PROXY 或保留直接連線，避免將內部主機送往外部代理。相反地，公共 registry 若在目前網路環境中連線不穩，則可以讓 npm 使用與 VPN 用戶端相容的本機代理。完成測試後，記得檢查設定檔是否含有明文 Token，並將敏感內容改用安全的登入流程或 CI Secret。
| 問題表現 | 較可能的原因 | 建議排查順序 |
|---|---|---|
| GitHub 網頁正常，git clone 逾時 | Git 未套用代理，或遠端使用 SSH | 查看遠端 URL，再檢查 Git Proxy 設定 |
| Docker CLI 可執行，pull 仍失敗 | daemon 沒有取得 Proxy 設定 | 檢查 Docker Desktop 或 Docker Engine 服務環境 |
| npm metadata 正常，套件壓縮檔失敗 | 重新導向網域、TLS 或代理分流問題 | 查看詳細輸出，確認實際下載主機 |
| 內部套件突然無法安裝 | NO_PROXY 缺少內部網域或 DNS 被改變 | 先確認內部 registry 與本地網路是否應直連 |
動手設定與驗證流程
以下流程適合在 Windows、macOS 或 Linux 桌面逐項執行。先從 VFVPN 面板取得官方用戶端，或依目前系統選擇相容用戶端，再匯入訂閱。官方用戶端適合希望少處理格式差異的使用者；Clash Verge、sing-box 等工具則可讓熟悉規則的開發者依網域或應用程式分流。若使用 iOS，則依用戶端支援方式匯入訂閱；不要把代理訂閱直接貼到作業系統原生 VPN 欄位。
- 登入 VFVPN 面板，從下載頁取得對應平台的用戶端，或選擇支援目前訂閱格式的相容用戶端。
- 匯入訂閱並更新線路清單，先選擇較符合目標服務地區的線路，再確認一般 HTTPS 網頁能正常開啟。
- 在終端機確認 Git 的遠端 URL，先測試 HTTPS；若使用 SSH，另外檢查 SSH 的代理或改用 HTTPS。
- 查看 Docker Desktop 或 Docker Engine 的網路設定，確認真正發出 registry 請求的 daemon 能使用正確代理。
- 查看 npm 目前 registry 與代理設定，測試 metadata 和套件 tarball，並確認內部網域是否需要加入 NO_PROXY。
- 將暫時測試用的環境變數與長期設定分開，完成測試後清理終端機歷史、設定檔中的敏感值與不再使用的代理。
測試時最好一次只變更一項。先以瀏覽器或 curl 確認目標網域可達，再測 Git；Git 正常後再處理 Docker，最後才處理 npm 和專案建置。這樣可以把「VPN 線路問題」、「工具未讀取代理」和「服務本身需要認證」區分開來。若切換線路後結果改變，記錄當時的線路名稱、用戶端模式和目標服務，不需要編造延遲或成功率等無法由頁面驗證的數據。
分流與 CI的安全維護
開發環境不適合長期使用沒有邊界的全域代理。公共 GitHub、映像 registry、npm registry 或文件服務可以依需求經由 VPN；企業內網、localhost、區域網路設備、公司 VPN 和私有套件來源，則可能需要直連或使用另一套安全通道。分流規則可以按網域、IP、連接埠或應用程式制定，但越複雜的規則越需要在網路變更後重新驗證。
對本機開發而言，NO_PROXY 常用來保留 localhost、127.0.0.1、內部網域和容器間服務名稱。Docker 容器內的 localhost 不一定代表宿主機，容器、宿主機與內部服務之間的位址範圍需要按照實際拓撲設定。若把所有流量都交給代理，可能造成回呼網址無法連回本機、內部 API 被送到錯誤出口，或憑證驗證出現與原本不同的結果。
CI 建置則要另行設計。開發者本機的 VPN 連線不會自動延伸到 GitHub Actions、公司 Runner 或遠端容器。若 CI 需要代理，應由管理者在 Runner 層設定，或透過平台提供的 Secret 與受控環境變數注入；不要把含有代理帳密的 URL 寫入 workflow、Dockerfile、package-lock 以外的公開檔案，更不要將訂閱連結當作 CI 代理入口。建置完成後，檢查日誌是否意外列出 Token、Proxy URL、Authorization header 或私有 registry 位址。
- ✅ 公共服務、內部服務與 localhost 分別制定分流策略。
- ✅ Docker daemon、npm、Git 和 CI Runner 各自確認代理生效位置。
- ✅ 使用 CI Secret 管理 Token、私有 registry 認證與代理憑證。
- ✅ 線路或訂閱更新後，重新測試 clone、映像拉取、套件安裝與 API。
- ❌ 不要在 Dockerfile、公開 workflow 或專案版本庫中硬編碼敏感代理資訊。
- ❌ 不要因為下載失敗就關閉 TLS 驗證或跳過憑證檢查。