まず通信が通る経路を確認する

OpenWrtでmihomoを起動しても、プロキシのコアが動作しているだけで、LAN内の端末が透過プロキシを利用しているとは限りません。通信経路は少なくとも3段階に分かれます。端末からバイパスルーターへ通信を送り、バイパスルーターが対象の接続をコアに渡し、コアがルールに応じて直結またはプロキシ経由で通信します。DNSも別途設計が必要です。デフォルトゲートウェイを変更しただけで設定完了とはいえません。

mihomoはClash Metaから発展したプロキシコアであり、GUIを備えたデスクトップクライアントではありません。ルーター用プラグインは通常、コアのダウンロードや設定ファイルの生成、ファイアウォールルールの作成、サービス管理を担います。コアを直接導入する場合は、これらを自分で行う必要があります。すでにプラグインがネットワークを制御している端末では、別の透過プロキシルールを手動で重ねないでください。

まず1台の端末でテストする

メインルーターの既存のDHCP設定は維持し、テスト用PC 1台だけのゲートウェイとDNSを変更します。管理画面、LAN内アクセス、プロキシ接続が正常に動作することを確認してから、ネットワーク全体への設定を検討してください。作業前にローカルの管理手段を確保し、変更中のプロキシ経路を使って遠隔からネットワークを操作するのは避けましょう。

よくある3つの設置構成

構成通信の入口主な確認項目
メインルーターでコアを動かす端末のデフォルトゲートウェイがOpenWrtWAN側の出口、転送ゾーン、DNS、ルーティング制御
同一サブネットのシングルアーム構成端末のデフォルトゲートウェイにバイパスルーターを指定同一インターフェース間の転送、戻り経路、ICMPリダイレクト
別サブネットのバイパスルーター端末をバイパスルーター配下のサブネットに接続上位ルーターの静的ルートまたはNAT、下位側のDHCP、サブネット間通信

メインルーター構成は経路がシンプルですが、障害時の影響範囲が広くなります。同一サブネットのシングルアーム構成は段階的なテストに向いていますが、往路はバイパスルーターを通る一方、復路は端末へ直接戻るといった不整合が起きやすくなります。別サブネット構成は境界が明確になる反面、追加のルートやNATを管理する必要があります。選択の基準は機器のLANポート数ではなく、現在のネットワーク構成です。

ゲートウェイとDNSの設定先

以下は説明用のアドレスであり、実測値ではありません。メインルーターは192.168.10.1、OpenWrtのバイパスルーターは192.168.10.2、テスト端末は192.168.10.100で、サブネットマスクはいずれも255.255.255.0です。バイパスルーターのデフォルトルートはメインルーターを指し、テスト端末のデフォルトゲートウェイはバイパスルーターを指します。

テスト端末 192.168.10.100
  デフォルトゲートウェイ：192.168.10.2
  DNS：192.168.10.2
        ↓
OpenWrt バイパスルーター 192.168.10.2
  デフォルトゲートウェイ：192.168.10.1
        ↓
メインルーター 192.168.10.1
        ↓
インターネット

ゲートウェイは通信経路、DNSは問い合わせ先を決める

  • DNSだけ変更：ドメイン名の問い合わせはバイパスルーターに届いても、実際の通信はメインルーターを経由する可能性があります。これだけで透過プロキシが有効になったとは判断できません。
  • ゲートウェイだけ変更：通信がバイパスルーターを経由しても、端末は従来のDNSサーバーに問い合わせる可能性があります。ドメイン名に基づく判定や名前解決のルールが想定どおりに動かないことがあります。
  • 両方を変更：経路を統一してテストしやすくなりますが、バイパスルーターで転送が許可され、実際に通信が適切に取り込まれていることも確認してください。

一般的なLuCIでは、「ネットワーク」→「インターフェース」→「LAN」→「編集」から固定アドレスを確認できます。デフォルトゲートウェイとDNSの設定場所はファームウェアのバージョンによって異なります。メインルーターがDHCPを担当する場合、ネットワーク全体に配布する設定は通常、DHCPオプション3（デフォルトゲートウェイ）と6（DNSサーバー）に該当します。同じブロードキャストドメインで、連携していないDHCPサーバーをメインルーターとバイパスルーターの両方で有効にしないでください。端末ごとに異なるゲートウェイが割り当てられるおそれがあります。

