WSL2에서 127.0.0.1이 Clash를 못 찾는 이유

WSL2는 경량 VM에 가까운 별도 네트워크 스택을 씁니다. 그래서 WSL 안의 127.0.0.1그 Linux 인스턴스의 루프백이지, Windows 데스크톱에서 돌아가는 Clash 프로세스가 듣는 주소가 아닙니다. Windows에서 127.0.0.1:7890으로 잘 붙어도, WSL 터미널에 같은 주소를 넣으면 아무 것도 안 듣는 포트로 가거나 바로 거절될 수 있습니다.

해결의 첫 단계는 항상 같습니다: WSL이 Windows 호스트를 바라볼 때 쓰는 IP를 구한 뒤, http://그IP:포트 / socks5h://그IP:포트 형태로 환경 변수를 맞춥니다. Docker 터미널에서 host.docker.internal을 쓰는 것과 같은 “관점 전환”이고, 같은 맥락은 Docker·터미널 mixed-port 가이드와도 이어집니다.

용어: 아래 예시는 Meta/Mihomo 계열에서 흔한 mixed-port를 가정합니다. GUI에서는 “Mixed Port”로 표시되는 경우가 많습니다. port(HTTP 전용)와 socks-port를 나눠 쓰면 URL scheme만 실제 포트에 맞게 바꾸면 됩니다.

Windows 호스트 IP 확인: resolv.conf와 기본 게이트웨이

가장 단순한 방법 중 하나는 WSL에서 /etc/resolv.confnameserver 줄을 보는 것입니다. WSL이 자동 생성하는 경우가 많아, 거기 적힌 IP가 곧 Windows 호스트를 향하는 DNS/게이트웨이 역할을 하는 경우가 흔합니다(환경·버전에 따라 다를 수 있으니 아래 ip route와 교차 확인하세요).

WSL(Ubuntu) — 호스트 쪽 후보 IP 확인
# 1) resolv.conf의 nameserver (자동 생성 파일인지 확인)
grep -E '^nameserver' /etc/resolv.conf

# 2) 기본 라우트의 default via (게이트웨이 = 호스트일 때가 많음)
ip route show | grep -E '^default'

두 출력이 같은 대역(예: 172.x.x.x)을 가리키면 그 값을 WIN_HOST처럼 셸 변수로 잡아 두고 이후 예시에 넣기 좋습니다. 반대로 generateResolvConf = false로 꺼 두었거나 커스텀 DNS를 쓰는 경우, resolv.conf만 믿으면 엇나갈 수 있으니 ip route 결과를 우선하세요.

최신 WSL에서 mirrored 네트워킹을 켜 두었다면 localhost 공유 등 동작이 달라질 수 있습니다. 그래도 “명시적 프록시 주소”를 문서화해 두면 팀 내 재현성이 좋아집니다. Windows 측 전역 TUN·시스템 프록시 설정은 Windows 11에서 Clash Verge·TUN 정리를 참고하세요.

Clash 측: mixed-port·allow-lan·바인딩·방화벽

WSL에서 Windows IP로 접속하려면 Clash 입구가 루프백만이 아니라 LAN/WSL 쪽에서도 받아줄 수 있어야 합니다. 설정 예시는 코어/버전에 따라 키 이름이 조금 다를 수 있지만, 개념은 다음과 같습니다.

Illustrative YAML fragment (adapt to your core)
mixed-port: 7890
allow-lan: true
bind-address: '*'
보안: allow-lan과 와이드 바인드는 같은 Wi‑Fi의 다른 기기에서도 프록시 포트에 도달할 수 있게 만듭니다. 집/개발 PC에서는 흔하지만, 카페·공용망에서는 범위를 줄이거나 방화벽으로 제한하세요.

환경 변수로 HTTP·SOCKS 정렬: ALL_PROXYNO_PROXY

WIN_HOST를 앞 단계에서 구한 Windows 호스트 IP로 바꿉니다. mixed-port 하나에 HTTP와 SOCKS가 같이 열려 있다면 아래처럼 쓸 수 있습니다.

bash/zsh — 세션에만 적용(영구화는 ~/.bashrc 등에)
export WIN_HOST="172.x.x.x"   # 실제 IP로 교체
export HTTP_PROXY="http://${WIN_HOST}:7890"
export HTTPS_PROXY="http://${WIN_HOST}:7890"
export ALL_PROXY="socks5h://${WIN_HOST}:7890"
export NO_PROXY="localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

