Clash 常見問題
與故障排除

核心負責代理連線、DNS 解析與規則比對，圖形化用戶端負責匯入設定、選擇策略群組及管理系統代理。Mihomo 是 Clash 生態系中持續發展的相容核心，但不同用戶端搭載的核心及支援欄位不盡相同。排查時，先在「設定」→「關於」或核心資訊中記下用戶端名稱與核心版本，不要只說安裝了 Clash。某份設定能由另一款用戶端讀取，不代表目前的核心也支援其中所有欄位；出現 unsupported 或 unknown field 時，應依目前核心的支援範圍調整，而非反覆重裝圖形介面程式。

用戶端和訂閱服務是兩回事，安裝程式不會自動提供代理線路。你需要匯入自己的設定檔，或使用服務提供者提供的 Clash 相容訂閱。通常可在「設定」或 Profiles 頁面選擇「新增」→「從 URL 匯入」；下載完成後，還要選取該設定，再到代理頁面選擇策略群組。不要把服務商的登入頁面網址當成訂閱網址，也別把只有單一分享連結的內容當作完整 YAML。訂閱 URL 中的 token 等同存取憑證，截圖、提問及公開日誌都應遮蔽；若已外洩，請到服務商後台重設訂閱連結。

日常通常選規則模式，讓流量依序比對 rules，再交由對應的策略群組處理。全域模式會把進入核心的請求交給全域策略選擇，但不會自動接管所有應用程式；未使用系統代理、TUN 或明確設定代理的程式，仍可能繞過核心。直連模式則讓進入核心的連線直接連到目標。全域模式不代表速度更快，只會改變路由選擇，無法改善線路本身。暫時排查時，可用同一個節點比較規則與全域模式：若只有規則模式失敗，先檢查命中的規則和策略群組；測試後切回規則模式，並確認全域群組與業務群組沒有選到不同節點。

延遲測試量測的是特定目標的小型請求耗時，不是持續下載頻寬。測速目標、測試逾時時間，以及是否經過代理，都會影響結果；延遲低也不能證明線路在尖峰時段有足夠容量。先確認實際連線使用的就是受測節點，而不是自動策略群組選出的其他線路，再於相同時段下載同一個檔案進行比較。下載速度也會受到目標網站限速、本地 Wi-Fi、跨網壅塞及服務商流量限制影響。不要短時間內對所有節點密集測速，以免增加負載或觸發限制。出現 timeout 只代表這次測試失敗，應搭配實際連線狀況與日誌判斷，不能只憑一個數字就認定節點已完全失效。

先分辨是下載失敗還是設定解析失敗。日誌出現 401 或 403 時，優先確認訂閱連結是否已重設、方案是否到期，以及服務商是否限制請求；403 也可能是存取防護所致，不一定是密碼錯誤。若是連線逾時，請確認系統時間正確、目前網路能連上訂閱網域，並檢查更新訂閱時是否設定經由已失效的代理連線。若用戶端可切換更新路徑，可暫時改用直連再試。下載成功但匯入失敗時，檢查回傳內容是否為登入頁面或錯誤說明，而非 YAML。請重新從服務商後台複製 Clash 相容連結，不要任意刪除查詢參數，更不要把完整連結貼到公開討論區。

先查看錯誤訊息中的行號與欄位路徑，再檢查該行及上一行。YAML 縮排須使用空格，不要混用 Tab；清單項目前要加連字號，鍵名後使用半形冒號，值含特殊符號時可用引號括起來。常見問題包括複製程式碼時帶入全形標點、把 dns 底下的欄位放到頂層，或在同一層重複寫了兩個 rules。修改前先備份原始檔，一次只修一處，再使用用戶端提供的設定檢查功能。語法檢查通過後，若顯示策略群組或代理不存在，請核對名稱引用；這已不是縮排問題。遠端訂閱檔可能在更新時被覆蓋，若要長期修改，應使用用戶端的覆寫或合併功能。

先確認目前的用戶端與核心支援 TUN，再查看啟動日誌中的具體失敗原因。Windows 通常需要安裝或啟用用戶端的服務模式；必要時依用戶端說明，以系統管理員權限完成初次設定。macOS 可能需要核准背景服務或網路延伸功能，實際步驟視用戶端實作而定。Linux 則要確認 /dev/net/tun 是否存在，以及服務是否有建立介面和修改路由的權限。不要把長期以高權限執行整個桌面程式當成唯一解法。也應暫時停用其他 VPN 的虛擬網卡接管，避免路由衝突。每次只啟用一種流量接管方式，確認日誌顯示介面建立成功後，再檢查 DNS 與應用程式連線。

先確認啟動時已允許系統的 VPN 連線要求，並能看到用戶端的執行通知。Android 同一使用者環境通常只能有一個作用中的 VPN；另一個 VPN，或使用 VPN 介面的過濾工具，可能會取代目前連線。若只有鎖定螢幕後才斷線，請前往「系統設定」→「應用程式」→對應用戶端→「電池」，允許背景執行或設為不受限制，再檢查廠商提供的自動啟動、背景活動及工作鎖定選項；選單名稱依系統而異。不要以為只要把應用程式留在最近使用的清單中，就已加入白名單。若通知仍在但流量中斷，請查看日誌是否發生網路切換或節點重新連線失敗，並分別測試 Wi-Fi 與行動網路。

