2026 Hyper-V·VMware 등 가상머신에서 Windows 호스트의 Clash를 태우려면: NAT·기본 게이트웨이·방화벽 순서별 설정

① 이 주제가 WSL2·스마트폰 Wi-Fi 프록시 글과 다른 이유

WSL2는 리눅스 셸에서 호스트 게이트웨이 IP를 잡아 Git·npm에 붙이는 경우가 많고, 폰 같은 외부 기기를 묶을 때도 “같은 Wi-Fi 세그먼트에서 보이는 호스트 측 IP” 관점입니다. 반면 Hyper-V의 기본(Default) 스위치는 보통 호스트 안에서 제공하는 가상 라우터·NAT 뒤에 게스트 사설 IP 대역(172.x 등)만 따로 씁니다. 따라서 “guest의 기본 경로(default route)는 이미 브라우저의 인터넷은 되도록 잡혀 있다”만으로는 호스트 안의 특정 포트로 오는 새 TCP 세션이 허용되지 않거나, 게스트 어댑터가 호스트 클라에서 열린 127.0.0.1을 전혀 가리키지 않는 같은 정합 깨짐이 남을 수 있습니다. 본문은 그 NAT 게이트웨이 경계에 초점을 둡니다.

② 증상을 두 축으로 나눠 판별하기

아래처럼 A/B 축으로 나누면 디버깅이 빠릅니다.

• 축 A — TCP 앱 프록시: 게스트에서 http://호스트IP:포트 형태로 HTTP 프록시·SOCKS를 지정했는데도 앱이 붙지 않는다. 이 경우 호스트 쪽 Clash가 어느 주소에 리슨하는지(127.0.0.1만인지, 0.0.0.0인지)·allow-lan·방화벽 인바운드를 의심합니다.
• 축 B — ICMP ping: ping 호스트IP만 실패한다. ICMP는 HTTP/SOCKS와 전혀 다른 프로토콜이며, Windows 방화벽이 ICMP를 막으면 프록시가 정상이어도 ping은 실패할 수 있습니다. “ping이 안 되니 프록시도 안 된다”로 한꺼번에 결론내리면 안 됩니다.

호스트에서 Clash Verge를 처음 맞출 때는 시스템 프록시와 TUN을 먼저 정리해 두는 것이, 이후 VM에서 붙을 포트 번호를 확정하는 데 도움이 됩니다.

③ 호스트에서 Clash가 “로컬만” 열고 있지 않은지 확인

게스트가 와야 할 대상은 호스트의 루프백(127.0.0.1)이 아니라, NAT 대역에서 보이는 호스트 측 IP입니다. 하지만 Clash 프로필이 mixed-port나 port를 127.0.0.1에만 바인드하면, 게스트에서 아무리 올바른 “호스트 LAN IP”를 쳐도 연결 거절이 납니다. 클라이언트 화면이나 YAML에서 listen address가 0.0.0.0 또는 “모든 인터페이스”에 가깝게 열려 있는지 확인하고, allow-lan(또는 동등 옵션)이 켜져 있는지 봅니다. 이는 기기가 LAN에서 호스트 프록시를 쓰는 시나리오와 같은 전제입니다.

포트 숫자는 배포본마다 다릅니다. 예로 7890·7891이 흔하지만, 본인 환경의 실제 값을 메모해 두고 이후 단계에서 그대로 씁니다.

④ 게스트와 호스트 간에 도달 가능한 호스트 IPv4 주소 잡기

Hyper-V Default Switch를 쓸 때 게스트에게는 게이트웨이(보통 해당 서브넷의 .1)가 있고, 그 반대쪽이 호스트 역할입니다. 게스트 운영체제가 Windows이면 설정 앱의 네트워크 상세 또는 명령 프롬프트/PowerShell에서 기본 라우터·자기 주소 대역을 확인합니다. 게스트가 Linux면 ip route show default와 ip -4 addr로 한 번에 같은 정보를 적을 수 있습니다.

중요한 점은, “기본 게이트웨이(인터넷으로 나가는 다음 홉)”과 “Clash에 붙을 대상 호스트 주소”가 문맥별로 이름이 헷갈릴 수 있다는 것입니다. NAT 안에서는 종종 게이트웨이가 가상 라우터 IP이고, Clash에는 그 주소보다 다른 인터페이스에 매핑된 호스트의 접속 가능 인터페이스 IP를 적어야 합니다. 따라서 게스트 안에서 다음을 시험합니다.

# Linux guest — find default gateway toward "outside" NAT
ip route | grep '^default'

# PowerShell guest — same intent
Get-NetRoute -DestinationPrefix '0.0.0.0/0'

그다음 Windows 호스트에서 모든 어댑터의 IPv4를 나열합니다.

# Host PowerShell — list IPv4 that guests might route to (example)
Get-NetIPAddress -AddressFamily IPv4 | Sort-Object InterfaceIndex |
  Select-Object IPAddress, InterfaceAlias

목록 중 가상 네트워크와 같은 서브넷에 있는 호스트 인터페이스를 골라, 게스트 브라우저나 터미널 테스트에 쓸 한 개의 호스트 주소 문자열로 고정합니다.

⑤ 게스트에서 호스트 포트까지 TCP가 열렸는지 먼저 검증

프록시를 앱 설정에 넣기 전에, 원시 TCP로 포트만 열려 있는지부터 확인하면 원인 분리가 쉽습니다. Windows 게스트라면 다음과 같은 점검을 참고합니다(포트 번호와 호스트 주소를 본인 값으로 바꿔야 합니다).

