Clash 新手常見 10 問：訂閱匯入、代理模式與系統代理設定

一、Clash、用戶端與 mihomo 分別是什麼？

先分清楚三個部分：用戶端提供操作介面，核心負責處理網路連線，訂閱則提供節點或設定檔。安裝用戶端不代表已經有可用的代理節點；匯入訂閱後，還要啟用設定檔、選擇策略，並讓應用程式的流量進入代理。

Clash 原版核心與 mihomo 並非同一個持續更新的專案。mihomo 是從 Clash Meta 發展而來，保留許多 Clash 設定習慣，同時增加了通訊協定與設定功能。舊核心不一定能讀取為 mihomo 撰寫的設定檔；即使副檔名同樣是 .yaml，也不代表彼此相容。

• 選擇用戶端：依作業系統與處理器架構選擇安裝檔，並參考用戶端比較確認核心類型。
• 確認設定檔：向服務提供者確認應使用 Clash 或 Clash Meta／mihomo 格式。
• 查看錯誤訊息：若出現「不支援的代理類型」，先確認核心支援的功能，不要只是不斷下載同一份訂閱。

各用戶端的設定選單不盡相同。下文以「訂閱」、「系統代理」、「連線記錄」稱呼通用功能；提到作業系統時會列出明確路徑。範例連接埠為 7890，實際使用前請以用戶端目前顯示的監聽連接埠為準。

二、訂閱連結要貼在哪裡？怎樣才算匯入成功？

訂閱連結應貼在用戶端的遠端訂閱匯入欄位，不是瀏覽器的代理伺服器位址欄，也不是節點的伺服器位址欄位。遠端訂閱通常會傳回 YAML 設定檔；有些服務提供多種輸出格式，請複製適用於該用戶端的連結。

1. 在服務提供者的訂閱頁面複製完整連結，保留查詢參數，並避免複製時帶入空格或換行。
2. 開啟用戶端的訂閱管理頁面，使用遠端匯入功能貼上連結，再執行下載。
3. 下載完成後，選取或啟用這份設定檔。清單中出現設定檔卡片，不代表核心目前正在使用它。
4. 前往代理或策略群組頁面，確認看得到節點與群組，再查看記錄中是否有載入設定檔的錯誤。

如果手邊只有本機 YAML 檔案，請使用本機設定檔匯入功能。匯入後若沒有節點，先確認下載內容是否其實是登入頁面、錯誤訊息或空檔案。不要把所有能在瀏覽器開啟的 URL 都當成訂閱連結。

三、Rule、Global、Direct 該怎麼選？

日常使用通常選 Rule，依規則決定每條連線要直連、交由代理群組處理，或採取其他動作。Global 適合暫時測試代理連線；Direct 則讓進入核心的連線直接連至目標。模式只會決定已進入核心的流量如何處理，不會自動接管所有應用程式。

切換至 Global 後，仍要確認 GLOBAL 目前選了什麼。它可能選到另一個策略群組，也可能選到 DIRECT，並非一切換就一定會使用遠端節點。排查完畢後請切回 Rule，避免原本應直連的連線長期繞送至遠端。

以下是規則片段，並非完整設定檔。Proxy 是範例策略群組名稱，請替換成目前設定檔中實際存在的群組名稱，或先定義該群組：

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

MATCH 是最後的預設規則，通常放在最末尾。若提前放置，後面的規則就不會有比對機會。GEOIP 規則也需要相應的地理資料檔可用，不能只確認 YAML 語法正確就算完成。

四、已開啟系統代理，為什麼應用程式還是沒有走代理？

系統代理是提供給會讀取系統代理設定的應用程式使用，並非強制轉送所有流量。有些瀏覽器使用自己的代理設定；部分命令列程式只讀取環境變數，遊戲或其他應用程式也可能直接建立連線。

先檢查監聽狀態，再確認系統設定

