Clash 使用手冊

一、核心概念與流量路徑

用戶端、核心、節點與訂閱

Clash 並非單一安裝套件的名稱。實際使用時，圖形化用戶端提供設定頁、代理頁、連線清單與系統開關；核心則負責接收連線、解析目標、比對規則並建立對外連線。mihomo 是這個生態系中常見的核心。介面看起來相似，不代表核心功能完全相同；要確認某個欄位是否生效，應同時檢查用戶端如何產生設定，以及核心是否支援該欄位。

節點是一組連線至遠端服務的參數，通常包含伺服器位址、連接埠、通訊協定與驗證資訊。用戶端本身不等於節點服務，安裝完成也不會自動取得可用線路。訂閱則是取得設定或節點清單的更新管道。訂閱連結通常包含存取憑證，應像密碼一樣妥善保管；截圖、日誌與求助內容都不應公開完整連結。

設定檔會將這些項目組織起來：入站連接埠接收本機流量，節點描述遠端出口，策略組將出口整理成可選清單，規則則決定某次連線使用哪個清單。訂閱可能提供完整設定檔，也可能只提供節點清單。匯入成功後，應確認實際產生了哪些項目；不能只因設定頁出現一個名稱，就認定連線已準備就緒。

先確認流量接管，再檢查分流

一次連線可分成兩個問題。第一，應用程式的流量是否進入核心，通常由系統代理、應用程式自己的代理設定或 TUN 負責。第二，流量進入核心後如何連到外部，則由規則、策略組與節點決定。因此，連線清單完全沒有記錄，與已有記錄但遠端逾時，屬於不同層面的故障。前者先檢查流量接管，後者再檢查規則、DNS 解析與出口。

系統代理只是提供代理位址給願意遵循系統設定的應用程式，並不會替所有網路連線建立必經通道。瀏覽器可能會遵循設定，但某些遊戲、命令列工具或背景服務可能不會。TUN 透過虛擬網卡與路由擴大接管範圍，但仍會受到路由排除、應用程式行為與系統權限影響。要判斷流量接管是否成功，應查看連線記錄，而不只是觀察開關狀態。

用四個檢查點建立判斷依據

開始排錯時，依序確認目前設定已啟用、核心正在執行、應用程式連線已進入核心，以及命中的策略能完成連線。每一步都應留下可觀察的結果，例如設定頁的啟用狀態、日誌中的監聽資訊，或連線頁顯示的目標網域與策略鏈。缺少哪項證據，就停在相應層面檢查；不要同時修改 DNS、節點與規則，以免不同變更互相干擾。

也要區分延遲測試與實際服務連線。用戶端測試通常只會向特定測試位址送出請求，結果只能說明該測試路徑是否可通，無法證明所有網站、影音服務或登入介面都能使用。後續應以實際需要的應用程式驗證，並記錄時間、網路環境與錯誤狀況。比較不同設定時，才能確認測試的是同一條連線路徑，而非兩個無關情境。

二、用戶端與平台選擇

依作業系統、架構與維護狀態篩選

初次使用可優先考慮 Clash Plus，再依平台比較其他用戶端。選擇時先確認作業系統與處理器架構，不要只看介面截圖。Windows 常見裝置使用 x64，部分裝置採用 ARM64；macOS 要區分 Intel 與 Apple Silicon；Android 則須確認安裝套件支援的指令集。架構不符可能導致無法安裝、啟動失敗或必須透過轉譯執行，不能只憑副檔名判斷。

作業系統版本需求請以下載頁及用戶端目前的說明為準。不要因為同樣是 Windows 或 Android，就假設所有版本都能執行同一個安裝套件。下載前也要確認安裝權限、磁碟空間，以及是否允許建立虛擬網卡。由組織管理的裝置可能限制網路擴充功能與服務安裝，遇到這種情況應先向裝置管理員確認規範，不要把權限限制當成節點故障而反覆更換線路。

桌面版與行動版的差異

Windows 使用者通常可先透過系統代理測試瀏覽器，再決定是否啟用 TUN。macOS 除了晶片架構，也要留意系統要求授權應用程式與網路擴充功能的提示。Linux 桌面環境對系統代理的支援不盡相同；開關生效不代表終端機程式也會遵循。伺服器或路由器可直接執行 mihomo，但服務啟動、設定路徑、監聽範圍與日誌管理都需自行處理。

