Clash 從入門到精通使用手冊

先了解 Clash 的核心概念與流量路徑

客戶端、核心與設定檔並非同一層

日常所說的 Clash，往往同時指三類物件。第一類是具備圖形介面的客戶端，例如 Clash Plus、Clash Verge Rev、FlClash 與 Clash Nyanpasu；它們負責設定管理、系統匣選單、系統代理開關、服務安裝與日誌顯示。第二類是處理網路連線的核心，目前常見客戶端多使用 mihomo，核心負責監聽連接埠、解析規則、選擇策略、建立代理連線以及處理 DNS。第三類是 YAML 設定檔，其中描述連接埠、節點、策略組、規則與 DNS 行為。

這三個層次必須分開判斷。介面能開啟，只能表示客戶端程式已啟動；核心顯示運作，才表示本機代理連接埠已開始監聽；瀏覽器能存取目標網站，還要求系統流量確實進入該連接埠、規則選到有效策略、節點連線成功且 DNS 解析正常。許多「Clash 已啟動但沒有網路」的問題，實際發生在核心之後的某一層，而不是安裝程式本身。

設定檔也不等同於訂閱。訂閱網址通常由服務提供者產生，客戶端存取該網址後取得一份設定內容，再將其儲存為本機設定。單一節點連結只描述一台伺服器，並不會天然包含完整的策略組與分流規則；本機 YAML 檔案則是已成形的設定，可直接匯入，但之後是否自動更新取決於客戶端的管理方式。需要進一步辨識格式時，可參閱訂閱連結、YAML 設定與常見匯入格式說明。

從應用程式請求到最終出口的完整鏈路

以瀏覽器存取 HTTPS 網站為例，網域名稱首先需要解析為位址。接著瀏覽器建立 TCP 或 QUIC 連線，系統依照代理設定或虛擬網卡路由，將連線交給 Clash。核心讀取目標網域、目標位址、連接埠與程序等資訊，由上到下比對規則；命中規則後，將請求交給對應的策略組。策略組可能直接選取某個節點，也可能繼續引用另一個群組，最後得到「代理」「直連」或「拒絕」等動作。

因此，排查時應依照鏈路順序觀察：應用程式是否遵循系統代理，或流量是否由 TUN 接管；本機監聽連接埠是否存在；網域是否正確解析；規則是否命中預期項目；策略組是否選到可用出口；遠端節點是否能建立連線。跳過中間層而反覆更換節點，可能暫時掩蓋問題，卻無法解決錯誤的系統代理、DNS 或規則設定。

選擇客戶端並完成各平台安裝

先依平台與接管需求選擇

圖形客戶端的核心作用不是改變訂閱內容，而是降低設定管理與系統接管的複雜度。本網站的下載清單中，Clash Plus 是 Windows、macOS、Android 與 iOS 的首選入口，適合希望在多個常用平台維持相近操作流程的使用者。Windows 和 macOS 也可選擇 Clash Verge Rev、FlClash；Windows 可使用 Clash Nyanpasu，並保留已停止維護的 Clash for Windows 封存入口；macOS 另有已停止維護的 ClashX Meta。Android 可選擇 Clash Meta for Android、FlClash 或 Surfboard，Linux 桌面則可選擇 Clash Verge Rev 與 FlClash。

選擇時不要只看介面外觀。需要重點確認的是：目前系統架構是否有對應安裝包、客戶端是否支援所需核心、是否能安裝系統服務、是否提供 TUN 接管，以及訂閱更新與日誌查看是否清楚。只需要瀏覽器和少量遵循系統代理的程式時，普通系統代理已經足夠；需要接管命令列、遊戲啟動器、虛擬機器輔助程式或不讀取系統代理的應用程式時，應優先選擇能穩定管理 TUN 的客戶端。

