Clash 新手第一週最常見的十個問題：從匯入訂閱到系統代理一次搞懂

一、如何選擇客戶端，Clash、Clash Meta 與 mihomo 有什麼關係

問題 1：應該下載哪個 Clash 客戶端

直接說結論：先依作業系統選擇仍在維護、具備圖形介面的客戶端，再確認其核心支援目前訂閱使用的協定。Windows 與 macOS 新手優先選擇能管理設定、系統代理與 TUN 模式的桌面客戶端；Android 則選擇支援匯入設定與依應用程式分流的客戶端。首次使用不必同時安裝多個客戶端，同一台裝置執行兩個代理程式反而容易造成連接埠衝突。

「Clash」可能指原始 Clash 核心，也可能泛指採用 Clash 設定格式的客戶端。原始專案已停止更新，目前常見的新客戶端多採用 mihomo 核心。mihomo 曾以 Clash Meta 為名稱，設定結構延續 Clash YAML，並擴充協定、規則集、DNS 與透明代理能力。看到「Meta 核心」或「mihomo 核心」時，可以理解為同一技術路線在不同時期的名稱。

• 只需要基本網頁代理：圖形介面客戶端、規則模式與系統代理即可完成大部分操作。
• 需要遊戲啟動器、命令列或商店應用程式：選擇支援 TUN 模式的客戶端。
• 需要匯入既有 YAML：確認客戶端支援本機設定檔，而不只是訂閱連結。
• 裝置架構不同：Windows 常見 x64 與 arm64，Apple Silicon Mac 應選擇 arm64，Intel Mac 則選擇 x64。

二、訂閱連結從哪裡取得，如何正確匯入

問題 2：客戶端安裝完成後，為什麼沒有節點

Clash 客戶端本身通常只負責讀取設定、執行規則與轉送連線，不會自動產生可用節點。節點資訊來自使用者自己的服務設定、組織內部設定，或網路服務提供者產生的訂閱網址。訂閱網址通常是一串以 HTTPS 開頭的專用 URL，其中可能包含存取權杖，應視為帳號憑證管理，不要發布在截圖、論壇或公開程式碼儲存庫中。

典型匯入路徑是「設定」→「新增設定」→「從 URL 匯入」，部分客戶端則使用「Profiles」→「New Profile」→「URL」。貼上訂閱網址後先執行下載，再將新設定設為目前使用的設定。只看到設定出現在清單中，不代表已經啟用，還要確認該設定旁出現「目前」「已選取」或勾選標記。

1. 複製完整訂閱網址，確認開頭是否為 https://。
2. 進入客戶端的「設定」或「Profiles」頁面。
3. 選擇「從 URL 匯入」，貼上網址並下載。
4. 選取剛下載的設定，等待代理群組與節點清單出現。
5. 進入「代理」頁面，在目標策略群組中選定節點。
6. 回到首頁，開啟「系統代理」，再使用瀏覽器進行連線測試。

問題 3：訂閱匯入或更新失敗，該如何處理

先區分「網址無法下載」與「下載後無法解析」。前者通常表現為逾時、HTTP 401、403 或 404；後者通常會顯示 YAML 解析錯誤、欄位型別錯誤或設定驗證失敗。401 與 403 多半表示權杖失效、帳號狀態變更或服務端限制，404 可能代表網址已更換。解析錯誤則要檢查訂閱是否輸出 Clash 或 mihomo 可識別的設定格式。

首次匯入時不要同時開啟自動更新、設定覆寫與腳本處理。先確認原始設定可以載入，再逐項增加功能。如果在瀏覽器直接開啟訂閱網址後得到登入頁面或 HTML 錯誤頁，客戶端同樣無法將它解析為 YAML。訂閱網址有效但客戶端仍報錯時，可以在「設定」→「日誌」中暫時將日誌等級調至 debug，重現一次後查看具體失敗階段，排查結束再改回 info。

三、規則、全域與直連模式該選哪一個

問題 4：Rule、Global、Direct 有什麼差別

Rule 規則模式會依照設定中的規則，逐條比對網域、IP、程序或規則集，再將連線交給指定的策略群組。適合日常使用，也是多數訂閱設定的預設模式。中國大陸網站可以直連，需要代理的目標則進入代理策略，區域網路位址通常維持直連。

Global 全域模式會將大部分連線交給名為 GLOBAL 的策略群組，適合暫時確認某個節點能否建立連線。這不代表所有流量一定離開本地網路，區域網路、保留位址與客戶端自身連線仍可能依核心規則處理。長期使用全域模式會繞過訂閱預先設計好的分流邏輯。

Direct 直連模式讓連線直接存取目標，不經過代理節點。適合確認問題是否由代理鏈路造成，也適合暫時停用轉送。Direct 並不是退出客戶端；如果系統代理仍指向本機連接埠，流量仍會先抵達客戶端，再由客戶端直連。

