開發者 VPN 完整攻略：GitHub、Docker、npm 下⁠載一次搞定

開發者使用 VPN 時，真正需要處理的不是「所有流量都變快」，而是讓 GitHub、Docker Hub、npm Registry、PyPI 與 CI 建置流程走到合適的出口，同時避免本地服務、內網與無關流量被錯誤轉送。Git clone、套件下載、映像檔拉取與容器建置，使用的網域、連線方式和代理讀取規則並不完全相同；瀏覽器能開啟 GitHub，也不代表命令列工具已經正確使用代理。

比較穩妥的做法是先確認用戶端能正常連線，再依工具設定代理，最後透過實際的 clone、pull、npm install、pip install 與 docker pull 逐項驗證。Windows、macOS、Linux 官方客戶端通常適合快速建立系統代理；Clash Verge 與 sing-box 方便管理規則和訂閱，Shadowrocket 則比較適合行動裝置測試。不同客戶端支援的協定組合可能不同，Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 不能只看名稱判斷優劣，應以訂閱下發的完整參數和目前網路環境為準。

開發工具的流量為何需要分開規劃

GitHub 常見流量包括網頁登入、Git over HTTPS、Git over SSH、Release 下載與 API 請求。這些流量可能由不同程式建立，瀏覽器採用的代理設定不一定會被 Git 或 SSH 繼承。Docker 則至少分成 Docker CLI 與 Docker daemon：前者負責向 daemon 發送指令，後者實際連線至 Registry、下載映像檔與建立部分建置流程。只設定終端機代理，並不代表 daemon 已經取得相同設定。

npm、pnpm、Yarn 與 pip 通常會讀取各自的設定檔或環境變數。若團隊同時使用公司內部 Registry、公開 Registry 和私有套件庫，直接啟用全域代理可能造成內網請求繞行遠端，甚至出現登入、憑證或 DNS 解析問題。CI 也有相同情況：本機測試成功，不代表 Runner、容器內的 Shell 或 Docker 建置階段能使用本機的代理。

HBVPN 涵蓋 90+ 個國家、提供 200+ 條線路，且不限裝置台數。這對同時使用桌面電腦、測試機、手機與家庭伺服器的開發者比較方便，但多台裝置共用時仍應注意方案流量，以及不同線路之間的出口一致性。選擇節點時，可以先使用距離較近、一般網頁表現穩定的線路；需要特定服務地區或長時間下載時，再測試相應的出口與線路類型。

先決定哪些流量要代理

• ✅ GitHub、Docker Hub、公開 npm Registry 與 PyPI 可依實際可達性加入代理規則。
• ✅ 公司內網、localhost、區域網路位址與私有 Registry 通常應保持直連。
• ✅ 將瀏覽器、Git、Docker daemon 和 CI 分開測試，避免把問題混在一起。
• ✅ 使用規則模式時，確認 Registry 網域沒有被錯誤匹配至直連或錯誤出口。
• ❌ 不要因為瀏覽器可以開啟頁面，就直接假設所有命令列工具都已經使用代理。

用戶端與訂閱匯入的正確順序

Windows、macOS、Android、iOS 與 Linux 都可以先使用相應的官方客戶端；若需要更細緻的規則分流，桌面端可考慮 Clash Verge 或 sing-box，iOS 環境則可使用 Shadowrocket 等相容客戶端。實際可用性取決於裝置商店地區、客戶端版本與訂閱所包含的協定。不要把一份訂閱連結直接貼入不支援該格式或該協定的程式，否則可能出現節點清單空白、匯入成功但無法連線等問題。

1. 從 HBVPN 官方入口註冊或登入，保存使用者名稱、密碼與訂閱連結。註冊無需電子郵件地址。
2. 在目標平台安裝相容的官方客戶端或第三方客戶端，確認來源可靠並完成必要權限設定。
3. 將訂閱連結匯入客戶端，更新節點清單，不要自行刪除傳輸層、TLS、SNI 或安全參數。
4. 先選擇鄰近地區的節點測試一般網頁，再依 GitHub、Registry 或 CI 的需求選擇出口。
5. 啟用規則模式或系統代理，接著在終端機中檢查命令列工具是否真的能建立連線。

如果客戶端顯示已連線，但 GitHub 或套件工具仍然失敗，先不要連續切換多個節點。應依序檢查系統代理是否啟用、Shell 是否繼承代理變數、工具是否有自己的獨立設定，以及 DNS 是否能解析目標網域。某些客戶端的規則模式隻影響支援系統代理的應用程式，原生 SSH、Docker daemon 或背景服務可能完全不受影響。

