Clash 從零到進階完整使用指南

一、核心概念：先區分用戶端、核心與訂閱

三個組成部分各司其職

日常所說的「Clash」可能指圖形化用戶端、代理核心，也可能泛指相容於 Clash 設定格式的一組工具。開始操作前，先將三者分開：用戶端提供視窗、系統匣選單、設定管理與系統權限入口；核心讀取設定、監聽本機連接埠、執行規則並建立網路連線；訂閱服務提供伺服器資訊、策略組與規則內容。安裝用戶端不會自動取得可用線路，匯入訂閱也不代表應用程式流量已經經過代理。

例如 Clash Plus、Clash Verge Rev、FlClash 與 Clash Nyanpasu 都屬於具備圖形介面的用戶端。用戶端可能整合 mihomo 等核心，也可能允許切換核心。mihomo 與過去使用的 Clash Meta 名稱具有沿革關係，負責識別設定欄位、處理 DNS、執行規則與 TUN。介面上的開關最終會轉換為核心參數或作業系統網路設定，因此同一功能在不同用戶端中的名稱與位置可能不同，實際判斷應以產生的設定與核心日誌為準。

訂閱則是獨立來源。訂閱網址通常由使用者選用的服務提供，本網站與用戶端專案都不會因安裝完成而自動提供訂閱。一份訂閱可能包含節點、代理策略組、遠端規則集與 DNS 設定，也可能只包含最基本的節點清單。遇到「用戶端能開啟但沒有可選策略」時，應先確認訂閱內容是否完整，而不是反覆重新安裝用戶端。

從應用程式到出口的基本流量路徑

在系統代理情境下，應用程式讀取作業系統的 HTTP 或 SOCKS 代理設定，將請求交給用戶端監聽的本機連接埠。核心接著依設定模式處理請求：規則模式由上到下檢查規則，第一個符合項目決定使用 DIRECT、REJECT 或某個策略組；全域模式通常會將大多數可代理流量交給指定策略組；直連模式則讓支援的流量直接存取目標。TUN 模式會建立虛擬網路介面，在更接近網路層的位置接管流量，但仍須經過 DNS、路由與規則判定。

因此，「用戶端已啟動」、「本機連接埠正在監聽」、「系統代理已啟用」、「目標應用程式確實採用系統代理」、「規則選擇了可用出口」是五種不同狀態。瀏覽器能存取某個頁面，只能說明瀏覽器目前的路徑成立，不能證明終端機、遊戲或虛擬機器也使用相同路徑。排查時應依序確認應用程式設定、作業系統代理、本機監聽連接埠、核心規則與遠端連線，不應只觀察用戶端主畫面上的單一狀態標記。

建立可驗證的最小認知

首次使用不必立刻修改大量 YAML。先完成一個最小閉環：安裝適合平台的用戶端，匯入來源明確的訂閱，選擇設定與策略組，啟用一種流量接管方式，再分別以瀏覽器與終端機驗證。完成閉環後再學習規則覆寫、DNS 與 TUN，可避免同時引入多個變數。之後每次修改也遵循相同原則：一次只改一層，保留修改前的設定，並記錄變更後出現的日誌或存取結果。

二、選擇用戶端：依平台與維護方式判斷

先選操作入口，再考慮進階能力

選擇用戶端應從作業系統、安裝方式與日常維護習慣出發，而不是將不同專案當成單純的效能排名。初次使用者可優先選擇 Clash Plus，涵蓋常見桌面與行動平台，適合透過圖形介面完成訂閱管理、策略選擇與連線控制。需要在 Windows、macOS 或 Linux 上管理多份設定時，也可以比較 Clash Verge Rev 與 FlClash；Windows 使用者還可考慮 Clash Nyanpasu。已停止維護的用戶端可能仍能執行，但不適合依賴持續相容更新的新環境。

