開發者 VPN 實戰：GitHub、Docker、npm 加速一次配好

對開發者而言，VPN 加速的難點通常不在於「連上某個節點」，而在於不同工具使用不同的代理入口：Git 可能讀取自己的設定，Docker Engine 由 daemon 負責拉取映像檔，npm 則依賴 registry 與命令列環境變數。只在桌面用戶端開啟全域模式，未必能讓終端機、Docker 服務與套件管理器按照預期工作。

本文以 GitHub 原始碼同步、Docker Hub 映像檔下載與 npm 套件安裝為主，整理一套可在 Windows、macOS、Linux 上實施的設定方法。你可以使用 PeeVPN 官方用戶端，也可以在相容的 Clash Verge、sing-box 或其他規則型用戶端中匯入訂閱，再依照工具本身的本機代理埠完成分流。重點不是把所有流量永久交給代理，而是先確認代理入口，再讓需要的開發工具使用正確規則。

先理解三種開發流量的差異

GitHub、Docker Hub 與 npm 看似都是下載網路資源，實際上卻由不同程式和不同設定檔處理。Git 可能透過 HTTPS 存取遠端儲存庫，也可能使用 SSH；Docker CLI 發出的拉取請求通常交給背景執行的 Docker daemon；npm 則會讀取 registry 設定、環境變數與使用者層級的設定檔。這些程式不一定會自動採用桌面 VPN 用戶端的系統代理。

• ✅ 先確認 PeeVPN 用戶端已完成訂閱匯入、節點選擇與系統授權。
• ✅ 先用瀏覽器確認 GitHub、Docker Hub 或 npm registry 可正常開啟，再處理命令列。
• ✅ 每次只修改一層設定，避免同時更換節點、代理模式、DNS 與工具參數。
• ❌ 不要以「用戶端顯示已連線」推斷所有背景服務都已經走代理。

如果使用 Clash Verge 或 sing-box，通常需要先確認 HTTP、HTTPS 或 SOCKS5 本機監聽埠。不同配置與用戶端的埠號可能不同，不能直接照抄網路文章中的數值。Shadowrocket 主要服務於 iOS，適合在手機上驗證規則與出口；但 Git、Docker 與 npm 的實際設定方式，仍取決於你執行工具的裝置及其網路代理能力。

PeeVPN 支援 Windows、macOS、iOS、Android 與 Linux。開發者若需要在桌面與手機之間切換，可以分別使用對應官方用戶端；若偏好自訂規則，則應先確認相容客戶端是否支援訂閱中的 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 WireGuard 等協定。協定能否被辨識，會直接影響後續的路由與代理設定。

GitHub 與 Git 的代理設定方式

GitHub 原始碼同步常見兩種協議：HTTPS 與 SSH。HTTPS 比較容易套用 HTTP 或 HTTPS 代理；SSH 則需要另外設定 SSH 的 ProxyCommand，不能只設定 http.proxy 就期待所有 SSH 遠端連線通過代理。首次排查時，建議先確認遠端網址格式，再決定使用哪一種方式。

HTTPS 遠端：使用 Git 自己的代理設定

假設相容用戶端提供本機 HTTP 代理，並且你已經確認實際監聽位址與埠號，可以在終端機執行以下命令。示例中的 127.0.0.1:PORT 只是格式佔位，請替換成用戶端顯示的實際值，不要把範例數字當成固定設定。

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 http.proxy
git config --global --get https.proxy
git ls-remote https://github.com/OWNER/REPOSITORY.git

git ls-remote 只會查詢遠端參考，適合先驗證 DNS、TLS、代理與 Git 認證流程，而不會立刻下載完整工作樹。若命令出現代理連線拒絕，先檢查代理類型與埠號；若顯示憑證或驗證錯誤，不要急著加入 http.sslVerify false，因為關閉 TLS 驗證會降低連線安全性，應先核對系統時間、用戶端設定與企業網路攔截政策。

