Clash 安裝設定
Windows、macOS、Android、iOS 與 Linux

01 / PREPARE

通用準備工作：用戶端、訂閱與網路邊界

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

開始安裝前，先釐清三個經常混用的概念。用戶端是使用者實際操作的圖形介面，負責匯入設定、切換策略、查看日誌與控制系統代理；Mihomo 等核心負責解析設定、比對規則並建立代理連線；訂閱則是服務提供者提供的設定入口，通常包含節點、策略組、規則與更新網址。安裝用戶端不會自動產生可用節點，單獨下載核心也不會形成完整的桌面操作介面。一般桌面與行動裝置應優先選擇具備圖形介面的用戶端；伺服器、路由器或自動化環境才較適合直接執行核心。

本站下載頁依平台列出可選軟體，並將 Clash Plus 排在各平台首位。Windows 另可選擇 Clash Verge Rev、FlClash、Clash Nyanpasu 與已封存的 Clash for Windows；macOS 可選擇 Clash Verge Rev、FlClash 與已封存的 ClashX Meta；Android 可選擇 Clash Meta for Android、FlClash 或 Surfboard；Linux 桌面可選擇 Clash Verge Rev 與 FlClash。不同用戶端的選單名稱可能略有差異，但設定流程大致一致：匯入訂閱、選取設定、測試節點、選擇策略、啟用代理、驗證出口。

記錄必要資訊並確認系統架構

下載前確認裝置的作業系統版本與處理器架構。Windows 常見為 x64，部分新裝置使用 ARM64；搭載 Apple 晶片的 Mac 應選擇 Apple Silicon 或 ARM 建置版本，較早的 Intel Mac 則選擇 x64 建置版本；Android 安裝套件可能區分 arm64、arm 或通用架構；Linux 還需區分 Debian 系、RPM 系與壓縮格式的獨立二進位檔。架構不相容時，安裝程式可能直接拒絕執行，也可能在啟動後提示格式錯誤。無法確認時，應優先查看系統的「關於本機」或使用系統指令，而不是依裝置外觀判斷。

# Windows PowerShell
$env:PROCESSOR_ARCHITECTURE

# macOS
uname -m

# Linux
uname -m
cat /etc/os-release

同時準備有效的訂閱網址、必要的登入資訊，以及能正常連線至訂閱入口的網路。訂閱網址通常包含驗證參數，應像密碼一樣保存，不要貼到公開截圖、問題文章或共用日誌中。若服務方提供 QR Code，行動裝置可掃描匯入；桌面端通常透過剪貼簿貼上 URL。收到本機 YAML 檔案時，應使用「匯入本機設定」而不是「訂閱連結」，因為本機檔案不會自動隨遠端更新。

建立安裝前的基準狀態

啟用代理前，先確認裝置時間、瀏覽器連線與 DNS 解析均正常。系統時間偏差可能導致 TLS 連線失敗；既有 VPN、企業安全軟體、虛擬網卡或其他代理程式也可能佔用連接埠並改變路由。建議暫時退出同類網路工具，記錄系統原有的代理設定，再安裝 Clash 用戶端。如此一來，發生連線異常時便能判斷問題來自原有網路、用戶端接管或訂閱內容，而不必同時排查多個變數。

選擇系統代理或 TUN

系統代理主要影響遵循作業系統代理設定的瀏覽器與桌面應用程式，設定簡單、影響範圍明確，適合作為首次連線方式。TUN 會建立虛擬網路介面，從路由層接管更多流量，可涵蓋不讀取系統代理的程式、部分命令列工具與遊戲，但需要較高權限，也更容易與其他 VPN、虛擬機器、容器網路或安全軟體發生衝突。兩者不是速度等級，而是不同的流量接管方式。沒有明確需求時先使用系統代理；遇到應用程式繞過系統代理，再評估是否啟用 TUN。

02 / WINDOWS

Windows 安裝設定：系統代理、服務模式與 TUN

下載並完成首次安裝

Windows 使用者可在Windows 下載區選擇 Clash Plus，或依需求選擇 Clash Verge Rev、FlClash、Clash Nyanpasu。Clash for Windows 已停止維護，僅作為相容舊設定的封存選項，不適合長期用於新環境。下載前可在「設定 → 系統 → 系統資訊」查看系統類型，絕大多數桌上型電腦使用 x64。若安裝程式觸發系統安全性確認，應核對檔名與下載來源，再依一般應用程式安裝流程繼續。

安裝完成後先正常啟動一次，讓用戶端建立設定目錄與基本設定。若介面無法開啟，不要立即啟用相容模式或反覆重新安裝；先在工作管理員確認是否已有同名程序，再結束背景程序後重新啟動。可攜版與安裝版可能使用不同的資料目錄，遷移時不要只複製可執行檔，應從用戶端提供的設定目錄入口尋找 profiles、logs 或相關資料。

匯入訂閱並啟用設定

