訂閱更新失敗的排查順序

「更新失敗」是個很籠統的說法，底下至少藏了六七種完全不同的毛病：連結抓不到、抓到了是空的、抓到了跟上次一模一樣、明明寫著成功節點卻全不見了。排查的順序比排查的手段重要——先做那件能一刀砍掉一半可能性的事。

第一刀：把連結貼進瀏覽器

1. 在用戶端裡找到這份設定檔，進編輯或詳細資訊，把訂閱連結原樣複製出來。
2. 換一個瀏覽器視窗，貼進網址列，按 Enter。
3. 瀏覽器開始下載一個檔案，或者直接在頁面上攤出一大段 YAML——連結和網路都沒問題，毛病在用戶端這一側。
4. 瀏覽器轉半天逾時、跳 DNS 解析失敗、或者回一個錯誤頁——問題在網路或連結本身，在用戶端裡再怎麼點都沒用。

瀏覽器也打不開：先解開這個死結

最常見的狀況是訂閱網域本身要有代理才連得上，而你此刻剛好沒網。用戶端通常有「更新時走代理」「使用系統代理更新」這類開關——Verge Rev 在設定檔的編輯面板裡，別的用戶端叫法各異——把它打開，讓用戶端用現在還連得上的節點去抓新訂閱。前提是你手上真的還有一個能用的節點。

節點全掛了的話這條路就斷了。剩下的只有手動急救：服務商如果有備用網域，換那個再試；或者去後台拿一條單節點分享連結手動匯入，先把網連上，再回頭更新訂閱。

瀏覽器下得動，用戶端不行

• User-Agent。部分服務商靠 UA 決定給什麼，用戶端的預設 UA 不在名單上就回空內容或直接 403。有些用戶端可以自訂 UA，在設定檔的進階選項那一欄。瀏覽器下得動、用戶端拿到空的，八成就是這個。
• 憑證錯誤或 TLS 交握失敗。第一個要懷疑的是本機系統時間，差個幾分鐘交握就驗不過。第二個是會做 TLS 攔截的資安軟體或企業根憑證。
• 用戶端自己走了代理，而目前那個節點連不上服務商的網域。把「更新時走代理」關掉再試一次，開跟關兩種都試。
• 寫入失敗。設定檔資料夾唯讀或被資安軟體鎖住，內容抓回來了寫不進去。日誌裡會寫明是寫檔出的錯，不是網路。

顯示更新成功，結果卻不對

• 節點全不見了，只剩一兩個名字很奇怪的。多半是帳號到期或流量用完，服務商回的是一份只帶提示文字的空設定，在用戶端看來這次更新完全成功。看卡片上的到期日期和流量數字。
• 內容跟上次一模一樣，可是服務商明明說加了新節點。CDN 快取。等十幾分鐘再抓，或者在連結尾巴掛一個沒意義的參數把快取繞開。
• 直接 404。服務商換網域了，舊連結不再有效。去後台重新複製一條，別在舊的上面耗。

curl -A "clash-verge/2.0" -I "https://sub.example.com/link?token=YOURTOKEN"
curl -A "clash-verge/2.0" -sS "https://sub.example.com/link?token=YOURTOKEN&t=1738400000"

第一條只取回應標頭，看狀態碼是 200 還是 403、404、302。不少服務商還會在回應標頭裡帶一行 subscription-userinfo，裡面是已用流量和到期時間的原始數字，比介面上顯示的更可信。第二條把內容抓下來看，順便示範了繞快取：結尾那個 t= 參數服務商不認，CDN 認，換個數字就是一次全新請求。把 -A 後面換成不同的 UA 字串，就能驗證服務商是不是在按 UA 區別對待。

自動更新間隔設多久才合理

手動更新是你點一下馬上去抓；自動更新是用戶端按間隔在背景抓，失敗通常只在日誌裡留一行，介面未必提醒你。間隔設成幾分鐘沒有意義——節點清單不會變那麼勤，而且不少服務商會限制頻率，請求太密反而換來一串錯誤。設成一週又太長，人家換了節點你還在用舊的。多數人一天一次到兩天一次就夠，臨時想拿新節點，手點一下比調間隔快。