Clash 用戶端與訂閱設定完整指南

一、核心概念：用戶端、核心與設定

連線會經過哪些環節

Clash 生態系並非所有程式都採用相同介面。用戶端提供匯入設定、選擇模式、調整系統設定及檢視日誌的入口；核心則負責接收連線、解析規則並建立對外連線。兩者通常隨安裝套件一同提供，但更新步調不一定一致。確認功能是否支援時，除了查看介面是否有相關選項，也要確認實際執行的核心能否辨識對應欄位，不能只憑用戶端名稱判斷。

一筆連線可依序理解為應用程式、接入方式、核心、規則及對外連線。應用程式可能主動使用本機代理連接埠，也可能透過系統代理設定轉送要求；啟用 TUN 時，流量也可能由虛擬網路介面接管。核心收到要求後，會依模式和規則決定直連、拒絕，或交由某個策略組處理。理解整條流程，才能判斷網頁連線失敗是發生在應用程式接入、網域解析，還是遠端連線階段。

訂閱不等於完整設定

訂閱 URL 是取得遠端資源的網址，不是連線開關。回傳內容可能是完整設定，也可能只是供代理服務提供者使用的資源檔。完整設定通常包含代理、策略組、規則與 DNS；資源檔則只負責其中一部分。若把節點清單直接當成完整設定匯入，可能會遇到格式錯誤，或只有資源卻沒有可用的策略組。因此，匯入前應先確認提供者標示的格式，以及目標用戶端要求的格式。

設定檔通常以 YAML 表示階層，縮排本身具有意義。根層級欄位與子層級欄位不可任意互換；清單項目通常以連字號開頭，縮排應使用空格而非定位字元。同名欄位若重複出現，不同解析器的處理方式可能不同，建議主動合併，不要依賴後面的欄位覆蓋前面的內容。即使文字能成功解析，也不代表策略組引用、資源路徑與執行權限都正確；語法通過只是第一層檢查。

設定來源與執行狀態

用戶端中的原始訂閱、覆寫檔與最終生效設定應分開看待。遠端訂閱可能在更新時重新下載；覆寫機制則用來保存本機連接埠、規則或 DNS 調整；最終設定是用戶端合併後交給核心的結果。遇到設定還原、欄位未生效或規則順序改變時，應先檢查最終設定，而不是一再編輯下載後的暫存檔。不同用戶端合併陣列的方式各異，不能假設所有覆寫內容都會附加到原設定。

也要區分「設定已儲存」、「核心已載入」及「目標應用程式已使用代理」這三種狀態。編輯器顯示儲存成功，不代表核心接受了新內容；核心載入成功，也不代表瀏覽器或其他應用程式已接入。可靠的驗證方式是同時查看載入結果與連線紀錄，再由目標應用程式送出新的要求。既有連線可能繼續使用原本的出口；若觀察舊分頁或現有工作階段，容易把快取行為誤判為設定未生效。

二、用戶端選型：平台、核心與維護方式

先確認作業系統與使用情境

挑選用戶端時，先看作業系統，再確認處理器架構與使用情境。日常使用桌上型電腦或手機，建議優先選擇圖形介面；伺服器與路由器才考慮直接執行核心。本網站下載頁會優先列出支援平台上的 Clash Plus；若需要管理桌面端設定及使用 mihomo 相關功能，也可以比較 Clash Verge Rev 與 FlClash。推薦順序不代表各款功能完全相同，訂閱格式、接入方式與平台權限仍須逐項確認。

下載 Windows 版本前，可在系統設定查看系統類型，尤其要分辨 x64 與 ARM64。macOS 使用者須確認是 Intel 或 Apple Silicon，不能只依作業系統名稱選擇檔案。Android 可優先下載符合裝置架構的安裝檔；若不確定，再查看下載頁是否提供通用版本。Linux 除了處理器架構，還須考量發行版的套件格式與桌面環境；能夠安裝不代表系統匣、服務管理及權限提示的行為都相同。

功能相容性不能只看名稱

