折腾一整天，把家里的网络拆了又装：一个 dae 玩家的血泪实录
摘要：删不掉的节点、打不开的 Gmail、重启即失联的虚拟机，以及一个 19% 错误率的 Cloudflare Worker。今天我把家里的网络折腾了个底朝天，最后发现最大的 bug 是我自己的运维流程。
开场：本来只想删一个节点
事情的起因特别朴素。我家里的网关是一台跑在 Mac mini 上 VMware Fusion 里的 Debian 虚拟机，桥接 IP 是 192.168.0.7，上面跑着三件套：daed（dae 的 Web 面板版）负责分流，AdGuard Home 负责 DNS 和广告过滤，Tailscale 负责出门在外回家。这套组合平时稳得像块砖，我也渐渐产生了一种"我已经毕业了"的错觉。
今天早上我只是想在 daed 面板里删掉一个不怎么用的 us1 节点。点删除，面板显示删了，刷新，没了。完事。
——然后我发现流量还在往 us1 上走。
上午：幽灵节点与静默回滚
这是今天第一个坑，也是最值得写的一个。
面板明明显示删除成功，但实际生效的配置里 us1 还在。这种"UI 说一套、实际做一套"的情况，第一反应当然是查日志。翻开 daed 的日志一看，真相大白：
我的路由规则和 DNS 规则里引用了 geosite:category-ads-all 这个分类，但当前版本的 geosite.dat 里根本没有这个分类。于是每次我在面板做任何改动，dae 尝试生成新配置 → 校验失败 → 静默回滚到旧配置。面板那边只告诉你"操作成功"，至于配置有没有真的下发，它不管。
也就是说，我过去不知道多少次"改配置"其实都改了个寂寞，全被这个坏引用挡回去了。删掉路由和 DNS 里那两条引用 category-ads-all 的规则之后，一切恢复正常，us1 才真正被删掉。
技术洞察一：引用外部数据文件（geosite.dat / geoip.dat）的规则是有"版本契约"的。 你写的规则引用了某个分类，但 dat 文件更新后分类可能改名、合并或删除。引用失效不是报错崩溃，而是更阴险的"静默回滚"——系统看起来活着，实际上一直在跑旧配置。教训是：写 geosite 规则前，先确认当前 dat 里真的存在这个分类；面板改动不生效时，第一反应永远是查日志，而不是怀疑自己的眼睛。
顺手把上午的正经活也干了：新建了三个节点组——ai（美国节点）、crypto（日韩新节点）、crypto_web3（日韩新节点），然后写域名分流规则：OpenAI、Claude、Gemini 全家走 ai 组；Bybit、Binance、OKX 走 crypto 组；DeBank、Uniswap 这类 Web3 站点走 crypto_web3 组。交易所对 IP 属地和稳定性敏感，AI 服务对地区有要求，分开走是基本修养。
下午：39 次跳变和一个 19% 错误率的 Worker
下午进入验证环节。
先测交易所。手机上打开 Bybit，日志里 www.bybit.com 一度走了 proxy 默认组而不是 crypto 组。心里一紧，以为规则没生效，再仔细一看时间戳——是我刚重载配置和手机发起请求之间有个时间差，路由重载的空窗期里请求按旧规则走了。等重载完成再测，所有交易所域名全部乖乖走 crypto 组的新加坡节点。虚惊一场，但也提醒我：配置重载不是原子的，验证时别在刚改完的那几秒里下结论。
再测 AI。Claude、ChatGPT 都正确走了 ai 组的美国节点。但日志里有个扎眼的现象：10 分钟内，流量在两个美国节点之间来回切换了 39 次。
这是 dae 组策略的典型行为——如果策略是按延迟选优（比如 min），两个延迟相近的节点会轮流"夺冠"，每次健康检查结果一波动就切换一次。对普通网页无所谓，但对 Claude、ChatGPT 这种登录态服务，源 IP 高频跳变是触发风控认证的经典姿势。我把数据摆出来咨询：要不要给 ai 组固定一个节点，或者用更"粘"的策略？用户（也就是我自己，扮演了一下理性的甲方）拍板：保留多节点，先观察。
顺着这个话题我把 dae 的五种组策略梳理了一遍：
- min：选当前延迟最低的，最激进，跳变最频繁；
- min_avg10：选最近 10 次平均延迟最低的，平滑一些；
- min_moving_avg：移动平均，对突发抖动更不敏感；
- fixed：固定节点，最稳但失去故障转移的灵活性；
- random：随机，基本只适合特殊场景。
对于登录态敏感的服务，fixed 或 min_moving_avg 明显更合适。这个策略切换的提案我记下来了，暂未拍板——今天已经有太多改动，变量要一个一个来。
技术洞察二：负载均衡式代理和登录态服务天然有仇。 延迟最优 ≠ 体验最优。对风控敏感的目标（AI、银行、交易所），IP 稳定性权重要提到延迟前面。选策略前先想清楚这个组里的流量"怕什么"。
下午的第二个雷来自 Cloudflare。我顺手看了眼 Workers 的用量面板：今日总请求 63289，其中一个叫 cfnode 的 worker 独占 63282 次——这本身没问题，它本来就是干这个的。但点开错误数：12139 次报错，错误率 19%。
排查下来原因简单粗暴：我之前往订阅里加了 40 个 cfnode 节点（20 个 trojan-go + 20 个 vless），这 40 个全是坏的。每五个请求就有一个打到死节点上，worker 在那边干着急。没有任何犹豫，拍板删除这 40 个节点。错误率应声落地。
技术洞察三：节点数量是一种负债，不是资产。 面板里躺着 40 个死节点的唯一作用，就是在你不注意的时候吃掉 19% 的请求成功率。定期清理死节点比添加新节点重要得多。以及——监控面板要常看，这个 19% 如果我不点开，可能还要再烂一个月。
傍晚：Gmail 之死与订阅商之殇
傍晚干了件大事：把 Mac 上的 Surge 关了，网络改成手动静态 IP，网关和 DNS 全部指向 192.168.0.7——也就是说，这台 Mac 的流量也正式交给 dae + AdGuard Home 接管。全家桶统一，理论上很美好。
改完验证，大部分正常，然后发现 Gmail 打不开。
Google 系服务打不开，第一反应当然是"节点问题"，但其他 Google 服务都好好的，唯独 Gmail 超时。查 dae 的 DNS 链路才发现真相：dae 的 DNS 上游配的是 dns.google:53，也就是明文 UDP 53，而这个上游请求本身要走代理出去——结果它命中了一个已经死掉的 vless 节点，DNS 查询一直超时。Gmail 的域名解析恰好被路由到了这条坏路径上。
修法也简单：把 DNS 上游从 UDP 53 改成 DoH——https://dns.google/dns-query。DoH 走 443，路径和存活策略都不一样，绕开了那个死节点，Gmail 秒开。
技术洞察四：DNS 上游也是流量，也要走分流，也会踩死节点。 很多人（包括之前的我）把 DNS 配置当成"基础设施"，默认它永远可靠。但在 dae 这种架构里，DNS 查询本身是被路由的普通流量，上游协议的选择（UDP 53 / DoT / DoH）直接决定它走哪条路、踩哪些坑。DNS 出问题时症状五花八门（特定网站打不开、间歇性超时），排查时别忘了把 DNS 链路本身当成嫌疑对象。
刚喘口气，更大的来了：傍晚例行健康检查发现，全部日韩新订阅节点 + 部分美国订阅节点集体 NOT ALIVE。注意细节：TCP 能连通，但代理握手失败。这个特征很关键——TCP 通说明服务器在线、端口在听，握手失败说明服务端的代理服务挂了或者密钥/配置变了。结论：不是我这边的网络问题，是订阅服务商端故障。
能做什么呢？什么也做不了，除了止损：从 proxy 组里摘掉 25 个死节点，剩下 27 个存活节点（包括早上差点没删掉的 us1，命运真是爱开玩笑）。这也是多节点组存在的意义——单点故障时，组内还有足够的冗余兜底。
深夜番外：重启一次，回到解放前
晚上 Mac 重启了一次。然后两件事同时发生：
- 手动设置的静态 IP / 网关 / DNS 丢了，网络配置被还原；
- VMware Fusion 里的 Debian 虚拟机没随开机启动，网关直接消失，双路失联。
家里瞬间回到拨号上网时代的体验。用 vmrun start 把虚拟机组回来，网络恢复，然后痛定思痛，决定写个 launchd plist 让虚拟机开机自启。
然后就连踩两坑：
- 坑一：照着老教程用
launchctl load，结果发现这命令早就废弃了，现代 macOS 要用launchctl bootstrap gui/$(id -u) <plist>； - 坑二：改完 plist 文件没存盘就 bootstrap，加载了一个空配置，排查半天才发现编辑器没保存。是的，2026 年了，人类还是会栽在 Ctrl+S 上。
最终 plist 生效，虚拟机开机自启，关机断电重启演练一遍，全自动恢复。至此，这套系统的最后一个"需要人肉干预"的环节被消灭了。
教训总结（这部分是写给未来的自己的）
今天折腾了十几个小时，真正值得刻下来的教训有这么几条：
1. 咨询类问题，先给数据和建议，等拍板再动手。 今天两次被纠正（节点切换策略、组策略调整），都是因为看到问题就手痒想直接改。正确的姿势是：摆数据、列选项、给推荐、等确认。改动越多，变量越乱，出问题越难定位。
2. 面板显示成功 ≠ 配置真的生效。 daed 的静默回滚机制决定了任何改动后都要验证实际行为。改动不生效，第一步永远是查日志，不是重复点击。
3. 写 geosite 规则前，先查 dat 文件里有没有这个分类。 一条失效引用可以废掉你后续所有的配置变更，而且毫无声息。
4. 死节点是负债。 今天一共清了 65 个死节点（40 个 cfnode + 25 个订阅节点），它们生前唯一的贡献是拉低成功率、制造 19% 的错误率。定期体检，及时出清。
5. Mac 重启会丢手动网络设置。 改完静态 IP 记得截图存档，不然重启之后你会对着网络偏好设置面板怀疑人生。
6. 作为网关的虚拟机，必须开机自启。 没有自启的网关虚拟机，本质上是一个定时炸弹，爆炸时间就是下一次系统更新重启。以及，2026 年了别再用 launchctl load，以及，记得按 Ctrl+S。
今天的网络终于恢复了平静。daed 面板里 27 个节点绿油油地活着，Cloudflare Worker 的错误率回到了正常水位，Gmail 秒开，Claude 暂时还没把我踢去验证。
至于那个 min_moving_avg 策略切换的提案？明天再说吧。毕竟折腾的第一守则就是：系统能跑的时候，别动它。