Clash 使用指南：從核心概念到穩定分流

理解 Clash：核心、用戶端與代理鏈路

開始安裝前，先把幾個容易混淆的名稱區分清楚。Clash 通常既指一類代理設定格式，也指使用這種格式的用戶端生態；用戶端負責提供圖形介面、讀取設定與呼叫系統能力，真正執行 DNS 解析、規則比對與連線轉送的部分稱為核心。目前常見的開源核心路線是 Mihomo，它繼承並擴充了 Clash Meta 的設定能力。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等屬於用戶端，不能把用戶端名稱直接當成核心名稱。下載頁會依平台列出這些用戶端，選擇時應先看作業系統，再看介面與功能支援範圍。

一次存取通常會經過四個階段。應用程式先產生目標網域或 IP 位址，用戶端依目前設定決定是否接管請求；核心接著處理 DNS，並依規則順序尋找第一個符合項目；規則會把請求交給某個代理群組、直連策略或拒絕策略；最後由節點建立到目標伺服器的連線。任何一個階段出現問題，表現都可能是「網頁打不開」，但排查方法並不相同。規則命中錯誤時，切換節點沒有意義；DNS 回傳錯誤位址時，單純更換代理群組也無法解決；系統沒有把流量交給用戶端時，設定本身可能完全正常。

設定檔與執行狀態不是同一回事

YAML 設定檔會儲存連接埠、代理節點、代理群組、規則、DNS 等宣告式內容。用戶端啟動後會將這些內容載入記憶體，並依目前模式、網路介面與執行權限建立狀態。修改檔案卻沒有重新載入時，介面可能仍在使用舊設定；反過來，在介面中暫時切換節點，也不一定會修改原始訂閱。理解這一點有助於判斷問題是「檔案沒有更新」，還是「執行狀態沒有套用」。重新載入設定、更新訂閱與重新啟動用戶端是三個不同動作，後文會分別說明。

從請求到節點的完整路徑

以瀏覽器存取網域為例：瀏覽器先向作業系統發出連線請求，系統代理設定或 TUN 介面決定流量是否進入 Clash；核心接收後，依 DNS 模式取得目標位址，再由上到下掃描 rules；若命中 DOMAIN-SUFFIX，就把請求交給指定策略群組；策略群組再依手動選擇、故障轉移或 URL Test 結果選擇代理節點；節點協定完成握手後，目標請求才會送出。鏈路中的「延遲」可能只代表測試位址的 TCP 建立連線時間，不等於整個網頁的內容載入時間。關於測速指標的差異，可參考Clash 延遲測試原理。

還需要區分「代理用戶端」與「代理服務」。用戶端只負責執行本機設定，訂閱服務則提供節點資訊與流量服務，兩者不是同一個組織，也不共用帳號。訂閱網址應只向服務提供者取得；網站中的用戶端入口用於下載程式，不會替使用者產生節點或提供訂閱。完成概念分層後，第二章再依作業系統與使用目的選擇合適的用戶端。

選擇用戶端：依系統能力與使用目的判斷

選擇用戶端不應只看名稱或截圖，而要看三個條件：系統是否支援所需的接管方式、介面是否能完成訂閱與規則操作、核心版本是否涵蓋需要的協定與 DNS 功能。一般桌面使用者通常需要常駐系統匣、系統代理、設定重新載入與日誌檢視；行動裝置還要考量背景限制、電池策略與系統 VPN 權限；伺服器或軟路由使用者則更重視命令列啟動、設定檔位置與程序守護。下載頁將 Clash Plus 排在各平台首位，適合作為圖形介面入口，但不同用戶端的選單名稱仍可能不同。

Windows 與 macOS 的選擇邏輯

Windows 使用者可以優先查看 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu。需要傳統桌面控制與較少選項時，可選擇介面易讀的用戶端；需要更多 Mihomo 選項、TUN 或規則除錯功能時，則選擇能顯示核心日誌與完整設定區域的用戶端。Clash for Windows 已停止維護，不適合作為新安裝的預設選擇；既有設定可以遷移，但遷移前應先保存訂閱網址與自訂規則。macOS 可選項包括 Clash Plus、Clash Verge Rev、FlClash 與 ClashX Meta，其中 ClashX Meta 已停止維護，適合僅為讀取舊設定而保留，不建議作為新環境的主要入口。

Android 與 iOS 的限制

