第一次使用 Clash 最常見的十個問題：節點、模式、連接埠一次講清楚

一、Clash 裡的節點從哪裡來

直接結論：Clash 用戶端負責讀取設定、執行分流與建立代理連線，本身不會產生節點。節點通常來自服務提供者提供的訂閱網址，也可以由使用者手動寫入 YAML 設定。

一份可用的設定通常包含代理節點、策略群組、規則和 DNS 設定。只有節點清單而沒有策略群組時，介面可能看得到伺服器，卻無法用「自動選擇」「故障轉移」等方式切換；只有規則而沒有節點時，代理規則也沒有可用的出口。

訂閱網址和一般網頁連結的差別

• 訂閱網址通常由服務提供者產生，複製後應貼到用戶端的設定匯入欄位。
• 訂閱網址可能回傳 Clash YAML，也可能回傳 Base64 節點清單；後者需要用戶端支援相應格式，或先交由可信任的服務轉換。
• 瀏覽器能開啟連結，不代表格式一定能被 Clash 識別。若開啟後看到登入頁、方案頁面或 HTML 錯誤頁面，就不是有效的設定內容。
• 訂閱網址通常帶有身分驗證參數，應視同帳戶憑證保管，不要放在截圖、論壇或公開程式碼儲存庫中。

匯入後還要在設定清單中選取剛加入的設定。以 Clash Verge Rev 2.x 常見介面為例，路徑通常是「訂閱」→「新增」→貼上 URL →「儲存」，接著返回訂閱清單並點選對應設定。不同用戶端可能將「訂閱」寫成 Profiles、設定或設定檔，但流程都是「新增、更新、選取」三個步驟。

二、訂閱匯入成功後，為什麼還是不能使用

直接結論：「匯入成功」只代表用戶端取得了設定，不代表節點已選取，也不代表系統流量已交由 Clash 處理。新手最容易漏掉後面兩個步驟。

依序確認這四項

1. 設定已啟用：設定清單中的目前項目應呈現選取狀態，而不是只出現在歷史紀錄裡。
2. 策略群組已有選擇：進入「代理」或 Proxies 頁面，確認主要策略群組不是空白，並選取一個可用節點或自動測速群組。
3. 執行模式不是直連：排查期間可以先使用規則模式，不要誤選 Direct 或直連模式。
4. 流量入口已開啟：一般瀏覽器通常需要開啟系統代理；不遵循系統代理的應用程式則可能需要 TUN。

也可以查看執行記錄。若造訪網站時完全沒有新增記錄，表示請求沒有進入 Clash，應檢查系統代理、瀏覽器獨立代理、TUN 或連接埠設定；若記錄中出現請求，但顯示 timeout、connection refused 或 DNS 錯誤，才需要繼續檢查節點、網路和 DNS。

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

直接結論：日常使用優先選規則模式；全域模式適合暫時排查分流問題；直連模式可暫停代理轉送，但流量通常仍會經過 Clash 核心。

規則模式的核心是「由上到下，第一條符合即套用」。例如網域先符合 DOMAIN-SUFFIX 規則後，後面的 MATCH 就不會再處理它。設定末尾常見的 MATCH 是兜底規則，用來接住前面未符合的連線。

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

如果某個網站在全域模式下可用、在規則模式下卻無法使用，節點本身通常沒有問題，重點應放在規則套用結果。開啟連線記錄，查看目標網域最後是走 DIRECT、某個代理群組，還是 REJECT，再更新設定或調整對應規則。

四、7890 連接埠是什麼？必須一直使用預設值嗎

直接結論：7890 是許多 Clash 設定常用的本機代理連接埠，但不是所有用戶端都強制統一使用的固定值。它可能設定為 mixed-port，也可能只對應 HTTP 代理，實際數值應以目前用戶端的執行設定和 YAML 設定為準。

9090 不是讓瀏覽器填寫的代理連接埠。若誤將瀏覽器代理設為 127.0.0.1:9090，通常只會得到連線失敗。使用混合連接埠時，代理位址一般是 127.0.0.1:7890；若用戶端顯示其他連接埠，就應使用介面中目前生效的數值。

連接埠被占用時怎麼處理

當記錄出現 address already in use、bind failed 或「連接埠被占用」時，先退出其他代理工具，再重新啟動 Clash。仍有衝突時，可在「設定」→「參數設定」或「設定」→「連接埠設定」中，將混合連接埠改為 7892、7893 等未被占用的連接埠，然後重新開啟系統代理。若曾手動為瀏覽器設定代理，也要同步修改瀏覽器連接埠。

修改連接埠後，不要只看開關狀態。可以在記錄中確認本機監聽已啟動，或檢查用戶端首頁是否顯示 HTTP、SOCKS、Mixed 入口的實際連接埠。系統代理自動設定功能通常會跟著新連接埠更新，手動設定則不會自動變更。

