Clash 新手常見問題：訂閱匯入、模式選擇與連線檢查十問

如何選擇用戶端與核心

一、下載 Clash 時，應先看用戶端名稱還是系統版本？

先確認作業系統與處理器架構，再查看用戶端採用的核心。Clash 是代理設定與規則體系的常用統稱，實際使用時仍需要圖形化用戶端或命令列程式承載。Windows、macOS、Android、iOS 與 Linux 的安裝方式不同，同名安裝包也可能區分 x64、ARM64 等架構。

Windows 常見電腦通常使用 x64 安裝包，採用 ARM 處理器的裝置則需要 ARM64 版本。macOS 還要區分 Intel 與 Apple 晶片；選擇不相容的套件，可能導致無法安裝、啟動後立即退出，或必須經過額外的相容性轉換。無法判斷架構時，應先在系統資訊中查看「系統類型」或「晶片」，不要根據裝置上市年份猜測。

核心方面，仍在維護的用戶端通常採用 Mihomo，也就是由 Clash Meta 延續發展的核心。它相容於常見的 Clash 設定結構，並擴充代理協定、規則、DNS 與 TUN 能力。用戶端介面與核心並非同一層：介面負責訂閱管理、開關與日誌顯示，核心負責建立連線、執行規則與處理流量。因此，比較用戶端時應同時確認核心版本、更新狀態與設定相容範圍。

二、安裝完成後，為什麼還不能直接連上網路？

用戶端安裝完成只代表程式可以執行，不表示代理連線已經建立。至少還需要一份有效設定、一個可連線的節點，以及讓應用程式流量進入 Clash 的接入方式。最常見的完整流程是：匯入訂閱或本機設定、更新設定、選擇代理節點、開啟系統代理，然後使用瀏覽器進行測試。

如果介面中只有空白設定頁，或策略群組中沒有任何節點，用戶端就沒有可用的遠端出口。即使已選取節點，但系統代理未開啟，瀏覽器仍可能直接連線。部分應用程式還會忽略作業系統代理設定，此時一般系統代理無法接管其流量，需要在應用程式內個別填寫代理位址，或確認需求後啟用 TUN 模式。

如何判斷訂閱匯入與更新狀態

三、訂閱連結應貼到瀏覽器，還是匯入用戶端？

訂閱網址應新增至用戶端的設定、訂閱或 Profiles 頁面。在瀏覽器中開啟連結只能用來判斷伺服器是否回傳內容，不能取代用戶端匯入。不同服務回傳的內容可能是 YAML 設定、編碼後的節點清單，或需要經過伺服器轉換的專用格式；用戶端必須能辨識相應結構，才能產生節點與策略群組。

匯入時應複製完整網址，避免帶入前後空格、換行或通訊軟體附加的標點符號。訂閱連結通常帶有用於識別帳戶的參數，應視為敏感憑證處理，不要發布到公開頁面、截圖或日誌中。若服務提供專用的 Clash 或 Mihomo 訂閱入口，優先使用該入口，不要直接貼入其他用戶端格式。

匯入成功後應檢查三項結果：設定項目是否顯示更新時間、策略群組中是否有節點，以及日誌是否回報解析錯誤。只看到「下載成功」不足以證明設定可以載入；下載階段成功但 YAML 結構不相容時，核心仍可能拒絕啟用。

四、訂閱更新失敗，或更新後節點沒有變化，應先查什麼？

先區分「沒有取得內容」與「已取得內容但未生效」。前者常見表現為逾時、連線失敗或 HTTP 狀態異常；後者常見表現為設定解析錯誤、策略群組為空，或目前使用的設定仍是舊版本。可以依照以下順序檢查：

1. 確認裝置本身可以連線至訂閱伺服器，並檢查系統日期、時間與時區是否正確。
2. 重新複製完整訂閱網址，確認帳戶狀態與訂閱有效期限沒有變更。
3. 查看用戶端日誌，判斷錯誤發生在下載、解析還是設定切換階段。
4. 更新完成後確認新設定已設為目前使用的設定，而不只是儲存到清單中。
5. 檢查策略群組選擇。設定更新可能會重建節點清單，但策略群組仍保留原本的選擇，或恢復為預設項目。

自動更新週期由用戶端或設定中的訂閱提供者參數決定，並非所有用戶端都會在啟動時立即重新整理。手動更新時也不要連續快速點擊，因為並行請求可能觸發伺服器限制。更新後的節點名稱看起來相同，也不代表內容沒有變更；伺服器位址、連接埠與傳輸參數都可能在名稱不變的情況下更新。