開啟用戶端的訂閱、設定或 Profiles 頁面，將訂閱 URL 貼入輸入框後執行匯入。匯入成功後通常會出現設定名稱、更新時間與策略組。看到設定卡片不代表已經啟用，仍需點選該設定或將其設為目前設定。接著進入代理或 Proxies 頁面，先對候選節點執行延遲測試。延遲測試失敗不必立即刪除訂閱，因為 ICMP、TCP 探測與實際網頁連線可能採用不同方式；應再選取一個節點，進行實際連線驗證。

訂閱更新失敗時，先在瀏覽器中確認訂閱入口是否仍可存取。如果瀏覽器能開啟而用戶端報錯，請檢查 URL 是否在複製時遺漏結尾參數、是否混入空格，以及用戶端更新訂閱時是否錯誤地經過目前代理。部分用戶端提供「直接連線更新」或更新代理選項，可在基本網路可用時切換測試。遠端設定更新會覆蓋訂閱提供的節點與規則，手動修改內容前應先確認用戶端是否提供覆寫功能。

啟用系統代理並選擇模式

首次連線建議使用規則模式。選取一個可用節點或策略組後，開啟「系統代理」開關。用戶端會寫入 Windows 的代理設定，常見的本機位址為迴送位址，連接埠則由目前設定或用戶端設定決定。瀏覽器通常會立即讀取新設定，部分已在執行中的應用程式可能需要重新啟動。全域模式會將大多數請求交給選定策略，適合短時間判斷規則是否誤分流；直連模式則用於暫時繞過代理。排查結束後應回到規則模式，避免長期擴大代理範圍。

如果系統代理開關顯示已啟用，但瀏覽器仍直接連線，可進入「設定 → 網路和 Internet → 代理」檢查手動代理是否已寫入，同時確認企業策略或其他軟體沒有立即覆寫該值。不要同時啟用多個用戶端的系統代理開關，否則它們會爭用同一組系統設定。用戶端異常結束後若網頁完全無法存取，常見原因是系統仍指向已停止監聽的本機連接埠，此時關閉手動代理即可恢復基本網路。

服務模式與 TUN 權限

Windows 上的 TUN 通常需要系統管理員權限，或由用戶端安裝背景服務。服務模式的作用是讓核心或網路元件在受控權限下執行，並不等同於節點服務。安裝服務後再啟用 TUN，系統會出現新的虛擬網路介面卡，並加入相應路由。首次啟用時，安全軟體可能要求確認網路存取，應允許用戶端在目前需要的網路類型中通訊。若服務安裝失敗，先退出舊版用戶端，確認系統服務中沒有殘留的同名項目，再以系統管理員權限執行用戶端內建的服務安裝操作。

Windows 特有故障定位

Microsoft Store 應用程式、命令列程式與部分遊戲不一定遵循系統代理。一般瀏覽器可以連線而某個應用程式無法連線時，先判斷該應用程式是否讀取 WinINET 或系統代理；若不讀取，再使用 TUN，不應先修改訂閱規則。若只有區域網路裝置無法存取本機代理，需確認「允許區域網路連線」設定、Windows 防火牆入站規則與監聽位址，但開放區域網路監聽代表同一網路中的裝置可能連線至該連接埠，僅在確有需要時啟用。

遇到 HTTPS 憑證錯誤時，優先檢查 Windows 時間與時區、瀏覽器憑證詳細資訊，以及系統中是否同時執行封包擷取或過濾軟體，並參考HTTPS 憑證錯誤排查。代理協定本身通常不要求使用者任意安裝網頁提供的憑證；若問題只出現在某個瀏覽器，應先清除該瀏覽器的代理擴充功能與網路策略，再判斷是否屬於系統層級故障。

03 / MACOS

macOS 安裝設定：晶片架構、系統擴充功能與代理權限

選擇 Apple Silicon 或 Intel 建置版本

macOS 使用者可優先選擇 Clash Plus，也可使用 Clash Verge Rev、FlClash；ClashX Meta 已停止維護，主要作為既有環境的相容性參考。點選螢幕左上角的 Apple 選單並開啟「關於這台 Mac」，若晶片欄顯示 Apple M 系列，請選擇 Apple Silicon 或 ARM 建置版本；顯示 Intel 則選擇 x64 建置版本。也可以在終端機執行 uname -m，輸出 arm64 代表 Apple 晶片，輸出 x86_64 代表 Intel。

下載後通常將應用程式拖曳至「應用程式」資料夾，再從該資料夾啟動。長期直接從磁碟映像檔或下載目錄執行，可能導致自動更新、權限記錄與資料路徑不穩定。系統首次開啟來自網路的應用程式時會進行安全性確認，應透過 Finder 找到應用程式並依系統提示處理。不要為了繞過提示而全域降低系統安全性設定。若下載了錯誤架構，Apple 晶片可能透過相容層執行 x64 版本，但網路擴充功能、效能與輔助元件仍可能有差異，應優先改用符合架構的建置版本。

匯入訂閱與選單列操作

啟動後進入 Profiles、設定或訂閱頁面，貼上訂閱 URL，儲存並選取剛匯入的設定。macOS 用戶端經常同時提供主視窗與選單列入口，系統代理、執行模式與目前策略可能位於選單列圖示中。完成匯入後確認目前設定名稱已切換，再進入策略組選擇節點。關閉主視窗後若選單列仍有圖示，通常表示用戶端仍在背景執行；若要完全退出，應使用選單中的退出指令，而不只是按下視窗的關閉按鈕。