Android 用戶端通常透過系統 VPN 介面接管流量，因此不能照搬桌面版的系統代理操作步驟。首次啟動時須授權 VPN，持續執行也會受到省電策略影響。Surfboard 的設定語法與 Clash YAML 不同，選用前應確認訂閱提供相容格式，不能只改副檔名。背景執行設定可參閱Android 耗電與背景執行設定說明。

iOS 可選用 Clash Plus，並透過App Store 產品頁面查看系統需求；產品官網為 clashplus.io。授權 VPN 設定後，還須匯入相容設定並確認實際連線。手機上顯示 VPN 圖示，只代表相關網路介面正在使用，無法證明訂閱有效或所選出口可連線。

選擇時也要考量遷移成本

Clash for Windows 與 ClashX Meta 已停止維護，適合作為既有環境的參考，不建議作為新裝置的預設選擇。舊用戶端能夠啟動，不代表支援目前訂閱使用的通訊協定與欄位。遷移前先記錄原有規則、策略選擇與區域網路設定，再將設定獨立匯入新用戶端；不要直接覆寫舊目錄，以免遺失復原所需資訊。

同一台裝置可以保留多個用戶端進行比較，但測試時只執行一個負責接管流量的執行個體。多個系統代理開關、VPN 介面或 TUN 路由同時運作，會讓流量歸屬難以判斷。各平台的安裝入口都在用戶端下載頁；選定候選用戶端後，先完成基本連線測試，再比較快捷鍵、覆寫方式與連線面板，不必一開始就搬移所有進階設定。

三、安裝與初步檢查

安裝前記錄本機網路狀態

先結束正在執行的代理用戶端與 VPN，確認一般網路可以連線至平時使用的網站。記下系統代理是否已啟用、是否手動設定 DNS，以及裝置是否連上組織網路。安裝後若出現異常，才有明確的復原基準。如果裝置原本依賴組織提供的代理上網，不要直接清除原設定；先保存位址與連接埠，並確認能否同時使用其他網路工具。

從下載頁取得符合裝置架構的安裝套件，依照作業系統的安裝流程完成部署。桌面版的安裝權限與日常執行權限是兩回事：安裝服務可能需要管理員授權，但使用系統代理不一定需要。不要為了排除所有可能性，讓用戶端長期以最高權限執行。需要 TUN 時，再依用戶端說明安裝輔助服務，並確認服務來源與安裝目錄屬於目前使用的用戶端。

首次啟動時，先找出設定、代理、連線與日誌四個區域。設定頁決定目前使用哪份檔案；代理頁選擇策略組出口；連線頁顯示流量是否進入核心；日誌頁則提供載入與連線錯誤資訊。各區域的位置可參照用戶端介面分區說明。此時可先不啟用開機自動啟動、區域網路分享與 TUN，減少初始變數。

確認監聽連接埠與系統代理

匯入有效設定後，確認核心是否正常啟動，以及混合連接埠是否正在監聽。混合連接埠通常可同時接收 HTTP 與 SOCKS 代理請求，實際連接埠由目前使用的設定決定。以下是獨立的入站與直連測試設定，不包含代理節點，無法用來驗證遠端代理服務。使用前確認本機連接埠未被其他程序占用，測試完成後請切回自己的設定。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

rules:
  - MATCH,DIRECT

系統代理的伺服器位址應指向本機監聽位址，連接埠則須與目前核心設定一致。只修改 YAML 中的連接埠，不一定會同步變更用戶端寫入系統的代理設定。若發生連接埠衝突，可在用戶端支援的設定位置調整；調整後須再次確認兩端一致。切換不同設定檔也可能改變有效連接埠，因此不要憑記憶讓所有應用程式固定指向舊值。

在有 curl 的環境中，可執行以下命令並明確指定本機 HTTP 代理。收到 HTTP 回應，代表此請求至少經過指定的入站並完成連線；遠端回傳的服務狀態仍須另行判斷。如果瀏覽器連線失敗、命令卻成功，應優先檢查瀏覽器擴充功能、個別代理設定與既有連線，而不是立刻重裝用戶端。