伺服器與路由器使用者通常直接執行 mihomo 核心，但這條路線要求自行管理設定檔、程序權限、啟動服務與日誌輪替。一般桌面使用者沒有必要為了「更輕量」而跳過圖形客戶端，因為後續維護成本通常高於節省的介面資源。完整套件清單、平台入口與停止維護狀態以客戶端下載頁為準。

Windows、macOS 與 Linux 的安裝重點

Windows 安裝前應確認舊代理程式是否仍在執行。多個程式同時監聽相同連接埠時，新核心會啟動失敗；多個程式輪流修改系統代理時，則會出現介面顯示已開啟、系統實際指向另一個連接埠的情況。退出舊客戶端後再安裝新客戶端，首次啟動時先允許應用程式通過系統安全性提示。若要使用系統服務或 TUN，通常還需要在客戶端內完成服務安裝，並接受系統權限確認。服務安裝成功與 TUN 已開啟是兩種不同狀態，不應混為一談。

macOS 安裝後若提示應用程式來源或網路擴充功能權限，應在系統設定中完成確認。Apple Silicon 與 Intel 使用不同架構的軟體套件，下載時要依照「關於這台 Mac」中的晶片資訊選擇。系統代理只處理遵循 macOS 代理設定的連線；啟用增強接管功能時，系統可能要求加入 VPN 設定或授權網路擴充功能。若授權被拒絕，先回到隱私權與安全性、網路或 VPN 相關頁面重新確認，不要連續重複點擊啟動按鈕。

Linux 的差異主要來自發行版套件格式、桌面環境與權限模型。Debian、Ubuntu 類系統通常使用 deb 套件，其他發行版可選擇客戶端提供的相容格式。安裝後若介面可以啟動但無法接管流量，應檢查桌面系統代理是否確實寫入、目前工作階段是否讀取相關設定，以及 TUN 所需的網路管理權限是否存在。在伺服器環境執行核心時，設定目錄與日誌目錄應由專用服務帳戶存取，避免長期依賴互動式終端程序維持執行。

Android 與 iOS 的接管方式

Android 客戶端透過 VpnService 建立本機 VPN 介面，將裝置流量交給核心處理。首次連線時系統會顯示 VPN 授權視窗，確認後才能接管流量。鎖定螢幕後斷線、切換網路後停止工作，多半與系統省電策略、背景限制或廠商的自動清理機制有關。應允許客戶端在背景執行，並依系統設定將其加入電池最佳化例外。具體路徑因廠商而異，可繼續閱讀Android VpnService、背景執行與省電設定。

iOS 透過系統 VPN 設定運作，安裝 Clash Plus 後首次啟用時需要確認加入 VPN 設定。系統狀態列顯示 VPN 標誌，只代表設定已連線，最終能否存取仍取決於訂閱、策略與節點。行動裝置從 Wi-Fi 切換至行動網路時，原有連線會重新建立，短暫斷線屬於網路切換過程；若長時間無法恢復，應先停止連線，等待系統 VPN 狀態完全消失後再重新啟動，而不是反覆匯入同一份訂閱。

匯入訂閱並讀懂基礎設定結構

區分訂閱網址、節點連結與 YAML 檔案

訂閱網址通常是 HTTPS URL，存取後會回傳可供 Clash 使用的設定或經編碼的節點清單。它的價值在於可更新：服務提供者調整節點、策略或規則後，客戶端重新抓取即可取得新內容。本機 YAML 檔案是一份靜態快照，適合備份、自訂或離線管理，但不會因原始訂閱變更而自動同步。單一節點連結只包含協定、伺服器、連接埠與驗證資訊，匯入後仍可能需要手動建立策略組與規則。

匯入前應確認網址完整，沒有被聊天軟體截斷，也沒有在複製時混入前後空格。將訂閱網址貼到客戶端的訂閱或設定匯入口，而不是瀏覽器網址列的搜尋框。匯入成功後，先查看設定名稱、更新時間與代理組是否出現，再將該設定設為目前啟用項目。只有「下載成功」而沒有「切換為目前設定」時，核心仍可能繼續使用上一份檔案。

