이런 증상이면 먼저 읽는 길
호스트의 크롬·엣지는 Clash 시스템 프록시나 TUN로 해외·국내 응답이 있는데, VM 안의 브라우저·리눅스 셸·winget만 DNS는 되는 듯해도 TLS·다운로드가 멈춥니다. 반대로 호스트에서 Clash를 끄면 게스트가 곧장 인터넷이 된다면, 프로필보다 가상 스위치·라우팅 쪽을 의심하는 편이 낫습니다. NAT이면 기본 게이트웨이는 보통 .1이나 VMware에 정의된 .2 쪽이고, 게스트에서 ip route·ipconfig /all로 먼저 적어 둡니다. 그다음 호스트 Clash 포트에 다른 머신에서도 붙을 수 있게 Allow LAN이 켜져 있는지 보면 원인이 빨리 갈립니다.
NAT와 브리지: 게스트 눈에 보이는 호스트가 다르다
브리지(Bridged)이면 게스트는 공유기와 같은 L2·L3 층에 올라가 호스트와 비슷한 대역의 IP를 받는 경우가 많아, 호스트 LAN IP(예: 192.168.0.x)에 Clash mixed-port로 붙이기가 비교적 직관적입니다. NAT이면 게스트는 192.168.x.0/24 같은 VMnet 전용 세그먼트에 있고, Windows에는 vEthernet(VMware Network Adapter VMnet8 등)이 NAT 역할을 합니다. 이 분리된 세그먼트에서 인터넷으로 나가는 기본 경로는 게이트웨이이고, Clash는 호스트 OS에 떠 있으므로 게스트가 프록시로 가리켜야 할 IP는 “VMnet 쪽에서 본 호스트 쪽”이 됩니다. 대개 게이트웨이는 .1·.2이고, ip neigh·arp -a로 VMnet 쪽 인접 주소를 확인해 호스트 측 Clash에 붙을 주소를 확정할 수 있습니다.
1게스트에서 호스트(프록시 대상) IP 고정하기
리눅스 게스트는 ip route show default로, Windows 게스트는 ipconfig /all의 기본 게이트웨이로 먼저 봅니다. Clash에 붙이려는 주소는 대개 이 게이트웨이와 같은 서브넷에 있어야 합니다(게이트웨이 IP가 NAT 쪽이자 호스트의 vmnet 인터페이스 IP인 경우가 많음). 환경에 따라 192.168.137.1 등으로 보이기도 하니, 핑·traceroute로 한 번씩 확인하는 것이 안전합니다. LAN·mixed-port 글에서와 같이, 호스트가 VMnet 쪽에서 들어오는 인바운드 프록시 연결을 받으려면 OS 방화벽이 해당 포트를 허용하는지 점검합니다.
기억: 게스트의 127.0.0.1:7890은 게스트 자기 자신입니다. 호스트 Clash는 VMnet에서 보이는 호스트 IP와 Allow LAN이 맞는 주소·포트를 써야 합니다.
2Clash: Allow LAN·리스닝 주소·mixed-port / SOCKS
Clash·Clash Verge Rev·Mihomo 계열에서 Allow LAN을 켜지 않으면 127.0.0.1에만 바인딩되어 VM에서 오는 연결이 connection refused로 떨어질 수 있습니다. mixed-port 하나로 HTTP·SOCKS5를 같이 쓰는지, port·socks-port로 나눴는지 설정 화면과 YAML을 맞춥니다. SOCKS5는 socks5://호스트IP:포트, HTTP는 http://호스트IP:포트 형식으로 게스트에 넣습니다. 노드·DNS·FakeIP는 호스트 Clash 프로필이 이미 호스트 브라우저에 맞다면, 게스트는 터널만 쓰면 됩니다. 다만 게스트 DNS가 공인 DNS로만 나가면 FakeIP·분할 규칙과 어긋난 이름 해석이 섞일 수 있으니, DNS만 의심될 때는 Meta DNS 유출 방지 글의 점검과 비교하세요.
3게스트(Windows) 시스템·환경 프록시
Windows 10/11 게스트는 설정 > 네트워크 > 프록시에서 수동 프록시로 호스트의 VMnet IP와 Clash 포트를 넣을 수 있습니다. winget·PowerShell·배치 스크립트는 HTTP_PROXY·HTTPS_PROXY·ALL_PROXY을 읽는 경우가 많으니, 로그온 셸 프로파일이나 시스템 환경 변수에 같은 값을 반복해 두면 재현이 쉬워집니다. 회사 이미지 VM이면 그룹 정책이 사용자 프록시를 막는 경우가 있으니, IT 승인 하에 예외를 잡는 것이 안전합니다.
4리눅스 게스트: 환경 변수·APT·쉘
~/.bashrc 등에 아래와 같이 실제 HOST_VMNET_IP·PORT를 넣습니다.
export http_proxy="http://HOST_VMNET_IP:PORT"
export https_proxy="http://HOST_VMNET_IP:PORT"
export ALL_PROXY="socks5://HOST_VMNET_IP:PORT"
export no_proxy="localhost,127.0.0.1,::1"
curl -I --proxy http://HOST:PORT https://www.example.com로 터널만 먼저 검증합니다. APT는 /etc/apt/apt.conf.d/에 Acquire::http::Proxy를 쓰는 방식과 환경 변수 방식이 섞일 수 있으니, 중복·충돌이 없도록 한 가지 정책으로 정리하는 편이 트러블슈팅에 유리합니다.
macOS 호스트: VMware Fusion·방화벽
VMware Fusion을 쓰면 가상 스위치 이름·세그먼트는 네트워크 편집기에 있습니다. 호스트 macOS 방화벽이 Clash 앱의 수신을 막지 않는지, 앱 투명 동의가 한 번 떴는지 점검하세요. Clash Verge Rev 키체인·시스템 프록시 글은 호스트 측 동작에 초점이 있으나, LAN 수신과 방화벽 예외를 함께 보면 VM에서 오는 HTTP·SOCKS 연결도 같은 축에서 정리됩니다.
Windows 호스트: VMnet8·WSL2와의 거리
Workstation Player·Pro는 VMnet1(호스트 전용), VMnet8(NAT) 등 가상 어댑터가 별도로 뜹니다. WSL2는 /etc/resolv.conf의 nameserver로 호스트를 잡는 패턴이 흔하고, VMware 게스트는 게이트웨이 기준으로 IP를 잡는 편이 맞으므로, 두 문서의 IP 확인 요령을 섞지 않는 것이 중요합니다. Windows Defender 방화벽에 인바운드 규칙이 Clash 실행 파일·포트에 열려 있는지, Windows Clash 설치 가이드에 나온 초기 포트 번호와도 맞춰 보시면 좋습니다.
대안: 호스트 TUN으로 게스트를 한 번에 끌어오기
VMnet마다 손으로 프록시를 넣기 번거롭다면, 호스트에서 TUN 모드로 캡처 범위를 넓히는 구성을 검토할 수 있습니다. 드라이버·권한·정책 요구가 있고, VMware 세그먼트가 이중 NAT로 꼬이는지 등 부작용을 로그로 확인해야 합니다. Clash Verge Rev TUN 가이드의 전제를 읽고, 회사망에서는 승인 후 시도하세요.
(고급) NAT 포트 포워딩이 필요한 경우
대부분의 시나리오는 게스트에서 인터넷으로의 아웃바운드이므로, 인바운드 포트 포워딩이 꼭 필요한 것은 아닙니다. 호스트의 로컬 서비스를 게스트에 특정 포트로 노출하거나 리버스 테스트를 할 때만 VMware NAT의 포트 포워딩·Windows netsh portproxy를 검토합니다. “가상 머신이 인터넷이 안 됨”과 혼동되기 쉬우니, 목적이 아웃바운드인지 먼저 정리해 두면 낭비를 줄일 수 있습니다.
검증 체크리스트
- 게스트의 기본 게이트웨이·IP 대역을 메모한다.
- VMnet 쪽 호스트 IP가 Clash에 붙일 주소와 같은 서브넷인지 본다.
- Allow LAN과 실제 리스닝 포트(mixed·SOCKS 구분)를 맞춘다.
curl·게스트 브라우저로 프록시 경로만 단독 시험한다.- 여전히 이상이면 방화벽·DNS·회사 정책을 역순으로 의심한다.
준수: 소속 기관·서비스 약관·현지 법을 지키세요. 회사 PC·VM은 IT 정책 승인 후 프록시·방화벽을 변경하세요.
문서·다운로드
용어·YAML 키를 한곳에 모으려면 Clash 문서·설정 허브를 북마크해 두면, VMware와 호스트 Clash를 엇갈리지 않고 유지하기 쉽습니다.
맺음말
VMware NAT 가상 머신에서만 인터넷이 끊기는 흔한 이유는, 게스트 OS가 호스트 Clash의 127.0.0.1 리스너에 자동으로 붙을 수 없고, VMnet 게이트웨이와는 다른 IP 공간에 있기 때문입니다. Allow LAN을 켜 호스트 쪽 HTTP·SOCKS 포트를 VMnet에 열고, 게스트 시스템 프록시나 환경 변수에 동일한 호스트 IP·포트를 심으면 동일한 절차로 재현할 수 있습니다. 브리지로 바꾸면 IP 잡는 방식이 달라질 수 있으나, 공유기 할당·보안 정책을 함께 봐야 합니다. 다른 도구에 비해 정책 로그·규칙 이름이 읽기 쉬운 Clash 계열을 한 벌로 정해 두면, 호스트·VM을 오갈 때 점검 비용이 줄어듭니다.