Clash Meta 全平台安裝與設定指南

CHAPTER 01 / PREPARATION

通用準備：客戶端、訂閱與權限界線

先分清客戶端、核心與訂閱

Clash Meta 的實際運作流程由三個部分組成。mihomo 負責協定連線、規則比對、DNS 處理與流量轉送，是核心；Clash Plus、Clash Verge Rev、FlClash 等則是管理核心的圖形客戶端；訂閱是服務提供方產生的遠端設定，通常包含代理節點、策略群組與基本規則。安裝客戶端不代表已經擁有可用線路，訂閱連結也不是安裝套件；兩者需分別取得，再於客戶端內完成組合。

選擇客戶端時，先確認作業系統與處理器架構。Windows 常見裝置使用 x64 安裝套件；採用 ARM 處理器的裝置則需確認應用程式是否提供相應版本。macOS 需區分 Intel 與 Apple Silicon。Android 安裝套件可能依 arm64、arm 或通用架構區分，新款裝置通常使用 arm64；無法確認時，請從下載頁選擇客戶端提供的通用版本。Linux 另需確認發行版套件格式、CPU 架構以及是否具備桌面環境。

圖形客戶端適合日常桌面與行動裝置使用。直接使用 mihomo 核心則較適合伺服器、路由器、容器，或需要自行撰寫服務管理腳本的環境。兩種方式讀取的核心設定語意相近，但圖形客戶端可能將系統代理、TUN、設定覆寫與訂閱更新包裝成獨立開關。排查時應先確認問題發生在介面層、核心層，還是上游訂閱，避免反覆重新安裝卻沒有觸及真正原因。

匯入前檢查訂閱回應內容

訂閱連結應從服務提供方的管理頁面複製，不要手動截取聊天視窗中被換行的網址。連結通常含有存取憑證，應視為機密資料保存，不要放入公開截圖、程式碼儲存庫或共用文件。匯入失敗時，可先在系統瀏覽器直接開啟連結：若回傳 YAML 文字或觸發設定檔下載，表示網址至少可以連線；若顯示登入頁、過期提示、拒絕存取或空白回應，應先處理訂閱端問題。

同一項服務可能同時提供 Clash YAML、通用分享連結與其他客戶端格式。mihomo 客戶端通常需要 Clash 或 mihomo 相容設定。格式選錯時，客戶端可能回報解析失敗，也可能匯入後只有節點而沒有策略群組。更換格式前不要刪除仍可使用的舊設定，先為新設定使用不同名稱，確認代理群組、規則與 DNS 區段完整後，再決定是否替換。

建立可回復的設定基準

第一次啟動後，先維持預設連接埠與預設工作模式，只匯入一份設定，選定一個代理節點，再測試瀏覽器連線。這個順序有助於建立基準：預設狀態可用，後續故障才可能是由 TUN、覆寫規則、DNS 或同時啟用多份設定造成。第一次測試不要同時開啟系統代理、TUN、區域網路分享與自訂 DNS，否則出現異常後很難判斷是哪一層改變了流量路徑。

系統代理與 TUN 並不是同一個入口。系統代理通常只影響遵循作業系統代理設定的應用程式，常見形式為 HTTP 或 SOCKS 連接埠；TUN 則會建立虛擬網路介面，接管更多不讀取系統代理的程式。行動作業系統中的 VPN 開關通常負責與 TUN 類似的接管工作。兩者適用於不同情境，但日常桌面瀏覽通常先使用系統代理；遊戲、命令列工具或行為不一致的應用程式，再考慮使用 TUN。

CHAPTER 02 / WINDOWS

Windows：安裝、系統代理與 TUN 接管

安裝與首次啟動

Windows 使用者可在Windows 下載區選擇 Clash Plus，或依介面習慣使用 Clash Verge Rev、FlClash、Clash Nyanpasu。Clash for Windows 已停止維護，僅作為封存選項。下載前先在「設定 → 系統 → 系統資訊」查看系統類型，一般 Intel 與 AMD 電腦通常選擇 x64 版本。安裝套件與免安裝版本的資料目錄位置可能不同；需要長期保留設定時，安裝後不要任意移動免安裝目錄。

首次啟動若出現 Windows 安全性中心或防火牆詢問，請依使用範圍授權。只在本機使用時，不必為代理功能開放公用網路存取；需要區域網路裝置連線至本機連接埠時，才考慮允許相應的私人網路存取。關閉客戶端視窗後是否繼續常駐系統匣取決於設定；判斷是否仍在執行時，應查看工作列系統匣圖示或工作管理員，而不是只看視窗是否消失。

