왜 VM만 따로 프록시 주소를 잡아야 하나

호스트에서 Clash를 켠 뒤 시스템 프록시나 TUN으로 데스크톱 브라우저가 잘 따라가도, 가상머신 안에서는 그 설정이 자동으로 공유되지 않습니다. 게스트 OS는 별도의 IP 스택을 가진 “작은 PC”에 가깝기 때문입니다. 특히 127.0.0.1은 게스트 입장에서 자기 자신을 가리키므로, 호스트 문서에 적힌 127.0.0.1:7890 같은 예시를 그대로 붙여 넣으면 연결 거부나 즉시 실패로 끝나기 쉽습니다. Microsoft 쪽 경량 리눅스인 WSL2도 같은 종류의 함정이 있는데, 거기서는 Windows 호스트를 향하는 특수 IP·DNS 파일 패턴이 문서화되어 있습니다(WSL2·Windows 호스트 Clash 실측). 가상머신에서는 벤더가 만든 가상 라우터(NAT) 또는 물리 LAN과 붙는 브리지 중 어디에 서 있느냐에 따라 “호스트를 가리키는 다음 홉”이 달라집니다.

이 글은 라우터 전체를 Clash 앞에 두는 게이트웨이형 구성(예: 별도 리눅스 박스에서 nft로 포워딩)과는 접근이 다릅니다. 그런 투명 프록시·관문 패턴은 Linux nftables·TUN 게이트웨이 글과 목적이 겹치지만, 여기서 다루는 것은 이미 노트북에서 돌아가는 Clash 하나만 신뢰하고 VM 안 애플리케이션을 그 포트로 보내는 최소 구성입니다.

ℹ 표기: 아래에서는 호스트에서 Clash가 노출하는 mixed-port(HTTP·SOCKS가 같은 포트)를 7890으로 예시합니다. 실제 값은 대시보드에 표시된 숫자로 바꿉니다. HTTP만 열었다면 http://호스트IP:포트, SOCKS만 열었다면 socks5h://... 식으로 맞추면 됩니다.

호스트 Clash 쪽 선행: 포트·allow-lan·방화벽

게스트가 호스트 IP로 들어오려면 Clash가 루프백에만 붙어 있어서는 안 됩니다. 대개 다음 세 가지를 함께 확인합니다. 첫째, allow-lan: true(GUI의 동등 스위치)로 다른 인터페이스에서 오는 연결을 허용합니다. 둘째, 바인딩이 127.0.0.1로 고정되어 있지 않은지—와일드카드나 0.0.0.0에 가까운 설정은 코어·버전 문구가 조금씩 다릅니다. 셋째, macOS의 소프트웨어 방화벽이나 Windows Defender 방화벽이 해당 TCP 포트의 인바운드를 막고 있지 않은지입니다. 세그먼트 밖에서 폰이 접속해 버리는 부작용까지 포함해 LAN 공유 개념을 더 깊게 보고 싶다면 LAN 공유·방화벽·바인드 주소 글의 체크리스트를 같은 순서로 적어 두면 재현성이 좋아집니다.

호스트에서 TUN 모드까지 켜 두었다면, 게스트 트래픽이 자동으로 투명하게 빨려 들어가지 않습니다. TUN은 호스트 OS 라우팅 테이블 관점에서 동작하고 VM은 별도 장비처럼 보이기 때문입니다. 스택 감각을 정리하려면 TUN 모드 심층을 참고하고, VM에서는 “투명 게이트웨이를 바꾼다”보다 “명시적 프록시 종단을 호스트 IP로 준다” 쪽이 단순합니다.

NAT 모드: 기본 게이트웨이가 곧 “호스트 쪽 입구”인 패턴

Parallels·VMware 모두 기본 네트워크 어댑터를 NAT로 두는 경우가 많습니다. 이 때 게스트가 보는 기본 게이트웨이(default via)는 보통 가상화 소프트웨어가 만든 내부 라우터이고, 그 다음 홉이 호스트 커널입니다. 실무에서는 게스트 셸에서 다음을 먼저 실행해 숫자를 하나 적어 둡니다.

Linux guest — default gateway 
ip route | grep '^default'
Windows guest — PowerShell 
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric

