Clash Verge 绕过规则如何设置才能避免本地访问异常？
Clash Verge 绕过规则设置不当常导致本地服务访问异常。本文分平台给出最短配置路径与取舍建议，助你兼顾代理效率与本地调试稳定。
从一次本地调试失败说起：绕过规则为何总被忽略
很多运营者第一次接触 Clash Verge 绕过规则，往往不是因为想优化代理，而是因为某个本地服务突然连不上了。典型场景是：你在本机起了个开发服务器，地址是 http://127.0.0.1:3000，浏览器却返回代理错误；或者公司内网的 OA 系统在开启系统代理后无法登录。这类问题看着像是客户端出了故障，但根源通常不在 Clash Verge 本身，而在于绕过规则没有覆盖本地回环地址与局域网网段。
Clash Verge 是一款基于 Clash 内核的图形客户端，其中的绕过规则（Bypass）决定了哪些流量不经过代理、直接放行。它的定位是「系统代理的补充白名单」，而非「全局代理的替代品」。先把这条边界厘清，后续的每一步配置决策才有依据——否则很容易在一个本不属于它的层级上反复调整。
功能定位与边界：绕过规则到底管什么
在 Clash Verge 中，系统代理（System Proxy）与绕过规则是绑定生效的。当你开启系统代理时，操作系统会将 HTTP/HTTPS 请求转发到 Clash 的混合端口；而绕过规则则告诉系统：「这些地址不要发给代理，直接连」。因此，它只对走系统代理的流量生效。至于 TUN 模式或应用层自行设置代理的流量，绕过的行为逻辑会有所不同，需要另找入口。
归纳起来，绕过规则的核心作用是：让本地回环（loopback）、局域网（LAN）以及特定国内域名绕过代理，避免出现「本地服务被代理吞掉」或「内网访问被错误转发」的情况。它不负责分流规则中的域名匹配，那是规则集（Rule Set）的职责。两者容易混淆，但作用层级完全不同——一个是系统层面的白名单，一个是内核层面的路由判断。
提示：如果你使用的是 TUN 模式，绕过规则的表现取决于内核的 bypass 配置项，而非系统代理的白名单。此时应优先检查内核配置，而非 GUI 中的系统代理绕过列表。
对比选择：系统代理绕过 vs 规则集分流 vs TUN 排除
面对本地访问异常，运营者通常有三条路可走。第一条是修改系统代理绕过列表，这是最轻量的方式，只影响走系统代理的应用；第二条是在规则集中添加 DIRECT 规则，这种方式对所有流量生效，但需要理解规则优先级；第三条是在 TUN 模式下配置排除路由，适合需要全局接管流量的场景，但配置复杂度最高。
从取舍角度看，如果你的痛点只是「浏览器打不开本地服务」，修改系统代理绕过列表已经足够，副作用也最小。如果内网多个应用都需要直连，且你长期开启 TUN 模式，那么规则集或 TUN 排除才是更稳定的方案。经验性观察表明，多数本地访问异常通过补齐 127.0.0.1、localhost 和局域网网段即可解决。换句话说，先用代价最低的手段验证判断，再决定是否升级到更重的方案。
决策树：什么情况下该动绕过规则
在动手之前，建议先按以下顺序判断。第一步，确认异常是否只在开启系统代理后出现；关闭系统代理后恢复正常，则问题大概率在绕过规则。第二步，确认异常地址是本地回环、局域网 IP，还是公网域名——前两者适合用绕过规则处理，后者更适合用分流规则。第三步，确认你当前使用的是系统代理模式还是 TUN 模式，这决定了配置入口在哪里。
如果以上三步都指向系统代理绕过，那么可以进入具体操作。不过还有一层变量需要考虑：若你的客户端是移动端，Android 与 iOS 的系统代理机制并不相同，绕过规则的可用性和写法也有差异，桌面端的经验不能直接照搬。
桌面端最短操作路径：Windows 与 macOS
在 Clash Verge 桌面端，绕过规则的入口通常位于「设置」或「系统代理」相关区域。以常见版本的界面为例，最短路径是：打开 Clash Verge 主界面 → 进入「设置」→ 找到「系统代理」区域 → 点击「绕过规则」或「Bypass」编辑按钮。不同版本的文案可能略有差异，若界面显示为英文，则查找 Bypass 或 Proxy Bypass。若你的界面与上述描述不符，可以按此特征自行核对入口位置。
进入编辑框后，你会看到一行由分号或逗号分隔的地址列表，常见的默认值可能包含 localhost、127.0.0.1、::1 等。如果本地服务仍然异常，可以按以下顺序补齐：先加入 127.0.0.1 和 localhost，再加入 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 这三个私有网段。保存后，系统代理会自动重启，通常无需手动断开重连。
若保存后仍不生效，可以尝试关闭系统代理再重新开启，让新的绕过列表被操作系统重新读取。这一步在 Windows 上尤其常见，因为系统代理设置有时会被其他网络工具覆盖——此时列表本身没问题，问题出在没人去读它。
移动端差异：Android 与 iOS 的注意事项
Android 端的 Clash Verge 同类客户端通常以 privacy tool 模式运行，绕过规则更多体现为「应用绕过」或「分应用代理」。如果你只想让某个本地调试应用直连，可以在分应用代理中将其设为「直连」或「绕过」。需要说明的是，Android 不同发行版对 privacy tool 的绕过支持程度不一，部分定制系统可能限制局域网直连，此时应查阅设备厂商的网络说明。
iOS 端的情况则更受系统限制：第三方客户端无法像桌面端那样自由编辑系统代理绕过列表。iOS 上的 Clash 类客户端一般通过 privacy tool 描述文件工作，其绕过行为由客户端内部的规则决定，而非系统级白名单。因此，iOS 用户若遇到本地访问异常，应优先检查客户端内的规则配置，而不是寻找「系统代理绕过」入口。经验性观察表明，iOS 端更依赖规则集来实现直连，而非系统级绕过——把桌面端的思路平移过来，往往会白费力气。
该纳入哪些例外：常见绕过项清单
绕过规则不是越多越好。列表过长会增加系统匹配开销，也可能让某些本应走代理的域名意外直连。以下清单按优先级排列，供你按需取舍，而不是照单全收。
- 本地回环：
127.0.0.1、localhost、::1。这是必选项，缺失会直接导致本地开发服务不可用。 - 私有网段：
10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。适合有内网 OA、NAS、打印机访问需求的用户。 - 链路本地地址：
169.254.0.0/16。部分设备发现协议会用到，通常建议保留。 - 特定域名：如公司内部域名或测试域名。这类应按需添加，避免泛化到整个顶级域。
如果你的工作环境没有内网服务，那么只保留回环地址即可，无需添加全部私有网段。边界在于：一旦你加入了某个网段，该网段内的所有地址都会绕过代理，包括那些本应走代理的测试环境。因此，添加前先确认该网段内没有需要代理的地址——这一条比清单本身更值得记住。
副作用与缓解：绕过规则可能带来的问题
绕过规则最典型的副作用是「该走代理的没走」。例如，某运营者为了访问内网测试机，把整个 192.168.0.0/16 加入了绕过列表，结果发现某个使用局域网 IP 的第三方 API 无法连通。这类问题往往难以第一时间定位，因为开发者容易默认所有 192.168.x.x 都是本地设备。
缓解方法有两种。第一种是精确化：只添加实际需要的具体 IP，而不是整个网段。第二种是分层验证：修改绕过规则后，用浏览器分别访问一个本地地址和一个公网地址，确认前者直连、后者走代理。可复现的验证步骤是：在浏览器开发者工具的「网络」面板中查看请求的远程地址，若本地请求的远程地址显示为 127.0.0.1，则绕过生效；若显示为代理端口，则未生效。两种方法可以叠加使用，先精确、后验证。
注意：绕过规则中的通配符与 CIDR 写法因客户端版本而异。若你不确定当前版本是否支持 10.0.0.0/8 这类写法，建议先用单个 IP 测试，确认生效后再扩展为网段。
与机器人或第三方工具的协同：权限最小化原则
部分用户会通过第三方机器人或自动化脚本管理 Clash 配置。在这种情况下，绕过规则可能被远程下发或覆盖，本地的手动修改未必会被保留。若你使用此类方案，应遵循权限最小化原则：只允许机器人修改规则集或绕过列表中的特定字段，而不是整个配置文件。这样即使自动化出错，也不会导致系统代理完全失效。
需要强调的是，本文不推荐任何具体的第三方机器人名称，因为其可用性和安全性随时可能变化。如果你确有自动化需求，建议优先使用客户端自带的配置订阅功能，并定期备份本地绕过列表。一旦发现本地访问异常，先断开自动化同步，再手动检查绕过规则是否被覆盖——排查顺序反了，就很容易在错误的方向上消耗时间。
故障排查：现象、原因与处置
以下按「现象 → 可能原因 → 验证 → 处置」的结构整理常见问题，便于快速定位，而不是凭感觉逐个试。
现象一：浏览器访问 localhost 返回代理错误。可能原因是绕过列表缺少回环地址。验证方法是关闭系统代理后重试，若恢复正常则确认原因。处置是补齐 127.0.0.1 与 localhost，保存后重试。
现象二：内网 OA 无法登录，但公网访问正常。可能原因是私有网段未加入绕过列表。验证方法是查看 OA 地址是否属于 10.x 或 192.168.x。处置是添加对应网段，或仅添加 OA 的具体 IP。
现象三：修改绕过规则后仍不生效。可能原因是系统代理未重新加载，或配置被其他网络工具覆盖。验证方法是在系统网络设置中查看代理例外列表是否已更新。处置是关闭再开启系统代理，或重启客户端。
现象四：TUN 模式下本地访问异常。可能原因是内核层面未排除回环路由。验证方法是暂时关闭 TUN 模式，观察是否恢复。处置是查阅内核文档中关于 bypass 或排除路由的说明，而非仅修改系统代理绕过列表。
适用与不适用场景清单
为了帮助你快速判断是否应该调整绕过规则，以下列出典型适用与不适用场景。判断标准只有一条：异常流量是否经过系统代理。
| 场景 | 是否适用 | 说明 |
|---|---|---|
| 本地开发服务器访问 | 适用 | 加入回环地址即可解决 |
| 内网 OA、NAS 访问 | 适用 | 按需加入私有网段或具体 IP |
| 公网域名分流 | 不适用 | 应使用规则集而非系统代理绕过 |
| TUN 模式下的全局接管 | 部分适用 | 需检查内核排除路由，而非仅改 GUI |
| iOS 端本地直连 | 不适用 | iOS 受系统限制，应改用规则集 |
最佳实践清单：决策规则与检查表
最后，将前面讨论的内容浓缩为一份可落地的检查表。每次调整绕过规则前，按以下顺序核对，可以减少反复试错。
- 先确认异常是否由系统代理引起，再决定是否动绕过规则。
- 优先保留回环地址，这是本地开发的底线配置。
- 私有网段按需添加，避免无差别的全段绕过。
- 修改后立即用本地地址和公网地址各测一次，确认行为符合预期。
- 定期备份绕过列表，防止被订阅或自动化工具覆盖。
- TUN 模式用户应区分系统代理绕过与内核排除，不要混用入口。
- 移动端用户应了解平台限制，iOS 上不要期待桌面端同款绕过入口。
按这份清单执行后，多数「本地访问异常」都能在几分钟内定位。如果问题依旧，建议回到决策树的第一步，重新确认代理模式与异常范围，而不是继续堆叠绕过项——堆得越多，排查的干扰项也越多。
FAQ：常见问题与边界说明
绕过规则加得越多越稳定吗？
为什么 Android 上找不到系统代理绕过入口？
修改绕过规则后需要重启客户端吗？
TUN 模式下的本地访问异常该改哪里？
下一步行动建议
回到你的实际环境：先打开 Clash Verge 的系统代理设置，检查绕过列表是否包含回环地址；如果包含，再按本文的故障排查顺序逐项验证。若你使用的是 TUN 模式或移动端，请先确认对应平台的配置入口，避免在错误的层级上反复修改。绕过规则的本质是「最小必要放行」——理解这一点，就能在本地访问与代理效率之间找到平衡，也能在下次遇到类似异常时，更快地判断出该动哪一层配置。
