全局代理与分流模式的工作原理对比

凌晨两点，杭州城西的一间共享办公室里只剩下林澈一个人。屏幕上，Figma 的画布还开着，旧金山的设计团队刚刚发来一条消息：“新版落地页的动效需要再对一遍，你那边能打开 staging 环境吗？”林澈揉了揉眼睛，顺手点开浏览器书签。页面转了三圈，最终弹出一行冰冷的提示：连接超时。

他叹了口气，切到系统托盘，点开那个熟悉的 VPN 客户端。界面上有两个选项，像两条岔路：一条写着“全局模式”，另一条写着“分流模式”。林澈愣了两秒——这两条路他天天走，却从没认真想过它们到底差在哪里。而这一晚，正是这个看似微不足道的选择，让他经历了一场从困惑到豁然开朗的“网络地理课”。

一、那个让林澈抓狂的夜晚

林澈先选了全局模式。点击“连接”后，客户端图标变绿，他重新刷新 staging 页面，这次顺利打开了。可紧接着，问题来了：他习惯边工作边听国内某音乐平台的歌单，此刻播放器却卡在加载界面，转个不停；微信电脑版的文件传输也变成了“发送中”却迟迟不动；甚至连公司内网的 OA 系统都提示“无法访问”。

他只好断开，换成分流模式。这次 staging 页面依然能打开，音乐秒播，微信文件嗖嗖地传，OA 也恢复正常。林澈盯着托盘里那个绿色小图标，心里冒出一个问题：同样一个 VPN，为什么换个模式，效果就像换了个网络世界？

要回答这个问题，得先弄清楚一件事：数据包出门之后，到底听谁的指挥。全局代理和分流模式，本质上就是两种不同的“指挥策略”。

二、全局代理：把整条街都搬进隧道

1. 工作原理：一条隧道，全部收编

全局代理的逻辑非常直白：一旦开启，设备上所有的对外网络请求——浏览器的、微信的、系统的、后台更新的——统统被拦截，送进 VPN 建立的那条加密隧道，再从远端的代理服务器出去。你可以把它想象成：林澈把整间办公室的所有电话线都拔下来，统一接到一台总机上，所有打出去的电话都必须经过总机转接。

在技术层面，这通常通过虚拟网卡（TUN/TAP）配合路由表改写来实现。客户端在系统里创建一块虚拟网卡，并把默认路由指向它。于是，无论哪个应用发起连接，数据包都会先落到这块虚拟网卡上，被封装、加密，再发往代理服务器。对应用来说，它们完全不知道自己“出了国”，只知道网络通了。

2. 优点：简单、彻底、不挑应用

全局模式最大的好处是确定性。它不关心你用什么软件、访问什么地址，一律照单全收。对于那些本身不支持代理设置的应用——比如某些游戏客户端、某些桌面工具、甚至系统级的更新服务——全局模式是唯一能让它们“走出去”的办法。林澈能打开 staging 环境，正是因为那个页面依赖的几个第三方脚本域名不在任何分流规则里，全局模式“一刀切”地兜住了它们。

3. 代价：杀敌一千，自损八百

但代价也很明显。所有流量都绕道远端服务器，意味着访问国内网站也要多绕一圈地球。林澈的音乐平台卡顿，就是因为音频流被送到了海外节点再折返，延迟从几十毫秒飙升到几百毫秒。更麻烦的是，一些依赖本地网络环境的服务——公司内网、局域网打印机、智能家居——会因为路由被改写而“找不到回家的路”。这就是为什么他的 OA 系统在全局模式下直接罢工。

换句话说，全局代理像是一位过度尽责的保安：不管来的是谁，一律登记、一律盘问。安全是安全了，效率却打了折扣。

三、分流模式：给每个数据包发一张“身份证”

1. 工作原理：先判断，再放行

分流模式（也叫规则模式、智能路由）的思路完全不同。它不急着把所有流量塞进隧道，而是先做一件事：识别。客户端内置了一套规则库，可能包含域名列表、IP 段、地理位置数据库，甚至应用进程名。当一个连接请求出现时，它先问：这个目标地址属于哪一类？

如果是国内域名或国内 IP，就走本地直连，不经过隧道；如果是境外地址，或者命中了“需要代理”的规则，才送进隧道。林澈的 staging 环境域名在规则库里被标记为境外，于是走了代理；音乐平台的域名被标记为国内，于是直连；公司 OA 的地址落在内网网段，客户端甚至直接绕过虚拟网卡。三者各走各的路，互不干扰。

2. 规则从哪来：一场持续的“情报战”

分流模式的核心资产是规则库。常见的规则来源包括：维护者手工整理的域名清单、基于 IP 地理位置的分库、以及从公开项目同步的规则集。客户端在本地做匹配，匹配顺序通常遵循“精确优先、通配兜底”的原则——先看有没有完全匹配的域名，再看后缀匹配，最后看 IP 段，实在判断不了才交给“最终规则”决定走代理还是直连。

这就像一位经验丰富的海关关员：手里有一份不断更新的名单，看到熟悉的本地居民直接放行，看到名单上的境外访客引导到专门通道，遇到拿不准的，才按默认流程处理。规则越精细，误判越少，体验越顺滑。

3. 优点与软肋：聪明，但会“看走眼”

分流模式的最大优势是效率与体验的平衡。国内流量不绕路，延迟低；境外流量走隧道，访问稳。对绝大多数日常场景——查资料、看视频、传文件、开视频会——它几乎是无感的存在。

但它的软肋也同样明显：规则永远滞后于现实。新上线的服务、临时启用的 CDN 域名、小众的 API 端点，都可能不在规则库里。这时候，分流模式就会“看走眼”，把本该走代理的流量放成直连，结果就是页面转圈、接口超时。林澈之前遇到的“连接超时”，很可能就是某个 staging 依赖的域名没被规则覆盖。而全局模式不会犯这种错，因为它根本不做判断。

四、同一张网络地图，两种走法

如果把网络访问比作从杭州寄快递到世界各地，全局代理相当于“所有包裹一律先送到海外中转仓，再分发”；分流模式相当于“快递员先看面单，同城件直接送，国际件才进中转仓”。前者简单粗暴、不会漏件，但同城件也要绕一大圈；后者高效精准，但面单信息一旦过时，就可能寄错方向。

林澈后来养成了一个习惯：日常办公用分流模式，遇到某个页面怎么都打不开时，临时切到全局模式“兜底”试一次——如果全局能通，说明是规则没覆盖；如果全局也不通，那多半是对方服务本身的问题。这个小小的切换动作，其实就是在两种“指挥策略”之间做权衡。

五、选择的本质：你更怕“漏”，还是更怕“慢”

回到那个深夜。林澈最终把两种模式都试了一遍，弄清了症结：staging 环境里有一个新引入的第三方域名没被规则收录。他在客户端里手动加了一条规则，然后切回分流模式，一切恢复正常。音乐继续播，文件继续传，OA 也能打开。他关掉客户端设置面板时，忽然觉得这两个选项不再像“岔路”，而更像两把不同用途的工具。

全局代理与分流模式的对比，说到底不是“谁更好”的问题，而是“你此刻更在意什么”的问题。在意确定性、愿意用速度换省心，全局模式是稳妥的兜底；在意日常体验、愿意花一点心思维护规则，分流模式是更聪明的日常选择。真正理解它们的工作原理之后，那个绿色小图标背后的逻辑就不再神秘——它只是一张不断被判断、被转发的网络地图，而选择权，始终在按下开关的那个人手里。