Clash 新手到進階

一、了解 Clash 核心概念

用戶端、核心與伺服器的分工

Clash 通常泛指以代理核心為基礎的一系列用戶端與設定生態，並非某個固定介面。圖形化用戶端負責匯入設定、切換系統代理、選擇節點及顯示記錄；核心則負責監聽本機連接埠、讀取規則並建立連線。mihomo 是這個生態中常見的核心實作。介面能開啟，只代表用戶端已啟動，不能據此認定核心運作正常，更不代表遠端線路已可使用。

伺服器節點是實際提供轉送服務的遠端入口。用戶端安裝檔本身不會建立可用節點；訂閱也不是代理協定，而是傳送設定或節點資訊的方式。排查時應將三者分開確認：用戶端能否管理設定、核心能否接收連線，以及節點能否完成遠端交握。若把所有問題都歸因於軟體安裝失敗，往往只會反覆安裝，卻沒處理真正出錯的環節。

從一筆請求看完整連線流程

應用程式送出請求後，流量會先透過系統代理、應用程式本身的代理設定，或 TUN 進入核心。核心依據目標網域、位址及其他條件選擇規則，再將連線交給直連策略或代理群組。代理群組接著選定節點，由節點將請求送往目標服務，回應則沿原路返回。流量入口、規則判斷和出口節點屬於不同層次；啟用其中一項，不代表其他層次也已設定正確。

設定中的 proxies 用來描述節點，proxy-groups 用來組織選擇關係，rules 則決定連線交給哪個策略。規則引用的名稱必須能對應到節點、代理群組或內建策略。名稱看似相近不代表相同，大小寫、空格和標點都可能影響引用。閱讀不熟悉的設定時，先找入口連接埠、群組名稱和最後的預設規則，比從第一行開始逐項記住欄位更有效。

先分清節點、策略與解析結果

節點名稱中的地區通常只是服務提供者的標示，不能單憑名稱判定出口 IP 所在地；延遲測試通常只反映指定探測請求的結果，也不等於完整下載速度。代理群組是選擇節點的方式，不是另一台伺服器。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。Surfboard 的設定格式與 Clash YAML 不同，不能假設同一份訂閱能在所有用戶端直接使用。iOS 請優先查看 Clash Plus 的商店說明，官方網站為 clashplus.io。Linux 桌面可考慮 Clash Verge Rev 或 FlClash；沒有圖形介面的伺服器和路由器則較適合單獨部署 mihomo。

比較功能時確認實際使用的核心

確認協定支援時，應同時核對用戶端實際使用的核心和訂閱欄位。介面上顯示某種協定名稱，不代表目前的核心能解析服務提供者給出的所有參數。遇到匯入錯誤時，保留錯誤欄位和用戶端名稱，比只記下軟體圖示更有幫助。測試相容性時不要同時執行多個代理核心，它們可能會爭用連接埠、系統代理或虛擬網卡，反而讓原本正確的設定也無法運作。

系統架構會影響安裝檔能否正常執行。Apple Silicon 與 Intel 裝置應分別選擇對應版本，Windows 和 Linux 也需確認處理器架構。Android 的 ARM64 與 ARM 安裝檔不能任意互換；若不確定，先查看裝置資訊和下載頁說明。安裝失敗也可能是系統最低需求或安裝來源限制所致，不要一開始就修改代理設定，因為這些問題發生在網路轉送流程之前。

選定用戶端後，先讓其中一款完成基本連線，再評估是否遷移。遷移時應保留原設定檔、訂閱來源及必要的代理群組選擇紀錄，不能只複製介面上的節點名稱。需要並列比較各平台候選項目，請閱讀用戶端比較；遷移完成後，再停用舊用戶端的自動啟動與系統代理，避免下次重新啟動時兩個程式同時接管網路。

三、安裝用戶端並檢查連接埠

建立最基本的可執行環境

從下載中心取得符合作業系統與架構的安裝檔，依照系統提示完成安裝。首次啟動時先確認設定頁、核心狀態和記錄入口，不要立刻同時啟用系統代理、TUN、區域網路分享和複雜覆寫。此時最重要的是確認用戶端能啟動核心，並找到實際使用的設定檔位置。若需要網路擴充功能或服務權限，請看清系統提示後再授權，不要反覆關閉安全提示來嘗試啟動。

