2026 Android 에뮬레이터(블루스택·AVD)가 인터넷이 안 되나요? Windows 호스트 Clash와 프록시 IP·mixed-port·NAT/브리지

① 이 글을 읽고 나면 정리되는 것

Windows 호스트에서 Clash의 mixed-port(환경마다 다르며 예로 7890 등)와 allow-lan 계열 옵션을 확인하고, PowerShell·명령 프롬프트의 ipconfig로 에뮬이 붙는 가상·물리 인터페이스에 대응하는 호스트 IPv4(이하 HOST_IP)를 잡을 수 있습니다. AVD 기본 NAT와 블루스택 등에서 보이는 브리지 유사 설정의 차이를 구분하고, 에뮬 안 Wi‑Fi 수동 프록시나 ADB의 http_proxy 등으로 목적지를 http://HOST_IP:실제포트 형태로 맞출 수 있습니다. 또한 ICMP ping과 TCP 성공이 다르다는 점, 방화벽이 수신 TCP만 막을 때 증상이 어떻게 보이는지도 짚습니다.

② 실기 Android·WSL2·Docker 글과 무엇이 다른가

스마트폰에 Clash for Android를 직접 설치하면 트래픽이 단말 안에서 끝나므로「같은 PC의 127.0.0.1」 착각이 적습니다. WSL2나 Docker는 문서에 host.docker.internal·resolv.conf 등 호스트로 가는 전용 표기가 정리되어 있는 경우가 많습니다. 반면 에뮬레이터는 제품마다 UI 이름이 다르고, 사용자가 에뮬 안에서 127.0.0.1을 프록시에 넣으면 그건 게스트 자기 자신을 가리키기 쉬워 호스트 Clash와 어긋납니다. 이 한 줄이 실무에서 가장 많이 남는 함정입니다.

③ 첫 번째 벽: 에뮬 안 127.0.0.1은 호스트가 아니다

호스트 Windows 브라우저에서 http://127.0.0.1:7890에 붙으면 그것은 호스트 프로세스인 Clash입니다. 그러나 AVD의 Android에서 같은 주소를 쓰면 게스트 OS의 루프백으로 가서 호스트와 연결되지 않습니다. 따라서 에뮬 쪽 프록시 설정에는 ipconfig 등으로 얻은 사설 IPv4(192.168.x.x, 172.x.x.x, Hyper-V vEthernet 등)를 HOST_IP로 두고 http://HOST_IP:실제 mixed-port 형식을 기본으로 삼는 것이 안전합니다. 숫자는 반드시 본인 클라이언트 화면·프로필에 표시된 값으로 고정하세요.

④ Android Studio AVD: NAT와 10.0.2.2

많은 기본 구성에서 에뮬레이티드 디바이스는 NAT 뒤의 사설 대역을 쓰고, 문서에 소개되는 대로 호스트 루프백에 대응하는 예약 주소 10.0.2.2가 쓰이는 경우가 있습니다. 다만 Clash가 모든 NIC에 열려 있고 방화벽이 허용한다는 전제가 없으면 “문서대로 한 줄”만으로는 끝나지 않을 수 있습니다. 라우팅이나 서드파티 런치어가 끼면 문자열 하나에만 의존하기보다 adb shell에서 ip route·ip addr로 게스트 관점을 한 번 확인하는 편이 낫습니다.

# adb shell 예시 — 경로 확인
ip route show
ip addr show

⑤ BlueStacks 등 서드파티 에뮬: NAT와 브리지 표기 읽기

블루스택류는 설치 과정에서 가상 어댑터를 추가하고 설정에 브리지·네트워크 모드를 띄우기도 합니다. 이름이 달라도 본질은 에뮬 트래픽이 어떤 호스트 NIC 경로로 밖으로 나가는지와 에뮬에서 HOST_IP:포트로 TCP 세션이 열리는지 두 가지입니다. Hyper-V 게스트와 호스트 Clash 글에서 다룬 세그먼트 정합 사고 과정과 겹치는데, 차이점은 게스트가 “풀 OS VM” 대신 에뮬 프로세스로 보인다는 점뿐입니다.

⑥ 준비 0단계: 호스트에서 mixed-port·allow-lan·바인드

