1. 四种代理模式到底在解决什么问题

先把场景摆出来。你手上有一台电脑、一个客户端软件，它需要访问外部资源。这个客户端可能是浏览器、某个开发工具、某个下载器，也可能是某个只认系统代理设置的老软件。代理模式要回答的核心问题只有一个： 哪些流量走代理，哪些不走，走的话走哪条线路。

全局、规则、直连、脚本这四种模式，本质上是对这个问题的四种不同回答方式。它们不是四个互不相干的选项，而是从“一刀切”到“精细化控制”的一条光谱。理解这条光谱，比死记四种模式的定义有用得多。

我刚开始接触这类工具的时候，也犯过迷糊。当时觉得“全局”就是全走代理，“直连”就是全不走，那“规则”和“脚本”是不是多余？后来实际用下来才发现，真实网络环境远比想象中复杂。你可能有几十个需要访问的服务，其中一部分必须走特定线路，一部分走本地网络就行，还有一部分要根据时间段或网络状况动态决定。这时候光靠全局和直连两个开关，根本不够用。

所以这四种模式的设计逻辑，其实是 控制粒度 的递进：

• 全局模式 ：控制粒度最粗，所有流量统一处理
• 直连模式 ：控制粒度同样粗，但方向相反，所有流量都不处理
• 规则模式 ：控制粒度中等，按预设的域名、IP、地理位置等条件分流
• 脚本模式 ：控制粒度最细，用代码逻辑动态决定每一条流量的去向

这个递进关系很重要。很多人一上来就想用脚本模式，觉得最灵活最强大，结果发现自己连基本的规则都没搞清楚，写出来的脚本逻辑漏洞百出，反而导致网络时通时断。我的建议是：先把全局和直连用明白，再上规则，最后才考虑脚本。

还有一个容易被忽略的点：这四种模式并不是互斥的。很多客户端允许你在规则模式的基础上叠加脚本逻辑，或者在全局模式下排除某些特定流量。理解它们之间的组合关系，比单独理解每一种模式更有实战价值。

注意：不同客户端对四种模式的命名和实现细节可能有差异，但核心逻辑是相通的。本文讨论的是通用层面的设计思路，具体操作时请以你所用客户端的文档为准。

2. 全局模式：最直接但也最容易踩坑的选择

2.1 全局模式的工作原理与适用场景

全局模式做的事情非常简单： 所有流量都交给代理处理，不做任何区分。 你打开这个模式，浏览器访问网页走代理，系统更新走代理，连局域网内访问另一台电脑的共享文件夹也走代理。

这种“一刀切”的做法听起来很粗暴，但它有明确的适用场景。最常见的就是 临时需要统一出口 的时候。比如你在调试一个服务，需要确保所有请求都从同一个IP出去，这时候全局模式最省心。再比如你刚拿到一个新的代理配置，想快速验证它能不能用，全局模式也是最直接的测试方式。

另一个典型场景是 客户端本身不支持规则分流 。有些老软件或者轻量级工具，只提供全局和直连两个开关，没有规则引擎。这时候你只能在全局和直连之间切换，没有中间选项。

但全局模式的坑也很明显。最直接的问题就是 本地网络访问会受影响 。你开着全局模式，想访问路由器管理页面、局域网内的NAS、或者公司内网的OA系统，流量全被送到代理那边去了，结果就是打不开或者慢得离谱。

我踩过最典型的一次坑是：开着全局模式调试一个本地开发的服务，前端请求后端API一直超时。排查了半天以为是代码问题，最后发现是全局模式把 localhost 的请求也代理走了。这种问题在规则模式下根本不会出现，因为规则里通常会默认排除本地地址。

2.2 全局模式的实操要点与避坑指南

如果你决定用全局模式，有几个操作细节值得注意。

第一，确认客户端的“绕过本地地址”选项。 大多数客户端在全局模式下仍然提供一个“绕过局域网”或“绕过本地地址”的开关。打开它， 192.168.x.x 、 10.x.x.x 、 127.0.0.1 这些地址就不会走代理。这个开关能解决全局模式80%的日常问题。

