Clash 使用指南：
從安裝到規則與 TUN

一、核心概念與連線路徑

先分清用戶端、核心與服務

在 Clash 生態系中，用戶端負責提供操作介面，核心負責解析設定、處理連線及執行規則，遠端服務則提供實際出口。三者並非同一回事。安裝用戶端不會自動產生可用節點；訂閱也不是用戶端帳號。遇到問題時，先判斷故障來自介面、核心設定或遠端服務，就能避免把所有異常都歸咎於軟體安裝失敗。

許多用戶端採用 mihomo 核心，但實際支援情況仍取決於隨軟體提供的核心版本、系統權限及用戶端實作。介面能匯入某個檔案，不代表檔案中的每個欄位都已生效。反過來說，核心支援某項功能，介面也可能還沒有提供對應選項。本文的 YAML 範例以 mihomo 常見語法為基礎，套用前請確認目前用戶端提供的設定入口。

將一次連線拆成四個環節

瀏覽器連線至網站時，通常會先解析網域名稱，再建立連線、完成加密交握，最後交換應用程式資料。代理可能介入其中多個環節：系統代理告訴應用程式將請求交給本機連接埠，規則決定連線採用哪個策略，遠端節點再連線至目標網站。任何一個環節失敗，都可能造成網頁無法開啟，因此只看瀏覽器最後顯示的錯誤訊息，往往不足以找出原因。

本機監聽位址通常是迴送位址，表示只接受本機連線；連接埠則是應用程式進入核心的入口。它與遠端節點的伺服器位址及服務連接埠完全不同。修改本機連接埠後，瀏覽器或終端機中手動填寫的代理位址也要一併更新。遠端節點參數通常由訂閱提供，不應因本機連接埠衝突就任意修改，否則會把兩個不同問題混在一起。

策略群組是選擇連線去向的工具，不是節點本身。手動選擇群組可指定成員；自動測試群組會依設定的測試條件選擇成員；故障轉移群組則優先考量可用性順序。規則可以指向策略群組，也可以指向直連等內建動作。看到策略群組名稱時，不要只憑名稱判斷其行為，應展開檢查群組類型、成員及目前選取項目。

了解接管、分流與解析的界線

系統代理、TUN 與規則模式處理的是不同問題。系統代理與 TUN 主要決定流量如何進入核心；規則模式決定流量進入後如何分流；DNS 設定則決定網域名稱如何解析，以及相關資訊如何用於比對。這些設定可以搭配使用，不能互相取代。啟用 TUN 後仍可使用規則模式；關閉系統代理也不代表所有流量都一定不會進入核心。

設定中的 DNS 與裝置目前網路提供的 DNS 也可能同時存在。應用程式自行使用加密 DNS、瀏覽器內建解析及區域網路網域，都會讓連線路徑更加複雜。暫時不必立刻調整解析方案，但請記住：連線結果異常時，網域解析是需要獨立檢查的一環。使用 IP 位址與網域名稱測試得到不同結果，通常就是繼續追查解析路徑的線索。

第一次驗證時，選一個一般網站作為目標，同時查看用戶端的連線記錄。記錄中應能找到目標網域或位址、使用的策略及連線狀態。若沒有記錄，先檢查流量接管入口；若有記錄但連線失敗，再檢查節點、解析及遠端錯誤。先找出問題所在的環節，再逐步縮小範圍，後續各章都會用到這個方法，也比反覆重裝更能保留有效線索。

二、依平台與需求選擇用戶端

先選操作介面，再比較功能

日常使用圖形介面時，可先考慮 Clash Plus，再依作業系統與功能需求比較其他用戶端。選擇重點不在選項數量，而在訂閱更新、策略選擇、連線記錄與權限提示是否容易理解。安裝前請至下載中心查看目前的平台下載項目，確認系統架構及安裝形式，避免先下載多個程式，再在相似介面間反覆搬移設定。

桌面平台上，Clash Verge Rev、FlClash 與 Clash Nyanpasu 可作為不同介面及操作流程的比較對象。不要預設它們的設定可以逐項照搬：訂閱增強功能、服務模式、核心更新及記錄檔入口可能各不相同。若需要長期維護裝置，清楚知道設定儲存位置及還原方式，比只比較首次啟動畫面更重要。

