Clash 從零到精通完整手冊

核心概念：先了解請求如何通過 Clash

用戶端、核心與設定檔的關係

Clash 不是單一介面的名稱，而是一套由核心、圖形用戶端與設定檔共同構成的運作架構。核心負責監聽本機連接埠、解析設定、比對規則、建立代理連線與處理 DNS；圖形用戶端負責安裝、更新、設定管理、系統代理開關與日誌顯示；設定檔則描述監聽連接埠、代理節點、策略組、規則與 DNS 行為。mihomo 通常被稱為 Clash Meta 核心，它延續 Clash 設定體系，並擴充協定、規則與系統接管能力。理解三者的界線後，排錯會更直接：介面無法開啟屬於用戶端層，設定載入失敗應先檢查 YAML，某個網站走錯線路則檢查規則與策略組。

一次常見的瀏覽器請求，會先進入系統代理或 TUN 虛擬網卡，再交給核心處理。核心讀取請求的網域、目標位址、連接埠與網路類型，依照設定中 rules 的先後順序尋找第一個符合項目。符合項目通常不會直接對應某台伺服器，而是指向一個策略組。策略組再根據目前選擇、自動測試或回退邏輯，決定使用具體代理、直連或拒絕。整個流程可概括為「流量入口 → 規則比對 → 策略組 → 對外連線」。任何一層設定不一致，都可能出現「用戶端顯示已連線，但存取結果不如預期」的情況。

監聽連接埠與系統代理

Clash 常見的入口包括 HTTP、SOCKS 與 mixed-port。HTTP 代理適合支援系統代理或手動代理的軟體；SOCKS 可承載更通用的 TCP 請求；mixed-port 則在同一個連接埠同時接受 HTTP 與 SOCKS，有助於減少連接埠數量。系統代理開關只是將作業系統的代理位址指向本機監聽連接埠，不會改變設定檔中的規則，也無法影響完全忽略系統代理的應用程式。遇到「瀏覽器可用、某個程式不可用」時，應先確認該程式是否讀取系統代理；若不讀取，再考慮在程式內單獨設定代理或啟用 TUN。

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

上方的最小片段表示核心在本機監聽混合連接埠，預設不向區域網路中的其他裝置開放，使用規則模式並記錄一般等級的日誌。連接埠數值可以調整，但調整後必須同步修改系統代理或應用程式代理中的連接埠。若啟動日誌出現監聽失敗，通常是連接埠已被其他程序佔用，可參考Clash 連接埠被佔用的排查步驟找出程序，再決定關閉衝突程式或修改連接埠。

節點、策略組與規則不在同一層

節點是具體的對外連線定義，通常包含伺服器、連接埠、協定與驗證資訊；策略組則是組織多個節點或其他策略的方式；規則負責將請求送往策略組。日常切換線路時，應優先操作策略組，而不是反覆編輯規則。例如可建立名為「代理選擇」的手動組，再建立「自動選擇」的測速組，並將兩者放入更上層的「預設出口」。影片、下載、工作服務等規則只引用穩定的組名。如此一來，更換訂閱或節點時，就不必同步重寫規則層。

選擇用戶端：依平台、核心與管理方式取捨

首選完整圖形用戶端

大多數使用者應從圖形用戶端開始。本網站各平台首推 Clash Plus，提供常用的平台安裝入口、設定管理與連線控制，適合作為首次使用及日常維護的主要用戶端。Windows、macOS、Android 與 iOS 使用者可先在下載頁面切換到對應平台，閱讀系統需求後再安裝。選擇用戶端時不要只看介面外觀，應檢查四項基本能力：是否支援目前的作業系統與處理器架構、是否使用相容於目前設定的核心、是否提供 Profile 更新與切換，以及是否能依需求管理系統代理或 TUN。

Windows 與 Linux 也可選擇 Clash Verge Rev 或 FlClash；Windows 可選擇 Clash Nyanpasu；Android 可選擇 Clash Meta for Android、FlClash 或 Surfboard；macOS 也可見已封存的 ClashX Meta；Clash for Windows 同樣屬於停止維護的封存用戶端。封存不代表舊設定會立即失效，但不適合作為新部署的長期基礎。若現有環境仍依賴舊用戶端，遷移時應先匯出設定與覆寫設定，再在新用戶端中逐項還原，避免同時變更用戶端、核心、DNS 與 TUN，導致無法判斷問題來源。

