Clash 完整教學：
安裝、分流與維護指南

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

先分清操作介面與執行核心

Clash 生態系中的用戶端通常由圖形介面和代理核心組成。介面負責匯入訂閱、顯示策略組、調整設定及要求系統權限；核心則負責監聽本機連接埠、解析連線資訊、比對規則並建立外連。介面已啟動，不代表核心運作正常；核心正在執行，也不代表系統流量已送進代理。排查時分別確認這兩個環節，比反覆重新安裝更有效。

mihomo 是這個生態系常用的核心。不同用戶端可能搭載不同核心，也可能限制可修改的欄位。同一份設定能否跨平台使用，取決於通訊協定、規則類型、核心功能與平台能力是否相容，而不是副檔名是否相同。跨平台移轉時，先沿用訂閱與策略組架構，再檢查連接埠、檔案路徑、網卡名稱等裝置相關設定，不要直接覆蓋所有本機偏好。

一條連線會經過哪些環節

整體流程可分成四個步驟：應用程式發出請求、流量進入本機代理入口、核心依照模式與規則決定外連方式，最後透過直連或遠端代理存取目標。系統代理與 TUN 主要處理第二步，規則和策略組負責第三步，節點協定則處理第四步。網頁連不上可能發生在任何環節，因此「換節點」只是其中一種排查方式，不能取代對入口與名稱解析的檢查。

設定檔描述了這些環節之間的關係。proxies 定義個別代理，proxy-groups 將代理整理成可手動選擇或自動測試的群組，rules 則依序將連線交由特定策略處理。訂閱可能包含完整設定，也可能只有節點資訊；若只有節點資訊，用戶端還需要透過範本補上策略組與規則。訂閱能成功解析，不代表它已包含完整的分流邏輯。

節點是遠端服務的連線參數，策略組則是管理節點的方式，兩者不可混為一談。名為 Proxy 的策略組可以選擇個別節點，也可以指向其他策略組；直連策略 DIRECT 則表示連線不經過遠端代理。群組名稱通常由設定作者自行命名，沒有統一的中文名稱。下文使用 Proxy 作為引用關係的範例，實際修改時請依照自己的設定檔調整。

本機連接埠與 DNS 的作用

本機監聽連接埠就像應用程式進入核心的入口。混合連接埠可在同一個連接埠接受常見的 HTTP 代理與 SOCKS 代理連線，但不會自動接管所有程式。DNS 會將網域名稱轉換成 IP 位址，也會影響網域規則能否及時判斷。若瀏覽器使用自己的加密 DNS，而系統使用另一個解析器，同一個目標可能走不同路徑；需要搭配記錄檔，對照網域名稱與實際連線位址。

開始之前，也要分清用戶端軟體與網路服務。安裝用戶端不會自動提供可用的遠端代理；連線需要自行持有且有權使用的設定。訂閱網址通常含有存取憑證，請像密碼一樣妥善保管。截圖、記錄檔和求助內容都可能洩漏憑證，分享前請移除完整網址、帳號識別資訊及節點認證資料，只保留問題相關欄位與錯誤現象。

本章的目標不是記住所有術語，而是能回答三個問題：目前使用哪個用戶端與核心、設定從何處載入、應用程式透過哪個入口進入核心。先記下這三項，日後遇到系統代理未生效、規則未命中或訂閱更新失敗時，才能找對檢查方向，而不是一次切換多個開關。

二、選擇用戶端：先看平台，再看需求

優先選擇持續維護、適合日常使用的用戶端

選擇用戶端時，先考量裝置系統、處理器架構與使用情境，再看介面。初次使用可先了解 Clash Plus，依照用戶端下載頁上的系統分類選擇安裝方式。若需要經常編輯設定、查看連線或使用特定核心功能，再比較其他用戶端。不要只根據舊教學的截圖選擇；選單看起來相似，不代表目前的系統支援狀況與權限流程也相同。

桌面版常見需求包括常駐系統列、系統代理、開機啟動、設定覆寫與 TUN；行動版則更重視系統 VPN 授權、背景執行及休眠後的連線恢復。先列出真正需要的兩三項功能，再查閱對應用戶端的說明。不打算使用的進階選項不必納入選擇條件；功能多不代表初次設定更簡單，也不保證與其他網路軟體更相容。

