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

一、Clash 安裝後為什麼沒有可用節點？

Clash 客戶端主要負責讀取設定、執行代理規則與轉送連線，安裝套件通常不包含可直接使用的代理節點。首次啟動後只看到空白代理清單，或介面提示「未選擇設定」，通常不是安裝失敗，而是尚未匯入設定檔或訂閱網址。

訂閱連結從哪裡取得

訂閱網址由所使用的代理服務提供商產生，通常可以在該服務的控制台中找到「訂閱」、「一鍵訂閱」或「Clash 設定」入口。Clash 專案、Clash Meta（mihomo）核心與圖形化客戶端本身都不負責分配伺服器帳號，也不會自動產生可連線的節點。

優先選擇明確標示為 Clash、Clash Meta 或 YAML 的訂閱格式。
複製連結時確認開頭為 https://，避免誤把網頁網址當成訂閱網址。
訂閱網址通常包含存取憑證，請勿發布在截圖、論壇或公開程式碼儲存庫中。
服務商更換網域或重設訂閱後，舊網址可能回傳 404、403 或空白設定。

二、如何匯入訂閱連結，設定檔放在哪裡？

桌面客戶端常見的路徑是「設定」→「新增設定」→「從 URL 匯入」，貼上訂閱網址後執行下載。部分客戶端會將入口命名為「Profiles」→「New Profile」→「Import from URL」。完成匯入後，還要點選該設定，讓它成為目前使用中的設定；只完成下載但未選取時，核心仍可能繼續使用舊檔案。

從 URL 匯入與本機 YAML 的差異

方式	適用情境	更新方式
訂閱 URL	服務商持續維護節點與規則	在設定清單中點選更新，或依設定的週期重新整理
本機 YAML	自行撰寫固定連接埠、規則或代理群組	編輯檔案後重新載入設定
遠端 Provider	將節點與規則拆分為多個來源	依據 `interval` 定時抓取

最基本的設定至少需要監聽連接埠、代理定義、代理群組與規則。不同核心支援的欄位不完全相同，請勿直接將其他客戶端匯出的 JSON 當作 Clash YAML 使用。以下片段只展示常見結構，節點參數需由實際服務設定提供。

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

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,PROXY

若匯入時出現 YAML 解析錯誤，請先檢查縮排。YAML 通常使用空格建立層級，不能以 Tab 取代。冒號後需要保留空格，同一層級的清單項目短橫線也必須對齊。

三、規則、全域與直連模式該怎麼選？

Clash 常見的三種執行模式是 Rule、Global 與 Direct。新手日常使用時，建議優先選擇規則模式。它會按照設定中的 rules 由上到下比對目標網域或 IP，並將連線交給指定的代理群組；未命中時，通常由最後一條 MATCH 決定連線去向。

模式	處理方式	典型用途
規則 Rule	依網域、IP、程序等規則選擇策略	日常瀏覽、辦公與串流媒體分流
全域 Global	大部分連線統一交給全域代理群組	暫時判斷規則是否漏配
直連 Direct	連線不經過代理節點	暫停代理或排除節點故障

快速判斷方法

先使用規則模式存取目標網站，觀察連線清單中的策略名稱。
若失敗，暫時切換至全域模式，並選擇一個已通過延遲測試的節點。
若全域模式可以存取，表示節點基本可用，接著應檢查規則比對或 DNS。
若全域模式仍然失敗，請再檢查節點狀態、系統時間、防火牆與網路環境。

四、系統代理已經開啟，為什麼瀏覽器仍未生效？

「啟動核心」和「開啟系統代理」是兩個不同的動作。核心啟動後會監聽本機連接埠，例如混合連接埠 127.0.0.1:7890；系統代理則負責將遵循作業系統代理設定的應用程式指向該連接埠。只啟動核心但未開啟系統代理時，瀏覽器通常仍會直接連線。

依序檢查四個位置

