自定义规则教程：让指定 App 走指定节点
订阅里自带的「全球规则」往往偏通用：你可能希望游戏客户端固定走低延迟地区、办公软件全程直连、流媒体走解锁线路。在 Clash 里，这类需求靠两件事配合完成：一是为不同用途准备不同的代理组（proxy-groups）名称；二是在 rules 里按从上到下的顺序，把流量指到对应组。本文面向已能导入订阅的读者，说明域名规则、进程规则（需 Clash Meta／Mihomo 系内核）与规则合并时的常见坑，帮你写出可维护的自定义片段。
先搞清：规则匹配的是「代理组名」，不是「某一个节点名」
很多新手在 rules 里直接写真实节点名，结果发现不生效或启动报错。正确姿势是：规则右侧填的是 proxy-groups 里定义的 name，由代理组再去调度具体节点。例如你希望「游戏走香港池」，应先在 proxy-groups 里有一个名为 🎮 游戏（或任意你喜欢的 UTF-8 名称）的组，其 proxies 下列出香港相关节点；再在规则里写 ...,🎮 游戏。
若你对 select、url-test 等组类型还不熟，建议先阅读Clash 代理组（proxy-groups）完全指南，把「入口组」「地区池」「兜底组」的命名理顺，再回来写规则，会少一半低级错误。
规则顺序：从上到下，先命中先生效
Clash 的规则列表是有序决策链：每条连接会从第一条规则开始尝试匹配，一旦命中就不再往下看（除非特定类型另有说明）。因此更具体、更想优先保证的策略要写在前面；宽泛的兜底（例如 MATCH 走总出口）应放在最后。
实战里常见错误是：把自定义规则追加在订阅远程规则之后，但远程配置里已经用 MATCH 抢走了全部流量。解决办法取决于客户端：使用「规则预置／前置合并」「覆写」「本地优先」等能力，让你的片段插入到远程规则之前或之中正确位置。不同 GUI 名称不同，但思路都是控制合并顺序，而不是单纯「在文件末尾 append 一段」。
按域名或 IP：最通用、也最容易维护的一类写法
若目标服务有稳定域名（浏览器、多数在线应用），优先用域名类规则往往比猜 IP 更可靠：DOMAIN 精确匹配主机名，DOMAIN-SUFFIX 匹配后缀（适合整站 CDN），DOMAIN-KEYWORD 做宽松包含（慎用，避免误伤）。国内常用站点、局域网地址通常配合 GEOIP,CN 或私有 IP-CIDR 走 DIRECT，减少绕路。
下面是一段示意（组名请与你本地 YAML 保持一致）：
rules:
- DOMAIN-SUFFIX,openai.com,🤖 AI / 工具
- DOMAIN-SUFFIX,github.com,🚀 默认代理
- DOMAIN-SUFFIX,steampowered.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,🚀 默认代理使用 IP-CIDR 时，若配合 fake-ip 模式，常需要 no-resolve 以避免 DNS 阶段与预期不符；这类细节与 DNS、TUN 强相关，可结合TUN 模式深度解析一文中的 DNS 小节一起理解。
「指定 App」在 Windows／Android 上：进程名与包名规则
按应用程序分流，本质是匹配「谁发起了连接」。在 Clash Meta（Mihomo）系内核中，常见写法包括：
- Windows：
PROCESS-NAME，值为可执行文件名，例如chrome.exe、Telegram.exe。大小写与任务管理器里显示一致即可（仍建议以实际日志为准）。 - Android：
PACKAGE-NAME，值为应用包名，例如com.twitter.android，可在系统应用信息或开发者工具中查看。
这类规则通常要求流量确实经过内核的策略路由路径。若应用无视系统代理、且你未开启 TUN／透明代理，连接可能根本不会以「可被 Clash 分类」的形式出现——此时应先解决「流量进没进 Clash」，再谈进程匹配；详见上文 TUN 文章。
rules:
- PROCESS-NAME,steam.exe,🎮 游戏
- PACKAGE-NAME,com.discord,💬 社交
- MATCH,🚀 默认代理桌面平台若使用 PROCESS-NAME 仍异常，请打开客户端连接日志，核对进程名是否匹配、是否走了直连或 IPv6 旁路；移动端则注意厂商后台限制与分应用 VPN 权限。
用 RULE-SET 管理大量规则，而不是无限拉长主配置
当自定义条目超过几十行，维护成本会陡增。rule-providers 配合 RULE-SET 可以把规则集拆成远程或本地文件：更新广告拦截、流媒体列表时只替换子资源，主配置保持清爽。声明 provider 后在 rules 里用一行 RULE-SET,provider_name,某代理组 引用即可（具体键名随核心版本略有差异，以你所用的发行版文档为准）。
选择第三方规则集时，注意其授权与更新频率；不要盲信「超大合集」，以免引入过度拦截或与你本地 DIRECT 策略冲突。
与订阅共存：避免「一更新就丢自定义」
订阅刷新往往只替换远程 proxies 段或整段远程模板，你的本地改动若写在错误层级，可能在一次更新后被覆盖。稳妥做法是：把节点列表交给订阅，把稳定的代理组结构、规则片段放在本地 profile 或由客户端提供的「合并／覆写」层，并养成备份习惯。
若你从旧版 Clash for Windows 迁到 Clash Verge Rev 等现代客户端，可对照从 Clash for Windows 迁移到 Clash Verge Rev 完整指南，确认订阅 URL、覆写文件与内核版本是否一并对齐，避免「规则明明写了却不执行」的假阳性。
iOS 与其他平台的预期管理
受系统网络栈与沙箱限制，iOS 上的第三方客户端通常无法像 Windows／Android 那样细粒度按「单个 App」下发改写路由，更多依赖域名规则、全局策略或系统描述文件能提供的粒度。若你以 iOS 为主力，请把预期放在「站点／服务级分流」，而不是与桌面完全一致的进程级体验。
常见问题
写了 PROCESS-NAME 完全不生效？
依次检查：① 内核是否为 Meta 系且版本支持；② 进程名是否拼写正确；③ 流量是否未进入 TUN／系统代理导致绕过；④ 是否有更靠前的规则已匹配。用连接日志对照最快。
为什么 Netflix 仍走错出口？
流媒体常涉及多 CDN 域名与 IPv6；仅添加主域名有时不够。可结合远程流媒体规则集、检查 DNS 是否走 Clash、以及是否有 GEOIP 或 MATCH 提前兜底。
可以把规则写得非常「激进」吗？
技术上可以，但不建议：过宽的关键词规则容易误伤；过于频繁的调整会增加排错成本。建议小步迭代，每次改动后观察日志与延迟。
小结
让指定应用走指定节点，本质是为用途命名代理组 + 在有序规则中把流量指到这些名称；域名与 IP 规则适用面最广，进程／包名规则在 Meta 内核下可进一步细化到「哪一个 App」。同时务必处理合并顺序、DNS 与 TUN 的交互，并在订阅更新后复查是否仍然生效。
相比反复切换单一 VPN 开关，Clash 把「意图」固化在可读的 YAML 里，长期使用会更省心。若你尚未安装或准备换用仍在积极维护的客户端，可从本站获取对应平台安装包，再按使用教程完成订阅与规则入门——→ 立即免费下载 Clash，开启流畅上网新体验。