系統代理開關只是將代理位址寫入作業系統，不代表核心已成功監聽。先在日誌確認 mixed-port 實際監聽的位址與連接埠，再對照系統網路設定中的 HTTP、HTTPS 代理。瀏覽器擴充功能、自訂代理設定及部分應用程式的網路選項可能會覆寫系統設定，測試時先停用這些覆寫項目。開啟目標網站後查看用戶端的連線頁面：若完全沒有紀錄，表示請求尚未進入核心；若已有紀錄但顯示 DIRECT，應檢查規則與策略群組，而不是繼續切換系統代理。有些應用程式不會讀取系統代理，需要明確設定代理或使用 TUN。也要留意代理略過清單，若目標網域列在排除項目中，就不會如預期經由代理連線。

先查出占用連接埠的程式，再決定是否更換連接埠。Windows 可執行 netstat -ano | findstr :7890，再依 PID 找出對應程序；macOS 或 Linux 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN。若是另一個用戶端實例，請先正常關閉舊實例，不要結束不熟悉的系統程序。確實需要更換連接埠時，可使用下方設定，將混合連接埠改為 7891，並維持僅供本機使用。儲存後重新載入設定，確認核心已成功監聽，再關閉並重新開啟系統代理，讓位址同步；瀏覽器、終端機及其他明確設定代理的工具也要一併修改。若用戶端有獨立的連接埠設定頁面，請以最終生效的設定與日誌為準。

mixed-port: 7891
allow-lan: false

手機要連線到電腦的代理連接埠，通常需要在電腦上啟用 allow-lan，並讓監聽位址接受區域網路連線；若只監聽 127.0.0.1，其他裝置便無法連線。兩台裝置須位於彼此可連通且可信任的區域網路中；在手機 Wi-Fi 的手動 HTTP 代理設定中，填入電腦的區域網路 IP 與實際使用的 mixed-port，不能填 127.0.0.1。電腦防火牆只開放必要的網路範圍，並依核心支援情況設定代理驗證。不要透過路由器將代理連接埠轉送到公網。部分無線網路會啟用用戶端隔離，即使連上同一個基地台，裝置也可能無法互相連線。另外，手機的 HTTP 代理不會接管所有應用程式與協定，測試時先用瀏覽器確認基本連線。

先確認應用程式是否真的依賴本機代理。部分 UWP 或 AppContainer 應用程式會受到網路隔離限制，無法直接存取本機回送位址，因此瀏覽器正常並不能排除這類問題。若用戶端提供 UWP 回送或 Loopback 工具，可視需要為目標應用程式新增回送豁免。也可以先執行 CheckNetIsolation LoopbackExempt -s 查看現有豁免，再依正確的應用程式套件系列名稱，按照 Windows 工具說明新增；通常需要系統管理員權限。不要一次解除所有應用程式的隔離，也不要把回送豁免當成解決所有網路問題的方法。若啟用 TUN 後恢復正常，表示值得檢查原本的系統代理路徑；若仍無法連線，請繼續檢查應用程式帳戶、DNS 與命中的規則。

先確認關閉代理後，本地網路仍可正常上網，再檢查訂閱是否有效、流量是否用完，以及系統日期與時間是否正確。測試節點時同步查看日誌，分辨伺服器連線逾時、TLS 交握錯誤與網域名稱解析失敗；這三種狀況的處理方式不同。如果只是所有節點的測速都失敗，請換用確定可連線的測試 URL，並實際開啟目標網站，避免把測試網址故障誤判成所有線路失效。也要確認沒有同時執行兩個代理用戶端或 VPN。若同一節點在另一種網路下正常，應優先排查目前網路限制與本機路由；若多台裝置在多種網路下都失敗，再向服務提供者確認伺服器狀態。

有可能，但先從日誌確認是否出現解析失敗、逾時或異常位址。系統的 nslookup 通常查詢系統解析器，不一定和應用程式經由核心時的解析路徑相同，因此查詢成功也不能證明核心 DNS 正常。檢查目前生效設定中的 dns.enable、enhanced-mode 與 nameserver，並確認上游解析器在目前網路下可連線。使用 fake-ip 時，也要確認 TUN、DNS 劫持及應用程式快取的設定彼此配合；切換模式後，可重新啟動受影響的應用程式並清除其 DNS 快取。不要直接複製整段來路不明的 DNS 設定，也別以為加入 fallback 就一定能解決 DNS 污染。先還原訂閱的原始設定，再一次調整一個欄位，觀察同一個網域的結果。

最常見的原因是系統仍指向已停止監聽的本機代理。Windows 請到「設定」→「網路和網際網路」→「代理」檢查手動代理；macOS 請到「系統設定」→「網路」→目前連線→「詳細資訊」→「代理」，檢查 HTTP、HTTPS 與 SOCKS。只停用確認是用戶端留下的項目；公司網路原有的代理請先記錄，不要直接清除。若終端機曾設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也要檢查目前工作階段及啟動設定。若先前使用 TUN，可重新啟動用戶端後先關閉 TUN，再正常退出，讓程式清理路由與 DNS。若問題仍未解決，先記錄目前網路設定再重新連線，避免一開始就重設所有網路設定。

先保留設定與日誌，再考慮重裝。從用戶端資料目錄或系統當機報告中查看退出前的最後幾行，優先分辨設定解析失敗、核心檔案無法啟動、權限遭拒及圖形執行環境缺失。若剛修改過設定，可先備份，再還原上一個可用版本；若還原後仍閃退，請確認安裝套件架構與系統相符，並檢查安全軟體是否隔離核心檔案。不要長期以全面關閉安全防護來迴避問題。重裝前確認訂閱、覆寫設定及策略選擇都已備份，因為重新安裝程式不一定會清除損壞的使用者資料。回報問題時請提供用戶端與核心版本、系統資訊、重現步驟及已遮蔽敏感資訊的日誌，不要附上訂閱憑證。