Clash、Clash Meta 與 mihomo 之間有所承襲與演進，但不能把它們視為永遠支援相同欄位的不同名稱。通訊協定、規則類型與 DNS 選項會隨核心實作而變化，網路上的設定也可能是為不同分支準備。更換用戶端前，先記下目前使用的核心功能，再逐項確認目標用戶端是否支援，尤其要留意代理提供者、規則提供者、指令碼功能及平台專屬的接入方式，不要一次搬入所有舊設定。

手機用戶端還需特別確認設定格式。Surfboard 的設定系統與 Clash YAML 並不相同，不能因為下載頁上都是代理用戶端，就把同一個檔案直接匯入所有應用程式。iOS 使用者可從下載頁前往 Clash Plus 商店頁面，並在官方網站 clashplus.io 確認產品資訊。應用程式支援哪些匯入方式，請以實際介面為準；桌面端欄位也不能直接照搬成行動裝置設定。

已封存用戶端與遷移成本

Clash for Windows 與 ClashX Meta 在下載頁中保留為已停止維護的封存選項，較適合用於舊環境相容與查閱舊設定，不建議只靠舊教學截圖作為新安裝的依據。選擇仍在維護的用戶端時，也應了解設定檔的儲存位置、日誌匯出方式，以及解除安裝後如何處理系統設定。能清楚備份與還原，比介面上的按鈕多寡更重要，特別是需要跨裝置遷移或長期維護時。

不要同時安裝多個用戶端後直接一起執行。不同程式可能會占用相同連接埠、系統代理或 VPN 通道，讓問題更難判斷。比較用戶端時，請使用相同設定、相同網路與相同應用程式依序測試，每次先結束前一個程式。記錄可成功運作的條件後，再決定要保留哪一款。安裝檔與平台入口請見用戶端下載頁；核心之間的關係可另讀Clash、Clash Meta 與 mihomo 差異說明。

三、安裝與檢查：權限、連接埠與首次啟動

安裝前先保留可還原的狀態

開始安裝前，先結束其他正在執行的代理用戶端，並記下系統原有的代理設定。如果裝置使用企業網路、校園網路或專用 VPN，請先確認管理規範，避免中斷正常的網路連線。曾安裝舊版用戶端的裝置，也要檢查背景處理程序與自動啟動項目；關閉視窗不一定會結束核心程序。首次安裝建議使用目前使用者可管理的一般路徑，不要一開始就加入複雜的目錄權限或同步磁碟設定。

Windows 安裝完成後，首次啟動時先保持 TUN 關閉，確認主畫面、設定頁與日誌頁都能正常開啟。遇到系統保護提示時，應確認下載來源與發布說明，不要直接關閉整套安全功能。安裝目錄需要寫入權限，與執行資料目錄需要寫入權限是兩回事；若用戶端能啟動卻無法儲存設定，請檢查資料目錄權限、磁碟空間，以及檔案是否正被同步工具或安全軟體占用。

macOS 請依目前軟體套件提供的方式完成安裝，再按照系統提示授予必要權限。移動應用程式的位置後，舊的啟動項目或背景服務可能仍指向先前路徑，因此建議先決定最終位置，再啟用自動啟動。Linux 請使用適合發行版的套件管理方式安裝；遇到相依性錯誤時，請查看套件管理器的輸出，分辨是缺少相依套件、架構不符，還是圖形環境問題，不要把所有啟動失敗都歸因於訂閱內容。

行動裝置權限與背景執行限制

Android 匯入設定前後可能需要授予 VPN 連線權限，這是系統建立網路接管通道所需的授權，與訂閱驗證無關。首次授權後，仍須在用戶端啟動連線。若鎖定螢幕後容易斷線，可檢查電池最佳化、背景活動與裝置製造商的自動啟動設定，但只授予目前功能確實需要的權限。iOS 同樣須依系統提示允許網路設定，並確認沒有其他 VPN 應用程式同時占用連線通道。

連接埠衝突與核心啟動

桌面端常見的本機監聽服務包括 HTTP、SOCKS 或混合連接埠。混合連接埠可同時接受相應的 HTTP 代理與 SOCKS 連線，但不是所有程式都會自動使用它。範例中的 7890 只是可選連接埠，不是所有用戶端都固定使用的數值。若日誌顯示位址已被占用，請先找出占用中的程序，再決定結束舊程式或更換連接埠；不要只修改應用程式的代理位址，卻忘了同步調整用戶端的監聽設定。

