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

ルーターでClashコアを動かす：バイパスルーターの構成方法と必要リソース

メインルーターとバイパスルーターを比較し、構成、必要リソース、通信経路、運用範囲を解説します。

ルーターでClashまたはmihomoコアを動かす目的は、デスクトップクライアントの画面をネットワーク機器へ移すことではありません。ルーターにルール判定、DNS処理、トラフィック転送を集約することが本質です。テレビ、ゲーム機、モバイル端末など、クライアントをインストールしにくい機器も、ゲートウェイやポリシールーティングを通じて同じルールを利用できます。一方で、ルーターは転送経路の重要な中継点になるため、設定を誤るとLAN全体に影響します。導入前にトポロジー、復旧経路、機器の負荷を確認しておく必要があります。

ここでいう「ルーターでClashを動かす」とは、主にOpenWrt、その派生システム、または汎用Linuxゲートウェイ上でClash互換コアを実行することを指します。現在はmihomoを使う構成が一般的で、Clashの設定構造を引き継ぎながら、TUN、ルールセット、トラフィックインスペクションなどの拡張機能を利用できます。管理プラグインは設定ファイル、サービススクリプト、ファイアウォールルールを抽象化しますが、基盤となる流れは変わりません。コアがポートを待ち受け、システムが対象トラフィックをコアへ送り、コアがルールに基づいて直結またはプロキシ出口を選択します。

メインルーターとバイパスルーターの構成を選ぶ

メインルーターでコアを直接動かす

メインルーター方式では、PPPoE接続、DHCP、NAT、無線アクセスを担う機器でClashコアも実行します。端末の通信は必ずこの機器を通るため、転送経路が短く、DNSも一元的に制御しやすい構成です。十分な性能があり、システムを保守でき、ファイアウォールルールに慣れている場合に向いています。上流インターフェースは回線側、下流インターフェースはLAN側に接続し、プロキシプログラムはファイアウォールから取り込まれた通信を処理します。

主な代償は、障害の影響範囲が大きいことです。コアがメモリを使い切る、ファイアウォールルールの読み込みに失敗する、DNSのポートが競合するといった問題が、接続、LAN内名前解決、管理画面に同時に影響する可能性があります。システム更新によってnftables、iptables、プラグインがルールを生成する方式が変わることもあります。そのため、シリアル接続やレスキューモード、予備機器で復旧できる環境に適しており、唯一の家庭用出口で初めての実験を行うのはおすすめしません。

バイパスルーターを独立ゲートウェイとして使う

バイパスルーター方式では、既存のメインルーターに接続と基本ネットワークを任せ、別の機器にClashコアを配置します。一般的な片側接続のバイパスルーターはメインルーターと同じLAN上に置きます。たとえばメインルーターを192.168.1.1、バイパスルーターを192.168.1.2とします。プロキシルールを適用する端末のデフォルトゲートウェイを192.168.1.2に設定すると、バイパスルーターがポリシー処理を行い、その後メインルーターへ通信を転送します。

この構成は段階的な移行に向いています。まずテスト用PC 1台だけのゲートウェイとDNSを変更し、ルール、UDP、ドメイン名前解決を確認してから、DHCPでより多くの端末へ配布できます。バイパスルーターが停止しても、端末のゲートウェイをメインルーターに戻せばよく、回線接続の設定を変更する必要はありません。運用範囲も明確で、メインルーターは基本接続、バイパスルーターは透過プロキシと追加ポリシーを担当します。

片側接続のバイパスルーターは、ゲートウェイアドレスを1つ入力するだけの構成ではありません。バイパスルーターが送信元アドレス変換を行わずにパケットを転送すると、戻りの通信がメインルーターから直接クライアントへ送られ、行きはバイパスルーター、戻りは経由しない非対称経路になる可能性があります。問題が起きるかどうかは、透過プロキシ方式、コネクション追跡、メインルーターのルーティングテーブルによって異なります。一般的には、バイパスルーターの出口で適切なNATを行うか、メインルーターにクライアントセグメントへの明示的なルートを追加し、往復経路を設計どおりにします。

2ポートのバイパスゲートウェイ

