故障排查 預計閱讀 12 分鐘

Clash 已連線但無法上網？依序完成這份八步故障排查清單

代理顯示已連線卻無法開啟網頁，通常與節點失效、DNS 污染、規則模式或系統時間有關。依固定順序逐項排查，比盲目重新安裝更快找出問題。

這類故障適合依網路鏈路由外到內排查：基礎網路、遠端節點、裝置時間、規則選擇、DNS、代理入口、TUN 接管，最後才處理設定檔與核心記錄。每一步只修改一個變數，修改後立即重新測試。若同時切換節點、修改 DNS 並啟用 TUN，很難確認真正的故障點。

第一步：關閉 Clash，確認基礎網路可用

先停止代理服務，不要只把模式從「規則」改成「直連」。Android 用戶端可進入主畫面關閉執行開關，並確認狀態列中的 VPN 標記消失。Windows 或 macOS 用戶端還要關閉「系統代理」，避免核心停止後，系統仍將請求傳送到本機連接埠。

  1. 關閉 Clash 或 mihomo 核心。
  2. 關閉系統代理與 TUN 模式。
  3. 中斷後重新連線目前的 Wi-Fi，或切換一次飛航模式。
  4. 開啟一個之前未造訪過的一般網頁，避免瀏覽器快取造成誤判。
  5. 分別測試 Wi-Fi 與行動數據，記錄哪一種網路發生故障。

如果關閉 Clash 後仍無法存取任何網頁，問題就在上游網路。常見情況包括 Wi-Fi 尚未完成入口網站驗證、路由器 DNS 異常、行動數據受到限制，以及目前網路只能連線區域網路。公共 Wi-Fi 可先開啟一般 HTTP 頁面以觸發驗證頁。只有直連網路恢復後，後續的代理排查才有意義。

第二步：切換節點，區分訂閱正常與節點可用

訂閱可以更新，不代表訂閱中的每個節點都能建立連線。訂閱下載通常只是一次 HTTPS 請求，但代理存取還涉及網域解析、TCP 或 UDP 交握、TLS 時間驗證、協定參數與遠端服務狀態。

先進行延遲測試，再測試實際存取

在「代理」或「Proxies」頁面找到目前的策略組，對至少三條不同線路執行延遲測試。測試網址通常由設定中的 url 決定，例如 https://www.gstatic.com/generate_204。結果可依以下方式理解：

  • 80–300 ms：節點至少完成了目前的測試請求，但不代表所有網站都能存取。
  • 超過 800 ms：線路壅塞、繞路或封包遺失明顯，實際存取可能頻繁逾時。
  • timeout：測試時間內未完成請求，請優先切換節點。
  • 0 ms、空白或立即失敗：可能是測試網址、DNS、權限或核心狀態異常。

不要只在同一個自動選擇組內反覆點選。應手動選擇兩個不同地區、伺服器名稱也不同的節點，再分別存取網頁。若一個節點可用、其他節點失敗，故障已可縮小到線路端，不需要重新安裝用戶端。若所有節點同時逾時，再繼續檢查裝置時間與 DNS。

確認策略組不是停在 DIRECT 或 REJECT

設定可能將主要選擇組命名為「節點選擇」「Proxy」或其他名稱。開啟該組，確認目前選項不是 DIRECT、REJECT 或已失效的下級策略組。自動策略組可能保留上一次的測試結果，手動切換後等待約 5–10 秒 再重新測試。

第三步：校準系統時間與時區

TLS 憑證驗證需要準確的系統時間。裝置日期偏差數小時或數天時，節點交握、訂閱更新和 HTTPS 網頁都可能失敗。記錄中常見的訊息包括 certificate has expired、not yet valid、TLS handshake failed。

Android 可進入「設定」→「系統」→「日期與時間」，開啟「自動設定時間」與「自動設定時區」。部分廠商系統的入口位於「設定」→「更多設定」→「日期與時間」。開啟後等待電信業者或網路時間同步，再完全停止並重新啟動 Clash。

桌面系統同樣需要檢查時間同步。Windows 可在「設定」→「時間與語言」→「日期與時間」中執行立即同步。時區應與目前位置一致，例如中國標準時間通常顯示為 UTC+08:00。手動將時鐘調到大致正確，不等於完成同步；幾分鐘的偏差也可能影響部分短期憑證或驗證請求。

第四步：切換代理模式，定位規則比對問題

