Clash 全平台安裝設定大全 - Windows、macOS、Android、iOS 與 Linux

一、安裝前的通用準備工作

先區分客戶端、核心與設定檔

Clash 的實際使用流程由三個部分組成。圖形客戶端負責顯示設定、切換策略、控制系統代理與管理更新；核心負責解析規則、建立連線、處理 DNS 與 TUN 流量；設定檔則保存代理入口、策略組、分流規則、連接埠與 DNS 參數。多數桌面與行動客戶端已經內建相容核心，一般使用者不需要另外下載 Mihomo。只有在伺服器、路由器、容器環境，或需要自行維護服務程序時，才應直接部署核心。

訂閱連結也不是客戶端自動產生的內容。它通常由網路服務提供者提供，客戶端只負責讀取連結並轉換成本機設定。公開程式碼儲存庫、客戶端官方網站與本站下載頁都不提供可直接使用的代理訂閱。收到訂閱網址後，應將其視為敏感資訊，不要放入截圖、公開工單、命令歷史共用檔案或可公開存取的程式碼儲存庫。若只取得一份 YAML 檔案，也可以匯入本機設定，不必先轉換成訂閱連結。

選擇與裝置相符的客戶端

首次安裝建議優先選擇圖形客戶端。Windows、macOS、Android 與 iOS 可先查看 Clash Plus；Windows 和 macOS 也可依介面偏好選擇 Clash Verge Rev、FlClash 或 Clash Nyanpasu；Android 可選 Clash Meta for Android、FlClash 或 Surfboard；Linux 桌面可選 Clash Verge Rev 與 FlClash。Clash for Windows 與 ClashX Meta 已停止維護，僅適合處理舊有環境，不建議作為新安裝的起點。所有可用入口集中在客戶端下載頁，不要依照舊教學中的檔名判斷目前套件是否適用。

下載前先確認處理器架構。Windows 常見裝置使用 x64；Windows on ARM 裝置需要確認客戶端是否提供相應版本。Apple Silicon Mac 使用 arm64 架構，舊款 Intel Mac 使用 x64。Android 安裝包常見 arm64、arm 與通用版本，近年的主流手機通常是 arm64，但不應只憑品牌判斷。Linux 還要同時區分 CPU 架構與套件格式：Debian、Ubuntu 常用 deb，Fedora 系列發行版常用 rpm；壓縮包則需要自行設定可執行權限與服務管理。

平台	優先選擇	安裝前確認	流量接管方式
Windows	Clash Plus	x64 架構、系統管理員權限需求	系統代理或 TUN
macOS	Clash Plus	Apple Silicon 或 Intel	系統代理或 TUN
Android	Clash Plus	CPU 架構、系統 VPN 權限	本機 VPN 服務
iOS	Clash Plus	App Store 帳號與系統權限	Network Extension
Linux	Clash Verge Rev	發行版、桌面環境、架構	桌面代理、TUN 或服務程序

整理安裝所需資訊

開始前準備訂閱連結或 YAML 檔案、裝置管理員權限、可正常連線的基礎網路，以及一個用來驗證結果的瀏覽器。公司或校園裝置可能受到管理政策限制，無法修改代理、VPN、網路擴充功能與憑證設定；此時即使客戶端安裝成功，也未必能變更系統網路狀態。不要連續反覆開啟多個同類客戶端。兩個程式同時監聽相同連接埠、寫入系統代理或建立 TUN 介面時，常會出現啟動失敗、網路迴圈，以及退出後無法恢復連線等問題。

預設設定經常使用 mixed-port 作為 HTTP 與 SOCKS 的統一入口。連接埠值由設定決定，常見範例是 7890，但應以客戶端介面顯示的數值為準。手動填寫瀏覽器或終端機代理時，主機通常是本機迴圈位址 127.0.0.1，連接埠則必須與正在執行的設定一致。不要把訂閱服務的遠端連接埠誤填到系統代理中，也不要把區域網路位址作為預設監聽位址，除非確實需要讓其他裝置連入。

理解規則、全域與直連模式

規則模式會依照設定中的 rules，由上到下比對網域、IP、程序或規則集，並將連線交給指定策略組，是日常使用的預設選擇。全域模式會忽略分流規則，把可代理流量統一交給全域策略，適合短時間判斷規則是否誤判，但不適合長期使用。直連模式會繞過代理，主要用於恢復基礎網路或確認故障是否來自客戶端。切換模式不會修復無效訂閱，也不會自動替換策略組中不可用的選項。

匯入後應先查看策略組。常見組名包括 Proxy、Auto、Streaming、Final 與 REJECT。手動選擇策略組時，必須明確選取一個可用策略；自動測試組會依照設定中的測試方式更新選擇；Final 通常承接前面規則都未命中的連線；REJECT 用於拒絕符合條件的流量。不同訂閱產生的名稱可能不同，操作時應依照組別類型與用途判斷，不能機械式尋找固定的中文按鈕。

二、Windows 下載、安裝與系統代理設定

下載與安裝圖形客戶端

