Clash Verge Rev 日誌查看指南：常見錯誤訊息與排查方式

先重現一次請求，再查看同一時間的日誌

Clash Verge Rev 的日誌可用來判斷故障發生在哪個環節：設定檔是否載入、網域是否解析、請求符合哪條規則，以及代理節點是否連得上。紅色錯誤不一定表示所有連線都中斷；單筆失敗紀錄也不能直接證明訂閱已失效。先確認實際操作，再查看相近時間的紀錄。

用戶端介面與 mihomo 核心處理的工作不同。下載訂閱、操作介面及管理服務可能會產生用戶端日誌；代理連線、規則比對與 DNS 處理則主要記錄在核心日誌中。遇到「訂閱更新失敗」，先查看更新操作的提示；若是「瀏覽器無法開啟網頁」，則優先檢查核心連線日誌。

1. 開啟側邊欄的「日誌」頁面，記下目前時間，並暫停其他下載或測速工作。
2. 只瀏覽一個有問題的網站並重新整理一次，避免同時開啟十幾個分頁。
3. 在日誌中找到該時間點的目標網域、連接埠及錯誤訊息。有搜尋欄位時輸入關鍵字；若沒有，可複製必要片段並在本機文字編輯器中搜尋。
4. 開啟「連線」頁面，確認目標位址、符合的規則與代理鏈。短連線可能很快就消失，此時請以已記錄的日誌為準。

如何切換日誌層級：平時使用 info，排查時改用 debug

日誌層級會影響記錄的詳細程度，不會直接修復連線。在「日誌」頁面尋找上方的日誌層級選項；支援此控制項的版本可暫時從 info 切換至 debug。如果介面只有篩選選項，請分清楚「篩選已收到的日誌」與「變更核心日誌層級」：只調整顯示篩選，無法讓核心補上先前未記錄的細節。

介面沒有日誌層級選項時

mihomo 對應的設定欄位是頂層的 log-level。若需透過設定調整，請先備份，再使用目前版本支援的覆寫或合併方式加入下列一行，並重新載入設定。不要只修改之後會被訂閱更新覆蓋的原始內容，也不要假設編輯後已立即生效。

log-level: debug

重現問題後，確認是否出現更詳細的紀錄，以驗證設定已生效。排查完成後，請將層級恢復為 info。除錯日誌可能包含瀏覽過的網域、內網位址及代理名稱，不適合長時間開啟後整份公開分享。

連線逾時：先確認逾時的是節點還是目標網站

i/o timeout、context deadline exceeded 和 connect: connection timed out 都表示某項操作未能在期限內完成，但發生的位置可能完全不同。若錯誤前後出現 dial tcp，請繼續查看連線目標的 IP 與連接埠，不要一看到 timeout 就更換 DNS。

dial tcp 203.0.113.10:443: i/o timeout
context deadline exceeded

這裡的 203.0.113.10 是文件範例位址，不是可用來測試的節點。若實際日誌中的位址屬於代理伺服器，請檢查本機至節點之間的連線；若請求符合 DIRECT，該位址可能屬於目標網站。使用多層代理鏈時，也要確認連線在哪一跳失敗。

以相同目標進行交叉比對

• 只有一個節點逾時：在同一個策略群組中切換至另一個已知可用的節點，再瀏覽相同網址。若恢復正常，優先檢查原節點的位址、連接埠、服務狀態或網路連通性。
• 多個節點都逾時：檢查本機網路、入口網站驗證、防火牆，以及代理伺服器位址是否能正常解析。多個節點共用同一個網域時，也可能是共同入口發生異常。
• 只有一個網站逾時：確認規則與出口狀況。目標服務故障、出口受限或路由異常，都可能造成相同現象。
• 測速成功但網頁無法開啟：測速通常只會連線至設定的測試網址，無法保證所有網站、UDP 流量或各種協定都能正常使用。

不要一開始就把逾時時間調得很長。延長等待時間只會延後報錯，不會修正錯誤的節點位址，也無法恢復遭封鎖的連線。

DNS 解析失敗：分辨無法解析位址與解析服務無法連線

遇到 no such host、DNS resolve failed，或包含 DNS 上游位址的逾時訊息時，請先確認解析失敗的是哪個網域。代理伺服器的網域解析失敗，可能導致許多網站都無法使用；若只有單一網站的網域解析失敗，則應針對該網域排查。

系統 DNS 測試不等於核心 DNS 測試

可使用系統命令交叉比對；以下命令會查詢文件範例網域：

nslookup example.com

系統查詢成功，只能表示該命令使用的解析路徑有傳回結果。mihomo 可能使用獨立的 dns.nameserver、加密 DNS、網域策略或代理伺服器專用的解析設定，結果不能直接互相取代。瀏覽器的安全 DNS 也可能使用另一條解析路徑。

啟用 TUN 後，也應確認 DNS 劫持是否接管了預期的流量。使用 Fake-IP 模式時，連線資訊中出現設定的合成位址範圍，不一定代表異常；例如 198.18.0.0/16 常用作 Fake-IP 位址池，仍須搭配網域對應與規則判斷最終連線狀況。不要只因為看到這個位址就刪除整段 DNS 設定。

設定檔解析錯誤：先依行號檢查縮排，再確認欄位引用

設定載入失敗通常發生在建立連線之前。常見訊息包括 yaml: line 12: did not find expected key、欄位型別不符，以及規則引用了不存在的策略群組。此時反覆切換節點沒有幫助，應先確保設定檔能通過解析與核心驗證。

縮排錯誤與欄位型別錯誤

# 錯誤範例：nameserver 的階層不一致
dns:
  enable: true
 nameserver:
    - 1.1.1.1

