本文目錄
設定沒有修改，重新載入後網頁卻偶爾連錯或中斷，很容易讓人先清除 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 的狀態本身，並不能證明你使用的安裝套件是否包含修正。