架構與系統整合比名稱更重要

處理器架構應以系統資訊為準，不要只看電腦品牌。Apple Silicon 與 Intel 的 macOS 安裝檔需要區分；Windows 裝置也可能採用不同架構。Android 通用版與特定架構版本的適用範圍不同。請從下載頁提供的項目中選擇，不要根據檔名規律猜測不存在的安裝檔網址。

Linux 還要區分各發行版的套件管理方式。適用於 Debian 系發行版的套件，不能直接當成 RPM 系發行版的安裝套件。圖形用戶端適用於桌面工作階段；純命令列核心則需要自行處理設定目錄、服務啟動與記錄檔讀取。伺服器沒有圖形介面時，不必為了使用代理額外安裝整套桌面環境，直接搭配核心與服務管理工具通常更清楚。

行動裝置通常透過系統 VPN 介面接管流量，常見限制是同一時間只能由一個相關服務使用該介面。其他安全工具、工作設定檔或網路加速應用程式可能造成衝突。桌面系統也可能有虛擬網卡與路由競爭的情況。因此，若需求包含企業 VPN 或特殊區域網路，選擇時應優先確認能否明確控制接管範圍，不要假設所有網路工具都能同時運作。

另外確認訂閱相容性與維護狀態

同樣標示可匯入訂閱，實際接受的格式可能不同。完整的 Clash YAML、獨立節點清單及其他用戶端的設定並非同一種輸入格式。尤其選擇 Surfboard 時，應先確認提供者支援相應格式，不要把設定檔副檔名當成相容保證。轉換設定可能遺漏規則、策略群組或協定參數；即使轉換成功，也仍須檢查實際連線路徑。

Clash for Windows 與 ClashX Meta 已停止維護，僅供封存參考。若現有環境確實依賴這些程式，可將其作為遷移參考，但新裝置應優先評估仍在維護的方案。舊程式能啟動，不代表能辨識新訂閱中的協定與欄位。若出現未知欄位、節點遭略過或核心報錯，請先檢查功能支援差異，不要立刻判定訂閱已失效。

在 iOS 上使用 Clash Plus 時，請從下載中心前往 App Store，也可查看官方網站 clashplus.io 的產品說明。跨平台使用同名用戶端時，也不要假設桌面與行動版的權限完全相同。完成選擇後，記下用戶端名稱、系統架構、設定來源與主要用途；這些資訊會是後續疑難排解時最實用的環境說明。

三、安裝、權限與基本環境檢查

首次啟動時，先盡量不要變更設定

安裝前，先結束正在執行的同類代理工具，並記錄系統目前的代理設定與 VPN 狀態。兩套程式同時修改系統代理時，後啟動的程式可能覆寫前一套設定；結束程式的順序也會影響還原結果。已有工作設定的裝置應先備份，不要把解除安裝舊程式當成遷移的第一步。等新程式能匯入設定並穩定運作後，再處理舊環境，會更容易復原。

開啟用戶端後，先確認主畫面、設定頁與記錄檔頁面都能正常顯示，暫時不要啟用開機自動啟動、TUN 或複雜覆寫。此時尚未設定訂閱、沒有節點都屬正常情況，不應視為安裝異常。若程式啟動後立即關閉，優先檢查系統相容性、架構是否相符、安裝目錄存取權限及安全軟體的封鎖記錄，不要不斷重複下載同一個檔案。

確認權限要求對應的實際用途

桌面用戶端可能會要求額外權限，以安裝系統服務、虛擬網卡或網路延伸功能。先了解用途再授權，不要把長期以最高權限執行整個圖形程式當成通用解法。系統代理通常與目前使用者的工作階段有關；TUN 則可能涉及服務元件與路由調整。遇到權限不足時，先查看用戶端針對該功能的安裝說明，區分是缺少服務還是服務尚未啟動。

