外观
规则分流怎么配
规则分流是机场相对 VPN 最大的功能优势。
VPN 通常接管全部流量，国内访问也走隧道（可能变慢），也不能为不同服务选不同出口。机场配合支持规则的客户端，可以做到：
国内域名 → 直连（不绕远、不耗流量）
AI 服务域名 → 验证通过的新加坡节点
Netflix 域名 → 解锁通过的节点
视频会议域名 → 香港专线节点（丢包 ≈ 0）
YouTube / 下载 → 大带宽、低倍率节点
其余 → 默认香港节点这不是"高级功能"，而是让机场发挥价值的基础配置。 不配规则的机场，体验上不如一个 VPN。
最重要的一条：国内域名直连
三个原因
| 原因 | 说明 |
|---|---|
| 绕远 | 国内网站走境外节点，路径从"本地几毫秒"变成"跨境往返几十毫秒" |
| 消耗流量 | 国内访问的流量本来不该计入套餐 |
| 可能触发异常 | 部分国内服务对境外 IP 有额外的验证或限制 |
最常见的症状
"装了机场以后国内网站变慢了"——这几乎一定是规则配错了，不是机场质量问题。
| 症状 | 原因 |
|---|---|
| 国内网站加载变慢 | 国内域名走了代理 |
| 国内视频卡顿 | 同上，而且消耗套餐流量 |
| 国内 App 提示异常 | 出口 IP 在境外 |
| 流量消耗远超预期 | 国内流量也在计费 |
怎么确认
看客户端的连接日志。 访问一个国内网站，日志里该请求的出口应该显示 DIRECT（直连），而不是某个节点名。
多数机场提供的 Clash / sing-box 配置里已包含国内直连规则，所以默认情况下通常是对的。风险出现在你自己改配置的时候——加了一条兜底规则放在前面，把国内域名也捕获了。
规则的基本原理
自上而下，第一条命中即生效
规则 1：域名匹配 openai.com → 新加坡节点
规则 2：域名匹配 netflix.com → 解锁节点
规则 3：域名属于国内域名集合 → DIRECT
规则 4：（兜底）所有其余流量 → 香港节点一个请求从上往下匹配，命中第一条就停止。 所以：
| 原则 | 说明 |
|---|---|
| 具体的规则放前面 | 单个域名、特定服务 |
| 范围大的规则放后面 | 域名集合、地区规则 |
| 兜底规则放最后 | 匹配所有剩余流量 |
| 顺序错了的后果 | 后面的规则永远不会被匹配到 |
最常见的顺序错误：把兜底规则（MATCH / final）放在了中间，导致它下面的所有规则失效。
常见的规则类型
| 类型 | 匹配什么 | 举例用途 |
|---|---|---|
| 域名精确匹配 | 完整域名 | 单个服务 |
| 域名后缀匹配 | 某域名及其子域名 | 一家服务的全部子域 |
| 域名关键词匹配 | 域名中包含某字符串 | 宽松匹配 |
| 规则集 / 域名集合 | 一组预定义的域名 | 国内域名集合、广告域名集合 |
| IP 段匹配 | 目标 IP 属于某网段 | 游戏服务器、国内 IP 段 |
| 地理位置匹配 | 目标 IP 的国家归属 | 国内 IP 直连 |
| 端口匹配 | 特定端口 | 特定协议的流量 |
| 进程匹配 | 发起请求的程序 | 某个应用单独走某节点 |
| 兜底 | 所有其余 | 必须有且放最后 |
最实用的三种是：域名后缀、规则集（国内域名集合）、兜底。 大部分需求用这三种就能覆盖。
为什么要用规则集而不是逐个写域名
国内域名有几万个，不可能手写。规则集是维护好的域名列表，客户端定期从远程更新。
| 常见规则集 | 用途 |
|---|---|
| 国内域名集合 | 国内域名直连 |
| 国内 IP 段集合 | 国内 IP 直连 |
| 广告域名集合 | 广告拦截（可选） |
| 各类服务的域名集合 | 特定服务分流 |
机场提供的配置通常已引用了成熟的规则集。 你只需要在它们之前插入自己的几条规则。
策略组：让配置可维护
为什么需要策略组
如果规则直接指向具体节点：
规则：openai.com → "香港 IEPL 03"节点改名或下线后，这条规则就失效了。 而机场会定期调整节点。
用策略组：
规则：openai.com → 策略组 "AI"
策略组 "AI" 里包含：新加坡 01、日本 02节点变动时只改策略组，不用动规则。 规则可以写一次用很久。
常见的策略组设计
| 策略组名 | 包含什么节点 | 被哪些规则指向 |
|---|---|---|
| 会议 | 丢包 ≈ 0 的香港节点（主 + 备） | 视频会议域名 |
| AI | 验证通过的新加坡 / 日本节点 | AI 服务域名 |
| 流媒体 | 解锁通过的节点 | Netflix / Disney+ 域名 |
| 大带宽 | 大带宽、低倍率的机房 IP 节点 | YouTube、下载 |
| 游戏 | 低抖动、支持 UDP 的节点 | 游戏域名 / IP 段 |
| 默认 | 延迟最低的香港节点 | 兜底规则 |
| 直连 | （不含节点，直接直连） | 国内域名 / IP |
策略组的选择模式
| 模式 | 行为 | 适合 |
|---|---|---|
| 手动选择 | 你指定用组里的哪个节点 | 关键场景（会议、AI） |
| 自动选择（延迟最低） | 按延迟自动挑 | 日常浏览 |
| 故障转移 | 当前节点失效时切下一个 | 需要高可用的场景 |
| 负载均衡 | 请求分散到多个节点 | 下载（谨慎用，可能影响会话） |
关键场景建议用手动选择或故障转移，不要用"自动选择延迟最低"。 原因：延迟最低的节点可能是丢包最高的（超卖的典型特征），自动选择会把你切到那里。
负载均衡对需要保持会话的服务（登录态、流媒体播放）可能造成问题，因为不同请求走了不同出口 IP。
一个完整的规则方案
按优先级从上到下。
| 序号 | 规则 | 指向 | 说明 |
|---|---|---|---|
| 1 | 客户端自身的更新与订阅域名 | 直连或指定节点 | 避免自我依赖导致更新失败 |
| 2 | 局域网 IP 段（192.168.*、10.* 等） | DIRECT | 本地设备互访 |
| 3 | AI 服务域名 | 策略组「AI」 | 你验证通过的地区节点 |
| 4 | 视频会议域名 | 策略组「会议」 | 丢包 ≈ 0 的节点 |
| 5 | Netflix / Disney+ 域名 | 策略组「流媒体」 | 解锁通过的节点 |
| 6 | YouTube 域名 | 策略组「大带宽」 | 只看带宽 |
| 7 | 游戏域名 / IP 段 | 策略组「游戏」 | 低抖动 + UDP |
| 8 | 下载相关域名 | 策略组「大带宽」 | 低倍率优先 |
| 9 | 广告域名集合（可选） | REJECT | 拦截 |
| 10 | 国内域名集合 | DIRECT | 最重要的一条 |
| 11 | 国内 IP 段集合 | DIRECT | 补充上一条 |
| 12 | 地理位置为国内的 IP | DIRECT | 兜底的国内判断 |
| 13 | 兜底：其余全部 | 策略组「默认」 | 必须放最后 |
几个容易忽略的细节
第 1 条：客户端自身的流量。 如果客户端更新订阅的请求也走了代理，而代理又依赖订阅——就会形成循环依赖，节点全部失效时无法恢复。把订阅域名设为直连（或用一个固定可用的节点）能避免这个死锁。
第 2 条：局域网。 不加这条，访问路由器管理界面、局域网 NAS、打印机都可能失败。
第 10–12 条的顺序： 域名集合 → IP 段集合 → 地理位置。域名匹配最快，地理位置需要查询 IP 归属，放后面减少开销。
第 13 条必须在最后。 放在中间会让下面的规则全部失效。
各客户端的语法差异
逻辑一致，写法不同。 下面只说各自的特点，具体语法以客户端文档为准。
| 客户端 | 配置格式 | 特点 |
|---|---|---|
| Clash Verge Rev | YAML | 策略组与规则集生态最成熟，可视化编辑 |
| sing-box | JSON | 规则最灵活（出站 + 路由规则），门槛最高 |
| Shadowrocket | 配置文件 | iOS 上体验最好，规则写法自成一套 |
| v2rayN | 图形化路由设置 | 界面直观，灵活性不如前两者 |
| v2rayNG | 图形化路由规则 | 同上 |
Clash 系的要点
| 概念 | 说明 |
|---|---|
proxies | 节点列表 |
proxy-groups | 策略组 |
rules | 规则列表，自上而下 |
rule-providers | 远程规则集 |
MATCH | 兜底规则关键字，放最后 |
DIRECT / REJECT | 直连 / 拦截 |
sing-box 的要点
| 概念 | 说明 |
|---|---|
outbounds | 出站（相当于节点与策略组） |
route.rules | 路由规则 |
route.final | 兜底出站 |
rule_set | 规则集 |
direct / block | 直连 / 拦截出站 |
sing-box 的规则默认不是严格自上而下的单一语义（它支持逻辑组合），所以迁移 Clash 规则时不能逐条照搬——要按 sing-box 的文档重写。
不要跨客户端照搬配置
| 差异 | 后果 |
|---|---|
| 规则语法不同 | 直接报错或规则不生效 |
| 匹配语义不同 | 规则看起来对但行为不同 |
| 支持的规则类型不同 | 某些规则被忽略 |
| TUN 实现不同 | 覆盖范围不同 |
每个平台单独配，或使用支持跨平台的规则集格式。
配完必须验证
不要假设规则生效了。 配错的表现往往很隐蔽。
| 检查 | 怎么做 | 期望 |
|---|---|---|
| 国内域名走直连 | 访问国内网站，看日志 | 显示 DIRECT |
| 局域网可访问 | 打开路由器管理界面 | 能打开 |
| AI 请求走指定节点 | 打开 AI 服务，看日志 | 显示策略组「AI」里的节点 |
| 流媒体走解锁节点 | 打开流媒体，看日志 | 显示策略组「流媒体」里的节点 |
| 下载走大带宽节点 | 开始一个下载，看日志 | 显示「大带宽」里的节点 |
| 默认节点正确 | 跑一次测速 | 走的是「默认」组 |
| 订阅能更新 | 手动更新订阅 | 成功 |
第一项最重要也最容易配错。 它的表现只是"国内网站稍微变慢"，不会完全失效，所以容易被忽略或误判成机场问题。
常见配错与排查
| 症状 | 最可能的原因 | 怎么修 |
|---|---|---|
| 国内网站变慢 | 国内域名走了代理 | 检查国内规则的位置与走向 |
| 部分规则完全不生效 | 兜底规则放在了它们前面 | 把兜底移到最后 |
| 路由器管理界面打不开 | 缺少局域网直连规则 | 加局域网 IP 段直连 |
| 订阅无法更新 | 订阅域名走了失效的节点 | 把订阅域名设为直连 |
| AI 还是失败 | 规则没命中，或节点本身不行 | 看日志确认走了哪个出口 |
| 流媒体走了错节点 | 规则顺序或域名匹配范围问题 | 检查是否被前面的规则捕获 |
| 流量消耗异常 | 国内流量也在计费，或误用高倍率节点 | 检查国内直连 + 节点倍率 |
| 某个程序不走代理 | 需要 TUN 模式 | 见 TUN 模式 |
| 改了配置但没生效 | 未重新加载配置 | 重新选择配置或重启客户端 |
| 规则集更新失败 | 网络问题或规则集源不可用 | 换规则集源 |
排查的通用方法：看日志
客户端的连接日志是唯一能确定规则行为的工具。
| 日志里看什么 | 说明 |
|---|---|
| 请求的域名 | 确认是哪个请求 |
| 命中的规则 | 部分客户端会显示 |
| 实际出口 | DIRECT 或某个节点名 |
如果日志显示的出口与你的预期不符，就是规则问题；如果出口正确但结果还是不对，就是节点问题。 这个区分能省下大量时间。
从最简配置开始
完整方案对新手太复杂。先配三条，解决 80% 的问题。
| 优先级 | 规则 | 指向 |
|---|---|---|
| 1 | 国内域名集合 | DIRECT |
| 2 | AI 服务域名 | 验证通过的新加坡 / 日本节点 |
| 3 | 兜底 | 默认香港节点 |
多数机场的 Clash / sing-box 配置里已包含第 1 条和第 3 条。 所以你实际只需要加第 2 条——这是投入产出比最高的一次配置，因为 AI 的地区敏感度最高而默认规则通常不处理它。
之后按需要逐步加：
| 什么时候加 | 加什么 |
|---|---|
| 开始有视频会议需求 | 会议域名 → 专线节点 |
| 开始看流媒体 | 流媒体域名 → 解锁节点 |
| 流量开始紧张 | 下载域名 → 低倍率大带宽节点 |
| 开始玩游戏 | 游戏域名 / IP → 低抖动 + UDP 节点 |
| 配了第二家机场 | 按机场分工重新组织策略组 |
规则与 DNS 的关系
这是配规则时最容易出问题、也最少被解释清楚的一块。
为什么 DNS 会影响规则
域名规则需要知道域名，IP 规则需要知道 IP。 但一个请求到达客户端时，情况可能是：
| 情况 | 客户端看到什么 | 能用什么规则 |
|---|---|---|
| 程序传来域名（HTTP/SOCKS 代理） | 域名 | 域名规则 + IP 规则 |
| 程序已自己解析成 IP（TUN 模式下常见） | 只有 IP | 只能用 IP 规则 |
第二种情况是问题的来源：如果程序先用本地 DNS 把域名解析成了 IP，客户端就看不到域名，你写的域名规则不会命中。
三个相关概念
| 概念 | 作用 |
|---|---|
| DNS 泄露 | 域名解析请求走了本地 DNS，可能暴露你要访问的域名，也可能返回被污染的结果 |
| fake-ip | 客户端返回一个假 IP，等程序发起连接时再按域名做规则匹配。让域名规则在 TUN 模式下仍然有效 |
| 远程解析 | 由节点端解析域名，得到目标地区的正确 IP |
常见的 DNS 配置问题
| 症状 | 原因 | 怎么修 |
|---|---|---|
| 域名规则不生效（TUN 模式下） | 程序已自行解析 | 启用 fake-ip |
| 打开国内网站得到境外 IP | 国内域名被远程解析 | 国内域名用国内 DNS 解析 |
| 流媒体地区判定不对 | 域名被本地解析，返回了错误地区的 IP | 该域名用远程解析 |
| 能连上节点但网页打不开 | DNS 完全不工作 | 检查 DNS 配置，见 DNS 设置 |
| 部分网站很慢 | DNS 解析慢或返回了远的 IP | 换 DNS 服务器 |
一个合理的默认策略
| 域名类型 | 解析方式 |
|---|---|
| 国内域名 | 用国内 DNS 解析（快、返回国内 CDN） |
| 境外域名 | 由节点端远程解析（返回目标地区的正确 IP） |
| 所有域名（TUN 模式下） | 启用 fake-ip，让域名规则生效 |
多数机场提供的 Clash / sing-box 配置里已包含合理的 DNS 设置。 除非遇到上表里的症状，不建议自己改——DNS 配置错误的表现往往很隐蔽（部分网站慢、地区判定不对），比规则错误更难排查。
详见 DNS 设置。
TUN 模式与规则的配合
什么时候需要 TUN
| 情况 | 说明 |
|---|---|
| 某个程序不读系统代理设置 | 游戏、桌面应用、命令行工具 |
| 需要覆盖全部流量 | 包括不支持代理的程序 |
| 需要处理非 TCP 流量 | 部分 UDP 场景 |
不需要 TUN 的情况：如果你的需求都在浏览器里（网页、流媒体、AI），系统代理模式就够了，而且更简单、风险更低。
TUN 模式下规则的注意事项
| 注意 | 说明 |
|---|---|
| 必须启用 fake-ip（或等效机制） | 否则域名规则可能不生效 |
| 局域网直连规则必须有 | 否则路由器管理界面、NAS 都可能失败 |
| 客户端自身的流量要排除 | 否则可能形成循环 |
| 需要更高权限 | 管理员 / root |
| 配置错误的影响更大 | 影响整个系统的网络，不只是浏览器 |
最后一项是 TUN 的主要风险：系统代理模式配错了，最多是浏览器上不了网；TUN 配错了，整个系统可能断网。
建议：先在系统代理模式下把规则调好并验证，再切到 TUN。
详见 TUN 模式。
双机场的规则设计
配了"主力 + 备用"两家后，规则设计的逻辑会变。
基本思路
不是"两套规则",而是一套规则、策略组里混合两家的节点。
| 策略组 | 包含 | 承担 |
|---|---|---|
| 会议 | 主力的专线级节点（主 + 备） | 视频会议、直播 |
| AI | 解锁通过的节点（哪家都行） | AI 服务 |
| 流媒体 | 解锁通过的节点 | Netflix / Disney+ |
| 大带宽 | 备用的低倍率大带宽节点 | YouTube、下载 |
| 默认 | 主力的延迟最低节点，备用作故障转移 | 兜底 |
关键设计点
一、把大流量需求放到便宜的那家。 这是双机场最直接的收益——下载与 4K 视频不需要专线，走便宜大流量的节点最划算，同时省下主力的小流量池。
二、默认组用故障转移模式。 主力节点失效时自动切到备用，不需要手动干预。
三、会议组只用主力的节点。 会议对丢包最敏感，不要让它自动切到可能不达标的备用节点。
四、两家的订阅域名都设为直连。 避免循环依赖。
怎么把两家的节点放在一份配置里
| 客户端 | 做法 |
|---|---|
| Clash Verge Rev | 多份配置切换，或手工编辑把两家的 proxies 合并到一份 |
| sing-box | 在 outbounds 里同时定义两家的节点 |
| Shadowrocket | 多个 Subscribe 条目，节点合并在列表里 |
| v2rayN / v2rayNG | 多条订阅的节点自动合并在服务器列表 |
Clash 系需要手工合并（或用支持多订阅合并的工具），这是配置成本最高的一步。v2rayN / v2rayNG 与 Shadowrocket 的节点会自动合并，但它们的规则能力不如 Clash。
一个实用折中：如果合并太麻烦，用"切换配置"的方式——日常用主力配置，需要大流量下载时切到备用配置。牺牲自动化，但零配置成本。
分工验证
配完后逐项确认：
| 检查 | 期望 |
|---|---|
| 会议走主力的专线节点 | 日志显示主力节点名 |
| 下载走备用的大带宽节点 | 日志显示备用节点名 |
| 主力节点手动断开后，默认组自动切到备用 | 网络不中断 |
| 两家的订阅都能更新 | 都成功 |
| 国内域名仍走直连 | 显示 DIRECT |
规则的性能与维护
规则数量的影响
每个请求都要从上往下匹配规则，直到命中。 规则越多、越靠后命中，开销越大。
| 规则规模 | 影响 |
|---|---|
| 几十条 + 几个规则集 | 无感 |
| 几百条手写规则 | 轻微 |
| 上千条手写域名 | 可能有感知，尤其在移动设备上 |
实用建议：用规则集而不是手写大量域名。 规则集通常有优化的匹配结构，比逐条线性匹配快得多。
把高频规则放前面
如果某类流量占比很高（比如国内访问占 70%），把它的规则放前面能减少平均匹配次数。
但要与"具体规则在前"的原则平衡：如果国内规则放得太前，可能把本该走代理的域名也捕获了（某些服务的域名在国内域名集合里但你希望它走代理）。
通常的折中：具体的服务规则（十几条）放最前，然后是国内规则集，最后是兜底。十几条的匹配开销可以忽略。
规则集的更新
| 项目 | 说明 |
|---|---|
| 更新频率 | 多数客户端支持定时更新，24 小时是合理默认 |
| 更新失败的表现 | 使用缓存的旧版本，通常不影响使用 |
| 规则集源不可用 | 换源；部分客户端支持多个备用源 |
| 更新时机 | 不要在关键使用时段更新（更新瞬间可能有短暂中断） |
维护的三条建议
一、给策略组起清晰的名字。 "会议"、"AI"、"大带宽" 比 "组 1"、"组 2" 好维护。
二、在配置里写注释。 说明每个自定义规则是为什么加的、指向哪个节点、什么时候验证过。半年后你会感谢自己。
三、改配置前先备份。 改坏了能快速回滚。
节点变动后要做什么
机场调整节点时：
| 步骤 | 操作 |
|---|---|
| 1 | 手动更新订阅 |
| 2 | 检查各策略组里的节点是否还存在 |
| 3 | 失效的节点从策略组里替换掉 |
| 4 | 规则本身不用改（这是用策略组的好处） |
| 5 | 重新验证关键场景 |
如果规则直接指向具体节点，第 4 步就变成"逐条改规则"——这就是为什么要用策略组。
常见误判
- 不配规则也能用。 能用，但国内访问会变慢、流量会浪费，机场的优势没发挥出来。
- 国内网站变慢是机场质量问题。 几乎一定是规则配错。
- 规则顺序不重要。 非常重要，兜底规则放错位置会让下面全部失效。
- 规则可以直接指向具体节点。 节点会改名下线，用策略组更可维护。
- 自动选择延迟最低最省事。 延迟最低的可能是丢包最高的（超卖）。
- 配置可以跨客户端照搬。 语法与匹配语义都不同。
- 配完就生效了。 必须看日志验证，尤其是国内直连。
- 规则越多越好。 规则多会增加匹配开销，也更难维护。从三条开始。
- 负载均衡能提升速度。 对需要保持会话的服务可能造成问题。
- AI 失败一定是节点问题。 先看日志确认规则命中了没有。
规则分流的三个进阶用法
配熟基础规则后，这三个用法能进一步提升体验。
一、按进程分流
部分客户端支持按发起请求的程序匹配规则。
| 用途 | 举例 |
|---|---|
| 某个程序单独走某节点 | 一个只在特定地区可用的应用 |
| 某个程序完全直连 | 国内的下载工具、游戏加速器 |
| 某个程序完全拦截 | 不想让它联网的程序 |
优势：不用知道它访问哪些域名。 有些程序的域名很多或会变，按进程匹配一劳永逸。
限制： 只有桌面端客户端支持得比较好，移动端受系统限制。
二、按时段切换策略组
如果你的节点有明显的时段特性（某节点白天极快但晚高峰崩塌、另一个白天一般但晚高峰稳定），可以按时段用不同节点。
多数客户端不原生支持定时切换，实现方式：
| 做法 | 说明 |
|---|---|
| 手动切换策略组 | 最简单，白天一次晚上一次 |
| 用客户端的脚本 / API | 部分客户端提供外部控制接口 |
| 系统定时任务调用客户端 API | 桌面端可行 |
实用性评估：多数人不需要。 如果一个节点晚高峰崩塌，更好的做法是不用它，而不是为它设定时任务。这个用法只适合"节点选择极少但时段特性明显"的情况。
三、故障转移与健康检查
这是最值得配的进阶用法。
| 机制 | 作用 |
|---|---|
| 健康检查 | 客户端定期测试策略组里节点的可用性 |
| 故障转移 | 当前节点不可用时自动切到下一个 |
| 检查间隔 | 常见 300 秒；关键场景可以更短 |
| 检查目标 | 通常是一个轻量的 HTTP 请求 |
为什么值得配：会议、直播这类场景中途断掉的代价很高，故障转移能在你察觉之前完成切换。
注意两点：
一、健康检查只测"能不能连"，不测"好不好用"。 一个丢包 5% 的节点在健康检查里是"健康"的。所以策略组里只放你验证过的节点——故障转移只在合格候选之间切换，不会救你于一个全是差节点的组。
二、不要把检查间隔设得太短。 过于频繁的检查本身会产生请求，也可能被机场视为异常流量。
按需求给出的最小配置
不同用户需要的规则复杂度差别很大。下面按需求给最小方案。
只用浏览器（网页 + AI + 流媒体）
不需要 TUN，系统代理模式就够。
| 规则 | 指向 |
|---|---|
| 国内域名集合（通常已在默认规则里） | DIRECT |
| AI 服务域名 | 验证通过的新加坡 / 日本节点 |
| 流媒体域名（如有需求） | 解锁通过的节点 |
| 兜底 | 默认香港节点 |
四条。 其中第一条和第四条通常已在机场提供的配置里，你只需要加中间一到两条。
远程工作 / 会议为主
| 规则 | 指向 |
|---|---|
| 局域网 IP 段 | DIRECT |
| 国内域名集合 | DIRECT |
| 视频会议域名 | 策略组「会议」（故障转移，主备两个专线节点） |
| 兜底 | 默认香港节点 |
关键是会议组用故障转移模式，主节点异常时自动切备用。
游戏为主
通常需要 TUN（游戏客户端多数不读系统代理）。
| 规则 | 指向 |
|---|---|
| 局域网 IP 段 | DIRECT |
| 国内域名 + 国内 IP 段 | DIRECT |
| 游戏域名 / 服务器 IP 段 | 策略组「游戏」（低抖动 + UDP） |
| 游戏下载 / 更新域名 | 策略组「大带宽」（低倍率） |
| 兜底 | 默认节点 |
把游戏下载与对局分开是关键——下载流量很大（可能 50–100GB）但不需要低抖动；对局流量很小但对抖动敏感。
下载 / 大流量为主
| 规则 | 指向 |
|---|---|
| 国内域名集合 | DIRECT |
| 下载相关域名 | 策略组「大带宽」（低倍率优先） |
| 兜底 | 默认节点 |
倍率是这个画像最重要的一项。 ×2 倍率会让 500GB 变成实际 250GB。
全家 / 路由器
在路由器上跑，规则配置的重要性最高——配错会影响全家所有设备。
| 规则 | 指向 | 为什么关键 |
|---|---|---|
| 局域网 IP 段 | DIRECT | 否则家里设备互访全部失败 |
| 国内域名 + 国内 IP 段 | DIRECT | 否则全家的国内访问都变慢 |
| 智能家居设备的域名 | DIRECT | 很多只能连国内服务器 |
| 兜底 | 默认节点 | — |
加一条：智能家居设备。 摄像头、音箱、扫地机这类设备只连国内服务器，走代理会导致它们离线或异常。建议按设备 IP 段直连，而不是逐个找域名。
多机场
见前面「双机场的规则设计」一节。核心是：会议走主力专线、下载走备用大带宽、默认组用故障转移。
名词速查
| 名词 | 含义 |
|---|---|
| 规则分流 | 按规则决定每个请求走哪个出口 |
| 策略组 | 节点分组，规则指向它而不是具体节点 |
| 规则集 / 域名集合 | 一组预定义域名，远程更新 |
| 兜底规则 | 匹配所有剩余流量，必须放最后 |
| DIRECT | 直连，不走代理 |
| REJECT / block | 拦截该请求 |
| MATCH / final | 兜底规则的关键字 |
| 出站 / outbound | sing-box 里的出口概念 |
| 域名后缀匹配 | 匹配某域名及其全部子域名 |
| 地理位置匹配 | 按目标 IP 的国家归属匹配 |
| 进程匹配 | 按发起请求的程序匹配 |
| TUN 模式 | 让客户端接管系统全部流量 |
| 连接日志 | 显示每个请求走了哪个出口，排查的唯一可靠工具 |
完整配置流程
我该怎么配规则？
1. 机场给的是 Clash / sing-box 格式吗？
是 → 里面通常已有合理的默认规则，继续
通用 / Base64 格式 → **只有节点列表，没有规则**，需要自己全配或换格式
2. 先验证默认规则
访问国内网站，看日志是否显示 DIRECT
是 → 默认规则正常，继续
不是 → 先修这个，这是最重要的一条
3. 我有 AI 需求吗？
有 → 加一条：AI 域名 → 验证通过的新加坡 / 日本节点
无 → 跳过
4. 我有会议 / 直播需求吗？
有 → 加一条：会议域名 → 丢包 ≈ 0 的香港节点（建议用故障转移模式）
无 → 跳过
5. 我有流媒体需求吗？
有 → 加一条：流媒体域名 → 解锁通过的节点
无 → 跳过
6. 流量紧张吗？
是 → 加一条：下载域名 → 低倍率大带宽节点
否 → 跳过
7. 确认兜底规则在最后了吗？
没有 → 移到最后，否则下面的规则全部失效
8. 逐项验证
国内域名 DIRECT？局域网可访问？订阅能更新？
AI / 流媒体 / 下载各走了指定节点？
9. 有某个程序不走代理？
→ 需要 TUN 模式，见 /guides/tun本页数据说明
| 内容 | 层级 | 含义 |
|---|---|---|
| 规则原理、类型、策略组机制 | 一般性技术参考 | 非针对具体品牌 |
| 规则方案与优先级建议 | editorial | 本站方法建议 |
| 各客户端的语法特点 | 一般性技术参考 | 具体语法以客户端文档为准 |
| 站内品牌的订阅格式支持 | 无此字段 | 需向客服确认 |
本页不提供任何规避服务方检测的方法。使用任何网络服务都应遵守所在地的法律法规与服务方的使用条款。规则见 免责声明。
一句话总结
规则分流是机场相对 VPN 最大的优势：让国内域名直连、AI 走验证通过的新加坡节点、会议走香港专线、下载走大带宽低倍率节点。最重要的一条是国内域名直连——配错的表现是"装了机场以后国内网站变慢"，这个现象经常被误判成机场质量问题。规则自上而下匹配、第一条命中即生效，所以具体规则在前、兜底规则必须在最后（放错会让下面全部失效）。规则应指向策略组而不是具体节点，这样节点改名下线时只改策略组。关键场景用手动选择或故障转移，不要用"自动选择延迟最低"——延迟最低的节点可能恰好是丢包最高的。配完必须看客户端连接日志验证，尤其确认国内域名显示 DIRECT。新手从三条开始：国内直连、AI 域名指向、兜底。
下一步
- 某个程序不走代理 → TUN 模式
- 能连上但打不开网页 → DNS 设置
- 先确定每个场景用哪个节点 → 节点怎么选
- 客户端具体语法 → Clash Verge Rev · sing-box · Shadowrocket
- 速度慢排查 → 速度慢怎么排查
- 订阅问题 → 订阅链接怎么用 · 订阅更新失败
相关页面
- 教程：节点怎么选 · TUN 模式 · DNS 设置 · 教程中心
- 客户端：客户端总览 · Clash Verge Rev · v2rayN · v2rayNG · sing-box · Shadowrocket
- 线路：节点地区 · IP 类型 · 节点波动
常见问题
规则分流是什么？
让客户端按规则决定每个请求走哪个出口：国内域名直连、AI 走新加坡节点、会议走香港专线、下载走大带宽节点。这是机场相对 VPN 最大的功能优势。
为什么国内域名要直连？
三个原因：走代理会绕远导致国内访问变慢、会消耗你的套餐流量、还可能让部分国内服务因为出口 IP 异常而出问题。这是最重要的一条规则。
装了机场以后国内网站变慢了怎么办？
几乎一定是规则配错了——国内域名走了代理。检查规则里国内域名的走向，确认客户端日志显示 DIRECT。多数客户端的默认规则集已处理，自定义配置时容易改错。
规则的匹配顺序重要吗？
非常重要。规则是自上而下匹配的，第一条命中就生效，后面的不再检查。所以具体的规则要放在前面，兜底规则放在最后。
策略组是什么？
Clash 里的节点分组。规则指向策略组而不是具体节点，策略组里再决定用哪个节点。好处是节点变动时只改策略组，不用改每条规则。
怎么知道规则生效了？
看客户端的连接日志。它会显示每个请求走了哪个出口。重点确认三件事：国内域名显示 DIRECT、AI 请求走了指定节点、下载走了大带宽节点。
我需要自己写规则吗？
多数机场提供的 Clash / sing-box 配置里已有合理的默认规则（国内直连、常见服务分流）。你通常只需要加一两条自己的规则，比如把 AI 域名指向验证通过的节点。
最少需要配几条规则？
三条就能解决大部分问题：国内域名直连、AI 域名指向验证通过的节点、其余走默认香港节点。前两条里第一条通常已在默认规则集中。