Android エミュレーターがオフライン？Windows ホストの Clash と IP・mixed-port・NAT／ブリッジを揃える（2026）
同じ Windows 上で Clash（Clash Verge Rev／Mihomo 系）は動いているのに、Android エミュレーター（Android Studio の AVD や BlueStacks など）のブラウザやアプリだけが外に出ない、あるいは手動プロキシを入れても接続できない——原因はしばしば購読やノードではなく、エミュ内の 127.0.0.1 が ホストの Clash を指さないこと、NAT 背後の アドレス空間、mixed-port への 到達性、Windows ファイアウォール のどれかが噛み合っていないことにあります。本稿は 実機で Clash for Android を使う手順 や、WSL2 からホスト代理を使う記事、Docker Desktop とは棲み分け、エミュレーター 利用者向けに ホスト IP・ブリッジ／NAT・allow-lan を一連で整理します。利用は法令と利用ポリシーの範囲内で行ってください。
この記事で最後まで分かること
Windows ホストで Clash の mixed-port（多くの環境で例として 7890）と allow-lan 相当の設定を確認し、コマンド プロンプト や PowerShell の ipconfig から、エミュが接続している仮想／物理 インターフェース に対応する ホストの IPv4（以下 HOST_IP）を特定できます。AVD の既定 NAT と、ブリッジ 相当の構成で変わる「エミュから見た次ホップ」のイメージを押さえ、エミュ内 Wi‑Fi の手動プロキシ や ADB 経由の global_http_proxy など、自分の運用に合わせた指定先を http://HOST_IP:7890 形式に揃えられます。さらに 受信の規則 で TCP の宛先ポートが開いているか、ICMP ではなく TCP で疎通を確かめる理由も説明します。
実機の Android Clash や WSL2 記事との違い（なぜエミュだけハマるか）
スマートフォン 本体に Clash for Android を入れる場合は、端末上で完結するため、本稿のような「別マシンの 127.0.0.1」の取り違えは起きにくいです（概要は Android Clash 完全ガイド）。WSL2 や Docker Desktop は、ホストと別のネットワーク名前空間を持ちますが、多くの記事で紹介されている host.docker.internal や $(cat /etc/resolv.conf) 由来の nameserver のように、「ホストへ届けるための専用の書き方」 がドキュメント化されています。Android エミュ では、その接続先の書き方がプロダクトごとに異なり、さらに ユーザーが 127.0.0.1 をプロキシに書くとエミュ自身に向いてしまうという罠がある点が決定的に違います。
第一の壁：エミュの 127.0.0.1 は「エミュ自身」である
ホスト Windows のブラウザで http://127.0.0.1:7890 にアクセスすると、そこにあるのはホスト上の Clash の待ち受けです。一方、AVD の Android 内で同じ 127.0.0.1 を指定すると、届くのはゲスト Android のループバックであり、Windows 上の Clash ではありません。したがってエミュ側のプロキシ設定では、ホスト側で ipconfig により得た プライベート IPv4（例：192.168.x.x、172.x.x.x、仮想スイッチ由来の帯域など）を HOST_IP として使い、http://HOST_IP:実際のmixedポート と書くのが基本形です。数字は設定画面の表示に合わせ、以降 7890 は例示とします。
Android Studio AVD：NAT がデフォルトのときのイメージ
AVD のネットワークは多くの場合、ホストから見て NAT 背後のプライベートアドレスを Android が持ち、外向きはホストが肩代わりする形です。開発者ドキュメントで知られるように、標準構成ではゲスト側からホスト・ループバックへの特殊アドレス 10.0.2.2 が置かれることがあり、これはホストでの 127.0.0.1 に相当します。とはいえ、Clash が混在ポートを すべての NIC に bind しているわけでも、ファイアウォールだけで許可済みとは限らないので、運用によっては前述の HOST_IP:7890 の方が分かりやすいことがあります。どちらを試すにも、ホスト側の allow-lan と TCP の到達性 が先決です。
エミュの「Wi‑Fi」は物理ラジオではなく、仮想インターフェースの上に載った UI であることが多く、プロキシを指定してもアプリが無視する（独自のネットワークスタックを使う）こともあります。その場合でも、まず Chrome などプロキシ設定を尊重しやすいアプリで HOST_IP:7890 へ向けたときに海外サイトが開けるかを見ると、ルールや DNS 以前の到達性 を切り分けやすいです。ブリッジ や拡張コントロールでエミュに別セグメントの IP を持たせる構成では、HOST_IP の取り方が変わるため、構成変更のたびに ipconfig を正とします。
BlueStacks など他エミュ：ホスト側の「ブリッジ」表記をどう読むか
BlueStacks や各種ゲーム向けエミュでは、インストーラが 独自の仮想アダプター を追加し、設定画面に「ブリッジ」「有線／Wi‑Fi を共有」のような項目を出すことがあります。用語こそ違っても本質は共通で、エミュのトラフィックが最終的にどのホスト NIC を経由して外へ出るか と、エミュからホストの HOST_IP:7890 へ TCP で届くか の二点が揃えば、手動プロキシ 経由で Clash に乗せられます。NAT か ブリッジ かで困ったら、ホストで 既定ゲートウェイ が付いている実アダプター名と、エミュ関連の vEthernet 名を ipconfig の見出しで突き合わせ、取り違えを減らしてください。
ステップ0：ホストで Clash の mixed-port と allow-lan を確定する
エミュに入る前に、Windows 11 での Clash Verge 初回セットアップ 相当で、実際の mixed-port（または HTTP プロキシのポート）をメモし、allow-lan または LAN から接続 相当を有効にします。bind-address が 127.0.0.1 のみだと、エミュからの接続はそもそも届きません。0.0.0.0 など、同一 PC 上の他インターフェースからの着信を許す形になっているかを確認してください。スマートフォンから PC の Clash を使う場面と同じ層の話なので、LAN 許可とファイアウォール も参照すると早いです。
ステップ1：HOST_IP を ipconfig で取る（毎回でよい）
ホストで ipconfig を実行し、エミュが利用していると想定されるインターフェース の IPv4 アドレスを控えます。Hyper-V や 仮想スイッチ が有効な環境では、vEthernet (Default Switch) などに独立したアドレスが並びます。エミュがそこ経由でホストと話すなら、その行の IPv4 が HOST_IP 候補です。逆に無線 LAN だけ見て失敗する例は、エミュが別の仮想 NIC 側を向いているときに起きやすいです。Hyper-V 仮想マシンとホスト Clash の稿で触れた HV_HOST の考え方は、読み替えれば AVD にもそのまま移植できます。
ステップ2：Windows Defender ファイアウォールの受信規則
mixed-port 宛の TCP 受信 がブロックされていると、ホスト自身のブラウザでは通っても、エミュからだけ タイムアウト します。GUI では「受信の規則」に 特定のローカル ポート（実際の番号）を追加し、プロファイル（プライベート／パブリック）がエミュ側の経路と一致しているかを確認してください。詳細は上記 LAN 記事と同型です。ICMP（ping）は許可されていても TCP が閉じていることはよくあるため、疎通の正はポートに向けた Test-NetConnection や、エミュのシェルから可能なら curl 相当の確認に寄せます。
ステップ3：エミュ Android 側でプロキシを「HOST_IP:ポート」に合わせる
設定 → ネットワークとインターネット → インターネット → Wi‑Fi → 利用中のネットワーク → 詳細設定 からプロキシ を手動にし、ホスト名 に HOST_IP、ポート に 7890 などを入力します（UI の表記は Android の版により多少異なります）。開発者向けには ADB から settings put global http_proxy HOST_IP:7890 形式で入れる手法もありますが、端末状態や権限により失敗する場合があるため、まず Wi‑Fi UI で再現できるかを優先すると切り分けが楽です。アプリによってはシステムプロキシを無視するため、その場合はアプリ側のプロキシ設定か、より上位の経路設計が必要になります（本稿の主眼はホストとの層の整合です）。
ステップ4：DNS・ルール・TUN の「適用範囲」を誤解しない
ホストで TUN や システムプロキシ をオンにしていても、それが自動的に AVD 内の全アプリへ伝播すると期待するとハマりやすいです。エミュ内のトラフィックが Clash のコアに届いて初めて、分流ルール や DNS の話になります。fake-ip や sniffing の違和感は Clash Meta の sniffing と DNS を、モード全般は チュートリアル と併せてください。接続がコアに乗る前に プロキシ未設定 や ポート不達 を潰す順序が重要です。
Docker や WSL2 のドキュメントをそのまま当てはめない理由
Docker Desktop では host.docker.internal が公式に用意されている一方、AVD には同一の名前が常に存在するとは限りません。WSL2 では resolv.conf 上の nameserver がホストプロキシの置き場所のヒントになる場合がありますが、エミュはまた別のスタックです。いずれも「ループバックの意味がホストとズレる」点は共通なので、最終的に TCP で HOST_IP:実ポート が開いているか を軸にすると迷子になりにくいです。
上から順に使えるチェックリスト
（1） ホストの Clash で mixed-port の番号と allow-lan／bind を確認したか。（2） ipconfig でエミュ経路に合う HOST_IP を特定したか。（3） エミュから HOST_IP:7890 へ TCP が届くか（ping だけで判断しない）。（4） ファイアウォール 受信でブロックが残っていないか。（5） エミュ内のプロキシが 127.0.0.1 になっていないか。（6） ブラウザで試すならプロキシ尊重モードか。（7） ホスト Clash のログに接続が現れるか。ここまで揃うと、NAT／ブリッジ の表記に振り回されず、再現性のある排障がしやすくなります。
まとめ
Windows で Clash を動かしながら Android エミュレーター を使うときの本質は、エミュは別のゲスト機 であることを前提に、127.0.0.1 ではなく HOST_IP:mixed-port に各層を揃え、allow-lan とファイアウォールで着信を許し、ゲスト側の手動プロキシまで一気通貫で見ることです。BlueStacks と AVD で UI は違っても、ホスト IPv4・TCP 到達・手動プロキシ の三段が同型です。クライアントの導入と更新は 本サイトのダウンロードページ を主に参照し、ルールで挙動を追いやすいプロキシとして長期運用のしやすさを実感しやすいはずです。