에뮬에 손대기 전에 Windows에서 Clash Verge·시스템 프록시로 실제 mixed-port 번호를 메모하고 allow-lan을 켭니다. listen이 127.0.0.1만이면 에뮬에서 오는 연결은 애초에 도달하지 않습니다. 0.0.0.0 등 외부에서의 TCP를 받을 수 있는 형태인지 확인하세요. 같은 PC의 스마트폰이 Wi‑Fi로 붙는 경우와 동일한 층의 이야기이므로 LAN·방화벽 허용 글도 함께 보면 빠릅니다.

⑦ 1단계: ipconfig로 HOST_IP 고정

호스트에서 ipconfig로 어댑터별 IPv4를 나열하고, 에뮬이 실제로 사용하는 경로와 맞는 인터페이스의 주소를 HOST_IP 후보로 둡니다. 무선 LAN만 보고 실패하는 경우는 에뮬이 별도 가상 스위치 경로를 쓰고 있어서입니다. 게이트웨이 문자열을 무리하게 바꾸기보다, 애플리케이션 단 HTTP 프록시만 호스트 주소를 가리키는 편이 덜 깨집니다.

⑧ 2단계: Windows Defender 방화벽 수신 규칙

mixed-port에 대한 TCP 수신이 막히면 호스트 브라우저는 다른 경로로 잘 되는데 에뮬에서만 시간 초과처럼 보일 수 있습니다. 인바운드에서 해당 포트(또는 Clash 실행 파일) 허용, 네트워크 프로파일 확인을 합니다. ping이 되어도 TCP는 막히는 패턴은 흔하므로, 판별은 TCP 기준으로 하세요.

⑨ 3단계: 에뮬 안 수동 프록시를 HOST_IP:포트로

Android 설정의 Wi‑Fi 고급·프록시에서 호스트명에 HOST_IP, 포트에 실제 값을 넣습니다. UI는 버전마다 다릅니다. ADB로 settings put global http_proxy HOST_IP:포트 형태를 쓰는 방법도 있으나 기기 상태에 따라 다릅니다. 일부 앱은 시스템 프록시를 무시하므로, 먼저 프록시를 존중하는 브라우저로 호스트까지 붙었는지를 확인하면 규칙·DNS 이전 단계를 가릴 수 있습니다.

⑩ TUN·시스템 프록시·규칙의 적용 범위를 착각하지 않기

호스트에서 TUN이나 시스템 프록시를 켜도 그것이 자동으로 AVD 안 모든 앱에 전파된다고 기대하면 어긋나기 쉽습니다. 에뮬 트래픽이 Clash 코어에 닿은 뒤에야 분류 규칙·DNS 이야기가 의미를 가집니다. fake-ip·sniffing 이슈는 sniffing·예외 규칙 안내와 사용자 정의 규칙 튜토리얼을 순서적으로 참고하면 됩니다만, 그 전에L4 연결이 호스트 문자열까지 열렸는지부터 확인하는 순서가 맞습니다.

⑪ 체크리스트(위에서 아래로)

1. 호스트 Clash에서 mixed-port 번호와 allow-lan·바인드가 외부에서도 받도록 되었는지.
2. ipconfig로 에뮬 경로와 맞는 HOST_IP 문자열 하나로 고정했는지.
3. 에뮬에서 해당 주소와 포트로 TCP가 되는지(원시 테스트·curl --proxy http://HOST_IP:PORT … 등). ICMP만으로 결론 내지 않기.
4. 방화벽·백신 HIPS 인바운드가 막고 있지 않은지.
5. 에뮬 앱 설정이 여전히 127.0.0.1을 가리키지 않는지.

⑫ 정리

Windows에서 Clash를 돌리며 안드로이드 에뮬레이터를 쓸 때의 핵심은, 에뮬을 별도 게스트로 보고 127.0.0.1 대신 HOST_IP:mixed-port로 각 층을 맞추고, allow-lan과 방화벽으로 수신을 연 다음, 게스트 쪽 수동 프록시까지 한 줄로 잇는 것입니다. 블루스택과 AVD의 UI는 달라도 호스트 IPv4·TCP 도달·수동 프록시 세 단은 같은 유형입니다. 클라이언트 설치·업데이트는 입문 튜토리얼과 다운로드 페이지를 기준으로 잡고, 장기 구조는 Clash와 VPN 비교로도 정리해 볼 수 있습니다. → Clash를 무료로 받아 호스트 회로를 먼저 안정시킨 뒤, 에뮬에서 문자열 테스트로 앱별로 확인해 보세요.