プラットフォーム別導入 読了目安 15分

ルーター・透過ルーターへの Clash コア導入ガイド：OpenWrt、Raspberry Pi構成とDNSの引き継ぎ

メインルーターと透過ルーターで Clash コアを動かす構成を整理。OpenWrtプラグインとRaspberry Pi単体構成を比較し、透過プロキシとDNS引き継ぎの注意点を解説します。

まず構成を決める：メインルーター導入か透過ルーター導入か

Clash Meta（現在よく使われるコア名は mihomo）を家庭内ネットワークに配置する場合、パソコンでデスクトップクライアントを動かす場合とは大きく異なります。デスクトップクライアントは通常、その端末の通信だけを処理します。一方、ルーター構成では転送、ポリシールーティング、DNS、IPv4、IPv6を同時に扱い、プロキシ自身の上流接続を再びプロキシへ通さない設計も必要です。導入前に通信経路を図にして整理することが、プラグインを直接インストールするより重要です。

構成1：メインルーターで Clash コアを動かす

メインルーターがダイヤルアップ接続、DHCP、NAT、ファイアウォール、透過プロキシを直接担当します。端末のデフォルトゲートウェイは自然にこの機器を指すため、端末ごとにネットワーク設定を変更する必要がありません。OpenWrtを例にすると、ルーターのLANアドレスを 192.168.10.1、DHCPアドレスプールを 192.168.10.100–192.168.10.249 とし、クライアントのゲートウェイとDNSはDHCPから 192.168.10.1 として自動配布できます。

  • メリット：通信の入口を一元化でき、端末を接続するだけでルールを適用できます。ゲストネットワークや独立したVLANも個別に制御できます。
  • 制約：プロキシ、ダイヤルアップ、無線、NATが同じ機器のCPUとメモリを共有するため、設定ミスがLAN全体に影響する可能性があります。
  • 適する環境：十分な性能を持つx86 OpenWrt、小型ソフトルーター、またはクアッドコアARM64ルーター。

構成2：透過ルーターで Clash コアを動かす

透過ルーターとメインルーターを同じLANに配置します。メインルーターを 192.168.10.1、透過ルーターを 192.168.10.2 とすると、透過ルーター自身のデフォルトゲートウェイは引き続き 192.168.10.1 を指します。プロキシを利用する端末では、デフォルトゲートウェイとDNSを 192.168.10.2 に設定します。通信はいったん透過ルーターに入り、透過プロキシで判定された後、メインルーター経由でインターネットへアクセスします。

この片腕型の透過ルーターはイーサネットインターフェースを1つだけ持ち、受信と送信の通信が同じNICを通ります。ギガビットネットワークでインターネット転送を行うと、このインターフェース上で双方向の送受信が発生しますが、通常それだけで速度が半分になるわけではありません。実際のボトルネックは、暗号化スループット、ルールマッチング、USB NICの品質、メインルーターへの戻り経路に起因することが多いです。

比較項目 メインルーターで実行 透過ルーターで実行
端末側の変更 通常は不要 ゲートウェイ、DNS、またはDHCP配布設定の変更が必要
障害時の影響 ネットワーク全体の出口に影響する可能性がある ゲートウェイをメインルーターへ戻せば復旧できる
ハードウェアの選択 ルーターの仕様に制約される Raspberry Pi、ミニPC、古いパソコンを利用できる
ネットワークの複雑さ 転送経路が単純 戻り経路、DHCP、IP転送の確認が必要

OpenWrtプラグインとRaspberry Pi単体構成の選び方

OpenWrtプラグイン構成では、コア、設定サブスクリプション、ルール更新、ファイアウォール連携、実行ログを同じ管理画面で扱えます。一方、Raspberry Pi単体構成では通常、mihomoバイナリを直接実行し、systemd、nftables、dnsmasqを組み合わせて一連の経路を構築します。基本的な機能は近く、主な違いは保守方法と障害箇所を特定できる細かさです。

OpenWrtプラグイン構成

