開發者用 v2rayN 打通命令列代理：Git、npm、Docker 工作流實戰指南

先選擇 TUN 或工具個別代理

v2rayN 管理節點並啟動代理核心；Git、npm、pip 和 Docker 則是各自發起連線的應用程式。Windows 的「系統代理」通常只會影響會讀取系統代理設定的程式，並不保證命令列工具或背景服務也會跟著使用。因此，先確認是哪個程式正在連線，比反覆更換節點更有效。

初次設定建議先使用工具個別代理，不要同時修改 Git 設定、設定全域環境變數又開啟 TUN。一次只增加一種代理路徑，才能知道測試結果是由哪項設定造成。確認工具本身可用後，再依需求評估 TUN。

• HTTP 代理：常見情況下，可讓 HTTP CONNECT 隧道承載 HTTPS 連線。本文以 127.0.0.1:10809 作為範例。
• SOCKS 代理：部分工具支援 SOCKS5；使用 socks5h:// 時，網域名稱交由代理端解析，避免本機先解析目標名稱。本文以 127.0.0.1:10808 作為範例。
• 實際入口：請在 v2rayN「設定」→「參數設定」檢查本機監聽連接埠和協定。若版本介面名稱不同，以本機設定頁顯示的 HTTP、SOCKS 或混合入口為準。

準備 v2rayN 與本機代理入口

先確認核心已啟動，並有一個目前可用的作用中節點。用瀏覽器測試成功，只能證明瀏覽器當下的連線路徑可用，不能直接證明命令列工具已使用相同代理。以下步驟先確認本機入口，再測試每個工具。

1. 確認作用中節點

   在 v2rayN 主畫面選取已匯入的節點並設為作用中伺服器，查看核心記錄是否有啟動錯誤。若節點本身無法建立連線，先處理節點與核心問題，暫時不要改 Git 或 npm 設定。

2. 檢查本機連接埠

   開啟「設定」→「參數設定」，核對 SOCKS、HTTP 或混合入口的監聽位址和連接埠。本文命令以 SOCKS5 10808、HTTP 10809 示範；若設定只提供混合入口，請依該入口支援的協定格式使用。

3. 設定系統代理

   在 v2rayN 主畫面底部的「系統代理」選擇「自動設定系統代理」，再確認 Windows「設定」→「網路和網際網路」→「Proxy」中的本機位址與連接埠。此步驟可供讀取系統代理的應用程式使用，但不取代下文的工具個別設定。

4. 測試 HTTP 入口

   在 PowerShell 執行 curl.exe -x http://127.0.0.1:10809 -I https://registry.npmjs.org/。收到 HTTP 回應標頭表示這次 HTTP 代理請求取得了回應；若連線拒絕，先核對本機連接埠與核心監聽狀態。

5. 逐項測試工具

   依序設定 Git、npm、pip，再測 Docker。每完成一項便執行該工具自己的查詢或下載測試，並記錄使用的代理位址，避免同時調整多個工具而失去對照。

如果測試命令的結果與瀏覽器不同，先不要推斷節點速度不足。命令列可能沒有使用 Windows 系統代理、代理位址或連接埠填錯，也可能是工具使用了不同的 DNS 或憑證設定。先確認本機 HTTP 入口測試成功，再逐一檢查應用程式。

設定並驗證 Git、npm 與 pip

設定代理時要分清環境變數與工具自己的設定。環境變數可能被多個子程序繼承，適合短時間測試；工具設定較明確，但可能留在使用者設定檔中。選擇一種主要方式即可，避免留下彼此矛盾的代理值。

Git：設定 HTTP(S) 代理

Git 使用 libcurl 處理常見的 HTTP(S) 遠端連線，可先對一個測試儲存庫執行 git ls-remote。以下使用 HTTP 代理，將範例網域替換為自己有權存取的儲存庫網址：

git config --global http.proxy http://127.0.0.1:10809
git ls-remote https://github.com/OWNER/REPOSITORY.git
git config --global --get http.proxy

