路由器與旁路由直跑 mihomo 核心部署概覽：架構選擇與基本步驟

Clash Premium 舊核心停止維護後，路由器端部署逐漸轉向仍持續更新的 mihomo。不同於桌面用戶端，路由器沒有圖形介面代替核心處理設定目錄、權限、DNS 轉送與程序守護；部署重點也不只是讓代理連接埠開始監聽，而是確保區域網路流量經過明確且可回復的轉送路徑。

本文討論兩類常見環境：安裝 OpenWrt 的主路由器，以及執行 Debian、Ubuntu、ImmortalWrt 或其他 Linux 系統的旁路由。範例以 mihomo v1.19 系列設定語法為基準，採用 TUN 接管作為主軸，同時說明傳統防火牆轉送需要額外處理的部分。實際安裝前，仍應依裝置架構與目標版本的發布說明再次確認檔名。

先選擇架構：主路由直裝還是獨立旁路由

主路由直裝，是將 mihomo 放在同一台負責撥號、DHCP、NAT 與防火牆工作的裝置上。所有終端原本就以它作為預設閘道，流量路徑最短，通常不必逐台修改閘道。代價是代理設定錯誤可能同時影響整個家庭網路；升級核心、重新啟動防火牆或誤改 DNS 時，復原入口也在同一台裝置上。

旁路由則將代理接管交給另一台 Linux 裝置。上游主路由繼續負責撥號，旁路由只處理策略路由、DNS 與 mihomo。這種架構便於停機維護，也能只讓電視、手機或測試電腦經過代理；但同網段單臂旁路由容易出現回程繞過、閘道迴圈與 DHCP 衝突，必須先規劃好位址與轉送關係。

單臂旁路由位址範例

假設主路由位址是 192.168.1.1，旁路由固定使用 192.168.1.2。旁路由本身的預設閘道仍填寫 192.168.1.1；需要接管的終端則將閘道與 DNS 指向 192.168.1.2。若透過 DHCP 批次下發，應確保同一廣播網域只有一台 DHCP 伺服器，避免兩台裝置同時分配不同的閘道。

單臂架構建議在旁路由出口執行來源位址轉換，讓回程流量穩定經過旁路由。若要保留用戶端原始位址供規則比對，則需在主路由新增通往用戶端網段的靜態路由，並確認回程不會直接繞過旁路由。兩種方案不要混用到無法判斷封包實際經過的路徑。

檢查硬體、系統與二進位檔架構

mihomo 是單一核心程式，但規則集、連線追蹤與 Fake-IP 對映都會佔用記憶體。小型設定啟動後通常約佔用 70 MB 至 120 MB；載入較大的網域規則集、多個 provider 與數千條連線後，佔用量可能達到 180 MB 至 300 MB。只有 128 MB 記憶體的舊路由器餘裕很小，512 MB 可作為較實際的起點，1 GB 以上則更適合長時間執行與頻繁更新規則。

先透過 SSH 查詢系統架構與核心資訊：

uname -m
uname -a
getconf LONG_BIT
cat /etc/os-release
free -m
df -h

TUN 模式還依賴核心裝置與相關模組。可執行 ls -l /dev/net/tun 檢查裝置節點，再使用 ip rule、ip route 與 nft list ruleset 確認系統具備策略路由與 nftables 管理能力。OpenWrt 可在 LuCI 的「系統」→「套件」中檢查 kmod-tun，也可透過 SSH 安裝與目前韌體核心相符的套件。

建立設定目錄並完成首次驗證

一般 Linux 可將程式放在 /usr/local/bin/mihomo，設定目錄放在 /etc/mihomo。OpenWrt 快閃儲存空間吃緊時，可將較大的規則檔案放到掛載磁碟，例如 /mnt/data/mihomo，但開機服務必須等待該掛載點可用。以下指令假設壓縮檔已在本機解壓縮，檔名應替換成實際下載的架構版本：

sudo install -m 0755 mihomo-linux-amd64 /usr/local/bin/mihomo
sudo mkdir -p /etc/mihomo
sudo install -m 0600 config.yaml /etc/mihomo/config.yaml

/usr/local/bin/mihomo -v
sudo /usr/local/bin/mihomo -t -d /etc/mihomo

-t 用於測試設定，-d 指定工作目錄。測試通過只代表 YAML 可以解析且主要欄位可載入，不代表訂閱網址、DNS 上游與節點都能連線。正式啟動後，還要查看日誌中的 provider 更新、監聽連接埠、TUN 網卡與規則比對結果。

訂閱不等於可直接執行的完整設定