區分處理器架構

安裝套件名稱中的 x64、AMD64、ARM64、Apple Silicon 等標記，對應不同的處理器架構。多數傳統 Windows 電腦使用 x64；Windows on ARM 裝置需要確認用戶端是否提供 ARM64 建置版本。較新的 Mac 通常使用 Apple Silicon，對應 ARM 建置版本；較早的 Intel Mac 則使用 x64 建置版本。Android 裝置通常優先使用 arm64 套件，只有在架構不明或安裝失敗時才考慮通用套件。Linux 不僅要區分 AMD64 與 ARM，也要區分 deb、rpm 與壓縮核心檔案：桌面發行版適合使用對應的套件管理格式，伺服器與路由器環境則更常直接執行 mihomo 核心。

圖形用戶端與獨立核心的界線

獨立 mihomo 核心適合需要精確控制啟動參數、設定目錄、服務權限與日誌輸出的環境。它不會自動提供桌面圖形介面，也不會代替使用者修改系統代理。部署伺服器時，通常透過命令列指定設定目錄，再交由系統服務管理器維持執行。桌面使用者若只是希望匯入訂閱並建立連線，不必從核心壓縮包開始；圖形用戶端已封裝核心生命週期、Profile 切換與系統設定，更容易定位問題。

此外，同一台裝置不應讓多個用戶端同時接管相同連接埠，或同時建立 TUN。遷移時先退出舊用戶端，確認背景核心已停止，再啟動新用戶端。若新用戶端提示連接埠被佔用，不要連續改成多個隨機連接埠，應先查明殘留程序。若系統代理仍指向舊連接埠，應先關閉舊代理狀態，再由新用戶端重新寫入。維持「一套運作中的核心、一份目前設定、一個明確入口」，可以大幅減少交叉影響。

平台安裝：完成權限、入口與首次啟動檢查

Windows 與 macOS 安裝

Windows 安裝前先退出正在執行的同類用戶端，避免舊核心持續佔用監聽連接埠。完成安裝並首次啟動後，先不要立即開啟所有開關。進入設定頁確認核心狀態、設定目錄與 mixed-port，再匯入設定。啟用系統代理時，用戶端會將系統代理位址指向本機迴路位址與監聽連接埠。如果瀏覽器仍沿用舊設定，可先關閉系統代理，再重新啟用；若只有商店應用程式或 UWP 應用程式無法連線，應檢查應用程式是否允許存取本機迴路，而不是直接修改全域規則。

macOS 安裝時需要依處理器選擇 Apple Silicon 或 Intel 建置版本。第一次開啟若遭系統安全策略攔截，應在系統設定中核對應用程式來源與提示內容。啟用系統代理通常需要授權修改網路設定，啟用 TUN 或網路擴充功能還會出現額外授權。完成授權後應回到用戶端確認開關狀態，不能只以系統彈窗消失為準。若舊用戶端曾安裝輔助服務，遷移前應從舊用戶端正常關閉服務，避免兩個輔助元件同時嘗試修改網路設定。

Android 與 iOS 安裝

Android 用戶端通常透過系統 VPN 介面接管流量。首次啟動連線時，系統會顯示 VPN 授權提示，確認後狀態列會出現相應的連線標誌。若切換應用程式後連線很快停止，應檢查系統的電池最佳化、背景活動與省電限制。部分廠牌系統會在鎖定螢幕後回收背景服務，需要將用戶端加入允許背景執行的清單。分應用程式代理、繞過區域網路與 IPv6 行為由用戶端和設定共同決定，初次測試應先維持簡單設定，確認一般網頁可正常存取後，再增加分應用程式規則。