同一サブネットのシングルアーム転送では、ICMPリダイレクトも確認してください。ルーターの動作によっては端末にメインルーターを直接使うよう通知され、想定した経路を迂回することがあります。送信元アドレス変換が必要かどうかは、戻り経路と通信の取り込み方法によって異なります。「マスカレードを有効にする」ことを万能な解決策と考えないでください。コアや上位ルーターから見える送信元アドレスが変わり、端末ごとのルールやログに影響する場合があります。

導入前にシステムとコアを確認する

まずCPUアーキテクチャ、利用可能なストレージ、ファイアウォールの仕組みを確認してから、実行ファイルを選びます。OpenWrtのパッケージ用アーキテクチャ名と、上流のリリースパッケージ名は完全には一致しない場合があります。機器の商品名だけで選ばないでください。ARM機器では32ビット・64ビットの違いと具体的な命令セットを確認し、x86機器でもCPUが選択したビルドに対応しているかを確認します。

ubus call system board
uname -m
df -h /overlay
free
command -v fw4
command -v nft
ls -l /dev/net/tun
ip route show
ip -6 route show

公式のOpenWrt 23.05および24.10系でよく見られる環境では、通常firewall4がnftablesを管理します。サードパーティ製ファームウェアでは関連コンポーネントが変更されている場合があるため、実機で確認してください。旧バージョン向けの解説にあるiptablesコマンドを、現行システムでそのまま使える方法と見なさないでください。特に、同じ接続を複数のルールセットで管理しないようにしましょう。

設定を検証してからサービスを起動する

ここでは、コアの配置先を/usr/bin/mihomo、作業ディレクトリを/etc/mihomo、設定ファイルを/etc/mihomo/config.yamlとします。これらは本記事で使用するパスであり、すべてのプラグインの既定値ではありません。ルールファイル、地理データ、キャッシュも実際の設定に合わせて配置し、YAMLだけをコピーして実行時の依存ファイルを見落とさないようにしてください。

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

-vで実際のコアのバージョンを確認し、-tで設定をテストします。テストに成功しても、コアが設定を受け付け、必要なファイルを読み込めたことを示すだけで、端末のルーティングやファイアウォールが正しいとは限りません。初回のトラブルシューティングではフォアグラウンドで起動してログを確認し、その後OpenWrtのprocdで管理します。プラグインが管理している場合は、プラグインのサービス画面から操作し、コアを二重起動しないでください。

まずローカルのプロキシとDNSの基準を作る

透過プロキシを設定する前に、明示的なプロキシ接続をテストしましょう。以下の設定は、ローカルの待ち受けと直接接続の基準を作るだけで、プロキシノードを含まず、端末を自動的にプロキシ経由にするものでもありません。実際に導入するときは、有効な設定ファイルに統合してください。同じトップレベル項目をファイル末尾に重複して追加しないようにします。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - MATCH,DIRECT
  • mixed-port: 7890：明示的なHTTP/SOCKSプロキシ用のポートで、透過プロキシの入口ではありません。テストPCからこのポートに接続するには、LANからの待ち受け設定と厳格なアクセス制限が別途必要です。
  • allow-lan: false：この基準設定では、明示的なプロキシサービスをLANに公開しません。TUNによる転送通信の取り込みは、このポートを公開することとは別の機能です。
  • 127.0.0.1:9090：コントローラーはローカルホストのみで待ち受けます。遠隔管理が必要な場合は、認証とアクセス範囲を別途設計し、インターネットに直接公開しないでください。
  • 127.0.0.1:1053：DNS問い合わせはローカルからの転送のみ受け付けます。dnsmasqの待ち受けと直接競合しないよう、ここではポート53を使いません。
  • MATCH,DIRECT：どのルールにも一致しない接続をすべて直接接続にします。まず通信経路を確認するための設定です。プロキシ経由にするには、有効なノード、プロキシグループ、対応するルールを追加する必要があります。

機器にcurlとnslookupがインストールされていれば、バイパスルーター上で明示的なプロキシ接続とLAN向けDNSをそれぞれテストできます。例に使うドメイン名は疎通確認用であり、応答時間からプロキシノードの品質は判断できません。

