Clash 電腦版
從零開始的完整手冊

Clash 不是單純的「開關」，而是一套在本機執行的流量處理鏈。應用程式會先將連線交給本機監聽連接埠或虛擬網卡，Clash 核心再讀取目標網域、目標 IP、網路協定與程序等資訊，按照設定檔中的規則由上而下比對，最後將連線交給 DIRECT、某個代理群組或 REJECT。理解這條路徑，比記住客戶端介面上的按鈕更重要。即使開啟系統代理，某個程式仍然直連；節點可以測試卻無法開啟網頁；規則模式與全域模式的結果不同，根源通常都能回溯到這條鏈上的某個環節。

客戶端、核心與設定檔

桌面客戶端負責介面、設定管理、系統代理開關、日誌顯示與更新等操作；Mihomo 等相容核心則負責實際監聽連接埠、解析規則與轉送連線；YAML 設定檔描述連接埠、DNS、代理節點、代理群組與規則。三者需要分開理解。更換客戶端不一定會改變設定語法，同一份設定能否使用，主要取決於核心支援的欄位與客戶端的匯入方式。客戶端可以正常啟動，也不代表訂閱內容、DNS 或系統代理已設定正確。

常見的本機連接埠包括 HTTP 代理連接埠、SOCKS5 連接埠，以及同時接受兩種協定的 mixed-port。桌面客戶端通常會自動管理這些值。以 mixed-port: 7890 為例，瀏覽器或終端機將代理位址設為 127.0.0.1:7890 後，連線才會進入核心。external-controller 是控制介面，供客戶端介面讀取連線、切換代理群組或載入設定，不應與代理連接埠混為一談。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true
external-controller: 127.0.0.1:9090

系統代理與 TUN 的界線

系統代理是作業系統提供給應用程式的一組 HTTP 或 SOCKS 代理設定。瀏覽器與大多數桌面軟體會讀取它，但終端機指令、遊戲、部分商店應用程式、虛擬機器，以及自行實作網路堆疊的程式可能會忽略它。TUN 模式則會建立虛擬網路介面，在更底層接管 IP 流量，涵蓋範圍通常更廣。兩者不是速度檔位，也不是必須同時開啟的功能。日常瀏覽優先使用系統代理；遇到明確不讀取系統代理的應用程式，再評估是否需要 TUN。

網域、DNS 與規則比對

使用者輸入網域後，DNS 會先將名稱轉換為 IP；規則引擎可能在解析前依網域比對，也可能取得 IP 後繼續執行 GEOIP 或 IP-CIDR 規則。如果 DNS 請求走錯網路路徑，可能出現網頁無法開啟、規則命中與預期不一致，或本地網路網域失效等情況。所謂「節點正常但網站打不開」，問題往往不在代理節點本身，而是出在網域解析、IPv6、瀏覽器安全 DNS 或規則順序的某個環節。

日誌與連線頁是觀察這條處理鏈的兩個入口。日誌會顯示設定是否載入、連接埠是否被占用，以及 DNS 是否報錯；連線頁則會顯示哪些應用程式建立了工作階段、目標為何、命中了哪條規則，以及最後採用哪個策略。第一次使用客戶端時，可以搭配客戶端介面速覽了解代理頁、設定頁、連線頁與日誌頁的分工。建立這些概念後，後續的安裝、訂閱與規則操作就不再只是機械式點擊。

桌面端可選客戶端包括 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash for Windows 與 ClashX Meta；行動端還包括 Clash Meta for Android 與 Surfboard。本網站的下載清單將 Clash Plus 列為全平台首選，因為平台支援完整，適合希望在 Windows、macOS、Android 與 iOS 之間維持相近操作流程的使用者。偏好社群桌面客戶端時，也可以比較 Clash Verge Rev、FlClash 與 Nyanpasu。Clash for Windows 與 ClashX Meta 已停止維護，僅適合處理舊環境或既有設定，不建議作為新安裝的預設選擇。

Windows：架構、安裝目錄與回環限制