1. 確認核心正在執行，並找出 HTTP 或 mixed-port。mixed-port 可在同一個連接埠接收 HTTP 與 SOCKS 代理連線。
2. 本機應用程式應連線至 127.0.0.1 和實際連接埠。不要將訂閱網域填入系統代理伺服器欄位。
3. Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」，確認位址與連接埠。
4. macOS 可前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「Proxy」，確認 HTTP 與 HTTPS 代理設定。

使用以下命令明確指定代理，可排除「程式是否讀取系統設定」這個變因。Windows PowerShell 請使用 curl.exe，避免舊環境中同名別名造成干擾；其他系統通常使用 curl。

curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com

若記錄顯示無法連線至 127.0.0.1:7890，請優先檢查連接埠與核心程序。若代理連線已建立，但目標請求仍失敗，再檢查節點、規則與 DNS。成功收到網頁回應，只能表示這項請求經過本機代理入口，不能單憑此結果證明最後使用了遠端節點。

五、系統代理和 TUN 模式需要同時開啟嗎？

不必為了「更完整」而一開始就同時開啟。系統代理適合瀏覽器等遵循代理設定的程式；TUN 透過虛擬網路介面與路由接收流量，適合不遵循系統代理的應用程式，但也需要處理權限、路由和 DNS 等額外設定。

• 先用瀏覽器測試：先透過系統代理確認設定、節點與規則正常，再決定是否需要 TUN。
• 應用程式未使用代理：確認用戶端支援 TUN，並依照要求安裝服務或授予相應權限。
• 正在使用其他 VPN：先暫停另一套會接管路由的軟體，分開測試，避免預設路由與 DNS 接管互相影響。

mihomo 的 tun.enable 控制 TUN 開關，auto-route 涉及自動路由，dns-hijack 用來接管符合條件的 DNS 流量。這些欄位不代表「開啟後就一定能接管所有流量」；平台、權限、排除路由，以及應用程式自行使用的加密 DNS 都會影響結果。

六、節點顯示延遲數值，為什麼網頁還是打不開？

延遲測試通常是用戶端透過節點請求某個測試 URL 所花的時間，不等同 ICMP ping，也不代表所有目標網站都能連線。測試網址可連線，不代表影片、登入頁面或特定地區服務也一定可用。

逐項確認連線路徑

1. 檢查策略選擇：目前命中哪個群組？手動選取群組、自動測速群組與故障轉移群組的選路方式並不相同。
2. 重新發送請求：切換節點後重新連線。舊的 TCP 連線可能仍沿用原本的路徑，頁面快取也可能影響判斷。
3. 確認目標差異：先測試一般 HTTPS 網頁，再測試實際發生問題的頁面，判斷是節點整體無法使用，還是目標服務有限制。
4. 確認記錄顯示的階段：網域解析失敗、連線節點逾時和目標 TLS 失敗是不同問題，不宜一概歸因為「節點太慢」。

若只有特定網站無法使用，請查看該請求實際命中的規則。Rule 模式下，連線可能被分配至 DIRECT，或進入另一個策略群組。不要只看節點清單中目前選取的項目；連線記錄才對應到這次請求。

七、訂閱更新失敗，要先更換 DNS 嗎？

先看錯誤訊息，再決定要檢查哪裡。更新可能在網域解析、TCP 連線、TLS 交握、HTTP 回應或 YAML 解析階段失敗。只有解析相關錯誤才直接指向 DNS；HTTP 狀態碼或設定語法錯誤，不會因為更換 DNS 自動修復。

部分用戶端可設定訂閱更新是否透過代理，也有些使用獨立的下載機制。網頁能開啟，不代表更新程式使用相同路徑。請查閱用戶端說明確認下載方式，不要假設開啟系統代理後，所有背景更新都會使用代理。

保留最後一份可用的設定檔，再嘗試更新。訂閱無法連線時，不要先刪除唯一可用的設定檔；也不要為了排除 TLS 錯誤而直接關閉憑證驗證。若出現憑證時間錯誤，請先檢查系統日期、時區與網路環境。

八、如何理解 DNS、Fake-IP 與「DNS 洩漏」？