Windows 新安裝可從Windows 客戶端區選擇 Clash Plus。也可以使用 Clash Verge Rev、FlClash 或 Clash Nyanpasu。Clash for Windows 已停止維護，僅應在必須相容舊設定或移轉歷史資料時使用。下載完成後執行安裝包；若系統跳出使用者帳戶控制提示，應確認檔案來源與目前操作，再決定是否授權。安裝目錄盡量使用一般本機磁碟路徑，避免放在暫存目錄、同步磁碟或受企業政策限制的資料夾中。

部分客戶端提供目前使用者安裝與所有使用者安裝。前者通常不需要持續使用管理員權限，後者方便多個帳戶共用程式檔案，但設定資料仍可能分別儲存在使用者目錄。若準備啟用 TUN、安裝服務或設定開機啟動，客戶端可能在首次操作時要求管理員權限。僅開啟傳統系統代理時，通常不需要一直以管理員身分執行。長期強制以管理員身分執行，會讓拖放、瀏覽器呼叫與一般使用者目錄存取出現額外限制，不應把它當成通用修復手段。

匯入訂閱並確認設定已啟用

進入設定檔或 Profiles 頁面，選擇從 URL 匯入，將完整訂閱網址貼到輸入框後執行下載。匯入成功不代表設定已啟用，還要在設定清單中選取剛匯入的項目，讓它成為目前設定。若使用本機 YAML，請選擇匯入本機檔案，或將檔案放入客戶端允許的設定目錄。直接編輯客戶端內部快取檔案，可能在訂閱更新時被覆寫；需要長期保留的自訂規則，應使用客戶端提供的覆寫、合併或指令碼功能。

設定啟用後，依序檢查代理模式、策略組與連接埠。規則模式適合日常使用。開啟 Proxy 等手動策略組，選擇訂閱中實際存在的策略；若設定包含 Auto 或 url-test 組，可先觸發一次更新。不要只以介面是否顯示綠色狀態作為唯一判斷，仍需在後續驗證實際連線。若設定下載後清單為空，通常是訂閱回傳格式、授權狀態或網路存取問題，而不是系統代理開關造成的。

系統代理與 TUN 的適用範圍

Windows 系統代理會將本機代理位址寫入系統設定。遵循 WinINET 或系統代理設定的瀏覽器與桌面應用程式會自動使用它，但部分遊戲、命令列工具、商店應用程式及自行實作網路堆疊的軟體可能忽略該設定。啟用後可在 Windows 的代理設定中看到本機位址與連接埠。正常退出客戶端時通常會恢復設定；若程式被強制結束或系統異常關機，可能留下指向已停止連接埠的代理項目，結果是所有網頁都無法開啟。

TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，適合不讀取系統代理的應用程式。首次啟用可能會安裝驅動程式或系統服務，並要求管理員授權。開啟後應觀察路由表、DNS 與防火牆是否正常，不要同時執行其他會建立 TUN 或全域 VPN 介面的軟體。系統代理與 TUN 能否同時開啟取決於客戶端實作；初次排查時，建議只保留一種接管方式，確認穩定後再決定是否組合使用。

命令列、終端機與開發工具

PowerShell、命令提示字元、Git、套件管理器與開發語言執行環境不一定會讀取 Windows 系統代理。需要時可在目前終端機工作階段設定環境變數，連接埠應替換為客戶端目前的 mixed-port。暫時變數只會影響該終端機及其子程序，關閉視窗後即失效，適合測試；在寫入使用者層級環境變數前，應確認不會讓離線開發、區域網路服務或容器工具走錯路徑。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

之後停用客戶端時，也應刪除持久化的 Git 代理設定，否則 Git 會繼續連線到本機已關閉的連接埠。可使用 git config --global --unset http.proxy 與對應的 HTTPS 命令清理。終端機能存取而瀏覽器無法存取，優先檢查系統代理、瀏覽器擴充功能與安全軟體；瀏覽器能存取而終端機無法存取，則重點檢查環境變數、Git 設定與工具本身的代理欄位。

Windows 特有的故障範圍

連接埠被占用是 Windows 上常見的啟動失敗原因。若客戶端日誌顯示位址已被使用，應先確認是否有另一個 Clash 執行個體或殘留程序，再決定結束程序或修改 mixed-port。完整定位方法可參考連接埠占用排查步驟。修改連接埠後，系統代理、瀏覽器手動代理、終端機環境變數與區域網路裝置都必須同步調整。

退出後網路中斷時，先關閉 Windows 手動代理，再檢查是否遺留虛擬網卡、代理環境變數或其他 VPN。不要立即重設所有網路元件，因為這會同時清除虛擬交換器、靜態 DNS 與開發環境設定。應先確認客戶端程序已結束，再逐層恢復：系統代理、DNS、預設路由、TUN 服務。若只在休眠喚醒後失效，可先重新啟動客戶端核心，再重建 TUN；頻繁重裝通常無法解決由路由競爭或安全政策引起的問題。

三、macOS 安裝、網路擴充功能與代理切換

依處理器架構選擇安裝包

