튜토리얼 2026-04-25 · 약 17분

VMware·Parallels 가상머신이 호스트 Clash를 쓰게 하기: 브리지·NAT·공유와 프록시

WindowsmacOS에 이미 Clash를 올려 두었다면, VMware Workstation / Fusion이나 Parallels Desktop으로 돌리는 완전한 Guest OS에서도 apt·winget·curl·docker pull을 같은 출구로 보내고 싶을 때가 많습니다. WSL2와 달리 가상머신은 별도 커널·별도 IP 스택을 가지므로, 호스트 TUN이 자동으로 게스트까지 덮이지는 않습니다. 이 글은 가상 네트워크 모드(브리지, NAT, 호스트 전용, 공유)마다 게스트가 실제로 도달하는 호스트 주소가 어떻게 달라지는지 먼저 잡고, HTTP(S) 프록시 또는 투명 게이트로 Clash에 붙이는 실무 순서를 정리합니다. allow-lan·mixed-port·방화벽·DNS까지 한 흐름으로 묶습니다.

WSL2가 아닐 때의 전제: TUN은 호스트에만

호스트에서 Clash TUN이 켜져 있으면, 같은 OS 안의 앱·터미널 트래픽을 커널 가까이에서 잡을 수 있습니다. 그러나 가상머신 안의 Linux·Windows별도의 가상 NIC 뒤에 있어 Clash TUN 가상 어댑터/필터 스택 밖에 있습니다. VM에서 “그냥 다 된다”고 기대하면 안 되고, (1) 게스트가 프록시 주소·포트에 TCP로 붙는 방식이냐, (2) VM 전체의 기본 게이트를 호스트(또는 사내 라우터) 쪽에 두고 거기서 Clash 쪽으로 넘기는 방식이냐로 설계를 나눕니다. 전자가 단순하고 재현성이 좋고, 랩·CI 이미지 받기·브라우저·패키지 매니저에 특히 잘 맞습니다.

흔한 오해는 “호스트 127.0.0.1에 열었으니 게스트에서도 localhost로 된다”는 것입니다. 게스트 127.0.0.1자기 루프백입니다. 호스트 루프백이 아닙니다. VM에서는 반드시 LAN에 보이는 호스트 쪽 IP를 써야 합니다(모드에 따라 192.168.x.1 같은 VMware 가상 어댑터 주소이거나, 브리지일 때 공유기·사무실과 같은 망의 실제 LAN IP입니다).

브리지·NAT·호스트 전용·공유: 누가 게이트웨이인가

모드에 따라 게스트의 기본 게이트웨이호스트로 가는 래핑이 달라집니다. 프록시를 넣을 “대상 IP”는 같은 L2·L3 경로에 있는 호스트(또는 가상 NAT 장비)의 주소여야 합니다.

모드(대표) 게스트 입장 호스트 Clash에 쓰기 쉬운 IP 힌트
브리지(Bridged) LAN의 한 PC와 동일. DHCP로 물리 스위치·공유기와 직접. 호스트의 이더넷·Wi‑Fi LAN IP(예: 192.168.0.xx). 게스트·호스트가 동일 서브넷.
NAT(공유, VMware 기본) 가상 NAT 뒤; 게이트는 보통 192.168.x.1 같은 VMnet 어댑터. VMnet에 붙은 호스트 쪽 가상 NIC IP(게스트에 ping 되는 “호스트 IP”). 127.0.0.1는 안 됨.
호스트 전용(Host-only) 인터넷은 없을 수 있으나, 호스트·VM 상호는 전용망. VMnet1 등 host-only 어댑터 IP. 외망이 필요하면 NAT/브리지로 바꾸거나 이중 NIC.
Parallels 공유 맥과 게스트가 NAT 유사; 게스트는 호스트 “공유” 게이트 사용. Parallels가 안내하는 기본 게이트(호스트 측)를 확인. 보통 10.211.x.1 / 10.37.x.1 류(환경마다 다름).

핵심은 한 줄로 정리됩니다. “게스트 터미널에서 ping 되는, 호스트(또는 Parallels/VMware가 박아 준) 주소에 Clash mixed 포트를 열고 그 IP:포트를 HTTP_PROXY·시스템 프록시에 넣는다”입니다. 먼저 VM 안에서 ip route(Linux)나 ipconfig·route print(Windows)로 default gateway자기 IP·대역을 확인하세요. 그다음 같은 대역의 “호스트 쪽” 주소에 서비스가 떠 있는지 확인하는 순서로 좁힙니다.