訂閱包含多個策略組時，先處理「節點選擇」或名稱相近的手動選擇組，再檢查自動選擇、故障轉移等策略組是否引用了正確節點。規則最終指向的是策略組名稱，不一定直接指向某部伺服器。某個網站連線異常時，應查看連線記錄中命中的規則與策略，而不是只反覆切換首頁顯示的節點。

系統代理的寫入與還原

啟用系統代理後，用戶端會修改目前網路服務的網頁代理設定。macOS 會分別維護 Wi‑Fi、有線網路與其他網路服務的設定，因此切換網路後需要確認新服務是否已正確接管。可在「系統設定 → 網路 → 目前網路 → 詳細資訊 → 代理」查看網頁代理與安全網頁代理狀態。正常情況下應由用戶端管理這些項目，不要一方面讓用戶端自動寫入，一方面又手動填寫另一組連接埠。

如果用戶端崩潰後 Safari 與其他應用程式無法存取網路，先退出殘留程序，再到系統網路代理頁面取消已失效的本機代理。也可以使用指令查看具體網路服務，但服務名稱可能因語言與使用者修改而不同，應先列出名稱再查詢：

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

終端機中的 curl、套件管理器與開發工具不一定會統一讀取圖形介面的系統代理。某些工具讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 環境變數，另一些則擁有獨立的代理設定。如果圖形應用程式正常而終端機指令直接連線，應先確認工具的代理行為；需要涵蓋更多程序時可以評估 TUN，但不應在未記錄來源的情況下，把環境變數與 TUN 同時作為永久方案。

TUN、網路擴充功能與系統授權

啟用 TUN 時，macOS 可能要求系統管理員密碼、VPN 設定授權或網路擴充功能許可。授權通常只需依系統彈窗完成一次，之後可以在系統的 VPN 與網路相關設定中查看狀態。TUN 啟用後，用戶端會透過虛擬介面接收路由流量，因此 Docker Desktop、虛擬機器、企業 VPN、網路過濾器與本機開發網段都可能受到影響。若公司內網或區域網路服務突然無法存取，應檢查規則是否保留私有位址直連，並確認 TUN 自動路由沒有覆蓋專用路由。

DNS 與休眠後的連線問題

macOS 會維護系統 DNS 快取，瀏覽器也可能使用自己的安全 DNS。修改 Clash DNS 設定後，如果仍使用舊的解析結果，可先完全退出瀏覽器並重新連線網路；只有確認是快取問題時，再執行系統快取清除。休眠喚醒後出現「節點測試正常但網頁無法開啟」，常見原因包括虛擬介面未恢復、系統代理仍指向舊程序，以及上游網路的 DNS 位址變更。依照「停止接管 → 確認直連 → 重新啟動用戶端 → 重新啟用接管」的順序處理，可以判斷故障發生在哪一層。

04 / ANDROID

Android 安裝設定：VPN 授權、背景執行與應用程式分流

安裝用戶端並完成首次授權

Android 可優先選擇 Clash Plus，也可使用 Clash Meta for Android、FlClash 或 Surfboard。下載安裝套件時，應依裝置架構選擇 arm64、arm 或通用建置版本。近年的主流裝置通常為 arm64，但不能只依 Android 版本判斷；裝置資訊工具或系統硬體資訊能提供更準確的 ABI。安裝失敗時，先檢查檔案是否完整下載、架構是否相符，以及系統是否允許目前的瀏覽器或檔案管理器發起應用程式安裝。

用戶端首次啟動並開始連線時，Android 會彈出 VPN 連線要求。這是本機虛擬網路介面的系統授權，用於將應用程式流量交由用戶端處理。確認後，狀態列通常會出現 VPN 標誌。Android 通常同一時間只允許一個一般 VPN 連線，因此企業 VPN、其他代理用戶端或系統的永遠開啟 VPN 可能與 Clash 競爭。無法建立連線時，應先到系統 VPN 設定查看目前的使用者，而不是不斷重複點選啟動。

透過 URL、檔案或 QR Code 匯入訂閱

進入設定頁面後，可以貼上訂閱 URL、選取本機設定檔，或使用 QR Code 入口匯入。QR Code 可能包含完整訂閱網址，匯入後同樣需要妥善保護設定資訊。遠端訂閱匯入成功後，選取設定並等待核心載入；如果提示 YAML 解析失敗，問題通常來自遠端回傳登入頁、錯誤頁面或不相容內容，而不是手機網路權限本身。可先在瀏覽器中開啟訂閱入口，確認回應確實是設定資料。

行動網路與 Wi‑Fi 可能使用不同的 IPv6、DNS 與存取策略。某個網路更新失敗而另一個網路正常時，應分別測試訂閱入口與節點連線，不要直接判定用戶端損壞。部分訂閱需要定期更新，建議在設定頁面執行明確的手動更新動作，並查看更新時間與錯誤提示。更新後若節點名稱改變，原先手動選擇的策略可能回到預設項目，需要重新檢查策略組。

