Clash 首次安裝設定：跨平台初始化與常見錯誤

安裝前檢查：系統、架構與用戶端核心

首次設定 Clash 時，第一步不是立即執行安裝包，而是確認作業系統、處理器架構與用戶端類型。檔案能下載完成，不代表適合目前的裝置。選錯架構時，常見情況包括安裝程式拒絕啟動、系統提示應用程式不相容，或程式開啟後立即關閉。

Windows 常見裝置使用 x64 架構，搭載 ARM 處理器的部分輕薄型筆電和平板則需要 ARM64 版本。macOS 需區分 Intel 與 Apple Silicon；M 系列晶片對應 Apple Silicon 或 arm64，較早期的 Intel Mac 則對應 x64。Linux 除了 x86_64 與 arm64，也要確認軟體包格式：Debian、Ubuntu 通常使用 deb，Fedora、Rocky Linux 等系統常見 rpm；AppImage 則必須由用戶端明確提供，並支援目前的架構。

用戶端名稱與代理核心也要分開理解。桌面用戶端負責設定管理、訂閱更新、系統代理開關與日誌顯示；核心則負責規則比對、連線轉送、DNS 與 TUN 等實際網路工作。目前不少持續維護的用戶端採用 mihomo 核心；mihomo 源自 Clash Meta 的後續演進，能相容常見的 Clash 設定，並擴充規則、協定與流量接管能力。只要訂閱服務與用戶端支援的設定格式相符，新手不必因名稱差異而頻繁更換核心。

下載檔案的快速選擇順序

1. 先選擇 Windows、macOS 或 Linux 對應的頁面。
2. 再依 x64、arm64 或 Apple Silicon 區分處理器架構。
3. Linux 使用者接著選擇系統可管理的軟體包格式。
4. 確認用戶端仍在維護，並閱讀版本說明中的最低系統需求。
5. 若舊用戶端已有設定，先匯出設定或記下訂閱網址，再執行遷移。

不建議只憑檔名中的「通用版」判斷相容性。有些通用安裝包只是同時封裝兩種 macOS 架構，有些則僅表示適用於多個系統版本。最終應以下載頁標示與用戶端發佈說明為準。

跨平台安裝：完成程式部署與首次啟動

各平台介面不同，但初始化目標一致：讓用戶端能夠儲存設定、啟動代理核心，並取得修改系統代理或建立虛擬網路介面所需的權限。首次啟動時，先不要同時開啟其他代理、VPN 或網路過濾工具，以免連接埠佔用與路由衝突影響判斷。

Windows：安裝目錄與權限提示

執行與架構相符的安裝程式，依照精靈完成安裝。一般桌面使用通常不需要將程式放入特殊目錄，也不應在未確認原因前長期以系統管理員身分執行。之後若啟用 TUN，用戶端可能會另行要求提升權限或安裝虛擬網路元件，此時應確認提示是否來自剛安裝的用戶端。

啟動後先確認核心狀態、設定頁與日誌頁是否能正常開啟。若視窗沒有出現，可查看工作列通知區域，因為部分用戶端預設會最小化至系統匣。重複點擊啟動圖示可能只會喚起既有程序，不會建立新的視窗。

macOS：應用程式目錄與系統授權

使用 dmg 安裝時，通常需要將應用程式拖曳至「應用程式」目錄，再從該目錄啟動。Intel 與 Apple Silicon 安裝包不能任意混用。首次開啟系統代理時，用戶端可能要求授權修改網路設定；開啟 TUN 或增強模式時，還可能出現網路延伸功能、輔助服務或管理者密碼提示。

如果系統阻止開啟應用程式，應先確認檔案來源與用戶端發佈資訊，再到 macOS 的「隱私權與安全性」設定查看相關記錄。不要將關閉系統安全機制當作一般安裝步驟。更新用戶端後若再次出現權限提示，應確認舊的輔助程序是否已經結束。

Linux：軟體包、桌面工作階段與代理環境

deb 或 rpm 軟體包可交由系統套件管理器安裝，以便登錄相依套件與解除安裝資訊。AppImage 通常需要先加入可執行權限才能執行，但具體步驟取決於用戶端的發佈方式。桌面環境中的「系統代理」可能只影響讀取 GNOME、KDE 或環境變數設定的應用程式，終端機程式與系統服務不一定會自動套用。

在 Linux 上啟用 TUN 通常涉及網路管理、路由表與裝置權限。首次設定時，應先使用一般系統代理完成訂閱與節點驗證，確認代理核心本身能夠連線，再處理 TUN 權限。如此可將「節點無法使用」與「虛擬介面設定失敗」拆分成兩個獨立問題。

匯入訂閱：從設定網址到可用的策略群組

Clash 用戶端通常支援訂閱網址、遠端設定檔與本機 YAML 檔案。對首次安裝的使用者而言，最常見的方式是貼上服務商提供的 Clash 訂閱網址。這個網址可能包含存取憑證，應視為帳號金鑰處理，不要發佈在截圖、公開日誌、程式碼儲存庫或聊天群組中。

