Clash 設定完整指南

核心概念：連線會經過哪些環節

Clash 的基本工作是接收應用程式的連線，並依據設定選擇出站方式。完整的使用環境通常包含圖形介面用戶端、代理核心、設定檔與遠端代理伺服器。安裝用戶端只是備妥本機工具，不代表已經有可連線的遠端節點。先釐清各自的角色，才能判斷問題出在安裝、訂閱、規則或網路本身，避免把所有連線失敗都歸咎於用戶端。

用戶端負責操作，核心負責連線

圖形介面用戶端提供訂閱管理、模式切換、日誌檢視與系統整合；核心負責解析設定、處理 DNS、執行規則並建立連線。mihomo 是 Clash 生態系持續發展的核心，常見的 Clash Meta 名稱與其演進有關。不同用戶端可能採用不同核心與封裝方式，因此介面名稱相似，不代表支援完全相同的設定欄位。排查問題時，應同時記下用戶端名稱與核心資訊。

設定檔描述本機監聽連接埠、節點、策略組、規則與 DNS 行為。訂閱通常是用來取得設定或節點資訊的網址，但不同服務提供的內容不一定相同：有些提供完整 YAML，有些只提供節點清單。用戶端能匯入其中一種格式，不代表能自動辨識所有格式。遇到解析錯誤時，先確認訂閱服務商標示的目標格式，不要反覆切換本機網路設定。

從應用程式到出站的處理流程

以瀏覽器開啟網頁為例，連線會先透過系統代理或 TUN 進入核心，再由規則判斷要直接連線，還是交由某個策略組處理；策略組接著選擇實際節點，最後由該節點連線至目標服務。DNS 可能在流程中的多個環節參與解析，實際情況取決於接管方式與設定。了解這條流程後，檢視日誌就有了順序：先確認連線是否進入，再查看命中的規則，最後檢查選用的出站。

直連是指由目前裝置所在的網路直接連線至目標，不代表流量沒有經過本機規則判斷。代理是指將連線交給指定出站，也不保證一定能連上目標網站。遠端伺服器故障、帳戶限制、目標服務拒絕連線或本機 DNS 異常，都可能導致已進入代理流程的連線失敗。延遲測試成功，只能表示特定測試請求完成，不能取代實際應用程式的驗證。

建立最精簡的驗證流程

學習時只使用一個用戶端、一份已啟用的設定與一個手動策略組。先記下未啟用代理時的網路狀態，再開啟系統代理，瀏覽一個可重複測試的頁面，並在連線清單中尋找對應網域。看得到連線及其出站，才表示本機接管流程已建立。不要同時啟用多個代理工具，它們可能搶用連接埠、系統代理設定或預設路由，讓測試結果難以判讀。

後續章節都會沿用這套驗證流程。如果看不到連線，回頭檢查入口設定；看得到連線但策略選錯，檢查模式與規則；策略正確但請求失敗，再檢查節點與目標網路。依照這個順序排查，比逐一嘗試所有開關更能保留有效線索，也可減少誤改正常設定。

選擇用戶端：先確認平台與設定需求

初次使用建議先從 Clash Plus 開始，完成安裝、訂閱與連線驗證後，再考慮其他介面或管理方式。選擇時重點不在用戶端名稱有多少，而在裝置系統、處理器架構、設定格式及所需的系統整合功能。各平台的安裝檔與可選項目請以下載頁為準；若要比較各款差異，也可參閱用戶端比較評測。

依裝置確認候選用戶端

Windows 可選 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu，以及適用於舊環境的 Clash for Windows。macOS 可選 Clash Plus、Clash Verge Rev、FlClash 與已封存的 ClashX Meta。Android 可選 Clash Plus、Clash Meta for Android、FlClash、Surfboard。iOS 建議先查看 Clash Plus 的 App Store 下載資訊；Linux 則可從 Clash Verge Rev 與 FlClash 中挑選適合發行版的套件。