独立したネットワークポートを2つ備えた機器は、直列接続のゲートウェイとしても構成できます。一方をメインルーター、もう一方を別の下流スイッチや無線アクセスポイントに接続します。バイパスルーターは下流に独立したサブネットを作り、そのサブネットのDHCP、転送、プロキシ処理を担います。片側接続に比べて上下流の境界が明確で、戻りの通信も通常は自然にバイパスルーターを通るため、サブネット全体へのポリシー適用も容易です。

その代わり、ネットワーク階層が増えます。ポート転送、LAN内検出、画面ミラーリング、サブネット間アクセスには追加設定が必要で、メインルーターとバイパスルーターの両方でNATを行うと二重NATになります。家庭内機器がmDNSやブロードキャストによる検出に依存している場合は、中継サービスが必要か評価してください。サブネット間の問題をすべてClashコアのせいにするのは適切ではありません。

LANE 01

メインルーター方式

経路が短くDNSの制御を集約しやすいため、十分な性能と復旧手段を備えた機器に向いています。プロキシサービスの障害がネットワーク全体の出口に直接影響する可能性があります。

LANE 02

片側接続のバイパスルーター

1台の端末で試験運用し、すぐに元へ戻しやすい構成です。NAT、戻り経路、DHCPで配布するゲートウェイとDNSを重点的に確認します。

LANE 03

2ポートゲートウェイ

上下流の境界が明確で、独立したプロキシ用サブネットに適しています。ただし、二重NAT、サブネット間アクセス、機器検出への対応が必要です。

CPU、メモリ、ストレージの必要量

Clashコアに必要なハードウェア性能は、スループット、ルールの規模、接続数、暗号化処理の負荷、TUNの有効化状況によって変わります。「コアが起動する」だけで適性を判断することはできません。ルーターには、システムサービス、DNSキャッシュ、ファイアウォールのコネクション追跡、管理画面のためのリソースも必要です。メモリを使い切ると、単なる速度低下よりも、サービス再起動やシステム無応答のほうが原因を特定しにくくなります。

CPUと暗号化スループット

CPUはルール判定、暗号化通信、ユーザー空間での転送性能の上限を決めます。古いシングルコアMIPS機でも軽量なルールと少数の接続なら処理できますが、高速回線、多数の端末、複雑なプロトコルではボトルネックになりやすいです。現行のARM64やx86_64プラットフォームは、mihomoの常時稼働に適しています。コアファイルを選ぶ際はシステムのアーキテクチャを一致させてください。代表的な識別子はarm64、armv7、mipsle、amd64です。アーキテクチャを間違えると、通常は実行できないというエラーが直接表示されます。

ハードウェアNATやオフロード機能が、透過プロキシに必要なファイアウォールチェーンを迂回することがあります。プロキシ有効後に速度が異常な場合は、ソフトウェアオフロード、ハードウェアオフロード、透過プロキシプラグインの互換性を確認してください。インターフェース速度を最大化する前に、有線端末1台で直結、ルールプロキシ、UDPの3種類をテストし、CPU 1コアの使用率が継続的に上限へ近づいていないか確認します。

メモリとルールの規模

メモリ64MBの機器は、非常に軽量なシステムと小規模な設定に限って適しています。大規模なドメインルール、GeoIPデータ、管理パネル、複数の追加サービスを読み込むと、余裕はほとんどありません。128MBは基本構成の出発点になりますが、ルールセットと同時稼働サービスの管理が必要です。256MB以上あれば、mihomo、DNS拡張モード、大規模なルールセット、Web管理画面を同時に使いやすくなります。接続数が多い、ルールプロバイダーの更新頻度が高い、トラフィックインスペクションを有効にする場合は、さらに余裕を持たせてください。

Swapは一時的なメモリ不足を緩和できますが、フラッシュストレージへの交換は遅く、十分な物理メモリの代わりにはなりません。コアが周期的に終了する場合は、まずシステムログでメモリ回収やプロセス終了の記録を確認します。そのうえでルールを減らす、使っていないサービスを停止する、より余裕のある機器へ移行するといった対策を検討します。

ストレージ容量と書き込み方針