下載 macOS 版本前先開啟「關於這台 Mac」確認晶片類型。Apple Silicon 對應 arm64 版本，Intel 處理器對應 x64 版本。新安裝可從macOS 客戶端區選擇 Clash Plus，也可使用 Clash Verge Rev 或 FlClash。ClashX Meta 已停止維護，主要用於舊有環境移轉。選錯架構可能導致程式無法啟動、依賴轉譯層執行或輔助服務安裝失敗，不應只憑檔名中是否出現 macOS 判斷相容性。

常見安裝方式是開啟磁碟映像檔，將應用程式拖曳到「應用程式」資料夾，然後從該資料夾首次啟動。不要長期直接從下載資料夾或掛載的磁碟映像檔執行，否則自動更新、登入時啟動與輔助服務路徑可能不穩定。若系統阻止開啟，應先核對下載來源，再到「隱私權與安全性」查看相關提示。不要為了解決單一應用程式的授權問題而全面降低系統安全設定。

匯入設定與選單列操作

進入 Profiles 或設定頁面，透過 URL 匯入訂閱，或匯入本機 YAML。下載完成後明確選取設定，再進入策略頁面選擇 Proxy、Auto 或設定中定義的其他組別。macOS 客戶端通常常駐於選單列，關閉主視窗不等於核心停止；排查連接埠占用或代理殘留時，需要從選單列執行退出，或在活動監視器中確認相關程序是否仍在執行。

訂閱更新會重新取得遠端內容。若客戶端支援自動更新間隔，應依照服務提供者的更新方式設定，不宜設定過於頻繁的輪詢。遠端設定與本機修改同時存在時，下一次更新可能覆蓋直接編輯的內容。需要補充分流規則、DNS 或指令碼時，優先使用覆寫設定。匯出包含完整代理資訊的設定檔前，應確認接收位置與存取權限。

系統代理的運作方式

開啟系統代理後，客戶端會修改目前網路服務的 Web 代理與安全 Web 代理設定。Safari 和遵循系統設定的應用程式通常會直接生效，但某些命令列工具、沙盒應用程式及自行管理連線的軟體不會讀取這些設定。切換 Wi-Fi、乙太網路、個人熱點或新增網路服務後，應重新確認代理狀態，因為 macOS 的代理設定與特定網路服務相關。

可以使用 scutil --proxy 查看系統目前讀取到的代理資訊。該命令只能說明設定是否寫入，不代表本機連接埠能接受連線，也不代表策略組已有可用選項。若代理位址仍在但客戶端已退出，可先從客戶端重新開啟再正常關閉，讓它執行恢復流程；也可以在系統網路設定中手動關閉對應代理項目。不要同時讓瀏覽器擴充功能、自動代理設定檔與客戶端系統代理互相覆蓋。

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

TUN、系統擴充功能與權限

macOS 的 TUN 模式通常需要安裝輔助服務、建立虛擬介面或取得網路擴充功能權限。首次啟用時，系統可能要求輸入管理員憑證，並在隱私權與安全性設定中確認。授權完成後仍應回到客戶端檢查核心是否真正啟動。若按鈕短暫開啟後自動關閉，應查看日誌中的權限、路由、DNS 或介面建立錯誤，而不是反覆點擊。

TUN 可以涵蓋不遵循系統代理的應用程式，但也更容易與其他 VPN、企業安全客戶端、虛擬機器網路及容器網路發生路由衝突。排查時先退出其他會建立預設路由或 DNS 代理的程式，只保留一個流量接管工具。若區域網路印表機、NAS 或開發伺服器無法存取，應檢查設定中的私有位址直連規則與繞過路由，而不是直接將所有流量改成直連。

終端機代理與憑證範圍

Terminal、Homebrew、Git、curl 與語言套件管理器可能需要個別設定代理。可在目前 shell 中匯出 HTTP、HTTPS 與 ALL_PROXY。若使用 zsh 並將變數寫入設定檔，也應準備取消設定的方法。長期保留代理變數會讓終端機在客戶端未啟動時顯示連線被拒絕，也可能影響存取本機開發伺服器。

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

一般 Clash 代理不需要為了基本連線安裝自訂根憑證。只有明確使用 HTTPS 解密、指令碼除錯或特定工具鏈時，才會涉及憑證信任。遇到 TLS 錯誤時，先核對系統時間、網域解析、代理策略與應用程式自己的憑證儲存區，不要將關閉憑證驗證作為長期方案。公司裝置上的憑證與網路擴充功能可能受管理設定控制，這類限制應由裝置管理員處理。

四、Android 安裝、VPN 權限與背景執行

選擇安裝包並完成安裝

Android 可從Android 客戶端區選擇 Clash Plus，也可使用 Clash Meta for Android、FlClash 或 Surfboard。安裝包可能依 arm64、arm 與通用架構提供。近年的主流裝置通常採用 arm64，但舊裝置、電視盒與模擬器可能不同。無法確定時可使用客戶端提供的通用版本；若系統提示解析套件失敗，應同時檢查架構、系統版本、檔案是否完整下載，以及裝置是否允許安裝此來源的應用程式。