匯入失敗時，錯誤大致分為三層。網路層錯誤包括連線逾時、網域無法解析與憑證錯誤；服務層錯誤包括授權失效、拒絕存取或回傳網頁提示；設定層錯誤則包括 YAML 縮排錯誤、欄位型別不符與引用不存在的策略組。若客戶端日誌顯示 HTTP 狀態問題，應先確認訂閱本身；若日誌指出某一行解析失敗，則要檢查設定內容，而不是更換代理節點。

基礎設定中最值得先認識的欄位

一份可執行的設定通常包含本機監聽參數、代理節點、策略組、規則與 DNS 設定。圖形客戶端可能將部分全域欄位放在自己的設定資料庫中，因此匯出的設定不一定包含所有介面開關。以下範例展示基礎結構，不包含真實伺服器資訊；其中代理節點部分僅用於說明欄位關係。

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

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,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

mixed-port表示同一個本機連接埠同時接受 HTTP 與 SOCKS 連線，方便手動為應用程式填寫代理位址；連接埠只在本機監聽時，常用位址是 127.0.0.1。allow-lan控制區域網路中的其他裝置能否連線至目前裝置的代理連接埠，日常僅供本機使用時保持關閉會更清楚。mode決定整體比對模式，通常使用 rule。log-level影響日誌詳細程度，正常使用時維持 info，排錯時短暫調高後應恢復，避免長期累積大量日誌。

proxies定義具體出口，proxy-groups將多個出口組織成可選擇或自動測試的策略，rules則將流量交給策略組。規則引用的策略名稱必須與組名完全一致，包括大小寫與符號。若將組名從 PROXY 改成其他名稱，所有引用該名稱的規則也要同步修改，否則設定驗證會失敗。

更新、覆寫與本機修改之間的關係

訂閱更新通常會重新下載遠端內容並覆寫快取，因此直接編輯由訂閱產生的 YAML，下次更新後可能會遺失。需要長期保留的自訂內容，應優先使用客戶端提供的覆寫、合併、腳本處理或全域擴充功能；如果客戶端沒有這些能力，可以複製一份本機設定獨立維護，但之後必須自行同步節點變化。

更新失敗時不要立即刪除原有設定。先保留最後一次可用的快取，檢查訂閱網址是否仍有效，再嘗試手動重新整理。若更新後的設定突然無法使用，可以切回舊快取，比較代理組、規則與 DNS 區域發生了哪些變化。良好的客戶端會將「遠端訂閱」「本機快取」與「目前啟用設定」分開，理解這三種狀態能避免誤刪唯一可用的設定。

掌握系統代理、執行模式與連線驗證

系統代理與 Clash 執行狀態的差異

客戶端啟動核心後，本機會出現 HTTP、SOCKS 或混合代理連接埠，但作業系統不會自動將所有流量送入其中。系統代理開關的作用，是把本機代理位址寫入 Windows、macOS 或桌面環境的網路設定。瀏覽器等遵循系統代理的程式隨後會連線至該連接埠；忽略系統代理的程式仍會直連。因此，「核心正在執行」與「系統代理已開啟」是兩個獨立條件。

手動設定應用程式代理時，伺服器位址通常填寫 127.0.0.1，連接埠填寫設定中的 mixed-port、HTTP 連接埠或 SOCKS 連接埠。不要將遠端節點連接埠直接填入瀏覽器，遠端協定不一定是瀏覽器支援的 HTTP 代理。若客戶端修改過本機連接埠，系統代理與應用程式內的手動設定也必須保持一致。

部分命令列程式不會自動讀取桌面系統代理，而是讀取環境變數。臨時測試時，可以在目前終端機設定代理變數；關閉終端機後變數通常會失效，適合用來判斷程式是否能透過本機連接埠連線。

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

