VPN分流规则怎么设置：按应用、域名与设备完成配置

更新于 2026-10-26 · lvcha.online

简答：VPN分流规则的正确顺序是：先确认客户端接管方式，再确定默认代理或默认直连，最后添加应用、域名、IP和局域网例外。设置后必须用出口IP、DNS、客户端日志和局域网访问分别验证，不能只看“已连接”。

定义：VPN分流是把不同应用、域名、IP网段或端口分别送入VPN隧道或本地网络的路由方式。

先用这张表确定分流方向

按2026-10界面核对，VPN分流并不是一个单一开关。先判断客户端到底使用系统代理、应用分流、域名规则，还是TUN（虚拟网卡）接管；不同接管方式能匹配的对象不同。

模式或接管方式	适合解决的问题	常见限制	默认策略建议
全局代理	临时确认隧道和节点是否可用	所有支持代理的流量都可能进入代理	只用于测试，不宜作为长期规则设计
规则模式	按域名、IP、端口或网络类型分流	规则顺序、DNS和应用内置解析可能影响结果	先选默认代理或默认直连，再添加例外
应用分流	只让指定应用进入VPN，或排除指定应用	启动器、子进程和后台服务可能不在列表内	确认“允许列表”和“排除列表”没有选反
TUN或虚拟网卡	接管不遵守系统代理的程序、命令行和部分后台流量	可能影响局域网、IPv6、UDP和DNS	先放行局域网，再逐步增加域名或应用规则
系统VPN分流	企业内网、指定网段或受管设备的路由	系统原生能力通常以路由、应用和流量过滤为主，不等同于域名规则	用明确网段和应用过滤器，保留兜底规则

Windows原生VPN配置支持分流路由、应用触发和流量过滤；微软文档还区分了SplitTunnel与ForceTunnel等路由策略，不能把系统VPN和代理客户端的规则语法混为一谈。可查看Windows VPN profile options与Windows VPN technical guide。

通用设置顺序：四步避免规则方向设反

列出需要代理的对象。先写应用、完整域名、域名后缀、IP/CIDR（无类别域间路由，用于表示网段）、端口和局域网网段，不要一开始就复制大段规则集。
确定默认策略。“默认代理”表示未命中其他规则时进入VPN；“默认直连”表示未命中时使用本地网络。新手建议先用默认直连，只为明确目标添加代理规则，便于回滚。
把例外规则放在兜底规则前。局域网、回环地址、企业内网和必须直连的域名，应放在默认规则之前；最后才放MATCH、final或同类兜底规则。
保存、重连、验证。订阅更新可能覆盖本地修改，保存后断开并重新连接；若客户端提供规则命中或连接日志，应确认目标请求命中了预期规则。

规则列表通常按从上到下匹配，顶部规则优先级更高。mihomo文档列出了DOMAIN、DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME、NETWORK和MATCH等规则类型，并明确说明规则顺序影响匹配结果，详见mihomo路由规则文档。

一个通用设计可以写成：局域网直连 → 明确的应用或域名代理 → 明确的公网直连例外 → 最后兜底。不要把“国内直连”或“国外代理”当成客户端必然支持的固定按钮，实际行为取决于规则集、DNS和客户端内核。

按设备设置：Windows、Android、iPhone与macOS

Windows：先确认使用的是系统VPN、系统代理还是带TUN的客户端。系统VPN优先配置目标网段、应用触发或流量过滤；代理客户端则进入路由、分流或规则页面，选择默认策略后添加进程、域名或IP规则。验证时分别检查浏览器、命令行工具和局域网地址，因为系统代理不代表所有程序都会遵守代理。

Android：在客户端的分流或应用列表中先确认是“允许列表”还是“排除列表”。允许列表通常意味着只有选中的应用使用VPN，未选中的应用按系统网络访问；排除列表则相反。Android的VpnService接口也区分addAllowedApplication与addDisallowedApplication，且两类列表不能同时使用，可参考Android VPN官方说明。保存后重新建立VPN连接，再分别测试目标应用和未选中的应用。