命令列代理設定與驗證方法

命令列工具最常見的方式是使用 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 等環境變數。代理位址應以目前客戶端實際提供的本機代理端點為準，不要照抄網路文章中的固定埠號。以下使用佔位符表示本機代理，請替換為客戶端顯示的協定、位址與連接埠：

export HTTP_PROXY="http://127.0.0.1:<HTTP_PORT>"
export HTTPS_PROXY="http://127.0.0.1:<HTTP_PORT>"
export ALL_PROXY="socks5://127.0.0.1:<SOCKS_PORT>"
export NO_PROXY="localhost,127.0.0.1,.local,.internal"

Windows PowerShell 可使用 $env:HTTP_PROXY、$env:HTTPS_PROXY 與 $env:NO_PROXY 設定目前工作階段；若使用 macOS 或 Linux，Shell 設定只會影響從該 Shell 啟動的程式。重新開啟終端機後，環境變數可能消失，是否要寫入 Shell 設定檔，應依個人電腦安全政策決定。離開受代理需求的網路環境後，也要記得清除或停用這些變數。

Git 與 SSH 的分別處理

Git over HTTPS 可以透過 Git 自己的設定使用 HTTP 代理。設定前先確認代理端點可用，並避免把包含帳號密碼的代理字串寫入會被提交的檔案。若只想在單一專案測試，可以使用專案層級設定；若要套用至所有本機專案，才考慮使用全域設定。完成後應實際執行 git ls-remote 或從測試倉庫執行 git clone，觀察是否能取得遠端資訊。

git config --global http.proxy http://127.0.0.1:<HTTP_PORT>
git config --global https.proxy http://127.0.0.1:<HTTP_PORT>
git config --global --get http.proxy
git config --global --get https.proxy

Git over SSH 不會自動讀取 Git 的 HTTP 代理設定。若專案使用 SSH，需在 SSH 用戶端層設定 ProxyCommand，或改用服務商與團隊允許的 HTTPS 方式。不要在不理解跳板與金鑰流程的情況下，任意把 HTTPS 代理參數套用到 SSH；協定、驗證方式與主機金鑰檢查並不相同。企業環境還應確認代理是否允許長時間連線，以及是否會改寫或阻斷 SSH 流量。

npm 與 pip 的代理邊界

npm 可透過設定檔指定 proxy 與 https-proxy，也能在部分情況下讀取環境變數。設定時要同時檢查目前使用的 Registry，因為 npm 套件來源可能已被團隊配置成私有鏡像。若公開套件能下載、私有套件卻失敗，問題可能不是代理速度，而是內部憑證、權限或 Registry 位址不在 NO_PROXY 規則中。

npm config set proxy http://127.0.0.1:<HTTP_PORT>
npm config set https-proxy http://127.0.0.1:<HTTP_PORT>
npm config get registry
npm ping

pip 則可使用命令列的 --proxy，或在 pip 設定檔中指定代理。團隊若採用內部套件索引，應明確區分公開來源與私有來源，不要為了下載一個套件而把所有 Python 連線都導向同一出口。套件下載成功後，還要確認雜湊檢查、憑證驗證與套件來源符合專案的安全要求。

python -m pip install --proxy http://127.0.0.1:<HTTP_PORT> <PACKAGE_NAME>
python -m pip config list

Docker Hub 與映像檔建置的代理設定

Docker 的排查重點是分清楚 CLI、daemon 與建置容器。執行 docker pull 時，通常由 Docker daemon 連線至 Registry；即使終端機已有 HTTP_PROXY，daemon 仍可能沒有代理設定。若使用 Docker Desktop，應在其引擎或代理設定中確認；若是 Linux 上的獨立 daemon，則要依系統服務方式為 daemon 提供代理，完成後重新載入服務設定。

Dockerfile 中的 ARG HTTP_PROXY、ARG HTTPS_PROXY 隻影響建置階段是否把代理傳入指令環境，不能取代 daemon 連線 Docker Hub 所需的代理。執行時容器是否需要代理，也應透過執行參數或編排工具設定。更重要的是，含有敏感資訊的代理網址不應直接寫進 Dockerfile 或映像檔層，否則可能在歷史層、快取或建置日誌中留下憑證。

docker info
docker pull <IMAGE_NAME>
docker build --build-arg HTTP_PROXY=http://127.0.0.1:<HTTP_PORT> \
  --build-arg HTTPS_PROXY=http://127.0.0.1:<HTTP_PORT> \
  -t <IMAGE_NAME> .

