一、Clash Meta、mihomo 和用戶端之間有什麼關係？

Clash Meta 是以 Clash 為基礎發展的核心專案，後來改用 mihomo 這個名稱。核心負責讀取設定、處理代理協定、依規則分流及解析 DNS；桌面視窗、訂閱管理、系統匣選單與系統代理開關，通常由圖形介面用戶端提供。下載用戶端不代表已經取得可連線的代理節點。

排查問題時，請分別記錄用戶端版本、核心版本與作業系統版本。只說「Clash 最新版」無法判斷設定是否相容。同一個用戶端也可能在不同版本中整合不同版本的 mihomo。

  • 圖形介面位置：先在「設定」→「關於」查看用戶端版本，再確認核心資訊或啟動記錄。不同用戶端的選單名稱可能有所不同。
  • 命令列位置：在 mihomo 執行檔所在目錄執行 mihomo -v；Windows PowerShell 可使用 .\mihomo.exe -v。
  • 相容性判斷：若出現「未知欄位」或「不支援的代理類型」，請先確認實際執行的核心版本，不要反覆重新匯入訂閱。

二、訂閱從哪裡取得？為什麼安裝後沒有節點？

訂閱是由服務提供者或設定維護者提供的設定入口，常見形式是含有存取權杖的 HTTPS URL。用戶端會透過這個網址取得節點或完整設定。用戶端負責載入及使用設定，不會自動提供伺服器、帳號或流量。

操作位置：前往所使用服務的帳戶頁面，尋找「訂閱」或「Clash / Clash Meta」格式的入口，再回到用戶端的「訂閱」或「設定」頁面。建議使用明確支援 mihomo 的設定格式，避免直接把只包含其他協定連結的文字當成完整 YAML。

訂閱失效和節點連線失敗是不同問題。前者發生在下載設定時，後者則發生在設定載入後的代理連線階段。請先確認用戶端是否成功取得設定，再檢查節點狀態。

三、如何匯入訂閱？更新後為什麼沒有變化？

以 Clash Verge Rev 這類桌面用戶端為例，常見流程是「訂閱」→「新增」→選擇遠端訂閱類型→輸入 URL→儲存。有些版本會直接在訂閱頁提供網址輸入欄位。重點不在按鈕名稱，而是完成下載、選取、套用這三個步驟。

  1. 複製完整訂閱網址，確認前後沒有多出空格或換行。
  2. 新增遠端訂閱並下載，確認沒有 HTTP 錯誤或 YAML 解析錯誤。
  3. 選取剛匯入的設定，切換到「代理」頁面，確認是否出現代理群組。
  4. 手動更新一次，查看更新時間與記錄，並確認目前啟用的不是另一份舊設定。

如果下載回應 401 或 403，請檢查權杖、帳戶狀態及服務提供者的限制；如果取得的是網頁而非設定，可能複製到登入頁面的網址。解析錯誤訊息中的行號對應下載結果，不一定是本機覆寫檔案的行號。

更新注意事項：直接修改訂閱快取中的節點或規則，可能會在下次更新時被覆蓋。若要長期調整，請使用用戶端提供的覆寫、合併設定或腳本功能，並檢查最後產生的執行設定。

四、規則、全域、直連模式該選哪一種？

日常使用建議先選規則模式。設定中的 rules 會依序比對，符合後便將連線交由對應的策略處理。全域模式會把進入核心的連線交給全域策略；直連模式則讓進入核心的連線直接連往目標。以上都以「流量已進入核心」為前提。

模式適用情境檢查位置
規則 rule依網域、IP 等條件分流「代理」頁面的規則目標群組與連線詳細資訊
全域 global暫時確認是否為分流規則造成問題目前選取的全域策略節點
直連 direct確認目標是否可直接連線連線詳細資訊與目標網路的可連線狀態

操作位置：開啟用戶端的「代理」頁面，或使用系統匣選單中的模式選擇。切換到全域模式後，仍須為全域策略選擇可用節點；若選取的是 DIRECT，連線仍會直接連線。全域模式也不代表所有應用程式都會自動經過代理。

五、7890 連接埠是什麼？和節點連接埠有何不同？

7890 是設定範例中常見的本機代理監聽連接埠，不是固定值，也不是遠端伺服器的連接埠。設定為 mixed-port: 7890 時，同一個本機連接埠可接受 HTTP 代理和 SOCKS 代理連線。實際連接埠請以用戶端的執行設定為準。

本機監聽設定片段
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

操作位置：查看用戶端設定中的「連接埠」或「混合連接埠」，也可以在目前的執行設定中搜尋 mixed-port。不要把外部控制器連接埠當成代理連接埠；external-controller 提供管理介面，不能直接填入瀏覽器的 HTTP 代理位址。

在 Windows 中可執行下列命令，查看本機是否有程序正在監聽 7890。出現結果只能證明有程序在監聽，不代表一定是目前使用的用戶端，還需要確認 PID。

Windows PowerShell
netstat -ano | findstr ":7890"

如果啟動記錄出現 address already in use，請先關閉其他代理程序，或變更本機監聽連接埠，再同步調整依賴該連接埠的應用程式設定。

六、已開啟系統代理，為什麼終端機或遊戲仍未經過代理？

系統代理是作業系統提供給應用程式的一組代理設定，並不會強制接管流量。應用程式是否讀取這些設定，取決於程式本身。瀏覽器通常能使用系統代理；命令列工具可能會讀取環境變數，也可能只接受自己的代理參數；部分遊戲主要使用 UDP，無法只靠一般 HTTP 系統代理處理。