OpenWrt 24.10シリーズとOpenClash管理画面を例にすると、一般的な操作経路は「サービス」→「OpenClash」→「設定ファイル購読」です。購読URLを追加し、更新間隔を設定します。続いて「サービス」→「OpenClash」→「プラグイン設定」で、動作モード、DNS引き継ぎ方式、アクセス制御を選択します。プラグインのバージョンによってメニュー名は多少異なりますが、設定の考え方は基本的に同じです。

  1. デバイスのアーキテクチャを x86_64、aarch64_cortex-a53、mipsel_24kc などから確認し、アーキテクチャに合ったコアファイルを使用します。
  2. 永続化領域を確保します。ルールセット、Geoデータ、ログ、複数の設定ファイルで80 MB以上を消費する場合があるため、フラッシュ容量が16 MBしかない古い機器は大量のデータを長期保存する用途に向きません。
  3. まずルールモードで起動し、TCP、UDP、DNSを個別にテストします。実験的なオプションを最初からすべて有効にしないでください。
  4. 「実行状態」または「デバッグログ」で、設定の解析完了、透過プロキシルールの正常な書き込み、DNS待受ポートの競合がないことを確認します。

LuCIでサブスクリプションとアクセス制御を管理したい環境には、プラグインが適しています。OpenWrtをアップグレードする前に、プラグイン設定、設定ファイルの場所、カスタムファイアウォールルールを記録してください。ファイアウォール3とファイアウォール4では基盤実装が異なります。OpenWrt 22.03以降の主流バージョンはfirewall4とnftablesを採用しており、古い手順にあるiptablesコマンドをそのまま流用できない場合があります。

Raspberry PiまたはDebian単体構成

Raspberry Pi 4B、Raspberry Pi 5、Debian 12を動かすARM64ミニPCはいずれも透過ルーターとして利用できます。64ビットOS、有線LAN、安定した電源を推奨します。Raspberry Pi 4BのオンボードギガビットLANは一般的な家庭内経路に適しています。USB 3.0 NICを接続する場合は、チップのドライバーが安定していることを確認し、パケットロスと再接続ログを継続的に監視してください。

単体構成では mihomo を /usr/local/bin/mihomo に配置し、設定ディレクトリを /etc/mihomo としてsystemdで常駐させます。以下のサービスファイルは必要な構造を示したものです。実際の導入では専用ユーザーも作成し、そのユーザーに設定ディレクトリの読み書き権限を与えてください。

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

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

/etc/systemd/system/mihomo.service として保存した後、systemctl daemon-reload、systemctl enable --now mihomo、journalctl -u mihomo -n 100 の順に実行します。透過プロキシルールを書き込む前に、mihomo -t -d /etc/mihomo を実行してYAML構文を確認してください。解析に失敗した状態で起動時のファイアウォールルールを書き込むと、通信だけがリダイレクトされ、コアが待ち受けていないためネットワークが切断されることがあります。

透過プロキシ：REDIRECT、TProxy、TUNの違い

ルーター導入で重要なのは、HTTPやSOCKSのポートを1つ開放することではありません。手動プロキシに対応しないテレビ、ゲーム機、IoT機器の通信もルールで処理できるようにすることです。一般的な方式にはREDIRECT、TProxy、TUNがあります。いずれもLANアドレス、コア自身の通信、プロキシサーバーのアドレスを正しく除外する必要があり、設定を誤るとプロキシループが発生します。

REDIRECT：主にTCPを処理

REDIRECTは、ファイアウォールを通過するTCP接続をmihomoの透過プロキシポートへリダイレクトします。たとえば redir-port: 7892 です。実装が簡単で、WebやアプリのTCP通信をまず検証する用途に適しています。ただし、元の宛先情報を保持する必要があるすべてのUDP通信を完全には扱えないため、音声、ゲーム、QUICではTProxyまたはTUNが必要になる場合があります。

TProxy：TCPとUDPを同時に処理