透過瀏覽器或檔案管理器安裝時，Android 會要求為目前來源授予安裝權限。安裝完成後可以撤銷該來源權限，不影響客戶端後續執行。若系統已安裝相同套件名稱但簽章不同的版本，可能會拒絕覆蓋安裝。此時先匯出需要保留的設定，再解除安裝舊應用程式並重新安裝。不要假設解除安裝前的應用程式資料一定會自動恢復，尤其是本機覆寫、指令碼與手動匯入的 YAML。

匯入訂閱並建立本機 VPN

開啟客戶端後，在設定頁面新增訂閱 URL，填寫方便識別的名稱並執行更新。更新完成後選擇該設定作為目前設定，再進入代理組選擇策略。首次建立連線時，Android 會顯示 VPN 連線要求；這是系統授予應用程式建立本機 VPN 介面的權限。確認後，狀態列通常會出現 VPN 圖示。該圖示只代表介面已建立，仍需透過瀏覽器或客戶端日誌驗證流量是否成功轉送。

Android 通常一次只允許一個一般 VPN 服務處於啟用狀態。若系統已連線至其他 VPN、企業工作資料網路或廣告封鎖工具，新連線可能取代舊連線，或遭系統拒絕。私有 DNS 與 Clash 內部 DNS 也可能形成不同的解析路徑。出現網域無法開啟但直接存取 IP 正常時，應暫時檢查私有 DNS 設定，並確認設定中的 nameserver、fallback 或 fake-ip 行為。

應用程式分流與繞過設定

行動客戶端通常提供依應用程式選擇代理、繞過，或僅代理指定應用程式的功能。此功能適合讓銀行、區域網路控制、投放螢幕或對 VPN 敏感的應用程式保持直連，也適合只接管瀏覽器與通訊工具。修改應用程式清單後，需要重新建立 VPN 介面才能確保規則生效。系統應用程式可能由多個套件組成，不能只憑桌面圖示名稱涵蓋所有相關程序。

規則模式仍由設定規則決定目標連線的去向，應用程式分流則在更前一層決定某個應用程式是否進入 Clash。兩者不要混淆。某個應用程式設定為繞過後，其流量不會再進入網域規則，即使規則明確寫了代理也不會生效。排查單一應用程式時，應先檢查應用程式分流清單，再檢查規則命中與策略組，最後檢查該應用程式是否使用 QUIC、自訂 DNS 或憑證固定。

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

Android 裝置製造商經常會對背景活動、電池使用與自動啟動施加額外限制。常見表現包括鎖定螢幕一段時間後連線失效、清除最近使用的工作後 VPN 消失，以及切換行動網路後無法恢復。應在系統設定中允許客戶端於背景執行，依裝置提供的選項關閉過度的電池最佳化，並允許必要的自動啟動。不同製造商的選單名稱差異很大，但核心目標是避免系統凍結客戶端程序或限制其 VPN 服務。

永遠開啟的 VPN 可以由 Android 系統在網路變更後嘗試恢復，但在確認設定穩定前，不宜同時啟用「封鎖未使用 VPN 的連線」。如果訂閱失效、客戶端崩潰或核心啟動失敗，該選項可能導致裝置完全無法連線。先驗證 Wi-Fi、行動網路、休眠喚醒與重新啟動後的行為，再決定是否啟用嚴格模式。需要暫時恢復網路時，應先從系統 VPN 頁面中斷連線，而不是只關閉客戶端介面。

熱點、區域網路與 IPv6

手機開啟熱點後，連線至熱點的裝置是否經過 Clash，取決於系統版本、客戶端能力與轉送實作。一般 Android VPN 通常只保證本機應用程式流量，不應預設認為熱點下游裝置也會被接管。需要分享時，應確認客戶端是否明確提供熱點轉送或允許區域網路連線，並在下游裝置手動設定手機區域網路位址與代理連接埠。此時還要允許應用程式監聽區域網路，並注意公共網路中的存取風險。

部分行動網路優先使用 IPv6。若設定只提供 IPv4 DNS，或規則只涵蓋 IPv4，可能出現不同應用程式表現不一致的情況。不要直接關閉系統 IPv6 作為長期處理方式。應先確認核心 IPv6 開關、DNS 回應、規則匹配與代理入口是否支援對應連線。若日誌顯示連線嘗試停留在無法到達的 IPv6 位址，可暫時調整設定以便定位，再依網路環境決定是否啟用雙協定堆疊。

Android 端日誌是判斷故障層級的重要依據。設定解析錯誤通常會在核心啟動前出現；DNS 錯誤會顯示解析失敗或逾時；策略問題會顯示規則命中後連線失敗；應用程式被排除時，可能完全沒有對應請求。依照這四個層級排查，比反覆更換客戶端更容易定位原因。

五、iOS 安裝、設定匯入與隨選連線

透過 App Store 安裝 Clash Plus

iPhone 與 iPad 可在iOS 下載區進入 Clash Plus 的 App Store 頁面，客戶端官方網站為 clashplus.io。安裝完成後首次啟動時，系統可能要求新增 VPN 設定。該授權用於建立 Network Extension，不代表所有連線都已成功代理。授權後仍需匯入設定、選擇策略並啟動連線。

