Clash 常見問題

用戶端負責匯入設定、介面操作與系統整合；mihomo 核心負責監聽代理連接埠、解析 DNS 並套用分流規則；訂閱則是服務提供者提供設定或節點資訊的管道。安裝用戶端不代表已取得可用節點，匯入訂閱也不代表應用程式的流量已進入核心。首次使用時，應依序確認設定已啟用、策略群組已選取可用出口，再開啟系統代理或 TUN。排查時釐清這三個層面，可避免把帳戶到期誤認為安裝失敗，或把系統代理設定問題誤認為節點故障。

日常使用通常選 rule，核心會依照 rules 由上而下比對，並將連線交給對應策略。global 會將連線交給 GLOBAL 策略，但仍須確認該策略實際選取的出口；direct 則直接連線至目標。全域模式不會自動接管未進入核心的應用程式流量，也無法修復失效節點。若網站分流結果不如預期，先查看連線記錄中的比對規則與最終策略，再調整規則或策略群組。只切換模式卻不確認出口，容易混淆分流問題與節點是否可用。

公開節點的可用性、營運者及資料處理方式通常難以確認，不建議用於敏感帳戶或重要業務。HTTPS 可保護正常加密連線中的內容，但不能取代對用戶端、憑證及服務來源的判斷。訂閱連結通常包含帳戶識別資訊或存取憑證，應視為敏感資訊妥善保存，切勿張貼在公開論壇、截圖中或不熟悉的轉換網站上。如需協助排查，提供已移除憑證的錯誤訊息與欄位結構即可。若連結已外洩，請透過服務提供者的帳戶頁面重設訂閱連結，並同步更新用戶端設定。

通常可以遷移訂閱網址與標準 YAML 設定，但不應假設舊用戶端的所有設定都能直接匯入。選擇仍有維護且支援所需協定的用戶端後，先重新匯入訂閱，確認策略群組、規則與節點協定能否由目前的核心接受。舊用戶端的介面偏好、服務安裝方式、指令碼與覆寫邏輯可能需要另外重建。遷移時先結束舊用戶端，並關閉其系統代理與背景服務，再啟動新用戶端，避免兩套程式搶占連接埠或反覆修改代理設定。保留原設定備份，確認連線正常後再清理舊環境。

先確認複製的是完整訂閱網址，而不是帳戶頁面網址，並檢查網址中是否混入空格或換行。接著查看用戶端更新記錄：401 或 403 通常表示授權或存取受限，404 可能代表訂閱連結已變更；若請求成功但無法解析，則要確認回傳內容是否為登入頁、錯誤頁或不相容格式。帳戶到期、流量用盡或服務提供者更換連結，也可能導致訂閱無法使用。若更新必須透過代理，且用戶端支援，請指定可用出口。不要反覆覆寫本機設定；先保留最後一份可用副本，再向服務提供者確認連結狀態。

先依錯誤訊息中的行號檢查縮排、冒號後的空格與清單層級，使用空格縮排，切勿混用定位字元。行號可能指出錯誤被偵測的位置，真正的問題也可能在上一行。節點名稱或密碼含有特殊字元時，請依 YAML 語法加上引號。若語法檢查通過，卻顯示未知欄位或不支援的代理類型，應確認用戶端實際使用的核心及其版本支援範圍，而非繼續調整縮排。建議以原設定副本為基礎，逐段還原最近的修改；每次只改一處，確認載入成功後再繼續新增欄位。

mixed-port 會在同一個連接埠接受 HTTP 與 SOCKS 代理連線；port 用於 HTTP 代理；socks-port 則用於 SOCKS 代理。應用程式必須依照所使用的代理協定填入位址與連接埠，不能只因數字相同就認定設定正確。設定 mixed-port: 7890 時，本機應用程式通常會連線至 127.0.0.1:7890，但實際連接埠仍應以目前執行中的設定為準。若出現 address already in use，先找出占用中的程序，再決定關閉舊執行個體或更換連接埠。更換後也要同步更新系統代理、瀏覽器擴充功能與終端機環境變數。

TUN 需要建立虛擬網路介面並修改路由，通常需要相應的系統權限，但不一定要讓整個用戶端始終以管理員身分執行。部分用戶端會透過安裝服務處理需要較高權限的操作，實際方式取決於平台與實作。先確認服務是否已安裝並執行、虛擬介面是否建立成功，再查看記錄中的權限或路由錯誤。同時執行其他 VPN 時，可能發生介面或路由衝突，可暫時結束另一套網路接管程式進行比較。不要為了解決權限錯誤而長期關閉防火牆；應修復服務狀態、授權設定或特定衝突項目。

