Clash 完整使用指南

階段 01 / 建立觀念

核心觀念：客戶端、核心與連線路徑

先分清介面與實際負責轉送的程式

在 Clash 生態系中，客戶端通常是具備視窗、系統匣選單與設定檔管理功能的應用程式；核心則負責讀取設定檔、建立代理連線、比對規則及處理 DNS。mihomo 是這個生態系中持續發展的核心。介面上的開關不代表核心具備的全部功能；同一個核心在不同客戶端中也可能使用不同名稱。遇到教學截圖不一致時，先確認設定的用途，不必硬找完全相同的位置。

將連線拆成幾個環節來看：應用程式發出請求，系統或應用程式設定決定是否將請求送到本機代理，核心依目前模式選擇處理路徑，代理策略再決定實際出口。訂閱只提供設定檔或節點資訊，不能取代上述步驟。匯入成功只代表客戶端接受了設定檔；開啟代理只代表入口已設定；網頁能載入才表示相關鏈路大致暢通，這三種狀態不能互相取代。

分清節點、策略群組與規則

節點包含伺服器位址、協定與驗證參數，用來描述連線至遠端服務的方式。策略群組會將節點或其他策略組合起來，提供手動選擇、自動偵測或故障轉移等功能。規則則決定特定連線應交由哪個策略處理。在手動群組中選好節點，不代表所有連線都會使用它；只有符合該群組規則的流量才會受這次選擇影響。排錯時必須同時查看命中的規則與最終出口。

完整設定檔通常包含本機監聽埠、代理節點、策略群組、規則與 DNS 等內容；節點清單則可能只有伺服器資訊。兩者都可能透過連結取得，但不能預設可以互換。客戶端支援解析某類節點清單，也不代表它會自動補上符合需求的分流規則。選擇訂閱格式時，請確認提供者給的是完整 Clash 設定檔，還是需要進一步整理的節點集合。

分清本機代理與遠端服務

本機混合連接埠是應用程式與核心交換流量的入口，不是遠端伺服器的連接埠。常見範例使用 mixed-port: 7890，但實際值由目前的設定檔與客戶端設定共同決定。別因為教學使用這個數字，就直接覆寫目前使用中的連接埠。遠端服務還取決於帳號狀態、協定支援與網路連通性；本機程式正常執行，不代表遠端也正常。

系統代理主要影響會讀取系統代理設定的應用程式；TUN 則透過虛擬網路介面接管符合路由條件的流量。兩者並非規則模式的替代方案，而是流量進入核心的不同入口。可以將入口與分流視為兩個面向：先確認請求是否進入核心，再確認進入後的流向。依這個順序排查，能避免把入口故障誤判為規則錯誤，也能減少不必要的 DNS 調整。

開始操作前，先記下作業系統、客戶端名稱、設定檔來源，以及想改變的連線行為。例如，指定瀏覽器使用代理、區域網路裝置維持直連，就比「所有功能都開啟」更容易驗證。代理軟體不等於匿名工具；遠端服務、目標網站與本機應用程式仍各自處理相關資料。只匯入可信的設定檔，並依所在地法規與網路管理規範使用；不要將網路入口開放給不需要的裝置。

階段 02 / 選擇工具

選擇客戶端：先看平台，再確認設定相容性

先確認目前裝置的使用情境

初次安裝可從 Clash Plus 開始，依下載頁面選擇對應平台。選擇時也要確認系統架構、支援的系統版本、訂閱格式及所需權限，不要只看軟體名稱。桌面客戶端適合管理設定檔與查看連線；行動裝置則更仰賴系統提供的網路延伸功能或 VPN 介面。若要在伺服器或路由器上長期執行，可考慮部署核心，但必須自行維護服務與設定檔。

Windows 使用者可依序了解 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu；Clash for Windows 已停止維護，僅供封存參考。尋找 Clash for Windows 替代方案時，先保存原有訂閱來源與自訂規則，再確認新客戶端是否支援相同設定。舊軟體的資料夾結構與介面設定通常不能直接照搬；遷移時應保留的是設定內容，而非複製所有應用程式資料。