curl -I --proxy http://127.0.0.1:7890 https://example.com

Windows UWP 回送與例外情況

部分 Windows 應用程式容器受到回送存取限制，無法像一般桌面程式一樣連線至本機代理。常見情況是瀏覽器正常，但某個商店應用程式沒有連線記錄。先確認該應用程式確實使用系統代理，再考慮使用用戶端提供的 UWP 回送工具。只替確有需要且可信任的應用程式設定豁免，並記錄變更項目；回送豁免並非修復所有商店應用程式網路問題的通用開關。

初步檢查完成的標準是：設定檔載入正常、監聽連接埠明確、測試請求有記錄，且結束用戶端後網路能恢復。如果用戶端異常結束後，瀏覽器仍指向本機連接埠，先關閉殘留的系統代理，再檢查背景程序。安裝問題與節點問題應分開記錄：前者確認程式能否執行，後者確認目前設定能否建立預期的出口連線。

四、匯入訂閱與設定管理

先辨識訂閱內容，再選擇匯入方式

在設定頁選擇新增遠端設定、從連結匯入或類似功能，貼上服務提供者提供的相容訂閱連結，並設定容易辨識的本機名稱。複製時留意不要混入空格、換行或通訊軟體附加的標點。匯入前先確認連結用途：網頁管理網址、購買頁面與訂閱網址是不同資源；能在瀏覽器開啟網頁，不代表它就是核心能解析的設定。

下載完成後，檢查設定是否包含節點、策略組與規則。有些連結只會回傳編碼後的節點清單，需要用戶端明確支援這類匯入方式；有些則會回傳完整 YAML。遇到格式錯誤時，先查看錯誤行附近的內容，確認收到的是設定檔，還是登入頁面或錯誤頁面。不要把含有憑證的訂閱交給不明的線上轉換服務，因為對方可藉此取得訂閱內容。

啟用設定與匯入設定是兩個動作。設定清單新增項目後，還要將它設為目前使用的設定，等待核心重新載入，再到代理頁確認策略組是否出現。如果用戶端顯示載入失敗，請保留上一份可用設定，不要連續匯入多份同名副本。先確認此次下載內容是否完整、欄位是否相容，再決定要修正格式或聯絡設定提供者。

將遠端來源與本機調整分開管理

遠端設定更新時，直接修改訂閱檔案的內容可能會被覆蓋。需要長期保留的區域網路規則、DNS 設定或策略補充，應優先使用用戶端支援的覆寫、合併或指令碼擴充功能。這些功能的合併順序並不一致，尤其要留意規則是附加在前還是後、清單是取代還是合併。儲存後請檢查最終生效的設定，而不只是編輯框中的原始文字。

若暫時不使用覆寫機制，可以複製一份本機設定作為練習，但要了解本機副本不會自動同步遠端節點變更。建議將原始訂閱、測試副本與已驗證副本命名區分，並記錄近期修改目的。日後若更新造成異常，就能判斷問題來自上游內容變更，還是本機規則覆寫原有行為，不必從頭重建整份設定。

訂閱更新失敗時的分流處理

先區分下載失敗與解析失敗。下載失敗可能是網路無法連線、憑證時間異常、連結失效或伺服器拒絕；解析失敗通常發生在已收到內容之後。查看日誌中的錯誤類型與時間，不要只看紅色狀態提示。若裝置時間明顯不正確，先校正時間；若服務回報權限或使用額度問題，請到服務管理頁面確認帳號狀態，而不是反覆修改 DNS。

也要確認更新請求使用哪條連線路徑。部分用戶端可選擇直接更新，或透過目前代理更新；若目前設定已失效，依賴它更新可能形成啟動上的循環依賴。可在可信任的網路環境下嘗試另一種更新方式，但不要假設所有用戶端的操作入口都相同。每次只更動一種更新方式，保留其他設定；確認下載階段恢復後，再檢查新設定是否可用。

更新成功後仍須繼續檢查。上游可能更改節點名稱、調整策略組或更新規則，導致舊的手動選擇失效。請依序檢查目前使用的設定、策略組選項與實際連線。需要簡短操作步驟時，可回到訂閱匯入指南；本章的維護原則是讓遠端來源可更新、本機差異可追蹤，並在出問題時能夠回復。