Clash for Windows 與 ClashX Meta 已停止維護，適合用來了解舊設定或處理既有環境，不建議作為新裝置的首選。封存的用戶端可能缺少新協定、系統相容性修正或設定擴充支援。既有使用者遷移前，先備份訂閱來源與個人規則，再用新用戶端單獨匯入測試，不要直接覆蓋舊目錄；確認新環境能正常連線後，再移除舊程式。

架構與安裝套件不可混用

處理器架構會決定安裝檔能否執行。Windows 裝置請在系統資訊中確認系統類型；macOS 可在「關於這台 Mac」查看晶片或處理器；Android 則應依裝置支援的 ABI 選擇。Linux 除了確認 AMD64 或 ARM64，也要核對套件格式。同一個作業系統可能有多種安裝檔，不要只看檔案大小猜測。下載頁沒有對應架構時，也不要勉強改用其他架構的套件。

不要把「相容 Clash 設定」理解成每個欄位都能通用。例如規則提供器、特定 DNS 選項或協定參數，都需要核心支援；圖形介面也可能改寫部分欄位。Surfboard 使用另一套設定流程，匯入前應依照它支援的格式說明操作，不要預設能直接匯入完整 Clash YAML。換用戶端後若發生解析失敗，先比對格式與功能支援，再判斷訂閱是否損壞。

以相同條件比較遷移結果

比較兩款用戶端時，保持裝置、網路、訂閱、節點與測試目標一致，而且一次只執行一個接管網路的程式。先測試同一節點能否連線，再確認需要的功能是否可用。不要只憑一次延遲數值判斷優劣：測試 URL、逾時時間、是否重用連線及當時的網路狀態都可能不同。真正影響日常使用的是連線穩定度、規則是否容易理解，以及維護成本。

伺服器、路由器或需要自行管理程序的環境，可考慮直接執行 Mihomo 核心，但也必須自行處理服務管理、權限與控制介面的安全防護。一般桌面使用者先選圖形介面用戶端，比較容易查看狀態。iOS 使用者可在下載頁查看 Clash Plus，並透過官方網站 clashplus.io了解產品資訊；安裝後仍須匯入設定並授權連線。

安裝與檢查：先確認本機入口正常

安裝階段的目標是讓用戶端能啟動、核心能執行、本機連接埠能監聽，而不是立刻開啟所有網路功能。先從下載頁選擇正確的系統與架構，安裝後保留預設設定，並暫時關閉其他代理工具。首次啟動時記下程式資料目錄、目前的混合連接埠與日誌位置；匯入設定、處理連接埠衝突及備份遷移時都會用到這些資訊。

桌面平台的安裝順序

Windows 先正常安裝並啟動程式，確認主畫面沒有核心啟動失敗的提示，再匯入訂閱。系統詢問網路存取權限時，依實際使用情境選擇網路類型；不需要區域網路分享時，不必為其他裝置開放代理入口。若安裝在可攜式目錄，請確認目前帳戶能寫入設定與日誌。程式若放在唯讀目錄，可能會發生設定無法儲存、重新啟動後訂閱消失或更新失敗等問題。

macOS 請依安裝檔格式將 App 放到適當位置，再首次開啟。若遭系統阻擋，先確認下載來源與系統提示，不要透過大量停用安全機制來解決。需要 TUN 或背景服務的額外授權時，等基本連線驗證完成後再處理。Linux 請使用符合發行版的套件，並留意安裝時的相依性錯誤；若介面能啟動但核心立即退出，通常需要進一步檢查日誌中的權限或設定錯誤。

行動平台先確認連線授權

Android 首次建立本機 VPN 介面時會顯示系統授權提示，授權後才能透過此入口接管連線。系統通常限制同時啟用的 VPN 服務，因此其他 VPN、防火牆或使用 VPN 的過濾工具可能互相衝突。iOS 安裝 Clash Plus 後，依照系統提示新增連線設定並授權。兩種平台都應先在前景確認能正常使用，再觀察鎖定螢幕、切換網路與背景執行是否會影響連線。