若安裝程式無法寫入目錄，先確認下載檔案已完整儲存至本機，再嘗試在使用者具備寫入權限的位置執行。系統管理員權限主要用於安裝驅動程式、註冊服務或建立 TUN 介面，不應把「一律以系統管理員身分執行」當成所有故障的預設處理方式。一般系統代理模式通常不需要持續使用系統管理員權限，權限過高反而可能改變程式與瀏覽器之間的執行界線。

匯入訂閱並確認設定生效

在客戶端的設定、訂閱或 Profiles 頁面找到「從 URL 匯入」入口，貼上訂閱網址並為設定取一個容易辨識的名稱。匯入完成後，還需要明確選取該設定；設定出現在清單中不代表已經載入。接著進入代理或 Proxies 頁面，確認至少存在一個策略群組，並在最終出口策略群組中選擇節點。若頁面只有節點清單、沒有常見的選擇群組，可能是訂閱格式不完整，或客戶端沒有載入正確設定。

完成選擇後，先開啟系統代理。Windows 的系統代理設定應顯示指向本機回送位址的代理伺服器，連接埠需與客戶端目前的監聽值一致。不要手動將訂閱伺服器網址填入 Windows 系統代理；系統代理目標應是本機客戶端，再由客戶端依設定連線至遠端。測試時請開啟新的瀏覽器視窗，避免舊連線重複使用先前路徑。若關閉客戶端後網頁也無法存取，請檢查系統代理是否被異常保留。

常見連接埠欄位包括 port、socks-port 與 mixed-port。圖形客戶端通常使用 mixed 連接埠，同時接收 HTTP 與 SOCKS 請求。連接埠被其他程式佔用時，記錄會出現監聽失敗，客戶端可能仍顯示已啟動，卻無法處理連線。此時先退出同類代理程式，再改用未被佔用的本機連接埠，並同步檢查系統代理目標是否自動更新。

何時開啟 TUN

部分遊戲平台、命令列程式、商店應用程式或自帶網路堆疊的軟體不會讀取 Windows 系統代理。確認瀏覽器可用，但特定程式始終直接連線時，可以啟用 TUN。首次開啟通常需要安裝虛擬網卡或服務，應接受客戶端明確提出的系統權限要求。啟用後檢查客戶端記錄是否成功建立介面，以及系統路由表是否出現對應路由，不要只看介面開關的顏色。

TUN 可能與其他 VPN、虛擬機網卡、網路加速器及企業安全軟體同時修改路由。測試階段只保留一個接管工具，確認基本連線後再逐一恢復。若開啟 TUN 後區域網路分享、印表機或公司內網失效，請檢查規則是否讓私人位址保持直連，並確認繞過清單包含實際使用的內網網段。關閉 TUN 後需等待介面與舊連線釋放，再重新測試。

netsh winhttp show proxy
ipconfig /flushdns
netstat -ano | findstr LISTENING

CHAPTER 03 / MACOS

macOS：架構選擇、網路服務與系統擴充功能

選擇 Apple Silicon 或 Intel 版本

macOS 下載前先開啟「關於本機」查看晶片資訊。顯示 Apple 晶片時選擇 Apple Silicon 或 arm64 版本；顯示 Intel 處理器時選擇 x64 版本。可在macOS 下載區優先選擇 Clash Plus，也可使用 Clash Verge Rev、FlClash；ClashX Meta 已停止維護，適合已有設定、需要暫時延續使用的環境。架構選錯時，應用程式可能無法啟動，或需透過轉譯執行並產生額外行為差異。

下載後將應用程式移至「應用程式」目錄，再從該目錄啟動。直接在下載映像檔或暫存目錄中執行，可能導致更新、資料目錄與權限狀態不穩定。系統首次開啟來自網路的應用程式時會顯示安全性確認，請核對檔案來源為本站下載入口所指向的對應客戶端。若系統阻止開啟，可在「系統設定 → 隱私權與安全性」查看該次阻止紀錄，並依系統提供的明確入口確認。

客戶端的資料目錄通常位於使用者資料庫範圍內，解除安裝應用程式本體不一定會同時刪除訂閱與設定。準備更換客戶端時，先記錄訂閱來源、目前策略與自訂覆寫，再退出舊客戶端。不要讓兩個客戶端同時設定系統代理，因為後啟動的程式可能覆蓋代理連接埠，退出時又恢復到另一組已失效的值。

