先釐清：流量入口與代理規則

瀏覽器能上網，終端機卻連線逾時，通常應先確認流量有沒有進入用戶端，而不是急著更換節點。系統代理和 TUN 是兩種流量入口；規則模式與全域模式則決定流量進入核心後要走哪個出口。兩組設定處理的是不同問題。

系統代理會將本機代理位址登錄到 macOS 網路設定。只有願意讀取並採用這些設定的應用程式，才會將請求交給代理。TUN 則會建立虛擬網路介面，搭配路由將符合接管範圍的 IP 封包送進核心。mihomo 是相容於 Clash 設定檔生態系的代理核心；用戶端則負責提供操作介面、設定管理與權限服務。

比較項目系統代理TUN 模式
流量接管入口應用程式讀取代理設定後，主動連線至本機連接埠透過虛擬網卡與路由將 IP 封包送進核心
常見適用對象遵循系統設定的瀏覽器與桌面應用程式不讀取系統代理設定的程式，以及部分 UDP 應用程式
終端機指令通常需要指定代理參數或環境變數路由涵蓋時通常不必逐項設定
權限需求通常不需要安裝 TUN 輔助服務通常需要授權輔助服務來設定介面與路由
DNS 處理視應用程式與代理協定而定可搭配 DNS 劫持與核心 DNS，但仍有涵蓋範圍限制

系統代理：檢查設定與本機連接埠

在 macOS 確認代理設定是否已套用

以 macOS 13 及後續版本的系統設定介面為例，依序開啟「系統設定」→「網路」→「Wi-Fi」→「詳細資訊」→「代理伺服器」。使用有線網路時，請查看目前使用中的乙太網路服務。開啟用戶端的系統代理後，確認網頁代理、安全網頁代理或 SOCKS 代理的位址與連接埠；實際套用哪些項目視用戶端而定。

位址通常是 127.0.0.1，代表這台 Mac 本機；連接埠則必須與用戶端目前監聽的連接埠相同。本文以 7890 示範 HTTP 與 SOCKS 共用的混合連接埠，並非每個用戶端的預設值。請先在用戶端的連接埠設定中確認，再執行指令。

# 查看 macOS 目前彙整的代理設定
scutil --proxy

# 檢查範例連接埠是否有 TCP 監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN
  • 在 scutil --proxy 中查看 HTTPEnable、HTTPSEnable 或 SOCKSEnable，並確認對應的連接埠。
  • 如果 lsof 沒有輸出，請先檢查連接埠是否輸入錯誤、核心是否已啟動，以及連接埠是否已改成其他數值。
  • 如果監聽程序不是目前使用的用戶端，請先排查連接埠衝突，避免同時執行兩個用戶端並爭用相同位址。

開啟系統代理不代表所有應用程式會立即切換。應用程式可能使用自己的網路堆疊、既有長連線或獨立代理設定。變更後請建立新連線，必要時重新啟動目標應用程式，再查看用戶端的連線紀錄；不要只憑選單列的開關判斷是否成功。

終端機指令：明確指定代理來驗證入口

命令列工具是否會讀取 macOS 系統代理，取決於工具本身的實作。常見的 curl 用法會讀取代理環境變數，但不能因此推論它會自動採用系統代理設定。先明確指定代理參數進行測試，便能區分「代理入口問題」與「網站連線問題」。

先指定 HTTP 代理，再測試 SOCKS

# 透過本機 HTTP 代理發出 HTTPS 請求，最長等待 15 秒
curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 15 -I https://example.com

# 使用 SOCKS5，並交由代理解析目標網域名稱
curl --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 15 -I https://example.com

只有在該連接埠支援 SOCKS 時，第二個指令才適用。socks5h 中的 h 表示透過代理解析目標主機名稱；使用 socks5 時，curl 通常會先在本機解析。兩種寫法的差異會直接影響 DNS 排查結果。

需要持續使用時，設定暫時性變數

# 只影響目前的終端機工作階段及其後續啟動的子程序
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 測試完成後清除，避免之後誤用
unset http_proxy https_proxy

https_proxy 的值使用 http:// 並不矛盾：這表示本機代理入口使用的協定；HTTPS 目標通常會透過 HTTP CONNECT 通道連線。應用程式與目標網站之間的 TLS 加密不會因此自動取消。

TUN 模式：權限、路由與規則分流

TUN 是第三層虛擬網路介面，負責處理 IP 封包。在 macOS 上，用戶端通常會透過特權輔助服務建立或管理介面並設定路由。啟用前，請先選取有效設定檔並確認核心能正常啟動，再依用戶端提示安裝輔助服務並完成系統授權。請勿在訂閱頁面或設定檔中輸入系統登入密碼。

認識最小設定中的重要欄位

以下是 mihomo 設定片段，用於說明常見欄位，並非完整訂閱內容。不同用戶端可能會從介面產生這些欄位，也可能覆寫訂閱中的值。修改前請先備份設定，並檢查最後生效的設定；不要直接覆蓋整份訂閱。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  • enable 用來啟用 TUN；仍須具備足夠的系統權限，且核心必須成功啟動。
  • stack 用來選擇協定堆疊實作。範例使用 mixed，不代表它在每台 Mac 或各種網路環境中都比其他選項更合適。
  • auto-route 會要求自動設定路由；auto-detect-interface 則用來自動偵測輸出介面。切換 Wi-Fi、有線網路或熱點後，請重新確認出口。
  • dns-hijack 用來指定要劫持的目標；any:53 針對進入相應處理路徑的傳統 53 連接埠 DNS 請求，並非攔截所有加密 DNS。