不要把行動裝置上的 VPN 圖示視為已成功連上遠端節點，它只表示系統端的網路延伸功能或介面正在運作。節點無法連線、訂閱尚未啟用或規則設定錯誤時，圖示仍可能顯示。請以實際請求及用戶端連線紀錄為準。若 Android 在鎖定螢幕後頻繁斷線，再檢查省電政策、背景活動限制與應用程式自動啟動設定；不要一開始就同時修改多項系統權限。

辨識連接埠占用與啟動失敗

混合連接埠通常同時接收 HTTP 與 SOCKS 代理請求，實際數值請以用戶端目前設定為準。範例中的 7890 並非所有裝置的固定設定。若日誌顯示監聽位址已被占用，先關閉其他代理程式，再確認是否有舊的核心程序尚未結束。也可以改用空閒連接埠，但曾手動設定代理的瀏覽器、終端機與開發工具都必須同步修改，不能只改用戶端設定。

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

# macOS / Linux：查看正在監聽此 TCP 連接埠的程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

這些指令只用來檢查，不會自動排除衝突。若連接埠沒有監聽，接著檢查核心是否啟動、設定是否通過解析；若有監聽，請確認所屬程序，避免把其他服務誤認為 Clash。若終端機顯示無法使用該指令，可改用系統內建的網路或程序管理工具進行相同檢查，不必為了執行範例而安裝無關軟體。

安裝檢查完成時，應能找到日誌、確認核心狀態並知道本機代理連接埠。接下來應匯入訂閱，而不是先試用 TUN。Windows 防火牆、自動啟動與服務模式的詳細說明，請參閱Windows 安裝與設定完整流程；跨平台的首次啟動檢查則可查看初始設定檢查清單。

匯入訂閱：分清下載、解析與啟用

成功匯入訂閱需要經過三個獨立步驟：用戶端下載內容、核心能解析內容，以及目前執行環境實際使用這份設定。清單中出現訂閱名稱，只能證明已建立設定項目，不代表設定已生效。建議先保留一份可用的原始訂閱，再逐步加入本機覆寫。訂閱網址通常含有帳戶存取參數，應像密碼一樣妥善保管，不要放進公開截圖或求助內容。

從匯入到實際啟用

開啟用戶端的訂閱、設定或設定檔頁面，選擇透過連結匯入，貼上完整網址並儲存。網址前後的空格、換行及通訊軟體附加的標點，都可能造成請求失敗。匯入後執行更新，查看下載結果與解析提示，再從設定清單選取該項目作為目前設定。不同用戶端的按鈕可能標示為啟用、使用或啟動；請以目前設定標記與節點清單是否同步變更來判斷。

匯入本機檔案與透過連結訂閱並不相同。檔案匯入的是當下內容的副本，通常不會自動取得遠端後續更新的節點；連結訂閱則可在更新時重新取得內容。如果收到的是壓縮檔、網頁或登入頁面，不應直接當成 YAML 匯入。也不要只憑副檔名判斷內容是否正確：即使網頁回應狀態正常，解析器仍可能回報缺少欄位或出現非預期字元。

依失敗環節找出原因

下載失敗時先看錯誤類型：逾時可能與目前網路無法連線至訂閱伺服器有關；憑證錯誤應檢查裝置時間與請求路徑；授權失敗則可能表示訂閱網址已失效或帳戶狀態有變。解析失敗時，檢查目標格式、縮排與核心支援。只有內容下載完成並通過解析後，才適合繼續檢查策略組與節點；不要把所有訂閱問題都當成節點無法使用。

