症狀：為什麼「只有幾個站」特別像 IPv6 問題？
若你關閉 Clash 後一切正常、或改用手機行動數據就恢復，而開啟代理時卻出現部分網站打不開、特定 CDN 子網域逾時、或同一頁面在重新整理數次後才載入，很值得優先懷疑雙堆疊與路由不一致。典型模式是：解析同時拿到 A（IPv4）與 AAAA（IPv6），應用程式優先走 IPv6，但這條路徑在目前的閘道、學校網、公司網或代理出口上並未完整打通；IPv4 卻沒問題，於是使用者感覺像「被挑站點」。
Clash 類工具會再疊一層：分流規則多半以域名或 IP 為單位匹配，若 IPv6 流量沒有被同一套邏輯接住（例如規則缺 IP-CIDR6、或 TUN 只穩定處理其中一種位址家族），就會出現「日誌裡以為直連、實際卻從介面溜出去」的落差。接下來六步的目的，就是把作業系統、核心開關、DNS 與規則對齊到同一敘事，而不是盲目換節點。
這套流程刻意與「純 TLS 握手」「純訂閱更新」類教學錯開角度：你若已能穩定連上大多數站，只剩少數域名在開 IPv6 後才翻車，先把本文六步跑完，再決定是否深入憑證鏈或節點協定細節，通常更省時間。
第一步：確認作業系統與網路介面的 IPv6 狀態
在動 Clash 之前，先用系統工具確認 IPv6 是否「真的可用」，而非僅顯示有位址。Windows 可用 ipconfig /all 檢視各介面是否取得全球單播位址、閘道與 DNS 是否一併下發；macOS 可從「系統設定」→「網路」檢視詳細資訊，或使用終端機指令檢視路由表。若 IPv6 在 ISP 端本身斷斷續續，任何代理都只是在不穩定的地基上施工。
實務上建議做一個對照實驗：在網路介面暫時停用 IPv6（僅作診斷，診斷完可還原），若問題站點立刻恢復，幾乎可判定與 AAAA 優先有關。請記錄停用前後各測一次相同網域，避免把「剛好節點恢復」誤當成根因。若你必須長期使用 IPv6，則應回到後續步驟，讓 Clash 與規則支援 IPv6，而不是永久關閉系統功能。
第二步：核對 Clash／mihomo 核心的 IPv6 開關
設定檔頂層或通用區塊中常見的 ipv6: true/false（實際鍵名請以你所用分支文件為準），控制的是核心是否參與 IPv6 相關行為，與「系統有沒有 IPv6 位址」並不等價。若系統已開 IPv6、核心卻關閉，部分出站或嗅探行為可能與應用程式預期不符；若核心開啟，但節點或上游不支援 IPv6，雙堆疊站點仍可能在 IPv6 嘗試階段卡住。
操作原則仍是單因次：在固定 TUN／系統代理與 DNS 模式的前提下，只切換 ipv6 開關並重載設定，觀察同一組測試網域是否穩定。若開啟後惡化、關閉後改善，請同步檢查節點供應商是否宣告 IPv6 支援，以及下一節 TUN 是否正確承載 IPv6 預設路由。
實務上還有一類「看起來像節點掛掉」的案例：健康檢查或延遲測試只打 IPv4，實際瀏覽卻觸發 AAAA，導致自動選組挑到對 IPv4 友善、對 IPv6 卻黑洞的線路。此時若把問題誤判成「訂閱爛」而不看家族，會反覆換群組仍無解。建議在日誌中同時留意連線目標是 v4 還是 v6，再決定是否要在策略組層暫時偏好某一家族，或向節點商確認出口雙堆疊品質。
若你使用圖形客戶端，請確認「設定檔文字」與介面開關沒有互相覆寫：有些前端會在儲存時合併預設值，導致你以為關了 IPv6、實際重載後又開回。養成在修改後看一遍實際生效的 YAML 片段或核心日誌開頭摘要，能省下大量來回猜測。
第三步：TUN、預設路由與「漏網之魚」
TUN 模式會改寫系統路由表，讓更多程式無需額外設定即可進入代理管道。IPv6 若仍有更高優先序的介面路由繞過 TUN，或 MTU 導致分段異常，就會出現「瀏覽器偶發空白頁」「只有某 CDN 子網域失敗」。建議閱讀本站TUN 與系統代理對照教學中與路由、例外、bypass 相關段落，並比較「僅系統代理」與「TUN 開啟」兩種模式下的同一網域行為。
若只有 IPv6 流量異常，請在客戶端日誌中搜尋該次連線的目標位址是否為 IPv6 格式（含冒號）。若日誌幾乎只有 IPv4，但瀏覽器仍卡住，可能是應用程式在 Clash 之外另行解析了 AAAA，需回到 DNS 步驟處理。
第四步：DNS、AAAA 與 Fake-IP 的疊加效應
雙堆疊環境下，DNS 回覆是否包含 AAAA，直接影響應用程式要先連哪一條路。若你在 Clash 使用 fake-ip，域名規則通常能較早介入，但部分應用程式或系統解析器仍可能快取真實 AAAA，或在 Clash 未接管解析時先行查詢，造成規則命中與實際連線家族不一致。此時可參考Fake-IP 與 Redir-Host 專文，以 fake-ip-filter、nameserver／fallback 與 redir-host 對照實驗縮小範圍。
實務上可將上游 DNS 暫時簡化為少數可信來源，並確認沒有「繞過 Clash 的系統 DoH／私人 DNS」與設定打架。若某站只在特定解析器下回傳錯誤 AAAA，問題會表現得像節點故障，實則是解析分叉。請以連線日誌中的域名與策略為準，而不是只看延遲測試數字。
行動裝置上，Android 的「私人 DNS」與 iOS 的「限制追蹤」類選項，常會讓少數應用程式改走系統解析鏈，與桌面行為不同。若只有手機異常、電腦正常，請優先比較兩邊的 DNS 設定與是否啟用 TUN，而不是先複製電腦整份 YAML 到手機。Captive Portal 或校園網環境也可能對 IPv6 與 IPv4 採用不同認證狀態，讓「已連上 Wi‑Fi、但 IPv6 仍半開」成為常態。
當你懷疑某網域的 AAAA 有問題時，可嘗試在可信環境下比對不同解析器的回覆是否一致；若僅在某一 ISP 下 AAAA 指向異常段，規則再完美也救不了。此時要嘛在客戶端暫時讓該類流量強制走 IPv4 路徑（作為權宜），要嘛在 DNS 段為該網域指定更穩定的上游，兩者都應配合日誌驗證，而不是長期靠「感覺」。
第五步：分流規則、GEOIP 與 IP-CIDR6
當規則大量依賴 GEOIP 或 IPv4 的 IP-CIDR 時，IPv6 目標可能未被同一條規則覆蓋，因而落入預設策略或錯誤的直連／代理分支。若你的訂閱或自建規則含 IP-CIDR6，請確認其順序與國內／海外清單是否與 IPv4 邏輯對稱；若完全沒有 IPv6 條目，在雙堆疊站點上就容易出現「同一域名、不同家族走不同策略」的現象。
策略組方面，請留意自動選擇與健康檢查是否對 IPv6 同樣有效；部分節點僅 IPv4 可用，卻仍被納入 IPv6 嘗試路徑，會放大逾時。更細的規則語法與策略組寫法可搭配YAML 規則與策略組教學，但請記住：規則再漂亮，也必須與 DNS、位址家族與 TUN 路由一致，否則只會在日誌裡製造更多問號。
另一個容易忽略的是 MATCH 之前的「兜底」與實際意圖不符：例如你希望國內站直連，但 IPv6 段沒被對應的國內清單命中，最後整包被送進代理，出口對該 IPv6 目的地反而不通。修這類問題時，請先確認日誌裡顯示的目標位址是 v4 還是 v6，再回頭補規則或調整清單，而不是只加更多 DOMAIN-SUFFIX 卻永遠對不到真實連線。
若你同時使用 Rule Providers，請注意更新頻率與快取：IPv6 段新增往往晚於 IPv4，熱更新中的短暫空窗也會讓少數使用者「偶發」失敗。將這類現象與訂閱整體故障區分開來的方法，仍是固定時間窗口內重複抓日誌，看規則版本與命中是否一致。
第六步：用日誌與指令驗證「到底走了哪條路」
最後一步是把前五步的假設落到證據。在客戶端開啟連線日誌，針對異常網域記錄：命中規則名稱、策略組、出站標籤、目標 IP 或域名、以及位址家族。若你有權使用命令列，可對同一主機分別以 IPv4／IPv6 發起測試（例如僅強制 IPv4 的 HTTP 用戶端與支援雙堆疊的工具對照），觀察是否僅 IPv6 失敗。
撰寫排查筆記時，建議固定三個樣本網域：一個純 IPv4 熱門站、一個已知雙堆疊的大站、一個你實際故障的站，並在每次只改一項設定後重測。這套方法能避免「同時改 DNS 與 TUN 後剛好好了」但無法重現的挫折感。若日誌顯示流量已正確進入預期出站卻仍握手失敗，才將重心移回節點品質與 TLS／SNI 專題。
家用路由器＋桌面 Clash 並存時，也請確認沒有「兩層 DNS」或「兩層預設路由」：例如路由器廣播的 IPv6 RDNSS 與電腦上 TUN 注入的解析器不一致，會讓少數程式挑到路由器那一側，表現為只有特定應用異常。此時可先把情境簡化為單一閘道或單一解析入口，再逐步恢復複雜度。
最後提醒：IPv6 相關問題特別吃環境，同一份設定在朋友家正常、在你家異常並不罕見。把「當下網路供應商、是否開啟 TUN、DNS 模式、核心 ipv6 開關」四件事寫進筆記，未來遇到類似症狀才能快速對照，而不是每次從零開始搜尋論壇片段。
常見問答（精簡版）
為什麼開啟 IPv6 之後，只有部分網站打不開？ 因為應用程式可能優先使用 AAAA，而該路徑在目前的網路或代理鏈路上未完整可用；IPv4 仍正常時，症狀會像挑站點。
核心的 ipv6 開關和系統 IPv6 是同一回事嗎？ 不是，需分開核對；二者不一致時，最容易出現規則與實際連線家族脫節。
fake-ip 下 IPv6 要注意什麼？ 注意解析時序與快取是否讓應用程式仍持有真實 AAAA，必要時以 redir-host 做對照實驗；詳見本站 DNS 專文。
TUN 是否更容易踩到 IPv6？ 往往如此，因路由與注入範圍更大；請與系統代理模式對照，並一次只改一個變因。
寫在最後：對齊雙堆疊，比盲目換節點有效
Clash IPv6相關問題的本質，多半是雙堆疊世界裡「哪條家族先被選中」與「代理是否完整接住該家族」不一致，再疊上 DNS 與 Fake-IP 的時序差異。願意依序核對作業系統、核心開關、TUN、解析與 分流規則的使用者，通常能顯著縮短「只有幾個站打不開」的除錯時間，也更清楚自己的 YAML 在什麼前提下成立。
相較於僅憑感覺切換節點，把連線日誌與單因次實驗當成習慣，長期維護成本更低。若你希望使用介面清楚、能搭配較新核心與一致說明的客戶端來落實這些設定，也可從本站整理好的安裝入口開始，少在版本與權限細節上繞路。
歡迎前往我們的下載頁面取得對應平台客戶端；先把 IPv6 與 DNS 路徑對齊，再搭配規則與 TUN 進階調校，整體體驗會更可控。
想依場景延伸閱讀，可從技術專欄索引中挑選 DNS、TUN 與 YAML 規則文章，拼出最適合你網路環境的排查地圖。