1 Linux 宿＋QEMU/KVM が他の仮想化記事と違う理由
既存の当サイト記事では、WSL2 や VMware、Parallels など、ゲストからホストのプロキシへ載せる型は数多く扱ってきました。一方で Linux をホストにした QEMU/KVM は、仮想 NIC の名前もゲートウェイの意味も「Windows の VMnet」や「WSL の仮想スイッチ」と一致しないため、検索語をそのまま持ち込むと設定が噛み合いません。ここでの焦点は、ゲストが属する L3 の種類が「ユーザーモード（SLIRP）」か「libvirt の NAT ブリッジ」か「物理 LAN ブリッジ」かで、ホスト上の Mihomo の混合ポート（HTTP／SOCKS）に届けるべき IPv4が変わる点です。骨格はどのプラットフォームでも同じで、127.0.0.1 はゲスト内のループバックであり、宿の Mihomo には届きません。
宿で Mihomo を systemd 常駐させる前提は、Linux 向け Mihomo＋systemd の記事でポート番号と設定ファイルの所在を押さえてから読み進めると、以降の「どの IP に繋げばよいか」が素直に理解できます。
2 宿側の前提：リッスンアドレスと Allow LAN
ゲスト OS はホストにとって 別マシンからの接続に相当します。Mihomo／GUI クライアント側で Allow LAN（名称は製品により異なる）を有効にし、混合ポートが 127.0.0.1 だけでなく 0.0.0.0 側で LISTEN していることを確認してください。オフのままだと、正しいゲートウェイ IP を指定しても接続は拒否されます。検証が終わったらセキュリティのため Allow LAN を戻す、仮想マシンを止める、といった運用も検討してください。ホストの nftables／iptables で着信を絞っている場合は、該当 TCP ポートの許可も忘れずに確認します。
3 ユーザーモード・ネットワーク（SLIRP）と 10.0.2.2
QEMU のデフォルトに近い ユーザーモード・ネットワーク（-netdev user／SLIRP）では、ゲストはしばしば 10.0.2.0/24 系のプライベートアドレスを持ち、外向きは QEMU が NAT します。このとき ゲストから見た「ホスト本体」は、ドキュメント上も実務上も多くの場合 10.0.2.2 として参照できます。したがって、宿の Mihomo の混合 HTTP ポートが 7890 なら、ゲストでは http://10.0.2.2:7890 のように指定するのが定石です。virt-manager の XML でネットワークが <interface type='user'> に近い形になっている場合も同様の発想でよいことが多いですが、カスタム QEMU ラインを直接書いている環境では別の netdev 名やオプションがあるため、不通のときは ip route とゲストのデフォルトゲートウェイ表示を併せて確認してください。
ユーザーモードでは、ゲストから ホストの実 LAN 上の他 PC へ直接届かない制約が出やすく、逆に「検証用にインターネットだけ出せればよい」ケースではかえってシンプルです。複数 VM 同士や社内の別セグメントと積極的に話す必要があるなら、後述の NAT／ブリッジへ移行する判断材料になります。
curl -I --proxy http://10.0.2.2:7890 https://example.com4 libvirt のデフォルト NAT（virbr0／192.168.122.1）
virt-manager で「仮想ネットワーク」をデフォルトのまま使うと、多くのディストリビューションでは default ネットワークとして virbr0 が立ち、ゲストは 192.168.122.0/24 のようなレンジに DHCP で入ります。このときゲストの デフォルトゲートウェイ（例：192.168.122.1）は、ホスト側のブリッジインタフェース上のアドレスであり、プロキシの宛先としてその IP を使うのが素直です。つまり http://192.168.122.1:7890 の形です。環境によってサブネット番号が異なる場合があるため、ゲストで ip route show default を実行し、表示された「via」の IPv4 をそのままホスト名として使う手も確実です。
ここでの NAT は、外向き通信をホストがマスカレードするという意味での NAT であり、ゲストがホストのプロキシを使うこと自体には、Windows VMware 記事で説明した NAT モードと同型の理解で足ります。違いは VMnet8 の代わりに virbr0 が見えることだけです。
5 ブリッジ（macvtap／Linux bridge）を選ぶとき
ゲストを 物理 LAN と同じセグメントに載せるブリッジ構成では、ホストの Mihomo へ向けるべき IPは virbr0 ではなく、その LAN でホストが実際に使っている IPv4 です。同一 L2 上の別端末からプロキシポートへ TCP で入るのと同じ見方になるため、Allow LAN は引き続き必要です。ノート PC で有線と Wi-Fi を切り替えていると、ブリッジ先 NIC の取り違えで「ゲストだけ名前解決がおかしい」という症状も出やすいので、ip -br addr でホスト側の現物を確認してからゲストに書き込む癖をつけるとよいです。
6 NAT の「ポート転送」とプロキシ利用の棲み分け
QEMU の hostfwd=tcp::HOSTPORT-:GUESTPORT のようなオプションは、典型的には ホストの TCP ポートをゲスト内のサービスへ中継する用途（例：ゲスト SSH を localhost:2222 で触る）で説明されます。一方、ゲストのブラウザや apt が宿の Mihomo を使う場合、多くは ポート転送なしで、前述の 10.0.2.2 や 192.168.122.1 に対して直接プロキシポートへ TCP 接続すれば足ります。ポート転送や iptables／nft の DNAT が必要になるのは、(1) Mihomo がどうしても 127.0.0.1 だけでリッスンしており socat 等で別途トンネルを張る、(2) 複雑な複数ブリッジ間で経路を手作業で合わせる、といった例外的な制約に当たったときです。最初から転送ルールを増やすより、Allow LAN と正しい宛先 IP を優先してください。
libvirt のフックや virsh qemu-monitor-command で netdev を後付けする運用は上級者向けですが、思想は同じで、「外向きのプロキシ接続」は宛先 IP の特定が主戦場であり、転送は別問題として切り離して考えると混乱が減ります。
7 apt・コンテナレジストリ・ブラウザを安定させる
Debian／Ubuntu 系ゲストでは /etc/apt/apt.conf.d/ に Acquire::http::Proxy や Acquire::https::Proxy を置く方法や、一時的に sudo http_proxy=... を前置する方法があります。シェル全体で揃えるなら ~/.profile や systemd user 環境に http_proxy／https_proxy を書きます。Docker Engine では /etc/systemd/system/docker.service.d/http-proxy.conf の Environment= でデーモン自身のレジストリ pull にプロキシを載せるのが一般的です。ブラウザは OS のプロキシ設定か拡張でホストの IP を指してください。いずれも URL のホスト部分がユーザーネットなら 10.0.2.2、virbr NAT ならゲートウェイ IPというルールに戻ります。
コンテナ内からさらにプロキシを経由させる二重構成は、TLS インスペクションや企業プロキシと組み合わさると証明書エラーになりやすいため、どのレイヤで名前解決するかをチームで一本化しておくと運用が楽です。
8 DNS・FakeIP とログでの裏取り
ブラウザだけ Mihomo の DNS（FakeIP 等）を見に行き、apt や Docker はゲスト OS のリゾルバのまま、というズレがあると「ブラウザは通るが CLI だけ失敗」が起きます。名前解決まわりでつまずいたら DNS／FakeIP の実務記事を参照し、ゲストの /etc/resolv.conf をホスト側の推奨に合わせるか、接続ログでどのドメインがどのアウトバウンドに載ったかを追います。KVM 特有というより、分散クライアントの典型的な落とし穴です。
9 確認手順とよくある詰まり
- ホストで Mihomo を起動し、Allow LAN と混合／HTTP ポート番号を確認する。
- ゲストでユーザーネットか virbr NAT かを特定し、
10.0.2.2かゲートウェイ IP のどちらを宛先にするか決める。 curl -I --proxy http://HOST:PORT https://example.comで疎通し、Mihomo の接続ビューに流れが出るか見る。- 不通ならホストの LISTEN アドレス、nftables、別プロセスのポート奪い合いを疑う。
- ブリッジ構成に変えた直後だけ失敗するなら、ホストの実 LAN IPv4 の取り違えを疑う。
10 まとめ
Linux 宿の QEMU/KVM でゲストから Mihomo を使うとき、まず押さえるべきは 仮想ネットワークの種類ごとの「ホスト側到達可能 IPv4」です。ユーザーモード（SLIRP）では 10.0.2.2、libvirt のデフォルト NAT ではしばしば 192.168.122.1 のような ゲストのデフォルトゲートウェイと同じブリッジ IP、ブリッジでは実 LAN 上のホストアドレスを指します。いずれも Allow LAN と正しいポートが前提で、127.0.0.1 は使えません。NAT に付随するポート転送は、主にホストからゲストサービスへ穴を開ける用途であり、通常の「ゲストから宿プロキシへ出す」用途では、転送よりも宛先 IP の特定を優先すると筋が良いです。DNS は FakeIP と CLI の解決経路の差がつまずきやすく、ログで揃えます。
他 OS 上の仮想化と比べると検索語がブレやすい分、一度この骨格を覚えておくと、WSL2 や VMware の記事を読み返したときにも「結局はゲスト視点の IPv4 と Allow LAN か」と俯瞰しやすくなります。クライアントの入手は配布元を一本化する意味でも当サイトのダウンロードページから行い、ソースや Issue は GitHub を併用する程度に分けると運用が安定します。
同じ Linux でもコンテナではなく仮想マシンで隔離したい場合、本稿のネットワーク前提がそのまま効きます。逆に軽量な開発環境だけなら、要件次第で WSL2 側の記事と棲み分けて選ぶとよいでしょう。