桌面用戶端可能將圖形介面與背景服務分開執行。關閉視窗不一定會停止核心，結束系統匣程式也不一定會移除背景服務。因此，安裝前後都要檢查是否已有其他代理程式在執行。若介面提示連接埠遭占用，先確認是哪個程序占用，再決定如何處理；不要隨意結束所有網路相關程序。行動裝置出現 VPN 授權提示時，請確認授權對象確實是剛安裝的用戶端，並留意系統通常只允許一個一般 VPN 工作階段使用該入口。

本機連接埠不等於節點連接埠

mixed-port 是本機應用程式連線至核心的入口，可同時接收 HTTP 和 SOCKS 代理請求。節點的伺服器連接埠則定義在訂閱的節點資料中，兩者用途不同。以下範例將本機入口限制在迴圈位址，適合只供目前裝置使用。數字僅供設定示範，並非所有用戶端的預設值；替應用程式填寫代理位址時，務必以用戶端目前顯示的監聽連接埠為準。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

瀏覽器和工具使用本機代理時，位址通常填 127.0.0.1，連接埠則填核心實際監聽的值。不要把遠端節點位址填在這裡。若確實需要讓同一區域網路中的其他裝置使用代理，應另外評估監聽位址、存取驗證和防火牆範圍；不能只開啟 allow-lan 就認為設定已完成。對外開放的代理入口可能被其他裝置使用，也會消耗線路流量。

從啟動記錄確認服務狀態

Windows 可在 PowerShell 執行 Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue，查看此範例連接埠的監聽與連線資訊；Linux 可使用 ss -lntp 檢查監聽程序。若查詢結果為空，還要確認核心是否已啟動，以及連接埠是否被用戶端改寫。即使查到監聽記錄，也要確認程序所屬；不能只因為該連接埠有監聽，就認定它一定屬於目前的用戶端。

若核心啟動後立即結束，請優先查看記錄中的第一個設定錯誤。之後出現的連線遭拒，往往只是啟動失敗的連帶結果。常見原因包括 YAML 縮排錯誤、欄位重複、無法讀取設定檔及群組名稱引用錯誤。修正一個問題後重新載入，再查看新的第一個錯誤，避免一次修改大量欄位。若是系統權限問題，請回到用戶端的服務管理入口處理，不要在訂閱檔中加入無關參數。

安裝完成後，應確認核心能持續執行、本機連接埠所屬程序明確、記錄沒有反覆重啟，而且原本的直連網路仍可使用。接著記下設定目錄位置和啟動方式，再於下一章匯入訂閱。若關閉用戶端後網路異常，先確認系統代理是否仍指向已停止的本機連接埠；恢復直連後再處理安裝問題，避免誤把殘留代理當成整個系統網路故障。

四、匯入訂閱與管理設定

先確認訂閱提供的內容

訂閱網址可能回傳完整的 Clash YAML，也可能只提供節點清單或其他格式。完整設定通常包含節點、代理群組和規則，匯入後會形成可選取的設定檔；節點清單則可能需要搭配主設定中的 provider 才能使用。Base64 只是一種編碼方式，不代表內容一定相容。匯入前先確認服務提供者支援的目標格式，不要只看連結能否在瀏覽器中開啟。

在用戶端的設定或訂閱頁面新增遠端設定，貼上完整網址並儲存，等待下載完成後選取這份設定作為目前使用的設定。只新增項目卻沒有啟用，是常見的遺漏。啟用後確認代理群組是否出現，展開群組內的節點並檢查是否全都為空。若用戶端提供下載時間和更新時間，請確認最近一次更新狀態；不要把按下重新整理就當成伺服器內容已成功替換。

訂閱網址可能包含存取憑證，應視同帳戶資訊妥善保管。分享截圖時請遮住完整網址，將記錄交給他人前，移除其中的查詢參數和驗證欄位。不要把私人訂閱貼到不熟悉的線上轉換網站；轉換服務可能會讀取網址和節點內容。需要轉換格式時，優先使用服務提供者明確支援的輸出方式，或在受控環境中轉換並檢查結果。

區分本機修改與遠端更新

遠端設定的來源檔通常會在下次更新時被取代，直接修改其中的規則不一定能保留。用戶端的覆寫、合併或擴充設定功能可用來保存本機差異，但各用戶端的合併順序不盡相同。使用前先確認是附加內容還是取代整個陣列，並查看最終生效的設定。編輯器中看得到某條規則，不代表它已出現在核心目前讀取的檔案裡。