系統代理與網路服務

macOS 的系統代理會依網路服務儲存，Wi-Fi、有線網路與其他介面可能分別維護設定。客戶端開啟系統代理後，通常會為目前服務設定網頁代理、安全網頁代理與 SOCKS 代理。從 Wi-Fi 切換至有線連線後若狀態異常，請檢查新的網路服務是否也已由客戶端接管。企業網路的自動代理設定檔也可能與手動代理同時存在，需先確認哪一種設定應該生效。

驗證代理狀態可以在系統網路詳細資訊中查看，也可以使用命令讀取目前設定。代理伺服器應為 127.0.0.1 或本機回送位址，連接埠需與客戶端一致。若客戶端退出後網路中斷，請重新開啟客戶端並關閉系統代理，或在系統設定中清除殘留選項。只刪除應用程式而不恢復系統代理，會讓瀏覽器繼續將請求傳送至已沒有程式監聽的本機連接埠。

scutil --proxy
networksetup -listallnetworkservices
lsof -nP -iTCP -sTCP:LISTEN

終端機中的 curl、套件管理器與開發工具不一定完全遵循圖形介面的系統代理。需要臨時測試時，可以只在目前終端機工作階段設定代理環境變數，測試完成後再清除。連接埠應替換為客戶端實際使用的 mixed 連接埠，不要把範例值視為固定要求。

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

curl -I https://example.com

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

TUN、系統擴充功能與本機網路

需要接管不讀取系統代理的應用程式時，可在客戶端中啟用 TUN。macOS 可能要求輸入系統管理員憑證、允許網路擴充功能或新增 VPN 設定。權限只需依照系統彈窗列出的項目逐一確認；若先前拒絕過，可在隱私權與安全性、網路擴充功能或 VPN 設定中重新檢查。開關已開啟但介面建立失敗時，記錄通常會留下權限、服務或路由錯誤。

在 macOS 上同時執行企業 VPN、容器網路與虛擬機軟體時，多個虛擬介面會爭用預設路由或 DNS。先關閉其他網路接管工具，確認 Clash 單獨執行時的結果，再恢復必要軟體。如果公司內網依賴指定 DNS 或搜尋網域，TUN 的 DNS 接管可能改變解析路徑；應將內網網域與網段加入直連規則，並讓對應查詢使用能解析內部名稱的伺服器。

區域網路存取異常時，不要直接把所有私人位址都交給代理。家庭路由器、印表機、檔案分享與開發裝置通常應保持直連。設定中的 allow-lan 控制其他裝置能否連線至本機代理連接埠，並不決定本機是否能存取區域網路；區域網路是否直連主要由規則與路由共同決定。只有在明確需要分享代理時才開啟區域網路監聽，並搭配系統防火牆限制網路範圍。

CHAPTER 04 / ANDROID

Android：應用程式安裝、VPN 接管與背景執行

安裝與匯入訂閱

Android 可在Android 下載區優先選擇 Clash Plus，也可使用 Clash Meta for Android、FlClash 或 Surfboard。下載套件依架構區分時，近期主流裝置通常使用 arm64；較舊裝置可能需要 arm 版本。無法確認架構時，優先選擇客戶端提供的通用套件。若系統要求允許瀏覽器或檔案管理器安裝應用程式，只對本次使用的來源開啟權限；安裝完成後可視需要關閉。

首次啟動後，在設定頁面選擇從 URL 匯入，貼上訂閱連結並等待解析。行動網路可能讓首次請求出現短暫切換，因此匯入失敗時，應分別在 Wi-Fi 與行動數據下測試。設定下載成功後，還需要將它設為作用中的設定，再進入代理群組選擇節點。只看到設定名稱不代表 VPN 已連線；狀態列出現 VPN 圖示，且客戶端記錄開始處理連線後，流量接管才算真正建立。

透過 QR Code 匯入時，應確認 QR Code 內容確實是訂閱網址，而不是單一節點分享連結。單一節點連結可能被客戶端識別，但通常不包含完整規則與策略群組。掃描需要相機權限，從相簿識別則需要圖片存取權限；若不希望提供這些權限，直接複製 URL 會是更清楚的方式。匯入後可刪除包含訂閱 QR Code 的暫存截圖，避免長期留在相簿同步資料中。

Android VPN 與應用程式分流