Android 平台除了 Clash Plus 外，也可依裝置架構與操作習慣考慮 Clash Meta for Android、FlClash 或 Surfboard。iOS 的主要入口是 Clash Plus。Linux 桌面使用者可選擇 Clash Verge Rev 或 FlClash；伺服器、路由器與無桌面環境則更適合直接部署 mihomo 核心。完整的平台入口與目前安裝套件應從下載頁進入，避免將桌面用戶端的安裝步驟套用到命令列核心。

核對系統架構與套件格式

Windows 常見裝置使用 x64 架構，應依下載頁實際提供的建置版本選擇安裝套件。macOS 需要區分 Apple Silicon 與 Intel：在「關於這台 Mac」中查看晶片或處理器資訊，Apple 晶片選擇 ARM 建置版本，Intel 處理器選擇 x64 建置版本。Android 可在裝置資訊或可靠的硬體資訊頁面確認 ARM64、ARM 或通用套件；大多數較新的裝置使用 ARM64，但不能只憑系統版本推斷。

Linux 還要配合發行版的套件管理方式。Debian、Ubuntu 及其衍生系統通常使用 .deb，Fedora、RHEL 系列通常使用 .rpm。若使用獨立核心壓縮套件，需要自行準備設定目錄、服務檔案與更新流程。圖形化用戶端與裸核心的差別不只是有沒有視窗：前者往往代為處理權限申請、寫入系統代理與核心生命週期，後者要求使用者明確管理啟動使用者、工作目錄、日誌與重新啟動策略。

評估功能時查看實際工作流程

如果只需要讓瀏覽器與一般桌面應用程式使用代理，穩定的系統代理控制與訂閱更新比複雜的覆寫功能更重要。如果需要接管不讀取系統代理的應用程式，應確認用戶端對 TUN、權限安裝與路由復原的支援。如果經常維護多份訂閱，則要檢查設定切換、覆寫、訂閱更新與備份入口是否清楚。不要因介面出現某個開關，就假定目前核心支援所有欄位；進階設定能力最終會同時受核心版本、設定格式與作業系統限制。

選型完成的標準不是找到功能最多的用戶端，而是確認安裝套件與平台相符、常用入口容易理解、訂閱可維護、發生故障時能查看日誌。若仍難以判斷，可閱讀依平台與使用習慣選擇用戶端，再回到下載頁完成安裝。

三、安裝與權限：建立可復原的執行環境

桌面系統的安裝順序

安裝前先退出同類代理程式，記錄目前的系統代理設定，並確認安裝套件與系統架構一致。Windows 安裝後首次執行時，防火牆可能詢問網路存取範圍；只為實際需要的網路類型授權，不必為了本機代理監聽而開放公網入站連線。若用戶端提供「服務模式」或輔助服務，通常是用來取得修改路由、執行 TUN 或隨系統啟動所需的權限，應從用戶端內建入口安裝，不要從未知來源單獨取得服務元件。

macOS 將應用程式放入「應用程式」資料夾後再首次啟動，避免長期從下載目錄執行而導致路徑與權限記錄變動。系統可能依序出現應用程式安全性確認、網路延伸功能、VPN 設定或鑰匙圈存取提示，這些提示對應不同能力：VPN 設定通常與 TUN 或 Network Extension 有關；鑰匙圈提示可能用於儲存憑證；網路延伸功能用於接管網路流量。應依準備使用的功能授權，而不是把所有提示都視為同一種安裝錯誤。具體處理方式可參考macOS 權限說明。

Linux 圖形化用戶端透過發行版套件安裝後，應從桌面選單啟動一次，並觀察日誌目錄是否可寫入。使用 .deb 檔案時，可以在檔案所在目錄執行：

sudo apt install ./client-package.deb

上方的檔案名稱應替換為已下載的實際套件名稱。套件管理器會解析相依性，通常比直接呼叫底層安裝命令更容易處理缺少的元件。RPM 系統應使用對應發行版的套件管理命令。無桌面環境部署 mihomo 時，不應照搬圖形化用戶端的目錄；需要另外建立設定目錄、決定執行帳號，並限制控制連接埠的可存取範圍。

行動平台的系統授權