不再需要全域代理時，可以移除 Git 設定，避免未來在不適合的網路環境中繼續套用：

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

如果只想讓單次操作走代理，可以使用命令列層級設定，而不改動全域檔案：

git -c http.proxy=http://127.0.0.1:PORT \
    -c https.proxy=http://127.0.0.1:PORT \
    clone https://github.com/OWNER/REPOSITORY.git

SSH 遠端：不要混用 HTTPS 參數

先查看目前遠端網址：

git remote -v

如果結果是 [email protected]:OWNER/REPOSITORY.git，代表使用 SSH。SSH 不會讀取 Git 的 HTTP 代理欄位，需要透過 ~/.ssh/config 指定代理命令。不同相容客戶端提供的代理程式名稱可能不同，常見做法是使用系統中的 SOCKS5 轉換工具；請先確認本機確實存在該工具，再套用設定。

Host github.com
    HostName github.com
    User git
    ProxyCommand connect -S 127.0.0.1:PORT %h %p

完成後先以 ssh -T [email protected] 檢查握手。若代理工具不支援 connect，不能只改埠號，必須按照目前客戶端支援的 SOCKS5 工具、參數或跳板方式重新撰寫。SSH 金鑰本身仍由 GitHub 帳戶管理，VPN 或代理只負責傳輸路徑，不會代替金鑰驗證。

Docker 映像檔下載：設定 daemon 而不是隻設定終端機

執行 docker pull 時，CLI 通常會把請求交給 Docker daemon。這也是許多人已經在終端機設定 HTTP_PROXY，但 Docker Hub 仍然下載失敗的原因：終端機環境變數隻影響目前命令或 CLI，未必會傳遞給背景服務。

先確認 Docker 本身的狀態，再查看目前版本與上下文：

docker version
docker context show
docker info

在 Linux 使用 systemd 管理 Docker 時，可以為服務建立代理環境設定。以下是操作方向，實際目錄與服務名稱應以你的發行版及 Docker 安裝方式為準：

sudo systemctl edit docker

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:PORT"
Environment="HTTPS_PROXY=http://127.0.0.1:PORT"
Environment="NO_PROXY=localhost,127.0.0.1"

儲存後重新載入服務設定，再重啟 Docker，最後檢查 docker info 顯示的代理欄位。若使用 Docker Desktop，代理設定通常應在 Docker Desktop 的設定介面處理，而不是直接修改 Linux daemon 檔案。Windows 與 macOS 上的 Docker Desktop 可能在虛擬機或獨立服務中執行，宿主機終端機的代理變數不一定能影響其內部網路。

NO_PROXY 也很重要。localhost、本機開發服務、內部 registry 或區域網路資源通常不應繞到外部代理。若把所有網域都交給代理，可能導致內網名稱無法解析；若 NO_PROXY 過度寬泛，又可能讓本來需要代理的映像檔請求意外直連。調整後可以使用一個公開映像檔做基本拉取測試，並觀察 daemon 日誌，而不是反覆執行大型映像檔下載。

npm registry 與命令列代理

npm 的速度問題可能來自 registry 解析、代理協議、TLS 交握、套件快取或特定套件的依賴來源。先查看目前使用的 registry 與代理設定，可以避免在不知道原始狀態的情況下反覆修改：

npm config get registry
npm config get proxy
npm config get https-proxy
npm config list

若相容客戶端提供 HTTP 代理，可以將 npm 的代理欄位指向該入口：

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

npm ping
npm view npm version

npm ping 用於確認 registry 是否能回應，npm view 則能測試查詢套件 metadata。這兩個測試比直接執行完整 npm install 更容易定位問題。若公司或校園網路使用自簽憑證代理，不要為了讓安裝通過而永久設定嚴格 TLS 檢查為關閉狀態，應向網路管理員取得正確的 CA 設定，並確認代理是否真的需要攔截 HTTPS。

