先對齊症狀：是不是「優先 IPv6」造成的假性失效？
常見現象包括：同一台電腦上，某些國際站或 CDN 網站載入時間忽長忽短；開發者工具裡看得到請求發出去，但TLS 握在手上卡住；或是只有 IPv6 較普及的地區／供應商提供的頁面打不開，換手機熱點（僅 IPv4）卻立刻正常。另一種典型狀況是：DNS 明明解析成功，瀏覽器也顯示「正在連線」，畫面卻一片空白長達數十秒——這往往代表應用程式已選定某一組目的位址（通常是 IPv6），但後續路徑在某一段無回應或逾時。
若您完全沒開設定檔中的 ipv6，也未開啟 dns.prefer-ipv6，卻仍有類似問題，請優先排查節點健康、規則順序或TUN／系統代理是否一致；本文假設您已在客戶端看到「IPv6／優先 IPv6」相關選項被打開，並希望在不拆掉整套規則的前提下收斂異常。
雙棧網站在代理後發生了什麼？
現代網站常同時宣告 A（IPv4）與 AAAA（IPv6）紀錄。作業系統與瀏覽器會依版本與設定，在兩條路徑之間並行嘗試或競速連線（概念上常被稱為 Happy Eyeballs 類行為）。當您使用 Mihomo 這類使用者空間代理核心時，「要不要走 IPv6」不只取決於 home ISP，還取決於代理鏈末端節點是否真的能把 IPv6 流量送到對網際網路、以及策略組選到的出口是否支援。
因此同一個域名，在未開代理時可能長期只用 IPv4所以感覺穩定；開啟代理並打開 IPv6 或優先 IPv6後，核心／應用開始更積極選用 IPv6，反而暴露出節點 IPv6 路由不完整或本地 IPv6 ULA／ISP 委派與隧道不相容等問題。這類問題不一定是設定檔語法錯誤，而是網路拓撲與優先順序需要對齊。
小結：「打得開／打不開」在雙棰情境裡，常常是連線競賽輸贏與逾時重試的結果；請先用單一變因（先關 prefer-ipv6、不改規則）驗證，而不是一次改掉 DNS、規則與節點三組參數。
兩個旋鈕：頂層 ipv6 與 dns.prefer-ipv6
在 Clash Meta／Mihomo 常見設定裡，至少需要分清：
- 頂層
ipv6：決定核心是否處理並發起 IPv6 連線（語意類似「讓這套引擎進入雙棧模式」）。若關閉，許多情境會強制 IPv4行為較一致，但若您的環境確實需要 IPv6，就不宜長期關閉。 dns區塊中的prefer-ipv6：偏向解析結果優先序——當上游對同一域名同時給出 A 與 AAAA 時，核心／後續流程傾向先用 IPv6還是先IPv4。它不等於「開啟 IPv6 連線能力」的全部故事，但會放大上述「IPv6 路徑不佳」時的體感問題。
實務排查時，建議優先把prefer-ipv6設為 false（或依您所用 GUI 取消「優先 IPv6」），保留頂層 ipv6 開啟與否當第二個實驗：這樣能快速分辨究竟是解析優先順序惹祸，還是只要進入 IPv6 資料平面就不穩。
與 FakeIP、AAAA，以及 DNS 防洩漏長文的差異點
若您使用 enhanced-mode: fake-ip，域名會先在規則友善的假位址空間完成決策；這時公開網際網路上的雙棧解析細節常被延後到連線階段才揭露。若同步開啟prefer-ipv6，等於在「連線／選址」階段更偏向 IPv6；一旦下游 IPv6 不可用，就容易與IPv4-only 穩定的想像衝突。
這也是為什麼本文刻意與站內 Meta 核心 DNS 防洩漏指南區隔：防洩漏強調解析路徑與加密上游；本文強調雙棧優先順序與資料平面 IPv6 可行性。兩篇可以並讀，但請勿把 nameserver 列表換一套當成 IPv6 問題的全解——若問題出在出口 IPv6，改 DNS 供應商往往無感。
若您需放行區網或應直連域名以免 FakeIP 誤傷，請同步參考 fake-ip-filter 與區網／直連域名；IPv6 議題裡ULA／fc00::／fe80::也常需要不要在 FakeIP 池裡迷路，語意與該篇排除清單相通。
1建議排查順序（由快到慢）
- 確認現象是否只在「開 IPv6／prefer-ipv6」後出現：備份設定後，僅將
dns.prefer-ipv6調為false（或關 GUI 對應項），重載核心並清瀏覽器快取後再試同一網址。 - 對照另一出口或同一策略組內其他節點：若換節點後 IPv6 立刻正常，偏向該節點／線路的 IPv6 路由不完整，而非您本機 DNS 寫錯。
- 暫時關閉頂層
ipv6：若 prefer-ipv6 已關閉仍會卡在「IPv6-only／雙棧策略」相關現象，再把ipv6: false當二分法測試；確認無誤後再決定長期策略（例如維持 IPv4-only 出口）。 - 檢視
tun／系統代理模式是否一致：某些程式會繞過系統代理但仍吃系統 DNS；若 IPv6 路由只在 TUN 下完整，請對照 Clash Verge Rev TUN 模式教學，確保劫持／分流語意一致。 - 回到規則與日誌：用連線日誌對齊第一條命中規則與實際 outbound；若懷疑規則誤判，再讀 站內設定說明與策略組命名是否一致。
2YAML 片段示例（請依版本微調）
下列片段僅協助對齊鍵名位置，實際預設值與相容性請以您使用的核心版本為準；修改前請備份設定檔。
# Top-level: allow core to use IPv6 paths when appropriate
ipv6: true
dns:
enable: true
# Prefer AAAA answers when both A and AAAA exist — turn off for triage
prefer-ipv6: false
enhanced-mode: fake-ip
nameserver:
- https://dns.google/dns-query提醒：若您使用訂閱覆寫／Merge／mixin，請確認沒有另一份檔案在更深層把 prefer-ipv6 設回 true；這類「看似改了卻會復發」的案例，多半是合併順序問題。
路由器與作業系統層：別忽略 ISP／ULA
即使 Mihomo 設定看似正確，若您的路由器對 IPv6 委派不完整、或電腦拿到ULA（fc00::／fd00::）與公開 IPv6混淆路由，仍會出現間歇性連線失敗。這類問題不一定反映在 Clash 日誌的最上層，但在開 IPv6後會被放大。
排查時可先確認同一台機器在未開代理時造訪同一域名是否穩定；若未開代理也不穩，請優先處理ISP／路由器／防火牆層級，而非再加複雜規則。
節點與機場線路：IPv6 支援不是標配
許多機場節點對對外 IPv6採「視機房／線路而定」策略：同一訂閱內某些 POP IPv6 完整、某些只有 IPv4或NAT44行為較保守。當核心prefer-ipv6為真時，您的流量更容易選到 IPv6 出口；若該出口對特定 ASN／Prefixes 路由不完整，就會呈現為只有部分網站異常——這與DNS 污染不同，換加密 DNS 未必能改善。
可行的長期作法包含：在策略組中優選已知 IPv4 穩定的節點、為問題網域加獨立規則指向特定組別，或在確認無需 IPv6 時全域關閉 prefer-ipv6以降低變異數。
如何用日誌驗收「真的是 IPv6 路徑問題」？
建議抓三段證據交叉比對：（一）問題發生時連線日誌中的目的位址型態是否偏向 IPv6；（二）同一時間把 prefer-ipv6 關閉後現象是否立刻緩解；（三）換到IPv4-only 節點或手機網路後是否復現。三者指向一致時，就可以把調查重心放在IPv6 資料平面而非 DNS 文本本身。
請維持一次只改一個開關並記錄結果；這對半年後的自己或家人協助排錯會友善許多。
開源資訊與安裝包取得方式
Mihomo（Clash Meta）持續演進，鍵名與預設值可能隨版本調整；若要核對 prefer-ipv6 在不同版本的語意，建議閱讀對應版本的官方文件或 Release 說明。一般使用者取得安裝包與更新仍建議優先使用 本站 Clash 下載頁；若您需要提交 Issue 或檢視原始碼，可另外開啟公開程式庫頁面，與安裝分流入口分開看待。
結語
開 IPv6不是錯，但在代理鏈路裡，IPv6 代表的是更長的一條可用性鍊子：DNS 給出 AAAA、核心偏好 IPv6、節點也要真的能送達；任一環節偏弱，都會被使用者感知成網頁打不開。先把 prefer-ipv6與頂層 ipv6拆開理解，再用二分法對照節點／出口／路由器，多數案例都能在不必推翻整套規則的情況下收斂。
若您也需要兼顧DNS 管線透明度與規則一致性，可將本文與站內 DNS 長文並讀；與只做 FakeIP／DoH 調整相比，您會更快分辨究竟是解析側還是IPv6 路徑側該動刀。