Android 與 iOS 通常透過系統 VPN 介面接管流量。首次連線時出現的 VPN 授權，是作業系統建立虛擬網路通道所需的步驟，不代表訂閱已驗證成功。Android 還應檢查電池最佳化與背景活動策略：若用戶端在鎖定螢幕後被系統停止，連線會中斷或無法依計畫更新。允許必要的背景執行後，再觀察不同網路之間切換時能否復原，不要一開始就同時啟用常駐 VPN、依應用程式分流與複雜 DNS 覆寫。

部分 Android 系統允許設定「永遠開啟的 VPN」或限制未經 VPN 的連線。啟用這些系統層級選項前，先確認用戶端能在一般模式下穩定連線，並準備好關閉入口。否則當訂閱失效或 DNS 設定錯誤時，裝置可能表現為所有應用程式都無法連網，而使用者又難以分辨是代理失敗，還是系統強制策略仍在生效。

首次啟動後的基準檢查

安裝完成後先不要啟用 TUN。開啟用戶端日誌或執行狀態頁，確認核心能夠啟動、設定目錄可讀寫、本機監聽連接埠沒有衝突。常見監聽包括 HTTP、SOCKS 或 mixed 連接埠，具體數值以目前設定為準。如果日誌出現「address already in use」之類的訊息，表示連接埠已被其他程序佔用，應關閉舊代理程式或調整連接埠，而不是反覆點擊連線。

接著檢查退出行為。關閉視窗可能只是隱藏到系統匣，真正退出需要使用系統匣選單；卸載或切換用戶端前，應先關閉系統代理與 TUN，再退出核心。如此可讓用戶端恢復路由與系統代理狀態。若發生異常退出，可進入作業系統網路設定，手動確認代理位址是否仍指向本機連接埠，並檢查是否殘留虛擬網路介面。

無桌面 Linux 的服務化原則

在伺服器上執行 mihomo 時，應先以前景方式載入設定並閱讀錯誤訊息，確認無誤後再交給 systemd。服務檔案應指定明確的執行檔、工作目錄與設定目錄，並使用具備最低必要權限的帳號。若設定中啟用外部控制介面，監聽位址應優先限制在本機；確實需要遠端管理時，應透過受控網路與存取控制提供入口。更完整的桌面與服務部署差異可查看Linux 部署說明。

四、訂閱設定：匯入、選擇、更新與覆寫

匯入只是取得設定

訂閱網址通常會回傳一份用戶端可讀取的設定或節點集合。匯入時，在用戶端的設定、訂閱或 Profiles 頁面選擇「從 URL 匯入」，貼上來源明確的網址，等待用戶端下載並解析。匯入成功後，還要將該設定設為目前使用的設定，再檢查策略組是否有可選項目。若設定清單中出現名稱，但切換後核心報錯，應查看解析日誌，定位具體欄位，而不是把「下載成功」當成「設定可執行」。

訂閱網址可能具備存取權限，應視為敏感資訊，不應放入公開截圖、日誌分享頁或問題討論區。需要排查時，可以隱藏網址與節點憑證，只保留錯誤欄位、規則結構與相關日誌。若網址失效、回傳登入頁面或遭網路重新導向，用戶端可能回報 YAML 解析錯誤；此時先透過服務商提供的管理入口確認訂閱狀態，不要任意修改解析失敗的回應內容。

理解完整設定的主要結構

一份常見設定會包含監聽連接埠、執行模式、DNS、節點、策略組與規則。以下片段展示最小結構關係，其中伺服器位址與驗證內容僅為範例，不能直接用於連線：

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

proxies:
  - name: Example-Node
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: demo-user
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

mixed-port 同時接受常見的 HTTP 與 SOCKS 代理請求；mode: rule 表示依規則進行判定；proxy-groups 定義名為 PROXY 的策略組；最後一條 MATCH 接收前面沒有符合的流量。這裡的 PROXY 並不是核心自動產生的出口，刪除策略組卻保留 MATCH 會產生引用錯誤。no-resolve 表示處理該 IP 規則時，不主動為了符合規則而解析網域，並不等於關閉全部 DNS。