출력된 게이트웨이 IP(예: 10.0.x.1, 192.168.xxx.x 등)가 바로 VM 문서에서 말하는 “공유 장치 쪽 IP”에 해당하는 경우가 많습니다. 이 주소에 대해 호스트에서 Clash 포트가 열려 있는지 게스트 안에서 curl 혹은 PowerShell Test-NetConnection으로 검사합니다. NAT 아래에서는 브로드캐스트 정책 때문에 일부 툴이 헷갈리므로, 최종적으로는 “실제 애플리케이션이 쓰는 스킴과 포트”로 다시 한 번 확인합니다.

⚠ 보안: allow-lan과 와이드 바인드는 같은 서브넷·카페 Wi‑Fi의 다른 단말에서도 프록시 포트가 보일 수 있습니다. 불필요한 노출을 줄이려면 방화벽에서 소스 대역을 제한하거나, 테스트 후 스위치를 되돌리는 습관을 권장합니다.

브리지 모드: LAN 세그먼트와 호스트의 유선·무선 IP

어댑터를 브리지드로 바꾸면 게스트 NIC가 물리 스위치의 한 포트처럼 같은 서브넷에 직접 붙습니다. 이 경우 프록시 종단으로 쓸 주소는 위 NAT 게이트웨이가 아니라, 호스트가 그 세그먼트에서 받은 실제 LAN IP(예: 192.168.0.23)입니다. 노트북이 유선·무선을 바꿀 때마다 숫자가 변하므로, 문서에는 변수명 HOST_LAN_IP 정도로 적어 두고 필요할 때마다 갱신하는 편이 안전합니다. 멀티 홈(VPN·도킹·테더링 동시 사용) 환경에서는 어느 인터페이스가 기본 경로인지에 따라 VM에서 보이는 경로도 달라질 수 있습니다.

브리지 모드는 “호스트와 게스트가 같은 망에 있다”는 점에서 설정은 단순해지지만, 회사 NAC·Wi‑Fi 클라이언트 격리 정책에 걸리면 링크 자체가 실패하기도 합니다. 그럴 때는 다시 NAT로 돌아가 명시적 프록시만 맞추는 편이 현실적인 타협점입니다.

두 단계 — 시스템 프록시 vs 셸·APT 환경 변수

1단계는 브라우저·일부 데스크톱 앱이 읽는 OS 시스템 프록시(Windows “프록시 서버 사용”, macOS 네트워크 고급 설정, GNOME 프록시 등)입니다. 게스트 안에서 호스트 IP와 포트를 넣어 두면 Chrome·Edge 계열은 바로 따라오는 경우가 많습니다. 2단계는 터미널·빌드 도구·패키지 매니저가 주로 보는 환경 변수(http_proxy, https_proxy, all_proxy, 대문자 변형 포함)입니다. Docker나 CI 스크립트에서 이미 익숙한 패턴과 동일하며, 요약 예시는 Docker·CLI mixed-port 가이드와 같은 식으로 확장하면 됩니다.

bash/zsh — session exports (replace HOST_IP) 
export HOST_IP="192.168.x.x"   # NAT 게이트웨이 또는 브리지 LAN의 호스트 IP
export HTTP_PROXY="http://${HOST_IP}:7890"
export HTTPS_PROXY="http://${HOST_IP}:7890"
export ALL_PROXY="socks5h://${HOST_IP}:7890"
export NO_PROXY="localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

socks5h:// 접두사는 이름 해석 위치를 프록시 쪽에 두려는 의도일 때 자주 씁니다. 내부 레지스트리·사설 Git 호스트는 NO_PROXY에 꼭 넣어 직접 경로를 유지하세요. APT는 /etc/apt/apt.conf.d/ 아래 Acquire::http::Proxy 줄을 따로 두는 팀도 많습니다—환경 변수만으로 안 되면 패키지 계층 설정을 의심합니다.

게스트 OS별로 자주 쓰는 설정 위치

