故障排除 閱讀時間約 12 分鐘

Clash Mac 網速慢怎麼辦？從節點、線路到本機設定逐步排查

從節點品質、出口線路到本機設定逐步排查，涵蓋 DNS 模式、TUN 堆疊與 Wi-Fi 省電干擾，找出 macOS 網速瓶頸。

排查起點：分辨開啟慢、下載慢與間歇性斷線

Clash 顯示的節點延遲，不等於檔案下載速度。開啟網頁需要經過網域解析、建立連線、TLS 交握與傳輸內容；其中任何一個環節延遲，都可能讓人感覺「網速很慢」。先確認症狀，再依序檢查節點、線路與本機設定，比同時修改 DNS、規則和 TUN 更容易找出原因。

常見症狀優先檢查項目比對方式
第一次開啟時停頓，之後載入正常DNS、連線與 TLS 階段比較同一網址第一次與再次請求所需的時間
網頁能開啟，但大型檔案下載持續低速節點頻寬、出口壅塞、目標網站限速使用同一個檔案，切換兩個不同出口節點
每隔一段時間就卡頓自動策略切換、網路漫遊、資源占用固定節點，記錄卡頓時間與連線記錄
瀏覽器正常，終端機很慢或連線失敗終端機是否使用代理明確指定代理參數，測試同一個網址
只有啟用 TUN 後速度變慢路由、DNS 接管、其他網路延伸功能關閉 TUN，只保留明確指定的 HTTP 代理作為對照

建立可重複的測試方式

  1. 暫停雲端硬碟同步、系統更新和其他下載，使用同一台 Mac、同一個網路與同一個目標檔案。
  2. 將目標請求實際使用的策略群組改為手動選擇，固定使用一個節點，避免測試期間自動切換。
  3. 每組測試連續執行 3 次，記錄時間、節點、網路類型、代理方式和結果。第一次測試可能受快取影響，請另外註記。
  4. 每次只變更一個條件。測試結束後還原原始設定，並確認結果能否重現。

第一層：節點品質與實際代理出口

先開啟用戶端的連線清單，找到目前正在存取的網域，查看命中的規則、策略群組與最終節點。介面上選取某個節點，不代表每個請求都會經過它：規則可能指向其他策略群組，也可能命中 DIRECT。各用戶端的介面名稱與入口不盡相同，請以目前用戶端提供的連線詳細資訊為準。

固定節點，排除自動切換的影響

url-test 會依據設定的探測結果選擇節點，fallback 著重依序選取可用節點，load-balance 則依策略分配連線。排查時先使用手動選擇的群組，讓測試請求固定走相同出口。切換節點通常不會將已建立的長連線轉移到新節點，因此請重新發出請求；必要時，只關閉目標應用程式對應的舊連線。

  • 只有一個節點速度慢：優先檢查該節點的負載、頻寬限制或上游路徑，並切換其他節點重新測試。
  • 同一地區的多個節點都慢：接著比較不同地區、不同入口或不同供應路徑，不能只憑節點名稱判斷線路是否獨立。
  • 所有節點只有連到特定網站時速度慢：檢查目標網站的限速、CDN 分配、帳號狀態，以及出口 IP 是否受到存取限制。

分清延遲與傳輸量

低延遲有助於互動操作，但持續下載還會受到壅塞、封包遺失、可用頻寬和遠端服務能力影響。延遲較低的節點，下載大型檔案時仍可能比較慢。測試時請使用同一個可合法存取的檔案來源，不要直接比較不同網站的下載結果，也不要用只有幾 KB 的網頁來判斷頻寬上限。

也要留意單位：下載工具顯示的 MB/s 和寬頻方案標示的 Mbps 不同。以十進位單位換算，10 MB/s 約等於 80 Mbps，實際應用速度還會受到通訊協定開銷影響。這只是單位換算，不代表節點速度保證。

第二層：本機網路到節點，以及節點到目標的線路

代理連線至少包含兩段路徑：Mac 到代理入口，以及代理出口到目標服務。切換節點會同時改變其中一部分，因此也要更換本機網路進行交叉測試。保持節點與目標不變，短暫改用手機熱點比對；若熱點明顯改善，問題較可能出在原本的 Wi-Fi、路由器或網路業者的連線路徑。

