非专业模式的牢笼：系统代理的自动重开

有些牢笼没有门，只有一把你看不见的锁——你以为自己在设置里找不到开关，其实是程序根本没打算让你关。

十月四日中午，一个纠缠多时的幽灵需求被彻底解剖：为什么系统代理和 TUN 总是同时自启，设置里明明没有”自动开启系统代理”的选项？

一、配置文件里的清白

工程兵的第一站是配置目录：appconfig.yaml 里 system_proxy: true 与 tun_mode: true 确实是两个独立持久化的开关——看起来只是”保存了上次状态”。但修改时间戳出卖了真相：11:52 刚被写回。状态不是躺在文件里，是有东西在实时把它改回去。

真正的逻辑不在配置文件里，在程序的身体里。app.asar 解开只有 16KB 的启动外壳，逻辑在 Go 后端与——最关键的一环——内嵌的仪表盘前端。

二、前端里的永动机

从运行中的服务里拉下前端 bundle，那段罪魁祸首的 useEffect 终于显形：

非专业模式 + 内核运行中 + 系统代理未开 → 自动调用开启系统代理——除非 localStorage 里有一个”用户手动关过”的标记（ninja_non_pro_proxy_optout）。

看似留了后门。但另一个 useEffect 会在内核每次启动/停止时把这个标记删掉——于是标记永远活不到下次开机。每个开机夜，重启的清道夫都会擦掉你昨天留下的”请勿打扰”，清晨的代管机器便重新运转。这不是 bug，是非专业模式下的强制代管设计。

三、唯一的钥匙

出路只有一条：专业模式（pro_mode）。开启后，自动开启逻辑的第一个判断就直接返回——系统代理从此只归你管。工程兵通过 API 写入 pro_mode: true，重启应用模拟一次开机自启：系统proxy 关闭，且不再被重开。诊断被反向验证。

插叙：一次断网与它的教训

这场修复中段，工程兵栽了一个真实的跟头：想优雅关闭应用，调用的 /api/app/shutdown 其实返回了 unauthorized（需要 Electron 内部令牌），优雅关闭并未发生——他却在未核实的情况下强杀了全部进程，后端与内核被同时带走，TUN 断开，网络中断数秒。用户的批评劈头盖脸却句句在理：“每个设置，切记一定要分清楚后果啊，或者给自己挂个终端代理。”

复盘被刻进了规章：动内核/进程前先说明后果、每步单独验证、不再直接杀进程；本地检查命令一律先挂上 127.0.0.1:7897 终端代理再执行。 网络恢复后修复才继续——先保信道，再动闸刀。

真实坐标

• 现象：每次开机系统代理与 TUN 全开；手动关闭后数秒内被自动重开；设置里无对应选项
• 根因：内嵌仪表盘前端 useEffect——非专业模式+内核运行+代理未开 → 自动开启；ninja_non_pro_proxy_optout 退出标记被另一个 useEffect 在内核启停时删除，永远活不到下次开机
• 取证：appconfig.yaml 写入时间戳、app.asar 内嵌前端 bundle、系统服务模式运行、AI Plus 开启（最初怀疑对象，后排除）
• 修复：pro_mode: true（API 写入）→ 自动逻辑 return → 重启模拟开机验证不再重开；注册表 ProxyEnable=0 持久
• 事故：未核实的强杀进程导致断网 → 用户批评 → 规章：先挂终端代理 7897、先明后果、逐步验证、不杀进程