2026-09-17 ネットワーク構築読了時間：約14分

OpenWrt バイパスルーターでClashコアを直接実行する方法｜透過プロキシとゲートウェイ・DNS設定

OpenWrtルーターやバイパスルーターでコアを直接動かす方法を解説。TProxyとRedirの違い、端末のゲートウェイ設定、DNSの転送先を整理します。

導入前に確認：コアの起動だけでは透過プロキシは有効にならない

OpenWrtでClash系コアを直接動かすには、プロセス、トラフィックの入口、DNSをそれぞれ設定する必要があります。プロセスが起動しただけでは、設定を読み込めたことしか分かりません。クライアントの通信をバイパスルーター経由にし、ファイアウォールから透過プロキシのポートへ転送する必要があります。この記事ではmihomoを例に、3つの設定を連携させる方法を解説します。

プロセス：デバイスのアーキテクチャに合ったバイナリを用意し、設定を /etc/mihomo/config.yaml に配置します。サービスはOpenWrtのprocdで管理します。
転送：クライアントのデフォルトゲートウェイをバイパスルーターに設定し、バイパスルーターから主ルーターへ直接通信できるようにします。
通信の取り込み：ファイアウォールでプロキシ対象の接続を選び、DNSは明確なローカル名前解決経路を通します。

プロキシ管理プラグインをすでに導入している場合は、コアの起動、設定ファイルの生成、ファイアウォールルールの追加を担当しているか確認します。同じルーターで別の仕組みを手動起動すると、ポート競合やリダイレクトの重複、設定の上書きが発生することがあります。コアを直接動かす方法と管理プラグインのどちらを使うか決め、制御の入口を一本化してください。

ネットワーク構成：まず1台の端末をバイパスルーター経由にする

以下は、同一サブネットにある単一LANポートのバイパスルーターを想定した例です。実際の設定では、現在のネットワークに合わせてアドレスを変更してください。主ルーターはインターネット接続とDHCPを引き続き担当し、バイパスルーターには固定アドレスを設定します。テスト用PCだけ、ゲートウェイとDNSを個別に変更します。

デバイス・項目	設定例	用途
LANのサブネット	`192.168.10.0/24`	3台のデバイスを同じIPv4サブネットに配置
主ルーター	`192.168.10.1`	インターネット接続と既存のDHCPサービス
OpenWrtバイパスルーター	`192.168.10.2`	固定アドレスを設定し、デフォルトルートを主ルーターに向ける
テスト用PC	`192.168.10.100/24`	未使用または予約済みのアドレスを使用
PCのデフォルトゲートウェイ	`192.168.10.2`	外部への通信をまずバイパスルーターへ送る
PCのDNS	`192.168.10.2`	通常のDNSクエリをまずバイパスルーターへ送る

OpenWrtのインターフェースと転送設定を確認

LuCIの「ネットワーク」→「インターフェース」→「LAN」→「編集」で固定アドレスを確認します。テーマによって項目名が多少異なる場合があります。インターフェース、IPv4アドレス、ゲートウェイの各項目を確認してください。主ルーターのアドレスを、バイパスルーター自身のデフォルトゲートウェイに誤って設定しないよう注意します。

ip -4 addr show
ip -4 route show
sysctl net.ipv4.ip_forward
ping -c 3 192.168.10.1

ルーティングテーブルに 192.168.10.1 を指すデフォルトルートがあり、転送設定が 1 になっていることを確認します。該当するインターフェース間の転送がファイアウォールで許可されているかも確認してください。単一LANポートのバイパスルーターでは、同じLANデバイスから通信が入り、そのデバイスへ出ていく場合があります。LAN→WANルールをそのまま流用しないでください。

同一サブネット内の転送では、戻りの経路にも注意が必要です。直接接続の通信はバイパスルーターから出ても、主ルーターからPCへ直接返る場合があります。非対称ルーティング、ICMP Redirect、コネクショントラッキングの設定が結果に影響することもあります。構成によっては送信元NATで戻りの通信をバイパスルーター経由にできますが、元のクライアントアドレスが隠れます。常に有効にするのではなく、実際のルーティングとファイアウォール設定を確認して判断してください。