在 Windows PowerShell 中，可以為目前工作階段設定對應的環境變數，關閉應用程式後再清除。長期將代理變數寫入系統環境前，應確認連接埠不會隨客戶端切換而變更，否則客戶端未啟動時，依賴這些變數的工具會持續嘗試連線至不存在的本機連接埠。

規則、全域與直連模式分別解決什麼問題

規則模式依照設定中的規則由上到下判斷，是日常使用的主要模式。它可以讓區域網路、常用本地服務或指定網域直連，將需要代理的連線交給策略組，並對不希望存取的目標執行拒絕。規則模式的效果取決於規則品質與排列順序，若單一網站走錯出口，應查看規則命中情況，而不是先切換整個執行模式。

全域模式通常會將所有進入核心的流量交給指定策略組，適合進行短時間對照測試。如果規則模式無法存取、全域模式可以存取，表示節點與基礎鏈路大致正常，問題更可能位於規則、策略組引用或 DNS 對應。全域模式不等於系統所有流量都會自動被接管；未進入代理連接埠或 TUN 的連線，仍不會由它處理。

直連模式讓進入核心的流量直接存取目標，適合判斷異常是否與代理出口有關。如果直連模式也無法存取，需要進一步檢查 DNS、系統網路、目標服務或本機防火牆。排錯結束後應恢復規則模式，避免將臨時測試狀態誤當成長期設定。

利用連線記錄與日誌完成閉環驗證

僅憑網頁「能開啟」不足以驗證分流是否正確。客戶端的連線頁通常能顯示目標網域、目標位址、規則鏈與最終策略。存取測試目標後，觀察它是否出現在連線清單中：沒有記錄，表示流量可能未進入核心；有記錄但走向錯誤策略，表示規則或策略組選擇有問題；策略正確但連線失敗，則繼續查看節點、協定交握與 DNS 日誌。

日誌應從第一條明確錯誤的前後內容閱讀，而不是只看最後一行。連接埠佔用往往在核心啟動階段出現，設定引用錯誤會在載入階段出現，節點逾時則發生在實際建立連線時。日誌中的一次失敗也可能來自背景程式，不一定對應正在測試的瀏覽器，因此最好先清空日誌或記住時間點，再執行一次單一測試動作。

建立可維護的規則、策略組與 DNS 設定

規則由上到下比對，順序就是優先級

Clash 規則的基本結構是「類型、比對內容、目標策略」。例如 DOMAIN-SUFFIX,example.com,PROXY 表示目標網域以 example.com 結尾時交給 PROXY；IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 表示指定位址段直連，且比對這條規則時不主動觸發網域解析；MATCH,PROXY用於接收前面所有未命中的連線，通常放在規則清單最後。

由於核心遇到第一條符合的規則後就會停止繼續搜尋，更具體的例外應放在較寬泛的規則之前。例如需要讓某個子網域走代理，而同一主網域的其餘部分直連，就應先寫子網域規則，再寫主網域後綴規則。將 MATCH 放在中間會使其後的規則永遠沒有機會命中。調整大型規則集時，先判斷目標屬於網域規則、位址規則還是程序規則，再確認是否被前面的寬泛規則提前攔截。

rules:
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,media,MEDIA
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,FINAL

DOMAIN比對完整網域，適合精確例外；DOMAIN-SUFFIX涵蓋主網域及其子網域，是常用類型；DOMAIN-KEYWORD範圍較寬，容易誤傷名稱相似的網域，應謹慎使用。IP-CIDR與 IP-CIDR6直接比對目標位址，適合區域網路與明確網段。程序規則依賴作業系統與流量接管方式，系統代理情境不一定總能取得可靠的程序資訊，使用前應在連線記錄中確認。

策略組負責出口決策，不只是節點清單

策略組可以理解為規則與具體節點之間的決策層。select組由使用者手動選擇，結果穩定且便於排錯；url-test會依指定測試網址與間隔測量候選節點，選擇符合條件的結果；fallback通常依可用性順序切換；load-balance則依策略將連線分配至多個候選項目。不同核心與客戶端對進階參數的顯示方式可能不同，應以設定驗證結果為準。