進入用戶端的設定或 Profiles 頁面，找到「新增訂閱」、「從 URL 匯入」或意思相近的入口。貼上完整網址後儲存並執行更新。下載成功只代表用戶端取得了設定檔，接下來還要將該設定設為目前啟用項目。部分用戶端匯入後會自動啟用，其他用戶端則需要手動點擊設定名稱。

成功載入的設定通常會出現代理節點、策略群組、規則與 DNS 等內容。策略群組不是額外的節點，而是決定某類流量應使用哪個節點、自動選擇機制或直連動作的設定單元。例如「節點選擇」可能允許手動指定線路，「自動選擇」可能依延遲測試結果切換，「DIRECT」則表示直連。

匯入後依序檢查

1. 設定清單中顯示成功更新的時間，而不是持續轉圈或顯示錯誤狀態。
2. 代理頁面中有節點或策略群組，且群組內至少有可選項目。
3. 目前設定已被選取，核心日誌沒有持續回報解析失敗。
4. 在規則模式下，主要策略群組已選擇節點或有效的自動策略。
5. 訂閱自動更新間隔合理，避免短時間內反覆請求遠端網址。

本機 YAML 匯入更適合已有設定檔，或需要手動維護規則的使用者。YAML 對縮排與字元格式敏感，Tab、全形標點、重複欄位或層級錯誤都可能導致解析失敗。修改前保留原始檔案，每次只變更一小部分，並在用戶端重新載入後查看第一筆錯誤日誌。

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

以上片段只展示常見的基本欄位，不是一份完整設定。實際訂閱還需要代理節點、策略群組與規則等內容。連接埠也不固定為 7890，應以目前用戶端顯示的數值為準。如果用戶端會自動管理連接埠，不要為了套用範例而強行覆寫原有設定。

開啟代理：規則模式、系統代理與 TUN 的正確順序

匯入設定後，建議先選擇「規則」模式，再選定可用節點，最後開啟系統代理。規則模式會根據設定中的規則決定直連、代理或拒絕連線，適合日常使用。全域模式通常會讓大部分符合條件的流量經過所選代理，方便進行短時間對照測試，但不適合做為排查所有問題的唯一方法。直連模式則會繞過代理，可用來確認故障是否與代理鏈路有關。

系統代理是最容易驗證的入口。用戶端會將本機 HTTP、HTTPS 或 SOCKS 代理位址寫入作業系統設定，瀏覽器及遵循系統代理的桌面應用程式隨後會將連線交給 Clash。它不會自動接管每個程式：部分遊戲、命令列工具、系統服務與自行實作網路堆疊的軟體可能會忽略系統代理。

TUN 模式透過虛擬網路介面與路由接管更大範圍的流量，適合不讀取系統代理設定的應用程式，也能結合核心設定處理 UDP 與 DNS。它通常需要較高權限，並可能與其他 VPN、虛擬機器網路、線上遊戲加速器或安全軟體的網路驅動程式發生衝突。首次安裝時不應一開始就同時開啟系統代理、TUN 與多個網路工具，否則發生斷網時很難判斷是哪一層造成的。

什麼時候需要 TUN

• 目標程式明確不遵循作業系統的代理設定。
• 需要接管部分 UDP 流量，且節點、核心與設定都支援相應功能。
• 希望讓多種協定統一經過規則比對，而不是逐一設定代理位址。
• 已確認系統代理運作正常，需要進一步擴大應用程式涵蓋範圍。

如果只使用瀏覽器與常見桌面應用程式，系統代理通常更容易維護。TUN 不是「速度增強開關」，它改變的是流量進入核心的方式。線路品質、節點負載與目標網站仍然決定主要的連線表現。

基本驗證：逐層檢查節點、規則、DNS 與日誌

看到「已連線」不代表所有流量都依預期轉送。可靠的驗證方式應從核心狀態開始，再檢查節點延遲、瀏覽器請求、規則命中與 DNS 結果。一次只觀察一個變數，避免測試過程中連續切換節點、模式與設定。

第一層：核心與連接埠

確認用戶端狀態頁顯示核心正在執行，並查看 HTTP、SOCKS 或 Mixed 連接埠。若日誌出現「address already in use」或連接埠遭佔用的提示，表示相同連接埠可能正被另一個 Clash 程序、舊用戶端或其他代理程式使用。結束衝突程式後重新啟動核心，或在用戶端允許的範圍內更換監聽連接埠。

第二層：策略群組與節點

延遲測試只能表示測試位址當下能建立連線，不能完整代表下載速度或長期穩定性。先選擇一個能完成延遲測試的節點，再造訪平時可穩定開啟的網站。若自動策略群組反覆切換，可以暫時改用手動節點，排除策略變化造成的干擾。

第三層：規則命中

開啟連線記錄或即時日誌，觀察目標網域符合哪條規則，最終進入哪個策略群組。若目標被錯誤分配至 DIRECT，應檢查規則順序與目前設定；若進入代理群組但連線失敗，則繼續查看節點、DNS 或遠端回應。規則通常依設定順序比對，前方較廣泛的規則可能會覆蓋後方的具體規則。

