配置Proxifier时，最容易出现的误区是：看到代理服务器测试成功，就认为指定应用的流量一定会通过代理。
实际上，代理服务器是否可连接、应用连接是否命中规则、域名在哪里解析，是三个不同的检查点。真正排障时，应该从一条具体连接开始，而不是先删除规则或更换地址。
一条连接经过哪些判断
Proxifier处理连接时，会读取当前Profile中的Proxification Rules，并按照从上到下的顺序检查。
一条规则最多包含三类匹配条件：
- Applications：发起连接的程序；
- Target hosts：目标域名或IP地址；
- Target ports：目标端口。
如果多个字段都有内容，连接需要同时满足这些条件。匹配成功后，Proxifier执行该规则配置的动作：Proxy、Chain、Direct或Block。
如果所有自定义规则都没有匹配，连接进入Default规则。因此，“规则存在”不等于“连接命中”。
第一步：先从Connections窗口找事实
不要只看浏览器错误页面。打开Proxifier主窗口，在Connections区域找到刚刚发起的连接。
至少记录下面这些字段：
Application: 实际进程名称和PID
Target: 实际目标域名或IP及端口
Status: Connecting / Closed / Failed / Canceled
Rule: 实际命中的规则
Proxy: 使用的代理或Direct
Time: 发生时间
这一行记录能够回答最重要的问题：这条连接究竟有没有进入预期规则。
如果Rule显示Default，说明自定义规则没有匹配；如果Proxy显示Direct，说明最终动作是直连；如果规则和代理都正确但状态为Failed，则应该继续检查连接或认证错误，而不是修改规则顺序。
第二步：核对实际进程，而不是只看软件名称
很多桌面软件并不是由一个进程完成全部网络请求。
启动器可能先运行launcher.exe，再启动真正负责联网的client.exe；浏览器也可能创建多个子进程。规则里只写启动器名称，就可能漏掉后续进程。
应以Connections窗口记录的Application为准，再回头检查规则中的Applications字段。
例如：
预期进程：app.exe
实际连接：helper.exe
结果：应用条件不匹配，继续检查下一条规则
不要为了“肯定能匹配”直接把所有应用改成Any。先识别真实进程，再决定规则边界，能够避免其他程序意外共用同一代理。
第三步：检查目标主机和端口
用户在浏览器里看到的是一个网址，但程序实际连接的目标可能包含主域名、子域名、CDN域名和API域名。
规则只写example.com，未必能够覆盖api.example.com或其他资源域名。端口也可能不只使用443。
排查时可以把实际连接整理为：
Process: client.exe
Host: api.example.com
Port: 443
Rule: Default
然后与规则中的三个条件逐项对照。使用通配符时，也应该确认范围是否符合预期，而不是直接使用过宽的*。
第四步：检查规则顺序
Proxifier官方规则文档说明，规则从上到下扫描，顺序会影响最终结果。
如果一条宽泛的Direct规则位于具体Proxy规则之前，连接可能先被Direct规则匹配，后面的Proxy规则就没有机会执行。
可以用下面的方式检查：
1. Localhost -> Direct
2. Internal Network -> Direct
3. Target App -> Proxy A
4. Default -> Direct
确认目标连接没有被第1或第2条提前覆盖，再检查第3条的应用、主机和端口是否全部匹配。
第五步：把DNS路径单独拿出来
连接规则正确，不代表域名解析路径一定符合预期。
Proxifier既可以使用本地DNS，也可以通过代理解析域名。默认的自动检测模式会持续监测本地DNS状态，并在需要时切换解析方式。
Proxifier官方名称解析文档列出的切换日志类似：
(Automatic DNS mode detection)
Local DNS service is available/unavailable.
Name Resolution through proxy is disabled/enabled.
如果要分析DNS问题，可以在Log菜单中启用Verbose或Debug级别，并观察域名解析请求及模式变化。
通过代理解析域名时，Proxifier可能为域名分配仅在本机有效的占位地址。因此，依赖真实目标IP编写的规则可能不再按原方式工作。
这也是为什么DNS模式变化后，某些IP规则看起来突然“失效”。
第六步：避免一边测试一边修改多个变量
一次同时调整规则顺序、DNS模式、代理地址和认证信息，会让结果失去解释力。
更可靠的排障节奏是：
- 保存当前Profile；
- 复现一条连接；
- 记录Application、Target、Rule和Proxy；
- 每次只修改一个条件；
- 再次发起相同连接并比较结果。
如果规则命中从Default变为目标规则，说明匹配条件修正有效；如果规则一直正确但连接失败，就把排查重点转向主机、端口、协议和认证。
总结
Proxifier规则排障的核心不是“多试几个配置”，而是回答三个具体问题：
- 哪个进程发起了连接？
- 连接命中了哪条规则？
- 域名在本地还是通过代理解析？
从Connections和日志中获得这三项事实以后，才能区分规则未命中、Default直连、DNS路径变化和代理连接失败。
这样处理，比反复删除规则、重启软件或更换地址更容易找到真正故障点。
