Clash 訂閱拉取失敗？Windows 下對照日誌排查 TLS 與 DNS（附修復步驟）

1. 先釐清症狀：瀏覽器能開，不代表客戶端同一條路

當你懷疑 Clash 訂閱更新失敗，第一件事請先寫下三個觀察：錯誤文案（逾時、TLS handshake、憑證不受信任、DNS）、是否只在更新訂閱時發生，以及瀏覽器用同一台電腦、同一條寬頻直接開網址是否成功。若瀏覽器成功而客戶端失敗，常見原因不是「網址打錯」，而是客戶端在拉取時會走你設定檔裡的 DNS 模組、可能經過 本機 mixed-port／系統代理鏈，並以程式庫發起 TLS，而不是瀏覽器那套擴充套件與憑證儲存區。

另一個容易誤判的點是：你可能已開啟 TUN 或 系統代理，瀏覽器因此「剛好」走代理而訂閱站點可達；但 mihomo 更新訂閱時，若規則或路由把「對訂閱網域的連線」導向不穩定的節點、或形成自己拉自己的回環，就會出現只有客戶端失敗的現象。這也是為什麼我們後面會請你對照日誌裡的實際連線目標與出站標籤，而不是只看 UI 上的綠燈。

若你尚未熟悉匯入流程，可先閱讀 節點訂閱匯入教學，確認 YAML 內 proxy-providers／rule-providers 或傳統 proxies 訂閱區段本身沒有語法問題；本篇假設「檔案寫入沒報錯」，專注在網路層與 TLS 層的失敗。

2. 訂閱拉取鏈路：從 DNS 到 TLS 再到出站節點

以 mihomo 核心為例，更新訂閱可以想成一串排隊：解析訂閱網域（受 dns 區段、fake-ip、fallback 影響）→ 建立 TCP 連線 → TLS 交握與憑證校驗 → HTTP GET 下載內容。其中任一步卡住，UI 往往都只顯示「更新失敗」，但日誌會給不同線索。Windows 上還要多考慮：本機安全性軟體對「非瀏覽器行程」攔截更嚴、以及 公司根憑證是否只安裝在使用者憑證庫而程式讀不到等邊角情境。

若你使用圖形客戶端（例如 Verge 系），訂閱更新通常仍由核心執行；圖層負責把錯誤顯示出來。當懷疑路由互相打架時，請回頭檢查：訂閱網域是否被規則導到某個 DIRECT 或高延遲節點、以及 DNS 是否先把網域解析到「只在瀏覽器環境才正確」的位址。這類問題在 DNS 解析與 fake-ip 並用時特別常見，因為應用程式看到的 IP 可能與你以為的不同。

3. 日誌要怎麼看：關鍵字與時間軸

請在客戶端開啟「核心日誌」或寫入檔案日誌（實際選項名稱依版本略有差異），並在按下訂閱更新後從第一行錯誤往前後各抓數十行。你會想搜尋這幾類關鍵字：dial、timeout、i/o timeout、TLS、handshake、certificate、x509、lookup、NXDOMAIN、no such host、EOF、reset。它們大致對應「連線建不起來」「TLS 失敗」「DNS 失敗」「對方提早關閉連線」四種方向。

若日誌裡同時出現 TLS handshake timeout，但同一時間用瀏覽器開 HTTPS 很快，請不要急著怪節點；先確認客戶端是否改走另一條路由或另一組 DNS。另一個實務技巧是：把訂閱網域抄下來，在 PowerShell 用 Resolve-DnsName 或 nslookup 對照（僅作為輔助），再看 mihomo 內建的 DNS 日誌是否出現重試或 fallback。記得：系統 DNS 工具看到的是「作業系統解析鏈」，不一定等於 mihomo 的 dns 區段行為，但巨大差異通常代表你找對方向了。

Example: resolve subscription host from PowerShell (system resolver path)
Resolve-DnsName sub.example.com

當日誌顯示已連上遠端 IP、長時間停在某個階段後才失敗，比較像網路品質、被 RST、或對端限速；若一開始就失敗在解析，則回到下一節 DNS。請避免只靠「感覺」切換節點，先用文字證據把層級分開，修復會快很多。

4. DNS 解析類：lookup 失敗、慢、或被導去錯誤位址

DNS 解析問題的典型日誌是 lookup 失敗、no such host，或連續重試後才成功但已超過客戶端逾時。Windows 家用寬頻上，ISP DNS 偶發慢或快取污染也會讓「瀏覽器剛好用 DoH 所以沒事」與「核心走 UDP 53 所以爆炸」並存。處理順序建議是：先在設定檔確認 dns.enable、nameserver、fallback 與 fake-ip 是否符合你的使用情境；再檢查是否有過度激進的攔截規則把訂閱網域導去錯誤 IP。

若你同時使用 fake-ip，請理解：某些應用在收到假 IP 後仍會用「網域」做別的驗證，但 HTTPS 客戶端多半會用 SNI；訂閱下載屬於常規 TLS，多數情況下只要 DNS 模組與路由沒互相打架即可。若你發現「關掉 fake-ip 就突然能更新」，通常代表規則或 DNS 回退順序需要重排，而不是單純把 fake-ip 當成開關賭運氣。

想延伸理解 DNS 與分流的邊界，可搭配閱讀站內 Claude／Fake-IP 前置讀物 的思路：那篇以服務網域為例，但「先確認 DNS 日誌再談規則」的方法論完全適用於訂閱網域。

5. TLS 交握類：憑證、SNI、公司網路與中介憑證