若使用完整的遠端設定，更新可能會覆蓋本機直接編輯的規則。需要長期保留的自訂規則，應使用用戶端支援的覆寫、合併或腳本功能，並在修改前保留可還原的原始設定。不同用戶端對覆寫語法的實作並不完全相同，轉換用戶端時要重新驗證。

Rule、Global、Direct 與 TUN 的使用方式

五、Rule、Global 與 Direct 三種模式有什麼差別？

日常使用通常選擇 Rule，也就是規則模式。核心會由上而下檢查規則，命中後將連線交給指定策略群組、直接連線或拒絕處理。規則可以依據網域、網域後綴、IP 網段、程序等條件比對，具體能力取決於核心與用戶端。規則清單末端通常設有兜底項目，用來處理前面未命中的請求。

Global 是全域模式。進入 Clash 的連線會統一交給全域策略群組，但區域網路位址、核心保留連線等仍可能受到設定與實作限制，因此「全域」不應理解為繞過所有規則界線。它適合暫時判斷某個網站是否因規則分流錯誤而連線失敗，也適合短時間統一切換出口，不建議把它當成排查所有問題的唯一方法。

Direct 是直連模式。進入核心的連線通常不再交給遠端代理，而是由本地網路直接存取。它可用於快速確認故障是否與代理節點有關。若 Direct 也無法存取，問題更可能位於本地網路、DNS、目標服務或應用程式本身；若 Direct 正常而 Rule 異常，則應繼續檢查規則命中結果與策略群組。

六、什麼時候需要開啟 TUN 模式？

先使用系統代理，只有在應用程式不讀取系統代理、需要接管更多類型的流量，或需要統一處理多個程式時，才考慮 TUN。系統代理主要向遵循作業系統代理設定的應用程式提供 HTTP 或 SOCKS 接入；TUN 則透過虛擬網路介面接收 IP 流量，涵蓋範圍通常更廣，也會引入路由、DNS、權限與防火牆方面的額外變數。

開啟 TUN 前，應先確認一般節點測試可用，且 Rule 模式能正常處理瀏覽器連線。否則直接啟用 TUN，會把「節點故障」與「虛擬網卡故障」疊加在一起。Windows 上可能需要系統管理員權限或安裝服務，macOS 可能會跳出網路延伸功能授權，Linux 則涉及網路裝置權限與路由規則。未授予權限時，介面開關可能顯示已開啟，但實際介面並未成功建立。

TUN 與其他 VPN、虛擬機器網路、容器網路或安全軟體同時執行時，可能產生路由優先順序衝突。出現整個網路中斷、區域網路裝置無法連線，或關閉用戶端後仍然異常時，應先關閉 TUN、退出其他虛擬網路程式，再恢復系統網路測試。不要同時修改大量 DNS 與路由參數；每次只調整一項，才能判斷是哪一層影響結果。

節點、系統代理、DNS 與日誌排查

七、節點延遲顯示正常，為什麼網頁仍然打不開？

延遲測試只證明用戶端在特定測試方式下收到回應，不能完整代表目標網站的連線狀況。不同用戶端可能使用 TCP 握手、HTTP 請求或指定測試網址測量延遲。測試成功後，實際存取仍可能受到節點出口、目標網站、DNS 解析、規則分流與傳輸協定狀態影響。

先觀察存取時日誌中是否出現相應網域。如果完全沒有日誌，流量很可能沒有進入 Clash，應檢查系統代理、瀏覽器代理、TUN 狀態或應用程式本身的網路設定。如果日誌中出現網域但被分配到意外的策略群組，問題就在規則或策略選擇。如果日誌顯示逾時、握手失敗或連線遭拒，則應切換同一策略群組中的其他節點，確認是否為單一節點故障。

延遲數值也不能直接等同於頻寬與穩定性。低延遲節點可能壅塞，高延遲節點也可能在持續傳輸時更穩定。選擇節點時應綜合考量連線成功率、連續存取表現與下載速度，而不是只選清單中數字最小的一項。

八、開啟系統代理後仍然沒有流量，應檢查哪些連接埠？

先確認用戶端設定中的代理監聽連接埠，與作業系統目前填寫的連接埠一致。常見設定會提供 HTTP 連接埠、SOCKS 連接埠，或同時接受兩類流量的 mixed-port。控制器連接埠用於用戶端介面與核心通訊，不是提供給瀏覽器使用的代理連接埠，不能混用。