更新訂閱前區分遠端內容與本機修改

直接編輯訂閱產生的設定通常只能暫時生效。下次更新時，用戶端會以遠端內容覆蓋本機副本，手動加入的規則、DNS 或策略組選項可能消失。需要長期保留的修改，應優先使用用戶端提供的覆寫、合併或腳本機制；如果用戶端沒有穩定的覆寫功能，就將修改後的設定儲存為獨立本機檔案，並接受它不會自動隨訂閱更新的維護成本。

更新前記錄目前可用的設定、策略組選擇與關鍵覆寫。更新完成後先檢查設定能否解析，再確認節點清單與策略組引用，最後恢復流量接管。不要在連線異常時連續觸發多次更新，因為伺服器回應、網路快取與用戶端寫入檔案可能同時變動，反而難以判斷是哪一次內容造成錯誤。訂閱頻率也不宜無依據地設得過短，應採用服務商允許的合理間隔。

設定驗證要分三個層次

語法驗證只表示 YAML 能被解析；引用驗證還要確認策略組、節點與規則目標都存在；執行驗證則檢查連接埠、DNS、權限與遠端連線。用戶端提示「設定有效」後仍無法存取並不矛盾，因為它可能只完成前兩層。儲存修改後應重新載入設定並閱讀第一段日誌，先處理最早出現的錯誤。更多訂閱匯入的常見問題，可在幫助中心按「安裝設定」分類尋找。

五、代理模式：規則、全域與直連的作用界線

模式決定核心如何選擇去向

規則模式、全域模式與直連模式，是核心處理已進入代理鏈路流量的方式，不等同於系統代理、TUN 或 VPN 開關。系統代理與 TUN 決定哪些流量有機會進入核心，執行模式再決定這些流量使用哪個出口。將模式切換為全域，並不能讓完全不讀取系統代理的程式自動進入核心；同樣地，啟用 TUN 後選擇直連模式，流量可能經過虛擬介面與核心判斷，最後仍從本地網路直連。

規則模式通常適合日常使用。核心依規則清單由上到下檢查目標網域、IP、連接埠或規則集，第一個命中後停止繼續判定。規則可以指向 DIRECT、REJECT 或自訂策略組。規則品質會直接影響結果：過於寬泛的規則放在前面，可能遮蔽後方的精細規則；缺少兜底規則則可能導致不同設定產生難以預測的行為。

全域模式用於暫時判斷規則是否造成存取問題，或在明確需要統一出口的短時間情境使用。進入全域模式後，用戶端通常會要求選擇全域策略組或節點。排查時若全域模式可用而規則模式失敗，應檢查目標命中了哪條規則、策略組是否可用，而不是立即認定節點本身失效。長期使用全域模式會繞過原有的分流意圖，也可能讓區域網路或本應直連的資源走向錯誤出口。

直連模式可用於快速恢復本地網路、比較代理前後結果，或在保留用戶端執行的同時暫時停止代理轉送。它不是退出用戶端的替代方式：系統代理仍可能指向本機連接埠，TUN 仍可能保留介面與路由，只是核心選擇 DIRECT。維護或卸載前應關閉流量接管並退出核心，而不是只切換到直連。

系統代理適合遵循代理設定的應用程式

啟用系統代理後，用戶端通常會將作業系統代理位址設定為回送位址與本機連接埠，例如 127.0.0.1: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://example.com

連接埠必須與用戶端目前的監聽設定一致。只為目前的終端機工作階段設定變數，方便進行測試；確認結果後，再決定是否寫入 shell 設定。使用 sudo、容器或遠端工作階段時，環境變數可能不會自動繼承。本機回送位址在容器內通常指向容器本身，不能直接照搬主機位址。

用對照實驗確定問題所在層級

