工程師 VPN 怎麼配？GitHub、Docker 與套件下⁠載一次搞定

工程師在日常開發中遇到的網路問題，通常不是單純「網頁打不開」。GitHub 可能能載入首頁，卻在 clone、fetch 或下載 Release 時反覆逾時；Docker Hub 可能可以登入，實際拉取映像檔時卻停在某一層；npm、PyPI、Go Modules 或 Composer 也可能因為套件來源、DNS 解析與連線路徑不同而出現安裝失敗。這些問題如果只靠不斷切換節點處理，往往很難找出真正原因。

比較穩妥的做法，是先把開發工作拆成幾種不同的網路任務，再決定哪些程式使用代理、哪些服務維持直連，以及代理應該以系統代理、TUN 模式還是應用程式環境變數接入。本文以 GitHub、Docker 與常見套件管理工具為主，說明訂閱匯入、分流設定、終端機環境變數、容器執行環境與故障排除的實際順序。

先拆解工程師的網路需求

「開發用 VPN」並不是讓所有流量無條件經過同一條線路。工程環境通常同時存在公共服務、公司內部服務與本機開發服務。GitHub、Docker Hub、npm Registry、PyPI 和語言套件庫可能位於不同地區；公司 GitLab、資料庫、內網 API 和測試環境則可能只允許從指定網路進入。如果全部流量都代理，內部服務可能無法存取；如果全部直連，公共套件來源又可能不穩定。

在開始設定前，可以先列出每天會使用的服務，並標記它們的連線特性。瀏覽 GitHub 網頁與透過 SSH 讀取儲存庫，可能使用不同協定和連接埠；Docker CLI 需要讓 Docker Engine 或 Docker Desktop 取得映像檔，而不一定只要讓目前的終端機走代理；npm 的下載請求則可能由 registry、套件中的 postinstall 腳本與 Git 依賴共同組成。

如果使用 OJVPN，可在 Windows、macOS、Android、iOS 或 Linux 官方用戶端中匯入訂閱，也可以依用戶端相容格式，匯入 Clash Verge、sing-box 或 Shadowrocket 等第三方客戶端。Shadowsocks、VMess、Trojan、Hysteria2 與 WireGuard 代表不同的協定或實作方式，不能因為名稱相同，就假設所有客戶端都支援相同參數。使用前應確認訂閱格式、核心版本與平台權限彼此相容。

匯入訂閱並選擇適合的客戶端

訂閱連結是一組可更新的連線配置，通常包含節點名稱、伺服器位址、協定參數與分組資訊。它不是普通網頁，也不應貼到公開 Issue、團隊聊天或截圖中。若要請別人協助排查，只需提供客戶端名稱、節點類型、錯誤訊息與必要的脫敏記錄，完整訂閱網址和 QR Code 都應遮住。

官方客戶端適合希望快速完成安裝、匯入與連線的人。它通常會把帳號、訂閱更新和系統權限集中在同一個介面中，適合先建立基礎環境。Clash Verge 便於管理規則組、代理羣組與多份配置；sing-box 適合需要更細緻地處理 TUN、路由與 DNS 的使用者；Shadowrocket 則常用於 iOS 裝置上的訂閱管理與規則分流。第三方客戶端的彈性較高，但設定錯誤時也需要自行理解核心日誌。

1. 從可信來源取得與作業系統相符的官方客戶端，或確認第三方客戶端的核心與訂閱格式相容。
2. 完成安裝後，先在訂閱管理頁面貼上連結並更新，不要一開始手動修改所有節點參數。
3. 選擇一條靠近目標服務或適合目前網路環境的線路，先測試一般 HTTPS 網頁。
4. 確認客戶端的系統代理埠、HTTP/SOCKS5 支援方式，以及是否啟用了 TUN 模式。
5. 記錄這組可用配置，再開始設定 Git、Docker 與套件管理工具。

系統代理與 TUN 模式的作用不同。系統代理通常隻影響遵守作業系統代理設定的應用程式；終端機工具、Docker Engine 或自行建立的網路程序，未必會自動跟隨。TUN 模式則透過虛擬網卡接管較廣泛的流量，但可能影響公司內網、本機服務、虛擬機與容器網路，因此不宜在不瞭解分流規則時長期全域啟用。

動手設定 GitHub、Docker 與套件下載

GitHub 與 Git 的設定

如果使用 HTTPS 形式的 Git 儲存庫，Git 是否走代理取決於 Git 自身設定、環境變數或系統代理支援情況。可以先查看目前設定，避免重複寫入互相矛盾的代理：

git config --global --get http.proxy
git config --global --get https.proxy
git remote -v

若客戶端提供本機 HTTP 代理埠，可依實際埠號設定 Git。以下只是格式示例，埠號必須替換成客戶端介面顯示的值，不要直接照抄：

git config --global http.proxy http://127.0.0.1:PORT
git config --global https.proxy http://127.0.0.1:PORT

使用完成後，可透過 `git config --global --unset http.proxy` 與 `git config --global --unset https.proxy` 移除設定。若公司內部 GitLab 不應經過外部代理，可以使用 Git 的 URL 重寫、環境變數或分流規則將公司網域設為直連。SSH 儲存庫則是另一條路徑，不能只因瀏覽器能開啟 GitHub，就判定 SSH clone 一定正常；需要檢查 SSH 金鑰、主機名稱、連接埠與代理支援。

Docker pull 為什麼不能只設定終端機代理