處理器架構、設定相容性與舊版用戶端

處理器架構和作業系統是兩個不同面向。macOS 的 Apple Silicon 與 Intel 安裝檔不能只看檔名中有 Mac 就判定適用；Android 的 ARM64 與 ARM 套件也應依裝置能力選擇。採用 ARM 處理器的 Windows 裝置，請確認應用程式明確列出的支援方式，不要把所有桌面安裝檔都視為原生支援。下載頁未列出的架構，請勿自行猜測安裝檔網址。

Clash for Windows 與 ClashX Meta 已停止維護，適合用來辨認舊教學或移轉既有環境，不建議將封存版本當作持續更新的預設方案。尋找 Clash for Windows 替代品時，請確認新用戶端能否讀取現有設定、如何保存覆寫內容，以及關閉時是否會還原系統代理。完成移轉後再移除舊程式，以免兩個用戶端同時占用相同的監聽連接埠。

用戶端能匯入檔案，不代表檔案中的所有功能都能運作。訂閱中的通訊協定、規則提供器、指令碼或核心專用欄位，可能超出目標應用程式的支援範圍；Surfboard 等應用程式也必須使用其明確支援的設定格式。匯入失敗時，先查看欄位名稱與行號，不要反覆提交不相容的設定。必要時向設定提供者索取對應格式，避免使用來路不明的轉換服務處理憑證。

為移轉做好基本記錄

更換用戶端前，記下目前的訂閱名稱、模式、策略組選擇，以及哪些應用程式依賴手動代理。同時保存自行新增的規則，並確認它們是直接寫入訂閱檔案，還是由用戶端的覆寫功能管理。遠端訂閱檔案更新後可能被取代，只有存放在正確位置的本機修改才容易移轉。記錄請保存在本機，不要將完整訂閱網址貼進公開筆記或截圖。

iOS 版 Clash Plus 可從下載頁前往 App Store，產品官網為 clashplus.io。行動作業系統通常透過 VPN 設定接管流量，與桌面版的系統代理開關並非一一對應。閱讀跨平台教學時，應先理解功能目的再對照操作，不要在手機上尋找桌面版才有的混合連接埠選單，也不要在桌面版照搬手機的背景權限設定流程。

這個階段只要選定一個主要用戶端和一個備用方案即可，不建議同時安裝多個常駐代理。先用主要用戶端完成後續安裝與匯入，確認網路能正常恢復後，再了解其他介面的差異。選擇時應能說明理由：裝置支援、設定相容、必要功能齊全，而且遇到異常時找得到記錄檔與退出方式；不要只看名稱或介面配色。

三、安裝檢查：建立可復原的執行環境

安裝前先排除可能的衝突

安裝前先退出其他代理用戶端、遊戲加速器及可能修改系統網路的工具，並記下目前是否有手動代理、企業 VPN 或特殊 DNS。退出也包括背景程序，而不只是關閉視窗。多個程式同時修改路由與代理設定時，介面可能都顯示正常，實際流量卻被送往另一個入口。可先截下原有網路設定，測試完成後再據此還原工作環境。

從下載頁選擇符合系統與架構的安裝檔，並閱讀用戶端本身的安裝說明。安裝版、可攜版與壓縮檔的儲存位置可能不同；可攜執行也不代表所有資料都會存放在程式目錄。首次啟動前，請確認設定目錄可寫入，避免將程式放在唯讀路徑或限制嚴格的系統目錄。若需安裝服務，請先了解它是為了提供網路權限，並非用來取得遠端代理憑證。

依平台完成必要授權

Windows 首次執行時，先確認主介面與系統列入口都能開啟，再查看核心是否已啟動。防火牆提示應依實際使用情境處理，不要為了省事而允許所有網路存取。若只供本機使用，就不必開啟區域網路監聽。TUN 所需的服務或管理員權限，可等基本連線成功後再設定，這樣初次失敗時更容易分辨是安裝問題還是進階接管設定所致。