proxy-groups:
  - name: FINAL
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: MANUAL
    type: select
    use:
      - main-provider

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

自動測試只反映客戶端至測試目標的連線情況，不代表所有網站的體驗完全一致。測試網址、節點出口與目標服務之間的網路路徑可能不同，影片、下載與網頁瀏覽對頻寬、抖動與連線重用的要求也不同。日常可以用自動組提供基準，再保留手動組用於特定目標或故障切換。策略組之間可以互相引用，但應避免形成循環引用。

訂閱中若使用 provider 管理節點，use引用的是 provider 名稱，而不是單一節點。服務提供者新增節點後，更新 provider 即可將其加入相關策略組；如果策略組只寫死節點名稱，新節點不會自動出現。修改前應先確認客戶端是否提供圖形化覆寫功能，避免直接編輯遠端訂閱快取。

DNS 決定核心能看見哪些目標資訊

DNS 問題常見表現包括網頁長時間等待、部分網域無法開啟、規則命中位址而非網域，或系統偵測到解析路徑與預期不一致。Clash DNS 模組可以接管解析請求，將不同網域交給指定上游，並配合規則提供網域資訊。常見增強模式包括 fake-ip 與 redir-host。fake-ip 會先回傳保留位址，再由核心在連線階段還原真實網域，通常能保留更完整的網域比對能力；但少數區域網路裝置、特殊應用程式與連線檢查可能需要加入過濾清單。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

範例中的上游僅用於展示語法，實際選擇應考慮所在網路的可達性、解析結果與隱私需求。DNS 監聽位址若只供核心或本機使用，應限制在本機位址。開啟 TUN 後通常還會使用 DNS 劫持，將系統的 53 連接埠請求導入核心；此時若系統中還有其他 DNS 過濾程式、加密 DNS 客戶端或安全軟體同時接管，容易形成爭用或循環。

判斷 DNS 是否異常時，先區分「網域沒有解析結果」與「已取得位址但連線失敗」。前者查看 DNS 日誌、上游可達性與系統快取，後者查看規則命中、目標位址與節點連線。修改 DNS 後應重新啟動核心，並依系統情況清除快取，再用一個先前未存取過的網域測試。若擔心解析路徑，可繼續查看 FAQ 中的相關排查項目，並閱讀站內關於 Clash DNS 與連線異常的問答。

設定 TUN 接管並處理權限與路由衝突

TUN 能解決哪些系統代理無法涵蓋的問題

系統代理依賴應用程式主動讀取作業系統的代理設定。瀏覽器與多數桌面應用程式通常支援，但命令列工具、部分遊戲、虛擬機器元件、UDP 應用程式與自行實作網路堆疊的程式可能完全忽略。TUN 模式會建立虛擬網路介面，透過系統路由將連線送入 Clash，因此涵蓋範圍更廣，也能處理更多 UDP 與不具代理感知能力的應用程式。

TUN 並不天然比系統代理更快。它增加了虛擬網卡、路由、DNS 劫持與協定轉換等環節，優勢在於完整接管，而不是縮短網路距離。只需要瀏覽器代理時，系統代理更簡單；明確存在應用程式繞過、需要 UDP 或希望統一管理系統流量時，再開啟 TUN。排錯時也建議先讓普通代理正常運作，再加入 TUN，這樣可以分開判斷節點問題與系統路由問題。

了解常見 TUN 參數

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

dns:
  enable: true
  enhanced-mode: fake-ip

stack指定 TUN 使用的網路堆疊實作，常見值包括 system、gvisor 或 mixed，具體可用項目取決於核心。system 通常利用系統網路能力，相容性與效能受平台實作影響；gvisor 在使用者空間處理更多網路邏輯，某些環境下隔離更明確；mixed 會依協定採用組合方式。沒有明確故障時，應維持客戶端預設選項，不要只根據名稱推測效能。