如果 docker info 正常，但 docker pull 失敗，優先檢查 daemon 的代理、DNS 與 Registry 憑證；如果拉取成功而 docker build 在 apt、apk、npm 或 pip 階段失敗，則檢查建置容器是否收到代理變數，以及 Dockerfile 中是否把私有網域正確加入直連規則。使用多階段建置時，每個需要下載依賴的階段都要考慮代理是否可用。

CI 建置如何避免本機成功、伺服器失敗

CI 的網路環境與本機不同，Runner 可能位於容器、虛擬機器或雲端網路中。最常見的錯誤是隻在本機設定代理，卻沒有在 CI 的 Variables、Runner 服務或建置容器中設定；另一個問題是把完整代理網址輸出到除錯日誌，導致帳密或訂閱資訊外洩。CI 設定應使用平台的加密變數，並依最小權限原則提供必要的代理資訊。

建議把 CI 的驗證拆成數個明確階段：先檢查 DNS 與基本 HTTPS 連線，再確認 Git 依賴可以取得，接著測試 npm 或 pip 安裝，最後才執行 Docker pull 與 image build。每個階段都應保留不含敏感資料的錯誤摘要。若只看到「network error」，可以檢查代理是否被子程序繼承、容器是否能解析代理主機、憑證鏈是否完整，以及私有 Registry 是否被錯誤送往外部代理。

• ✅ 將 HTTP_PROXY、HTTPS_PROXY 與 NO_PROXY 以加密變數注入 CI 工作階段。
• ✅ 為 Git、套件管理器和 Docker daemon 分別確認代理是否生效。
• ✅ 對私有 Registry、公司網域與內部 API 設定清楚的直連規則。
• ✅ 在建置日誌中遮蔽代理帳密、訂閱連結與私有套件憑證。
• ❌ 不要把本機的 localhost 代理位址直接寫進遠端 Runner 設定。
• ❌ 不要把暫時性的全域代理設定提交到專案版本庫。

若團隊需要長期穩定的建置流程，應優先使用合法、可管理的內部鏡像或快取 Registry，並把外部套件版本鎖定、雜湊驗證與來源審查納入流程。VPN 或代理可以改善取得外部依賴時的連線路徑，但不能取代套件供應鏈安全、鏡像可用性管理與 CI 權限控管。對於需要固定出口的工作，可選擇較穩定的 IEPL 或 BGP 線路進行比較；對於一般開發下載，則應先以鄰近且規則清晰的線路驗證。

常見故障與最後檢查清單

GitHub 網頁正常但 Git clone 失敗，通常要檢查 Git 自己的代理設定、憑證、SSH 與 HTTPS 的差異。Docker Hub 可以在瀏覽器開啟但 docker pull 失敗，通常要回到 daemon、DNS 或 Registry 憑證層排查。npm 下載速度不穩，應先確認目前 Registry、代理協定與套件快取；pip 失敗則要分辨是代理連線、TLS 憑證、索引網址還是套件本身不存在。

切換節點後，請關閉長時間保持的 Git、Docker 或套件下載工作，再重新執行測試。舊 TCP 連線可能仍然使用原先出口，立即重試不一定能反映新線路。若所有工具同時失敗，先檢查客戶端是否真的在線、系統時間是否正確、DNS 是否可用，以及本機防火牆是否阻擋代理端點；若只有一個工具失敗，優先查看該工具的獨立設定。

• ✅ 客戶端顯示已連線，且訂閱節點與協定參數完整。
• ✅ 瀏覽器、終端機、Git、Docker daemon 與 CI 分別完成驗證。
• ✅ NO_PROXY 包含 localhost、內網與私有服務，但不誤排公開 Registry。
• ✅ 切換線路後重新建立工作階段，不沿用舊的下載或 SSH 連線。
• ✅ 將代理設定、憑證和訂閱資訊與專案程式碼分離保存。
• ❌ 不要把單次測速結果當成 Git、Docker 或套件下載的完整結論。

對多數開發者而言，最實用的方案不是永久開啟全域代理，而是使用規則分流：GitHub、公開 Registry 與必要的外部依賴走合適線路，本地服務和內部資源保持直連。HBVPN 支援 Windows、macOS、iOS、Android 與 Linux，付款方式包含支付寶、微信與 USDT，並提供 60 天無理由退款。完成訂閱匯入後，建議先從一台主要開發機開始建立可重複的設定，再逐步同步至其他裝置與 CI 環境。