使用 curl 確認請求確實經過代理

終端機工具不一定會使用 macOS 系統代理。以下命令會明確指定本機 HTTP 或混合連接埠，並輸出各階段的計時結果。範例使用 127.0.0.1:7890，執行前請先確認用戶端目前的監聽連接埠。輸入的網址應是允許下載、大小適中的 HTTPS 檔案；請勿將簽名網址或訂閱連結貼到公開記錄中。

printf '請輸入測試檔案的 HTTPS 網址：'
read -r TEST_URL
curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --location --output /dev/null --silent --show-error \
  --connect-timeout 10 --max-time 60 \
  --write-out 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$TEST_URL"

speed_download 的單位是位元組／秒。time_starttransfer 是從開始請求到收到第一個位元組的累計時間，並非單獨的伺服器處理時間。透過本機 HTTP 代理存取 HTTPS 時，time_connect 主要反映連上本機代理所需的時間，不能視為連到遠端節點的延遲；後續代理通道與 TLS 階段仍會受到遠端路徑影響。

若目標本身允許直接連線，可以將代理選項替換成 --proxy "" --noproxy "*" 再進行一輪比對。不過，這只會略過 curl 明確指定的代理；若已啟用 TUN，請求仍可能由路由接管。若要真正比較直連，請先關閉 TUN，並確認沒有其他 VPN 接管該流量。

依時段判斷是否壅塞

同一個節點白天正常、晚上持續變慢，而且有線與 Wi-Fi 的表現相近時，通常更應檢查共用線路是否壅塞。分別記錄兩個時段各 3 次的結果，比只測一次更有參考價值。對代理伺服器執行 ping 只能提供有限線索：伺服器可能限制 ICMP，且 ICMP 的路徑與優先順序不一定能反映實際代理連線。

第三層：系統代理、規則與本機負載

在較新版 macOS 中，可前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理」，查看 HTTP、HTTPS 與 SOCKS 設定。不同系統版本的項目名稱可能略有差異。請先確認代理位址是本機監聽位址、連接埠與用戶端設定一致，再檢查是否留有舊用戶端的設定。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
scutil --proxy

若網路服務已重新命名，或目前使用 USB 乙太網路，請將命令中的 Wi-Fi 換成第一個命令列出的實際服務名稱。檢查輸出中的啟用狀態、伺服器位址與連接埠，不要只看用戶端開關的顏色，就判斷系統設定已經寫入。

檢查重複代理與規則誤判

  • 瀏覽器代理擴充功能可能會覆蓋系統代理。測試時請先停用擴充功能，或明確記錄該擴充功能使用的出口。
  • 同時執行兩個具備 TUN、VPN 或流量過濾功能的工具，可能造成路由衝突。驗證時一次只保留一種流量接管方式。
  • 若只有特定網域速度慢，請在連線清單確認是否誤走遠端代理，或原本應透過代理的連線被直連規則攔截。
  • 開啟「活動監視器」觀察 CPU 與網路使用情況。若用戶端或其他程序持續占用資源，請先停止耗用資源的背景工作，再重新測試相同請求。

Clash 是核心與用戶端生態中的名稱，並非所有圖形化用戶端都有相同的覆寫、記錄或服務模式。使用 mihomo 的用戶端，也可能採用不同的權限管理與設定合併方式。修改前請查看實際生效的設定，而不只是訂閱檔案中的原始 YAML。欄位意義可參閱YAML 手冊。

DNS 模式：排查首次開啟緩慢與解析異常

DNS 問題常見的表現包括第一次開啟網頁很慢、部分網域無法連線，或瀏覽器與命令列的結果不一致。mihomo 的 fake-ip 模式會為網域指派對應位址，redir-host 模式則使用實際解析結果。兩者並非單純的「快」與「慢」之分，是否適用取決於應用程式、路由接管方式與 DNS 設定。

