先把等級調對
log-level 有五檔：silent、error、warning、info、debug。日常掛著建議 warning——真出事才有輸出，平時安靜。要看每條連線命中哪條規則，臨時切到 info。
debug 只在排查具體問題時開，用完就關。它洗得太快，你根本來不及看；更實際的顧慮是它會把你造訪的每一個網域都寫下來，多數用戶端還會同時落到磁碟上的記錄檔裡。
一行記錄裡有什麼
info 等級下最有價值的是連線行：時間、等級、然後是這次請求的目標（網域或 IP 加連接埠）、命中的規則類型和內容、以及最後選了哪個出口。三樣湊齊，「為什麼這個站走錯了線路」這個問題就是可以直接讀出答案的，不用猜。
另一類是核心自己的狀態行：載入設定、啟動監聽、DNS 初始化、TUN 介面建立。這些集中在啟動那幾秒，之後就不太出現了。
問題一：這個網站走了哪條規則
- 把
log-level切到info，重新載入設定。 - 清空記錄檔視窗，然後關掉瀏覽器裡其它分頁——不然背景請求會把你要找的那行淹掉。
- 只造訪你要查的那個站，回頭看新出現的行，找目標網域。
- 讀它命中的規則。如果命中的不是你寫的那條，說明前面有一條更靠前的規則先比對上了；規則是從上往下第一條命中就停的。
問題二：用戶端起不來
只看最前面十幾行，別往下翻。設定解析出錯一定發生在載入階段，而且錯誤訊息通常帶欄位名，有時帶行號——比如某個 proxy-groups 引用了不存在的節點名，或者某個欄位型別不對。找到那行，去設定裡對應位置改。
如果最前面幾行顯示監聽失敗，那不是設定寫錯，是連接埠被占了。這種情況記錄檔會點出具體連接埠號，換一個連接埠或者找出占用的程序。
問題三：時通時斷
這類問題看的不是某一行，是重複出現的模式。找 timeout、EOF、connection reset、i/o timeout 這類字樣，然後回答一個問題：它們集中在同一個節點，還是所有節點都有？集中在一個節點，換節點就完事；所有節點都有，問題多半在本地網路或 DNS，不在代理鏈路上。
把記錄檔貼到論壇或群組之前，先刪掉兩樣東西：訂閱網域（往往帶 token），以及你自己造訪過的網域清單——那基本等於一份瀏覽紀錄。截圖比複製文字更容易漏掉邊角，最好用文字，刪乾淨了再發。