机场进阶指南：分流规则、协议选择、多设备与线路优化
从「能上网」到「用得顺手」有六个台阶：代理模式、分流规则、协议选择、DNS、多设备、策略组，按顺序爬完就不用再问别人配置了。
如果你已经能导入订阅、选节点、正常访问境外网站，那么下一阶段要解决的就不是「能不能用」，而是这四类问题：某些应用不走代理、规则写了不生效、多台设备各配一套太麻烦、节点要手动切换太累。
这篇按六个阶段排出一条进阶路线，每一阶段解决一类问题，顺序不要跳——后面的配置依赖前面的理解。全部走完，你就能自己写配置、自己排查，不用再去群里问「为什么我的规则不生效」。还没走完基础流程的话，先看新手指南。
第一阶段：系统代理还是 TUN 模式？
这是进阶的第一个分岔口，也是最多人配错的地方。两种模式接管流量的层次完全不同。
| 对比项 | 系统代理 | TUN / 虚拟网卡模式 |
|---|---|---|
| 工作原理 | 在系统设置里声明代理地址，应用主动读取 | 创建虚拟网卡接管整机路由 |
| 覆盖范围 | 只覆盖读取系统代理设置的应用 | 覆盖所有走 IP 的流量 |
| 典型能覆盖 | 浏览器、大部分 GUI 应用 | 浏览器、终端、游戏、任何程序 |
| 典型覆盖不到 | 终端命令、Docker、部分 Electron 应用、游戏 | 极少数直接操作网卡的程序 |
| 权限要求 | 无 | 需要管理员/root 权限，移动端需 VPN 权限 |
| 对性能影响 | 极小 | 略高，但通常不可感知 |
| UDP 支持 | 多数情况不支持 | 支持 |
怎么选： 如果你只用浏览器和常规软件，系统代理就够了，权限要求低、副作用少。一旦你开始用终端拉代码、跑 Docker、玩需要 UDP 的应用，就必须上 TUN，因为这些程序根本不读系统代理设置。
TUN 模式还有两个配套设置要留意：是否开启「绕过局域网」（不开的话访问路由器管理页、NAS、局域网打印机都会走代理）和是否劫持 DNS（关系到下面第四阶段）。Clash Verge 里这两项都在设置页，操作位置见 Clash Verge 教程。
第二阶段：分流规则怎么写才生效？
分流是进阶的核心能力。理解两件事就够了：规则类型和匹配顺序。
规则类型：什么时候用哪一种
| 类型 | 匹配对象 | 典型用法 | 注意 |
|---|---|---|---|
| DOMAIN | 完整域名，精确匹配 | 单个特定站点 | 不匹配子域名 |
| DOMAIN-SUFFIX | 域名后缀 | 整个站点及其子域 | 最常用 |
| DOMAIN-KEYWORD | 域名中包含某关键词 | 一批含相同词的域名 | 容易误伤，慎用 |
| IP-CIDR | IP 段 | 已知服务器网段 | 需要真实 IP，与 fake-ip 有交互 |
| GEOIP | IP 的国家归属 | 国内流量直连兜底 | 依赖数据库，有误差 |
| PROCESS-NAME | 发起请求的进程名 | 让某个软件整体走/不走代理 | 桌面端可用，移动端受限 |
| RULE-SET | 引用一组外部规则 | 批量引入维护好的规则集 | 减少配置体积，推荐 |
| MATCH / FINAL | 兜底 | 所有未匹配的流量 | 必须放最后一条 |
日常够用的其实只有四种：DOMAIN-SUFFIX 处理站点、PROCESS-NAME 处理应用、RULE-SET 引入现成规则集、MATCH 兜底。
匹配顺序：命中即停止
规则从上往下逐条比对，命中第一条就停止，后面的全部不再判断。这一条机制解释了几乎所有「规则不生效」的问题。
典型的错误配置长这样：
RULE-SET,cn_domains,DIRECT
RULE-SET,proxy_domains,PROXY
DOMAIN-SUFFIX,example.com,日本节点 ← 永远不会被执行到
GEOIP,CN,DIRECT
MATCH,PROXY如果 example.com 已经被 proxy_domains 规则集包含，第三行就永远轮不到。正确的做法是把自定义规则放在所有规则集之前：
DOMAIN-SUFFIX,example.com,日本节点 ← 优先级最高
RULE-SET,cn_domains,DIRECT
RULE-SET,proxy_domains,PROXY
GEOIP,CN,DIRECT
MATCH,PROXY三个高价值的实用规则
进阶用户最值得先配的三条规则：
- 给 AI 服务固定出口。把 AI 服务和 API 的域名指向某个固定节点，避免自动切换导致的 IP 跳变触发风控。
- 给开发工具指定出口。代码托管、包管理源、容器镜像仓库这类域名，指向延迟稳定的节点而不是速度最快的节点，中途断连比慢十倍更麻烦。
- 把局域网和内网域名强制直连。公司内网、NAS、路由器管理地址写进 DIRECT，避免开着代理访问不到内网资源。
规则的完整语法、规则集的引用方式、以及按应用分流的具体写法，在自定义分流规则里有逐条示例，这里不展开。
第三阶段：协议什么时候需要换？
先说结论：大多数时候不需要换，机场给什么用什么。 但你应该知道各协议的特性，以便在出问题时判断该往哪个方向调。
| 协议 | 特点 | 适合场景 | 局限 |
|---|---|---|---|
| Shadowsocks | 成熟、轻量、开销小 | 日常通用 | 特征相对明显 |
| VMess | 功能完整，支持多种传输层 | 需要 WebSocket/gRPC 伪装时 | 对系统时间敏感 |
| VLESS | VMess 的精简版，无加密开销 | 配合 TLS 使用，性能更好 | 必须配合传输层加密 |
| Trojan | 伪装成正常 HTTPS 流量 | 干扰较强的网络环境 | 需要合法证书 |
| Hysteria2 | 基于 QUIC/UDP，抗丢包 | 移动网络、丢包率高的链路 | 部分网络对 UDP 限速 |
三种值得切换的场景：
- 连接频繁被重置、握手失败：说明协议特征可能被识别，换到 Trojan 或带 TLS 的 VLESS 试试。
- 丢包严重、速度忽高忽低：这是 TCP 拥塞控制在丢包下的典型表现，换 Hysteria2 往往有明显改善，尤其在 4G/5G 网络下。
- 设备或客户端不支持：老设备、路由器固件、某些精简客户端不一定支持新协议，退回 Shadowsocks 兼容性最好。
各协议的技术原理、握手过程和伪装方式，在代理协议详解里有展开。
第四阶段：DNS 为什么要单独配？
DNS 是进阶阶段最容易被忽略、又最容易造成诡异问题的一环。典型症状：节点能连、测速正常，但某些网站打不开、流媒体解锁失效、访问国内网站却被解析到境外服务器。
三种解析方式的区别
- 本地解析：客户端先在本地把域名解析成 IP，再按 IP 走规则。问题是国内 DNS 可能返回被污染的结果，而且基于域名的规则会失效（因为到规则匹配时只剩 IP 了）。
- 远程解析：把域名原样交给节点，由节点所在地解析。结果准确，且解锁类服务会正确识别归属地。
- fake-ip：客户端返回一个保留段的虚拟 IP 给应用，域名信息完整保留到规则匹配阶段，解析在真正建立连接时由节点完成。
推荐组合：开启 fake-ip，国内域名用国内 DNS 解析，其余域名交给节点远程解析。这样既避免污染，又保证流媒体的地区判断正确。
两个常见坑
- DNS 泄漏：客户端开了代理，但系统或浏览器仍在用本地 DNS 查询境外域名，导致解析结果被污染或暴露访问目标。TUN 模式下开启「劫持 DNS」可以避免。
- fake-ip 与 IP-CIDR 规则冲突：开了 fake-ip 之后，基于 IP 的规则拿到的是虚拟 IP，会匹配失败。所以 fake-ip 模式下要尽量用域名类规则，少用 IP-CIDR。
第五阶段：多设备怎么统一管理？
三台以上设备各配一套规则是不可持续的。有三种量级递增的方案。
方案一：同一订阅 + 各自客户端（最简单）
同一条订阅链接导入所有设备，规则由机场的订阅提供。适合规则需求简单的人。缺点是自定义规则要在每台设备上重复写一遍。
方案二：订阅转换 + 自定义规则模板（推荐）
把订阅链接经过订阅转换服务处理，套上一份你自己维护的规则模板，生成一条新的订阅链接，所有设备都导入这条新链接。改规则只需改模板，全部设备下次刷新自动同步。
方案三：软路由 / 网关级代理（一劳永逸）
在路由器或一台常开的设备上跑代理，整个局域网的流量都经过它。电视、游戏机、智能家居这些没法装客户端的设备也能覆盖。代价是配置复杂、故障时全家断网，而且对路由器性能有要求。
三种方案可以叠加：家里用方案三覆盖固定设备，手机和笔记本用方案二覆盖外出场景。
第六阶段：用策略组做线路优化
策略组决定「流量到了这一组之后，具体走哪个节点」。四种类型各有适用场景。
| 策略组类型 | 行为 | 适合 | 不适合 |
|---|---|---|---|
| select（手动选择） | 你指定哪个节点 | 需要固定出口的场景 | 节点失效时不会自动切 |
| url-test（自动选择） | 定期测延迟，选最快 | 日常浏览 | 需要会话保持的服务 |
| fallback（故障转移） | 按顺序用，前一个不通就换下一个 | 稳定性优先的场景 | 对延迟敏感的场景 |
| load-balance（负载均衡） | 连接分散到多个节点 | 下载、批量请求 | 登录态服务、AI、银行 |
一套实用的策略组结构大致是这样分层的：
- 日常浏览组：url-test，覆盖香港、日本、新加坡的低倍率节点，自动选延迟最低。
- AI 与 API 组：select，手动固定一个原生 IP 节点，绝不自动切换。
- 流媒体组：select，按要看的内容库手动切地区。
- 开发工具组：fallback，按稳定性排序放专线节点，断了自动顺延。
- 兜底组：指向日常浏览组。
这个分层的核心思想是：自动化只用在不需要状态保持的地方，需要固定 IP 的地方一律手动。 把 AI 服务放进 url-test 组，是进阶阶段最常见的错误配置——延迟测试触发的节点切换会让 IP 不断跳变，直接导致验证循环。
选节点时具体看哪些指标（延迟、抖动、倍率、IP 类型），见怎么选机场节点。
进阶阶段的常见误区
按出现频率排序，这些是最容易自伤的操作。
- 认为全局模式更快。全局模式把国内流量也送出境再回来，国内网站会明显变慢，而境外网站的速度和规则模式完全一样。全局模式只在排查问题时临时用。
- 规则越多越好。几万条规则里大部分你永远用不到，却会增加内存占用和维护成本。用维护良好的规则集加十几条自定义规则，效果最好。
- 对所有流量用负载均衡。会导致 IP 不断变化，触发各类服务的风控。
- 同时开系统代理和 TUN。前面说过，这是第一大自伤配置。
- 忽略倍率。写了一堆精细规则，却把日常流量指向了 5x 的节点，流量三天用完。
- 用来路不明的在线订阅转换。相当于把订阅凭证交给第三方。
- 改了配置不做对照测试。每次只改一处，改完立刻用同样的方法测一次，否则出问题时无法定位是哪一步引入的。
- 忘记留一条直连兜底。规则里没有处理内网和局域网地址，导致开代理后访问不了 NAS 和路由器。
走完六个阶段之后
到这里，你已经能处理绝大多数配置问题。如果你的使用场景偏开发——终端走代理、Git 和包管理器超时、Docker 拉不下镜像、API 调用需要固定出口——那还有一层专门的配置要做，集中在开发者网络指南里，包括环境变量、各工具的代理设置和容器网络的坑。
最后提醒一句：进阶配置的目的是减少日常干预，不是为了配置本身。一套好的配置应该是装好之后几个月不用动，只在换机场或出故障时才打开。如果你每天都要手动切节点、改规则，说明配置的分层还没做对，回到第六阶段重新设计策略组。