macOS 請依照應用程式的提示完成首次開啟與系統授權。涉及網路延伸功能、輔助服務或鑰匙圈時，先確認提示確實來自正在安裝的應用程式，不要盲目核准不明來源的要求。遇到「已損毀」或延伸功能無法啟用時，請檢查下載來源、系統相容性及系統設定中的封鎖資訊；不要直接關閉整套系統安全機制。個別授權流程可參考macOS 安裝與權限設定。

Android 與 iOS 初次連線時通常會要求系統 VPN 權限。若裝置已使用其他 VPN，請確認是否會被取代或暫停。Android 若長時間鎖定螢幕後斷線，可再檢查電池最佳化與背景限制，不要一開始就開放所有權限。Linux 則應確認套件格式符合發行版，並依用戶端說明安裝桌面相依套件與服務；圖形介面能開啟，不代表權限服務已正常運作。

先確認本機入口，再設定自動啟動

進入設定後，找出實際監聽的位址與連接埠並記下。教學中常見的連接埠只是範例，可能已被其他程序占用，也可能由用戶端改寫。連接埠衝突通常會造成核心啟動失敗，或在記錄檔中顯示位址已被占用。遇到這種情況，先退出舊用戶端，再確認衝突來源；不要任意更換多個連接埠，否則瀏覽器、終端機或系統代理中的舊設定仍會指向失效入口。

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

# macOS / Linux：查看範例連接埠的監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

上述指令僅用於診斷，不會自動啟動代理。沒有輸出可能只是尚未開始監聽；找不到指令也可能是系統未安裝對應工具。找到程序後先確認其用途，再決定要退出哪個程式，不要直接終止不熟悉的系統服務。若監聽位址是本機迴路位址，其他裝置無法連線，這是合理的本機預設邊界，不要為了「修復網路」而任意改成對外開放。

最後進行一次復原測試：先不匯入複雜設定，確認用戶端能正常退出，關閉後原本的直連網路仍可使用。接著重新啟動，檢查核心記錄與監聽連接埠是否一致。這個看似簡單的步驟，能及早發現系統代理殘留、權限服務異常與連接埠占用。保留這個基本環境，下一章只加入訂閱，不要同時調整 DNS、TUN 與區域網路分享。

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

選擇匯入方式並確認內容類型

訂閱是用戶端定期取得設定的一種方式，常見入口位於「設定」、「訂閱」或「Profiles」。從提供者複製完整網址後，選擇從 URL 匯入，替設定命名以便辨識，再開始下載。網址中的查詢參數可能用於身分驗證；複製時漏掉尾端字元、帶入空格或換行，都可能導致請求失敗。不要將訂閱網址直接貼到搜尋引擎或公開的線上檢測網站。

若已有完整 YAML 設定，可匯入本機檔案。先確認取得的是設定內容，而不是登入頁面、說明文字或壓縮檔。訂閱請求成功，也可能只取得帳戶登入頁；下載成功與解析成功是兩個不同的檢查點。若用戶端顯示格式錯誤，可查看檔案開頭及錯誤行附近的結構；分享內容前，務必移除認證欄位，不要以排錯為由洩漏整份設定。

YAML 透過縮排表示層級，通常使用空格而非定位字元。冒號後需要正確分隔，清單項目也要維持相同縮排。編輯時保留原有編碼與結構，不要把中文標點當成語法符號。含有特殊字元的字串可依 YAML 規則加上引號，但不能一律替所有欄位加引號。錯誤行通常只是解析器發現問題的位置，真正缺少的縮排或引號可能在前一行。

匯入後還要切換至目前使用的設定

設定出現在清單中，只代表用戶端已將它儲存。接著點選「啟用」、「使用」或對應的活動標記，等待核心重新載入，再前往代理頁面查看策略組。若畫面仍顯示舊的群組名稱，很可能只是下載完成，尚未切換設定。先確認目前啟用的設定名稱、更新時間與載入錯誤，比立刻刪除重建更穩妥。若同時保留多份設定，可在名稱中註明用途，避免日常誤選。