最後一行只用來確認 Git 讀到的代理值，不代表遠端連線成功。若只希望特定網域走代理，可改用 Git 的網域限定設定，避免將所有 HTTP(S) 儲存庫都導向同一入口。排查完成後，可用 git config --global --unset http.proxy 移除全域設定；若之前使用不同範圍設定，也要在對應範圍檢查。

npm：使用 HTTP 代理設定

npm 常用的 proxy 與 https-proxy 設定值是代理伺服器網址，不是套件 registry 的網址。HTTPS 套件請求通常透過 HTTP 代理建立 CONNECT 隧道，因此可先用本機 HTTP 入口測試：

npm config set proxy http://127.0.0.1:10809
npm config set https-proxy http://127.0.0.1:10809
npm ping
npm view npm version

npm ping 與 npm view 可以分別檢查 registry 回應和套件中繼資料查詢。若使用組織指定的 registry，先執行 npm config get registry 查看目前目標，不要為了連線問題任意切換到未核實的第三方來源。完成臨時測試後，可用 npm config delete proxy 和 npm config delete https-proxy 清除相應設定。

pip：用命令列參數或環境變數測試

pip 可透過 --proxy 指定代理，適合先做單次驗證而不修改永久設定。以下只顯示安裝來源連線的測試形式；請選擇實際存在且可信任的套件名稱，避免將此命令誤當成必須安裝特定套件：

python -m pip index versions PACKAGE_NAME --proxy http://127.0.0.1:10809

若目前 pip 版本或索引服務不支援該查詢，可改用正常的套件安裝或下載測試，並以 pip 顯示的連線錯誤作判斷。也可以在 PowerShell 目前工作階段設定 $env:HTTP_PROXY 與 $env:HTTPS_PROXY，再執行 pip；關閉該終端機後，工作階段變數通常不會繼續生效。代理設定不會解決套件版本衝突或憑證信任問題。

• 看到 407 Proxy Authentication Required，表示代理要求驗證；檢查本機入口類型與認證設定，不要把帳密直接貼到公開記錄。
• 看到名稱解析錯誤，先比較使用代理與不使用代理時的結果，並確認代理網址拼寫及目標 registry 網域。
• 如果只有某個儲存庫或索引失敗，檢查該服務的存取權限、網址與憑證，不要因此立即清除所有工具設定。

Docker Desktop 與映像檔拉取

Docker 的連線路徑比一般命令列工具多一層。執行 docker pull 時，請求通常由 Docker Desktop 管理的 Docker Engine 或相關背景服務負責；僅在 PowerShell 設定 HTTP_PROXY，不一定能讓映像檔拉取使用該代理。Docker CLI 的環境變數、建置程序的代理參數、Engine 的代理設定也不是同一個設定位置。

在 Docker Desktop 中，代理選項的名稱和位置可能隨版本及部署方式不同而變動，請以目前介面中的代理設定說明為準。若使用本機代理，檢查 Docker Desktop 執行環境是否能連到該位址；某些隔離環境對 127.0.0.1 的解讀與一般 Windows 程式不同，不能預設一定可用。設定後可執行：

docker info
docker pull hello-world

docker info 可協助確認 Engine 是否正常回應，但不保證映像檔來源可達；docker pull 才會實際測試映像檔下載。若拉取成功而建置失敗，檢查 Dockerfile 中的套件下載步驟和建置代理參數；若容器執行後無法連線，則要檢查容器網路與容器內程式的代理設定。這三種情況的流量來源不同，不應只改一處設定就預期全部生效。

終端仍無法連線時的排查順序

依照「核心是否運作 → 本機入口是否監聽 → 工具是否使用代理 → 目標服務是否回應」逐層排查。每次只改一項設定，並保留錯誤原文、執行命令及時間點，方便與 v2rayN 核心記錄對照。測試前也要確認作用中節點沒有切換，否則不同次結果不易比較。

結束測試後，清除不再需要的全域代理設定，或還原原先的環境變數；尤其在共用電腦上，不要讓含有代理驗證資訊的命令列歷程或設定檔長期保留。若問題涉及訂閱或節點資料，分享記錄前也應遮蔽伺服器位址、使用者識別資訊及存取權杖。