Clash 常見問題

用戶端負責匯入設定、系統代理與介面操作；核心則負責解析設定、比對規則並建立連線。Clash Meta 是從原版 Clash 發展而來的分支，mihomo 延續這條核心路線；用戶端名稱含有 Clash，不代表使用相同核心。遇到不支援的協定或欄位錯誤時，請先在用戶端的「關於」頁面確認核心名稱，再查閱對應版本的欄位說明；不要只憑介面名稱判斷相容性。

用戶端是網路工具，安裝程式本身不等於可用的代理服務。通常必須匯入有權使用的訂閱網址，或填入自行管理的伺服器參數。先確認設定頁面中有設定檔，且該檔案已啟用，再檢查策略組是否引用代理或代理集合。只有 DIRECT 的設定可用於直連分流，但不會自動產生代理節點；下載用戶端和取得伺服器連線參數是兩個不同步驟。

規則模式會依 rules 的順序逐條比對，由第一條符合的規則決定連線出口，適合日常分流；全域模式則將進入核心的連線交由全域策略選擇；直連模式會讓進入核心的連線直接連到目標。建議先使用規則模式，再查看連線記錄確認命中的規則。全域模式不會讓原本未進入核心的程式自動使用代理，也不能取代系統代理或 TUN 的流量接入設定。

兩者是不同的流量接入方式，正常使用不必一律同時開啟。系統代理主要供遵循作業系統代理設定的應用程式使用；TUN 則透過虛擬網路介面接入流量，通常涵蓋更多程式，也可能需要管理員權限。初次設定建議只開啟系統代理，確認節點與規則運作正常後，再依應用程式需求啟用 TUN。若同時使用，請依照用戶端說明設定；發生異常時先關閉其中一種，縮小排查範圍。

它們扮演的角色不同。核心專案維護網路處理程式碼，用戶端專案負責圖形介面與系統整合，訂閱服務商則提供伺服器連線參數並維護服務狀態。Clash設定教學提供用戶端下載入口與設定說明，不會發放訂閱，也無法恢復已到期的帳戶。搜尋 Clash 官方網站或 Clash 免費節點時，請先確認頁面所屬專案及用途，切勿將訂閱金鑰提交給來源不明的轉換頁面或回報表單。

Ubuntu 桌面環境使用者可先選擇支援 Linux 的圖形化用戶端，方便匯入訂閱、切換策略及查看記錄；沒有桌面環境的伺服器則較適合直接執行 mihomo，並以 systemd 管理程序。下載前可用 uname -m 確認處理器架構，再核對安裝檔類型。桌面用戶端與獨立核心不可同時占用相同的代理連接埠；改用服務執行時，也要重新確認服務帳戶、設定目錄及設定檔的讀取權限。

先確認複製的是完整訂閱網址，而非帳戶管理頁面的網址，並檢查網址前後是否多了空格或換行。接著查看更新記錄：401 或 403 通常要檢查存取授權，404 則確認網址是否已變更；逾時時請檢查目前網路，以及更新時使用的連線出口。若已取得內容但解析失敗，可能是伺服器回傳登入頁面或不相容的格式。向服務商回報時只提供狀態碼與錯誤摘要，不要公開完整訂閱網址。

先備份目前可用的檔案，再依記錄中的行號檢查附近內容；錯誤位置有時是由上一行縮排錯誤或引號未閉合造成。YAML 縮排請使用空格，不要使用 Tab；清單項目的連字號要與同層欄位對齊。general 是教學中的基礎設定分段名稱，不應直接寫成頂層鍵；mixed-port 等欄位則應放在根層級。修正語法後若仍顯示未知協定或欄位，請確認核心是否支援，而非一再調整縮排。

先查看記錄，判斷問題是建立虛擬網卡失敗、修改路由失敗，還是缺少裝置。Windows 可依用戶端說明安裝服務模式並授予權限；Linux 請確認 /dev/net/tun 是否存在，以及程序是否具備所需的網路管理權限；容器環境也需要由主機明確提供裝置與權限。不要用放寬所有目錄權限的方式處理網路權限問題。修正後重新啟動核心，並確認虛擬介面、路由及 DNS 接入是否確實生效。

若直接修改遠端訂閱產生的設定檔，下次更新時可能會被遠端內容覆蓋。建議優先使用用戶端提供的覆寫、合併或擴充設定功能，將自訂規則與訂閱來源分開保存。合併後請檢查最終生效的設定，確認規則位置與策略組名稱正確；需要優先比對的規則通常要放在兜底規則之前。不同用戶端的合併方式不盡相同，搬移設定時不能只複製覆寫檔而不檢查結果。

