这次真是很离奇，基本浪费了一整晚，最后才发现问题根本不在节点本身，而是在本机代理“嵌套了”。
现象一开始非常怪：
- 节点机主来问我到底怎么回事，说后端那边一直有连续的奇怪请求。
- 我这边本机几乎连不上任何节点。
- 更诡异的是，我本地代理配置怎么改，节点机那边还是持续能看到那种连续请求。
刚开始怀疑过很多方向，比如：
- 节点本身炸了
- 订阅内容有问题
- 规则写错了
- DNS 或系统代理没切干净
- 某个程序在后台疯狂重试
结果最后排出来，核心问题其实是代理回环 / 嵌套代理。
更具体一点，就是本机当时并不是只有一个 mihomo 在跑，而是同时有两份：
- 一份是当前 Sparkle 正常拉起的
mihomo - 另一份是旧的残留孤儿进程
于是流量路径开始变得非常诡异，像“短路”一样在本地绕来绕去：
- 本地配置改了，但真正接管流量的未必是你以为的那一份 core
- 某些请求会被重复转发、重复命中，最终在节点机那边看起来像连续的奇怪请求
- 本机自己反而会表现成大量节点不可用、几乎全部连不上
我后面才恍然大悟：这不是单纯的“节点坏了”，而是本地代理套本地代理 / 残留 core 叠了一层。
把旧的残留进程清掉之后，再重新打开 Sparkle，系统里恢复成：
- 一个 Sparkle 主进程
- 一个由它拉起的
mihomo子进程
这时候就正常了。
这次的教训很直接：
- 看到“节点端有奇怪连续请求 + 本机几乎所有节点都不通”时，不要只怀疑远端。
- 先查本机到底跑了几个代理 core，尤其是
mihomo这种有没有残留孤儿进程。 - 一旦发生嵌套或回环，症状会特别像玄学，实际上是本地流量路径已经乱掉了。
如果以后再遇到类似情况，我觉得第一反应应该就是先查：
- 有几个
mihomo在跑 - 谁是父进程，谁是孤儿进程
- 哪个实例真正监听了
7890/7891/7892 - 系统代理是不是又指回了自己
离谱，但也算长记性了。