Mihomo on 亂筆

拋棄所謂「客戶端」，直接使用 Mihomo 內核

Thu, 03 Jul 2025 10:30:00 +0000

自從開始使用 Clash/Mihomo，我和大多數人一樣選擇了基於其內核的圖形化客戶端——圖方便。實際上，這些 Mihomo 客戶端本質上都差不多：內核都是同一個，他們主要負責提供一個易用的界面、管理配置文件、訂閱更新，以及 GUI 下的系統代理設置。基於這一點，我認為判斷一個 Mihomo 客戶端優劣的關鍵，便是看它的「覆寫」功能做得如何。每一個通過客戶端下載或者訂閱的配置文件，都會經過一系列「覆寫」過程，比如更換 mixed-port、添加 sniffer 配置等，最後生成用於啟動 Mihomo 內核的最終配置。

然而，並非所有客戶端都能勝任這一核心工作。比如 ShellCrash，其覆寫功能經常莫名其妙出岔子，說到底還是實現得太粗糙。如果連覆蓋和修改配置都做不好，這種客戶端實在難稱合格。

與其依賴這些~~屎一樣的~~不盡如人意的 Mihomo 客戶端，不如自己動手，直接自己編寫、管理配置文件交給內核啟動，而不是依賴「黑箱」一般的各種「客戶端」，不僅更純淨、更穩定，而且更可控。

需要的預備知識

基本的 Linux 操作
知道如何使用 CLI 編輯器，如 nano
已經搭建 Substore（可選）
默認使用 root 用戶操作，非 root 用戶請自行注意提權

安裝 Mihomo 內核

對於基於 Debian 的分支，可以使用預編譯的.deb包安裝，對於其他使用systemd的系統，下載編譯好的二進制文件，重命名為mihomo，放到/usr/local/bin：

curl -o /usr/local/bin/mihomo <下載鏈接>
chmod +x /usr/local/bin/mihomo

然後新建/etc/systemd/system/mihomo.service：

[Unit]
Description=mihomo Daemon, Another Clash Kernel.
After=network.target NetworkManager.service systemd-networkd.service iwd.service

[Service]
Type=simple
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
Restart=always
ExecStartPre=/usr/bin/sleep 1s
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

使用systemctl daemon-reload重新加載systemd，此時還沒有配置文件，不能直接啟動內核，但可以使用systemctl enable mihomo讓內核開機自啟，方便後續使用。

配置文件

內核啟動時會加載/etc/mihomo/config.yaml，沒有了黑箱一樣的礙事「客戶端」，配置文件可以隨心所欲的定製。部分機場會下發完整的配置文件，直接用curl下載即可。

對於訂閱的管理，我目前使用 Substore，我之前分享過「最速 Substore 訂閱管理指南」，可以直接參考這篇文章來定製自己的訂閱。為了實現純內核啟動，現在我的 Substore JS 格式覆寫已經加入了full參數，可以生成完整的配置文件，包括各種端口設置、統一延遲和外部控制器等，開箱即用。

在 Substore 配置完成以後便可以下載配置文件並啟動內核：

sudo curl -o /etc/mihomo/config.yaml 配置文件鏈接
sudo systemctl start mihomo

自定義覆寫

我的配置文件不能滿足你的所有需求？沒問題！你可以自己添加覆寫，想要什麼加什麼。

我用過各種覆寫規則，後來也開始自己從零開始編寫覆寫規則，即使使用自己的覆寫規則能滿足 99% 的場景，但有極個別的域名還是會在規則中有遺漏，更不用說用別人寫的覆寫規則了。這些遺漏的規則大多是形如我服務器的非標準端口 SSH 的前置代理等相對隱私的規則，直接上傳到 Github 公開顯然不太合適，那麼在自定義規則的基礎上再添加覆寫就成了唯一的選擇。

好在 Substore 可以添加多個腳本操作，只需要在生成配置文件時額外添加一個腳本操作就能解決我們的問題。

function main(config) {
  config["rules"].unshift("DOMAIN-SUFFIX,xxx,DIRECT")
  return config
}

需要注意的是覆寫rules時必須要使用.unshift()放在最前面，而不是用.push()放到最後面，因為放在MATCH後面的規則是永遠都匹配不到的。

自定義配置文件

完全不喜歡我的覆寫規則？不會用/不喜歡用 Substore？沒問題！你也可以參考 Mihomo 文檔，自己從頭開始手搓配置文件：

