先分清流量入口與出站模式

系統代理與 TUN 模式處理的是「流量如何進入用戶端」；規則、全域與直連處理的則是「流量進入用戶端後如何轉送」。這是兩個不同層次的設定。啟用 TUN 不代表所有連線都會經過遠端節點；選擇全域模式，也不代表所有應用程式都會自動把流量送進用戶端。

可以依照以下順序理解一條連線。代理群組的選擇，以及訂閱中的節點是否可用，都發生在流量進入後。如果連線根本沒有進入核心，反覆切換節點通常也不會改變結果。

應用程式發起連線
  → 系統代理連接埠，或 TUN 虛擬網卡
  → Clash / mihomo 核心
  → 出站模式與規則判斷
  → DIRECT、代理節點或 REJECT

系統代理：應用程式主動連線至本機連接埠

系統代理本質上是一組供應用程式讀取的網路設定。例如，用戶端在本機監聽混合連接埠 127.0.0.1:7890，再將這個位址設為系統代理。支援此設定的應用程式會先連線至本機連接埠，再由核心繼續連線至目標。這裡的 7890 僅為範例，實際連接埠請以用戶端設定為準。

HTTP、HTTPS 與 SOCKS 的連線方式

  • HTTP 代理：應用程式將 HTTP 請求交由代理伺服器處理。
  • 透過 HTTP 代理連線 HTTPS：通常會先傳送 CONNECT 請求建立通道，再於通道內完成 TLS 交握；這不代表用戶端會解密 HTTPS 內容。
  • SOCKS5：應用程式透過 SOCKS 協商目標位址。是否將網域名稱交由代理解析，取決於應用程式與連線方式。
  • 混合連接埠：同一個監聽連接埠可接受 HTTP 與 SOCKS 代理連線，但不代表系統會強制所有程式使用它。

在 macOS 哪裡查看

在 macOS 13 或更新版本中，前往「系統設定」→「網路」→目前使用的網路服務，例如「Wi-Fi」→「詳細資訊」→「代理」，查看網頁代理、安全網頁代理及 SOCKS 代理的伺服器與連接埠。不同系統版本的選單名稱可能略有差異。切換 Wi-Fi、乙太網路或其他網路服務後，也要檢查目前使用的服務，而非只查看上次使用的服務。

瀏覽器、終端機與桌面應用程式不一定使用同一套代理設定。有些應用程式會讀取系統設定，有些則使用自己的代理選項；命令列工具也可能讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY 環境變數。因此，「瀏覽器可以連線，終端機卻不行」首先代表連線入口可能不同，還不足以證明節點故障。

TUN 模式：透過虛擬網卡與路由接收 IP 流量

TUN 提供虛擬的第三層網路介面。應用程式仍以一般方式建立連線，作業系統會依據路由，將符合條件的 IP 封包送入虛擬網卡，再由核心處理這些資料。應用程式不必主動支援 HTTP 或 SOCKS 代理，因此 TUN 常用於不讀取系統代理設定的程式。

在 macOS 上，虛擬介面通常會以 utun 系列裝置的形式出現。不過，系統 VPN 和其他網路服務也會建立同類介面，因此不能只憑出現 utun 就判定用戶端已成功接管流量。還需要搭配用戶端記錄、路由與連線記錄確認。

啟用條件與能力限制

  • 權限：建立介面、設定路由等操作通常需要管理員授權或用戶端的服務元件。授權成功不代表後續路由設定一定正確。
  • 核心：是否提供 TUN、支援哪些網路堆疊與欄位，應以實際使用的核心為準。用戶端介面名稱是 Clash，不代表一定使用 mihomo。
  • UDP：TUN 可將符合條件的 UDP 流量送入核心，但遠端節點與通訊協定也必須支援 UDP 轉送。開啟功能無法補足節點本身不具備的能力。
  • 涵蓋範圍：IPv6、區域網路、排除路由與其他 VPN 都可能影響接管範圍。TUN 也無法完整接管所有第二層廣播流量。

mihomo 的 auto-route 用於自動設定相關路由，auto-detect-interface 用於自動辨識出站介面。這些功能有助於設定常見網路環境，但無法保證與公司 VPN、虛擬機網路或多網卡策略完全相容。

系統代理與 TUN 的實際差異

比較項目系統代理TUN 模式
流量進入方式應用程式主動連線至本機代理連接埠路由將 IP 封包送入虛擬網卡
應用程式相容需求應用程式需讀取系統設定或手動設定代理通常不需要應用程式提供代理選項
UDP 使用條件取決於應用程式與代理通訊協定，不能一概以一般 HTTP 代理涵蓋取決於路由、核心與節點的 UDP 能力
權限與影響範圍主要修改網路服務的代理設定涉及虛擬介面、路由，以及可能的 DNS 接管
常見排查入口連接埠監聽、應用程式代理設定、略過清單授權狀態、路由、DNS、IPv6 與 VPN 衝突

兩者沒有固定的速度排名。同一個請求若最終使用相同節點，使用體驗通常更受節點負載、連線品質與目標服務影響。TUN 多了一層流量處理，但不能因此推斷它一定比較慢；系統代理的路徑較直接，也不保證應用程式一定會依預期使用。

DNS：解析位置決定網域規則能取得哪些資訊