macOS 可選用 Clash Plus、Clash Verge Rev、FlClash；ClashX Meta 已停止維護，僅供封存參考。Apple Silicon 與 Intel 的安裝套件不同，請先在「系統資訊」確認晶片類型。更換客戶端時，也要檢查舊程式是否仍在登入時啟動，避免兩個系統匣應用程式反覆修改系統代理。由單一程式管理代理入口，系統設定才容易保持一致，也更容易確認退出後的還原狀況。

了解行動裝置與 Linux 的差異

Android 可考慮 Clash Plus、Clash Meta for Android、FlClash 和 Surfboard。請注意，Surfboard 使用的設定格式與 Clash YAML 不同，不能把所有訂閱連結都當成通用輸入。選擇前先確認提供者的格式說明。系統顯示 VPN 圖示，通常只表示本機網路介面已建立；不能單憑圖示判斷流量已抵達預期的代理出口，還需實際測試應用程式的連線。

iOS 使用者可先查看 Clash Plus 的 App Store 頁面，並透過官網 clashplus.io了解產品資訊。系統網路延伸功能、背景執行時間與應用程式沙盒都會影響設定路徑，不能照搬桌面版的服務安裝步驟。Linux 圖形桌面可優先考慮 Clash Verge Rev，再了解 FlClash；依發行版選擇套件格式，並分清系統代理設定與整個系統的路由接管。

依實際功能需求選擇

如果設定檔使用較新的協定、規則提供器或 DNS 參數，請確認客戶端搭載的核心能解析這些欄位。客戶端名稱中有 Clash，不代表所有擴充語法都相同。匯入時若出現「不支援的欄位」，先對照核心文件與目前的設定格式，不要直接刪除整段內容。刪掉參數或許能讓設定檔通過解析，卻也可能改變原有的安全設定或分流行為。

對多數新手來說，設定檔容易匯入、錯誤訊息清楚、系統代理可以還原，比功能開關的數量更重要。若需要排查應用程式分流，連線詳細資訊、規則命中狀況與程序辨識能力會更實用。筆電和手機則還應測試休眠喚醒、網路切換及背景執行策略。先列出實際需求，再安裝一款候選程式進行驗證即可，不必為了比較介面一次裝好所有客戶端。

選定客戶端後，保留目前可用的安裝套件與匯出的自訂設定，並記下訂閱更新方式。之後遷移時，先在新程式中確認設定檔可正常解析，再停用舊程式的流量入口，最後啟用新程式的入口。依這個順序交接可減少斷線，也能避免誤將連接埠衝突當成新軟體無法使用。實際套件類型、平台入口與維護狀態，請以下載頁面的最新說明為準，不要依舊版截圖推測。

階段 03 / 建立執行環境

安裝與權限：確認核心啟動及連接埠使用狀況

先正常啟動，再處理進階權限

下載符合系統架構的安裝套件，先關閉仍在執行的同類客戶端，再依系統提示安裝。首次啟動時先不要開啟 TUN、區域網路存取或自動啟動等選項；先確認介面能正常開啟、核心可以執行，且能進入設定檔頁面。將安裝、設定檔解析與系統流量接管分開處理，之後發生錯誤時才能判斷問題出在哪一層，而不是在一堆同時開啟的選項間反覆嘗試。

Windows 上的圖形介面與背景服務可能分開執行。TUN 或部分系統層級操作需要客戶端提供的服務模式或系統管理員授權，但一般介面不必因此長期以最高權限執行。若服務安裝失敗，先查看應用程式記錄與系統提示，確認安全軟體是否阻擋了相關操作。不要下載來源不明的修復指令碼，也不要為了完成安裝而直接關閉整套系統防護。

macOS 使用時，應先將應用程式移至適合長期使用的位置，再啟動並依系統提示確認來源與網路相關權限。系統代理需要修改網路服務設定；TUN 可能還需要額外權限，實際情況取決於客戶端的實作。若無法啟動，請確認應用程式來源、晶片架構與系統相容性，不要直接複製網路上的權限繞過指令；不同系統版本的授權位置可能不同。

檢查行動裝置授權與 Linux 服務