Clash 常見模式包括 rule、global 和 direct。其中規則模式會依照設定檔中的 rules 由上到下比對，命中後交給指定策略組。規則順序錯誤、策略組名稱變更或末尾缺少規則，都可能造成特定網站無法存取。

使用全域模式進行短時間對照

  1. 記錄目前模式與已選節點。
  2. 將模式從「規則」切換為「全域」。
  3. 在全域策略組中手動選擇一個延遲正常的節點。
  4. 重新開啟目標網頁，不要只重新整理舊分頁。
  5. 測試完成後切回「規則」，避免長時間擴大代理範圍。

全域模式可以存取、規則模式卻無法存取，表示節點和基礎連線大致正常，問題位於規則或策略組。此時開啟「連線」記錄，查看目標網域對應的 Rule、Rule Payload 與 Chains。如果目標流量落到 DIRECT，請檢查網域規則是否被更前面的直連規則覆蓋。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

規則會由上到下執行，第一個命中的項目生效。末尾通常需要一條兜底規則，例如 MATCH,PROXY。實際策略組名稱必須與 proxy-groups 中的名稱完全一致，包括大小寫與空格。訂閱產生的設定不建議直接大幅改寫，可優先使用用戶端提供的覆寫功能，並保留原始訂閱作為備援。

第五步：排查 DNS 解析與 Fake-IP 對映

網頁提示找不到伺服器、節點測速全部失敗、IP 位址可以存取但網域無法存取時，應重點檢查 DNS。Clash Meta，也就是 mihomo 核心，常見增強模式為 fake-ip 或 redir-host。Fake-IP 會先向應用程式回傳對映位址，再由核心依據對映關係處理真實網域，因此必須確保 DNS 請求確實進入 Clash。

先清除快取，再重新啟動 DNS 鏈路

  • 停止 Clash，等待約 5 秒。
  • Android 切換一次飛航模式，或中斷後重新連線 Wi-Fi。
  • 清除瀏覽器的 DNS 快取，最直接的方式是完全結束瀏覽器程序後重新開啟。
  • 重新啟動 Clash，再存取一個之前未測試過的網域。

Android 的「私人 DNS」也可能改變解析路徑。可進入「設定」→「網路與網際網路」→「私人 DNS」，暫時改為「自動」進行對照。不同廠商的選單名稱可能是「連線與共用」→「私人 DNS」。如果指定的加密 DNS 主機在目前網路中無法連線，應用程式會長時間等待解析結果。

檢查設定中的 DNS 關鍵項目

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853

listen 連接埠必須未被其他程式佔用。上面的 1053 只是常見範例，實際設定可能不同。若記錄出現 address already in use，表示發生連接埠衝突。加密 DNS 位址還取決於網路是否允許對應連接埠，DoT 通常使用 853，DoH 通常使用 443。

第六步：核對系統代理位址、連接埠與監聽狀態

桌面端最常見的情況是 Clash 核心執行正常，但系統代理仍指向舊連接埠。典型混合連接埠為 7890，SOCKS 連接埠可能為 7891，不過訂閱與用戶端都可以修改這些值，不能只憑預設值判斷。

進入用戶端的「設定」→「參數設定」或「General」頁面，記錄 mixed-port、port 和 socks-port。再檢查作業系統代理是否指向 127.0.0.1 以及相同的連接埠。若用戶端只開啟 SOCKS 監聽，系統 HTTP 代理卻填入該連接埠，部分程式會直接連線失敗。

終端機可使用明確指定代理的請求，繞過系統代理設定，以驗證本機入口是否正常。以下指令假設混合連接埠為 7890：

curl -I --connect-timeout 10 \
  -x http://127.0.0.1:7890 \
  https://example.com

如果明確指定代理的請求成功，但瀏覽器失敗，問題多半位於系統代理或瀏覽器本身的設定。如果指令立即回傳「connection refused」，表示對應連接埠沒有監聽，應檢查核心是否啟動以及連接埠是否已變更。若請求停住並最終逾時，則本機連接埠可能正常，但節點、DNS 或對外連線仍有問題。

瀏覽器可用但終端機指令不可用，也不一定是 Clash 故障。許多命令列程式不會自動讀取作業系統代理，需要設定 HTTP_PROXY、HTTPS_PROXY，或在指令參數中明確指定代理。

第七步：檢查 TUN 模式、VPN 權限與應用程式衝突

