まず構成を決める：メインルーターか旁路ルーターか

OpenWrtでClash系コアを動かす場合、現在は通常mihomoを導入します。mihomoはClash Metaの設定形式とルール機能を引き継いでおり、YAML設定を直接読み込めるほか、mixed-port、DNS、TUN、ルールセット、外部制御インターフェースを利用できます。ルーター環境はデスクトップクライアントと異なります。デスクトップでは本体の通信だけを処理しますが、ルーターではLAN機器から転送される通信も識別し、DNS、ポリシールーティング、IPv4とIPv6の戻り経路まで処理する必要があります。

導入前に、機器をネットワーク内でどの役割にするか決めます。メインルーター構成では、OpenWrtがPPPoE接続、DHCP、DNS、デフォルトゲートウェイを担当します。通信経路が分かりやすく、透過プロキシのルールも一元管理しやすい構成です。旁路ルーター構成では既存のメインルーターを残し、OpenWrtを同じLAN内の第2のレイヤー3機器として配置します。指定した端末、またはDHCPで割り当てた通信だけを引き受けます。変更は少なくて済みますが、ゲートウェイ、DNS、戻り経路を一つずつ確認する必要があります。

メインルーター構成

  • ONUをブリッジモードにする場合は、OpenWrtのWANポートからPPPoE接続します。ONUをルーターモードで使う場合は、OpenWrtのWANポートが上位ネットワークからアドレスを取得します。
  • LAN端末のデフォルトゲートウェイをOpenWrtに設定します。例：192.168.10.1。
  • DHCPとDNSはOpenWrtが提供するため、端末ごとにプロキシアドレスを設定する必要はありません。
  • TUNまたはTProxyのルールでLAN全体を対象にすることも、送信元アドレス、MACアドレスに紐づく固定リース、宛先ネットワーク単位でバイパスすることもできます。

旁路ルーター構成

  • メインルーターには192.168.1.1を使用し、旁路ルーターには同じサブネットの固定アドレス192.168.1.2を設定します。
  • 旁路ルーターのデフォルトゲートウェイと上位DNSは、まずメインルーターに向けます。これにより、サブスクリプション更新時に自身の外部通信経路を失うのを防げます。
  • プロキシを利用する端末では、ゲートウェイとDNSを192.168.1.2に設定します。それ以外の端末は引き続きメインルーターを使用します。
  • メインルーターのDHCPがカスタムゲートウェイを配布できる場合は、旁路ルーターのアドレスを一括配布できます。対応していない場合は、端末ごとに手動設定するか、DHCPサービスの範囲を慎重に調整してください。

ハードウェア、アーキテクチャ、ストレージ容量

コアが起動できるかどうかは、アーキテクチャとランタイムライブラリが一致しているかで決まります。実際のスループットは、CPUのシングルコア性能、暗号アルゴリズム、ルール規模、接続数、ネットワークドライバーの影響を受けます。2～3台の端末で、およそ100 Mbpsまでの回線を使うだけなら、デュアルコアARM64と256 MBのメモリで基本的なルールプロキシを運用できます。500 Mbps以上の回線でTUN、DNS fake-ip、大規模なルールセットを同時に有効化する場合は、4コアARM64、メモリ512 MB以上を目安にしてください。ギガビット回線では、機器のNAT性能、NIC割り込み、CPUソフトIRQの使用率も確認します。

数万件のルールと複数のrule-providerを含む設定では、mihomoの常駐メモリは一般に約80～180 MBです。大量のドメインルール、コネクショントラッキング、ダッシュボードからの照会を有効にすると、さらに増加します。OpenWrt本体に加え、dnsmasq、firewall4、ログサービスもメモリを使用するため、128 MBの機器は通常、最小限の設定に適しています。フラッシュ容量は、コア本体、GeoIP、GeoSite、ルールセット、一時ダウンロードファイルを合わせて100 MB以上確保すると安心です。

CPUアーキテクチャを確認する

SSHでOpenWrtにログインし、まずシステム情報を確認します。ルーターの商品名だけでバイナリを選ばないでください。

uname -m
ubus call system board
cat /etc/openwrt_release

x86_64はAMD64、aarch64はARM64に対応します。古い機器ではarmv7l、mips、mipselが返ることもあります。MIPSはエンディアンや浮動小数点実装も分かれるため、ダウンロード前にリリースファイルのアーキテクチャ表記と一つずつ照合してください。バイナリのアーキテクチャが誤っている場合、実行時に通常Exec format errorが直接返されます。

TUNと透過プロキシのモジュールを確認する

ls -l /dev/net/tun
opkg list-installed | grep -E 'kmod-tun|firewall4|nftables'
nft list ruleset | head