Android 首次連線通常會要求建立 VPN 連線；確認要求來自目前使用的客戶端後再授權。如果另一個應用程式已使用系統 VPN 通道，兩者可能無法同時接管網路，請先決定要保留哪一個。iOS 也需要依系統提示授權相關網路設定。完成授權後，回到客戶端查看執行狀態；系統跳出授權視窗，不代表訂閱與出口也已準備就緒。

Linux 圖形應用程式能開啟，不代表它可以順利修改桌面代理或建立虛擬介面。依客戶端說明設定服務權限，避免對整個安裝資料夾開放過寬的寫入權限。部署核心時，應明確設定服務帳號、設定檔目錄、工作目錄與記錄檔的歸屬。不要直接將下載套件所在位置當成長期工作目錄，否則清理下載檔案時，可能同時刪除正在使用的規則檔和設定檔。

確認混合連接埠，不要反覆修改數字

啟動記錄若顯示位址已被占用，先查明是哪個程序占用了連接埠。可能是舊客戶端尚未退出、同一程式的另一個執行個體，甚至是無關服務。確認後只保留需要的執行個體，或替目前客戶端選擇未使用的連接埠。更改連接埠後，也要同步調整瀏覽器擴充功能、命令列環境變數及手動代理設定；只改核心端，應用程式仍可能連到舊入口。

# Windows PowerShell：查看範例連接埠的監聽記錄
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux：查看範例連接埠的監聽記錄
ss -ltnp 'sport = :7890'

# macOS：查看範例連接埠的監聽記錄
lsof -nP -iTCP:7890 -sTCP:LISTEN

這些指令只能協助查看本機監聽狀況；部分程序資訊可能需要額外權限才能顯示。看到監聽記錄後，請搭配程序名稱與客戶端記錄確認其歸屬，不要直接結束不熟悉的系統程序。沒有監聽記錄也不一定表示安裝損壞；核心可能仍在等待有效設定檔，或實際使用了其他連接埠。先查看設定頁面與記錄中的目前值，再決定是否調整執行環境。

最後測試退出後能否還原：選擇可接受短暫中斷的時段退出客戶端，確認系統代理是否已正確清除，再重新開啟應用程式。若退出後瀏覽器無法連線，且系統仍指向本機代理連接埠，表示入口尚未還原。優先透過系統網路設定關閉殘留代理，再重新啟動客戶端並排查退出流程。設定完成前應測試一次，避免日後將正常退出後的狀況誤認為網路故障。

階段 04 / 準備有效設定

訂閱與設定檔：匯入、啟用並保留本機修改

先確認輸入格式，再開始匯入

開啟客戶端的設定檔或訂閱頁面，選擇從 URL 匯入，貼上可信來源提供的完整連結。下載前先確認複製的內容沒有前後空格、換行或通訊軟體附加的標點符號。訂閱網址可能含有帳號存取憑證，不要貼到公開討論區或不可信的線上轉換網站。截圖時應隱藏完整網址，尤其不能只遮住網域而留下後面的敏感參數。

匯入本機檔案時，請選擇有效的 YAML 設定檔，並確認檔案不是由網頁另存而來，或被系統加上了額外副檔名。完整設定檔、Base64 節點清單和單一分享連結的結構各不相同，客戶端能否接受取決於匯入功能。需要分辨格式時，請閱讀訂閱 URL、本機 YAML 與 Base64 格式說明，不要反覆修改副檔名來嘗試相容。

下載完成後，還要在設定檔清單中選取並啟用這份設定檔。部分客戶端可以同時儲存多份訂閱，但核心實際上只會載入目前選取的設定檔或合併後的結果。確認頁面上的目前使用標記，再查看代理頁面是否出現預期的策略群組。顯示設定檔名稱只代表記錄存在；如果核心回報解析錯誤，仍應從記錄找出欄位、縮排或參照名稱的問題。

了解 YAML 結構與策略參照

YAML 以空格表示層級，不可任意混用定位字元。陣列項目通常以連字號開頭，欄位名稱與值之間必須使用符合語法的分隔方式。含特殊字元的文字可以用引號括起來，但必須成對閉合。排查時先查看記錄指出的位置及其前後幾行，因為錯誤往往是上一行漏了符號。不要直接把整份設定檔貼到公開平台；節點密碼與驗證資訊也可能藏在更深層的結構中。

