本文目錄
Wi-Fi 切到行動網路，或電腦換了網路後，節點還能連線，部分網站卻持續逾時。舊 DNS 答覆可能是排查方向，也可能是新網路、DNS 上游或節點的問題；先保留一組對照，再決定是否清除快取。
換了網路，只有部分網域仍然打不開？
FlClash v0.9.2 正式發行加入手動及網路變更時清除 DNS 快取的功能。本文依該版本的介面與固定版本原始碼說明操作，適用於 Android 與桌面用戶端；清理快取不保證能修復所有換網斷線。
先判斷哪些情況值得清理
| 實際觀察 | 下一步 |
|---|---|
| 一般網路正常，FlClash 中的同一網域仍然失敗 | 固定 Profile、節點及網域，記錄查詢後，清理一次作為對照。 |
| 關閉 FlClash 接管後，一般網路也無法存取 | 先恢復新網路或系統解析；應用程式快取不能取代連網排查。 |
| 只有某個節點失敗，切換節點後同一網域正常 | 優先檢查節點與出站，不能只憑網站打不開就判定快取過期。 |
| 剛重新載入設定後，Fake-IP 對應異常 | 另外檢查 Fake-IP 與重新載入範圍；本文的按鈕不會重設 Fake-IP 位址池。 |
這個按鈕清除什麼，哪些內容不會改變？
DNS 查詢頁的按鈕會呼叫 FlClash 核心的 clearDnsCache，最後執行 dns.ClearAll()。它會清理核心保存的 DNS 答覆，並重設相關 DNS 上游用戶端連線，讓後續查詢重新取得結果。
該版本使用的用戶端核心分支，也會在桌面端重新讀取系統 nameserver 清單。這並非執行 Windows 或 macOS 的系統 DNS 更新命令，也不保證瀏覽器或其他應用程式的快取會一併清空。
清除 DNS 答覆與清除 Fake-IP 對應是不同操作；固定版本原始碼另有 FlushFakeIP。不要把這次清理視為刪除虛擬位址池，也不要因此修改 fake-ip-range、重新匯入訂閱或清空應用程式資料。
DNS 查詢清單是觀察紀錄。清理快取不會刪除這些歷史紀錄；清單仍在，並不表示按鈕沒有生效。後續應查看新的查詢時間與實際請求，而非等待清單變空。
清理前，先保留同一網域的對照
每次只改變一個條件
記下版本與目前網路
確認應用程式實際為 v0.9.2，記下系統、網路類型、換網時間、目前的 Profile、節點及原有 DNS 覆寫。舊版沒有此按鈕時，不要在其他設定裡猜測哪個開關作用相同。
確認一般網路是否可用
短暫停止 FlClash 接管，以同一網路存取原目標。僅在允許直接連線的情境下測試；必須經過代理的業務應先暫停，直接連線成功不代表代理已恢復。
回到原設定，記錄新查詢
重新使用同一 Profile 與節點請求目標，在工具的 DNS 頁面找到對應網域，記下 A 或 AAAA、時間、來源、回應碼及答覆。若沒有紀錄，先確認請求是否經過 FlClash DNS。
系統或瀏覽器可能保留既有答覆與連線。DNS 頁面沒有新查詢時，不能只憑重新整理網頁就判定核心是否重新解析；先對照新的查詢紀錄，必要時重新發起該應用程式的請求，不要同時修改多組 DNS 參數。
在 v0.9.2 的「Tools → DNS queries」中清理
手動清理並立即複查
開啟 DNS 查詢頁
以下按英文介面標示對照：進入 Tools，選擇 DNS queries，確認目前頁面確實是查詢紀錄。頂端掃帚按鈕的提示為 Clear DNS cache；導覽配置可能隨視窗寬度改變。
只執行一次清理
點選掃帚，等待結果。成功提示為 DNS cache cleared，失敗則為 Failed to clear DNS cache。成功只表示這次核心操作回傳成功，不能取代網站存取驗證。
重新發起原請求
保留同一網路、Profile、節點及 DNS 設定，重新請求同一網域，核對同一紀錄類型的新時間、來源、回應碼及答覆，再確認實際 HTTPS 頁面或業務請求。
出現失敗提示時，先保留日誌並核對核心執行狀態，不要連續點選或刪除全部設定。若沒有此入口，先備份並核對專案正式 v0.9.2 與系統支援情況，透過正常更新管道取得對應版本，不擅自覆寫應用程式內部的核心。
換網時會自動清理，為何仍需手動驗證？
網路變更時清理是該版本的內建行為，原始碼並未提供需要使用者開啟的自動清理開關。不能因此保證每次 Wi-Fi 狀態提示、每次重新整理網頁，或所有平台事件都會執行同一套操作。
桌面端的網路回呼，僅在核心已連線且 VPN 是否存在的狀態未改變的對應路徑中，經約 200ms 彙整後清除 DNS；它本身不會直接關閉全部作用中的連線。
Android 使用原生網路觀察。首選網路的 DNS 清單變更時，會更新核心使用的系統 DNS；既有首選網路從 A 切換至 B 的路徑，則會透過 resetNetwork 先關閉作用中的連線，再清除 DNS。自動清理不代表舊連線必然不中斷，也不能從桌面端行為推論 Android。
換網後若仍異常，維持相同目標，做一次手動清理對照即可。只有新的查詢與實際存取結果支持，才能記錄為本機已恢復；不要為了強制觸發回呼而反覆斷開網路。
如何確認結果，而非只看成功提示？
清理後的驗證清單
- 已記錄版本、網路、Profile、節點及 DNS 覆寫，清理前後沒有同時變更設定。
- 對照同一網域及 A 或 AAAA，確認有新的查詢時間，並記錄來源、快取標記、回應碼及答覆。
- 不要求 IP 必須改變，也不要求第一筆紀錄的快取標記一定為「否」；同時發生的請求可能先填入快取，正確的 DNS 答覆也可能仍是同一個位址。
- 原本的 HTTPS 頁面或業務請求確實完成，連線紀錄顯示預期出站；節點延遲數字或 VPN 圖示不能取代這一步。
- 之後自然切換網路時，複查相同目標。若問題再次發生，保留網路、查詢及連線紀錄的時間對照。
新的查詢仍顯示逾時、拒絕或解析錯誤時，應繼續核對目前網路、DNS 上游、規則及節點。僅憑清理前後的差異，無法證明快取是唯一根因；本文也不保證清理一次就能永久解決換網問題。
仍然失敗時，如何還原與回報？
已清除的快取無法透過按鈕復原，後續查詢會重新建立。若這次只執行清理而未變更設定，就維持原本的 Profile 與 DNS；若另做過對照，則還原這次更動項目的原值。清理失敗時，不必還原整份應用程式備份。
升級後若出現其他相容問題，先停止受影響的操作，透過原本支援的方式還原對應版本與獨立備份；避免兩個版本共用同一資料目錄。暫停接管後，確認一般網路可用，必須經過代理的業務則繼續暫停。
向專案回報應用程式與系統版本、換網類型及時間、同一網域與同一紀錄類型的前後查詢、清理成功或失敗提示，以及實際請求的出站與錯誤。公開資料應遮蔽訂閱權杖、密碼及私人網域，原始備份留在本機。