コア本体、GeoIPデータ、ルールセット、サブスクリプションキャッシュ、ログはすべてストレージを消費します。ルーターの内蔵フラッシュが小さい場合は、データディレクトリを拡張ストレージや外付けディスクへ移せますが、サービス起動前にマウントポイントが利用可能になっていなければなりません。ログレベルをdebugのまま長期間運用するのは避けてください。詳細ログは短時間の原因調査には有効ですが、継続的な書き込みは容量を消費し、低速なフラッシュの負担も増やします。

透過プロキシ、TUN、DNSの転送経路

ルーター構成で最も混同されやすいのは、「コアが動作している」ことと「LANの通信がコアへ入っている」ことです。mixed-port、HTTPポート、SOCKSポートは待ち受けの入口にすぎず、端末側で手動設定するプロキシに適しています。プロキシ未設定の機器も自動的にルール転送するには、REDIRECT、TProxy、TUNなどの取り込み方式と、それに対応するファイアウォールおよびポリシールーティングが必要です。

REDIRECTとTProxy

REDIRECTはTCP接続の取り込みによく使われ、設定も比較的簡単ですが、UDPや元の宛先アドレスを保持する必要がある場面には制約があります。TProxyはTCPとUDPを処理でき、ポリシールーティングによって透過通信をコアの待ち受けポートへ送ります。ファイアウォールマーク、ポリシールーティングテーブル、カーネル関連モジュールに依存するため、どれか1つが欠けると、TCPだけ使えてUDPがタイムアウトする、またはLAN通信が誤って転送されるといった症状が起こります。

ファイアウォールルールでは、機器自身の管理アドレス、LANの予約済みセグメント、マルチキャスト、ブロードキャスト、プロキシサーバー自身の接続を除外する必要があります。除外しないと、コアが作成した外向き接続まで透過ルールに再び捕捉されるプロキシループが発生し、接続失敗やCPU使用率の上昇につながります。プラグインが除外項目を生成する場合でも、対象ネットワーク、プロセス、ファイアウォールマークをカスタムスクリプトで個別に確認してください。

TUNモード

TUNモードは仮想ネットワークインターフェースでIPトラフィックを受け取るため、TCP、UDP、複雑なアプリケーションをまとめて処理したい環境に適しています。mihomoのTUN設定では自動ルートやインターフェース検出を有効にできますが、ルーターにはWAN、LAN、ポリシールーティング、ファイアウォールゾーンがすでに存在します。自動生成されたルートが既存トポロジーに合うとは限りません。導入時は設定ファイルの構文だけでなく、デフォルトルート、TUNのルーティングテーブル、LANの転送チェーンを確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この設定は、mihomo側でTUN、自動ルート、DNS取り込みを有効にする意図を示すだけで、ルーターのファイアウォールがLAN通信のTUNへの流入を許可したことを意味しません。ファームウェア、プラグイン、ネットワーク管理コンポーネントによって、インターフェース名やルールチェーンの扱いは異なります。管理プラグインがすでにTUN設定を生成している場合、メイン設定で同じ項目を重複して宣言すると、設定の上書きやルートの重複が発生する可能性があります。

DNSリクエストの経路

ルールがドメイン名に依存する場合、DNSの経路もプロキシポリシーと一致させる必要があります。一般的には、端末のDNSリクエストをルーターへ送り、dnsmasqなどのローカル名前解決サービスからmihomoのDNS待ち受けポートへ転送します。別の方法として、ファイアウォールでLANの53番ポートへのリクエストを取り込むこともできます。前者は構造を理解しやすく、後者は端末が手動でパブリックDNSを設定している場合にも対応できますが、暗号化DNSを使うアプリは通常の53番ポートを通りません。

fake-ipモードでは、ドメイン名に予約済みアドレスを返し、コアがマッピングから元のドメイン名を復元してドメインルールを適用します。一部のLANサービス、ゲームプラットフォーム、実アドレスによる判定に依存するアプリでは、fake-ip-filterへの追加が必要になる場合があります。redir-hostモードは従来の名前解決に近い一方、マッチング効率や特定の接続フローが異なります。モードを切り替えた後は、古い結果がテストに影響しないよう端末のDNSキャッシュを消去してください。