iOS 上的網路接管由系統擴充功能管理，不使用桌面系統代理開關。狀態列或控制中心出現 VPN 圖示，表示擴充功能處於連線狀態。即使關閉應用程式主介面，擴充功能仍可能繼續執行；若從系統設定中斷連線，應用程式內的狀態也應同步更新。排查時需要同時查看應用程式頁面與「設定」中的 VPN 狀態，避免只根據其中一個介面判斷。

匯入訂閱與本機設定

在設定頁面新增訂閱 URL，執行更新後選取該設定。若訂閱連結是從其他應用程式複製而來，應檢查首尾是否多出空格、換行，或遭聊天軟體截斷。透過檔案 App 匯入 YAML 時，可使用系統分享選單傳送至 Clash Plus，接著在設定清單中確認匯入結果。若設定檔引用外部規則集，首次載入時還需要下載相關資源；主 YAML 成功匯入，不代表所有規則資源都已準備完成。

策略組的選擇邏輯與其他平台相同。規則模式依規則分流，手動組需要選定實際策略，自動組則依設定中的測試方式更新。行動網路環境變化較頻繁，某個策略在 Wi-Fi 下可用，不代表在行動網路下也能建立連線。遇到單一網路失效時，應先保持設定不變，對比 Wi-Fi 與行動網路日誌，避免同時修改 DNS、模式與策略而無法判斷變數。

隨選連線與系統網路切換

隨選連線可依系統網路狀態自動啟動擴充功能，適合已驗證穩定的設定。啟用前先手動完成一次完整連線，並分別測試 Wi-Fi、行動網路與鎖定螢幕後恢復。若隨選規則設定不當，可能在可信任的區域網路中也自動接管，影響印表機、投放螢幕與家庭裝置存取。對區域網路有明確需求時，應保留私有位址直連規則，並檢查是否已授予本機網路權限。

iOS 在網路切換、低電量與系統資源緊張時，可能會重新建立網路擴充功能。短暫斷線後應先等待擴充功能重新協商，再查看應用程式日誌。若反覆卡在連線中，可以從系統設定中斷 VPN，返回客戶端重新啟動。不要同時保留多個處於隨選啟用狀態的 VPN 設定，否則系統的選擇行為會難以判斷。

DNS、QUIC 與應用程式差異

Safari、原生應用程式與第三方瀏覽器可能採用不同的連線策略。部分應用程式會優先嘗試 HTTP/3 或自訂解析，表現為瀏覽器可用但特定應用程式逾時。設定中的 DNS 模式、規則與 UDP 支援會共同影響結果。若關閉 UDP 後某個應用程式恢復，表示問題可能位於 UDP 轉送或 QUIC 路徑；這只是定位線索，不應長期以停用所有 UDP 取代修復。

fake-ip 模式會為網域回傳保留位址，再由核心還原網域並匹配規則。它通常能提高分流一致性，但區域網路探索、少數裝置控制應用程式與特殊網域可能需要加入過濾清單。redir-host 更接近真實 DNS 回傳，相容性思路不同。兩種模式沒有適用於所有網路的固定結論，應依設定規則、區域網路需求與日誌選擇。關於洩漏與 nameserver 的完整檢查，可參考DNS 檢測與設定說明。

耗電、背景與設定維護

網路擴充功能持續處理連線會消耗一定電量，規則數量、DNS 查詢、日誌層級與網路品質都會影響實際表現。日常使用不應長期保持 debug 日誌；詳細日誌適合短時間重現問題，完成排查後應恢復一般層級。若耗電量突然增加，先檢查是否出現連線重試、DNS 迴圈或多個自動測試組高頻執行，而不是只看 VPN 圖示存在的時間。

訂閱更新前可記錄目前策略組的選擇。部分設定更新會重建策略組，舊選擇可能因名稱變更而回到預設項目。更新後若突然無法存取，應依序確認設定是否啟用、策略組是否仍有選項、規則資源是否下載完成，以及擴充功能是否重新建立。刪除並重新安裝應用程式會同時清除本機覆寫與歷史日誌，應放在備份設定與基礎排查之後。

iOS 端不像桌面系統那樣能直接查看完整路由表與監聽程序，因此更依賴客戶端日誌與對照測試。建議一次只改變一個條件：先更換策略，再更換模式，最後檢查 DNS。若在同一步驟同時重建設定與切換網路，即使最後恢復，也無法確認真正的故障來源。

六、Linux 桌面客戶端與核心服務部署

桌面環境的安裝選擇

Linux 桌面可從Linux 下載區選擇 Clash Verge Rev 或 FlClash。安裝前確認發行版、CPU 架構與套件格式。Debian、Ubuntu 及其衍生系統通常使用 deb，Fedora、RHEL 系列發行版常見 rpm。使用套件管理器安裝本機套件時，可以讓系統一併檢查相依性；直接解壓縮可執行檔則需要自行處理桌面入口、權限、自動啟動與更新。