macOS 請依系統提示完成網路相關授權，並在系統設定中確認對應項目的狀態。Android 與 iOS 首次啟用流量接管時會出現 VPN 授權提示；拒絕後介面仍可能正常開啟，但流量不會依預期進入核心。若裝置由公司或機構管理，相關權限可能受到政策限制，請遵循管理規定，不要反覆安裝以試圖繞過限制。

安裝完成後，找出設定目錄與記錄檔入口，確認用戶端使用的是可攜式目錄、使用者資料目錄，還是獨立服務目錄。介面顯示的設定檔不一定就是實際交由核心執行的檔案。為了避免後續混淆，可先記下目錄位置，不必立即手動編輯其中內容。直接修改產生的檔案，常會在下次儲存或啟動時被用戶端覆寫。

本機連接埠與監聽範圍

本機連接埠是應用程式連線至核心的入口。若某個連接埠已被其他程式占用，記錄檔通常會出現繫結失敗或位址已使用等訊息。此時可關閉占用中的程式，或在用戶端支援的設定位置調整監聽連接埠，並同步修改手動輸入的代理位址。不要為了避開本機衝突而修改訂閱中的遠端服務連接埠，兩者影響的是完全不同的連線環節。

# 僅用於了解本機入口，並非完整的可上網設定
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

範例中的混合連接埠可接受常見的 HTTP 與 SOCKS 代理請求，但實際連接埠應以用戶端顯示的執行值為準。關閉區域網路存取有助於將初步疑難排解範圍限制在本機。若日後需要供其他裝置使用，還要一併考量監聽位址、防火牆及存取控制；不能只開啟區域網路選項，就認為已建立妥善的共享環境。

基本檢查的目標不只是能否開啟某個網站，而是程式能正常啟動、核心沒有持續報錯、監聽入口清楚，而且結束程式後網路能還原。完成後再匯入訂閱，問題範圍會更明確。Linux 使用者若打算採用命令列部署，可接著閱讀桌面用戶端與 systemd 兩種部署方式，不要把桌面自動啟動與系統服務混為一談。

四、匯入訂閱、更新與設定持續保存

先確認匯入的內容類型

訂閱通常是服務提供者維護的設定網址，用戶端透過網址取得節點、策略群組與規則等內容。網址可能包含個人存取識別資訊，應妥善保管。不要放進公開截圖、客服案件內容或共用文件。匯入前先確認提供者要求的用戶端類型與格式；能在瀏覽器開啟某個網址，不代表回傳內容適用於目前的核心。

在用戶端中找到訂閱、設定或設定檔入口，新增遠端設定、貼上網址並儲存。更新完成後，還要將其設為目前使用的設定，再檢查策略群組與節點是否出現。有些用戶端會將下載與啟用分成兩個步驟；只完成下載，核心可能仍在使用舊設定。若介面支援替設定命名，取個能辨識來源與用途的名稱即可，不要將完整網址放進名稱。

首次匯入後，請檢查更新記錄與核心執行記錄，不要只看成功提示。下載成功只代表收到回應；解析成功代表內容結構可讀取；核心載入成功才表示設定已進入執行階段。若某些節點協定不受支援，畫面可能只顯示部分成員。此時應比對節點數量變化與警告訊息，避免誤以為提供者主動刪除了節點。

更新失敗時，分別檢查請求、內容與載入階段

請求失敗時，先確認網址是否完整複製，特別注意結尾參數與多餘空格。接著查看錯誤屬於解析失敗、連線逾時、存取遭拒或重新導向異常。網路可用但無法連上訂閱，可能與更新請求所走的網路路徑有關。不同用戶端對更新請求是否經由現有代理處理的方式並不一致，請在對應設定中確認，不要假設更新一定會跟隨目前的策略群組。

取得內容後仍無法載入，請檢查回傳的是 YAML、其他格式，還是網頁錯誤訊息。帳戶狀態頁面、登入頁面與人機驗證頁面都不能當成代理設定載入。若伺服器暫時回傳異常內容，不要將錯誤頁面儲存後繼續手動修改。保留原有可用設定並等待來源恢復，通常比清除本機資料更穩妥，也能避免失去仍可使用的節點與規則。