TProxyは通常、tproxy-port: 7893 のような専用ポートを使用し、ポリシールーティング、パケットマーク、カーネルモジュールに依存します。ファイアウォールで通信にfwmarkを付け、ip rule とローカルルーティングテーブルを通じてmihomoへ渡します。UDP透過プロキシ、DNSクエリ、一部のリアルタイム通信では、より完全なルール設定が求められます。

  • ループバックアドレス、マルチキャストアドレス、LANセグメント、ルーター管理アドレスを必ず除外します。
  • プロキシノードサーバーへの接続は上流へ直接到達させ、再び透過プロキシに入らないようにします。
  • mihomoプロセス自身の通信を除外するか、ルーティングマークで処理済みのパケットを区別します。
  • コアにTPROXY、ポリシールーティング、nftablesの対応機能が含まれているか確認します。

TUN：仮想NICでIP通信を受け取る

TUNモードでは仮想ネットワークインターフェースを作成し、mihomoがIP層の通信を受け取ります。デスクトップOSでよく使われる方式ですが、透過ルーターでも利用できます。ただし、転送、ルーティング、DNSの連携は引き続き必要です。基本設定には次のような項目が含まれます。

mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  strict-route: true

mixed-port: 7890 は明示的なHTTP・SOCKSプロキシのテストに使用します。透過プロキシにはREDIRECT、TProxy、TUNの経路を使用します。管理インターフェースを 127.0.0.1:9090 にバインドすれば、LAN全体へ直接公開せずに済みます。他の端末から管理インターフェースへアクセスする必要がある場合は、ファイアウォールで管理セグメントだけを許可し、コントローラーキーを設定してください。

TUNの auto-route と auto-redirect は手動ルールを減らせますが、すべてのルーター環境でそのまま有効にできるわけではありません。OpenWrtプラグインには独自のファイアウォール管理ロジックがあることが多く、コアの自動ルーティングを重ねると二重管理になる可能性があります。導入時には、プラグイン、起動スクリプト、mihomoのどれがルーティングを担当するのかを明確にし、制御元を1つに絞ってください。

DNSの引き継ぎ：漏えい、汚染、名前解決ループを防ぐ

透過プロキシは接続の転送方法を決めるだけで、DNSはドメイン名を最初にどのアドレスへ解決するかを決めます。端末がメインルーターやISPのDNSへ直接問い合わせ続けると、ルールから見えるのは宛先IPだけになり、ドメインルールのマッチ率が低下する場合があります。DNSリクエストがプロキシ経路と直接経路の間で繰り返し入り直すと、Webページの待ち時間が長くなったり、一部ドメインだけ断続的に失敗したりします。

推奨する通信経路

透過ルーターでは、dnsmasqにLANの 53 ポートを待ち受けさせ、リクエストをmihomoの 127.0.0.1:1053 へ転送できます。あるいは、端末から他のDNSへ送られるTCP/UDP 53番ポートの通信を、ファイアウォールでローカルへリダイレクトします。mihomoのDNSモジュールは、ドメインルールに応じて直接接続用またはプロキシ用のリゾルバーを選択します。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

default-nameserver にはIPアドレスを指定し、主にDoHサーバー自身のドメイン名を解決します。これにより、起動時に「ドメイン名が先かDNSが先か」という依存ループを避けられます。nameserver は実際の問い合わせ先です。さらに複雑な設定では、nameserver-policy でドメインごとに異なるリゾルバーを選択できますが、まず基本的な名前解決が安定してからポリシーを追加してください。

fake-ipとredir-hostの使い分け

fake-ip は予約済みアドレスプールから一時アドレスを返し、mihomoがマッピングから元のドメイン名を復元します。そのためドメインルールを直接マッチさせやすくなります。例にある 198.18.0.1/16 はベンチマーク用の予約済みセグメントで、通常はパブリックIPと競合しません。LAN内ドメイン、プリンター検出、NTP、実IPに依存する一部アプリは fake-ip-filter に追加できます。