コアのバイナリ：アーキテクチャ、設定ディレクトリ、起動オプションを確認

まず uname -m でハードウェアのアーキテクチャを確認し、次に ubus call system board でシステム情報を確認します。名称が似ているアーキテクチャでも、バイナリに互換性があるとは限りません。CPU命令セットとリリースファイルの動作要件も確認してください。デスクトップ用クライアントのインストーラーをルーター上で実行しないでください。

uname -m
ubus call system board
df -h /overlay
free -m

永続ストレージと実行時メモリに十分な空きがあるか確認します。ルールセット、地理データベース、接続数によって必要なリソースは増えるため、どの設定にも共通する固定のメモリ要件はありません。再起動後に消去される /tmp に、設定ファイルの唯一のコピーを置かないでください。

以下のコマンドは、デバイスに合ったmihomoバイナリを入手し、/usr/bin/mihomo として保存済みで、完全なYAML設定ファイルを所定のディレクトリに配置していることを前提としています。まずテストしてからサービスを起動します。

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

-v は現在実際に使われているコアのバージョン確認に、-t は設定ファイルの検証に使います。ログにルールファイルやデータベースの不足、ダウンロード失敗が表示された場合は、該当するリソースを用意してください。設定テストに合格しても、リモートノードへの接続やファイアウォールによる通信の取り込みが成功したとは限りません。

Redir・TProxy・TUN：通信の種類に合わせて入口を選ぶ

方式	対象となる通信	必要な設定
Redir	主にTCPのリダイレクトに使用	`redir-port` を設定し、NATリダイレクトルールを追加
TProxy	TCPとUDPを取り込み可能	`tproxy-port` を設定し、透過プロキシルール、パケットマーク、ポリシールーティングを追加
TUN	仮想ネットワークインターフェース経由でIP通信を処理	コアのTUNサポート、ルーティング、DNSを設定し、自動ルーティングの対象範囲を明確にする

この記事ではRedirとTProxyを中心に解説します。RedirのTCP用入口では、一般的なUDP通信を取り込めません。Redirだけを設定しても、QUIC、ゲーム、音声アプリのUDP通信が自動的にプロキシ経由になるわけではありません。TProxyならUDPを取り込めますが、選択したノードのプロトコルとサーバー側も該当する転送方式に対応している必要があります。

mihomoのポート設定例

以下は既存の設定に追加するための抜粋であり、単独でプロキシ環境を構築できる設定ではありません。既存のノード、プロキシグループ、ルールは維持し、YAMLの最上位で同名のキーを重複定義しないでください。2つの透過プロキシ用ポートを同時に待ち受けることはできますが、同じ通信を処理するファイアウォール経路は1つに決めてください。

mode: rule
log-level: info
redir-port: 7892
tproxy-port: 7893

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

ここでは挙動を確認しやすい出発点として redir-host を使用し、DNSから実際のIPアドレスを返します。223.5.5.5 は上流DNSサーバーの例です。利用場所からの接続性や名前解決の要件に合わせて選び、直接接続できることを確認してください。ドメインごとの振り分けに必要な名前解決方針、ノードのドメイン名解決、暗号化DNSは、基本経路が安定してから個別に設定します。

fake-ip に切り替える場合は、クライアントから合成アドレス範囲への接続をコアで処理できるようにし、アプリとの互換性に応じてフィルターも設定してください。DNSモードだけを切り替えて、合成アドレス宛ての通信がバイパスルーターを通らない状態にしないでください。

ファイアウォールで通信を取り込む：firewall4と旧ルール体系を見分ける

まず以下の読み取り専用コマンドを実行し、デバイスで使われているファイアウォールツールを確認します。OpenWrt 22.03以降はfirewall4とnftablesが標準ですが、実際のデバイスは異なるファームウェアを使っていたり、変更されていたりする可能性があるため、ローカルの結果を基準にしてください。

command -v fw4
command -v nft
command -v iptables
nft list ruleset
ip -4 rule show
ip -4 route show table all

