同一份机场订阅，在电脑上稳定跑一整天，换到手机上却总在锁屏十几分钟后断掉——这是手机端最典型的抱怨，也是最容易被误判的一类问题。多数人第一反应是"机场跑路了""节点被封了"，然后开始换机场、换节点、重装 App，折腾一圈发现换了三家还是同样会断。原因很简单：手机上"息屏后掉线"绝大多数不是线路问题，而是系统省电机制、App 后台策略、隧道连接状态这三层里的一层被掐了。运营商和手机厂商为了续航，把后台网络管得越来越紧，而代理 App 恰恰是最依赖"后台常驻网络"的一类应用，两者天然冲突。
节点侧的因素当然也在，但它是放大器而不是主因：一份带多地区落地、客户端实现完整的订阅（例如走自家客户端的自由猫，节点覆盖 100+、线路以 IEPL 专线为主），会让系统层的排查变量少一个——线路本身就稳，剩下的就只剩系统层。这一篇不讲"哪个机场最好"，只做一件事：把手机端掉线的每一层机制摊开，给你能自己动手验证的判据、命令和配置步骤。
一、先分清手机上三种完全不同的"断"
把"掉线"当成一个现象去修，是排查效率最低的做法。它至少是三种不同的故障，成因、判据、修法都不一样。先看下表，对号入座再往下读，能省掉一半试错时间。
| 你看到的现象 | 关键判据 | 大概率是哪一层 |
|---|---|---|
| 状态栏的 VPN 钥匙图标/常驻通知消失，App 里显示"未连接" | 进程被系统回收，前台服务被停 | 系统省电层（进程被停） |
| 图标还在，但所有 App 都打不开网页，连 DNS 都超时 | 隧道进程活着，底层网络被切断 | 系统省电层（网络被限制） |
| 前台浏览正常，只有后台下载、推送、同步停了 | 隧道没断，是各 App 自己的后台策略 | App 后台层 |
| 图标在、页面转圈、几十秒后自己恢复 | 隧道离开了"已连接"状态，正在重连 | 隧道状态层（重连窗口） |
| 只有某个地区/某个节点连不上，换节点立刻正常 | 单点故障，不是系统问题 | 节点层 |
四层里，第一层和第二层占到实际案例的绝大多数，第三层和第四层常被误判成第一层。判断顺序建议是：先看图标在不在（区分"进程被停"和"网络被切"），再看换个网络是不是立刻好（区分"系统限制"和"隧道重连"），最后才去怀疑节点。
二、先做一次对照实验，把系统层和节点层分开
在动手改设置之前，花十分钟做一次对照，能确定后面该往哪儿使劲。下面五个观察点按顺序做，任何一个命中，都能直接把范围砍掉一半。
- 亮屏时稳定吗？亮屏浏览半小时完全正常、只有熄屏后才断——直接锁定系统省电层。因为 Doze 这类机制的前提就是"息屏 + 静止 + 未插电"，亮屏时根本不触发。
- 切一次网络会不会立刻恢复？熄屏后断了，点亮屏幕切一下 Wi-Fi/蜂窝马上好——这是隧道重连，不是节点挂，属于第四层。
- 换一台设备挂同一份订阅。手机上断、电脑上不断，说明订阅和节点没问题，问题在手机侧。
- 看代理 App 的系统流量统计。熄屏那段时间流量为 0、同时节点侧没有异常——系统把网络掐了，属于第一层或第二层。
- 换一份已知可用的订阅做对照。如果两份订阅表现完全一样，基本可以排除机场；如果只有某一份会断，那才轮到节点层。
第 5 条是很多人卡住的地方：手上只有一份订阅时，"是系统还是线路"永远分不开。最省事的做法是留一份低成本的入门档专门当对照样本——比如小流量就够用的瑶瑶领先（¥9.9/月 384GB、3 台设备），它的定位就是入门低门槛，不需要为了一次对照去买贵的套餐。这份订阅平时不用，只在排查时挂上去跑一天，就能把"系统层"和"节点层"彻底分开——省下来的时间远比这十块钱值钱。
三、Android 侧机制：Doze 与 App Standby 到底限制了什么
Android 从 6.0 起就有两个省电机制在管后台行为，它们对代理 App 的杀伤力远大于普通应用。先看官方对触发条件的定义：设备未插电、静止一段时间、且屏幕熄灭，系统就进入 Doze，此时会"推迟应用的 CPU 与网络活动"。注意这个组合条件——它解释了为什么你盯着手机测的时候永远测不出来。
3.1 Doze 生效时被掐掉的东西
官方给出的 Doze 限制清单里，与代理直接相关的有这么几条：挂起网络访问；忽略 wake lock（应用自己申请唤醒锁没用）；把普通 AlarmManager 定时推迟到维护窗口（包括 setExact/setWindow 这类精确闹钟）；不做 Wi-Fi 扫描；sync adapter 不运行；JobScheduler 不运行（WorkManager 内部用的就是它，所以一起被推迟）。
系统会周期性地短暂退出 Doze，开一个"维护窗口"让攒下来的同步、任务、闹钟跑完，然后再次进入。关键在于：随着设备静止时间变长，维护窗口的调度会越来越稀疏。也就是说，手机放在桌上不动两小时后，后台能拿到网络的机会比刚熄屏时少得多。设备一旦被移动、亮屏或插上充电器，系统立刻退出 Doze，所有应用恢复正常。这就是为什么"手机揣兜里走路时反而不掉"——移动会不断把设备拉出 Doze。
3.2 官方资源限制表：Doze 状态下还剩多少额度
Android 官方把"设备状态 × 资源类型"的额度列成了表，下面摘出与代理最相关的三行（数值均取自官方文档）：
| 设备状态 | 定时/作业 | 网络访问 | 云端消息 |
|---|---|---|---|
| 充电中 | 除"受限"分桶外无执行上限 | 无限制 | 无限制 |
| 屏幕亮着 | 按待机分桶执行 | 取决于分桶或进程状态 | 无限制 |
| 屏幕熄灭且 Doze 生效 | 常规闹钟推迟到维护窗口；"允许在 idle 下触发"的闹钟每小时最多 7 次 | Doze 期间被限制 | 高优先级不受限；普通优先级推迟到维护窗口 |
这张表藏着一个很重要的推论：代理 App 想"靠自己的定时任务维持存活"是行不通的——Doze 期间作业被推迟到维护窗口，靠唤醒锁也唤不动。官方推荐的解法是只把真正需要实时性的通知走高优先级推送，而不是让应用自己维持长连接。代理 App 显然不属于"推送"场景，所以它必须换一条路：把自己变成系统认可的前台服务，并让用户把它从这个机制里豁免出去。这就是下一节要做的配置。
3.3 App Standby：被判定"闲置"的 App 网络直接被关
比 Doze 更隐蔽的是 App Standby 与"待机分桶"（Android 9 引入）。系统会根据使用频率，把每个应用放进五个优先级桶之一，然后按桶限制它能用的资源。官方给出的桶与额度如下：
| 待机分桶 | 常规作业额度 | 闹钟 | 网络访问 |
|---|---|---|---|
| Active（活跃） | 滚动 60 分钟内最多 20 分钟 | 无执行限制 | 无限制 |
| Working set（工作集） | 滚动 4 小时内最多 10 分钟 | 每小时最多 10 次 | 无限制 |
| Frequent（常用） | 滚动 12 小时内最多 10 分钟 | 每小时最多 2 次 | 无限制 |
| Rare（少用） | 滚动 24 小时内最多 10 分钟 | 每小时最多 1 次 | 禁用 |
| Restricted（受限） | 每天一次，最多 10 分钟 | 每天一个闹钟 | 禁用 |
"网络访问：禁用"这五个字就是根因。一个被判为 Rare 或 Restricted 的应用，系统会直接断掉它的网络——不管它是不是代理 App、有没有在前台列表里。什么样的应用会掉进这两个桶？官方对 App Standby 的判定是：用户一段时间没碰这个 App，且不满足以下任一条件——用户显式启动过它、它的进程处于前台（Activity 或前台服务）、或者它产生了用户可见的通知。反过来读就是：只要代理 App 有系统可见的常驻通知、有前台服务在跑，它就不该被判为闲置。而如果通知被系统屏蔽了、前台服务被厂商省电策略掐了，它就会滑向 Rare。
另外两条容易被忽略的官方规则：长时间闲置的应用，系统"大约一天只给一次网络访问"；而设备一旦插上电源，系统会把应用从待机状态释放，网络与作业额度立刻恢复。这也解释了一个常见现象——插着充电器测一晚上都不断，拔了充电器就断。
最后补一个 Android VPN 机制上的细节，它决定了"App 被杀掉之后还会不会恢复"。按官方 VpnService 文档：VPN 连接存活期间系统会显示一个托管的通知；当隧道对应的文件描述符被关闭时，网络会自动恢复，这个恢复过程同样覆盖"VPN 应用崩溃或被系统杀死"的情况；另外从 Android 8.0 起，系统会把 VPN 应用临时加入白名单以便它在后台启动，但该应用必须在启动后把自己提升为前台服务，否则系统会把它关掉。这三条合起来说明一件事：Android 上的代理存活链条是"被系统拉起 → 立刻转前台服务 → 保住通知 → 不被掐网络"，任何一环断了，用户看到的就是"息屏后没了"。
四、Android 侧配置：把存活链条的每一环都补上
机制清楚了，配置就有章法。下面五步按重要性排序，每一步都给出"做完怎么验证"，不要只做不验。
4.1 第一步：给通知权限（Android 13 及以上）
Android 13 引入了通知运行时权限 POST_NOTIFICATIONS。官方文档写得很明确：应用不需要这个权限也能启动前台服务，而且启动前台服务时必须带上一条通知；但如果用户选了"不允许"，该应用的所有通知渠道都会被屏蔽（除非命中少数豁免）。后果很直观：前台服务在跑，但你状态栏里什么都看不到，于是把"正在正常运行"误判成"没在跑"，然后去改一堆没问题的设置。做法很简单——系统设置里找到代理 App 的通知权限并允许，确认状态栏/通知栏能稳定看到那条常驻通知。
4.2 第二步：电池优化改成"不受限制"
这是整套配置里收益最大的一步。官方文档给的路径是"设置 → 电池 → 电池优化"，用户可以手动把某个应用从优化列表里豁免；应用侧也可以调用 isIgnoringBatteryOptimizations() 自检自己是否已在豁免名单里。豁免后的效果，官方在资源限制表里写得很直白：用户手动"不受限制"的应用，其网络访问为"不受限（除非设备处于流量节省模式）"。
括号里那半句是重点，也是第九节要展开的坑：即使你把电池优化关了，只要系统开着"流量节省/数据节省"（Data Saver），网络仍会被限制。很多人只做了前半步就以为完事，结果在开着省流量的手机上永远修不好。验证方法：进应用信息页看"电池"一项是否显示为"不受限制"，再去"流量使用情况"里确认数据节省没有开着。
4.3 第三步：确认"开机/后台自启"这条路是通的
Android 12 起，应用在后台启动前台服务会被系统拦截（抛 ForegroundServiceStartNotAllowedException）。官方给的豁免清单里，有两条和代理场景直接相关：用户关闭了该应用的电池优化，以及设备重启后收到 ACTION_BOOT_COMPLETED 等开机广播。这正好解释了小白最常踩的坑：重启手机后代理不会自己起来。原因是"开机自启"被厂商的自启动管理关了，或者电池优化没给豁免，系统拦掉了它在后台启动前台服务。验证方法很简单：重启一次手机，什么都不点，看代理有没有在一两分钟内自己连上。
4.4 第四步：打开系统 VPN 的"始终开启"
如果代理 App 走的是系统 VPN 接口（绝大多数客户端都是），系统里会多出一个"始终开启的 VPN"开关，配合"阻止未使用 VPN 的连接"一起用。前者解决"断了之后谁负责拉起来"，后者是系统级的兜底开关——隧道没起来的时候，系统干脆不放行流量，避免出现"以为在走代理、其实在裸奔"的窗口。VpnService 官方文档里也提到，VPN 服务可以通过元数据声明自己支持 always-on 模式，也就是这个开关能出现在你的设置里，取决于 App 的实现。验证方法：手动断开一次隧道，看系统是否能自动把它拉回来。
4.5 第五步：处理厂商层的省电策略
国产 ROM 在 AOSP 之上又加了一层：自启动管理、后台冻结、锁屏清理、深度睡眠、智能省电。各家菜单名和路径都不一样，所以别背路径，用两个判据判断是否处理干净：① 重启后代理能不能自己起来；② 熄屏半小时后常驻通知还在不在。如果这两条有一条不通过，就去系统设置的搜索框里分别搜"自启动""后台""电池""省电"，把代理 App 相关的开关都放开。这一层不处理干净，前三步做对了也白做。
做完这五步之后，还有一个容易被忽略的连带项：套餐的设备数。手机常驻之后，你还想同时挂着平板和电脑，这时"几台设备"就从一个小字变成硬约束；选购时把手机、平板、电脑三台同时在线算进去，别选只有 1–3 台档的套餐。以站内在售的SS-ID为例，100G 与 200G 两档标的都是 5 台设备（¥20/¥30 月付），手机 + 平板 + 电脑三台常驻之后还剩余量，属于这个场景比较合适的档位区间。
五、iOS 侧机制：隧道由系统托管，断的是"连接状态"而不是 App
iOS 的机制和 Android 完全不同，把 Android 的经验直接套过来会走很多弯路。关键区别在架构：iOS 上第三方代理必须通过 Network Extension 实现（要么是 packet tunnel provider，要么是 app proxy provider），隧道不是跑在 App 的界面进程里，而是由系统托管的扩展进程负责。Apple 官方对 app proxy provider 的描述是：系统启动 VPN 配置时会拉起你的 App 扩展、在其中实例化 provider、然后开始把流量转发给它。
这就带来一个反直觉但非常重要的结论："App 在后台被挂起"和"隧道断开"是两件独立的事。你在 iOS 上滑关闭 App，关掉的是界面进程；隧道由系统托管，会不会断要看系统 VPN 的状态，而不是看 App 是不是在后台列表里。所以"我的 iOS 客户端被系统杀了所以断了"这个判断，在多数情况下是错的。
那 iOS 上到底什么情况会真断？Apple 官方在 Network Extension 的网络路由文档里给两个状态变化的后果写得很具体：
- 当 VPN 离开"已连接"状态时，系统会丢弃网络流量。官方举的例子正是最常见的场景：设备从 Wi-Fi 切到蜂窝网络时，以及它在蜂窝网络上重连 VPN 服务器的这段时间。
- 当 VPN 从"已断开"进入"正在连接"状态后，系统不会关闭已经建立的 TCP 连接，但会丢弃这些连接后续收发的数据包。
第二句解释了那个最让人困惑的现象：切换网络或重连期间，你打开网页不是立刻报"无网络"，而是转圈、超时，几十秒后恢复正常。因为老连接没被关掉，只是后续的包全被扔了，客户端只能等到超时。这也意味着重连窗口内的"断"是设计行为，不是故障，你要优化的是窗口的长短和自动重连是否生效。
自动重连靠的是"按需连接"（on-demand）规则，而不是靠 App 常驻前台。Apple 的 API 设计里，按需连接由配置项的 isOnDemandEnabled 开关加一组规则决定，官方明确说"系统会遵循你配置的 disconnect on-demand 规则"。换句话说：没配按需连接，隧道断了就一直是断的；配了之后，系统才知道什么条件下该把它拉起来。这就是为什么同一个 App，在两个人手机上表现完全不同。
还有两个 iOS 特有的因素值得记下来。第一是低电量模式：Apple 官方支持页列出的影响清单里，包括关闭"后台 App 刷新"、关闭电子邮件获取、把自动锁定改成 30 秒、降低显示亮度等，充电到 80% 以上会自动关闭。注意它影响的是 App 侧的后台任务（订阅更新、节点测速、自动选择这类活），系统托管的隧道本身不在这个清单里。所以"一开低电量模式就断"这个现象，更该往重连规则和网络切换上找原因，而不是归罪于这个开关。第二是与 iCloud 私密代理的关系：官方注明"当某个 VPN 配置处于激活状态时，连接会使用该 VPN 而不是 iCloud 私密代理"。两者不会叠加，排查时可以把这个变量划掉。另外，企业受监督设备上那个"始终打开 VPN"是 MDM 下发的能力，个人设备上与之最接近的就是按需连接，不要指望个人设备能开出完全等价的效果。
六、重连窗口：能优化的三个变量，以及出口变化的连带后果
把 Android 和 iOS 的机制放在一起看，可以提炼出"重连窗口"这个统一概念：从隧道离开已连接状态，到它重新连通并恢复转发，中间这段窗口里丢包是必然的。窗口本身没法消除，但它是可控的，可优化的变量有三个。
- 自动重连是否生效。Android 靠系统 VPN 的"始终开启"，iOS 靠按需连接规则。这两个开关没配，窗口就是无限长——断了就等人手动去点。
- 节点侧的可用性。隧道重建时要先建立一个能用的连接。如果当前节点恰好不通，客户端会先试下一个，窗口被拉长；节点越多、线路越杂，这个尝试过程越久。
- 出口会不会变。重连之后落到哪个出口，取决于客户端的选择策略。对普通浏览来说无所谓，对跨境账号、流媒体、支付类场景就是另一回事——出口 IP 一换，账号的登录地区、平台的风控评分都可能跟着变。这类场景下值得优先考虑出口属性明确的方案：仙路湾提供原生 IP 与住宅 IP 两档（原生 IP 档 50GB 起 ¥9.9/月，住宅 IP 档 100GB 起 ¥30/月），重连后出口属性更稳定，掉线带来的连带损失也就更小。
三个变量里最容易被忽略的是第三个。多数人重连后只确认"能上网了吗"，却没注意出口换到了哪里。有些客户端在重连时会重新跑一遍"自动选择"，结果上一次落在日本、这一次落在美国；对只看视频的人来说无所谓，但对登录后台、跑广告账号、做跨境电商的人来说，出口频繁漂移本身就是风险信号。如果业务对出口敏感，把客户端的选择策略从"自动/延迟优先"改成"固定节点或固定地区"，让重连后仍回到同一个出口，通常比换一条更快的线路更值得做。
重连窗口的长短也别只凭感觉。有个很朴素的办法可以量化：让手机熄屏静置，同时用另一台设备持续探测一个固定域名，观察丢包持续了多久；然后把 Android 的"始终开启 VPN"、iOS 的按需连接依次打开再测一遍，两次的丢包时长之差，就是这次配置带来的实际收益。这套动作比"感觉今天稳一点"可靠得多，而且全程不需要任何专业工具。
还有一个认知上的修正：重连窗口里的丢包不是"代理坏了"，而是"本地到出口的路径在重建"。所以遇到转圈，第一反应应该是等十到三十秒，而不是马上去点断开再连——手动断开会改变系统的连接状态，而不同实现对"用户主动断开"的处理并不一样：Android 的"始终开启"会让系统再把它拉起来，iOS 侧则完全取决于按需连接规则怎么配。把手动操作当成恢复手段，经常会让本该自动完成的恢复变得更慢。
把上面三条落到具体动作，是一个有先后顺序的清单：先开自动重连（这是唯一能决定"断了之后会不会自己回来"的开关），再固定出口策略（避免重连后出口漂移），最后才是调客户端的节点切换逻辑（把"自动选择"换成带健康检查的固定组）。顺序颠倒的话，前两步没做只调第三步，效果会非常有限——隧道根本没被拉起来，谈"切到哪个节点"没有意义。
还有一点值得写下来：如果排查到最后发现"系统层都配齐了、掉线频率依然很高"，那就别继续折腾手机设置了。这时该看的是客户端版本与系统版本这对组合——Android 的每一次大版本都在改后台上限（12 的前台服务启动限制、13 的通知权限、14 的服务类型强制声明），老客户端跑在新系统上表现变差是常见情况；iOS 同理，大版本更新后按需连接规则的行为也可能变化。先更新客户端、再决定要不要换方案，比反过来做省事得多。
最后，别把重连窗口当成唯一的稳定性指标。真正影响体验的是"两次掉线之间隔了多久"：一天掉三次、每次三十秒，窗口再短体验也很差；三天掉一次、每次一分钟，多数人根本察觉不到。所以排查时先记录频率，再谈窗口——频率问题几乎总是系统层造成的，窗口问题才是客户端策略和线路该管的事。
顺带说清一件事：很多人把"重连窗口"当成节点质量差，于是不停地换机场。但按上面的机制，窗口长短主要取决于本地是否配了自动重连、以及客户端的节点选择策略——系统层没配好时，换十家机场的表现是一样的。
七、分平台排查表：症状对号入座
把前面几节的判据整理成一张对照表，出问题时按行找。
| 症状 | 判读 | Android 侧处置 | iOS 侧处置 |
|---|---|---|---|
| 熄屏十几分钟后连接标记消失 | 进程被回收，前台服务被停 | 通知权限 + 电池不受限 + 厂商自启动三项一起放开 | 隧道由系统托管，先看系统 VPN 状态再说，别急着怪 App 被杀 |
| 标记在，全部 App 无网、DNS 超时 | 网络被系统限制 | 检查是否落进待机分桶的低档；确认数据节省没开着 | 检查是否刚发生过 Wi-Fi/蜂窝切换 |
| 页面转圈几十秒后自己恢复 | 重连窗口丢包 | 打开系统 VPN"始终开启"，缩短窗口 | 配置按需连接规则，让系统主动拉起隧道 |
| 只有后台下载/推送停，前台正常 | App 各自的后台策略，不是隧道问题 | 无需改代理配置，去看下载类 App 的后台权限 | 确认"后台 App 刷新"没被低电量模式关掉 |
| 重启手机后代理不自动连 | 后台启动前台服务被系统拦截 | 放开自启动 + 关掉电池优化（这两条是官方豁免项） | 配置按需连接，或重开一次 App |
| 插着充电器怎么都不掉，拔了就掉 | Doze 只在"未插电 + 静止 + 息屏"下生效 | 把电池优化豁免开上，等效于部分抵消 | 属于系统行为，靠按需连接兜底 |
| 只有某个节点不行，换节点就好 | 单点故障 | 换节点，顺手看客户端是否在自动切换 | 同左 |
八、最容易被忽略的八个坑
- 只把 App 加进电池白名单就以为完事。官方明确写了豁免后的网络是"不受限，除非设备处于流量节省模式"。省流量一开着，白名单等于没加。
- 通知权限拒了，然后误判"没在跑"。Android 13 起通知是运行时权限，前台服务的通知不显示，状态栏一片安静，看起来就像没启动。
- Android 12 起后台启动前台服务被拦，重启后起不来。官方豁免清单里，"用户关闭了电池优化"和"开机广播"是关键两条，必须给。
- Android 14 起前台服务必须声明类型。没声明类型的话，系统是直接抛异常（MissingForegroundServiceTypeException 或 SecurityException），而不是静默失败。老版本客户端在新系统上出问题，先更新 App 而不是改设置。
- 在多任务里把 App 划掉。Android 上划掉等于杀进程，前台服务一起停，之后只能等系统重新拉起——这就是"我清理了一下后台，结果代理再也没连上"的原因。
- 把"iOS 上滑关闭 App"当成断线原因。隧道由系统托管，划掉的是界面。判断看系统 VPN 状态，不看后台列表。
- 只在亮屏时测试。Doze 的触发条件是"未插电 + 静止 + 息屏"，你盯着手机测，它永远不会进 Doze，于是"测不出来"。要测就熄屏放半小时再看。
- 以为设备息屏后网络一定还在。按官方的 App Standby 规则，长时间闲置的应用系统"大约一天只给一次"网络访问。后台任务不是"随时能做"，是"有机会时才能做"。
这八个坑有一个共同特征：都能靠"观察系统状态"而不是"猜"来判断。如果你习惯用命令行，Android 侧还有一组官方文档里给出的命令可以直接模拟这些状态，比等一小时快得多：先把设备设成"未插电"再强制进 idle，观察 App 反应，然后退出 idle 并恢复电池状态。
# 模拟未插电（App Standby 测试的第一步）
adb shell dumpsys battery unplug
# 强制系统进入 Doze/idle，观察代理是否掉线
adb shell dumpsys deviceidle force-idle
# 退出 idle 状态
adb shell dumpsys deviceidle unforce
# 恢复电池状态（做完务必执行，否则设备状态是假的）
adb shell dumpsys battery reset
# 单独把某个应用置为待机/唤醒（把包名换成你的客户端）
adb shell am set-inactive <包名> true
adb shell am set-inactive <包名> false
adb shell am get-inactive <包名>这组命令的价值在于"可复现"：你不用等半小时,而是主动把设备推进 Doze，立刻看代理会不会断；如果是断了，再逐项放开配置并重跑同一条命令，用同一套动作验证修复是否有效。不同 Android 版本对 dumpsys 子命令的支持略有差异，本机报错的话先执行 dumpsys deviceidle 看它自己打印的用法。
九、后台常驻的流量账：一个月到底吃掉多少额度
做完上面的配置，代理会在后台长期存活，自然会带来一个疑问：它会不会偷偷把流量吃掉？结论先行——量级很小，但值得算清楚，因为一旦你换到小额度套餐（比如原生 IP、住宅 IP 这类按 50GB/100GB 起步的档位），后台探测就不再是完全可忽略的项。
后台流量主要来自三件事：节点测速（urltest 这类定期探测）、订阅自动更新、以及节点信息/用量查询。单次探测消耗多少字节，取决于订阅里节点数量和探测方式，官方文档不会给这个数字，所以下面按"每次探测约 2KB"的假设做量级估算（这个假设写在这里，你可以按自己的实际情况替换）：
| 后台行为 | 频率 | 单次估算 | 月度合计（30 天） |
|---|---|---|---|
| 节点测速探测 | 每 180 秒 | 约 2KB | 约 28MB |
| 节点测速探测 | 每 300 秒 | 约 2KB | 约 17MB |
| 节点测速探测 | 每 600 秒 | 约 2KB | 约 8MB |
| 订阅自动更新 | 每天 1 次 | 约 200KB | 约 6MB |
| 节点信息/用量查询 | 每天 4 次 | 约 50KB | 约 6MB |
把最"费"的组合（180 秒一测 + 订阅每天更新 + 用量每天查四次）加起来约 40MB/月，最省的组合约 20MB/月。对 384GB 级的大流量套餐，这点消耗占比不到万分之一个百分点；但如果你用的是 50GB 档，40MB 大约是它的万分之八——依然可忽略，前提是别把测速间隔调到几十秒一次，那才会开始有存在感。想把这个账算细的，可以对照站内这篇机场流量计费口径的拆解，那里讲了倍率、双向计费与协议封装开销是怎么把额度算掉的，后台探测属于其中最小的一块。
十、自检清单与选型建议
把可执行部分压缩成一份清单，出问题时照着跑一遍，基本能定位到具体那一层：
- 亮屏时会不会断？会 → 不是省电问题，往节点和客户端配置方向查。
- 图标在不在？不在 → 进程被停（通知权限、电池不受限、自启动）；在但没网 → 网络被限（待机分桶、数据节省）。
- 重启后能不能自己起来？不能 → 自启动和开机广播这条路没通。
- 熄屏半小时后常驻通知还在不在？不在 → 厂商省电策略没处理干净。
- 切网络后是立刻恢复还是转圈？转圈 → 重连窗口，去配自动重连。
- 换个订阅表现一样吗？一样 → 排除机场，别白花换机场的钱。
- 后台测速间隔是多久？几十秒一次 → 调到 300 秒以上，省流量也更省电。
最后给一个选型层面的判断。手机端长期不稳时，先分清"是系统层还是方案层"：如果桌面端和手机端表现一致地不稳，那才轮到换方案；这时优先看两件事——有没有客户端实现完整的选项（走自家客户端的方案在手机上的常驻行为通常更可控），以及套餐的设备数与出口属性是否匹配你的用法。手机是全年 24 小时在线的那台设备，它在套餐里占的名额和它对出口稳定性的要求，都比电脑更高，别把它当成"顺手多连一个"。
相关阅读：客户端报错类的排查（连不上、订阅更新失败、超时断流）可以看这篇客户端故障排查完全指南，手机端和桌面端的错误码含义是共通的，本篇只补充了"系统层"这一段；iOS 侧的订阅导入与规则分流细节，iOS 客户端配置完全指南里写得比较全，本篇不再重复；Android 侧如果要横向比较客户端之间对前台服务、TUN 模式的支持差异，Android 客户端横评与配置指南里有逐项的对照。
推荐阅读：