進入「設定」→「核心設定」，確認核心狀態為執行中。
進入「設定」→「參數設定」，確認 Mixed Port 為 7890，且沒有顯示連接埠被佔用。
返回首頁開啟「系統代理」，再檢查作業系統代理位址是否為 127.0.0.1，連接埠是否一致。
關閉瀏覽器中的獨立代理擴充功能，避免擴充功能中的舊連接埠覆蓋系統設定。

可以在終端機驗證本機連接埠是否正在監聽。Windows 可執行 netstat -ano | findstr :7890，macOS 或 Linux 可執行 lsof -iTCP:7890 -sTCP:LISTEN。若沒有結果，表示核心未成功監聽；若程序不是目前的 Clash 客戶端，則可能存在連接埠衝突。

Firefox 等應用程式可以使用獨立的代理設定。如果設為「不使用代理」或手動填入其他連接埠，就不會跟隨系統代理。此時可在瀏覽器的網路設定中選擇「使用系統代理設定」，或手動填寫 HTTP/SOCKS 位址，並確保連接埠相符。

五、如何切換節點，代理群組又是什麼？

進入「代理」或「Proxies」頁面後，通常會看到多個代理群組，而不是一份單純的節點清單。代理群組是規則引用的策略入口，例如 PROXY、Streaming、Telegram。每個群組內可以選擇具體節點，也可以選擇自動測試群組或另一個代理群組。

手動選擇與自動選擇

select：由使用者手動指定節點，選擇結果通常會保留至下次啟動。
url-test：依固定網址測試延遲，並自動選擇目前測量值較低的節點。
fallback：依清單順序檢查可用性，目前節點失效後切換至後續節點。
load-balance：依核心策略將不同連線分配給多個節點，登入類服務可能不適合頻繁變更出口。

切換節點時，應先找出目前規則實際使用的代理群組。例如規則寫著 DOMAIN-SUFFIX,example.com,PROXY，就需要修改 PROXY 群組，而不是只修改名稱相似但未被引用的群組。可以開啟「連線」頁面並存取一次目標網站，查看策略鏈是否顯示為 PROXY / 節點名稱。

六、延遲數值越低，節點就一定越快嗎？

客戶端顯示的延遲通常是從本機到測試網址完成一次 HTTP 請求所需的時間。它可以反映節點是否可達與基本回應速度，但無法完整代表下載頻寬、尖峰時段壅塞、丟包率，或目標網站與出口伺服器之間的線路品質。

如何解讀常見測試結果

50 至 120 毫秒：互動回應通常較快，仍需搭配實際網站測試。
120 至 250 毫秒：一般網頁可以使用，影片拖曳與即時通訊可能出現明顯等待。
超過 500 毫秒：可能存在壅塞、繞路或丟包，建議更換節點後重新測試。
Timeout：測試網址未在逾時時間內回應，不一定代表所有目標都無法存取，但應視為異常訊號。

連續點擊延遲測試也可能造成數值波動。較穩妥的方法是間隔 10 至 20 秒測試兩次，再透過實際下載或播放影片驗證。對於遠距離節點而言，150 毫秒但沒有丟包的連線，實際體驗可能比延遲 80 毫秒卻頻繁抖動的連線更好。

七、可以連線至節點，但網站提示解析失敗怎麼辦？

節點可連線只代表代理伺服器位址能夠建立連線，網域解析仍可能失敗。常見情況包括日誌出現 no such host、瀏覽器提示找不到伺服器、IP 位址可以存取但網域無法開啟。此時應檢查 Clash DNS 是否啟用、nameserver 是否可達，以及系統中是否還有其他 DNS 工具同時接管請求。

Clash Meta 常用的 DNS 增強模式包括 fake-ip 與 redir-host。Fake-IP 會先向應用程式回傳對應位址，再由核心保留網域資訊並執行規則比對，通常更適合 TUN 與精確的網域分流；部分區域網路裝置、遊戲或特殊解析流程不相容時，可以透過 fake-ip-filter 排除對應網域。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

八、系統代理與 TUN 模式有什麼差異？

