系統代理是什麼？原理、設定方式與先天限制

在客戶端裡按下的那個「系統代理」開關，做的事其實比多數人想像的單純：它把「本機某個連接埠有一個代理」這件事寫進作業系統的設定，如此而已。之後哪些程式會照做、哪些不理，作業系統並不強制。

理解這個前提，很多怪現象立刻說得通——瀏覽器明明正常，某個遊戲或命令列工具卻完全不受影響；或者關掉客戶端後上不了網，因為系統設定裡的代理宣告還留著。這篇把系統代理的運作方式、涵蓋範圍與先天限制說清楚。

系統代理的本質：一份作業系統層的宣告

系統代理是作業系統提供的一組設定值，內容大致是「HTTP 與 HTTPS 流量請送到 127.0.0.1 的某個連接埠」。支援這套機制的應用程式在發起連線前會去讀它，然後把請求交給該位址上的代理程式——也就是你的客戶端與背後的 mihomo 核心，核心再依分流規則決定直連或轉發到節點。

關鍵字是「自願遵守」。作業系統只負責保存與提供這份設定，不會攔截任何封包；程式若不讀這份設定，就完全不受影響。這是系統代理與 TUN 模式最根本的差異。

客戶端如何自動幫你設定

你不需要手動填寫，客戶端會在開關打開時寫入系統設定，關閉時再還原。三個桌面系統的機制略有不同：

• Windows：寫入系統的網際網路設定，設定 → 網路和網際網路 → Proxy（Proxy 伺服器）能看到目前的值。
• macOS：寫入目前使用的網路服務設定，可在系統設定 → 網路 → 詳細資訊 → 代理伺服器中查看。
• Linux 桌面：桌面環境各有各的設定位置，涵蓋程度也不一致，部分應用程式只吃環境變數而不看桌面設定。

不同系統版本的路徑名稱略有出入，但邏輯一致。若客戶端非正常結束（例如當掉、被強制關閉），設定可能來不及還原，症狀就是關掉軟體後整台電腦都上不了網——這時到上述位置手動把代理關掉即可復原。

哪些流量會走系統代理，哪些不會

所以「開了代理還是連不上」的情況，經常不是節點壞了，而是那個程式根本沒在看系統代理。判斷方法很直接：換瀏覽器開同一個服務，若瀏覽器正常，問題就在該程式的涵蓋範圍。

命令列工具用環境變數解決

終端機裡的工具通常認的是環境變數。macOS 與 Linux 在目前的終端機工作階段中設定（把 7890 換成你的實際連接埠）：

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
curl -I https://www.example.com

Windows 的 PowerShell 則是：

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

這種設定只對目前這個終端機視窗有效，關掉就沒了，適合臨時使用；想長期生效可以寫進 shell 的設定檔或系統環境變數。要注意有些工具不吃這一套，得在它自己的設定裡指定代理。

PAC 模式是什麼

PAC（Proxy Auto-Config）是另一種宣告方式：系統設定裡填的不是固定的代理位址，而是一個描述規則的腳本，由它逐一判斷某個網址該直連還是走代理。好處是分流決策發生在應用程式端，某些場景更靈活。

不過在 mihomo 這類客戶端上，分流本來就由核心的規則系統完成，功能更完整，多數人不需要再套一層 PAC。除非你有特殊需求（例如要讓某些程式完全繞過代理），否則用一般的固定位址模式即可。

什麼時候該改用 TUN

系統代理夠輕量、不需要額外權限，日常瀏覽網頁、看資料完全夠用，也是出問題時最好排查的模式。但它的天花板很明確：涵蓋不了不讀設定的程式。當你遇到某個工具、遊戲或背景服務怎麼調都不走代理，就是該考慮 TUN 的時候——它在網路層直接接管全部流量，不需要應用程式配合，做法見 TUN 模式詳解。

兩種模式並非二選一，很多人的用法是平常開系統代理，需要時再切 TUN。完整的取捨比較見TUN 模式與系統代理怎麼選；如果目前是兩種都開了卻反而連不上，先關掉其中一個再照分步排查指南逐層確認。