TUNモードには少なくともカーネルのTUNサポートが必要で、OpenWrtでは通常kmod-tunを使用します。nftablesベースのTProxy構成では、現在のファームウェアがkmod-nft-tproxyなどの透過プロキシ用モジュールを提供している必要があります。パッケージ名はOpenWrtのブランチやターゲットプラットフォームによって変わるため、現在の機器で利用できるパッケージソースを基準にしてください。別バージョンのリポジトリにあるカーネルモジュールを混在させないでください。

mihomoコアと最小構成を配置する

単独で導入する場合、実行ファイルは/usr/bin/mihomo、設定と実行データは/etc/mihomoに置くことをおすすめします。フラッシュ容量が少ない機器では、ルールセットのディレクトリをマウントしたUSBストレージに移しても構いませんが、起動スクリプトはマウント完了を待つ必要があります。以下のコマンドは、バイナリをSCPで/tmp/mihomoにアップロード済みであることを前提とします。

mkdir -p /etc/mihomo
install -m 0755 /tmp/mihomo /usr/bin/mihomo
/usr/bin/mihomo -v

まず、起動可能な/etc/mihomo/config.yamlを用意します。プロキシノードとプロキシグループは実際のサービス設定に合わせてください。以下では、ルーターに関係するリスニング、制御インターフェース、DNSの構成だけを示します。

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

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

proxies: []
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

allow-lan: trueを設定するとLAN端末からプロキシの待ち受けポートへアクセスできるため、OpenWrtのファイアウォールでは信頼できるLANゾーンから7890、7892、7893、DNSの待ち受けポートだけを許可してください。外部制御インターフェースの例では127.0.0.1:9090にのみバインドしています。別の機器にダッシュボードを配置する場合は、LANの待ち受けアドレスに変更し、推測困難なsecretと明確なファイアウォールの送信元制限を設定します。

保存後、まず構文を検証してからフォアグラウンドで起動します。-dは作業ディレクトリを指定するオプションで、mihomoはそのディレクトリからconfig.yamlを読み込み、キャッシュデータもそこに保存します。

/usr/bin/mihomo -t -d /etc/mihomo
/usr/bin/mihomo -d /etc/mihomo

設定の読み込み完了を確認したら、別のSSHセッションでポートを確認します。

ss -lntup | grep -E '7890|7892|7893|9090|1053'
logread -f

TUNとTProxyの選び方

TUNとTProxyはいずれも端末を意識させずに接続できますが、処理経路は異なります。TUNではmihomoが仮想NICを作成し、仮想インターフェースに入ったIP通信をユーザー空間のプロトコルスタックへ渡します。TProxyでは、ファイアウォールマーク、ポリシールーティング、透過ソケットを使い、元の宛先アドレスを保持したままTCPまたはUDP通信を指定の待ち受けポートへ送ります。どちらも設定スイッチを1つ有効にするだけでは動作しません。ルーターでは、現在のOpenWrtの転送構成とファイアウォール構造に合わせる必要があります。

TUN：導入経路を集約しやすい

mihomoのTUN設定はYAMLに直接記述できます。OpenWrtでは通常systemスタックを使用し、自動ルートと出口インターフェースの自動検出を組み合わせます。

tun:
  enable: true
  stack: system
  device: mihomo
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
  mtu: 1500

TUNの利点は、ルールの大部分をコア設定に集約でき、TCPとUDPを同じ方法で処理できることです。ゲーム機、テレビ、手動プロキシに対応していないアプリにも適しています。一方、通信をユーザー空間の仮想NICへ通すため、低性能なルーターでは、目的を絞って設定したTProxyよりCPU使用率が高くなる場合があります。一部のサイトだけタイムアウトし、小さなパケットは正常な場合は、MTUを1500から1480、1460、1400へ段階的に下げてテストできます。ただし、最終値はPPPoE、トンネル、上位ネットワークを踏まえて決めてください。

TProxy：細かな制御に向く

TProxyは、nftables、ポリシールーティング、OpenWrtのfirewall4に慣れた管理者に適しています。典型的な通信経路は、preroutingチェーンでLAN通信を選別し、LANや予約アドレスを除外し、宛先接続にファイアウォールマークを付け、ip ruleでマーク付き通信をローカルルーティングテーブルへ送り、mihomoのtproxy-port: 7893へ転送する流れです。UDPも個別にルールへ含める必要があります。

OpenWrt 22.03以降は、デフォルトでfirewall4とnftablesを使用します。古い記事にあるiptablesのコマンド、チェーン名、起動タイミングをnftables環境へそのまま適用することはできません。TProxyルールを手作業で記述する場合は、ルーター自身が開始するサブスクリプションのダウンロード、NTP、パッケージ更新、ノード接続まで重複処理しないよう注意してください。そうしないとプロキシループが発生する可能性があります。実際の導入では、現在のOpenWrtバージョンに対応した管理コンポーネントでルールを生成し、nft list rulesetで結果を確認する方法が適しています。