# Windows PowerShell：查看本機監聽連接埠
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS：查看 TCP 監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 監聽與程序
ss -lntp

檢查指令沒有輸出，只表示找不到相符的監聽服務，不能據此認定用戶端已損壞。連接埠可能不同，核心可能尚未載入設定，部分程序資訊也可能需要更高權限才能顯示。請先在用戶端介面確認實際連接埠與執行狀態，再比對日誌找出問題。若程序反覆結束，應優先檢查設定解析錯誤、資源路徑與權限提示，而非不斷重新安裝；重新安裝可能保留原有資料目錄，因此不一定能排除故障原因。

四、訂閱與更新：匯入、資源更新間隔與覆寫

依內容選擇匯入方式

在用戶端的設定或訂閱頁面選擇新增、匯入或類似功能，將完整訂閱 URL 貼到對應欄位。複製時請留意連結是否被通訊軟體自動換行、開頭或結尾是否混入空格，以及驗證參數是否完整。匯入成功後，還需要將該設定設為目前使用中。清單出現新項目只代表已建立記錄；是否已完成下載、解析及核心載入，仍須查看狀態提示與日誌，不能只憑名稱判斷。

匯入本機檔案時，用戶端通常會將 YAML 複製到管理目錄，也可能保留對原始檔案的參照，實際行為依用戶端而異。修改原始下載檔後，用戶端不一定會自動同步；相反地，某些編輯功能會直接修改目前管理中的檔案。匯入後請確認自己正在編輯哪一份內容，並保留原始檔案備份。如果提供者交付的是編碼節點清單或其他設定格式，應使用相容的匯入方式或可信的轉換工具，不能只改副檔名。

完整設定更新與資源更新

更新完整訂閱會取代遠端設定內容；更新代理提供者通常只會重新整理該提供者的資源；規則提供者則有獨立的下載週期。這三項可能由不同功能控制，更新其中一項不代表另外兩項也已更新。用戶端介面中的訂閱間隔可能以分鐘為單位，而 mihomo 的提供者 interval 欄位通常以秒為單位；不能將介面輸入值原封不動地搬進 YAML，也不能只憑一個欄位推斷整份設定的更新頻率。

# 本機代理提供者片段：合併前須併入現有設定
# 檔案內容必須符合目前核心的代理提供者格式
proxy-providers:
  local-resources:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 手動選擇
    type: select
    use:
      - local-resources

上述片段展示的是提供者與策略組之間的引用關係，不會自動建立資源檔。使用前須在核心實際使用的工作目錄中準備檔案，並確認用戶端有權存取該路徑。HTTP 類型的提供者還需要有效的資源網址、儲存路徑與更新間隔；網址必須來自可信來源，不能把管理網頁當成資源介面。若訂閱回傳的是 HTML、登入頁面或錯誤訊息，即使要求成功送達，也無法將其載入為 YAML 資源。

將本機修改保存於持久設定層

自訂連接埠、DNS 或規則，應盡量透過用戶端支援的覆寫、合併或延伸設定機制保存。直接修改遠端檔案，可能在下次更新時遭到取代；手動複製整份訂閱，則會失去遠端資源的更新能力。設定覆寫後，請檢查最終生效的設定，確認欄位層級與陣列順序符合預期。尤其是規則清單，有些機制會取代所有規則，有些則支援在前面或後面插入；兩者對預設比對規則的影響完全不同。

更新失敗時，先記錄失敗的對象與錯誤類型。驗證遭拒時，檢查連結是否有效及帳戶狀態；解析錯誤時，查看回傳內容與格式；連線逾時時，分辨是本機網路、網域解析還是下載路徑出了問題。有些訂閱下載需要透過目前的代理，而目前代理又依賴這份訂閱，可能形成啟動相依問題。可在可信任的網路環境中還原已知可用的設定後再更新，切勿將敏感 URL 貼到公開轉換服務或排錯網站。

五、代理模式：接入開關與對外連線判斷

系統代理不等於規則模式