以下是 mihomo 的遠端節點集合片段，僅適用於服務已提供相容 provider 內容的情況。範例網域只用來說明結構，不會提供實際節點；使用時必須替換成有效網址。對應的主設定也需定義引用該 provider 的代理群組。下載一般完整訂閱時，優先使用用戶端的遠端設定入口，不必為了匯入自行拆分成多個檔案。

proxy-providers:
  remote:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote.yaml
    interval: 3600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote

處理更新失敗與多設定切換

訂閱更新失敗時，先分辨是下載失敗還是解析失敗。下載失敗要檢查目前網路、訂閱是否有效，以及請求是否錯誤地依賴尚未運作的代理；解析失敗則要確認回傳內容是否為網頁、登入提示或不相容格式。不要把介面回傳的錯誤頁面存成 YAML 後繼續修改縮排。保留上一份可用設定，更新失敗時才有明確的復原方式。

多份設定應依用途命名，並記錄來源、適用的用戶端及本機擴充位置。切換後代理群組名稱可能改變，先前選取的節點不一定會保留；請重新確認目前模式和預設群組。自動更新間隔應配合服務提供者的要求，不必頻繁手動重新整理。格式差異請參閱訂閱 URL、YAML 與 Base64 說明；多設定的整理方式請參閱Profile 管理方法。

五、選擇代理模式並確認連線

模式決定處理策略，不決定流量入口

規則模式會依照設定中的規則逐條決定流量去向，適合日常分流；全域模式通常會將進入核心的代理流量交給全域選擇器；直連模式則讓進入核心的流量採用直連策略。這三種模式決定核心如何處理已收到的連線。如果應用程式根本沒有使用系統代理，也沒有由 TUN 接管，切換成規則或全域模式都不會自動讓流量進入核心；這是排查時最先要確認的界線。

系統代理是作業系統提供給應用程式的一組代理設定，不會強制接管所有網路連線。有些應用會遵循設定，有些使用自己的代理設定，另一些則直接連線。先用明確支援系統代理的瀏覽器測試，再逐步檢查其他應用。不要因為某款遊戲或命令列工具沒有走代理，就直接認定系統代理開關失效；它們可能根本不會讀取這項設定。

依序檢查入口、規則與出口

匯入設定後，先在主要代理群組中選取一個節點，再啟用系統代理並從瀏覽器送出新的請求。查看連線面板是否出現目標網域，並確認命中的規則和策略鏈是否符合預期。既有的長連線可能會沿用原本的路徑；切換節點後，請建立新連線再觀察。若記錄中完全沒有相應請求，先檢查應用程式入口和代理連接埠，不要急著修改遠端節點參數。

命令列可用以下方式明確指定本機 HTTP 代理。範例連接埠必須與實際設定相符，目標服務本身也必須可連線。收到 HTTP 回應只能證明這次請求透過指定入口完成；是否經過遠端節點，仍需查看規則和連線紀錄。若規則選到 DIRECT，即使用命令列指定本機代理入口，出口仍可能是目前網路的直連出口。

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

測試網站時，應分開確認連線狀態、出口位址與服務可用性。網頁能開啟不代表所有資源都走相同路徑；出口位址改變也不代表特定服務一定可用。服務提供者可能依帳戶、地區、裝置或業務政策限制存取。挑選節點時先確認線路能建立連線，再比較實際使用狀況；延遲與倍率的判讀方式請參閱Clash 節點挑選方法。

Windows UWP 迴圈例外與應用程式例外

部分 Windows 沙箱應用程式受網路隔離限制，可能無法存取本機迴圈代理。只有在確認應用程式使用系統代理、瀏覽器測試正常，但連線仍未進入核心後，才考慮設定 UWP 迴圈例外。若用戶端提供迴圈管理工具，請只授權特定應用程式，不要批次修改所有應用程式。迴圈例外只能解決本機入口的存取限制，無法修復訂閱失效、節點逾時或規則指向錯誤。

若應用程式有獨立代理設定，請檢查它是否與系統設定衝突。停止用戶端前先關閉系統代理，避免系統繼續連到已停止的連接埠。若全域模式能正常使用、規則模式卻失敗，請記錄兩種模式下的策略鏈，再到規則章節定位問題；若明確指定代理測試時所有節點都失敗，應先檢查節點和網路。首次確認連線也可參考連線檢查清單，不要只憑開關顏色下結論。

