2026 WSL2에서 Git·npm이 프록시를 안 탈 때: Windows Clash와 localhost·DNS까지 맞추는 실무 순서

① 왜 WSL2의 localhost가 Windows Clash와 다를까

WSL2는 가벼운 가상화 네트워크를 쓰기 때문에, 리눅스 안의 127.0.0.1은 「WSL 자기 자신」을 가리킵니다. Windows에서 돌아가는 Clash(또는 Clash Verge 등)가 127.0.0.1:7890 같은 주소로 리슨하고 있어도, WSL 안에서 같은 주소를 열면 호스트의 프록시가 아니라 빈 포트를 두드리는 셈이 됩니다. 그래서 Windows 쪽에선 시스템 프록시만 켜도 잘 되는데, WSL 터미널만 예외로 실패하는 패턴이 반복됩니다.

최신 Windows에서는 WSL 네트워킹 모드(예: mirrored 등)에 따라 localhost 전달이 달라질 수 있습니다. 그래도 처음 설정할 때는 「WSL이 Windows를 어떤 IP로 보는지」를 숫자로 확인하고, 그 주소에 Clash의 HTTP 또는 SOCKS 포트를 붙이는 방식이 가장 재현성이 높습니다. Windows 11에서 Clash를 처음 깔았다면 Windows 11 Clash Verge 첫 설정에서 시스템 프록시·TUN 차이를 먼저 맞춰 두는 편이 이후 WSL 작업이 수월합니다.

② 흔한 증상: Git·npm만 프록시를 “모른 척”한다

아래 증상이 겹치면 이 글의 순서를 적용할 가치가 큽니다.

• Git: git clone https://github.com/...가 타임아웃·연결 거절, 또는 특정 지역에서만 느림
• npm·yarn·pnpm: 레지스트리·tarball 다운로드가 중간에 끊기거나 DNS 오류
• 브라우저는 정상인데 WSL 터미널만 이상함(같은 노드를 써도 경로가 다름)
• curl https://api.github.com는 되는데 패키지 매니저만 실패(프록시 환경 변수와 도구별 설정이 엇갈린 경우)

반대로, GitHub·npm 레지스트리를 규칙으로만 골라 보내고 싶다면 Clash 분류로 GitHub·개발 트래픽만 노드로 보내는 글과 이 글을 짝지으면 「Windows 쪽 규칙」과 「WSL에서 프록시 주소」를 동시에 정리하기 좋습니다.

③ 1단계: Windows에서 Clash가 실제로 열어 둔 포트 확인

대부분의 프로필은 mixed-port 또는 port·socks-port 조합으로 로컬 프록시를 띄웁니다. 숫자는 설치본·프로필마다 다르므로, Clash 클라이언트 화면이나 YAML에서 HTTP·SOCKS가 각각 몇 번인지 먼저 적어 둡니다. 예시로 자주 보이는 값을 들면 HTTP 7890, SOCKS 7891 정도이지만, 본인 환경의 값을 그대로 써야 합니다.

WSL에서 Windows 프록시로 붙을 때는 보통 HTTP 프록시가 설정이 단순합니다. Git의 HTTPS는 HTTP CONNECT를 타는 경우가 많아, SOCKS만 열려 있으면 도구별로 추가 옵션이 필요할 수 있습니다. 또한 Clash 쪽에서 Allow LAN(로컬망 허용)이 꺼져 있으면, WSL 가상 NIC에서 오는 연결이 거절될 수 있습니다. 같은 Wi-Fi의 휴대폰과 PC를 묶는 시나리오는 LAN 프록시·방화벽 글과 맥락이 비슷하니, 방화벽 규칙을 건드릴 때 참고하면 됩니다.

④ 2단계: WSL2에서 “Windows 호스트” IP 얻기

클래식한 NAT형 WSL2에서는, 리눅스가 Windows를 향하는 기본 게이트웨이 IP를 쓰는 방법이 널리 쓰입니다. 터미널에서 아래를 실행해 게이트웨이 주소를 확인합니다.

# Show default route gateway (often the Windows host from WSL2)
ip route show | grep -m1 default

또는 배포판·WSL 버전에 따라 /etc/resolv.conf의 nameserver 줄이 Windows 쪽을 가리키는 경우가 있습니다. 다만 최근 빌드에서는 resolv.conf 생성 방식이 바뀌기도 하므로, 게이트웨이 IP를 우선 삼고 resolv는 DNS 절에서 별도로 다루는 편이 안전합니다.

Windows 11·WSL 최신 채널에서는 네트워크 모드에 따라 localhost 공유가 개선될 수 있습니다. 그래도 팀·회사 PC처럼 버전이 고정된 환경에서는, 위에서 얻은 숫자 IP에 Clash 포트를 붙이는 방식이 여전히 가장 트러블이 적습니다. 예를 들어 게이트웨이가 172.28.80.1이고 HTTP 프록시가 7890이면, WSL에서는 http://172.28.80.1:7890 형태로 접근합니다(실제 값으로 바꿔야 함).

⑤ 3단계: Git에 프록시 지정하기

저장소 전체에 동일 정책을 쓸 거라면 전역 설정이 편합니다. 앞 단계에서 확인한 호스트 IP와 포트를 넣습니다.

# Replace HOST and PORT with your Windows Clash HTTP proxy listen address
git config --global http.proxy http://HOST:PORT
git config --global https.proxy http://HOST:PORT

