為什麼「Clash 明明開著」，終端卻像沒代理？

在 Windows 上，許多圖形化 Clash 用戶端會提供「一鍵設定系統代理」：把 Internet Explorer／WinHTTP 層級的 Proxy 指到本機某個埠。這對會讀取系統 Proxy 設定的應用程式（常見如 Edge、部分商店 App）很友善，但命令列工具不一定會沿用同一套設定。典型症狀是：瀏覽器分頁能開 GitHub、npm 官網，換到 PowerShell 執行 git clone 或 npm install 卻卡住、逾時，或錯誤訊息顯示仍在嘗試直連公司網路無法存取的位址。

另一個常見誤解，是把「開了 TUN」當成終端一定會走代理。TUN 會在較底層改寫路由，讓多數程式被迫把流量交給核心；但本文鎖定的情境是維持目前使用者工作階段、不額外啟用 TUN，而是用最單純、可預測的本機 HTTP／SOCKS 入站埠＋環境變數，讓 Git、npm、curl 這類明確支援代理環境變數的工具自己連到 Clash。這樣做的好處是權限與路由面較單純，也比較容易和本站其他 Windows 主題（例如區網分享代理、TUN 故障排除）分工閱讀：若你需要整機或 UDP 更一致的路徑，可再參考TUN 與路由排查；若要把手機接到電腦上的 Clash，則對照區網代理與防火牆中的混合埠說明。

系統代理 vs 終端環境變數：兩條路不要搞混

簡單講：系統代理是 Windows「設定」裡那組對 WinINet／部分 Runtime 生效的 Proxy；終端環境變數則是傳給目前 Shell 行程及其子行程的一組鍵值，常見如 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY。許多跨平台 CLI（含 Git、npm、curl）在設計上優先讀環境變數，而不是去問「系統 Proxy 現在指到哪」。因此你在用戶端勾了「系統代理」≠ PowerShell 裡自動多出這些變數。

實務建議採分層心智模型：瀏覽器與少數桌面程式走系統代理；開發者工具鏈走「本機 Clash 入站＋環境變數或 Git／npm 專用設定」。兩者可以並存，但要清楚誰負責誰，避免出現「系統代理指到舊埠、環境變數又指到新埠」的雙重混亂。若你剛從其他用戶端遷移，請先在圖形介面確認目前實際監聽埠，再對照YAML 設定教學裡 mixed-port、port、socks-port 的意義，確定你寫進變數的數字真的是「現在這份設定檔正在聽的那個」。

混合埠（mixed-port）要填什麼？跟獨立 SOCKS 埠差在哪？

現行 mihomo／Clash Meta 生態常見做法，是使用混合埠讓單一 TCP 埠同時接受 HTTP 與 SOCKS 風格的連線協商。對多數開發者情境，你只要記一組數字（例如介面上顯示的 7890），就能把 http://127.0.0.1:7890 當成 HTTP_PROXY／HTTPS_PROXY 的值；許多工具會自動用 HTTP CONNECT 方式穿透 HTTPS 站台。

若你的設定檔仍分開指定 port（純 HTTP 入站）與 socks-port，請依工具類型選對：只支援 SOCKS 的程式要指向 SOCKS 埠；純 HTTP 代理則對應 HTTP 埠。把兩者抄反了，症狀會是「連得上 proxy 手續、後面卻全失敗」或「用戶端顯示有在聽，但 Git 一直回 connection refused」。混合埠的存在，就是為了降低這種抄錯機率：同一個數字，讓常見 CLI 先以 HTTP 代理方式接入即可。若你使用圖形殼層，建議先閱讀Clash Verge Rev 安裝與模式說明確認「埠號顯示」與實際載入的設定檔一致，再回來設環境變數。

在 PowerShell 為「目前使用者」設定工作階段變數

若你只想在當前視窗測試，可直接在 PowerShell 輸入（請把埠號改成你的混合埠）：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"

接著用 curl -I https://www.google.com 或實際的 git ls-remote 測試。這種寫法只影響這個 PowerShell 視窗及其子行程，關閉視窗即失效，最適合先驗證埠號與規則是否正確。

若你希望「每次開 PowerShell 都自動帶上」，請改寫入使用者層級的 PowerShell Profile，或透過系統「環境變數」編輯器新增使用者變數（不是全系統 Machine），同樣填上 HTTP_PROXY 等名稱。這樣做仍屬於「目前登入的 Windows 使用者」，不會強迫其他帳號跟著走代理，符合多數開發機的需求。請注意：setx 指令會永久寫入登錄檔，但不會讓已開著的終端立刻生效，需要開新視窗；若設錯變數，也可能讓內網工具誤走代理，此時應搭配 NO_PROXY 列出本機與內網網段。