Android 客戶端通常透過系統 VPN 介面接管流量。首次連線時，系統會顯示 VPN 授權視窗；確認後客戶端才能建立介面。系統通常同一時間只允許一個一般 VPN 生效，因此其他 VPN、過濾工具或使用本機 VPN 介面的防火牆會被中斷。若連線按鈕反覆回到停止狀態，應先檢查是否有其他應用程式持續爭用 VPN 權限。

部分客戶端提供依應用程式代理或繞過清單。規則模式處理的是網域、IP 與規則集如何選擇出口；依應用程式分流處理的是哪些應用程式進入 VPN，兩者位於不同層級。某個應用程式被設為繞過後，其連線不會進入 mihomo，後續網域規則也無法處理它。排查單一應用程式無法使用時，先檢查應用程式分流名單，再查看規則命中結果，最後確認所選節點是否支援該應用程式所需的協定與網路環境。

區域網路裝置探索、投放與列印依賴多播或本機網段，VPN 接管後可能受到系統限制。可先確認私人位址使用 DIRECT，並在客戶端支援時允許區域網路存取。即使規則正確，部分應用程式仍會根據 Android VPN 狀態改變探索行為；此時可暫時中斷 VPN 進行對照測試，以區分是規則錯誤，還是應用程式本身對虛擬網路的限制。

背景執行、省電與網路切換

Android 裝置製造商的省電策略可能在螢幕關閉後停止客戶端背景程序。常見情況是剛連線時可用，鎖定螢幕一段時間後 VPN 圖示消失，或網路恢復直接連線。應在系統應用程式設定中允許背景活動，將電池策略調整為不受限制或同等選項，並依系統功能鎖定最近使用的任務。設定名稱會因系統介面而異，判斷標準是應用程式在螢幕關閉與網路切換後仍能維持 VPN 服務。

從 Wi-Fi 切換至行動數據時，既有 TCP 連線無法沿用原本的網路路徑，短暫中斷屬於正常重建過程。若長時間未恢復，可以在客戶端內重新連線，不必反覆切換飛航模式。啟用「一律開啟 VPN」時，系統可能同時啟用阻止未經 VPN 的連線；一旦客戶端未能成功啟動，所有網路都會被阻斷。啟用這類系統策略前，應確認客戶端重新啟動後能穩定自動啟動。

DNS 異常在行動裝置上常表現為部分應用程式可以存取 IP，但網域解析失敗，或同一網站在 Wi-Fi 與行動數據下結果不同。先關閉私人 DNS、瀏覽器安全 DNS 等額外變數進行對照，再檢查客戶端的 DNS 模式。確認衝突來源後，再決定保留哪一層；不應長期同時疊加系統私人 DNS、應用程式內 DNS 與多個過濾工具，讓每一層都嘗試改寫查詢。

CHAPTER 05 / IOS

iOS：Clash Plus、VPN 設定與隨選連線

安裝與設定入口

iPhone 與 iPad 可從iOS 下載區進入 Clash Plus 的 App Store 頁面；客戶端相關資訊也可查看官網 clashplus.io。安裝完成後，先在系統設定中確認裝置日期、網路與 App Store 登入狀態正常。iOS 的網路接管由系統 VPN 架構管理，客戶端無法繞過系統授權直接修改其他應用程式的連線。

開啟 Clash Plus 後，從設定頁面選擇匯入訂閱，貼上服務提供方提供的 Clash 相容連結。若連結透過剪貼簿傳入，系統可能顯示允許貼上的提示；拒絕後可重新進入輸入框並主動貼上。匯入完成後檢查策略群組與節點是否出現，再將該設定設為目前設定。訂閱清單中的更新時間只代表最近一次請求結果，不代表節點連線能力已完成驗證。

首次啟動連線時，iOS 會要求新增 VPN 設定，並使用裝置解鎖密碼或生物辨識確認。此步驟由系統完成，成功後可在狀態列或控制中心查看 VPN 狀態。若系統設定中已有其他 VPN，啟動 Clash Plus 時通常會切換目前設定。企業管理裝置也可能受到管理策略限制而無法新增 VPN；這類限制需由裝置管理方處理，反覆安裝應用程式不會改變系統策略。

規則模式、策略群組與隨選連線

日常使用建議先維持規則模式。規則模式會依設定中的網域、IP、規則集與最終 MATCH 規則，決定 DIRECT 或代理策略；全域模式則把連線集中交給一個代理群組，適合暫時驗證節點，不適合作為永久繞過所有問題的方法。若規則模式下某個網站異常，而全域模式正常，應查看該連線在記錄中的命中規則，不要直接認定節點失效。

