WSL2 Clash 프록시 브리지·DNS 동기화 실측

어떤 상황을 가리키는가

Windows 11(또는 Windows 10)에서 Clash 클라이언트를 실행하고, Edge나 Chrome에서는 노드가 잘 타는데 WSL2 안의 Ubuntu에서 curl로 IP 확인 사이트를 열어 보면 여전히 집 회선처럼 보이거나, sudo apt update가 특정 미러에만 닿지 못하고, git clone이 느리거나 끊기는 패턴을 말합니다. 검색어로는 Clash WSL2 프록시, WSL2 프록시 안 됨, Windows 서브시스템 프록시처럼 적는 경우가 많습니다.

이 증상은 대개 「구독이 망가졌다」보다 먼저, 리눅스 쪽이 애초에 Windows가 열어 둔 로컬 프록시 포트까지 트래픽을 보내고 있지 않다는 신호에 가깝습니다. 특히 WSL2는 가상 네트워크 네임스페이스를 쓰기 때문에, Windows에서 말하는 127.0.0.1:7890과 WSL2 안에서의 127.0.0.1이 서로 다른 대상을 가리키는 점을 놓치면 같은 설정을 반복해도 답이 나오지 않습니다. 이 글에서는 그 전제를 바로잡은 뒤, 호스트 프록시 브리지와 DNS 동기화를 같은 줄기에서 처리하는 순서를 적습니다.

왜 Windows 시스템 프록시만으로는 부족한가

Clash가 제공하는 「시스템 프록시」는 WinHTTP·일부 Microsoft 스택과, 시스템 설정을 읽는 브라우저 계열에는 잘 전달됩니다. 그러나 WSL2 안에서 돌아가는 GNU/Linux 바이너리는 Windows의 인터넷 설정 UI를 자동으로 상속하지 않습니다. 대신 http_proxy·https_proxy·all_proxy 같은 환경 변수나, 앱별 자체 설정을 따르는 경우가 많습니다.

또 한 가지, WSL2의 기본 게이트웨이는 보통 가상 스위치 뒤의 Windows 호스트 쪽 주소를 가리키며, 리눅스 루프백의 127.0.0.1은 Clash가 리슨하는 Windows 쪽 포트와 연결되지 않습니다. 최신 Windows 11에서는 .wslconfig의 mirrored networking 등으로 localhost 전달이 완화되는 경우도 있으나, 환경마다 다르므로 호스트 IP를 명시하는 방식이 여전히 재현성이 높습니다. Windows 쪽 브라우저만 이상할 때는 Windows 11 시스템 프록시 가이드를 먼저 보는 편이 좋고, 본문은 WSL2 전용 흐름에 집중합니다.

1단계: Clash에서 Allow LAN(또는 동등 옵션) 켜기

WSL2가 Windows 호스트의 IP와 포트로 붙으려면, Clash가 127.0.0.1에만 바인딩되어 있으면 가상 네트워크에서 들어오는 연결을 받지 못합니다. 클라이언트 설정에서 「Allow LAN」「허용 LAN」처럼 불리는 항목을 켜서, HTTP·mixed 포트가 모든 인터페이스(0.0.0.0)에서 리슨하도록 맞춥니다. 포트 번호는 본인 환경의 값(예: 7890)을 그대로 사용합니다.

같은 Wi‑Fi의 다른 기기와 공유하는 시나리오와 원리가 통합니다. 자세한 방화벽·바인드 설명은 LAN 프록시 공유 가이드를 참고하면, 인바운드 규칙을 어디에 열어야 하는지 그림이 잡힙니다. 요지는 Windows Defender 방화벽에서 해당 포트 TCP 인바운드를 허용하는 것입니다. WSL2에서 연결이 거절되면, 우선 방화벽 프로필(개인/공용)과 규칙이 실제로 적용됐는지부터 확인하세요.

2단계: WSL2에서 Windows 호스트 IP 확인

가장 단순한 방법은 기본 라우트의 게이트웨이를 읽는 것입니다. 많은 환경에서 이 값이 Windows 호스트를 향하는 WSL2 측 관문이 됩니다.

ip route show default | awk '{print $3}'