iOS 使用 Clash Plus 時，請透過 App Store 安裝，並在首次連線時授權新增 VPN 設定。系統同一時間只能維持一套活動中的 VPN 設定，若已有其他網路工具連線，應先中斷再測試。切換無線網路與行動網路後，觀察用戶端是否仍保持連線，並以實際存取結果確認規則生效。行動系統會隱藏部分底層日誌，因此排錯時應記錄問題發生在無線網路、行動網路，還是兩者皆有，並確認是否只影響某個應用程式。

Linux 桌面與核心部署

Linux 桌面安裝 deb 或 rpm 套件後，仍需確認桌面環境是否讀取系統代理設定。不同桌面環境對 HTTP、HTTPS 與 SOCKS 的設定入口不同，用戶端的「系統代理」按鈕未必涵蓋所有工作階段。可先在瀏覽器內測試，再使用明確支援代理環境變數的命令進行驗證。部署獨立核心時，應為設定建立固定目錄，並以前景方式完成第一次啟動，讓語法錯誤直接顯示在終端機中。確認設定可載入後，再交由服務管理器接手。

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

-d 用於指定工作目錄，核心會從該目錄讀取設定及相關資料檔案。實際可執行檔名稱與存放路徑應以下載套件為準。若準備長期執行，應建立權限受限的專用使用者，明確指定設定檔與日誌目錄的擁有者，不要為了繞過權限問題而直接放寬整個目錄的存取範圍。服務啟動失敗時，先在前景執行相同命令，比只查看服務狀態更容易看到 YAML 行號、連接埠衝突或資源檔案遺失。

首次啟動後的四項確認

安裝完成後依固定順序確認：第一，用戶端顯示核心已啟動；第二，目前 Profile 已選取且沒有解析錯誤；第三，系統代理或 VPN/TUN 只有一個預期入口處於啟用狀態；第四，策略組中存在可選擇的對外連線。接著存取一個一般網站並查看連線記錄，確認請求進入核心、命中規則且建立對外連線。不要只用用戶端首頁的狀態文字判斷成功，因為系統代理可能尚未寫入、應用程式可能繞過代理，或 DNS 仍由其他網路元件處理。

訂閱與設定：建立可更新、可回復的 Profile

Profile 是完整設定的入口

Profile 可以來自本機 YAML 檔案，也可以來自遠端訂閱網址。它不只是節點清單，還可能包含策略組、規則、DNS 與覆寫設定。匯入遠端網址後，用戶端通常會將內容儲存為本機副本，並記錄更新來源。之後按下更新時，遠端內容可能覆蓋同一份 Profile 中的手動修改，因此長期自訂內容不應直接散落在自動更新檔案裡。較穩妥的方式是保留原始訂閱作為基礎，再使用用戶端提供的覆寫、腳本或單獨維護的本機設定來增加規則。

管理多份 Profile 時，應為每份設定使用能表達用途的名稱，例如「日常規則」「行動網路測試」「本機最小設定」，不要只保留一串匯入時間。切換 Profile 後，核心需要重新載入設定，策略組的選擇可能恢復為該設定自己的狀態。切換完成後檢查目前檔名、模式與主要策略組，避免介面顯示已切換，但實際仍使用上一份設定。關於多份設定的更新關係與切換邏輯，可繼續閱讀Clash Profile 匯入與多設定管理。

YAML 的結構與縮排

Clash 設定使用 YAML。縮排代表層級，通常使用空格，不應混用定位字元。清單項目以連字號開頭，鍵名後的冒號必須維持正確結構。名稱中含有冒號、井號、逗號或其他特殊字元時，使用引號較為穩妥。設定載入失敗時，應先查看日誌提供的行號，再檢查該行及其上方的層級，因為實際錯誤常來自前一個清單項目的縮排不完整。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: "代理選擇"
    type: select
    proxies:
      - "自動選擇"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    proxies:
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,代理選擇

這個片段展示了層級關係，但「自動選擇」組只有 DIRECT，因此僅用於說明語法。實際節點通常由訂閱或代理提供器寫入。MATCH 是最後的兜底規則，應放在規則清單末尾；前面的規則會優先處理區域網路與其他明確目標。策略組名稱必須與規則中引用的名稱完全一致，包括空格與大小寫。修改名稱後若忘記同步規則，設定可能載入失敗，或請求被送往不存在的策略。