auto-route讓核心自動寫入所需路由，auto-detect-interface嘗試辨識實際連線介面，適合在 Wi-Fi 與有線網路之間切換。strict-route用於加強路由限制，減少流量繞過，但存在虛擬機器、容器、企業 VPN 或特殊區域網路路由時，可能需要額外調整。dns-hijack會將指定 DNS 請求導入 Clash DNS，避免應用程式直接使用系統 53 連接埠繞過分流。

不同平台的權限與衝突來源

Windows 上啟用 TUN 往往依賴系統管理員權限、系統服務或驅動元件。客戶端顯示服務未安裝時，應先在設定中完成服務安裝，再重新啟動核心。若虛擬網卡建立失敗，請檢查其他 VPN、網路加速器與安全軟體是否也在管理路由或過濾驅動。不要同時開啟兩個全域 VPN 接管程式，它們可能不斷重寫預設路由，導致連線週期性中斷。

macOS 通常透過系統網路擴充功能或 VPN 設定實現接管。首次啟用時應完成系統授權；若設定殘留導致無法重新建立，可以先在系統網路設定中停用舊 VPN 項目，再由客戶端重新建立。Android 與 iOS 本身就是透過系統 VPN 介面接管，同一時間通常只能有一個主要 VPN 設定處於活動狀態，切換客戶端前要先中斷目前連線。

Linux 上直接執行核心時，需要具備建立 TUN 裝置與修改路由的權限。使用 systemd 管理服務時，可依發行版安全策略授予必要的網路能力，而不是依賴長期保持開啟的管理員終端機。在容器環境中還要明確提供 TUN 裝置與網路管理權限；若主機已有防火牆規則，應確認核心寫入的路由與轉送規則沒有隨後被覆寫。

區域網路、虛擬機器與企業 VPN 的邊界

開啟 TUN 後無法存取印表機、路由器管理頁面或 NAS，通常是區域網路路由被接管。先確認私有位址段是否保持直連，例如 IPv4 常見區域網路範圍與 IPv6 本機位址；再檢查嚴格路由是否阻止特定介面。企業 VPN 可能只將內部網段導向專用介面，若 Clash 覆蓋該路由，會造成內部網域或辦公系統無法存取。解決時應明確哪些網段必須交由企業 VPN 管理，而不是簡單關閉所有分流。

虛擬機器與容器可能透過獨立網橋存取網路。主機的 TUN 是否接管這些流量，取決於路由、轉送與網路模式，不能只看主機瀏覽器的結果。發生衝突時，記錄啟用 TUN 前後的路由表變化，暫時關閉自動路由進行對照，再決定加入排除網段或調整介面優先級。

建立日常維護、遷移與故障排查流程

日常更新不等於同時更新所有部分

Clash 環境通常包含客戶端程式、代理核心、訂閱設定與規則資料四類可更新物件。客戶端更新可能改變介面與系統整合；核心更新可能影響協定、規則語法或 TUN 行為；訂閱更新主要帶來節點與服務提供者的設定變化；規則集更新則會改變分流結果。將這些更新安排在同一時間，一旦出現異常就很難判斷來源。

較穩妥的做法是保留最後一次可用設定，先更新訂閱並驗證，再更新客戶端或核心。重要裝置更新前，記錄目前使用的設定名稱、代理模式、策略選擇、監聽連接埠、DNS 模式與 TUN 狀態。客戶端支援匯出設定時，可以保留一份備份，但備份中可能包含訂閱網址或驗證資訊，應存放在受控位置，不要上傳至公開儲存庫或公開問題截圖。

訂閱更新頻率應與實際變化相符。過於頻繁地重新整理不會改善節點品質，反而可能在暫時的網路波動期間不斷產生失敗記錄。更新後若發現策略組為空，應檢查 provider 是否載入成功、節點過濾條件是否過嚴，以及訂閱回傳格式是否改變。沒有備份時不要刪除舊設定後重新匯入，因為舊快取本身就是重要的對照樣本。