載入階段報錯時，先查看錯誤指出的欄位或行號。YAML 以縮排表示階層，使用定位字元、漏寫冒號或清單層級錯誤都可能造成解析失敗。能解析的 YAML 也可能有語意問題，例如規則引用了不存在的策略群組。要區分文字格式錯誤與核心驗證錯誤：前者檢查結構，後者檢查欄位支援情況及名稱引用。

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

直接編輯訂閱產生的檔案，修改內容往往會在下次更新時消失。長期設定應放在用戶端提供的覆寫、合併、修補或本機擴充入口；具體名稱與合併順序請以目前用戶端為準。先做一項小幅調整來驗證能否持續保存，例如變更記錄等級；再手動更新訂閱並重新啟動核心，確認執行中的設定確實保留了變更。

合併陣列時尤其要小心。某些覆寫機制會取代整份規則清單，而不是只新增一條；策略群組也可能被同名項目覆蓋。套用前應查看預覽或匯出的最終設定，確認原有節點、策略群組與預設備用規則仍然存在。不要在介面選項、本機檔案及遠端修補三處同時維護同一欄位，否則很難判斷最後生效的值。

更新後立刻變慢，不必先更換整套用戶端。可比較更新前後使用的節點、策略群組選擇與規則比對結果是否有變化。節點名稱變更時，原本的手動選擇可能失效，用戶端便會改用其他成員。簡易操作流程請參閱入門指南的訂閱步驟；本章重點是讓更新過程可觀察、可復原，而不只是設定一個定期工作。

五、代理模式與連線驗證

規則、全域與直連模式各自會改變什麼

日常使用建議從規則模式開始。進入核心的連線會依規則清單決定去向，既能讓需要的服務直接連線，也能將特定請求交由代理處理。全域模式通常會將進入核心的一般連線交給全域策略，適合短時間比對測試；直連模式則可用來檢查不經代理出口時的情況。模式名稱只描述核心內的選擇方式，不保證所有應用程式都已被接管。

常見的誤解是切換至全域模式後，整台裝置的所有通訊就會經過代理。若某個應用程式不讀取系統代理，其連線可能根本沒有進入核心；切換模式當然也不會改變結果。因此疑難排解時，應先查看連線記錄中是否有請求，再確認符合的策略，最後才判斷出口是否可用。不要把接管範圍與分流方式當成同一個選項。

建立最精簡的驗證流程

先關閉 TUN、啟用系統代理，選定一個節點並開啟測試網頁。同時開啟連線面板，依目標網域篩選，查看使用的策略與出口。瀏覽器載入頁面只是第一層證據；連線記錄可證明請求確實進入核心，記錄檔則能進一步說明失敗環節。若只用出口位址查詢頁驗證，也要確認該查詢請求本身是透過預期路徑送出的。

命令列工具可能不會讀取桌面系統代理，可以明確指定本機入口進行比對。以下命令假設用戶端的混合連接埠確實是七八九零；實際操作時，請改成介面顯示的連接埠。測試目標是公開的示範網站，不代表所有目標都能以相同方式連線。成功送出一次請求，表示這條路徑大致正常，不代表所有協定、應用程式與網站都已正常運作。

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

第二個命令會將目標主機名稱交由 SOCKS 代理解析，有助於與先在本機解析網域的路徑比較。若兩種方式結果不同，應結合用戶端 DNS、節點協定與記錄檔繼續判斷，不要只憑結果就斷定發生了某種洩漏。測試時記下命令、時間、模式與節點，之後以相同條件重測才有比較價值。

延遲測試不代表下載效能保證

用戶端顯示的測試數值，通常反映特定請求的往返時間，實際意義取決於測試網址與實作方式。數值較低不代表檔案下載一定更快，也不保證影片、遊戲或特定網站更穩定。測試失敗可能只是測試目標無法連線，節點仍可能適用於其他目標。選擇節點應考量實際用途、連線成功率與一段時間內的穩定性，不要只看清單排序。

瀏覽器正常但另一個應用程式失敗時，先檢查該應用是否支援系統代理、是否設定了獨立代理，以及是否只將部分流量交由代理處理。登入流程也可能呼叫系統元件或其他程序，導致主視窗與登入視窗採用不同路徑。不要立刻切換至全域模式並長期維持；先找出失敗的連線，才能判斷應調整應用設定、新增規則，或擴大接管範圍。