多數 Windows 電腦使用 x64 安裝套件。ARM 裝置需要選擇客戶端明確提供的 ARM 架構套件，不能只因系統介面相似就混用。安裝完成後先正常啟動客戶端，確認系統匣圖示、設定頁與日誌頁都能開啟，再匯入訂閱。若系統提示需要確認來自網路的應用程式，核對下載入口與檔名後，依照系統流程處理，不要為了略過一次提示而關閉整套安全功能。

開啟系統代理後，傳統桌面瀏覽器通常可以直接使用；部分 UWP 應用程式會受到 Windows 回環隔離影響，無法存取本機代理連接埠。此時應使用客戶端提供的 UWP 回環工具，將確實需要代理的應用程式加入豁免清單，再重新啟動目標應用程式。回環設定解決的是「應用程式無法連線至本機代理」問題，不會修復失效訂閱、錯誤節點或 DNS 設定。完整的平台操作與常見問題可參閱Windows 安裝 Clash 完整流程。

macOS：晶片架構與網路權限

在「關於這台 Mac」中確認處理器屬於 Apple Silicon 還是 Intel，再選擇對應的安裝套件。架構不符時，應用程式可能無法啟動，或需要額外的相容層。第一次開啟系統代理、服務模式或 TUN 時，macOS 可能要求輸入管理者憑證並核准網路延伸功能。只要依照系統對話框完成授權即可，不要將客戶端直接移出「應用程式」資料夾後繼續執行，否則登入啟動項目與輔助服務路徑可能失效。

Linux：套件格式與桌面工作階段

Debian、Ubuntu 及其衍生發行版通常使用 DEB；Fedora、RHEL 系列發行版通常使用 RPM。安裝後如果選單入口沒有立即出現，可以結束並重新進入桌面工作階段，或從終端機啟動一次以讀取明確錯誤。Linux 桌面環境對系統代理的實作並不完全一致，瀏覽器可能讀取 GNOME 或 KDE 的代理設定，終端工具則通常依賴環境變數。需要全域接管時再設定 TUN，並先確認系統具備建立虛擬網卡與修改路由的權限。

# Debian / Ubuntu 安裝本機 DEB 套件
sudo apt install ./client-package.deb

# 查看常見連接埠是否已被占用
ss -lntp | grep -E '7890|9090'

如果仍在比較客戶端，可以查看Clash Plus、Verge Rev 與 FlClash 橫向比較。選型時優先考慮目前系統支援、TUN 實作、設定相容性與更新狀態，而不是介面元素的數量。確認選擇後，從下載中心進入對應平台，避免在不同來源之間混用安裝套件與設定說明。

Clash 設定通常以 YAML 檔案存在。完整設定不只包含代理節點，也可能包含代理群組、規則、DNS、TUN 與監聽連接埠。訂閱連結則是設定的遠端來源，客戶端會依連結下載內容並儲存為本機設定。匯入完成後，實際由核心讀取的是本機副本；更新訂閱會重新取得遠端內容，因此直接修改由訂閱產生的設定，可能在下次更新時被覆蓋。

先辨識手上的內容

可直接在瀏覽器網址列匯入的訂閱 URL、由大量編碼字元組成的通用訂閱，以及包含 proxies:、proxy-groups:、rules: 的 YAML 檔案，並不是同一種交付形式。客戶端提示格式錯誤時，先確認連結回傳的內容，不要連續點擊匯入。服務端回傳登入頁面、過期提示或通用 Base64 節點清單時，客戶端可能會將其儲存下來，卻無法作為完整的 Clash 設定載入。

有效的 YAML 對縮排很敏感，應使用空格而不是定位字元。同一層級的欄位要保持相同縮排，清單項目以連字號開頭，包含冒號、井字號或特殊字元的名稱應放在引號中。從瀏覽器複製時，也要避免全形標點與智慧引號。關於 YAML、Base64 與格式轉換的差異，可繼續閱讀Clash 訂閱格式與互轉方法。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    proxies:
      - "範例節點 A"
      - "範例節點 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

匯入、啟用與更新是三件事