# 最小直連範例：用來了解層級，不包含遠端代理節點
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

此範例適合用來了解結構，但所有連線最後都會直連，不應拿來取代預期要連線至遠端服務的訂閱。規則中的策略名稱必須已存在於設定檔中，大小寫與文字也必須相符。日常修改建議使用客戶端提供的覆寫、合併或擴充功能，實際名稱因應用程式而異。直接修改下載產生的設定檔，可能在下次更新訂閱時被覆蓋，讓設定「自動消失」。

安排更新，並準備處理失敗情況

自動更新間隔是維護設定，不是連線速度設定。有些介面以分鐘計算，有些則以秒計算，輸入前務必確認單位。例如介面明確使用分鐘時，輸入一千四百四十表示一天；不能將這個值直接貼到要求秒數的提供器欄位。也不建議以極短間隔持續向伺服器發出請求；頻繁更新無法修復格式不相容，還可能觸發提供者的請求限制。

更新失敗時，先分辨是網路逾時、驗證失效、收到網頁內容，還是設定檔解析錯誤。逾時要檢查連線路徑；驗證失效要確認帳號與訂閱網址；收到網頁可能是登入頁或錯誤頁面；解析錯誤則要檢查格式與核心支援範圍。「透過代理更新」只有在現有代理仍可使用時才有幫助；若目前設定檔已失效，可能需要暫時改用直連，或採用提供者支援的其他更新方式。

每次更新成功後，確認目前使用的設定檔仍已啟用，再測試策略群組的選擇是否如預期保留。另行保存一份不公開分享的可用設定檔以便復原，並備份自訂規則。更完整的錯誤排查方式請參閱訂閱更新失敗與自動更新間隔設定。先恢復可用連線，再整理失敗原因，比起不斷刪除並重建訂閱，更能保留排查線索。

階段 05 / 確認流量入口

代理模式：分清系統代理、規則與全域模式

先決定請求如何進入核心

匯入設定檔後，先選擇可用策略，再啟用系統代理，並用一般瀏覽器發出一次新的連線請求。開啟連線清單，查看是否出現對應網域與處理策略。如果網頁連不上且完全沒有連線記錄，應優先檢查系統代理和瀏覽器自己的代理設定，而不是先修改規則。瀏覽器擴充功能、應用程式內的獨立代理與系統設定可能互相覆蓋，務必確認目前請求實際使用哪個入口。

系統代理通常會將支援此設定的應用程式導向本機位址與連接埠，但不保證所有程式都會遵循。命令列工具、遊戲、背景服務及部分商店應用程式可能使用自己的網路堆疊。Windows 上的 UWP 應用程式還可能受到迴圈存取限制影響，不能把所有相關錯誤都歸因於訂閱。有需要時可查看客戶端提供的迴圈存取設定或系統說明，但只調整確實有需求的應用程式，不要批次開放所有應用程式的權限。

依用途選擇規則、全域或直連模式

規則模式會依設定檔中的條件分配連線，適合日常分流；全域模式通常會將進入核心的連線交由全域策略處理；直連模式則讓進入核心的連線直接存取目標。這裡的「全域」不代表系統上的所有流量都已被接管：未進入核心的請求，不會因為選擇全域模式就自動改道。先確認入口，再選擇模式，是整份指南中最重要的排錯順序之一。

全域模式適合短時間進行對照測試。某個目標在規則模式下失敗、全域模式下成功，代表值得檢查規則或其相關策略；但不同出口也可能造成 DNS、連線重用等差異，不能直接認定只有某一條規則有問題。測試結束後應還原原本的模式，並關閉舊連線或重新啟動相關應用程式，讓後續請求依新設定建立，避免舊工作階段影響判斷。

使用明確指定的代理進行對照

本機混合連接埠確認為七八九零時，可使用以下指令明確指定代理。指令中的目標是公開範例網站，只用來確認是否能建立連線。Windows PowerShell 使用 curl.exe可避免某些環境中同名命令別名造成的差異。若連接埠不同，請替換成目前使用的值。指令成功只代表這次請求的路徑可用，不能據此推斷所有應用程式或目標都正常。

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

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