切換節點或模式後，已建立的長連線可能繼續沿用舊路徑。驗證新設定時，可重新開啟目標頁面，必要時關閉相關連線再送出請求，但不應任意清除所有無關工作階段。有些應用程式也會快取解析結果與連線池，需要結束後重新啟動。若將舊連線當成新設定的結果，可能會誤以為修改成功後仍毫無變化。

完成本階段後，應能重現一條成功連線，並說明所用的模式、入口與出口。若要進一步檢查首次連線，可閱讀選擇節點、測試並確認流量去向。只有這條最精簡的連線路徑穩定後，繼續調整規則與 TUN 才能明確判斷新設定造成的變化。

六、規則順序、策略群組與分流維護

從第一條比對規則到最後的預設備用規則

規則清單通常會由上而下比對，第一條符合條件的規則就會決定連線去向。因此，規則內容與排列順序同樣重要。範圍很廣的網域後綴規則若放在前面，可能使後面的精確網域規則永遠沒有機會執行。新增規則前，先找出目前的比對位置，不要只在檔案末尾新增；若末尾已有預設備用動作，新增內容尤其容易看似儲存成功，實際上卻始終不生效。

網域規則適合描述網站或服務範圍，位址區段規則適合處理明確的網路範圍，程序規則則受平台、權限及識別能力影響。同一個應用程式可能存取多個網域，也可能透過輔助程序發起連線，因此將主要網域加入規則，不代表已涵蓋該應用的所有請求。維護時應查看實際連線，不要只憑應用程式名稱猜測它會連至哪些伺服器。

# 設定片段：併入現有設定，並非完整訂閱
# 本範例不會依據中國大陸或其他地區標籤進行判斷
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

範例使用內建的直連動作以說明規則順序，不適合作為所有人的實際分流方案。精確網域規則只符合指定名稱；後綴規則則涵蓋該網域及其子網域。位址區段規則的附加選項可避免為了比對該位址而主動觸發解析。最後的預設備用規則負責處理前面都未符合的連線。實際需要經由代理連線時，目標名稱必須對應目前設定中存在的策略群組。

先確認群組類型，再調整成員

手動策略群組適合固定選擇；自動測試群組適合依據設定的測試結果選擇成員；故障轉移群組則更重視順序與可用性。測試目標、間隔與容許值都會影響切換行為，不能只看到「自動」兩字，就假設它一定會選到最適合實際使用的節點。需要穩定工作階段的應用程式，也應留意切換是否會中斷現有連線或重新建立連線。

策略群組之間可以互相引用，但名稱必須正確，引用關係也應避免形成循環。訂閱更新後群組名稱若有變更，本機規則仍引用舊名稱就可能載入失敗。修改前先列出規則目標、群組成員與最終節點間的對應關係，確認每條路徑都能連至可用出口。複雜設定中，最難排查的往往不是規則語法，而是多個名稱相近的群組之中究竟選中了哪一個。

查看連線記錄驗證規則，不要猜測

新增分流規則時，先選定一個明確目標，記錄修改前符合的規則與出口，再將小範圍規則放在合理位置，重新建立連線並觀察結果。若結果沒有變化，依序檢查目前使用的設定是否正確、覆寫是否確實合併、規則是否排在範圍更廣的項目前方，以及目標請求是否仍是舊連線。檢查完這四項後，再考慮規則類型本身是否適用。

位址比對與網域比對的結果可能受到 DNS 行為影響。若核心無法取得原始網域名稱，就只能依據現有資訊比對；反過來說，fake-ip 對應機制有助於保留網域與連線的關聯，但也需要完整的流量接管路徑。不要把所有異常都歸因於規則集過期。先確認連線記錄中顯示的是網域還是位址，再決定要新增網域規則、位址規則，或修復解析路徑。