匯入只是將訂閱或檔案加入客戶端設定清單；啟用表示選擇其中一份設定交給核心執行；更新則是重新取得遠端內容。操作時，先在設定頁貼上訂閱位址並確認下載完成，再選取該設定，接著到代理頁選擇代理群組策略，最後開啟系統代理。如果設定清單中已有多份檔案，應明確確認目前的啟用項目，避免修改 A 設定，實際執行的卻是 B 設定。

訂閱更新失敗時，應沿著 HTTP 請求鏈排查。首先確認連結尚未過期，且能在目前網路中存取；其次檢查系統時間，時間偏差可能導致 TLS 連線失敗；接著查看客戶端日誌中的狀態碼或解析錯誤。回傳 401、403 通常與授權或連結狀態有關；回傳 HTML 往往表示位址指向網頁而非設定內容；解析錯誤則應重點檢查 YAML 結構與客戶端核心的相容性。不要將完整訂閱連結公開貼到論壇或截圖中，因為連結本身可能帶有存取憑證。

覆蓋風險與本機擴充

需要增加自訂規則時，優先使用客戶端提供的覆寫、合併設定、腳本擴充或規則集功能。這樣可以將服務方維護的節點部分與本機規則分離。如果客戶端不支援合併機制，可以將訂閱設定複製為本機檔案，在副本中修改，同時保留原始訂閱以便更新與比對。更新後再將節點與代理群組的變化合併至本機副本，比直接編輯會自動更新的檔案更容易復原。

設定載入失敗時，日誌中的行號通常會指向解析器發現問題的位置，但真正的縮排錯誤可能出現在前面幾行。可以從錯誤行向上檢查同層級欄位、引號是否閉合，以及清單縮排。如果設定能載入但代理群組為空，請檢查 proxy-groups 引用的節點名稱是否與 proxies 完全一致。節點存在卻無法選擇，可能是群組類型、provider 引用或訂閱轉換結果不完整。將「下載失敗、解析失敗、執行失敗」分開記錄，排查會更直接。

Clash 客戶端常見的 Rule、Global 與 Direct 模式，控制的是核心如何決定最終策略。它們不會改變應用程式是否將流量交給 Clash，也不會自動修復無法使用的節點。系統代理關閉時，即使切換至 Global，未進入本機代理連接埠的瀏覽器連線仍不會經過核心；TUN 已接管流量時，切換模式才會對被接管的連線生效。因此，必須將模式選擇放在完整的流量路徑中理解。

Rule：逐條依規則決定

Rule 是日常使用的預設選擇。核心會從規則清單頂端開始比對，命中後便停止繼續向下檢查。常見結果是本地網路與明確的直連網域走 DIRECT，需要代理的網域進入代理群組，廣告或不希望連線的目標進入 REJECT，其餘流量則由最後的 MATCH 兜底。規則模式的價值，在於同時維持存取範圍、網路路徑與本地服務的相容性，而不是讓所有流量統一走同一個出口。

Global：集中交給全域群組

Global 模式通常會將所有已進入核心的連線交給全域代理群組。它適合暫時判斷「問題是否來自規則」。例如某個網站在 Rule 下失敗、在 Global 下成功，表示節點與基本代理鏈路大致可用，應轉向檢查規則命中、DNS 或代理群組選擇。如果兩種模式都失敗，則優先檢查節點、連接埠、系統代理與網域解析。Global 不適合長期用來掩蓋錯誤規則，因為本地服務、區域網路裝置與不需要代理的連線也可能被送入代理。

Direct：讓已接管的流量直接連線

Direct 模式會讓進入核心的連線直接存取目標。它可用來判斷客戶端接管本身是否造成影響，也可在暫時停用代理時保留核心的執行狀態。但 Direct 不等於完全退出客戶端：本機連接埠、TUN、DNS 模組與連線記錄可能仍在運作。如果要恢復作業系統原本的網路路徑，應關閉系統代理或 TUN，再退出核心，並確認作業系統的代理設定已還原。

代理群組比模式更接近實際出口

模式決定「到哪裡尋找策略」，代理群組才會進一步決定使用哪個節點或子群組。select 群組由使用者手動選擇；url-test 會依指定測試位址定期測量並選擇可用候選；fallback 會依序使用可用節點；load-balance 則根據實作與策略分配連線。測試結果只能反映到測試位址的連通情況，不等同於所有目標網站的使用體驗，也不能代表持續頻寬。