第二，注意DNS解析的位置。 全局模式下，DNS请求也可能被代理走。有些客户端提供“远程DNS”和“本地DNS”的选项。如果你访问的是一些对DNS地理位置敏感的服务，选错了会导致解析结果不理想。一般来说，全局模式下建议用远程DNS，保证解析结果和出口IP一致。

第三，全局模式下的速度问题。 所有流量都走代理，意味着你的代理线路要承载全部网络活动。如果你同时在下载大文件、看视频、开视频会议，线路压力会很大。这时候要么升级线路，要么切回规则模式让部分流量直连。

下面这张表总结了全局模式的核心特征：

维度	说明
控制粒度	最粗，所有流量统一处理
适用场景	临时统一出口、测试新配置、客户端不支持规则
主要风险	本地网络访问受阻、DNS解析异常、线路压力大
关键设置	绕过局域网开关、DNS模式选择
推荐指数	临时用可以，长期用不推荐

实操心得：我通常把全局模式当作“诊断工具”来用。当规则模式出现问题时，切到全局模式看看是否恢复正常。如果全局正常而规则不正常，说明问题出在规则配置上；如果全局也不正常，说明是代理线路本身的问题。这个排查思路帮我省了很多时间。

3. 直连模式：看似简单却最容易被误解

3.1 直连模式的本质与常见误区

直连模式就是 所有流量都不走代理，直接由本机网络发出 。听起来很简单，但很多人对它的理解有偏差。

最常见的误解是：以为直连模式等于“关闭代理”。其实不完全一样。关闭代理意味着客户端完全不工作，而直连模式是客户端仍然在运行，只是把所有流量都放行直连。区别在于，直连模式下客户端仍然可以做一些事情，比如记录日志、统计流量、或者作为规则模式的“兜底”存在。

另一个误解是：直连模式下网络就一定快。不一定。如果你的本机网络本身就有问题，比如DNS解析慢、路由跳数多，直连反而可能比走代理还慢。直连只是“不经过代理”，不等于“网络优化”。

直连模式真正有用的场景其实不多，但都很关键：

• 代理线路出问题时临时恢复网络 ：线路挂了，切直连至少能保证基本的上网能力
• 访问必须走本地网络的资源 ：比如公司内网系统、本地开发环境
• 需要确认某个问题是否由代理引起 ：切直连对比一下，快速定位问题范围

3.2 直连模式与其他模式的配合使用

直连模式很少单独长期使用，它更多是作为其他模式的补充或兜底。

在规则模式中，通常会有一条“最终规则”：如果所有规则都不匹配，走直连还是走代理？这个默认行为的选择很关键。选直连，意味着未知流量不走代理，安全性更高但可能漏掉一些需要代理的服务；选代理，意味着未知流量都走代理，覆盖更全但可能把不该走的也走了。

我的习惯是： 默认走直连，需要代理的明确加规则。 这样做的逻辑是，未知流量的风险不可控，让它走本地网络至少不会因为代理配置问题导致连接失败。而且从资源占用角度，直连不消耗代理线路带宽，整体效率更高。

在脚本模式中，直连通常作为脚本逻辑的一个分支。比如脚本判断某个请求的目标地址在本地网段内，就返回直连；否则返回代理。这种用法比规则模式更灵活，因为判断条件可以写得很复杂。

注意：直连模式下，客户端的某些功能可能不可用，比如流量统计、访问日志等。如果你需要这些数据，直连模式就不适合长期使用。

4. 规则模式：日常使用的主力选择

4.1 规则模式的分流逻辑与规则类型

规则模式是大多数人日常使用的模式。它的核心思想是： 预设一批规则，每条规则定义一个匹配条件和对应的处理方式，流量逐条匹配，命中即执行。

规则的类型通常包括以下几种：