系統代理、TUN 與規則模式屬於不同層次。系統代理決定支援該系統設定的應用程式如何將連線交給本機連接埠；TUN 提供另一種流量接入方式；規則、全域與直連模式則決定核心收到連線後如何選擇出口。因此，切換成全域模式不會自動接管未使用代理的應用程式；開啟系統代理也不代表所有要求都會經由遠端出口。排除問題時，必須先確認連線是否已進入核心。

日常使用通常從規則模式開始，由網域、位址或其他條件決定連線去向。全域模式適合暫時確認特定出口是否可用，但仍須在策略組中選對目標。直連模式有助於判斷問題是否來自遠端連線路徑；不過，若應用程式根本沒有接入核心，這項比較就沒有診斷價值。比較不同模式時，請使用相同應用程式與目標，並建立新連線，避免將網路環境變動誤認為模式差異。

建立可重複測試的連線要求

驗證系統代理時，先檢查用戶端的監聽位址與連接埠，再確認應用程式是否另有獨立代理設定。瀏覽器擴充功能、終端機環境變數及開發工具內建設定，都可能覆蓋系統預設值。終端機指令不一定會因桌面系統代理已啟用，就自動採用相同路徑；可透過明確指定參數進行測試。以下指令會將要求明確送至本機混合連接埠；若使用不同連接埠，請一併修改。目標網站僅用於建立簡單的 HTTPS 要求。

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

收到回應表示這次要求透過指定連接埠完成相應連線，不代表一定使用了遠端代理。實際出口仍取決於目前的模式與規則，請在用戶端連線頁面確認。若指令無法連上本機連接埠，先檢查監聽服務與程序；若出現憑證錯誤，請檢查系統時間、憑證環境及目標網站，不要將略過憑證驗證當成日常解法。狀態碼也須依回應來源判讀，不能一概認定是節點故障。

模式變更與連線生命週期

切換模式或策略組主要影響之後建立的連線，既有長連線可能繼續沿用原本路徑。瀏覽器連線池、即時通訊工作階段與下載工作尤其容易保留舊連線。需要嚴格驗證時，請在應用程式中重新送出要求；必要時關閉目標連線或重新啟動該應用程式，而不是立刻清空整份設定。若用戶端支援主動中斷連線，請確認中斷範圍，避免影響仍在傳輸的重要工作。

結束用戶端後網頁無法開啟，常見原因是系統代理仍指向已停止監聽的本機連接埠。先到系統網路設定中關閉殘留代理，再確認是否有其他程式重新寫入設定。若使用終端機環境變數，也須清除目前工作階段中的代理變數。恢復直連後，再重新啟動用戶端以找出退出流程的問題；反覆切換規則或全域模式，無法修復核心已結束後本機連接埠無法連線的狀況。

六、規則分流：比對順序與資源管理

從最精簡的規則集開始

規則模式通常依照清單順序由上而下比對，先符合的規則就會決定要求的去向。因此，規則內容正確但位置不對，仍可能永遠不會生效。特定網域或需要優先處理的條件，應放在較廣泛的條件之前；預設的 MATCH 規則應放在最後。新增規則前，先查看連線詳細資訊中的目前命中項目，再決定插入位置；不清楚原有順序就直接新增，往往只會讓檔案變長，實際結果卻不變。

網域規則與位址規則處理的情境不同。DOMAIN 用來比對指定網域，DOMAIN-SUFFIX 可涵蓋網域本身及其子網域，IP-CIDR 則依位址網段判斷。若應用程式直接連線至 IP，或網域資訊未傳入核心，預期的網域規則就可能無法命中。此時應檢查連線紀錄中的目標資訊，而不是不斷為同一個網域新增重複規則。規則所需的比對資訊必須確實存在。

# 最精簡的規則範例，不包含遠端代理資源
mode: rule
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

這段設定用來說明順序與語法，所有未命中的要求最後都會直連，並不是完整的代理方案。若要將特定類型的要求交給自訂策略組，必須先定義該策略組，再將規則目標設為完全相同的組名。名稱中的空格與大小寫都必須符合設定中的實際內容。no-resolve 表示不要只為了這項位址規則主動觸發網域解析；這不代表整筆要求永遠不會進行 DNS 查詢，也不代表停用所有位址比對。