Windows 게스트에서는 설정 앱의 프록시 섹션에 호스트 IP·포트를 넣거나, 레거시 대화상자의 LAN 설정에서 동일하게 지정합니다. 회사 PC면 그룹 정책이 덮어쓸 수 있으니 변경 후 재부팅·gpupdate 여부를 확인합니다. macOS 게스트(드물지만 테스트용으로 띄우는 경우)는 시스템 설정 ▸ 네트워크 ▸ 세부 정보 ▸ 프록시에서 HTTP·SOCKS를 각각 채웁니다. Linux 게스트는 데스크톱 세션마다 /etc/environment, systemd user 단위, 셸 RC 파일 등 여러 층이 공존하므로 “실제로 실행 중인 셸에 변수가 있는지”를 env | grep -i proxy로 먼저 확인합니다.

어떤 GUI 빌드를 쓸지 팀 기준을 맞추려면 클라이언트 선택 가이드에서 호스트 쪽 용어(Mixed, TUN, System Proxy)를 통일해 두는 것도 도움이 됩니다. VM 안에서는 호스트와 같은 바이너리가 필요하지 않고, 끝점 주소만 일치하면 됩니다.

DNS는 어디서 맞출까 (게이트웨이만 바꾸면 안 되는 이유)

프록시 문자열만 넣고도 웹 페이지가 열리면 TLS 계층까지는 성공한 것입니다. 그러나 일부 CLI 도구는 여전히 로컬 스텁 리졸버(systemd-resolved, Windows NXDOMAIN 패턴 등)를 타며 Clash의 fake-ip·분류 규칙과 어긋날 수 있습니다. 코어 DNS 블록 설계 자체를 손볼 때는 Meta DNS(nameserver·fallback·fake-ip-filter) 순서를 호스트에서 먼저 안정화하고, 게스트에는 “프록시만 명시하고 DNS는 기본 게이트웨이를 그대로 둔다” 혹은 “프록시 DNS까지 통일한다” 중 하나를 문서화해 팀 합의를 두는 편이 좋습니다. 두 방향을 섞으면 「브라우저만 되고 apt만 안 된다」 같은 분기가 늘어납니다.

특정 도메인이 게스트와 호스트에서 서로 다른 응답을 받으면, 규칙 우선순위 문제일 수도 있습니다. 규칙 디버깅 흐름은 MATCH·GEOIP 우선순위 교정 글과 연결 패널 로그를 같이 보세요.

실패 분기 줄이는 검증 순서

  1. 호스트 로컬에서 127.0.0.1:포트가 살아 있는지 확인한 뒤, 같은 검사를 게스트에서 호스트IP:포트로 반복합니다.
  2. 연결 거부면 allow-lan·바인드·방화벽 순입니다. 타임아웃이면 방화벽이나 잘못된 서브넷 선택을 의심합니다.
  3. NAT와 브리지를 바꿨다면 HOST_IP 후보를 반드시 다시 적습니다—문서에 붙여 둔 예전 숫자가 가장 흔한 실수입니다.
  4. 브라우저만 성공하고 터미널이 실패하면 OS 프록시와 환경 변수 중 어느 층이 비었는지 나눕니다.
  5. TCP는 성공하는데 특정 이름만 실패하면 DNS·fake-ip 축을 호스트 Clash 설정에서 재점검합니다.

TLS 핑계와 타임아웃 메시지를 구분하는 방법은 연결 로그 timeout/TLS 안내와 함께 보면 VM 안팎을 오가며 디버깅할 때 시간을 줄일 수 있습니다.

맺음말

가상머신은 WSL2와 마찬가지로 “화면은 한 대인데 네트워크 스택은 분리”되어 있습니다. NAT에서는 가상 게이트웨이, 브리지에서는 LAN 상의 호스트 IP가 프록시 종단으로 적합하고, 127.0.0.1 예시를 게스트에 그대로 복사하지 않는 것이 첫 번째 관문입니다. 그다음 OS 시스템 프록시와 터미널 환경 변수를 순서대로 맞추면 브라우저·curl·패키지 매니저까지 같은 출구로 정렬하기 쉬워집니다.

무료로 제공되는 공식 패키지 페이지에서 호스트 클라이언트를 받아 포트를 확인한 뒤, 게스트에는 주소 한 줄만 반복해서 테스트해 보세요. → Clash V.CORE 공식 다운로드 페이지에서 무료로 받기