Clash 速度慢怎麼辦：節點、線路與本機設定三層排查

先確認「速度慢」具體發生在哪裡

Clash 顯示已連線，但網頁開啟緩慢、影片頻繁緩衝或下載速度偏低，不一定都是節點效能問題。完整連線包含本機應用程式、Clash 核心、DNS 解析、代理節點、電信業者線路與目標網站。任何一段發生壅塞，都可能在 iPhone 上呈現為「開啟 Clash 後反而變慢」。

排查前先固定變數。選擇同一個 Wi-Fi、同一個測速網站、同一個瀏覽器與同一個代理節點，每輪測試至少持續 30 秒，連續進行 3 次。不要同時切換節點與網路，否則無法判斷改善來自哪個變更。

記錄四組基準資料

例如，直連下載速度為 280 Mbps，開啟代理後穩定在 85 Mbps，表示瓶頸位於代理線路或節點。若直連本身只有 18 Mbps，代理通常無法突破目前接入網路的上限。若測速速度正常，但網頁首次開啟需等待 3 至 5 秒，應優先檢查 DNS，而不是繼續測試頻寬。

第一層：檢查節點本身的負載與協定

先在 Clash 的策略組頁面確認目前實際選取的節點。使用「自動選擇」或「故障轉移」策略組時，首頁顯示的組名不等於最終出口節點；應進入「代理」或「策略」頁面，展開對應策略組查看實際選取的節點。

使用固定檔案測試持續吞吐量

1. 維持目前節點不變，關閉正在進行的雲端同步、系統更新與影片播放。
2. 選擇一個可重複存取的 100 MB 至 500 MB 測試檔案，觀察 30 秒後的穩定速度。
3. 等待 2 分鐘後重複兩次，記錄最低值、中位數與最高值。
4. 只切換節點，不修改 DNS、規則模式或本機網路，再完成相同測試。

如果某個節點三輪結果分別為 72 Mbps、69 Mbps、74 Mbps，表示表現穩定。若結果在 8 Mbps、91 Mbps、17 Mbps 之間劇烈波動，常見原因是節點負載過高、上游頻寬共享或封包遺失。此時繼續調整本機規則通常不會有明顯效果。

節點協定與裝置效能

不同協定的加密、封裝與傳輸方式會占用不同程度的 CPU。較新的 iPhone 通常能輕鬆處理常見的 Shadowsocks、Trojan、VLESS 與 WireGuard 流量，但舊裝置在高頻寬、複雜加密或持續發熱時可能降頻。測試時可開啟 iOS「設定」→「電池」，查看 Clash 用戶端在測速期間是否持續占用較高電量，並確認裝置沒有明顯發熱。

• 只有單一節點速度慢：優先判斷為節點負載、節點出口或節點設定問題。
• 同一地區的所有節點都慢：可能是該地區的入口、出口或電信業者互聯壅塞。
• 所有協定都慢：繼續檢查中間線路與本地網路。
• 只有某一種協定速度慢：檢查該協定的傳輸參數、UDP 支援與伺服器設定。

第二層：區分節點問題與中間線路問題

從 iPhone 到代理節點之間，還要經過家用路由器、寬頻電信業者、行動網路與跨網互聯。節點本身閒置，不代表你到節點的線路順暢。最簡單的區分方法，是維持節點不變，只切換接入網路。

完成 Wi-Fi 與行動網路交叉測試

1. 在 Wi-Fi 下選擇一個固定節點，完成三輪延遲與下載測試。
2. 關閉 Wi-Fi，使用 4G 或 5G，再測試同一個節點。
3. 如果行動網路明顯較快，請重新啟動數據機與路由器，並檢查寬頻在尖峰時段的表現。
4. 如果 Wi-Fi 較快，請檢查行動網路訊號、流量限速與目前基地台負載。

