Clash 使用手冊：訂閱、分流與 TUN 設定

核心概念：先分清核心、用戶端與設定檔

Clash 不是單一安裝套件

日常所說的「Clash」，可能是代理核心、圖形化用戶端，也可能泛指採用 Clash 設定格式的一整套工具。核心負責讀取設定、建立代理連線、比對規則與轉送流量；圖形化用戶端則負責將設定、日誌、策略群組、系統代理與更新操作整理成可點選的介面。mihomo 是目前 Clash 生態系中常見的延續核心，許多新用戶端使用它來提供協定、規則類型、TUN 與 DNS 能力。理解這層關係很重要：同一份訂閱在不同用戶端中的按鈕位置可能不同，但核心實際處理的代理節點、策略群組與規則邏輯往往相近。

設定檔通常採用 YAML，可包含連接埠、代理節點、策略群組、規則、DNS 與 TUN 設定。訂閱則是一種遠端設定來源：用戶端儲存訂閱連結，按需下載服務提供者產生的設定，再交由核心載入。訂閱連結本身不是「連線按鈕」，節點名稱也不等於最終出口；請求會先經過規則比對，再由規則指定的策略群組選擇具體節點或直連。因此排錯時必須區分三個環節：遠端訂閱能否下載、設定能否由核心解析，以及流量能否依規則送往可用策略。

一次請求如何經過 Clash

以瀏覽器瀏覽網頁為例，瀏覽器會先將請求交給系統網路堆疊。若系統代理已開啟，支援系統代理的應用程式會將 HTTP 或 SOCKS 請求送往用戶端監聽連接埠；若啟用 TUN，更多 IP 流量會先進入虛擬網路介面。核心取得目標網域或目標位址後，從規則清單頂端開始比對，命中後便將請求交給指定策略。策略可以是具體節點，也可以是手動選擇、自動測速、故障轉移、直連或拒絕。最後，節點依對應協定與遠端伺服器建立連線，回傳資料再沿原路交給應用程式。

這條鏈路能解釋常見現象：瀏覽器正常但某個遊戲無法連線，通常表示該應用程式沒有使用系統代理，可能需要 TUN；所有網站都無法開啟但訂閱更新成功，通常表示設定已下載，問題出在節點、策略或本機接管環節；只有特定網域異常，則更可能是規則、DNS 或目標服務本身的限制。排錯不應反覆刪除用戶端，而應先確認故障位於「取得訂閱、解析設定、接管流量、比對規則、連線節點、解析 DNS」中的哪一層。

選擇用戶端：依平台、核心與使用情境判斷

優先選擇仍在維護的圖形化用戶端

選擇用戶端時，先看作業系統，再看維護狀態、核心類型與所需功能。本網站下載清單首推 Clash Plus，涵蓋 Windows、macOS、Android 與 iOS，適合希望在多個平台採用相近操作方式的讀者。Windows 與 macOS 也可選擇 Clash Verge Rev、FlClash；Windows 另有 Clash Nyanpasu。Android 可選擇 Clash Meta for Android、FlClash 或 Surfboard。Linux 桌面環境可使用 Clash Verge Rev 或 FlClash。Clash for Windows 與 ClashX Meta 已停止維護，只適合處理舊設定遷移，不應作為新安裝時的預設選擇。

「介面看起來熟悉」不是唯一標準。需要 TUN、程序規則、規則集或較新的設定欄位時，應確認用戶端採用的核心能夠識別這些功能。採用 mihomo 核心的用戶端通常更適合目前的設定生態系，但即使都是 mihomo 用戶端，權限申請、設定儲存位置、系統匣選單與系統代理實作仍可能不同。訂閱服務產生的設定若依賴特定欄位，也應優先遵循服務說明；遇到無法識別的欄位時，先確認核心相容性，不要直接刪改整份設定。

桌面、行動裝置與伺服器不是同一種使用方式

桌面用戶端通常同時提供系統代理與 TUN。系統代理設定簡單，適合瀏覽器、即時通訊與遵循系統代理設定的軟體；TUN 覆蓋範圍更廣，適合不讀取系統代理的應用程式。Android 用戶端通常透過系統 VPN 介面接管流量，啟用時會顯示 VPN 狀態標誌；若系統同時執行其他 VPN 類應用程式，通常無法同時佔用介面。iOS 版本同樣依賴系統網路延伸功能，設定入口與背景行為受系統規則影響。行動裝置還應特別留意電池最佳化、背景限制與依應用程式代理。

