開發者 VPN 實戰指⁠南：GitHub、Docker、npm 加⁠速一次搞定

GitHub clone 卡住、Docker 映像檔下載逾時，或 npm、pip 安裝速度不穩，通常不是單一工具故障，而是開發程序與網路路徑沒有對齊。瀏覽器能開啟 GitHub，不代表 Git 命令列、Docker daemon 或 CI/CD runner 也會使用同一個代理；桌面用戶端顯示已連線，也不代表所有背景服務都已經被接管。

要讓開發環境穩定，應把問題拆成三層：先確認 VPN 或代理通道本身能正常建立，再確認作業系統、終端機與背景服務是否使用正確的代理入口，最後從 Git、Docker、npm、pip 以及自動化建置日誌中驗證實際結果。這種做法比反覆更換節點或單純測試網頁更容易找到根因，也方便日後維護。

先釐清開發工具的連線層級

VPN 通常負責改變作業系統或指定應用程式的網路路徑；代理則是讓某個應用程式把請求交給本機代理連接埠，再由代理用戶端轉送。兩者不是完全相同的概念。Windows、macOS、Android、iOS 與 Linux 官方用戶端可能提供系統代理、規則模式或虛擬網卡模式；Clash Verge、sing-box、Shadowrocket 等相容用戶端，則可能讓你分別管理本機 HTTP、HTTPS、SOCKS5 入口。

Git 通常會讀取自己的設定與部分環境變數；npm、pip 也有各自的代理設定；Docker CLI 發出的請求，還要看實際工作的 Docker daemon 是本機程序、Linux 服務，還是遠端主機。換句話說，單純在桌面用戶端勾選「系統代理」，並不能保證 Docker daemon 或遠端建置服務會自動繼承。

實務上可先選擇一種接管方式，再逐項測試。若只是 Git、npm 與 pip 需要代理，系統代理加上工具層設定通常較容易控制；若 Docker、套件管理器與其他背景程序都要走同一條路徑，虛擬網卡或通道模式可能更完整，但也要注意路由、DNS、系統權限與分流規則。

• ✅ 先確認用戶端已連線，再確認本機代理連接埠或虛擬網卡已啟用。
• ✅ 將瀏覽器、終端機、Docker daemon 和 CI/CD runner 視為獨立環境分別驗證。
• ✅ 本地套件鏡像、內網 Git 服務與公司網域可按需求保留直連。
• ❌ 不要同時啟用兩個代理用戶端，避免連接埠、路由和 DNS 設定互相覆寫。

GitHub clone 與 Git 操作的穩定設定

Git clone 會同時涉及網域解析、TLS 連線、遠端驗證、物件下載與工作階段維持。大型倉庫、子模組或需要多次拉取的專案，對短暫丟包和連線重建更敏感。若只在瀏覽器中確認 GitHub 頁面能開啟，仍不足以證明 Git 命令列具備相同的連線條件。

先確認終端機是否繼承桌面代理。常見做法是設定目前工作階段的 HTTP 與 HTTPS 代理環境變數，再執行 Git 操作；若不希望所有命令都經過代理，也可以改用 Git 自己的設定。以下範例中的位址和連接埠應替換為目前用戶端實際提供的本機入口，不要直接照抄不存在的連接埠。

export HTTP_PROXY="http://127.0.0.1:本機HTTP連接埠"
export HTTPS_PROXY="http://127.0.0.1:本機HTTP連接埠"

git config --global http.proxy "$HTTP_PROXY"
git config --global https.proxy "$HTTPS_PROXY"

git config --global --get-regexp 'http.*proxy'

如果使用 SOCKS5 入口，Git 是否能直接使用，取決於版本與底層傳輸支援。遇到設定後仍無法連線的情況，不要只改代理協定；先查看 Git 輸出的錯誤是 DNS 失敗、TLS 憑證問題、代理拒絕，還是遠端服務主動中斷。把所有錯誤都歸類成「速度慢」，會讓排查方向失準。

