本文目录
Windows 上正常退出 FlClash 后，系统代理仍开着，不一定是清理失败；原来的代理被关闭，也不意味着应用保存了旧设置却没有恢复。先看设置来自哪里，再决定保留、关闭或按原值恢复。
退出以后，代理还在与代理被关是两种情况
FlClash v0.9.2 的正式发布记录提到保留不是由它设置的系统代理。本文限定 Windows 10/11、该版本的系统代理开关与正常退出；不把 TUN、WinHTTP、终端环境变量或应用内代理当成同一份设置。
先按退出前后的真实设置分流
| 看到的现象 | 先做什么 |
|---|---|
| 本次从未尝试启用，或此前已成功停用，退出后原代理还在 | 先核对它是否仍是自己需要的原服务器或脚本；不因开关还开着就清空。 |
| 曾启用 FlClash，退出后原企业代理或 PAC 没有回来 | 该版本没有自动恢复原值的保证，按事前记录恢复需要的设置。 |
| FlClash 已退出，手动代理仍启用并指向它原来的本地端口，且请求失败 | 核对是否真的正常退出、系统设置和失败日志，再按原网络需要恢复。 |
| 浏览器正常，只有终端或某个应用失败 | 另查该程序的代理来源；系统代理开关不能代表所有程序。 |
v0.9.2 保留的是哪一种设置？
该版本进入系统代理启用流程后，会留下一次待解除记录；退出时只在记录仍在的情况下停用。此前已成功停用就会清掉记录，与本次从未尝试启用一样，不会在退出时重复解除。它不等于读取 Windows 当前代理来判断归属。
固定源码把这次记录称为 _applied，并在调用 startProxy 前就置为 true；所以它表示已经尝试，并不证明系统代理写入成功。启用和停用失败都可能留下 update system proxy failed 日志。
Windows 的 stopProxy 走 WinINet，把连接选项切到 PROXY_TYPE_DIRECT；它没有保存并还原之前的服务器、PAC 或全部例外。系统代理被解除与恢复原来的企业网络设置不是一件事。
判断也不能只看自己有没有手动点过开关：该版本 systemProxy 默认 true，已保存的自动运行等状态可能进入启用流程。真正需要区分的是这次进程有没有尝试接管，而不是记忆里有没有点击。
先记录 Windows 原值和 FlClash 当前状态
保留可恢复的对照
记录系统设置
打开 Windows 设置的“网络和 Internet → 代理”。分别记录“自动检测设置”、配置脚本、手动代理的开关，以及脚本地址、服务器、端口和例外。原来不用代理时，也记下这个状态。
记录应用与接管方式
确认 FlClash 实际版本为 v0.9.2，记下当前配置、实际代理端口、仪表盘“系统代理”和“虚拟网卡”（TUN）的状态，以及自动运行设置。不要用默认端口代替实际值。
安排单独验证
在可中断的使用时段验证系统代理。记录 TUN 原值后暂时关闭“虚拟网卡”（TUN），暂停其它会自动改写同一 Windows 设置的功能；需要的原代理服务可以继续运行。
没有可信原值时先保留现状与记录，使用原代理工具或组织提供的恢复方法，不填入陌生服务器。Windows 设置显示由组织管理而不能更改时，按既有管理员流程恢复，不删除注册表项来绕过。
验证“本次未接管”时，原代理是否保留
建立一个清楚的新进程对照
先保存 FlClash 系统代理关闭
在可控状态关闭 FlClash 的“系统代理”，再从托盘“退出”正常结束。关闭开关本身可能解除本次代理，先确认已经记录原值。
恢复需要的原代理基线
FlClash 退出后，用原工具或 Windows 代理页恢复事前确认的自动检测、脚本和手动代理设置，并验证真实请求。原来允许直连则恢复原直连状态；不要把直连当作需要代理业务的等价恢复。
重新打开但不启用系统代理
确认已保存的系统代理关闭，留意自动运行状态，全程不启用该开关。用同一目标请求核对原路径，再从托盘“退出”；关闭窗口可能只是最小化，不能代替这一步。
比较 Windows 与真实请求
再次查看自动检测、配置脚本和手动代理的开关、地址、端口是否仍符合基线，验证同一请求。如果设置变化，记录前后时间、应用状态与日志，不只凭图标推断。
v0.9.2 的普通退出保护只适用于其对应流程。若原代理没有变化且需要它继续工作，就保留原值；若仍被关闭，先保留可复现条件，不能据一次结果断言其它版本、所有退出方式或其它软件也受保护。
本次接管过，就按原值恢复所需网络
需要验证 FlClash 自己的系统代理时，先确认它已运行并记下实际端口，确认 TUN 仍关闭，再开启“系统代理”。Windows 设置应与 FlClash 的本地地址 127.0.0.1 和实际端口对应；单看按钮亮起不能证明写入成功。
停用、恢复与复查
停止这次接管
通过“系统代理”开关停用，或使用托盘“退出”正常结束，等待操作完成。若出现 update system proxy failed，保留日志和 Windows 当前值，不连续切换掩盖差异。
恢复原来需要的配置
原来直连时，把手动代理恢复为原来的关闭状态；原来用其它服务器或 PAC 时，按事前记录恢复自动检测、脚本、手动代理各自开关，以及地址、端口和例外，或让原工具重新设置。不要假定退出会自动还原。
分别验证实际请求
在恢复后的同一网络访问原目标，核对使用了预期代理或直连。若只某个程序失败，另查该程序配置，不一口气重置 WinHTTP、环境变量和所有代理层。
如果别的工具在 FlClash 接管后又写入了系统设置，本次进程的记录并不会自动变成可靠的“当前归属”判断。先让写设置的操作串行完成，再恢复所需原值；不要把它当作多客户端自动仲裁机制。
哪些结果通过，才算完成？
退出与恢复验证清单
- 已经记录应用完整版本、真实端口，以及 Windows 自动检测、配置脚本与手动代理的原值。
- 已把本次从未尝试接管、曾经尝试接管及开启失败分开，不只凭点击记忆判断。
- 使用托盘正常退出，而不是仅关窗口、任务管理器强制结束或安装程序的清理过程。
- 退出或停用后 Windows 设置符合实际需要；原自动检测、企业服务器、PAC 或例外已按记录恢复。
- 同一目标的真实请求通过，终端、TUN 或应用内代理另有异常时单独保留证据。
安装和卸载是另一条路径：该版本安装程序会调用带 --clear-stale-proxy 参数的进程来处理遗留代理。它不等于本文的普通退出队列。不要为验证本次保护运行该参数，也不能把强制结束或崩溃当成已经执行正常清理。
设置仍异常时，怎样回退和反馈？
先停止本次对照，恢复自己记录的 Windows 设置、FlClash 系统代理与 TUN 原值及其它临时改动，再确认普通网络和必须通过原代理的目标。若代理服务本身不可用，先恢复那个服务，不只是把同一失效地址重新填回。
若为了取得功能需要升级，先独立备份应用数据和 Windows 原值，再通过项目正式渠道更新。升级后出现兼容问题时，用原支持方式恢复对应版本与备份；回退不会自动还原 Windows 外部设置，也不要让两个版本共用唯一数据目录。
向项目反馈完整客户端与系统版本、是否自动运行、系统代理和 TUN 状态、这次进程的启用经过、正常退出方式、前后地址及失败时间。公开材料隐藏私人服务器、PAC 凭据和订阅令牌；原始日志与备份保留在本机。