完整設定通常會包含節點與策略組。先展開主要策略組，確認其中確實有可選的外連方式，再選擇一個有權使用的節點進行測試。看得到節點名稱，不代表服務可用；憑證過期、遠端無法連線或協定不相容，都可能要等到建立連線時才會發現。延遲測試失敗也不代表所有網路都無法使用，測試位址、測試方法與實際服務可能不同。

更新訂閱與更新用戶端是兩回事。前者會變更節點、規則或策略架構，後者會更新程式與核心功能。遠端更新可能覆蓋直接編輯過的檔案，因此長期使用的規則應放在用戶端提供的覆寫、合併或本機擴充位置。先確認合併順序，再少量測試：有些機制會整體取代陣列，有些支援插入前方或附加在末尾；名稱相似不代表運作方式相同。

判斷更新失敗的原因

更新失敗時，先分辨是請求未完成、伺服器拒絕存取，還是內容無法解析。請求逾時時，檢查目前網路、網域解析，以及更新是否需要透過代理；遭拒時，確認網址完整性、帳戶狀態與提供者說明；解析失敗則檢查回傳內容及核心支援範圍。不要把所有錯誤都歸咎於節點故障，因為訂閱下載可能使用另一條網路路徑。

若首次匯入必須透過代理才能下載，可使用提供者允許的本機設定匯入方式，先建立基本連線，再測試更新路徑。不要為了解決一次下載問題，就把訂閱交給資料處理方式不明的轉換網站。訂閱提供器與規則提供器也可能各自下載外部檔案；主設定載入成功後，仍應確認這些資源是否就緒，尤其是首次啟動與離線復原時。

完成本章後，應能在設定清單中指出目前啟用的項目，在代理頁面找到主要策略組，並判斷更新失敗發生於下載或解析階段。將最後一份可用設定保存在本機，也記下自訂內容的位置。下一章先用現有策略驗證模式，不要立即增加規則；如此一來，存取結果改變時才能確認原因是切換模式，而非訂閱內容同時更新。

五、代理模式：分開檢查入口與外連

規則、全域與直連模式的用途

代理模式決定進入核心的連線該如何選擇外連方式。規則模式依設定中的規則逐條比對，適合日常按目標分流；全域模式將進入核心的連線交由全域策略處理；直連模式則讓這些連線直接存取目標。三種模式都以流量已進入核心為前提。未透過系統代理、手動代理或 TUN 接管的應用程式，不會只因切換至全域模式就自動改變連線路徑。

初次測試可先選擇規則模式，確認主要策略組已選取可用節點，再開啟一個明確需要代理的目標，以及一個應正常直連的目標。兩者都測試，可避免只測單一網站就誤判整體網路正常。若出現問題，再短暫切換至全域模式作為對照；若全域模式可用、規則模式失敗，應優先檢查規則命中與策略組引用，不要立刻重新安裝用戶端。

全域模式不代表所有裝置流量都會經過代理，也不保證 DNS 請求使用相同出口。它只會改變核心對已接收連線的策略判斷。有些用戶端的全域選擇與日常使用的 Proxy 策略組彼此獨立，切換後請確認全域策略目前指向哪個外連方式。測試完成後恢復原本模式並重新確認實際使用情況，避免忘了原本的分流需求，長期維持臨時測試設定。

系統代理是流量入口，不是代理模式

系統代理開關會修改作業系統提供給應用程式的代理資訊。瀏覽器通常會遵循，但遊戲、部分更新程式、終端機工具或採用自有網路實作的應用程式可能不會。某個程式直連，不一定代表規則有錯；它可能根本沒有連到本機代理連接埠。先在連線清單中尋找對應程序與目標；若沒有紀錄，應檢查流量入口，而不是繼續修改無法影響該連線的規則。

若要單獨測試本機 HTTP 代理，可使用下方指令。這裡的連接埠僅為範例，請替換成用戶端實際監聽的混合連接埠或 HTTP 代理連接埠。指令會明確指定入口，因此不必依賴終端機是否讀取系統代理設定。測試成功只代表這次請求透過該入口完成，不能證明瀏覽器、其他通訊協定或所有目標也使用相同路徑。

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

透過連線紀錄確認判斷