部分網路環境必須透過既有代理才能連線至訂閱伺服器，但新裝置尚未建立可用代理，便會形成啟動依賴。請先使用訂閱服務商提供的可連線入口，或匯入先前保存的有效設定，再考慮調整更新請求的代理設定。不要將含有帳戶參數的網址交給不熟悉的線上轉換服務；對方在轉換過程中可取得原始連結與回傳內容，風險不只是設定格式變更。

讓個人修改與遠端內容分開管理

遠端訂閱更新時可能會重新產生設定檔，直接編輯其中的規則、連接埠或群組名稱，容易在更新時被覆蓋。優先使用用戶端提供的覆寫、合併或擴充設定功能，並確認它會在訂閱更新後套用。不同用戶端的合併規則不盡相同，尤其要確認清單項目是附加還是取代。先用一項小改動驗證效果，例如新增一條明確的測試規則，再擴充至完整的個人分流設定。

訂閱中的策略組名稱必須保持一致。如果本機規則指向服務商已刪除或改名的群組，設定可能無法載入。更新後請檢查群組是否仍存在、手動選擇是否保留，以及節點名稱是否有變。不要只依據介面的舊快取判斷更新結果；必要時重新載入設定並查看核心實際接受的內容，但請先保存目前可用的狀態。

若訂閱能正常更新但無法連線，請接著閱讀代理模式章節。其他常見錯誤可參閱常見問題；求助時只需提供錯誤類型、用戶端名稱及已移除敏感資訊的設定結構，不必公開完整訂閱網址。

代理模式：分清流量入口與出站選擇

規則、全域與直連決定進入核心的連線如何出站；系統代理與 TUN 則決定應用程式的連線是否進入核心。這是兩組不同設定。切換至全域模式，不會自動接管忽略系統代理的應用程式；關閉系統代理，也不一定會停止已由 TUN 接管的連線。遇到「已切換模式但應用程式沒有變化」時，先確認該應用使用的入口，而不是繼續更換節點。

日常使用建議採用規則模式

規則模式會依照設定中的規則順序，為每條連線選擇策略。一條連線可能設定為直連，另一條則透過代理組處理，實際結果由網域、位址、程序等比對條件決定。此模式適合日常使用，但前提是規則完整且組名有效。初次測試時，先在手動策略組中選擇可用節點，再查看目標網域命中哪條規則，避免把規則選錯出站誤認為節點故障。

全域模式通常會將進入核心的連線交由全域策略處理，仍須在對應策略中選擇正確的節點或群組。這適合短時間排除規則因素：同一目標在規則模式下失敗、在全域模式下成功，表示應優先檢查分流結果。比較時必須確定應用程式確實進入核心，而且全域策略與原代理策略最後選用的是同一節點，否則同時改變了兩個變數，結論就不可靠。

直連模式會讓進入核心的連線透過直接出站，常用於確認基本網路狀態。這不等於退出用戶端，也不一定會關閉本機監聽或虛擬介面。若要完全取消用戶端對系統網路的影響，請依序關閉 TUN、關閉系統代理，再正常結束程式。只切換至直連，無法確認系統代理的殘留設定是否已清除。

透過明確指定代理建立對照

終端機工具不一定會讀取桌面系統代理，瀏覽器擴充功能也可能覆蓋系統設定。若要驗證本機入口，可讓單次指令明確使用混合連接埠。這能分別檢查系統代理讀取情況與核心出站行為。以下指令假設目前混合連接埠為 7890；若已變更，請同步修改。Windows PowerShell 中使用明確的可執行檔名稱，可避免與指令別名混淆。

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

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

收到回應表示這次請求已透過指定入口完成，但無法證明其他應用程式使用相同路徑。測試時也要開啟連線清單，確認請求網域、規則與出站。若指令立即顯示無法連線至本機連接埠，請回到安裝章節檢查監聽狀態；若已連上本機連接埠但遠端逾時，再檢查節點。測試目標本身也可能有限制，必要時換另一個已知正常的目標重試。

切換後重新建立連線