# 正確範例：同層欄位對齊，清單位於 nameserver 下方
dns:
  enable: true
  nameserver:
    - 1.1.1.1

YAML 縮排須使用空格，不要混用 Tab。行號通常指出解析器發現問題的位置，但實際錯誤可能出現在前一行，例如漏了冒號、引號未成對或清單縮排有誤。檢查報錯行時，至少一併查看前後幾行。

• 欄位型別：mixed-port: 7897 應設定為連接埠數值；清單欄位不可任意改成一整段字串。
• 名稱引用：規則中的策略名稱必須對應到已存在的代理或策略群組。重新命名策略群組後，也要檢查 rules 中的引用。
• 規則提供者：RULE-SET 引用的名稱必須已在 rule-providers 中定義。下載失敗與名稱不存在是兩種不同問題。
• 設定來源：若只有更新訂閱後才發生失敗，請先保留錯誤訊息與舊設定檔，再確認是訂閱回傳內容異常，還是本機覆寫設定與新設定檔互相衝突。

連接埠遭拒與位址被占用：先確認錯誤位址屬於哪一端

connection refused 表示連線遭到明確拒絕。若位址是 127.0.0.1:7897，請優先檢查本機代理是否正在監聽，而非遠端節點。開啟用戶端「設定」，查看目前的混合連接埠，並確認核心運作正常；手動填入應用程式的代理連接埠也必須與之一致。

connect to 127.0.0.1:7897: connection refused
listen tcp 127.0.0.1:7897: bind: address already in use

第二種錯誤表示監聽連接埠已被占用。Windows 使用者可在終端機執行下列命令，查看監聽紀錄及其 PID：

netstat -ano | findstr :7897

macOS 與已安裝 lsof 的 Linux 系統，可查看相同 TCP 連接埠上的監聽程序：

lsof -nP -iTCP:7897 -sTCP:LISTEN

先確認程序屬於哪個應用程式，不要直接結束不熟悉的系統程序。若要將用戶端混合連接埠改為 7898，也要同步更新瀏覽器擴充功能、終端機環境變數及其他手動代理設定。使用系統代理的應用程式也應重新確認系統代理狀態，避免仍指向舊連接埠。

若遭拒的是遠端節點位址，請檢查節點連接埠與服務狀態。即使錯誤關鍵字相同，位址不同，應處理的對象也不同。

如何區分 TLS 錯誤、連線重設與 TUN 異常

TLS 憑證與交握錯誤

遇到 x509: certificate has expired or is not yet valid，請先確認系統日期、時間與時區，再檢查伺服器憑證的有效期限。certificate is valid for 這類訊息可能表示憑證網域不符，請確認節點的伺服器位址、TLS 服務名稱及訂閱參數。

TLS handshake timeout 不等於憑證錯誤，也可能是連線遭封鎖、封包遺失，或遠端未依預期回應。不要把關閉憑證驗證當成通用解法；這既無法解決所有交握失敗，也會降低身分驗證能力。

連線重設與 EOF

connection reset by peer 表示連線遭對端或路徑中的設備重設；EOF、unexpected EOF 表示讀取時連線已結束。這些情況可能源自目標服務、代理伺服器或中間網路，單憑這幾個字無法判斷是哪一方的問題。

若紀錄只在關閉網頁或結束下載後出現，而且實際使用正常，可以先觀察。若每次瀏覽相同位址都立即失敗，請記下目標、使用的節點與發生時間，再透過切換節點或網路進行比對。

TUN 建立失敗與權限問題

若出現與虛擬介面、路由安裝或權限相關的錯誤，請先確認用戶端服務模式是否正常，以及目前系統是否允許建立虛擬網路介面。TUN 接管的是網路流量，無法修復節點本身失效；若系統代理正常但 TUN 失敗，請集中檢查虛擬介面、路由及其他 VPN 是否衝突。

測試時不要同時變更 TUN、DNS、節點與規則。先記錄原本狀態，每次只調整一個變數。若要了解兩種流量接管方式，請參閱用戶端使用教學；欄位說明可參考進階設定。

透過關鍵字縮小範圍，保留可重現的排查紀錄

有效的紀錄應能串起「哪項操作失敗」與「相關的日誌內容」。先搜尋目標網域，再查看同一時間範圍內的錯誤，通常比單獨篩選所有 error 更有幫助。背景健康檢查、規則集更新及其他應用程式也會產生日誌，不要把所有異常都歸因於目前瀏覽的網頁。

1. 記下環境資訊：作業系統、實際使用的用戶端版本、mihomo 版本，以及系統代理與 TUN 是否啟用。版本資訊請以用戶端顯示為準，不要依安裝時間推測。
2. 固定重現步驟：記錄目標網址、發生時間、應用程式名稱及具體狀況，例如「頁面一直載入」或「立即顯示代理連線失敗」。
3. 保留前後文：複製首次失敗前後約 10 至 20 行相關日誌，保留時間、錯誤關鍵字、連接埠及規則資訊。
4. 進行一次比對：只切換節點或只更換網路，並記下是否恢復。不要同時重寫設定檔，之後再宣稱某個開關有效。
5. 恢復日常設定：將日誌層級調回 info，復原臨時測試項目，並儲存最後確認有效的設定。

排查順序可固定為：設定是否載入 → 本機連接埠是否正在監聽 → 網域是否完成解析 → 規則是否符合預期 → 節點與目標是否連得上。先處理連線路徑中最早失敗的環節，再查看後續錯誤。這樣能減少重複修改，也能避免將同一次失敗產生的多筆日誌誤認為多個獨立問題。