六、撰寫 Clash 自訂規則

由上往下比對，先符合者先決定

規則清單有先後順序，並非彼此無關的條件集合。核心通常由上往下檢查，符合條件後就套用對應策略；因此，範圍較小的例外應放在廣泛規則之前，預設規則則放在最後。若 MATCH 已經涵蓋所有剩餘連線，後面的普通規則就不會再有機會處理這些連線。調整分流時，先確認規則位置，再核對策略名稱；不能只看語法是否能通過解析。

DOMAIN 用於精確比對網域，DOMAIN-SUFFIX 用於比對網域後綴，IP-CIDR 用於比對 IP 網段，GEOIP 則依據地理位置資料判斷。網域規則需要核心取得相應的名稱資訊，位址規則則依賴目標位址及相關資料。單靠一條網域規則無法解決所有連線方式；尤其是應用程式直接連線至 IP、自行解析或重複使用連線時，更要透過連線面板查看實際目標。

先用小範圍例外確認規則順序

以下片段示範讓文件網域直連、程式碼代管網域交由 PROXY，再處理中國大陸 IP 和其他流量。實際設定中必須先定義 PROXY。網段規則中的 no-resolve 是為了避免單純進行這項位址比對時額外觸發網域解析，不代表關閉整份設定的 DNS。範例僅說明規則順序是否適用目前網路，仍應依實際用途逐條確認。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

新增規則後重新載入設定，再建立一筆新連線。查看命中的規則、目標網域及最後使用的代理群組，確認修改確實套用到執行中的設定。如果命中較前面的規則，請調整順序或縮小前置規則的條件；若記錄中一直只有 IP、沒有網域，則檢查應用程式的解析方式和 DNS 流程。若服務需要多個網域共同運作，不要只替首頁加一條規則，也要查看登入、API 和資源網域的連線。

規則集合與本機覆寫的界線

規則數量增加後，可透過 rule-providers 引用規則集合，再於 rules 中使用 RULE-SET。集合的類型必須符合內容，網域清單、位址清單和傳統規則不能任意混用。遠端集合更新失敗時，核心可能繼續使用現有快取；因此介面顯示某個集合存在，不代表它剛剛已成功下載。請同時檢查更新時間、記錄和實際連線命中結果。

訂閱規則與本機規則合併時，最重要的是最後的排列順序。有些覆寫會取代整個 rules 陣列，有些則只會在前後插入；把例外加在 MATCH 之後，通常不會生效。長期維護時，建議只保留明確的個人化規則，並記下新增原因。整份複製外部規則可能造成條件重複或分類過時，出錯時也很難判斷應該修改哪一層。

測試規則時，至少要包含一筆應直連和一筆應走代理的請求，避免修好一個網站卻影響其他服務。選擇 REJECT 前，請確認被拒絕的確實是目標連線，而不是登入流程所需的連線。分享設定前請移除私人網域和內部網路資訊。熟悉常用比對方式後，再嘗試進程規則等平台相關條件；不同系統對進程識別的支援和權限要求不一，不能把單一裝置的結果當成所有平台都適用。

七、設定 TUN 與 DNS

TUN 接管與系統代理的差異

TUN 透過虛擬網路介面和路由接收流量，可涵蓋部分不遵循系統代理的應用程式，但它不是用來加速節點的選項。啟用後，流量入口和 DNS 路徑都會改變，因此應先確認一般代理運作正常，再開啟 TUN。不同系統可能需要背景服務、管理員權限或網路擴充功能授權；行動裝置通常使用系統 VPN 介面。可用欄位取決於用戶端採用的核心及其提供的設定入口。

啟用用戶端的 TUN 開關前，先確認沒有其他 VPN 或 TUN 程式控制相同路由。記錄啟用前的本機網路、內部網域和主要服務是否正常，再逐項比較。企業 VPN、虛擬機網段和遠端管理連線可能與自動路由衝突。不要在唯一的遠端工作階段中直接切換路由接管方式；應先準備本機主控台或獨立復原管道，以免失去管理連線。

將 DNS 視為完整流程來處理