策略群組可能包括自動選擇、故障轉移、手動選擇與直連。自動選擇的結果取決於訂閱定義的測試網址與間隔，不代表任何時候都適合所有服務。對穩定性要求較高時，可以在手動群組中固定一個節點，排除自動切換變數；確認連線穩定後，再恢復自動策略。切換節點只會影響新建立的連線，既有工作階段可能繼續使用舊路徑；測試時應完全關閉並重新開啟目標應用程式。

隨選連線可以在特定網路條件下自動啟用 VPN，但規則設定過寬，會導致回家、進入公司或切換行動網路時頻繁重新連線。首次設定階段先使用手動連線，確認訂閱與規則穩定後，再依可信任 Wi-Fi、行動網路等條件建立隨選策略。設定後應實際測試鎖定螢幕、解鎖、飛航模式恢復與網路切換，不要只根據開關狀態判斷。

iOS 的 DNS 與區域網路權限

iOS 會限制應用程式存取本機網路。若需要存取 NAS、投放裝置或區域網路控制頁面，應在系統隱私權設定中允許客戶端或相關應用程式使用本機網路，並確保設定將私人位址設為直連。客戶端本身擁有權限，不會自動授予其他應用程式權限；實際存取仍取決於目標應用程式與系統網路策略。

使用 fake-ip 模式時，DNS 回傳的位址會由核心映射至網域，再依規則處理。多數一般網頁適合此模式，但依賴區域網路探索、特殊網域解析或直接驗證 IP 的應用程式，可能需要加入 fake-ip 過濾清單。修改過濾項目後應重新載入設定並建立新連線，因為舊 DNS 快取不會隨設定文字立即消失。問題只在某個 Wi-Fi 出現時，也應檢查該網路是否需要入口網站驗證。

連線顯示正常但網頁無法開啟時，先在 Safari 開啟一般 HTTP 頁面，確認是否存在飯店、機場或校園網路的驗證頁面。完成驗證前，VPN 可能無法建立有效的外部連線。完成驗證後重新啟動連線，再查看記錄是否出現 DNS 逾時、路由失敗或節點握手錯誤。若行動網路正常而指定 Wi-Fi 異常，應優先處理該網路的驗證、DNS 與 IPv6 條件，而不是立即更換訂閱。

CHAPTER 06 / LINUX

Linux：桌面客戶端、mihomo 服務與環境變數

桌面客戶端與軟體套件選擇

具備桌面環境的 Linux 使用者可在Linux 下載區選擇 Clash Verge Rev 或 FlClash。下載前使用 uname -m 確認架構：常見桌上型電腦多為 x86_64，ARM 裝置可能顯示 aarch64。同時確認發行版使用的套件格式；Debian、Ubuntu 系統通常使用 deb，其他發行版應選擇明確支援的格式，或採用適合本機的安裝方式。

圖形客戶端啟動後，訂閱匯入、策略群組選擇與系統代理邏輯和其他桌面平台相近。差異主要在桌面環境：GNOME、KDE 與精簡視窗管理器對系統代理的實作並不一致，部分命令列程式也會完全忽略桌面代理。先在客戶端內確認 mixed 連接埠正在監聽，再分別測試瀏覽器、終端機與需要代理的應用程式，不要把單一瀏覽器的結果當成整個系統的結果。

安裝軟體套件後若應用程式無法啟動，可從終端機執行程式，以讀取缺少相依套件、權限或圖形工作階段相關錯誤。Wayland 與 X11 下的系統匣圖示、視窗縮放及自動啟動行為可能不同，但這些介面問題不一定會影響核心執行。可以透過監聽連接埠、程序清單與記錄判斷代理服務是否正常，再另外處理桌面整合。

直接執行 mihomo 核心

伺服器、路由器或無桌面環境通常會直接執行 mihomo。下載頁的核心區提供不同架構版本，必須依 uname -m 結果選擇。設定檔應存放在權限受控的目錄，因為其中可能包含展開訂閱後的驗證資訊。首次執行時先以前景模式載入設定，觀察語法檢查、連接埠監聽與規則載入是否成功，再撰寫 systemd 服務，避免服務反覆重新啟動卻看不到最初錯誤。

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

ss -lntp
journalctl --user -u mihomo --no-pager -n 100