操作位置：先開啟用戶端的「系統代理」，再到 Windows 11 的「設定」→「網路和網際網路」→「代理伺服器」查看本機代理位址，接著前往用戶端的「連線」頁面，觀察目標應用程式發出的連線。在 macOS 中，可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」檢查。

測試終端機時，先用單次明確指定代理的方式測試，避免立刻修改全域環境變數。以下命令假設混合連接埠確實是 7890；在 Windows 使用 curl.exe，可避免部分 PowerShell 環境中的命令別名差異。

明確指定 HTTP 代理
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

在 macOS 或 Linux 中，將命令裡的 curl.exe 改成 curl。如果明確指定代理後連線成功，但一般連線失敗，請優先檢查應用程式是否讀取代理設定，而非重新安裝核心。

七、什麼時候需要開啟 TUN 模式？

TUN 透過虛擬網路介面與路由設定接收流量，適合不讀取系統代理的程式，以及需要處理更多網路流量的情境。它不是節點加速開關，也無法自動修復訂閱失效、伺服器故障或分流錯誤。

操作位置：在用戶端「設定」中的「TUN 模式」或「虛擬網卡」選項啟用。Windows 用戶端可能需要先安裝服務模式或取得系統管理員權限；Android 通常透過系統 VPN 授權接入，不能直接照搬桌面版的選單操作。

  1. 先不要開啟 TUN，使用明確指定的代理確認節點可正常使用。
  2. 記錄目前的系統代理、DNS 與其他 VPN 狀態，再啟用 TUN。
  3. 測試目標應用程式，並在「連線」頁面確認是否出現對應記錄。
  4. 如果本機網路或公司 VPN 異常，先關閉 TUN 進行比較，再檢查路由衝突與略過範圍。

八、DNS 和 fake-ip 是什麼？需要手動修改嗎？

DNS 負責將網域名稱解析為位址。mihomo 的 DNS 模組也會參與網域與連線的關聯。在 fake-ip 模式下，核心會向應用程式回傳虛擬位址，並保留該位址與網域的對應關係；這些位址並非目標伺服器的實際公網位址。

常見設定會使用 198.18.0.1/16 作為 fake-ip 範圍。看到這個範圍的位址，不要立刻判定節點遭到污染或伺服器位址有誤。請先確認是否啟用了 enhanced-mode: fake-ip。

操作位置：查看目前執行設定中的 dns 區段，以及用戶端的 DNS 覆寫設定。瀏覽器自行啟用的加密 DNS、系統 DNS 與核心 DNS 不一定走同一條路徑，因此只查看一次系統解析結果，無法證明應用程式實際使用了哪個解析器。

  • 只有少數網域異常時，先查看連線記錄中的網域、命中規則與解析錯誤。
  • 需要真實位址的區域網路服務，可依實際網域評估是否設定 fake-ip-filter，避免一次排除過大的範圍。
  • 修改 DNS 後，請重新建立應用程式連線；既有連線或應用程式快取可能仍保留先前的結果。

九、自訂規則要放在哪裡？為什麼沒有命中？

規則通常依照由上而下的順序比對，MATCH 通常作為最後的兜底規則。以下是規則片段，並非可獨立啟動的完整設定。它會讓範例網域直連，其餘連線則交由名為「代理選擇」的策略處理；該策略必須已在 proxy-groups 中定義。

規則設定片段
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,代理選擇

操作位置：在用戶端的設定覆寫入口新增規則，再查看合併後的執行設定，確認新規則排在兜底規則之前。編輯後重新載入設定，並在「連線」頁面檢查規則類型、策略鏈與實際出口。

如果一直沒有命中，請依序檢查三件事：目前是否使用規則模式；應用程式實際連線的網域是否符合預期；流量是否進入這個用戶端。使用 IP 連線、應用程式自行解析網域，以及既有的長連線，都可能影響觀察結果。

使用 rule-providers 時，也要確認規則集已成功下載，且 rules 中有對應的 RULE-SET 引用。僅宣告規則集來源，不代表它已參與比對。

十、節點延遲正常卻無法開啟網頁，該如何依序排查？

延遲測試通常只會連線到設定或用戶端指定的測試位址。測試結果只能反映特定請求，不能證明所有網站、UDP 或登入流程都正常。排查時可依「設定→入口→規則→節點→目標」的順序進行。

  1. 確認載入成功：查看「記錄」，排除 YAML 解析失敗、缺少策略群組與連接埠遭占用等問題。命令列使用者可執行 mihomo -t -f config.yaml 檢查設定；檢查通過仍不代表遠端節點可連線。
  2. 確認流量有進入：使用明確指定的代理發出請求，再查看「連線」。如果沒有目標記錄，請檢查應用程式的代理位址、實際監聽連接埠與 TUN 接管狀況。
  3. 確認規則出口：查看連線命中的規則與最終使用的節點。暫時切換到全域模式，並明確選取同一個節點，比較結果。
  4. 確認目標差異：使用同一個節點測試兩個不同網站。若只有單一網站無法連線，請留意目標服務的限制、DNS 與出口連線狀況。
  5. 保留有效線索：記錄用戶端與核心版本、錯誤時間、模式、目標網域及已遮蔽敏感資訊的記錄。完成一次測試後，再修改下一項設定。

需要確認操作流程，可參閱入門指南；需要依錯誤現象找出原因，可使用故障排除。回報問題前，請先移除訂閱權杖、節點驗證資訊與控制介面金鑰。