伺服器、軟路由與容器環境更適合直接執行 mihomo 核心。這類環境無須為了圖形介面增加桌面相依套件，通常透過設定檔、命令列參數與外部控制介面管理。但核心套件不等於開箱即用的桌面用戶端：使用者需要自行準備設定路徑、執行使用者、服務管理、日誌輪替與防火牆規則。僅在個人電腦上瀏覽網頁時，應優先選擇圖形化用戶端；只有明確需要閘道轉送、旁路由或自動化部署時，才考慮純核心方案。

確認系統架構與安裝套件類型

Windows 常見桌面裝置使用 x64；搭載 ARM 處理器的裝置才需要 ARM64。macOS 可在「關於這台 Mac」中查看晶片類型：Apple 晶片對應 arm64，Intel 處理器對應 x64。Android 安裝套件可能分為 arm64、arm 或通用套件，近年的主流手機多使用 arm64，但舊裝置與特殊模擬器需要依實際架構選擇。Linux 除了架構外還要區分 deb、rpm 與壓縮檔：Debian、Ubuntu 常用 deb，Fedora 系列常用 rpm，純核心壓縮檔則需要手動部署。

完整用戶端清單、平台入口與維護狀態集中在下載頁。如果舊用戶端仍保存重要設定，遷移前先匯出設定或記下訂閱位址、策略選擇與自訂規則，再安裝新用戶端。不同用戶端的資料庫與設定目錄通常不能直接互相覆蓋，較穩妥的做法是重新匯入訂閱，再逐項恢復自訂內容。

安裝與初始設定：建立可恢復的基礎環境

安裝前先清除衝突狀態

安裝用戶端前，先退出仍在執行的代理、VPN 與舊版 Clash 用戶端，並確認系統代理沒有殘留。Windows 可在系統網路設定中查看手動代理是否仍然開啟；macOS 可在目前網路服務的代理設定中檢查 HTTP、HTTPS 與 SOCKS 項目。殘留代理常造成一種誤判：新用戶端尚未啟動，瀏覽器卻仍把請求送往已不存在的本機連接埠，導致所有網頁都無法開啟。此時問題不在安裝套件，而是舊程式退出後沒有恢復系統代理。

桌面安裝完成後，先啟動用戶端，但不要立即開啟所有進階功能。確認介面能正常顯示、核心可以啟動，且日誌沒有持續重複的錯誤後，再匯入訂閱。首次啟用 TUN 時，Windows 可能要求管理員權限或安裝虛擬網路元件；macOS 可能要求允許網路延伸功能或輸入系統認證。只有在功能確實啟用時才授予權限。若拒絕權限，系統代理通常仍可使用，但 TUN 無法建立虛擬介面。

先確認設定目錄與自動啟動策略

圖形化用戶端通常會將設定、訂閱索引、核心檔案與日誌儲存在使用者目錄。不要將程式目錄與設定目錄混為一談：解除安裝應用程式未必會刪除使用者設定，覆蓋安裝也未必會重設設定。遇到異常時，應先使用用戶端提供的重設、切換設定或清除快取功能；只有確認設定資料庫損壞後，才考慮備份並刪除設定目錄。任意清理使用者目錄會同時遺失訂閱位址、腳本、自訂規則與策略選擇。

「開機啟動」與「啟動時開啟系統代理」是兩個不同選項。前者只負責執行用戶端，後者會修改作業系統的代理設定。行動辦公裝置可以開啟用戶端自動啟動，但建議先觀察幾次重新啟動的行為，再決定是否自動接管網路。若裝置經常連入需要網頁驗證的公共網路，自動開啟代理可能導致驗證頁無法跳出；此時先暫停系統代理完成網路驗證，再恢復連線。TUN 的自動啟動也應在基礎設定穩定後開啟，避免開機階段因權限或 DNS 設定異常影響整個網路。

連接埠設定要保持職責清楚

Clash 設定常見連接埠包括 HTTP 連接埠、SOCKS 連接埠與混合連接埠。混合連接埠可在同一監聽連接埠接收 HTTP 與 SOCKS 請求，適合多數個人裝置。只要連接埠未被其他程式佔用即可，不需要為了「速度」頻繁修改。允許區域網路連線會讓同一網路中的其他裝置有機會存取監聽連接埠，因此只在確實有共享需求時開啟，並搭配監聽位址、存取控制與系統防火牆限制來源。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090

