開發者 VPN 怎麼設定？GitHub、Docker、npm 高速工作流

開發工作卡住，很多時候不是程式碼本身出了問題，而是 GitHub 儲存庫、容器映像檔註冊中心或 npm 套件倉庫的連線不穩。瀏覽器偶爾能開啟頁面，不代表 Git、Docker daemon 與終端機內的套件管理工具都能使用同一條網路路徑。這些工具各自擁有連線程序、DNS 解析方式、憑證驗證與代理設定，任何一層不一致，都可能出現下載速度忽快忽慢、交握逾時、套件解析失敗或容器建置中斷。

本文以日常開發流程為主軸，說明如何選擇適合的 VPN 用戶端、如何匯入訂閱、如何讓終端機工具使用代理，以及如何為 GitHub、Docker 與 npm 設計不互相干擾的分流規則。重點不是把所有流量一律送進代理，而是先分清楚瀏覽器、命令列、容器服務與 CI 執行器的網路邊界，再逐層驗證。Windows、macOS、Linux、Android 與 iOS 都可以使用官方用戶端；若需要更細緻的規則，也可以依相容性選擇 Clash Verge、sing-box 或 Shadowrocket 等用戶端。

開發者 VPN先釐清用戶端、訂閱與代理層

VPN 用戶端負責建立系統層級的通道，訂閱連結則提供節點、協定與相關參數。兩者不是同一件事。取得訂閱後，應使用服務說明所列出的相容應用程式匯入，而不是把訂閱網址直接貼入 Git 或 Docker 的設定檔。常見的 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard，在加密方式、傳輸層與設定格式上各不相同，用戶端與服務端必須支援同一組參數才能正常建立連線。

如果主要工作是瀏覽文件、查閱儲存庫與下載套件，Windows 或 macOS 官方用戶端通常較容易開始；Linux 開發機則可使用官方用戶端或相容的 sing-box、Clash Verge 設定。Shadowrocket 主要適合 iOS 裝置。無論選擇哪種工具，都應先確認訂閱匯入、規則分流、DNS 處理與自動重新連線是否可用，再比較不同節點的實際工作表現。

線路名稱也需要正確理解。直連、中轉、BGP 或 CN2 描述的是網路路徑與互聯方式；IEPL 通常指企業級國際專線類傳輸。Shadowsocks、VMess、Trojan、Hysteria2 與 WireGuard 則屬於不同層面的協定或傳輸方案。不要只看節點名稱中的「高速」或「專線」字樣，應觀察 Git 操作、映像檔拉取與套件下載能否連續完成，並檢查切換網路後是否能恢復。

GitHub 與 Git的終端機代理設定

GitHub 的使用情境至少包括網頁存取、HTTPS 方式的 clone 或 fetch，以及 SSH 方式的遠端連線。瀏覽器能開啟 GitHub，不代表終端機中的 Git 會自動使用同一個代理。桌面 VPN 若採用全域模式，通常可以涵蓋 Git；規則分流則需要確保相關網域與連線程序沒有被錯誤判定為直連。

使用 HTTPS 遠端網址時，可以在 Git 設定中指定代理，但要注意這是 Git 自己的設定，不等同於系統環境變數。以 HTTP 代理為例，可在確認代理位址與連接埠後執行：

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 --get-regexp 'http.*proxy'

上面的 PORT 必須替換為實際用戶端提供的本機代理連接埠，不要直接照抄。若用戶端使用 SOCKS5，則應依用戶端格式使用 socks5h://，讓網域解析也交由代理處理。測試完成後，若不再需要 Git 專用代理，可以移除設定，避免日後切換網路時誤以為 GitHub 服務故障：

git config --global --unset http.proxy
git config --global --unset https.proxy

SSH 連線則不會讀取上述 HTTP 代理設定。若公司網路或目前接入環境對 SSH 不友善，可以改用 HTTPS 遠端網址，或依團隊安全規範設定 SSH 的 ProxyCommand。不要把私人金鑰、存取權杖或完整訂閱連結放進公開腳本與截圖。遇到 clone 卡住時，先用 git remote -v 判斷目前是 HTTPS 還是 SSH，再針對正確層級排查。

Docker 映像檔下載與 daemon 代理

Docker 是最容易被誤判的環節。你在終端機設定了 HTTP_PROXY，只代表目前這個 shell 內啟動的程序可能讀取環境變數；Docker CLI 發出的請求最後通常由 Docker daemon 執行。Docker daemon 可能在本機背景服務、遠端主機、虛擬機或 Windows/macOS 的桌面虛擬化環境中運作，因此它不一定能看到桌面用戶端的本機代理位址。

開始設定前，先確認 Docker daemon 的實際位置，以及映像檔來源是 Docker Hub、私有 Registry 還是團隊內部鏡像。若只在 CLI 端設定代理，docker pull 仍然逾時，通常表示 daemon 沒有代理或無法連到主機上的本機代理。對 systemd 管理的 Linux 服務，可依作業系統的服務設定方式加入代理環境，再重新載入服務並查看 daemon 狀態；不要把含有帳號密碼的代理字串直接提交到版本庫。

建立映像檔時還要分清楚兩件事：建置程序的網路，以及容器執行時的網路。docker build 需要取得基底映像檔並執行套件安裝；容器啟動後的應用程式則可能需要另一組環境變數。兩者都應依最小必要原則配置，並透過安全的環境注入方式傳入，而不是將代理憑證寫死在 Dockerfile 或映像檔層中。

