1 NAS 旁路で叶えたいこと
すでに Synology NAS を常時オンで運用している家庭では、ルーターに OpenWrt を焼いたり、メッシュ AP の DHCP をいじるのを避けつつ、家じゅうの端末から見える「出口のひとつ」を NAS 上に用意したい、というニーズがよく出ます。DSM 7 では従来の Docker アプリが Container Manager に統合され、GUI からイメージの取得、環境変数、ボリュームマウント、再起動ポリシーまでを一括管理しやすくなりました。その上で動かすのが、Clash Premium 方言と互換性の高いコアである Mihomo（旧称 Clash.Meta 系の流れをくむ実装）です。GUI クライアントを各端末に入れ替えなくても、同一 LAN から mixed-port や TUN を公開し、端末側のデフォルトゲートウェイを NAS の IPv4 に向けることで、設定コストを下げた「疑似ゲートウェイ」運用が可能になります。
ただし「ゲートウェイを NAS に変えた瞬間に、OS が発行するすべてのパケットが自動で Mihomo に吸い込まれる」と単純には限りません。L3 のデフォルト経路を NAS に寄せたあと、NAS 側で IP 転送・NAT・場合によっては iptables／nftables と Mihomo の TUN や redir ポートをどう接続するかが本題になり、機種（Plus シリーズか Value か）、カーネルモジュール、Docker の権限フラグによって取りうる解が変わります。本稿では再現しやすい下限として、Container Manager でのコンテナ定義、設定ディレクトリのマウント、待受ポート、DSM のファイアウォール、端末側でゲートウェイと DNS をどう書くかを中心に整理し、踏み込んだ転送まわりは「ここから先は SSH と自己責任の領域」と区切って触れます。
2 トポロジと用語の整理
典型的な家庭では、インターネット側の本番ゲートウェイはプロバイダ直結のルーター（例：192.168.1.1）が握り、NAS はその下の同一サブネットに有線でぶら下がっています（例：NAS が 192.168.1.50）。この状態で端末のデフォルトゲートウェイだけを 192.168.1.50 に書き換えると、端末から見た「次ホップ」は NAS になりますが、NAS がインターネットへ出ていくときの戻り経路をルーターが正しく転送できるか、NAS が届いたパケットをどう処理するかが別問題です。ここでいう旁路（サイドゲートウェイ）は、ルーターを置き換えずに「オプションの経路ノード」を横に置くイメージです。
用語を揃えます。デフォルトゲートウェイは IPv4 のデフォルトルート（0.0.0.0/0）の次ホップです。DHCP オプション 3はルーターから配られる「ルーター（ゲートウェイ）アドレス」であり、家庭用ルーターの管理 UI によっては「常に自分をゲートウェイとして配る」固定実装で、カスタムゲートウェイを配れないものもあります。その場合は、端末ごとに静的 IP か、別 DHCP サーバ（Synology の DHCP Server パッケージなど）へ切り替える、あるいは対象端末だけ手動設定する、といった住み分けが必要です。DNSも合わせて NAS 上のリスナ（Mihomo の dns.listen など）へ向けるか、信頼できる外部 DoH を端末に直指定するかで挙動が変わるため、FakeIP／DoH の整理と矛盾がないかログで確認してください。
3 DSM 7 と Container Manager の準備
DSM 7.2 以降ではパッケージセンターから「Container Manager」をインストールします（旧 Docker アプリからの移行ガイドは Synology のヘルプにあります）。インストール後、共有フォルダ（例：/volume1/docker/mihomo）に config・ui・必要なら ruleset 用のサブディレクトリを作成し、File Station または SSH で権限を整えます。Mihomo は単一の config.yaml を軸に動くため、コンテナ内の /root/.config/mihomo など標準パスへホスト側ディレクトリをマウントする形がわかりやすいです。
CPU アーキテクチャは Intel／AMD の x86_64 系か、RK 系などの aarch64 かでイメージタグが分かれます。Container Manager の「イメージ」タブで公式またはコミュニティが提供する Mihomo イメージを取得し、脆弱性の少ないタグ選び（digest 固定）を推奨しますが、入門時はメンテされているマルチアーキタグを使い、動作確認後にピン留めすると安全です。NAS の省電力 CPU でも Mihomo 自体は軽量ですが、大規模なルールセットや高頻度の GeoIP 更新はディスク I/O を食うため、SSD キャッシュやデータセットの置き場所にも注意してください。
4 コンテナ定義：ポートマップとボリューム
Container Manager では「プロジェクト」として docker-compose 形式を貼り付けるか、ウィザードで同等の設定を行います。最低限ホスト側に公開したいのは、HTTP/SOCKS を束ねる mixed-port（例：TCP 7890）、管理 UI 用の external-controller（例：9090）、FakeIP 運用なら DNS リスナ（例：UDP/TCP 1053）です。TUN モードまで含めて透過プロキシを狙う場合は --cap-add=NET_ADMIN と /dev/net/tun のデバイスマウント、さらに network_mode: host もしくは macvlan によるブリッジ設計が話題になりますが、DSM の Docker 実装とセキュリティポリシーによっては GUI からは入力しづらいため、高度な構成は別稿レベルに分けます。
services:
mihomo:
image: metacubex/mihomo:latest
container_name: mihomo
restart: unless-stopped
ports:
- "7890:7890/tcp"
- "9090:9090/tcp"
- "1053:1053/udp"
- "1053:1053/tcp"
volumes:
- /volume1/docker/mihomo/config:/root/.config/mihomo
# TUN を使う場合のみ検討（機種・DSM バージョンで要検証）
# cap_add:
# - NET_ADMIN
# devices:
# - /dev/net/tun
ボリュームはホストパスを絶対指定するのが DSM では一般的です。設定を編集したあとコンテナを再起動すると反映されます。ログは docker logs mihomo 相当を Container Manager の詳細画面から確認できるほか、長期保存したい場合はホスト側にログディレクトリをマウントして log-level を調整してください。バックアップは config.yaml と購読 URL を含むメモだけでなく、実際に配信されているルールファイルのスナップショットもセットで取ると復旧が早いです。
5 Clash 互換 YAML の要点
Mihomo は Clash 系クライアントと同じ宣言的 YAML を読みます。LAN 端末から接続させるなら allow-lan: true と、ブリッジ上の NAS IP で待ち受ける bind-address: '*'（または明示的に LAN インターフェース IP）が定番です。external-controller を 0.0.0.0 に広げるとスマホのブラウザからもメトリクスに触れられて便利そうに見えますが、認証トークン（secret）を強くし、DSM ファイアウォールで送信元を自宅サブネットに限定しないと危険です。まずはループバック相当に閉じ、必要なら VPN 内からだけ叩く、が堅実です。
mixed-port: 7890
allow-lan: true
bind-address: '*'
mode: rule
log-level: info
ipv6: false
external-controller: 0.0.0.0:9090
secret: "replace_with_long_random"
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- tls://1.1.1.1
fallback:
- https://dns.google/dns-query
proxies: []
proxy-groups:
- name: Proxy
type: select
proxies:
- DIRECT
rules:
- GEOIP,JP,DIRECT
- MATCH,Proxy
proxies と購読は各自のプロバイダポリシーに従って追加します。NAS 上でサブスクリプション変換サービスを動かす場合は、そのプロセス自体の更新とログ監査を忘れないでください。Linux サーバに素のバイナリで立てるパターンはLinux と systemd の記事と思想が共通なので、ユニットファイルの代わりに Docker の restart ポリシーを当てはめると理解しやすいです。
6 ポート公開と DSM ファイアウォール
DSM の「コントロールパネル」→「セキュリティ」→「ファイアウォール」では、プロファイルごとに許可ルールを積み上げます。Mihomo の mixed ポートや DNS リスナを LAN に開けるルールを作り、可能なら送信元 IP を自宅のプライベート帯（例：192.168.1.0/24）に限定します。IPv6 を無効にしている構成でも、DSM 側で IPv6 ファイアウォールが別枠になっている場合があるため、意図しない露出がないかインターフェース単位で確認してください。
QuickConnect やリバースプロキシ経由で管理画面を外に出している環境では、Mihomo の管理ポートが誤ってワンクリック公開されないよう、ルールの優先順位とインターフェース選択に注意が必要です。また、ルーター側の「NAS 向けポート転送」は基本的に不要です。ゲートウェイ構成はあくまでイントラ内の経路変更であり、インターネットから NAS のプロキシポートに触れさせる必要は通常ありません。もし外出先から家の Mihomo を使いたいなら、別途 VPN（WireGuard など）を立て、そのトンネル内だけにポートを開く方が安全です。
7 端末側：デフォルトゲートウェイと DHCP
Windows では「設定」→「ネットワークとインターネット」→ 使用中の NIC →「ハードウェアのプロパティ」またはアダプタの詳細から IPv4 を手動に切り替え、デフォルトゲートウェイに NAS の IP、DNS に NAS の DNS ポートか公開 DoH を指定します。Android／iOS は Wi-Fi ネットワークの詳細設定で「ルーター」「DNS」を静的に上書きできる機種がありますが、メーカー UI 差が大きいので、確実性を取るならルーター DHCP でオプションを配る方式が楽です。Synology の DHCP Server を使う場合、スコープの「ゲートウェイ」欄に NAS のデータポート IP を入れ、DNS も NAS か別リゾルバを指定します。既存ルーターの DHCP を止めずに二重配布しないよう、対象 VLAN だけ Synology に任せるなどの設計が必要です。
ゲートウェイを NAS に向けた直後にインターネットに出られない場合、まず NAS から ping 1.1.1.1 が通るか、Mihomo コンテナが起動しているか、ルーターが ARP プロキシとして振る舞っているかを切り分けます。多くの初心者トラブルは「端末は NAS に届いているが、NAS がルーターへ戻す NAT を持っていない」「NAS の IP 転送が無効」です。ここは次節のテーマです。
8 IP 転送・NAT と「透過」の限界
端末のデフォルトゲートウェイを NAS にしただけでは、NAS は届いたパケットをそのまま捨てるか、ルーティングテーブルに従ってルーターへ転送しようとしても、戻りパケットの宛先 NAT が揃わず非対称になることがあります。一般的な Linux ルーターでは net.ipv4.ip_forward=1 と iptables の MASQUERADE で「NAS を経由してルーターへ出す」形を作りますが、Synology ではカーネルパラメータやパッケージのサポート範囲が機種依存であり、保証された機能として公式ドキュメント化されていない部分もあります。現実的な落としどころは、(1) まずはゲートウェイではなく各端末のシステムプロキシ／PAC で NAS の mixed ポートだけ向ける、(2) どうしても L3 が要るなら SSH での一時的な sysctl／iptables と、再起動後の永続化スクリプトを自分で背負う、(3) ルーター側で静的ルートを張る、の三段階です。
Mihomo の TUN を Docker 内で生かす構成は、クライアント PC 上の TUN 解説と概念は似ていますが、NAS ではコンテナとホストのネットワーク名前空間の境目でハマりやすいです。検証環境で tcpdump を取りながら、期待する五元組がコンテナの eth0 に現れるかを確認するのが近道です。要件が「とにかく家じゅうのブラウザだけ」なら、ゲートウェイ変更より DNS のみ Mihomo に寄せ、HTTP トラフィックをプロキシで掬う方が単純なケースもあります。
9 トラブルシューティング
- LAN から 7890 に繋がらない： DSM ファイアウォール、コンテナのポートマップ、
allow-lan、別プロセスのポート占有を順に確認します。 - 名前解決だけ失敗する： 端末の DNS が NAS を向いていない、または FakeIP と端末キャッシュの組み合わせでループしていないかを見ます。
- ゲートウェイ変更後に全滅する： NAS の転送と SNAT が未設定の可能性が高いです。当面ゲートウェイをルーターに戻し、mixed ポート経由のプロキシ運用で要件を満たせないか検討します。
- CPU が張り付く： ルールプロバイダの更新間隔が短すぎる、GeoIP が巨大、ログレベルが debug などを疑います。
- DSM アップデート後に起動しない： Container Manager とイメージの再 pull、ボリュームパスの変化（ストレージプール移行）を確認します。
10 まとめ
Synology DSM 7 の Docker（Container Manager）に Mihomo を載せ、Clash 互換の YAML で mixed ポートと DNS を公開し、DSM ファイアウォールで LAN からの到達だけを許可する、という下限セットは再現性が高いです。その上で端末のデフォルトゲートウェイを NAS に向けると、運用の見通しは良くなりますが、NAS がルーター相当の転送と NAT を背負えるかは環境依存が大きいです。ルーターを触りたくないという制約と引き換えに、NAS 側の責務が増える点を理解したうえで、まずはプロキシ明示から試し、必要なら段階的に L3 を足すのが安全です。
同じ Mihomo コアでも、手元の PC やスマホでは GUI クライアントのほうがルール試行が速い場面が多く、NAS は「常時オンで家じゅうに同じ出口を配る錨」として割り切ると運用が安定します。ビルドの入手や各 OS 向けクライアントはダウンロードページから辿ると、端末側の切り替え実験にも戻りやすいです。
ルーターに手を入れる代わりに NAS をゲートウェイに据える発想は、消費者向けハードの中では特に現実的な落としどころです。一方でセキュリティ境界も NAS に集約されるため、シークレット管理とファイアウォールの最小権限は手を抜かないことが長期運用の鍵になります。