不同桌面環境對系統代理的支援並不一致。GNOME、KDE 與輕量桌面寫入代理設定的位置不同，部分應用程式讀取環境變數，部分應用程式讀取桌面設定，還有些應用程式完全忽略兩者。因此圖形客戶端顯示「系統代理已開啟」後，仍要分別驗證瀏覽器、終端機與目標應用程式。Wayland 或 X11 通常不會直接決定代理能力，但會影響托盤圖示、授權視窗與桌面整合表現。

匯入設定並驗證監聽連接埠

圖形客戶端的訂閱匯入流程與其他桌面平台相同：新增 URL、更新、選取設定、選擇策略組，再開啟系統代理或 TUN。若使用核心，應將設定儲存在權限受控的目錄，並以命令列指定路徑啟動。啟動前可先執行設定測試，避免服務反覆重新啟動。不同 Mihomo 版本的參數應以目前程式的說明資訊為準，常見啟動形式如下。

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

ss -lntp | grep 7890
journalctl -u mihomo --no-pager -n 100

-t 用於檢查設定是否能夠解析，-f 指定單一設定檔，-d 指定工作目錄。工作目錄內可能包含快取、規則集與資料庫，執行使用者必須擁有所需的讀寫權限。不要為了消除權限錯誤，直接將整個目錄改成所有使用者皆可寫入。服務程序應使用專用低權限帳戶，只有在建立 TUN、修改路由或繫結受限資源時，才授予必要能力。

systemd 服務與自動啟動

伺服器或長期執行的桌面主機可使用 systemd 管理核心。服務應在基礎網路可用後啟動，並在異常退出時以合理間隔重試。更新設定前先執行語法檢查，再重新載入或重新啟動服務。以下範例假設二進位檔與設定目錄已依對應路徑準備完成，實際使用者名稱與路徑需要依本機環境調整。

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

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

儲存為服務單元後，先執行 systemctl daemon-reload，再啟動並檢查日誌。自動啟動應在手動執行穩定一次後再開啟。若服務一啟動就反覆失敗，先停止自動重試，直接執行設定測試；持續重新啟動會快速塞滿日誌，也可能反覆修改路由。升級服務時應保留舊二進位檔與設定備份，以便發生相容性問題時回復。

環境變數、桌面代理與 TUN

終端機工具可使用 http_proxy、https_proxy 與 all_proxy。變數名稱同時存在大小寫形式時，不同工具的讀取規則可能不同。伺服器上的 systemd 服務不會自動繼承使用者 shell 設定，需要在服務單元或專用環境檔案中明確設定。對於只需代理單一命令的情況，建議將變數限定在命令前，避免影響整套系統。

http_proxy=http://127.0.0.1:7890 \
https_proxy=http://127.0.0.1:7890 \
curl -I https://example.com

all_proxy=socks5://127.0.0.1:7890 git fetch

Linux TUN 部署涉及虛擬介面、策略路由、DNS 與防火牆規則。核心需要存取 /dev/net/tun，並取得建立介面與修改網路設定所需的權限。在容器內執行時，還要明確傳入 TUN 裝置與網路能力。不要在不理解目前 nftables、iptables 或策略路由的情況下，複製整套清空規則的命令，這可能中斷遠端連線。路由器與旁路由情境可繼續閱讀OpenWrt 部署概覽。

權限、DNS 與容器邊界

長期直接以 root 執行可以繞過部分權限問題，但會擴大設定指令碼、外部規則與管理介面帶來的風險。更合適的做法是使用專用帳戶，透過 capabilities 或服務管理授予最小權限。管理控制連接埠若只供本機使用，應繫結迴圈位址；確實需要區域網路存取時，應同時設定存取控制與主機防火牆，不要直接暴露到公網。

systemd-resolved、NetworkManager、dnsmasq 與 Clash DNS 可能爭用本機 DNS 連接埠，或彼此轉送請求。先釐清查詢路徑：應用程式將請求傳給誰、系統 stub 轉送給誰、Clash 監聽哪個位址、上游 nameserver 位於何處。發生連接埠衝突時，不要盲目停用系統解析服務，應調整監聽位址或轉送關係。容器內的 127.0.0.1 指向容器自身，不是主機；容器應用程式若要使用主機代理，需要明確的閘道位址與監聽範圍。

七、通用設定檔、DNS、規則與 TUN 參數

設定檔的基本結構

Clash 設定使用 YAML。縮排只能表示層級，不能任意混用定位字元。鍵名後的冒號需要保留正確空格，清單項目使用短橫線。設定通常包含監聽連接埠、執行模式、日誌層級、代理定義、策略組、規則提供者、DNS 與最終規則。訂閱產生的完整設定可能很長，但排查時應先確認頂層結構是否正確，再查看具體代理入口。

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

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

上例用於說明語法，不包含可用的代理定義。mixed-port 同時接受 HTTP 與 SOCKS 連線；allow-lan 決定是否允許其他裝置連線；bind-address 限制監聽位址；mode 決定規則、全域或直連行為；log-level 控制日誌詳細程度。只要連接埠未被占用即可，不必固定使用範例值。修改監聽連接埠後，所有外部代理設定都必須同步調整。