mode: rule
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
log-level: info
ipv6: true
external-controller: 127.0.0.1:8000
# secret: yoursecret
unified-delay: true
routing-mark: 7894
tcp-concurrent: true
disable-keep-alive: true # 推薦在給移動設備代理時啟用，可以解決待機異常耗電的問題

dns:
  # 你的 DNS 配置

sniffer:
  # 你的域名嗅探配置

geodata-mode: true
geox-url:
  # 自定義 Geodata 文件 URL

proxy-providers:
  # 你的機場訂閱

rule-providers:
  # 外部規則

rules:
  # 分流規則

proxy-groups:
  # 自定義代理分組

管理面板

管理面板可以根據個人喜好選擇，以 Zashboard 為例，我在使用 mihomo 自帶的external-ui時遇到了一些莫名其妙的問題，所以乾脆直接運行一個 Docker 容器，畢竟這東西就真的只是一個 Web 面板，只要確保內核 API 使用 HTTP 時，Web 面板也使用 HTTP 即可，如果此時 Web 面板使用 HTTPS，則會因為 CORS 策略問題無法連接。

$ mkdir zashboard && cd zashboard
$ nano compose.yml
$ docker compose up -d

compose.yml內容：

services:
  zashboard:
    image: ghcr.io/zephyruso/zashboard:latest
    ports:
      - "8899:80"
    restart: "unless-stopped"

自動維護

內核已經運行起來，自動更新訂閱這種功能怎麼實現？

答曰：自行編寫一個 Shell 腳本，配合 Crontab 即可實現自動更新訂閱的功能。例如我希望每天凌晨 3 點自動更新訂閱並重啟服務，遂編寫/etc/mihomo/auto_update.sh：

#!/bin/bash

# === 配置信息 ===
CONFIG_URL=""
CONFIG_PATH="/etc/mihomo/config.yaml"
BACKUP_DIR="/etc/mihomo"
BACKUP_PREFIX="config.yaml"
MAX_BACKUPS=7
TMP_PATH="/tmp/config.yaml.tmp"
LOG_FILE="/var/log/mihomo_update.log"

# === 日誌 ===
log() {
    echo "$(date '+%F %T') $1" | tee -a "$LOG_FILE"
}

# === 備份現有配置，並自動清理舊備份 ===
backup_config() {
    if [ -f "$CONFIG_PATH" ]; then
        backup_file="$BACKUP_DIR/${BACKUP_PREFIX}.$(date '+%Y%m%d_%H%M%S').bak"
        cp "$CONFIG_PATH" "$backup_file"
        log "配置文件已備份到 $backup_file"
        # 清理多餘的備份，只保留最新的 $MAX_BACKUPS 個
        old_backups=$(ls -1t $BACKUP_DIR/${BACKUP_PREFIX}.*.bak 2>/dev/null | tail -n +$(($MAX_BACKUPS+1)))
        for f in $old_backups; do
            rm -f "$f" && log "已刪除舊備份 $f"
        done
    else
        log "未找到現有配置文件，無需備份"
    fi
}

# === 下載新配置 ===
download_config() {
    log "開始下載新配置..."
    curl -fsSL -o "$TMP_PATH" "$CONFIG_URL"
    if [ $? -ne 0 ]; then
        log "下載配置失敗，請檢查網絡或地址"
        return 1
    fi
    # 基本校驗：檢測文件體積
    if [ ! -s "$TMP_PATH" ]; then
        log "下載文件為空，停止更新"
        return 2
    fi
    log "配置下載完成"
    return 0
}

# === 更新配置文件 ===
replace_config() {
    mv "$TMP_PATH" "$CONFIG_PATH"
    log "配置文件已更新"
}

# === 重啟 mihomo 服務 ===
restart_service() {
    systemctl restart mihomo
    if [ $? -eq 0 ]; then
        log "mihomo 服務已重啟"
    else
        log "mihomo 服務重啟失敗，請手動檢查"
    fi
}

main() {
    backup_config

    download_config
    DL_STATUS=$?
    if [ "$DL_STATUS" -ne 0 ]; then
        log "操作終止：配置文件未更新，保留原有配置"
        exit 1
    fi

    replace_config

    restart_service

    log "=== 更新流程完成 ==="
}

main "$@"

使用crontab -e編輯 Crontab，設置如下 Crontab 即可在每天凌晨三點自動更新配置：

0 3 * * * /etc/mihomo/update_config.sh

防火牆

手動配置防火牆把流量劫持到 Mihomo 內核其實並不是什麼難事，我之前在「從入門到進階：Tailscale + ShellCrash 異地組網和科學上網」（以下簡稱「Tailscale 那篇文章」中的兩個小節中提到過具體的操作方法，這裡只提操作，不做解說。

