이 글이 말하는 증상

Windows 11에서 Clash·Clash Verge Rev·mihomo 기반 GUI를 실행해 시스템 프록시나 브라우저 확장을 켜 두면 Edge·Chrome은 기대한 출구로 잘 나갑니다. 그런데 같은 PC에서 WSL2(Windows Subsystem for Linux) 안의 Ubuntu로 들어가 sudo apt update나 curl https://example.com를 실행하면 패키지 목록이 받아지지 않거나, 연결이 매우 길게 멈췄다가 타임아웃합니다. 사용자 입장에서는 “Clash는 켰는데 왜 리눅스 쪽만 직결처럼 보이지?”라는 느낌이 들지만, 실제로는 프로세스가 붙는 IP 주소와 프록시 설정을 읽는 계층이 Windows 네이티브 앱과 WSL2가 완전히 다르기 때문입니다.

이번 가이드는 Windows 호스트에서 이미 열어 둔 Clash 혼합 포트(mixed-port)를 전제로, WSL2 셸과 apt·curl 같은 도구가 그 포트를 HTTP CONNECT와 일반 HTTP 프록시로 사용하도록 맞추는 절차에 집중합니다. 네이티브 PowerShell에서 Git·npm만 안 되는 경우는 Windows 터미널·혼합 포트 환경변수 가이드가 더 가깝고, 여기서는 가상화된 리눅스 환경이 Windows 루프백과 어떻게 어긋나는지를 중심으로 설명합니다. YAML에서 포트를 고정해 두었다면 YAML 설정 가이드의 숫자와 클라이언트 UI의 mixed-port가 같은지도 함께 확인하세요.

WSL2가 Windows “시스템 프록시”를 자동으로 쓰지 않는 이유

WSL2는 경량 가상 머신 위에서 자체 네트워크 네임스페이스를 가집니다. 따라서 Windows 설정 앱의 프록시나 WinINet 계열이 넘겨 주는 정보가, 리눅스 안의 apt·curl·wget에 자동으로 주입되지 않습니다. 일부 Microsoft 도구는 호스트와 연동하는 경로가 있지만, 일반적인 Debian·Ubuntu 패키지 관리자와 GNU 도구들은 POSIX 관례인 HTTP_PROXY 같은 환경변수나 도구별 설정 파일을 보지 않으면 그냥 기본 라우팅으로 직접 나가려 합니다. 그 결과 Windows 브라우저는 잘 되는데 WSL만 막히는 “한쪽 다리만 절뚝이는” 화면이 자주 나옵니다.

또 하나의 함정은 127.0.0.1의 의미입니다. Windows에서 Clash가 127.0.0.1:7890처럼 mixed-port를 열었다고 해서, WSL2 안에서 같은 주소를 치면 리눅스 쪽 루프백을 가리킵니다. 즉 WSL의 127.0.0.1은 Windows 호스트의 Clash 리스너와 연결되지 않습니다. 그래서 Windows PowerShell용으로 적어 둔 http://127.0.0.1:7890 설정을 그대로 WSL에 복사하면 실패하는 것이 정상에 가깝습니다. 해결의 핵심은 Windows 호스트의 브리지 IP(보통 기본 게이트웨이)를 구한 뒤, 그 주소와 mixed-port를 조합하는 것입니다.

1단계: Windows 호스트 IP 확인과 재부팅 후 변동

가장 단순한 확인 방법은 WSL 터미널에서 다음과 같이 기본 라우트를 읽는 것입니다.

# Show default gateway (often the Windows host IP from WSL2)
ip route show default | awk '{print $3}'

출력된 주소를 $WIN_HOST처럼 변수에 넣어 두고 이후 예제에서 재사용하면 편합니다. 일부 가이드는 /etc/resolv.conf의 nameserver 줄을 호스트 IP로 쓰라고 하기도 하는데, 빌드와 DNS 플러그 설정에 따라 실제 게이트웨이와 다를 수 있으므로 우선은 ip route 기반 값을 기본으로 삼는 편이 안전합니다. WSL을 재시작하거나 PC를 슬립에서 깨운 뒤에도 같은 명령으로 다시 확인하는 습관을 들이면, “어제는 됐는데 오늘은 안 된다”는 상황에서 IP 변동을 빨리 걸러낼 수 있습니다.