切換模式通常會先影響新連線，已建立的長連線可能繼續使用原本的出站。驗證設定是否生效時，請重新載入頁面、關閉相關連線或重新啟動測試應用程式，避免把重用連線的狀況誤認為設定未生效。影音、即時通訊與瀏覽器的連線池尤其可能延遲反映變更。關閉所有連線會中斷進行中的傳輸，請在可接受中斷時操作。

規則分流：從比對順序到策略組

規則分流的核心是依序由上而下尋找符合條件的項目，通常由第一條命中的規則決定出站。因此撰寫規則前，先釐清三件事：要比對哪種連線、命中後交由哪個策略處理，以及這條規則應排在其他哪些規則之前。規則數量不是品質指標，清楚的順序與穩定的策略組引用更重要。建議先了解內嵌規則，再使用外部規則集，避免一次加入太多難以追蹤的條件。

先了解三種常見的比對方式

DOMAIN 用於精確比對網域；DOMAIN-SUFFIX 用於比對指定網域及其子網域；IP-CIDR 用於比對 IP 位址範圍。MATCH 是最後的預設規則，不應放在仍需執行的規則前面。網域規則需要核心取得目標網域資訊；若應用程式只發出純 IP 連線，某些網域條件可能無法直接命中，須依實際連線資訊判斷。

策略組不是規則本身，而是供規則引用的出站選擇器。手動選擇組適合學習及固定出口；自動測試組通常依據指定測試目標的結果選擇；故障轉移組則會考量可用性與候選順序。實際功能取決於核心支援。自動測試結果只反映該測試目標，不能保證同一節點連線至所有網站、地區服務或長時間傳輸時都有相同表現。

# 規則片段：合併至現有設定，不是完整訂閱
# DIRECT 是內建的直連出站
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

此範例示範規則順序與語法，所有出站都使用內建直連，方便在沒有節點的環境中理解規則。實際需要代理時，應將對應出站改為目前設定中確實存在的策略組名稱，不要直接使用教學中的示意組名。最後的直連預設規則也不是通用建議：若希望未命中的連線預設走代理，就應將預設規則指向已驗證可用的代理組，並評估這項變更會涵蓋哪些流量。

了解 no-resolve 與 DNS 的關係

位址規則中的 no-resolve 表示不會為了比對此位址而主動將網域解析成 IP；它不代表停用所有 DNS，也不表示已知目標 IP 不會再被比對。私有網段規則使用此選項，可減少僅為判斷是否屬於該網段而觸發的額外解析。若要依目標解析結果進行分流，則須配合 DNS 設定判斷是否應保留解析流程，不要機械式地為所有位址規則加上相同參數。

DNS 回應會影響位址規則與實際連線目標，但網域規則不一定需要先取得目標位址。使用 fake-ip 模式時，也會出現合成位址，用於維持網域與連線之間的對應，並非遠端伺服器的真實位址。看到合成位址，不應立即判定為 DNS 污染。請檢查核心辨識到的網域、命中的規則及最終出站，再判斷是否需要調整 DNS 或排除特定應用程式。

修改規則後驗證命中結果

先備份目前設定，只在本機覆寫中新增一條目標明確的規則，重新載入後開啟對應網域，並從連線詳細資訊確認實際命中的項目。若沒有命中，檢查前方是否已有更寬泛的規則、應用程式是否重用了舊連線，以及用戶端是否確實將覆寫套用至執行中的設定。若設定無法載入，先檢查縮排、逗號與組名；還原至上一份可用內容後，再逐項修正。

規則集適合集中維護大量同類網域，但應確認提供者支援的格式、行為類型、更新週期與本機快取路徑。下載失敗時是否有快取可用，會影響設定能否正常運作。不要同時疊加用途重複、來源不明的多個規則集，否則相同網域可能被不同條件提前攔截。先建立清楚的分類策略，再挑選符合分類需求的規則內容。