根據我的情況，我需要把tailscale0上的網卡的所有流量劫持到 Mihomo 內核，其它的情況（例如本機代理）操作也大同小異。如果只是想劫持 TCP 流量，那麼用iptables的 REDIRECT 功能已經足夠，但若還想劫持 UDP、QUIC 等流量，則必須用到 Tproxy。最後，不要忘了 IPV6。

以下是我的防火牆配置：

# 創建自定義鏈
iptables -t mangle -N MIHOMO

# 根據自己的需要忽略本地流量
iptables -t mangle -A MIHOMO -d 127.0.0.1/8 -j RETURN
iptables -t mangle -A MIHOMO -d 100.64.0.0/10 -j RETURN
iptables -t mangle -A MIHOMO -d 192.168.1.0/24 -j RETURN
iptables -t mangle -A MIHOMO -d 172.17.0.0/16 -j RETURN

# mark UDP 和 TCP 到代理
iptables -t mangle -A MIHOMO -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
iptables -t mangle -A MIHOMO -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳轉
iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO

# 路由表配置
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip rule add fwmark 233 lookup mihomo
ip route add local 0.0.0.0/0 dev lo table mihomo

# IPv6
# 創建鏈
ip6tables -t mangle -N MIHOMO6

# 跳過本地地址
ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN
ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN

# 標記 TCP/UDP
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳轉
ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6

# 路由表配置
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip -6 rule add fwmark 233 lookup mihomo
ip -6 route add local ::/0 dev lo table mihomo

大多數系統默認不會保存防火牆規則，關於規則持久化的內容我已經分別在 Tailscale 那篇文章的「路由規則持久化」和「iptables 規則持久化」兩小節做了詳細說明，直接參考即可。

本機代理怎麼配置？

大多數代理軟件默認的配置（其實就是 ShellCrash 的默認配置）是 REDIRECT，用它也基本能滿足大多數需求，REDIRECT 的示例如下：

# IPv4 劫持 eth0
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 劫持 eth0
ip6tables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

其中 7892 要和 Mihomo 配置中的redir-port一致，eth0就是想要劫持的 Interface，相比 Tproxy 那可真是簡單太多了。

實際上我個人並不喜歡用把本機所有流量都劫持到防火牆，我更喜歡在需要時直接通過環境變量、proxy-chains和各種軟件自帶的代理配置把流量指向 Mihomo 內核，例如想讓 Docker 走代理，則可以直接編輯 Docker 的/etc/docker/daemon.json來指定代理，而不是直接一股腦把網卡上的所有流量都劫持到代理：

{
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "127.0.0.0/8"
  }
}

這麼折騰，何必呢？用客戶端不香嗎？

別問，問就是玩虛空終端玩的。

最速 Substore 訂閱管理指南

Fri, 07 Mar 2025 10:54:29 +0000

當我趁著春節各家機場的促銷訂閱多個機場之後，如何充分利用每個節點就變成了說難不難說簡單也不簡單的問題，我當然可以訂閱各家機場提供的配置文件，然後在他們之間切換，但這樣未免也太麻煩了。更何況我還有自建節點，我可不想為了這一個節點專門去開一個新的配置。

Sub-Store 很好的解決了這個問題，它可以從多個訂閱中抽取節點信息，通過正則表達式或者 JS 整理它們，最後輸出一個整合了所有節點信息的訂閱。

部署它可以直接使用 xream 打包好的鏡像，這個鏡像整合了前後端，如果在公網部署，記得更改一下後端路徑，否則你的配置文件很可能會被盜用。

services:
  sub-store:
    image: xream/sub-store
    container_name: substore
    restart: always
    environment:
      - SUB_STORE_CRON=55 23 * * *
      - SUB_STORE_FRONTEND_BACKEND_PATH=/super-random-path
    ports:
      - "3001:3001"
    volumes:
      - ./data:/opt/app/data

反代 3001 端口即可訪問 Substore 的前端，這裡以 Caddy 為例：

sub-domain.example.com {
        reverse_proxy :3001
}

當然，初次進入前端別忘了新增後端地址，這時的後端地址取決於之前 compose file 裡的設置，在本文的例子中，後端地址為https://sub-domain.example.com/super-random-path。

組合訂閱的管理

添加所有機場上游和自建節點之後，就可以開始把它們全都加進單個組合訂閱，但各個機場對節點的命名五花八門，默認情況下看起來非常雜亂，甚至不同機場之間的節點還有重名的可能。好在 Sub-Store 有通過腳本對節點進行批量重命名操作的功能，這裡推薦一個腳本，能夠幫我們為所有的機場節點重命名。

