一、现象对齐：整机断网还是只有部分 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 的实作，再依本文顺序验证。