分開管理策略組與規則集

策略組負責選擇出口，規則負責選擇策略組。手動選擇組適合需要明確控制目前出口的情境；自動測試或故障切換組則取決於測試目標、間隔與判斷方式。某個測試目標可以連線，不代表實際使用的服務也一定正常；不同應用程式可能受到通訊協定、地區、驗證或遠端限制影響。不要只憑單項測試結果取代實際服務驗證，也不要為了追求表面上的即時變化而把測試間隔設得過短。

規則較多時，可透過規則提供者分開管理，但必須選擇符合資源行為類型的設定。網域清單、位址清單與包含完整規則條件的資源檔格式各不相同，不能只更換下載網址。定義提供者後，還須透過對應規則引用它，否則即使檔案下載成功，也不會參與分流。請一併確認路徑、名稱與行為類型；若資源解析失敗，是否保留舊資源或載入失敗，取決於用戶端與核心狀態，應透過日誌確認實際結果。

依命中結果排查分流問題

排查時，先記錄目標網域、實際目標位址、命中規則與最終策略組，再考慮修改設定。一個網頁通常會同時要求主網站、靜態資源及驗證介面等多個網域，只修正主要網域不一定能讓整個頁面正常載入。可逐項確認哪些要求失敗，而不是把整項服務都歸因於同一條後綴規則。存取區域網路裝置時，也應確認目標實際使用的網段；範例中的私有網路範圍不一定涵蓋所有家庭、企業或虛擬網路位址。

更新規則時也要留意資源來源與供應鏈風險。選擇來源清楚的規則資源，了解其涵蓋範圍，以及更新後是否會改變流量去向。合併多組大型規則集時，重複與重疊條件可能增加維護難度；規則數量變多不代表分流更精確。建議先保留少量明確需求，再依連線紀錄補上例外；每次新增規則，都應記錄適用目的，並在更新後確認重要應用程式仍依預期運作。

七、TUN 與 DNS：網路接管與解析範圍

先確認是否真的需要 TUN

TUN 透過虛擬網路介面接入流量，適用於不遵循系統代理設定的應用程式，但它不是解決所有網路問題的通用開關。啟用後需要協調路由、權限、DNS 與其他網路軟體，複雜度高於單純使用本機連接埠代理。建議先確認一般代理流程正常，再啟用 TUN 並比較接入範圍。行動裝置的系統 VPN 介面與桌面端虛擬網卡，在權限與實作方式上並不相同，不能直接照搬同一套操作步驟。

桌面用戶端可能透過服務元件取得建立介面與修改路由所需的權限。啟用前應確認服務狀態及系統提示，不要只看開關是否變色。若同時使用企業 VPN、容器網路或其他通道，路由優先順序與 DNS 接管可能發生衝突。測試時先保留一種接管方式，並記錄原本的路由行為；遠端操作裝置時尤其要準備還原通道，避免修改路由後失去管理連線。

# mihomo TUN 範例：合併前確認用戶端服務與平台支援
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

這段設定不是所有平台都適用的通用開關。auto-route 用於自動設定相關路由，auto-detect-interface 用於協助判斷對外連線介面，實際結果仍會受到系統與網路環境影響。若用戶端已透過介面管理這些欄位，請選擇一種持久的設定方式，避免不同覆寫彼此覆蓋。切換 Wi-Fi、有線網路或熱點後若連線異常，請檢查介面偵測結果與路由是否已更新，而不是直接更換訂閱。

DNS 與 Fake-IP 的設定關係

DNS 會將網域名稱轉換成位址，也為網域分流與出口選擇提供判斷資訊。系統 DNS、瀏覽器的加密 DNS、用戶端內建 DNS 及遠端解析可能同時存在，必須先確認查詢實際使用哪條路徑。TUN 接管傳統 DNS 連接埠，不代表所有應用程式內的加密解析也會被接管。僅憑某個檢測頁面顯示的解析器，就判定所有要求都外洩或解析完全正確，證據都不足。