更詳細的比對順序、網域後綴範圍與預設規則寫法，請參閱Clash 自訂規則與優先順序詳解。開始維護個人規則時，請為每項修改記錄用途與驗證目標，日後遷移會更容易。

TUN 模式：擴大接管範圍並處理 DNS

TUN 透過虛擬網路介面接收連線，適合處理不遵循系統代理的應用程式，但並非所有問題的通用解法。啟用前應先確認一般系統代理流程正常，否則接管範圍一旦擴大，原本局部的設定錯誤可能演變成整部裝置無法正常連線。也要分清 TUN 介面已建立、路由已接管與 DNS 已接管這三種狀態，它們不一定會同時成立。

先確認權限與衝突條件

桌面平台通常需要服務模式、輔助服務或提升權限，才能建立介面及修改路由；實際方式依用戶端實作而異。先閱讀介面上的服務狀態提示，再依需求授權。若裝置上已有公司 VPN、虛擬機器網路、容器網路或其他代理，請先記錄其狀態。多個工具若同時修改預設路由或 DNS，可能造成迴圈、互相搶用或部分位址無法連線；測試時應盡量簡化網路環境。

行動平台的網路接管由系統提供的 VPN 或網路延伸機制管理，介面不一定會出現與桌面版相同的 TUN 參數。不要將桌面版 YAML 中所有網路選項原封不動複製到手機。系統限制、用戶端實作與設定覆寫方式都可能不同。即使使用同一份訂閱，也應分別測試 Wi-Fi、行動網路、鎖定螢幕及網路切換後的連線狀況。

了解常見參數的用途

# mihomo TUN 設定片段，須合併至現有設定
# 先確認用戶端是否已透過介面產生相同設定
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable 用來啟用介面，stack 用來選擇網路堆疊，auto-route 讓核心依平台能力設定路由，auto-detect-interface 則會嘗試辨識出站介面。此範例不是完整設定，也不代表每個環境都適合使用相同組合。如果用戶端介面已管理這些欄位，請以其合併機制為準，避免設定檔與介面互相覆蓋。

dns-hijack 用於接管符合條件的 DNS 流量，但不會自動涵蓋所有應用程式內建的加密解析方式。瀏覽器的安全 DNS、應用程式自行解析、寫死的 IP 位址及系統快取，都可能影響觀察結果。啟用後，除了檢查一般網頁，也要測試本機網路名稱與實際需要的應用程式；不要只因為某個網站能開啟，就認定所有 DNS 路徑都符合預期。

依照可復原的順序啟用

先儲存目前可用的設定，確認如何退出用戶端，再從介面啟用 TUN。先查看核心日誌，確認介面是否成功建立；接著瀏覽一般網站與區域網路資源，並檢查連線紀錄。若區域網路印表機、路由器管理頁或公司內部位址受到影響，請檢查相關網段的路由與直連規則。路由排除與規則直連屬於不同層級，不能只靠新增網域規則取代所有路由設定。

若整部裝置無法連線，先關閉 TUN，讓用戶端繼續執行，並檢查一般系統代理是否恢復正常。恢復後比較兩種入口的差異，再檢查服務狀態、預設介面、DNS 與其他 VPN。不要在無法連線時同時修改網路堆疊、DNS、規則與節點，即使恢復也無從判斷原因。遠端管理伺服器時，尤其要保留獨立的存取路徑，避免修改預設路由後失去控制。

使用 UDP 的應用程式需要另外驗證。網頁可以瀏覽，只表示部分 TCP 請求正常，不能證明即時通訊、遊戲或特定 UDP 協定也能使用。還須確認節點支援、伺服器端策略、目前網路與用戶端設定。不要把切換網路堆疊當成第一步；先從日誌找出對應連線及錯誤，再決定是否要更換出站或調整接管策略。

