WSL2에서 Git·npm이 Clash를 타지 않을 때: Windows 호스트와 프록시 포트 연결 (2026)

왜 WSL2는 Windows 프록시를 “자동으로” 안 탈까

WSL2는 경량 가상화 환경에 가깝고, 네트워크 스택도 Windows 데스크톱과 완전히 동일하지 않습니다. 브라우저처럼 WinINET 시스템 프록시를 읽는 경로가 없기 때문에, 호스트에서 Clash의 시스템 프록시 토글을 켜도 서브시스템 안의 터미널 프로세스는 그 사실을 모릅니다. 그 결과 curl·Git·npm·파이썬 패키지 매니저 등이 각자 HTTP_PROXY 같은 힌트가 없으면 공인망으로 직접 나가려 하고, 방화벽·회선·지역 제한에 걸려 실패하는 패턴이 자주 보고됩니다.

두 번째 함정은 localhost의 의미입니다. Windows에서 127.0.0.1:7890이 Clash를 가리킬 때, WSL 배시에서 같은 주소를 치면 WSL 내부의 7890 포트를 두드리게 됩니다. 호스트의 프록시 데몬과는 다른 머신이므로, 문서에 나온 “로컬 프록시 주소”를 그대로 복사하면 안 되는 이유가 여기에 있습니다. 해결의 핵심은 Windows 호스트 쪽 IP(게이트웨이 역할)와 실제로 열려 있는 프록시 포트를 짝지어 주는 것입니다.

UWP·Loopback 이슈와는 다른 문제인지 가르기

Microsoft Store·UWP가 localhost 프록시를 거부하는 현상은 Loopback 격리와 가깝습니다. 반면 본 글의 증상은 “리눅스 셸에서 호스트 서비스에 어떻게 붙을지”에 가깝습니다. 증상 문장이 비슷해 보여도, WSL에서는 CheckNetIsolation보다 호스트 IP·포트·방화벽을 먼저 맞추는 편이 낫습니다. Windows 쪽 기본 설치가 아직이라면 Clash Verge Rev 설치 가이드로 포트 번호와 시스템 프록시 동작을 먼저 확인한 뒤 이어가면 실수가 줄어듭니다.

1Windows 호스트 IP 확인하기

전통적으로는 WSL 안에서 /etc/resolv.conf의 nameserver 항목이 가리키는 주소가 Windows 호스트를 의미하는 경우가 많았습니다. 최신 빌드에서는 네트워킹 모드(mirrored 등)에 따라 문서화된 방법이 달라질 수 있으므로, 한 번 확인한 값을 메모해 두고 방화벽 규칙과 함께 관리하는 습관이 좋습니다. 아래는 흔히 쓰이는 확인 예시입니다.

# Show default resolver (often Windows host in classic WSL2 setups)
grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}'

다른 터미널에서 ip route show default로 기본 게이트웨이를 보는 방법도 있습니다. 조직망·VPN·하이퍼바이저 조합에 따라 숫자가 바뀔 수 있으니, 재부팅 후에도 동일한지 가끔 점검하세요. 호스트 IP가 바뀌면 셸 프로파일에 박아 둔 프록시 줄도 함께 갱신해야 합니다.

2Clash에서 LAN(외부 인터페이스) 바인딩 허용

WSL에서 호스트 IP로 붙는 트래픽은 Windows 입장에서 다른 인터페이스에서 들어온 연결과 비슷하게 취급될 수 있습니다. 그래서 Clash 코어·GUI에 Allow LAN(또는 동등한 “로컬 네트워크에서 수신”) 옵션이 있다면 켜 두는 것이 안전합니다. 끄면 connection refused나 즉시 끊김이 나면서 “IP는 맞는데 왜 안 되지”하는 상황이 됩니다. 혼합 포트(mixed-port)를 쓰는지, HTTP와 SOCKS를 나누는지에 따라 주소 형식이 달라지므로, 클라이언트 설정 화면에 표시된 실제 리스닝 포트를 기준으로 하세요.

3환경 변수: http_proxy·https_proxy·ALL_PROXY

대부분의 CLI 도구는 대문자 또는 소문자 이름의 프록시 환경 변수를 읽습니다. 호스트 IP를 WIN_HOST에 넣었다고 가정하고, HTTP 프록시가 7890이라면 예시는 다음과 같습니다. 포트는 본인 환경에 맞게 바꿉니다.

# Example — replace WIN_HOST and port with your values
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 ALL_PROXY="socks5://${WIN_HOST}:7891"

ALL_PROXY에 SOCKS를 쓸지, 전부 HTTP로 통일할지는 클라이언트가 열어 준 프로토콜에 따릅니다. 회사에서 HTTP_PROXY만 허용하는 경우도 있으니 정책을 확인하세요. 영구 적용은 ~/.bashrc·~/.zshrc 또는 /etc/profile.d/ 스크립트에 같은 블록을 넣으면 됩니다. 다만 앞서 말했듯 호스트 IP가 변하면 스크립트를 매 세션에서 다시 계산하거나, 수동으로 고정 IP를 쓰는 전략을 택해야 합니다.

4Git: http.proxy·https.proxy와 주의점

Git은 환경 변수만으로도 동작하는 경우가 많지만, 저장소마다 다르게 두고 싶다면 git config --global http.proxy 형태가 명확합니다. 값은 http://호스트:포트 식으로 맞추고, SSH 원격([email protected])은 이 설정과 무관하다는 점을 잊지 마세요. SSH 경로까지 우회하려면 ~/.ssh/config의 ProxyCommand 등 별도 논의가 필요합니다.