遠端更新與本機覆寫

訂閱更新失敗時，先區分「網址無法存取」「伺服器回傳錯誤」「內容不是有效 YAML」與「用戶端寫入失敗」。可以查看更新日誌中的網路狀態與解析結果。不要連續點擊更新，因為重複請求無法修復網址、權限或格式問題。若舊副本仍可使用，先保留目前活動中的設定，再單獨排查更新來源。更新成功後若節點變化但規則未變，屬於設定提供方式的差異；若策略組名稱也變更，則本機規則引用可能需要同步調整。

覆寫設定適合放置本機連接埠、區域網路存取、DNS 偏好與少量固定規則，但應記錄覆寫是在匯入前還是匯入後套用。後套用的同名欄位通常會覆蓋前者，清單欄位則可能是取代、置前或追加，具體取決於用戶端實作。修改前匯出可正常運作的設定，修改後只進行一類變更並立即重新載入。若同時更改連接埠、DNS、規則與 TUN，發生故障時很難判斷是哪一項造成。

代理模式：理解 Rule、Global 與 Direct 的適用範圍

Rule 模式作為日常預設

Rule 模式會逐條讀取規則，並將請求交給符合的策略組。它適合長期使用，因為區域網路、常用直連目標、代理目標與拒絕目標可以分別處理。規則比對採用由上到下、首次命中即停止的方式，因此排序比規則數量更重要。更具體的規則應放在更寬泛的規則之前，例如完整網域放在網域後綴之前，私有網路位址放在通用 IP 規則之前，最後使用 MATCH 處理未命中的流量。

Rule 模式下的「代理選擇」不是模式開關，而是策略組目前的對外連線。使用者可以在策略組中選擇具體節點、自動測試組或 DIRECT。若某個網站走錯線路，應查看連線記錄中的命中規則與策略名稱，而不是先切換到全域模式。全域模式可用於快速判斷節點本身是否可用，但會繞過原有分流邏輯，不能證明規則設定正確。

Global 模式用於隔離規則問題

Global 模式通常會將進入核心的流量統一送往全域策略組。它適合短時間診斷：如果 Rule 模式存取失敗，而 Global 模式透過同一節點可以存取，問題較可能位於規則、DNS 解析結果或策略組引用；如果兩種模式都失敗，則應繼續檢查節點、目標網路、監聽入口與系統權限。完成診斷後應切回 Rule，避免區域網路、軟體更新與本機服務也被不必要地送往代理。

全域模式不會讓原本沒有進入核心的流量自動進入。某個應用程式若忽略系統代理，即使用戶端切換到 Global，也可能仍然直連。此時連線記錄中通常看不到該應用程式的請求。應檢查應用程式本身的代理設定，或在確認需求後啟用 TUN。這個判斷非常關鍵：模式決定「進入核心後的處理方式」，系統代理與 TUN 決定「請求是否進入核心」，兩者不能互相取代。

Direct 模式與真正退出

Direct 模式通常會讓進入核心的請求直接連線至目標。它適合對照測試，但不等同於完全退出用戶端。系統代理仍可能指向 Clash，DNS 仍可能由核心處理，應用程式的連線記錄也可能繼續出現。若需要恢復作業系統原本的網路路徑，應先關閉系統代理或 TUN，再停止核心；如果用戶端提供「還原系統代理」操作，應透過用戶端正常執行，避免系統保留失效的本機代理位址。

延遲數值僅供相對參考

策略組中的延遲測試通常會向固定網址發起連線，用於判斷節點是否可達，以及比較特定測試路徑。它不等於存取所有網站的實際耗時，也無法完整反映頻寬、封包遺失、連線重複使用、DNS、壅塞與目標伺服器狀態。自動測試組應選擇穩定、回應內容較小的測試網址，並設定合理間隔。間隔過短會增加額外連線，間隔過長則無法及時發現線路變化。具體原理可參考Clash 延遲測試數值解析。

規則分流：從比對順序到自訂策略