規則模式、全域模式與應用程式分流

Android 首次連線仍建議使用規則模式。選擇節點後啟動 VPN，再用瀏覽器驗證出口。全域模式適合短時間確認某條規則是否導致直連，測試完成後回到規則模式。應用程式分流可指定哪些應用程式經過代理、哪些繞過代理，但不同用戶端可能分別使用「僅代理選取的應用程式」或「排除選取的應用程式」這兩種相反語意。儲存前必須核對目前模式，避免誤將需要代理的應用程式加入繞過清單。

應用程式分流只決定流量是否進入用戶端，進入後仍會繼續比對網域、IP 與策略規則。若一個應用程式同時存取公開介面、區域網路裝置與推播服務，簡單地讓整個應用程式走代理可能造成登入異常。更穩妥的做法是先讓應用程式進入規則模式，再根據連線日誌補充特定網域規則。銀行、付款、區域網路控制與電信業者服務通常更依賴本地網路環境，應依實際存取需求決定直連規則。

背景限制與連線遭系統回收

Android 裝置製造商經常對背景應用程式實施電池限制。鎖定螢幕數分鐘後 VPN 標誌消失、通知被清除或連線需要重新啟動時，通常應檢查用戶端的電池最佳化、背景活動、自動啟動與通知權限。將應用程式設為不受限制可提高背景存活機會，但也可能增加耗電，應依裝置系統提供的選項逐項調整，不必一次開放所有無關權限。用戶端的常駐通知是前景服務狀態的一部分，關閉通知權限可能影響系統對服務的管理。

從 Wi‑Fi 切換至行動網路時，原連線的來源位址與路由會改變。用戶端通常會自動重建連線，但某些長連線仍需由應用程式重新發起。切換網路後若只有個別應用程式卡住，可以先強制結束該應用程式再重新開啟；若所有流量都失敗，再重新啟動用戶端連線。頻繁自動斷線時，還應檢查系統是否啟用了省電模式、節省數據模式或製造商的休眠應用程式清單。

私人 DNS、IPv6 與熱點分享

Android 的私人 DNS 使用加密解析，可能與用戶端的 DNS 劫持或 fake-ip 方案形成兩條解析路徑。出現網域解析失敗、瀏覽器可用但其他應用程式不可用時，可暫時將私人 DNS 調整為自動狀態進行對照測試。確認衝突後，再決定保留系統私人 DNS，或由 Clash 統一處理解析。IPv6 也應依節點、電信業者與設定支援情況啟用，單純關閉並不是長期解決方案；應透過日誌判斷失敗請求使用的是 IPv4 還是 IPv6。

使用手機熱點分享時，下游裝置的流量不一定會自動進入 Android 本機 VPN。能否接管熱點流量取決於系統實作、用戶端能力與裝置權限。需要為其他裝置提供代理時，更清楚的做法是在用戶端允許區域網路連線，讓下游裝置手動填寫手機的區域網路位址與代理連接埠，並限制在可信任網路中使用。若沒有明確的分享需求，應保持區域網路監聽關閉，減少額外暴露範圍。

05 / IOS

iOS 安裝設定：App Store、VPN 設定與隨選連線

從 App Store 取得並辨識系統權限

iPhone 與 iPad 可透過 App Store 取得 Clash Plus。安裝完成後首次建立連線時，iOS 會要求加入 VPN 設定，並透過裝置密碼、生物辨識或系統確認完成授權。授權後，用戶端才能建立本機網路通道並處理流量。此權限由系統統一管理，可以在「設定 → 一般 → VPN 與裝置管理」或對應版本的 VPN 設定中查看。若裝置由學校或企業管理，管理政策可能限制新增 VPN 設定，應先確認裝置政策。

iOS 同一時間只會讓一組主要 VPN 設定處於啟用狀態。其他 VPN、企業安全用戶端、內容過濾器或私人轉送等功能可能改變實際連線路徑。點選連線後立即中斷時，先查看系統 VPN 頁面是否存在衝突設定，再回到用戶端讀取錯誤資訊。刪除所有系統網路設定會同時影響 Wi‑Fi 與其他設定，不應作為第一個排錯動作。

匯入訂閱並選擇目前設定

在用戶端中開啟設定或訂閱入口，貼上服務方提供的 URL，或掃描 QR Code。若連結是從通訊軟體複製而來，應檢查是否包含換行、前後空格或遭截斷的查詢參數。匯入後選取該設定，再進入策略頁面選擇節點。部分用戶端會在匯入完成後自動載入，但不會自動替使用者確定每個手動策略組；首次連線前至少應檢查主要節點組與最終兜底策略。

從「檔案」App 匯入 YAML 時，檔案可能來自 iCloud Drive 或本機儲存空間。若檔案尚未完成雲端下載，用戶端可能無法讀取；先在「檔案」中確認可以開啟，再執行分享或匯入。遠端訂閱與本機檔案的更新方式不同：遠端訂閱可以重新向上游請求，本機檔案則需要重新匯入修改後的版本。不要直接編輯訂閱產生的節點欄位，下一次更新通常會覆蓋這些修改。

