Windows 가상머신(VM)이 호스트 Clash를 못 탈 때: VMware·Hyper-V 브리지 NIC와 mixed-port·게이트웨이로 검증하기 (2026)

1. 흔한 증상: “호스트만 되고 VM만 안 된다”

호스트 Windows에서 Clash Verge Rev 등으로 시스템 프록시나 TUN을 켜 두면 Edge·Chrome은 정상인데, 가상머신 안에서는 같은 사이트가 타임아웃되거나 apt update가 거의 진행되지 않습니다. 반대로 VM만 따로 “다이렉트”로 두고 싶은 경우는 드물고, 대개는 호스트와 같은 출구를 쓰고 싶어하는 시나리오입니다. 이때 VM이 NAT 모드이면 게스트의 기본 경로는 “가상 라우터 → 외부”로 잡히기 때문에, 호스트에 떠 있는 127.0.0.1:7890 같은 주소는 게스트 입장에서 아무 의미가 없습니다. 게스트 OS가 루프백을 호스트와 공유하지 않기 때문입니다.

또 한 가지는 VM 안에서 수동으로 프록시를 127.0.0.1로 넣어 둔 채 “왜 안 되지?”로 남는 경우입니다. 이는 WSL2에서 호스트 IP를 명시해야 하는 문제와 같은 맥락입니다. VM에서는 반드시 호스트 LAN IP(예: 192.168.0.xx)나, 조직망이라면 IT에서 허용한 중계 주소를 써야 합니다.

2. NAT와 브리지: 게이트웨이가 달라지는 이유

NAT(또는 Hyper-V “기본 스위치”에 가까운 구성)에서는 게스트가 사설 대역을 받고, 외부로 나갈 때 호스트가 SNAT 역할을 합니다. 이 구조에서는 “게스트 → 호스트의 특정 TCP 포트로 붙어서 프록시”도 가능하지만, 호스트 IP를 정확히 알아야 하고, 가상 DHCP가 바뀔 때마다 고정이 깨질 수 있습니다. 반면 브리지(Bridged) 모드는 게스트 NIC을 물리 스위치와 같은 브로드캐스트 도메인에 올려, 공유기에서 보기에 “또 한 대의 PC”처럼 동작하게 합니다. 이때 게스트의 기본 게이트웨이는 보통 공유기(192.168.x.1 등)이고, 호스트 PC도 같은 대역의 또 다른 IP를 가집니다. 즉 VM과 호스트가 동급 이웃이 되므로, VM에서 http://호스트IP:mixed-port로 접속하는 모델이 이해하기 쉽습니다.

어떤 독자는 “브리지가 보안상 부담스럽다”고 느낄 수 있습니다. 폐쇄망이나 실험망이 아니라면, 대안으로 NAT를 유지한 채 호스트만의 고정 내부 주소를 VM 라우팅 표에 넣는 방법도 있지만, 설정 난이도가 높아 본문에서는 브리지 + 호스트 IP 패턴을 기본으로 둡니다. LAN 프록시에서 설명한 allow-lan 개념이 그대로 이어집니다.

3. 호스트 Clash: mixed-port·allow-lan·바인딩

Mihomo·Clash Meta 계열 설정에서 mixed-port를 하나 정합니다(예: 7890). HTTP와 SOCKS를 한 포트에서 받는 구성이면, VM 안의 브라우저는 보통 HTTP 프록시만 지정해도 되고, 터미널은 ALL_PROXY=socks5h://...를 병행할 수 있습니다. 다음으로 allow-lan: true를 확인합니다. 이 값이 꺼져 있으면 데몬이 127.0.0.1에만 바인딩되어, 이웃 IP인 VM에서 오는 SYN이 거절됩니다. GUI 클라이언트는 초보자 가이드의 흐름으로 프로필을 적용한 뒤 YAML이나 설정 화면에서 위 두 항목을 맞추면 됩니다.

bind-address를 특정 인터페이스로 한정해 두었다면, 브리지 환경에서 그 인터페이스가 실제로 VM 트래픽이 들어오는 쪽과 일치하는지 확인합니다. “이론상 맞는데 연결 거절”이 계속되면 netstat나 클라이언트 로그로 리슨 주소를 다시 봅니다.

4. Windows Defender 방화벽: 인바운드 TCP 허용

호스트에서 allow-lan을 켜도, Windows 방화벽이 해당 TCP 포트를 막으면 VM에서는 타임아웃만 보입니다. 인바운드 규칙으로 Clash 실행 파일 또는 포트(예: TCP 7890)를 “개인 네트워크” 프로필에서 허용하는 것이 일반적입니다. 회사 PC라면 보안 제품이 별도 방화벽을 얹었을 수 있으니, 그때는 IT 정책을 따릅니다. 테스트할 때는 잠깐 방화벽을 끄고 재현이 사라지는지로 원인을 가르는 방법도 있으나, 최종적으로는 최소 권한 규칙만 남기세요.

5. 호스트 IPv4 확인하기

브리지 구성에서 호스트는 물리 LAN과 같은 대역의 IPv4를 가집니다. PowerShell에서 Get-NetIPAddress -AddressFamily IPv4로 후보를 나열하거나, 작업 표시줄의 네트워크 속성에서 어댑터별 주소를 확인합니다. VMware Virtual Adapter·vEthernet (WSL)·Loopback에 붙은 사설 주소를 게스트에 넣으면 실패하기 쉽습니다. 목표는 “실제로 공유기와 통신하는 그 이더넷/Wi-Fi”의 IPv4입니다. 노트북이 유·무선을 바꿀 때마다 바뀌므로, 장시간 실험이면 호스트에서 DHCP 예약을 쓰거나 고정 IP를 검토합니다.

