1. 為何雙堆疊會讓「開了 TUN」仍像漏網
Clash TUN會在本機插入虛擬介面，嘗試讓符合條件的 IP 流量進入代理管線；但在雙堆疊環境中，同一個網域名稱往往同時有 A 與 AAAA 紀錄。若應用程式或作業系統解析後優先走向 IPv6，而你的 TUN／規則／DNS 路徑沒有把該 IPv6 前綴完整納入策略，外觀就像「明明開了隧道、測漏仍顯示電信／家裡的真實位址」。這不是一定代表用戶端損壞，而是資料平面分裂：IPv4 與 IPv6 在路由表裡是兩套決策。
另一個容易混淆的點是系統代理與 TUN的覆蓋範圍差異：前者主要影響願意讀取系統 Proxy 的應用程式；後者較接近「符合條件就進管線」。然而作業系統仍可能在介面層優先發起 AAAA，若上游或本機某段設定把 IPv6 視為「不需進 TUN」的本地直連，你就會在雜誌式教學裡看到矛盾說法。實務上應先接受一個工作假設：要嘛讓 IPv6 也走同一套匹配鏈，要嘛在排查期暫停 IPv6，避免兩條路徑互相污染觀測。
2. 典型徵兆：真實位址、錯區、或只部分網站異常
最常見的用戶描述是：測漏網站顯示 ISP 配發的 IPv6，或顯示「IPv6 連線／IPv4 連線」其中一欄仍為本地。另一種是跨境服務只對特定子網域或 API做地區檢測，瀏覽器頁面正常、後端 API 却回傳「區域不可用」——在雙堆疊下，這常與某一筆解析仍落到直連的 IPv6有關，而非單純節點品質問題。與 地區限制與 Fake-IP這類題目相同，關鍵一直是「連線層與解析層是否敘述同一故事」，只是 IPv6 讓故事多了一條平行叙事線。
若你同時使用公司 VPN、校園網路或家長管控軟體，也可能出現路由表互相覆寫：Clash 日誌顯示命中代理，但應用程式實際封包仍繞過。此時請優先排除「第二套 VPN 或安全軟體正在改寫介面優先序」，再回頭檢查 IPv6；與 Windows 11 圖形版首次設定一文所述的多模式並存情境可以交叉閱讀。
3. 系統與介面：關閉或暫停 IPv6 的取舍
排查期「暫時關閉作業系統的 IPv6」是最快縮小變因的方法之一：在 Windows可於介面內容取消勾選 IPv6 通訊協定；在 macOS可針對特定介面調整設定；在 Linux桌面則常以 NetworkManager 或發行版網路面板處理。若關閉後測漏結果立刻一致，幾乎就能斷定先前問題在雙堆疊資料平面，而不是訂閱本身。長期是否維持關閉視你的網路環境而定：有些 ISP 僅對 IPv6 提供較佳的對等連線，關閉後可能反向影響延遲；這時就應改走下一節的「讓 IPv6 也進同一套 Clash 管線」。
行動裝置上，系統層選項差異更大：部分ROM／廠商介面不直接暴露關閉開關，這時請以「路由器層關閉 IPv6」或「客戶端僅使用 IPv4 出站策略」為替代路線。重要的是：不要同時改太多變因。建議先固定一個客戶端版本與同一套訂閱，再只切換 IPv6 開關對照日誌，避免把規則誤判成壞掉。
若你主要處理 UWP 或 Windows Store 類程式，亦可搭配 Clash TUN 與 UWP 回環一文，確認應用程式是否仍有特殊回環限制與雙堆疊無關的第二類問題。
4. mihomo：IPv6 開關、TUN 與本機堆疊
在 mihomo（Clash Meta）核心中，通常會透過頂層 ipv6 與 tun 相關區塊表述「核心是否接受／產生 IPv6」。實際鍵名與預設值會隨版本演進，請以你正在執行的發行說明與範例組態為準；下面片段僅示意排查時最常檢查的語意方向，註解使用英文以利版本控管。
① 全域 IPv6 語意（示意）
ipv6: false # If leaks stop with this, revisit dual-stack routing or DNS AAAA handling.
② TUN：與 DNS 堆疊協同（示意欄位）
tun: enable: true stack: system # Or gvisor/mixed per your OS; mismatch can change IPv6 capture behavior. dns-hijack: - any:53
stack 選項會改變虛擬介面與系統堆疊互動方式；某些環境下切換 system／gVisor 類模式，可觀察到 IPv6 封包是否較一致地進入 Clash。搭配 dns-hijack是為了避免作業系統仍向「非 Clash 指定的解析路徑」送出 DNS，形成規則看起來命中、實際解析先走旁路的表徵。若你希望先建立心智模型再回到 GUI，可瀏覽 進階分流與規則順序的總覽段落。
開啟或關閉 IPv6、切換 TUN stack 都可能影響延遲與相容性；建議每次只調一個欄位，並保留上一版 YAML 備份再對照 mihomo 日誌。
5. DNS 雙堆疊校準：AAAA、Fake-IP 與 nameserver-policy
若你把 DNS 外洩當成「瀏覽器測到的解析伺服器不是節點那側」，在雙堆疊裡還要多問一句：應用拿到的位址族別是否與你的策略一致。例如 Fake-IP 模式下，本機程式先拿到一個「看似私有」的映射，真正的目的地由核心還原；當 AAAA 仍被系統或程式另行解析時，可能出現「IPv4 走 Fake-IP、IPv6 仍用真實前綴」的組合。這時候需要的不是再多堆規則，而是把 DNS 模組與 TUN 的 hijack／routing-mark 敘事對齊。
nameserver-policy 與 fallback 類設定，用於替特定網域後綴指定不同上游；跨境服務專文常見寫法是讓敏感後綴固定走可信上游，避免被本地 ISP 搶答。把同一套邏輯搬到 IPv6 場景，意味著你也要確認上游是否回傳你期望的 AAAA，以及核心是否在後續匹配時把它視為應代理流量。這與「只改規則卻不改 DNS」的傳統踩雷點是同一枚硬幣的兩面。
6. 分流校準：規則順序、GEOIP 與 Sniffer
IPv6 位址進入管線後，規則仍依序命中；若你大量使用 GEOIP 或下載型 rule-providers，請確認資料庫版本與規則合併順序是否過時——錯置的 MATCH 或過早的 DIRECT 會讓 IPv6 看起來像「莫名其妙直連」。需要抽絲剝繭時，可參考 rule-providers 與 GEOIP 更新一文，對照日誌關鍵字與下載失敗原因。
當連線以 IP 顯示在日誌、而規則多寫在維度時，Sniffer可把 TLS Client Hello 中的 SNI 還原成網域命中。這在「IPv6 先到、沒域名無法分流」時特別有感；細節步驟已於 Sniffer 專文展開，本篇只強調：IPv6 場景下請把 Sniffer 日誌與「是否真的走 TUN」一併閱讀，避免誤判為節點問題。
7. 可重現的驗證與清單
建議以三層對照完成驗證：① 關閉系統 IPv6 前先截圖測漏、② 關閉後再測一次、③ 僅在確認方向後回到 mihomo 調整 IPv6／TUN／DNS。若 ① 與 ② 差異顯著，就不必急著改訂閱；應優先把雙堆疊路徑講清楚。每次測試固定同一瀏覽器設定檔、停用可切換網路的分頁外掛，避免引入第三變因。
進階使用者可在外部裝置以 ping -6 與對照 traceroute（命令名稱依系統而定）觀察 IPv6 是否仍從實體介面出去；若在開啟 TUN 後路徑仍完全未經過虛擬介面，代表接管條件與路由優先序需要回到作業系統層再確認。完成組態後，若你尚未匯入訂閱，可先依 匯入訂閱教學建立乾淨基底，再逐步合併本篇欄位。
簡短驗證清單
- 關閉系統 IPv6 後，測漏網站的 IPv4／IPv6 欄位是否與預期一致。
- mihomo 日誌中，同一目標是否同時出現 IPv4 與 IPv6 命中，或其中之一為
DIRECT。 - DNS 模組與 TUN 的 hijack 是否實際生效（可暫時提高日誌等級對照）。
rule-providers／GEOIP是否過期或順序過寬鬆。- Sniffer 還原的網域是否讓規則從「純 IP」回到可維護的網域維度。
寫在最後
相較單一維度的「節點不好換一顆」，IPv6 雙堆疊問題更像路由與解析的一致性問題：Clash TUN能接管很大一部分資料平面，但若 IPv6 仍在介面層擁有較早建立連線或被系統偏好的路徑，你見到的就是測漏網站上那行刺眼的真實上網位址。把「關閉／約束 IPv6」與「DNS、分流校準」放在同一張檢核表上，通常能顯著縮短試錯時間。生態內持續維護的 Clash 用戶端搭配 mihomo 日誌，也讓這類排查比起純憑感覺換節點更可控。
若你希望在一個安裝包與圖形介面內完成訂閱、TUN／系統代理切換、DNS 與規則覆寫，建議從本站 下載頁取得適合你系統的版本並完成初始設定。相較零散腳本與過時截圖，整合度高的用戶端在處理雙堆疊與日誌對照時通常更省時。若你已準備好把 IPv6、解析與分流一次對齊，現在即可動手：→ 立即免費下載 Clash，開啟流暢上網新體驗。
相關閱讀 · 同主題集群
依主題相關度匹配的延伸閱讀，涵蓋同分類下的實戰配置文章。
Clash Meta 規則集與 GEOIP 更新失敗？對照 mihomo 日誌修正路徑與權限
開啟 rule-providers 或 GEOIP 自動更新卻下載失敗、路徑找不到？從 mihomo 日誌區分 URL、TLS、DNS、快取與本機寫入權限，整理工作目錄與 geodata／mmdb，並說明規則順序與 interval；與訂閱 TLS／DNS、Sniffer 站內文互補。
閱讀全文Clash Meta 開啟 Sniffer 後 HTTPS 仍走錯節點？對照 mihomo 日誌查 SNI 並修復
規則寫好卻直連或誤入策略組？說明 HTTPS 與 SNI、Sniffer 如何還原網域，並從 mihomo 日誌確認嗅探是否生效、對照憑證與規則順序；與訂閱 TLS／DNS、策略組測速、Fake-IP 專文互補。
閱讀全文Clash 策略組裡負載均衡怎麼配：load-balance 與散列選節點分步操作
已會 url-test／fallback，仍想下載或多連線時把流量拆到一組節點、或用 consistent-hashing 讓同一來源固定出口？說明 mihomo 策略組 load-balance、strategy 與 YAML 分步寫法、規則怎麼指過來，並對照自動測速與故障轉移；與站內 url-test 專文互補。
閱讀全文