适用条件：核对应围绕运行模式、进程匹配与日志
要核对「应用实际选择的代理类型」，在官方全局配置里对应的是内核如何处理该应用发出的连接：mode 决定规则匹配、全局代理还是全局直连；find-process-mode 决定是否按进程匹配；日志与外部控制 API 用来观察结果。这里的「类型」不是去猜测应用界面上的文案，而是确认 Clash 当前究竟处于 rule、global 还是 direct，以及是否对该进程做了匹配。
适用场景包括：本机多个应用表现不一致、怀疑应用走了直连、以及使用了策略组但不确定当前生效的是哪一种运行模式。全局 TLS 指纹在文档中已标明弃用，核对应以 mode、进程匹配和日志为准，不要用已弃用项去反推应用选择了哪种代理。
具体操作步骤与判断依据
第一步，读取 mode。可选值为 rule（规则匹配）、global（全局代理，需要在 GLOBAL 策略组选择代理或策略）、direct（全局直连），默认规则模式。判断依据：配置为 direct 时，应用即使填写了 Clash 的代理端口，内核出站仍按全局直连理解；配置为 global 却未在 GLOBAL 组选定节点或策略，则「应用选了代理」与「内核真正出站」仍可能不一致。必须先让 mode 与预期一致，再解释应用侧现象。
第二步，读取 find-process-mode。可选 always（强制匹配所有进程）、strict（默认，由 Clash 判断是否开启）、off（不匹配进程，文档推荐在路由器上使用）。判断依据：需要按应用进程区分走代理或直连时，off 会导致进程信息不可用，规则即使写了进程条件也不应预期生效；路由器场景按文档使用 off 则不应再拿「某个 App 名」当核对依据。always 与 strict 的差异在于是否强制匹配，核对前要知道当前到底是哪一档。
第三步，用日志核对实际行为。log-level 可选 silent、error、warning、info、debug，仅在控制台和控制页面输出。判断依据：需要看清某次连接被如何处理时，silent 无法提供信息；error 只覆盖严重到无法使用的情况；debug 会尽可能输出运行中所有信息，适合核对该应用连接是否被接受、是否认证、是否因模式或进程匹配走出不同路径。同时确认 ipv6 是否允许该地址族，避免把「IPv6 不被接受」误判成应用选错了 HTTP 或 SOCKS。
第四步，经外部控制 API 查看可被接口读取的状态。external-controller 提供 RESTful API（文档示例 127.0.0.1:9090），可配合 secret。profile.store-selected 为 true 时，会储存 API 对策略组的选择，供下次启动使用。判断依据：若依赖 API 切换过 GLOBAL 或其他策略组，核对「当前选择」应以内核已保存并正在使用的选择为准，而不是只看应用里填写的是 SOCKS 还是 HTTP——那只说明入站协议，不说明出站策略。
失败时下一步
若仍无法判断该应用实际走了哪种处理路径：将 find-process-mode 从 off 改为文档允许的 always 或 strict 后再观察（路由器环境则按文档保持 off，改用地址类规则，而不是强行匹配进程）；把 log-level 提到 info 或 debug；确认 API 监听地址与密钥后读取运行模式和策略组选择。authentication 与 skip-auth-prefixes 只能说明应用是否成功进入 http(s)/socks/mixed 入口，不能单独证明 mode 为 global 还是 rule。若日志只显示验证失败或源 IP 命中 lan-disallowed-ips，应先解决入站访问，再谈代理类型核对。