上个月我遇到一件怪事：手机上 Google Play 有个 200MB 的更新，挂着代理下了半小时还没完。我随手把代理一关，嘿，一分钟下完了。再打开代理，YouTube 照看不误。那一刻我悟了：不是网速慢，是流量走错了路。
问题出在哪
道理很简单：应用商店的下载服务器在国内（或离你很近）本来就有节点，你非要让它先绕到国外代理服务器再回来，等于从北京寄快递到北京，非要经停洛杉矶。更新包动辄几百 MB，这种绕路的代价会被放大无数倍。
系统更新同理：iOS 的更新、Windows Update、Mac 的软件更新，服务器离你都不远，走直连又快又稳。让它们走代理，除了慢，还可能因为 IP 地区不对被应用商店限速——这是很多人没想到的第二层伤害。
分流规则的基本思路
分流的核心就一句话：国内的、近的，走直连；国外的、被墙的，走代理。主流客户端都支持按域名、按 IP 段、按 GeoSite/GeoIP 规则集来分流。新手不用自己写规则，用现成的规则集就行：
第一步，确认你的客户端用的是"规则模式"而不是"全局模式"。全局模式下所有流量都走代理，更新慢是必然的。
第二步，检查规则集是否包含应用商店相关域名。常见的规则集（比如 Loyalsoldier 的 geo 规则）一般都覆盖了主流应用商店，但如果你用的是机场自带的精简规则，可能缺了这部分，手动补一条"应用商店域名直连"就行。
我帮朋友配规则的那一晚
上个月朋友来找我，说他手机更新 App 奇慢，还怀疑是机场不行。我远程看了他的配置：全局模式，常年不关。我给他切到规则模式，加了三条规则——应用商店直连、系统更新直连、国内域名直连，然后让他更新那个 800MB 的游戏。两分钟，下完了。他愣了半天：“就这？“就这。很多时候问题不在"车”（节点），在"路”（分流）。新手最容易犯的错，就是把所有问题都归因于机场，然后换了一家又一家，问题原地踏步。
iOS 和 Android 的区别
iOS 上，App Store 的更新走的是苹果的 CDN，国内节点覆盖很好，直连速度极快。但要注意：iOS 的"自动更新"在后台跑，你可能意识不到它在走代理——症状是"手机发热、流量莫名其妙没了"。建议把 App Store 相关域名全部直连，一劳永逸。
Android 上情况复杂点：Google Play 本来就要走代理（国内直连不上），这时候"快"的定义变了——目标是让 Play 的流量走"最快的那条代理线路"，而不是直连。做法是给 Google Play 相关域名单独建一个策略组，指定低延迟节点。国内应用商店（华为、小米、OPPO）则全部直连。两套商店、两套逻辑，别混为一谈。
规则维护的日常习惯
规则不是配一次管一辈子的。我的习惯：每月初更新一次规则集（GeoSite/GeoIP 数据库会过期）；每次换机场，先确认新机场的订阅和我的自定义规则兼不兼容；大版本系统更新（比如 iOS 大版本）后，检查一遍分流——苹果偶尔会换 CDN 域名，规则里没覆盖就又慢了。把这些做成日历提醒，一年花不了半小时，换来的是全年丝滑。
第三步，系统更新单独处理。Windows Update、Apple 软件更新这些，建议直接加直连规则。它们流量大、服务器近，走代理纯属负优化。
几个容易踩的坑
坑一：规则和 DNS 打架。分流靠域名匹配，域名解析如果走了错误的 DNS，匹配就失效。排查时可以对照代理模式的科普，确认自己到底开的是哪种模式。
坑二：机场订阅自带的"去广告"“解锁"规则和你手动加的规则冲突。症状通常是"加了直连规则反而更慢”，解决办法是理清规则的优先级，或者干脆用一套统一的规则集。
坑三：把"更新慢"全怪到分流头上。有时候就是单纯的节点不行：晚高峰、免费节点和付费节点的差距在更新这种大流量场景下暴露无遗。先换个节点试试，确认是"路"的问题还是"车"的问题。
进阶：给更新流量单独开条路
如果你用的客户端支持策略组（Clash 系、Surge、Stash 都支持），可以给应用商店、系统更新单独建一个"直连"策略组。这样既不影响代理流量，也不用每次手动开关。对 NaiveProxy 这类新协议 的用户同样适用：协议再新，分流的逻辑不变。
复盘这次经历，最大的收获不是"更新变快了"，而是理解了分流的本质：代理是工具，不是信仰。该走代理的走代理，该直连的直连，让每一条流量都走它该走的路，网络体验才能真正丝滑。从那以后，我的规则集里第一条就是：应用商店，永远直连。