npm 與 git 仍走直連？
macOS 與 Linux 終端機設定 Clash 代理與環境變數

一、為什麼 GUI 代理套不到終端機

在 macOS 與 Linux 上，瀏覽器跟隨「系統代理」或透過圖形客戶端注入的設定，往往只影響有權讀取系統代理 API 的應用程式。相對地，你在終端機裡執行的 npm、yarn、pnpm、git、多數版本的 curl，預設看的是目前 shell 行程的環境變數（以及各工具自己的設定檔），而不是選單裡那一欄「HTTP 代理」。

因此會出現非常典型的現象：Safari／Chrome 能開 GitHub、registry 網站，但同一臺機器上 git clone 或 npm install 卻逾時。這不代表 Clash 沒在運作，而是終端機流量根本沒被送到本機的 Clash 連接埠，仍在嘗試直連被封鎖的目標。先把「誰負責帶路」釐清，再談規則與節點，排障會快很多。

二、先對齊 Clash 本機 HTTP／SOCKS 埠

無論使用 Clash Verge、其他圖形客戶端，或自行跑 Mihomo 核心，都請在介面或設定裡確認三個數字：混合埠（mixed port）、獨立的 HTTP 埠、SOCKS 埠。教學與截圖常假設混合埠為 7890、SOCKS 為 7891，但你實際環境可能不同；以下範例請一律替換成自己的埠號。

建議檢查項

1. 客戶端是否顯示「系統代理已開啟」：那通常只幫瀏覽器類應用，不等於已幫終端機 export 變數。
2. 混合埠是否僅監聽 127.0.0.1：本機終端機使用沒問題；若從另一臺裝置或 VM 連回來，才需要「允許區域網路」類選項，與 Linux 上自行綁定介面的考量類似。
3. 若你同時開 TUN，仍建議記下 HTTP／SOCKS 埠，因為不少工具不會自動走 TUN，仍需顯式代理。macOS 上若系統代理異常，可先對照 《Clash Verge 在 macOS 上系統代理不生效》 權限與網路延伸段落。

接下來所有指令，都把 127.0.0.1:7890 當成「本機 Clash 的 HTTP 代理位址」的占位符；若你使用 SOCKS，請改成 socks5h://127.0.0.1:7891 這類形式（socks5h 表示連遠端網域的解析也交給代理端，較符合 Clash 場景）。

三、環境變數：http_proxy、HTTPS_PROXY、ALL_PROXY

多數 CLI 會讀小寫與大寫兩套約定：http_proxy／HTTP_PROXY、https_proxy／HTTPS_PROXY。實務上兩套都設最省事，避免某個程式只認其中一種。若你希望連非 HTTP 類連線也預設走代理，可再加 all_proxy／ALL_PROXY（常配 socks5h://127.0.0.1:7891）。

no_proxy／NO_PROXY 用來列出不要走代理的網域或 IP，例如公司內部 Git、私有 npm registry、localhost、127.0.0.1。漏設時，內網流量被硬送去 Clash，可能出現「內部服務突然連不上」的副作用。

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export all_proxy="socks5h://127.0.0.1:7891"
export ALL_PROXY="$all_proxy"
export no_proxy="localhost,127.0.0.1,::1"
export NO_PROXY="$no_proxy"

在當前 shell 執行上述區塊後，再跑你的 npm／git 指令，屬於暫時生效；關掉視窗就消失。要長期生效，請把同等內容寫進登入 shell 讀取的設定檔（見下兩節）。更進階的 DNS、規則與 Fake-IP 行為，請一併參考 設定與規則文件，避免代理已通但解析鏈與核心假設不一致。

四、macOS：zsh／bash 與設定檔載入順序

現行 macOS 預設登入 shell 多半是 zsh。互動式終端機開啟時，會讀取使用者家目錄下的 ~/.zshrc；若你仍使用 bash，則常見為 ~/.bash_profile（登入）與 ~/.bashrc（非登入互動）。圖形介面啟動的終端機 App與 SSH 進來的連線，是否為 login shell，決定了會不會載入某一份檔案；若你發現「手動 source 就正常、開新分頁又沒有」，幾乎都是寫錯檔案或載入順序問題。

建議把代理匯出集中寫在 ~/.zshrc 尾端，並用註解區塊標示，日後要關閉時整段註解即可。若你使用多種終端機（Terminal.app、iTerm2、IDE 內建終端機），可任開一個新視窗執行 echo $SHELL 與 grep -n proxy ~/.zshrc，確認實際載入內容。

五、Linux：登入與非登入 shell

在 Linux 桌面或伺服器上，bash 仍常見。一般規則是：登入 shell 讀 ~/.profile 或 ~/.bash_profile；互動非登入讀 ~/.bashrc。若你只把 export 寫在 ~/.bashrc，但某些排程或服務用非互動模式啟動，就不會帶到那些變數。

