在路由器上執行 Clash 核心：旁路由部署方式與資源需求

在路由器上執行 Clash 或 mihomo 核心，重點不是把桌面用戶端介面搬到網路設備，而是讓路由器集中處理規則比對、DNS 解析與流量轉發。電視、遊戲主機、行動裝置，以及其他不便安裝用戶端的終端，都能透過閘道或策略路由套用同一套規則。同時，路由器也會成為轉發鏈路中的關鍵節點；設定錯誤可能影響整個區域網路，因此部署前務必先確認拓撲、回復路徑與設備負載。

本文所稱的「在路由器上執行 Clash」，主要是指在 OpenWrt、衍生系統或通用 Linux 閘道上執行 Clash 相容核心。目前常見的實作以 mihomo 為主，延續 Clash 的設定結構，並提供 TUN、規則集與流量嗅探等擴充能力。不同管理外掛會封裝設定檔、服務腳本與防火牆規則，但底層仍離不開三個環節：核心監聽連接埠、系統將目標流量送入核心，以及核心依規則選擇直連或代理出口。

主路由與旁路由的架構選擇

主路由直接執行核心

主路由方案是讓負責撥號、DHCP、NAT 與無線存取的設備，同時執行 Clash 核心。終端流量本來就會經過這台設備，轉發路徑最短，也較容易統一接管 DNS。對硬體效能充足、系統易於維護，且熟悉防火牆規則的使用者而言，這種方式結構清楚：上游介面連接電信業者網路，下游介面連接區域網路，代理程式只需處理由防火牆導入的流量。

主要代價是故障影響範圍較大。核心耗盡記憶體、防火牆規則載入失敗或 DNS 服務連接埠衝突，都可能同時影響撥號、區域網路解析與管理頁面。系統升級也可能改變 nftables、iptables 或外掛產生規則的方式。因此，主路由部署較適合能透過序列埠、救援模式或備用設備恢復網路的環境，不宜將第一次實驗直接放在唯一的家庭網路出口上。

旁路由作為獨立閘道

旁路由方案保留現有主路由負責撥號與基礎網路，將 Clash 核心放到另一台設備。最常見的單臂旁路由與主路由位於同一個區域網路，例如主路由位址為 192.168.1.1，旁路由位址為 192.168.1.2。需要套用代理規則的終端，將預設閘道指向 192.168.1.2；旁路由完成策略處理後，再將流量轉發給主路由。

這種架構方便分批遷移。可以先只調整一台測試電腦的閘道與 DNS，驗證規則、UDP 與網域解析，再決定是否透過 DHCP 將旁路由下發給更多設備。旁路由停止服務時，終端可將閘道改回主路由，不必變更寬頻撥號設定。維護界線也更清楚：主路由確保基礎連網，旁路由負責透明代理與附加策略。

單臂旁路由不代表只填寫一個閘道位址。若旁路由直接轉發封包而不進行來源位址轉換，回程流量可能由主路由直接傳送給用戶端，形成去程經過旁路由、回程繞過旁路由的非對稱路徑。是否出問題取決於透明代理方式、連線追蹤與主路由路由表。常見處理方式是在旁路由出口執行適當的 NAT，或在主路由新增指向用戶端網段的明確路由，讓往返路徑符合設計。

雙網路埠旁路閘道

具備兩個獨立網路埠的設備，也能部署為串聯閘道：一個介面連接主路由，另一個介面連接獨立的下游交換器或無線存取點。旁路由為下游建立獨立子網路，並負責該子網路的 DHCP、轉發與代理處理。與單臂架構相比，雙網路埠方案的上下游界線清楚，回程流量通常會自然經過旁路由，也更容易針對整個子網路套用策略。

代價是網路層級增加。連接埠轉送、區域網路探索、投放與跨網段存取都需要額外處理；如果主路由與旁路由都執行 NAT，還會形成雙重 NAT。家庭設備若依賴 mDNS 或廣播探索，應評估是否需要中繼服務，而不是把所有跨網段問題都歸因於 Clash 核心。

CPU、記憶體與儲存空間需求

