本文目錄
開關再次關閉，可能是訂閱內容變更後的保護，也可能是已確認的選擇沒有被記住。判斷前要固定同一訂閱、保存相關欄位，並分別核對開關狀態和實際解析結果；只追求開關一直開著，可能忽略來源變更後需要重新確認的情況。
DNS 覆寫確認過，重啟後為什麼仍會關閉？
“DNS 覆寫”會把 Clash Verge Rev 設定頁中的 DNS 值寫入核心設定。核心是實際處理連線的程式；設定中的 dns.enable 決定其解析功能是否啟用，和覆寫開關不同。訂閱內建受保護的解析策略時，應用要求確認，以免本機值覆蓋後導致節點或網頁無法存取。
固定同一訂閱，保存其受保護 DNS 內容，以及重新啟動前後的覆寫狀態。相關內容未變、已確認開啟，卻在重新啟動後關閉，才符合本篇修正。若訂閱更新改變相關欄位，或切到未確認的另一份訂閱，重新確認仍是正常保護。
官方 issue #7996 記錄了 macOS v2.5.4 的情況；#8024 記錄了 Windows v2.5.5 每次重新啟動都必須重新確認的情況。Clash Verge Rev v2.5.7 Release 明確列出這項問題的修復。這些回報無法證明每個系統或每個舊版本都受影響。
若開啟 TUN 後無法解析網域，而執行設定中只剩不完整的 dns 區段，應閱讀本站的 macOS TUN DNS 殘留設定排查。那是 issue #8122 的另一種設定產生問題，不能用 v2.5.7 的這項修復直接下結論。
如何判斷是重新啟動後誤關，還是訂閱更新後的保護機制？
先在設定頁記下 Clash Verge Rev 版本、目前選用的訂閱名稱與 DNS 覆寫狀態。網路已中斷時，先關閉 TUN，恢復一般網路連線或原本可用的系統代理；不要在斷網時反覆改動 DNS。
變更設定前，先備份目前的訂閱、自行編寫的擴充設定與客戶端設定，並記下覆寫頁面中想保留的 DNS 值。訂閱可能含有節點密碼與訂閱權杖，備份請只留在本機，公開回報前務必遮蔽敏感資料。
檢查目前訂閱的原始內容中的 dns。v2.5.7 標籤的原始碼只將非空的 proxy-server-nameserver、proxy-server-nameserver-policy、nameserver-policy 視為需要確認的受保護來源。
單獨存在的 nameserver、空清單、空對應表或空字串，不會觸發這項來源檢查；不能把「訂閱中有任何 dns 欄位」當成觸發條件。
比較重新啟動前後這三個欄位的實際值，以及是否仍為同一份訂閱。若訂閱在背景自動更新、切換到其他訂閱，或受保護欄位的值改變，應先依新內容判斷是否需要重新確認。只變更其他無關欄位或調整對應表的鍵順序，不應讓同一份訂閱原有的確認失效。
這一節只記錄目前版本的表現。只有確實要以本機 DNS 覆寫訂閱的解析設定時，才開啟並閱讀風險提示；在同一訂閱未更新的情況下，保存確認結果、開關狀態與執行設定，供升級後比較。
訂閱與欄位對照結果
| 觀察到的結果 | 下一步 |
|---|---|
| 同一份訂閱、受保護欄位未變，已確認的覆寫在重新啟動後關閉 | 符合本文的修復情況；核對版本並更新至 v2.5.7。 |
| 訂閱更新後受保護欄位改變，或首次切換到另一份訂閱 | 需要重新確認；比對新內容後決定是否覆蓋。 |
| 訂閱只有 nameserver，沒有三個非空的受保護欄位 | 不屬於這項保護的觸發條件；請另查設定儲存、擴充設定與日誌。 |
| 覆寫維持開啟，但開啟 TUN 後仍無法解析網域名稱 | 檢查執行設定與 DNS 上游，不要把開關狀態無法保留，當成 TUN 故障的原因。 |
如何透過 v2.5.7 修復，同時保留訂閱 DNS 保護？
從 Clash Verge Rev 專案的正式 Release 核對 v2.5.7，再依裝置平常的更新方式升級。不要從未經確認的鏡像下載，也不要清空應用程式資料目錄或手動編輯產生的執行設定。保留升級前的訂閱與擴充設定備份，以便比較實際生效的 DNS。
升級後繼續使用原本的同一份訂閱，確認三個受保護 DNS 欄位未變。確實需要本機覆寫時，開啟並完成一次風險確認，再按下一節統一進行重新啟動驗證。
v2.5.7 標籤原始碼會保存每份訂閱的確認；測試涵蓋同一份訂閱、同一組受保護來源在重新啟動後仍維持開啟，以及來源變更後重新關閉。因此修復目標是記住仍有效的確認，並未取消訂閱 DNS 的保護。切換到另一份未確認的訂閱，可能關閉該訂閱的覆寫；切回未變動的原訂閱時，原有確認仍應有效。
官方擴充設定文件指出，覆寫開啟時，覆寫頁面中有填入值的 dns 欄位與 hosts，會取代訂閱中對應的欄位；關閉時，應用程式不會因這個開關改動訂閱的 dns。全域擴充、訂閱擴充與腳本仍可能在後續流程改寫結果。若開關維持開啟但解析結果不如預期，應檢查執行設定與擴充設定流程，不要反覆切換開關。
用同一訂閱重新啟動應用程式兩次，DNS 覆寫應保持開啟
先確認版本為官方 v2.5.7、目前訂閱與三個受保護 DNS 欄位均與測試前相同。開啟並確認一次後，完整結束並重新啟動兩次，DNS 覆寫都應對這份訂閱維持開啟。
再查看執行中的設定所含的 dns，確認填入的覆寫值已進入最終設定，並固定同一節點開啟一個實際 HTTPS 網站。Windows 使用者開啟 TUN 前，還必須確認實際服務元件已包含安全修正；尚未確認的舊服務應保持停用。
需要 TUN 時，先確認系統代理或一般網路能正常使用，再於權限和服務條件都符合後短暫開啟 TUN，檢查網域解析、網頁完整載入及連線日誌。
若有第二份訂閱，切換過去時檢查它自己的覆寫狀態，再切回原訂閱；不要把其他訂閱尚未確認時的自動關閉，誤認為原訂閱設定遺失。當訂閱中受保護的 DNS 內容確實更新時，客戶端應再次要求確認，不能為了讓開關「永遠保持開啟」而繞過保護。
覆寫設定仍無法保留，或網路中斷時，恢復原設定並保留證據
先關閉 TUN，停用本機 DNS 覆寫，讓應用程式依官方文件使用目前訂閱自帶的 DNS 產生執行設定；確認一般網路或先前驗證可用的系統代理恢復。若也改過擴充設定或訂閱，從事前備份還原這些改動，再重新啟動並檢查執行設定。關閉覆寫只是撤銷本機覆蓋，不等於關閉核心 DNS，也不能保證原訂閱本身一定正確。
不要手動修改 verge.yaml 的確認值來強制維持開啟，不要隨意貼入來路不明的 DNS 設定、清空 Profile 或刪除整個應用程式資料目錄。若在 v2.5.7 上，同一份訂閱與三個受保護欄位完全未變，開關仍誤關，請向專案 issue 提供作業系統與客戶端版本、訂閱是否自動更新、重新啟動前後的開關狀態、遮蔽敏感資訊後的相關欄位、執行設定差異與日誌。
若開關維持開啟但 TUN 仍斷網，請另查 DNS 設定流程、上游解析、節點與介面，不要將其併入這次開關狀態無法保留的問題。本站已有 macOS TUN DNS 殘留設定的獨立排查文章，適用於證據吻合時的修復與還原。