allow-lan 與監聽位址

僅在本機使用時，保持 allow-lan: false 並繫結迴圈位址會更清楚。需要讓同一區域網路內的其他裝置使用代理時，可以開啟區域網路存取，並確認客戶端實際監聽在區域網路介面。接著在其他裝置中填寫執行 Clash 裝置的區域網路 IP 與 mixed-port。主機防火牆需要放行對應連接埠，但不應對所有網路設定檔無條件開放。

允許區域網路連線不會自動將流量分享給其他裝置，也不會設定閘道。下游裝置必須手動設定 HTTP/SOCKS 代理，或由閘道完成透明轉送。行動裝置離開目前 Wi-Fi 後，原本的區域網路位址將無法到達，應清除手動代理。公共 Wi-Fi 中不建議開放監聽；若確實需要，至少限制來源網段，並確保控制介面沒有一併暴露。

規則匹配順序與策略組

規則依照由上到下的順序匹配，第一條命中後通常不會繼續。因此更具體的網域、程序與私有網路規則應放在寬泛規則之前，MATCH 通常位於末尾。DOMAIN 匹配完整網域，DOMAIN-SUFFIX 匹配網域後綴，DOMAIN-KEYWORD 依關鍵字匹配，IP-CIDR 匹配位址範圍。IP 規則可能觸發 DNS 解析，是否跳過解析取決於語法與核心支援。

策略組並不是代理入口本身，而是用於選擇、測試或回退多個策略的邏輯層。select 組由使用者手動選擇；url-test 依測試位址與間隔更新選擇；fallback 通常按可用性順序切換；load-balance 用於依設定策略分配連線。測試結果只反映測試目標與當時網路，不等同於所有網站都能存取。過短的測試間隔會增加連線與耗電，不應為了介面頻繁重新整理而持續探測。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 600

DNS 模式與查詢路徑

DNS 設定的目標不只是解析網域，還要讓解析結果與規則匹配、代理連線保持一致。fake-ip 模式會回傳保留位址，由核心記錄網域對應關係，並在連線階段還原網域，通常適合需要穩定網域分流的環境。redir-host 回傳真實解析結果，對部分區域網路與特殊應用程式更直觀，但分流路徑不同。選擇前應理解客戶端是否接管系統 DNS，以及未進入 Clash 的應用程式會向哪裡查詢。

nameserver 是一般上游，fallback 可提供另一組解析路徑，default-nameserver 通常用於解析 DoH 或 DoT 上游本身的網域。若上游填寫網域，而基礎解析又依賴同一個上游，可能形成啟動依賴迴圈。瀏覽器的安全 DNS 也可能繞過系統路徑。檢測 DNS 洩漏時，應同時檢查瀏覽器設定、系統解析器與 Clash 日誌，不能只看單一網頁結果。

TUN 參數與嚴格路由

TUN 模式的常見參數包括是否啟用、協定堆疊實作、自動路由、自動偵測介面與嚴格路由。不同平台與核心版本的支援範圍可能不同，客戶端介面也可能代為產生這些欄位。開啟自動路由後，核心會負責加入必要路由；自動偵測介面用於在 Wi-Fi、乙太網路或行動網路變更時識別出口；嚴格路由可減少流量繞過，但更容易暴露與虛擬機器、容器或區域網路路由的衝突。

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

首次啟用時應從保守設定開始，只開啟必要欄位，確認瀏覽器、終端機、區域網路與休眠恢復都正常後，再調整嚴格路由或 DNS 劫持。若系統已有企業 VPN、虛擬交換器、容器網橋或多條預設路由，應記錄啟用前後的路由差異。TUN 不是系統代理失效時的萬用替代方案，它解決的是流量接管範圍問題，不能修復無效訂閱、錯誤策略與遠端連線失敗。

八、設定更新、連線異常與恢復流程

按層級定位，不要同時修改多個變數

故障排除應依序確認基礎網路、客戶端程序、設定載入、監聽連接埠、流量接管、規則匹配、策略連線與 DNS。先切換至直連或完全退出客戶端，確認裝置本身能夠連線；再啟動客戶端但暫不接管系統流量，檢查核心是否正常執行；接著透過本機代理連接埠執行一次明確測試；最後才開啟系統代理或 TUN。這樣可以區分問題是在核心之前，還是在系統接管之後。

一次只改變一個條件。不要同時更新訂閱、切換客戶端、修改 DNS、開啟 TUN 與更換策略。多項操作同時進行後，即使恢復也無法確定原因。客戶端日誌應先使用 info 層級觀察，確實需要更多細節時再短暫切換至 debug。分享日誌前，清理訂閱 URL、驗證欄位、代理位址與裝置資訊。

訂閱更新失敗

