1 기본 게이트웨이와 시스템 프록시, 왜 헷갈리나
기본 게이트웨이는 IP 패킷이 «로컬 망 밖으로 나갈 때」 거치는 다음 홉 라우터입니다. 집 공유기에 붙어 있으면 보통 공유기 내부 주소가 게이트웨이이고, Hyper-V NAT 안에 있으면 Microsoft가 만든 가상 NAT 장치 쪽 주소가 게이트웨이로 잡히는 경우가 많습니다. 반면 시스템 프록시는 운영체제나 런타임이 HTTP·HTTPS 요청을 중간 서버로 우회하도록 알려 주는 별도의 설정입니다. 프록시를 켰다고 해서 게이트웨이가 자동으로 Clash가 되지는 않으며, 게이트웨이를 호스트 물리 주소로 임의 변경한다고 해서 모든 앱이 Clash를 타는 것도 아닙니다.
실무에서 가장 재현성이 좋은 첫 단계는 «게스트 OS 안에서 명시적으로 프록시 주소를 호스트가 수신 중인 IP와 포트로 지정하는 것»입니다. Windows 게스트라면 설정 → 네트워크 및 인터넷 → 프록시에서 수동 프록시를 넣거나, 회사 정책이 허용하면 그룹 정책·레지스트리로 맞춥니다. 이때 필요한 IP는 NAT이냐 브리지냐에 따라 달라지므로 다음 절부터 스위치 종류를 먼저 구분하세요.
호스트 쪽 클라이언트 설치가 아직이라면 Windows 설치 가이드로 mixed·시스템 프록시 동작을 맞춘 뒤 이 글을 적용하는 편이 빠릅니다.
2 Hyper-V: NAT(기본 스위치)와 외부 스위치의 차이
기본 스위치(Default Switch)나 사용자가 만든 내부+NAT 구성은 게스트를 호스트 뒤에 숨긴 사설 대역으로 올립니다. 이 경우 게스트가 ipconfig로 본 기본 게이트웨이는 «인터넷 공유·가상 NAT» 쪽 인터페이스에 해당하는 경우가 많고, 그 주소가 곧 호스트가 그 가상 네트워크에서 듣는 쪽과 맞물립니다. 그래서 Allow LAN을 켠 Clash가 0.0.0.0 또는 해당 인터페이스에서 mixed·HTTP 포트를 열고 있으면, 게이트웨이 IP에 프록시 포트를 붙여 접속하는 패턴이 자주 통합니다.
외부 스위치는 물리 NIC와 게스트를 같은 L2 세그먼트에 올리는 형태에 가깝습니다. 이때 게스트의 기본 게이트웨이는 대개 집 공유기이고, 호스트 PC는 «같은 망의 또 다른 장치»입니다. 따라서 프록시 주소로는 호스트의 LAN IP(예: 192.168.x.y)를 써야 하며, 게이트웨이를 호스트로 바꾸는 식의 접근은 상위 라우터·DHCP와 충돌하기 쉽습니다.
3 호스트에서 Clash(Mihomo) 준비: Allow LAN과 방화벽
게스트가 호스트의 IP로 프록시 포트에 붙으려면, Clash가 루프백(127.0.0.1)만 듣고 있으면 실패합니다. GUI에서 Allow LAN을 켜거나, 구성에서 mixed·HTTP 수신 주소가 LAN 인터페이스를 포함하도록 맞춥니다. 포트 번호(예: 7890)는 메모해 두었다가 게스트와 동일하게 사용합니다.
Windows Defender 방화벽이 해당 TCP 포트의 인바운드를 막으면 증상은 «타임아웃» 한 가지로만 보입니다. 전용 네트워크 프로필과 인바운드 규칙을 정리하는 방법은 Windows 11 방화벽·Clash 글과 흐름이 같습니다. 호스트에서 TUN 모드만 켜 두고 시스템 프록시는 끈 상태라면, 게스트는 «호스트의 프록시 포트」를 기준으로 검증하는 편이 디버깅에 유리합니다. TUN 전반은 TUN 모드 가이드를 참고하세요.
4 게스트에서 호스트 쪽 IP 확인하기
Windows 게스트에서는 관리자 권한이 필요 없는 범위에서 ipconfig /all로 IPv4 주소·기본 게이트웨이·DNS를 먼저 봅니다. NAT 구성이라면 게이트웨이 주소를 메모한 뒤, 호스트에서 Clash mixed 포트로 Test-NetConnection(PowerShell) 또는 브라우저 없이 curl이 있다면 curl -x http://게이트웨이:7890 -I https://example.com 형태로 응답을 확인합니다.
외부 스위치를 쓰는 경우 게스트와 호스트가 같은 대역인지 확인하고, 호스트의 ipconfig에서 해당 vEthernet이 아닌 «실제 사용 중인 LAN 어댑터」의 IPv4를 프록시 서버 주소로 씁니다. VPN이나 Wi-Fi 이동 뒤에는 숫자가 바뀌므로, 장시간 고정이 필요하면 DHCP 예약·호스트 고정 IP를 검토합니다.
Linux 게스트라면 ip route show default로 게이트웨이를 보고, WSL2 Ubuntu 가이드와 비슷하게 http_proxy에 호스트 IP를 넣되, Hyper-V에서는 WSL의 미러 네트워킹 이슈 대신 «스위치 종류」를 우선 확인합니다.
5 방법 1: Windows 게스트에서 시스템 프록시만으로 가져가기
Edge·일부 스토어 앱·WinHTTP를 쓰는 도구는 시스템 프록시를 따르는 경우가 많습니다. 설정 → 네트워크 및 인터넷 → 프록시에서 수동 프록시를 켜고, 앞에서 확인한 호스트 후보 IP와 mixed·HTTP 포트를 넣습니다. 프록시 IP를 127.0.0.1로 두면 게스트 입장에서는 자기 자신을 가리키므로 실패합니다—반드시 호스트 방향 주소를 넣어야 합니다.
Microsoft Store·UWP 앱만 예외라면 호스트가 아니라 게스트 안의 Loopback 이슈일 수 있습니다. 이 경우 UWP·Loopback 문서의 도구를 게스트 OS에 맞게 적용해 볼 수 있습니다. 반면 완전히 프록시를 모르는 터미널 도구는 환경 변수나 도구별 설정이 필요합니다.
프록시만으로 부족한 경우
ICMP ping, 일부 게임 프로토콜, 임의의 UDP 세션은 HTTP 프록시 체인만으로는 그대로 나가지 않습니다. 이때는 호스트에서 TUN·별도 브리지·게스트 전용 VPN 등 다른 층을 검토해야 하며, «시스템 프록시를 켰는데도 안 된다»를 곧바로 구독 불량으로 단정하지 않는 것이 좋습니다.
6 방법 2: 기본 게이트웨이를 호스트로 바꾸는 시도에 대해
검색을 하다 보면 «가상 머신의 기본 게이트웨이를 호스트 IP로 설정한다»는 식의 글을 보기도 합니다. 그러나 외부 스위치 + 집 공유기 DHCP 환경에서 게스트 게이트웨이를 호스트로만 바꾸면, 게스트는 공유기가 아닌 호스트를 통해 나가려 하게 되는데 호스트가 IP 포워딩·NAT을 완전히 제공하지 않으면 인터넷 전체가 끊깁니다. Clash는 응용 계층 프록시·TUN 등 역할이 있지만, 사용자가 기대하는 «공유기를 대체하는 순수 L3 게이트웨이»와 항상 동일하지는 않습니다.
NAT 스위치에서는 이미 가상 게이트웨이가 존재합니다. 여기서 사용자가 할 일은 대개 «그 게이트웨이(혹은 같은 망의 호스트 주소)의 특정 TCP 포트로 HTTP 프록시를 보낸다»이지, DHCP가 준 게이트웨이를 임의로 다른 사설 주소로 덮어쓰는 것이 아닙니다. 정말로 게스트 전체 트래픽을 호스트 한 대에 모으려면, Synology NAS나 라우터 급에서 다루는 것처럼 라우팅·마스커레이드·DNS까지 포함한 설계가 필요합니다. 입문 단계에서는 시스템 프록시 + 필요한 터미널 환경 변수가 비용 대비 효과가 가장 좋습니다.
http_proxy·apt Acquire::http::Proxy를 명시하세요. 라우팅 표를 건드리기 전에 항상 스냅샷을 만듭니다.
7 Linux 게스트: 셸 환경 변수와 apt
Debian·Ubuntu 계열이라면 /etc/environment나 ~/.bashrc에 http_proxy·https_proxy를 넣고, sudo로 돌아가는 apt는 /etc/apt/apt.conf.d/ 아래에 Acquire::http::Proxy를 별도로 두는 방식이 안정적입니다. 호스트 IP 자리에는 NAT라면 가상 게이트웨이, 외부 스위치라면 호스트 LAN IP를 넣습니다.
export HOST_GW=$(ip route | awk '/default/ { print $3; exit }')
export http_proxy="http://${HOST_GW}:7890"
export https_proxy="http://${HOST_GW}:7890"
위 스니펫은 «기본 게이트웨이 = 호스트 쪽 후보」가 맞을 때 빠르게 검증할 때 유용합니다. 맞지 않는 스위치 구성이라면 HOST_GW 대신 ip -4 addr로 같은 망의 호스트 주소를 직접 박아 넣어야 합니다. DNS 이상 징후가 있으면 DNS·Fake-IP 글과 Clash DNS 설정을 함께 보세요.
8 DNS와 «절반만 되는」 트래픽
프록시는 살아 있는데 특정 사이트만 깨진다면, 이름 해석이 게스트 로컬 DNS로만 나가고 Clash의 fake-ip·도메인 규칙과 어긋나는 경우를 의심합니다. 호스트 Clash에서 DNS 모드를 정리한 뒤, 게스트가 어떤 DNS 서버를 쓰는지 ipconfig /all 또는 resolvectl status로 확인하세요. 브라우저만 되고 나머지는 실패한다면 프록시 우회 대상이 아닌 경로로 나가는지 살펴봐야 합니다.
9 트러블슈팅 체크리스트
- 호스트 Clash 로그에 게스트 IP에서 온 요청이 보이는가? 안 보이면 Allow LAN·바인딩·방화벽부터.
- 게스트에서 프록시 IP로
ping이 막혀 있어도 TCP 포트가 열려 있는지는 별개—포트 프로브로 확인. - NAT와 외부 스위치를 바꿨다면 이전에 쓰던 «게이트웨이=프록시 주소» 공식을 그대로 가져오지 말 것.
- 호스트가 노트북이라 Wi-Fi만 켠 채 절전에 들어가면 가상 스위치 상태가 흔들릴 수 있음.
- 회사망·다른 보안 에이전트가 로컬 프록시 포트를 정책 차단하는지 확인.
10 정리
Hyper-V 게스트가 Windows 호스트의 Clash·Mihomo를 안정적으로 쓰려면, 먼저 스위치가 NAT인지 외부(브리지)인지에 따라 «프록시 서버로 넣을 IP»가 달라진다는 점을 몸에 익히는 것이 중요합니다. 대부분의 데스크톱 시나리오에서는 시스템 프록시와 명시적 HTTP 프록시 주소가 1차 해결책이고, 기본 게이트웨이를 임의로 호스트로 바꾸는 방식은 상위 라우터·포워딩 설계 없이는 위험합니다. 호스트에서는 Allow LAN과 방화벽 인바운드를 맞추고, 게스트에서는 127.0.0.1 착각만 피해도 성공률이 크게 오릅니다. 장기적으로는 GUI에서 로그·규칙·DNS를 한 화면에서 다루기 쉬운 클라이언트를 쓰면 가상 머신·물리 호스트를 오가며 디버깅할 때도 부담이 줄어듭니다.
설치 패키지는 신뢰할 수 있는 배포 페이지를 우선하는 것이 좋습니다. 동일한 구성을 빠르게 맞추려면 아래 링크에서 Windows용 클라이언트를 받아 mixed 포트와 LAN 수신을 확인해 보세요.