上方的基礎片段代表啟用混合連接埠、僅允許本機存取、使用規則模式，並將控制介面限制在本機。不同用戶端可能會由介面產生這些欄位，手動編輯前應確認用戶端是否會在儲存時覆寫檔案。控制介面用於圖形介面與核心通訊，不應直接暴露於不受信任的網路。日誌層級日常使用選擇 info 即可；debug 會產生更多診斷資訊，適合短時間排錯，長期啟用會增加日誌容量並干擾關鍵資訊判讀。

用最小閉環驗證安裝

基礎驗證依固定順序進行：先確認核心狀態為執行中；再匯入一份可用設定；選擇策略群組中的節點；開啟系統代理；最後使用瀏覽器瀏覽一般網頁。若失敗，先觀察用戶端連線紀錄與日誌：完全沒有連線紀錄，表示流量沒有進入用戶端；有紀錄但顯示直連，表示規則命中了 DIRECT；有代理紀錄但握手失敗，表示節點連線或網路環境存在問題。完成這個最小閉環後，再啟用 TUN、DNS 劫持、腳本或複雜規則，可大幅降低排錯難度。

訂閱匯入與更新：管理遠端設定的完整週期

訂閱連結、設定檔與節點連結的差異

訂閱連結通常會回傳一份由服務端產生的設定，內容可能包括多個節點、策略群組、規則與 DNS 設定。單一節點連結只描述一個代理節點，無法自動提供完整的分流結構；本機 YAML 檔案則是某個時間點儲存的靜態設定，不會自行跟隨遠端變更。匯入前先確認手上的內容類型：如果用戶端要求填寫 URL，應提供以 HTTPS 開頭的訂閱位址；如果使用檔案匯入，應選擇完整 YAML；如果只有單一節點連結，則需要用戶端支援從剪貼簿解析，或自行加入現有設定。

訂閱位址相當於設定存取憑證，不適合發布到截圖、論壇或公開儲存庫。用戶端通常會把位址儲存在本機設定資料庫中。跨裝置同步時，優先在每台裝置中分別匯入訂閱，或使用服務方提供的集中管理方式；不要把包含訂閱位址的設定檔放進公開同步目錄。範例位址應使用測試網域，例如：

https://example.invalid/api/profile/clash?token=xxxx

一次正確的匯入流程

在用戶端中開啟「訂閱」、「設定」或「Profiles」頁面，選擇從 URL 新增設定，貼上連結後為設定填寫容易辨識的名稱。更新間隔可依設定變更頻率調整，日常使用通常不需要每隔幾分鐘重新整理。儲存後手動執行一次更新，確認用戶端顯示設定名稱、更新時間或策略群組，而不是只看到「已新增」狀態。接著切換至這份設定，讓核心重新載入。某些用戶端將「下載訂閱」與「啟用設定」分成兩個動作，只更新而不切換時，目前執行的可能仍是舊設定。

匯入完成後不要立即刪除舊設定。先檢查關鍵策略群組是否存在、規則模式能否選擇、常用節點是否顯示，再完成連線測試。確認新設定穩定後，可以保留一份舊設定作為短期回復方案。多份設定並存時應使用明確名稱，例如「日常訂閱」、「本地規則測試」，避免全部命名為 config 或 default。切換設定會改變策略群組與規則，用戶端可能無法將舊的策略選擇對應至新設定，因此切換後需要重新確認出口群組。

更新失敗時分層排查

訂閱更新失敗時，先查看錯誤類型。逾時通常表示用戶端無法存取訂閱伺服器；憑證或系統時間錯誤會影響 HTTPS 建立；回傳未授權通常表示位址失效或存取條件變更；下載成功但解析失敗，則表示回傳內容不是有效設定，可能是網頁錯誤資訊、編碼異常，或包含目前核心無法識別的欄位。先將訂閱位址複製到可存取的瀏覽器環境中確認是否能取得內容，但不要公開回傳內容。若瀏覽器可存取而用戶端失敗，請檢查用戶端是否設定以代理、直連或目前代理更新訂閱。

「透過代理更新訂閱」有一個常見循環：目前設定中的節點全部失效，而訂閱更新又必須經過目前代理，因此用戶端無法取得新設定。此時可暫時切換為直連更新，或使用仍可用的備用設定完成更新。相反地，若目前網路無法直接連到訂閱伺服器，則需要透過可用代理更新。不同用戶端對更新通道的命名不同，應在訂閱設定、全域設定或網路設定中尋找，而不是反覆重新加入同一個位址。