分層排查「完全無法上網」

第一步檢查系統基礎網路：關閉系統代理與 TUN 後，直連網路是否正常。如果直連也失敗，先處理 Wi-Fi、有線連線、閘道或系統 DNS。第二步啟動 Clash 核心但不接管系統，查看是否存在設定解析錯誤與連接埠衝突。第三步開啟系統代理，用瀏覽器存取測試網站並觀察連線記錄。沒有連線記錄時檢查系統代理位址；出現記錄後再查看命中策略與節點錯誤。

若所有節點都逾時，應判斷是訂閱過期、節點整體無法連線，還是本機網路受到阻擋。切換至同一設定中的直連策略，有助於確認本機網路；選擇不同地區或不同協定的節點，有助於判斷單一出口問題。若只有一個節點失敗，不應修改整套 DNS 與規則設定。若所有節點立即回傳驗證錯誤，則應回到訂閱狀態與服務授權檢查。

HTTPS 憑證錯誤應與一般連線失敗分開處理。先檢查系統日期、時區與憑證鏈，再確認是否啟用了會檢查 HTTPS 的安全軟體或中間代理。Clash 的一般轉送不要求為普通 HTTPS 網站安裝網站憑證。詳細判斷順序可參閱代理環境中的 HTTPS 憑證錯誤處理。

依現象排查部分網站或部分應用程式

只有單一網站異常時，先開啟連線記錄，確認網域、命中規則與最終策略。如果規則走錯，調整更具體的網域規則；如果策略正確但連線失敗，嘗試同組中的其他節點；如果連線記錄只有位址沒有網域，檢查 DNS 接管與 fake-ip 行為。目標使用 QUIC 時，UDP 支援也可能影響結果，可以暫時停用瀏覽器 QUIC 進行對照，但不應將對照設定當作永久結論。

瀏覽器正常、命令列或其他應用程式異常，通常表示應用程式沒有遵循系統代理。先查詢應用程式是否支援手動 HTTP 或 SOCKS 代理，再使用環境變數測試；需要長期統一接管時，可考慮 TUN。若只有行動應用程式在鎖定螢幕後斷線，則檢查背景執行與省電限制。若只有區域網路資源無法存取，則檢查私有網段直連、TUN 嚴格路由與 DNS 對本地域名的處理。

代理關閉後系統仍無法連線，常見原因是客戶端異常退出後留下系統代理設定。進入系統網路設定，確認代理位址與開關，關閉失效的手動代理；若曾使用 TUN，則確認虛擬 VPN 已中斷、預設路由已恢復。重新啟動客戶端，再透過正常按鈕關閉接管，有時比直接結束程序更容易讓系統設定恢復。

收集有效日誌，而不是整頁截圖

提交問題前記錄作業系統、客戶端名稱、目前接管方式、故障開始時間與最小重現步驟。日誌保留錯誤前後的一小段即可，並處理訂閱網址、伺服器位址、使用者名稱與驗證欄位。介面截圖應包含狀態與錯誤區域，不必把無關的桌面內容一併傳送。能夠說明「關閉 TUN 正常、開啟後失敗」或「全域正常、規則模式失敗」的對照結果，比籠統描述「不能用」更有價值。

更多簡短問題可在常見問題頁依基礎認知、安裝設定、使用技巧與故障排查分類查詢。若不熟悉介面中的代理頁、設定頁與日誌頁，可閱讀Clash 客戶端介面功能速覽，先找到對應狀態，再依本章鏈路定位。

從穩定可用邁向進階設定與長期維護

先建立模組化設定思維

進階設定的目標不是堆積更多規則，而是將節點來源、策略決策、規則來源、DNS 與系統接管拆分為可獨立驗證的模組。節點可以由 proxy provider 管理，規則可以由 rule provider 管理，固定的策略組與全域設定則保留在主要設定中。如此一來，更新節點時不會覆寫自訂策略，更新規則時也不需要重新複製整份設定。

