VMware VM·호스트 Clash: NAT·브리지·Host-Only

1 Hyper-V 튜토리얼과 무엇이 다른가

같은 «Windows 호스트 + 가상 머신 + Clash»라도, Hyper-V는 스위치·기본 게이트웨이 이야기가 중심에 서고, VMware는 VMnet·가상 어댑터(VMware Network Adapter VMnet1/VMnet8 등)가 먼저 등장합니다. 검색어로 VMware Workstation·Player·NAT·브리지·Host-Only를 쓰는 사용자는 설정 화면이 다르므로, Hyper-V 글의 문장을 그대로 가져오면 주소가 어긋나기 쉽습니다. 본문은 VMware 쪽 용어에 맞추되, 개념이 겹치는 부분은 Hyper-V·NAT·시스템 프록시 글과 대조해 이해를 돕습니다.

공통 전제는 같습니다. 게스트가 호스트의 127.0.0.1로 프록시를 걸면 안 되고, 호스트 Clash가 LAN 인터페이스에서 mixed·HTTP 포트를 열어야 합니다. 호스트 쪽 설치가 처음이라면 Clash Verge Rev Windows 설치로 포트와 시스템 프록시 동작을 먼저 맞춘 뒤 이 글을 적용하는 편이 빠릅니다.

2 NAT·브리지·호스트 전용, 한눈에

NAT는 게스트를 사설 대역 뒤에 두고 호스트가 SNAT 역할을 하는 전형적인 «공유기 뒤 PC» 모델입니다. Windows VMware에서는 보통 VMnet8에 해당하며, 게스트의 기본 게이트웨이는 가상 라우터 주소(흔히 서브넷의 .1 또는 .2—설정에 따라 다름)로 잡힙니다. 브리지(Bridged)는 물리 NIC와 같은 L2 세그먼트에 올라가 집 공유기 DHCP를 그대로 받는 모드라, 게스트의 게이트웨이는 대개 실제 공유기입니다. 호스트 전용(Host-Only)는 인터넷 없이 호스트·게스트만 만나는 고립 망(VMnet1 등)으로, 멀티 VM 실험이나 내부 서비스 테스트에 쓰입니다.

Clash 입장에서는 «어느 IP로 들어오는 TCP 연결을 받을지»와 «게스트가 프록시 서버 주소에 무엇을 쓸지»가 핵심입니다. 모드가 바뀌면 그 주소도 바뀌므로, 네트워크 모드를 바꾼 뒤에는 게스트 안의 수동 프록시·환경 변수를 반드시 다시 확인하세요.

가상 네트워크 편집기 Windows에서는 편집 → 가상 네트워크 편집기에서 VMnet 서브넷·NAT 게이트웨이를 확인할 수 있습니다. 숫자가 문서 예시와 다르면 그대로 복붙하지 말고 자신의 화면을 기준으로 잡으세요.

3 NAT(VMnet8): 게이트웨이와 호스트 쪽 주소

NAT 모드에서 게스트는 ipconfig(Windows)나 ip route(Linux)로 기본 게이트웨이를 확인할 수 있습니다. VMware NAT에서는 이 게이트웨이가 가상 NAT 장치 쪽이며, 호스트는 같은 VMnet에 VMware Network Adapter VMnet8 같은 인터페이스로 붙어 있습니다. 실무에서는 «프록시 서버 = 게이트웨이 IP + Clash mixed 포트»가 먼저 통하는지, 아니면 호스트 어댑터에 할당된 호스트의 VMnet8 주소(예: 192.168.xxx.1)로 붙어야 하는지를 한 번씩 시험합니다. 둘 중 하나는 반드시 같은 브로드캐스트 도메인에서 TCP로 열려 있어야 합니다.

호스트에서 Clash가 127.0.0.1:7890만 듣고 있으면 게스트는 연결할 수 없습니다. GUI에서 Allow LAN을 켜거나, 수신 주소가 0.0.0.0 또는 해당 VMnet 인터페이스를 포함하도록 설정합니다. 방화벽이 인바운드를 막으면 증상은 전부 «시간 초과»로만 보이므로, Windows 11 방화벽·Clash 글의 흐름으로 규칙을 추가합니다.

4 브리지: 호스트의 «실제 LAN IP»를 프록시 주소로