redir-host は実際の名前解決結果を返すため、互換性の確認は直感的です。一方、透過プロキシの段階ではスニッフィングやIPルールへの依存が大きくなる場合があります。LAN機器の検出に失敗しても、すぐにDNS引き継ぎをすべて無効にせず、まず対象ドメインを確認して、必要なものだけを正確な除外項目に追加してください。

IPv6は個別に検証する

IPv4だけを引き継ぎ、端末へIPv6のデフォルトルートを配布し続けると、IPv6対応アプリが既存のポリシーを迂回する可能性があります。単純にすべてのAAAAレコードを削除するのではなく、ネットワークの能力に応じて、IPv6を完全にプロキシする、指定したIPv6セグメントだけ直接接続する、準備が整うまでテストセグメントへIPv6のデフォルトルートを配布しない、といった方法を選びます。少なくともAとAAAAを個別に問い合わせ、IPv4のみのサイトとIPv6対応サイトを1つずつテストしてください。

透過ルーターの導入手順：1台のテストからネットワーク全体へ

透過ルーターは段階的に導入するのが適しています。まず1台のパソコンだけを透過ルーター経由にし、その後、対象のデバイスグループへ徐々に広げるほうが、ネットワーク全体のDHCPを直接変更するより問題を特定しやすくなります。以下の例でも、メインルーターは 192.168.10.1、透過ルーターは 192.168.10.2 とします。

  1. 透過ルーターのアドレスを固定：LANアドレスを 192.168.10.2/24、デフォルトゲートウェイを 192.168.10.1 に設定し、メインルーターのDHCP動的割り当て範囲と重ならないようにします。
  2. IP転送を有効化：Linuxでは sysctl net.ipv4.ip_forward を確認し、結果が 1 になることを確認します。IPv6転送が必要な場合は、対応するパラメーターも個別に確認してください。
  3. 通常の転送を確認：Clashをまだ有効にせず、テスト用パソコンのゲートウェイを 192.168.10.2 に変更します。この状態でインターネットへ接続できない場合は、まずルーティング、NAT、戻り経路を修正してください。プロキシ設定の問題と決めつけてはいけません。
  4. 明示的プロキシを確認：mihomoを起動した後、テスト用パソコンのHTTPまたはSOCKSプロキシを 192.168.10.2:7890 に手動設定し、ノード、サブスクリプション、ルールが動作することを確認します。
  5. 透過プロキシを有効化：まずTCPを処理し、その後UDPをテストします。ログで、インバウンドの種類、宛先アドレス、マッチしたルール、最終的なプロキシグループを確認します。
  6. DNSを引き継ぐ：テスト用パソコンのDNSを 192.168.10.2 に変更し、nslookup または dig で応答サーバー、応答時間、A・AAAAの結果を確認します。
  7. 対象範囲を広げる：安定動作を確認したら、メインルーターのDHCPで指定端末のゲートウェイとDNSを透過ルーターのアドレスとして配布するか、VLANで1つのテストセグメントだけを引き継ぎます。

テストでは具体的な数値を記録してください。LANから透過ルーターまでの有線遅延は通常1 ms未満が目安です。DNSの初回問い合わせが継続して2秒を超える場合は、DoHの接続確立、上流ルート、ループバックを確認します。ルールを切り替えた後は、名前解決と接続を20回連続でテストし、断続的なタイムアウトがないことを確認します。速度テストは特定時点のスループットしか示さないため、パケットロス、遅延、長時間接続のテストの代わりにはなりません。

DHCP配布の2つの方法

  • ネットワーク全体へ配布：DHCPオプション3でデフォルトゲートウェイを 192.168.10.2、オプション6でDNSを 192.168.10.2 に指定します。透過ルーターが安定稼働しているネットワークに適しています。
  • 端末ごとに配布：テスト用パソコン、テレビ、ゲーム機に静的リースを設定し、それらの端末だけに透過ルーターのゲートウェイとDNSを割り当てます。業務用端末と管理端末は引き続きメインルーターを経由させます。

