Clash 效能與電量最佳化清單

一個只是在幫你轉送瀏覽流量的代理用戶端，本來應該接近感覺不到。感覺得到，通常是某一件具體的事在燒資源，而不是它整體需要調校。所以在改任何設定之前，先量一遍。沒有基準的調校不叫調校，叫重新裝潢設定檔。

先量一遍，再決定要不要動

• Windows：工作管理員的「詳細資料」頁。找核心程序——一般叫 mihomo，也可能用用戶端的名字，還可能兩個都在，因為介面和核心本來就是兩個程序。看 CPU 和記憶體。
• macOS：活動監視器，除了 CPU 那一欄，也看「能源」頁。能源影響這一欄比 CPU 百分比更接近電池的真實感受。
• Linux：top 或 htop 依核心程序名稱過濾；用 systemd 跑的話，systemctl status 也會回報這個單元的記憶體占用。

什麼算正常：沒有流量經過的時候，CPU 應該貼著零偶爾跳一下。記憶體跟節點數量、活躍連線數有關，幾十到幾百 MB 都不稀奇。真正值得看的是趨勢——機器放著不動一個小時，記憶體還在往上爬，這才是個發現；截圖上一個孤零零的高數字不是。

真正在燒資源的，按影響排序

1. 自動測速。第一名，而且甩開後面一大截。一個 url-test 群組，interval 寫 60，組裡掛著四十個節點，就是每分鐘四十次完整的 HTTP 請求，每次都要建立連線和交握。改到 300 到 600 之間，日常用起來你察覺不出差別。
2. 節點數量。上千條的訂閱，清單繪製、健康檢查、連線頁面的比對，樣樣都按這個量級跑，而你實際會用的可能就十幾個。用 provider 或策略群組的 filter 把用不到的擋在視野之外。
3. 日誌等級。長期開著 debug，既吃 CPU 又一直在寫磁碟，日誌檔還會一路長大。日常放在 info 或更安靜的等級，要查問題的時候再臨時調高。
4. TUN 模式。它比系統代理多一層封包處理。桌面上這點差別淹沒在雜訊裡，手機上感覺得出來。為了省電退回系統代理，只有在你本來就不需要接管全部流量時才划算。
5. 連線堆積。幾天不清的連線清單一直占著記憶體，幾千列的表格畫起來也不便宜。定期清一次，別把那一頁當成預設停留的畫面。

proxy-providers:
  my-sub:
    type: http
    interval: 86400
    health-check:
      enable: true
      interval: 600
      lazy: true
proxy-groups:
  - name: Auto
    type: url-test
    interval: 600
    lazy: true

上面這段裡有個坑值得點出來：interval 出現了兩次。策略群組自己有一個，provider 的健康檢查也有一個。你把組裡的間隔拉長一倍，provider 還在按自己那份短間隔安靜地測，等於白改。兩處都要看。lazy 是被忽略的另一半——打開之後，目前沒有流量經過的群組根本不測，那些你留著但很少選的地區群組會徹底安靜下來。這筆帳很好算：四十個節點、間隔 60 秒，一小時 2400 次測試請求；間隔 600 秒，240 次。

手機：電量是另一本帳

先接受一件事。要轉送流量的 App 必須在背景活著，這部分最佳化不掉。想讓它不執行又能轉送，這不是設定問題。你能減少的是它待在那裡的時候做了多少事。

• 自動測速。手機上這是最大的一項。直接關掉，或者把間隔推到十分鐘以上。你切換節點的頻率根本沒那麼高。
• 訂閱自動更新。一天一次足夠，有的用戶端預設是一小時一次。
• 分應用代理——名字各家不一樣，一般叫「應用代理」或「分應用」，各平台能力也不同。只讓需要的 App 走代理，其餘走直連，它們的流量根本不經過這個程序。這是清單裡最實在的一條。
• IPv6。網路本來就不用它的話，把相關解析關掉，每個網域少一次查詢，還少掉一批注定連不上的嘗試。

有個選項很多人沒讀清楚就按了：把用戶端加進電池最佳化白名單。那個設定的用途是讓系統別殺它，代價剛好是讓它在背景更自由地做事。它跟省電是反著的。你是在用電量換連線穩定，這筆交易通常划算——只是要清楚自己換的是什麼。

想知道它到底費不費電，打開系統的電池用量頁面按 App 排序看一眼。很多人一口咬定是代理軟體在耗電，翻開一看第一名是螢幕，用戶端排在第七。憑感覺調校，調的多半是心情。

桌面端：這幾件事幫不上忙

開機自動啟動、服務模式，以及各種名字裡帶「效能」的開關，改善的是使用便利或權限問題，沒有一個能降低資源占用。裝了服務元件不會讓 CPU 降下來，它只是讓 TUN 不用每次都要系統管理員權限。想讓機器涼快點，有用的全在上面那張清單裡。