Fake-IP 模式會為網域配置虛擬位址，核心再透過映射還原網域名稱並處理連線。這些位址並非網站的實際伺服器位址，因此看到虛擬位址本身不代表解析錯誤。部分區域網路探索、裝置驗證或特殊通訊協定可能不適合這種行為；遇到確實的相容性問題時，可針對特定網域設定排除項目，不必立刻放棄整個模式。排除範圍越廣，行為越難判斷，建議從單一目標開始驗證。

DNS 上游、代理伺服器的網域解析與直連要求的解析之間，也可能存在啟動相依關係。若 DNS 上游必須經由代理，而代理伺服器的網域又依賴同一個上游，就可能形成循環。設定時應明確區分哪些解析用於建立代理連線、哪些用於一般網路服務，並依目前核心支援的欄位分別設定。不要將來源不明的上游清單全部堆在一起；伺服器數量增加不代表結果更一致，反而可能增加延遲與排錯難度。

確認接管範圍與結束後還原

啟用 TUN 後，先確認原先未進入核心的目標應用程式是否出現連線紀錄，再檢查規則與 DNS 行為。若區域網路存取異常，請檢查網段路由、位址衝突與網域排除項目；若只有切換網路後異常，請檢查對外連線介面與 DNS 快取。停用 TUN 後，應確認虛擬介面、自動路由與系統 DNS 都已還原。還原前不要繼續加入新規則，以免將接管問題誤判為分流問題。

八、日常維護：更新、備份與分層排錯

分別更新不同項目

日常維護至少要區分用戶端、核心、完整訂閱、代理提供者與規則資源。更新用戶端主要影響介面、整合功能及平台相容性；更新核心會影響通訊協定與網路行為；更新資源則會改變設定內容。某個更新功能顯示完成，不代表所有項目都處於相同狀態。建議先更新資源並確認正常，再安排程式更新，避免多個層面同時變動，難以判斷相容性問題的來源。

更新程式前，先備份目前設定、覆寫內容與重要選項，並記錄接入方式和連接埠。備份應包含還原所需資訊，但不要上傳至公開儲存庫或聊天群組。用戶端的匯出功能可能不包含系統服務狀態、外部檔案與環境變數，還原前應確認備份涵蓋範圍。若使用檔案型提供者，也要備份相對路徑所對應的檔案；只保存主設定卻漏掉資源目錄，遷移後可能出現語法正常但找不到資源的問題。

依故障發生位置縮小範圍

網頁無法開啟時，先結束用戶端並還原系統設定，再確認基本網路是否正常。若基本網路也無法使用，應先處理 Wi-Fi、閘道、驗證頁面或電信網路問題。基本網路恢復後，再檢查本機連接埠是否正在監聽、應用程式連線是否進入核心、規則是否命中，以及對外連線是否成功。依此順序排查，就能區分「尚未接入」與「接入後失敗」，避免漫無目的地切換所有設定。

訂閱更新失敗與服務連線失敗可能彼此無關。訂閱介面可能因驗證過期而失敗，但現有設定仍能建立連線；對外連線也可能失效，而訂閱介面仍可下載。記錄問題時，應明確寫下失敗對象、執行的動作與錯誤類型。日誌中的逾時、連線遭拒、解析失敗與驗證失敗代表不同狀況，不能一律解讀為網路速度太慢。日誌過長時，先縮小至一次可重現的操作，再擷取對應時段的資訊。

速度、延遲與應用程式體驗

連線測試中的延遲，只代表特定目標與測試方式下的一次結果，不等於實際下載速度、穩定度或所有網站的使用體驗。排查速度問題時，固定網路環境與測試目標，分別比較直連、不同出口及目標應用程式的實際傳輸狀況。無線訊號、同時下載工作、遠端限制與路徑壅塞都可能成為瓶頸。持續重複測速也可能消耗資源；觀察一般服務的實際表現，通常比追求單一測試數字更有參考價值。

若只有一個應用程式異常，優先檢查該程式的代理設定、網域解析與連線快取。若所有應用程式同時異常，再檢查核心狀態、接入通道或上游網路。若只有規則模式異常、全域模式正常，請著重檢查命中規則、策略組與相關 DNS 路徑。每次比較都應維持其他條件不變，並記錄還原方式；「重新啟動後就正常」雖可暫時排除問題，仍須保留重新啟動前的錯誤資訊，才能繼續追查原因。