使用 systemd 使用者服務時，工作目錄、可執行檔路徑與設定目錄都應使用絕對路徑。服務帳戶必須具備讀取設定與寫入快取目錄的權限。若需要繫結低位連接埠、修改路由或建立 TUN，應採用系統服務並明確授予必要能力；不要為了省略權限設定，就讓無關目錄長期對所有使用者開放寫入。

[Unit]
Description=mihomo proxy core
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

終端機代理、TUN 與防火牆

命令列工具最清楚的接入方式，是為目前工作階段設定環境變數。HTTP 工具通常讀取 http_proxy 與 https_proxy；需要 SOCKS 時，可依工具能力使用 all_proxy。環境變數是否區分大小寫由具體程式決定，腳本中最好明確設定需要的形式。不要把代理變數永久寫入所有系統服務的全域環境，否則軟體更新、內網存取與本機管理工作也可能被意外轉送。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890

curl -I https://example.com
env | grep -i proxy

Linux TUN 需要核心 TUN 裝置、路由權限與防火牆規則互相配合。容器環境可能還需要開放 /dev/net/tun 與網路管理能力。開啟前先記錄目前的預設路由、策略路由與 DNS 設定，發生問題時才能回復。使用 nftables、iptables、firewalld 或發行版網路管理器時，應避免多套工具同時維護同一批轉送規則。

伺服器開啟 allow-lan 或監聽所有位址，會把代理連接埠暴露在網路介面上。只有明確需要其他裝置接入時才這樣設定，並使用主機防火牆限制來源位址。作為本機代理使用時，監聽 127.0.0.1 即可。檢查連接埠時也要查看監聽位址：連接埠存在不代表存取範圍正確；監聽回送位址與監聽所有介面具有完全不同的界線。

當 DNS 由 systemd-resolved、NetworkManager、容器執行環境或手動 resolv.conf 管理時，TUN 的接管結果可能互相覆蓋。先確認 resolvectl status 顯示的每個介面 DNS，再判斷查詢是否進入 mihomo。若只有容器內解析失敗，應分別檢查主機、容器 DNS 與轉送規則，不能只修改主機瀏覽器的代理設定。

CHAPTER 07 / CONFIGURATION

通用設定：連接埠、DNS、規則與訂閱更新

最小可讀設定與監聽界線

圖形客戶端通常會從訂閱產生設定，不要求使用者從零撰寫 YAML，但理解關鍵欄位有助於判斷介面開關實際改變了什麼。以下範例展示本機 mixed 連接埠、規則模式、記錄層級、控制介面與 DNS 的基本關係。這不是完整訂閱，缺少 proxies 與 proxy-groups 時不會憑空產生可用線路；實際使用應由訂閱提供節點，並在保留結構的前提下進行覆寫。

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

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port 同時接收 HTTP 與 SOCKS 連線，方便桌面系統代理與命令列工具共用一個入口。allow-lan: false 搭配回送位址繫結，表示只允許本機存取。若需要讓同一區域網路的手機或其他裝置使用此連接埠，必須同時調整監聽位址、防火牆與存取規則；只修改一個開關可能仍然無法連線，也可能意外擴大暴露範圍。

external-controller 是管理介面，不是一般代理連接埠。圖形客戶端可能透過它讀取連線狀態與切換策略。直接暴露在區域網路時，應設定驗證並限制存取來源；本機客戶端則應維持回送位址監聽。發生連接埠衝突時，不要任意刪除控制介面，否則介面可能失去與核心的通訊；應先判斷衝突的是 mixed、DNS 還是 controller 連接埠。

DNS 模式與 fake-ip 過濾

DNS 決定網域如何解析，也是網域規則辨識的基礎。fake-ip 模式會先回傳保留位址，再由核心將連線映射回原始網域，因此即使應用程式只發起 IP 連線，也能保留網域規則資訊。redir-host 更接近傳統解析流程，對少數特殊程式的相容性較直接，但網域映射與快取行為不同。模式選擇應根據應用程式表現判斷，不宜只以「速度」為理由切換。

區域網路網域、連線檢測網域、時間同步，以及部分對回傳位址有特殊要求的應用程式，可能需要加入 fake-ip-filter。過濾表示這些網域會取得真實解析結果，不代表它們會自動直連；最終出口仍由 rules 決定。修改後應清除系統 DNS 快取、重新載入設定並重建連線。只重新整理網頁可能仍會使用瀏覽器內部快取，造成設定看似沒有生效。

