Clash 内核退出后，http(s)/socks/mixed 入站不再由该进程提供服务。操作系统里的 HTTP/HTTPS 代理登记并不是官方全局配置中的字段，因此 YAML 里不会出现一项叫作系统代理残留，但系统侧仍可能指向已经消失的代理端口。检查时要分开三件事：系统是否还把流量指向原入站、内核是否仍在监听、以及认证与局域网相关配置会不会在下次启动时继续生效。
残留可能属于哪一类状态
第一类是操作系统代理仍指向 Clash 原先使用的本机地址与端口，但内核已停止。浏览器会按系统代理去连接无人监听的端口，表现为无法加载或代理连接失败。这时与 mode、规则无关，因为没有进程再接受入站，日志也不会再增加记录。
第二类是内核并未真正退出，external-controller 仍可访问，入站仍在。文档中 API 示例为 127.0.0.1:9090，还可配置 Unix socket 或 Windows namedpipe。若 API 仍响应，应视为进程还在运行，而不是系统代理残留。文档写明从 socket 或 namedpipe 访问 API 时不会验证 secret，检查退出状态时要避免连到其他仍在监听的实例。
第三类是配置文件中的入站策略会在下次启动时继续生效，例如 authentication、skip-auth-prefixes、allow-lan、bind-address。它们不是操作系统残留，而是内核配置被再次加载。lan-disallowed-ips 黑名单优先于白名单，下次打开允许局域网时仍可能拦住部分设备。mode 与 profile.store-selected 会影响下次分流和策略组选择，它们同样不是系统代理残留，却容易让人觉得退出后行为没有恢复。
退出后按什么顺序核对
先确认内核是否已停止：原 http 或 mixed 端口是否还被占用，external-controller 是否还能连上。若 API 可连，并且按当前 log-level 仍能在控制页面看到输出，应先结束该进程，再谈系统侧残留。log-level 为 silent 时控制台没有输出，不能把“看不见日志”当成已经退出。
再查看操作系统网络设置中的 HTTP/HTTPS 代理主机、端口以及是否仍启用。官方文档不描述各系统图形界面上的具体名称，核对原则是：主机应为空或不再指向已关闭的 Clash 入站。若仍指向该端口且内核已退出，即可判断为系统代理残留。此时浏览器的失败模式是连不上代理，Clash 日志不会有新记录。
然后检查即将再次启动的配置。authentication 是否仍要求密码，skip-auth-prefixes 是否仍覆盖 127.0.0.1/8 与 ::1/128。残留的认证策略不会写在操作系统里，但会造成清掉系统代理后又一次开启却无法浏览。allow-lan 与 bind-address 只在还需要其他设备使用代理端口时检查。store-selected 为 true 时会保存 API 对策略组的选择供下次使用，若退出前停在 global 的某一选择，下次启动仍可能沿用，不要把它当成系统代理没清掉。
判断依据和未恢复时的下一步
判断依据可以收成三条。内核已停止且 API 不可达，但操作系统代理仍指向原入站：判定为系统代理残留。操作系统代理已关闭，但 API 仍可达：判定为进程未退出。系统代理已关、进程已退出，再次启动后出现认证失败：判定为配置中的 authentication 与跳过前缀问题，而不是操作系统残留。find-process-mode、unified-delay、geo 相关项与系统代理残留无关，不必列入这项检查。
建议处理顺序是：确认进程与 API 已停止，再关闭操作系统 HTTP/HTTPS 代理，用浏览器访问同一普通网址，此时流量不应再尝试 Clash 端口，然后再启动内核并按需重新指向入站。失败时的下一步：端口仍被占用，则查找仍在运行的实例，包括其他 Unix socket 或 namedpipe 监听；系统代理已关仍无法上网，则问题不在 Clash 入站；再次开启后要求密码，则检查 authentication 与 skip-auth-prefixes。需要确认内核是否还在听时，使用文档中的外部控制地址，并注意 secret 以及 socket、pipe 不校验密钥所带来的访问范围问题。