Android 用戶端必須透過系統 VPN 或 VpnService 接管流量，首次執行時會出現系統授權提示。Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 的設定位置不同，但都需要確認 VPN 開關處於執行狀態。Android 的省電策略可能暫停背景程序，造成鎖定螢幕後連線中斷；遇到這種情況，應將用戶端加入系統的電池最佳化例外，並檢查背景資料權限。Android 使用重點還包括通知權限、永遠執行的 VPN 選項以及區域網路存取權限，具體可參考Android VpnService 與省電設定。

iOS 的系統代理權限集中於 VPN 設定授權，用戶端的取得與設定匯入都受系統介面控制。下載頁提供 Clash Plus 的 App Store 入口，並標示官方網站 clashplus.io。首次啟動時，先完成設定匯入，再允許系統加入 VPN 設定，最後在用戶端內啟動連線。iOS 的背景行為、隨選連線與網路切換策略由系統共同管理，遇到行動網路與 Wi-Fi 表現不同時，應分別測試。

Linux 與 Mihomo 核心

Linux 桌面使用者可以從 Clash Verge Rev 或 FlClash 開始；伺服器、路由器及沒有桌面環境的裝置，則更適合直接執行 Mihomo。核心套件只提供執行檔或壓縮檔，不會自動建立 systemd 服務、寫入設定或開放連接埠。安裝後需要自行確認架構、檔案權限、設定目錄與監聽位址。將管理面板公開到網際網路會擴大風險，通常應只監聽本機位址，並透過 SSH 通道或區域網路管理。

選擇完成後，不要同時安裝多個用戶端，並讓它們全部開啟系統代理。多個程式競爭同一個連接埠或反覆改寫系統代理，會製造難以判斷的狀態。首次設定建議只保留一個正在執行的用戶端，確認連線、規則與 DNS 都正常後，再嘗試遷移到其他軟體。

安裝與初始設定：先建立可回復的工作環境

安裝前先記錄作業系統版本、CPU 架構，以及目前是否存在其他 VPN 或代理工具。桌面系統還應確認目前帳號具備安裝權限，行動系統則要準備好系統 VPN 授權。建議從用戶端頁面進入對應平台，再依照卡片說明選擇安裝套件。首次使用不要急著開啟 TUN 或修改 DNS，先讓用戶端以最小權限完成一次普通系統代理連線，這樣後續每增加一項功能，問題範圍都比較明確。

桌面端的初始順序

安裝完成後啟動用戶端，先找到設定、Profiles、訂閱或類似名稱的區域。沒有訂閱時，可以先確認程式是否能正常開啟、核心是否啟動、日誌區域是否出現啟動資訊；不要為了測試而填入來源不明的網址。匯入設定後，檢查代理群組中是否出現節點，並確認規則區能載入規則數量或規則檔案。接著進入設定，記錄混合連接埠、HTTP 連接埠、SOCKS 連接埠與外部控制位址。不同用戶端的預設連接埠可能不同，不能直接照搬其他軟體的連接埠。

系統代理通常只會影響遵守系統代理設定的應用程式。瀏覽器、命令列工具與部分桌面程式可能讀取 HTTP、HTTPS 或 SOCKS 設定中的其中一種，也可能完全忽略系統代理。啟用系統代理後，先用瀏覽器存取一個可確認的網站，再用命令列測試；如果瀏覽器可用而命令列不可用，優先檢查命令列是否需要個別設定環境變數，而不是立即開啟 TUN。

行動端的初始順序

Android 首次啟動時，用戶端會要求建立 VPN，系統跳出的應用程式名稱應與目前安裝的用戶端一致。授權後回到用戶端，確認狀態由停止變為執行，並觀察通知列是否出現 VPN 標誌。iOS 則需要允許用戶端加入 VPN 設定，授權成功後，系統設定中的 VPN 狀態會改變。若系統提示已有 VPN，先關閉其他 VPN，再重新授權，避免兩個網路擴充功能同時運作。

Linux 核心的最小執行方式

在 Linux 上直接執行 Mihomo 時，可以先將設定檔放在明確的目錄，並以前景模式啟動以觀察日誌。確認設定讀取成功、連接埠監聽正常後，再交由 systemd 或其他程序管理器處理。以下命令只展示通用執行方式，路徑需要替換為實際檔案位置：

mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/"
mihomo -d "$HOME/.config/mihomo"

啟動日誌中應重點查看設定解析、DNS 初始化、代理群組載入與連接埠監聽。如果 YAML 縮排錯誤，核心通常會在啟動階段直接報錯；如果設定能載入但節點無法使用，錯誤會出現在實際連線或健康檢查階段。這兩類日誌不要混為一談。確認前景執行穩定後，再設定服務檔案，並為服務指定固定的工作目錄與使用者權限。