明確指定代理後可以連線，但瀏覽器仍失敗時，請檢查瀏覽器擴充功能、獨立代理設定與快取連線；兩者都失敗且記錄中有請求時，接著檢查策略選擇、節點可用性及目標存取限制。若記錄中沒有請求，則重新確認連接埠、核心是否執行，以及請求是否確實送出。不要只根據瀏覽器顯示的一般錯誤頁面判斷，因為同一提示可能由解析失敗、連線遭拒或遠端中斷引起。

命令列環境變數也可能留下舊的代理入口。排錯時，請檢查目前終端機是否設定過 HTTP_PROXY、HTTPS_PROXY或 ALL_PROXY，以及應用程式是否會讀取這些變數。修改變數通常只會影響新啟動的程序，已執行的程式可能仍保留舊值。不要為了讓單一終端機使用代理，就修改所有工作階段的全域設定；先在一個終端機中驗證，再決定是否永久保存。

完成本章後，應能說明哪些應用程式使用系統代理、哪些需要明確設定代理，以及目前模式的作用範圍。若仍遇到「已連線卻無法開啟網頁」，請依照系統代理、連接埠占用與規則排查清單逐項檢查。每次只修改一個變數，並記錄修改前後的結果，避免一次切換模式、節點和 DNS 後失去比較依據。

階段 06 / 控制連線流向

規則分流：依序比對並確認實際命中結果

先了解比對順序，再設定條件

規則清單通常由上而下比對，第一條符合條件的規則會決定處理策略，最後再由預設規則處理其餘流量。因此規則並不會因為「條件越具體」就自動優先，位置同樣重要。將涵蓋範圍很廣的條件放在前面，可能導致後面的細分條件永遠不會生效。修改前先寫清楚目標：哪些網域要直連、哪些交由特定策略群組處理，以及沒有符合規則時要如何處理。

網域規則與 IP 規則比對的對象不同。DOMAIN比對指定網域，DOMAIN-SUFFIX用於比對網域後綴，IP-CIDR針對 IP 網段，GEOIP則依賴地理資料庫。網域後綴規則不等於任意字串包含條件，也不會自動涵蓋與網站相關的所有獨立資源網域。同一個頁面可能會連線至登入、圖片、介面等不同主機，需依實際連線記錄補上判斷條件。

先從容易理解的最小規則開始

以下片段示範常見的規則順序，必須合併到既有的完整設定檔中，而且其中的 PROXY必須是已定義的策略或策略群組。範例會將某個網域後綴交給代理、讓私有網段直連、對中國大陸 IP 使用直連規則，最後再以代理作為預設策略。這只是用於學習的分流結構，不代表適合原樣套用至所有網路環境，尤其應依區域網路路由與服務提供者的建議調整。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - 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
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve可避免為了比對這條 IP 規則而主動進行網域解析；它不會關閉整份設定的 DNS，也不代表目標永遠不會取得 IP。若連線已有可用位址，仍可能進行位址比對。是否使用此選項，取決於希望如何處理網域請求與解析成本。地理資料庫則必須有可用的資料來源；若資料庫缺漏或過舊，相關規則的行為也可能不如預期。

保留區域網路存取與服務探索

路由器管理頁面、印表機、檔案伺服器和企業內網通常需要維持直連，但不能只靠幾個私有網段解決所有問題。內網可能使用專用網域、分流 DNS 或其他位址範圍；跨子網存取還會受到實際路由影響。內網網域無法連線時，應分別確認網域解析與目標位址是否可連通，不要直接將整個頂層網域設為直連，以免連帶改變無關服務的流量路徑。

規則提供器適合管理大量規則，但必須分清規則行為類型與檔案格式。網域集合、位址集合和傳統規則集合的寫法不同，參照時指定的類型也必須與內容相符。使用前先確認來源可信、更新週期合理，以及下載失敗時是否仍有本機可用資料。不要直接疊加不熟悉的大型規則集，因為重複條件、範圍過廣和更新覆蓋都會讓命中結果越來越難判斷。

透過連線詳細資訊確認結果，不只看設定檔文字