Docker 指令由 Docker CLI 發出，但真正下載映像檔層的程序通常是 Docker Engine 或 Docker Desktop 背後的守護程序。這表示在 Shell 中設定 `HTTP_PROXY`，可能隻影響目前命令或建置程序，未必能讓 Engine 連到 Docker Hub。Windows 與 macOS 上的 Docker Desktop 需要在其設定介面處理代理；Linux 上則常見於 systemd 服務的環境設定或 Docker daemon 配置。

設定代理後，先重啟 Docker Engine，再檢查登入與拉取結果。若公司環境使用私有 Registry，還要確認 Registry 的網域被正確分流，並檢查憑證是否由系統或 Docker 信任。不要為了繞過憑證錯誤而直接關閉 TLS 驗證，這會把傳輸與映像來源的安全問題掩蓋起來。

docker version
docker info
docker pull IMAGE:TAG

如果 `docker info` 正常，但 `docker pull` 仍停滯，可把問題分成三層：第一層是本機客戶端能否連到代理；第二層是 Docker Engine 是否真的使用該代理；第三層是 Registry 認證、映像檔標籤或特定 layer 是否出錯。不要只反覆切換節點，應先觀察 Docker Desktop 日誌或 daemon 記錄中的目標網域與錯誤類型。

npm、pip 與其他套件管理器

npm 可以透過設定檔或環境變數指定 HTTP、HTTPS 代理，也可以單獨設定 registry。若只有 npm registry 連線正常，但某個套件仍安裝失敗，原因可能是 package.json 內含 Git URL、GitHub Release、二進位檔下載或 postinstall 腳本。此時要查看完整錯誤訊息，確認失敗的到底是 registry、Git 還是額外下載來源。

npm config get registry
npm config get proxy
npm config get https-proxy
npm install

pip、RubyGems、Cargo 與 Go Modules 也各有自己的來源與代理處理方式。建議先確認官方或公司指定的套件來源，再決定是否使用代理。對於需要登入的私有 Registry，不要把 Token 直接寫入公開腳本或提交到 Git 儲存庫；環境變數、作業系統憑證管理與專案範圍的設定通常更安全。

• ✅ Git HTTPS、Git SSH、Docker Engine 與 npm 分別驗證，不把一個工具的成功視為全部成功。
• ✅ 對公司內網、localhost、私有 Registry 設定明確的直連或指定路由。
• ✅ 讓套件管理器使用固定且可信的 registry，避免安裝時隨意切換來源。
• ❌ 不要把完整訂閱連結、Registry Token 或 SSH 私鑰放入 Issue 和除錯記錄。
• ❌ 不要同時啟用多個代理客戶端，避免系統代理埠、DNS 與 TUN 路由互相衝突。

分流、DNS 與容器網路的細節

分流的核心不是「全部代理」或「全部直連」，而是讓不同目的地採用可預期的路徑。公共程式碼平台、映像檔 Registry 與套件來源可以依網域規則交由代理；公司域名、內部 IP、localhost 與本機測試服務則通常需要直連。若使用域名分流，必須確認 DNS 解析結果不會被錯誤快取或解析到不適合的位址。

DNS 模式也會影響分流判斷。部分客戶端採用本地解析，部分客戶端會把 DNS 請求送入代理通道，TUN 模式還可能透過虛擬 DNS 回應應用程式。當瀏覽器能開啟 GitHub、但 Git 或 Docker 報告找不到主機時，應比較不同程序使用的 DNS 路徑，而不是隻測試瀏覽器。

容器內的 DNS 與主機不同。Docker 容器通常透過 Engine 提供的 DNS 轉送服務解析網域；即使主機瀏覽器能連線，容器內的 `curl`、套件安裝或建置步驟仍可能失敗。建置映像檔時，代理環境變數還可能被傳入 build stage；若其中包含帳號或密碼，不應用不安全的方式寫入 image layer。完成建置後，也要檢查最終映像檔是否殘留代理憑證。

從錯誤訊息開始排除問題

故障排除應從最短路徑開始。先確認目前客戶端確實已連線，再測試 DNS 解析，接著測試代理本身，最後才測試應用程式。GitHub 的網頁錯誤、Git 的 TLS 錯誤、Docker 的 registry timeout 與 npm 的 certificate error，表面上都像「速度慢」，實際原因可能完全不同。

1. 確認目前只啟用了一個代理客戶端，並記下使用中的節點、模式與代理埠。
2. 用瀏覽器或命令列測試目標網域的 DNS 解析與 HTTPS 連線。
3. 分別測試 Git、Docker Engine 和套件管理器，不要在同一條複合指令中同時執行多個步驟。
4. 查看客戶端日誌、Docker daemon 日誌或套件工具的詳細輸出，辨認逾時、拒絕、解析失敗與認證錯誤。
5. 只修改一項設定，重新測試後記錄結果，確認問題是否真的因該變更而改善。

若連線時好時壞，可先固定目標地區與一條線路，觀察是否仍會在相同任務中失敗。若只有大型映像檔或 Release 下載失敗，應考慮長連線穩定性、分段下載、代理對大檔案的處理方式與本地磁碟空間。若每次都在驗證階段失敗，則應優先查看帳號權限、Token、SSH 金鑰或 Registry 憑證，而不是繼續測速。

當問題涉及公司程式碼、私有映像檔或內部套件時，還要遵守公司資訊安全政策。VPN 或代理可以改變網路路徑，不能取代存取控制、雙因素驗證、程式碼審查與祕密管理。開發者也不應使用不明公共代理轉發私有原始碼、部署憑證或容器認證資料。