觀察一次請求時，依序記錄來源應用程式、目標網域或位址、命中規則、策略組及最終節點。若請求走 DIRECT，先確認是否符合設定；若已命中正確策略卻仍失敗，再檢查節點連線與名稱解析。連線清單通常會彙整或快速移除短連線，可先開啟記錄檔再重現問題。不要只依系統列圖示顏色或單一總開關判斷實際出口，它們可能只顯示服務正在執行。

切換模式後，已建立的長連線不一定會立即改道。瀏覽器連線重用、聊天程式的長連線及影片串流都可能繼續沿用原本路徑。對照測試時請建立新請求，必要時關閉再開啟對應應用程式；若用戶端提供關閉連線的功能，也要留意這會中斷傳輸中的工作。不要快速連續切換模式，再觀察同一條舊連線，否則很容易得到互相矛盾的結果。

本章建議建立固定的測試順序：確認核心正在監聽、確認應用程式已進入核心、確認代理模式，再確認外連方式。直連模式不能取代退出軟體，程式仍可能保留系統代理入口。結束測試時，請依用戶端流程關閉流量接管並確認系統設定已還原。遇到「顯示已連線，網頁卻打不開」，可參考訂閱、連接埠與系統代理疑難排解清單逐項檢查。

六、規則分流：順序、策略組與本機覆寫

從容易理解的一組規則開始

規則通常由上而下比對，符合條件後便交由對應策略處理，因此規則順序與內容同樣重要。明確的例外應排在涵蓋範圍較廣的規則之前，兜底規則則放在最後。只新增規則卻不檢查位置，可能永遠不會生效；若將 MATCH 放在前面，後續規則就無法達到預期的分流效果。學習時先弄清楚幾條規則的適用範圍，再加入大型規則集，遇到異常時才有辦法說明命中原因。

DOMAIN 用來比對指定網域，DOMAIN-SUFFIX 可比對該網域及其子網域，DOMAIN-KEYWORD 則會搜尋網域中的關鍵字。關鍵字規則涵蓋範圍較廣，容易將無關服務納入同一策略。IP-CIDR 依據 IP 網段比對，GEOIP 則依賴地理位置資料庫，判斷結果不等於服務實際營運地區。網域規則與 IP 規則使用的資訊不同，應依據實際連線紀錄選擇，不要互相取代。

# 合併至現有設定；Proxy 必須是已存在的策略組
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-SUFFIX,google.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

這段範例只展示規則區塊，沒有遠端節點，因此無法單獨建立代理。no-resolve 表示這條位址規則不會為了比對網域連線而主動觸發解析，並非全域停用 DNS。區域網路直連還需配合實際網段與 TUN 路由檢查；只列出一個私人網段，不代表涵蓋所有內部網路。企業環境可能使用自訂位址範圍，請以實際網路規劃為準。

策略組讓規則與節點各自獨立

規則指向策略組後，就能在不修改規則的情況下切換節點。選擇型策略組由使用者決定目前的外連方式；自動測試型策略組會依設定的測試結果挑選節點；故障轉移型策略組則依序尋找可用成員。它們解決的問題不同：延遲較低不代表下載速度較快，測試目標可連線也不代表實際服務網域可用。請依用途選擇，不要把所有策略組都改成相同類型。

更改群組名稱時，必須同步檢查規則、其他策略組與覆寫設定中的引用。名稱不一致可能導致載入失敗，或讓原本預期的引用失效。請先複製一份可用設定，在單一策略組中測試成員與選擇，再擴大修改範圍。也要避免策略組彼此形成循環引用；若用戶端回報循環相依，請沿著引用鏈逐項檢查，不要任意刪除錯誤訊息提到的節點來規避問題。

安全更新自訂設定的方法

長期使用的自訂內容，應優先透過用戶端支援的覆寫或合併功能管理。先確認新增規則會排在訂閱規則之前或之後，再加入一條容易驗證的測試規則。若合併機制會直接取代整個 rules 陣列，原有分流可能全部消失；若只在末尾附加，新規則又可能排在 MATCH 之後。儲存前查看合併後的結果，比只看編輯框中的片段更可靠。

