WSL2 터미널이 Windows Clash를 타기: 미러 네트워크와 localhost 프록시 설정 실측 (2026)

1. WSL2 안의 127.0.0.1은 Windows Clash가 아니다

WSL2는 경량 VM에 가까운 별도 네트워크 네임스페이스를 씁니다. 그래서 리눅스 셸 안에서 127.0.0.1은 「그 리눅스 인스턴스 자기 자신」을 가리킬 뿐이고, Windows 호스트에서 127.0.0.1:7890으로 리슨 중인 Clash와 자동으로 연결되지 않습니다. 브라우저만 쓸 때는 시스템 프록시가 잘 잡혀 보여도, 터미널은 환경 변수나 도구별 설정을 따로 줘야 하는 경우가 많습니다. 여기서 흔한 실수가 「호스트와 같은 루프백이라 착각하고 주소를 127로 고정한다」는 것입니다. 실무에서는 먼저 호스트 측 가상 어댑터 IP(WSL이 Windows를 바라볼 때 쓰는 게이트웨이 후보)를 확정하고, 그 주소와 mixed-port 조합으로 붙이는 흐름이 안정적입니다.

반대로 말하면, WSL2에서 나가는 SYN이 실제로 어디로 향하는지 한 번만 명확히 잡아 두면, 이후 export HTTP_PROXY=...를 셸 프로필에 넣든 git config --global http.proxy를 쓰든 같은 엔드포인트를 재사용할 수 있습니다. Hyper-V·Docker Desktop·다른 VPN이 같이 깔린 환경에서는 어댑터 우선순위가 바뀌어 숫자만 복사해 쓰다가 틀어지는 경우도 있으니, 증상이 바뀔 때마다 호스트 IP를 다시 확인하는 습관이 좋습니다.

2. 호스트 IP 잡기: 기본 게이트웨이와 resolv.conf

가장 널리 쓰이는 방법은 WSL2 안에서 기본 라우트의 다음 홉을 보는 것입니다. 예를 들어 ip route show default 출력에 나오는 via 뒤의 IPv4 주소가, 종종 Windows 호스트 쪽 인터페이스를 가리킵니다. 또 다른 휴리스틱은 cat /etc/resolv.conf에서 nameserver 줄을 확인하는 것인데, Microsoft가 자동 생성하는 설정에서는 이 값이 호스트의 DNS 프록시나 가상 어댑터와 연결되는 경우가 많습니다. 다만 수동으로 resolv.conf를 고정해 둔 팀도 있어서, 「항상 nameserver 한 줄이 곧바로 호스트 IP다」라고 단정하기는 어렵습니다. 중요한 것은 실제로 TCP 연결이 되는지입니다.

# In WSL: find default gateway and test port (replace 7890 with your mixed-port)
ip route show default
grep -E '^nameserver' /etc/resolv.conf
nc -vz <HOST_IP> 7890

nc나 curl -v로 먼저 포트가 열려 있는지 본 뒤, 프록시 환경 변수를 채우면 원인 분기가 빨라집니다. Windows 11에서 Verge Rev로 시스템 프록시와 TUN을 켠 상태라면, 호스트 쪽에서 mixed-port가 실제로 리슨 중인지와 방화벽 인바운드 예외가 맞는지도 함께 봐야 합니다.

3. 미러 네트워크 모드와 localhost 전달

비교적 최신 WSL2에는 네트워킹 옵션이 늘어났고, 그중 미러 네트워크(mirrored networking) 계열 설정은 호스트와 게스트가 서로의 localhost에 도달하는 방식을 바꿉니다. 이 모드가 켜져 있으면 「리눅스에서 127.0.0.1:포트로 보내면 호스트의 같은 포트로 전달된다」는 기대가 성립하는 경우가 있어, Clash를 호스트 루프백에만 바인딩해 둔 구성과도 맞물릴 수 있습니다. 반대로 미러 모드가 꺼져 있거나 빌드·배포판에 따라 동작이 다르면, 앞 절의 호스트 IP + mixed-port 조합이 여전히 기본값이 됩니다.

정리하면, 문서만 읽고 「이제 127이 된다」고 단정하기보다, 본인의 wsl.conf·Windows 쪽 프리뷰 채널·버전 조합에서 실제로 어떻게 되는지 curl -v http://127.0.0.1:7890 같은 관측으로 확인하는 편이 안전합니다. 회사 보안 정책으로 가상 스위치 구성이 고정된 환경에서는 팀 표준 문서와 실측이 어긋나기도 하므로, 내부 위키의 IP 예시를 그대로 복사하지 말고 항상 연결 테스트를 한 번 거치세요.

4. Windows Clash 쪽: mixed-port·allow-lan·바인드

WSL2는 호스트의 루프백이 아니라 가상 네트워크 대역에서 오는 클라이언트처럼 보입니다. 그래서 Clash 코어 설정에서 mixed-port가 127.0.0.1에만 열려 있으면 WSL2에서 아무리 올바른 IP를 쳐도 SYN이 거절됩니다. GUI 클라이언트라면 LAN 허용·수신 주소 옵션을 켜서 0.0.0.0 또는 해당 인터페이스에 바인딩해야 하는 경우가 많습니다. 동시에 불필요하게 넓게 노출하지 않도록, 개발 전용 PC·홈 네트워크인지 사내망인지에 따라 allow-lan·방화벽 범위를 조절하는 편이 좋습니다.