インターネット上のiptables用通信取り込みスクリプトを、そのままfirewall4の設定に追加しないでください。互換コマンドが使える場合でも、ルールが実際にどのルールセットへ登録されるか、ファイアウォールの再読み込み後も残るかを確認します。TProxyには対応するカーネルモジュールとユーザー空間の式サポートも必要です。ポートを待ち受けるだけでは不十分です。

通信を取り込むルールで最低限確認する4項目

送信元を限定：最初はテスト用PC 192.168.10.100 の通信だけを対象にします。LAN全体をすぐに取り込んだり、WANからの任意の通信を対象にしたりしないでください。
除外してから取り込む：ローカル管理用アドレス、LAN宛ての通信、必要なブロードキャストとマルチキャストを除外します。IPv4とIPv6の除外範囲はそれぞれ設計してください。
入口を指定：TCP Redirは 7892 へ、TProxyは 7893 へ転送します。さらに、マークと一致するポリシールーティングを設定し、マーク済みの通信をローカルに配送します。
ループを防止：コア自身がノード、DNS、直接接続先へ確立する外向きの通信を、同じ通信取り込みルールに再度通してはいけません。ルーター本体のOUTPUTチェーンでの取り込みは別途設計してください。

TProxyの一般的な実装では、fwmark、ip rule、ルーティングテーブル内のローカルルートを組み合わせます。マーク値、マスク、ルールの優先度、ルーティングテーブル番号は、既存のVPNやポリシールーティング用プラグインと競合しないようにしてください。すべてのデバイスで安全に使える固定番号はないため、稼働中のネットワークをそのまま置き換えられる一式のルールはここでは提示しません。

初回のテストでは、該当するフローオフロードを無効にしてからカウンターを確認してください。ハードウェアまたはソフトウェアのオフロードによって、後続パケットの経路が変わることがあります。最初の接続が成功しただけで、すべての通信が正しく取り込まれていると判断しないでください。

DNSの取り込み：dnsmasqの53番ポートからコアの1053番ポートへ転送

まずはdnsmasqがLAN向けの 53 番ポートを担当し、mihomoはループバックアドレス 127.0.0.1:1053 だけで待ち受ける構成がおすすめです。2つのプロセスが同じアドレスとポートを奪い合うことがなく、コアのDNSポートをLANに直接公開する必要もありません。

「ネットワーク」→「DHCP/DNS」でDNS転送の設定を開き、127.0.0.1#1053 を追加します。これはdnsmasqのサーバーとポートの記法であり、YAMLの記法ではありません。
ほかの転送先サーバーとresolvファイルの読み込み元も確認します。DNSクエリを必ずmihomo経由にする場合は、上流のresolvファイルから別のサーバーを読み込む経路を無効にし、ローカル転送と並行しないようにしてください。
mihomoの上流DNSが、バイパスルーター自身の 53 番ポートを指していないことを確認します。そうなっていると「dnsmasq → mihomo → dnsmasq」という名前解決ループが発生します。
サービスを再読み込みした後、テスト用PCで nslookup example.com 192.168.10.2 を実行し、同時にコアのログとDNSの待ち受け状態を確認します。

PCのDNS欄には 192.168.10.2 だけを入力し、192.168.10.2:1053 は指定しないでください。通常のOSのDNS設定では、このようなポート指定はできません。DHCPのDNSオプションでも、配布するのはサーバーアドレスだけです。

dnsmasqとコアの両方でキャッシュを有効にしている場合は、設定変更後も古いレコードが残ることがあります。まずサーバーを明示したクエリで検証してから、クライアントのキャッシュを消去してください。キャッシュから応答が返っただけで、新しい名前解決経路が有効になったと判断しないでください。

procdで自動起動：まずプロセスを管理し、通信の取り込み設定は別に行う

コアを直接実行する場合は、OpenWrtのprocdで管理できます。以下の内容を /etc/init.d/mihomo に保存してください。これはプロセスを管理する最小限のサービス例であり、ファイアウォールルールの追加やクライアントのゲートウェイ変更は行いません。

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