測速通常只會確認節點對指定測試網址的請求結果，無法證明所有目標網站、協定與連接埠都可用。先查看失敗的請求是否進入核心，以及最後套用的策略群組是否確實選取剛才測試的節點。接著分別檢查目標網域解析、節點是否能連上該網站，以及伺服器端是否有限制。若測速結果是較早前的記錄，請重新測試並實際開啟目標網站；若只有影片、遊戲或語音異常，還要確認是否支援 UDP 及相關分流設定。不要只依測速結果頻繁切換節點；維持相同目標與網路條件，才能有效比較。

需要長期保留的規則，不要只寫在更新時會被取代的遠端設定檔本文中。優先使用用戶端提供的覆寫、合併或擴充設定功能，將個人規則與遠端訂閱分開保存，並確認合併順序。規則通常應放在兜底 MATCH 之前，否則連線可能已先被比對；引用的策略群組名稱也必須存在於最終設定中。不同用戶端處理陣列追加、置前或取代的方式不盡相同，更新後應查看實際執行中的設定，而非只看編輯器中的片段。首次設定完成後，手動更新一次訂閱，確認修改仍然生效。

先確認兩台裝置能在區域網路中互相連線，再啟用 allow-lan，並檢查 bind-address 是否允許從區域網路介面連線。另一台裝置的代理位址應填入電腦的區域網路 IP，不能填 127.0.0.1；連接埠則填入目前的 HTTP 或混合監聽連接埠。同時確認電腦防火牆只對可信任的網路開放該連接埠，以及無線基地台是否啟用了用戶端隔離。只在可信任的網路中開放監聽，必要時設定代理驗證，切勿將代理連接埠轉送至公用網際網路。設定 HTTP 代理通常不會接管裝置上的所有流量。

許多命令列工具不會自動讀取桌面系統代理，必須使用工具本身的代理參數或環境變數。可以先執行 curl -x http://127.0.0.1:7890 https://example.com 進行單次測試，並將連接埠替換為目前的監聽值。若單次請求成功，再依終端機與工具的文件設定 http_proxy、https_proxy 或 ALL_PROXY，並確認 no_proxy 沒有排除目標。環境變數通常只會影響目前程序及其子程序，已開啟的終端機可能需要重新啟動。HTTPS 目標使用本機 HTTP 代理時，代理位址仍可使用 http:// 前綴。

所有節點都逾時時，先確認本機網路可以直接連上一般網站，再確認訂閱更新成功、帳戶有效，且用戶端已載入正確設定。接著檢查系統時間、節點網域解析、連接埠連通性，以及記錄中的協定錯誤；也可以在另一個網路中使用同一個節點測試，以區分本地網路限制與伺服器故障。若只有部分節點逾時，優先比較其伺服器位址、連接埠、協定參數與服務狀態。不要同時更改 DNS、TUN 與節點參數，否則難以判斷是哪項變更生效。記下錯誤時間，並保留已移除憑證的記錄，再向服務提供者確認對應出口。

先確認系統代理指向的位址與連接埠是否和核心的監聽設定一致，並確認核心仍在執行。接著檢查瀏覽器是否受到代理擴充功能、自訂代理設定或組織政策影響；暫時停用衝突的擴充功能後，用同一個網址重新測試。查看用戶端連線記錄最有幫助：沒有對應連線時，優先檢查流量入口；已出現連線但使用 DIRECT 時，檢查規則與策略選擇；連線已走代理卻失敗時，再檢查節點與 DNS。結束其他會修改系統代理的程式，避免設定反覆被覆蓋。啟用 TUN 前應先找出問題，不必把它當成所有故障的預設解法。

部分使用應用程式容器的 Windows 應用程式預設無法存取本機迴圈位址，因此瀏覽器正常，不代表這些應用程式也能使用 127.0.0.1 上的代理。先確認應用程式確實會讀取系統代理，再透過用戶端提供的迴圈豁免功能，授權需要使用代理的特定應用程式；也可以先了解系統工具的使用方式，再檢查現有豁免清單。操作可能需要管理員權限，而且不同應用程式的網路實作並不相同，不應一律對所有應用程式開放。設定後，完全結束並重新開啟目標應用程式，同時查看連線記錄。若問題仍未解決，再檢查應用程式本身的服務、帳戶狀態與分流規則。

不應直接關閉 DNS 來掩蓋問題。Fake-IP 會為網域指派合成位址，依賴真實 IP 的區域網路服務或應用程式可能需要設定例外。先確認內網網域應由哪台 DNS 伺服器解析，再搭配 fake-ip-filter 與 nameserver-policy，為相關網域設定過濾或指定解析路徑。單純切換至 redir-host 不一定能解決路由、快取或多點傳播探索問題。修改後清除相關 DNS 快取並重新啟動受影響的應用程式，再查看解析結果與連線記錄。若裝置探索使用多點傳播流量，還須另外檢查網路隔離與 TUN 路由，不能只調整網域解析。