設定檔的基本結構

以下片段展示一個易讀的最小結構。節點內容與訂閱服務提供的欄位必須以實際設定為準，範例中的名稱只用於說明引用關係：

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "範例節點"
    type: ss
    server: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "範例節點"
      - DIRECT

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

這段設定中的密碼是範例值，不能直接用於連線。實際設定還可能包含 TLS、UDP、連接埠複用與特定協定欄位。不要把訂閱內容、密碼或管理金鑰發佈到公開儲存庫，也不要在截圖中暴露完整訂閱網址。完成安裝後進入下一章，使用真實訂閱取代範例設定。

訂閱與節點：更新設定，理解代理群組的來源

訂閱通常是由服務提供者產生的 URL，用戶端存取後取得節點與規則設定。更新訂閱不是「測試某個節點」，而是重新下載並解析一份設定；更新成功後，用戶端才可能顯示新增節點、失效節點或新的代理群組。匯入訂閱時應使用服務提供者給出的原始網址，不要把網址貼到不明的轉換頁面，也不要在公開聊天、截圖或工單中暴露完整連結。訂閱網址往往包含存取憑證，洩漏後應在服務端重設或重新產生。

第一次匯入的檢查方法

在用戶端的訂閱管理區域新增網址，填寫一個容易辨識用途的名稱，然後執行更新。更新結束後先查看狀態提示與更新時間，再開啟設定詳情，確認節點數量、代理群組與規則已經出現。不要只看「更新成功」四個字：有些網址回傳的是 HTML 錯誤頁，用戶端可能提示下載完成，卻無法解析為有效設定。如果代理群組為空，請檢查回應格式、訂閱是否過期，以及用戶端是否支援該設定格式。

訂閱更新失敗時，依照以下順序縮小範圍。第一，直接確認網址在目前網路下能否存取；第二，檢查系統時間，TLS 憑證驗證依賴正確時間；第三，確認用戶端是否需要透過既有代理更新；第四，查看日誌中的 HTTP 狀態碼與解析錯誤；第五，刪除網址末尾多餘的空格或換行。如果瀏覽器能開啟網址但用戶端失敗，可能是瀏覽器使用了代理，而用戶端尚未建立代理；如果用戶端直連失敗、切換既有代理後成功，則應在訂閱設定中選擇正確的更新代理。

節點、代理群組與策略的關係

節點是具體的遠端連線入口，代理群組則是將多個節點組織起來的選擇器。最簡單的 select 群組由使用者手動選擇；URL Test 會依測試結果選擇節點；fallback 會在目前節點無法使用時切換；load-balance 則會依策略分配請求。測試結果只反映測試 URL 與測試當下的狀況，不能取代實際存取體驗。節點所在地區、線路壅塞、目標網站位置與協定相容性都會改變結果。建議先使用 select 群組建立可控基準，確認規則無誤後再嘗試自動選擇。

訂閱更新與本機修改

許多用戶端會分開儲存訂閱設定與本機覆寫內容。直接修改訂閱產生的檔案，下一次更新可能會覆蓋變更；較穩妥的方式是使用用戶端提供的覆寫、Merge 或 Patch 功能，將自訂代理群組、規則與 DNS 放在獨立檔案中。如果用戶端不支援覆寫，至少應在修改前匯出備份，並記錄修改位置。判斷修改是否生效時，要查看執行中的設定預覽與日誌，而不是只看磁碟上的檔案。

節點篩選不應只追求最低延遲。穩定且低封包遺失率的線路，通常比偶爾出現極低數值的節點更適合長期使用；還要注意流量倍率、出口地區、協定是否支援 UDP，以及目標服務對該出口的限制。可以參考Clash 節點怎麼選，建立自己的篩選紀錄。訂閱正常更新後，下一章再選擇代理模式，避免在模式尚未明確時誤判規則效果。

代理模式：Direct、Global 與 Rule 應如何使用

代理模式決定核心收到請求後採用哪一類決策方式。Direct 會直接連線到目標，通常用於驗證網路本身與排查規則影響；Global 會將大多數請求交給一個代理群組，適合快速確認某條線路能否存取目標，但不適合長期作為精細分流方案；Rule 依 rules 由上到下比對，是日常使用最常見的模式。切換模式不會改變節點本身，也不會自動修復 DNS、系統代理或 TUN 權限問題，因此需要結合日誌與連線紀錄判斷。