curl --proxy http://127.0.0.1:7890 -I https://example.com
nslookup example.com 192.168.10.2

DNSの転送経路は1つに絞る

確認しやすい構成の一例は、端末からバイパスルーターの53番ポートへ問い合わせ、dnsmasqからローカルのmihomoの1053番ポートへ転送する方法です。一般的なLuCIでは、「ネットワーク」→「DHCP/DNS」→「一般設定」→「DNS転送」を開き、127.0.0.1#1053を指定します。同時に、上流から別のDNSサーバーを取得していないかも確認してください。外部への問い合わせをすべてコア経由にする場合は、ファームウェアの画面に合わせて「resolvファイルを無視」などの設定を調整し、必要なローカルドメインの処理は維持します。

DNSループを防ぐ

dnsmasqからmihomoへ問い合わせを転送している場合、mihomoの上流DNSを同じdnsmasqの転送経路に戻してはいけません。ここで示す数値IPの上流は経路の説明用であり、すべての環境に推奨する値ではありません。ドメイン名を使う暗号化DNSに切り替える場合は、上流ドメインの名前解決方法と、上流への接続が直接接続かプロキシ経由かも検討してください。

透過プロキシで通信を取り込む3つの方法

透過プロキシとは、端末のアプリごとにプロキシアドレスを設定せずに済む仕組みです。すべてのプロトコルが自動的にプロキシを利用できるわけではありません。実際に適用される範囲は、取り込み方式、コアの対応状況、ノードのプロトコル、ファイアウォールルールによって決まります。UDP、IPv6、LAN内宛ての通信は個別に確認してください。

方式基本的な仕組み導入時の注意点
REDIRECTファイアウォールで接続を透過プロキシの待ち受けポートへリダイレクトする主にTCPで使用します。TCPのリダイレクトルールをUDPの完全な取り込みに流用することはできません。
TPROXY透過ソケットとトラフィックマーク、ポリシールーティングを組み合わせるTCPとUDPに利用できます。対応するカーネルモジュール、ルート、ファイアウォールルールが必要です。
TUN仮想レイヤー3デバイスを介してIP通信をコアに渡すTUNのサポートと権限が必要です。ルーティングとLAN転送が取り込み経路に入るかも確認してください。

主な方式を1つ選んで設定してください。「カバー範囲を広げる」ために、プラグインのTPROXY、自作のREDIRECT、別のTUN自動ルーティングを同時に有効にしないでください。設定を重ねると、同じ接続がコアに二重に渡ったり、マークが競合したり、ルーティングループが発生したりすることがあります。一部のサイトだけ開けて、ほかの接続がタイムアウトし続ける原因になります。

TUN設定項目の例

以下の設定例は、対応する項目を備えたLinux版mihomoビルドを対象に、TUNによる通信取り込みの仕組みを説明するものです。すべてのOpenWrtファームウェアでそのまま使える設定ではありません。実際に使用するコアで設定をテストし、起動ログ、生成されたルール、ルーティングを確認してください。古いビルドでは一部の項目が認識されない場合があります。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack: []
  • enable：TUNを有効にします。システムでTUNデバイスを利用できることと、必要なネットワーク管理権限があることを確認してください。
  • stack: mixed：混合プロトコルスタックを選択します。複数の透過プロキシ入口を同時に有効にする設定ではありません。
  • auto-route：コアに関連する自動ルートを設定させます。LAN側のゲートウェイ設定を代替するものではなく、ファームウェアのすべての転送ポリシーで通信が許可される保証もありません。
  • auto-redirect：対応するLinux環境では、自動ルーティングと連携して通信取り込みに必要なルールを作成します。firewall4、既存プラグイン、ポリシールーティングと競合しないか、実機で確認してください。
  • strict-route：取り込み時のルーティング動作を厳密にします。ただし、IPv6やすべての迂回経路の検証が完了したことを意味するものではありません。
  • dns-hijack: []：この例ではTUNによるDNSハイジャックを行わず、前述のdnsmasq転送経路を使用します。初回の導入時に、2種類のDNS取り込みを重ねないためです。