只有這段設定還不夠，還需要節點、策略群組、規則及合適的上游 DNS 等內容。請優先使用用戶端支援的設定方式；如果核心回報欄位錯誤，先確認實際使用的核心類型與版本，再依照對應文件調整。

分清 TUN 開關與全域模式

啟用 TUN 後，流量會進入 mihomo，仍可在規則模式下依網域名稱、IP 或其他條件比對規則。符合直連規則就直接連線；符合代理群組則使用群組中選定的出口。全域模式通常會將流量交由全域策略群組處理，但仍會受到入口涵蓋範圍與路由排除影響。若要擴大接管範圍，請啟用 TUN；若要變更出口選擇，則應檢查規則與策略群組。

DNS：網頁能開啟，不代表解析路徑相同

DNS 會將網域名稱轉換成 IP 位址。系統代理只會改變應用程式連線至代理的方式，並不會統一控制所有應用程式的網域解析。瀏覽器可能透過代理傳送網域名稱，也可能使用自己的安全 DNS；其他程式則可能先查詢系統 DNS，再連線至取得的 IP 位址。

TUN 可搭配核心 DNS 處理更多解析請求。啟用 fake-ip 後，核心會為網域名稱指派用於對應的虛擬位址，再於連線階段關聯實際目標。看到 198.18.0.0/15 範圍內的位址不一定代表故障，但仍須以實際設定的 fake-ip 位址範圍為準。

從三個層面檢查解析問題

  1. 檢查系統入口。執行 scutil --dns 查看目前的解析器。這會顯示系統設定，但無法證明每個應用程式都使用這些解析器。
  2. 檢查核心紀錄。開啟用戶端的連線與記錄頁面，使用同一個網域名稱重新發出請求，觀察是否出現 DNS 請求、規則命中情形與出口選擇。
  3. 檢查應用程式內建設定。查看瀏覽器的安全 DNS、應用程式內的代理與加密解析設定。DoH 使用 HTTPS 傳輸，DoT 通常使用 853 連接埠，不能只靠劫持 53 連接埠來涵蓋。

不要只執行一次 dig，就認定整個系統的 DNS 路徑都相同。macOS 的分域解析、VPN 解析器與應用程式快取都可能造成差異；dig 的查詢路徑也不完全等同於應用程式呼叫系統解析服務的方式。排查時請記錄目標網域、時間與使用的工具，避免混淆不同測試結果。

遊戲與 UDP：成功接管後還要檢查節點

遊戲經常同時使用 TCP 和 UDP。傳統 HTTP 系統代理通常無法承接遊戲自行傳送的 UDP 封包；SOCKS 協定雖然支援 UDP 轉送，但應用程式也必須主動支援並使用這項功能。TUN 能將更多這類流量送進核心，因此更適合排查不使用系統代理的遊戲連線。

不過，虛擬網卡無法替遠端節點補上 UDP 支援。節點協定、伺服器設定、策略群組選用的出口與本機網路，都可能限制 UDP。請先在用戶端的連線清單確認是否看得到遊戲連線，再查看它符合 DIRECT 還是代理群組規則，最後確認選用的節點是否支援所需流量。

  • 成功登入，但無法進入對戰：分別檢查登入階段的 TCP 請求與對戰階段的 UDP 連線，不要只測試登入頁面。
  • 能連線但延遲偏高：在相同伺服器區域、相同時段比較遊戲內延遲與封包遺失率。節點清單中的 HTTP 測速結果不等同於遊戲延遲。
  • 區域網路連線或裝置探索異常：檢查本機網段的略過策略。廣播、多點傳播與探索協定不應視為一般遠端單播連線來處理。

如果應用程式依賴特定網路介面、防作弊元件或特殊傳輸方式，TUN 也不保證能相容。請先保留原有網路設定與復原方式，每次只變更一個項目，才能判斷問題是由接管方式、規則還是出口造成。

Mac 上的選擇方式與故障復原順序

依應用程式需求選擇流量入口

  • 主要使用瀏覽器與遵循系統代理的應用程式：先啟用系統代理，設定方式較直覺，也方便檢查本機連接埠。
  • 偶爾使用終端機：優先在指令中加入 --proxy，或設定目前工作階段的變數，讓影響範圍一目瞭然。
  • 多個程式不使用代理，或需要處理 UDP：可考慮使用 TUN，並一併檢查輔助服務、DNS 與路由。
  • 正在連線公司 VPN：請先遵循組織的網路規範。兩種工具都可能修改路由與 DNS，應分開測試，避免直接疊加使用。

啟用 TUN 後無法上網：先復原再排查

  1. 關閉 TUN，讓用戶端繼續執行，確認一般網路是否恢復。暫時不要反覆匯入不同訂閱。
  2. 關閉系統代理，清除測試用終端機中的代理變數，再確認是否已恢復直連。如果曾設定 all_proxy 或其大寫變數，也要一併清除。
  3. 執行 scutil --proxy 檢查是否有殘留代理設定；執行 route -n get default 查看預設路由。TUN 可能會使用更具體的分流路由，因此預設路由本身無法代表所有流量的接管結果。
  4. 使用 netstat -rn -f inet 查看 IPv4 路由；若涉及 IPv6，再執行 netstat -rn -f inet6。出現 utun 介面不一定代表它屬於目前使用的用戶端，其他 VPN 也可能使用該介面。
  5. 確認網路恢復後，只開啟一種流量入口並重新測試。如果只有 TUN 會出問題，再檢查服務權限、路由衝突與 DNS 記錄。

系統代理與 TUN 並沒有固定的優劣之分。前者適合能主動使用代理的應用程式；後者能擴大接管範圍，但也增加路由、權限與 DNS 的排查項目。先以最少設定滿足目前需求，再逐步擴大涵蓋範圍，會比一次啟用所有選項更容易維護。