DNSループはバイパスルーターでよくある障害です。mihomoが問い合わせをdnsmasqへ渡し、dnsmasqが再びmihomoへ返す状態です。ループを確認するには、両サービスの待ち受けポートと上流アドレスを調べ、名前解決チェーンが1つの明確な方向になっていることを確認します。バイパスルーター自身の問い合わせ、LANクライアントの問い合わせ、プロキシノードのドメイン解決は分けて考える必要があります。ノードのドメイン名は、プロキシ経路を確立する前に解決できなければなりません。

IPv6も忘れずに確認する

IPv4だけを取り込む構成では、IPv6対応端末がメインルーターからIPv6のデフォルトルートを直接取得し、既定のポリシーを迂回する可能性があります。IPv6の転送とルールを完全に構成するか、導入初期はテスト端末へIPv6ルートを配布しない方法があります。最終的な選択は家庭内ネットワークの要件に合わせてください。「同じWebサイトなのに、時にはルール適用、時には直結になる」場合は、AとAAAAレコード、IPv4とIPv6のデフォルトルート、コア設定のIPv6スイッチを個別に確認します。

バイパスルーターの導入手順と検証順序

  1. バイパスルーターの管理アドレスを固定する。

    メインルーターと同じセグメントに属し、DHCPアドレスプールと重ならない静的アドレスをバイパスルーターに設定します。デフォルトゲートウェイはメインルーターに向けます。まず、バイパスルーター自身が時刻を更新し、ドメインを解決し、ソフトウェアリポジトリへアクセスできることを確認してください。

  2. アーキテクチャに合ったコアと管理コンポーネントをインストールする。

    CPUアーキテクチャ、システムのlibc環境、使用可能なストレージを確認します。まずコアを直接実行してバージョンと設定の読み込み結果を確認し、その後サービススクリプトに管理させます。これにより、バイナリ互換性の問題をファイアウォール障害と誤認せずに済みます。

  3. 設定を取り込み、外向き通信を確認する。

    サブスクリプションから生成されたプロキシグループ、ルールプロバイダー、ノードのプロトコルが、現在のコアでサポートされているか確認します。まず明示的なHTTPまたはSOCKSプロキシを使ってコアの外向き通信をテストし、成功してから透過的な取り込みを設定します。これにより、ノードの問題とルーティングの問題を切り分けられます。

  4. IP転送と透過プロキシを有効にする。

    プラグインの対応状況に応じてTProxyまたはTUNを選択し、LANからWANへの転送、ファイアウォールゾーン、ポリシールーティングが有効になっていることを確認します。複数の透過プロキシスクリプトを同時に有効にしないでください。マークやリダイレクトが重複する可能性があります。

  5. テスト端末を1台だけ移行する。

    テスト端末のゲートウェイとDNSを手動でバイパスルーターへ向け、LANアクセス、直結サイト、ルールプロキシ、動画、音声通話、スリープ復帰を順番に確認します。安定性を確認してからDHCPの配布内容を変更してください。

  6. 除外ルールとグループポリシーを設定する。

    プリンター、NASの管理アドレス、メインルーターの管理画面、必要なLANセグメントを直結またはバイパスのリストに追加します。テレビ、ゲーム機、ゲスト端末は、送信元IPまたはMACに対応する固定アドレスでグループ化すると、プロキシへ通す端末を管理しやすくなります。

  7. 更新方法と復旧方法を設定する。

    サブスクリプションとルールセットの更新は、機器の負荷が高い時間帯を避け、直近で動作した設定を保管します。サービスの起動に失敗した場合は基本設定へ戻せるようにし、メインルーターではDHCPとインターネット出口を維持します。

透過プロキシを検証する際、Webページを1つ開くだけでは不十分です。ブラウザーがキャッシュ、HTTP/3、独自のセキュアDNSを使う可能性があるため、経路全体の正しさは判断できません。まず端末が取得したアドレス、ゲートウェイ、DNSを確認し、次にバイパスルーターが接続を受信しているかを確認します。その後、ルールのヒットと外向き先を確認し、最後にUDP、IPv6、LANアクセスをテストするのが確実です。

ip address
ip route
ip rule
nft list ruleset
logread
ss -lntup