每次調整規則後，先確認設定檔已重新載入，再為目標建立新連線，查看連線詳細資訊中的網域、目標位址、命中規則與最終策略。有些應用程式會重用長連線，規則文字變更後，舊連線不會立即切換出口。有需要時，只關閉相關連線或重新啟動測試中的應用程式，不必清除所有系統網路設定。請用新請求驗證結果，不要以已載入頁面中的快取內容作為依據。

若目標仍未依預期分流，先確認請求是否帶有網域資訊，再檢查規則順序、策略名稱，以及設定檔是否被訂閱更新覆蓋。程序規則也取決於平台功能與程序辨識條件，不適合直接在所有裝置間同步。新增規則時盡量縮小涵蓋範圍，並加上用途註解；過一段時間後，刪除已失去依據的臨時規則，比不斷堆疊例外更容易維護。

階段 07 / 擴大接管範圍

TUN 與 DNS：先接管流量，再確認解析

確認是否真的需要啟用 TUN

需要讓不讀取系統代理的應用程式進入核心時，再考慮使用 TUN。它透過虛擬網路介面與路由設定擴大流量接管範圍，但能否涵蓋特定流量，仍取決於系統權限、路由、協定支援與客戶端實作。不要把 TUN 當成「修復所有網路問題」的開關。在系統代理路徑已確認可用後再啟用 TUN，才能清楚比較差異；若發生問題，也能迅速退回原本的入口。

啟用前，先記下目前使用的 VPN、容器、虛擬機與企業網路工具。這些工具可能同時修改路由或 DNS，並用時必須確認由誰負責預設路由、由誰處理內網存取。若啟用後內網斷線或遠端連線不斷循環，先關閉 TUN 以恢復原狀，再檢查路由衝突。不要同時修改網卡優先順序、防火牆與解析服務，否則很難判斷是哪個步驟真正影響結果。

了解幾個常見的 TUN 參數

auto-route用來讓核心自動設定相關路由，auto-detect-interface可協助選擇出口介面，dns-hijack則用於接管符合條件的 DNS 請求。這些選項並非不受平台限制、開啟後就一定有效。筆電從有線網路切換至無線網路後，出口辨識與路由可能需要重新建立；請依客戶端提供的方式重新連線或重新啟動核心，不要反覆重新匯入訂閱。

# 合併至支援這些選項的 mihomo 設定檔中
# 需要相應的系統權限；啟用前請保留原有設定
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

這段內容不是完整訂閱，也不適合略過客戶端本身的 TUN 管理機制後直接貼上。設定中的解析服務必須能從目前網路連線，核心也必須能完成該服務網域的初始解析。範例中的虛構位址池用於內部對應，不是遠端代理伺服器位址；若與目前環境的位址範圍衝突，請先閱讀相關設定說明，再決定是否調整範圍或過濾條件。

分辨解析失敗與連線失敗

DNS 負責將網域名稱與存取目標連結，不能只靠更換解析伺服器來修復節點驗證失敗或連接埠占用。fake-ip 模式會為請求配置用於對應的位址，讓核心保留網域關聯；redir-host 通常會回傳解析後的實際位址。兩者在相容性與處理路徑上有所不同，沒有適用於所有裝置的固定答案。部分區域網路應用程式、特殊偵測程式或直連服務可能需要個別設定例外。

nameserver、fallback與相關過濾設定各有用途；備用解析並不是簡單地「主要伺服器故障時才查詢一次」。最終結果會依選擇邏輯與過濾條件而定，設定前應先了解目前核心的處理方式。不要隨意堆疊多個解析位址，以為數量越多就越穩定。需要逐項了解欄位時，請閱讀mihomo DNS 設定與 fake-ip 說明，再將修改範圍限於明確的問題。

瀏覽器或應用程式自行使用的加密 DNS，可能繞過一般的五十三連接埠請求路徑，因此 DNS 劫持不代表能控制所有解析。排錯時應記錄應用程式是否啟用了獨立解析，並與系統解析路徑比較。不要只為了查看記錄就長期關閉所有應用程式的安全功能；應在可控的測試中確認差異，了解影響後再決定統一使用解析設定，或保留應用程式自己的策略。