1. 日常使用選擇「模式」→「規則」。
2. 進入「代理」→目標策略群組，選擇延遲測試可用的節點。
3. 某個網站異常時，暫時切換全域模式進行比對。
4. 全域可用但規則模式失敗，重點檢查規則命中結果與策略群組選擇。
5. 全域也失敗，重點檢查節點、網路、連接埠與 DNS。

如何確認一條連線命中了哪一條規則

開啟「連線」或「Connections」頁面，重新造訪目標網站，再依網域篩選。記錄通常會顯示目標主機、目標連接埠、上傳下載量、命中的規則與實際策略鏈。例如記錄顯示 DOMAIN-SUFFIX 命中 Proxy，而 Proxy 目前選擇某個節點，就能確認分流路徑。若顯示 MATCH → DIRECT，表示最後的兜底規則將連線交給直連。

四、系統代理已開啟，為什麼瀏覽器仍然無法連線

問題 5：系統代理開關究竟做了什麼

系統代理開關通常只是將作業系統的 HTTP 與 HTTPS 代理位址設定為 127.0.0.1 加上本機連接埠。例如設定使用 mixed-port: 7890，系統代理就會指向 127.0.0.1:7890。應用程式是否遵循這項設定，取決於應用程式本身。主流瀏覽器通常會讀取系統代理，部分遊戲、終端程式、商店應用程式與使用自有網路堆疊的軟體可能會忽略它。

依照以下順序檢查，避免反覆切換節點而掩蓋真正原因：

1. 在客戶端首頁確認核心狀態為執行中，而不只是介面已啟動。
2. 進入「設定」→「連接埠設定」，記錄 Mixed Port 的實際值。
3. 確認系統代理位址與該連接埠一致，例如 127.0.0.1:7890。
4. 開啟「連線」頁面，再重新整理瀏覽器，查看是否出現新連線。
5. 有連線但無法存取，檢查規則命中、節點與 DNS。
6. 完全沒有連線，檢查瀏覽器代理擴充功能、系統代理覆寫與應用程式自身設定。

瀏覽器同時安裝代理擴充功能時，擴充功能可能會覆寫系統代理。排查期間應將擴充功能切換為「使用系統代理」或暫時停用。命令列工具也可能讀取環境變數，Windows PowerShell 可檢查 HTTP_PROXY 與 HTTPS_PROXY，macOS 或 Linux 終端機可執行 env | grep -i proxy。舊環境變數若仍指向另一個連接埠，就會造成瀏覽器正常、終端機失敗的分歧現象。

問題 6：什麼時候需要開啟 TUN 模式

TUN 模式透過虛擬網路介面接收更多系統流量，適用於忽略系統代理的應用程式、UDP 流量、部分遊戲啟動器，以及需要統一接管的命令列程式。它不是「加速」開關。只使用瀏覽器與一般桌面應用程式時，系統代理通常更容易維護；明確發現目標應用程式不讀取系統代理後，再啟用 TUN 會更合適。

常見路徑為「設定」→「網路設定」→「TUN 模式」，首次開啟可能要求管理員權限並安裝虛擬網路元件。開啟後檢查客戶端是否顯示 TUN 正常執行，同時確認系統中沒有另一個 VPN、虛擬網卡工具或舊客戶端爭用路由。Windows 上若啟用失敗，可先完全退出客戶端，再以管理員權限啟動一次完成服務安裝；之後是否持續需要管理員權限，取決於客戶端的服務實作。

五、節點顯示逾時、連接埠衝突與 DNS 該如何檢查

問題 7：延遲測試顯示 Timeout，是否代表節點一定無法使用

不一定。延遲測試通常會請求設定指定的測試 URL，並設定固定的逾時時間。測試網址無法連線、節點不允許存取該目標、DNS 解析失敗或本機網路封包遺失，都可能顯示 Timeout。至少應進行三項交叉驗證：更新設定、切換兩個不同地區的節點，以及使用瀏覽器存取一個明確支援 HTTPS 的目標。

延遲數值也不等於下載速度。一次測試得到 80 ms，只表示該測試請求當時約在 80 毫秒內完成，不能據此推論持續傳輸能力。連續三次分別為 85 ms、92 ms、410 ms，表示鏈路抖動較大；穩定的 140 ms 節點在影片與一般網頁情境中，可能比頻繁跳到 400 ms 的低延遲節點更實用。

• 所有節點同時逾時：先檢查訂閱狀態、本機網路、DNS 與客戶端日誌。
• 只有一個節點逾時：切換同組其他節點，稍後再次測試。
• 延遲測試正常但網頁失敗：檢查規則命中、瀏覽器代理與目標網站限制。
• TCP 頁面正常但遊戲失敗：檢查客戶端是否接管 UDP，以及 TUN 設定是否生效。