출력된 IPv4 주소를 메모해 두고, 아래 예시의 WIN_HOST 자리에 넣습니다. 일부 빌드에서는 /etc/resolv.conf 안의 nameserver가 호스트를 가리키기도 하지만, 최근에는 자동 생성 정책이 바뀌는 경우가 있어 라우트 기반 값을 우선하는 편이 안전합니다. 두 값이 다르면, 우선 라우트 값으로 curl 테스트를 해 보고 실패할 때만 다른 후보를 시험합니다.

ℹ️

참고: Windows 11의 최신 WSL에서는 .wslconfig에 networkingMode=mirrored를 켜 두면 로컬호스트 전달이 단순해지는 사례가 있습니다. 그래도 이 문서의 호스트 IP + 환경 변수 흐름은 그대로 유효한 백업 절차입니다.

3단계: `http_proxy`로 호스트 Clash에 붙이기

2단계에서 얻은 주소를 WIN_HOST, Clash의 HTTP(또는 mixed) 포트를 7890이라 가정합니다. 실제 포트는 클라이언트 화면의 값으로 바꿉니다.

export WIN_HOST="$(ip route show default | awk '{print $3}')"
export http_proxy="http://${WIN_HOST}:7890"
export https_proxy="$http_proxy"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"

SOCKS 포트를 쓰려면 예를 들어 all_proxy="socks5://${WIN_HOST}:7891" 형태를 추가합니다. 다만 apt 등은 HTTP 프록시 쪽이 다루기 쉬운 경우가 많아, 우선 HTTP 포트로 통일해 검증하는 것을 권장합니다. 여기까지가 전형적인 호스트 프록시 브리지 패턴입니다.

curl -sS https://api.ipify.org
echo

출력 IP가 Clash 노드 쪽과 일치하면, WSL2 안의 TCP 스택이 실제로 Windows 쪽 Clash를 경유하고 있다는 뜻입니다. 여전히 집 IP라면 (1) Allow LAN·바인드 (2) 방화벽 (3) 포트 번호 (4) 호스트 IP 후보를 다시 의심합니다.

4단계: DNS를 Clash 쪽과 맞추기

프록시는 타는데 특정 도메인만 이상하게 느리거나, 해석 결과가 Windows 브라우저와 다를 때는 WSL2 DNS가 따로 놀고 있을 수 있습니다. systemd-resolved를 쓰는 배포판에서는 /etc/resolv.conf가 심볼릭 링크인 경우가 많아, 무분별한 수동 편집은 업데이트 때 되돌아가기도 합니다. 우선 resolvectl status로 현재 DNS 스택을 확인하고, 회사망 정책을 해치지 않는 범위에서 조정합니다.

Clash 쪽에서 Fake-IP를 쓰는 구성이라면, WSL2 안의 애플리케이션이 보는 IP 대역과 Windows 쪽이 어긋나면서 「연결은 되는데 내용이 이상하다」 같은 증상이 나기도 합니다. 이때는 코어의 DNS 모드, redir-host 전환 여부, fallback 체인을 점검해야 합니다. 개념 정리는 Fake-IP·DNS 누출 방지 가이드를 함께 읽는 것이 좋습니다. WSL2 DNS 키워드로 검색해 들어온 경우에도, 프록시만 고치고 DNS를 그대로 두면 같은 벽에 다시 부딪히기 쉽습니다.

5단계: `apt`·`git` 실측

Debian·Ubuntu 계열에서 apt는 환경 변수의 프록시를 상속합니다. 위에서 http_proxy를 보낸 동일 셸에서 다음을 실행해 봅니다.

sudo -E apt update

-E는 현재 사용자의 환경 변수를 유지해 sudo 자식 프로세스까지 전달합니다. 이것을 빼면 프록시가 빠져 apt만 또 직행하는 것처럼 보일 수 있습니다. 정책상 sudo -E를 쓰기 어렵다면, /etc/apt/apt.conf.d/ 아래에 Acquire::http::Proxy 지시를 두는 방식도 있습니다.

git은 HTTPS 원격이면 대체로 위 프록시 변수를 따릅니다. SSH 원격([email protected]:...)은 별도의 ProxyCommand가 필요할 수 있어, 본문 범위를 넘어섭니다. 우선 git ls-remote https://...처럼 HTTPS로 빠른 확인을 해 보세요.

6단계: 셸·`systemd`로 영구화