USE_PROCD=1
START=99
STOP=10

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_close_instance
}

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

待ち受け一覧で 7892、7893、127.0.0.1:1053 を確認します。使えるコマンドはファームウェアに含まれるツールによって異なります。netstat が該当オプションに対応していない場合は、インストール済みの ss -lnptu で確認してください。管理APIをインターネットに接続されたインターフェースで待ち受けさせないでください。

このサービス例ではシステムのデフォルト権限で起動します。透過プロキシとルーティングの操作には権限が必要です。設定ファイルとサービススクリプトは管理者だけが変更できるようにしてください。ファイアウォールルールは現在のファイアウォール体系に対応した仕組みで永続化し、サービス停止時に通信の取り込みを解除する方法も明確にします。そうしないと、コアの終了後もクライアントが待ち受けプロセスのないポートへ転送され続ける可能性があります。

検証の手順：ルーティング、DNS、通信の取り込み、リモート接続を順に確認

まず基本のルーティングを確認：透過プロキシを有効にする前に、テスト用PCのゲートウェイをバイパスルーターにしてもインターネットへ接続できることを確認します。この段階で接続できない場合は、転送と戻りの経路を先に修正してください。
次にDNSを確認：192.168.10.2 を指定して問い合わせます。タイムアウトする場合は、dnsmasq、1053番ポートの待ち受け、名前解決ループを確認してください。アドレスが返ってきても、該当サイトへの接続が成功するとは限りません。
次にTCPの取り込みを確認：テスト用PCからHTTPSサイトへアクセスし、該当するファイアウォールカウンターとmihomoの接続ログを確認します。送信元アドレス、適用されたルール、最終的なポリシーが一致していることを確かめてください。
UDPを個別に確認：UDPを必要とするアプリを実際に使い、TProxyのカウンターと接続ログを確認します。一般的なWebページが表示できても、UDPプロキシが動作しているとは限りません。
IPv4とIPv6を個別に確認：両方の通信をテストします。IPv6が主ルーターから直接外部へ出ている場合は、IPv6の通信取り込み、DNS配布、ファイアウォールポリシーを明確に設計してください。デュアルスタック時の挙動を偶発的なエラーとして扱わないでください。
最後に再読み込みと再起動をテスト：ファイアウォールの再読み込み、コアの再起動、ルーター全体の再起動を試し、ルールが重複しないこと、DNSが復旧すること、コア停止後の明確な復旧手順があることを確認します。

ノードを何度も変えず、現象に応じて原因を切り分ける

ゲートウェイ変更後に完全に通信できない：サブスクリプションを疑う前に、IP転送、ファイアウォールの転送、主ルーターの出口、戻りの経路を確認してください。
IPアドレスには接続できるが、ドメイン名では開けない：PCが実際に使用しているDNS、dnsmasqの上流設定、コアのDNSログ、ブラウザーのセキュアDNSを確認してください。
Webは使えるが一部のアプリが動かない：UDP、IPv6、ルールの適用状況、リモート側のプロトコル対応を確認し、通信が取り込まれていないのか、取り込み後に接続が失敗しているのかを切り分けてください。
ルーター自身だけが接続できない：OUTPUTチェーンとコア自身の通信に対する除外設定を確認し、プロキシの外向き通信が再び取り込まれないようにしてください。
再起動後に動作しない：サービスが自動起動に設定されているか、依存ファイルが永続領域にあるか、ファイアウォールの再読み込み時に該当ルールが登録されるかを確認してください。

ネットワーク全体に適用する前に、1台での検証結果を記録します。アドレス、ゲートウェイ、DNS、透過プロキシのポート、適用されたポリシー、再起動後の結果を控えてください。安定して動作することを確認してからDHCP設定を変更します。リースはすぐ更新されるとは限らず、端末によってはWi-Fiの切断と再接続が必要です。元に戻す場合は、まずクライアントのゲートウェイを主ルーター、DNSを元の設定に戻し、次に通信の取り込みを解除してからコアを停止します。ネットワーク全体の転送経路が使えなくなる事態を防げます。