同時使用系統加密 DNS、瀏覽器獨立 DNS 與客戶端 DNS 時，一次查詢可能繞過預期入口。排查階段應暫時關閉額外層，只保留 mihomo DNS，觀察記錄能否看見網域與規則命中。確認基本流程後，再逐一恢復需要的安全 DNS 設定。關於洩漏檢查與設定驗證，可繼續閱讀Clash DNS 洩漏檢測與防洩漏設定實作。

規則順序與策略群組

規則會依由上而下的順序比對，第一條命中後便不再繼續。具體網域、程序或規則集通常放在前面，範圍較大的 GEOIP、GEOSET 與最終 MATCH 則放在後方。如果把 MATCH 放在前面，後續規則永遠不會執行。修改規則後，應在連線記錄中檢查「請求網域—命中規則—目標策略」三者，而不是只觀察最終網頁能否開啟。

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

RULE-SET 用於引用獨立規則集合，方便更新與重複使用。規則提供者下載失敗時，現有快取可能仍能運作，但新安裝或清除快取後問題就會暴露。應檢查 provider 位址是否可達、behavior 類型與規則內容是否一致，以及策略名稱是否確實存在。規則命中不存在的策略群組時，設定通常會在載入階段報錯。

策略群組名稱由訂閱決定，範例中的 PROXY 並非所有設定都固定存在。進行覆寫時必須使用目前設定中的實際群組名稱。全域模式會略過大部分規則判斷，將流量交給指定的全域群組；直連模式則略過代理出口。三種模式的差異可參考規則、全域、直連三種模式說明。

訂閱更新與覆寫的關係

訂閱更新通常會重新下載並取代遠端設定。如果直接編輯訂閱產生的 YAML，下次更新可能會覆蓋修改。支援覆寫、腳本或 Mixin 的客戶端，應將本機連接埠、DNS 與附加規則放入專用覆寫層；不支援時，應保留修改記錄，並在更新後重新核對。不要為了保護單一修改而永久關閉更新，這也會同時失去節點、策略與規則的正常變更。

自動更新間隔不宜短到頻繁發出請求，也不應長到無法及時取得服務方調整。遇到更新失敗時，應區分 HTTP 請求失敗、回應內容變化、解析錯誤與代理迴圈。若客戶端使用目前代理請求訂閱，而訂閱網域又因錯誤規則被送往無法使用的節點，就可能形成更新迴圈。詳細步驟請見訂閱更新失敗排查與自動更新設定。

CHAPTER 08 / TROUBLESHOOTING

常見設定問題：依流量路徑逐層定位

客戶端已啟動但沒有網路

排查順序應沿著真實流量路徑進行：目標應用程式是否將請求交給本機代理、本機連接埠是否正在監聽、核心是否載入目前設定、規則是否將連線交給預期策略、節點是否能建立遠端連線，以及 DNS 是否回傳可用結果。只看到客戶端主介面顯示「執行中」，只能證明程序存在，不能證明以上每一層都成功。

先關閉 TUN，只保留系統代理，使用瀏覽器存取一般網站。若瀏覽器連線失敗，檢查系統代理位址是否為本機、連接埠是否與客戶端一致，再查看記錄是否有連線紀錄。完全沒有記錄通常表示流量未進入客戶端；有請求但立即遭拒，常見原因是連接埠錯誤或核心未啟動；有規則命中但遠端握手失敗，則繼續檢查節點與網路條件。

若關閉系統代理後仍無法開啟網頁，可能存在代理殘留、DNS 快取或其他 VPN 路由。Windows 檢查系統代理，macOS 檢查目前網路服務，行動系統檢查 VPN 狀態，Linux 檢查環境變數與預設路由。重新啟動裝置可以清除部分暫存狀態，但應在重新啟動前記錄設定與記錄，否則重現問題後仍不知道是哪一層發生改變。

訂閱無法更新或解析失敗

訂閱更新失敗時，先用瀏覽器開啟原始連結，確認回傳狀態。若連結無法存取、已過期或回傳登入頁，應在服務提供方端更新網址。瀏覽器可以存取但客戶端失敗時，再檢查客戶端網路權限、目前代理規則與系統時間。憑證連線依賴準確時間，裝置時間偏差過大時，可能出現看似網路故障的安全連線錯誤。

解析失敗通常表示回傳內容不是相容的 YAML、欄位結構不被目前客戶端識別，或內容已被網頁驗證頁與錯誤頁面取代。不要只看 HTTP 狀態碼，回應成功也可能只是一段 HTML。可將回應內容儲存至本機，檢查開頭是否為設定欄位，並確認縮排與編碼。完整的逐項判斷可參考訂閱失效與解析失敗自我檢查清單。

