誰向けの話か——「出口を束ねる」とは
リモート勤務・動画配信・生成 AI の Web UI・パッケージレジストリなど、日常業務が「海外リージョンを前提にしたサービス」に寄っているなら、LAN 内の複数端末で同じルールと同じ出口の品質を保ちたくなるのは自然です。問いはシンプルで、「手元のノート PC だけに Clash 系クライアントを入れるのか」「Wi-Fi ルータの手前か横に OpenWrt+OpenClash のサイドゲートウェイを置くのか」「すでにある NAS の Docker で mihomo(Clash Meta 系コア)を常駐させるのか」というトポロジ(配置)の選択になります。
いずれもコアが処理するプロトコルや YAML の骨格は共通ですが、DNS がどこで決まるか、ゲーム機のようにプロキシ欄のない端末を含めるか、誰が再起動とログを見るかで運用負荷がまったく違います。本稿は特定メーカー前提の画面操作ではなく、家庭や SOHO が意思決定するときの比較軸と移行チェックに振ります。サイドルータの配線や透過プロキシの詳細は OpenWrt+mihomo のサイドゲートウェイ解説や、LuCI からの運用に寄せた OpenClash の購読・ノード・ログの整理と組み合わせて読むと実務へ落とし込みやすいです。
用語の線引き:本文の「サイドゲートウェイ/旁路」は、メインルータを撤去せず LAN に二段目の出口を置く構成を指します。OpenClash はその上での OpenWrt 向けフロントエンドの代表例です。NAS Docker は「ホームサーバ上のコンテナがプロキシ役」となるケースで、LAN 内の他の PC からそのポートへ向ける形が典型です。
比較の軸をそろえる
三つのトポロジを並べる前に、次の五つを自分の環境に点数化すると迷いが減ります。(1)カバー範囲——スマホとゲーム機まで同じポリシーに載せる必要があるか。(2)可用性——親機の再起動や Windows アップデートでプロキシが止まっても業務が続くか。(3)名前解決の一貫性——fake-ip や redir-host、DoH を端末がバイパスしていないか。(4)ハード予算と消費電力——常時稼働を追加するか、既存 NAS に載せるか。(5)運用者のスキル——ルータの nft/iptables や Docker の healthcheck を誰が触るか、です。
Clash/Mihomo の強みは、ルールとポリシーグループで出口を状況別に切り替えられることにあります。トポロジを変えても、その設計思想は流用できます。むしろ移行でつまずくのはコアよりDHCP・DNS・ファイアウォールの三層のことが多いので、以降の各パターンではその三点を軸に描写します。
パターン A:単体 PC(ワークステーション常駐)
最も初期コストが低く、GUI クライアントのトレーから購読更新やノード選択ができるのが、使う本人の PC だけに Clash 系を置く運用です。開発者が自分のノートで完結する場合、TUN とブラウザ拡張の干渉さえ押さえれば、分流の詰め方は最速です。家族や来訪者の端末まで同じ品質にしたい、テレビやゲーム機も含めたい、となった時点で限界が見えてきます。
拡張策としては、PC 上の mixed-port へ同一 LAN の端末を向ける(allow-lan+ OS ファイアウォール)方法がありますが、PC スリープと OS アップデートがそのまま全屋の SPOFになります。また「プロキシ手入力が難しい機器」は相変わらず外れます。結論として、一人用の制作環境や試行段階のルール検証には最適で、小型オフィス全体の既定出口には薄い、という位置づけです。
まず手元で安定したプロファイルを作り、のちにルータや NAS に同じ YAML を移植する流れが安全です。OS ごとのクライアントは ダウンロードページから用途に合わせて選べます。
パターン B:OpenWrt+OpenClash のサイドゲートウェイ
メインルータは ISP 付属のまま、LAN に OpenWrt 機器をサイドルーターとして置き、OpenClash 経由で mihomo コアを動かす構成は、日本語圏のコミュニティでも事例が多いパターンです。DHCP で既定ゲートウェイと DNS をサイドに寄せれば、スマホもタブレットもプロキシ欄なしで同じ出口に乗ります。透過プロキシと DNS リダイレクトの整合が鍵で、ここが崩れると「ブラウザだけ通る」「遅延テストだけ赤い」といった典型的な症状に戻ります。
長所は一台に集約できることと、LuCI から運用担当者が購読とノードを触れることです。短所は、IPv6・二重 NAT・ゲームの開放ポートなどメイン側との兼ね合いを学習コストとして払う必要がある点、そしてルータの Flash/RAM がコアとルールセットに追いつくかです。すでにメインを賢くしたい欲張り構成にするとデバッグ変数が増えるので、最初は「ゲートウェイ指し替え+ DNS 集中」から入るのが無難です。
運用上の落とし穴:家族全員のトラフィックがサイドを通ると、誤った全域プロキシ設定や過激なルール更新の影響面が一気に広がります。変更はメンテナンス窓口を決め、設定バックアップとロールバック手順をメモしておく価値が高いです。
パターン C:NAS 上 Docker の mihomo
すでに NAS を停めずに回している家庭やスタジオでは、Docker で公式またはコミュニティの mihomo イメージを載せ、LAN 内の他端末からその mixed-port や TUN 相当のブリッジを参照する構成があります。配線は増えず、UPS やディスク冗長化といった既存インフラに便乗できるのが魅力です。開発用コンテナだけ別 PC の Docker Desktop を使う場合は、ホストと WSL2 のルーティング調整が絡むので、Docker Desktop と Clash を併用する記事も参照ください。
短所は、NAS OS アップデートやパッケージ移行でコンテナが止まるリスクを自己的に管理する必要があること、そしてプロキシ専用ではない機器に性能競合が生まれることです。また Web UI や API を外向きに晒さない・LAN 内に閉じるといった管理面の筋の良さを最初から組み込まないと、後から穴を塞ぐのが面倒になります。とはいえ「ルータを触りたくないが常時出口は欲しい」という要求にはよく合います。
早見:こんな優先順位ならどれか
まず動いてほしいのは自分の PC だけ、ルールは日々いじる——パターン A で十分です。家族分のスマホと在宅ワーカ複数台を同じ基準で扱いたいがルータは触りたくない——初期は A+ allow-lan、のちに C へ寄せる段階設計が現実的です。全屋の既定ゲートウェイを明確に一本化したい、DHCP も自分で握りたい——パターン B が本命です。すでに信頼できる NAS が 24h 稼働している——C を第一候補にしつつ、ゲーム機対応まで必要なら後から B を足す二段構えもありえます。
いずれの場合も、DNS が複数経路に割れる構成は避けるのが安定への近道です。端末ローカルにハードコードされた DoH、ブラウザのセキュア DNS、社用 VPN のスプリット除外が混ざると、mihomo 側のログだけ見ても挙動が説明しにくくなります。移行チェックではまずそれらを棚卸ししてください。
トポロジ変更の移行チェックリスト
倉庫運用でもつまずきやすいのは「コアは起動したがトラフィックが載っていない」状態です。次の順で押さえると戻しやすくなります。
- 現行 DNS の実測:
digやブラウザの net ログ、mihomo の query ログを突き合わせ、どの端末がどのリゾルバを使っているか表にする。 - 対象セグメントの決定:全屋か、VLAN や SSID 単位か、静的 DHCP でテスト端末だけかを宣言し、メインルータのオプション編集可否を確認する。
- プロファイルの単一ソース化:手元で安定した YAML を「正」と決め、ルータ/NAS 側では購読 URL とローカル上書きルールの境界を決める。
- バックアウト:ゲートウェイと DNS を元に戻す手順(スクショでも可)を家族共有のメモに残し、変更窓口の時間帯を決める。
- 観測:代表サイト、社内システム、ストリーミング、パッケージ取得の四種類くらいをスモークテストに固定し、切替直後に毎回同じセットを踏む。
よくある質問
家庭では順番としてどれから試すべきですか
購読と分流が未成熟なうちにゲートウェイを握ると切り分けが難しいので、パターン A でプロファイルを固めるのが無難です。家族端末に展開する段階で allow-lan を検討し、全宅で同じ既定ルートが欲しくなったら B か C を選ぶ、という三歩が失敗しにくいです。
OpenClash と NAS、両方を同時に回す意味はありますか
冗長化を設計できるほどの環境なら意味はありますが、多くの SOHO では出口役は一系統に絞る方が DNS とルールの二本立てが整理されます。片方をホットスタンバイにするより、まずは設定のエクスポートとリストア手順を確実にする投資効果が高いです。
PC から NAS プロキシへ、ルータはそのまま、でもゲーム機だけ直出し、は可能か
可能ですが、ポリシーの一貫性が崩れやすいので例外端末を明示的にリスト化してください。将来の自分が「なぜこの機器だけ挙動が違うのか」で迷わないよう、DHCP 予約やメイン側の静的ルートも合わせてメモに残すとよいです。
まとめ
家庭/SOHO で複数端末の出口を安定させるには、コアの性能以上にトポロジと DNS の設計が効きます。単体 PC は素早いがカバー範囲に限りがあり、サイドゲートウェイは全屋へ一気に効く反面ルータ知識が要り、NAS Docker は既存インフラに乗せやすいが役割が衝突しやすい——三つは補完関係であり、一家に一台の最適解ではありません。
市販の「その他プロキシツール」は画面が単純でも、分流表現やルールセット資産が乏しく、開発者向けサービスを細かく切るには手数が増えがちです。Clash 公式サイト は Clash/Mihomo エコシステムに沿ったビルド整理とドキュメント整備に振っており、トポロジがどれであっても同じ考え方でプロファイルを育てられる点が実務では大きいです。自宅やスタジオの出口を一段理屈に沿わせたいときは、まず手元で形を固め、そのうえで Clash を無料ダウンロード し、ルータや NAS へ載せ替える流れを試すと安心です。細かいドメイン別の作法は チュートリアル・ドキュメントと併せて追うと、移行後の差分も説明しやすくなります。