빠른 점검

게스트 셸에서 ip neigh / arp -a로 이웃을 보고, VM 문서·가상 스위치에 찍힌 호스트 측 IP와 대조하세요. 의심나면 브리지로 잠시 바꾼 뒤 같은 서브넷의 맥/윈도 LAN IP에 프록시를 여는 쪽이 디버깅이 쉽습니다.

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

가상머신에서 SOCKS/HTTP로 쓰려면 호스트 Clash에 mixed-port가 있어야 합니다(클라이언트마다 portsocks-port를 쪼갠 구성이면, 게스트엔 둘 중 하나 + 프로토콜 일치를 쓰세요. 보통 mixed 한 군데에 맞추는 편이 낫습니다). 외부(게스트)에서 붙을 수 있게 allow-lan: true적절한 bind-address가 필요합니다. 자세한 YAML 키 이름은 《Clash LAN 프록시·allow-lan》에 맞춰 주세요. 요지는 127.0.0.1 전용으로만 열려 있으면 VM에서 연결이 거절된다는 점입니다.

Windows 방화벽은 Clash(또는 쉘) 인바운드 해당 TCP 포트개인/도메인 프로필에 허용해야 VM 경로로 들어온 SYN이 잘리지 않습니다. macOS도 방화벽·“들어오는 연결” 경고를 확인하세요. 클라우드/보안 SW가 localhost만 허용하는 정책이면 예외에 넣어야 합니다.

보안

allow-lan을 켜면 같은 L2에 붙은 다른 기기에서도 올 수 있습니다. 신뢰하는 LAN에서만 쓰고, 공용 Wi‑Fi에서는 끄거나 OS 방화벽으로 VMnet·브리지 대역만 허용하세요. 외망에 포트를 그대로 노출하지 마세요(라우터 포트포워딩·DMZ는 이 글 범위 밖 위험 요소입니다).

게스트 쪽: HTTP(S) 프록시(권장 경로)

Linux 게스트

일회성: export https_proxy=http://<호스트_LAN_IP>:<mixed_port>http_proxy=를 동시에(HTTPS URL도 https_proxy에 넣는 관행이 흔합니다). apt·dnf는 별도 설정 파일을 보기도 합니다. 《터미널·Git·npm 프록시》의 환경 변수 절을 그대로 응용하되, IP만 호스트 쪽으로 바꾸면 됩니다.

Windows 게스트

설정 → 네트워크·인터넷 → 프록시에서 수동 프록시<호스트_LAN_IP>:<port>를 넣습니다. “로컬 주소에 프록시 사용 안 함” 체크로 사내 *.local 직행을 유지하는 경우가 많습니다. winget·Invoke-WebRequest는 WinHTTP 스택이 따로 있어 netsh winhttp가 필요한 경우가 있습니다—이때는 《Clash for Windows》로 호스트·게스트 둘 다 “시스템과 동기화” 패턴에 익숙해지는 것이 도움됩니다(게스트 전용 Clash는 또 다른 토론이므로, 여기서는 호스트 출구만 쓰는 가정에 집중합니다).

최소 단계(요약)

  1. 호스트: Clash 가동 + mixed + allow-lan + 올바른 bind.
  2. VM 네트워크 모드 확정(브리지 권장이면 먼저 브리지로 검증).
  3. 게스트에서 ping 가능한 호스트 IP를 확인.
  4. 해당 IP:포트로 프록시 설정 후 curl -I https://www.google.com 등으로 확인.
  5. 안 되면 방화벽·IP 대역·클라이언트가 실제로 프록시를 쓰는지를 역순으로 추적.

TUN·전역 “게이트”로 가져가기는 언제인가

게스트 OS 전체를 TUN으로 강제하려면, 보통 (a) 게스트 안에 별도 Clash/VPN을 설치하거나, (b) 게스트의 기본 게이트호스트에서 Clash TUN/포워딩으로 이어 붙이는(라우터급) 구성이 필요합니다. (b)는 IP 포워딩·iptables/nft·Windows 공유/ICS·VMnet 라우팅 지식이 필요해 가정/소규모 랩 외엔 HTTP 프록시 + 필요 시 도구별 no_proxy가 훨씬 낫습니다. 호스트 TUN이 VM 트래픽을 자동으로 먹지는 않는다—이 점이 WSL2 《미러·포트포워딩》과 주제가 갈리는 이유입니다.