若日誌出現 certificate signed by unknown authority、x509 之類字樣，代表 TLS handshake 階段校驗失敗。常見情境包含：訂閱站點憑證鏈不完整、你所在網路有 HTTPS 檢查（MITM）、或公司代理把流量置換成自簽憑證。瀏覽器可能已信任該公司根憑證，但 mihomo 行程未必讀同一個憑證庫，於是出現「瀏覽器 OK、客戶端不行」。

實務上請先確認訂閱 URL 是否為 HTTPS、憑證是否來自公開 CA；若你必須在公司網路更新訂閱，請依資安規範處理根憑證信任問題，而不是在設定檔裡隨意關閉校驗（若你的客戶端或外掛提供類似選項，風險極高，不建議作為長期解法）。另一個較溫和的方向是：改用手機熱點或其他網路驗證是否為環境性 MITM，再把結果交給 IT 處理憑證鏈。

SNI 與 HTTP/2、CDN 邊角

少數訂閱網域架在 CDN 後面，若客戶端 TLS 的 SNI 或 ALPN 與瀏覽器預設不同，可能觸發不同的邊緣規則。此時日誌常會看到握手階段被拒絕或立即斷線。處理方式仍是：先固定 DNS 與路由，再用最小設定重現，避免同時調三個變因。

6. 本機網路：mixed-port、回環、防火牆與多層 Proxy

當 mihomo 已設定 mixed-port（同埠混用 HTTP／SOCKS）或分拆的 port／socks-port，而你的系統或上游又把「本機程式對外連線」導回代理，就可能形成回環（loop）：訂閱更新流量繞了一圈又回到自己，最後逾時。這類問題在「系統代理指向 127.0.0.1」「同時 TUN 也接管」或「其他加速軟體注入 LSP／Filter Driver」時更常見。

建議你用兩步驗證：第一，暫時關閉「由客戶端寫入的系統代理」或改為純手動確認；第二，在日誌確認訂閱連線的 實際 outbound 標籤 是否符合預期（例如是否意外走了需認證的 HTTP 代理）。若你正在調整區網分享或 Docker 走主機代理，請一併參考 區網共用與 mixed-port 指南，裡面對「本機要連哪個埠」有更可操作的對照。

Windows 防火牆或第三方防毒若攔截「非瀏覽器行程對外連線」，也可能表現成間歇性逾時。排查時請記錄：是每次必敗還是尖峰時段才敗；後者更像限速或供應商側問題，前者更像本機或憑證。

7. 訂閱源與反爬：User-Agent、頻率限制與 CDN

有些訂閱站會對 User-Agent、來源 IP、或更新頻率做限制；瀏覽器因為帶了完整瀏覽器 UA 與 Cookie 行為，看起來像「正常訪客」，而 mihomo 的請求可能被當成異常流量。若日誌顯示 HTTP 403／429，或 TLS 成功但內容長度異常，請先降低更新頻率、避免多台裝置同一秒輪詢同一 token，並確認訂閱商文件是否要求固定 UA 或特定路徑。

另一種情況是訂閱商臨時把檔案搬到 CDN，舊網址在瀏覽器因 302 導向仍可用，但客戶端因不跟轉或規則攔截導致失敗。此時請用瀏覽器開發者工具看實際最終 URL，再回到客戶端更新為穩定跳轉後的 HTTPS 終點（若供應商允許）。

8. 可複製的修復檢查清單（依序做）

步驟 A：固定變因。先關閉多餘 VPN、公司全流量代理、以及會改寫系統 Proxy 的「網路加速」工具，只保留 Clash 與乾淨的網路，重試訂閱更新一次並存日誌。

步驟 B：分類錯誤。在日誌搜尋上一節關鍵字：先判是 DNS、TLS，還是 TCP／HTTP 層。若完全沒有 TLS 字樣就失敗，偏向 DNS 或連線被擋；若卡在 handshake，偏向憑證或網路品質。

步驟 C：檢查路由與回環。確認訂閱網域沒有被規則導向會回環的出站；暫停「寫入系統代理」後再測一次。若你剛完成 Win11 首次設定，請對照 Windows 11 Verge Rev 系統代理與 TUN 設定，避免在核心尚未穩定時就把多層模式全開。

步驟 D：調 DNS 與 fake-ip。為訂閱網域準備乾淨的 nameserver／fallback，避免過度依賴單一 UDP 路徑；調整後觀察日誌是否仍出現 lookup 重試。

步驟 E：處理 TLS 與環境。若確定為 MITM 或公司憑證，請走資安流程；若是供應商憑證鏈問題，請向供應商回報並暫時改用官方建議鏡像。

步驟 F：對照訂閱商限制。降低更新頻率、確認 token 是否過期、必要時更換訂閱入口 URL。

9. 開源資訊與回報習慣

若你使用基於 mihomo 的客戶端，上游專案適合放在獨立段落了解授權、原始碼與 Issue 回報方式；公開儲存庫可參考 MetaCubeX／mihomo。回報問題時請附上去除敏感 token 後的訂閱網域、完整錯誤堆疊、以及作業系統與客戶端版本；避免只截圖「更新失敗」而沒有日誌。與「取得安裝包」分開：一般使用者要下載可執行檔，仍建議優先使用本站 下載頁，再依 使用教學總覽銜接到分流與規則調校。

例行更新客戶端前，建議先備份設定檔；若更新後才開始訂閱失敗，請比對新舊版本的 TLS 預設與 DNS 行為差異，而不是第一時間重灌系統。