iPhone与iPad：普通个人VPN的分流能力取决于客户端和系统配置，不能假定系统设置里一定能按任意应用自由切换。Apple文档将Per-App VPN描述为受管理设备和配置文件场景，支持按受管应用或指定域名控制流量，相关限制见Apple VPN security说明与Apple Network Extension路由文档。如果客户端只有全局开关而没有规则页面，应以客户端实际显示的能力为准。

macOS：先区分系统VPN配置和TUN/代理客户端。系统VPN更适合指定路由或企业资源；需要按进程、域名和网络类型分流时，应使用明确支持这些匹配项的客户端。测试时不要只用浏览器，至少再测一个命令行程序、一个局域网地址和一个DNS查询。

每个平台都按“导入配置—开启分流—验证结果”三步做：导入订阅或配置文件；开启规则、应用分流或TUN；查看出口IP、DNS、日志和局域网访问。日志入口名称因客户端不同，通常位于“日志、连接、规则命中、诊断或运行记录”，页面未显示该入口时不要自行猜测。

Clash Meta规则示例：语法不要与sing-box混用

下面是Clash Meta或mihomo风格的最小示例，仅用于展示规则顺序。PROXY、DIRECT和FINAL需要替换成配置中真实存在的策略组或出站名称；示例域名和网段仅作结构演示。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,work.example,DIRECT
  - PROCESS-NAME,example-app.exe,PROXY
  - DOMAIN-SUFFIX,service.example,PROXY
  - MATCH,DIRECT

no-resolve会影响目标IP规则触发DNS解析的行为，不能在不了解客户端实现时随意添加。应用规则还要确认实际进程名；启动器、主程序和子进程可能是不同名称。Windows路径、Android包名和macOS进程匹配也可能因客户端能力不同而变化。

如果使用规则集合，应先确认规则集合的格式。mihomo文档区分classical、domain和ipcidr等内容格式，详见mihomo rule-providers文档。不要把带YAML字段的规则集合直接当成另一种客户端的JSON配置导入。

sing-box规则示例：路由和DNS要分别设计

sing-box使用JSON配置，路由规则的字段与Clash Meta不同。官方路由文档支持domain、domain_suffix、ip_cidr、process_name、process_path、package_name、network_type等匹配项，并通过action和outbound指定处理方式，详见sing-box Route Rule。

{
  "route": {
    "rules": [
      {
        "ip_is_private": true,
        "action": "route",
        "outbound": "direct"
      },
      {
        "domain_suffix": ["work.example"],
        "action": "route",
        "outbound": "direct"
      },
      {
        "package_name": ["com.example.app"],
        "action": "route",
        "outbound": "proxy"
      }
    ],
    "final": "direct"
  }
}

上例只表达结构：direct和proxy必须与实际outbound标签一致，Android应用还需要填写设备中真实存在的包名。sing-box路由规则按配置顺序处理，版本变化也可能引入字段迁移，因此应以当前版本官方文档为准。

DNS不能只看路由结果。sing-box单独提供DNS服务器、DNS规则和final等配置项；DNS规则可以把查询送到不同服务器，官方说明见sing-box DNS文档。如果路由已经直连但DNS仍走另一条路径，可能出现域名解析失败、返回地址不匹配或看似“规则不生效”的现象。

规则不生效时，按这份清单定位

