本稿でできるようになること
作業のゴールは、単一の compose ファイルとホスト上の設定ディレクトリがあれば、別マシンでも同じ手順でMihomo コンテナを立ち上げられる状態です。コンテナは再起動しても設定を失わず、7890 や 7891 などミキサー／SOCKS用に決めたポートがホストに公開され、同じLANのPCやスマートフォンから明示プロキシとして指定できるようになります。外部コントローラやダッシュボード用に 9090 系を開く場合も、どのインタフェースにバインドするかと認証の有無をセットで決めると安全です。ここまで整えば、ルーター側で透明プロキシを組まなくても、コンテナプロキシとして開発機やメディア端末を束ねる土台になります。
コンテナプロキシの心象図：ホストとポートの役割
Docker は別のネット名前空間にプロセスを閉じ込めるため、コンテナ内で 0.0.0.0:7890 をListenしていても、それが自動的にLAN全体に開放されるわけではありません。ポートマッピング ホスト:コンテナ を書いたとき、実際に他機器から触れるのはホストのIPとホスト側ポートです。127.0.0.1 にだけマップするとホスト自身からは届くが、別PCからは届きません。0.0.0.0:7890:7890 のように書くと、ファイアウォール次第でLANからも見える形になります。つまり「Allow LAN をオンにしたのに繋がらない」は、バインドアドレスとpublish の幅のどちらかが狭いことが多いです。
用語の整理：docker-compose.yml の ports は「ホストへ穴を開ける」設定です。expose は同一ユーザ定義ブリッジ内の他コンテナ向けで、ホストやLANには届きません。目的が「スマホからプロキシを使う」なら ports が主役です。
ボリュームマウント：設定をホスト側に残す
コンテナを捨てても残したいのは、購読URLを含む可能性のある YAML、rule-providers のキャッシュ、場合によっては GeoIP や ASN 用のデータです。典型はホストに ./mihomo を作り、コンテナ内の作業ディレクトリ（イメージの README が示す -d パス）にマウントします。パスは配布元ごとに違うため、利用するイメージのドキュメントを一度だけ確認し、そこに合わせて volumes: を書いてください。読み取り専用にしたいファイルがある場合は :ro サフィックスも検討できますが、キャッシュ書き込みで失敗するなら読み書きのままにします。
権限トラブルは「コンテナ内ユーザーUIDとホスト側ディレクトリの所有者が噛み合わない」パターンが定番です。rootless Docker や特定UIDで動くイメージでは、chown か compose の user: 指定で揃えるとログに出る Permission denied が消えやすくなります。NAS 製品では共有フォルダのACLが絡むため、公式のコンテナUIからマウントパスを選ぶより、テスト用にローカルディスク上の単純なパスで一度通してから移すと切り分けが早いです。
docker-compose.yml のスケッチ
以下は説明用の雛形です。イメージ名・タグ・作業ディレクトリは、実際に追うリリースに合わせて置き換えてください。restart: unless-stopped を付けておくと、ホスト再起動後もサービスが戻りやすく、再現性という本稿の主題に合います。
# Sketch — replace image, paths, and ports with your environment
services:
mihomo:
image: metacubex/mihomo:latest
container_name: mihomo
restart: unless-stopped
volumes:
- ./mihomo-config:/root/.config/mihomo
ports:
- "7890:7890" # mixed / HTTP depending on your config.yaml
- "7891:7891" # SOCKS if you expose it
- "9090:9090" # external-controller (protect with secret / firewall)
# Some images accept extra flags via command:
# command: ["-d", "/root/.config/mihomo"]
config.yaml 側の port・socks-port・mixed-port・external-controller と、compose の ports の数字の対応がズレていると「コンテナは起動しているのに接続できない」になります。まずコンテナ内で ss -lntp 相当の情報を確認し、実際にListenしている番号に合わせてマップを直すのが確実です。
allow-lan とバインドアドレス
Mihomo 系では allow-lan: true とし、リスナーを 0.0.0.0 側に寄せる構成がよく使われます。ただしコンテナのポートpublishが127.0.0.1限定のままでは、LANからは一生届きません。Docker Desktop や一部NAS UIでは「ホスト側のバインド」を細かく選べるため、compose とGUIの両方を見る癖が必要です。セキュリティ的には、LANに開くほど認証のないHTTPプロキシは誤利用されやすいので、可能なら信頼できるセグメントだけに絞る、もしくはVPNの内側に置く、といったネットワーク設計とセットで考えてください。
別端末から使う：プロキシURLの書き方
同じLANのPCなら、ブラウザやOSの手動プロキシに http://NASのIP:7890 のようにホストのIPアドレスを書きます。コンテナの内部IPを直接書いても、通常は意味がありません。スマートフォンアプリが「プロキシホスト」欄を持っている場合も同様で、到達できるのはルーティングテーブル上の次ホップだという意識を持つと設定ミスが減ります。HTTPS トラフィックをHTTP CONNECT で流す典型構成では、クライアント側が「プロキシの証明書」を要求しない限り、中間者としての挙動は出口ノード側のプロトコルに依存します。細かいDNSの話は Meta コア DNS リーク防止ガイド に譲りますが、コンテナだけ立てて端末のDNSが別経路のままだと、ルールと実接続のズレが起きやすい点は裸機運用と同じです。
TUN をコンテナで使う話：期待値を下げる
裸機Linuxで TUN と systemd を組む記事とは対照的に、コンテナ内TUNはホストカーネル・ランタイム・追加能力（capabilities）の話が一気に増えます。/dev/net/tun のデバイス渡し、NET_ADMIN、場合によっては privileged や network_mode: host まで検討が及びます。network_mode: host にするとポートマッピングの模型は変わり、代わりにホストのネットワークスタック上で直接Listenする形に近づきます。どちらがよいかは「LANの他端末にプロキシだけ晒したい」のか「そのホスト上の全トラフィックをコアに載せたい」のかで分かれます。2026年現在、多くの読者の最初の一歩はポートプロキシで十分なことが多く、TUNは要件がはっきりしてから入れるとトラブルコストを抑えられます。
注意：privileged や過剰な capability 付与は攻撃面を広げます。本当に必要な権限だけに絞り、更新可能な最小イメージと組み合わせて運用してください。
NAS と VPS での差分
クラウドVPSでは、プロバイダのセキュリティグループやufwで7890番を全世界に開放しないよう注意します。必要ならSSHトンネルやWireGuardの内側だけにプロキシを置く方が無難です。自宅NASでは、ルーターのポートフォワードでプロキシを外向きに晒す構成は、認証が弱いままだと第三者の中継点にされかねません。家族やゲストWi‑Fiから見える範囲も含め、どのSSIDからそのポートが見えるかを一度マップに起こすと事故が減ります。
ヘルスチェックとログの見方
docker compose logs -f で起動時の YAML エラーをすぐ拾い、購読フェッチ失敗やルールコンパイルエラーがループしていないかを確認します。ヘルスチェックを付けるなら、外部コントローラの /version 相当や、ローカルで curl できるミニマルなエンドポイントを叩く方式が扱いやすいです。設定変更のたびにコンテナを再作成するのではなく、APIリロードが使える構成にしておくと試行錯誤が速くなります（利用中のバージョンでサポート範囲を確認してください）。
よくあるつまずき
ホストからは繋がるがLANから繋がらない：ports が 127.0.0.1 束縛になっていないか、OSファイアウォール、NASのセキュリティパネルを疑います。
コンテナはhealthyだが一切プロキシできない：config.yaml のモードが direct のまま、プロファイルが空、プロキシグループ名とルールの参照が不一致、などを順に見ます。
再起動のたびにルールキャッシュが毎回取り直す：ボリュームが読み書き可能か、パスがコンテナ再起動で別ボリュームに差し替わっていないかを確認します。
ドキュメントとクライアント入手
コンテナはあくまでコアを包む箱であり、日常のブラウザ体験をGUIで整えたい場合は、Windows や macOS 向けクライアントと併用する構成も一般的です。インストーラ類は 公式ダウンロードページ から揃えると、リリース資産の取り違えを防ぎやすくなります。用語やモードの整理は ドキュメント・チュートリアル も参照してください。ソースコードの閲覧やIssue追跡は各プロジェクトのGitHubが向いていますが、日々のクライアント入手はサイト側の導線に寄せると目的が混線しにくいです。
まとめ
Docker で Mihomo を運用するときの主役は、イメージの新しさよりcompose・ボリューム・ポートの三本柱です。docker-compose で起動と再起動を固定し、ボリュームマウントで設定とキャッシュをホストに残し、ポートマッピング と allow-lan・バインドを整合させれば、コンテナプロキシとしてLAN端末から安定して使える土台ができます。TUN でホスト全体を載せ替えたい場合は裸機や network_mode: host など別レイヤの検討になり、本稿の「まずプロキシポートを確実に開ける」という段階とは難易度が一段上がると心得ておくと安全です。
同じポリシーをデスクトップでも再現したい場合、GUI クライアントの方がログの見え方が友好的なことが多く、サーバー側コンテナと設定思想だけ共有する使い分けも現実的です。安定した体験を優先するなら、エコシステム全体を公式ページから揃え、本稿のコンテナ構成と比較検証するのも有効です。