規則集適合重複使用一批持續更新的條件，但須確認它採用的行為類型、儲存位置及規則引用方式。下載成功不代表已建立引用，檔案類型也不能混用。加入外部規則集前，應了解更新來源及失敗時的影響，並保留上一份可用內容。不要為了增加涵蓋範圍而疊加大量重複規則；規則重複越多，比對結果越難解釋。

維護一段時間後，應清除已失去用途的例外，尤其是測試期間新增的強制直連或強制代理規則。這些項目可能讓後續的訂閱規則失效，卻很難從介面上一眼看出。穩定的規則設定不是項目越多越好，而是發生問題時能迅速說明連線為何走到這裡，並安全撤銷最近一次修改。

七、TUN 接管與 DNS 協同

需要擴大流量接管範圍時再啟用

TUN 透過虛擬網路介面接收系統流量，適合處理不遵循系統代理的應用程式。但它不會提供新的遠端出口，也不會自動修復失效節點。啟用前，應先使用系統代理確認訂閱與節點可用，並儲存目前設定。如此啟用後若發生問題，便能將調查範圍集中在權限、路由、DNS 或虛擬介面，而不必從頭懷疑整條連線路徑。

桌面版通常需要相應的服務權限或網路元件；行動版則主要由系統 VPN 介面管理。若已使用企業 VPN、安全工具或其他虛擬網路軟體，請先確認它們是否也會修改預設路由或 DNS。多個工具各自運作正常，組合使用時仍可能互相競爭路徑。測試期間盡量只保留一種流量接管工具，同時記下原本必須存取的區域網路資源，以便逐項檢查。

# mihomo 設定片段，須與有效節點、規則及 DNS 設定合併
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

範例展示常見欄位間的關係，不保證適用於每種用戶端與作業系統。自動路由決定是否由核心設定相關路由；自動識別出口介面用於選擇實際網路出口；協定堆疊選項則與系統相容性有關。用戶端可能透過介面產生這些欄位；若直接寫入檔案後又遭覆寫，應改由用戶端提供的正式入口調整，不要同時維護兩套互相衝突的設定。

DNS 不是附加選項

DNS 劫持通常只處理經由流量接管路徑的傳統解析請求，不能因此認定所有應用程式內建的加密解析都會被接管。瀏覽器的安全 DNS、應用程式私有解析及企業內部網域，都可能採用不同路徑。診斷時應分別檢查一般網站、區域網路名稱及依賴特定解析服務的應用程式，不要只用單一公開網域的結果代表整體網路狀況。

fake-ip 模式會回傳供對應使用的位址給應用程式，再於後續連線中關聯原始網域；這種機制有利於網域分流，但需要確保對應關係與連線路徑一致。redir-host 較接近直接回傳實際解析位址的方式，但同樣有比對與快取條件。兩者沒有脫離使用情境的絕對優劣。某個區域網路服務發生異常時，應先調查網域及應用程式需求，不要立刻全面切換解析模式。

核心的上游解析、代理伺服器網域解析及直連網域解析，可能各自負責不同工作。看似合理的加密上游位址，若必須依賴尚未建立的代理才能連線，就可能形成啟動依賴循環。節點伺服器本身若使用網域名稱，也要確保解析該名稱的路徑可用。欄位關係可接著參閱nameserver、fallback 與 fake-ip 設定解析。

啟用後分階段檢查，異常就復原

先測試瀏覽器，再測試原本不使用系統代理的應用程式，最後檢查印表機、網路儲存裝置、遠端桌面等區域網路服務。每個步驟都要查看連線記錄與路由相關記錄檔。若區域網路發生異常，先確認目標位址是否屬於應略過的範圍，以及解析結果是否仍然正確。不要第一時間關閉系統防火牆；這會擴大變更範圍，也容易掩蓋真正原因。

從無線網路切換至有線網路、行動熱點或從休眠狀態恢復後，出口介面與預設路由可能有所變動。若 TUN 原本可用，切換網路後卻失效，先檢查介面識別與服務狀態，再重新啟動相關連線。有些環境需要重新建立虛擬介面，但不代表每次都必須重裝用戶端。保留切換前後的記錄檔，有助於區分介面變更、節點重新連線與 DNS 快取問題。