自動更新需要保留回復空間

啟動時自動更新適合設定較穩定、裝置網路可靠的情境，但不應將其視為唯一的維護方式。遠端設定若暫時產生失敗，自動更新可能會把可用設定替換成異常內容。較穩妥的做法是保留最近可用設定、設定合理的更新間隔，並在重要出行或切換網路前手動更新與測試。對於自行維護的本地覆寫規則，應確認訂閱更新不會直接覆蓋修改；若用戶端支援覆寫、合併或腳本功能，應將自訂內容放在獨立層，而不是直接編輯每次都會被替換的訂閱檔案。

代理模式：如何選擇規則、全域與直連

規則模式是日常使用的預設選擇

規則模式會逐條檢查請求目標，依網域、IP、程序或規則集將流量交給不同策略。常見設定會讓本地網路與不需要代理的目標直連，將特定目標交給代理群組，再用最後一條兜底規則處理未命中的請求。它的優勢不是「自動選擇最快節點」，而是讓不同類型的流量採用不同路徑。最終使用哪個節點，仍由命中的策略群組決定。多數日常情境應保持規則模式，因為它兼顧存取範圍、區域網路服務與不同應用程式的連線需求。

規則模式出現「部分網站正常、部分網站異常」時，不要立即改成全域模式。先在連線紀錄中找到目標請求，查看命中的規則與策略。若目標被誤判為直連，可以加入更精確的網域規則；若被送往錯誤的策略群組，應調整規則目標或策略群組選擇；若完全看不到網域，只顯示 IP，則需要檢查 DNS 模式、嗅探或應用程式是否直接連線至位址。全域模式可以作為診斷工具：切換至全域後恢復，表示節點本身大致可用，問題集中在規則或 DNS；全域模式也失敗，則優先檢查節點與流量接管。

全域模式不是「效能強化模式」

全域模式通常會將所有已進入核心的流量交給同一個全域策略群組，不再依一般分流規則決定路徑。它適合短時間驗證節點、臨時存取尚未被規則涵蓋的目標，或在明確知道所有流量都應使用同一路徑時啟用。全域模式不會讓不遵循系統代理的應用程式自動進入 Clash，也不會繞過作業系統權限；某個程式在規則模式下完全沒有連線紀錄時，切換全域模式通常仍然無效，此時需要處理系統代理、應用程式代理設定或 TUN。

長期使用全域模式可能使本地服務、印表機、區域網路裝置與原本應直連的業務也經過代理。部分設定會對區域網路位址保留特殊處理，但不能假設所有用戶端行為完全相同。需要存取路由器管理頁、區域網路儲存或開發環境時，若發現連線繞遠，應恢復規則模式並為本地網段保留 DIRECT。全域模式下的出口取決於「GLOBAL」策略群組目前的選擇，不代表會自動使用清單中的第一個節點。

直連模式用於恢復與定位問題

直連模式會讓進入核心的流量不經過代理節點，常用於網路驗證、直接更新訂閱、確認目標在本地網路是否可達，以及暫時恢復一般網路。它與「退出用戶端」並不完全相同：用戶端仍可能維持系統代理或 TUN 接管，只是轉送動作改為 DIRECT。排查系統代理殘留時，應同時測試直連模式與完全關閉接管；若直連模式可用但退出用戶端後不可用，可能是系統 DNS、代理設定或網路介面狀態尚未恢復。

切換模式後的驗證方法

切換模式後，應重新發起一次請求，不能只查看先前已建立的連線。瀏覽器可能重複使用現有連線，應用程式也可能保留 DNS 快取，因此測試時可以開啟新的無痕視窗、重新載入目標或暫時重新啟動應用程式。接著在連線清單中確認新請求命中的模式與策略。若用戶端支援清理連線，可在切換後關閉舊連線，但不需要頻繁重新啟動核心。記錄「模式、命中規則、策略群組、具體節點、錯誤資訊」五項，通常比只記錄「能開或不能開」更容易找出差異。

選擇模式時還要區分「代理模式」與「流量接管方式」。規則、全域、直連決定進入核心後的處理邏輯；系統代理與 TUN 決定哪些流量能夠進入核心。兩個維度彼此獨立。規則模式搭配 TUN 可以處理更多應用程式，全域模式搭配系統代理仍只能涵蓋遵循系統代理的軟體。理解這一點後，許多看似矛盾的現象便會變得清楚。