TUNでDNSも取り込む場合は、問い合わせの入口、上流DNS、除外ルールをあらためて確認してください。any:53をコピーするだけで設定完了とはなりません。従来のUDP/TCPポート53による問い合わせ、アプリ内蔵のDoH、OSのプライベートDNSはそれぞれ異なる経路です。ポート53を取り込んでも、アプリ内の暗号化DNSが自動的に対象になるわけではありません。

IPv6、戻り経路、ファイアウォールの境界

IPv4でテストに成功しても、デュアルスタック端末のすべての接続がバイパスルーターを経由するとは限りません。メインルーターがIPv6のルーター広告で端末にデフォルトルートを配布していると、AAAAレコードを持つサイトへの通信が別経路を通ることがあります。DHCPv4のオプション3と6を変更しても、このIPv6経路は制御できません。

  1. まずテスト端末でIPv4とIPv6のデフォルトルートを確認し、実際の次ホップを特定します。
  2. IPv4とIPv6の両方を取り込むのか、まずテスト対象をIPv4に絞るのかを明確にしてください。mihomoのIPv6向けDNS応答を無効にしただけで、システムのIPv6通信まで無効になるわけではありません。
  3. LANから上流への転送権限、同一インターフェース間の転送、関連するファイアウォールゾーンを確認します。トラブルシューティングのために、すべてのゾーンの入力と転送を許可する設定には変更しないでください。
  4. ルーターの管理用アドレス、LANのサブネット、プロキシサーバー自身への接続が迂回する経路を確認し、出口への接続が再び取り込み口へ送られないようにします。

nft list rulesetでファイアウォールルールを、ip rule showとip route show table allでポリシールーティングを確認できます。出力内容は、導入済みのプラグインとファームウェアに照らして判断してください。実装ごとにテーブル番号、ルール名、優先度が異なるため、特定の番号や名前だけで成功と判断しないでください。

段階ごとの検証と安全な切り戻し

トラブルシューティングでは、通信の入口から出口に向かって段階ごとに確認し、一度に変更する項目は1つにします。Webページが開けても、利用できた経路が直接接続、明示的なプロキシ、透過プロキシのどれかは判断できません。端末のルート、コアの接続ログ、実際に適用されたポリシーをあわせて確認してください。

症状まず確認する項目次の手順
端末からバイパスルーターの管理画面を開けないIPアドレス、サブネットマスク、アドレスの重複、入力ルールまずLAN内の管理アクセスを復旧し、透過プロキシの変更は続けない
IPアドレスには接続できるが、ドメイン名を解決できないポート53と1053の待ち受け、dnsmasqの転送、DNSループLAN側のDNS入口とコアの上流DNSを個別に確認する
ローカルの明示的なプロキシは動くが、端末の接続ログがないデフォルトゲートウェイ、IPv6、転送、通信取り込みルール通信が実際にバイパスルーターへ届いているか確認する
TCPは正常だが、ゲームや音声通話に問題があるUDPの取り込み、ノードのUDP対応、ファイアウォール該当するプロトコルで再テストし、Webページの結果だけで判断しない
ファイアウォールの再読み込み後に接続できなくなった自動で作成される通信取り込みルールが残っているか該当サービスからルールを再作成し、サービスの起動順序を確認する

切り戻しは端末の設定から戻し、その後にサービスを停止する

テストに失敗した場合は、まずテスト端末のデフォルトゲートウェイを192.168.10.1に戻し、DNSも元の有効な設定に戻します。その後、追加したサービスを停止し、サービスが作成した通信取り込みルールを削除してください。TUN終了後のルートも確認が必要です。実行ファイルを削除するだけでは不十分です。DHCPの設定をネットワーク全体で変更していた場合は元に戻し、端末のリースを更新してください。

構成が安定したら、procdによる自動起動、ログ容量、設定更新の手順を整えます。設定を更新する前にテストを実行し、ノード名とプロキシグループの参照が一致していることを確認してからサービスを再読み込みしてください。ファイアウォールやルーティングを更新した場合は、端末のDNS、TCP、UDP、IPv6、LAN内アクセスも再確認します。各項目の説明は設定リファレンス、基本的なインポート手順とクライアントの操作はインストール・設定ガイドを参照してください。