可利用出口查詢與解析測試輔助觀察，但單一網頁無法證明整台裝置的所有應用程式都採用相同路徑。結論應限定於實際測試過的應用程式與請求類型。TUN 的理想結果是所需應用程式已被接管、區域網路仍可使用，且切換網路後能恢復；不必為了讓設定看起來完整而一直開啟所有進階選項。

八、日常維護、備份與疑難排解

將可用狀態記錄為基準

連線穩定後，記錄用戶端名稱、核心資訊、目前使用的設定、訂閱來源、接管方式及必要的本機例外。備份應包含個人覆寫與必要的策略選擇，但不應公開含有存取識別資訊的網址。只儲存主畫面截圖通常不足以還原環境，因為真正影響執行的欄位可能藏在服務設定、DNS 或本機擴充設定中。

備份檔案應儲存在只有本人或獲授權人員可存取的位置。準備更換裝置時，先匯出用戶端支援的設定，再檢查匯出內容是否包含訂閱憑證與本機路徑。桌面系統的路徑不一定適用於行動裝置，部分介面偏好也無法跨系統還原。遷移成功的標準，是新裝置能重建預期連線，而不是匯入檔案時沒有顯示錯誤訊息。

分開更新各項目，預留觀察時間

用戶端、核心、訂閱與規則集屬於不同的更新層。不要在同一時間全部更新，否則發生問題後無法判斷變化來自哪一項。可先更新訂閱並驗證，再更新用戶端或核心，最後處理個人規則。每次都保留一個可復原的狀態；尤其在重要工作前，不宜臨時大幅調整權限、網路延伸功能或路由。

閱讀更新記錄中的功能變更時，應搭配自己的實際設定判斷。若新增的協定支援與目前使用方式無關，不必立即遷移；若舊欄位的行為有所變更，則應先在副本中驗證。圖形用戶端更新也可能改變設定合併順序或預設值，因此升級後應重新檢查最終執行設定，不要只確認原本的按鈕仍顯示為啟用。

依故障範圍選擇疑難排解入口

先確認故障影響的是一個目標、一個應用程式，還是所有連線。只有單一網站受影響時，應優先檢查目標服務狀態與單一規則；所有節點都失敗時，應優先檢查本機入口、解析及目前的網路限制；只有特定節點異常時，則應集中查看該節點的連線錯誤。判斷影響範圍不是最後結論，但能大幅減少沒有根據的重複操作。

從錯誤發生的時間點附近開始閱讀記錄檔，先找出第一個相關錯誤，再查看後續連鎖訊息。解析失敗可能導致後續連線全部逾時；本機連接埠繫結失敗也可能造成介面連線異常。不要只截取最後一行。暫時提高記錄詳細程度後，疑難排解完成時應恢復日常等級，避免長期累積大量記錄、增加儲存空間使用量，並暴露不必要的存取資訊。

分開測試開機自動啟動與休眠恢復

開機啟動用戶端、啟動核心服務及自動啟用系統代理，可能是三個獨立選項。設定完成後應實際重新啟動一次，檢查登入前後的服務狀態，以及網路尚未就緒時如何處理訂閱更新。不能只看啟動項目清單中有程式名稱，就認定代理已正常運作。需要輸入密碼解鎖或等待使用者確認的環境，也可能影響自動連線所需時間。

休眠恢復與網路切換也應納入維護檢查。若恢復後只有舊工作階段失敗，重新建立連線可能就足夠；若所有請求都沒有記錄，請檢查流量接管入口與服務；若記錄存在但解析持續失敗，再檢查 DNS 與出口。分層排查可保留仍正常運作的部分，不必每次都重新啟動整台裝置，讓暫時性的線索消失。

用戶端顯示已連線但存取仍異常時，先依本指南的精簡驗證流程重新測試，再根據結果選擇排查方向。若無法說明變更造成的影響，請還原至最後一個可用狀態，並一次只重新加入一項修改。維護的目標不是記住所有錯誤訊息，而是建立穩定的記錄方式，讓下次遇到類似故障時能更快找出原因，也避免臨時修復變成長期隱患。

九、從可用設定到易維護的進階方案

先學會查看最終設定