選択の目安

  • TCP、UDP、多くのLAN機器をすばやくカバーしたい：まずTUNを検討します。
  • 機器のCPUが弱い一方、管理者がnftablesを正確に管理できる：TProxyを検討します。
  • ブラウザーと少数のPCだけをプロキシする：まずmixed-port: 7890を使い、すぐに透過プロキシの複雑さを増やす必要はありません。
  • 端末ごとに分流したい：どちらの方式でも送信元IPで制御できます。ただし、DHCPで端末に固定アドレスを割り当てることが前提です。
  • IPv6を使用している：IPv6のDNS、ルーティング、ファイアウォールポリシーも同時に設計してください。IPv4だけを処理して、すべての通信がプロキシを通ると考えることはできません。

サブスクリプション更新：ダウンロード、設定構文の検証、アトミック置換

ルーターのサブスクリプションは、URLをGUIに入力して終わりではありません。更新処理には少なくとも、一時ファイルへのダウンロード、YAMLのテスト、正式設定との置換、サービスのリロードという4段階が必要です。使用中のconfig.yamlを直接上書きすると、ダウンロードが中断したり、サーバーからHTMLのエラーページが返ったりした場合、次回再起動時に設定を読み込めなくなる可能性があります。

以下のスクリプトはuclient-fetchで完全な設定をダウンロードします。サブスクリプションURLはrootだけが読み取れるファイルまたはスクリプトに記述し、公開ログへ出力しないでください。スクリプトを/usr/bin/update-mihomoとして保存し、chmod 700 /usr/bin/update-mihomoを実行します。

#!/bin/sh
set -eu

CONFIG_DIR="/etc/mihomo"
TEMP_FILE="/tmp/mihomo-config.yaml"
SUB_URL="https://subscription.example/path"

uclient-fetch -q -O "$TEMP_FILE" "$SUB_URL"

/usr/bin/mihomo -t -f "$TEMP_FILE"

cp "$CONFIG_DIR/config.yaml" "$CONFIG_DIR/config.yaml.bak"
mv "$TEMP_FILE" "$CONFIG_DIR/config.yaml"

/etc/init.d/mihomo reload || /etc/init.d/mihomo restart

mihomo -t -fは指定した設定ファイルを解析し、YAMLのインデント、フィールド構造、一部のルールエラーを検出できます。ただし、すべてのリモートノードに接続できることまでは確認できません。更新後もサービスログとプロキシグループの状態を確認してください。サブスクリプションが特定のUser-Agentやリダイレクトを必要とする場合は、サービス提供元の要件に合わせてダウンロードコマンドを調整します。

手動更新が安定してからcronに登録します。例として、毎日04:17に1回更新する場合：

17 4 * * * /usr/bin/update-mihomo >> /tmp/mihomo-update.log 2>&1

OpenWrtの/tmpはメモリファイルシステム上にあるため、更新ログは再起動後に消去されます。長期間フラッシュへ書き込まずに済むため、更新処理に適しています。トラブルシューティング中はログサイズを制限し、通常運用ではデバッグレベルのログをフラッシュへ継続的に書き込まないでください。

procdで自動起動を設定する

OpenWrtのサービスは、バックグラウンドコマンドを/etc/rc.localへ直接追加するのではなく、procdに管理させます。procdはプロセスを監視し、異常終了時に再起動できるほか、起動、停止、リロードも一元管理できます。/etc/init.d/mihomoを作成します。

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

START=99
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="65535 65535"
  procd_close_instance
}

reload_service() {
  procd_send_signal mihomo HUP
}

service_triggers() {
  procd_add_reload_trigger "network"
}

実行権限を付与してサービスを有効化します。

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

respawn 3600 5 5は、監視期間内の異常終了を処理して遅延再起動する設定です。プロセスが高頻度でクラッシュした際の短時間ループを防ぎます。設定内のリモートルールセットがネットワーク接続を必要とする場合、初回起動時はWANの準備が整っていない影響を受けることがあります。必要なルールファイルをあらかじめローカルへ置くか、ネットワーク接続後に更新タスクを別途実行してください。毎回の起動時にすべてのリモートリソースを即時取得する設計は避けます。

分流、安全な境界、よくあるトラブル

予約アドレスは必ず直接接続する

透過プロキシのルールでは、ローカルループバック、LAN、マルチキャスト、予約アドレスを除外します。例：127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、224.0.0.0/4。家庭内ネットワークで複数のプライベートサブネットを使用している場合は、静的ルートで相互接続するネットワークも明確にしてください。NAS、プリンター、管理画面を無差別にプロキシすると、迂回経路になったり、ルーターの管理画面を開けなくなったりします。