連線、規則模式與隨選啟動

選取設定與節點後啟用連線，狀態列或控制中心會顯示 VPN 狀態。先使用 Safari 存取常用網站，再檢查其他應用程式。規則模式會依設定中的規則決定直連或代理；全域模式可用於短時間定位規則問題；直連模式則用於確認關閉代理後的基本網路。若 Safari 正常而某個應用程式失敗，應查看該應用程式相關網域是否命中拒絕、直連或不適合的策略組，而不是只切換伺服器。

隨選連線可以依網路變化自動啟動 VPN，但條件設定過寬時，會在所有 Wi‑Fi 與行動網路上持續連線；條件過窄時，切換網路後又可能不會觸發。首次安裝階段建議先手動連線，確認訂閱、節點與 DNS 都正常後，再設定隨選規則。若需要在可信任的家庭網路停用，應依網路識別資訊設定例外，並定期檢查路由器重新命名後條件是否仍然符合。

iOS 的網路變化與背景行為

iOS 會依電量、網路狀態與系統排程管理背景活動，但已建立的 VPN 通道由系統網路擴充功能維持，不等同於一般應用程式一直停留在前景。若鎖定螢幕後連線頻繁中斷，應查看用戶端日誌中的停止原因、系統低耗電模式與網路切換情況。行動網路與 Wi‑Fi 之間切換時，原有 TCP 連線可能中斷，這是來源位址變更的正常結果；重新開啟受影響的應用程式通常會建立新連線。

某些 Wi‑Fi 需要先完成網頁驗證。連線至這類網路時，如果 VPN 已自動啟動，驗證頁面可能無法跳出。可以暫時中斷用戶端，開啟任意非加密網頁觸發驗證，完成後再連線。飯店、機場與公共網路還可能限制特定協定，若節點在行動網路正常而公共 Wi‑Fi 全部失敗，應先判斷網路限制，不要反覆刪除設定。

DNS、區域網路與推播服務

iOS 應用程式可能存取區域網路裝置、系統推播服務與區域化介面。規則設定應讓私有位址與本地域名保留直連，避免家庭儲存裝置、印表機與智慧裝置因被送入遠端代理而失去連線。首次存取區域網路時，系統可能詢問本地網路權限；拒絕後，用戶端介面本身可能仍能連線至網際網路，但區域網路探索與分享功能會受限。可在系統隱私權設定中重新確認權限。

若通知延遲但網頁存取正常，應檢查推播相關連線命中的策略、節點穩定性與系統通知設定。不要只因推播異常就改用全域模式，因為全域模式會改變更多應用程式的出口。DNS 問題則應比較同一網域在 Safari、應用程式內與不同網路下的表現。關於解析出口與 fake-ip 的判斷，可繼續閱讀Clash DNS 洩漏檢測與修復。

06 / LINUX

Linux 安裝設定：桌面用戶端、核心服務與權限

桌面用戶端與獨立核心的取捨

Linux 桌面使用者可在Linux 下載區選擇 Clash Verge Rev 或 FlClash。兩者提供訂閱管理、策略切換與日誌介面，適合日常桌面環境。伺服器、軟路由與沒有圖形介面的裝置可以直接執行 Mihomo 核心，但需要自行管理設定檔、啟動參數、權限與服務生命週期。兩種方式不要同時監聽同一組連接埠，否則可能啟動失敗或使流量進入錯誤程序。

安裝套件需要與發行版相符。Debian、Ubuntu 及其衍生系統通常使用 deb；採用 RPM 套件管理的發行版使用 rpm；獨立壓縮包則需要手動放置可執行檔並管理相依套件。處理器架構可透過 uname -m 確認，x86_64 對應 AMD64，aarch64 對應 ARM64。路由裝置還可能使用 ARMv7 或 MIPS 變體，選擇錯誤時常見提示為無法執行二進位檔。

桌面環境中的系統代理

GNOME、KDE 與其他桌面環境儲存系統代理的方式各不相同，用戶端的「系統代理」開關不一定能涵蓋所有環境。啟用後，應在桌面網路設定中檢查 HTTP、HTTPS 與 SOCKS 代理是否指向用戶端監聽的連接埠。瀏覽器可能讀取桌面代理，也可能使用自己的設定；終端機程式則通常依賴環境變數。某個圖形應用程式正常而命令列失敗，不代表節點失效，應先確認該程式讀取的是哪一套代理設定。

# 僅對目前終端機工作階段生效，連接埠應與用戶端實際監聽值一致
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:7891

# 測試完成後還原
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

變數名稱同時存在大小寫形式時，不同工具的讀取順序可能不同。不要把臨時測試變數直接寫入所有 shell 啟動檔案，否則用戶端關閉後，套件管理器與開發工具仍會指向失效連接埠。需要長期設定時，應建立獨立的啟用與停用腳本，並明確記錄連接埠來源。

以服務方式執行 Mihomo

