Clash 新手十問十答：訂閱、節點、代理模式一次搞懂

一、Clash 是節點服務嗎？訂閱連結從哪裡取得

Clash、Clash Meta（目前通常使用 mihomo 這個名稱）以及各類圖形化客戶端，負責讀取設定、比對規則並轉送連線。它們本身不提供節點，安裝完成後也不會自動產生訂閱。訂閱連結需要由你使用的服務提供商建立，通常位於服務後台的「訂閱」、「一鍵訂閱」或「客戶端匯入」頁面。

一個訂閱通常會回傳 YAML 設定，或經過編碼的節點清單。完整的 Clash 設定不只包含伺服器位址，也可能包含代理群組、規則集、DNS 與 TUN 參數。只有單一節點分享連結時，也可以手動匯入，但代理群組與分流規則需要另外設定。

取得連結後先檢查三件事

確認服務後台提供的是 Clash 或 Clash Meta 格式，而不是僅供其他客戶端使用的格式。
複製時保留完整的 https://、路徑、查詢參數與權杖，不要遺漏結尾字元。
先用瀏覽器開啟服務後台，確認帳戶與訂閱仍然有效；不要把登入頁網址誤當成訂閱位址。

二、訂閱該如何匯入？為什麼匯入後還要更新

不同圖形化客戶端的名稱略有差異，但操作順序基本一致。以常見介面為例，進入「訂閱」→「新增訂閱」，貼上 URL，填寫方便辨識的名稱，然後選擇「儲存並更新」。另一類介面會將入口標示為「設定」→「新增」→「URL」。匯入成功後，應該能看到更新時間、設定檔名稱以及代理數量。

「儲存」只會記錄位址，「更新」才會真正取得遠端內容。首次匯入後節點清單為空，最常見的原因就是只儲存了 URL，沒有執行更新。建議將自動更新間隔設在服務允許的範圍內，例如每 1,440 分鐘一次；頻繁設為 5 分鐘不會讓線路更穩定，反而可能觸發伺服器端的請求限制。

更新失敗時依照這個順序排查

查看錯誤是否為 401 或 403。這通常表示權杖失效、帳戶狀態異常或請求遭拒。
出現 404 時重新複製訂閱位址，重點檢查路徑和查詢參數是否完整。
出現連線逾時時，先關閉目前的代理後再更新一次；如果直連無法連到伺服器，再嘗試啟用可用的舊設定進行更新。
更新完成但節點數量為 0 時，請確認下載到的是網頁 HTML，而不是 YAML 或節點清單。
設定解析出錯時，查看記錄檔中的行號。若伺服器回傳不相容的欄位，請切換至 Clash Meta 格式或更新 mihomo 核心。

三、訂閱匯入成功，為什麼看不到節點

先區分「訂閱存在」與「目前設定已啟用」。許多客戶端允許儲存多個設定，但同一時間只會載入其中一個。進入「訂閱」或「設定」頁面，選取剛更新的設定，再執行「啟用」、「設為目前設定」或「切換」。接著開啟「代理」頁面，檢查策略群組中是否出現節點。

如果設定已啟用，仍然沒有可選項，可能是設定只定義了規則，沒有定義 proxies 或 proxy-providers。也可能是代理提供者尚未完成首次擷取。對於 provider 設定，可以進入「代理提供者」頁面手動更新，或在記錄檔中搜尋 provider 名稱。

介面現象	常見原因	處理方式
訂閱卡片存在，但代理頁仍顯示舊節點	新設定尚未設為目前設定	選取新設定並執行啟用或切換
代理群組存在，但群組內為空	代理提供者擷取失敗	手動更新 provider 並查看記錄檔
更新提示解析失敗	YAML 縮排、欄位或格式不相容	切換訂閱格式或更新 mihomo 核心
只有 DIRECT 與 REJECT	設定未包含可用的代理定義	檢查服務後台匯出的設定類型

四、節點為什麼全部逾時？延遲數字怎麼看

延遲測試不是對節點伺服器進行一次簡單的網路探測。Clash 通常會透過該節點請求測試 URL，並計算從建立連線到收到回應所需的時間。因此，「逾時」可能發生在本地網路、節點入口、目標測試網站、DNS 解析或 TLS 交握的任何一個環節。

可以先單獨測試 3 個節點，避免一次對數十條線路發起請求。常見測試 URL 為 https://www.gstatic.com/generate_204，逾時值可先設為 5,000 毫秒。若目前網路無法連到這個位址，應改用服務提供方建議的 HTTP 204 測試位址，否則所有節點可能同時顯示逾時。