在模組化之前，先為每個策略組定義明確職責，例如「手動選擇」「自動選擇」「媒體服務」「開發服務」「最終出口」。組名應保持穩定，並容易在日誌中辨識，不要頻繁使用只靠符號區分的相似名稱。規則引用職責組，而不是直接引用某個短期節點；節點變更時只需調整組成員，規則層無須改動。

遠端 provider 應設定合理的更新間隔，並保留本機快取。規則來源暫時無法存取時，核心仍可使用快取啟動；如果所有關鍵內容都依賴即時下載，網路恰好異常時可能無法完成啟動。外部資源的格式與 behavior 必須相符，例如網域集合、IP 網段集合與傳統規則格式不能隨意混用。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-network.yaml
    url: https://example.com/rules/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,FINAL

範例網址僅用於展示結構。實際使用遠端規則前，應確認來源、內容更新方式與可用格式。規則集並非越大越好：大量重疊項目會增加理解與排錯成本，錯誤分類還會將原本應直連的連線送入代理。優先維護與自身使用情境相關的少量例外，再選擇界線清楚的通用規則來源。

了解 mihomo 擴充能力的適用界線

mihomo 在原版 Clash 設定思路上擴充了更多協定、規則類型、DNS 能力、provider 選項與 TUN 行為。遷移舊設定時，應先驗證基礎欄位與策略組，再逐步導入新能力，而不是直接將多個來源的片段拼接在一起。不同客戶端內建的核心版本、預設參數與覆寫機制可能存在差異，同一份片段在某個客戶端可用，不代表另一個客戶端會以完全相同的方式載入。

需要完整了解相容關係、擴充規則與遷移重點，可閱讀mihomo 核心特性與原版 Clash 差異解析。學習時建議以客戶端實際產生的執行設定為準：介面儲存的設定可能在啟動時合併至訂閱設定，最終送給核心的內容才會決定實際行為。

為設定變更建立驗證與回復機制

長期維護應保留三類檔案：一份確認可啟動的基準設定、一份目前使用的設定，以及一份正在修改的測試設定。修改後先執行客戶端提供的設定檢查，再啟動測試；確認核心啟動、系統代理、規則命中、DNS 與 TUN 都正常後，才替換目前設定。文字設定可以使用本機版本管理記錄差異，但驗證資訊與訂閱網址不應放入公開儲存庫。

每次變更都寫下目的，例如「讓開發網域使用指定策略」「排除家庭區域網路」「為不遵循系統代理的應用程式開啟 TUN」。如果無法用一句話說明目的，通常表示一次修改混入了太多變數。發生回歸時，依照記錄恢復上一個狀態，再將修改拆小。可維護性來自穩定的命名、清楚的職責與可回復的步驟，而不是設定檔的長度。

建議的進階學習順序

第一階段應熟練使用規則模式、手動策略組與連線記錄，能夠解釋一次存取為何走向某個出口。第二階段學習 DOMAIN、IP-CIDR、RULE-SET 與 provider，建立少量自訂分流。第三階段了解 DNS 請求路徑、fake-ip 與網域嗅探，能夠區分解析問題與連線問題。第四階段再研究 TUN 路由、區域網路排除、IPv6 與多 VPN 共存。最後才考慮自動測試、負載分配、腳本覆寫與複雜規則集。

完成這條路線後，遇到問題時不再需要反覆重新安裝客戶端，而是能依照應用程式接管、核心監聽、DNS、規則、策略與節點的順序定位。需要更換客戶端時，也能明確判斷哪些內容屬於訂閱、哪些屬於本機設定，以及哪些依賴特定平台。若目前目標只是完成首次連線，回到快速使用指南依最短流程操作；若準備重新選擇客戶端，可查看Clash 客戶端選擇指南與全平台下載入口。