規則分流：從比對順序到策略群組設計

規則由上至下比對，首次命中即停止

Clash 規則清單具有明確順序。請求從第一條開始檢查，命中後便直接使用該規則指定的策略，不再繼續向下比對。因此，範圍越精確的規則通常越靠前，範圍較大的規則集與最終兜底規則則放在後面。如果將廣泛的網域後綴或 IP 區段放得太早，後方的精確規則便永遠沒有機會生效。排查規則時，不能只確認「設定中有這條規則」，還要確認它位於哪一條更寬泛的規則之前或之後。

常見規則類型包括精確網域、網域後綴、網域關鍵字、IP 網段、來源位址、目標連接埠、程序名稱與規則集引用。網域規則依賴核心取得目標網域；若請求只呈現 IP，網域規則可能無法比對。IP 規則則要考慮解析結果以及 IPv4、IPv6 的差異。程序規則在桌面平台較有價值，但受系統權限與用戶端實作影響，不應將所有核心分流都建立在程序識別之上。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - DOMAIN-KEYWORD,media,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DST-PORT,22,Direct-or-Proxy
  - MATCH,Final

範例中，精確網域首先直連，example.org 及其子網域進入 Proxy，名稱包含 media 的網域進入 Media，本地網段直連，目標連接埠為 22 的請求交給獨立策略，其餘請求由 Final 處理。策略名稱必須與 proxy-groups 中的名稱完全一致，包括大小寫與空格。no-resolve用於避免某些 IP 規則為了比對而額外觸發網域解析，但是否適用仍須結合規則類型與設定目標判斷。

策略群組將規則與具體節點解耦

規則最好指向語意清楚的策略群組，而不是直接寫入某個節點名稱。例如規則指向「Media」、「Work」或「Final」，再於策略群組內選擇具體節點。如此一來，即使訂閱更新導致節點增刪，規則層也不必全部重寫。手動選擇群組適合由使用者明確決定出口；自動測試群組會定期存取測試位址，依回應選擇節點；故障轉移群組會按順序嘗試可用節點；負載平衡群組則依設定的演算法分配連線。不同群組解決的問題不同，不能只憑名稱推斷行為。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

url-test測量的是對指定測試位址發出一次請求的表現，不代表影片頻寬、長連線穩定性或所有目標的實際體驗。測試位址應長期可存取、回應內容小，並與實際使用的網路路徑具有一定代表性。間隔過短會產生額外請求，間隔過長則可能無法及時發現節點變化。tolerance用於減少延遲接近時的頻繁切換，避免策略在多個節點之間來回變動。自動群組適合一般存取，重要工作階段或需要固定出口的業務則更適合手動選擇群組。

規則集與遠端提供者

規則數量較多時，可使用 rule-providers 將不同類別拆成獨立檔案，再由主設定引用。如此可單獨更新規則集，也方便重複使用。但遠端規則同樣存在下載失敗、格式不相容與更新後行為改變的風險。應為規則提供者設定合理的更新間隔與本地快取路徑，首次啟用後檢查日誌是否下載成功。規則集類型、行為類型與檔案格式需要互相匹配；domain、ipcidr 與 classical 的內容結構不同，混用會導致解析錯誤或規則無法如預期運作。

修改規則時採用「最小覆蓋」思路：先為明確異常的網域增加一條精確規則，確認命中後再決定是否擴大至網域後綴或規則集。不要因為一個子網域異常，就把整個頂級網域全部送往同一策略，也不要把最終 MATCH 提到前面。若用戶端支援覆寫或合併規則，應將本地規則放入持久化覆寫層，避免訂閱更新後遺失。關於 DNS 與規則如何互相影響，可繼續閱讀Clash DNS 設定詳解。

TUN 與 DNS：接管更多流量並維持解析一致

TUN 解決的是流量入口問題

系統代理依賴應用程式主動讀取作業系統的代理設定。瀏覽器與多數桌面應用程式通常支援，但遊戲、命令列工具、部分商店應用程式，以及使用自訂網路堆疊的軟體可能完全忽略系統代理。TUN 會建立虛擬網路介面，透過路由將更多 IP 流量送入核心，因此能涵蓋更廣泛的應用程式。它不是一種新的代理模式：流量進入 TUN 後，仍須依規則、全域或直連模式處理，也仍由策略群組決定出口。