DNS 會將網域名稱解析為 IP 位址。mihomo 的 Fake-IP 模式會為網域分配對應位址，再透過內部映射處理後續連線；常見設定會使用 198.18.0.0/16。看到這類位址，不代表節點故障或網域解析錯誤。

DNS 洩漏關注的是 DNS 查詢是否經過非預期的解析路徑。檢測頁面顯示的解析器所在地，不一定與瀏覽器代理節點所在地相同；遠端解析服務、快取及服務提供者的網路出口都會影響顯示結果。只憑地區標籤，無法完整判定是否發生洩漏或是否安全。

• 先確認系統 DNS 請求是否進入核心，再檢查核心使用的 nameserver 與網域層級的 nameserver-policy。
• 瀏覽器自帶的安全 DNS／DoH 可能使用獨立連線，應配合實際路由檢查，不要只修改系統 DNS。
• 部分區域網路服務或應用程式不適合使用 Fake-IP，可視需要設定 fake-ip-filter，不要直接排除所有網域。

新手建議先使用來源明確、且符合目前核心版本的 DNS 設定，再針對特定問題調整。DNS 欄位彼此相關，盲目拼湊多篇教學的設定容易造成上游解析迴圈。欄位說明請參閱進階設定與 mihomo DNS 文件。

九、如何確認某個網站實際套用哪條規則？

在用戶端的連線頁面找到目標請求，查看目標網域、命中的規則與策略路徑。各用戶端的介面名稱可能不同，重點是將「一次請求」與「一項路由結果」對應起來，而不是透過外網 IP 檢測網站推測所有應用程式的連線方式。

1. 暫停無關的下載，減少背景連線造成的干擾。
2. 開啟連線記錄，再於瀏覽器重新造訪目標頁面。
3. 依網域或程序篩選，確認目標連線套用的規則與最終策略。
4. 修改規則後重新載入設定檔，並建立新連線再次測試。

若要暫時新增網域規則，請放在可能提前命中的廣泛規則之前。以下片段會讓 example.com 及其子網域直連，僅用來說明語法；它不是完整設定檔，也不會影響其他網域：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Proxy

Proxy 仍須對應到實際存在的策略群組。遠端訂閱更新可能會覆蓋直接編輯的內容；若要長期自訂，請使用用戶端提供的覆寫、合併或指令碼機制，並確認產生後實際生效的設定。各用戶端的合併順序不同，不要只根據編輯器顯示的片段判斷最終規則。

十、關閉用戶端後網路中斷，該如何恢復？

常見原因是本機代理程序已停止，但系統仍指向該程序的監聽位址。此時應用程式仍會連線至 127.0.0.1:7890，自然無法取得回應。先恢復網路連線入口，再檢查設定，不必立刻重新安裝用戶端。

從小範圍開始逐步恢復

1. 若用戶端仍可開啟，請先關閉系統代理和 TUN，再正常結束程式。
2. Windows 11 請前往「設定」→「網路和網際網路」→「Proxy」，關閉不再使用的手動 Proxy；若是由公司管理的代理設定，請先向管理員確認。
3. macOS 請前往目前網路服務的「詳細資訊」→「Proxy」，取消已失效的代理項目。
4. 若只有終端機無法連線，請檢查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等環境變數，以及工具本身的代理設定。
5. 若 TUN 異常結束後仍無法連線，請重新啟動用戶端並正常關閉 TUN；必要時重新啟動系統，讓網路介面與路由重新建立。

Linux 或 macOS 可先查看目前 shell 的代理環境變數。以下命令只會讀取並篩選資料，不會變更系統設定；變數內容可能包含帳戶資訊，分享輸出前請先遮蔽敏感資料：

env | grep -iE '^(http|https|all|no)_proxy='

一開始不要執行網路重設或清除所有防火牆規則，這些操作可能影響其他 VPN、虛擬機或企業網路。恢復連線後，依照「設定檔已啟用 → 核心已監聽 → 應用程式已接入 → 規則選路正確」的順序重新確認，通常就能將問題縮小到特定環節。