切換節點後，已建立的 TCP、QUIC 或長連線不一定會遷移至新節點。瀏覽器可能重用舊連線，應用程式也可能保留 DNS 快取。需要驗證切換結果時，可以在連線頁關閉相關工作階段，重新開啟目標應用程式，必要時等待舊連線釋放。如果規則將目標送入另一個代理群組，切換目前群組自然不會改變結果，因此應先查看連線頁中的規則與鏈路，而不是只觀察代理頁的高亮項目。

模式切換應服務於判斷，而不是隨機嘗試。每次切換後記錄目標網域、命中規則、實際策略與連線結果，就能快速區分規則問題與鏈路問題。日常狀態建議回到 Rule，並透過自訂規則修正少量例外，這比長期使用 Global 更容易控制。

規則清單會依照由上而下的順序執行，第一條命中的規則決定連線策略。規則系統不是多個條件的綜合評分，也不會自動選擇「更具體」的規則。如果前面已存在寬泛的 DOMAIN-SUFFIX、GEOIP 或 IP-CIDR，寫在後面的例外規則可能永遠沒有執行機會。設計規則時應遵循「精確例外在前、寬泛分類居中、最終兜底在後」的結構。

常用規則類型

DOMAIN 精確比對完整網域，例如只比對 api.example.com；DOMAIN-SUFFIX 比對指定網域及其子網域，適合依網站體系分流；DOMAIN-KEYWORD 依網域中的字串比對，範圍較寬，容易誤傷；IP-CIDR 與 IP-CIDR6 依 IPv4、IPv6 網段比對；GEOIP 依 IP 地理資料庫分類；PROCESS-NAME 依程序名稱比對，但可用性取決於作業系統、權限與核心支援；MATCH 處理前面未命中的剩餘連線。

rules:
  - DOMAIN,printer.lan,DIRECT
  - DOMAIN-SUFFIX,example.org,節點選擇
  - DOMAIN-KEYWORD,example,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

no-resolve 用來告知核心，執行 IP 類規則時不要為了比對而額外解析網域。它適合已取得目標 IP 的連線，也能避免某些規則觸發不必要的 DNS 查詢；但如果規則必須依賴網域解析後的 IP 才能命中，加入此參數可能會改變結果。不應機械式地附加參數，應配合規則類型與連線中繼資料判斷。

策略欄位必須引用實際存在的群組

規則最後一段不是任意標籤，而是代理群組名稱、節點名稱或內建策略。設定中寫了 節點選擇，就必須在 proxy-groups 中存在同名群組，字元、空格與大小寫都要一致。DIRECT 表示直接連線，REJECT 表示拒絕連線。自訂名稱使用中文沒有問題，但在多份設定與覆寫檔案之間維護時，穩定的短名稱比較不容易發生引用錯誤。

將本地例外放在易於維護的位置

家庭 NAS、印表機、路由器管理頁面與公司內網通常需要直連。應先列出明確網域，再涵蓋常見私有位址範圍，同時保留本地網域解析支援。如果直接將所有未知位址交給代理，可能導致區域網路存取繞路或失敗。反過來，過寬的直連規則也會讓原本應走代理的目標提前命中。新增規則時，先從連線頁複製實際目標，不要根據網頁顯示名稱猜測網域，因為一個頁面通常會存取多個 API、靜態資源與驗證網域。

規則集與 provider

大型規則不適合全部寫在主要設定中。支援 rule-provider 的核心可以從本機檔案或遠端位址載入規則集，再透過 RULE-SET 引用。規則集應明確定義行為類型、格式、更新間隔與儲存路徑。遠端規則更新失敗時，核心可能繼續使用快取，也可能因設定方式不同而報錯，因此關鍵規則應評估快取策略與失敗行為。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-network.yaml
    url: https://example.com/rules/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,節點選擇