例如，以下設定表示本機應用程式可以連線至 7890 混合連接埠；是否允許區域網路裝置接入，則由 allow-lan 與監聽位址共同決定：

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

僅在本機使用時，應維持收斂的監聽範圍，不需要為了排查而開放區域網路存取。若連接埠已被其他程式佔用，核心日誌通常會出現 bind、listen 或 address already in use 類型的錯誤。此時應退出佔用程式或更換連接埠，並同步更新系統代理設定。只修改 YAML 而沒有重新載入設定，也不會改變目前執行中的監聽連接埠。

瀏覽器擴充功能、開發人員工具與其他代理軟體可能覆寫系統設定。排查時應暫時停用額外的代理入口，只保留一種接入方式。否則瀏覽器可能連線到舊連接埠，或形成「瀏覽器代理指向另一個代理程式，再轉回 Clash」的迴圈。

九、哪些現象通常與 DNS 有關？

可以透過 IP 存取服務但網域失敗、部分網域持續解析到異常位址，或切換網路後舊結果仍被保留，通常需要檢查 DNS。Clash 設定可以讓核心處理 DNS，並依據規則搭配 fake-ip 或 redir-host 等模式運作；具體欄位與行為取決於核心版本。新手不應直接複製來源不明的大段 DNS 設定，因為監聽位址、上游類型與增強模式必須配合目前的接入方式。

排查時先查看日誌中的網域是否成功解析，再確認作業系統的 DNS 請求是否進入 Clash。系統代理主要處理應用程式建立的代理連線，不保證所有獨立 DNS 請求都會被接管；TUN 模式下還要檢查 DNS 劫持與虛擬位址路由。若關閉 Clash 後解析仍然異常，可以清除作業系統 DNS 快取、重新啟動網路連線，並確認路由器或本地網路提供的 DNS 是否正常。

使用 fake-ip 時，應用程式看到的是保留位址範圍中的虛擬結果，核心再將該位址對映回網域進行規則比對。這些虛擬位址不應被當成真實伺服器位址長期記錄。某些區域網路服務、遊戲或依賴特殊 DNS 行為的程式可能需要加入相容清單，但應根據日誌與實際故障逐項新增，不要一次排除大量網域。

十、完全無法連線時，最有效的檢查順序是什麼？

有效排查需要分層進行，而不是反覆重新安裝用戶端。建議從變數最少的狀態開始，將問題定位到設定、節點、流量接入、規則或系統網路中的某一層：

1. 確認本地網路：切換至 Direct 或暫時關閉代理，檢查一般網站是否可以直連。若基礎網路已中斷，先恢復 Wi-Fi、有線網路或行動網路。
2. 確認設定載入：查看目前使用的設定名稱與更新時間，檢查日誌中是否有 YAML 解析、欄位不支援或檔案讀取錯誤。
3. 確認節點連線：選擇目前策略群組中明確存在的節點，執行延遲測試，並在瀏覽網頁時觀察即時日誌。
4. 確認流量進入：開啟系統代理後，檢查作業系統代理位址與連接埠。完全沒有請求日誌時，優先處理接入問題。
5. 確認規則結果：使用 Rule 模式查看目標網域命中了哪條規則、交給哪個策略群組，再核對該群組目前的選項。
6. 對照 Global 與 Direct：Global 有助於判斷規則是否選錯出口，Direct 有助於判斷本地網路能否直接存取。
7. 最後檢查 TUN 與 DNS：只有基礎代理連線可用後，再啟用 TUN、DNS 增強功能與應用程式相容設定。

日誌層級使用 info 通常足以完成初步判斷。需要進一步定位時，可以暫時提高日誌詳細程度，但日誌可能包含存取網域、節點名稱、伺服器位址與本地網路資訊，分享前應刪除帳戶參數與敏感設定。排查結束後恢復一般日誌層級，避免長期產生大量記錄。

如果修改後出現新問題，回到最近一次可正常運作的設定，比繼續疊加設定更有效率。訂閱、覆寫規則、DNS 與 TUN 應分別驗證：先確認原始訂閱可以載入，再加入本地覆寫；先確認系統代理可用，再啟用 TUN。依照這個順序，絕大多數「匯入成功但無法連線」的問題都能定位到具體環節。