欲使用這個腳本，只需在編輯訂閱時將以下地址粘貼到腳本操作處即可。

https://raw.githubusercontent.com/Keywos/rule/main/rename.js

最後再進行一些你喜歡的節點操作，可以整理出一個統一規範的節點列表。

生成 Clash 配置

現在雖然已經有了節點列表，但現在生成的配置文件並不包含任何規則，需要自行編寫或者拉取第三方規則。

轉到 Substore 的文件管理，創建一份新的 Mihomo 配置：

「來源」選擇組合訂閱，並在訂閱名稱上選擇你的訂閱組
在腳本操作中填入自己的覆寫配置

這是我自己的覆寫規則 powerfullz/override-rules，為 Mihomo/Substore 設計，核心特色如下：

集成 SukkaW/Surge 與 217heidai/adblockfilters 等優質規則，兼容性強，覆蓋面廣。
針對 Truth Social、E-Hentai、TikTok、加密貨幣等場景，新增專用分流規則，滿足多樣化需求。
精簡冗餘，結構清晰，維護便捷。
深度融合 Loyalsoldier/v2ray-rules-dat GeoSite/GeoIP，分流更精準。
IP 規則默認添加 no-resolve，有效減少本地 DNS 解析，提升速度與隱私。
動態覆寫：自動識別節點國家/地區，僅生成實際存在的分組，節點名稱實時枚舉，配置更智能。

JavaScript 格式覆寫

複製 JavaScript 格式覆寫文件的鏈接https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js，並根據需要在後面附加參數，格式如下：

https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#參數1=true&參數2=true

目前支持如下參數：

參數	功能
`loadbalance`	啟用國家/地區節點組的負載均衡
`landing`	啟用落地節點功能
`ipv6`	啟用 IPv6 支持
`full`	生成針對純內核使用場景的完整配置
`keepalive`	啟用 TCP KeepAlive
`quic`	允許 QUIC 流量¹
`fakeip`	DNS 增強模式使用 fake-ip²
`regex`	各國家代理組改用 include-all + 正則過濾模式³
`threshold`	國家/地區節點數量小於該值時不顯示分組（默認 0）

例如，若有負載均衡和 IPv6 需求，最終的覆寫腳本鏈接為：

https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#loadbalance=true&ipv6=true

將最終的覆寫腳本鏈接粘貼到腳本操作處，使用 Substore 的生成預覽功能確認沒有問題後即可保存。

YAML 格式覆寫

~~YAML 格式覆寫我自己已經不用了，隨緣維護，但歡迎 PR~~

寫了個 Github Actions 自動根據 JS 格式覆寫生成 YAML 格式覆寫，所以現在 YAML 格式又開始維護了。

除了直接引用 convert.js 動態覆寫，你也可以使用倉庫中預先生成好的 32 份 YAML 格式覆寫——它們都放在 yamls/ 目錄裡，由 GitHub Actions 在每次推送後自動重新生成、覆蓋。適用於諸如 Clash Verge 等不支持 JS 覆寫的客戶端和轉換服務。

文件命名規則：

config_lb-{0|1}_landing-{0|1}_ipv6-{0|1}_full-{0|1}_keepalive-{0|1}_fakeip-{0|1}_quic-{0|1}.yaml

示例（開啟 full，其餘關閉）：

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/yamls/config_lb-0_landing-0_ipv6-0_full-1_keepalive-0_fakeip-0_quic-0.yaml

CI 只是套用一份假的fake_proxies.json來生成覆寫，所以不可能實現 JS 覆寫自動根據節點匹配生成對應代理組的功能，只能把所有地區節點組都放進去。如果你已經搭建 Substore，並且想要「動態識別國家 + 傳參」的靈活性，還是推薦使用 JS 覆寫。

生成下載鏈接

保存成功後點擊分享按鈕生成分享鏈接，設置分享有效期後點擊「創建分享」，生成的鏈接即最終成型的 Mihomo 配置文件，將其作為訂閱鏈接在你的代理軟件內訂閱就大功告成了。

部分機場 UDP 性能差，開啟後可能出現體驗降級。 ↩︎
開啟後可能有助於解決 TUN 模式無法上網的問題。 ↩︎
各國家代理組改用 include-all + 正則過濾模式，由 Mihomo 內核在運行時按正則動態篩選節點，而非在腳本執行時枚舉節點名稱（默認 false） ↩︎