常見規則類型

DOMAIN 比對完整網域，適合精確指定單一主機；DOMAIN-SUFFIX 比對某個網域及其子網域，適合涵蓋一組同源服務；DOMAIN-KEYWORD 依網域中的關鍵字比對，範圍較廣，應謹慎放置；IP-CIDR 與 IP-CIDR6 比對位址區段；GEOIP 依位址資料庫分類；PROCESS-NAME 在支援程序辨識的平台上依程式名稱比對；RULE-SET 引用外部規則集合。最後的 MATCH 接收所有先前未命中的請求。

網域規則通常能在 DNS 取得目標位址前完成判斷，IP 類規則則依賴解析結果或實際目標位址。某些連線會直接存取 IP，不含網域資訊，只能由 IP 規則或兜底規則處理。啟用 no-resolve 可以阻止某些 IP 規則為了比對而觸發額外解析，但是否適用取決於規則類型與設定目標。撰寫規則時不要只追求涵蓋數量，應先定義策略組職責，再讓規則引用穩定的職責名稱。

rules:
  - DOMAIN,updates.example.test,DIRECT
  - DOMAIN-SUFFIX,example.test,代理選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,代理選擇

範例使用保留的測試網域說明語法。第一條完整網域規則優先於後面的後綴規則，因此更新主機直連，其他相同後綴的主機則交給「代理選擇」。私有位址區段維持直連，最後由 MATCH 兜底。實際設定中還應依本機網路加入必要的位址區段，並確認區域網路服務不會被送往遠端連線。

規則順序決定最終結果

Clash 不會在全部規則中尋找「最精確的一條」，而是使用第一條符合的規則。因此，若寬泛的 DOMAIN-SUFFIX 放在前面，後面的完整網域例外就永遠沒有機會命中；若 MATCH 提前放置，後續所有規則都會失效。調整規則時，應先在連線記錄中找到目標網域、目標位址與目前命中項目，再將例外規則放到造成衝突的寬泛規則之前。

規則集同樣遵循所在位置的順序。引用多個規則集時，應明確每個集合的範圍與更新來源。不要同時載入大量職責重疊的集合，否則同一個網域可能被前一個集合提前攔截，後續規則便難以理解。可依「本機與私有網路、明確直連、明確代理、特定服務、位址規則、最終兜底」分段維護規則，並在每次變更後選擇幾個代表性目標驗證連線記錄。

策略組設計比堆疊規則更重要

常見策略組類型包括 select、url-test、fallback 與 load-balance。select 由使用者手動選擇；url-test 定期比較候選對外連線；fallback 依序選擇可用項目；load-balance 則在多個對外連線之間分配連線。自動測試不是適用於所有工作的通用解法：需要固定出口的登入工作階段較適合手動組，需要連續性的下載工作也不應頻繁切換。可以先建立「手動選擇」與「自動選擇」，再依工作、媒體、下載等用途建立上層組。

策略組可以引用其他策略組，形成分層結構，但層級過深會增加排錯成本。建議讓業務規則只引用少量穩定的頂層組，底層節點變化交由訂閱與自動組處理。刪除策略組前先全文搜尋其名稱，確認沒有規則、代理提供器或其他策略組繼續引用。自訂規則的完整修改方法可結合實際設定查閱站內使用文件；遷移至 mihomo 時，則可閱讀mihomo 核心功能與設定差異。

DNS 與 TUN：處理系統接管與網域解析

為什麼系統代理之外還需要 TUN

系統代理只會影響主動讀取代理設定的應用程式。遊戲、部分命令列工具、獨立更新程式與使用特殊網路堆疊的程式，可能直接建立連線。TUN 會建立虛擬網路介面，將符合路由條件的 IP 流量送入核心，因此涵蓋範圍更廣。但它也會帶來額外變數：管理員權限、路由表、DNS 劫持、虛擬網卡、其他 VPN 與安全軟體都可能影響結果。首次啟用 TUN 前，應先讓一般系統代理在 Rule 模式下穩定運作，再把 TUN 作為獨立階段測試。