• 域名规则 ：按域名或域名后缀匹配，比如 *.example.com 走代理， *.local 走直连
• IP段规则 ：按IP地址范围匹配，比如 10.0.0.0/8 走直连
• 地理位置规则 ：按IP归属地匹配，比如国内地址走直连，国外地址走代理
• 进程规则 ：按发起请求的进程名匹配，比如浏览器走代理，下载工具走直连
• 端口规则 ：按目标端口匹配，比如80和443走代理，其他端口直连

这些规则类型可以组合使用，形成一套完整的分流策略。规则模式的强大之处在于，它把复杂的网络分流需求抽象成了“条件-动作”的配对，不需要写代码就能实现相当精细的控制。

但规则模式也有它的局限。最大的问题是 规则是静态的 。你预设了什么规则，它就按什么规则执行。如果遇到规则没覆盖到的情况，只能靠默认规则兜底。而且规则多了之后，维护成本会上升，容易出现规则冲突或遗漏。

4.2 规则配置的实战经验与优化技巧

配置规则模式，我总结了几个实用原则。

原则一：从简到繁，逐步添加。 不要一上来就写几十条规则。先设置几条核心规则，比如“国内直连、国外代理”，用一段时间，发现哪些服务需要单独处理，再逐条添加。这样规则集始终是精简有效的。

原则二：规则顺序很重要。 大多数规则引擎是按顺序匹配的，命中第一条就停止。所以要把最具体、最明确的规则放在前面，最宽泛的规则放在后面。比如 *.example.com 应该放在 *.com 前面，否则后者会先匹配。

原则三：定期清理无效规则。 用了一段时间后，有些规则可能已经不需要了，比如某个服务已经不再使用，或者它的域名已经变更。定期检查规则命中日志，把长期没有命中的规则删掉，保持规则集干净。

原则四：善用规则分组。 很多客户端支持把规则分组管理，比如“工作相关”“娱乐相关”“开发相关”。分组的好处是，你可以按场景启用或禁用某一组规则，而不需要逐条修改。

下面是一个典型的规则配置示例（以通用格式表示）：

# 本地地址直连
DOMAIN-SUFFIX,local,DIRECT
IP-CIDR,127.0.0.0/8,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT

# 常用服务走代理
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY

# 国内地址直连
GEOIP,CN,DIRECT

# 默认规则
MATCH,PROXY

这个配置的逻辑是：本地地址直连，特定服务走代理，国内地址直连，其余走代理。实际使用时，你需要根据自己的需求调整规则内容和顺序。

实操心得：我习惯在规则模式运行一段时间后，查看客户端的连接日志，看看哪些请求走了代理但其实可以直连，哪些请求走了直连但其实需要代理。根据日志调整规则，比凭感觉写规则准确得多。

5. 脚本模式：灵活性的天花板与复杂度的代价

5.1 脚本模式能做什么规则做不到的事

脚本模式把分流决策交给一段代码。这段代码接收请求信息（比如目标地址、端口、进程名等），返回一个决策结果（走代理、直连、拒绝等）。因为是代码，所以判断逻辑可以任意复杂。

举几个规则模式做不到、但脚本模式能轻松实现的例子：

• 按时间段分流 ：工作时间走代理，非工作时间直连
• 按网络状况分流 ：当前线路延迟高时自动切换直连
• 按请求频率分流 ：短时间内大量请求走直连，避免触发代理线路的限制
• 按组合条件分流 ：目标地址是国外且进程是浏览器且端口是443才走代理
• 动态读取外部数据 ：从文件或接口读取最新的分流策略

这些场景在规则模式下要么无法实现，要么需要非常复杂的规则组合才能勉强做到。脚本模式的灵活性是它最大的价值。

但灵活性是有代价的。脚本模式的问题主要有三个：

第一，调试困难。 规则模式出问题了，你看一眼规则列表就能找到原因。脚本模式出问题了，你得读代码、加日志、逐步排查。如果脚本写得复杂，排查时间会很长。

第二，性能开销。 每条请求都要执行一遍脚本逻辑，如果脚本写得不够高效，会明显增加延迟。规则模式的匹配通常是优化过的，速度很快；脚本模式的执行速度取决于代码质量。