延遲結果的實用判斷

50 至 120 毫秒：通常適合瀏覽網頁、即時通訊與一般影音連線。
120 至 250 毫秒：可以正常使用，但即時語音、遠端桌面可能會感覺回應變慢。
超過 500 毫秒：應更換線路再次測試，並觀察是否伴隨封包遺失或頻繁中斷。
固定顯示 0 毫秒：通常不是真實結果，可能表示測試尚未執行或介面尚未重新整理。
全部 Timeout：先測試直連網路，再檢查系統時間、DNS、核心記錄檔與測試 URL。

五、規則、全域和直連模式該選哪個

新手日常使用建議優先選擇規則模式。規則模式會由上而下比對網域、IP、程序或規則集，再將連線交給指定的策略群組。中國大陸服務可以直連，需要代理的目標則經由節點，區域網路與特殊位址也能依設定個別處理。

模式	連線處理方式	適用情境
Rule	依規則逐條比對，符合後使用對應策略	日常使用與長時間執行
Global	將大部分可代理的連線統一交給全域策略群組	暫時判斷是否因分流規則導致無法存取
Direct	連線直接送出，不經過代理節點	暫停代理、測試本地網路或更新訂閱

如果某個網站在規則模式下無法開啟，可以暫時切換到全域模式測試。若全域模式可用，表示節點本身大致正常，應檢查該網域命中了哪條規則；若全域模式也失敗，則繼續檢查節點、DNS 與目標網站狀態。測試完成後切回規則模式，避免所有連線長期集中到同一個節點。

記錄檔中的規則命中資訊非常重要。將記錄層級暫時設為 info，重新存取目標網站，查看網域最後進入了 DIRECT、REJECT 或某個代理群組。排查結束後不必長期使用 debug，詳細記錄會快速增加檔案大小。

六、系統代理和 TUN 模式有什麼不同

系統代理是在作業系統中寫入 HTTP 與 SOCKS 代理位址。遵循系統代理設定的瀏覽器和應用程式，會將連線傳送給 Clash，例如本機常用的 mixed 監聽位址 127.0.0.1:7890。它設定簡單，也方便隨時開關，但部分遊戲、命令列工具、商店應用程式和採用自有網路堆疊的軟體可能會忽略系統代理。

TUN 模式會建立虛擬網路介面，並透過路由接管更多 TCP、UDP 與 DNS 流量。它適合無法手動設定代理的應用程式，但需要作業系統授予建立虛擬網卡和修改路由的權限。Windows 客戶端通常需要先安裝服務模式；macOS 會要求網路延伸功能權限；Linux 則需要相應的網路管理能力。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

以上是 mihomo 設定中常見的 TUN 結構，實際可用欄位取決於核心版本與客戶端的管理方式。圖形化客戶端已經接管這些參數時，請優先透過「設定」→「網路設定」→「TUN 模式」啟用，不要同時在介面和訂閱覆寫中維護兩份互相衝突的設定。

新手選擇建議

只需要瀏覽器和一般桌面應用程式：先啟用系統代理。
遊戲、終端機或特定應用程式不讀取系統代理：再啟用 TUN。
啟用 TUN 後無法上網：關閉 TUN、恢復網路，再檢查服務模式、路由與 DNS 記錄檔。
系統代理與 TUN 可由部分客戶端協同管理，但不要另外安裝多個工具重複接管路由。

七、7890、7891 和 9090 連接埠各自做什麼

連接埠是本機程式連線至 Clash 核心的入口。設定中的 mixed-port: 7890 可以同時接受 HTTP 與 SOCKS 代理連線，適合多數桌面客戶端。舊設定常將 HTTP 放在 7890、SOCKS 放在 7891。external-controller: 127.0.0.1:9090 則用於圖形介面控制核心，不是供一般應用程式填寫的代理連接埠。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

如果應用程式要求填寫代理位址，可以使用主機 127.0.0.1 和 mixed 連接埠 7890。不要將 9090 填入瀏覽器的代理設定。若要在區域網路分享代理，必須明確啟用 allow-lan 並設定監聽位址，同時在系統防火牆中限制來源；只在本機使用時保持關閉會更容易管理。

啟動記錄檔出現 address already in use，表示連接埠已被其他程序監聽。進入「設定」→「參數設定」修改 mixed 連接埠，例如從 7890 改為 7893，然後重新啟動核心。修改後，曾手動設定代理連接埠的瀏覽器、終端機和其他應用程式也要同步更新。