五、代理模式與策略組

規則、全域與直連的適用範圍

規則模式會依照設定中的規則決定出口，適合需要區分本機服務、一般網站與代理目標的日常情境。全域模式通常會將進入核心的連線交由全域策略處理，方便判斷問題是否來自分流。直連模式則讓進入核心的連線直接連出。模式只會影響已進入核心的流量；全域模式不會自動接管忽略系統代理的程式，也不能取代 TUN。

排錯時可短暫切換至全域模式作為對照：若同一目標在全域模式正常、規則模式失敗，先檢查規則命中狀況與策略組選擇；若兩者都失敗，再檢查節點、DNS 解析與網路。比較時應使用相同節點，並重新建立連線。既有長連線可能繼續使用原本的出口，單純按下重新整理不一定會建立新連線；可先關閉相關應用程式再測試。

直連模式也不等於「關閉用戶端」。系統代理與 TUN 仍可能啟用，連線仍會由核心接收並處理。若要恢復不經用戶端的原始網路路徑，須關閉相應的流量接管功能，並確認系統代理與 VPN 介面狀態。了解這個差異，就不會在用戶端仍控制網路路徑時誤判為系統網路損壞，也能理解為何直連模式下連線清單仍會留下記錄。

策略組：選擇出口，不只是選節點

策略組可以包含節點，也可以引用其他策略組。手動選擇組適合固定出口；自動測試組會依測試結果挑選候選項目；故障轉移組則依設定順序尋找可用項目。自動選擇的實際行為也會受到測試網址、測試間隔、容差與核心實作影響。不要把自動策略理解為所有目標都會選到最快線路；它只會根據設定的探測條件進行選擇。

以下是可加入既有有效設定的策略組片段。練習用設定只有直連與拒絕兩個內建策略，因此雖然可以載入，卻不會提供遠端代理。實際使用時，應將已確認的節點加入候選清單，並讓規則引用相同的組名。名稱的大小寫、空格與字元都必須一致；若規則引用不存在的組，可能導致設定驗證失敗或無法達成預期分流。

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,出口選擇
  - MATCH,DIRECT

設定中出現 PROXY，不代表這是核心強制保留的唯一代理名稱。它通常只是作者自訂的策略組名稱，也可以叫出口選擇或其他名稱。了解名稱與功能的關係後，多層策略也會更容易理解：服務規則先進入服務組，服務組再選擇地區組，地區組最後選取節點。排錯時應展開完整策略鏈，不能只看第一層的組名。

依使用情境驗證節點選擇

選擇節點時，應同時考量實際連線能力、服務的地區需求、線路穩定度，以及服務端的流量計費方式。延遲低只代表探測路徑較短或回應較快，不表示持續下載速度一定較快。測試影音、會議或遊戲時，應觀察服務一段時間內的實際表現，不要直接比較不同時間、不同網路環境下的單次結果。

部分服務對出口變更很敏感，自動策略在背景切換節點可能導致重新驗證或工作階段失效。此時可為該服務設定獨立的手動選擇組，固定出口，再讓一般瀏覽使用自動選擇。更多比較方法請見節點延遲、倍率、地區與通訊協定的選擇說明。先確認一個節點穩定可用，再增加策略層級，維護成本會低得多。

六、規則分流與比對驗證

依照由上而下的順序讀取規則

規則分流的基本原則是由上而下比對，第一條符合的規則會決定連線使用哪個策略。因此，精確的例外規則通常應放在範圍較廣的規則之前，最終兜底規則則放在最後。若網域已符合前面的網域後綴規則，後面更精確的項目通常就沒有機會生效。新增規則前先檢查現有順序，避免以為多加一條就能覆蓋原有行為。

網域規則仰賴核心取得目標網域。應用程式若直接連線至 IP，或目標資訊在接管過程中遺失，預期的網域規則就可能無法命中。此時連線頁可能只顯示目標位址，須搭配 DNS 模式、嗅探功能與應用程式行為判斷。不要一看到規則未命中就擴大整個網段的代理範圍，否則可能連本機裝置或原本直連的服務也一起導向代理出口。

先建立最精簡的規則，再逐項擴充

