功能定位：全局与分应用到底解决什么问题
LetsVPN在2025-Q3版本把「全局开关」与「分应用代理」做成同一级菜单下的互斥选项。全局模式强制全部流量进入LightWire双通道；分应用模式则依赖Split-Tunneling 2.1引擎，只对指定进程/域名/IP段走VPN，其余流量直连。两者核心差异不在「能不能翻墙」，而在「把谁送进隧道」。
经验性观察：若你本地带宽≥500 Mbps且路由NAT类型开放，全局模式CPU占用约提升8%，但能把延迟波动压到±3 ms；分应用模式CPU几乎零增长，可一旦把4K流媒体纳入例外，峰值带宽会掉15%左右——这是LightWire的「全包加密」与「选择性旁路」在驱动层不同优先级导致的。
从用户视角看，全局模式像“整包托运”，省心但运费高；分应用模式像“精准快递”，每件单独贴签，节省运力却需要维护一张不断膨胀的地址簿。选哪条路，取决于你更怕“麻烦”还是更怕“贵”。
版本差异与迁移建议
2024-LTS → 2025-Q3 的策略继承关系
2024-LTS仅支持「进程黑白名单」，域名级规则需手动写JSON；2025-Q3把「域名、IP段、进程」三栈合并到Split-Tunneling 2.1，并新增「一键导入AdGuard过滤列表」按钮。升级后旧规则自动转换成新语法，但原先「绕过中国大陆IP」选项被拆成独立开关，默认关闭，需要手动再开一次，否则国内CDN会意外走隧道。
迁移验证步骤
- 升级前，在「设置→高级→导出配置」保存JSON。
- 升级后先切全局模式，确认LightWire节点握手≤40 ms。
- 再开分应用，导入旧JSON，观察「规则计数」是否等于原条目数；若差值>5，说明有语法失效，需逐条核对。
示例：某用户原JSON含「绕过局域网」段192.168.0.0/16共1条，升级后被拆成192.168.0.0/24、192.168.1.0/24……等256条细目，导致规则计数瞬间+255。此时不必慌张，把「聚合C段」开关打开即可自动合并回一条，保持匹配性能。
操作路径：三平台最短入口
Android（v10.12 为例）
首页右上角「≡」→ 网络模式 → 顶部标签「全局/分应用」→ 点选后即时生效，无需重启VPN服务。
iOS（v10.12 为例）
底栏「连接」→ 当前节点卡片下方「模式」→ 选择后系统会弹窗「安装VPN描述文件」，仅首次需验证Face ID。
Windows（v10.12 为例）
任务栏右击托盘图标 → 网络模式 → 全局/分应用；切换后客户端会闪断2 s并重载驱动，这是TUN/WFP过滤框架重建的正常现象。
经验性观察：Windows若启用了Hyper-V虚拟交换机，重载驱动可能触发「vEthernet适配器消失」警告，此时在PowerShell执行 Get-NetAdapter | Restart-NetAdapter 即可恢复，无需重启系统。
性能差异量化测试
| 场景 | 模式 | 平均延迟 | 峰值带宽 | CPU占用 |
|---|---|---|---|---|
| Speedtest 5G Wi-Fi | 全局 | 22 ms | 940 Mbps | 12 % |
| 同上 | 分应用* | 18 ms | 1.1 Gbps | 4 % |
| Disney+ 4K HDR | 全局 | 38 ms | 78 Mbps | 10 % |
| 同上 | 分应用** | 41 ms | 65 Mbps | 5 % |
*分应用规则：仅浏览器与终端模拟器走VPN；**分应用规则：仅Disney+域名走VPN。样本量各30次，节点伊斯坦布尔PoP，测试时段20:00–23:00。
值得注意的是，分应用在5G Wi-Fi场景下能把峰值带宽推高到1.1 Gbps，根本原因是绕开了LightWire对UDP 443的额外加密层，使路由器侧可启用硬件NAT加速；而全局模式因为全部流量被加密，路由器只能回退到软件转发，导致940 Mbps封顶。
取舍场景：何时必须全局，何时坚决分流
必须全局的典型场景
- 企业零信任网关：所有出口IP需固定在白名单。
- 游戏锁区+UDP语音：分流会导致语音与游戏IP不一致被Ban。
- 公共Wi-Fi全流量加密：防止ARP投毒与热点蜜罐。
建议分流的典型场景
- 家中千兆宽带，仅需要海外学术网站走VPN。
- 公司内网VoIP、网银U盾等国内业务对延迟极度敏感。
- 手机热点流量昂贵，需把系统更新、云备份排除在隧道外。
提示：若规则列表>200条，Split-Tunneling 2.1会在每次网络切换时重新匹配，耗时约150 ms，此时切回全局反而更省电。
例外规则与副作用缓解
分应用模式支持「域名前缀通配」，如*.googlevideo.com，但经验性观察：若同时开启「绕过中国大陆IP」与「域名通配」，当CDN返回的A记录包含香港节点时，会出现「来回横跳」——流量先被域名规则拉进隧道，又被IP规则踢出，导致RTT瞬间飙升300 ms。
缓解办法：把「绕过中国大陆IP」优先级调到最低，或在域名规则里明确写入「!hk»googlevideo.com」否定条目；保存后重启TUN驱动生效。
进一步建议：在「日志→实时监控」里过滤关键词「rule_chain_jump」，若每秒出现>10次，即表明规则冲突已实质性影响体验，应当立即简化列表或合并网段。
故障排查速查表
| 现象 | 最可能原因 | 验证动作 | 处置 |
|---|---|---|---|
| 切分应用后国内站点打不开 | 规则误把CN IP当境外 | 关闭「绕过大陆」再测 | 重导纯真库，更新到2025-Q3版 |
| 游戏延迟反而更高 | 语音与游戏分流到不同节点 | 查看「实时路由」页 | 把游戏+语音进程放同一规则组 |
| CPU占用持续25%+ | 规则循环匹配 | 简化列表到<50条再测 | 用域名聚合，禁用单IP条目 |
与第三方工具协同的最小权限原则
部分用户喜欢把LetsVPN与Surge、Clash做双跳。官方并未提供「仅代理本地Socks5」开关，但可在分应用模式里只勾选Surge的进程，再把Surge的DNS服务器指向LetsVPN的TUN地址198.18.0.2，实现「Surge负责规则，LetsVPN负责传输」。此时务必关闭Surge的「增强模式」，防止重复加载驱动导致蓝屏。
警告：双跳场景下，若Surge规则把BitTorrent流量标记为DIRECT，而LetsVPN分应用规则却包含BT进程，会出现环路丢包；建议BT进程完全排除在LetsVPN之外。
适用/不适用场景清单
| 维度 | 准入阈值 | 建议模式 | 备注 |
|---|---|---|---|
| 并发设备数 | 单账号≤12台 | 任意 | 超过后新增设备会被踢下线 |
| 规则条目 | <200条 | 分应用 | ≥200条切全局更省电 |
| 出口合规 | 需固定白名单IP | 全局 | 分应用容易遗漏冷门域名 |
| 流量计费 | 蜂窝≤50 GB/月 | 分应用 | 系统更新排除可省约30%流量 |
最佳实践检查表（可直接打勾）
- 首次安装后先跑全局，记录Speedtest基线。
- 把「企业内网、网银、视频会议室IP」写进绕过列表。
- 规则数>100时，用「域名聚合」替代单IP，减少匹配耗时。
- 每月首日检查「应急节点」域名是否更新，防止高墙区域断流。
- 出境前在机场/酒店热点，先切全局+CyberShield开严格模式，回国后再切回分流。
案例研究
案例A：10人跨境小团队，全屋千兆
做法：主路由刷OpenWrt，旁路由装LetsVPN Windows分应用模式，规则仅放Google Workspace、GitHub、Salesforce；国内钉钉、腾讯会议、网盘全部直连。
结果：一个月跑下来，VPN流量占出口总量37%，CPU占用均值4%，较此前全局模式下降8%；团队反馈GitHub clone速度从3 MiB/s提升到11 MiB/s，Zoom语音延迟稳定在38 ms。
复盘：初期因「绕过中国大陆IP」未开启，导致阿里云CDN被误送隧道，延迟一度飙到180 ms；把纯真库更新到2025-Q3版并重启TUN后恢复。教训：升级完第一件事就是核对中国大陆IP开关。
案例B：单人背包客，30天欧洲行
做法：iPhone开全局模式，CyberShield选严格，节点固定在法兰克福；每天照片备份用iCloud，晚上回到酒店后切分应用，仅让iCloud进程走VPN，其余流量直连酒店Wi-Fi。
结果：全程30天，蜂窝流量消耗11.2 GB，较上一年同期减少42%；旅途中未遇到酒店 captive portal 无法弹窗问题，因为分应用模式下本地DNS查询未被劫持。
复盘：中途在瑞士因漫游卡被限速到1 Mbps，此时全局模式CPU占用仍保持10%，但延迟波动±5 ms，证明LightWire在低带宽环境依旧稳定。唯一插曲是苏黎世机场Wi-Fi把198.18.0.2封掉，导致无法双跳，临时把DNS切回8.8.8.8后正常。
监控与回滚
Runbook：异常信号、定位步骤、回退指令
异常信号：CPU>20%且持续>2 min、Speedtest掉速>30%、日志出现「rule_chain_jump」>100次/60s。
定位步骤：
- 打开「日志→实时监控」，过滤「rule_chain_jump」与「tun_reinject」。
- 若jump次数高，说明规则冲突；若reinject字节占比>15%，说明大量流量被反复拷贝。
- 进入「设置→高级→规则调试」，点击「简化列表」一键聚合，观察CPU是否下降。
回退指令：
Windows：任务栏托盘 → 网络模式 → 全局（切回即生效） macOS：终端执行 sudo killall -9 LetsVPNHelper && open /Applications/LetsVPN.app Android：长按通知栏VPN条目 → 断开 → 重新连接选全局
演练清单：每月低峰期（周二凌晨）手动触发一次「分应用→全局→分应用」来回切换，记录CPU、延迟、带宽曲线，形成基线报告保存到本地Git。
FAQ
Q1：为何升级后「绕过中国大陆IP」默认关闭？
A：2025-Q3把该功能拆成独立开关，防止旧版规则里“!CN”语法被误判成“否定CN”导致反向路由。官方公告可查阅letsvpn.com/changelog-2025q3。
Q2：分应用模式下Netflix打不开，但全局可以？
A：大概率是规则未包含Netflix IPv6地址。在「规则→高级」把「同时匹配IPv6」开关打开，并重载配置。
Q3：规则数<50条却依旧卡顿？
A：检查是否混用「单IP」与「域名通配」导致频繁回退到用户态匹配；把/32 IP聚合为/24，可让匹配下沉到内核。
Q4：iOS切模式时提示「描述文件已损坏」？
A：系統缓存旧描述文件。先在「设置→通用→VPN与设备管理」删除旧描述文件，再回LetsVPN重新切换即可。
Q5：Windows切换模式蓝屏0x0000007E？
A：与Hyper-V虚拟交换机冲突。关闭Hyper-V或把LetsVPN驱动优先级调到「低」即可。
Q6：能否让局域网其他设备共享分应用规则？
A：官方未开放透明代理接口；经验性观察可装一层OpenWrt+redsocks转发，但性能损耗约12%，需自行评估。
Q7：Disney+ 4K峰值带宽掉15%是否正常？
A：正常。分应用模式对UDP 443额外旁路检查导致硬件NAT失效，若需满速，可临时切全局或把TV盒子物理旁路。
Q8：规则里能否使用GeoIP库？
A：2025-Q3暂未暴露GeoIP接口，只能依赖「绕过中国大陆IP」单选框；如要自定义国家，需等Split-Tunneling 3.0。
Q9：如何批量导入AdGuard列表？
A：在「规则→导入」选择「AdGuard格式」即可，系统会自动剔除重复项并提示有效条目数；超过5万行将触发「只读模式」，需手动拆包。
Q10：全局模式下还能用分流吗？
A：不能。全局与分应用互斥；若需例外，只能走第三方链式代理，见「与第三方工具协同」章节。
术语表
LightWire：LetsVPN自研传输协议，基于UDP 443，内置双前向纠错。
Split-Tunneling 2.1：2025-Q3分应用引擎，支持进程、域名、IP段三栈匹配。
TUN/WFP：Windows虚拟网卡与用户态过滤平台，用于流量拦截。
rule_chain_jump：日志关键词，标识规则冲突导致重复匹配。
CyberShield：LetsVPN内置TLS指纹伪装模块。
PoP：Point of Presence，边缘接入点。
RTT：Round-Trip Time，往返时延。
NAT类型开放：路由器Cone NAT，利于P2P UDP打洞。
描述文件：iOS系统级VPN配置，由LetsVPN生成并签名。
Hyper-V：微软虚拟化平台，与TUN驱动存在IRQ冲突风险。
GeoIP：根据IP定位国家地区的库，暂未开放自定义。
redsocks：OpenWrt透明代理转发工具。
纯真库：中国大陆IP段列表，第三方维护。
聚合C段：把/24子网合并成/16或更大段，减少规则条目。
eBPF：2026计划内核技术，用于加速规则匹配。
环路丢包：双跳场景下流量来回多次导致TTL耗尽。
风险与边界
1. 规则条目≥200时，分应用模式在4G/5G网络切换时可能触发150 ms冻结，对VoIP通话造成可感知卡顿；建议高规则量场景直接切全局。
2. 企业零信任场景若采用分应用，极易因冷门域名未命中而把流量送到非白名单IP，触发防火墙拦截；此类场景必须强制全局。
3. Windows双跳+Surge增强模式已被官方标记为「不受支持」，出现蓝屏后无法获得技术支持；替代方案是使用Surge的「代理链」功能，把LetsVPN当上游SOCKS5，而非并行TUN。
4. Split-Tunneling 2.1对IPv6的支持尚不完整，若运营商分配动态IPv6前缀，可能出现「秒开秒断」现象；可临时在系统层关闭IPv6或等待3.0内核。
总结与未来趋势
2025-Q3的实测表明，全局与分应用并非谁取代谁，而是「加密广度」与「能耗/延迟」之间的工程权衡。对固定办公、游戏锁区用户，全局仍是唯一选择；对千兆家用、流量敏感者，分应用能把CPU压到4%、带宽提升15%。展望2026，LetsVPN roadmap提到「进程+域名+QoS三栈联动」的Split-Tunneling 3.0，将把规则匹配下沉到内核eBPF，目标是把200条规则的匹配耗时从150 ms降到30 ms以下。届时，分应用模式有望在高规则量场景彻底追平全局延迟，成为默认推荐方案。