八、瀏覽器可以存取，其他應用程式為什麼仍然直連或斷網

瀏覽器可以存取，只代表瀏覽器的連線進入了 Clash，不表示整台裝置的所有流量都已被接管。先確認瀏覽器是否安裝了獨立的代理擴充功能；如果擴充功能直接指向 127.0.0.1:7890，即使系統代理關閉，瀏覽器仍可能繼續使用 Clash，而其他應用程式仍然直連。

依應用程式類型檢查

一般桌面應用程式：檢查「系統設定」→「網路和 Internet」→「代理伺服器」中的位址與連接埠是否由客戶端正確寫入。
命令列工具：確認工具是否讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 環境變數。
遊戲與 UDP 應用程式：系統 HTTP 代理通常無法涵蓋，應使用支援 UDP 的節點並啟用 TUN。
Windows 市集應用程式：部分 UWP 應用程式會受到迴圈存取限制影響，需要為目標應用程式設定迴圈存取豁免。
虛擬機器與容器：其中的 127.0.0.1 指向虛擬環境本身，不能直接代表主機位址。

排查時開啟客戶端的連線清單，然後在目標應用程式中發起一次新請求。如果清單中完全沒有對應的網域或程序，表示流量尚未進入核心；如果已出現連線但結果失敗，則查看規則命中、節點與 DNS。這個判斷能避免在「接管問題」和「代理問題」之間反覆切換。

九、規則為什麼沒有生效？自訂規則應該放在哪裡

Clash 會依照設定中的順序，由上而下比對規則，通常命中第一條規則後就會停止繼續檢查。因此，更具體的自訂規則應放在寬泛規則之前，也必須位於最後的 MATCH 規則之前。將規則加在 MATCH 後面不會產生效果。

rules:
  - DOMAIN,api.example.com,Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

DOMAIN 只會比對完整網域，DOMAIN-SUFFIX 會比對該後綴及其子網域。IP-CIDR 用於網段，結尾的 no-resolve 表示比對時不要為了取得 IP 而主動解析網域。規則最後的策略名稱必須與 proxy-groups 中的群組名稱完全一致，包括大小寫與空格。

訂閱更新經常會覆蓋原始 YAML，直接編輯訂閱檔案並不穩妥。支援覆寫功能的客戶端通常提供「訂閱」→「覆寫」或「設定」→「合併設定」入口，可以將自訂規則插入遠端規則之前。儲存後重新載入設定，再透過連線記錄檔確認實際命中的規則。

十、如何確認代理已生效？離開前要注意什麼

確認連線是否生效，不要只看客戶端的開關。先在直連模式記錄一次目前的出口資訊，再切換到規則模式並選擇節點，重新開啟檢測頁面。若出口位址和地區如預期變化，同時客戶端連線清單出現對應網域，表示該請求已經經過代理。

接著檢查 DNS 與規則。開啟客戶端記錄檔，存取一個應該直連的中國大陸網站，以及一個應該使用代理的目標，確認兩者分別命中 DIRECT 與指定代理群組。使用 Fake-IP 時，應用程式看到 198.18.0.0/15 範圍的映射位址屬於常見運作方式，真實網域仍由核心保存映射並用於規則比對。

首次使用完成後的檢查清單

目前設定已啟用，訂閱更新時間和節點數量正常。
模式設為 Rule，目標策略群組已選取可用節點。
系統代理或 TUN 至少啟用一個，並與實際應用程式類型相符。
連線清單能看到目標請求，規則命中結果符合預期。
核心記錄檔沒有持續出現連接埠衝突、DNS 逾時或 provider 更新失敗。
關閉客戶端時，同時恢復系統代理與 TUN 路由，避免系統保留失效的代理位址。

如果關閉 Clash 後網頁全部無法開啟，先到系統代理設定中確認代理開關已關閉。TUN 使用異常時，退出客戶端後重新連線網路，必要時重新啟動系統以恢復路由。再次啟動前，不要同時執行多個監聽 7890 或接管預設路由的代理客戶端。

新手排障可以固定按照一個順序進行：先檢查本地網路，再檢查訂閱是否更新，接著確認設定已啟用、節點可連線、模式與策略群組正確，最後檢查系統代理或 TUN 是否真正接管應用程式。每次只修改一個變數，並在連線清單和記錄檔中驗證結果，通常比反覆重新安裝客戶端更快。