訂閱更新失敗時，首先檢查 URL 是否完整、是否過期、複製時是否帶入空格，以及基礎網路能否存取對應位址。HTTP 狀態錯誤通常來自授權、頻率限制或服務端狀態；連線逾時可能是 DNS、目前代理鏈路或網路封鎖；下載成功但解析失敗，則更可能是回傳內容不是預期的 YAML 或轉換格式。不要把反覆切換系統代理開關當作唯一處理方式。

若舊設定仍可使用而新設定無法更新，可以先保留舊設定，使用瀏覽器或 curl 單獨請求訂閱位址並觀察回應類型。更新是經由目前代理還是直連，取決於客戶端實作；必要時可暫時切換接管方式進行對照。設定包含遠端規則集時，主訂閱成功後仍可能在規則資源下載階段失敗，應從日誌區分具體 URL 與資源類型。

啟動失敗與連接埠衝突

日誌出現 address already in use 時，表示監聽位址或連接埠已被占用。常見原因包括同一客戶端啟動兩個執行個體、舊核心未退出、其他代理軟體使用相同連接埠，或系統服務自動啟動了另一個執行個體。Windows 可使用 netstat 與工作管理員定位，macOS 與 Linux 可使用 lsof 或 ss。確認程序用途後再結束，不要只憑連接埠號直接終止未知的系統程序。

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

若決定修改 mixed-port，客戶端介面、系統代理、環境變數、瀏覽器手動代理與區域網路裝置都要改成新值。只修改 YAML 而客戶端實際使用覆寫設定時，連接埠可能在啟動後再次被替換。詳細分支請見連接埠 7890 被占用的定位方法。

已連線但網頁無法開啟

先檢查策略組是否選擇了實際策略，而不是空組或不可用的上層組。再觀察請求日誌是否出現以下情況：完全沒有日誌，表示流量未進入客戶端；有規則命中但連線失敗，表示問題位於策略或遠端；只有網域解析失敗，表示應優先檢查 DNS；瀏覽器回報憑證或協定錯誤，則應檢查系統時間、QUIC、憑證儲存區與中間網路。切換至全域模式只能協助判斷規則影響，不代表適合長期使用。

若只有部分網站異常，查看該網域命中了哪條規則以及最終策略。規則由上到下執行，前面的寬泛規則可能攔截後面的精確規則。若只有某個應用程式異常，檢查它是否忽略系統代理、是否被應用程式分流排除，以及是否使用 UDP 或自訂 DNS。此時 TUN 可用於驗證接管範圍，但仍需透過日誌確認請求是否真正進入。

DNS 異常與洩漏檢查

網域解析失敗而 IP 可存取，通常表示 DNS 路徑有問題。檢查系統 DNS 指向、Clash DNS 監聽連接埠、nameserver 可達性、瀏覽器安全 DNS 與 TUN 的 DNS 劫持設定。在 fake-ip 模式下看到保留位址不代表一定異常，關鍵是連線是否由核心接管並還原至原始網域。若應用程式繞過 Clash 直接存取 fake-ip 位址，便會失敗，需要調整接管範圍或過濾規則。

檢測 DNS 洩漏不能只依賴一次網頁測試。應比較啟用前後的解析伺服器，查看客戶端日誌中是否出現目標查詢，並使用命令列工具指定系統預設解析器進行測試。企業網路、行動網路與瀏覽器本身的加密 DNS 都可能產生額外路徑。完整操作可參考DNS 洩漏檢測與 fake-ip 設定實作。

TUN 開啟後區域網路或虛擬機器失效

TUN 會改變路由優先順序，嚴格路由與 DNS 劫持還會擴大影響範圍。區域網路失效時，先確認私有位址直連規則，再查看路由表中目標網段由哪個介面承載。虛擬機器、Docker、WSL 與容器平台通常會建立自己的私有網段，若與實體區域網路或代理保留位址重疊，就可能發生衝突。不要只新增單一裝置 IP 作為長期補丁，應辨識完整網段與實際出口。

關閉 strict-route 或暫停 DNS 劫持可以作為定位手段，但應記錄是哪項變更讓連線恢復。若只在休眠、網路切換或 VPN 重新連線後出現，可能是自動偵測介面未重新整理。重新啟動核心或重新建立 TUN，通常比重新啟動整台裝置更有針對性。Linux 伺服器還應檢查 nftables、策略路由與反向路徑過濾；Windows 與 macOS 則檢查其他 VPN 與安全客戶端。

建立可回復的維護習慣

更新客戶端或大幅修改設定前，保留目前可用的設定、覆寫檔案與重要設定記錄。不要將包含敏感訂閱的檔案備份到公開位置。修改後分別驗證設定解析、核心啟動、單一連接埠代理、系統代理或 TUN、DNS、區域網路與休眠恢復。任何一步失敗，都應回到最近一個明確可用的狀態，而不是繼續疊加修改。

若要快速完成初次設定，可回到Clash 快速上手教學；需要重新選擇客戶端，可查看客戶端橫向評測；策略組、設定檔、fake-ip、mixed-port 等術語可在術語表中單獨查閱。建立「下載來源明確、分層保存設定、一次只改一項、依層級判斷日誌」的流程，比記住某個客戶端介面的固定位置更可靠。