DNS 不只是設定伺服器位址，還牽涉由誰發出查詢、查詢透過哪條路徑送出、回覆如何交給應用程式，以及規則何時使用解析結果。fake-ip 模式會替網域指派用於對應的虛擬位址，再由核心連結至實際目標；它不是節點出口位址。部分內部服務或裝置探索機制需要實際位址，應依問題設定例外，而不是一次替所有網域停用對應功能。

以下是 mihomo 的學習範例，展示 TUN 接管與內建 DNS 的關聯。DNS 僅監聽本機迴圈位址；範例上游是否可連線仍取決於目前網路。合併設定時，務必保留既有節點、規則和用戶端必要選項。若介面已有 DNS 和 TUN 管理項目，優先透過介面調整並確認最後生效的設定，避免同一欄位遭兩處反覆覆寫。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

dns-hijack 中的連接埠設定適用於相應的傳統 DNS 請求，不代表能自動處理所有加密 DNS 連線。瀏覽器或應用程式若自行使用加密解析，可能改變可見的網域資訊和規則判斷條件。排查時應記錄相關設定，並暫時統一解析路徑後比較結果。若 DNS 上游必須透過代理才能連線，也要避免節點本身的解析又依賴同一條尚未建立的代理路徑。

依照症狀復原，不要同時修改多個層次

啟用 TUN 後所有應用程式都無法連線，請先關閉 TUN，確認原本的系統代理設定是否恢復，再檢查路由、權限和記錄。若只有網域無法存取、直接輸入位址卻能連線，應優先查看 DNS；若只有內部服務失敗，則檢查私有網段路由和內部 DNS；若只有特定應用異常，請觀察它使用的協定與連線路徑。一次只調整一個層次，才能確認是哪項修改讓連線恢復。

停止 TUN 後，請確認虛擬介面、路由和系統 DNS 都已恢復正常。不要因為網頁能開啟就忽略背景應用程式的舊連線，也不要長期疊加多種網路接管工具來「補漏洞」。完整驗收應涵蓋一般網頁、不使用系統代理的應用程式、內部網路存取，以及裝置休眠喚醒後重新連線。若只需要讓瀏覽器使用代理，保留較簡單的系統代理即可，沒有必要為了啟用進階選項增加維護負擔。

八、維護設定與排查異常

保留可復原的穩定基準

日常維護的重點是清楚掌握目前使用的設定，並能在修改失敗後復原。至少記錄用戶端名稱、核心來源、目前的 Profile、本機入口連接埠和覆寫位置。備份時請區分遠端來源設定與個人擴充，尤其要保留無法透過訂閱重新取得的規則。備份檔可能包含節點憑證和訂閱網址，請存放在安全的位置，不要上傳到公開程式碼儲存庫或任意交給他人排查。

用戶端更新、核心更新和訂閱更新是三種獨立變更。更新用戶端可能改變服務管理和合併邏輯；更新核心可能影響欄位支援；更新訂閱則可能更動節點、群組名稱和規則。發生異常時，先確認最近變更的是哪一層。不要在同一輪排查中同時升級用戶端、替換訂閱又重寫 DNS；否則即使網路恢復，也很難說明原因或重現穩定設定。

將無法上網拆解成具體症狀

完全沒有連線紀錄時，通常應先檢查應用程式是否進入本機入口，以及系統代理是否指向正確連接埠。已有紀錄但節點連線逾時，應著重檢查節點狀態、遠端位址是否可連線及目前網路限制。若出現名稱解析失敗，則檢查 DNS 請求和節點位址解析。收到明確的 HTTP 錯誤回應，代表連線可能已抵達某個服務，接著應分辨是代理驗證、目標服務拒絕，還是帳戶或業務政策限制。

切換網路或裝置休眠喚醒後，舊連線可能仍依賴已失效的介面。先建立新的請求，再考慮重新啟動核心，不必立刻刪除設定。若公共 Wi-Fi 需要網頁登入，請先完成網路登入驗證，再恢復代理；否則訂閱更新和節點探測可能同時失敗，看起來就像所有線路突然都不能使用。行動裝置也要檢查背景執行限制，確認系統是否在鎖定螢幕後停止用戶端程序或網路工作階段。

記錄要足以定位問題，也要控制範圍

平時可使用資訊層級的記錄；需要定位問題時，短暫提高詳細程度，重現一次後再調回。長期保留大量詳細記錄會增加磁碟寫入，也可能記下網域、路徑和連線中繼資料。回報問題時，附上操作步驟、作業系統、錯誤發生時間和相關幾行記錄即可；請移除訂閱、驗證資料和私人網路資訊。若只說「連不上」，卻沒有入口、策略和錯誤類型，通常難以提出可行的判斷。