可靠的模式測試應保持節點與接管方式不變，只切換一個變數。先在規則模式中記錄目標命中的規則，再切換到全域模式並選擇同一個實際出口。如果兩者都失敗，應查看本機連接埠、DNS、節點連線與系統時間；如果只有規則模式失敗，檢查規則順序與策略組；如果瀏覽器成功而終端機失敗，檢查應用程式代理設定。詳細的分層方法可參考瀏覽器與終端機代理排查。

六、規則分流：由上到下理解匹配與策略組

第一條匹配規則決定結果

規則分流的核心不是規則數量，而是順序、匹配條件與目標策略是否一致。核心從清單頂端開始檢查，請求命中一條後通常不會繼續。一條寬泛的網域後綴規則若放在前面，會覆蓋後方針對特定子網域的規則；大範圍 IP 規則也可能搶先處理原本希望交給其他策略組的位址。因此，自訂規則應由具體到寬泛排列，最後由 MATCH 或同等兜底規則接收未匹配流量。

rules:
  - DOMAIN,blocked.example,REJECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

DOMAIN 匹配完整網域，適合單一主機；DOMAIN-SUFFIX 匹配指定網域及其子網域；IP-CIDR 依位址範圍匹配；MATCH 作為兜底。上例會先拒絕指定網域，再讓 example.org 及其子網域直連，讓私有位址範圍直連，其他請求交給 PROXY。PROXY 必須是已定義的策略組名稱；若實際設定使用「節點選擇」等其他名稱，規則目標也必須完全一致。

策略組負責將規則結果轉為可選出口

規則通常不會直接綁定某個固定節點，而是指向策略組。select 組讓使用者手動選擇；其他組類型可能依可用性或預設邏輯選擇成員，具體支援取決於核心。策略組可以包含節點、DIRECT 或其他策略組，但巢狀關係應保持清楚，避免多個組互相引用。修改組名時，要同步檢查所有規則與其他策略組中的引用。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Example-Node
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Example-Node
      - Backup-Node
    url: https://www.gstatic.com/generate_204
    interval: 300

這個範例說明結構關係，並不代表任何訂閱一定包含相同節點。url-test 會依指定 URL 進行可用性測試，測試結果只反映該探測目標與當時的網路條件，不能取代對實際業務目標的驗證。測試間隔過短會增加連線與日誌負擔。對於重要存取，應優先選擇行為容易理解的策略組，發生問題時確認目前組別最後選中了哪個成員。

網域規則與 IP 規則會受到 DNS 路徑影響

網域請求進入核心後，可以直接參與 DOMAIN 類規則；當應用程式只提交目標 IP，或規則需要依 IP 判斷時，DNS 解析與連線階段的位址資訊會影響匹配。no-resolve 用於阻止某條 IP 規則為了匹配網域而主動觸發解析，有助於減少不必要的 DNS 查詢，但不會關閉設定中的 DNS 服務。若同時使用 fake-ip、網域嗅探或複雜 DNS 分流，應先理解用戶端產生的完整設定，再新增規則。

區域網路位址一般應在寬泛的代理規則之前處理，避免存取路由器、印表機或本地服務時被交給遠端出口。常見私有位址包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16，但企業網路可能使用更多內部網域與位址範圍。不要機械式複製公共規則集後就假定適用於目前網路，應依實際內網範圍補充並測試。

遠端規則集與本機規則各有維護成本

遠端規則集便於集中更新，但可用性取決於下載網址、格式與更新策略。本機規則較容易稽核，卻需要自行維護。採用遠端規則集時，應查看它處理的類別、預設出口以及更新失敗時的行為；採用本機規則時，應為每組規則寫清用途，並避免堆積重複項目。規則越多不代表分流越精準，過期網域、重疊範圍與無法到達的規則都會增加排查成本。

調整規則的安全流程是：複製目前設定，新增一條具體規則，重新載入並測試目標，同時測試一個不應受影響的目標。確認無誤後再繼續。若訂閱更新會覆蓋規則，應將修改移至用戶端的覆寫層，並記錄規則需要位於遠端規則之前或之後。

七、TUN 模式：接管範圍、DNS 與路由排查

TUN 解決的是流量進入核心的問題

