先確認失敗發生在哪一層
Clash 用戶端中的「更新訂閱」並不是單一步驟。點選更新後，用戶端會先讀取設定中儲存的訂閱 URL，再透過網路請求取得遠端內容，接著檢查內容能否解析為 Clash 設定，最後才會以新設定取代本機副本。任何一層失敗，介面都可能只顯示「更新失敗」，但處理方式並不相同。
排查前先不要刪除目前的設定。大多數用戶端會保留上次成功下載的本機副本，即使遠端暫時無法使用，已載入的節點與規則通常仍可繼續使用。直接刪除設定會一併失去這份可用副本，反而增加復原步驟。
從錯誤訊息判斷方向
| 介面提示或記錄檔關鍵字 | 通常代表什麼 | 優先檢查 |
|---|---|---|
| timeout、deadline exceeded、i/o timeout | 請求未能在限定時間內完成 | 網路路徑、DNS、代理更新開關 |
| 404、Not Found | 伺服器找不到該訂閱位址 | 連結是否過期、複製是否完整 |
| 401、403、Forbidden | 身分參數失效或請求遭伺服器拒絕 | 重新取得訂閱、裝置或頻率限制 |
| connection refused | 目標連接埠拒絕連線，或更新請求錯誤地傳送至本機代理 | 7890、7891 等連接埠及代理設定 |
| unexpected EOF、connection reset | 傳輸過程中連線被關閉 | 網路穩定性、重複請求、伺服器狀態 |
| YAML、parse、unmarshal | 內容已下載，但格式無法解析 | 回傳內容是否確實是 Clash YAML |
確認是「下載失敗」還是「解析失敗」
下載失敗時，記錄檔通常會包含網域、連線、逾時或 HTTP 狀態碼。解析失敗則常見 YAML 行號、欄位名稱、類型不相符等資訊。例如請求成功回傳登入頁面時，HTTP 狀態可能仍是 200，但內容第一行是 HTML，用戶端就會在解析階段報錯。
如果用戶端支援檢視設定檔，可開啟剛下載的內容檢查開頭。標準 Clash 或 mihomo 設定通常包含 proxies、proxy-groups、rules 等欄位；如果只有網頁程式碼、錯誤提示或帳號登入頁，表示訂閱位址回傳的不是可載入設定。
mixed-port: 7890
mode: rule
proxies:
- name: Example
type: ss
proxy-groups:
- name: PROXY
type: select
rules:
- MATCH,PROXY上面只是用來辨識結構的簡化範例，不應用來取代真實訂閱。不同服務提供的設定還可能包含 DNS、規則集、健康檢查與大量節點欄位。
Clash 訂閱更新逾時的處理順序
逾時表示用戶端未能在規定時間內取得完整回應。原因可能是訂閱網域無法解析、直連路徑無法連通、代理節點失效，也可能是用戶端啟用了「使用代理更新」，但目前代理本身尚未建立可用連線。依固定順序檢查，通常比反覆切換節點更快。
第一步：分別測試直連更新與代理更新
不同用戶端的名稱略有差異，常見入口是「設定」→「參數設定」→「訂閱」，或設定頁面右上角的更新選單。可尋找「使用代理更新」、「透過代理更新訂閱」、「Proxy Subscription Update」等類似開關。
- 先關閉「使用代理更新」，儲存後手動更新一次。這會讓訂閱請求優先透過系統目前的直連網路。
- 如果仍然逾時，再開啟該開關，選擇已確認可用的節點後重新更新。
- 不要連續快速切換兩種方式，每次測試至少等待目前請求結束，並記錄哪一種方式能成功。
直連失敗而代理更新成功，通常表示訂閱網域在目前網路下存取不穩定。直連成功而代理更新失敗，則應檢查節點、代理群組選擇與本機連接埠。兩種方式都失敗時，繼續檢查 URL、DNS 與伺服器狀態。
第二步：檢查本機代理連接埠
不少 Clash 用戶端預設使用混合連接埠 7890，HTTP 連接埠常見為 7890，SOCKS5 連接埠常見為 7891，但這些數值可以修改。如果作業系統、瀏覽器或其他下載工具仍指向已關閉的連接埠，訂閱請求可能出現 connection refused。
- 在用戶端「設定」→「網路設定」或「連接埠」中查看目前的 Mixed Port、HTTP Port 與 SOCKS Port。
- 確認系統代理顯示的主機通常為
127.0.0.1，且連接埠與用戶端實際監聽的數值一致。 - 不要同時執行兩個佔用相同連接埠的 Clash 用戶端。發生連接埠衝突時，後啟動的用戶端可能無法監聽。
- 如果剛修改連接埠，先關閉再開啟系統代理，讓作業系統重新寫入正確位址。
第三步：排除 DNS 與網路切換問題
從公司網路切換至手機熱點、從 Wi-Fi 切換至有線網路後，舊連線與 DNS 快取可能暫時保留。先完全退出用戶端，斷開並重新連線網路，再啟動用戶端測試。只關閉視窗不一定等於退出，需確認系統匣或選單列中的程序已經結束。
如果記錄檔顯示 no such host、server misbehaving 或網域解析逾時，應先確認一般網頁能否開啟。啟用 TUN 模式時，可暫時關閉 TUN，只保留一般系統代理後測試訂閱更新；如果關閉 TUN 後恢復，應檢查 TUN 使用的 DNS 劫持、Fake-IP 範圍與 nameserver 設定，而不是直接重裝用戶端。
出現 404、401 或 403 時怎麼處理
HTTP 狀態碼表示請求已抵達伺服器，因此重點不再是本機連接埠，而是訂閱 URL 與伺服器授權。404 多半表示位址不存在，401 表示缺少有效身分資訊，403 則表示伺服器理解請求但拒絕提供內容。
404：訂閱連結過期或複製不完整
訂閱連結通常包含很長的路徑與查詢參數，例如權杖、用戶端類型或設定格式。聊天軟體換行、瀏覽器網址列截斷、複製時漏掉結尾字元，都會讓有效位址變成 404。檢查時不要只比對網域，應從 https:// 開始逐字核對完整 URL。
- 回到訂閱提供商的管理頁面，重新複製用於 Clash 或 mihomo 的訂閱位址。
- 在用戶端設定清單中開啟原設定的編輯選單，替換 URL 後儲存。
- 如果用戶端不支援編輯 URL，請建立遠端設定並匯入新連結。
- 新設定更新成功且能正常切換節點後，再刪除失效的舊項目。
如果重新複製後仍是 404，可在瀏覽器中直接開啟連結查看結果。下載 YAML 檔案或顯示設定文字，表示位址可用；如果直接進入登入頁、方案頁面或網站首頁，則可能複製了管理頁面位址，而不是訂閱介面位址。
401 與 403：授權參數或存取限制
401 常見於權杖失效、帳戶狀態變更或訂閱位址已重設。403 除了授權問題，也可能來自請求頻率、來源網路或裝置數量限制。這類問題通常無法透過修改 Clash 的代理連接埠解決。
- 在服務頁面重新產生訂閱連結，避免繼續使用歷史收藏中的舊位址。
- 停止在短時間內連續重新整理。建議至少間隔 5 分鐘後再進行一次測試。
- 檢查帳戶有效期限、流量狀態，以及服務方是否發布介面維護通知。
- 如果瀏覽器可以下載而用戶端回傳 403，嘗試先關閉代理更新，排除出口位址受到限制的情況。
- 如果直連回傳 403、代理更新正常，可保留代理更新，但應選擇穩定的代理群組，而不是延遲波動較大的自動節點。
回傳 200 仍失敗：檢查設定格式與內容
HTTP 200 只代表伺服器成功回傳一段內容，不代表這段內容一定是 Clash 設定。網頁錯誤頁面、Base64 節點清單、其他用戶端專用格式都可能以 200 回傳，接著在解析階段失敗。
辨識常見解析錯誤
| 現象 | 可能原因 | 處理方式 |
|---|---|---|
| 第一行附近出現 YAML 語法錯誤 | 回傳 HTML、JSON 錯誤資訊或內容遭截斷 | 查看原始回應，重新取得正確的訂閱位址 |
| 提示缺少 proxies 或 proxy-groups | 訂閱不是完整的 Clash 設定 | 選擇 Clash、Clash Meta 或 mihomo 格式 |
| 提示 unknown field | 設定使用了目前核心不支援的新欄位 | 更新用戶端或切換相容格式 |
| 提示 mapping values、bad indentation | YAML 縮排損毀或手動編輯有誤 | 還原遠端原始設定，避免使用定位字元縮排 |
| 下載內容只有一行編碼文字 | 可能是通用 Base64 節點訂閱 | 從服務頁面選擇 Clash 專用連結 |
mihomo 對規則集、代理提供者與 DNS 欄位的支援範圍比早期 Clash 核心更廣。如果訂閱明確標示為 mihomo 或 Clash Meta，而用戶端仍使用較舊核心，可能出現無法辨識欄位的情況。應優先在「設定」→「核心」或「關於」中確認核心類型與版本，再選擇相應的訂閱格式。
不要為了消除錯誤而隨意刪除不認識的欄位。某些欄位負責規則提供者、DNS 分流或節點健康檢查，刪除後即使設定能載入，也可能改變流量路徑。較穩妥的做法是升級支援該格式的用戶端，或讓訂閱服務產生相容設定。
自動更新間隔怎麼設定才合理
自動更新不是越頻繁越好。節點與規則通常不會每分鐘變更，間隔過短會產生重複請求，也更容易遇到伺服器頻率限制。對個人裝置而言，6 至 24 小時是較常見的範圍。
| 使用情境 | 建議間隔 | 說明 |
|---|---|---|
| 日常個人電腦 | 12 小時 | 兼顧節點變更與請求頻率 |
| 偶爾啟動的筆記型電腦 | 24 小時 | 啟動後手動更新一次通常已足夠 |
| 節點變動較頻繁 | 6 小時 | 不建議再縮短至幾分鐘 |
| 固定規則與自建節點 | 24 至 72 小時 | 設定變動少，可降低更新頻率 |
| 正在排查故障 | 暫時關閉自動更新 | 避免自動工作覆寫記錄檔與測試結果 |
在用戶端中設定更新間隔
常見操作路徑是進入「設定」或「訂閱」頁面，開啟對應遠端設定的編輯選單，將自動更新間隔設為小時數。部分用戶端使用秒為單位：6 小時是 21600 秒，12 小時是 43200 秒，24 小時是 86400 秒。如果輸入框明確標示分鐘，則分別填寫 360、720 或 1440，不要混用單位。
設定完成後，應觀察下一次預定更新時間是否符合預期。有些用戶端只會在程式執行時執行定時更新，電腦關機期間不會補跑所有工作；重新啟動後更新一次即可，不需要把間隔調得很短。
「使用代理更新」要一直開啟嗎
是否開啟取決於訂閱網域的實際可達性。直連長期穩定時，關閉代理更新更簡單，也能避免目前節點失效導致訂閱無法重新整理。只有訂閱位址必須經過代理，或直連經常逾時時，才適合保持開啟。
- 直連更新穩定：關閉「使用代理更新」，自動間隔設為 12 或 24 小時。
- 直連逾時、代理穩定：開啟代理更新，讓更新流量經過穩定的代理群組。
- 經常更換網路：優先使用直連；失敗時再手動切換至代理更新。
- 目前所有節點都無法使用：關閉代理更新，避免請求被送入失效代理。
修復後如何確認設定確實生效
介面顯示「更新成功」只代表新檔案已儲存，還要確認用戶端實際載入了它。有些用戶端下載完成後會自動切換，有些則會繼續使用舊設定，需要手動選取新項目。
- 在設定清單查看「最後更新」時間，確認它與剛才的操作時間一致。
- 選取更新後的設定，等待核心完成重新載入。
- 進入代理頁面，檢查節點數量、代理群組名稱或規則是否出現預期變化。
- 對常用節點執行一次延遲測試。延遲數值只能表示測試位址可達，不代表所有網站都能存取。
- 保持「規則模式」，存取一個應直連及一個應使用代理的目標，確認分流結果。
- 查看執行記錄，確認沒有持續出現解析錯誤、DNS 迴圈或連線遭拒。
仍然失敗時的最終檢查清單
- 訂閱 URL 是否從服務頁面重新複製，且開頭與結尾沒有空格、換行或遺漏字元。
- 在瀏覽器開啟位址時，回傳的是設定文字或下載檔案，而不是登入頁面。
- 直連更新和代理更新是否分別測試過，而不是只反覆嘗試同一種路徑。
- 系統代理連接埠是否與用戶端實際監聽的連接埠一致，7890 或 7891 是否被其他程式佔用。
- 關閉 TUN 後能否更新；如果可以，應繼續檢查 DNS 劫持與 TUN 堆疊設定。
- 訂閱格式是否與 Clash、Clash Meta 或 mihomo 核心相符。
- 自動更新間隔是否過短，是否因連續請求觸發 403 或暫時限制。
- 更新成功後是否手動選取了新設定，並確認核心完成重新載入。
排查訂閱故障最有效的方法，是先按狀態碼區分網路、授權與格式問題，再比較直連和代理兩條更新路徑。逾時優先檢查網路與代理開關，404 重新取得完整連結，401 或 403 檢查授權與請求頻率，解析錯誤則確認回傳內容與核心格式。將自動更新設定為 6 至 24 小時，並保留最近一次可用設定，通常能減少重複故障的影響。