啟用 TUN 後，如果所有網頁都無法存取，先檢查核心日誌中的虛擬介面是否建立成功，再檢查預設路由與 DNS。若只有區域網路裝置無法連線，應檢查私有位址是否繞過 TUN、路由是否保留本機網段，以及規則中是否將區域網路位址設為 DIRECT。若關閉 TUN 後網路沒有恢復，應退出用戶端並檢查系統是否仍保留虛擬介面或失效的代理設定。不要在故障狀態下反覆切換多個 VPN 工具，它們可能持續改寫同一套路由。

DNS 模式與請求路徑

DNS 決定網域如何轉換為位址，也會影響網域規則能否正確關聯到連線。若系統 DNS 在 Clash 之外完成，網域請求可能繞過既定的上游；若應用程式自行使用加密 DNS，核心可能只能看到目標位址。Clash 的 DNS 設定可指定監聽、啟用狀態、IPv6 行為、增強模式、預設解析器與上游伺服器。選擇上游時應兼顧可達性與用途，不應單純堆疊大量位址。設定越複雜，越需要記錄每組解析器負責的階段。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - "https://dns.alidns.com/dns-query"

fake-ip 模式會為網域回傳保留位址區段中的映射位址，讓核心在後續連線中保留網域關係，方便進行規則比對。某些區域網路服務、裝置探索、登入驗證或對解析結果有特殊要求的網域，可能不適合 fake-ip，需要加入過濾清單。過濾項目不應無限增加；每次增加前先確認故障確實由 fake-ip 映射造成，並記錄目標網域。若改用 redir-host，解析與連線行為會不同，切換後應清除系統與應用程式的 DNS 快取再比較。

TUN 設定的關鍵欄位

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

stack 決定 TUN 使用的網路堆疊實作，mixed 常用於兼顧不同流量；dns-hijack 將一般 53 連接埠的 DNS 請求交給核心；auto-route 自動寫入必要路由；auto-detect-interface 嘗試辨識目前的出口網卡。嚴格路由可以減少部分流量繞行，但也可能與虛擬機器、容器、區域網路共享及其他 VPN 衝突。調整這些欄位時應逐項測試，不要直接複製一份包含大量平台特定參數的設定。

在 Windows 上，TUN 通常需要提升權限或輔助服務；macOS 需要網路擴充功能或相應授權；Linux 需要存取 TUN 裝置與修改路由的能力；行動裝置通常透過系統 VPN 介面實現。同一份 YAML 在不同平台上不一定具備完全相同的權限條件。出現問題時，應將「設定語法正確」與「作業系統允許執行」分開檢查。

檢查解析是否按預期運作

DNS 排錯需要同時觀察系統端與核心端。先確認系統 DNS 請求是否進入 Clash，再查看核心選用了哪個上游、回傳了什麼類型的結果，最後查看目標連線命中了哪條規則。檢測網站的單次結果可能受到瀏覽器安全 DNS、快取、IPv6 與網路出口影響，不能只看單一結論。可更換瀏覽器、關閉瀏覽器獨立 DNS 後重新測試，並比較連線日誌。更完整的檢查路徑見Clash DNS 外洩檢測與防護設定。

日常維護：更新、備份、日誌與故障隔離

建立可回復的更新流程

用戶端、核心、訂閱與規則集是四種不同的更新對象，不應在同一時間全部更新。較穩妥的順序是先備份目前可用的設定，記錄主要策略組選擇；接著只更新訂閱並進行驗證；再依需求更新用戶端或核心；最後更新外部規則集。每個步驟都完成啟動、解析、連線與規則命中檢查。如此發生相容性問題時，就能明確判斷是哪一層發生變化，並回復到上一個可用狀態。

備份內容至少包括本機 Profile、覆寫規則、腳本、策略組命名，以及關鍵的 DNS/TUN 設定。訂閱網址本身只是更新來源，不能取代本機備份；遠端內容變更後，重新下載未必能恢復原本狀態。備份檔案應依用途與日期整理，並避免讓用戶端同時掃描多個重複副本，否則 Profile 清單會出現難以區分的設定。還原時先在不啟用系統代理與 TUN 的情況下，確認設定能否載入，再逐步恢復接管。