獨立核心通常透過 -d 指定設定目錄，透過 -f 指定設定檔。首次執行前先驗證檔案權限與工作目錄，尤其是由 systemd 啟動時，服務使用者的主目錄、相對路徑與互動式終端機都不同。建議使用專用目錄保存設定與執行資料，並讓服務使用者擁有必要的讀寫權限。不要長期以最高權限執行所有功能；只有建立 TUN、寫入路由等操作需要額外能力。

# 前景測試設定，確認日誌沒有解析錯誤後再交給服務管理器
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

# 檢查監聽連接埠
ss -lntup | grep -E '7890|7891|9090'

systemd 服務應設定明確的啟動指令、重新啟動策略與工作目錄。更新設定後先在前景或獨立指令中驗證，再重新啟動服務，避免錯誤設定造成反覆退出。日誌可透過服務管理器查看，也可依用戶端設定寫入檔案。若控制介面需要監聽區域網路，應設定存取控制並限制防火牆來源；僅供本機管理時，維持迴送位址監聽更為穩妥。

TUN、路由與 DNS 權限

Linux TUN 需要系統存在 /dev/net/tun，並要求程序具備建立介面與修改路由的權限。在容器、受限 VPS 或部分 NAS 環境中，這個裝置可能未映射，即使使用管理員帳戶也無法建立。啟用自動路由後，先檢查預設路由、策略路由表與防火牆規則，確保本機網段、遠端管理入口及代理伺服器本身的流量不會再次進入 TUN 而形成迴圈。

DNS 劫持依賴防火牆或路由能力，不同系統可能使用 nftables、iptables、systemd-resolved 或 NetworkManager。不要同時讓多個元件反覆重寫 /etc/resolv.conf。若系統使用 systemd-resolved，應透過其介面確認實際上游；若由 NetworkManager 管理，則應從連線設定調整。修改前記錄目前 DNS 狀態，關閉用戶端後確認系統解析能夠恢復。

Linux 常見啟動與權限問題

圖形用戶端無法啟動時，可從終端機執行以查看缺少的函式庫、顯示服務或沙盒提示。Wayland 與 X11 下的系統匣支援可能不同，關閉視窗後應確認程序是否仍在背景執行。核心提示連接埠已被佔用時，使用 ss 或 lsof 找出佔用者，不要任意更換所有連接埠，因為瀏覽器、環境變數與區域網路裝置可能仍引用舊值。設定目錄唯讀時，應修正檔案擁有者與權限，而不是將整個目錄開放給所有使用者寫入。

07 / CONFIGURATION

通用設定與規則分流：連接埠、DNS、策略組與 TUN

理解設定檔的執行順序

Clash 設定通常由基本監聽、代理節點、代理組、規則提供者、規則、DNS 與 TUN 等部分組成。節點定義連線參數，策略組決定如何從節點或其他策略中選擇，規則則將請求送入某個策略組。排查時應沿著「網域解析 → 規則比對 → 策略組選擇 → 節點連線」的順序判斷。只看到節點延遲正常，不能證明 DNS 與規則路徑正確；同樣地，規則命中代理也不代表目標節點一定可用。

YAML 依靠縮排表達階層，必須使用空格並保持同一層級的縮排一致。冒號後需要空格，包含特殊字元的文字可使用引號。節點密碼、訂閱參數與控制介面金鑰屬於敏感內容，展示日誌或設定片段前應刪除。訂閱檔案由上游維護時，直接修改正文可能在更新後遺失，應優先使用用戶端提供的覆寫、擴充腳本或本機規則合併功能。

監聽連接埠與區域網路存取

mixed-port 可以在同一連接埠接收 HTTP 與 SOCKS 請求，適合一般桌面使用；分別設定 port 與 socks-port 則便於依協定管理。allow-lan 控制區域網路裝置能否連線至監聽連接埠，關閉時通常只有本機可用。需要分享時，還要檢查 bind-address、系統防火牆與路由器隔離設定。區域網路代理沒有自動探索功能，下游裝置仍需填寫執行 Clash 裝置的區域網路位址與連接埠。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true

external-controller: 127.0.0.1:9090

外部控制介面供圖形介面或管理工具讀取狀態，並不是一般代理連接埠。僅供本機管理時，應監聽迴送位址。若確實需要遠端管理，應設定存取控制並在防火牆限制來源，避免將控制能力直接暴露於不可信網路。連接埠變更後，系統代理、瀏覽器擴充功能、終端機環境變數與區域網路裝置都需要同步更新。

規則模式與比對優先順序

規則通常由上而下比對，第一條命中的規則決定策略，最後則使用兜底規則處理前面未涵蓋的請求。網域規則適合穩定的網站範圍，IP 規則依賴解析結果，程序規則則受平台與權限限制。過於寬泛的規則若放在前面，會遮蔽後續更精確的規則。例如先寫入整個頂級網域規則，再寫入某個子網域直連規則，後者可能永遠不會命中。

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,FINAL

上述範例中的 PROXY 與 FINAL 必須對應實際存在的策略組名稱。no-resolve 表示比對 IP 網段時，不為此規則額外觸發網域解析，適合私有位址規則。實際設定中還應包含迴送、鏈路本地與其他需要直連的網路。需要完整了解網域、IP、程序規則的寫法與排列方式，可查閱Clash 自訂規則語法與優先順序。