Clash 核心的實際硬體需求，取決於吞吐量、規則規模、連線數量、協定加密負載，以及是否啟用 TUN。不能只根據「核心能啟動」就判斷設備是否適用。路由器還要為系統服務、DNS 快取、防火牆連線追蹤與管理介面保留資源；一旦記憶體耗盡，服務重啟或系統無回應通常比單純降速更難排查。

處理器與加密吞吐量

CPU 決定規則比對、加密傳輸與使用者空間轉發的上限。較舊的單核心 MIPS 設備可以應付精簡規則與少量連線，但在高速寬頻、多個終端或複雜協定下容易成為瓶頸。現代 ARM64 或 x86_64 平台通常更適合長時間執行 mihomo。選擇核心檔案時必須符合系統架構，常見識別名稱包括 arm64、armv7、mipsle 與 amd64；架構選錯時，程式通常會直接回報無法執行。

硬體 NAT 或流量卸載可能繞過透明代理所依賴的防火牆鏈。啟用代理後速度異常時，應先確認軟體流量卸載、硬體流量卸載與透明代理外掛之間的相容性。在追求跑滿介面速率之前，先以單台有線終端測試直連、規則代理與 UDP 三類流量，觀察單核心 CPU 使用率是否持續接近上限。

記憶體與規則規模

64 MB 記憶體的設備通常只適合非常精簡的系統與小型設定；載入大型網域規則、GeoIP 資料、控制面板與多個附加服務後，可用空間十分有限。128 MB 可作為基礎部署起點，但仍需控制規則集與並行服務。256 MB 或以上的記憶體，更適合同時啟用 mihomo、DNS 增強模式、較大型規則集與 Web 管理介面。連線數量多、規則提供者頻繁更新或啟用流量嗅探時，應繼續保留更多餘裕。

Swap 可以緩解短暫的記憶體壓力，但快閃記憶體交換速度較慢，也不能取代足夠的實體記憶體。發現核心週期性退出時，可先查看系統日誌是否出現記憶體回收或程序遭終止的紀錄，再考慮縮減規則、關閉暫時不用的服務，或移轉到資源更充足的設備。

儲存空間與寫入策略

核心本體、GeoIP 資料、規則集、訂閱快取與日誌都會佔用儲存空間。路由器內建快閃記憶體容量較小時，可以將資料目錄放在擴充儲存裝置或外接磁碟，但服務啟動順序必須確保掛載點先準備完成。日誌等級不宜長期維持 debug；詳細日誌適合短時間定位問題，持續寫入不但會佔用空間，也會增加低速快閃記憶體的寫入負擔。

透明代理、TUN 與 DNS 的轉發路徑

路由器部署中最容易混淆的是「核心已執行」與「區域網路流量已進入核心」。mixed-port、HTTP 連接埠或 SOCKS 連接埠只是監聽入口，適合終端手動填寫代理。若要讓未設定代理的設備自動依規則轉發，還需要 REDIRECT、TProxy 或 TUN 等接管方式，以及相應的防火牆與策略路由。

REDIRECT 與 TProxy

REDIRECT 常用於接管 TCP 連線，設定相對直接，但對 UDP 及需要保留原始目標位址的情境有所限制。TProxy 可處理 TCP 與 UDP，並透過策略路由將透明流量送至核心監聽連接埠。它依賴防火牆標記、策略路由表與核心相關模組，任何一環缺失，都可能表現為 TCP 可用但 UDP 逾時，或區域網路存取遭錯誤轉發。

防火牆規則應排除本機管理位址、區域網路保留網段、群播、廣播與代理伺服器自身的連線。否則可能形成代理迴圈：核心建立的對外連線再次被透明規則攔截，最終導致連線失敗或 CPU 使用率升高。外掛通常會產生這些排除項目，但自訂腳本仍應逐項檢查目標網段、程序或防火牆標記。

TUN 模式

TUN 模式透過虛擬網路介面接收 IP 流量，對需要同時處理 TCP、UDP 與複雜應用程式的環境而言更一致。mihomo 的 TUN 設定可啟用自動路由與介面偵測，但路由器平台本身已有 WAN、LAN、策略路由與防火牆區域，自動產生的路由不一定符合現有拓撲。部署時應核對預設路由、TUN 路由表與區域網路轉發鏈，不要只確認設定檔語法通過。

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