規則提供器可將大量規則存放在獨立資源中，再透過 RULE-SET 引用。使用前須了解提供器的格式、行為類型與更新方式；網域清單與完整規則集不能任意互換。資源下載失敗時，主設定可能仍能載入，但分流結果會有所不同。請檢查記錄檔中的資源狀態與快取，先確認不是提供器尚未就緒，再檢視個別規則是否正確。

實際排查時，可固定一個目標，先確認是否看得到網域，再查看命中的項目與最終策略。若只看到 IP 位址，需考慮應用程式直接連線 IP、解析快取或流量接管方式的影響；若規則正確但服務仍異常，可能還有其他網域、內容傳遞網路位址或登入介面需要一併存取。不要為了解決單一應用程式的問題，就把所有流量改成全域模式；先縮小例外範圍並記錄修改原因。

完成本章後，應能說明一條請求為何命中目前的規則，以及切換策略組會影響哪些目標。保存修改前後的規則差異，重新載入後以新連線驗證。若結果不如預期，先還原這次修改，再檢查下一個環節；採取小幅變更，才能避免將訂閱更新、DNS 調整與分流測試混成同一個故障。

七、TUN 模式：接管範圍、權限與 DNS

哪些情況需要 TUN

TUN 透過虛擬網路介面與路由將流量送入核心，適合不遵循系統代理設定的應用程式，也常用於統一處理更多網路流量。它和系統代理的主要差異在於接管位置，而不是「速度更快」或「功能更進階」。實際接管範圍仍會受到路由排除、應用程式略過設定、通訊協定支援及平台限制影響；啟用 TUN 不代表每個封包都會走相同的遠端出口。

開始前，應先確認訂閱可用、規則合理且一般代理入口正常。保存目前的設定並退出其他 VPN，確認遠端工作、虛擬機與容器網路是否依賴特殊路由。若透過遠端連線管理裝置，貿然變更預設路由可能中斷管理連線，請預先準備本機操作方式或復原方案。TUN 疑難排解必須建立在基本代理可用的前提上，不能拿來掩蓋無法使用的訂閱。

逐項啟用，不要同時變更多項設定

依照用戶端提示安裝權限服務或完成系統授權，啟用後查看虛擬介面、路由與核心記錄。部分用戶端會自動協調系統代理，其他用戶端則允許兩者並行，實際行為請以用戶端說明為準。若要比較效果，可先只使用一種接管方式進行測試，確認目標應用程式是否出現在連線紀錄中，再決定是否保留另一種入口。不要未經確認就同時開啟所有網路強化選項。

# mihomo 設定片段，須配合現有設定與用戶端管理方式
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

範例中的自動路由負責新增流量接管路徑，自動辨識介面用於尋找外連網卡，DNS 劫持項目則用來接收符合條件的 DNS 流量。實際支援的欄位與行為取決於核心和作業系統；若用戶端已有 TUN 設定頁面，應優先透過介面管理，避免介面設定與檔案內容互相覆蓋。單獨複製這段設定無法補齊完整的 DNS 服務，也不保證所有平台使用相同的網路堆疊實作。

DNS 會影響網域如何參與分流

DNS 是 TUN 環境的重要配套。Fake-IP 模式會將網域映射到虛擬位址，讓核心在後續連線中找回原始網域；傳統的實際位址解析則直接回傳目標位址。兩種方式各有相容性限制，不能只憑一次開啟網頁的速度判斷優劣。某些依賴實際位址的裝置探索、內部服務或應用程式可能需要例外設定；調整前先確認問題確實出在解析模式，而非規則或路由。

fake-ip-filter 用來列出不使用虛擬位址回應的網域，但它不是通用的代理略過清單。回傳實際位址後，連線仍會繼續參與規則判斷。將網域加入過濾清單，不會自動讓連線直連；若服務需要直連，還要檢查規則與路由。想了解位址映射流程，可接著閱讀Fake-IP 模式與虛擬位址池，再設定範圍最小的例外。