策略組的選擇邏輯

手動選擇組允許使用者指定節點；自動測試組依探測結果選擇；故障轉移組在目前選項不可用時依序切換；負載平衡組則依設定策略分配連線。自動測試結果只反映指定測試 URL 與探測當下的狀態，不等同於所有網站的實際體驗。頻繁探測也會增加行動裝置耗電與網路請求，因此測試間隔應配合使用情境。

策略組可以引用其他策略組，形成「地區選擇 → 自動選擇 → 具體節點」的階層。修改最外層策略時，實際出口仍取決於內層結果。排查出口錯誤時，應逐層展開目前的選擇，查看連線記錄最後使用了哪個節點。策略組名稱變更會影響規則引用；訂閱更新後若日誌提示找不到策略，應檢查上游是否重新命名了策略組。

DNS 的 fake-ip 與 redir-host

fake-ip 模式會為網域回傳保留位址，並在核心中維持網域對應，讓後續連線階段保留網域資訊，規則比對通常更完整。部分區域網路裝置、遊戲、時間同步或依賴真實 IP 的程式可能不適合 fake-ip，需要透過過濾清單讓這些網域回傳真實位址。redir-host 更接近傳統解析路徑，但在某些流量接管情境中可能失去網域上下文。選擇哪種模式應依應用程式相容性與日誌判斷，不要把其中一種視為絕對更快。

dns:
  enable: true
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

範例中的公共解析位址僅用於說明結構，實際應依所在網路、隱私需求與可達性選擇。若啟用加密 DNS，還需要確保用於解析其伺服器網域的引導 DNS 可用，否則會形成循環依賴。瀏覽器自身的安全 DNS 可能繞過系統解析路徑，檢測 DNS 出口時應分別核對瀏覽器設定、系統查詢與用戶端日誌。

TUN 設定的關鍵項目

TUN 的核心是虛擬介面、自動路由與 DNS 接管。不同核心版本與用戶端對欄位的支援可能不同，應以目前用戶端產生或文件支援的設定為準。啟用 auto-route 後，核心會寫入路由；strict-route 會加強路由限制，但也更容易影響區域網路、虛擬機器與多網卡環境。行動裝置用戶端通常透過介面管理這些參數，不建議在不清楚合併規則時同時修改介面開關與底層 YAML。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53

啟用前先確認系統代理流程正常，再單獨測試 TUN。若啟用後斷網，立即關閉 TUN 並驗證直連，接著檢查權限、預設路由、DNS 劫持與其他 VPN。關於虛擬網卡接管範圍及各平台權限差異，可繼續閱讀Clash TUN 模式與全域流量接管。

08 / TROUBLESHOOTING

設定常見問題：依連線流程定位訂閱、節點、DNS 與路由

建立分層排查順序

Clash 故障應由外而內分層處理。第一層是基本網路：關閉系統代理與 TUN 後，裝置能否正常存取本地網路與訂閱入口。第二層是用戶端狀態：設定是否成功載入、核心是否執行、連接埠是否監聽。第三層是節點連線：目標位址能否建立連線，驗證與協定參數是否有效。第四層是規則與策略：請求命中了哪條規則、進入哪個策略組、最後選擇了哪個節點。第五層是 DNS 與系統路由：網域解析是否走預期路徑，虛擬介面與預設路由是否衝突。

每次只修改一個變數並記錄結果。反覆切換節點、模式、DNS 與 TUN 會同時改變多層狀態，最後即使恢復連線，也無法判斷真正原因。建議保存三組對照結果：停止接管時的直連狀態、規則模式加系統代理的狀態，以及規則模式加 TUN 的狀態。透過這三組結果，可以快速判斷問題位於基本網路、應用程式代理或路由接管。

訂閱匯入失敗或匯入後沒有節點

訂閱匯入失敗時，在瀏覽器中開啟訂閱入口，確認沒有跳轉至登入頁、錯誤頁或驗證碼頁面。檢查網址是否完整、是否已過期、是否被通訊軟體截斷，以及裝置時間是否正確。用戶端日誌出現 HTTP 狀態錯誤時，通常應先處理訂閱服務存取問題；出現 YAML 解析錯誤時，則應確認回傳內容是否確實為相容設定。不要將網頁 HTML 儲存後改名為 YAML，這不會轉換內容格式。

匯入成功但沒有節點，可能是設定只包含規則、節點由 provider 延遲載入，或上游回傳了空內容。查看設定中的 proxies、proxy-providers 與用戶端日誌，確認 provider 位址是否可存取。若節點存在但策略組為空，請檢查策略組篩選運算式是否排除了所有節點，以及引用名稱是否與 provider 一致。遠端設定更新後出現此問題，應對比上一次可用設定的策略組結構。

節點測試失敗但網頁偶爾可用