啟用後分三步驗證：先確認一般網頁能否正常開啟，再查看原本不使用系統代理的目標應用程式是否出現在連線清單中，最後測試區域網路與休眠喚醒。行動裝置還需觀察背景執行策略與耗電情況，相關取捨請參閱手機背景執行與 TUN 常駐說明。若只有啟用 TUN 時出現異常，先切回已驗證可用的入口，再根據路由與記錄資訊繼續排查。

階段 08 / 保持可復原

日常維護：備份、更新與故障排查順序

為可用狀態保留復原點

將維護項目分為應用程式、核心、訂閱與本機覆寫四類。應用程式升級可能改變介面與系統整合；核心升級可能改變欄位支援或預設行為；訂閱更新會替換遠端內容；本機覆寫則保存個人分流設定。最好分別記錄這四類內容，不要同一時間全部更新。發生異常時，能指出最後變動的是哪一類，往往比一大段未整理的記錄更有幫助。

備份不應只保存訂閱網址，也要記錄目前的策略選擇、自訂規則、DNS 例外、混合連接埠及客戶端的系統整合設定。部分匯出功能不包含系統服務、登入啟動項目或本機規則檔，需依應用程式說明另外備份。備份可能含有存取憑證，請存放在受控位置，不要公開分享，也不要使用雲端公開連結作為長期設定檔散布方式。

讓每次更新都成為可驗證的變更

更新前先保存目前的設定檔，並選在能接受短暫斷線的時段操作。更新後檢查核心啟動、設定檔載入、一般瀏覽器連線、重要應用程式與區域網路服務，再決定是否清理舊檔案。若遇到欄位淘汰或解析行為變更，先閱讀版本變更說明並找出相關設定區段。不要為了啟用所有功能而同時開啟新選項；穩定運作的基準設定比功能清單更值得參考。

自動啟動也需要確認執行順序。應用程式隨登入啟動，不代表網路已準備就緒；網路尚未連線時，訂閱與規則提供器更新失敗，也不一定代表設定檔已損壞。請確認網路恢復後能否重新更新，必要時使用客戶端支援的延遲啟動或重試選項。筆電從休眠恢復後若發生問題，應比較出口介面、系統代理與核心狀態，不要一開始就刪除所有訂閱。

依入口、核心、出口、目標的順序排錯

第一步確認入口：核心是否正在執行、連接埠是否在監聽，以及應用程式是否真的使用該入口。第二步確認設定檔：目前啟用的是哪一份，是否出現解析錯誤，策略群組參照是否有效。第三步確認出口：同一策略下的遠端服務是否可用，是否有驗證或協定錯誤。第四步確認目標：其他網站與應用程式是否正常，異常是否只發生在特定網域或網路。

記錄應針對一次可重現的失敗來收集。先記下時間與操作，再送出請求並保留前後相關行。暫時提高記錄等級有助於觀察，但長期啟用詳細記錄可能增加寫入量，也可能包含存取網域；排查結束後應恢復為適合日常使用的等級。分享前請隱藏訂閱網址、驗證資訊與不希望公開的網域，不要只截取最後一行通用錯誤訊息而漏掉前面的原因。

處理網路切換與退出後的殘留設定

從家用網路切換至辦公室網路時，DNS、驗證入口網站與存取限制可能同時改變。先完成網路本身要求的登入；必要時暫時關閉代理入口，確認直連路徑可用後再恢復設定。企業環境可能明確禁止代理或 VPN，請遵守相關管理規定，不要透過反覆更換連接埠或隱藏程序來規避政策。只有在目前網路允許的路徑可用時，後續的客戶端測試才有意義。

退出客戶端後若無法連線，優先檢查殘留的系統代理；重新啟動系統後仍無法連線，也要檢查自動啟動程式與持續生效的環境變數。發生故障時，先保留明確的復原方式，例如關閉系統代理或停用 TUN，不要立刻重設所有網路元件。一般問題可繼續查閱常見問題；提交問題時請附上系統、客戶端、入口方式、重現步驟與已完成的對照測試，不必公開整份設定檔。

階段 09 / 逐步擴充

