外观
Wi-Fi 与移动数据切换时的断连问题
手机在 Wi-Fi 与移动数据之间切换时断连，根本原因是本地 IP 与出口路径改变，代理客户端与节点之间原本绑定在旧网络上的连接必须作废并重建，重建完成之前流量会短暂中断。这属于网络层的通用现象，并不能直接证明某个机场线路有问题。
是否能快速恢复，取决于客户端检测网络变化的速度、协议的重连方式、系统对后台进程的管理，以及当时哪些应用正持有长连接。本文按"现象、机制、对照、排查、取舍"的顺序拆解，不给任何速度或时延数值，品牌信息均为 Vendor Data，实测为 Not Tested。
核心结论与适用条件
- 如果断连只发生在切换瞬间，几秒内自动恢复，那么这是连接重建的正常代价，不必更换节点或服务，先观察是否每次都能自愈。
- 如果切换后 VPN 标识仍在，但境外应用一直打不开，直到手动关闭再打开代理才恢复，那么更像是客户端没有感知到底层网络变化，仍在使用已失效的连接，应优先检查客户端的网络变化处理与重连相关选项。
- 如果切换后 VPN 标识消失，那么问题多半是系统结束了客户端进程，而不是线路问题，应回到耗电与后台保活一文处理电池与自启动设置。
- 如果只有视频通话、直播、在线游戏这类基于 UDP 或实时会话的应用在切换后中断，而网页浏览很快恢复，那么这是应用层会话无法迁移所致，代理客户端无法替应用保住会话。
- 如果你在家里经常需要手机在 Wi-Fi 与蜂窝之间来回跳，例如在门口、电梯、地下车库，那么可以考虑让家里设备尽量由网关层统一接管，减少手机侧切换的次数，见后文路由器一节。
- 如果你准备更换客户端来解决问题，先确认是不是同一网络环境下复现，因为不同客户端的差异主要体现在重连策略，而不是接管能力。
这些结论的前提是：客户端从官方渠道获取、系统与客户端均为当前可用状态、订阅有效。手机与平板的整体方案请先看移动与路由器专题。
先分清三种"断连"
用户口中的"断了"其实包含三种不同的现象，处理方式差别很大，混在一起排查会走弯路。
第一种是瞬时中断。切换发生后，正在进行的请求失败或卡住，几秒后新请求恢复正常。这是最常见的情形，对应的是旧连接作废、新连接尚未建立的空窗期。网页刷新一下就好，视频可能需要重新缓冲。
第二种是假在线。系统状态栏仍显示 VPN 标识，客户端界面也显示已连接，但所有境外流量没有响应。这通常意味着客户端内部仍持有旧网络下建立的连接，而对端早已无法通过旧路径到达，客户端又没有及时发现。这种情形不会自愈，往往需要手动切换节点或重启代理。
第三种是进程被回收。切换前后客户端被系统结束，VPN 接口消失，手机直接回到未代理状态。此时国内应用不受影响，境外应用报错，用户容易误以为是节点被封。它本质上是后台管理问题，与网络切换只是时间上的巧合，但网络切换常常触发系统的省电与资源调度，使这类问题在切换后更容易出现。
把三种现象区分开，第一步观察三个信号：状态栏的 VPN 标识是否还在；客户端界面是否仍显示连接中；刷新页面是否在几秒内恢复。三个信号的组合基本能定位问题所在层次。
切换时到底发生了什么
本地地址与出口路径改变
手机连接 Wi-Fi 时，本地地址由路由器分配，出口是家庭宽带；切到移动数据后，本地地址由运营商网络分配，出口是蜂窝网络。两个网络的本地地址、网关、DNS 服务器、公网出口地址通常都不同。一条 TCP 连接由本地地址、本地端口、对端地址、对端端口等要素共同标识，本地地址变了，这条连接在网络层面就已经不是原来那条，对端不会再接受来自新地址的旧连接报文。
隧道是一条建立在底层网络之上的连接
代理客户端与节点之间的隧道，本身也是一条或多条普通的 TCP、UDP 连接。手机上所有应用的流量先进入系统的虚拟网卡，被客户端接管后封装进这条隧道，再通过底层网络发给节点。底层网络一换，隧道的底层连接随之失效，客户端必须重新向节点发起连接、重新完成握手，隧道才能恢复。握手本身需要若干个往返，这就是空窗期的来源。
应用侧的连接同样要重建
隧道恢复之后，应用自己的连接也大多要重来。应用与目标服务之间的 TCP 连接是通过隧道转发的，隧道断过一次，这些端到端连接要么在应用层超时后重试，要么被客户端主动重置。不同应用的重试策略差异很大：浏览器遇到失败通常会换新连接重试，即时通讯应用会在后台悄悄重连，而视频通话、直播推流这类应用的会话状态绑定在连接上，常常需要用户重新进入。
系统会同时存在两个网络吗
现代手机系统在 Wi-Fi 信号变差时，可能保持蜂窝连接待命，或者在两个网络间自动选择更优的一个。系统层面的切换策略因品牌与系统版本而异，有的会在 Wi-Fi 无法访问互联网时自动转向移动数据，有的需要用户手动开启相关选项。这类策略会让切换发生的时机变得难以预期：你并没有主动操作，系统却在后台换了网络。因此遇到"莫名其妙断了一下"，先考虑系统是否自动切换过网络，本文不列举具体选项名称，请在系统网络设置中查找与 Wi-Fi 质量、蜂窝辅助相关的开关。
技术参数对比大表
下表按"现象类型"对照切换断连的机理、典型表现和处理方向。表中不含任何速度或时延数值，数据来源均为通用技术资料，实测数据为 Not Tested。
| 指标 | 瞬时中断 | 假在线 | 进程被回收 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 根本原因 | 旧连接作废，新连接建立中 | 客户端未感知底层网络变化 | 系统结束了后台进程 | — | 机制归纳 | 通用技术资料 | 2026-10-18 |
| VPN 标识 | 保持 | 保持 | 消失 | — | 状态栏观察 | 通用技术资料 | 2026-10-18 |
| 客户端界面状态 | 已连接 | 已连接 | 未连接或已退出 | — | 界面观察 | 通用技术资料 | 2026-10-18 |
| 能否自愈 | 通常能 | 通常不能 | 不能，需重新启动 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 国内应用是否受影响 | 短暂受影响 | 通常不受影响 | 不受影响 | — | 现象归纳 | 通用技术资料 | 2026-10-18 |
| 优先排查方向 | 观察是否每次自愈 | 重连与网络变化相关选项 | 电池优化与自启动 | — | 处理顺序 | 通用技术资料 | 2026-10-18 |
| 与线路质量的关系 | 弱相关 | 弱相关 | 无关 | — | 因果判断 | 通用技术资料 | 2026-10-18 |
| 与协议的关系 | 重连方式有差异 | 保活探测方式有差异 | 无关 | — | 机制归纳 | 通用技术资料 | 2026-10-18 |
| 实测数据 | Not Tested | Not Tested | Not Tested | — | 本站测试状态 | 本站 | 2026-10-18 |
读这张表时要注意一点：三类现象的"能否自愈"是经验性归纳，不同客户端、不同系统版本的表现会有出入，所以排查时以自己手机上的实际观察为准。
Decision Path
切换网络后断连的排查路径
text
切换 Wi-Fi 与移动数据后境外应用打不开？
├─ 状态栏 VPN 标识还在吗？
│ ├─ 不在 → 进程被回收
│ │ ├─ 检查电池优化白名单与自启动
│ │ ├─ 检查系统是否有"始终开启 VPN"类选项
│ │ └─ 参见耗电与后台保活一文
│ └─ 在 → 继续
├─ 等待数秒后刷新，能恢复吗？
│ ├─ 能 → 瞬时中断，属于正常重建
│ │ └─ 若每次都要等较久 → 检查客户端重连与网络变化相关选项
│ └─ 不能 → 假在线
│ ├─ 手动切换一次节点或关闭再打开代理
│ ├─ 能恢复 → 客户端未感知网络变化
│ │ └─ 查找客户端中与网络变化、连接重置相关的选项
│ └─ 不能恢复 → 继续
├─ 不走代理时国内网站能打开吗？
│ ├─ 不能 → 新网络本身有问题，与代理无关
│ └─ 能 → 检查 DNS 与节点域名解析
└─ 仅实时通话、直播、游戏中断？
└─ 应用层会话无法迁移，需在应用内重新进入知识图谱：网络切换与代理连接重建
实体定义
网络切换在本文中指手机的默认网络接口在 Wi-Fi 与蜂窝之间发生变化。代理隧道指客户端与节点之间承载全部转发流量的连接。连接重建指客户端发现底层网络变化后，放弃旧连接、重新握手建立新连接的过程。
相关概念
- 虚拟网卡：系统 VPN 接口创建的网卡，应用流量先进入它，再由客户端处理，切换网络时这块虚拟网卡本身不消失，变化的是它背后的出站路径。
- 长连接与保活：客户端与节点之间通过周期性探测确认连接仍然可用，探测间隔与超时判定决定了客户端多久才能发现"假在线"。
- 多路复用：部分协议把多个应用请求放进同一条隧道连接，好处是减少握手，代价是这条连接一旦失效，其上所有请求同时受影响。
技术参数
本文涉及的参数都是定性的：重连触发条件、探测间隔的存在与否、是否检测网络变化事件、是否在变化后主动重置连接。不提供任何时间数值，因为这些数值在不同客户端和不同版本之间不同，且容易过时。
对比依据
判断一个客户端对切换的处理是否友好，只看三件事：能否在网络变化事件发生后主动重连而不是被动等待超时；重连时是否重新解析节点域名；重连后是否主动重置旧的端到端连接让应用重试。
常见问题指向
本页后文 FAQ 覆盖：为什么只有部分应用中断、要不要关闭 Wi-Fi 助理类功能、协议是否影响重连、路由器能否减少切换影响，以及怎样判断是不是线路问题。
协议与传输方式如何影响重连
TCP 承载的隧道
基于 TCP 的隧道在底层网络变化后，旧连接会因为对端不再收到有效报文而逐渐超时。超时判定需要时间，客户端如果只依赖 TCP 自身的超时，发现问题会很慢，这就是"假在线"的典型来源。因此客户端通常会叠加应用层的心跳或探测，由客户端自己判断隧道是否仍然通畅。
基于 UDP 或 QUIC 的隧道
基于 UDP 的隧道没有连接状态，单个数据包发出后若没有响应，客户端同样要靠应用层的探测来判断。部分基于 QUIC 的方案支持连接迁移，理论上可以在本地地址变化后继续使用原有会话，但这要求两端都实现该能力，并且路径上的网络设备没有因地址变化而丢弃报文。实际体验因实现而异，本文不对任何协议的切换表现作断言。
VLESS、REALITY 与多路复用
本站资料中不少品牌标注了 VLESS 协议。VLESS 本身是一个轻量的传输协议，是否使用 REALITY、是否开启多路复用，取决于节点端和客户端的具体配置。多路复用把多个请求放进一条底层连接，切换网络时这一条连接失效意味着所有请求同时失败，恢复时也同时重来；不使用多路复用则每个请求各自建立连接，单个失败影响小，但握手次数更多。两种取舍没有绝对优劣，取决于使用习惯。
客户端层面可以关注的设置方向
不同客户端的设置名称和位置差异很大，而且更新后会变化，所以下面只写"应该去找什么类型的选项"，不写具体菜单路径或默认值。
网络变化的响应
在客户端设置中查找与"网络变化""连接重置""断开重连"相关的选项。有的客户端提供在检测到网络变化后自动断开旧连接的开关，开启后可以减少假在线。具体是否存在、叫什么名字，以所用客户端的说明为准。
节点自动选择与故障转移
如果订阅中有多个节点，策略组可以设置自动测试与故障转移。网络切换后，原本最优的节点未必仍然最优，自动选择组会在下一次探测时重新挑选。这里要注意探测间隔与容忍机制：探测太频繁会增加额外流量与耗电，太稀疏则恢复慢。具体数值本站不给，建议读者在自己的使用环境里小步调整并观察。备用节点的组织方式可参考故障转移分组一文。
DNS 相关设置
切换网络后，系统分配的 DNS 服务器会变化。如果客户端使用了自己的 DNS 处理方式，例如加密 DNS 或 fake-ip 模式，需要确认它在网络变化后仍然使用正确的上游，而不是缓存了旧网络下的结果。路由器侧的 DNS 取舍可参考路由器 DNS 与分流。
不同应用在切换时的反应
代理客户端只能保住隧道，应用自己的会话能否延续，取决于应用的设计。下表按应用类型整理，同样不含数值，"重试能力"是定性判断。
| 应用类型 | 连接特点 | 切换时典型表现 | 用户可做的事 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|
| 网页浏览 | 短连接为主，失败即重试 | 加载中断，刷新即恢复 | 刷新页面 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 即时通讯 | 长连接加后台重连 | 短暂显示连接中后自动恢复 | 等待片刻 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 点播视频 | 分片请求加缓冲 | 缓冲区够用则无感，不够则转圈 | 等待或暂停后继续 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 直播与实时通话 | 绑定会话，常基于 UDP | 画面中断，常需重新进入 | 退出并重新进入 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 大文件下载 | 长连接，支持断点续传时可恢复 | 下载中止，是否续传取决于应用 | 手动重试 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| AI 对话类应用 | 流式响应，长时间保持连接 | 回复中途截断，需重新发送 | 重新生成回复 | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 在线游戏 | 实时会话，对抖动敏感 | 掉线，需重新匹配或重连 | 重新进入游戏 | 经验归纳 | 通用技术资料 | 2026-10-18 |
流式响应为什么特别容易被切换打断
AI 对话类应用的回复通常通过一条持续的连接逐段返回内容。这条连接在切换时失效，回复就会在中途停止，页面上可能显示出错或一直转圈。这与线路好坏没有直接关系，只是长时间持有同一条连接，被切换命中的概率更高。遇到这种情况，刷新或重新生成即可。关于 AI 场景下的连接与延迟，可参考AI 工具使用中的延迟问题。品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准。
网络切换导致的出口变化
切换网络同时意味着公网出口变了。对于依赖 IP 与地区判断的服务，出口变化可能触发重新验证、账号风控提示或内容地区变化。这类现象与代理是否断连是两件事：即使代理一直在线，底层网络变化后，节点看到的来源地址也会不同，但目标服务看到的仍是节点的出口地址。需要强调的是，具体服务如何响应，随 IP、地区和平台策略变化，本站不作任何断言。账号与出口一致性的问题可参考AI 账号与网络环境一致性。
一套可操作的排查流程
排查的原则是一次只改变一个变量，并且记录每一步的现象。
第一步：确认是否可复现
在可控环境下主动切换一次：先在 Wi-Fi 下确认境外应用可用，然后关闭 Wi-Fi 让手机转向移动数据，观察多久恢复，再反向再试一次。如果只是偶发一次，可能是网络本身的抖动，不必处理；如果每次都复现，才值得深入。
第二步：区分三类现象
用前文三个信号判断属于瞬时中断、假在线还是进程被回收。这一步决定后面的方向，不要跳过。
第三步：查看客户端日志
大部分客户端提供连接日志或实时日志。切换发生后留意日志中是否出现重新连接、握手失败、域名解析失败、超时等字样。日志的作用不是读懂每一行，而是确认客户端在切换后做了什么：是否主动重连，是否在反复失败。如果日志在切换后很久都没有新条目，说明客户端没有感知变化。
第四步：排除省电与后台限制
打开系统的电池设置，确认客户端没有被限制后台活动。有些系统在网络切换、息屏时会收紧后台进程，客户端被冻结后就不再处理网络变化事件。这一步与耗电与后台保活互补。
第五步：换节点与换网络对照
在同一网络下换一个节点，看问题是否消失；在同一节点下换一个网络，看问题是否消失。两次对照可以区分问题出在节点还是网络环境。如果换节点后好转，才有理由怀疑原节点；如果换网络后好转，则更可能是网络环境本身。
路由器与桌面：减少手机侧切换的影响
为什么路由器方案有帮助
在家里，手机通常固定连接家庭 Wi-Fi。如果代理在路由器上运行，手机本身不运行代理，就不存在"手机切到移动数据时隧道断裂"的问题：手机在 Wi-Fi 下，流量经路由器被统一接管；离开 Wi-Fi 后回到普通移动网络，此时若仍需要代理，则要靠手机客户端。也就是说，路由器方案消除的是家庭内部的切换问题，而不是出门后的问题。网关层的做法可参考 OpenClash 配置思路与旁路由方案。
两种方案并存时的注意点
如果手机既在路由器接管的 Wi-Fi 下，又自己开启了客户端，就会出现代理叠加：手机的流量先进入手机客户端的隧道，再经路由器的代理，等于走了两层。这会增加不必要的开销，也让排错变得复杂。在家时应关闭其中一层，出门时再开启手机客户端。这个习惯本身也是减少"切换断连"的办法：回家时关闭手机客户端，出门时重新开启，把切换边界变成一次主动的操作，而不是系统自动触发的意外。
方案关联：客户端与订阅的搭配
本文主题是通用的客户端行为，与具体品牌的关系较弱，所以这里写"方案关联"，不作品牌评价。可以引用的事实只有 brands.json 中的字段：品牌是否支持第三方客户端订阅导入，是否有自研客户端，协议是否包含 VLESS，以及套餐流量档位。切换断连的表现与这些字段没有可验证的因果关系，本站实测状态为 Not Tested。
| 关联项 | 与切换断连的关系 | 可核对来源 | 状态 |
|---|---|---|---|
| 订阅格式 | 决定能用哪类客户端，从而决定重连策略可选范围 | 各品牌官方说明 | Vendor Data |
| 协议类型 | 影响重连与握手方式，但无实测对比 | brands.json 协议字段 | Vendor Data |
| 节点数量与入口 | 影响故障转移时可选项，具体数量待核实 | brands.json 节点字段 | 待核实 |
| 设备数限制 | 手机与平板同时在线时需核对 | 品牌服务条款 | 待核实 |
| 实测切换表现 | 无公开口径 | — | Not Tested |
如果你想在品牌库里按协议或客户端支持方式筛选，可以进入品牌库查看各品牌的字段，或在横向对比页里做并列核对。下面的快照仅展示一个品牌的公开资料字段，不构成对其切换表现的评价。
Infrastructure Service Snapshot
灵猫网络 /lingmao
- 入门价格
- 19 元/月
- 价格类型
- 月付 月付价
- 入门流量
- 150GB
- 线路
- 企业级内网专线
- 协议
- 待核实
- 运营年份
- 2024
- 客户端
- 支持第三方客户端订阅导入
- 支付方式
- 支付宝 / 微信 / USDT
选型时如何把客户端兼容性放进清单，可参考选型方法专题，其中的清单思路适用于任何品牌。
优点、限制与风险提示
优点
- 理解切换机制后，可以避免把客户端问题误判成线路问题。
- 把"谁在重建连接"想清楚，有助于合理设置策略组与自动选择，减少无谓的手动操作。
限制
- 应用层会话无法由代理客户端保住，视频通话、直播、在线游戏在切换时中断是常态。
- 不同客户端、不同系统版本对网络变化的处理差异大，本文只能给出方向，不能保证某个设置一定有效。
风险提示
- 为了追求"不断线"而把探测间隔调得过于频繁，会增加额外流量与耗电，得不偿失。
- 同时启用"始终开启 VPN"与"阻止无 VPN 的连接"后，客户端异常会让手机完全断网，需要知道如何在系统设置中解除。
- 在不可信的公共 Wi-Fi 下切换网络时，仍应注意账号与隐私风险，代理不等于安全保证。
- 切换网络造成的出口变化，可能触发某些服务的二次验证或提示，应遵守相关服务条款，本文不涉及任何规避平台规则的做法；更多使用风险见风险专题。
常见问题
手机从 Wi-Fi 切换到移动数据时为什么会断连？
切换会让手机的本地 IP、网关和出口路径同时变化，客户端与节点之间建立在旧网络上的连接随之失效，必须重新握手建立新连接，重建完成之前流量会短暂中断。这是网络层的通用现象，通常不能直接说明线路有问题。
为什么状态栏还显示 VPN 标识，却打不开境外应用？
这种情形可以称为假在线，客户端仍持有旧网络下的连接，没有及时发现对端已经无法到达。它不会自愈，通常需要手动切换一次节点或关闭再打开代理，并在客户端设置中查找与网络变化、连接重置相关的选项。
切换网络后 VPN 标识消失了是怎么回事？
多半是系统在切换前后结束了客户端进程，属于后台管理问题而不是线路问题。应检查电池优化白名单、自启动权限，并考虑系统层面的始终开启 VPN 类选项，具体路径因手机厂商和系统而不同。
为什么网页很快恢复，视频通话和直播却要重新进入？
网页多为短连接，失败后浏览器会换新连接重试；视频通话和直播的会话状态绑定在具体连接上，常基于 UDP，连接失效后会话无法迁移，需要应用重新建立。代理客户端只能保住隧道，无法替应用保住会话。
不同代理协议在网络切换时表现一样吗？
不一样，但本站没有实测数据，不能给出优劣结论。差异主要来自传输方式是否有应用层心跳、是否使用多路复用、是否支持连接迁移，这些取决于节点端与客户端的具体实现，应以实际测试为准。
策略组的自动选择和故障转移对切换有帮助吗？
有一定帮助。网络切换后原来的最优节点未必仍然最优，自动选择组会在下一次探测时重新挑选。但探测间隔过短会增加额外流量与耗电，过长则恢复慢，具体取值本站不给，建议在自己的环境中小步调整。
切换网络后境外服务提示验证或地区变化，是代理的问题吗？
不一定。切换网络同时改变了公网出口，依赖 IP 与地区判断的服务可能触发重新验证。具体表现随 IP、地区和平台策略变化，品牌资料显示覆盖相关使用场景，具体可用性及节点表现建议以最新实际测试结果为准。
使用路由器方案能减少这类断连吗？
能减少家庭内部的问题。手机固定连接家庭 Wi-Fi 且代理运行在路由器上时，手机无需运行隧道，也就没有隧道随网络切换而断裂的情况。但离开家庭网络后仍需手机客户端，并且在家时应关闭手机端代理以避免叠加两层。
怎样判断断连是线路问题还是网络切换问题？
用对照法：在同一网络下换一个节点，看问题是否消失；在同一节点下换一个网络，看问题是否消失。换节点后好转才有理由怀疑原节点，换网络后好转则更可能是网络环境。同时查看客户端日志，确认切换后客户端是否主动重连。
是否需要为了避免断连而关闭系统的自动切换网络功能？
不必一概关闭。自动切换能在 Wi-Fi 质量差时保住上网，代价是切换时机不可预期。如果你经常在信号交替区域做对连接敏感的操作，可以在系统网络设置中查找相关开关自行取舍，具体名称和位置因系统不同而变化。
信息来源与更新日期
- 信息来源：通用网络与代理技术资料；品牌公开资料与用户提供清单；本站 brands.json 中的 Vendor Data 字段。本文未使用任何实测数据，测速与切换表现均为 Not Tested。
- 数据核实日期：2026-10-18
- 最近更新时间：2026-10-18
- 说明：本文不包含速度、延迟、耗电的具体数值，不列举软件版本号和菜单路径，客户端的实际选项以其官方说明为准。
下一步
Cluster · handheld
手机与平板
- Shadowrocket 导入订阅与规则设置如何在 Shadowrocket 中导入订阅并设置规则？
- Stash 在 iOS 上的配置与规则使用Stash 怎么配置订阅和规则？
- Android 上的 Clash 类客户端：FlClash 与 Clash Meta for AndroidAndroid 上有哪些 Clash 类客户端，怎么选？
- v2rayNG 使用指南与常见问题如何用 v2rayNG 导入订阅？
- iOS 客户端获取：App Store 地区与账号注意事项在 iOS 上获取代理客户端需要注意什么？
- 手机代理耗电与后台保活设置手机开代理为什么耗电，后台被杀怎么办？
- Wi-Fi 与移动数据切换时的断连问题手机在 Wi-Fi 和移动数据之间切换时为什么会断连？
读完本文后，可以按需要继续：若问题出在后台被结束，回到耗电与后台保活；若想了解 iOS 客户端的配置，看 Shadowrocket 使用说明；若家里有多台设备，看家庭共用订阅；若在意视频场景，看流媒体场景总览；整体方案回到客户端与配置总览，路由与分流的原理可对照路由专题。