1. 確認 VPN 用戶端已連線，並記下本機 HTTP 或 SOCKS5 代理的實際入口。
2. 確認 Docker daemon 是本機服務、桌面虛擬機還是遠端主機。
3. 先測試目標 Registry 的網域解析與 TLS 交握，再執行映像檔拉取。
4. 若仍然失敗，查看 daemon 日誌，區分代理拒絕、DNS 失敗、憑證錯誤與連線逾時。
5. 建置完成後，檢查 Dockerfile、建置快取與 CI 設定是否意外保存代理憑證。

• ✅ 將 Docker daemon 視為獨立網路程序，單獨確認它能否使用代理。
• ✅ 基底映像檔、套件來源與私有 Registry 分別驗證，不要只測試首頁。
• ✅ 在建置記錄中遮蔽權杖、密碼與帶有驗證資訊的 URL。
• ❌ 不要把桌面 VPN 的 127.0.0.1 直接當成遠端 daemon 可使用的代理位址。
• ❌ 不要在 Dockerfile 中永久寫入私人代理憑證。

npm 套件倉庫與終端機分流

npm 下載通常受到 Registry 網域、DNS、代理環境變數與本機快取共同影響。先用 npm config get registry 確認目前套件來源，再決定是否需要代理。若團隊已有固定的私有 Registry，不應為了追求下載速度而隨意改成陌生來源；供應鏈安全、套件完整性與團隊鎖定檔一致性，比單次下載速度更重要。

需要讓 npm 透過代理時，可在 npm 設定中明確指定 HTTP 或 HTTPS 代理。設定前先確認用戶端的代理格式，並避免將含認證資訊的指令貼入共享終端機記錄。若只是暫時測試，也可以使用目前 shell 的環境變數；測試結束後清除，避免影響不需要代理的內部套件來源。

npm config get registry
npm config set https-proxy http://127.0.0.1:PORT
npm config get https-proxy

分流時可以把公開套件倉庫、GitHub API、容器 Registry 與公司內部網域分開處理。常見做法是讓公開開發資源走代理，內部 Git、私有套件倉庫與本機服務保持直連，但實際規則仍要依公司網路政策與 DNS 架構調整。規則更新後，應分別測試套件中繼資料、壓縮檔下載與登入流程，因為它們可能使用不同網域。

CI 環境如何設計代理與安全邊界

CI 與個人電腦最大的差異，是執行器通常是短生命週期、非互動式且可能位於不同網路環境。即使開發機上的 VPN 已能正常 clone、pull 與 install，CI 執行器仍可能無法存取同樣的 GitHub、Registry 或套件來源。應先確認執行器所在主機是否允許出站連線，再決定使用網路層代理、Runner 層代理，或由企業閘道統一轉送。

CI 設定建議把 HTTP_PROXY、HTTPS_PROXY 與 NO_PROXY 視為部署變數管理。NO_PROXY 可放入本機回環位址、服務名稱、內部網域與需要直連的管理端點，避免健康檢查或服務間通訊繞行外部代理。代理認證則應使用 CI 平台的加密變數或短期憑證，並確認日誌不會展開完整環境變數。

若 CI 需要透過特定出口存取外部資源，應保留可追蹤的設定版本，記錄代理用途、適用工作流程與撤銷方式。不要讓所有工作都使用全域代理，也不要為了繞過單一下載錯誤而關閉 TLS 驗證。若使用自建 Registry 或快取服務，應優先從快取與依賴鎖定方向改善，而不是在每次建置時隨意切換套件來源。

• ✅ 將 CI 代理設定放在受保護的變數與執行器層級。
• ✅ 為公開來源、內部來源與本機服務建立清楚的分流邊界。
• ✅ 在日誌中保留錯誤類型與網域，遮蔽權杖、密碼及完整訂閱資訊。
• ✅ 開發機與 CI 分別驗證，不把個人電腦的成功結果當成部署環境證明。
• ❌ 不要使用關閉憑證驗證的方式處理代理交握問題。
• ❌ 不要讓未知的第三方套件來源取代團隊覈准的 Registry。

故障排查與日常使用建議

當 GitHub、Docker 或 npm 同時出現問題時，先檢查 VPN 是否真的建立通道，再檢查 DNS 是否能解析目標網域，接著確認對應程序是否讀取代理，最後才比較節點與線路。若只有瀏覽器正常，通常是終端機或背景服務沒有套用代理；若只有 Docker 失敗，則優先檢查 daemon 的網路位置；若 npm 能取得中繼資料卻無法下載壓縮檔，則應查看 Registry 是否使用了不同的下載網域。

更換 Wi-Fi、行動網路或節點後，建議重新啟動受影響的命令列工作階段與 Docker 操作，不要只查看 VPN 圖示。部分長連線會保留舊的 DNS 或 TCP 工作階段，表面上仍顯示連線，實際請求卻已經失效。規則修改後也要清理不必要的快取，並記錄修改前後的結果，讓團隊能夠重現問題。

對個人開發者而言，最實用的配置通常是官方用戶端加上規則分流，先讓 GitHub、Docker Registry 與 npm 的必要網域走代理，再逐一確認 Git、Docker daemon 與 npm 的代理設定。團隊環境則應統一 Registry、憑證與 CI 出口政策，避免每位成員自行使用不同套件來源。若需要開始使用，可先查看教程，再依平台取得相容用戶端；套餐、流量與平台支援則可前往查看套餐核對。