Clash 常見問題
設定與連線疑難排解

用戶端負責管理訂閱、選擇策略群組及切換系統代理；mihomo 核心則負責監聽連接埠、解析 DNS 與套用分流規則。Linux 桌面使用者可先使用 Clash Verge Rev，伺服器使用者則可直接執行核心。兩者的設定儲存位置不一定相同，圖形介面用戶端也可能會產生執行時設定。疑難排解前，先確認實際啟動的執行檔與設定目錄，不要修改另一份未使用的 config.yaml。命令列部署通常使用 ~/.config/mihomo/，但仍須以啟動參數中的 -d 或 -f 為準。

日常使用建議先選規則模式，也就是 mode: rule，再檢查請求符合的規則與策略群組。全域模式會將一般連線交由 GLOBAL 策略群組處理，但該群組仍可能選到 DIRECT；此外，它不會自動接管未進入核心的程式流量。直連模式則讓進入核心的連線直接存取目標，適合用來比對測試。切換模式後應重新建立連線，既有的長連線可能仍沿用原本路徑。如果某個軟體沒有變化，先確認它是否使用系統代理或已由 TUN 接管，再檢查模式設定。

用戶端與核心提供連線及分流功能，但不代表已經有可用的遠端代理。訂閱通常包含節點、策略群組或規則，也可能只提供節點清單。匯入前，請確認服務商提供的格式可供 Clash 或 mihomo 識別；只有節點的 Provider 檔案不能直接取代完整設定。匯入成功後，還要啟用對應設定檔，在策略群組中選擇可用的出口，並確認服務期限與流量額度。訂閱連結通常包含存取憑證，請勿貼到公開日誌、截圖或線上轉換網站。

不需要同時啟用。系統代理適合遵循桌面代理設定的瀏覽器與應用程式；TUN 則透過虛擬網路裝置與路由接管更多連線。初次部署時，建議先關閉 TUN，透過明確指定代理驗證節點與連接埠，再單獨測試 TUN，以便區分設定問題和系統權限問題。若同時啟用兩者，還要檢查用戶端的路由排除與 DNS 設定，避免重複接管或連線迴圈。TUN 不代表所有流量都一定會經過代理；實際出口仍受規則、策略群組與略過設定影響。

先確認匯入的設定已設為目前使用的設定，而不只是儲存在設定清單中。接著查看訂閱更新日誌，確認收到的內容是否其實是登入頁、錯誤頁或空檔案。如果設定使用 proxy-providers，主設定載入成功不代表節點清單也已成功下載，還要查看對應 Provider 的狀態、路徑與遠端回應。命令列部署可執行 mihomo -t -d ~/.config/mihomo 檢查設定，再查看執行日誌中的下載錯誤。請勿將包含憑證的訂閱 URL 貼到公開求助區。

401 通常與缺少驗證資訊或憑證失效有關，請先向服務商重新取得連結；403 也可能與存取政策、請求標頭或額度限制有關，應參考回應內容判斷。若發生逾時，先確認網路能否連上訂閱網址；必要時檢查用來下載訂閱的代理是否依賴尚未載入的節點。遇到憑證錯誤，先用 timedatectl 檢查系統時間，再確認發行版的 CA 憑證是否正常。不要長期關閉憑證驗證來避開錯誤。如果連結已更新，請取代舊網址後手動重新整理，並查看實際的 HTTP 狀態碼與日誌。

先執行 ls -l /dev/net/tun，確認裝置是否存在；若不存在，可檢查 tun 模組，必要時執行 sudo modprobe tun。接著確認實際執行的核心具備建立虛擬網卡與修改路由的權限，優先使用圖形介面用戶端提供的服務安裝方式。直接部署時，部分環境可透過 sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo 授權，但路徑必須與實際執行檔一致；更新檔案後可能需要重新授權。容器也必須允許存取裝置並提供網路能力，systemd 的能力限制也可能導致授權無法生效。

先執行 systemctl --user cat mihomo 檢查 ExecStart，確認執行檔與設定目錄都存在。服務設定中應優先使用明確路徑；設定目錄可寫成 %h/.config/mihomo，不要依賴 shell 展開 ~ 或讀取互動式終端機的環境變數。接著用 mihomo -t -d ~/.config/mihomo 測試相同目錄，再執行 journalctl --user -u mihomo -b -n 80 --no-pager 查看結束原因。修改服務檔案後執行 systemctl --user daemon-reload，再重新啟動服務；請勿混用使用者層級與系統層級的服務指令。