TUN 模式透過虛擬網路介面與系統路由接管更多 IP 流量，適合不讀取系統代理的應用程式、部分命令列工具及需要統一接管的情境。它不會提升節點本身的連線品質，也不會取代規則與策略組。流量進入 TUN 後，仍須經過 DNS 解析、路由判斷、規則判定與出口連線。若規則指向 DIRECT，最後仍可直連；若設定或權限錯誤，影響範圍可能比系統代理更廣。

首次啟用前，先在系統代理模式下確認訂閱、節點與規則基本可用，再關閉其他 VPN、代理或網路過濾工具，記錄目前的 DNS 與預設路由。用戶端可能要求安裝服務、授權 VPN 設定或啟用網路延伸功能，應從正式介面完成。啟用後先測試區域網路位址、常用網域與一個不使用系統代理的程式，確認三類路徑都符合預期，再考慮開機啟動或永遠開啟。

常見設定欄位的作用

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

auto-route 讓核心嘗試寫入必要路由，auto-detect-interface 用於識別目前的出站介面，dns-hijack 指示接管指定的 DNS 流量。stack 的可用值與行為受核心及平台影響，不應脫離目前用戶端文件盲目切換。範例中的公共 DNS 僅用於說明欄位結構，實際選擇應結合網路可達性、隱私要求與訂閱設定。若訂閱已提供完整 DNS 區段，不要同時疊加另一套未經驗證的覆寫。

fake-ip 會為網域回傳保留範圍內的對映位址，再由核心還原網域並套用規則。它有助於保留網域資訊，但某些區域網路服務、需要真實位址的應用程式或特殊協定可能需要加入過濾範圍。出現區域網路裝置無法探索、應用程式識別到異常位址時，應先檢查 fake-ip 過濾與區域網路直連，而不是立即關閉所有 DNS 功能。

路由衝突比節點問題更常見

同時執行企業 VPN、虛擬機器網路、容器網路或另一款代理程式時，各工具可能爭用預設路由、DNS 或虛擬介面。表現包括啟用 TUN 後完全斷網、只有內網失效、休眠恢復後無法連線、切換 Wi-Fi 後流量仍經過舊介面。排查時先關閉其他接管工具，關閉 TUN 並確認基礎網路恢復，再單獨啟用 Clash。若單獨執行正常，再逐一恢復其他工具，觀察衝突出現的時點。

Windows 可查看路由表與網路介面卡，macOS 可檢查網路服務與 VPN 設定，Linux 可使用系統命令檢查路由與規則。診斷重點不是複製全部輸出，而是比較啟用前後的預設路由、DNS 指向與新增介面。Linux 常用檢查命令如下：

ip addr
ip route
ip rule
ss -lntup
resolvectl status

不同發行版可能不提供所有命令。ss 可確認本機連接埠，ip route 與 ip rule 用於觀察路由，resolvectl 適用於採用 systemd-resolved 的環境。不要在不了解用途時批次刪除路由規則；先關閉用戶端讓它執行清理，再重新啟動網路服務或系統，最後才考慮手動恢復。

DNS 故障要區分解析與連線

能存取 IP、不能存取網域時，通常應優先檢查 DNS；網域能解析但連線失敗，則繼續檢查規則、出口與防火牆。可使用 nslookup、dig 或系統內建解析工具，比較系統解析結果與用戶端日誌。若日誌中完全沒有目標請求，問題可能發生在應用程式、系統路由或 DNS 到達核心之前；若能看到請求但策略錯誤，則回到規則與 DNS 設定檢查。

判斷 TUN 是否穩定執行，應涵蓋啟動、關閉、休眠恢復、網路切換與區域網路存取。只有一次網頁存取成功，不足以證明路由清理與 DNS 恢復正常。行動裝置還應測試背景與鎖定螢幕行為，桌面系統則要驗證退出用戶端後代理與路由沒有殘留。

八、日常維護：更新、備份、日誌與故障復原

分開更新用戶端、核心與訂閱