6. VMware Workstation·Player에서 브리지로 전환

가상머신을 끈 뒤 VM → Settings → Network Adapter에서 Bridged를 선택하고, 자동 브리지가 원하는 물리 NIC을 고르는지 확인합니다. 여러 VPN이 물리 NIC을 가리면 브리지 대상이 엉뚱한 곳으로 잡힐 수 있으니, 테스트 시에는 불필요한 가상 어댑터를 정리합니다. 게스트가 부팅되면 ip route(Linux)나 route print(Windows)로 기본 게이트웨이가 공유기인지 확인합니다. 같은 서브넷 안에서 호스트 IP로 ping이 되면 L3 이웃 관계는 정상에 가깝습니다(ping이 막혀 있어도 TCP 프록시는 될 수 있음).

7. Hyper-V: 외부 가상 스위치

Hyper-V 기본 스위치는 NAT 성격이 강해, VMware에서 말하는 브리지와 다른 느낌을 줄 수 있습니다. 게스트를 물리 LAN과 같은 대역에 두려면 가상 스위치 관리자에서 외부 스위치를 만들고, 물리 NIC과 브리지되도록 연결합니다. 그다음 VM의 네트워크 어댑터를 그 스위치에 붙입니다. 이후 절차는 앞선 절과 동일하게 “호스트 LAN IP + mixed-port”로 검증합니다. 보안 부팅·Credential Guard 등과 겹치면 VMware와 Hyper-V를 동시에 쓰지 못하는 환경도 있으니, 한 가지 하이퍼바이저만 켠 상태에서 테스트하는 것이 좋습니다.

8. 게스트 안에서 프록시 지정: 브라우저·환경 변수

Windows 게스트라면 설정 앱의 프록시에 호스트IP:7890을 넣거나, 브라우저만 수동 프록시로 묶을 수 있습니다. Linux 게스트라면 셸에 다음과 같은 형태를 씁니다(포트는 본인 환경에 맞게).

export HOST_WIN=192.168.0.10
export http_proxy="http://${HOST_WIN}:7890"
export https_proxy="http://${HOST_WIN}:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export all_proxy="socks5h://${HOST_WIN}:7890"
export ALL_PROXY="$all_proxy"

apt는 /etc/apt/apt.conf.d/ 아래에 Acquire::http::Proxy를 따로 두는 편이 안정적입니다. curl -I https://example.com로 먼저 확인하고, 실패 시 Connection refused면 포트·바인딩·방화벽, 장시간 대기면 DNS·노드 쪽을 의심합니다.

9. DNS: 게스트가 묻는 이름이 호스트와 같은가

프록시까지는 타는데 특정 도메인만 실패하면, 게스트의 DNS 서버가 공유기·사내 DNS를 가리키는지, DoH를 쓰는지 살펴봅니다. Clash의 fake-ip는 “Clash를 경유하는 앱”과 잘 맞지만, 게스트가 프록시 없이 직접 조회하는 트래픽은 호스트와 다른 경로를 탈 수 있습니다. 증상이 도메인별로 갈린다면 호스트 Clash 로그에 해당 VM의 소스 IP가 찍히는지 먼저 확인합니다. 로그가 없으면 아직 프록시로 안 들어온 것입니다.

10. TUN 모드와 VM의 관계(짧은 주의)

호스트에서 TUN이 전역 캡처를 하더라도, 그것이 자동으로 “VM 내부까지 동일 정책”을 보장하지는 않습니다. VM은 별도 스택을 가진 게스트 OS이기 때문입니다. 본문의 접근은 “VM이 의도적으로 호스트 프록시 포트를 타게 만든다”는 명시적 모델입니다. 호스트 TUN과 충돌하는 로컬 대역이 있으면, 예외 규칙이나 브리지 대역 선택을 조정합니다.

11. 검증 체크리스트

순서를 요약하면 다음과 같습니다. (1) 호스트에서 mixed-port·allow-lan 확인, (2) 방화벽 인바운드 허용, (3) 올바른 호스트 LAN IPv4 확인, (4) VM을 브리지(또는 동등한 L2 접근)로 연결, (5) 게스트에서 curl로 프록시 동작 확인, (6) 브라우저·apt 등 앱별 설정 반영. 중간에 막히면 호스트 Clash 연결 로그에 VM IP에서 들어온 세션이 보이는지가 가장 빠른 이정표입니다.

12. 정리

Windows 가상머신이 호스트 Clash를 “모른 척”하고 직접 나가려다 막히는 문제는, 대개 가상 NIC 모드와 프록시 주소 착각, 그리고 LAN 수신·방화벽 세 가지로 귀결됩니다. 브리지로 게스트를 물리 LAN과 같은 축에 두고, 호스트의 mixed-port를 allow-lan과 함께 열어 두면, VMware·Hyper-V 모두에서 재현성 있게 검증할 수 있습니다. WSL2나 Docker와 달리 게스트는 완전한 OS이므로, “루프백=호스트” 가정을 버리고 이웃 IP로 프록시를 찍는 습관을 들이면 이후 트러블슈팅이 쉬워집니다. GUI로 프로필·로그를 한 화면에서 다루고 싶다면 Clash 기반 공식 클라이언트를 기준으로 삼는 편이 안전합니다. 유사 도구 대비 규칙·로그·업데이트가 한 흐름에 모여 있어 교차 검증에 유리합니다. → Clash를 무료로 다운로드하고 VM과 호스트를 같은 mixed-port 축으로 맞춰 보세요