桌面系統代理不是通用的流量接管介面。有些命令列程式只讀取環境變數，有些應用程式則使用自己的代理設定。先用 curl -I -x http://127.0.0.1:7890 https://example.com 測試明確指定代理的連線，再依程式文件設定 http_proxy、https_proxy 或 ALL_PROXY。請注意，環境變數對大小寫的支援可能不同，NO_PROXY 也可能讓目標略過代理。若要接管不支援代理設定的程式，可在確認明確代理運作正常後考慮使用 TUN；不要只憑桌面開關判斷終端機已透過代理連線。

先確認一般桌面瀏覽器能否透過相同連接埠連線，再判斷是否為應用程式容器的迴圈存取限制。部分 UWP 應用程式若要存取 127.0.0.1 上的代理，需要設定迴圈豁免；建議優先使用用戶端提供的 UWP 迴圈設定，並只選取需要的應用程式。可在系統管理員終端機中執行 CheckNetIsolation LoopbackExempt -s，查看現有的豁免清單；手動修改前，請先確認正確的套件系列名稱。只為必要的應用程式開放，不要批次修改不明應用程式。若已啟用 TUN，也要確認該應用程式的流量確實進入核心，避免把所有連線問題都歸因於迴圈限制。

監聽位址、allow-lan 與防火牆三項都必須設定正確。啟用 allow-lan: true 後，確認 bind-address 允許區域網路位址，並用 ss -lntp 檢查實際監聽位置；其他裝置應填入這台電腦的區域網路 IP 與 mixed-port，而不是 127.0.0.1。防火牆只對可信任的網段開放代理連接埠，並視需要設定代理驗證。external-controller 管理介面應維持僅限本機存取，除非已明確設定存取控制。共用 HTTP 代理與將電腦設為透明閘道器是不同的部署方式，不要把設定代理連接埠當成已完成閘道器設定。

HTTP 類型的 proxy-providers 可透過 interval 設定更新間隔，單位為秒；例如 interval: 3600 代表每小時檢查一次。每個 Provider 都應使用獨立的快取路徑，並確認執行服務的使用者有權寫入該目錄。health-check.interval 控制的是節點健康檢查，不是訂閱更新週期；縮短間隔不會更快取得新節點，反而會增加請求量與耗電。圖形介面用戶端的設定更新排程也可能獨立於核心的 Provider 更新，因此請先確認要更新的是整份設定還是節點清單。修改前先備份設定，再查看日誌中的實際下載結果。

先確認訂閱有效，且策略群組確實選取了遠端節點，再檢查節點伺服器位址能否解析，以及系統時間是否正確。若只有單一節點失敗、其他節點可用，優先檢查該節點或測試目標；如果全部失敗，則檢查本機網路、防火牆、訂閱狀態與核心日誌。延遲測試只反映連線到指定測試位址的結果，不代表所有網站都無法存取。可透過明確指定代理，連線到實際需要使用的 HTTPS 網站作為比對，並記錄連線過程中的錯誤。不要同時更換 DNS、連接埠與模式；每次只修改一項，才能確認是哪個環節恢復正常。

先確認 mixed-port 是否正在監聽，再比較明確指定 HTTP 代理與瀏覽器的連線結果。可執行 curl -I -x http://127.0.0.1:7890 https://example.com；若請求成功但瀏覽器失敗，請優先檢查瀏覽器代理、擴充功能與安全 DNS。若日誌顯示網域名稱解析錯誤，再確認 dns.enable、上游 DNS 是否可連線，以及 TUN 是否接管 DNS。fake-ip 模式下回傳映射位址通常是預期行為，不能只憑位址判斷是否故障。若應用程式快取了舊的解析結果，可重新啟動應用程式並建立新連線；必要時檢查系統與瀏覽器各自的快取。

執行 ss -lntp 查看 TCP 監聽連接埠，尤其檢查 mixed-port 和 external-controller 使用的連接埠；若要查看其他使用者的程序，可使用 sudo。常見原因包括圖形介面用戶端與手動啟動的核心同時執行，或使用者層級與系統層級服務重複啟動。先確認程序屬於哪個服務，再停止不需要的執行個體，不要直接終止所有同名程序。也可以更改衝突的連接埠，但必須同步調整系統代理、環境變數與控制面板的連線位址。如果錯誤涉及 UDP 監聽，請再執行 ss -lnup 檢查，避免只檢查 TCP 就誤以為連接埠未被占用。

先執行 systemctl --user is-enabled mihomo 和 systemctl --user status mihomo，確認是服務未啟用還是啟動失敗。若要在開機後隨使用者管理器啟動，可執行 systemctl --user enable --now mihomo。使用者服務在登出後是否繼續執行，也取決於 linger 設定，可用 loginctl show-user "$USER" -p Linger 查看；若確實需要在登出後持續執行，再評估啟用 loginctl enable-linger 的影響。若 TUN 依賴額外權限，請另外確認更新後權限是否失效。最後確認桌面代理或終端機變數仍指向正在監聽的連接埠，不要只檢查服務狀態。