日誌等級與連線記錄

info 適合日常使用，可以看到啟動、設定載入與主要連線資訊；需要排查規則或網路細節時，可暫時提高日誌詳細程度，但長期保留大量詳細日誌會增加磁碟寫入與閱讀成本。排查日誌應圍繞時間點進行：記錄觸發問題的具體操作，接著在相同時間範圍內尋找 DNS、規則、策略與連線錯誤。只截取最後一行錯誤通常不夠，因為根因可能出現在更早的設定重新載入或介面建立階段。

連線記錄適合回答三個問題：請求是否進入核心、命中了什麼規則、最終使用了哪個對外連線。若沒有記錄，檢查系統代理、TUN 與應用程式本身的網路設定；若規則不符，檢查網域、位址與順序；若對外連線正確但連線失敗，檢查節點、目標服務與網路環境。對於間歇性問題，應記錄發生當下使用的網路、Profile、模式與策略組選擇，避免在重現前不斷切換設定。

常見故障的分層處理

連接埠衝突是最常見的啟動問題之一。修改連接埠前先確認佔用者；若佔用者是舊的 Clash 核心，應正常結束舊程序，而不是讓兩個執行個體使用不同連接埠長期共存。DNS 問題則經常表現為部分網站失敗、規則命中異常或切換網路後暫時恢復。此時要區分網域解析失敗、解析結果不符預期，以及連線至目標位址失敗，三種情況對應不同的處理層。

維持設定可讀且可遷移

策略組名稱應穩定、清晰，規則應依職責分段，外部規則集應記錄來源與用途。避免在同一份設定中保留大量已失效的節點、重複規則與未使用的策略組。每次整理後先用設定檢查或用戶端重新載入確認語法，再驗證幾個代表性目標。若準備遷移用戶端，應先關閉舊用戶端的系統代理與 TUN，匯出設定，再在新用戶端中匯入並檢查覆寫能力；不要直接複製整個應用程式資料目錄，因為不同用戶端的資料庫、快取與介面狀態未必相容。

日常使用中可保留一份「最小可用設定」作為診斷基準，只包含監聽連接埠、一個明確的對外連線、簡單策略組、區域網路直連與 MATCH。複雜設定發生故障時，先用最小設定確認用戶端與網路入口正常，再逐層加入 DNS、規則集與 TUN。這個方法比在數千行設定中隨機刪除欄位更可靠，也能協助判斷問題屬於基礎環境還是擴充設定。

進階路線：從穩定使用到可維護的設定體系

第一階段：固定基礎入口

進階設定的起點不是增加更多規則，而是讓基礎入口可預測。固定 mixed-port，明確是否允許區域網路存取，選定日常使用的 Rule 模式，並確保系統代理與 TUN 不會同時受到多個用戶端控制。建立一份最小 Profile，記錄設定目錄、用戶端名稱與核心類型。完成後應能清楚回答：請求從哪裡進入、目前使用哪一份設定、預設策略組是什麼，以及關閉用戶端後如何恢復系統網路。

這個階段還應建立測試方法。選擇一個區域網路位址、一個預期直連的目標，以及一個預期使用代理的目標，分別觀察連線記錄。測試時保持節點與網路不變，只調整一個參數。若基礎入口仍不穩定，不要急著加入遠端規則集、複雜 DNS 或程序規則，因為這些功能會增加觀察面向。

第二階段：重構策略組與規則

將節點層、選擇層與業務層分開。底層由訂閱提供節點，中層建立手動選擇、自動選擇與故障回退，上層依用途建立穩定策略，例如「預設出口」「工作服務」「下載任務」。業務規則只引用上層名稱。訂閱節點發生變化時，中上層結構不必重寫；需要臨時切換線路時，也只操作策略組，不修改規則檔案。

接著整理規則順序。先處理私有網路與明確例外，再放置業務規則集與網域規則，之後處理位址規則，最後使用 MATCH。每加入一個規則集，都記錄涵蓋範圍、更新頻率與目標策略。若兩個集合的範圍高度重疊，只保留職責較明確的一份。對於經常變動的例外，可維護獨立的小型本機規則區，並放在寬泛規則集之前。