브리지 모드에서는 게스트가 물리망과 같은 대역의 IP를 받습니다. 이때 게스트의 기본 게이트웨이는 거의 항상 집·사무실 공유기이고, 호스트 PC는 그 망의 또 하나의 장치일 뿐입니다. 따라서 Clash 프록시 서버 주소로는 «가상 NAT 게이트웨이»가 아니라, 호스트 Windows에서 ipconfig로 확인한 브리지에 쓰는 물리/무선 어댑터의 IPv4(예: 192.168.0.42)를 넣습니다. 노트북이 Wi-Fi만 쓰다가 유선으로 바꾸면 이 숫자가 바뀌므로, DHCP 예약이나 호스트 고정 IP가 필요하면 미리 잡아 두는 편이 덜 헷갈립니다.

브리지에서 흔한 실수는 «게스트 게이트웨이를 호스트 IP로 바꾼다»는 식의 조언을 그대로 적용하는 것입니다. 호스트가 공유기 역할의 IP 포워딩·NAT을 완전히 제공하지 않으면 인터넷 전체가 끊깁니다. 입문 단계에서는 HTTP/HTTPS 프록시 주소만 호스트로 두고, 라우팅 표는 건드리지 않는 것이 안전합니다.

같은 포트 번호 주의 브리지는 NAT처럼 포트 포워딩 계층이 없어서, 호스트와 게스트가 동시에 7890에 서비스를 올리면 충돌이 납니다. 한쪽 포트를 바꾸거나, 게스트에서는 다른 포트로 Clash를 띄우세요.

5 호스트 전용(Host-Only): 고립 망에서의 호스트 IP

호스트 전용은 인터넷이 필요 없을 때 호스트와 VM만 통신하게 만드는 모드입니다. VMware는 보통 VMnet1 등 별도 서브넷을 쓰고, 호스트에는 VMware Network Adapter VMnet1에 IP가 잡힙니다. 게스트에서 프록시로 쓸 주소는 대개 그 서브넷에서의 호스트 쪽 IP(흔히 .1)입니다. 다만 가상 네트워크 편집기에서 서브넷을 바꿨다면 문서 예시와 다를 수 있으니, 호스트·게스트 각각에서 ipconfig·ip addr로 확인하는 것이 정답입니다.

Host-Only는 외부와 격리되므로 보안 실험에는 좋지만, 게스트가 동시에 인터넷도 필요하면 NIC를 하나 더 달아 NAT 또는 브리지를 병행하는 구성이 일반적입니다. 이때 «어느 NIC로 프록시를 보낼지»가 갈라지므로, 게스트 OS 안에서 라우팅·DNS 기본값이 어떤 인터페이스를 타는지도 함께 확인하세요.

6 Allow LAN을 켜야 하는 시점

게스트 IP에서 호스트 Clash의 mixed·HTTP 포트로 TCP 연결이 들어오려면, 데몬이 루프백만 바인딩해 있으면 안 됩니다. 대부분의 GUI는 Allow LAN 스위치로 이를 켜며, 꺼져 있으면 증상은 항상 연결 거부·시간 초과입니다. 켠 뒤에도 안 되면 Windows Defender 방화벽 인바운드 규칙과, 회사 보안 제품이 로컬 프록시 포트를 막는지 확인합니다.

Allow LAN은 같은 L2에 있는 다른 장치에도 포트가 노출될 수 있다는 뜻이므로, 카페·공용 Wi-Fi에서는 끄거나 사용 후 즉시 복구하는 습관이 좋습니다. 호스트에서 TUN 모드만 켜 두고 시스템 프록시는 끈 경우, 게스트는 «시스템 프록시를 따라간다»고 가정하면 안 되고, 명시적으로 호스트 IP:포트를 검증해야 합니다. TUN 전반은 TUN 모드 가이드를 참고하세요.

보안 범위 LAN 허용은 편의 기능이지 접근 제어 목록이 아닙니다. 신뢰할 수 있는 가정·사무 망에서만 사용하고, 가능하면 호스트 방화벽으로 소스 IP를 VM 서브넷으로 제한하세요.

7 Windows 게스트: 시스템 프록시와 수동 서버

Windows 게스트에서는 설정 → 네트워크 및 인터넷 → 프록시에서 수동 프록시를 켜고, 앞에서 확인한 호스트 측 IP와 Clash mixed·HTTP 포트(예: 7890)를 넣는 방식이 가장 직관적입니다. 주소에 127.0.0.1을 넣으면 게스트 자신을 가리키므로 실패합니다—반드시 NAT/브리지/Host-Only에 맞는 호스트 방향 주소를 사용하세요. Microsoft Store·UWP 앱만 예외라면 UWP·Loopback 이슈를 게스트 안에서 점검합니다.