這段設定只代表 mihomo 端啟用 TUN、自動路由與 DNS 接管的意圖，不代表路由器防火牆已允許 LAN 流量進入 TUN。不同韌體、外掛與網路管理元件對介面名稱及規則鏈的處理方式各不相同。若管理外掛已負責產生 TUN 設定，再於主設定中重複宣告，可能導致設定被覆寫或產生重複路由。

DNS 請求路徑

當規則依賴網域名稱時，DNS 路徑必須與代理策略一致。常見作法是讓終端將 DNS 請求送至路由器，再由 dnsmasq 或其他本機解析服務轉發至 mihomo 的 DNS 監聽連接埠；另一種作法是透過防火牆接管區域網路的 53 連接埠請求。前者結構容易理解，後者可處理終端手動填寫公共 DNS 的情況，但加密 DNS 應用程式不會經過一般的 53 連接埠。

fake-ip 模式會為網域回傳保留位址，再由核心根據對映還原原始網域，方便套用網域規則。某些區域網路服務、遊戲平台或依賴真實位址判斷的應用程式，可能需要加入 fake-ip-filter。redir-host 模式更接近傳統解析，但在比對效率與特定連線流程上有所不同。切換模式後應清除終端的 DNS 快取，避免舊解析結果干擾測試。

DNS 迴圈是旁路由常見的故障：mihomo 將查詢交給 dnsmasq，而 dnsmasq 又把請求轉回 mihomo。判斷迴圈時，可查看兩個服務的監聽連接埠與上游位址，確保解析鏈只有一個明確方向。旁路由本身的查詢、區域網路用戶端查詢與代理節點網域解析也應分開考量；節點網域必須能在建立代理通道前完成解析。

IPv6 不應遺漏

只接管 IPv4 時，支援 IPv6 的終端可能直接透過主路由取得 IPv6 預設路由，導致部分連線繞過既定策略。可以完整設定 IPv6 轉發與規則，也可以在部署初期暫緩向測試終端下發 IPv6 路由，但最終選擇應符合家庭網路需求。排查「同一個網站有時套用規則、有時直連」時，應分別檢查 A 與 AAAA 記錄、IPv4 與 IPv6 預設路由，以及核心設定中的 IPv6 開關。

旁路由部署步驟與驗證順序

1. 固定旁路由管理位址。

   為旁路由設定與主路由相同網段、且不與 DHCP 位址池衝突的靜態位址，預設閘道指向主路由。先確認旁路由本身可以同步時間、解析網域並存取軟體來源。

2. 安裝符合架構的核心與管理元件。

   確認 CPU 架構、系統 libc 環境與可用儲存空間。先直接執行核心，查看版本與設定載入結果，再交由服務腳本管理，避免將二進位檔相容性問題誤判為防火牆故障。

3. 匯入設定並驗證對外連線。

   檢查訂閱產生的代理群組、規則提供者與節點協定是否受目前核心支援。先透過明確指定的 HTTP 或 SOCKS 代理測試核心對外連線；這一步成功後，再設定透明接管，便能將節點問題與路由問題分開。

4. 啟用 IP 轉發與透明代理。

   依外掛支援選擇 TProxy 或 TUN，確認 LAN 到 WAN 的轉發、防火牆區域與策略路由都已生效。不要同時啟用多套透明代理腳本，以免重複標記或重複重新導向。

5. 只遷移一台測試終端。

   手動將測試終端的閘道與 DNS 指向旁路由，依序驗證區域網路存取、直連網站、規則代理、影片、語音通話與休眠喚醒。確認穩定後，再修改 DHCP 下發內容。

6. 建立排除與分組策略。

   將印表機、NAS 管理位址、主路由頁面與必要的區域網路網段加入直連或繞過清單。針對電視、遊戲主機與訪客設備，依來源 IP 或 MAC 對應的固定位址分組，方便控制哪些終端進入代理。