Windows 11의 미러 모드 네트워킹을 켠 환경에서는 주소 체계가 달라질 수 있으니, 공식 문서의 권장 확인 방법과 함께 위 명령을 병행하세요. 미러 모드를 쓰지 않는 일반적인 NAT형 WSL2라면, 위 게이트웨이 주소로 호스트의 수신 포트에 TCP 연결을 시도하는 패턴이 널리 쓰입니다.

2단계: Clash 쪽 mixed-port·Allow LAN·수신 주소

Windows에서 Clash가 mixed-port에서만 요청을 받도록 하려면, 클라이언트 설정에서 혼합 포트 숫자를 확인합니다. Verge 계열 UI에서는 비슷한 이름의 필드로 표시되며, 실제로는 하나의 TCP 포트에서 HTTP와 SOCKS를 함께 받는 구성이 일반적입니다. 개념 정리는 Clash Verge Rev Windows·macOS 가이드와 같은 흐름으로 읽을 수 있습니다.

다음으로 중요한 것은 Allow LAN(또는 동등한 “LAN에서 수신 허용”) 옵션입니다. 기본값이 루프백만 수신이면 WSL2에서 호스트 IP로 붙어도 연결이 거절될 수 있으므로, 가상화된 리눅스에서 접근하려면 LAN 허용과 방화벽 예외를 함께 검토해야 합니다. 휴대폰을 같은 Wi-Fi에서 PC 프록시로 붙이는 시나리오는 LAN 프록시·방화벽 가이드와 맥락이 비슷하지만, WSL2는 물리 LAN이 아니라 호스트 가상 어댑터 쪽 경로에서 오므로 “LAN 허용”이라는 이름이 조금 헷갈릴 뿐, 실무에서는 같은 스위치를 건드리는 경우가 많습니다.

Windows Defender 방화벽에서 해당 실행 파일에 대한 인바운드 규칙이 막혀 있으면 WSL에서 연결이 즉시 끊깁니다. 잠시 방화벽 프로필을 테스트용으로 완화해 원인을 분리한 뒤, 최소 권한으로 TCP mixed-port만 허용하는 편이 안전합니다. 회사 보안 정책이 빡빡한 PC라면 IT 가이드를 먼저 확인하세요.

3단계: 셸 환경변수로 curl·wget·대부분의 CLI 붙이기

mixed-port 값을 예시로 7890이라고 하겠습니다. 실제 값으로 바꿔 주세요. 앞에서 구한 호스트 IP를 172.31.32.1 같은 placeholder로 두면, 현재 세션에서만 적용하려면 다음과 같이 설정할 수 있습니다.

export WIN_HOST=$(ip route show default | awk '{print $3}')
export MIXED_PORT=7890
export http_proxy="http://${WIN_HOST}:${MIXED_PORT}"
export https_proxy="http://${WIN_HOST}:${MIXED_PORT}"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
# optional for tools that honor ALL_PROXY
export all_proxy="$http_proxy"
export ALL_PROXY="$all_proxy"

이후 curl -I https://deb.debian.org처럼 헤더만 받는 테스트로 우선 연결을 확인합니다. 여기까지 되면 “curl은 프록시를 탄다”는 층은 통과한 것입니다. NO_PROXY에는 최소한 localhost,127.0.0.1,::1과 사내 전용 호스트 접미사를 넣어 두는 것이 좋습니다. 사내 Git·Docker 레지스트리까지 전역 프록시로 끌고 가면 오히려 느려지거나 막히는 경우가 많습니다.

영구 적용은 사용자 홈의 ~/.bashrc나 ~/.profile에 같은 블록을 넣는 방식이 일반적입니다. 다만 Clash를 끈 채로 WSL만 켜 두면 존재하지 않는 출구로 붙으려다 실패하므로, “Clash를 켤 때만 소스한다”는 래퍼 스크립트로 나누는 팀도 있습니다. zsh을 쓴다면 ~/.zshrc에 동일한 내용을 두면 됩니다.

4단계: apt만 별도로: Acquire::http::Proxy와 인증서

apt는 환경변수를 항상 신뢰하는 구성이 아니라서, 안정적으로 맞추려면 /etc/apt/apt.conf.d/ 아래에 작은 설정 파일을 두는 방식이 흔합니다. 예시는 다음과 같습니다. 주석은 영어로 유지합니다.

# /etc/apt/apt.conf.d/95clash-proxy (example; use your WIN_HOST and port)
Acquire::http::Proxy "http://172.31.32.1:7890";
Acquire::https::Proxy "http://172.31.32.1:7890";