進階學習路線：提供器、自動策略與部署限制

先掌握設定層次，再加入自動化功能

能穩定使用，不代表還需要繼續增加功能。進階學習應從具體問題出發：節點較多時，學習代理提供器；規則更新頻繁時，學習規則提供器；遠端裝置需要長期執行時，學習服務管理。每個階段都保留最小可用設定檔與獨立測試目標，避免從網路複製一份含有大量未知欄位的設定檔，再靠隨機切換開關來猜測其行為。

代理提供器會將節點來源與主要設定檔分開，方便更新與重複使用，但必須確認來源格式、儲存路徑、更新週期，以及引用它的策略群組。提供器下載成功，不代表節點已實際使用；策略群組還必須引用對應名稱。健康檢查也需要可連線的測試目標，結果只代表該測試路徑，不代表所有業務請求都成功，更不能據此推論實際連線速度。

了解自動選擇的測量範圍

手動選擇群組的行為最容易觀察；自動測速群組、故障轉移群組與負載平衡群組則各有用途。自動選擇依賴測試條件，故障轉移依賴可用性判定，負載平衡則涉及不同連線的分配方式。不要只看名稱就把各種群組層層疊加。先確認目標應用程式是否需要固定出口，例如必須維持工作階段的服務，再判斷自動切換會不會造成額外登入或連線中斷。

測試間隔、逾時與容差會共同影響自動策略。間隔太短可能增加網路請求與行動裝置耗電；間隔太長則可能延後偵測路徑變化。如果目前網路無法連線至測試位址，整組結果都會失真。先用手動選擇確認基本連線正常，再啟用自動偵測；發生異常時，比較測試目標與實際服務目標，不要將所有失敗都歸因於節點品質。

將命令列核心視為獨立的部署工作

在伺服器或路由器上部署，還需處理執行帳號、服務啟動、設定檔權限、記錄檔輪替與網路轉送。桌面系統代理的使用經驗不能取代這些工作。直接執行核心，只會提供設定檔中已啟用的功能，不會自動將整個區域網路變成代理網路。旁路由或閘道器方案還涉及預設閘道、轉送、防火牆與回程路由，必須依設備拓撲規劃，不宜在正式網路上邊試邊改。

# 在已安裝 mihomo 的環境中檢查設定檔語法
mihomo -t -f ./config.yaml

# 指定工作目錄執行；該目錄需依設定檔準備相關資源
mihomo -d ./profile

語法測試通過只代表核心能接受相應設定檔，不代表遠端服務、DNS 與規則下載在執行環境中一定可用。檢查時盡量使用與正式執行相同的核心與工作目錄，並留意相對路徑參照。以服務方式啟動時，環境變數、權限與目前目錄可能與互動式終端機不同；若「手動執行成功，服務啟動失敗」，應優先比較這些環境差異。

限制管理介面與區域網路暴露

管理介面可供控制面板與自動化工具使用，但具備變更代理狀態的能力。只在確有需要時啟用，並優先限制為本機迴路位址，再依核心支援設定驗證方式。混合代理連接埠、管理介面與 DNS 監聽埠是不同入口；不要因為其中一個需要區域網路存取，就把其他入口也一併綁定到所有網路介面。對外開放前，還應透過主機防火牆限制來源。

讓其他裝置使用代理時，請逐項確認監聽位址、區域網路存取開關、驗證方式與防火牆規則。不能假設共用網路上的每台裝置都可信，也不要直接將連接埠轉發到公網。路由器上的長期部署還要考慮裝置重新啟動、儲存空間，以及規則資源更新失敗時的處理方式。先在隔離的測試環境驗證，再考慮將其作為長期網路入口，避免一次設定錯誤影響整個網路。

建議依序學習：先讀懂目前的設定檔，再獨立修改規則，接著了解 DNS 與 TUN，最後處理提供器與服務部署。每個步驟都要回答三個問題：要解決什麼問題、如何確認設定生效，以及怎麼還原。如果需要重新確認基礎流程，請回到入門指南；若要更換工具，請查看客戶端下載頁面。能說明一條連線的入口、命中規則與最終出口，就是從會用進步到可維護的關鍵。