DNS 劫持也不代表能攔截所有解析方式。應用程式內建的加密 DNS 可能透過一般 HTTPS 或其他連線傳送，因此不能只看是否接管第 53 埠，就認定 DNS 請求已進入核心。遇到網域規則表現不一致時，請檢查瀏覽器安全 DNS、應用程式內的解析設定與系統快取。不要同時修改系統 DNS、核心解析器與瀏覽器設定；每次只調整一處，並重新建立連線。

也要測試網路切換：從有線改用無線、從 Wi-Fi 切換至行動網路，或從休眠恢復時，原本的外連介面可能會改變。若一般代理可用但 TUN 失敗，請檢查預設介面、殘留路由、權限服務與 DNS 接管，再決定是否重新啟動用戶端。更多差異請參考TUN 與系統代理的流量接管範圍比較。本章的完成標準是流量接管正常、內部網路可用，關閉後也能還原原有網路。

八、日常維護：更新、測速與故障記錄

分開管理設定更新與程式更新

穩定使用後，維護重點在於控制變因。不要在同一次操作中一併更新訂閱、用戶端、核心或作業系統。先記下目前啟用的設定、模式與策略組選擇；完成一種更新並重新測試後，再進行下一項。如此一來，發生故障時就能將問題對應到特定變更。只記下「昨天可以用，今天不行」，通常不足以分辨是遠端服務變動還是本機環境改變。

更新訂閱前，先確認本機自訂規則已存放在不會被取代的位置，並保留一份可用設定。更新後檢查策略組名稱、成員與主要規則是否有變動，原本選取的節點可能已被移除。升級用戶端則應閱讀功能與相容性說明，留意設定目錄、權限服務與核心參數是否有所變更。不要讓舊程序與新程式同時執行，否則介面與實際監聽程序可能不屬於同一套安裝。

測速結果只能回答部分問題

Clash 節點測速通常會針對指定測試位址，反映單次請求的回應狀況，不等於持續下載速度，也不能代表所有網站的使用體驗。測試失敗可能是測試目標本身、解析路徑或請求逾時設定所致。比較節點時，應在相同條件下觀察相近時間對同一目標的結果，再搭配實際服務驗證。頻繁重新測試不但會增加請求，也容易把短暫波動誤認為長期品質差異。

自動測試型策略組同樣會受測試目標與間隔影響。測試間隔過短可能讓選擇頻繁變動，但長連線不會隨每次切換立即改道。若某項服務需要穩定的出口，手動固定可用節點可能更合適；若更重視持續可用性，則需要合理設定故障轉移。不要只憑單一延遲數值，就判定節點適合影片、會議或大型檔案傳輸；這些情境仰賴的指標並不相同。

依連線流程保留排錯資訊

發生故障時，先確認不經代理的基本網路是否正常，再檢查訂閱有效性、核心監聽、系統入口、規則命中與 DNS。記下一個能穩定重現問題的目標與明確時間，不要一次測試十多個應用程式後再混在一起判斷。記錄檔先維持一般詳細程度，只有在需要進一步定位時才短暫提高層級；排查結束後請恢復原狀，避免記錄檔持續增長並累積不必要的瀏覽資訊。

連線遭拒與連線逾時代表不同情況。前者常表示本機連接埠沒有監聽、遠端服務拒絕連線或防火牆主動封鎖；後者則可能與封包遺失、路由、目標無法連線或解析等待有關。錯誤訊息只是線索，不能直接當成結論。請依發生位置判斷：若本機入口拒絕連線，換遠端節點通常沒有幫助；若規則已命中但遠端交握失敗，反覆切換系統代理也無法修復認證問題。

整理求助資料時，保留用戶端與作業系統名稱、使用模式、重現步驟、目標類型及已遮蔽敏感資料的錯誤資訊。刪除訂閱網址、節點位址中的帳戶參數、密碼與可識別個人身分的資料。記錄檔可能包含瀏覽網域，截圖中的 QR Code 也可能等同憑證。若已公開完整訂閱網址，請向服務提供者重設相關存取憑證；只刪除貼文無法消除憑證已被複製的風險。