排查規則時，先在連線頁找到目標工作階段，記錄 Host、目標 IP、命中規則與最終策略。如果命中規則不符合預期，檢查是否有更早的寬泛規則；如果規則正確但策略錯誤，檢查代理群組目前的選擇；如果沒有出現網域規則，檢查應用程式是否直接使用 IP、DNS 是否由其他程式處理，以及連線是否重用了舊工作階段。修改後重新載入設定並建立新連線，避免用舊連線驗證新規則。

訂閱設定經常會在更新時重寫 rules。長期維護自訂規則時，優先使用客戶端的 prepend、append 或覆寫機制：需要優先命中的例外放在規則清單前端，一般補充則放在 MATCH 之前。每條自訂規則旁保留用途記錄，並定期刪除已失效項目。規則越多不代表效果越好，能夠說明每條規則的來源、優先順序與目標，才是可維護的分流設定。

TUN 模式透過虛擬網路介面接收 IP 流量，再將連線交給 Clash 規則引擎。它適合終端工具、遊戲、部分商店應用程式，以及自行管理網路連線的軟體。與系統代理相比，TUN 涵蓋範圍更廣，也更容易受到路由、DNS、防火牆、虛擬機器與其他 VPN 軟體影響。只有在系統代理無法涵蓋目標應用程式時才需要啟用，日常瀏覽不必把 TUN 當成固定前置條件。

啟用前的基本條件

Windows 通常需要客戶端輔助服務或管理員權限，才能建立虛擬網卡與修改路由；macOS 需要核准網路延伸功能；Linux 則需要 TUN 裝置權限，以及修改路由與防火牆規則的能力。客戶端提供「服務模式」時，應先確認服務安裝成功，再開啟 TUN。如果開關立即跳回、日誌提示 permission denied、operation not permitted 或無法建立 interface，問題位於權限與服務層，不應繼續更換代理節點。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

stack 指定 TUN 網路堆疊的實作，常見值包括 system、gvisor 與 mixed，實際支援範圍取決於核心與作業系統。system 更依賴作業系統網路堆疊，gvisor 在使用者態處理更多網路行為，mixed 則嘗試在相容性與效能之間分配協定。遇到特定 UDP、遊戲或區域網路連線異常時，可以將網路堆疊作為單獨變數測試，但每次變更後都應完全重新啟動核心並清除舊連線。

auto-route 讓核心自動寫入接管所需的路由；auto-detect-interface 用於識別目前的出口網卡，適合在有線與無線網路之間切換。多張網卡、虛擬機器、容器、撥號連線或其他 VPN 同時存在時，自動識別可能會選到錯誤介面。常見表現是 TUN 開啟後完全斷網、區域網路無法連線，或流量在兩個虛擬介面之間循環。此時先關閉其他網路接管軟體，再查看系統路由表與預設出口。

DNS 劫持與 fake-ip

dns-hijack 會將指定連接埠的 DNS 查詢交給核心處理，避免應用程式繞過 Clash DNS。fake-ip 模式會為網域回傳保留位址，核心再根據對映還原原始網域並執行規則，優點是網域規則命中更穩定；但依賴真實 IP 的區域網路裝置、部分遊戲、企業驗證與特殊協定，可能需要加入 fake-ip-filter。redir-host 則回傳真實解析結果，採用不同的相容路徑。切換增強模式會影響快取與既有連線，驗證前應重新整理系統與瀏覽器的 DNS 快取。

區域網路與保留位址

開啟 TUN 後，仍需確保私有網段、鏈路本地位址與本地域名能夠直連。家庭網路常見的 IPv4 網段包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16，IPv6 本地位址也應依實際環境處理。只有直連規則還不夠：如果 DNS 將 NAS 名稱送往外部解析器，仍可能無法取得正確位址。內部網域應交由區域網路 DNS 處理，或在 hosts、nameserver-policy 等位置明確指定解析路徑。

最小化排錯步驟

開啟 TUN 後斷網，第一步關閉 TUN，確認原本的網路恢復；第二步檢查日誌中的權限、介面與路由錯誤；第三步關閉其他 VPN 與虛擬網卡程式；第四步只保留 enable、stack、auto-route 與 auto-detect-interface 等必要欄位進行測試；第五步再加入 DNS 劫持與自訂路由。如果網頁正常但某個遊戲失敗，應重點比較 TCP、UDP、IPv4 與 IPv6 路徑，不要直接推翻整套設定。