VMware(Workstation / Fusion) 실무 팁

가상 네트워크 편집기로 VMnet0(브리지), VMnet8(NAT) 등 대역이 어디인지 먼저 봅니다. NAT이면 “호스트” 항목 IP는 VMware 문서/화면에 나온 VMnet8 게이트와 짝이 맞는지 확인하세요. 브리지이면 Wi‑Fi 절전·엔터프라이즈 802.1x는 브리지가 불안정할 수 있으니, 유선이나 호환되는 어댑터를 고릅니다. 여러 VM이 동시에 쓰면 같은 mixed 포트를 공유해도 되지만, 동시에 붙는 세션·대역이 커질 수 있으니 노드·클라이언트 Rule로 무거운 다운로드와 인터랙티브 셸을 나누는 편이 좋습니다.

Parallels Desktop(맥) 실무 팁

공유 네트워크는 NAT 유사; 브리지는 맥과 동일한 LAN에 둡니다. Wi‑Fi 브리지는 macOS·하드웨어 조합에 따라 제한이 있을 수 있어, 안 되면 공유 네트워크 + 호스트 측 도달 IP로 확실히 가져가는 편이 빠릅니다. 호스트·게스트 양쪽에서 System Settings / 네트워크에 보이는 IP를 적어 두고, 게스트 traceroute 1 hop이 말하는 첫 홉이 누구인지를 보면 혼동이 줄어듭니다. Parallels 도구(게스트 도구) 설치는 공용 폴더·해상도 외에도 네트워크 진단에 유용합니다(공식 문서의 네트워크 절을 함께 읽는 것을 권합니다).

DNS: 게스트가 resolver만 바꾸면 안 되는 이유

Clash fake-ip호스트의 Clash에 붙은 스택이 이해하는 방식이고, 게스트가 8.8.8.8로 직접 물으면 DNS만 우회되어 “브라우저는 열리는데 API가 깨진다” 같은 불일치가 납니다. VM 안에서는 (1) 프록시를 경유하는 쪽에 HTTP 클라이언트를 맞추고, (2) 필요 시 게스트 systemd-resolved / Windows DNS를 기본 네트워크가 쓰는 쪽Clash 쪽 fake-ip 중 무엇을 쓰는지 의도를 하나로 정하세요. 이상이면 《DNS·fake-ip 점검》한 변수씩 접근이 안전합니다.

짧은 트러블슈팅

  • Connection refused: 호스트가 127.0.0.1에만 bind했거나, allow-lan이 꺼짐, 또는 Windows 방화벽 차단.
  • Timeout: 잘못된 “호스트” IP(게이트웨이와 혼동), VMnet 다른 대역, 게스트 기본 경로가 인터넷이 아닌 host-only에만 있음.
  • TLS / 인증서만 수상하면 프록시가 아니라 캡티브·회사 점검일 수 있으니, 우선 호스트 브라우저로 같은 AP를 점검.

체크리스트

  1. VM 네트워크 모드(브리지·NAT·공유)를 먼저 결정·기록.
  2. 게스트 ↔ 호스트 ping/ARP로 L3·L2 도달성 확인.
  3. Clash mixed + allow-lan과 방화벽 인바운드 허용.
  4. 게스트 HTTP(S)_PROXY 또는 Windows 수동 프록시로 통합.
  5. DNS·fake-ip와 충돌이 있으면 같은 스택(프록시 경로)에 맞춰 재점검.

호스트·게스트 둘 다 “규칙이 보이는” Clash로

가상머신은 문제를 한 겹 더 쌓는 환경입니다. 호스트 Clash 로그에 게스트 IP에서 붙는 세션이 잡히면, 남는 건 앱·DNS뿐이라 디버깅이 빨라집니다. Clash를 무료로 내려받고 차이를 경험해 보세요

VM에서도 동일한 출구

mixed-port·allow-lan·게스트 IP 대역을 맞추면 WSL2가 아닌 풀 VM에서도 안정적으로 패키지·이미지·브라우저를 Clash에 태울 수 있습니다.

Clash 다운로드