先看客户端是否真的接管流量。系统代理只影响遵守代理设置的程序；TUN或虚拟网卡才可能接管更多非代理流量，但也会增加局域网、IPv6和UDP排查项。
检查规则是否被订阅覆盖。重新更新订阅后，本地规则可能被替换、追加到错误位置，或策略组名称发生变化。
检查域名是否完整。一个应用可能访问主域名、静态资源、登录域名、API域名和CDN域名；只添加一个域名不代表整个应用都会命中。
检查DNS路径。分别测试普通域名、目标域名和内网域名；如果只有域名访问失败而IP可用，优先查看DNS规则、内置DNS、FakeIP和应用内置DNS。
检查IPv6与UDP/QUIC。只写IPv4规则时，IPv6请求可能走另一条路径；浏览器使用QUIC时，TCP规则命中情况也不能直接代表UDP结果。
检查进程与子进程。启动器可能只负责拉起主程序，真正联网的是另一个进程；按应用分流时要在日志中确认实际命中的进程名或包名。
保留回滚方案。修改前导出配置或复制原文件；出现全网断网时，先关闭TUN或分流，恢复默认直连，再逐条加回规则。

建议每次只改一类变量，并记录“时间、网络类型、客户端模式、目标域名、出口IP、DNS、是否命中规则、日志关键行”。这样可以区分规则错误、DNS错误和线路本身的问题，而不是反复切换节点。

可复制的分流验证记录模板

以下模板适合连续测试多次。不要把单次结果写成稳定结论；无独立数据时，只能记录本机在指定时间和网络下的观察。

日期：2026-10-26
时间段：
网络：Wi-Fi / 手机网络 / 有线
设备与系统：
客户端与模式：系统代理 / 应用分流 / TUN / 系统VPN
默认策略：默认代理 / 默认直连
目标应用或域名：
预期路径：代理 / 直连
实际出口IP：
DNS结果：
规则命中：
局域网访问：成功 / 失败
TCP测试：成功 / 失败
UDP或QUIC测试：成功 / 未测试
客户端日志关键行：
修改内容与回滚结果：

至少做三组对照：关闭VPN、开启全局或全量接管、开启目标分流规则。若只有目标规则异常，再比较DNS、IPv6、UDP和应用子进程；若全局模式也失败，则优先排查配置、网络或连接本身。

遵守所在地法律与服务条款。多网络、多设备对照后仅目标服务异常时，可考虑已公开主体信息的服务。

常见问题

VPN分流规则应该默认代理还是默认直连？

没有统一答案。需要少量对象进入VPN时，通常先用默认直连并添加明确代理规则；需要大部分流量进入VPN时，才考虑默认代理，再添加局域网和特定直连例外。关键是能否清楚回滚和验证。

为什么规则写对了，但浏览器仍然没有按预期分流？

先确认浏览器是否使用系统代理，其次检查DNS、IPv6和QUIC，再查看实际访问的主域名、API域名和CDN域名。只写一个页面域名，通常不足以覆盖整个应用请求。

允许列表和排除列表有什么区别？

允许列表是只让被选中的应用使用VPN，未选中的应用按系统网络访问；排除列表是让大多数应用使用VPN，只把被选中的应用放回系统网络。两者方向相反，不要只看“应用分流”这个名称。

手机上能不能像电脑一样按任意域名分流？

取决于客户端内核和系统权限。Android客户端可能同时支持应用、域名和IP规则；iPhone的系统级Per-App VPN通常涉及受管设备和配置文件。若客户端没有域名规则入口，不能假定系统会自动提供该能力。

局域网打印机或NAS在开启TUN后无法访问怎么办？

先临时关闭TUN确认问题是否由接管造成，再把局域网网段放到直连规则前面，并检查IPv4与IPv6是否都被覆盖。修改后重新连接，分别测试设备IP、主机名和网页管理地址。

Clash Meta和sing-box的规则能直接互换吗？

不能直接互换。Clash Meta常见的是YAML规则行和策略组名称，sing-box使用JSON对象、action和outbound字段；应按对应内核的官方格式重新转换，并检查策略标签是否真实存在。

订阅更新后本地分流规则为什么消失？

部分客户端会重新生成配置或覆盖本地规则。更新前导出配置，更新后检查规则顺序、策略组名称和本地覆写功能；如果客户端没有覆写能力，只能把自定义规则放入可持久化的配置文件或规则集合。