例如，同一個節點在家用 Wi-Fi 下延遲 240 ms、下載 12 Mbps，在 5G 下延遲 96 ms、下載 83 Mbps，通常不是節點整體故障，而是家用寬頻到該節點的路徑較差。反過來，如果兩種網路都穩定在約 10 Mbps，而直連分別達到 200 Mbps 與 150 Mbps，則節點端受限的可能性較高。

辨識尖峰時段與持續性封包遺失

線路壅塞常在當地時間 20:00 至 23:00 集中出現。可以在上午、下午與晚間各進行一次相同測試。如果白天穩定、晚間突然下降，不必頻繁修改設定，先切換入口地區或不同電信業者線路通常更有效。

延遲偶爾從 80 ms 跳到 180 ms，不一定會影響下載；如果每隔幾秒就發生逾時，影片、語音與遊戲會更容易卡頓。部分用戶端只顯示成功請求的延遲，逾時節點看起來可能仍有正常數值，因此還要觀察連線記錄中是否連續出現 timeout、connection reset 或 context deadline exceeded。

檢查家用路由器與 Wi-Fi

• 優先使用 5 GHz 或 6 GHz Wi-Fi，避免擁擠的 2.4 GHz 頻道。
• 靠近路由器重新測試，排除牆壁遮蔽與訊號微弱造成的重傳。
• 暫時關閉路由器上的二次代理、家長監護與流量整形，避免重複處理。
• 確認區域網路中沒有裝置正在上傳照片、同步雲端硬碟或下載大型更新。
• 如果路由器與 iPhone 都執行代理，測試時只保留一層，避免流量被重複轉送。

第三層：檢查 Clash 本機設定

當多個節點、不同接入網路都偏慢時，再檢查 Clash 的本機設定。重點不是一次修改十個開關，而是每次只改一項，重新測試後再決定是否保留。

先比較規則模式與全域模式

在用戶端的「代理」或「模式」頁面，將 Rule 暫時切換為 Global，維持同一個節點完成測試。如果全域模式明顯較快，表示規則模式可能讓測速網域走 DIRECT、選到另一個策略組，或套用不合適的規則。測試完成後應切回 Rule，再查看連線記錄中的規則命中結果。

規則會由上到下進行比對，命中後便不再繼續。網域規則、規則集與 GEO 類規則的順序不合理，可能導致目標網站選錯出口。下載網站的網域直連，但其資源網域經過代理，也會出現頁面開啟正常、檔案下載緩慢的情況。

精簡高頻率健康檢查

節點健康檢查不會直接占滿頻寬，但數量很多、間隔過短時，會持續喚醒網路延伸功能並產生額外連線。包含 80 個節點的策略組若設定為每 30 秒檢查一次，每小時可能產生 9600 次請求。日常使用可先將 interval 調整為 600 秒，規則提供者的更新間隔可設定為 86400 秒。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點 A
      - 節點 B
      - 節點 C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

rule-providers:
  common:
    type: http
    behavior: classical
    path: ./ruleset/common.yaml
    url: https://example.com/rules/common.yaml
    interval: 86400

這裡的測試網址應選擇穩定、回傳內容很小且目前網路可存取的 URL。不要同時為多個大型策略組設定 30 秒或 60 秒的檢查間隔。若用戶端提供「設定」→「參數設定」→「健康檢查」路徑，可先關閉不使用策略組的自動測試。

檢查 TUN 模式與 MTU

TUN 模式會接管更多系統流量，適合需要透明代理的應用程式，但錯誤的 MTU 可能造成分片、重傳或部分網站載入緩慢。常見測試值為 1500、1400 與 1280。不要一次跨越多個數值；先記錄目前設定，再改為 1400 重新測試。如果問題只出現在行動網路或特定 WireGuard 線路，可繼續測試 1280。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

這種寫法適用於支援 Clash.Meta 或 mihomo 設定語法的用戶端，舊版 Clash 核心未必支援所有欄位。iOS 用戶端也可能將這些選項放在圖形介面的「設定」→「參數設定」→「TUN」中。修改後應中斷並重新建立系統 VPN，讓網路延伸功能重新載入設定。

