适用条件：能确认到哪一层
官方规则没有单独的「主程序 / 子进程」类型。Clash（mihomo）能直接比较的是 PROCESS-PATH 的完整进程路径，以及 PROCESS-NAME 的进程名；通配与正则只是这两种对象的匹配方式变化。因此，确认发起请求的是主程序还是子进程，适用条件是：你可以把实际发起该请求的那个进程的路径或名称取出来，并与规则 payload 对照。无法取得该进程自己的路径或名称时，不能靠域名、目标 IP 或 MATCH 推断它是不是主程序。
PROCESS-NAME 在 Android 平台可以匹配包名，电脑端仍应按进程名理解，例如官方的 chrome.exe、curl。包名不能用来在电脑端区分主程序与其它进程。规则按从上到下顺序匹配，若更早规则已经命中，进程行不会被用来做这次确认。
用路径和进程名区分不同可执行文件
把实际发起请求的完整路径写成 PROCESS-PATH 的对照项。官方示例 /usr/bin/wget 与 C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe 都指向一个具体可执行文件。若实际发起请求的是另一个可执行文件，它的完整路径会不同，针对主程序路径的那一行不会命中它。若两者是同一个可执行文件路径，则 PROCESS-PATH 无法把它们分成两个匹配对象，因为比较的就是这条完整路径。
再看 PROCESS-NAME。它只使用进程匹配，payload 如 chrome.exe。名称相同的进程会被当成同一类名称对象；名称不同则不是同一 PROCESS-NAME 条件。因此名称规则不能证明这就是主程序，只能证明进程名与 payload 一致。要收紧到某一个可执行文件，应改用完整路径。PROCESS-PATH-WILDCARD 仅支持 * 和 ?，可能把不同目录下的同名文件一起罩住，不适合用来做「是不是这一个可执行文件」的确认。过宽正则同样如此，例如 .*telegram.* 会覆盖名称中带该片段的进程。
核对时不要引入域名规则。DOMAIN 匹配的是域名，不能回答发起者是哪一个进程。把待确认的 PROCESS-PATH 或 PROCESS-NAME 放到会抢先命中的域名规则之前、MATCH 之前，再用该请求自己的路径或名称对照。需要名称与路径同时限制时，使用带括号的逻辑规则，形式为 LOGIC_TYPE,((payload1),(payload2)),Proxy。
判断依据与失败时下一步
判断依据：已取得发起该请求的进程自己的完整路径或进程名；该字符串与所写规则 payload 一致，则视为同一路径对象或同一名称对象，不一致则不是该条规则所描述的进程；当完整路径相同、仅靠名称无法再拆分时，承认 PROCESS-PATH 不能把同路径的多个进程实例分成主进程与子进程。
失败时下一步：若只写了主程序的 PROCESS-NAME 但不命中，核对该请求的进程名是否其实不同，再按实际名称另写一行，或改为实际完整路径的 PROCESS-PATH。若路径规则过宽，去掉通配与过宽正则，改回官方那种完整路径写法。若无法取得实际发起者自己的路径，不要用 GEOSITE 或 IP-CIDR 去代替进程确认。确认对象之后，把临时提前的进程行放回按优先级排列的位置，并保留末尾 MATCH。