1 왜 WSL2만 따로 설정해야 하나
WSL2는 경량 가상 머신 위에 Linux 커널이 올라가고, Windows와는 NAT로 연결된 별도 주소 공간을 씁니다. 그래서 Windows에서 시스템 프록시나 브라우저 확장으로 잘 나가도, WSL 안의 apt·git·curl은 그 설정을 «그대로» 물려받지 않는 경우가 많습니다. 사용자 입장에서는 «같은 PC인데 왜 터미널만 다르지?»로 느껴지지만, 사실 두 개의 네트워크 스택을 동시에 다루는 상황에 가깝습니다.
Clash가 Windows에서 127.0.0.1의 mixed·HTTP 포트로 수신 중이면, WSL 쪽에서는 그 주소가 «자기 자신»이 아니라서 붙을 수 없습니다. 대신 Windows 호스트의 LAN 쪽 IP(WSL 기본 게이트웨이로 잡히는 주소)로 프록시를 지정해야 합니다. 이 한 줄이 빠지면 규칙을 아무리 손봐도 WSL 트래픽은 Clash 로그에 잡히지 않습니다.
Windows 쪽 클라이언트 설치가 아직이라면 Windows 설치 가이드로 먼저 mixed 포트와 시스템 프록시 동작을 맞춘 뒤, 아래 단계를 적용하는 것을 권장합니다.
2 Clash 쪽에서 먼저 맞출 것
WSL에서 호스트 IP로 붙으려면 Clash가 그 IP에서도 수신해야 합니다. Allow LAN·바인드 주소·방화벽 예외처럼 «로컬 루프백이 아닌 인터페이스에서 mixed/HTTP가 열려 있는지»를 확인하세요. Mixed 포트 번호(예: 7890)는 메모해 두었다가 뒤에서 그대로 씁니다.
TUN 모드만 쓰고 시스템 프록시는 끈 구성이라면, Windows 쪽에서 어떤 경로로 패킷이 나가는지가 달라질 수 있습니다. WSL에서의 목표는 «호스트의 HTTP 프록시 포트로 명시적으로 보내기»이므로, 우선 mixed/HTTP 포트가 LAN에서 접근 가능한지를 기준으로 잡는 편이 디버깅에 유리합니다. TUN 전반은 TUN 가이드와 함께 참고하면 흐름이 잘 맞습니다.
3 WSL2에서 Windows 호스트 IP 구하기
가장 흔한 방법은 기본 라우트의 게이트웨이를 보는 것입니다. Ubuntu 셸에서 다음과 같이 실행하면, 그 값이 곧 Windows 호스트를 향하는 주소인 경우가 많습니다.
ip route show | grep -m1 default | awk '{ print $3 }'
또 다른 방법으로 cat /etc/resolv.conf의 nameserver 한 줄을 볼 수 있습니다. WSL2가 자동 생성하는 설정에서는 이 주소가 호스트 쪽 DNS 프록시와 맞물리기도 하므로, «호스트 IP 후보»로 같이 적어 두고 ping이나 curl로 응답을 확인합니다. 다만 DNS 전용으로 쓰는 주소와 HTTP 프록시 목적지가 항상 동일하다고 단정할 수는 없어, 기본 게이트웨이를 우선 기준으로 삼는 편이 안전합니다.
호스트 IP는 재부팅·네트워크 전환 후에 바뀔 수 있으므로, 스크립트로 매 세션 읽어서 http_proxy에 넣거나, 변하지 않는 구성을 원하면 Windows 쪽 고정 IP·wsl.conf 등을 검토합니다.
4 환경 변수와 셸 프로파일
터미널 도구 대부분은 http_proxy·https_proxy·필요 시 all_proxy를 읽습니다. 호스트 IP를 HOST_IP로 두고 포트를 7890이라고 가정하면 예시는 다음과 같습니다.
export HOST_IP=$(ip route show | grep -m1 default | awk '{ print $3 }')
export http_proxy="http://${HOST_IP}:7890"
export https_proxy="http://${HOST_IP}:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
no_proxy에는 localhost,127.0.0.1,::1과 사내망 대역을 넣어 두면, 로컬 서비스나 내부 레지스트리까지 불필요하게 프록시로 보내는 일을 줄일 수 있습니다. 위 내용을 ~/.bashrc나 ~/.zshrc에 넣되, 회사 정책상 프록시가 항상 필요하지 않다면 별도 파일로 빼서 source하는 방식이 관리하기 쉽습니다.
한 번 설정한 뒤에는 curl -I https://www.google.com 같은 명령으로 응답 헤더가 오는지, Clash 로그에 해당 요청이 찍히는지 함께 확인하면 «환경 변수가 실제로 먹었는지»를 빠르게 가릅니다.
5 apt 전용 프록시(APT::Acquire)
apt는 sudo로 돌아가며, 일부 환경에서는 일반 사용자의 http_proxy가 비어 있는 채로 실행되기도 합니다. 그래서 APT 설정 파일에 직접 적어 두는 방식이 안정적입니다. /etc/apt/apt.conf.d/95clash-proxy 같은 새 파일을 만들고(관리자 권한), 내용은 다음과 같이 맞춥니다.
Acquire::http::Proxy "http://<HOST_IP>:7890/";
Acquire::https::Proxy "http://<HOST_IP>:7890/";
여기서 <HOST_IP>는 앞에서 구한 Windows 호스트 주소로 바꿉니다. HTTPS 저장소를 쓰는 경우에도 apt는 환경에 따라 위 Acquire::https::Proxy를 참조합니다. 프록시를 끄고 싶을 때는 해당 파일을 삭제하거나 주석 처리한 뒤 sudo apt update를 다시 시도합니다.
/etc/apt/sources.list를 국내 미러로 바꿔 두었다면, «미러 서버 자체는 국내인데도 느리다»는 증상은 DNS나 상위 회선 문제일 수 있습니다. 이때는 DNS·Fake-IP 관련 글과 Clash 쪽 DNS 설정을 같이 보는 것이 좋습니다.
6 Git·curl 검증
Git은 저장소마다 프록시가 다를 수 있어 git config --global http.proxy·https.proxy에 호스트 IP 형태의 URL을 넣거나, 위에서 설정한 환경 변수를 따르도록 둘 수 있습니다. 회사망에서는 git@ SSH만 열려 있는 경우도 있어, 프록시를 넣어도 clone이 실패하면 SSH 포트(22) 경로와 HTTPS 경로를 나누어 점검해야 합니다.
curl·wget은 환경 변수를 잘 따르는 편이라, 프록시가 적용됐는지 확인하는 데 적합합니다. 반면 일부 언어 런타임의 패키지 매니저는 별도 설정 파일을 쓰므로, Node·Python·Rust 등을 WSL에서 쓸 때는 각 도구 문서의 프록시 항목을 추가로 확인합니다.
7 resolv.conf와 DNS
WSL2는 부팅 시 /etc/resolv.conf를 자동 생성하는 경우가 많고, 상단에 nameserver가 Windows 쪽으로 향합니다. Clash에서 DNS를 가로채거나 Fake-IP를 쓰는 구성이라면, «이름은 붙는데 TCP 연결이 이상하다»는 식의 증상이 나올 수 있어 DNS 모드와 규칙 순서를 Windows 쪽 Clash 설정에서 먼저 맞추는 것이 좋습니다.
자동 생성이 방해된다고 느끼면 /etc/wsl.conf에서 [network] 아래 generateResolvConf = false를 설정한 뒤, 수동으로 resolv.conf를 관리하는 방법도 있습니다. 이 경우 잘못 고정하면 이름 해석이 전부 실패하므로, 신뢰할 nameserver와 회사 정책을 확인하고 적용하세요. 변경 후에는 WSL을 완전히 종료했다가(wsl --shutdown) 다시 올리는 것이 안전합니다.
resolv.conf만 손대고 프록시·방화벽은 그대로면 증상이 바뀌지 않을 수 있습니다. DNS는 «이름을 IP로 바꾸는 단계»이고, 실제 출구는 여전히 Clash 규칙과 호스트 연결 가능 여부에 달려 있습니다.
8 미러 네트워킹(Mirrored mode) 알아두기
Windows 11의 최신 빌드에서는 WSL용 미러 네트워킹 옵션을 켜서, 호스트와 WSL이 네트워크 관점에서 더 잘 맞물리게 할 수 있습니다. 기능 이름과 정확한 동작은 Windows 버전에 따라 문서를 확인해야 하며, 켠 뒤에는 앞서 쓰던 «호스트 IP 추정」방법이 달라질 수 있으므로 ip route와 resolv.conf를 다시 읽는 습관이 필요합니다.
미러 모드를 쓰지 않는 환경에서도, 본문에서 설명한 게이트웨이 IP + HTTP 프록시 포트 패턴은 대부분 동작합니다. 반대로 미러 모드를 켰다고 해서 apt·Git 설정을 전부 생략할 수 있는 것은 아니므로, «기능을 켰다」와 «프록시 주소를 안다»는 별개의 체크로 두는 것이 혼란을 줄입니다.
9 자주 보는 증상과 순서
- Windows 브라우저는 되는데 WSL
curl만 실패 → 호스트 IP·포트·LAN 허용부터 확인 apt update만 실패 →Acquire::http::Proxy와 sudo 환경의 프록시 유무- 이름 해석은 되는데 특정 도메인만 실패 → Clash DNS·규칙·TUN과의 관계 점검
- IP가 자주 바뀜 → 셸에서 매번 게이트웨이 읽기 또는 고정 IP 검토
증상을 섞어서 해석하면 시간이 길어지므로, HTTP 프록시 연결 가능 여부 → apt 전용 설정 → DNS 순으로 좁히는 것을 권장합니다. Linux 네이티브에 가까운 systemd 환경은 Linux Mihomo 가이드와 비교해 보면 개념이 연결됩니다.
Acquire로 따로 박아 두면 재현성이 좋아집니다.
10 정리
WSL2의 Ubuntu에서 Windows의 Clash를 쓰려면, 브라우저와 달리 127.0.0.1이 아닌 호스트 IP로 HTTP 프록시를 지정해야 한다는 점이 핵심입니다. 환경 변수로 터미널 도구를 맞추고, apt는 /etc/apt/apt.conf.d/에 Acquire::http::Proxy를 적어 두면 sudo apt update가 안정적으로 같은 경로를 탑니다. resolv.conf·DNS는 이름 해석 단계의 문제인지, 아니면 프록시·방화벽 문제인지 나누어 보면 디버깅이 빨라집니다. 미러 네트워킹은 주소 체계에 변화를 줄 수 있으니, 적용 후에는 라우트와 DNS를 다시 확인하세요.
Windows용 클라이언트는 규칙·로그·DNS를 한 화면에서 다루기 쉬운 편이라, WSL과 병행하는 개발 환경에서도 같은 스택을 유지하기 좋습니다. 설치 패키지는 공식 다운로드 페이지를 우선하는 것을 권장합니다.