確認沒有重複代理

iOS 通常只允許一個主要 VPN 設定同時啟用，但瀏覽器代理、路由器代理與 Clash 仍可能形成多層轉送。進入 iOS「設定」→「一般」→「VPN 與裝置管理」→「VPN」，確認目前連線的是預期的用戶端。再開啟「設定」→「Wi-Fi」→目前網路→「設定代理伺服器」，日常由 Clash 接管時通常應保持「關閉」。

分開處理 DNS 慢與頻寬慢

DNS 主要影響網域解析與首次連線。典型表現是：輸入網址後等待數秒，但頁面一旦開始載入，圖片與影片速度正常。若大型檔案開始下載後仍長時間只有幾百 KB/s，單獨更換 DNS 通常無法解決持續性的頻寬瓶頸。

透過 IP 與網域表現判斷

• 所有網站首次開啟都很慢，重新整理後變快：優先檢查 DNS 逾時與快取。
• 只有特定網域速度慢：檢查該網域的規則命中、IPv6 結果與 CDN 路徑。
• 測速網站延遲正常但下載速度低：回到節點與線路層排查。
• 記錄反覆出現 DNS timeout：切換可存取的 nameserver，並檢查監聽位址。

支援 mihomo 語法的設定可以先採用一組簡單的 DNS 設定進行比較。以下範例啟用 fake-ip，主要解析使用兩個明確的 DNS 伺服器，並避免同時堆疊過多 fallback。不同網路對公共 DNS 的可達性不同，應以目前地區的實測結果為準。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 223.5.5.5
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

1053 是 Clash DNS 常用的本機監聽連接埠範例，不是外部 DNS 服務的連接埠。若用戶端已自動管理 DNS，不要再讓另一套本機服務占用相同連接埠。修改前可在「設定」→「參數設定」→「DNS」儲存目前值，測試結束後再依結果決定是否恢復。

單獨測試 IPv6

部分網路能回傳 AAAA 記錄，但實際 IPv6 路徑品質較差，表現為網站先等待，之後退回 IPv4。可暫時將 dns.ipv6 設為 false 進行比較。如果關閉後首次開啟速度明顯改善，表示需要繼續檢查本機 IPv6、節點 IPv6 支援或目標網站的 IPv6 路徑，而不是長期把所有問題歸因於節點。

根據結果選擇下一步

完成三層測試後，應根據比較資料處理，而不是繼續隨機切換設定。以下對照關係可以快速縮小範圍。

使用最小設定進行最終隔離

如果問題仍無法定位，可以建立一份只包含 1 個節點、1 個策略組與 2 條規則的臨時設定。監聽連接埠使用常見的 7890，關閉腳本、規則提供者、流量嗅探與額外健康檢查，只保留必要功能。最小設定正常，表示原設定中存在衝突或額外負擔；最小設定仍然很慢，則應回到節點、線路或裝置層繼續處理。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 測試節點

rules:
  - MATCH,PROXY

測試完成後，不要直接將臨時設定當作長期設定。它的作用是隔離變數，不包含日常需要的直連、區域網路、隱私與應用程式分流規則。確認原設定的問題範圍後，再逐組恢復 DNS、規則集、TUN 與健康檢查，每恢復一項就進行一次相同測試。

排查時常見的三個誤區

只看節點延遲

延遲適合篩掉無法連線或回應明顯過慢的節點，但不能代表頻寬、封包遺失與尖峰時段負載。至少加入一次持續 30 秒以上的下載測試。

同時修改 DNS、MTU 與規則

一次修改多個項目，即使速度恢復，也無法知道是哪一項生效。正確做法是先儲存原設定，每次只改一個變數，並記錄修改前後的三輪結果。

把全域模式長期當作加速開關

全域模式適合用於比較測試，它會讓更多流量經過同一個代理，並不代表一定更快。確認是規則命中問題後，應修正规則或策略組，再回到 Rule 模式。