Direct 模式用於建立基準

網頁無法開啟時，可以暫時切換至 Direct，觀察目標是否能正常連線。如果 Direct 正常而 Rule 失敗，問題可能出在規則、代理節點或代理群組；如果 Direct 也失敗，則應檢查本機網路、DNS、目標網站狀態或系統防火牆。Direct 不能證明規則正確，因為它繞過了代理鏈路。測試結束後應切回原本的模式，否則部分請求會繞過預期的分流策略。

Global 模式用於驗證節點

Global 模式會將請求集中交給選定的代理群組，適合驗證「這組節點是否能存取目標」。如果 Global 下能存取、Rule 下不能存取，優先查看規則命中與代理群組引用；如果 Global 下仍不能存取，請檢查目前節點、協定握手、出口地區與遠端回應。Global 也可能讓原本應直連的中國大陸網站、區域網路位址或需要本機 IP 的服務經過代理，因此只能作為短時間診斷工具，使用完後恢復 Rule。

Rule 模式的判斷重點

Rule 模式的核心不在規則數量，而在順序與涵蓋範圍。同一個網域可能同時符合多個條件，核心通常採用最先命中的規則。常見設定會先處理區域網路、私有 IP、特定網域，再處理廣告或地區清單，最後用 MATCH 作為兜底。沒有 MATCH 時，未命中的請求可能採用預設策略，導致行為與預期不同。選擇代理群組時，請確認群組名稱與規則中引用的名稱完全一致。

用戶端連線紀錄通常能顯示請求網域、命中的規則與最終策略。出現存取問題時，先清除或篩選連線紀錄，再只開啟一個目標頁面，觀察請求是否出現、規則欄位顯示什麼，以及策略群組最後選用了哪個節點。瀏覽器可能同時請求多個網域，頁面能開啟並不代表所有資源都經過相同路徑。若是應用程式問題，還要確認應用程式是否使用 QUIC、DoH 或自帶代理，這些流量可能不會以一般瀏覽器連線的方式出現。

系統代理與 TUN 的界線

系統代理主要接管遵守系統設定的 TCP 應用程式，TUN 則透過虛擬網路介面接管更廣泛的系統流量。啟用 TUN 後，某些原本繞過系統代理的程式也會進入核心，但權限、路由與 DNS 處理的複雜度會增加。建議先在系統代理模式下完成訂閱、規則與節點驗證，只有確定需要接管不遵守系統代理的應用程式時，再進入第七章的 TUN 設定。

規則分流：從比對順序到可驗證的策略設計

規則分流的目標，是讓不同請求依照明確條件進入直連、代理或其他策略群組。規則不是越多越好，最重要的是界線清楚、順序穩定、兜底明確。常見規則類型包括依完整網域比對的 DOMAIN、依後綴比對的 DOMAIN-SUFFIX、依關鍵字比對的 DOMAIN-KEYWORD、依 IP 或網段比對的 IP-CIDR，以及最後處理未命中請求的 MATCH。規則右側的策略名稱必須存在於設定的 proxy-groups 或保留策略中，否則規則雖然寫在檔案裡，也無法依預期執行。

網域規則的差異

DOMAIN,api.example.com,PROXY 只會比對指定的完整網域；DOMAIN-SUFFIX,example.com,PROXY 通常涵蓋該網域及其子網域；DOMAIN-KEYWORD,example,PROXY 會比對網域中的關鍵字，範圍更廣，也更容易誤傷。為服務新增規則時，應優先使用完整網域或後綴規則，只有在網域結構複雜且確認影響範圍時才使用關鍵字規則。規則中的網域不應包含協定、路徑或連接埠，寫入 https://example.com/path 通常不會得到預期的比對結果。

規則順序與區域網路例外

區域網路與本機位址通常應放在較前面的位置。如此可避免印表機、路由器管理頁面、家庭伺服器等請求被送往遠端節點。範例順序如下：

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve 可以避免 IP 規則為判斷網域而額外觸發 DNS 解析，適合已明確使用 IP 網段判斷的情境。它不是所有規則都必須加入的開關，使用前要理解目前的 DNS 模式與規則引擎行為。GEOIP 依賴 IP 資料庫，資料庫更新狀態會影響結果；如果某個網站的出口與網域策略有明確要求，應優先撰寫網域規則，不要完全依賴地區判斷。

規則集與本機覆寫