Git：全域 http.proxy 與環境變數二選一即可，別重複打架

Git 同時認 http.proxy／https.proxy 與環境變數。實務上建議選一條路貫徹：要嘛只用環境變數，要嘛只用 git config --global。兩邊都設但指向不同埠時，除錯會非常痛苦。若你走設定檔路線，範例如下（埠號請自行替換）：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

請特別留意：透過 SSH（[email protected]:...）的連線不會吃 HTTP 代理，除非你再額外設定 core.sshCommand 走 nc／connect-proxy 等橋接。若你發現「HTTPS clone 正常、SSH clone 仍失敗」，這不是 Clash 沒開，而是協定本來就不同路。公司內網若阻擋 22 埠，也可改回 HTTPS 遠端網址，或改用官方支援的 SSH over 443 方案，與代理是分開的議題。

另一個 Git 常見坑是只設了 http.proxy 卻忘了 https.proxy，在現今幾乎全面 TLS 的遠端上會表現為「部分指令偶發成功、多數仍逾時」。建議兩者設成同一個本機混合埠位址即可。若需排除特定網域不走代理，可使用 http.<url>.proxy 區段或改以 NO_PROXY 控制，細節請以團隊規範為準。

npm／pnpm／Yarn：registry 走 HTTPS，代理變數要對齊

npm 預設會讀 HTTP_PROXY／HTTPS_PROXY，也可用 npm config set proxy 與 npm config set https-proxy 寫進使用者設定檔。對大多數從 registry.npmjs.org 拉套件的情境，HTTPS_PROXY 才是關鍵；只設 HTTP 而沒設 HTTPS，會出現「瀏覽器能開 npm 網站、CLI 卻裝不起來」的落差。

若你使用公司內部 Verdaccio／JFrog，請把該主機名加入 NO_PROXY，避免內部套件庫被硬繞去境外節點。pnpm、Yarn 家族同樣繼承 Node 生態對代理變數的慣例，診斷時可先用最小指令 npm ping 或 npm view lodash version 驗證連線，再回頭查是否混用了舊的 .npmrc 裡另一組 proxy。更多名詞與流程可搭配站內文件總覽一起閱讀，先把「流量是誰發起、誰該讀代理」對齊。

常見坑整理：大小寫、只設 ALL_PROXY、與防毒掃描

下表整理高頻錯誤與建議處理方向。實際欄位名稱可能因工具版本略有差異，以官方文件為準。

此外，少數企業防毒會對本機 Loopback 上的 CONNECT 流量插入掃描，表現為「代理已連上但 TLS 握手極慢」。可先用最小化測試（暫時關閉 HTTPS 掃描或將 Clash 加入信任清單）對照；若確認與安全軟體無關，再回到規則與節點品質檢查。

刻意不開 TUN：什麼時候「只開發者代理」就夠了？

若你的目標僅是讓版本控制與套件管理器穩定出網，而不需要整台電腦所有 UDP／非代理感知程式都進 Clash，那麼維持 Rule 模式＋本機混合埠＋環境變數通常就夠用，也較少與公司 VPN 搶路由。這與「為了 Discord 語音或遊戲 UDP」那類必須談 TUN／堆疊的情境不同；本站亦已有Discord 與 UDP 分流等文章專注在傳輸型態，本篇則專注在 CLI 與文字介面。

當你照上述步驟設定後，建議保留一份「可複製的最小環境片段」（幾行 PowerShell 或 .npmrc 註解），換專案或重灌時能快速還原。相比依賴零散論壇片段，使用持續更新的用戶端與核心，並從本站教學建立完整脈絡，長期維護成本通常更低。

結語

Windows 上「Clash 有開、終端卻像直連」大多不是魔法問題，而是系統代理沒有自動變成 Git／npm 看得懂的變數。把混合埠對準、為目前使用者設定 HTTP_PROXY／HTTPS_PROXY，再依需要補上 Git 與 npm 的專用設定，就能在不大開 TUN、不改整機路由的前提下，讓開發工具鏈穩定走代理。相比其他同類工具，Clash 在規則可視化與核心一致性上的體驗通常更省心；若你希望先取得與本機環境相符的安裝包，再依教學逐步設定，建議從用戶端下載頁取得最新版本並搭配文內連結操作。→ 立即免費下載 Clash，開啟流暢上網新體驗