首次啟用 TUN 時，用戶端可能需要管理員權限、網路延伸功能權限或 VPN 權限。Windows 上還要留意其他虛擬網卡、企業安全軟體與既有 VPN；macOS 上要確認網路延伸功能已獲系統允許；Android 與 iOS 通常會將 TUN 表現為系統 VPN，可能與其他佔用同一介面的應用程式衝突。若啟用後所有網路立即中斷，應先關閉 TUN 恢復基礎連線，再查看日誌中的介面建立、路由寫入與 DNS 監聽錯誤，而不是繼續切換節點。

常見 TUN 參數的作用

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

auto-route讓核心自動寫入必要路由，auto-detect-interface用於識別目前的對外網路介面，適合會在有線、無線與行動熱點之間切換的裝置。stack決定 TUN 使用的網路堆疊實作，mixed 是常見選擇；若某個平台出現相容性問題，可依用戶端文件在 system、gvisor 或 mixed 之間測試，但一次只修改一個參數。dns-hijack用於將符合條件的 DNS 請求交給核心，減少應用程式繞過 Clash DNS 的情況。

範例中的位址僅用於說明欄位結構。實際 DNS 伺服器要依目前網路可達性、隱私需求與設定來源選擇。不要簡單堆疊大量 nameserver 與 fallback；伺服器越多不一定越穩定，反而會讓查詢路徑與排錯結果變得複雜。若訂閱已提供 DNS 區段，應先理解既有邏輯再修改。用戶端透過圖形化開關產生 TUN 設定時，也應避免同時在訂閱檔案與全域設定中寫入兩套互相衝突的 DNS 參數。

fake-ip 與 redir-host 的差異

fake-ip 模式會為網域回傳保留位址區段中的映射位址，核心透過映射關係保留原始網域，從而更早進行網域規則比對。它通常具有較佳的分流能力，但某些區域網路服務、特殊應用程式或依賴實際解析結果的程式，可能需要加入 fake-ip-filter。redir-host 更接近傳統解析流程，回傳實際 IP，再結合解析結果進行轉送，相容性思路較直觀，但網域資訊保留與比對路徑有所不同。選擇時應依據用戶端預設值與實際相容性，不需要為了追求某個名稱而頻繁切換。

出現「網頁能開啟但找不到某個區域網路裝置」、「應用程式登入失敗但瀏覽器正常」時，可以檢查 DNS 日誌、fake-ip 過濾項目與區域網路網域。過濾應盡量精確，例如只針對特定本地域名後綴，而不是排除所有網域。修改後清除應用程式自身的 DNS 快取或重新建立連線，否則舊的解析結果可能繼續生效。若系統啟用了其他加密 DNS、瀏覽器安全 DNS 或企業 DNS 用戶端，還要確認它們是否繞過 Clash 的解析路徑。

定位 TUN 常見衝突

TUN 開啟後完全斷網，優先檢查虛擬介面是否建立成功、預設路由是否寫入，以及目前實體介面是否正確識別。只有部分應用程式異常，則查看該應用程式的請求是否進入連線清單，以及是否被排除在 TUN 路由之外。存取區域網路異常時，檢查私有網段規則與路由排除項目。休眠喚醒後失效，可能是網路介面發生變化而路由未及時重新整理；可先關閉再開啟 TUN，確認是否恢復，再考慮自動偵測介面與更新用戶端。

同時執行容器、虛擬機器、遊戲平台加速工具或企業 VPN 時，路由表會更複雜。排錯時先暫時退出其他會修改路由的程式，驗證單獨執行 Clash TUN 是否正常；接著逐一恢復，觀察衝突在哪一步出現。若工作環境強制使用企業 VPN，不應擅自覆寫其路由，應優先使用系統代理或遵循網路管理要求。TUN 的目標是擴大接管範圍，而不是強行改變所有受管理的網路策略。

日常維護與故障排查：建立穩定的檢查順序

維護重點是設定、核心與系統狀態

Clash 用戶端穩定執行後，不需要頻繁清空設定或更換節點。日常維護可固定為四項：按需更新訂閱、留意用戶端與核心的維護狀態、定期檢查日誌容量，以及保留可恢復的設定來源。訂閱更新後簡單驗證常用策略群組即可；用戶端更新前記下目前設定位置與關鍵開關，更新後先確認核心啟動、系統代理與 TUN 狀態。直接覆蓋安裝通常不會改變訂閱，但仍應為自訂規則與本地設定保留獨立備份。