較大的網域清單通常會以 rule-provider 或規則集形式載入。規則集適合集中維護，但除錯時要知道實際命中的來源。修改本機規則後，應先儲存設定，再執行重新載入；如果規則集是遠端網址，還要確認它是否更新成功。為降低排錯難度，可以把少量個人例外規則放在獨立檔案的頂部，把通用規則集放在後面，最後保留一條明確的 MATCH。這樣既能快速覆蓋個人例外，也不會直接修改上游訂閱。

如何驗證一條規則

驗證時只選擇一個目標網域。清除連線紀錄，存取目標，查看連線詳情中的網域、解析位址、命中規則與最終策略。若沒有紀錄，先檢查應用程式是否經過系統代理或 TUN；若有紀錄但命中 MATCH，檢查規則檔案是否載入、規則順序是否正確；若命中目標規則卻仍然失敗，問題已從規則層轉移到策略群組、節點或遠端回應。不要同時修改三個地方，否則無法知道是哪項修改產生了結果。

規則分流也會受到快取影響。瀏覽器可能快取 DNS、連線或重新導向結果，用戶端也可能保留連線狀態。修改規則後關閉目標頁面，執行一次設定重新載入，必要時重新建立連線，再觀察新的請求。長期維護時，建議將個人規則寫成附有日期與用途說明的獨立片段，並定期刪除已不再需要的例外，避免規則表逐漸變成無法解釋的黑箱。

TUN 與 DNS：處理系統代理無法涵蓋的流量

TUN 是一種虛擬網路介面。系統將流量送入該介面後，Clash 核心可以在更接近網路層的位置接收請求，因此不遵守系統代理的程式也有機會被納入分流。TUN 不是「更快的代理模式」，也不是開啟後所有網路問題都會消失。它需要系統權限、路由設定與正確的 DNS 配合；與其他 VPN、虛擬網卡、企業安全軟體同時執行時，還可能產生路由衝突。只有在一般系統代理無法涵蓋目標應用程式時，才建議啟用。

啟用前的準備

先關閉其他 VPN，記錄目前網路是否能正常使用。在桌面用戶端中找到 TUN、增強模式或虛擬網卡設定，確認核心具備相應能力。Windows 可能會跳出驅動程式或管理員權限要求，macOS 可能要求允許網路擴充功能，Linux 則可能需要 CAP_NET_ADMIN 或 root 權限。行動裝置的 VPN 接管由系統應用層控制，通常不會使用桌面端相同的 TUN 開關。啟用前保留關閉 TUN 的回復路徑，避免重新啟動後網路無法恢復。

DNS 模式的作用

DNS 不只是將網域翻譯成 IP。規則通常需要先看見網域，DNS 的處理方式會影響規則比對、Fake-IP 對映、區域網路存取與污染規避。常見思路包括 redir-host 與 fake-ip。redir-host 會回傳真實解析位址，相容性較直觀，但某些網域的解析結果可能受到目前網路影響；fake-ip 會為網域分配虛擬位址，核心透過對映表保留網域資訊，方便在連線階段繼續依網域比對，但部分區域網路裝置、硬編碼 IP 的應用程式與特殊驗證流程可能不相容。

範例設定如下，實際 DNS 伺服器應依網路環境與用戶端支援情況調整：

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.local"

Fake-IP 位址範圍不能與實際區域網路網段衝突，過濾清單也不能任意照抄。需要存取區域網路主機名稱、智慧家庭或公司內網時，應將相應網域加入過濾範圍，並確認區域網路 DNS 仍可到達。如果某個應用程式顯示 IP 位址而不是網域，Fake-IP 可能無法還原原始網域；這類應用程式要麼加入過濾清單，要麼使用更適合它的接管方式。

開啟 TUN 後的排錯順序

啟用後先測試區域網路閘道，再測試一般網域，最後測試需要代理的目標。區域網路失敗時檢查路由、Fake-IP 過濾與允許區域網路設定；一般網域失敗時檢查 DNS 日誌、虛擬網卡與系統 DNS；只有前兩者正常而代理目標失敗時，才轉向規則、代理群組與節點。如果所有網路都中斷，立即關閉 TUN 或退出用戶端，恢復基礎網路後再檢查權限與路由日誌，不要繼續疊加設定。

DNS 快取也會讓修改看起來沒有生效。完成設定修改後，執行用戶端設定重新載入，重新連線網路，並依作業系統需要重新整理 DNS 快取。瀏覽器內建的安全 DNS 可能繞過系統 DNS，應用程式自帶的解析器也可能繞過核心；排錯時應明確確認測試工具使用的解析路徑。完成 TUN 與 DNS 驗證後，不要為了追求複雜設定而繼續增加選項，穩定且可解釋的設定比堆疊功能更容易長期維護。

