1. 왜 WSL2만 프록시가 안 맞을까

WSL2는 경량 가상화 위에서 리눅스 커널이 돌아갑니다. Windows 쪽에서 Clash가 시스템 프록시를 켠다고 해서, WSL2 안의 모든 프로세스가 자동으로 그 설정을 읽지는 않습니다. 터미널 도구는 대개 환경 변수나 자체 설정 파일만 따르고, apt는 http_proxy를 무시하고 Acquire::http::Proxy를 요구하기도 합니다. 또한 WSL2에서 127.0.0.1:7890으로 붙으면 그건 리눅스 자신의 루프백이므로, Windows Clash가 듣고 있는 포트와 연결되지 않습니다. 예외적으로 최신 Windows 11·WSL 조합에서는 localhost 전달 옵션이 켜져 있으면 편해질 수 있지만, 환경마다 다르므로 본문에서는 호스트 IP를 명시하는 방식을 기본으로 둡니다.

같은 PC 안에서 “다른 기기처럼” Windows IP의 포트로 들어가야 하므로, Clash가 127.0.0.1에만 바인딩되어 있으면 WSL2에서 연결이 거절됩니다. 이는 LAN 공유와 같은 맥락으로, LAN 프록시 가이드에서 다룬 allow-lan 개념을 호스트 측에 먼저 적용해야 합니다.

2. Windows Clash 측 준비: mixed-port와 allow-lan

Clash·Mihomo 계열 설정에서 mixed-port(예: 7890)가 HTTP와 SOCKS를 한 포트에서 받도록 되어 있는지 확인합니다. 포트 번호는 본인 환경에 맞게 고정해 두고, 이후 WSL2 전체에서 동일한 숫자를 참조하게 만듭니다. allow-lan을 true로 두면 데몬이 모든 인터페이스에서 수신할 수 있어, 가상 스위치 너머의 WSL2에서도 호스트 IP로 접근할 수 있습니다. GUI를 쓰는 경우 Clash Verge Rev 초보자 가이드에서 프로필 적용과 시스템 프록시 토글 흐름을 먼저 익힌 뒤, 설정 편집기나 구성 파일에서 위 두 항목을 맞추면 됩니다.

Windows Defender 방화벽에서 해당 포트(예: TCP 7890)에 대한 인바운드 허용 규칙이 없으면 WSL2에서 즉시 타임아웃이 납니다. “개인 네트워크” 프로필에만 열어 두는 편이 안전합니다. 회사 보안 정책으로 인바운드 추가가 어렵다면, 조직 IT 가이드를 따르거나 WSL 전용 우회 정책을 별도로 협의해야 합니다.

3. WSL2에서 Windows 호스트 IP 확인하기

가장 흔한 방법은 /etc/resolv.conf 안의 nameserver 줄입니다. WSL2는 기본적으로 Windows 호스트를 DNS 포워더로 쓰도록 구성되는 경우가 많아, 그 주소가 곧 WSL2가 Windows에 도달할 때 쓰는 게이트웨이에 가깝습니다. 터미널에서 다음을 실행해 보세요.

grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}'

출력된 IPv4(예: 172.x.x.x)를 메모해 두고, 아래에서 WIN_HOST 자리에 넣습니다. 일부 커스텀 이미지는 resolv.conf가 자동 생성과 충돌할 수 있으니, ip route show default로 기본 게이트웨이를 교차 확인하면 안전합니다. 두 값이 다르면 실제로 패킷이 나가는 쪽(보통 default route의 next hop)을 우선합니다.

4. 셸 환경 변수: http_proxy·all_proxy·no_proxy

대부분의 CLI는 대문자·소문자 조합을 모두 지원하지만, 도구마다 우선순위가 달라 둘 다 넣어 두는 편이 덜 헷갈립니다. 예시는 포트 7890과 호스트 IP 자리 표시자입니다.

export WIN_HOST=$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')
export http_proxy="http://${WIN_HOST}:7890"
export https_proxy="http://${WIN_HOST}:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export all_proxy="socks5h://${WIN_HOST}:7890"
export ALL_PROXY="$all_proxy"
export no_proxy="localhost,127.0.0.1,::1"
export NO_PROXY="$no_proxy"

socks5h는 DNS를 프록시 측에서 해석하게 하여, 일부 환경에서의 누수·오해석을 줄입니다. git·curl·wget·npm(기본 레지스트리) 등은 이 설정만으로도 동작하는 경우가 많습니다. 영구 반영은 ~/.bashrc 또는 ~/.zshrc에 같은 블록을 넣되, 호스트 IP가 바뀔 수 있으면 작은 래퍼 함수로 매 세션마다 WIN_HOST를 다시 읽게 하는 방식이 유지 보수에 유리합니다.

5. apt 전용 설정: Acquire::http::Proxy

Ubuntu·Debian 계열에서 apt는 환경 변수만으로는 충분하지 않을 때가 있습니다. /etc/apt/apt.conf.d/95proxies 같은 파일을 만들고 다음 형식을 씁니다.