五、系統代理已開啟，為什麼網站還是打不開

直接結論：先判斷請求是否進入 Clash，再判斷進入後卡在哪個步驟。系統代理開關亮起只是起點，節點無法使用、規則走直連、DNS 失敗，以及瀏覽器覆蓋系統設定，都可能造成「開啟後仍無法連線」。

五分鐘排查流程

1. 開啟用戶端記錄或連線頁面，清除目前的篩選條件。
2. 在瀏覽器中造訪目標網站，觀察是否出現對應網域。
3. 沒有記錄時，關閉瀏覽器內單獨安裝的代理擴充功能，並確認代理位址為 127.0.0.1，連接埠與用戶端一致。
4. 有記錄但套用 DIRECT 時，暫時切換至全域模式進行比對。全域模式可用，表示應檢查規則。
5. 記錄顯示 timeout 時，換一個延遲正常的節點，並測試本地網路能否存取一般網站。
6. 記錄顯示 DNS error、no such host 或解析逾時時，應檢查 DNS 設定，而不是繼續反覆切換連接埠。

Windows 還應留意系統代理是否被其他軟體改寫。常見檢查路徑是「設定」→「網路和網際網路」→「代理伺服器」。若 Clash 正在自動管理系統代理，手動代理位址一般會指向本機回送位址。退出用戶端前應先關閉系統代理，避免作業系統繼續將請求送到已停止監聽的 7890 連接埠。

macOS 可在「系統設定」→「網路」→目前網路→「詳細資訊」→「代理伺服器」查看狀態。通常不需要同時手動勾選多個協定，再讓用戶端重新接管；重複設定可能造成連接埠不一致。優先讓用戶端的「設為系統代理」功能統一管理。

六、節點延遲多少才算正常？數字越小就一定越快嗎

直接結論：延遲反映測試請求往返所需的時間，不直接等於下載速度。日常瀏覽網頁時，50 至 150 毫秒通常反應較快，150 至 300 毫秒仍可使用；持續超過 500 毫秒或顯示 timeout，才值得優先更換節點。

這些數值不是固定的品質門檻。不同地區、電信業者、Wi-Fi 訊號和測試網址都會顯著影響結果。例如同一個節點對某個測試 URL 是 92 毫秒，對另一個網址可能是 180 毫秒；晚間尖峰也可能從 110 毫秒升至 260 毫秒。應連續測試兩到三次，並結合實際開啟網頁、播放影片和下載檔案的表現判斷。

延遲低但速度慢的常見原因

• 節點到測速網址的路徑較短，但通往實際目標網站的線路壅塞。
• 伺服器端可用頻寬有限，建立連線很快，但持續傳輸速度不高。
• 本地 Wi-Fi 丟包，延遲偶爾正常，但連線穩定性不佳。
• 策略群組顯示的是上一次的快取結果，節點目前狀態已經改變。
• UDP、影片分段或大型檔案傳輸所採用的路徑，與一般 HTTP 延遲測試不同。

自動選擇群組通常會根據定期 URL 測試挑選延遲較低的節點；故障轉移群組則更重視目前節點是否可用。前者適合日常選擇，後者適合維持連線不中斷。不要把測試間隔設得太短；每 300 至 600 秒檢查一次通常已經足夠，每隔幾秒測試一次只會產生額外請求。

七、系統代理和 TUN 模式有什麼差別

直接結論：系統代理依賴應用程式主動讀取作業系統的代理設定；TUN 模式則透過虛擬網卡接管更多 IP 流量。瀏覽器和大多數桌面軟體通常能使用系統代理，遊戲、命令列程式、部分商店應用程式，以及使用自訂網路堆疊的軟體，可能需要 TUN。

第一次使用時，建議先讓系統代理穩定運作，再考慮 TUN。以採用 Mihomo 1.19.x 設定語意的用戶端為例，TUN 常見設定包括 enable、stack、auto-route、auto-detect-interface 和 DNS 劫持。圖形用戶端通常在「設定」→「系統設定」→「服務模式」安裝背景服務，然後在「設定」→「網路」或首頁開啟 TUN。

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

stack: mixed 是兼顧相容性的常見選擇；若特定系統出現連線問題，可依用戶端說明測試 system 或 gVisor。不了解現有設定時，不要整段覆蓋訂閱中的 TUN 和 DNS 項目，因為訂閱可能已提供適用的參數。

八、為什麼瀏覽器能用，遊戲、終端機或商店應用程式卻不走代理

直接結論：這些程式可能沒有讀取系統代理，或使用 UDP、自訂 DNS、QUIC 等不同的網路方式。瀏覽器可用已表示節點和基本代理入口大致正常，下一步應檢查程式流量是否進入 Clash。