練習時先使用容易觀察的網域規則與直連兜底，確認順序及目標資訊正確，再加入代理組。以下片段適用於既有設定的規則區，保留回送與常見私有位址直連，並以示範網域驗證後綴比對。這不是完整的區域網路位址清單，也未涵蓋所有 IPv6 情境，不應視為適用所有網路環境的最終範本。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolve 可避免為了目前的 IP 規則主動觸發網域解析，但不代表整份設定停止使用 DNS。若連線目標已是 IP，仍可參與位址區段比對；如果目前只有網域且尚未取得位址，這條規則可能不會命中。地理規則則還需要資料庫與解析結果，應以目標 IP 的資料庫歸屬為準，而不是依網站營運者所在地推斷。

使用遠端規則集時，還要確認提供者名稱、格式、行為類型與更新時間。規則集有本機快取，不代表已成功更新；更新成功也不代表涵蓋目標網站所有相關網域。主網站、登入頁、圖片與 API 可能使用不同網域。應依實際連線記錄補上必要項目，而不是只新增瀏覽器網址列中的單一網域。

依據連線記錄驗證，而非猜測出口網頁

儲存規則後重新載入設定，發出新的請求，再到連線頁查看目標、命中規則、策略鏈與最終出口。查詢出口位址只能顯示該次查詢請求使用的出口，無法證明另一個應用程式使用相同策略。比較時最好選擇可重複的單一操作，例如重新開啟某個頁面或執行一次命令列請求，並在記錄出現後立即查看比對資訊。

如果自訂規則儲存後消失，請檢查是否直接編輯了遠端訂閱，或覆寫內容在合併時被取代。如果規則仍在卻沒有命中，請檢查排序、網域是否可見與是否沿用舊連線。如果已命中正確策略但連線失敗，就轉而檢查節點與 DNS，不要繼續堆疊規則。可搭配網速慢的分層排錯順序，避免把所有網路問題都歸咎於分流。

七、TUN 與 DNS 設定

系統代理穩定後，再擴大流量接管範圍

TUN 適合需要接管不遵循系統代理的應用程式，但會帶來虛擬網卡、路由與 DNS 路徑等新變數。桌面版應先透過系統代理確認設定與節點可用，再依用戶端說明安裝服務或授予網路權限。行動裝置透過系統 VPN 介面運作的方式與桌面服務不同，不要只按名稱尋找相同按鈕。能建立介面，不代表流量一定能正確轉送，兩者須分開驗證。

啟用前記錄現有 VPN、虛擬機器網路與容器網路，避免路由重疊造成連線繞道。啟用後先連線至一般網域，再檢查區域網路裝置、工作所需網路與原有 VPN。若只有區域網路無法連線，先檢查直連規則、排除路由與目標網段，而不是更換遠端節點。存取組織內部網域時，也可能需要保留專用 DNS 的解析路徑。

DNS、Fake-IP 與目標辨識

DNS 會將網域名稱轉換為位址，但代理連線不一定只由系統 DNS 決定。應用程式內建解析、瀏覽器安全 DNS、系統解析與核心 DNS 可能同時存在。排錯時先釐清請求實際交由哪一方處理，再決定要修改哪項設定。只更換上游位址，卻沒有讓請求進入核心 DNS，通常不會改變實際結果；加密 DNS 的首次連線也可能需要引導解析。

Fake-IP 模式會回傳一個供對應使用的位址，核心會保存該位址與網域的關聯，之後據此還原目標並比對規則。這個位址不是遠端伺服器的真實公開位址，不能用來判斷伺服器位置。某些依賴真實位址、廣播探索或特殊解析行為的應用程式，可能需要設定過濾例外。原理比較請參閱Fake-IP 與 Redir-Host 說明。

以下是適用於支援這些欄位的 mihomo 桌面環境的獨立直連測試設定。DNS 監聽使用本機高連接埠；TUN 自動路由與介面偵測仍需要系統權限。此設定僅用於了解欄位與檢查流量接管，不包含代理節點；組織內網、其他 VPN 或特殊路由環境應先評估是否衝突，不要直接覆寫正在使用的完整設定。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

rules:
  - MATCH,DIRECT

分別驗證路由與解析