節點探測成功但服務無法使用時，請用同一項服務進行比較，並確認它是否使用 UDP、多個網域或獨立 DNS 解析。探測位址和實際服務並非相同目標，結果不同並不矛盾。也不要長期用全域模式掩蓋規則問題；可以短暫比較連線路徑，但最後應恢復所需模式並修正相應條件，避免內部網路、更新服務和其他應用程式意外改走不同路徑。

每輪維護結束後，關閉不再需要的除錯功能，移除重複的自動啟動項目，並確認結束用戶端後系統能回到預期狀態。用簡短紀錄記下有效修改，例如調整了哪條規則、要解決什麼症狀，以及如何驗證。下次遇到類似問題時先查閱紀錄，不要重新複製整份陌生設定。穩定設定的價值不在欄位多，而在每項修改都有可觀察的原因和結果。

九、建立可驗證的進階學習路線

從單一裝置建立易維護的設定

完成前八章後，應依明確需求進一步學習。經常手動切換節點，可研究代理群組的選擇方式；規則需要重複維護，可研究規則集合；需要服務常駐執行，再學習命令列和服務管理。不要將外部設定中的每個欄位都照搬到自己的環境。某個選項適用於路由器，不代表同樣適合行動裝置；啟用前要先了解依賴條件、權限和復原方式。

代理群組中的 select 適合明確手動選擇；url-test 會依指定探測結果比較候選節點；fallback 則依可用狀態和排列順序選擇。自動選擇不保證實際服務品質，探測請求成功也不代表所有目標服務都能使用。設定時應明確指定探測網址、檢查間隔和候選範圍，不要為了查看排名而頻繁探測。若需要穩定使用特定地區的服務，手動固定合適線路可能比頻繁自動切換更符合需求。

命令列部署先驗證，再設為常駐服務

Linux 無圖形介面的環境，應先在前景驗證設定，確認記錄和檔案路徑後，再交由 systemd 等服務管理工具執行。程式的工作目錄不可與設定目錄混淆，規則集合的相對路徑也必須有固定位置。以下命令假設 mihomo 已位於可執行路徑，且目前目錄已有完整設定檔。語法測試通過只代表設定可以讀取，不保證節點、DNS 和目標服務都能連線。

mihomo -t -d ./mihomo-data -f ./config.yaml
mihomo -d ./mihomo-data -f ./config.yaml

確認前景執行正常後，再依系統規範設定服務使用者、工作目錄、設定路徑和重啟策略。預設情況下不要讓所有工作都以高權限帳戶執行；若 TUN 確實需要特定網路能力，請依部署環境授予必要權限。查看服務記錄時，要分辨是程序結束還是網路請求失敗；設定錯誤造成的無限重啟不會自行修復。桌面與命令列部署方式的差異，請參考在 Linux 上部署 Clash 的兩種方式。

分別評估管理介面與網路分享

外部控制介面是管理入口，不是一般代理入口。需要控制面板時，應優先限制在本機或受控網路，並設定適當的驗證方式；不要直接暴露在公開網路上。開放區域網路代理也應設置獨立的存取範圍和防火牆規則。管理介面、訂閱憑證和代理驗證保護的是不同項目，設定其中一種不會自動保護其他項目；部署時應分別檢查實際監聽位址。

在路由器或閘道器部署會影響其他裝置，風險範圍遠大於單一電腦。先準備測試裝置和旁路復原方案，確認網段、DHCP、DNS 與出口路由之間的關係，再逐步擴大接管範圍。IPv4 正常不代表 IPv6 路徑也相同；UDP 正常也不能只靠一次網頁測試推斷。每次擴大範圍後，都應測試直連服務、代理服務和內部網路服務，不能只確認一個外部網站。

最後，依照目前環境建立驗收清單：核心啟動、訂閱更新、直連規則、代理規則、DNS、網路切換和退出後復原。每次修改只變更一個主要條件，並保留修改前後的記錄與設定差異。若測試失敗，先恢復已知可用的狀態，再整理原因。想重新依最短流程建立連線，請回到使用指南；需要更換用戶端，先查看下載中心，不要把更換軟體當成解決所有網路問題的方法。