TUN 的驗收應涵蓋瀏覽器、終端機、區域網路與系統復原四項：瀏覽器能依規則存取；未設定代理環境變數的終端機連線能出現在連線頁；路由器或 NAS 仍可存取；關閉 TUN 後系統預設路由與 DNS 能夠恢復。四項同時通過，才表示接管與退出路徑都完整。

穩定使用仰賴少量但持續的維護：保留可用設定、按需更新訂閱、留意客戶端與核心的更新說明、清理失效規則，並在系統網路變更後驗證代理設定。遇到故障時，重裝客戶端通常不是第一步，因為訂閱、系統代理、DNS、TUN 權限與規則錯誤在重裝後仍會原樣存在。更有效的方法，是依照應用程式層、接管層、核心層、策略層與遠端鏈路逐層確認。

建立可重複的健康檢查

每次更新客戶端或設定後，先確認核心是否啟動、設定是否載入、連接埠是否監聽，再用一個瀏覽器頁面與一個終端機請求進行驗證。連線頁應出現相應工作階段，規則欄位應符合預期，代理群組應指向實際選擇。最後測試一個區域網路位址，確保直連例外未受影響。這套檢查不必頻繁執行，但在大幅修改設定、系統升級或切換網路環境後很有價值。

# macOS / Linux：暫時為目前終端機設定代理
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# 測試完成後清除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# PowerShell：只影響目前視窗
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# 清除目前視窗中的設定
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

終端機環境變數與系統代理彼此獨立。瀏覽器能存取而命令列無法存取時，先檢查終端程式是否讀取系統代理，再查看 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY。反過來，關閉客戶端後終端機仍嘗試連線 127.0.0.1:7890，通常表示環境變數仍然存在。瀏覽器與終端機的分流檢查可參閱系統代理無法生效的兩條排查路線。

常見故障與定位入口

連接埠占用與殘留程序

日誌出現 address already in use，表示另一個程序已經監聽相同連接埠。可能是重複啟動的核心、另一款代理客戶端，或異常退出後殘留的程序。先在系統工作管理員或連接埠工具中確認占用者，再正常結束對應程式。直接將連接埠改成其他數字雖然能讓核心啟動，但瀏覽器、終端機與系統代理可能仍指向舊連接埠，最後形成「客戶端正常、流量不通」的新問題。若確實修改連接埠，應同步更新所有引用位置。

更新策略與回退

客戶端、核心、訂閱與規則集是四條不同的更新鏈。不要在同一時間全部更新。先儲存現有設定與客戶端設定，再更新其中一項並完成基本測試。核心更新後，重點查看設定欄位的相容性；訂閱更新後，重點查看代理群組名稱與規則變化；規則集更新後，重點查看命中結果；客戶端更新後，重點查看系統代理、服務模式與啟動項目。發生異常時，明確回退哪一層，比重新建立所有設定更可靠。

系統休眠、切換網路，或從公司網路回到家庭網路後，舊連線、預設網卡與 DNS 快取可能仍然存在。此時先重新啟動核心，再重新開啟目標應用程式；使用 TUN 自動識別出口時，確認目前的預設介面已經變更。如果只有一個網站異常，清除該網站的連線與 DNS 快取即可，不必重設整套系統網路。維護的目標是縮小變更範圍，並保留足夠資訊來說明每次變化。

完成前七章後，客戶端應具備穩定的基本路徑：應用程式流量能夠進入核心，訂閱可以更新，Rule 模式能依預期分流，TUN 只在需要時啟用，故障可以透過日誌與連線頁定位。進階階段不應繼續堆疊功能，而是將設定拆分成清晰、可驗證、可回退的模組。判斷一項設定是否成熟，不在於規則數量，而在於它能否在切換網路、更新訂閱與升級客戶端後持續運作。

第一階段：拆分設定責任