dns-hijack 會接收符合條件的 DNS 流量，但應用程式若透過 HTTPS 等方式自行解析，不會因為設定了一般 DNS 連接埠攔截就自動改用其他解析方式。auto-route 負責自動設定相關路由，auto-detect-interface 則會嘗試辨識出口介面；遇到多張網卡、虛擬網路或預設路由變動時，仍可能需要手動檢查。欄位存在不代表目前環境一定能自動選對出口。

瀏覽器正常但其他應用程式失敗時，檢查應用程式的請求是否出現在連線頁；網域無法連線但已知位址可達時，優先檢查解析；啟用 TUN 後全面斷網時，先關閉 TUN 恢復原有路徑，再檢查服務權限、預設路由與重複接管。修改 DNS 模式後，應重新建立應用程式連線，必要時清除相關快取，避免用舊的對應資料驗證新設定。

最終驗收不只要確認網頁能開啟，也要測試休眠喚醒、網路切換與結束用戶端後是否能恢復。若關閉 TUN 後仍有異常，請確認輔助服務與虛擬介面是否正常結束，並檢查系統代理是否殘留。流量接管範圍越大，復原方式就越重要；保留一份已驗證的系統代理設定，能在複雜網路故障時提供明確的比較基準。

八、日常維護與復原

將更新分成三類

用戶端更新、核心更新與訂閱更新處理的問題不同。用戶端更新可能改變介面、服務與設定產生方式；核心更新會影響通訊協定與欄位支援；訂閱更新則會改變節點、策略或規則內容。每次維護盡量只更新一類，確認穩定後再進行下一類。若三者同時變更，出問題時很難判斷該回復哪一部分，也容易把設定差異誤認為程式缺陷。

更新前保存目前使用的設定、覆寫內容與重要選項，並記錄系統代理連接埠、目前的策略選擇、TUN 狀態與服務安裝狀況。備份應能還原實際執行狀態，而不只是保存介面截圖。更新後檢查最終生效的設定，尤其留意由用戶端自動管理的欄位；部分用戶端會以介面設定覆蓋 YAML，因此只比對來源檔案無法反映所有變更。

復原也應分層處理。訂閱變更可先切回已在本機驗證的副本；覆寫錯誤可暫時停用擴充功能；用戶端更新異常則依相應安裝說明處理程式與服務。不要直接用舊程式覆寫新設定目錄，因為設定結構或資料庫可能不相容。測試舊環境時請使用獨立備份，並確認沒有兩個執行個體同時占用相同連接埠或網路介面。

開機自動啟動與背景執行

開機自動啟動通常只代表啟動用戶端，不一定能確保核心、訂閱與系統代理都已就緒。應先在手動啟動的情況下完成驗證，再啟用用戶端提供的自動啟動選項。下次重新開機後，依序確認程式已啟動、目前設定正確、流量接管已如預期啟用，最後測試實際連線。如果系統代理先啟用而核心尚未監聽，啟動期間可能會短暫無法上網。

休眠喚醒與網路切換也是必要的測試項目。從 Wi-Fi 切換至有線網路、手機熱點或不同路由器後，預設網卡與 DNS 可能改變，TUN 也需要重新辨識連線路徑。若每次喚醒都失敗，請記錄介面變化與日誌時間，再依序嘗試重新啟動流量接管或核心。不要把週期性故障一概歸因於節點不穩，否則可能忽略本機路由復原問題。

Android 背景執行設定須配合裝置製造商的省電策略。先允許必要的背景活動，觀察鎖定螢幕後是否中斷，再決定是否將應用程式加入電池最佳化允許清單。不要一次開放所有應用程式權限，也不要為了減少常駐提示而破壞系統要求的前景執行機制。比較耗電量時，應盡量維持相近的螢幕亮度、網路與使用時間，並區分螢幕、無線訊號和代理流量各自的影響。

建立適量的日誌與復原清單

日常使用 info 等適當等級即可，遇到明確問題時再暫時提高詳細程度。記錄發生時間、目標應用程式、錯誤狀況與當時使用的設定，有助於縮小排查範圍。日誌可能包含瀏覽過的網域、節點位址與驗證資訊，公開前務必檢查。排查完成後，請恢復一般等級並清除不再需要的診斷檔案，避免長期累積敏感瀏覽記錄。