還原流程與日常紀錄

建議保留一份已驗證可正常運作的基準設定，並記錄本機修改的目的、位置與還原方式。發生故障時，先匯出必要日誌，再還原最近一次修改；不要一開始就刪除所有資料目錄。確認用戶端可以正常結束、系統代理可以關閉、TUN 路由可以還原後，再套用基準設定。若問題只在新設定中出現，可逐項合併以找出觸發欄位，不要長期停用更新並依賴整份舊訂閱。

九、進階方向：設定分層與核心維運

從能連線進階到能解釋結果

進階設定不必從增加更多參數開始，應先做到能解釋一筆連線。選擇一個熟悉的應用程式，記錄它如何接入、存取哪些網域、命中哪條規則、選擇哪個策略組，以及是否使用預期的 DNS 路徑。能夠重複驗證這些環節後，再加入規則提供者、複雜策略組或獨立核心。功能越多，相依項目也越多；缺乏觀察方式時，增加功能只會讓錯誤更難發現。

設定可依資源來源、共用策略與本機差異分層管理。遠端資源負責需要持續更新的內容，共用策略則表達多部裝置一致的分流需求，本機層負責連接埠、路徑、介面與權限。這樣遷移時不必複製整份執行檔，也能降低訂閱更新覆蓋本機設定的風險。實際做法應依循用戶端提供的合併機制；通用的分層概念不代表所有用戶端都採用相同的覆寫語法。

直接執行核心前的準備

伺服器或路由器使用者可以直接執行 mihomo，但必須自行管理設定目錄、程序、日誌、權限與啟動順序。圖形用戶端原本代為處理的功能不會自動提供，尤其是系統代理、服務常駐與資源下載狀態顯示。先在前景驗證最基本的設定，再接入系統服務管理；啟動失敗時應保留標準輸出與錯誤輸出，避免背景程序靜默結束後只能看到連接埠無法連線。

# 先確認目前核心支援的參數
mihomo -h

# 在目前目錄檢查設定；通過後再以前景模式啟動
mihomo -t -d . -f config.yaml
mihomo -d . -f config.yaml

這些指令假設執行檔已位於系統搜尋路徑，且目前目錄包含設定及相關資源。-d 指定的工作目錄會影響相對路徑解析；若服務執行使用者與互動式終端機使用者不同，也可能導致讀取失敗。設定檢查只能找出部分語法與引用問題，無法證明遠端資源可連線、路由權限足夠，或實際服務連線成功。改用服務模式前，仍須完整驗證一次連線，並確認停止與還原步驟。

區域網路、控制介面與路由器部署

若要讓其他裝置使用本機代理，必須一併考量監聽位址、允許區域網路連線的設定及防火牆範圍。只開放連接埠並不代表設定完成，也不應將代理連接埠直接暴露在公網。請優先限制可連線的信任網段，必要時設定驗證，並確認用戶端實際支援的方式。外部控制介面應另外加以保護，避免將設定管理功能與一般代理入口混為一談；控制介面可存取哪些功能，應依核心說明確認。

路由器部署還須考量主路由或旁路由的角色、用戶端閘道、DNS 派發與回程路徑。旁路由上執行核心，不代表區域網路裝置已將流量交給它。先確認裝置從何處取得閘道與 DNS，再檢查透明接管流程，最後才加入分流設定。若家用網路中已有多個 DHCP 服務，應先排除位址派發衝突。部署方式概覽可參閱在 OpenWrt 旁路由上執行 mihomo，不要直接把桌面端設定當成完整的路由器方案。

持續維護的驗收標準

自動更新應形成「設定檢查、成功載入、失敗還原」的完整流程，而不是定時下載後直接覆蓋。資源下載失敗時保留已知可用的檔案；設定檢查失敗時停止發布；重新載入後再驗證重要連線。維護規則時應保留變更紀錄，但含有憑證的資源不可提交至公開儲存庫。若需要版本管理，可只記錄已遮蔽敏感資訊的規則與覆寫邏輯，並透過受保護的本機設定提供敏感資料。