PowerShell에서 빠르게 검증하려면 Test-NetConnection -ComputerName <호스트IP> -Port 7890처럼 TCP 연결만 먼저 확인한 뒤, 브라우저·curl로 확장합니다. 회사 GPO가 프록시를 덮어쓰면 사용자 설정이 무시되므로, 그 경우에는 IT 정책과 충돌하지 않는지 확인이 필요합니다.

8 Linux 게스트: 환경 변수·apt·도구별 설정

셸에서 http_proxy·https_proxy를 http://호스트IP:포트 형식으로 export하고, apt는 /etc/apt/apt.conf.d/에 Acquire::http::Proxy를 별도로 두는 패턴이 흔합니다. «기본 게이트웨이 = 프록시 주소 후보»가 맞는지는 모드에 따라 다르므로, 아래처럼 한 번에 넣기보다 먼저 ip route show default 결과를 보고 조정하세요.

bash

# Example: replace HOST_IP after checking route / VMware mode
export http_proxy="http://HOST_IP:7890"
export https_proxy="http://HOST_IP:7890"
curl -I --max-time 15 https://example.com

컨테이너·스냅 안에서 돌아가는 도구는 호스트 프록시와 또 다른 네트워크 네임스페이스를 쓸 수 있습니다. WSL2 Ubuntu 가이드와 개념은 비슷하지만, VMware 게스트는 WSL 미러 네트워킹 이슈 대신 «VMnet 모드»를 우선하세요.

9 포트 충돌과 DNS가 꼬이는 패턴

포트 충돌은 브리지에서 특히 잘 납니다. 호스트와 게스트가 같은 7890·7891 등으로 서비스를 띄우면 한쪽이 바인딩 실패하거나 예기치 않은 쪽으로 트래픽이 갑니다. 한쪽 포트를 바꾼 뒤 게스트 설정·환경 변수·브라우저 확장까지 동일하게 맞춥니다. DNS는 브라우저만 되고 터미널만 실패하거나, 일부 도메인만 깨지는 식으로 나타납니다. 게스트가 ISP DNS를 쓰는데 호스트 Clash는 fake-ip·분할 DNS를 쓰면 이름 해석 경로가 어긋날 수 있으므로, DNS·FakeIP 글과 함께 호스트 쪽 DNS 모드를 정리한 뒤 게스트 resolvectl·/etc/resolv.conf를 대조합니다.

스냅샷 VMware에서 NIC 모드를 바꾸기 전에 스냅샷을 찍어 두면 라우팅·프록시 실험 후에도 빠르게 되돌릴 수 있습니다.

10 트러블슈팅 체크리스트

호스트 Clash 로그에 게스트 IP에서 온 연결이 보이는가? 없으면 Allow LAN·바인딩·방화벽 순으로 본다.
ping이 막혀 있어도 HTTP 프록시는 TCP이므로 포트 프로브로 별도 확인한다.
NAT에서 브리지로 바꿨다면 이전에 쓰던 «게이트웨이=프록시 IP» 공식을 그대로 가져오지 않는다.
호스트 VPN이 켜지면 VMware 가상 어댑터 우선순위가 흔들릴 수 있다—실패 시 VPN 일시 중지로 비교한다.
ICMP·UDP·게임 트래픽은 HTTP 프록시만으로는 부족할 수 있다—그때는 TUN·별도 설계를 검토한다.

11 정리

VMware Workstation·Player에서 가상 머신이 Windows 호스트의 Clash·Mihomo를 쓰려면, 먼저 NAT·브리지·호스트 전용 중 어디에 붙어 있는지에 따라 «프록시 서버로 넣을 IP»가 달라진다는 점을 분리해 이해하는 것이 중요합니다. NAT는 VMnet 게이트웨이·호스트 VMnet 어댑터를, 브리지는 호스트의 실제 LAN IP를, Host-Only는 고립 망의 호스트 쪽 주소를 기본 후보로 삼습니다. 호스트에서는 Allow LAN과 방화벽을 맞추고, 게스트에서는 127.0.0.1 착각과 포트 충돌·DNS 경로만 정리해도 성공률이 크게 오릅니다. Hyper-V 기반 설명이 필요하면 Hyper-V 글을 함께 보세요.

동일한 GUI에서 규칙·로그·LAN 수신을 한 번에 다루면 VM과 물리 호스트를 오가며 디버깅할 때 부담이 줄어듭니다. 설치 패키지는 신뢰할 수 있는 배포 경로를 쓰는 것이 좋습니다.

→ Clash를 무료로 내려받아 VMware와 호스트 프록시를 맞춰 보세요

VMware 가상 머신이 Windows 호스트의
Clash를 탈 때: NAT, 브리지, 호스트 전용