定期清除不再使用的設定、過時規則與測試用系統代理；備份則保留可用設定及本機修改說明。退出用戶端後，確認系統網路已恢復；休眠及重新啟動後，也要確認啟用的設定正確。遇到類似故障時，先查閱自己的變更記錄，再參考本站使用文件與疑難排解文章。本章的目的不是頻繁維護，而是透過少量記錄，讓每次復原都有明確方向。

九、進階設定：從可用設定到可理解的設定

先建立實驗副本並確認觀察方式

完成前八章後，進階學習不應從疊加更多參數開始，而要先理解現有設定的運作方式。複製一份可用設定作為實驗副本，為每次修改記下目的、預期結果與復原方式。測試時一次只改變一個變因，以相同目標建立新連線，記錄命中的規則與最終外連方式。能說明修改前後的差異，才算真正掌握該參數，而不是碰巧得到一次可用結果。

第一階段適合整理設定架構：將遠端訂閱內容、本機規則、策略組偏好與裝置設定分開管理。確認哪些欄位由用戶端產生、哪些來自遠端設定、哪些由覆寫功能加入。若不清楚最終設定如何合併，就先研究用戶端的合併順序，不必急著加入複雜指令碼。設定規模變大後，清楚劃分來源比縮短檔案長度更有價值。

依相依順序學習 DNS 與提供器

第二階段可深入了解 DNS。先釐清基礎解析器、代理網域解析與目標網域解析各自負責哪個環節，再研究 nameserver、fallback 及其篩選條件。不要只把多個加密解析位址堆在一起，就認為設定更可靠；解析器本身的網域可能也需要引導解析，存取路徑還可能依賴尚未建立的代理。相依循環會讓設定看似完整，啟動時卻一直等待。

各項欄位可搭配閱讀DNS 的 nameserver、fallback 與劫持設定詳解。請留意，fallback 的用途與判斷方式取決於設定及核心實作，不宜將它機械地理解成主要解析器失敗後才啟用的備用清單。先建立可重複的網域測試，再觀察解析結果、規則命中與連線狀況；不要只看回傳位址就下結論。

第三階段再加入代理提供器與規則提供器。它們能將經常更新的資源從主設定中拆開，但也會增加下載、快取與啟動相依項目。請分別確認資源來源、格式、儲存路徑與更新間隔，並檢查首次下載失敗時是否有可用快取。不同裝置的路徑權限各異，桌面版可用的相對目錄用於行動裝置或服務環境時，可能需要交由用戶端重新管理。

伺服器、路由器與控制介面的適用範圍

第四階段才考慮在伺服器或路由器上執行 Mihomo 核心。這些環境沒有桌面介面代為處理權限、服務啟動與系統復原，需要自行管理設定路徑、執行使用者、記錄檔與路由。先驗證本機明確指定的代理，再規劃區域網路入口與防火牆範圍，不要直接取代預設閘道。路由器還涉及處理器架構、記憶體與系統元件，不能只根據壓縮檔名稱判斷是否適用。

控制介面用於查看狀態或管理核心，不是一般的代理入口。若需要遠端存取，應限制監聽範圍並設定驗證，再搭配防火牆與受保護的管理通道。不要將控制介面直接開放到公用網路，也不要在公開的設定儲存庫中保留認證欄位。分享區域網路代理同樣需要明確界定使用者與存取範圍；允許區域網路連線只是開啟入口，不會自動建立完整的存取控制。

若要處理企業內網、依應用程式分流、雙網路出口或 IPv6，請先寫出預期路徑：哪些流量進入核心、哪些必須維持直連、由誰負責解析，以及中斷代理後應呈現什麼狀態。IPv6 需同時考量位址、解析與路由，不能只開啟一個欄位就認定已完整支援。若涉及單位網路政策或受管理裝置，請先取得授權，不要透過代理設定規避既有存取限制。

最終應建立一套容易理解的個人設定：每個策略組用途明確、每項例外都有原因、每個背景服務都知道如何停用，更新失敗時也有復原方式。初次連線可回到快速入門文件，更換裝置則可前往用戶端下載頁。將學習成果整理成少量清楚的規則與穩定的操作流程，比長期複製不理解的設定片段更容易維護，也更容易判斷下次網路異常發生在哪個環節。