Android 上的 Clash 通常透過系統 VpnService 建立本機 VPN 介面。連線請求獲得授權，只代表介面可以建立。若系統撤銷權限、省電策略結束背景服務，或另一個 VPN 應用程式佔用介面，介面可能短時間仍顯示執行中，但流量已無法正常轉送。

  1. 停止其他 VPN、網路過濾與防火牆應用程式。
  2. 在 Android 系統的 VPN 設定中中斷舊連線。
  3. 返回 Clash，重新啟動服務並確認系統連線請求。
  4. 先關閉 TUN，只使用用戶端預設的 VPN 接管方式進行測試。
  5. 桌面端則反向測試：系統代理可用後，再啟用 TUN 來接管不讀取代理設定的程式。

桌面 TUN 模式需要建立虛擬網路卡並調整路由。mihomo 常見參數包括 stack: mixed、auto-route: true 與 auto-detect-interface: true。如果裝置同時連線有線網路、Wi-Fi、虛擬機網路卡和企業 VPN，自動出口判斷可能選錯介面。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

排查時先關閉 TUN，使用系統代理驗證 HTTP 與 HTTPS 是否恢復。如果系統代理正常、開啟 TUN 後卻失敗，請重點查看路由建立、虛擬網路卡權限、目前預設閘道及其他 VPN 衝突。不要把「啟用 TUN」視為所有連線問題的通用修復方式；它解決的是流量接管範圍，不會修復失效節點或錯誤 DNS。

第八步：讀取記錄、回復設定並重新匯入訂閱

前七步都未能定位問題時，再檢查設定完整性與執行記錄。先將記錄層級設為 info，重現一次故障後立即查看最新記錄。只有在資訊不足時才短時間使用 debug，因為詳細記錄增長較快，也更難篩選關鍵錯誤。

記錄片段 優先檢查
i/o timeout 節點無法連線、封包遺失、對外連線遭阻擋
connection refused 目標連接埠未監聽，或遠端服務拒絕連線
no such host DNS 解析失敗、上游 DNS 無法連線
address already in use 本機代理連接埠或 DNS 連接埠衝突
authentication failed 節點憑證、UUID、密碼或訂閱內容已失效
certificate 相關錯誤 系統時間、憑證鏈或 TLS 參數

如果問題出現在某次訂閱更新之後，先切換到更新前仍可用的本機設定。多個設定共存時，確認目前啟用的 Profile 正是剛才檢查的那一份。接著重新取得訂閱，檢查更新時間與設定解析結果。解析失敗時不要繼續使用半載入狀態，應回復舊設定或聯絡訂閱提供者確認設定格式。

手動覆寫也是常見故障來源。重點檢查 dns、rules、proxy-groups、tun 與連接埠欄位。YAML 對縮排敏感，應使用空格維持層級一致。策略組引用不存在的節點名稱、規則指向不存在的策略組、同一連接埠被重複定義，都可能導致啟動失敗或部分功能失效。

最後的最小化恢復順序

  1. 匯出或記錄目前的設定名稱、連接埠與關鍵覆寫項目。
  2. 關閉 TUN、私人 DNS 和瀏覽器獨立 DNS。
  3. 匯入一份確認可以解析的訂閱設定。
  4. 選擇一個延遲正常的節點。
  5. 先使用全域模式測試，再切回規則模式。
  6. 基礎代理恢復後，逐項重新啟用 DNS 覆寫與 TUN。

重新測試標準：不要只看一次網頁重新整理

修復後至少執行三類測試。第一類是開啟兩個不同網域的 HTTPS 頁面；第二類是切換一次 Wi-Fi 與行動數據，確認網路變更後服務能夠重新建立；第三類是在「連線」記錄中檢查目標網域是否命中預期規則與節點。單次測速呈現綠色，只能表示測試網址當時可以存取。

Android 還應鎖定螢幕等待約 3–5 分鐘，再解鎖存取網頁。如果只有鎖定螢幕後才斷網，排查方向應轉向背景執行權限、電池最佳化與廠商省電策略，而不是繼續修改節點協定。桌面端可重新啟動瀏覽器或終端機，確認舊代理連線與 DNS 快取已釋放。

完整排查的目標不是讓狀態按鈕重新顯示已連線，而是確認一條可重複的鏈路：裝置取得基礎網路，DNS 能夠解析，流量進入正確的代理入口，規則選中預期策略組，節點完成對外連線，回傳資料再沿同一路徑交給應用程式。依這條鏈路逐層驗證，通常能在八步內將問題縮小到明確範圍。

用戶端與設定入口

取得適用於對應平台的用戶端，或繼續查看首次連線、匯入訂閱與執行模式設定。

前往下載頁 查看教學
下載Clash