日誌用於定位問題，不適合長期保持 debug 層級。正常執行時使用 info，可看到設定載入、監聽連接埠、訂閱更新與連線錯誤。出現問題後重現一次，再從重現時間點附近讀取日誌。搜尋第一個明確錯誤通常比盯著最後一行更有效，因為後續錯誤可能只是前面失敗造成的連鎖結果。分享日誌前應刪除訂閱位址、節點認證資訊與個人路徑，只保留錯誤類型、相關欄位與必要上下文。

依「範圍」判斷故障位置

所有應用程式都無法連線時，先切換直連模式並關閉 TUN，檢查一般網路是否可用；接著確認核心狀態與連接埠佔用。只有遵循系統代理的應用程式正常、其他應用程式異常，表示需要檢查 TUN 或應用程式自身的代理設定。只有一個網站異常，查看命中規則、DNS 結果與目標服務狀態。只有某個節點異常，則與同一策略群組中的其他節點進行對照。訂閱無法更新但現有連線可用，便將問題限定在訂閱位址與更新通道，不要重設整個用戶端。

延遲測試只能反映測試位址上的短請求表現。某個節點顯示較低延遲，卻可能受頻寬、封包遺失、壅塞或目標線路影響，在影片與大型檔案情境下表現不佳。反過來，延遲略高的節點也可能更加穩定。判斷實際體驗時，應結合連線成功率、持續傳輸、目標服務回應與一段時間內的穩定性。延遲數字的原理與誤區可參考Clash 延遲測試數字怎麼看。

連接埠、時間與快取是容易忽略的基礎項目

連接埠遭佔用會讓核心無法監聽，日誌通常會出現 address already in use 類似的資訊。先退出舊用戶端與重複的核心程序，再確認連接埠是否釋放。系統時間明顯不準會導致 HTTPS 憑證驗證與部分協定握手失敗，應開啟可靠的時間同步。DNS 與連線快取則會讓修改無法立即反映：切換規則後舊連線仍可能繼續使用原本的策略，修改 DNS 後應用程式也可能保留舊結果。測試時重新建立連線，必要時重新啟動目標應用程式，而不是每次都重新啟動整台裝置。

系統代理關閉失敗時，可在作業系統網路設定中手動恢復。Windows 還應檢查自動設定指令碼與手動代理是否同時殘留；macOS 則需要依目前網路服務檢查代理項目。用戶端異常退出後，TUN 路由通常會被清理，但少數情況下虛擬介面或路由狀態可能暫時保留；重新啟動用戶端並正常關閉一次，通常比直接刪除驅動程式更穩妥。行動裝置則可在系統 VPN 設定中中斷連線，再重新授權用戶端。

建立可重現的排錯紀錄

有效的排錯紀錄至少包括作業系統、用戶端名稱、使用的接管方式、代理模式、問題發生時間、目標應用程式、命中策略與關鍵日誌。描述「不能用」無法區分訂閱、規則、DNS 與節點問題；描述「規則模式下瀏覽器請求命中 DIRECT，全域模式命中 Proxy 後恢復」便能直接指向規則層。每次測試只變更一個變數，並記錄變更前後的結果。複雜問題可以複製目前設定建立測試副本，避免在日常設定上連續疊加臨時修改。

如果更新用戶端後出現新問題，先確認設定是否仍被選取、核心是否切換，以及 TUN 權限是否保留，再考慮回復。舊用戶端停止維護後不宜長期停留，遷移至新用戶端後應重新驗證系統代理、策略群組與自訂覆寫。關於原版、Meta 與 mihomo 的關係，可閱讀Clash 核心版本差異與選擇，避免將用戶端版本變化與核心差異混為一談。

進階路線：從圖形化設定走向可維護設定

先學會閱讀設定，再開始重寫設定

進階設定的第一步不是從空白檔案開始，而是讀懂一份已經可以執行的設定。先識別基礎監聽、DNS、代理提供者、策略群組、規則提供者與最終規則，再追蹤一個實際請求會經過哪些欄位。為訂閱產生的設定建立副本，在副本中進行最小修改，並透過用戶端的設定檢查功能驗證。YAML 對縮排敏感，清單項目、物件層級與字串中的特殊字元都可能導致解析失敗；編輯器應使用空格縮排，並避免自動將普通字元替換為排版符號。