用戶端更新、核心更新與訂閱更新是三條不同的鏈路。用戶端更新可能改變介面、權限輔助元件與設定儲存方式；核心更新可能改變欄位支援、預設行為與協定能力；訂閱更新會改變節點、策略組與規則。日常維護應記錄是哪一層發生變化，避免同一天同時更新三層後無法定位回歸問題。穩定使用時，可以先備份設定，再更新訂閱並驗證；需要更新用戶端或核心時，則單獨安排一次測試。

更新前儲存訂閱網址、目前的策略選擇、本機覆寫與重要自訂規則。僅複製訂閱產生的 YAML 還不夠，因為用戶端可能將覆寫、策略選擇與介面設定放在其他檔案或資料庫中。優先使用用戶端提供的匯出功能；沒有匯出功能時，分別記錄可重建的資訊。備份應放在用戶端資料目錄之外，避免卸載或清理快取時一併刪除。

日誌應圍繞一次可重現的操作閱讀

有效的日誌需要明確的時間範圍與觸發動作。先將日誌層級設為一般資訊等級，清除或記住目前時間，然後執行一次失敗操作，立即查看對應片段。重點尋找設定載入、DNS 查詢、規則匹配、策略選擇、建立連線與逾時資訊。長期開啟過於詳細的除錯層級會產生大量記錄，也可能包含目標網域等使用資訊，應只在排查期間啟用，完成後恢復。

分享日誌前應移除訂閱網址、驗證欄位、控制介面憑證與節點連線資訊。保留錯誤類型、目標類別、規則名稱與必要上下文即可。單獨截取最後一行往往會遺漏真正原因，例如連線失敗可能是前面更早的 DNS 錯誤觸發。排查時優先處理時間順序上的第一個異常，而不是日誌中重複次數最多的後續錯誤。

建立分層復原順序

遇到無法連網時，先恢復基礎網路，再恢復代理。關閉 TUN、關閉系統代理，切換到直連或完全退出用戶端，確認作業系統能正常解析與存取。基礎網路恢復後，啟動用戶端但暫不開啟接管，確認設定載入與本機連接埠；接著啟用系統代理並測試瀏覽器；最後才啟用 TUN。這個順序能將權限、設定、節點與路由問題拆開。

若只有某個網站或應用程式失敗，先不要重新安裝。比較同一目標在直連、規則與全域模式下的結果，檢查日誌中的命中規則，再確認應用程式是否有獨立代理設定。若所有節點同時失敗，檢查訂閱狀態、系統時間、DNS 與目前網路限制；若只有一個節點失敗，切換同一策略組中的其他成員，將問題限定在該出口。常見問答可繼續查閱幫助中心。

清理設定時要保留回復點

設定長期累積後，重複訂閱、失效覆寫與舊規則可能互相影響。清理時先複製目前可用的設定，然後停用而不是立即刪除可疑項目。確認一段時間沒有依賴後再移除。不要一次刪除用戶端快取、設定資料庫與核心目錄，因為這會同時遺失故障證據與可回復狀態。若確實需要重設，先匯出必要內容，再從最小設定開始驗證。

對於已停止維護的用戶端，維護重點是遷移，而不是繼續堆疊臨時修補。先選擇仍在維護且支援目前平台的用戶端，匯入原訂閱，確認基本連線後，再遷移本機規則與 TUN 設定。不要直接覆蓋舊用戶端目錄，也不要讓兩個用戶端同時控制系統代理或路由。遷移完成後，關閉舊用戶端的開機啟動，並確認系統只保留一條明確的接管鏈路。

九、進階路線：從會使用到能獨立診斷

先掌握設定讀取，再學習複雜覆寫

進階的第一步不是收集更多設定片段，而是能讀懂目前生效的設定。應能找到監聽連接埠、執行模式、DNS、策略組、規則與 TUN 區段，並回答請求從哪個入口進入、命中哪條規則、使用哪個策略組、最後選擇什麼出口。當用戶端介面隱藏部分預設值時，可以查看匯出的設定或核心日誌，但除非清楚知道何時會被覆蓋，不要直接編輯程式自動產生的檔案。