第三，维护门槛高。 规则模式谁都能改，脚本模式需要懂编程。如果团队里只有一个人会写脚本，这个人不在的时候其他人很难接手。

5.2 脚本编写的实用建议与性能优化

如果你决定用脚本模式，以下建议能帮你少走弯路。

建议一：脚本逻辑尽量简单。 能用规则实现的，不要用脚本。脚本只用来处理规则覆盖不了的边缘情况。我见过有人把所有分流逻辑都写成脚本，结果几千行代码，维护起来苦不堪言。

建议二：加日志，加日志，加日志。 脚本模式最大的痛点就是“不知道它为什么做了这个决策”。在关键分支上加日志输出，记录匹配条件和决策结果。出问题时看日志，比读代码快得多。

建议三：做好异常处理。 脚本执行出错时，客户端通常会有一个默认行为（走代理或直连）。确保你的脚本在异常情况下也能返回合理的结果，不要让一个未捕获的异常导致所有流量都走错方向。

建议四：性能敏感的场景用缓存。 如果脚本需要做DNS查询、读取文件等耗时操作，考虑加缓存。同样的输入在短时间内重复出现时，直接返回缓存结果，避免重复计算。

建议五：版本管理。 脚本是代码，代码就需要版本管理。每次修改前备份，修改后记录改了什么、为什么改。出问题时可以快速回滚。

下面是一个简单的脚本示例（伪代码，展示逻辑结构）：

function decide(request) {
    // 本地地址直连
    if (isPrivateIP(request.destinationIP)) {
        return "DIRECT";
    }
    
    // 特定域名走代理
    if (request.domain.endsWith(".example.com")) {
        return "PROXY";
    }
    
    // 工作时间走代理，非工作时间直连
    if (isWorkingHours()) {
        return "PROXY";
    }
    
    // 默认直连
    return "DIRECT";
}

这个脚本的逻辑很清晰：本地地址直连，特定域名走代理，工作时间走代理，其余直连。实际编写时，你需要根据客户端的脚本接口调整函数名和返回值格式。

注意：脚本模式的性能影响在高流量场景下会被放大。如果你经常下载大文件或看高清视频，建议把这类流量用规则模式排除掉，不要让它们经过脚本判断。

6. 四种模式怎么选：场景对照与组合策略

6.1 按使用场景选择模式的决策框架

四种模式没有绝对的好坏，只有适不适合当前场景。我整理了一个决策框架，帮你快速判断该用哪种模式。

场景	推荐模式	理由
刚拿到新配置，测试是否可用	全局	最直接，所有流量统一验证
日常上网，国内外服务混合	规则	分流精细，维护成本低
访问公司内网或本地开发	直连	避免代理干扰本地网络
需要按时间段或网络状况动态调整	脚本	规则做不到的动态逻辑
代理线路故障，临时恢复网络	直连	快速恢复基本上网能力
需要统一出口IP做调试	全局	确保所有请求从同一IP发出
多设备多场景混合使用	规则+脚本	规则处理常规分流，脚本处理特殊情况

这个框架的核心逻辑是： 先看需求是静态的还是动态的，再看控制粒度需要多细。 静态需求用规则，动态需求用脚本；粗粒度用全局或直连，细粒度用规则或脚本。

6.2 组合使用与模式切换的实战策略

实际使用中，很少有人只用一个模式。更常见的做法是组合使用，根据场景切换。

我的个人配置是这样的：

• 默认用规则模式 ：覆盖90%的日常场景
• 规则中嵌入脚本判断 ：处理少数需要动态决策的情况
• 保留全局和直连的快捷切换 ：需要时一键切换，不用改配置

这种组合方式的好处是，日常使用无感，特殊场景也能快速应对。

切换模式时，有几点需要注意：

第一，切换后确认DNS设置。 不同模式下DNS的处理方式可能不同。从规则切到全局时，确认DNS是否也跟着切换了。如果DNS没切，可能出现解析结果和出口IP不一致的问题。

第二，切换后检查本地网络。 从直连切到全局时，确认绕过局域网的设置是否生效。否则本地网络访问会中断。