桌面用戶端通常會在圖形介面中封裝訂閱匯入、覆寫與核心參數；路由器直跑則需要一份完整的 config.yaml。有些訂閱會回傳完整 Clash 設定，有些只回傳節點集合；後者需要透過 proxy-providers 引用，並自行補上策略群組、DNS、規則與監聽連接埠。

訂閱網址通常帶有帳戶權杖，應將設定檔權限限制為僅管理員可讀。更新 provider 後，先保留上一份可用快取，避免遠端回傳空內容時立即覆寫正在運作的節點集合。替換主要設定檔前，可以先執行一次測試：

cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
/usr/local/bin/mihomo -t -d /etc/mihomo

# 測試失敗時復原
cp /etc/mihomo/config.yaml.bak /etc/mihomo/config.yaml

透明代理設定：TUN、DNS 與監聽範圍

僅啟用 mixed-port: 7890 時，區域網路裝置仍需手動填寫 HTTP 或 SOCKS 代理；它無法自動接管電視應用程式、遊戲主機及不遵循系統代理設定的程式。路由器部署通常會使用 TUN 或基於 nftables 的透明轉送。TUN 設定較集中，但仍需處理核心模組、策略路由、DNS 劫持與防火牆相容性。

以下是用來說明關鍵欄位的基礎片段。節點、策略群組與業務規則仍需由完整設定提供：

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-secret"

profile:
  store-selected: true
  store-fake-ip: true

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

auto-detect-interface 用於識別實際出口，可減少撥號介面名稱變動造成的設定修改；但在多 WAN、VPN 疊加或容器網橋較多的環境中，自動判斷未必符合預期，需要透過日誌與 ip route get 1.1.1.1 核對出口。strict-route 可減少 DNS 或連線繞過，但也更容易暴露策略路由設定錯誤。

範例將 DNS 監聽設定在 1053，避免直接佔用可能已被 dnsmasq 使用的 53 連接埠。OpenWrt 上可讓 dnsmasq 將上游轉送至 127.0.0.1#1053，對應 LuCI 常見路徑為「網路」→「DHCP/DNS」→「一般設定」→「DNS 轉送」。儲存前應關閉會同時將請求送往其他上游的平行轉送設定，否則可能造成解析結果與代理規則不一致。

Fake-IP 過濾需要涵蓋區域網路服務

Fake-IP 能讓網域規則在建立連線階段直接參與分流，但印表機、NAS、投放與區域網路探索服務可能依賴真實位址。可將本地域名後綴、路由器管理網域與必要的連線檢測網域加入 fake-ip-filter。區域網路服務也應優先使用本地 DNS 回傳的私有位址，避免網域先由公共 DNS 解析。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.local"
    - "nas.home.arpa"
    - "+.home.arpa"

OpenWrt 主路由的實作步驟

1. 備份現有設定。在 LuCI 開啟「系統」→「備份與升級」，產生可復原的設定封存檔；同時記錄 WAN 介面名稱、LAN 位址與 DHCP 設定。
2. 檢查剩餘空間。使用 df -h 查看 overlay；可執行檔、Geo 資料與規則集合計可能佔用數十 MB。空間不足時改用外接儲存，不要將根分割區塞滿。
3. 安裝 TUN 支援。進入「系統」→「套件」安裝與韌體相符的 kmod-tun，接著確認 /dev/net/tun 存在。
4. 放置程式與設定檔。建議使用 /usr/bin/mihomo 與 /etc/mihomo/config.yaml，權限分別設定為 0755 與 0600。
5. 先以前景模式執行。執行 /usr/bin/mihomo -d /etc/mihomo，觀察 TUN、DNS 與 provider 日誌，再從一台測試終端驗證直連與代理規則。
6. 加入開機服務。確認前景執行穩定後，再建立 procd 服務，最後在「系統」→「啟動項目」查看啟用狀態。

OpenWrt 使用 procd 管理服務。以下腳本展示最小結構，設定目錄應與實際位置一致：

#!/bin/sh /etc/rc.common

START=95
STOP=10
USE_PROCD=1

start_service() {
  procd_open_instance
  procd_set_param command /usr/bin/mihomo -d /etc/mihomo
  procd_set_param respawn 3600 5 5
  procd_set_param stdout 1
  procd_set_param stderr 1
  procd_set_param limits nofile="1048576 1048576"
  procd_close_instance
}

service_triggers() {
  procd_add_reload_trigger "mihomo"
}

將其儲存為 /etc/init.d/mihomo 後執行：

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo

若啟動時外接磁碟尚未掛載，服務會找不到設定或規則檔案。可將設定檔留在內部快閃儲存，只把 provider 快取放到外接磁碟；也可以調整啟動順序，並在腳本中檢查目錄。不要依賴固定等待數秒來掩蓋掛載順序問題。

一般 Linux 旁路由的 systemd 設定