第二步是建立可維護的覆寫層。將區域網路直連、特定網域策略、DNS 例外與策略組調整分成獨立目的，每次只加入一組。規則名稱與註解應描述原因，而不是只寫臨時編號。訂閱更新後自動合併的內容要檢查插入位置，因為同一條規則放在清單頂端與末端可能得到完全不同的結果。若用戶端支援 YAML 合併，應確認陣列是追加、置前還是整體替換。

理解 mihomo 的能力與設定相容邊界

mihomo 在 Clash 設定生態的基礎上擴充了協定、DNS、規則與執行能力，但具體欄位仍受目前核心建置版本與用戶端整合方式影響。遷移舊設定時，應先使用目標核心進行語法檢查，再核對已棄用欄位、規則提供程式、DNS 增強模式與策略組行為。不要僅憑檔案副檔名相同，就認為設定可以直接互換。相關背景可閱讀mihomo 與原版 Clash 的差異說明。

伺服器與路由器部署還涉及執行使用者、網路命名空間、防火牆轉送與持久化路由。桌面端的「啟用 TUN」按鈕往往代為完成權限與路由操作，裸核心則需要部署者明確負責這些工作。進階部署前，應先在一般使用者空間驗證設定載入、DNS 與代理連接埠，再逐步加入透明接管與開機服務，避免將設定問題與系統網路問題疊加。

用最小重現取代大範圍試錯

遇到複雜問題時，複製一份設定並縮減到一個入口、一個可驗證節點、一個策略組與少量規則。確認最小設定可執行後，再逐段恢復 DNS、規則集、TUN 與覆寫。每恢復一段就執行固定測試：設定載入、網域解析、直連目標、代理目標、區域網路目標與關閉後的網路恢復。如此可以將故障定位到具體設定區塊。

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

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

這段內容僅用於驗證核心結構與本機監聽，不包含可用的代理節點。由於 PROXY 組只包含 DIRECT，所有兜底流量最後都會直連。在加入真實訂閱節點前，先確認設定能載入、連接埠能監聽且規則日誌可見，再逐步新增節點。如此即使連線失敗，也能確定問題不是 YAML 結構或本機連接埠造成。

建立固定的診斷工具箱

桌面與伺服器都應掌握幾類基礎工具：查看監聽連接埠、解析網域、發起 HTTP 請求、檢查路由、查看程序與讀取服務日誌。Windows 可使用系統網路命令與 PowerShell，macOS 和 Linux 可使用 curl、dig 或 nslookup、netstat 或 ss。工具的價值在於回答明確問題，例如「7890 是否正在監聽」、「網域解析到什麼位址」、「請求是否採用代理」，而不是一次匯出所有系統資訊。

診斷時為每項測試寫下預期結果。存取區域網路位址預期為 DIRECT，存取測試網域預期使用某個策略組，關閉用戶端後預期系統代理已清除。實際結果與預期不同時，再查看對應層的日誌。沒有預期的測試容易陷入「網頁能開就是正常」的模糊判斷，也無法發現本應直連的流量被錯誤代理。

建立可持續的學習順序

完成本指南後，可以依「設定結構—規則順序—DNS 路徑—TUN 路由—服務化部署」的順序繼續深入。每個階段都應保留一份可工作的基準設定，並將實驗內容放在副本中。先理解單機請求路徑，再研究遠端規則集、複雜策略組與路由器透明代理；先學會恢復網路，再啟用開機自動接管。

當問題涉及特定平台權限時，回到安裝章節；涉及單一應用程式未生效時，回到代理模式章節；涉及目標走錯出口時，回到規則章節；涉及啟用後整體斷網時，回到 TUN 與 DNS 章節。若只需要重新完成一次基礎連線，可轉到快速教學；若需要更換用戶端或重新下載安裝套件，使用用戶端下載頁。這種按層回查的方式，比反覆重新安裝更容易保留證據並得到可重現的結果。