SSH 與 HTTPS 是兩條不同的設定路徑。HTTPS clone 通常較容易配合 HTTP 代理；SSH clone 則需要在 SSH 設定中指定跳板或代理方式，不能只依賴 Git 的 HTTP proxy。若團隊使用 SSH 金鑰，應先在不涉及敏感資料的情況下測試主機交握，再確認實際倉庫權限。認證失敗與網路逾時必須分開處理。

Docker 映像檔下載與 daemon 代理

Docker 最容易被誤判的地方，是命令列與背景 daemon 並不一定在同一個環境。當你執行 docker pull 時，CLI 可能只是向 Docker daemon 發送請求，真正連往映像檔倉庫的是 daemon。即使終端機已設定 HTTP_PROXY，Docker daemon 仍可能沒有代理設定，因此映像檔下載依然逾時。

本機 Docker Desktop、Linux 上的 Docker 服務，以及遠端 Docker 主機的設定方式不同。應先確認目前 CLI 連接的是哪個 daemon，再在對應環境設定代理。Linux 服務通常需要在 systemd 的服務環境中設定；Docker Desktop 則應使用其設定頁中的代理選項。修改後要重新載入服務，並以日誌確認設定是否被讀取。

docker context show
docker info
docker pull <映像檔名稱>

若映像檔可以開始下載但中途失敗，還要區分映像檔倉庫連線、DNS、認證和本地儲存空間等問題。代理只處理網路路徑，不能解決錯誤的倉庫名稱、失效的登入憑證、磁碟空間不足或映像檔標籤不存在。企業環境中若使用私有 Registry，也要確認其網域是否應直連，以及 TLS 憑證是否由 Docker daemon 信任。

另外，Docker 建置程序可能同時包含兩種網路：一種是 daemon 拉取基礎映像檔時的網路，另一種是建置步驟執行 apt、npm 或 pip 時的網路。前者設定成功，不代表後者一定能用。若 Dockerfile 內的套件下載失敗，應在建置階段檢查代理是否傳入、憑證是否可用，以及是否將代理帳號或密碼不慎寫入映像檔層。

• ✅ 先用 docker context show 確認實際 daemon。
• ✅ 分開驗證基礎映像檔拉取與 Dockerfile 內的套件下載。
• ✅ 將代理憑證放在安全的建置機密中，不要硬編碼到 Dockerfile。
• ❌ 不要因為 docker pull 成功，就認定所有建置步驟都能正常連線。

npm 與 pip 套件安裝的代理策略

npm 和 pip 的請求通常由命令列程序直接發出，不一定遵循瀏覽器代理。npm 可以使用自己的設定項目，也會受到部分環境變數影響；pip 則可透過命令列參數、設定檔或環境變數指定代理。團隊環境中應選擇一種清楚且可撤銷的管理方式，避免全域設定、專案設定與 Shell 環境同時存在，最後無法判斷哪個值生效。

npm config set proxy http://127.0.0.1:本機HTTP連接埠
npm config set https-proxy http://127.0.0.1:本機HTTP連接埠
npm config get proxy
npm config get https-proxy

python -m pip install --proxy http://127.0.0.1:本機HTTP連接埠 套件名稱

npm 的 registry 設定與代理設定是兩個不同問題。registry 決定套件從哪個服務取得，代理決定請求如何抵達該服務。pip 也可能使用自訂索引、額外索引或企業內部套件站。遇到安裝失敗時，先確認目標 registry、憑證和套件版本，再檢查代理；不要為了追求速度而隨意把未驗證的第三方鏡像設成全域來源。

對正式專案而言，鎖定檔、套件雜湊、私有套件權限和憑證驗證比單次下載速度更重要。若代理會進行 TLS 檢查，系統可能需要安裝企業根憑證；不應用關閉 SSL 驗證的方式繞過錯誤，因為那會削弱套件供應鏈的安全性。完成設定後，應清理不再需要的全域代理，並把可公開的設定與機密憑證分開保存。

