本文目录
配置没有改，重载后网页却偶尔连错或断开，容易让人先清 DNS 缓存。若你使用 Mihomo 的 Fake-IP 模式，可以先核对一个更具体的现象：旧域名在重载后仍保留地址，却在查询新域名之后得到不同地址。
刚重载时没变，为什么后来旧域名换了地址？
官方 #3281 提供了 v1.19.32 与 alpha-9f053c4 的 macOS 复现：同一配置重载会保留映射，但后续新域名分配可能从地址池开头重新占用旧地址。这不是“每次重载立刻改变所有 Fake-IP”。
Fake-IP 是内核交给应用使用的虚拟地址，内核还需要把它对应回原域名。只看到网页卡住，或只看到两次 DNS 结果不同，都不足以确认这个缺陷；报告中与 AdGuard 卡顿的实际因果也未得到证明。
先把相似现象分开
| 观察到的情况 | 判断与下一步 |
|---|---|
| 同一进程重载同一范围后，新查询挤占保留的旧映射 | 按本文核对版本并做前后查询对照。 |
| 退出进程、清过缓存或改过 fake-ip-range 后地址改变 | 这些操作已经改变条件，不能据此确认本缺陷。 |
| 域名返回真实公网地址，或请求根本没有进入内核 DNS | 先检查监听地址、查询类型、hosts 与 Fake-IP 过滤规则。 |
v1.19.33 修复了哪一部分？
v1.19.33 正式发布说明列出 #3283 的修复。固定源码在复制旧映射后，仅当新旧地址池范围相同时，同时保留分配位置 offset 和循环状态 cycle，避免从开头再次分配刚保留的地址。
随修复加入的测试检查：复制后给新域名分配地址时，原有域名和反向映射仍然保留。这不承诺地址永远不变；地址池容量回收、范围变化、进程重启等情况仍要分别判断。
profile.store-fake-ip 用于保存 Fake-IP 映射。开启它不等于已经取得这次分配状态修复，也不是本问题已验证的绕过方法；不要为了对照随意切换它或删除缓存文件。
怎样保留条件，查到真正的 Fake-IP？
先从客户端的内核信息或本次启动日志确认正在运行的 Mihomo 版本。图形客户端版本不等于内核版本；在另一个目录运行 mihomo -v，也不能证明客户端实际使用那个文件。
查询必须发到实际的 dns.listen。下面以本机 127.0.0.1:1053 为例，只在它与你核对的监听一致时照用；其他情况替换服务器地址和端口，不要为套用示例修改监听配置。
先记录，再进行一次配置重载
保留原配置和状态
独立备份当前配置与客户端数据，记录内核版本、地址范围、过滤规则和持久化开关。选择可中断的时间，暂停自动订阅更新，防止对照期间又换配置。
记录一个已有域名的地址
用下方 A 查询记录旧域名 example.com 的 Fake-IP。它必须确实进入该内核的 Fake-IP 分配；若命中 hosts 或过滤规则返回真实地址，就换成适合对照的域名。
通过现有入口重载同一配置
使用客户端或服务已经支持的重新加载配置入口，保持进程和 fake-ip-range 不变；不要同时退出应用、清缓存或更换配置。确认操作确实触发了内核重载。
先查新域名，再回查旧域名
查询此前未由该内核分配过的域名，再查旧域名，对比地址与相应日志。example.net 只是示例；若以前查过，应换成自己可控且未查询过的域名。
nslookup -type=A -port=1053 example.com 127.0.0.1完成同一配置的重载后，再依次执行下方两条查询。若工具不存在，使用系统已有的等效 DNS 查询工具；不要改用浏览器缓存结果代替，也不要向公共 DNS 查询后把真实地址当作内核映射。
nslookup -type=A -port=1053 example.net 127.0.0.1
nslookup -type=A -port=1053 example.com 127.0.0.1一次新查询未触发覆盖，不能证明旧内核不受影响；池中已有分配和查询次序会影响结果。保留每次域名、地址与时间，不做大量生产域名请求来强行触发，也不把正常容量回收误判为同一缺陷。
怎样更新，才能实际用上这次修复？
先看应用或服务是否支持独立更新内核。支持时从其认可的正式渠道选择包含本修复的版本，并保留原文件与配置；不支持时等待或选择维护者明确说明已集成修复的正式客户端包，不擅自覆盖应用内部文件。
v1.19.33 的正式记录确认收录此修复，但不能仅凭客户端刚更新就断言内核已更新。完成更新后检查新的启动日志或内核信息，确认真正运行了目标版本。
更新后重新建立一组对照
保留可恢复的原状态
把独立备份、原版本与配置对应好，确认恢复方法后再更新。不要覆盖唯一备份或把另一版本直接写入唯一数据目录。
确认新进程实际版本
按维护者要求启动更新后的内核，查看正在运行的版本，核对实际加载的配置和 DNS 监听。
在新进程内重新做前后查询
升级通常会重启进程，旧进程与新进程的地址不必相同。先重新建立旧域名映射，再在同一新进程内重载同一配置、查询新域名并回查旧域名。
怎样确认结果，不把一次成功当成全部修好？
同时核对映射和实际连接
- 已记录真正运行的内核版本，而不是只记录图形客户端版本。
- 前后查询发到同一 dns.listen，使用 A 类型，且域名没有被 hosts 或 Fake-IP 过滤规则排除。
- 在同一新进程、同一地址范围内完成重载对照，没有清缓存、退出进程或中途改配置。
- 适量新域名查询后，保留的旧域名映射未被提前挤占；同时核对与它有关的实际网页或应用新请求。
- 恢复原自动更新安排后再次观察，失败时保留版本、配置差异和脱敏后的查询记录。
如果映射保持而连接仍失败，继续检查实际路由、上游解析和应用连接记录，不把所有 DNS 或 AdGuard 故障都归于这次修复。本文依据官方报告、修复与回归测试，没有代替你的客户端环境做实机复现。
更新后仍异常时，怎样回退并留下线索？
若新版本造成其他兼容问题，通过原来的受支持更新方式恢复已保存的原内核或客户端，再按对应版本恢复独立备份。停止受影响操作后再切换，避免两个版本同时写入同一数据目录。
回退旧版本可能重新带回本缺陷，不能视为最终修复。恢复配置和原自动更新安排后，重新检查运行版本、DNS 监听及实际连接；不要靠清空唯一缓存或删除订阅来掩盖尚未查明的差异。
向维护者反馈时提供内核完整版本、系统、重载方式、实际地址范围、持久化设置和有顺序的前后查询结果。移除订阅凭据、secret、私人域名与个人信息；原 issue 的状态本身不等于你所用安装包是否包含修复。