先確認解析使用哪條路徑

  1. 執行 scutil --dns，查看系統目前使用的解析器及其作用範圍。VPN 與不同網路介面可能各自提供解析器。
  2. 確認瀏覽器是否啟用了獨立的安全 DNS。瀏覽器解析正常，不代表系統解析與用戶端內建 DNS 也正常。
  3. 在用戶端記錄中檢查解析逾時、上游無法連線或重複重試等情況。若上游 DNS 本身依賴尚未建立的代理，可能造成啟動依賴問題。
  4. 只針對一個受影響的網域重複測試，再比較切換網路前後的結果，不要同時更換所有上游伺服器與模式。

透過 HTTP 代理存取 HTTPS 時，目標網域通常會交由代理端處理，因此 curl 在本機測得的解析時間，不能直接代表目標網域的 DNS 效能。同樣地，dig 預設測試的解析路徑，也未必等同於瀏覽器、系統解析 API 或 mihomo 內部使用的解析路徑。

TUN 堆疊與 Wi-Fi 省電：逐一驗證單一變數

TUN 堆疊選擇與路由檢查

TUN 透過虛擬網路介面接管 IP 流量，不會直接增加節點頻寬。mihomo 提供的堆疊選項包括 system、gvisor 和 mixed，實際支援情況與預設值請以用戶端搭載的核心及其文件為準。不同堆疊會影響通訊協定處理方式、相容性與資源開銷，沒有適用於所有 Mac 的固定最佳選項。

先記錄目前使用的堆疊，再只切換堆疊選項，依照用戶端要求重新啟用 TUN 或重新啟動核心，並重新測試同一個請求。以下僅展示要比較的欄位，並非完整設定；請勿用它覆蓋既有的 TUN、DNS、路由或權限設定。

tun:
  enable: true
  stack: system

若明確指定 HTTP 代理時正常、使用 TUN 時異常，應優先檢查路由迴圈、DNS 接管與其他網路延伸功能。不要一開始就隨意調整 MTU。只有在特定目標出現大型封包傳輸停滯、交握後卡住等跡象時，才依照核心文件逐項測試。啟用自動路由前，也應確認是否需要存取區域網路裝置與工作用 VPN。

分辨 Wi-Fi 干擾與低耗電模式

Mac 的低耗電模式不是「代理限速開關」，不能因此認定 Clash 下載速度變慢。可將它列為測試變數：前往「系統設定」→「電池」查看低耗電模式，接上電源後，在相同位置、使用同一節點分別記錄結果。選項名稱與適用範圍會因機型和系統版本而異，不能只憑一次變化就認定兩者有因果關係。

  • 按住 Option 鍵並點選選單列中的 Wi-Fi 圖示，可查看系統提供的訊號、雜訊與傳輸速率資訊；這些是無線連線指標，不等於網際網路下載速度。
  • 靠近路由器重新測試，並在條件允許時比對有線連線。若有線正常、Wi-Fi 異常，請優先處理訊號、干擾與漫遊問題。
  • 分別測試 5 GHz 與 2.4 GHz 網路。前者在隔間較多的環境中不一定更穩定，應以目前位置的多次測試結果為準。
  • 若只有從睡眠狀態喚醒後才變慢，請重新連線 Wi-Fi，再檢查用戶端的代理與 TUN 狀態；不要長期透過反覆重新安裝來掩蓋問題。

歸納結果並還原設定

排查的目標應是得到可重現的結論，而不是「改過很多設定」。例如：「固定同一節點與檔案時，有線正常、Wi-Fi 持續低速」，足以將重點轉向無線網路；「關閉 TUN 後，明確指定代理的連線正常」，則能將範圍縮小到本機流量接管路徑。結論越具體，後續處理就越不需要靠猜測。

  1. 節點問題：更換出口，並向服務提供者提供時間、節點與目標資訊；請隱去帳號、訂閱網址與驗證參數。
  2. 線路問題：保留不同接入網路與不同時段的比對結果，區分本機接入壅塞與出口到目標之間的異常。
  3. 本機問題：只保留已確認有效的變更，還原暫時調整過的堆疊、DNS、策略群組與省電設定。
  4. 仍無法定位：提供用戶端名稱、核心類型、macOS 環境、代理方式與已去識別化的記錄，避免只提交一張延遲截圖。

更換用戶端有助於確認圖形介面設定或權限差異，但不會自動改變訂閱節點的容量。先找出瓶頸，再決定要調整規則、修正本機設定，還是更換出口線路。

下載Clash