一、現象對齊：整機斷網還是只有部分 App
開始改設定之前，請先用兩個維度描述問題，否則很容易把「DNS 偶發失敗」誤判成「節點全掛」。
第一個維度是影響範圍：瀏覽器與通訊軟體全部無法連線（像整機沒網路），還是只有特定 App在行動網路下異常？若僅少數 App，要懷疑該 App 是否不讀系統代理、是否需在 TUN／VPN 模式下才被核心接管，或是否被系統標記為「僅 Wi-Fi 下載／更新」。若幾乎所有 App 都異常，則優先檢查系統層 DNS、VPN 連線狀態與預設閘道是否被反覆改寫。
第二個維度是時間與切換關係：問題是否在「從 Wi-Fi 斷開、改成行動網路的當下或數十秒內」就出現？不少情況是客戶端核心或系統服務在介面變更後尚未完成重新綁定，表現為短暫逾時；若手動在 Clash 內停開再啟、或重新載入設定檔後恢復，就應把「網路切換後的重建流程」納入日常習慣，而不是一直換節點。
二、為什麼 Wi-Fi 與行動網路表現常不一致
Wi-Fi 與蜂巢式網路在作業系統裡通常是兩張不同介面，各自有路由優先順序、可能不同的 DNS 下發方式（路由器 DHCP 對電信商／自動帳戶伺服器），以及電信環境常見的 CGNAT、IPv6-only、雙堆疊差異。當你開啟 Clash 的系統代理時，只有會主動讀取系統代理的 App 才穩定受益；許多遊戲、視訊或通訊類 App 會採自有網路堆疊或長連線，此時往往需依賴 TUN（或 iOS 上綁定於 VPN 通道的實作）才能把流量導入核心。
另一方面，行動裝置為了省電，對背景網路、定位服務與 VPN 程序常有較嚴格限制；這些限制在接 Wi-Fi 時可能較寬鬆或行為不同，一旦切到行動網路，就可能出現「表面上看代理開著，實際上核心已被暫停或DNS 查詢被導到錯誤上游」的情況。也因此，僅在某一種網路下異常是行動場景的典型訊號，與 fake-ip 與 DNS 排查文 中提到的「換網路環境後恢復／失效」可以互相印證：先把解析與劫持從節點品質裡分離出來。
與「TUN 斷網」「WebRTC／IP 檢測」主題的邊界
本站另有多篇針對 TUN 全網斷流、fake-ip 下少數站異常、以及 WebRTC 與瀏覽器真實 IP 的專文；本文不重複那些協定細節，而是補上「網路介面從 Wi-Fi 換成行動數據」時最常卡住的系統權限與省電層面。若你確認問題只出現在 IP 檢測或特定瀏覽器行為，可改讀 WebRTC 與 DNS 逐步排查。
三、共通排查：切換網路前後先做這幾步
下列步驟不分平台，建議在改規則或換節點前先完成，能省下大量時間。
- 核對系統時間與時區：時間錯誤會導致 TLS 憑證驗證失敗，在電信網路下常被誤解成「節點掛了」。請在設定中確認自動設定時間開啟。
- 在客戶端內手動「更新訂閱」或重新整理遠端規則：行動網路若曾短暫無法連到訂閱主機，可能留下過期快取。本站 Android 訂閱匯入文 已說明連結校驗與快取觀念，桌面客戶端也可類比。
- 確認目前模式：你使用的是僅系統代理、還是已啟用 TUN／VPN？若只有瀏覽器正常、多數 App 在行動網路下仍直連，優先懷疑未進核心。
- 關閉或暫停其他會改寫路由的 App：其他 VPN、廣告封鎖 VPN、企業安全閘道若同時常駐，可能在切換介面時與 Clash 爭奪預設路由。
- 做一次對照：同一支手機、同一套設定，在 Wi-Fi 與行動網路各測一次；若僅行動網路失敗，把排查焦點放在私人 DNS、省電清單、背景資料與 VPN 權限。
| 你看到的現象 | 較可能優先檢查 |
|---|---|
| Wi-Fi 正常，一切換行動網路就連不上 | 私人 DNS、DNS over HTTPS 是否與 Clash 設定衝突；行動網路下 DNS 是否被電信／裝置改寫 |
| 瀏覽器可用，其他 App 不行 | 系統代理僅影響部分 App；需 TUN／VPN 或分 App 代理能力 |
| 一開始能連，螢幕關閉一會兒就不行 | 省電策略、背景資料限制、休眠中斷 VPN 連線 |
| 僅在戶外或特定基地台發生 | 行動網路干擾與 IPv6；必要時關閉實驗性網路堆疊做對照（以裝置實際選項為準） |
四、Android 逐步排查
以下順序由最常見到較進階排列；實際選單名稱可能因廠牌（三星、小米、Pixel 等）與 Android 版本略有差異，請以你的裝置為準。
1. 私人 DNS（Private DNS）
在 Android 上若設定為自動或指定某個主機名，可能與 Clash 內建的 DNS（含 fake-ip、DoH）形成雙重解析，在 Wi-Fi 下行為正常，換到行動網路後卻因上游差異而「看似斷網」。建議在排查時暫時改為關閉私人 DNS或僅使用供應商 DNS，僅讓核心作為單一真相來源，再觀察症狀是否消失。釐清 DNS 與 fake-ip-filter 的邊界時，可再對照 fake-ip 專文。
2. 省電與背景限制
開啟 設定 → 電池 → 應用程式電池管理（路徑依機型而異），將 Clash 客戶端設為不受限制或不最佳化，避免行動網路且螢幕關閉時核心程序被凍結。若系統提供「背景資料」開關，請確認 Clash 未被關閉背景傳輸。
3. 確認 VPN／連線權限與永違開啟狀態
在 Android 上，TUN 類通常透過系統 VPN 介面呈現；請在設定 → 網路 → VPN中確認 Clash 對應的連線仍為使用中。若你常在 Wi-Fi 與行動網路間切換，部分裝置會短暫中斷 VPN 工作階段，需在客戶端內重連或開啟「開機／網路變更時自動重連」類選項（名稱依客戶端而定）。
4. 以「僅限 Wi-Fi」或資料節省為線索
檢查系統與各 App 是否開啟僅在 Wi-Fi 更新、資料節省模式；少數機型在資料節省下會抑制非系統 VPN 的背景封包，表現為行動網路時斷時續。
5. 分流與通知日誌
最後再調規則與策略組：切換網路不應需要換一整套規則；若你認為「只有行動網路需要不同規則」，多半仍是 DNS 或模式問題。請在問題發生的瞬間查看 Clash 連線或通知日誌，確認是否有新連線紀錄，還是根本沒有流量進核心。
五、iOS 逐步排查
iOS 上的第三方代理／VPN 類 App 多透過系統的 VPN 與裝置管理描述檔 或 網路延伸（Network Extension） 運作，權限模型與 Android 不同；下列順序同樣由常見到較細。
1. VPN 連線是否真的「已連線」
打開 設定 → VPN 與裝置管理／一般 → VPN 與裝置管理（路徑隨版本微調），確認 Clash 所註冊的 VPN 設定已啟用且顯示已連線。若你在控制中心看到我方圖示，但系統 VPN 頁未維持連線，表示工作階段可能在切換網路時被系統收回，需要在客戶端重新連線或檢查是否開啟按需求連線類錯誤選項。
2. 低數據模式與背景 App 重新整理
在 設定 → 行動服務中檢查是否開啟低數據模式；開啟時系統可能更積極中斷背景連線，導致長連線類應用看起來「在行動網路特別不穩」。另可在 一般 → 背景 App 重新整理中確認 Clash 客戶端未被關閉（實際可選項仍受系統策略影響）。
3. 本機網路與行動數據權限（若客戶端會詢問）
部分版本在首次連線時會詢問本機網路或相關權限；若曾拒絕，可能導致區網或特定探測流程失敗。可在設定中向下捲到該 App，檢查是否需重新授權。
4. DNS 與描述檔：避免多重解析源頭
若你另外安裝過描述檔、第三方 DNS 或「防護類」設定，可能與 Clash 的 DNS 鏈路衝突。建議在排查期暫時停用非必要描述檔，讓單一路徑可解釋行為。與 fake-ip、DoH 相關的細節仍建議回到 fake-ip 與 DNS 排查 統一處理。
5. 與 Wi-Fi 輔助、網路選擇有關的錯覺
若開啟「Wi-Fi 輔助」或類似功能，在訊號邊緣可能頻繁在 Wi-Fi 與行動網路間跳動，代理連線會反覆重建；此時看到的現象像「只有行動網路不穩」，實際是介面切換過於頻繁。可在固定單一介面下做 A/B 以釐清。
六、分流、系統代理、TUN 與 DNS
當你已在 Android／iOS 完成權限層檢查，仍然遇到「特定網域在行動網路下特別容易失敗」，再回到設定檔本體：
- 規則與策略組是否仍期待「同一出口」涵蓋該服務的全部子網域與 CDN；若 Wi-Fi 下行動路徑較單純、行動網路卻多一條 IPv6 或不同解析，就需要核對 規則優先順序與 GEOIP／網域集是否覆蓋完整。
- DNS 區段中 nameserver、fallback 與 fake-ip 是否與你在行動網路下測到的實際解析路徑一致；這部分與 fake-ip-filter、fallback-filter 強相關，請勿在行動網路上「只靠換節點」掩蓋解析異常。
- 系統代理僅能約束會遵守系統代理的應用程式；需要全裝置一致行為時，應以客戶端支援為前提改採 TUN 或 iOS 上對應的 VPN 通道模式，並接受其對電池與延遲的取捨。
更完整的設定架構與術語說明可參考 本站文件，再以你實際使用的核心版本為準做微調。
七、進階：雙卡、IPv6 與電信環境
若裝置為雙卡雙待，預設數據卡切換時，底層 APN 與路由可能整組改變，VPN 連線有時需手動重連。部分電信環境在 IPv6-only 或 DS-Lite 下，若設定檔內對某一類位址假設不足，也可能只在行動網路暴露出問題——此時可先做控制實驗：暫時在行動網路下禁用 IPv6（若裝置提供）或反過來只在 IPv4 下測試，觀察是否與位址族有關。
企業或校園若透過行動裝置管理（MDM）下發描述檔，亦可能覆寫 DNS 或代理；此情況下需與管理單位協調，本文所列手機端開關可能被政策鎖死。
八、小結
Clash 僅在 Wi-Fi 能用、換成 4G／5G 就異常，多數不是神秘難解的問題，而是網路介面切換後，DNS、系統代理／TUN 權限與省電／背景限制沒有同時到位。先把現象收斂成「整機無網路」或「僅部分 App」，再用對照實驗鎖定是否與私人 DNS、VPN 連線狀態、資料節省相關，最後才回到規則分流與 DNS／fake-ip本體。
相比不斷更換訂閱或節點，把上述檢查做成固定清單，日後每次換機、升級系統或更換電信方案時都能省下大量試錯時間；若你也關心瀏覽器 IP 顯示與真實 IP 外洩議題，可延伸閱讀 WebRTC 與 DNS 外洩排查。
整體而言，Clash 生態在規則可組合性與多模式共存上相當靈活；先把行動網路下的系統層條件站穩，再調策略組與節點，體感會比「只換機房」穩定得多。若你希望從本站取得客戶端與一致的下載入口，可前往下載頁選擇適用 Android 或 iOS 的實作，再依本文順序驗證。