制御インターフェースは管理ネットワークだけに公開する

9090の制御インターフェースでは、プロキシグループの切り替え、接続情報の取得、実行状態の変更ができます。通常はループバックアドレスにバインドしてください。LANからダッシュボードを使う場合は、ルーターのLANアドレス、例として192.168.10.1:9090にバインドし、secretを設定したうえで、ファイアウォールで送信元を制限します。プロキシポートもLANのファイアウォールゾーンだけで開放し、WANからの接続を受け付けないでください。

コア起動後も端末がインターネットへ接続できない

  1. ルーターでip routeを実行し、デフォルトルートが実際のWANを向いていることを確認します。
  2. nslookup openwrt.org 127.0.0.1を実行し、基本DNSが正常に動作していることを確認します。
  3. PCをルーターの7890ポートへ手動接続し、ノードとサブスクリプションの問題を切り分けます。
  4. nft list rulesetを実行し、透過プロキシのチェーンが実際に存在し、カウンターが増加していることを確認します。
  5. 端末のゲートウェイとDNSが、計画したメインルーターまたは旁路ルーターのアドレスを向いているか確認します。

中国本土のサイトは正常だが、一部の海外サイトがタイムアウトする

まずプロキシグループで利用可能なノードが選択されているかを確認し、ドメインの名前解決結果とルール適用状況を比較します。大きなページ、アップロード、動画の接続だけが失敗する場合はMTUをテストします。PPPoE回線は通常、イーサネットより8バイト小さく、別のトンネルを重ねるとさらに小さくなります。パケットサイズを段階的に下げて変化を確認できますが、すべての障害をMTUが原因だと決めつけないでください。

ルーターからはアクセスできるが、LAN端末からはアクセスできない

この場合、mihomo自身の外向き通信は正常ですが、LANからの転送経路が透過プロキシへ入っていない可能性があります。メインルーターではLANからWANへの転送と透過プロキシルールを確認します。旁路ルーターではnet.ipv4.ip_forward、ファイアウォールゾーン、端末のゲートウェイを確認してください。端末が引き続きメインルーターをゲートウェイにしている場合、通信が旁路ルーターを通らないのは当然です。

再起動後もサービスは存在するが、ルールが有効にならない

サービスの起動とファイアウォールの読み込みには、順序の違いがあります。TProxyルールを独立したスクリプトで生成する場合は、firewall4のincludeまたはホットプラグ機構に組み込み、繰り返し実行しても重複チェーンを作らないようにします。TUNの自動ルートを使用する場合は、起動ログにインターフェース作成、ルーティングテーブル、権限に関するエラーがないか確認し、起動時に/dev/net/tunが利用可能であることも確認してください。

導入後の確認チェックリスト

ルーターでコアを直接動かす際に重要なのは、プロセスが「実行中」と表示されることではなく、通信経路全体を予測可能かつ復旧可能にすることです。家庭内ネットワークを正式に引き継ぐ前に、次の項目を一つずつ確認してください。

  • コアのアーキテクチャが機器と一致し、mihomo -vでバージョン情報が正常に返る。
  • mihomo -tで設定チェックに合格し、サブスクリプション更新に失敗しても既存設定が上書きされない。
  • 7890の通常プロキシポートを個別に検証し、ノードとプロキシグループが接続を確立できる。
  • メインルーターまたは旁路ルーターのゲートウェイ、DHCP、DNSの役割が明確で、DHCPサービスが競合していない。
  • TUNまたはTProxyの主要な引き継ぎ経路を1つだけ有効にし、同じ接続を二重にリダイレクトしていない。
  • LAN、ルーター管理アドレス、マルチキャスト、必要な予約ネットワークをプロキシから除外している。
  • 制御インターフェースにアクセスキーを設定し、ファイアウォールで信頼できる管理ネットワークに限定している。
  • 機器再起動後、WAN、時刻、DNS、mihomo、透過プロキシルールが順番どおり復旧する。
  • Webページ、動画、UDPアプリ、LAN内のNAS、プリンターへのアクセスを個別にテストする。
  • 速度測定時は、単発の帯域結果だけでなくCPU、メモリ、ソフトIRQ、温度も記録する。

初回導入では、まず通常のmixed-portと1台のテスト端末から始め、その後TUNまたはTProxyへ拡張することをおすすめします。メインルーター構成は経路がより直接的で、一括管理に適しています。旁路ルーター構成は段階的な移行がしやすく、少数の機器から始めるのに向いています。どちらの構成を選ぶ場合でも、設定構文、DNS経路、ファイアウォールルール、自動起動後の復旧をそれぞれ検証できる状態にしてください。