日常維護與進階路線：讓設定保持可解釋

穩定使用 Clash 的關鍵不是頻繁調整，而是建立固定的檢查週期。每次更新訂閱後，確認更新時間、節點是否仍存在、代理群組引用是否完整；每次升級用戶端後，查看核心日誌與系統代理狀態；每次修改規則或 DNS 後，只改變一個變數並進行一次目標測試。將設定視為需要維護的執行檔案，而不是匯入一次後永遠不變的選項，可以明顯減少「昨天還正常、今天突然失效」時的無從下手。

建議保留的紀錄

至少保留目前使用的用戶端名稱、設定來源、代理模式、混合連接埠、是否啟用 TUN、DNS 模式以及自訂規則檔案。不要將訂閱網址直接寫入公開文件，可以只記錄用途與服務端管理位置。發生問題時，記錄發生時間、網路類型、目標網域、連線日誌中的命中規則與錯誤訊息。比起一句「無法上網」，這些背景資訊更能協助定位是訂閱、規則、DNS、節點還是系統權限發生變化。

更新用戶端與核心時的遷移流程

升級前匯出目前設定或複製本機覆寫檔案，記下自訂規則與代理群組名稱。安裝新用戶端後先不要啟用 TUN，匯入設定並檢查代理群組；接著啟用系統代理測試瀏覽器；最後才恢復 TUN、DNS 與開機啟動。不同用戶端對欄位、外部控制介面與覆寫語法的支援並不完全一致，舊設定能匯入不代表每個選項都已套用。發現啟動錯誤時，應回復到最小設定，逐段恢復，而不是將舊目錄整個覆蓋到新用戶端。

常見故障的判斷樹

如果用戶端無法開啟，先檢查安裝套件、權限與系統日誌；如果用戶端能開啟但沒有節點，檢查訂閱更新與設定解析；如果節點存在但所有請求都失敗，檢查代理群組選擇、節點握手與系統時間；如果只有部分網域失敗，檢查規則命中、DNS 與目標網站限制；如果瀏覽器可用而某個應用程式不可用，檢查應用程式是否遵守系統代理；如果開啟 TUN 後全域斷網，關閉 TUN 並檢查路由、權限與其他 VPN。這個順序從本機程式逐步延伸到遠端服務，能避免把所有問題都歸因於節點。

FAQ 頁面整理了訂閱更新失敗、系統代理與設定匯入等短問題；需要查詢某個術語時，可以從站內的用戶端與設定說明進入對應章節。部落格文章適合閱讀特定主題，例如 Fake-IP 原理與 iOS 設定匯入，而本頁適合在設定過程中反覆定位章節。三類內容的用途不同，遇到問題時不必從頭讀完所有文件。

進一步學習 Mihomo 設定

完成基礎分流後，可以依序學習代理群組策略、rule-provider、腳本規則、外部控制介面與服務化執行。進階設定應遵循兩個原則：每個新增功能都能說明要解決什麼問題，每個遠端來源都能說明由誰維護。不要為了複製別人的完整設定而一次啟用大量 DNS、腳本與規則集；複雜設定的故障邊界更廣，且上游變更可能使舊欄位失效。閱讀設定時，先看連接埠與模式，再看 DNS，接著看代理群組與規則，最後查看進階實驗選項。

對於伺服器或路由器，建議分開規劃 Mihomo 程序權限、設定目錄與管理介面。管理介面只繫結至可信任位址，限制設定檔的讀取權限，服務重新啟動後檢查日誌，升級時保留上一個可正常工作的核心檔案。對桌面與行動裝置而言，重點是控管背景權限、避免多個 VPN 競爭、及時清理失效訂閱與過期規則。無論平台如何變化，核心排錯方法都相同：確認流量是否進入核心，確認 DNS 與規則如何處理，再確認策略群組與節點是否完成連線。

至此，可以將 Clash 的使用流程歸納為一條穩定路線：選擇與系統相符的用戶端，完成最小權限安裝；匯入並驗證訂閱；使用 Rule 模式建立分流基準；透過連線紀錄驗證規則；確有需要時再啟用 TUN 與 Fake-IP；依週期更新訂閱、檢查日誌並備份自訂設定。遇到具體操作問題，回到快速入門依主線執行；需要完整用戶端套件清單時，前往Clash 下載頁面選擇對應平台。