第四層：DNS

網域無法開啟，但直接存取已知 IP 有回應時，可能涉及 DNS。檢查日誌中的解析逾時、上游無法連線或循環轉送提示。系統同時執行其他 DNS 修改工具時，應先保留一條明確的解析鏈路。在 TUN 模式下，還要確認用戶端要求的 DNS 設定已啟用，避免虛擬介面接管流量後，查詢仍被送往無法連線的位址。

驗證結束後，記下可正常運作的設定名稱、模式、節點與代理開關狀態。之後升級用戶端或切換訂閱時，可以這組狀態作為回復基準。

常見錯誤：依故障發生位置處理

訂閱下載失敗或顯示逾時

先確認訂閱網址完整，複製時沒有多出空格、換行或中文標點。接著檢查系統時間是否準確、一般網路能否連線至訂閱伺服器，以及服務商是否要求更新訂閱網址。如果舊用戶端可以更新而新用戶端失敗，可比較兩者的使用者代理需求、網路出口與訂閱格式支援情況。失敗時不要連續高頻率重新整理，遠端服務可能會限制請求頻率。

訂閱更新成功但看不到節點

設定可能尚未啟用，也可能只包含代理提供者引用，需要用戶端繼續載入 provider 內容。查看設定詳情與日誌，確認遠端提供者是否下載成功。若日誌回報不支援欄位或 YAML 解析錯誤，表示訂閱格式與目前核心不相容，應使用服務商提供的 Clash 或 mihomo 格式，而不是直接將其他用戶端格式改名後匯入。

開啟系統代理後瀏覽器無法連線

先檢查核心是否仍在執行，以及系統代理指向的連接埠是否與用戶端監聽連接埠一致。接著關閉系統代理，確認直連網路恢復，再重新啟動核心。若用戶端異常結束後系統仍保留舊代理位址，需要在作業系統網路設定中關閉手動代理。恢復後只啟動一個代理用戶端重新測試。

節點有延遲但網頁無法開啟

延遲測試位址與目標網站並非同一條連線。檢查即時日誌中的目標網域、規則比對、策略群組與錯誤類型。若表現為連線逾時，可切換同一訂閱中的其他節點進行比較；若只有特定網域失敗，應重點查看規則與 DNS；若所有節點同時失敗，則優先排查本機網路、訂閱狀態或服務端狀態，而不是逐一修改連接埠。

TUN 開啟失敗或開啟後無法上網

確認用戶端取得建立虛擬介面所需的權限，並結束其他 VPN、舊代理核心與可能修改路由的網路工具。Windows 可檢查是否殘留異常虛擬網路介面卡，macOS 可查看網路延伸功能授權，Linux 則需要確認 TUN 裝置、路由權限與網路管理服務。關閉 TUN 後若系統代理仍可運作，表示節點與訂閱大致正常，問題集中在權限、路由或 DNS 接管層。

區域網路裝置無法使用本機代理

預設的本機監聽通常只接受本機連線。確實需要為區域網路裝置提供代理時，用戶端必須啟用允許區域網路連線，並監聽其他裝置可存取的位址；作業系統防火牆也要允許對應連接埠。開放前應確認目前網路可信，並設定用戶端支援的存取控制。僅供本機使用時，保持區域網路存取關閉可減少不必要的暴露。

更新用戶端後原有設定失效

先判斷是設定未被遷移、核心路徑變更，還是新版本不再支援舊欄位。保留舊設定副本，查看升級後的第一筆解析錯誤，不要一次刪除所有設定。若訂閱可以重新取得，優先建立新設定並重新匯入，再手動恢復少量本機規則。跨用戶端遷移時，介面設定、覆寫規則與腳本通常不會僅靠訂閱自動帶入。

初始化完成後的維護清單

Clash 正常運作後，日常維護重點是保持設定來源清楚、減少重複的網路元件，並在發生變更時保留可供比較的狀態。用戶端升級、訂閱規則更新與作業系統網路重設，都可能改變原本的代理行為。

• 保留目前可用的用戶端版本、設定名稱與架構資訊。
• 依訂閱服務建議的頻率更新，不要進行無意義的連續重新整理。
• 切換網路後重新檢查節點延遲與 DNS，不要直接重新安裝程式。
• 只讓一個用戶端負責相同的系統代理連接埠與 TUN 路由。
• 結束用戶端前關閉系統代理；異常結束後檢查作業系統代理設定。
• 修改 YAML、覆寫規則或 DNS 設定前，先儲存原始設定。
• 排查問題時先查看日誌中的第一個錯誤，再處理後續的連鎖提示。

完整的首次安裝流程可歸納為：選對安裝包、確認核心啟動、匯入並啟用訂閱、選擇規則模式與節點，先用系統代理驗證，再依需求設定 TUN。依層次處理後，即使發生連線失敗，也能快速判斷問題位於安裝、設定、節點、規則、DNS 或流量接管環節。