파일을 직접 편집하려면 관리자 권한이 필요합니다. 회사 이미지에서 apt가 사내 CA를 요구한다면, 프록시만 맞춰도 TLS 검증에서 막힐 수 있으니 인증서 체인을 별도로 정비해야 합니다. Clash의 TLS 가로채기나 스니핑 기능을 켠 상태에서 apt 저장소와 충돌하면 증상이 비슷하게 보이므로, 개발 편의와 보안 정책 사이에서 옵션을 명확히 나누는 것이 좋습니다.

설정을 넣은 뒤에는 sudo apt update로 인덱스만 받아 보고, 특정 패키지를 apt install -s로 시뮬레이션해 보는 순서가 안전합니다. 프록시를 끄고 싶을 때는 해당 apt.conf.d 파일을 제거하거나 줄 앞에 주석을 달면 됩니다.

5단계: wsl.conf·DNS와 헷갈리기 쉬운 함정

/etc/wsl.conf의 network 섹션은 주로 생성된 resolv.conf 동작이나 미러 모드 같은 호스트 연동 정책을 다룹니다. “프록시 URL 한 줄”을 넣는 파일이 아니라는 점을 기억하세요. DNS가 불안정하면 apt 인덱스 URL은 맞는데 이름 해석만 실패하는 일이 생기므로, 문제가 DNS인지 TCP인지부터 dig나 getent hosts로 나눕니다.

IPv6만 있는 환경에서 IPv4 프록시만 열어 둔 경우, 애플리케이션이 AAAA를 먼저 시도하다 지연되는 패턴도 있습니다. 그럴 때는 일시적으로 curl -4로 좁혀 보거나, 시스템의 주소 선호 정책을 점검합니다. 반대로 호스트 IP를 잘못 잡아 172.x 대역이 아닌 값을 쓰면 아예 SYN이 나가지 않기도 하므로, 매 세션 시작 시 게이트웨이를 다시 읽는 작은 스크립트를 두면 운영이 편해집니다.

TUN 모드와의 관계: “전부 WSL에서 나가게”가 필요한 경우

이 글의 방법은 프록시를 이해하는 HTTP 클라이언트에 초점을 맞춘 것입니다. 반대로 WSL 안의 임의 프로세스까지 한 번에 특정 출구로 보내고 싶다면 Linux 쪽에서 tun2socks류를 쓰거나, Windows 쪽 Clash TUN이 WSL 트래픽까지 어떻게 보이는지까지 설계를 넓혀야 합니다. 그런 구성은 라우팅 표와 충돌이 생기기 쉬워 TUN 사용 후 인터넷이 끊기는 문제와 맞닿습니다. 우선은 mixed-port와 환경변수로 80~90퍼센트의 개발 시나리오를 커버한 뒤, 정말 필요할 때 TUN 쪽으로 확장하는 순서를 권합니다.

재현 체크리스트와 마무리

정리하면 다음 순서로 좁히면 대부분의 “apt·curl만 직결” 사례를 재현 가능하게 풀 수 있습니다. 첫째, WSL2에서 Windows 호스트 IP를 다시 구한다. 둘째, Clash의 mixed-port 숫자가 문서·YAML·UI에서 일치하는지 확인한다. 셋째, Allow LAN과 방화벽으로 호스트 IP에서의 TCP 접속이 열려 있는지 본다. 넷째, 셸에 HTTP_PROXY·HTTPS_PROXY를 호스트 IP 기반 URL로 넣는다. 다섯째, apt는 필요하면 Acquire::http::Proxy로 별도 고정한다. 여섯째, DNS·IPv6·TLS 가로채기 같은 프록시 “앞뒤”의 변수를 의심한다.

Windows 네이티브 터미널과 WSL2를 같이 쓰는 개발 환경에서는, 한쪽만 맞춰 두고 다른 쪽 설정을 복사해 오면 꼭 한 번은 127.0.0.1 함정에 빠집니다. 혼합 포트라는 숫자 자체는 맞는데도 안 되는 대부분의 경우는 주소가 루프백으로 남아 있거나 LAN 수신이 꺼져 있는 경우입니다. 설치 파일과 업데이트 채널은 공식 배포 페이지를 기준으로 맞추면 버전 혼선이 줄고, GUI 클라이언트를 쓰면 포트와 시스템 프록시 토글을 한 화면에서 관리하기 쉬워집니다. 같은 맥락에서 한 번에 경로를 정리하고 싶다면 → Clash를 무료로 내려받아 Windows와 WSL2를 같은 출구 설계로 맞춰 보세요.