使用系統代理時，應用程式可能會將網域名稱交給代理，也可能先在本機解析。以 curl 為例，socks5:// 通常會在本機解析目標網域，socks5h:// 則會將目標網域交給 SOCKS 代理解析。即使使用相同連接埠，解析路徑也可能不同。

TUN 接收到的主要是 IP 封包。如果應用程式已將網域名稱解析成實際 IP，核心不一定能直接得知原始網域。DNS 接管、Fake-IP 對應與流量嗅探都可提供網域規則所需資訊，但三者的作用並不相同。

  • DNS 接管：將符合條件的 DNS 請求交由核心 DNS 模組處理。常見的 53 埠接管無法直接解密應用程式內建的 DoH 或 DoT。
  • Fake-IP：由核心回傳對應位址，並保留網域名稱與位址之間的對應關係。常見的位址範圍為 198.18.0.0/16；這類位址不是遠端節點位址。
  • 嗅探：嘗試從可見的通訊協定特徵還原目標網域，例如部分 TLS ClientHello 中的 SNI。這並非 HTTPS 解密，遇到加密的用戶端問候等情況時也有其限制。

mihomo 設定片段的檢查方式

以下僅展示相關欄位，並非完整設定。使用前請確認用戶端確實執行支援這些欄位的 mihomo，並保留原設定中的 DNS 上游、代理節點與規則。如果用戶端會透過圖形介面產生設定，建議優先使用介面中的設定選項，以免手動修改在更新訂閱時被覆蓋。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

依序排查各個入口，不要同時變更多個開關

步驟一：單獨測試本機代理連接埠

先關閉 TUN，讓核心維持執行，再使用明確指定代理的命令進行測試。以下假設混合連接埠為 7890；若用戶端顯示其他數值，請一併修改。命令設定了 15 秒逾時，並輸出連線階段資訊，方便區分連接埠遭拒、TLS 錯誤與目標逾時。

curl -I -v --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://example.com/

curl -I -v --max-time 15 \
  --proxy socks5h://127.0.0.1:7890 \
  https://example.com/

如果連線至 127.0.0.1:7890 遭拒，請先確認核心是否正在執行、連接埠是否一致，以及是否被其他程式占用。如果代理交握成功後目標連線仍逾時，再檢查節點與出站規則。單一測試位址連線成功，只能證明這條請求路徑可用，不能代表所有網站都正常。

步驟二：確認應用程式是否使用系統代理

啟用系統代理後，在 macOS 終端機執行 scutil --proxy，查看目前的代理字典，再檢查特定應用程式的獨立設定與略過清單。終端機可執行 env | grep -i proxy，查看目前設定的代理變數。系統代理設定正確，與應用程式實際採用該設定，是兩件需要分別確認的事。

步驟三：單獨測試 TUN

關閉系統代理後啟用 TUN，再重新建立目標應用程式的連線。可以使用下方命令排除 curl 明確指定代理的影響，再到用戶端的連線頁面查看記錄。此命令只會讓 curl 不使用代理，不會繞過 TUN 路由。

curl -I -v --max-time 15 --noproxy '*' https://example.com/

若沒有相應的連線記錄，請優先檢查 TUN 啟動記錄、排除路由、IPv6 路徑與其他 VPN；若已有記錄，則檢查命中的規則與最終出站。變更設定前已建立的長連線可能仍沿用舊路徑，必要時請關閉目標應用程式後重新開啟。

情境選擇：先用系統代理，有需要再啟用 TUN

  • 主要使用瀏覽器：系統代理通常較容易確認影響範圍。先確認瀏覽器確實遵循系統設定。
  • 終端機開發工具：可優先明確設定代理參數或環境變數；若要統一處理多個不支援代理的程式，再考慮使用 TUN。
  • 遊戲或其他 UDP 應用程式：先確認節點支援 UDP，再檢查 TUN 路由與應用程式連線記錄。只啟用系統 HTTP 代理，通常無法涵蓋這類流量。
  • 公司 VPN 與內網連線：逐一確認內部網域、私有網段與 DNS。必要時調整排除路由與直連規則，不要直接覆寫公司要求的網路設定。

系統代理與 TUN 可以同時啟用，但排查問題時建議先分別測試。應用程式明確連線至本機代理連接埠時，仍可能使用明確指定的代理入口；其他連線則由 TUN 接收。不要把兩個開關理解成必然經過兩次遠端代理，也不要假設核心在所有設定下都會自動處理所有路由衝突。

關閉功能後仍無法連線時的復原方式

  1. 先在用戶端關閉 TUN 與系統代理，再正常結束用戶端，讓它有機會撤除自行設定的路由與代理。
  2. 檢查目前網路服務的代理頁面，清除指向已停止監聽之本機連接埠的設定；若設定由組織管理，請聯絡管理員處理。
  3. 檢查終端機代理環境變數、應用程式獨立代理設定與其他 VPN 是否仍在生效，然後重新建立網路連線。
  4. 如果區域網路或網域解析仍異常，請記錄路由與 DNS 狀態，再依照特定用戶端的復原步驟處理，不要貿然刪除所有網路服務。

最終判斷依據是可確認的連線路徑：應用程式是否進入核心、網域如何解析，以及規則命中了哪個出站。分開檢查這三項，通常比反覆切換系統代理與 TUN 開關更容易找出問題。