系統時間、封包擷取工具與 DNS 路徑可能造成憑證問題，相關排查步驟請參閱開啟 Clash 後網頁出現憑證錯誤的排查順序。完成驗證後，只保留確實需要的接管方式。

日常維護：更新、備份與還原

穩定使用的關鍵，是讓每次變更都能追蹤並復原。用戶端更新、核心更新、訂閱更新與個人規則修改是四種不同操作，不宜同時進行。先記下目前正常運作的狀態，再逐項變更並重複相同測試。發生問題時，才能還原至明確的起點，而不是在多份設定、多個節點與多項接管設定之間反覆嘗試。

備份哪些內容才真正有用

至少保存訂閱來源、目前啟用的設定、個人覆寫規則、策略組選擇與重要網路設定。用戶端資料目錄可能包含存取參數或管理介面資訊，請將備份存放在安全的位置，不要上傳至公開儲存庫。跨裝置遷移前，先確認匯出檔包含哪些內容：有些只包含規則，有些則包含整個執行目錄，對隱私與還原能力的影響不同。

訂閱原始內容與個人規則最好分開保存。前者可從遠端重新更新，後者可能只存在本機。也應記錄連接埠、是否允許區域網路連線、TUN 狀態及開機啟動設定，因為這些可能由用戶端介面保存，不一定會出現在匯出的 YAML 中。還原後不要只檢查節點名稱，也要確認系統代理指向、監聽位址與本機覆寫是否確實生效。

更新前後使用同一份檢查清單

更新前先閱讀與自身平台及使用功能相關的版本變更說明，不必看到新版本就立刻在所有裝置上安裝。更新後確認程式啟動、核心解析、訂閱載入、規則命中與 TUN 狀態，再測試一個代理目標與一個直連目標。若新環境不穩定，請使用先前保存的設定與選項還原；不同核心的快取或擴充欄位，不一定能直接沿用舊版內容。

日常延遲測試可用來找出明顯無法連線的節點，但不應頻繁更新整份訂閱來追求最低數值。大量並行測試會消耗網路資源，也可能受到伺服器限制。下載速度、首次連線耗時與長連線穩定度是不同指標。為常用策略組保留一個已驗證的候選節點，發生異常時拿來比對，會比依據一次測試結果不斷切換更有參考價值。

利用日誌建立排查紀錄

日誌平時維持一般詳細程度，只有在重現問題的短時間內才提高詳細程度。記錄問題發生時間、應用程式、目標網域、接管入口、模式、命中規則與錯誤資訊。日誌中的逾時、連線遭拒、解析失敗與授權失敗，代表不同處理環節；不要只摘錄最後一句「失敗」。複製日誌前，先檢查是否包含訂閱參數、節點位址、內部網路位址或本機路徑，並視需要移除敏感資訊。

也要記錄環境變化。切換至新的 Wi-Fi、連上公司網路、啟用安全軟體或啟動虛擬機器後才出現問題，通常表示預設路由、DNS 或防火牆規則有所變動。先切回先前使用的網路進行比對，再判斷是否需要修改用戶端。若多部裝置在同一網路同時發生異常，應優先檢查共用網路與遠端服務，而不是逐一重新安裝用戶端。

正常結束與解除安裝前的處理

結束前先關閉 TUN 與系統代理，再正常關閉程式。若程式異常結束後瀏覽器無法連線，請確認系統代理是否仍指向已停止監聽的本機連接埠；確認連接埠已失效後，再依目前網路需求清除殘留設定。不要直接執行來源不明的網路重設指令；全面重設可能一併清除公司代理、固定 IP 位址或其他原本正常的網路設定。

進階學習路線：從使用設定到自主維護

進階不代表開啟更多選項，而是能預測設定變更會影響哪些內容，並以紀錄驗證實際結果。完成前八個階段後，建議依序學習設定結構、規則提供器、DNS 與執行管理。每次只加入一種功能，先在可復原的測試設定中驗證，再合併至日常環境。對用途不明的欄位，保留預設值通常比照抄整份「最佳化設定」更穩妥。

