Clash 电脑端卸载后要核对系统代理状态，必须改用操作系统自己的网络信息，而不能再依赖已经删除的图形界面。Clash Verge Rev 提供系统代理和守卫，并能以服务模式运行内核；发布说明中出现过系统代理状态读取报错、内核停止后代理仍指向失效端口、服务残留等问题。因此“应用没了”只证明界面不在，不证明系统代理已关闭，也不证明端口已空闲。核对的目标是得到可复查的三项结果：代理是否启用、指向何处、该处是否还有监听。
适用条件与核对标准
本做法适用于已经卸载 Clash Verge Rev 电脑端、需要确认系统代理是否恢复的场景，也适用于卸载后浏览器或其它程序仍走代理的场景。通过标准如下：系统代理开关为关闭，或虽开启但不指向本机已不存在的服务；代理主机与端口为空或不再使用原内核端口；本机该端口无监听；TUN 若曾启用，虚拟接口不应仍处于接管状态。任一条件不满足，就不能认为卸载后的代理状态已干净。
判断时要把“读到了系统当前值”和“应用上次显示的值”分开。发布记录写过 macOS 在 VPN 接管或开机网络未就绪时系统代理状态读取报错，也写过手动配置网卡后无法设置系统代理。网络未就绪时读到的失败，不能直接当成代理已关闭。应在网络接口正常后再读一次。
具体核对步骤
第一步，打开操作系统提供的代理查看入口，记录是否启用、服务器地址和端口。界面名称因系统而异，以当前系统实际字段为准，不使用未在官方资料中出现的菜单叫法。若地址为本机回环且端口为过去内核使用的端口，即可判定仍存在应用写入的系统代理残留。这与发布说明中“系统代理仍指向失效端口”属于同一类现象。
第二步，核对本机端口。在系统仍能使用的网络工具中查看该端口是否有进程监听。无监听而系统代理仍开启，属于典型的失效代理：流量被送到空端口。有监听则还要看是否为残留服务或未卸净的内核。官方区分服务模式与 Sidecar，服务可能在应用删除后仍存在，故不能只看前台进程列表。
第三步，核对其它网络路径。系统代理只是其中一条。若代理字段已空但仍异常，检查 TUN 虚拟网卡和默认路由是否仍指向该应用创建的接口。功能说明把系统代理和 TUN 并列，核对时也应并列，避免只关代理、忽略虚拟网卡。
第四步，留下书面记录：核对时间、代理开关、地址与端口、是否有监听、是否见 TUN 接口。不需要写入完整订阅网址；若记录令牌，只保留 token= 片段。较新版本提到服务自身运行日志会保存到文件，若本机数据目录仍在，可把服务日志是否仍报告内核停止或代理错误作为旁证，但不能替代系统代理字段本身。
核对失败或结果矛盾时的下一步
若系统设置里读不到代理状态，先确认网络已就绪，再对照发布说明中代理读取失败的条件，避免在接口未好时下结论。若字段显示已关闭但程序仍报代理错误，查浏览器独立代理和残留服务，而不是反复卸载空应用。若字段显示开启且指向本机、端口无监听，应在系统侧关闭代理后再测一次连通。Windows 若因旧服务残留影响后续安装，核对代理之后仍需处理服务状态，二者不是同一项。资料见 https://github.com/clash-verge-rev/clash-verge-rev 与 https://github.com/clash-verge-rev/clash-verge-rev/releases 。