進階設定的第一步不是新增更多欄位，而是能說明目前執行設定由哪些來源產生。訂閱、用戶端預設值、介面選項與本機覆寫可能共同參與合併。先找到預覽、匯出或執行設定入口，抽查監聽連接埠、模式、DNS、策略群組與規則順序。若檔案中的值與介面顯示不同，應先釐清覆寫關係，再決定要修改哪一層。

建立一份專供實驗使用的設定副本，並保留日常設定作為基準。每次實驗只調整一個項目，記下預期結果與驗證方式。例如加入規則集時，先確認檔案可更新，再確認規則已被引用，最後查看測試連線是否符合該規則。即使實驗失敗，也能指出問題發生在哪個環節，而不是只得到整套設定無法使用的結論。

依相依關係逐步擴充功能

可先學習規則集，再了解節點提供者，之後研究 DNS 分流與更複雜的策略群組。規則集用於重複使用條件；節點提供者則負責管理節點來源，兩者並不相同。使用前應確認內容格式、行為類型、更新位置與引用方式。某個來源可以下載，不代表其內容會自動加入現有規則或策略群組；必須明確建立引用關係。

定期更新、健康檢查與自動策略選擇，也應放在同一張相依關係圖中理解。節點清單更新可能改變成員；健康檢查提供可用性資訊；策略群組再依自身類型選出成員。若其中一層更新失敗，介面可能仍保留舊結果。排查自動選擇異常時，先確認成員是否為最新、測試是否成功，再檢查選擇邏輯，不要直接縮短測試間隔。

協定功能必須同時符合核心支援、用戶端設定支援及伺服器參數正確等條件。文件中出現某個協定名稱，不代表目前安裝的核心一定支援。遷移舊設定時，可閱讀mihomo 與原版 Clash 核心差異，重點核對欄位與協定，不要只憑軟體名稱推斷所有設定都相容。

終端機與服務環境分開管理

終端機環境變數通常只會影響目前工作階段及其子程序，不會自動替所有桌面應用程式設定代理。不同工具對環境變數的支援也有差異。需要暫時測試時，優先使用命令本身的代理參數；確實需要工作階段層級的設定時，再使用環境變數。不要將本機位址長期寫入多個啟動檔後忘記來源，否則用戶端結束後，終端機可能仍指向已失效的連接埠。

# POSIX shell：僅為目前工作階段及其子程序設定
# 連接埠須與用戶端實際監聽值一致
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

# 測試結束後，清除本範例設定
unset http_proxy https_proxy

由服務管理工具啟動的程序通常不會繼承互動式終端機中的所有環境變數。部署伺服器時，應明確設定檔案路徑、工作目錄、執行使用者與記錄檔位置，再考慮開機自動啟動。不要因為程式能在終端機中執行，就認定系統服務已正確設定。使用用戶端 API 或控制面板時，也要限制監聽範圍並設定存取控制，避免管理入口暴露於不需要存取的網路。

以驗收清單取代設定複雜度

一套進階設定至少應通過以下檢查：一般網頁可正常開啟、需要代理的應用程式有連線記錄、區域網路服務仍可連線、訂閱更新不會覆蓋個人規則、切換網路後能恢復，以及關閉程式後系統網路能回到預期狀態。這些都是使用結果，不受特定介面限制。若新增功能破壞其中一項，應先解決範圍界線問題，再繼續擴充功能。

涉及旁路閘道器、路由器或多裝置共享時，影響範圍會從單一裝置擴大至其他裝置。此時還需要了解閘道器、封包轉送、防火牆與回程路由，不能直接照搬桌面版 TUN 範例。請先在獨立裝置或可隔離的網路中測試，並保留還原原有閘道器與 DNS 的方法。超出目前知識範圍時，維持穩定的單機方案並非功能不足，而是合理控制影響範圍。

需要重新依照主要操作流程設定，可回到入門指南；準備更換裝置或用戶端，可前往下載中心依平台選擇；遇到特定設定問題，可在技術文章依主題繼續閱讀。完整參考指南的價值不在一次讀完所有欄位，而在每次修改前，都清楚知道目標、條件、證據與復原方式。