매번 수동으로 export하기 번거롭다면, ~/.bashrc 또는 ~/.zshrc 끝에 함수를 두고 필요할 때만 켜는 방식이 안전합니다. Clash를 항상 켜 두지 않는 PC라면, 로그인할 때마다 자동으로 프록시를 붙잡아 두었다가 실패하는 스크립트를 넣기보다 토글 함수를 권장합니다.

wsl_proxy_on() {
  export WIN_HOST="$(ip route show default | awk '{print $3}')"
  export http_proxy="http://${WIN_HOST}:7890"
  export https_proxy="$http_proxy"
  export HTTP_PROXY="$http_proxy"
  export HTTPS_PROXY="$https_proxy"
  echo "WSL proxy on -> ${http_proxy}"
}
wsl_proxy_off() {
  unset WIN_HOST http_proxy https_proxy HTTP_PROXY HTTPS_PROXY all_proxy ALL_PROXY
  echo "WSL proxy off"
}

systemd 사용자 유닛을 쓰는 경우, environment.d에 동일한 변수를 넣으면 로그인 세션 전체에 퍼질 수 있습니다. 다만 WIN_HOST는 부팅 직후에도 유효한지 검증해야 하므로, 셸 함수 방식이 유지 보수에는 더 단순한 경우가 많습니다. Windows 서브시스템 프록시 검색으로 이 페이지를 찾은 분도, 위 스니펫만 저장해 두었다가 단계적으로 확장하면 됩니다.

7단계: 그래도 빠져나간다면 TUN·규칙

환경 변수를 맞춰도 특정 바이너리만 프록시를 무시한다면, 그 프로그램이 자체 프록시 설정을 갖고 있거나, Clash 규칙에서 해당 트래픽이 DIRECT로 매칭되는지를 봐야 합니다. 브라우저와 무관하게 커널 레벨에서 모으고 싶다면 Windows 호스트 쪽 TUN 모드를 검토할 수 있으나, 권한·다른 VPN과의 충돌을 읽고 켜는 것이 안전합니다.

Clash 설치와 구독 반영이 아직이라면 설치·기본 설정 문서에서 프로필을 먼저 안정화한 뒤, 본문의 WSL2 단계로 넘어오는 편이 디버깅 비용이 적습니다.

⚠️

주의: 사내 보안 정책으로 SSL 검사·맞춤 신뢰 저장소가 있는 환경에서는, 프록시를 타도 apt·curl이 인증서 오류로 멈출 수 있습니다. 그때는 IT 가이드를 벗어나지 않는 범위에서 대응해야 합니다.

한눈에 보는 점검 순서

Clash에서 HTTP·mixed 포트와 Allow LAN을 확인한다.
Windows 방화벽에서 해당 포트 인바운드를 허용한다.
WSL2에서 ip route show default로 호스트 후보 IP를 얻는다.
http_proxy·https_proxy를 http://호스트IP:포트로보낸다.
curl로 출구 IP를 확인하고, sudo -E apt update·git로 확장한다.
이상 징후가 남으면 DNS·Fake-IP·규칙 로그를 함께 본다.

✅

팁: 문제를 기록할 때 「Windows 브라우저 출구 IP」「WSL2 curl 출구 IP」「echo $http_proxy 출력」을 한 줄로 적어 두면, 이후 규칙을 손볼 때 비교가 빨라집니다.

맺음말

Clash WSL2 프록시 이슈는, 구독 품질 이전에 「WSL2가 Windows의 127.0.0.1과 같은 주소를 공유하고 있지 않다」는 전제를 바로잡는 것이 첫 단추입니다. 호스트 프록시 브리지로 호스트 IP와 포트를 명시하고, WSL2 DNS를 Clash의 Fake-IP·fallback 설계와 함께 보면, curl·apt·git이 동시에 안정하는 경우가 많습니다. Clash 계열 클라이언트는 포트·LAN 허용·코어 로그를 한 화면에서 다루기 쉬워, 위 순서를 반복 실험하기에도 편합니다.

Windows 쪽 클라이언트를 최신 상태로 유지하고 설치 패키지를 내려받을 때는, 릴리스 페이지만이 아니라 Clash 공식 다운로드 페이지를 기준으로 삼는 편이 안전합니다. → Clash를 무료로 내려받아 Windows와 WSL2를 같은 절차로 점검해 보세요.