命令列工具通常有獨立的代理變數。例如只想讓目前的終端機工作階段使用本機 HTTP 代理，可以依工具支援情況設定 HTTP_PROXY 和 HTTPS_PROXY；支援 SOCKS5 的程式則可指定 127.0.0.1:7890 或用戶端顯示的 SOCKS 連接埠。變數名稱和代理協定必須與程式文件一致，不能假設所有工具都會讀取系統設定。

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890

遊戲和部分商店應用程式經常使用 UDP，一般 HTTP 系統代理無法直接承載這類流量。此時應先確認節點支援相應傳輸，再開啟 TUN，並在連線清單中檢查目標 IP、協定和套用的策略。若開啟 TUN 後仍沒有記錄，應檢查虛擬網卡、路由排除項目，以及應用程式是否使用了另一張網路介面。

還要注意，「全域模式」只決定已進入 Clash 的連線如何選擇出口，不負責把所有程式強制送入核心。因此，將模式從規則改成全域，不能取代系統代理或 TUN。這是新手最容易混淆的兩個層級：流量入口決定「是否進入 Clash」，代理模式決定「進入後往哪裡走」。

九、訂閱更新失敗、404 或逾時，分別該怎麼處理

直接結論：404 多半與連結本身或帳戶狀態有關，逾時則更可能是網路路徑、伺服器回應或代理更新設定造成。先依錯誤類型處理，不要立刻刪除目前仍可使用的設定。

看到 404、401 或 403

• 404：訂閱路徑不存在、連結已更換，或伺服器回傳統一錯誤頁面。請重新從服務提供者的控制台複製最新網址。
• 401：身分驗證參數已失效或缺少，應重新登入帳戶取得訂閱。
• 403：伺服器拒絕目前請求，可能與帳戶狀態、請求頻率或存取來源有關。

看到 timeout 或 connection reset

先用瀏覽器測試訂閱網域是否能建立連線，但不要公開完整訂閱網址。若目前網路無法直接連線至訂閱伺服器，可在用戶端尋找「透過代理更新」「代理訂閱更新」一類的開關；如果伺服器只允許直接取得，則應關閉該選項。兩種方式不要快速來回重試，以免觸發伺服器的頻率限制。

自動更新間隔不宜過短。節點資訊不會每分鐘變動，常見設定是每 1440 分鐘更新一次；需要較快同步時可設為 360 分鐘。設定成 5 分鐘會增加無意義的請求，也可能讓暫時性的網路波動反覆覆蓋狀態。更新失敗時應保留上一次成功的設定，再手動重試。

若更新後設定突然變空，先切回上一份本機紀錄，並檢查回傳內容是否為 HTML 登入頁、錯誤 JSON 或不相容格式。用戶端提示 YAML parse error 時，可查看錯誤行號；縮排、冒號後的空格、重複鍵名，以及未閉合的引號，都可能導致解析失敗。

十、第一週怎麼設定最穩妥？出現問題又該如何復原

直接結論：保持設定簡單，先使用規則模式、一個主要策略群組和系統代理；確認瀏覽器穩定後，再啟用自動測速、TUN、自訂 DNS 或腳本。每增加一項功能，都要進行一次實際存取驗證。

適合新手的基本狀態

• 目前設定已明確選取，並保留一份最近可用的本機紀錄。
• 執行模式使用規則模式，主要代理群組手動選取一個已驗證的節點。
• 混合連接埠使用用戶端自動管理的數值，例如 7890。
• 系統代理由用戶端開關管理，不要在瀏覽器中重複疊加擴充功能。
• 自動更新間隔設為 360 至 1440 分鐘。
• 日常使用時，記錄層級設為 information；只有排查問題時才暫時切換至 debug。
• 只有確有需要時，才逐項開啟 TUN、腳本覆寫和自訂 DNS。

設定弄亂後，依這個順序復原

1. 關閉 TUN、腳本和手動覆寫，只保留原本的訂閱設定。
2. 切換回規則模式，選取一個測試確認可用的節點。
3. 檢查本機混合連接埠，確認沒有連接埠衝突。
4. 先關閉再重新開啟系統代理，讓作業系統重新整理代理位址。
5. 用瀏覽器造訪目標網站，同時觀察連線記錄。
6. 基本存取恢復後，再逐一加回自訂設定，每一步都記錄變化。

如果完全退出 Clash 後所有網站都打不開，通常是系統代理殘留。重新啟動用戶端並關閉系統代理，或進入作業系統的網路設定取消手動代理即可。若開啟 Clash 後一般中國大陸網站也變慢，可檢查規則是否將所有請求送到代理群組，以及目前是否誤處於全域模式。

第一週不必同時理解所有設定項目。先分清四個層次即可：訂閱提供設定，節點負責連線出口，系統代理或 TUN 負責接入流量，規則負責選擇出口。大多數「開啟後卻無法連線」的問題，都能沿著這四個層次逐步定位。