問題 8：出現「連接埠 7890 已被使用」怎麼辦

這表示另一個程序已經監聽相同的連接埠。常見原因包括舊客戶端仍在背景執行、同一客戶端啟動了兩個執行個體，或其他網路工具也使用 7890。不要直接連續更換連接埠，先找出占用中的程序。Windows 可在命令提示字元執行以下命令：

netstat -ano | findstr :7890
tasklist /fi "PID eq 程序編號"

macOS 與 Linux 可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iUDP:7890

確認是舊執行個體後，正常退出該程序，再重新啟動目前的客戶端。如果連接埠確實被其他必要程式使用，可進入「設定」→「連接埠設定」，將 Mixed Port 改為 7891 或其他未被占用的連接埠。修改後必須同步重新整理系統代理，使其指向新連接埠。手動維護 YAML 時，對應設定可寫成：

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info

allow-lan: false 表示不向區域網路裝置提供代理入口。如果確實需要讓手機透過電腦代理，再開啟區域網路存取，並配合作業系統防火牆與信任網路範圍設定，不應只修改監聽連接埠。

問題 9：網頁可以開啟，但網域解析很慢或出現 DNS 異常怎麼辦

Clash 或 mihomo 的 DNS 模組負責在規則比對與建立連線之間協調網域解析。常見的增強模式包括 fake-ip 與 redir-host。fake-ip 會先回傳保留位址對映，再由核心還原原始網域，規則比對效率較高，也更適合 TUN 接管；某些區域網路裝置、企業軟體或依賴真實 IP 的程式可能需要加入 fake-ip-filter。

在尚未確認問題來源前，不要堆疊大量 DNS 伺服器。先使用兩條穩定的解析線路，觀察日誌中是否出現逾時。基本結構如下，實際設定仍應依照目前客戶端與訂閱要求：

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

修改設定後應執行「設定」→「重新載入」，再清除應用程式自身的快取並重新測試。Windows 可執行 ipconfig /flushdns 清除系統 DNS 快取，macOS 則可關閉並重新開啟目標應用程式。若客戶端日誌持續出現 DNS timeout，應先測試目前網路能否連線至所填的解析伺服器，而不是繼續增加 fallback 數量。

六、設定更新、自動選擇與故障復原

問題 10：第一週結束前應該保留哪些設定

先保留最小可重現狀態：一個有效訂閱、一份目前設定、規則模式、一個確認可用的節點、正確的本機連接埠，以及明確選定的系統代理或 TUN 接管方式。不要同時開啟多個自動選擇腳本、遠端規則覆寫與實驗性 DNS 選項。基礎鏈路穩定後，再加入自動更新、延遲測試與規則集功能。

訂閱自動更新間隔不宜過短。節點資訊通常不需要每分鐘重新整理，設定為 6 小時、12 小時或 24 小時更方便觀察。客戶端從睡眠狀態恢復網路後，可以手動更新一次設定；若更新失敗，不要立即刪除目前可用的設定，因為舊設定仍可能維持連線。先查看日誌中的 HTTP 狀態碼，再決定是否重新取得訂閱網址。

建議記錄的六項資訊

• 客戶端名稱、版本號與系統架構，例如 Windows 11 x64。
• 核心名稱與版本，例如 mihomo 1.19.x。
• 目前模式：Rule、Global 或 Direct。
• 流量入口：系統代理、TUN，或應用程式內手動代理。
• Mixed Port 實際值，例如 7890 或 7891。
• 故障發生時間、日誌錯誤行與命中的策略群組。

這六項資訊比「連不上」更容易定位問題。例如：Windows 11 x64、mihomo 1.19.x、規則模式、系統代理、mixed-port 7890、瀏覽器連線命中 Proxy 但日誌顯示 connection timeout。根據這些資訊，可以直接將範圍縮小至節點鏈路，不必反覆重新安裝客戶端。

一套固定的五分鐘排查順序

1. 看核心：確認執行狀態，且日誌中沒有設定載入失敗。
2. 看入口：確認系統代理連接埠或 TUN 接管狀態。
3. 看連線：重新整理目標應用程式，觀察 Connections 是否出現記錄。
4. 看規則：確認記錄命中的規則、策略群組與最終節點。
5. 看出口：切換另一個節點，比較全域模式與規則模式的結果。

如果 Direct 可以存取、Rule 失敗，而 Connections 顯示請求進入錯誤的策略群組，應修正規則或策略群組選擇；如果 Direct 與代理都失敗，應回到本機網路與 DNS；如果瀏覽器有連線記錄而目標應用程式完全沒有記錄，則應檢查該應用程式是否讀取系統代理，並決定是否使用 TUN。依照入口、規則、出口分層排查，比刪除設定後重新安裝更容易保留有效線索。