先確認要比對的是單一網域，還是整個網域後綴。DOMAIN 用於比對完整網域名稱；DOMAIN-SUFFIX 則會套用至該網域及其子網域，影響範圍較大。規則的目標必須是現有代理、策略組或 DIRECT 等有效出口，並放在可能先命中的廣泛規則及 MATCH 之前。儲存並重新載入後，先關閉舊連線再存取目標，並從連線記錄確認命中的規則；既有長連線通常不會因修改規則而自動改用新出口。

部分命令列程式只讀取自身參數或代理環境變數，不會讀取桌面代理設定。可先執行 curl --proxy http://127.0.0.1:7890 https://example.com 測試單次連線，並將連接埠替換為實際的 mixed-port。若測試成功，再依工具文件設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，並確認 NO_PROXY 是否排除了目標。終端機中的變數不會自動傳給已執行的背景服務；systemd 服務必須另外設定執行環境。

先確認 dns.enable 已啟用，再分別檢查應用程式請求、系統 DNS 與核心的上游解析。只啟用核心 DNS 不會自動接管所有系統查詢；瀏覽器內建的加密 DNS 也可能使用獨立路徑。請搭配記錄、系統解析器設定及 TUN 的 DNS 接入設定逐項確認，必要時暫時關閉瀏覽器自訂 DNS 作為對照。DNS 檢測頁面顯示某個解析器的位置，單憑這點還不足以判定發生 DNS 洩漏。

先在用戶端允許區域網路存取，再確認核心的監聽位址，以及防火牆是否允許使用中的連接埠。其他裝置應填入執行用戶端的電腦在區域網路中的位址，而非 127.0.0.1；後者永遠指向裝置本身。建議只對可信任的區域網路開放，並依用戶端功能設定存取驗證與來源限制。不要在路由器上將代理連接埠直接轉送至公網，也不要為了分享代理而開放 external-controller 管理介面。

測速通常只會對指定網址送出一次請求，無法代表所有網站、協定及出口都能正常使用。先查看存取目標時是否產生連線記錄，再確認實際命中的策略組是否使用與測速相同的節點。接著分別測試網域解析、目標網站及其他網站，判斷問題出在 DNS、特定網站還是節點連線。不要只根據單一延遲數字不斷切換節點；保留失敗時的錯誤類型與規則記錄，更有助於找出問題。

先確認核心已在執行，且系統代理指向的位址與連接埠和 mixed-port 相同，再存取目標並查看連線記錄。若沒有記錄，請檢查應用程式是否忽略系統代理、瀏覽器擴充功能是否覆寫設定，以及系統是否仍使用其他軟體留下的 PAC 位址。若有記錄但顯示 DIRECT，應檢查模式與規則，而非繼續修改系統代理。對於確實不支援系統代理的應用程式，確認基本設定可用後再嘗試 TUN。

先關閉代理測試基本網路，再確認訂閱仍在有效期限內，且節點清單已更新。重新啟動核心後，檢查系統時間、伺服器網域解析及記錄中的交握錯誤；若只有某種協定失敗，也要確認核心是否支援，以及目前網路能否連通 UDP。若所有節點同時失敗，優先檢查共用的依賴項，例如 DNS、錯誤的輸出介面或其他代理工具。可換一個網路進行對照，但不要只因測速逾時就認定所有伺服器都已離線。

先關閉重複執行的用戶端，並確認背景中是否仍有獨立核心或 systemd 服務在執行。Ubuntu 可使用 ss -ltnp 查看 TCP 監聽狀態，並搭配程序資訊確認占用者；不要直接終止不明的系統程序。若兩個服務都需要保留，可修改 mixed-port，並同步更新系統代理、瀏覽器設定及終端機環境變數。也要區分代理連接埠與 external-controller 管理連接埠；修改管理連接埠無法解決代理監聽衝突。

部分採用 UWP 沙箱的應用程式會受到回環存取限制，可能無法連線至 127.0.0.1 上的代理，但不是所有市集應用程式都有這個問題。先確認瀏覽器能否正常使用同一個代理，再檢查目標應用程式是否產生連線記錄。若確認是回環限制，可使用用戶端提供的豁免工具，或以管理員權限透過 CheckNetIsolation 為對應套件新增豁免；請記下修改的對象，以便日後撤銷。也可評估使用 TUN，但不必為所有應用程式一律解除限制。

不要直接忽略，也不要關閉憑證驗證來恢復連線。先檢查系統時間與時區，再確認警告中的網域、憑證簽發者及有效期限是否符合目標網站。接著關閉封包擷取工具或其他網路過濾軟體，並比較直連、其他節點與其他網路的結果。一般代理轉送不需要安裝來源不明的根憑證；若只有某個出口發生異常，請停止透過該出口提交帳戶或付款資訊，保留錯誤訊息後繼續排查。