第三階段：設定提供器與規則提供器

當節點與規則需要獨立更新時，可以使用代理提供器與規則提供器，將大段遠端內容從主設定中拆出。主設定保留連接埠、DNS、策略組與引用關係，提供器則按間隔更新外部檔案。拆分後更容易維護，但也增加了下載失敗、路徑權限與格式相容性等檢查項目。提供器更新失敗時，核心通常會嘗試使用快取，因此快取目錄必須可寫入，並應保留最近一次可用的內容。

rule-providers:
  local-service:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/local-service.yaml
    url: "https://example.invalid/rules/local-service.yaml"
    interval: 86400

rules:
  - RULE-SET,local-service,DIRECT
  - MATCH,代理選擇

範例網址是保留的測試網址，用於展示結構。實際使用時，規則檔案的行為類型必須與內容一致：domain 適合網域集合，ipcidr 適合位址區段，classical 支援完整規則表達式。路徑應位於核心可寫入的工作目錄中。提供器名稱同樣屬於穩定介面，修改後要同步調整所有 RULE-SET 引用。

第四階段：依平台處理程序與區域網路

程序規則依賴作業系統與核心取得程序資訊的能力，不同平台的支援程度可能不同。使用前先在連線記錄中確認能否看到程序名稱，再撰寫 PROCESS-NAME 規則。程序路徑、應用程式商店封裝與子程序都可能影響比對，不能只根據介面顯示名稱猜測。行動裝置更適合使用用戶端提供的分應用程式代理介面，因為系統權限與應用程式識別碼由用戶端直接處理。

區域網路共享需要同時考慮 allow-lan、監聽位址、防火牆與存取控制。只開啟 allow-lan 不代表其他裝置一定能存取，本機防火牆可能仍會阻擋連接埠；反過來，監聽所有介面也會擴大可存取範圍。若只供本機使用，請維持關閉區域網路存取。確有共享需求時，應限制在可信任的網路，並明確其他裝置使用的本機區域網路位址與連接埠。在 TUN 下還要保留私有網段直連，避免印表機、儲存裝置與開發服務被送往代理。

第五階段：建立變更記錄與驗證清單

長期維護的設定需要簡單的變更記錄。每次修改寫明目的、欄位、驗證目標與回退方式。例如「為某個完整網域增加直連例外，放在對應後綴規則之前；驗證首頁與下載介面；異常時刪除該行並重新載入」。這種記錄比只儲存多份沒有說明的副本更有價值。發生問題時，可以沿著變更順序定位，而不必重新閱讀整份設定。

最終驗證清單應涵蓋：用戶端啟動、Profile 載入、系統代理、TUN、DNS、區域網路、直連目標、代理目標、策略組切換、訂閱更新與規則集更新。並非每次小幅修改都要執行全部項目，但涉及入口、DNS 或 TUN 的變更應完成完整檢查。測試後查看日誌中是否存在持續重試、解析失敗或介面錯誤；即使表面存取正常，也應處理重複錯誤，避免在後續網路切換時集中暴露。

繼續查閱與實作順序

完成本手冊後，可以依實際需求選擇下一步。需要盡快建立基礎連線，回到使用文件複核最短流程；需要更換用戶端，前往平台下載入口核對架構與系統需求；出現連接埠錯誤時查看監聽連接埠排查；DNS 結果異常時查看DNS 檢測與修正；管理多份設定時查看Profile 管理方法；遷移舊設定時查看mihomo 設定差異。

從零到穩定使用的關鍵，不是一次寫出複雜設定，而是分層推進：先讓用戶端與核心穩定啟動，再建立可更新的 Profile；先理解 Rule、Global 與 Direct，再撰寫自訂規則；先讓系統代理運作，再啟用 TUN；先確認 DNS 請求路徑，再調整增強模式；最後才引入提供器、程序規則與自動化維護。每完成一層都保留可回退狀態，設定體系就能在用戶端、訂閱與網路環境變化時持續維護。