如果你只想為某個專案指定 registry，可以在專案目錄放置 .npmrc，但要注意它可能被一併提交到版本控制。公開專案通常不應放入私人 registry 的 token；需要登入私人 registry 時，應使用 npm 建議的使用者層級設定或受保護的環境變數。完成測試後，可以列出設定檔位置，確認沒有把祕密值寫入錯誤層級：

npm config get userconfig
npm config get globalconfig
npm config delete proxy
npm config delete https-proxy

npm 也能讀取 HTTP_PROXY、HTTPS_PROXY 與 NO_PROXY 等環境變數。環境變數適合 CI 或臨時工作階段，但不要把包含 token 的完整命令寫入 CI 公開輸出。若 GitHub Actions、公司 CI 或容器內的 npm 行為與本機不同，應在相同執行環境中檢查 DNS、代理可達性與憑據來源。

動手建立一套可回復的分流設定

比較穩妥的做法，是先建立最小可用配置，再逐步加入規則。先在相容客戶端中匯入 PeeVPN 訂閱，選擇一條適合目前網路的線路，確認本機 HTTP 或 SOCKS5 代理入口，再開始調整 Git、Docker 與 npm。不要一開始就把所有網域加入複雜規則，否則遇到問題時很難知道是規則、DNS 還是工具本身造成。

1. 在官方用戶端或相容客戶端中匯入訂閱，確認節點列表已更新，並選取一條線路。
2. 查看客戶端的 HTTP、HTTPS、SOCKS5 本機代理入口，記下協議與埠號；實際數值以客戶端介面為準。
3. 先用瀏覽器測試 GitHub、Docker Hub 與 npm registry，確認代理模式能處理這些網域。
4. 使用 git ls-remote、docker info 或小型映像檔拉取、npm ping 分別驗證三條路徑。
5. 把需要長期使用的設定寫入正確層級；Git 可用全域設定，Docker 要設定 daemon，npm 則要分清專案、使用者與環境變數。
6. 最後建立 NO_PROXY 清單，加入 localhost、本機服務及確實應直連的內部網域。

建議將每個工具的修改記錄在本機安全文件中，包括設定檔位置、目前使用的代理類型、規則目的與撤銷命令。這比複製一份來路不明的完整配置更容易維護。當節點或代理入口變更時，只需先更新一個變數或設定項，再逐項重新測試。

• ✅ Git HTTPS、Git SSH 分開測試，不用一種協議的結果推斷另一種。
• ✅ Docker Desktop 與 Linux daemon 分開確認，查看真正執行拉取請求的服務。
• ✅ npm 先驗證 registry，再驗證套件 metadata，最後才執行完整安裝。
• ❌ 不要同時啟用兩個代理核心，避免路由、DNS 與本機埠互相衝突。
• ❌ 不要把整個家庭或公司網段直接交給外部代理，先確認內部服務的解析需求。

故障排查與流量控制

若 GitHub 可以在瀏覽器開啟，但 Git 命令失敗，先查看 git config --show-origin --get-regexp proxy，確認是否存在過期或重複代理設定。若 Docker 失敗而 Git、npm 正常，優先檢查 daemon 的代理環境與 Docker Desktop 設定。若只有 npm 某個套件失敗，則查看該套件是否引用其他 registry、Git 遠端或二進位檔下載位址，因為 npm registry 可用不代表所有依賴來源都可用。

開發流量通常具有可預測的分流邏輯。GitHub 的程式碼與發布資源可依網域規則處理；Docker Hub 相關網域、映像檔 layer 與認證端點可能不只一個；npm 則可能從 registry 取得 metadata，再前往其他位址下載套件或預編譯檔。因此，不應只把單一首頁加入代理規則，而應根據實際錯誤訊息與請求目標逐項確認。

流量管理也要考慮月訂閱與流量包的使用方式。月訂閱包含 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按開通日每月重置；流量包則是 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完為止且永久不過期。Docker 映像檔 layer、npm 快取與大型 release 下載可能消耗較多流量，建議啟用 Docker layer 快取、保留 npm 快取，並避免在沒有必要時重複拉取相同版本。