家庭用メインルーターの中には、ゲートウェイを一律にしか配布できず、端末ごとの設定に対応しないものがあります。その場合はテスト端末を手動設定するか、独立したゲストネットワークを分けてください。重複NAT、ブリッジ、ポリシールーティングを同じ問題の対策として同時に使わないでください。経路の階層が増えるほど、戻り経路の不一致を特定しにくくなります。

よくある障害と確認の順番

端末から透過ルーターにはアクセスできるが、インターネットへ接続できない

まずmihomoと透過プロキシルールを停止し、基本的な転送だけを確認します。透過ルーターのデフォルトルートがメインルーターを指していること、IP転送が有効であること、メインルーターが端末セグメントへの戻り方を把握していることを確認してください。片腕型の透過ルーターは通常同じ /24 セグメント上にあります。独立したサブネットを使う場合は、メインルーターに静的ルートを追加するか、透過ルーターで送信元アドレス変換を行う必要があります。

Webページは開けるが、ゲームや音声通信に失敗する

これは通常、TCP経路は正常でもUDPがプロキシに入っていないか、プロキシノードが必要なUDPに対応していないことを示します。TProxyまたはTUNが有効か、UDPルールが書き込まれているか、ファイアウォールが関連モジュールを読み込んでいるかを確認し、接続ログにUDPインバウンドが現れるか確認します。QUICはUDP 443を使用します。ブラウザーのQUICを無効にするのは切り分けには使えますが、正しいUDP設定の代わりにはなりません。

日本国内のサイトへの経路が遠回りになる、またはLAN機器にアクセスできない

ルールの順序を確認します。LANセグメント、ルーター管理アドレス、プライベートアドレスは、フォールバックのプロキシルールより前に直接接続へ振り分ける必要があります。ルールは上から順にマッチし、末尾の MATCH は未マッチのすべてのリクエストを受け取ります。LAN内ドメインに .lan や .local を使用している場合は、fake-ipの除外設定とローカルDNS転送も確認してください。

再起動後、一時的にネットワークへ接続できない

ファイアウォールルールが先に読み込まれ、mihomoが設定解析やDNS初期化を完了していない可能性があります。systemdサービスは network-online.target を待機するようにし、ファイアウォールスクリプトもコアの待受ポートが利用可能になってから通信を引き継ぐようにします。設定、Geoデータ、キャッシュが、再起動で消去される一時ディレクトリではなく永続ストレージにあることも確認してください。

CPU使用率が高い、またはスループットが大幅に低下する

まず暗号化性能、ルール処理、ログ書き込みを切り分けます。ログレベルは info に保ち、障害調査時だけ一時的に debug へ切り替えます。大量の正規表現ルール、長時間の接続スニッフィング、重複したDNS問い合わせが有効になっていないか確認してください。ギガビット回線では、低クロックのデュアルコアルーターが先に1コアのボトルネックへ達することがあります。メモリ使用量が正常でも、転送性能が十分とは限りません。

導入の結論：まず正しいルーティングを確保し、次にルール機能を広げる

OpenWrtをメインルーターに導入するメリットは入口を一元化できることです。十分なハードウェア性能があり、ネットワーク全体のポリシーを集中管理したい環境に適しています。OpenWrtを透過ルーターとして使えば、LuCIとプラグインによる管理機能を残しつつ、障害時には端末のゲートウェイをメインルーターへ戻せます。Raspberry PiまたはDebianの単体構成は、systemd、nftables、ログをより明確に制御できるため、Linuxネットワークスタックを自分で保守したいユーザーに適しています。

どの方式を選んでも、信頼できる順序は同じです。まず通常のレイヤー3転送を確認し、次に 7890 の明示的プロキシを検証します。その後TCP透過プロキシを有効にし、UDPとDNSを追加し、最後にIPv6とネットワーク全体へのDHCP配布を扱います。Clash Metaやmihomoは通信経路の一部にすぎません。安定性を本当に左右するのは、ゲートウェイ、戻り経路、ファイアウォール、DNSの整合性です。

Clashクライアントをダウンロード