Acquire::http::Proxy  "http://WIN_HOST:7890/";
Acquire::https::Proxy "http://WIN_HOST:7890/";

WIN_HOST는 실제 IPv4로 바꿉니다. 프록시가 HTTPS CONNECT를 잘 처리하는지에 따라 https 줄이 필수인지 달라질 수 있으나, Clash mixed-port는 일반적으로 둘 다 같은 포트로 받습니다. 설정 후 sudo apt update로 검증하고, 실패 시 -o Debug::Acquire::http=true로 어느 단계에서 멈추는지 로그를 확인합니다.

6. Docker Desktop(WSL2 백엔드)과 프록시

Docker 엔진이 이미지 레지스트리에 나갈 때는 호스트 OS 설정과 WSL2 내부 터미널 설정이 완전히 같지 않을 수 있습니다. Docker Desktop을 쓰는 경우, 앱 설정의 Resources → Proxies에서 수동 프록시를 켜고, Windows 호스트 입장에서 접근 가능한 주소를 넣습니다. 여기서는 http://127.0.0.1:7890이 Docker VM 측에서 의미 있게 동작하는 경우가 많지만, 빌드 컨테이너가 WSL2 네임스페이스 안에서 직접 외부로 나가는 시나리오라면 앞서 구한 WIN_HOST 형태가 더 맞을 수도 있습니다. 증상은 docker pull 단계에서 바로 드러나므로, 한 번 성공할 때까지 두 경로를 번갈아 시험해 보는 것이 빠릅니다.

고급 사용자는 데몬 JSON에 proxies 블록을 두기도 합니다. 조직 프록시나 MITM이 끼어 있으면 인증서를 컨테이너에 주입해야 하는데, 그때는 보안 정책 문서를 반드시 따르세요. 순수 docker build만 막힌다면 BuildKit 인자나 Dockerfile의 ARG HTTP_PROXY 전달을 추가로 검토합니다.

7. 검증 순서와 흔한 오류

먼저 WSL2에서 curl -I https://www.google.com 또는 자주 쓰는 헬스 체크 URL로 상태 코드를 확인합니다. 여기서 실패하면 DNS 문제인지 TCP 문제인지 나눕니다. Connection refused는 대개 잘못된 IP·포트이거나 Clash가 루프백에만 바인딩된 경우이고, 장시간 대기 후 끊기면 방화벽이나 노드 측 차단을 의심합니다. Windows 쪽 Clash 로그에 WSL2에서 온 소스 IP가 찍히는지도 함께 보면 원인 분리가 쉬워집니다.

localhost 전달을 켠 최신 환경에서는 WSL2에서 127.0.0.1:7890이 통하는 사례도 있으나, 업데이트나 배포판에 따라 달라집니다. 문서를 팀과 공유할 때는 “호스트 IP + mixed-port” 패턴을 표준으로 적어 두면 재현성이 높아집니다. 그 밖의 Clash 자체 오류는 일반 트러블슈팅 가이드의 포트·구독 절차와 연계해 점검하세요.

8. 보안과 운영 측면 짧은 메모

allow-lan은 같은 서브넷의 다른 기기에서도 프록시 포트에 도달할 수 있게 만듭니다. 카페·공용 Wi-Fi에서는 끄거나 방화벽으로 출처 IP를 제한하는 편이 안전합니다. 또한 프록시 URL을 셸 히스토리에 남기기 싫다면 별도 설정 파일에 두고 권한을 제한하세요. 기업망에서는 프록시 사용 자체가 정책 대상일 수 있으니 내부 규정을 우선합니다.

9. 정리

WSL2 개발 환경에서 “Windows만 되고 리눅스만 안 된다”는 현상은 대개 호스트 주소 착각과 프록시 수신 범위 두 가지로 귀결됩니다. Clash의 mixed-port를 열어 두고 allow-lan과 방화벽을 맞춘 뒤, WSL2에서는 호스트 IP를 기준으로 환경 변수와 apt 설정을 채우고, Docker는 Desktop 설정이나 데몬 프록시로 같은 출구를 맞추면 apt·git·npm·컨테이너 풀을 한 흐름으로 묶을 수 있습니다. 순수 리눅스 서버에 Mihomo를 systemd로 올리는 길과 달리, 이 구성은 Windows 워크스테이션에 이미 깔린 클라이언트를 최대한 재사용한다는 점에서 유지 비용이 낮습니다.

GUI로 프로필 전환과 로그 확인을 함께 하고 싶다면 Windows용 공식 클라이언트를 기준으로 잡는 것이 실수를 줄입니다. 유사 도구들과 비교해도 Clash 계열은 규칙·로그·업데이트 흐름이 한데 모여 있어 교차 검증이 수월한 편입니다. → Clash를 무료로 다운로드하고 WSL2와 Windows를 같은 프록시 축으로 맞춰 보세요