Debian、Ubuntu 與其他使用 systemd 的系統，可建立 /etc/systemd/system/mihomo.service。路由透明接管需要建立 TUN、寫入路由並管理相關網路能力，最直接的初始方案是以 root 執行；部署穩定後，再依實際功能逐步縮減權限，而不是一開始就移除能力導致 TUN 建立失敗。

[Unit]
Description=mihomo routing core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/local/bin/mihomo -t -d /etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo
sudo journalctl -u mihomo -n 100 --no-pager

旁路由還必須啟用 IPv4 轉送。可建立 /etc/sysctl.d/90-router-forward.conf：

net.ipv4.ip_forward=1

接著執行 sudo sysctl --system。若啟用 IPv6，還要另外規劃 IPv6 預設路由、DNS 與防火牆，不能只開啟 net.ipv6.conf.all.forwarding=1 就假設所有流量都已進入 mihomo。在尚未完成 IPv6 接管前，可先於測試網路中停用 IPv6，避免終端透過未納入規則的 IPv6 路徑連線。

不要讓防火牆與 TUN 規則重複接管

已有 nftables、Docker、Tailscale 或其他 VPN 時，規則優先順序可能發生衝突。啟用 mihomo 後，應分別執行 ip rule、ip route show table all 與 nft list ruleset，檢查是否出現重複標記、預設路由回指 TUN、容器網段誤進代理等情況。TUN 的自動路由已接管目標流量時，不要再照搬一套舊版 REDIRECT 規則。

效能驗證與故障排查

部署完成後，不要只以網頁能否開啟作為判斷依據。至少驗證區域網路直連、代理連線、DNS、規則命中、重新啟動後復原，以及高並發穩定性六項。測試時先固定同一個節點與同一台終端，避免節點波動與本機設定同時變動。

• 連接埠狀態：使用 ss -lntup 檢查 7890、9090 與 1053 是否依預期監聽。
• DNS 路徑：執行 nslookup example.com 192.168.1.2，再查看 mihomo 日誌中是否出現對應查詢。
• 閘道轉送：在終端執行路由追蹤，確認第一跳是規劃中的主路由或旁路由，而不是另一台 DHCP 伺服器下發的舊閘道。
• 規則命中：將日誌暫時改為 debug，核對目標網域最終進入預期策略群組；完成後恢復為 info，避免長期產生大量日誌。
• 重新啟動後復原：整台裝置重新啟動後，檢查 mihomo、DNS 轉送與 TUN 是否自動恢復，並確認能讀取 provider 快取。
• 回復測試：停止 mihomo 後，將測試終端的閘道切回主路由，確認基礎網路仍可獨立運作。

作為硬體等級參考，在 500 Mbps 連線、mihomo v1.19 系列、約 8,000 條規則的測試條件下，Intel N5105 四核心小型主機透過 TUN 轉送通常可達約 430 至 470 Mbps；四核心 Cortex-A53、1 GB 記憶體裝置通常約為 180 至 240 Mbps。數值會受到加密協定、節點距離、網卡驅動程式、規則規模及是否啟用流量嗅探影響，不能直接視為裝置標示效能。

若測速只有直連的一半，先觀察單核心 CPU 是否接近 100%，再檢查 MTU。PPPoE、WireGuard 與 TUN 疊加時，MTU 過大可能造成分片或部分網站載入停頓。可從 1500 逐步測試 1492、1480 或 1400；每次只變更一個參數，並記錄吞吐量、延遲與封包遺失結果。

更新核心與設定檔的交接流程

路由器上的更新應依照「驗證新檔案、保留舊檔案、切換服務」的順序進行。不要直接覆寫正在執行的二進位檔後立即重新啟動。先將新版儲存為 mihomo.new，執行版本檢查與設定測試，再停止服務、替換檔案並啟動。確認執行穩定後，舊版仍可保留一個更新週期。

sudo install -m 0755 mihomo.new /usr/local/bin/mihomo.new
sudo /usr/local/bin/mihomo.new -v
sudo /usr/local/bin/mihomo.new -t -d /etc/mihomo

sudo systemctl stop mihomo
sudo mv /usr/local/bin/mihomo /usr/local/bin/mihomo.previous
sudo mv /usr/local/bin/mihomo.new /usr/local/bin/mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo

更新設定檔也應先寫入暫存檔測試，再替換主要檔案。涉及 DNS 模式、TUN 堆疊、規則集格式或 provider 行為變更時，先在一台終端上驗證，不要與系統韌體升級安排在同一時間。舊核心謝幕後，mihomo 接手的不只是可執行檔，設定欄位與網路接管方式也會持續變化；將驗證與回復做成固定步驟，比依賴某一份長期不變的腳本更可靠。