これらのコマンドは、インターフェースアドレス、ルーティングテーブル、ポリシールール、ファイアウォールルール、システムログ、待ち受けポートを確認するために使います。iptablesを使用するシステムでは、対応するルールテーブルを確認してください。重要なのは大量のコマンドを一度にコピーすることではなく、データ経路に沿って切り分けることです。端末がパケットをバイパスルーターへ渡しているか、ファイアウォールがマークまたはリダイレクトしているか、コアが受信しているか、外向き通信がメインルーターへ送られているかを順に確認します。

よくある障害と運用範囲

バイパスルーターは接続できるが、クライアントは接続できない

まずクライアントのデフォルトゲートウェイが本当にバイパスルーターを指しているか、バイパスルーターでIPv4転送が有効かを確認します。続いてLANの転送ゾーン、NAT、戻り経路を確認してください。バイパスルーター本体からアクセスできることは、その機器自身のOUTPUT通信が使えることを示すだけで、LANから来たFORWARD通信が許可されている証拠にはなりません。

Webページは開くが、ゲームや音声アプリがタイムアウトする

通常はUDPの確認が必要です。REDIRECT方式がTCPしか処理していない、またはTProxyに必要なモジュールやポリシールーティングが読み込まれていない可能性があります。ルールがUDPをコアへ送っているかを確認し、選択したノードのプロトコルとプロキシサーバーが対象のUDP通信に対応していることを確認してください。特定のゲームだけで問題が起きる場合は、NATタイプ、ポート転送、ゲームプラットフォームのリージョンルールも調べます。

有効化後、LAN内の機器へアクセスできない

透過プロキシの除外リストに、プライベートアドレス、マルチキャストアドレス、ローカルサービスのポートが含まれていない可能性があります。一般的なLANセグメントとルーターの管理アドレスがローカル経路で転送されるようにしてください。VLAN間やサブネット間のアクセスではファイアウォールゾーンも確認します。すべてのプライベートアドレスを恒久的に直結へ回すのではなく、プロキシリソースが内部セグメントにある場合も含め、実際のトポロジーに沿った正確なルールを作成します。

CPU使用率が高いのにスループットが低い

まずdebugログを停止してシングルコアの負荷を確認し、直結ルールとプロキシルールの速度を比較します。直結も明らかに遅い場合は、透過転送によってハードウェアオフロードが無効になった、またはファイアウォールチェーンでパケットが重複処理されている可能性があります。プロキシ接続だけが遅い場合は、暗号化プロトコル、ノードの経路、MTUを確認します。TUN環境でMTUが適切でないと、フラグメント、特定サイトの表示停滞、大容量ファイルの接続停止が起こることがあります。

サブスクリプション更新後にサービスが起動しない

よくある原因は、設定項目とコアのバージョンの不一致、ルールプロバイダーのダウンロード失敗、YAMLのインデントミス、データディレクトリの権限変更です。運用時は、「サブスクリプションの元データ」「プラグイン生成後の実行設定」「コアが実際に読み込んだ設定」を分けて確認します。管理プラグインがテンプレートを統合したり、ポートを上書きしたり、DNS項目を追加したりするため、サブスクリプションファイルだけでは最終的なエラーを発見できない場合があります。

導入の結論：まず経路を決め、その後にコンポーネントを選ぶ

ルーターでClashコアを動かす際の難しさは、プログラムの起動よりも、通信を想定どおりに取り込み、送り出し、戻すことにあります。メインルーター方式は経路がシンプルですが、障害対応のリスクが集中します。片側接続のバイパスルーターは段階的なテストに向いている一方、NATと戻り経路への対応が必要です。2ポートゲートウェイは境界が明確ですが、独立サブネットとサブネット間管理のコストが増えます。機器を選ぶ際は、CPUアーキテクチャ、シングルコア性能、メモリの余裕、ルール規模、ログ保存領域を総合的に考慮してください。

実際の導入では、まず明示的なプロキシでコアとノードを検証し、その後に透過転送を有効にします。最初は1台の端末だけをバイパスルーター経由にし、次にDHCPを変更します。IPv4、TCP、基本DNSを確認してから、UDP、TUN、IPv6へ進んでください。データ経路を階層ごとに検証すれば、サブスクリプション、コア、ファイアウォール、DNS、LANトポロジーの問題を切り分けられ、設定変更後の影響範囲も素早く特定できます。

Clashをダウンロード