7. 設定更新與復原方式。

   訂閱與規則集更新應避開設備負載高峰，並保留最近一次可用設定。服務啟動失敗時，可退回基礎設定，而主路由仍應維持 DHCP 與網際網路出口。

驗證透明代理時，不要只開啟一個網頁。瀏覽器可能使用快取、HTTP/3 或自身的安全 DNS，測試結果不足以證明整條路徑正確。更可靠的順序是先檢查終端取得的位址、閘道與 DNS，再查看旁路由是否收到連線，接著確認規則命中與對外連線選擇，最後測試 UDP、IPv6 與區域網路存取。

ip address
ip route
ip rule
nft list ruleset
logread
ss -lntup

這些指令分別用於查看介面位址、路由表、策略規則、防火牆規則、系統日誌與監聽連接埠。使用 iptables 的系統可改為查看相應的規則表。重點不是一次複製大量指令，而是沿著資料路徑定位：終端是否將封包交給旁路由、防火牆是否標記或重新導向、核心是否接收，以及對外流量是否發往主路由。

常見故障與維護界線

旁路由能連網，用戶端卻無法連網

先檢查用戶端的預設閘道是否確實指向旁路由，以及旁路由是否開啟 IPv4 轉發。接著檢查 LAN 轉發區域、NAT 與回程路徑。旁路由本機存取成功，只代表它自身的 OUTPUT 流量可用，不能證明來自區域網路的 FORWARD 流量已獲准通過。

網頁可以開啟，遊戲或語音應用程式卻逾時

這通常需要檢查 UDP。REDIRECT 方案可能只處理 TCP，TProxy 所需模組或策略路由也可能尚未載入。查看規則是否將 UDP 送入核心，並確認所選節點協定與代理伺服器能承載相應的 UDP 流量。若只有特定遊戲異常，還應檢查 NAT 類型、連接埠轉送與遊戲平台的區域規則。

啟用後區域網路設備無法存取

透明代理排除清單可能遺漏私有位址、群播位址或本地服務連接埠。應確保常見區域網路網段與路由器管理位址依本地路徑轉發。跨 VLAN 或跨子網路存取還要檢查防火牆區域，不要簡單地將所有私有位址永久設為直連；如果代理資源位於內部網段，仍需依實際拓撲建立精確規則。

CPU 使用率高，但吞吐量低

先關閉 debug 日誌並觀察單核心負載，再比較直連規則與代理規則的速度。如果直連也明顯變慢，可能是透明轉發關閉了硬體卸載，或封包在防火牆鏈中被重複處理。如果只有代理連線較慢，則應檢查加密協定、節點鏈路與 MTU。TUN 情境中的 MTU 不合適，可能造成分片、部分網站卡頓或大型檔案連線停滯。

訂閱更新後服務無法啟動

常見原因包括設定欄位與核心版本不相容、規則提供者下載失敗、YAML 縮排錯誤或資料目錄權限變更。維護時應區分「訂閱原始內容」、「外掛產生後的執行設定」與「核心實際載入的設定」。管理外掛可能會合併範本、覆寫連接埠或新增 DNS 欄位，只查看訂閱檔案不一定能發現最終錯誤。

部署結論：先確定路徑，再選擇元件

在路由器上執行 Clash 核心的難點通常不在於啟動程式，而在於讓流量依預期進入、離開並返回。主路由方案路徑簡潔，但維護風險集中；單臂旁路由適合漸進式測試，需要處理 NAT 與回程；雙網路埠閘道界線明確，同時也帶來獨立子網路與跨網段管理成本。設備選擇則應同時考量 CPU 架構、單核心效能、記憶體餘裕、規則規模與日誌儲存。

實際部署時，先用明確代理驗證核心與節點，再啟用透明轉發；先讓一台終端使用旁路由，再調整 DHCP；先確認 IPv4、TCP 與基礎 DNS，再繼續測試 UDP、TUN 與 IPv6。依照資料路徑分層驗證，可以分別定位訂閱、核心、防火牆、DNS 與區域網路拓撲的問題，也能在設定變更後快速找出影響範圍。