CI/CD 環境中的代理與機密管理

CI/CD runner 是最常見的「本機可以、流水線失敗」來源。你的電腦可能使用桌面 VPN 和本機代理連接埠，但 runner 往往位於另一個網路環境，既看不到你的 127.0.0.1，也不會自動取得本機訂閱設定。若 runner 在雲端或公司內網，應由管理者在 runner 所在環境配置出站路由、代理服務、DNS 與憑證。

在流水線中，建議把 Git、Docker、npm、pip 所需的代理參數作為受保護變數注入，並限制其作用範圍。代理 URL 若包含帳號或密碼，不能出現在公開日誌、錯誤輸出、建置產物或 Docker image layer 中。執行診斷時可只列出是否存在設定，不要直接輸出完整值。

echo "HTTP proxy configured: ${HTTP_PROXY:+yes}"
echo "HTTPS proxy configured: ${HTTPS_PROXY:+yes}"

git config --global http.proxy "$HTTP_PROXY"
npm config set proxy "$HTTP_PROXY"
python -m pip config debug

容器化 runner 還要額外確認代理變數是否由 runner 傳入建置容器，以及 Docker daemon 是否使用另一組設定。若流水線包含多個工作階段，應讓每個階段明確宣告需要的代理與憑證，避免依賴前一階段留下的暫存環境。對內部 Registry、原始碼服務與套件庫，則應透過規則分流或明確的直連清單降低不必要的繞路。

測試策略也應貼近實際流程：先拉取原始碼，再拉取基礎映像檔，接著執行套件安裝，最後進行建置與推送。每一階段都保留可讀的錯誤分類。DNS 失敗、代理拒絕、認證失敗、憑證不受信任和遠端限流的處理方式不同，不能只設定一個超長逾時來掩蓋問題。

一套可重複的排查與維護流程

當 GitHub、Docker 或套件安裝出現問題時，先不要同時更改協定、節點、代理和 registry。固定目前網路環境，記錄客戶端模式與節點，再依照「通道、代理、DNS、應用程式、遠端服務」的順序檢查。每次只改一個變數，才能知道哪項調整真正有效。

1. 確認 VPN 用戶端的連線狀態、目前模式與節點，必要時更新一次訂閱。
2. 確認出口 IP 是否符合預期，並檢查 DNS 是否由預期路徑解析。
3. 在終端機測試實際使用的代理入口，而不是隻開啟瀏覽器頁面。
4. 分別執行 Git、Docker、npm 與 pip 的最小請求，記錄各自錯誤。
5. 若問題只出現在 CI/CD，轉到 runner 主機檢查，而不是繼續修改本機設定。
6. 完成排查後移除臨時全域設定，將穩定配置寫入適當的使用者設定或流水線機密。

線路選擇方面，06VPN 支援 Windows、macOS、iOS、Android 與 Linux，並可在相容用戶端中匯入訂閱。可根據實際環境測試 Shadowsocks、VMess、Trojan、VLESS、Hysteria2、WireGuard 等協定，但不要僅以協定名稱判斷結果；本地網路、出口位置、DNS、線路類型與目標服務路由都會影響開發工具的表現。需要多台電腦或手機共同使用時，方案支援不限台數同時在線裝置，仍應為 CI/CD 機密與個人訂閱連結做好分開管理。

穩定的開發加速不是把所有流量永久導向同一條線路，而是讓每個工具知道何時使用代理、何時直連，以及發生錯誤時如何恢復。完成一次設定後，建議把代理入口、Git 協定、Docker daemon、套件來源和 CI/CD 機密位置整理成團隊文件；當網路環境或節點調整時，只需依照同一套流程重新驗證，就能降低整個開發流程的維護成本。