第三，脚本模式下切换要谨慎。 如果脚本逻辑依赖当前模式，切换后脚本可能行为异常。切换前先确认脚本的兼容性。

实操心得：我习惯在客户端的快捷菜单里把四种模式都放上，需要时一键切换。同时给每种模式配一个简单的验证步骤，比如切换后访问一个已知的测试地址，确认网络正常。这个习惯帮我避免了很多“切换后忘了改回来”的问题。

7. 常见问题排查与避坑经验实录

7.1 模式配置中的典型问题与解决方法

问题一：全局模式下本地服务无法访问。

这是最常见的问题。原因是本地地址也被代理走了。解决方法是打开“绕过局域网”开关，或者在规则中明确添加本地地址直连的规则。

问题二：规则模式下某些网站打不开。

可能的原因有三个：规则没覆盖到、规则顺序不对、DNS解析有问题。排查步骤是：先看连接日志确认请求走了哪条规则，再检查规则顺序是否合理，最后确认DNS设置是否正确。

问题三：脚本模式下网络时通时断。

脚本逻辑有bug，某些情况下返回了错误的结果。解决方法是加日志，记录每次决策的输入和输出，找到异常的分支。如果脚本复杂，考虑简化逻辑或拆分成多个简单脚本。

问题四：切换模式后网络没变化。

可能是客户端没有真正应用新配置。尝试重启客户端，或者手动触发一次配置重载。有些客户端需要点击“应用”按钮才会生效。

问题五：直连模式下某些服务反而更慢。

直连不等于优化。如果本机网络本身有问题，直连可能比走代理还慢。这时候需要排查本机网络，而不是代理配置。

下面这张速查表总结了常见问题和对策：

问题现象	可能原因	排查方向	解决方法
本地服务无法访问	本地地址被代理	检查绕过局域网设置	打开绕过开关或加直连规则
部分网站打不开	规则未覆盖或顺序错误	查看连接日志	调整规则内容或顺序
网络时通时断	脚本逻辑异常	检查脚本日志	修复脚本bug或简化逻辑
切换模式无效	配置未应用	确认客户端状态	重启客户端或手动重载
直连反而更慢	本机网络问题	排查本机网络	检查DNS和路由设置

7.2 长期使用中的维护建议与经验总结

用了几年这类工具，我最大的体会是： 配置越简单，维护越轻松。 一开始总想把所有场景都覆盖到，规则写了几百条，脚本写了几千行，结果每次出问题都要花大量时间排查。后来慢慢精简，只保留真正需要的规则和脚本，反而更稳定。

几个具体的维护建议：

定期审查规则和脚本。 每个月花十分钟看看哪些规则长期没命中，哪些脚本分支从没执行过。删掉无用的部分，保持配置精简。

保留一份最小可用配置。 当复杂配置出问题时，能快速切换到一个简单可靠的配置，保证基本使用。这份最小配置通常就是“国内直连、国外代理”两条规则。

记录每次修改。 改了哪条规则、为什么改、改后效果如何。这些记录在出问题时非常有用，能帮你快速定位是哪次修改引入的问题。

不要频繁切换模式。 每次切换都有成本，而且容易忘记切回来。尽量让默认模式覆盖大多数场景，减少切换频率。

关注客户端的更新日志。 新版本可能改变了某些模式的行为，或者增加了新的功能。及时了解这些变化，避免配置失效。

最后分享一个我踩过的坑：有一次我把脚本模式设成了默认模式，脚本里有个逻辑是“如果当前时间在凌晨2点到4点之间，走直连”。结果有一天凌晨3点我需要访问一个必须走代理的服务，怎么都连不上，排查了半小时才想起来是脚本的时间判断在起作用。从那以后，我在脚本里加了一条“手动覆盖”的逻辑，可以通过一个开关强制走代理，避免被自动逻辑困住。

这个内容后续还可以这样扩展：如果你用的是特定客户端，可以进一步研究它的规则语法和脚本接口，写出更贴合自己需求的配置。不同客户端的实现差异挺大的，通用逻辑理解之后，具体操作还是要看文档。