遇到「Clash 無法上網」時，先停止流量接管並確認原始網路，再切回已知可用的設定，接著檢查節點與訂閱狀態。若原始網路也無法使用，應先處理本機連線、路由器或電信業者問題。若只有單一應用程式失敗，查看它的代理行為與連線記錄；若所有代理目標都失敗但直連正常，再優先檢查節點、服務狀態與出口連線。

區域網路分享尤其需要定期重新檢查。允許區域網路連線會讓其他裝置有機會存取本機監聽連接埠，不能只因為連上家用 Wi-Fi 就忽略存取範圍。確實需要分享時，請設定驗證、限制防火牆的來源範圍，並在更換網路後重新確認。維護的目標不是永遠開啟所有功能，而是清楚掌握哪些功能正在影響目前裝置的網路路徑。

九、進階學習與獨立排錯

先管理設定差異，再導入自動化

進階設定的第一步是能說明目前的設定檔，而不是繼續堆疊更多來源。先區分由訂閱維護、由用戶端產生與本機手動維護的內容，並為每一類指定唯一的修改位置。如果同一個 DNS 欄位同時出現在介面設定、訂閱檔案與覆寫內容中，先確認最終優先順序再調整，否則每次重新啟動都可能讓人誤以為「修改沒有生效」。

接下來可學習節點提供者與規則提供者，將連線參數、策略邏輯與服務規則分開管理。拆分有助於獨立更新，但也會增加名稱引用、路徑、快取與下載依賴。初次使用時只拆分一小組內容，確認下載成功、格式正確且策略能夠引用後，再移轉其他內容。不要一次加入所有遠端資源，最後只憑一次啟動結果判斷是否完成。

自動測試與故障轉移也應以實際需求為出發點。對於需要維持登入狀態的服務，頻繁切換可能比延遲稍高更不理想；一般瀏覽則可能可以接受自動選擇造成的出口變更。測試間隔要兼顧流量與探測即時性，測試位址則應能穩定代表所需路徑。多個策略組重複探測同一批節點，也可能增加不必要的背景請求。

把重現過程整理成小型實驗

排查複雜問題時，先寫下預期：使用哪個應用程式、前往哪個目標、應命中哪條規則，以及最後應使用哪個出口。接著選擇最精簡的操作，例如開啟新的瀏覽器視窗瀏覽固定頁面，或使用明確指定代理的命令發出請求。每一輪只更動一個條件，並記錄是否有連線、命中哪條規則，以及在哪個階段出錯。這樣的結論可重複驗證，也方便向他人清楚說明。

可用三種環境進行比較：關閉流量接管的原始網路、使用系統代理的已知可用設定，以及使用 TUN 的相同設定。原始網路正常、系統代理失敗時，優先檢查入站與出口；系統代理正常、TUN 失敗時，優先檢查路由與 DNS 接管。若只有特定網域失敗，檢查相關網域、服務限制與規則鏈，不必重裝整套軟體。

進一步部署至伺服器與遠端管理前

直接執行 mihomo 時，圖形化用戶端原本代為處理的工作都須自行完成，包括設定目錄、工作目錄、服務帳號、日誌輪替與失敗後重新啟動。先在前景驗證設定可正常載入，再將其納入系統服務。服務成功啟動不代表流量接管已完成，還要確認監聽位址、路由與權限。路由器環境也須考量儲存空間、處理器架構與原有防火牆規則。

遠端控制介面可查看連線並修改策略，只應在確有需要時啟用，並限制於本機或受控網路，同時設定存取驗證。不要為了連接手機面板就直接暴露在公開網際網路上，也不要混淆控制連接埠與代理入站連接埠。分享設定前請移除驗證資訊；遠端管理出問題時，優先檢查存取範圍與驗證，而不是擴大監聽範圍碰運氣。

完成這個階段的標準，是能說明一次請求如何進入核心、如何取得目標資訊、如何命中規則，以及如何連到出口，並能在失敗時定位問題所在層級。若要重新走一次最精簡的操作流程，請參閱連線驗證指南；若要進一步了解特定機制，可從專題文章繼續查閱。每學會一項新功能，都應保留驗證記錄與復原方式，再開始下一項設定。