先建立設定之間的依賴關係

一份設定可以視為由入口、出站、策略組、規則與 DNS 組成的相依網路。規則會引用策略組，策略組會引用節點或其他群組，提供器負責取得外部內容，系統整合則會將應用程式流量送入入口。修改名稱時應沿著引用關係逐項檢查；刪除節點來源前，先確認策略組是否仍在使用。成功解析只是第一步，還要驗證最終出站是否符合原本目的。

學習規則提供器時，先建立一份規模小且內容明確的規則集合，再檢查格式、行為類型與更新結果。不要直接加入一長串外部清單，讓自己無法解釋分流邏輯。更新週期也要設定得合理：規則內容不需要每隔幾秒就重新取得，過度頻繁更新只會增加對網路的依賴。也要了解首次啟動時沒有快取，與日常更新失敗但仍有快取可用，兩者的差異。

接著研究 DNS 與連線中繼資料

學習 DNS 時，應先釐清系統解析、核心解析與應用程式自行解析的差異，再比較 fake-ip 與回傳實際位址的處理方式。每次測試都記錄請求網域、解析結果、命中規則與出站路徑。某種模式或許能解決特定應用程式的問題，卻也可能影響區域網路探索或使用特殊解析流程的應用程式；因此調整時應保留涵蓋常見情境的回歸檢查，而不只測試單一網站。

流量嗅探可在特定條件下補充網域資訊，但不代表能看見所有應用程式內容，也無法保證每條連線都能正確補齊目標資訊。效果會受協定、加密方式與應用程式行為影響。先了解未啟用嗅探時的連線資訊，再依需求評估是否開啟；不要把嗅探當成正確 DNS 接管或規則設計的替代方案。若涉及敏感業務，也應遵循所屬網路的管理規範。

使用命令列核心時，先做好安全防護

直接執行核心適用於伺服器與路由器環境，但必須自行管理設定路徑、工作目錄、程序重啟、日誌保留與權限。先在前景完成設定檢查，再交由系統服務管理。以下指令假設已安裝可執行的 mihomo，且目前目錄中存在設定檔；此指令用於測試設定，不會下載或安裝程式，也不能證明所有遠端節點都可連線。

# 檢查目前設定的語法及可載入性
mihomo -t -f ./config.yaml

# 在前景模式執行指定設定
mihomo -f ./config.yaml

設定測試通過後，還應在實際執行時驗證規則與連線。服務環境與互動式終端機的工作目錄、環境變數及使用者權限可能不同，因此前景執行正常，不代表服務也能找到相同檔案。使用絕對路徑與明確的資料目錄有助於避免混淆，但請依實際部署位置填寫，不要照抄其他裝置的路徑。

允許區域網路連線會擴大本機代理入口的可存取範圍；外部控制介面則可能提供更完整的設定管理功能。兩者都不應任意公開至網際網路。只有在確實需要分享或管理時才啟用，並限制監聽位址與網路存取範圍，使用用戶端支援的驗證機制。不要只為了用手機存取控制面板，就直接開放路由器連接埠；應先確認存取範圍與關閉方式，再進行設定。

整理個人疑難排解手冊

為常用環境建立固定的測試項目：基本直連目標、需要代理的服務、區域網路資源、終端機明確指定代理，以及實際需要的 UDP 應用程式。每次調整後逐項重測，記錄結果而不是只靠印象。發生問題時，依序檢查入口、解析、規則、出站與遠端服務五個環節。累積的紀錄可直接用於日後遷移，也更容易向他人說明可重現的問題。

能說明每項變更的目的、驗證結果並還原至舊狀態，就已具備自主維護設定的基礎。日後選擇功能時仍應遵循相同原則：先確認問題屬於哪個環節，再選用對應功能，不要為了增加參數而引入不必要的複雜度。