匯入後節點為空時，先確認選用的是 Clash 或 mihomo 格式，而不是僅適用於其他工具的訂閱。節點存在但策略群組為空，可能是設定轉換時缺少 proxy-groups。不要手動將大量節點逐一複製到新檔案，優先從訂閱來源重新取得正確格式，避免驗證欄位與協定參數在複製過程中損壞。

只有部分網站或應用程式失敗

部分網站無法使用時，先查看連線記錄中的網域、命中規則與策略。若誤命中 DIRECT，應調整具體規則，並將它放在範圍較寬的規則之前；若已進入代理但仍失敗，固定一個已驗證的節點重試，以排除自動策略切換。若瀏覽器正常而某個應用程式失敗，請檢查該應用程式是否讀取系統代理，必要時測試 TUN 或行動端應用程式分流。

網站可以開啟，但圖片、登入或影片失敗，通常是主網域與資源網域命中不同策略。開發者工具或連線清單可以顯示附屬網域，再判斷是否應使用相同策略。不要用一條過於寬泛的 DOMAIN-KEYWORD 規則涵蓋所有相似名稱，這可能連無關服務也一併改變。較穩妥的方式是採用維護良好的規則集，或為明確的網域後綴新增規則。

切換節點後問題短時間內仍存在，可能來自 DNS、HTTP/2、QUIC 或應用程式工作階段快取。完全退出目標應用程式，清除必要快取並重新建立連線後再測試。瀏覽器隱私視窗只能減少部分快取，不能取代系統 DNS 刷新。對照測試每次只改變一個變數，並記錄模式、節點、網路與命中規則。

DNS、連接埠與 TUN 衝突

DNS 故障的典型特徵是 IP 可達但網域失敗、記錄持續出現查詢逾時，或同一網域在不同應用程式中得到矛盾結果。先檢查本機 DNS 監聽連接埠是否被佔用，再關閉瀏覽器獨立 DNS 與系統額外 DNS 工具進行對照。fake-ip 模式下看到保留位址是設計行為，不應將該位址本身視為遠端伺服器故障。

連接埠衝突會導致代理或控制介面無法監聽。查看記錄中的 bind、address already in use 等資訊，再使用系統工具定位佔用程序。修改連接埠後，系統代理、終端機環境變數、瀏覽器擴充功能與區域網路裝置都必須同步更新。只修改客戶端欄位而保留舊系統代理，會形成「核心正常執行但沒有請求進入」的狀態。

開啟 TUN 後整個網路中斷時，先關閉 TUN 恢復基準，再檢查虛擬介面權限、預設路由、DNS 劫持與其他 VPN。桌面虛擬機、容器、遊戲加速器與企業網路軟體都可能安裝網路過濾驅動程式。依序停用衝突工具，每次只恢復一個。若問題只在休眠喚醒後出現，應重建 TUN 介面並觀察是否有殘留路由。

如何閱讀記錄，以及何時回復

日常排查使用 info 層級即可；debug 記錄只在需要短時間收集細節時開啟，因為它會產生大量連線紀錄。重點尋找設定載入錯誤、監聽失敗、DNS 逾時、規則命中、遠端握手與路由建立資訊。分享記錄前，請移除訂閱網址、驗證欄位、節點憑證與不希望公開的存取網域。

當多項修改疊加後無法判斷時，應回到最小狀態：停用 TUN 與覆寫，只載入一份原始訂閱，使用預設本機連接埠，固定一個節點，透過系統代理測試瀏覽器。恢復基準後，依「自訂 DNS—附加規則—TUN—區域網路分享」的順序逐項加入。某一步加入後立即重現問題，就能將調查範圍限制在該層。

如果原始訂閱在多個網路、 多個客戶端上都無法連線，而連結回傳內容正常，應聯絡訂閱服務提供方確認節點狀態；如果同一份訂閱在其他裝置可用，則優先檢查本機權限、連接埠、DNS 與路由。重新安裝客戶端只適合修復程式檔案或系統整合損壞，不會自動修正訂閱格式、規則邏輯與遠端節點狀態。

完成排查後，應將最終有效的客戶端、設定名稱、代理模式、DNS 選擇與必要覆寫記錄在本機。後續更新只需與這份基準比較，不必重新猜測整條流量路徑。需要重新安裝或更換平台時，可返回客戶端下載頁核對系統架構與可用客戶端。