系統代理適合會讀取 HTTP 或 SOCKS 代理設定的應用程式，例如多數瀏覽器與桌面軟體。部分遊戲、命令列程式、商店應用程式以及使用 UDP 的程式不會遵循系統代理，這時才需要考慮 TUN 模式。TUN 會建立虛擬網路介面，由核心接管更廣泛的 TCP 與 UDP 流量。

項目	系統代理	TUN 模式
接管範圍	遵循系統代理的應用程式	經過虛擬網卡的系統流量
權限要求	通常只需一般使用者權限	通常需要管理員權限或 VPN 授權
UDP 支援	取決於應用程式與 SOCKS 的使用方式	由核心與節點協定共同決定
排障複雜度	較低	需要檢查路由、DNS 與虛擬網卡

新手應先使用系統代理完成基本連線，再啟用 TUN。Windows 首次啟用可能需要安裝虛擬網卡服務並授予管理員權限；Android 與 iOS 會顯示系統 VPN 授權提示，同一時間通常只能有一個應用程式占用 VPN 介面。若另一個 VPN 正在執行，Clash 的 TUN 或行動裝置 VPN 服務可能無法啟動。

九、訂閱更新會覆蓋手動選擇與自訂規則嗎？

更新訂閱通常會重新下載遠端設定。直接寫入訂閱產生檔案中的規則、DNS 或代理群組可能會被新內容覆蓋，因此不適合長期手動修改。若客戶端提供「覆寫」、「Mixin」、「擴充設定」或「設定預處理」功能，應將本機固定設定放入對應入口，再讓客戶端於每次更新後進行合併。

建議保留的更新流程

在「設定」頁面記錄目前使用中的設定名稱與最後更新時間。
執行更新後先進行設定檢查，不要立即刪除舊設定。
確認代理群組、節點數量、DNS 與規則都已載入。
測試一個直連目標與一個代理目標，檢查連線頁面中的命中策略。
更新異常時切回上一份可用設定，再檢查訂閱回傳內容。

手動選擇的節點是否保留，取決於客戶端的持久化機制，以及代理群組名稱是否變更。如果服務商將 PROXY 改名為其他名稱，舊選擇無法對應至新群組，就可能恢復為清單第一項。自動更新時間也不宜設定得過短；節點訂閱常見的重新整理間隔為 6 小時或 24 小時，每分鐘更新並沒有實際效益。

十、第一次排障應該按照什麼順序進行？

Clash 連線問題通常涉及設定、核心、連接埠、節點、規則、DNS 與系統接管。按照固定順序檢查，比反覆重新安裝更容易找到原因。每完成一步都要觀察日誌與連線頁面，不要同時更換訂閱、模式、DNS 與客戶端版本。

十分鐘基本檢查清單

確認系統時間：日期、時區與分鐘誤差應正確，時間偏差會影響 TLS 連線。
檢查設定狀態：目前設定已選取，語法檢查通過，且沒有缺少代理群組。
檢查核心：日誌中已顯示監聽連接埠，啟動後沒有立即退出。
檢查連接埠：7890 或目前的 mixed-port 未被其他程式占用。
檢查節點：執行延遲測試，並手動切換至少兩個不同節點。
切換全域模式：用於區分規則問題與節點問題，測試後再恢復規則模式。
檢查系統代理：位址為 127.0.0.1，連接埠與客戶端一致。
檢查 DNS：查看日誌是否出現逾時、解析失敗或循環查詢。
暫時關閉 TUN：先驗證一般系統代理，排除虛擬網卡與路由衝突。
查看日誌原文：記錄發生時間、目標網域、策略名稱與具體錯誤，而不是只記錄「無法連線」。

日誌中的 connection refused 通常表示目標連接埠明確拒絕連線，i/o timeout 或 dial tcp timeout 更常見於網路無法連通、節點壅塞或防火牆丟棄封包，no such host 則優先指向 DNS。看到錯誤後，先確認它發生在本機監聽、代理節點還是最終目標，排查範圍就會明顯縮小。