對於在圖形桌面開啟的終端機模擬器，各發行版預設不盡相同；最穩妥的做法是在 ~/.profile（或發行版建議的全域位置）放一份「最小必要」的代理匯出，並在 ~/.bashrc 用 source ~/.profile 繼承，避免重複維護。使用 fish、zsh 者請改寫對應語法與檔名。

若你在伺服器上只跑核心而沒有圖形客戶端，仍可在本機 127.0.0.1 對 Clash／Mihomo 的混合埠設代理；安裝與常駐流程可與 Ubuntu systemd 專文併讀，先把服務聽在穩定埠，再回來設環境變數。

六、Git：http.proxy 與 SSH 分流

Git 除了讀環境變數，也常見使用 git config 寫入的使用者層或全域層設定：http.proxy、https.proxy。若兩邊同時存在，行為可能讓人困惑；建議用 git config --global --get-regexp proxy 先看清目前值，再決定要保留環境變數還是 Git 專用設定。

對於 https:// 開頭的遠端網址，HTTP 代理通常可直接生效；若遠端是 [email protected]:... 這類 SSH 協定，則不會走 http_proxy，而要走 ~/.ssh/config 裡的 ProxyCommand（例如透過 nc 或 connect 接到本機 SOCKS）。許多使用者以為設了 http_proxy 就能加速 SSH，其實兩條管道是分開的。

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

若要還原，使用 git config --global --unset http.proxy 等指令即可。與 GitHub、Cursor 等場景相關的分流思路，也可參考 《Cursor 與 GitHub 分流與逾時》，與本文終端機代理設定互相補強。

七、npm／yarn／pnpm 與 .npmrc

npm 會讀環境變數，但也常被專案或使用者層的 .npmrc 覆蓋。proxy／https-proxy 鍵若指向舊的埠或錯誤的協定，會出現「明明 shell 已 export 仍不走 Clash」的現象。可用 npm config list 檢查來源層級（project、user、global）。

yarn（v1）有類似的 yarn config；yarn berry 與 pnpm 則建議優先依賴環境變數，或在各自設定檔中明確指定 registry 與代理。企業內網若使用私有 registry，請一併把該網域列入 no_proxy，避免套件下載繞一大圈又失敗。

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

設定完成後，用 npm ping 或實際 npm install 驗證；若仍失敗，請把錯誤訊息區分是 TCP／TLS 連線問題 還是 registry 回 4xx／5xx，兩者後續排查方向不同。

八、用 curl 做可重現驗證

在調整任何套件管理器之前，建議先用 curl 建立最小實驗：它對 http_proxy／HTTPS_PROXY 的行為相對直觀，且 -v 可看到實際連到的代理與 TLS 握手階段。下列指令將占位 URL 換成你環境可訪問的 HTTPS 站點即可。

curl -vI --proxy http://127.0.0.1:7890 https://www.google.com

若未設代理時該指令失敗、設了之後回應標頭正常，代表終端機→Clash 埠→出口這條鏈路已通，後續只剩各工具是否讀到同一組環境變數或設定檔。若連代理埠都連不上，請回到第二節確認 Clash 是否監聽、埠號是否一致，而不是急著改規則。

九、TUN 或系統代理開著，還要 export 嗎？

TUN 模式的目標是在系統路由層把符合條件的 IP 流量導入 Clash；理論上「支援走系統路由」的程式會跟著受益。但現實中仍有大量工具或執行環境不經過你以為的那張路由表，或仍按自己的 DNS 策略直連。因此實務上常見做法是：TUN 與本機 HTTP／SOCKS 代理兩手準備——瀏覽器與多數 App 靠系統／TUN，終端機與開發工具靠環境變數與 Git／npm 設定對齊同一個本機埠。

這樣做並非重複開兩次代理，而是讓不同類型的行程各走其能理解的路徑。等你確認所有常用 CLI 都已穩定，再考慮精簡設定也不遲。

十、現象與檢查項速查表

先把問題收成「到不了本機 Clash 埠」與「到了埠但工具沒跟」兩類，通常能在幾步內定位，而不必同時改訂閱、規則與系統設定。

十一、小結

macOS 與 Linux 上「瀏覽器能上、終端機不行」，多半不是 Clash 沒開，而是命令列行程沒有讀到與本機 Clash 埠對齊的代理設定。依序確認混合埠／SOCKS 埠、在 shell 裡匯出 http_proxy、HTTPS_PROXY、ALL_PROXY 與 no_proxy，再為 Git、npm 等工具補上獨立設定，通常就能讓 git clone、npm install 與 curl 行為一致。

相比只在圖形介面勾選系統代理，把終端機環境變數寫清楚之後，日常開發與 CI 本機除錯都會穩定許多；成熟 Clash 用戶端在規則與核心上的彈性，也能在同一臺工作機上延續同一套出口策略，減少「換個工具就斷網」的斷裂感。

若你希望使用維護積極、預設選項清楚的 Clash 用戶端，並從本站取得對應平臺的安裝指引，可先前往下載頁選擇 macOS 或 Linux 版本，再依本文對齊本機埠與 shell 設定。

→ 立即免費下載 Clash，開啟流暢上網新體驗