設定拆分應圍繞維護邊界：訂閱負責遠端節點，本地覆寫負責個人規則，規則提供者負責可重複使用的分類，全域設定負責裝置層級的連接埠、TUN 與介面行為。不要把所有內容堆進一個每次訂閱更新都會被替換的檔案。若用戶端支援 merge、override 或腳本，應先確認合併順序：同名欄位是覆蓋、追加還是深度合併，會直接影響最終設定。修改後查看用戶端實際產生並交給核心的設定，而不是只看輸入片段。

代理提供者適合管理動態節點

proxy-providers:
  main-provider:
    type: http
    url: https://example.invalid/provider.yaml
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: Main
    type: select
    use:
      - main-provider
    proxies:
      - DIRECT

proxy-providers 可以將節點來源與主設定分開，主設定透過 use 引用提供者。遠端檔案應採用核心支援的 provider 格式，路徑用於本地快取，更新間隔控制重新取得的頻率。健康檢查用於判斷節點對指定測試位址的可達性，但結果仍不代表所有目標的使用體驗。多個提供者並存時，可以依用途分別建立策略群組，不必將所有節點塞進一個龐大的清單。提供者更新失敗時，本地快取通常仍有機會繼續使用，因此快取路徑應放在用戶端可寫入且會被保留的位置。

外部控制介面與區域網路開放應分別管理

external-controller 允許圖形介面或管理面板讀取核心狀態並執行切換操作。個人電腦上優先監聽回環位址，只有需要從其他裝置管理時才考慮監聽區域網路，同時設定存取憑證、系統防火牆與受信任網段。allow-lan 控制代理連接埠是否允許區域網路裝置連線，與控制介面不是同一個開關。開放代理連接埠不代表應開放控制介面，反之亦然。任何面向區域網路的監聽都應明確用途與存取範圍。

在軟路由或伺服器中執行時，還要決定核心以哪個使用者啟動、設定與快取目錄由誰寫入，以及服務失敗後如何重新啟動。使用系統服務管理器比在終端機中長期掛起程序更可靠。更新核心前應保留目前的可執行檔與設定，先執行設定檢查，再重新啟動服務並觀察日誌。容器部署則需要明確連接埠對映、網路模式、TUN 裝置權限與設定磁碟區，不應將主機的全部目錄直接對映給容器。

DNS、嗅探與規則應作為一套系統設計

進階設定經常同時啟用 fake-ip、DNS 劫持、網域嗅探與規則集。它們的共同目標是盡可能保留網域資訊並正確分類流量，但重複或互相衝突的設定會增加誤判。嗅探可以從部分 HTTP、TLS 或 QUIC 流量中還原網域，對直接連線至 IP 的應用程式有所幫助；它不能解密業務內容，也不是所有協定都能取得網域。應從用戶端預設範圍開始，只為明確的問題調整連接埠或排除項目。

設計 DNS 路徑時，先釐清三個問題：系統請求交給誰、核心向哪些上游查詢，以及解析結果如何參與規則。若使用 nameserver-policy，可為特定網域指定解析伺服器，但規則範圍要精確，避免大量查詢意外送往不合適的上游。fallback-filter 用於判斷哪些結果進入備用解析邏輯，應結合地理資料、網段與網域條件理解。相關欄位的完整關係可查閱nameserver、fallback 與劫持參數說明。

建立自己的變更流程

可維護的設定需要一套固定流程：複製目前可用設定，寫明本次只解決一個問題；修改後執行語法檢查；在可透過直連恢復的環境中載入測試；觀察連線紀錄、規則命中與日誌；確認穩定後再合併至日常設定。對於規則集與代理提供者，記錄來源、用途與更新方式。刪除不再使用的欄位，避免同一功能在圖形化設定、覆寫檔案與訂閱中重複定義。

學習順序可以沿三條線推進。第一條是規則線：掌握 DOMAIN、IP-CIDR、PROCESS-NAME、RULE-SET 與 MATCH 的比對邊界。第二條是網路線：理解系統代理、TUN、路由、DNS 與 IPv6。第三條是維運線：掌握設定拆分、日誌、服務管理與回復。完成這三條線後，再研究 mihomo 擴充協定與特殊規則類型。可先閱讀mihomo 核心功能差異，確認哪些欄位屬於目前核心，再決定是否加入設定。