软件走错线路？从连接记录检查命中规则

先分清是哪一种走错线路

不要先把整个软件加入一份新的规则列表。先说清你期待哪一次请求走哪条线路，以及你现在依据什么认为它走错。软件提示地区变化、下载速度变慢或登录失败，都只是现象；如果还没有对应连接的规则和出口，原因就仍然未知。

先在分流检测保存浏览器三条线路的基线，再回原软件重现。浏览器成功不能证明桌面软件已经进入同一个客户端；反过来，软件某次失败也不能单独证明浏览器分流有问题。把两个结果分别记录，后面的对照才不会混在一起。

只重现一个操作，找到对应连接

1. 确认当前运行模式、配置名称和内核版本。本文讨论规则模式下的匹配；如果当前使用的是其他模式，先记录差异，不要拿另一种模式的表现证明某条规则生效。
2. 打开客户端已有的连接或日志视图，记下时间。回原软件只执行一次动作，例如打开一个页面或开始一次登录，尽量避开同时更新和下载。
3. 按对应时间找请求，记录目标域名或目标地址、TCP 或 UDP、进程信息、命中规则和策略链。不同界面显示内容不同，缺少的字段就写“未取得”。
4. 如果一次操作产生多条请求，不只看第一条。分别标记成功和失败请求，再找与你看到的错误同时出现的那一条。

没有记录不一定等于请求没有进入客户端，也可能只是筛选范围不对或记录显示不全。先去掉与本次无关的筛选，再查同一时间窗口。仍然找不到时，参照TUN 流量接管排查核对程序使用的路径；此时新增路由规则可能根本影响不到它。

日志只服务于定位本次问题，不需要长期打开最详细级别。分享排查材料前，去掉认证信息、订阅地址和无关的个人数据；保留时间、目标类型、命中项和出口等必要字段就够了。本文的示例域名和进程名也不代表任何真实测试结果。

从命中项查回规则顺序

Mihomo 的路由规则按从上到下的顺序匹配。一般情况下，先命中的适用规则决定处理策略；还要留意目标策略不支持 UDP 等内核说明中的特殊情况。不要只在配置里搜索“有没有我加的域名”，还要看它前面是否已经有能接住这次连接的条件。

下面是顺序示意，假设你希望这一个域名走已经存在的“已有代理组”。service.example.com 是文档示例，需换成日志里核实的目标；组名也必须换成当前配置中实际存在的名称。代码只演示局部顺序，不能覆盖整份规则。

rules:
  - DOMAIN,service.example.com,已有代理组
  # 其余原有规则仍然保留在适合的位置
  - MATCH,DIRECT

DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，RULE-SET 引用规则集合，MATCH 是无条件兜底。你只确认一个目标时，先用精确域名表达需求，不要立即把整个后缀、全部 UDP 或全部程序都改变出口。例外范围越大，越难排除对其他请求的影响。

如果连接只显示目标地址，而没有可用域名，不要凭软件名称猜一个域名写进去。先把目标信息查清；如果现有规则涉及 no-resolve，它表示不要为了该目标 IP 规则额外触发解析，并不表示此前已经取得的目标 IP 永远不能匹配。不要把一个附加选项误当作完整的匹配结果。

继续看策略组的实际选择

连接记录里出现“代理”二字，还不足以证明连接最终经过某一个远端出口。那可能只是你自己给策略组取的名字。如果组里允许选择 DIRECT，并且当前实际选中了它，命中这个组仍然可能选择直连。需要沿当前请求的策略链，继续查看被选中的组或出口。

记录“规则匹配正确，但组选择不符”时，先核对当前选择是否就是你想要的，而不是立刻把规则复制一遍。若是嵌套组，还要继续查下一层；若界面没有展示完整链，就注明证据不完整。不要用组的名称、颜色或一张旧截图替代本次实际选择。

自动选择或回退类型的组还有自己的选择逻辑。为了做单项对照，可以在原配置允许的范围内临时选一个明确目标，并记下原选项，完成后恢复。本文不建议为了一个软件永久更换所有分组，也不要求你关闭原有故障回退机制。

进程规则没有命中时查什么

以 Mihomo 为例，PROCESS-NAME 用于匹配进程名称，PROCESS-PATH 用于匹配进程路径。填写前先看连接记录实际识别到的内容，不要用桌面快捷方式的显示名称代替。你点击的程序和真正发起请求的进程也未必相同，应以这次请求的证据为准。

内核的 find-process-mode 控制进程匹配，可选 strict、always、off；不能把空白进程栏解释成“进程规则肯定写错”。先查平台和运行方式是否支持、实际配置是否关闭了匹配，以及记录中是否确实有可用进程信息。路由器上的记录也不能直接当作某台电脑的本机进程信息。

如果能确认应用需要某个精确域名，却暂时拿不到可靠进程信息，可以先围绕这个目标做有限的域名对照；不要为了补齐进程名就无依据扩大权限或强制打开全部进程匹配。不同客户端和平台能力有差异，文中的 Mihomo 字段不能直接当成所有客户端的统一设置名。

只改一项，再用新连接复验

修改前保存当前配置与选择，修改后先检查是否加载成功。不要把同一个 rules 键重复加到文件末尾，也不要手工替换一段由客户端自动生成、下次更新又会覆盖的内容；应按当前客户端支持的覆盖或合并方式处理，并检查实际运行配置。

1. 一次只调整一个明确条件，例如把一个精确域名例外移到兜底前，或者修正一个组的当前选择。记录旧值与新值，不同时更换 DNS、TUN 和所有出口。
2. 结束本次用于对照的旧连接，再回原程序执行相同操作。看新请求的命中规则、策略链和结果；一条修改前建立的记录不能证明新规则已经生效。
3. 回到首页重测国内、海外与谷歌三栏，确认浏览器基线没有被意外改变。若结果失败或未知，原样保留，不写成全部正常。
4. 没有改善就撤回这一次变化，保留记录，继续检查下一层。若已改善，保留最小修改及原因，并检查这个软件的其他必要操作是否仍可使用。

如果新连接的规则与出口都符合预期，应用却仍报错，就不要继续把问题都归给分流。把结论收窄到“本次连接的路由符合设置，应用操作尚未恢复”，再沿服务响应或程序错误继续查。规则排查的完成标准，是请求路径有证据、原操作有结果，而不是配置里多了一条看起来正确的规则。