延遲測試通常會存取預設 URL，並受測試位址、DNS、節點出口與目標網站限制影響。測試失敗不一定代表所有連線都失敗，測試成功也不保證目標服務可用。應選取節點後存取實際目標，並在連線日誌中查看狀態。所有節點同時失敗時，更可能是訂閱參數、基本網路、系統時間或用戶端核心問題；只有少數節點失敗時，再考慮個別節點狀態。

同一節點在行動網路可用、Wi‑Fi 不可用，表示網路路徑或 DNS 存在差異。可以比較目標伺服器位址的解析結果、IPv4 與 IPv6 的可達性，以及公共網路是否限制相關協定。不要透過持續快速測試節點來恢復連線，這會增加並行請求，還可能觸發上游限制。

啟用系統代理後完全無法連線

先確認用戶端核心仍在執行，並監聽系統代理所填寫的連接埠。若用戶端已退出而系統仍保留手動代理，所有遵循系統代理的應用程式都會連線至不存在的本機服務。此時關閉系統代理或在系統設定中清除手動位址即可恢復。若連接埠正常監聽，切換至直連模式測試；直連模式可用而規則模式不可用時，重點檢查規則與策略；直連模式也不可用時，則檢查連接埠類型、驗證設定與本機防火牆。

瀏覽器可用而命令列不可用時，應檢查命令列工具是否讀取系統代理或環境變數。單一應用程式不可用時，檢查該應用程式是否繞過代理、使用 QUIC、固定 DNS 或需要 TUN。不要因為某個應用程式不遵循系統代理，就判定整個用戶端失效。

啟用 TUN 後區域網路或所有網路失效

立即關閉 TUN，確認基本網路恢復後，再查看虛擬介面是否已由系統刪除，以及預設路由是否還原。區域網路失效時，檢查私有位址直連規則、自動路由排除項與多網卡優先順序。所有網路失效時，重點檢查系統管理員權限、TUN 裝置、DNS 劫持與其他 VPN 衝突。Linux 還需檢查防火牆與策略路由；Windows 應檢查服務模式與虛擬介面卡；macOS 與行動裝置則應檢查系統 VPN 設定。

遠端伺服器上的 TUN 故障更加危險，因為錯誤路由會切斷管理連線。應預先保留管理來源直連，並透過主控台或備用工作階段恢復。於容器內執行時，還要確認主機是否映射 TUN 裝置並授予所需的網路能力。若不具備這些條件，應使用明確的代理連接埠，而不是強行啟用 TUN。

網域解析錯誤、DNS 出口異常或 fake-ip 衝突

先使用同一網域比較瀏覽器、系統查詢工具與用戶端日誌。若瀏覽器結果不同，檢查瀏覽器安全 DNS；若系統查詢正常但應用程式失敗，檢查應用程式快取與獨立解析設定；若所有查詢都失敗，檢查 Clash DNS 是否啟用、上游是否可達，以及引導 DNS 是否形成循環。fake-ip 位址出現在系統查詢結果中不一定是錯誤，可能是增強模式的正常行為，關鍵在於後續連線是否由核心正確還原至原始網域。

區域網路網域、印表機、投放與部分遊戲不相容 fake-ip 時，將明確的網域加入過濾清單，並保留私有位址直連。不要將所有網域都加入過濾，否則會失去 fake-ip 的主要作用。修改後需要讓應用程式重新發起解析，必要時重新啟動受影響的應用程式，而不只是重新整理網頁。

HTTPS 憑證錯誤與系統時間

多個網站同時出現憑證尚未生效、已過期或簽發者異常時，先檢查系統日期、時區與自動校時。只有某個瀏覽器異常時，檢查瀏覽器擴充功能、獨立代理與憑證快取。只有啟用某個網路過濾軟體後才出現異常，則逐層關閉中間處理元件，確認是哪一層改變了連線。不要忽略公共 Wi‑Fi 的驗證頁面，它可能將請求重新導向至驗證入口，導致憑證網域不相符。

憑證詳細資訊中的目標網域、簽發者與有效期限，有助於區分時間錯誤、網路驗證與中間層介入。完整判斷流程可參考代理鏈路、系統時間與憑證信任排查。

日誌讀取與恢復策略

排查期間將日誌層級調整為 info 通常已經足夠；debug 會產生大量內容，只應短時間使用。重點關注設定解析錯誤、DNS 查詢、規則命中、策略組、連線目標與底層網路錯誤。分享日誌前刪除訂閱 URL、節點憑證、裝置位址與存取記錄。錯誤訊息中的 timeout 表示逾時結果，不能直接說明是 DNS、路由或伺服器問題；connection refused 表示目標明確拒絕或沒有連接埠監聽；no such host 較偏向解析失敗；permission denied 則應檢查系統權限。

如果多次修改後狀態混亂，先匯出必要的本機規則與設定，停用系統代理與 TUN，退出用戶端，確認直連恢復後，再重新啟動並只匯入一份已知可用的設定。不要一開始就刪除所有應用程式資料，因為日誌、舊設定與設定差異正是定位問題的重要依據。需要快速重新建立基本連線時，可回到快速入門流程逐步執行；需要更換用戶端或重新下載安裝套件時，使用全平台下載頁選擇符合系統與架構的版本。