터미널 프록시로 붙을 때는 보통 http://호스트IP:포트 형식이 이해하기 쉽습니다. SOCKS만 열어 둔 프로필이라면 ALL_PROXY=socks5://... 쪽을 택해야 하고, mixed-port가 살아 있다면 HTTP 계열 도구와의 궁합이 좋습니다. 호스트에서 TUN까지 켜 두었다면, 일부 트래픽은 이미 전역으로 잡힐 수 있으니 이중으로 프록시를 겹치지 않도록 주의하세요.

5. 터미널: HTTP_PROXY·HTTPS_PROXY·ALL_PROXY·NO_PROXY

셸에서 공통으로 쓰려면 ~/.bashrc·~/.zshrc 등에 다음과 비슷한 줄을 넣습니다. 호스트 IP 자리에는 앞에서 구한 값을, 포트에는 Clash의 mixed-port를 넣습니다.

# Example: proxy env in WSL shell (adjust host IP and port)
export HTTP_PROXY=http://172.x.x.x:7890
export HTTPS_PROXY=http://172.x.x.x:7890
export ALL_PROXY=http://172.x.x.x:7890
export NO_PROXY=localhost,127.0.0.1,::1

NO_PROXY에는 사내망 Git·내부 레지스트리·메쉬 호스트를 넣어 직접 경로로 빼는 패턴이 흔합니다. 프록시를 끄고 싶은 날에는 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY로 깨끗이 지우는 것이 디버깅에도 도움이 됩니다.

6. apt·git·npm·curl이 각각 보는 것

curl는 표준 환경 변수를 잘 따르는 편이라 위 설정만으로도 재현이 쉽습니다. git은 http.proxy·https.proxy를 별도로 둘 수 있어, 팀 규칙상 셸 변수와 분리해 두는 경우가 있습니다. npm·pnpm·yarn은 프록시 키와 레지스트리 URL, TLS 검증 옵션이 얽혀 「브라우저에선 되는데 레지스트리만 실패」가 나올 수 있으니, npm config list로 실제 값을 확인하세요. apt는 Acquire::http::Proxy 같은 설정 파일 문법을 쓰는 경우가 많아, 단순히 HTTP_PROXY만으로는 안 바뀌는 빌드도 있습니다.

한 가지 더 짚으면, 어떤 도구는 HTTP(S)만 프록시하고 DNS 조회는 로컬 리졸버로 먼저 던집니다. 그때 Clash의 fake-ip나 스플릿 DNS 설정과 WSL2의 resolv.conf가 엇갈리면 「IP로는 되는데 이름만 실패」처럼 보입니다. 다음 절에서 그 교차를 정리합니다.

7. DNS·fake-ip와 resolv.conf 교차

호스트 Clash가 DNS를 가로채 fake-ip를 쓰는 프로필이라면, WSL2 안의 애플리케이션이 어떤 업스트림에 질의하는지가 규칙 매칭에 직접 영향을 줍니다. /etc/resolv.conf가 가리키는 nameserver가 호스트의 Clash DNS와 일관되는지, 아니면 별도의 공용 DNS로 새 나가는지를 먼저 구분하세요. systemd-resolved를 쓰는 배포판과 순수 Debian 계열에서 파일 생성 방식이 달라, 팀원마다 내용이 다르면 같은 YAML을 써도 증상만 달라질 수 있습니다.

실무에서는 「DNS 문제인지 TCP 프록시 문제인지」를 가르는 것이 빠릅니다. 호스트에서 Clash 로그로 해당 도메인이 어떤 줄에 매칭되는지 보고, WSL2 안에서 dig·resolvectl 등으로 실제 응답 IP를 확인해 보세요. 규칙·스니퍼·TUN의 관계는 TUN 모드 설명과 맞물리므로, 브라우저만 정상일 때 특히 유용합니다.

8. 연결 실패 시 권장 점검 순서

아래 순서를 권합니다. 첫째, Windows에서 Clash가 실행 중이고 mixed-port에 LISTEN이 있는지 확인합니다. 둘째, WSL2에서 호스트 후보 IP와 포트에 TCP 연결이 되는지 nc나 curl -v로 검증합니다. 셋째, 셸·도구별로 프록시 환경 변수나 설정이 실제로 주입됐는지 확인합니다. 넷째, DNS가 의심되면 resolv.conf와 질의 결과를 호스트 로그와 대조합니다. 다섯째, VPN·다른 필터·회사 보안 에이전트가 같은 경로를 가로막지 않는지 봅니다.

Docker 안에서만 문제가 재현된다면 게이트웨이와 브리지 시야가 다릅니다. 그때는 Docker·호스트 Clash 절차를 따르고, 본 글의 WSL2 터미널 설정과 혼동하지 않도록 증상을 분리해 적어 두면 이후 재현이 쉬워집니다.