# Example only — substitute HOST_IP and YOUR_CLASH_MIXED_HTTP_PORT
Test-NetConnection -ComputerName HOST_IP -Port YOUR_CLASH_MIXED_HTTP_PORT

Linux 게스트는 busybox/OpenBSD 계열 nc나 telnet 대체 클라이언트, 혹은 curl으로 실제 CONNECT가 되는 호스트까지 시도해 보면 됩니다.

# Example curl to HTTP proxy tunnel test (adapt URL for your rules)
curl -v --proxy http://HOST_IP:PORT https://example.com/

여기서 TcpTestSucceeded가 false이거나 연결 거절이라면 문제는 게스트 라우팅보다 호스트 바인드·방화벽 쪽 가능성이 큽니다.

⑥ Windows Defender 방화벽: 프로세스·포트 단위 인바운드

호스트 방화벽이 Clash 실행 파일 프로세스 또는 TCP 해당 포트 인바운드를 막으면 게스트에서는 항상 비슷하게 “먹통”처럼 보입니다. 방법은 회사 보안 제한에 따라 다르지만 일반적인 흐름은 다음과 같습니다.

• 인바운드 규칙: “특정 지역 로컬” 대역(가상 어댑터가 속한 세그먼트)에서 오는 접속 허용
• 프로파일별: 사설망/도메인/공용에 따라 규칙이 달라질 수 있으므로 현재 활성 네트워크 프로파일 확인
• 제3자 백신·엔터프라이즈 에이전트가 별도 HIPS 방화벽을 겹치면 동일 증상이 반복될 수 있습니다

설정 검증 후에는 같은 Test-NetConnection을 게스트에서 다시 실행해 결과가 바뀌는지 봅니다.

⑦ 브리지 모드 게스트였다면: VMware·Hyper-V External 스위치

게스트 어댑터를 물리 LAN과 같은 브리지 모드로 두었다면 게스트 자체에 공유기급 라우터에서 줄 공인 또는 사설 IP 한 개가 직접 붙습니다. 이때 게스트 입장에서는 “프록시는 물리망 다른 PC의 호스트처럼 행동”해야 하므로, 기본 라우팅은 이미 라우터 쪽 게이트웨이 기준이 되고 Clash까지는 해당 LAN에서 보이는 별도 호스트 IP(혹은 이 경우 굳이 프록시를 안 태우고 라우팅 규칙만 쓸 수 있는지 포함) 검토 영역입니다. 사용자가 많이 헷갈리는 패턴 중 하나가 브리지이면 게이트웨이를 무조건 Windows 호스트 IP로 바꾼다는 접근입니다. 보통 브리지 게스트에서는 기본 라우팅은 라우터/게이트웨이 유지하고, 브라우저·패키지만 HTTP 프록시 또는 시스템 프록시로 호스트 클라 포트를 가리키는 편이 덜 깨집니다.

NAT 세그먼트인지 브리지 세그먼트인지에 따라 “어떤 문자열을 프록시에 넣는지”부터 달라지므로, 이 한 줄을 헷갈리지 않는 것이 본글의 목적 중 하나입니다.

⑧ VM 안에서 Clash 규칙과 DNS를 기대하기 전에 알아둘 점

게스트 브라우저가 호스트 클라까지 붙더라도, 앱이 여전히 DIRECT만 타거나 이름 해석이 어색하면 게스트 안의 시스템 프록시·앱별 프록시·fake-ip 환경이 엇갈린 경우입니다. 분류(규칙) 구조 설명 전체는 커스텀 규칙 글과 묶지만, 우선은 “L4 TCP가 호스트로 닿았느냐”부터 해결해야 합니다. TUN 미러싱 세계가 아닌 순수 게스트에서는 호스트 클라 안의 GEOIP 같은 규칙이 사용자가 기대한 것과 다르게 느껴질 수 있습니다. 회사 업무용이라면 WSL 개발 호스트 게이트웨이 패턴 문서와 병렬로 읽을 때 초점 차이만 정리하면 혼선이 줄어듭니다: WSL2·Git 네트워크 참고.

⑨ 정리: 순서만 지키면 “가상머신은 왜 우리 안에서만 이상하게 보이나”가 줄어듭니다

Hyper-V 같은 NAT 게스트가 같은 PC의 Windows Clash와 연동되는지 막히면, 순서대로 확인할 것은 (1) 호스트 Clash 바인 주소와 allow-lan, (2) 게스트와 서브넷이 맞닿는 호스트 IPv4 문자열 하나로 고정, (3) TCP 포트 테스트로 실제 회로 증명, (4) 방화벽 인바운드, 그리고 선택적으로 ping은 별 규격임을 기억하는 것입니다. VMware Workstation Player 등 다른 하이퍼바이저도 라우팅 개념은 같고, 이름만 다른 경우가 많습니다.

클라이언트를 묶어두면 이후 회사 또는 개인 규모로 “게스트 테스트용 OS”까지 규칙과 같이 재현 가능한 환경이 됩니다. 설치 패키지는 릴리스 노트만 쫓기보다 이 사이트 튜토리얼 입문 페이지와 다운로드 페이지를 함께 보시면 채널·언어별로 덜 헷갈립니다. 전통 VPN과 규칙형 프록시의 차이는 Clash와 VPN 차이 비교 글에서 참고하면, 어느 쪽 경로를 우선할지도 정리하기 쉽습니다. → Clash를 무료로 받아 같은 PC 호스트 규칙을 먼저 안정시킨 다음, NAT 가상머신에서 테스트해 보세요.