# Example — global Git HTTP proxy (HTTPS remotes use http.proxy for CONNECT)
git config --global http.proxy  "http://WIN_HOST:7890"
git config --global https.proxy "http://WIN_HOST:7890"

내부망 전용 저장소와 공개 저장소를 섞어 쓰면 insteadOf나 조건부 설정이 필요해질 수 있습니다. 프록시를 끄고 싶을 때는 --unset으로 깔끔히 제거하는 습관을 들이면 디버깅이 쉬워집니다.

5npm: proxy·registry·strict-ssl

npm은 자체 설정 키로 proxy·https-proxy를 갖고 있어, CI 스크립트와 분리해 두기 좋습니다. 레지스트리를 국내 미러로 바꾼 상태에서도 원본 registry.npmjs.org로 나가야 하는 패키지가 있으면, 미러와 프록시 조합이 꼬여 이상 증상이 날 수 있습니다. Cursor·GitHub·npm 분류 글에서 다루는 것처럼 규칙·DNS를 호스트(Windows) 쪽 Clash에서 먼저 안정화해 두면 WSL에서도 같은 출구 품질을 기대하기 쉽습니다.

# Example — npm client proxy (replace host:port)
npm config set proxy http://WIN_HOST:7890
npm config set https-proxy http://WIN_HOST:7890

회사 방화벽이 TLS 검사를 하면 strict-ssl 관련 오류가 날 수 있는데, 보안과의 트레이드오프를 이해한 뒤에만 완화 설정을 검토해야 합니다. 문제가 프록시 연결 자체인지, 레지스트리 응답인지는 npm ping·curl -I로 단계별로 나누어 보세요.

6Windows 방화벽·보안 소프트웨어

설정을 모두 맞춰도 연결이 안 되면 Windows Defender 방화벽이나 제3자 보안 제품이 Clash 프로세스의 수신을 막는 경우를 의심합니다. 개인 PC라면 테스트용으로 인바운드 규칙을 잠시 완화해 재현 여부를 보고, 가능하면 포트 단위로 최소 권한만 열어 두는 편이 좋습니다. 회사 PC에서는 보안팀 승인 없이 방화벽을 건드리지 마세요.

WSL 네트워킹 모드(mirrored 등)를 쓸 때

Microsoft는 WSL의 네트워킹 옵션을 확장해 왔고, .wslconfig로 mirrored 모드를 켜면 localhost 의미가 과거와 달라질 수 있습니다. 문서를 따라 모드를 바꾼 뒤에는 이 글의 “호스트 IP” 단계를 해당 버전 안내에 맞게 다시 확인하세요. 모드별로 프록시 설정 난이도가 달라질 수 있으므로, 팀 내에서는 한 가지 조합을 표준으로 정해 두면 재현성이 좋아집니다.

대안: Windows 쪽 TUN으로 터미널까지 한 번에

호스트 IP를 매번 신경 쓰기 싫다면, Windows에서 TUN 모드로 트래픽 캡처 범위를 넓혀 WSL 유입·유출을 함께 다루는 구성을 검토할 수 있습니다. 드라이버·권한 요구가 있으므로 Clash Verge Rev TUN 모드 가이드의 전제 조건을 읽고, 회사 정책과 충돌하지 않는지 확인하세요. TUN이 활성화되어도 일부 툴은 여전히 환경 변수를 요구할 수 있어, “한 방에 끝”보다는 검증을 권합니다.

검증 순서 요약

1. WSL에서 호스트 IP와 Windows에서 Clash 프록시 포트를 다시 적어 둔다.
2. curl -I --proxy http://호스트:포트 https://www.example.com 등으로 터널 자체를 본다.
3. 같은 값으로 Git·npm을 시험하고, 로그에서 의도한 노드·규칙이 보이는지 본다.
4. 실패 시 방화벽·Allow LAN·IP 변동을 역순으로 의심한다.

문서 허브와 함께 보기

용어와 설정 키를 한곳에 모아 두면 이후 장애 대응이 빨라집니다. Clash 문서·설정 허브를 북마크해 두고, 본 글의 순서와 병행하면 WSL2·Windows·Clash를 같은 그림으로 유지하기 쉽습니다.

마치며

WSL2 개발 환경에서 Git과 npm이 Windows의 Clash를 타지 않는 문제는, 대개 시스템 프록시 미전파와 localhost 의미 차이 두 축으로 설명됩니다. 호스트 IP와 프록시 포트를 정확히 짝지우고, LAN 허용과 방화벽까지 확인하면 재현성 높은 해결책을 얻을 수 있습니다. 규칙·DNS 쪽은 Windows 클라이언트에서 먼저 안정화하는 편이 전체 파이프라인에 유리합니다.

여러 클라이언트를 겹치기보다 한 프로필에 정리하고, 같은 검증 루틴으로 브라우저와 WSL 셸을 함께 두면 이후에도 대응이 빨라집니다. 설치 패키지는 릴리스 직링크보다 사이트의 다운로드 허브를 기준으로 삼는 편이 플랫폼별 혼선이 적습니다. 오픈소스 저장소는 라이선스·이슈 확인용으로 두고, 아래 링크에서 동일한 Meta 계열 경험을 이어 가 보세요.

→ Clash를 무료로 다운로드하고, Windows와 WSL2를 한 프록시 파이프라인으로 맞춰 보세요