主要設定保留連接埠、模式、DNS、代理群組與規則入口；服務方訂閱負責節點與基礎群組；本機覆寫負責固定的自訂規則；大型規則放入 rule-provider；裝置相關設定則另外記錄。這樣更新訂閱時不會覆蓋本機策略，更換客戶端時也能快速判斷哪些部分可以遷移。設定檔命名可以包含用途與環境，例如 desktop-rule、laptop-tun、home-lan，而不是使用「新設定 2」這類無法長期辨識的名稱。

如果需要在多台裝置上維護同一套策略，不要直接同步包含節點憑證的完整檔案。可以同步不含敏感內容的規則片段、DNS 範本與說明文件，再由各台裝置分別匯入訂閱。這樣既能統一分流邏輯，也能避免裝置之間互相覆蓋連接埠、網卡與本機路徑等系統差異。

第二階段：依網域建立 DNS 策略

在複雜網路中，單一 nameserver 未必適合所有網域。核心支援時，可以透過 nameserver-policy 為內部網域、特定公共網域或不同規則集指定解析器。設計前先釐清問題：是內部網域只能由區域網路 DNS 解析，還是某些網域需要避免錯誤結果，或 IPv6 路徑不穩定。沒有明確目標時，不應同時堆疊多組解析器、fallback 與過濾條件。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.internal.example":
      - 10.0.0.53
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.home.arpa"

內部 DNS 位址必須在對應網路中確實可達。筆記型電腦離開家庭或公司網路後，這些位址可能逾時，因此要考量網路環境切換。如果客戶端支援依設定切換，可以為不同網路準備獨立的 DNS 覆寫；如果只維護一份設定，則應確保內部網域規則不會影響一般公共解析。調整 DNS 後，使用明確網域驗證解析結果與連線頁中的規則命中，不要只看網頁最後是否開啟。

第三階段：使用控制介面進行唯讀診斷

控制介面可以讀取目前的設定、代理群組與連線狀態。預設監聽在本機位址會更安全，也足以供桌面客戶端使用。透過命令列存取介面前，先確認 external-controller 的位址與連接埠；如果設定了 secret，請依照客戶端方式提供驗證。控制介面不應直接暴露在公共網路上。以下範例讀取本機控制連接埠，只用來確認介面是否回應。

curl http://127.0.0.1:9090/configs
curl http://127.0.0.1:9090/proxies
curl http://127.0.0.1:9090/connections

診斷時優先讀取而不是修改。/configs 可確認目前模式與部分執行參數，/proxies 可查看代理群組結構，/connections 可檢查活動連線。不同相容核心的介面欄位可能存在差異，自動化腳本應處理欄位缺失與介面不可用的情況，而不是假設所有客戶端都會回傳相同結構。

第四階段：為變更建立測試清單

每次變更規則或 DNS 後，至少測試四類目標：明確應直連的區域網路服務、明確應走代理的網域、由 MATCH 兜底的未知目標，以及需要特殊處理的應用程式。記錄目標、預期策略、實際規則與最終鏈路。測試清單比憑感覺瀏覽幾個網站，更能發現寬泛規則提前命中、DNS 策略遺漏與代理群組引用錯誤。

如果設定使用 TUN，還要加入退出測試：關閉 TUN 後預設路由恢復，系統 DNS 可用，瀏覽器不再依賴本機連接埠。如果使用開機啟動，則在重新啟動系統後檢查輔助服務、核心、設定與系統代理的啟動順序。啟動項目顯示已開啟，不代表每一層都已就緒；日誌中的時間順序可以說明設定載入是否早於網路建立，或系統代理是否指向尚未監聽的連接埠。

後續學習可以圍繞三個方向展開：需要更精細的分流時，深入研究 rule-provider、代理群組鏈與程序規則；需要涵蓋更多應用程式時，研究 TUN 路由、DNS 劫持與多網卡行為；需要長期維護時，建立設定版本記錄、變更說明與自動化語法檢查。不要同時推進三條路線，先選擇目前環境中最明確的問題。

從零開始到精通的終點，不是記住所有欄位，而是能解釋一條連線如何進入 Clash、為何命中某條規則、最後選擇哪個策略，以及失敗時應查看哪一層。需要重新走一次最短操作流程，可以返回入門指南；準備安裝或更換客戶端，可以前往下載中心。將快速操作與系統查閱分開，日常維護會更穩定。