1. WSL2에서 127.0.0.1이 “호스트 Clash”가 아닌 이유
WSL2는 가벼운 가상화 기반 리눅스 환경이라, 터미널 안의 127.0.0.1은 그 리눅스 인스턴스 자신을 가리킵니다. Windows에서 돌아가는 Clash 클라이언트가 127.0.0.1:7890 같은 주소로 HTTP·SOCKS 리스너를 열었다면, 그 소켓은 호스트 OS 쪽 루프백에 붙어 있고 WSL2 프로세스의 127.0.0.1과는 별개입니다. 그래서 브라우저(Windows 네이티브)에서는 잘 되는데 WSL2의 curl만 “연결 거부”가 나오는 패턴이 매우 흔합니다.
해결의 첫 단계는 항상 트래픽을 어디로 보낼지 주소를 바꾸는 것입니다. 즉 WSL2 안에서는 127.0.0.1 대신 Windows 호스트의 가상 어댑터 IP(또는 배포판·WSL 버전에서 제공하는 별칭)를 써야 합니다. 둘째로, 호스트의 Clash가 127.0.0.1에만 바인드되어 있으면 외부(여기서는 WSL2 가상 NIC)에서 들어오는 연결을 받지 못하므로, 모든 인터페이스에서 수신하거나 LAN 허용 옵션을 켜야 합니다. 이는 Mixed Port·Allow LAN 글에서 다룬 내용과 직결됩니다.
127.0.0.1 vs 호스트 IP) 또는 WSL2 전용 DNS 문제입니다. 먼저 TCP 연결부터 분리해 보세요.
2. Windows 호스트 IP를 WSL2에서 확인하는 방법
가장 널리 쓰이는 방법은 WSL2 셸에서 cat /etc/resolv.conf를 열어 nameserver 줄을 보는 것입니다. 많은 기본 구성에서 이 주소가 기본 게이트웨이이자 Windows 호스트를 가리키는 내부 IP로 잡혀 있습니다. 다만 배포판 업데이트·systemd·사용자 정의 resolv.conf 때문에 항상 동일하지는 않으므로, ip route show default로 기본 경로의 next hop을 같이 확인하는 습관이 안전합니다.
Windows 11의 일부 미리보기·설정에서는 WSL의 네트워킹 모드가 달라져 호스트 접근 방식 문서가 바뀌기도 합니다. 그럴 때는 공식 릴리스 노트를 보고, localhost 포워딩 관련 옵션(예: .wslconfig)이 있는지 확인하세요. 본문은 “전통적인” NAT형 WSL2를 기준으로 설명하되, 모드가 다르면 같은 증상이라도 첫 확인 명령이 달라질 수 있다는 점만 기억하면 됩니다.
연결만 먼저 검증하기
호스트 IP를 알았다면 WSL2에서 nc -vz 호스트IP 포트 또는 curl -v --proxy http://호스트IP:포트 https://example.com처럼 TCP 레벨부터 확인하세요. 여기서조차 타임아웃이면 Clash 이전에 방화벽·바인드 주소·포트 번호 오타를 의심합니다. Windows Defender 방화벽이 WSL 가상 스위치에서 들어오는 인바운드를 막는 경우도 있어, Mixed Port를 연 상태에서 인바운드 규칙을 짧게 열어 실험해 볼 수 있습니다.
3. Clash(Windows) 쪽: 수신 주소·Mixed Port·Allow LAN
Clash·Mihomo 계열 코어는 mixed-port·port·socks-port 등으로 인바운드를 정합니다. GUI 클라이언트에는 Allow LAN·유사 옵션이 있어 켜면 0.0.0.0에서 수신하는 식으로 동작하는 경우가 많습니다. 꺼져 있으면 Windows 자체의 루프백에서만 연결이 열려 WSL2는 영원히 못 붙습니다.
config.yaml을 직접 편집한다면 allow-lan·bind-address 계열 키를 코어 문서에 맞춰 확인하세요. 저장 후 실제 로드된 설정이 UI·로그에 반영됐는지도 봐야 합니다. 구독 갱신이나 프로필 전환 때 값이 덮어씌워지는 경우가 있어, “어제까지 됐는데 오늘 안 된다”는 보고가 종종 올라옵니다.
4. 환경 변수: http_proxy·HTTPS_PROXY·ALL_PROXY·Git
대부분의 CLI 도구는 대문자·소문자 환경 변수를 혼용합니다. export http_proxy=http://호스트IP:7890와 export HTTPS_PROXY=...를 셸 프로필(~/.bashrc 등)에 넣는 방식이 흔합니다. git은 git config --global http.proxy를 별도로 두는 경우가 있어, 환경 변수만 바꿨는데도 Git이 안 따라온다면 git config --list로 중복 설정을 확인하세요.
apt는 프록시 환경 변수를 따르는 경우와 /etc/apt/apt.conf에 고정된 경우가 섞여 있습니다. 회사 이미지처럼 사전 구성된 배포판에서는 예전 프록시 주소가 남아 WSL2에서 이상 동작하기도 합니다. sudo로 실행할 때 환경 변수가 빠지는 문제도 있어, sudo -E나 apt 전용 설정을 점검해야 합니다.
도구마다 “프록시를 아예 안 쓰는 모드”가 있으므로, 한 번에 전부 고치려 하기보다 curl 한 줄로 호스트 경유가 되는지 먼저 증명하고 범위를 넓히는 편이 빠릅니다. 문법과 모드 전반은 설정 가이드·튜토리얼과 함께 보시면 구조가 잡힙니다.
5. DNS: 이름은 되는데 HTTPS만 실패할 때
프록시 TCP는 붙는데 특정 사이트만 안 열리면 DNS가 원인인 경우가 많습니다. Clash에서 fake-ip 모드를 쓰면 클라이언트가 받는 IP가 실제 서버가 아니라 코어가 부여한 가짜 대역이 되어, 애플리케이션이 “이상한 IP”로 직접 붙으려다 실패하는 흐름이 생깁니다. WSL2 안의 앱이 시스템 리졸버를 통해 얻은 주소와, 프록시 내부의 해석 결과가 어긋나면 증상이 꼬입니다.
이때는 (1) Clash DNS 섹션에서 어떤 리스너를 쓰는지, (2) WSL2가 실제로 어떤 DNS 서버를 바라보는지, (3) TUN을 켰을 때 호스트 쪽 가상 어댑터와 충돌이 없는지를 같이 봐야 합니다. TUN 관련 전체 단계는 TUN·라우팅 글이 더 깊습니다. WSL2 사용자는 “호스트 Clash만 켜고 TUN은 끈 상태”인 경우가 많으므로, 우선 HTTP 프록시 경로에서 DNS가 어디서 해석되는지부터 나누는 것이 좋습니다.
6. systemd-resolved·/etc/resolv.conf 스텁
Ubuntu 등 최신 배포판은 systemd-resolved가 127.0.0.53 스텁 리졸버를 쓰도록 /etc/resolv.conf를 자동 관리합니다. 사용자가 수동으로 네임서버를 박아 넣으면 업데이트 때 되돌아가거나, WSL 특유의 자동 생성 파일과 충돌합니다. “프록시는 맞는데 이름만 이상하다”면 resolvectl status·systemd-resolve --status(버전에 따라 명령이 다름)로 실제 업스트림 DNS를 확인하세요.
일부 사용자는 WSL2에서 호스트의 Clash DNS 포트(예: 코어가 열어 둔 로컬 DNS)를 직접 네임서버로 지정하기도 합니다. 이 경우에도 앞서 말한 127.0.0.1 함정이 재등장합니다—WSL2의 127.0.0.1은 호스트가 아닙니다. 호스트 DNS 리스너를 쓰려면 역시 호스트 IP로 지정해야 합니다.
7. WSL 네트워킹 모드·미러링·포트 전달에 대한 짧은 메모
마이크로소프트는 WSL의 네트워크 스택을 개선하면서, 특정 채널에서는 “Windows와 더 가깝게” 동작하는 옵션을 실험·배포해 왔습니다. 어떤 모드에서는 localhost가 호스트와 공유되기도 하고, 어떤 모드에서는 전통적인 NAT 모델을 유지합니다. 증상이 업데이트 직후에만 바뀌었다면 릴리스 노트와 .wslconfig의 네트워킹 항목을 의심하세요.
고급 사용자는 Windows 쪽에서 netsh interface portproxy로 포트를 중계하거나, 별도 중계 프로세스를 두기도 합니다. 다만 대부분의 개발 환경에서는 호스트 IP + Clash Allow LAN + 올바른 환경 변수 조합으로 충분한 경우가 많아, 우선 단순 경로를 안정화한 뒤 복잡한 포워딩을 검토하는 순서가 유지 보수에 유리합니다.
8. 증상별로 어디를 볼까
아래는 WSL2에서 Windows Clash를 쓸 때 자주 보는 패턴을 정리한 표입니다.
| 증상 | 가능성이 큰 원인 | 먼저 할 일 |
|---|---|---|
curl: (7) Failed to connect to 127.0.0.1 |
WSL2의 루프백 ≠ Windows 루프백 | 호스트 IP로 바꾸기·Clash Allow LAN |
| TCP는 되는데 TLS·도메인만 이상 | DNS 불일치·fake-ip | 리졸버·Clash DNS 모드·로그 비교 |
| 간헐적으로만 끊김 | 호스트 IP 변경·프로필 덮어쓰기 | DHCP·구독 갱신 후 설정 재확인 |
| sudo apt만 실패 | 환경 변수 미전달·apt 고정 프록시 | sudo -E·apt.conf 확인 |
표에 없는 “전체 인터넷이 끊김” 류는 호스트에서 TUN·다른 VPN·라우팅이 겹친 경우가 많습니다. 해당 증상은 본 글보다 TUN 점검 글의 순서를 따르는 편이 빠릅니다.
9. 요약
WSL2에서 Windows의 Clash를 쓰려면 세 가지를 동시에 맞춰야 합니다. 첫째, WSL2는 127.0.0.1을 호스트로 쓰지 말고 호스트 측 가상 어댑터 IP 등 실제 경로를 찾을 것. 둘째, Clash가 루프백에만 바인드되어 있지 않게 LAN·바인드를 정리할 것. 셋째, TCP가 통과한 뒤에도 문제가 남으면 DNS·systemd-resolved·fake-ip 축을 의심할 것입니다. 이 세 축이 맞으면 apt·git·컨테이너 빌드 스크립트까지 같은 프록시 스택을 공유하기 쉬워집니다.
설치 패키지는 소스 저장소가 아니라 공식 다운로드 페이지를 우선하는 것이 버전·업데이트 경로가 분명합니다. 오픈 소스 저장소는 빌드와 이슈 추적용으로 두면 혼선이 적습니다.
→ Clash를 무료로 내려받아 Windows에서 안정적으로 연 뒤, WSL2 환경 변수와 DNS만 맞춰 보세요