특정 도메인만 프록시를 태우고 싶다면 http.https://github.com.proxy처럼 URL 단위 설정을 쓸 수도 있습니다. 반대로 사내 GitLab은 직접 연결이 맞을 수 있으니, 프록시가 필요한 호스트만 좁히는 편이 속도와 정책 모두에 유리합니다.

설정이 먹었는지는 git config --global --get http.proxy로 확인하고, git clone 한 번으로 검증합니다. 여전히 SSL 관련 오류가 난다면 프록시 문제가 아니라 사내 MITM·루트 인증서 쪽을 의심해야 합니다.

⑥ 4단계: npm·yarn·pnpm 프록시와 레지스트리

npm은 자체 설정 키가 있으므로, 셸 환경 변수만으로 끝내지 말고 클라이언트 설정을 맞추는 것이 좋습니다.

# npm: use the same Windows Clash HTTP proxy URL
npm config set proxy http://HOST:PORT
npm config set https-proxy http://HOST:PORT

yarn(Classic)·pnpm도 각각 yarn config set proxy, pnpm config set proxy 패턴으로 동일한 URL을 넣을 수 있습니다. 모노레포·CI 스크립트에서는 HTTP_PROXY·HTTPS_PROXY를 export하는 방식이 편하지만, 로컬 개발자 PC에서는 도구별 설정이 우선하는 경우가 있어 둘 다 맞추거나 실패 시 어느 쪽이 이겼는지 확인해야 합니다.

레지스트리를 registry.npmjs.org가 아닌 미러로 바꿔 쓰는 팀이라면, 미러 주소가 국내·사내망으로 바로 가는지도 함께 봅니다. 불필요하게 해외 구간만 프록시로 돌리면 지연이 줄지 않을 수 있습니다.

⑦ 5단계: DNS 불일치·resolv.conf·Clash DNS 블록

연결이 아니라 이름 해석에서만 깨질 때는 DNS 경로를 의심합니다. WSL은 기본적으로 Windows가 넘겨 준 DNS를 쓰지만, 브라우저 DoH·Clash의 fake-ip·코어의 dns 블록이 동시에 개입하면 「어느 응답을 믿었는지」가 어긋날 수 있습니다.

점검 순서는 다음과 같이 잡을 수 있습니다.

1. WSL에서 dig 또는 getent hosts github.com으로 해석 결과가 기대와 같은지 본다.
2. Windows 쪽에서 같은 이름을 해석했을 때와 IP가 다른지 비교한다.
3. Clash 로그에서 해당 요청이 어떤 규칙·DNS 경로를 탔는지 확인한다.

fake-ip 프로필을 쓰는 경우 애플리케이션이 보는 주소와 실제 아웃바운드가 다르게 느껴질 수 있습니다. TUN·DNS를 한꺼번에 손댈 때는 TUN 모드·DNS 심화 글의 체크 순서를 같이 보는 것이 시간을 아낍니다.

⑧ TUN·시스템 프록시: WSL 경계에서 기대할 수 있는 것

시스템 프록시는 프록시를 존중하는 앱에만 전달됩니다. TUN은 가상 NIC 쪽으로 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있지만, WSL 패킷이 어디까지 OS 커널 경로를 타는지에 따라 체감이 갈립니다. “Windows에선 TUN이 켜져 있는데 WSL 터미널만 예외” 같은 상황은 흔하므로, 결국 WSL 안의 Git·npm에는 명시적 프록시 URL을 주는 방식이 가장 직설적입니다.

회사 PC에서 사내 VPN·Zero Trust 에이전트와 겹치면 라우팅 충돌이 날 수 있습니다. 이때는 IT 정책을 우선하고, 분할 터널 옵션과 Clash 규칙을 동시에 조정해야 합니다.

⑨ 혼합 네트워크·방화벽·버전 고정 환경 체크리스트

마지막으로 현장에서 자주 걸리는 항목만 모았습니다.

• Windows Defender 방화벽: Clash 프로세스·포트에 대한 인바운드 허용 여부
• 보안/백신: 로컬 프록시 포트를 루프백이 아닌 주소로 필터링하는 경우
• IPv6: 한쪽만 IPv6로 해석됐다가 특정 구간에서 막히는 경우
• 프로필 업데이트: mixed-port가 바뀌었는데 WSL 셸 설정이 옛날 값을 물고 있는 경우

전역 터널형 VPN과 규칙형 Clash의 선택 기준은 Clash와 VPN의 차이에서 정리한 대로, 호스트·앱 단위 정책이 필요하면 후자가 유리한 경우가 많습니다.

⑩ 정리: WSL2 개발은 “주소를 숫자로 고정”하는 것부터

WSL2에서 Git·npm이 Windows의 Clash를 안 탄다고 느낄 때, 첫 질문은 「127.0.0.1이 진짜로 같은 프록시를 가리키느냐」입니다. 대답이 아니라면 호스트 IP + Clash HTTP 포트를 Git·패키지 매니저에 명시하고, 그다음에 DNS·방화벽·혼합 네트워크를 순서대로 줄여 가면 됩니다. 브라우저만 되고 터미널만 안 되는 현상은 대부분 이 경로에서 해결됩니다.

클라이언트 설치와 버전 안내는 릴리스 페이지만 쫓기보다 Clash 입문 튜토리얼과 사이트 다운로드 페이지를 함께 보는 편이 덜 헷갈립니다. Windows에서 규칙을 안정적으로 돌린 뒤 WSL 쪽 주소만 맞추면, 개발용 해외 호스트도 훨씬 예측 가능해집니다. → Clash를 무료로 내려받고, WSL2와 Windows를 같은 프록시 정책으로 맞춰 보세요.