1 macOS 시스템 프록시가 VM 트래픽을 자동으로 타지 않는 이유
Clash Verge Rev에서 시스템 프록시를 켜면 Safari·Chrome처럼 macOS 네트워크 스택을 따르는 앱은 루프백의 mixed-port 쪽으로 잘 붙습니다. 그러나 Parallels 게스트 OS는 별도의 TCP/IP 스택과 가상 NIC을 가지며, 기본적으로 «Mac이 설정한 HTTP 프록시」를 물려받지 않습니다. 공유 네트워크(Shared Network)는 게스트가 인터넷으로 나갈 때 호스트의 물리 인터페이스 쪽으로 NAT되게 만들 뿐, 그 패킷이 자동으로 Mihomo의 TUN 계층이나 시스템 프록시 설정을 거친다고 가정하면 안 됩니다. 그래서 실무에서는 가장 예측 가능한 방법인 «호스트에서 SOCKS 또는 HTTP 프록시 포트를 LAN에 열어 두고, 게스트에서 그 주소를 수동으로 지정»하는 패턴이 널리 쓰입니다.
VMware나 Hyper-V처럼 다른 하이퍼바이저를 쓰던 분이라도, Mac 호스트라는 점에서 게이트웨이 IP와 방화벽 UX가 다릅니다. Windows 호스트 위 VM 글과 개념은 겹치지만 경로 이름이 다르므로, 본문은 Parallels Desktop과 macOS에 맞춰 서술합니다. Windows 호스트 기준 NAT·브리지 비교는 VMware Workstation·Clash 글을 참고하면 좋습니다.
3 호스트 Clash Verge Rev에서 LAN 연결 허용
기본값으로 프록시 포트가 127.0.0.1에만 바인딩되어 있으면, 게스트에서 아무리 올바른 IP를 쳐도 연결이 거절됩니다. Clash Verge Rev·Mihomo 계열에서는 설정에 «Allow LAN»·«LAN에 허용»·비슷한 이름의 스위치가 있으며, 이를 켜면 0.0.0.0 또는 모든 인터페이스에서 mixed·외부 컨트롤러 포트를 받게 됩니다. 메뉴 막대 아이콘이나 설정 창에서 네트워크 섹션을 찾아 켠 뒤, 앱을 한 번 재시작해야 반영되는 빌드도 있으니 로그를 확인하세요.
또한 외부 컨트롤러나 API 포트를 열어 두었다면, 그 포트 역시 LAN에서 접근 가능해질 수 있으므로 불필요하면 끄거나 강한 토큰을 설정합니다. Verge Rev는 GUI로 대부분 조절되지만, 고급 사용자는 생성된 config.yaml에서 allow-lan·bind-address 필드가 기대와 일치하는지 교차 확인할 수 있습니다. 호스트 쪽 기본 설치 절차는 macOS 설치 글과 같은 흐름입니다.
4 mixed 포트와 SOCKS 포트를 VM에 맞추기
Mihomo 기반 프로필에서는 mixed-port 하나로 HTTP와 SOCKS가 같이 열리는 경우가 많습니다. 앱 UI에 표시된 숫자(예: 7890)를 메모해 두고, Windows의 수동 프록시 설정에는 HTTP와 HTTPS에 동일 호스트·포트를 넣거나, 애플리케이션이 SOCKS5만 지원하면 SOCKS 전용 포트가 따로 있는지 확인합니다. 구성에 따라 SOCKS는 7891 등으로 분리되어 있을 수 있으니, Connections 화면이나 설정 JSON을 기준으로 하지 «예전 스크린샷의 7890」에 의존하지 마세요.
게스트에서 먼저 TCP 연결만 검증하고 싶다면 PowerShell에서 Test-NetConnection으로 호스트 IP와 포트를 찍어 보거나, Linux에서는 nc -vz 호스트IP 포트로 SYN 이후 응답이 오는지 확인합니다. 여기서부터 막히면 아직 LAN 허용이 꺼져 있거나 방화벽이 가로막고 있는 경우가 대부분입니다.
Test-NetConnection -ComputerName 10.211.55.1 -Port 78905 macOS 방화벽과 인바운드 차단 해제
macOS 시스템 설정 → 네트워크 → 방화벽(또는 이전 OS의 보안 패널)에서 방화벽이 켜져 있으면, 새로 바이너리가 갱신될 때마다 «수신 연결 허용」 확인이 뜨기도 하고, 조용히 차단되기도 합니다. Clash Verge Rev에 대해 들어오는 연결을 허용했는지 확인하세요. 또한 서드파티 EDR·필터 드라이버가 loopback이 아닌 인터페이스로 들어오는 프록시 핸드셰이크를 막는 경우가 있어, 그럴 때는 해당 보안 제품의 예외 목록에 Verge Rev 실행 파일과 가상화 스택을 넣어야 합니다.
방화벽을 잠시 꺼서 증상이 사라지는지로 원인을 좁힌 뒤, 가능하면 최소 권한으로 다시 켜는 것이 좋습니다. «방화벽을 완전히 끄고 영구 운용»은 다른 LAN 위협에도 노출되므로 권장하지 않습니다.
6 Windows 게스트에서 시스템 프록시·환경 변수
Windows 11이라면 설정 → 네트워크 및 인터넷 → 프록시에서 수동 프록시를 켜고, 주소에 앞서 확인한 호스트 게이트웨이 IP, 포트에 mixed 포트를 넣습니다. Microsoft Store 앱·일부 UWP는 시스템 프록시를 다르게 타기도 하니, 그런 앱만 실패하면 Windows UWP·루프백 주제를 함께 보는 것이 좋습니다. 개발 도구는 각자의 프록시 설정이 있으므로, VS Code·Git 등은 앱 내부에 동일한 http://게이트웨이:포트를 넣어야 합니다.
PowerShell·cmd에서만 쓸 HTTP_PROXY·HTTPS_PROXY 환경 변수를 사용자 프로필에 넣는 방법도 흔합니다. 이 경우 시스템 UI의 프록시와 이중으로 걸리지 않게, 어느 한쪽만 쓰는지 정리하세요. 회사 GPO가 프록시를 덮어쓰면 사용자 설정이 무시되므로, 그런 환경에서는 IT 정책을 확인해야 합니다.
7 Linux 게스트: 환경 변수와 apt
Debian·Ubuntu 계열 게스트에서는 /etc/environment나 셸 프로필에 export https_proxy=http://10.211.55.1:7890 형태를 넣고, sudo -E apt update처럼 환경을 승계하는지 확인합니다. SOCKS만 열려 있다면 all_proxy=socks5://...를 사용합니다. 일부 도구는 프록시 URL 스킴을 엄격히 검사하므로, 오타 없이 http://와 socks5://를 구분하세요.
컨테이너 안에서 또 다른 프록시 체인을 만들기보다, 게스트 전체를 호스트 한 포트에 붙이는 편이 디버깅이 쉽습니다. systemd 유닛으로 상시 환경 변수를 넣고 싶다면 서버용 Linux Mihomo·systemd 가이드의 패턴을 참고하되, 본 시나리오에서는 게스트가 Mihomo를 직접 돌릴 필요는 없습니다.
8 DNS만 이상할 때: FakeIP·DoH·게스트 리졸버
호스트 Mihomo에서 FakeIP를 쓰는 프로필이라면, 게스트가 호스트 DNS를 그대로 물려받지 못하거나, 물려받아도 198.18.0.0/15 대역 응답을 게스트가 해석하지 못해 «브라우저는 되는데 ping은 이상하다» 같은 혼란이 생길 수 있습니다. 이럴 때는 게스트 DNS를 공용 DoH/DoT가 아닌 «호스트가 실제로 쓰는 리졸버»와 맞추거나, 브라우저만 프록시를 타고 시스템 DNS는 ISP 쪽으로 가는 비대칭을 없애야 합니다. 원리 정리는 Meta DNS·FakeIP 유출 방지 글을 함께 읽으면 원인 분해가 빨라집니다.
Windows에서 ipconfig /all로 DNS 서버 목록을 보고, Linux에서 resolvectl status나 cat /etc/resolv.conf로 확인해 보세요. 호스트 Clash의 DNS 섹션에서 listen을 LAN에 열어 두었다면 그 IP를 게스트의 유일한 DNS로 지정하는 방법도 있지만, 그만큼 호스트가 항상 켜져 있어야 하므로 운영 형태를 고려합니다.
9 일부 앱만 프록시가 먹히는 이유
브라우저는 시스템 프록시를 잘 따르지만, Go·Rust로 빌드된 CLI는 기본이 직접 연결인 경우가 많습니다. 또 Electron 앱은 내장 Chromium 설정이 별도인 때도 있습니다. 증상이 «앱마다 다르다»면 프록시 체인 자체는 살아 있는 경우가 많으니, 해당 앱의 문서에서 프록시 환경 변수나 PAC 지원 여부를 확인하세요. 호스트 macOS에서 TUN 모드를 켜 두면 터미널 트래픽까지 한 번에 잡는 편이 수월하지만, TUN이 가상화와 겹칠 때는 라우팅 우선순위를 더 조심해야 합니다.
Parallels와의 조합에서 TUN을 쓸지, 게스트에만 수동 프록시를 줄지는 트레이드오프입니다. TUN에 대한 단계별 설명은 Clash Verge Rev TUN 모드 가이드를 참고하세요. 본문의 SOCKS 경로는 TUN 없이도 동작한다는 점이 장점입니다.
10 브리지 모드·Wi-Fi 격리·다른 하이퍼바이저와의 비교
브리지 네트워크로 바꾸면 게스트가 상위 라우터의 한 대의 PC처럼 보이므로, 사무실망에서 DHCP를 받아 쓰는 시나리오에 맞을 수 있습니다. 다만 앞서 말한 것처럼 AP 클라이언트 격리 정책이 있으면 호스트와 게스트가 서로를 못 보는 경우가 생깁니다. 이럴 때는 공유 네트워크로 되돌리거나, USB 이더넷 어댑터로 별도 망을 구성하는 등 물리적 우회를 검토해야 합니다.
Hyper-V NAT나 VMware의 NAT와 비교하면, «호스트 IP = 게이트웨이»라는 사용자 경험은 비슷하지 Mac 쪽 UI 용어만 다릅니다. 팀 단위로 문서를 공유할 때는 스크린샷만 Windows 호스트 기준으로 두지 말고, 본 글처럼 Parallels Desktop과 macOS 방화벽 이름을 명시하는 편이 혼선을 줄입니다.
11 정리
Parallels Desktop의 공유 네트워크 아래에서 Windows·Linux 게스트가 macOS 호스트의 Clash Verge Rev를 타려면, 시스템 프록시에만 기대지 말고 호스트의 mixed·SOCKS 포트를 LAN에 열고 게이트웨이 IP와 조합해 주면 됩니다. 방화벽과 보안 제품이 인바운드를 막지 않는지, DNS가 FakeIP와 충돌하지 않는지, 브라우저만 되고 CLI는 안 되는지를 나누어 보면 대부분의 «연결 안 됨»이 해소됩니다. 같은 Mihomo 규칙을 호스트에서만 유지해도 되므로 구독 동기화 부담도 적습니다.
상용 VPN 앱과 달리 Clash 계열은 규칙·노드·DNS를 직접 설계할 수 있어, 개발용 VM과 일상용 Mac을 한 세트의 정책으로 묶기에 적합합니다. 호스트 클라이언트를 아직 설치하지 않았다면, 먼저 공식 경로로 받아 기본 프로필을 맞춘 뒤 이 글의 LAN·포트 단계로 넘어오면 전체 소요 시간이 짧아집니다.
다른 플랫폼에서도 Verge Rev를 쓰고 있다면 Windows·Linux 설치 글과 개념이 이어지므로, 팀원에게는 «호스트 OS별 설치 + VM은 SOCKS로 붙인다»는 한 줄 요약을 공유해도 좋습니다.