socks5h://h도메인 이름을 프록시 쪽에서 해석하라는 뜻에 가깝습니다. 로컬에서 먼저 해석하면 split-DNS·오염된 응답 때문에 “이상한 IP로 붙는” 현상이 줄어듭니다. NO_PROXY는 사내 Git·사설 레지스트리·K8s API처럼 절대 프록시를 타면 안 되는 대상을 반드시 넣어 조정하세요.

apt, Git, curl이 각각 읽는 설정

apt/etc/apt/apt.conf 또는 /etc/apt/apt.conf.d/ 아래의 Acquire::http::Proxy 등을 별도로 둘 수 있습니다. 환경 변수만으로 안 될 때는 apt 전용 설정이 우선하는지 확인하세요.

Githttp.proxy / https.proxy를 명시하는 편이 디버깅에 유리할 때가 있습니다. SSH 원격([email protected]:)은 HTTP 프록시와 별개이므로, HTTPS 원격으로 바꾸거나 ProxyCommand를 검토해야 합니다.

검증용으로 curl -I https://example.com를 쓸 때는 HTTPS_PROXY가 실제로 잡혔는지 env | grep -i proxy로 먼저 확인하고, 이어서 Clash 연결 로그에 해당 요청이 찍히는지 봅니다. TLS·timeout 계층 분리는 timeout/TLS 로그 가이드를 참고하세요.

DNS·resolv.conf·Fake-IP와의 충돌

WSL의 /etc/resolv.conf는 재부팅 후 자동 재생성될 수 있습니다. “호스트 IP용으로만 쓰고 DNS는 Clash 쪽 fake-ip와 맞추고 싶다” 같은 요구가 있으면, DNS 모듈도메인 규칙을 같이 봐야 합니다. 잘못 맞추면 “터널/프록시는 타는데 특정 도메인만 실패” 패턴이 납니다.

Clash Meta 계열의 nameserver·fallback·fake-ip-filter 흐름은 Clash Meta DNS 가이드에 정리되어 있으니, WSL에서 보이는 증상이 DNS에 가깝다면 그 글의 순서와 대조해 보세요. FAQ의 DNS 항목도 함께 보는 것이 좋습니다(FAQ).

mirrored 네트워킹·VPN·TUN과의 관계(요약)

Windows 측에서 다른 VPN이나 TUN 기반 클라이언트가 이미 라우팅을 잡고 있으면, WSL→Windows 호스트 IP 경로는 살아 있어도 그 다음 홉에서 막힐 수 있습니다. 이때는 “WSL 프록시 주소가 틀렸다”기보다 Windows 쪽 우선순위와 분할 라우팅을 의심하는 편이 빠릅니다. 개념 정리는 TUN 심화와 Windows 설정 글을 함께 보세요.

자주 틀리는 설정과 점검 순서

  1. 여전히 127.0.0.1 — WSL에서 Windows Clash로 가는 첫 오류입니다. 호스트 IP로 바꿉니다.
  2. allow-lan 꺼짐 / 루프백만 바인드 — 연결 거부. Clash 설정과 GUI 스위치를 다시 확인합니다.
  3. 방화벽 — 타임아웃에 가깝거나 간헐 실패. 인바운드 규칙을 확인합니다.
  4. 포트 불일치 — mixed-port가 7897인데 7890으로 적어 둔 경우 등. 대시보드에 표시된 값을 기준으로 합니다.
  5. DNS만 이상 — 프록시는 타는데 이름 해석이 꼬였는지, fake-ip와 로컬 DNS가 충돌하는지 점검합니다.

클라이언트를 고를 때는 업데이트 주기와 로그 가독성이 중요합니다. 클라이언트 선택 가이드로 팀 기준을 맞춰 두면 WSL 포함 여러 환경에서 같은 맥락으로 돌아올 수 있습니다.

맺음말

WSL2와 Windows는 “같은 키보드에서 보이지만 네트워크 관점에서는 다른 머신”에 가깝습니다. 호스트 IP + Clash 입구 포트 + 환경 변수 + DNS를 한 줄로 맞추면, 브라우저만 되고 터미널만 안 되는 이중 세계가 꽤 줄어듭니다. 규칙 자체를 손보기 전에, 먼저 “트래픽이 Clash 포트에 실제로 들어왔는지”를 로그로 확인하는 습관을 추천합니다.

Clash를 무료로 내려받고, Windows에서 입구·규칙·로그를 정리한 뒤 WSL 셸에 동일한 포트 정보만 복사해 맞춰 보세요.