Windows 11에서 Clash와 WSL2를 함께 쓸 때 끊김 복구: 라우팅·MTU 단계별 점검

어떤 증상부터 이 가이드를 보면 좋을까요?

Windows 11에서 Clash 계열 클라이언트(예: Clash Verge Rev)를 시스템 프록시나 TUN(가상 어댑터)로 켠 상태로 WSL2를 쓰다 보면, 다음과 같은 패턴이 자주 보고됩니다. Edge·Chrome은 열리는데 wsl 안에서 apt update·git pull·curl만 타임아웃된다. 또는 호스트와 WSL가 번갈아 “잠깐 됐다가” 끊긴다. 재설치·구독 갱신만 반복하기보다, 라우팅 우선순위와 MTU처럼 재현 가능한 층부터 짚는 편이 빠릅니다.

이 글은 “Clash를 지우면 된다” 수준의 일반론 대신, 기본 게이트웨이·Hyper-V/WSL 가상 NIC·인터페이스 메트릭·패스 MTU·DNS 상속을 한 줄기 흐름으로 묶은 실무 체크리스트입니다. 초보용 전체 설치 흐름은 문서·튜토리얼과, TUN 개념은 TUN 모드 가이드를 함께 보시면 맥락이 이어집니다.

왜 Clash와 WSL2가 충돌해 보일까요?

첫째, 시스템 프록시는 주로 WinHTTP/WinINet을 쓰는 앱에 영향을 주고, WSL2 리눅스 커널이 보내는 순수 IP 트래픽은 Windows의 라우팅·NAT 규칙을 그대로 탑니다. 둘째, TUN 모드는 Clash가 만든 가상 인터페이스와 라우팅 항목을 추가해 “어떤 목적지를 어느 게이트웨이로 보낼지”를 바꿉니다. 셋째, Hyper-V가 만든 vEthernet (WSL)·vEthernet (Default Switch) 등은 각각 인터페이스 메트릭이 있어, 숫자가 낮을수록 OS가 더 “선호”하는 출구가 됩니다. 넷째, VPN·클라우드 동기화·보안 제품이 또 다른 가상 어댑터를 올리면 상황이 겹칩니다.

따라서 증상이 “프록시 규칙이 틀렸다” 한 가지로만 정리되지 않고, 출구 NIC 선택과 단편화(Fragmentation) 문제가 섞여 나옵니다. 아래 단계는 변경을 최소화하면서 원인을 층별로 가르는 순서입니다.

1단계: 기준선을 나누어 재현하기

같은 증상이라도 원인이 다를 수 있으니, 먼저 네 가지 조합을 짧게 비교해 보세요. (1) Clash 완전 종료 후 WSL만 테스트 (2) 시스템 프록시만 켜고 TUN 끔 (3) TUN만 켜고 시스템 프록시는 끔 (4) 둘 다 켬. 어느 조합에서만 깨지는지가 다음 점검의 방향을 정해 줍니다. TUN을 켰을 때만 WSL가 죽으면 TUN·라우팅과 MTU를 우선 보고, Clash를 끈 상태에서도 WSL가 불안정하면 Hyper-V·외부 VPN·회사 보안 에이전트 쪽을 의심합니다.

Windows PowerShell에서 관리자 권한 없이도 볼 수 있는 Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric 출력을 한 번 캡처해 두면, 나중에 메트릭을 건드린 뒤 전후 비교가 쉽습니다. WSL 안에서는 ip route와 ip -br link로 기본 경로와 eth0 상태를 확인합니다.

2단계: 기본 라우트와 게이트웨이가 말하는 것

Windows에서 route print -4를 실행하면 IPv4 테이블이 나옵니다. 0.0.0.0 행이 여러 개일 때 메트릭이 가장 낮은 쪽이 실질적인 기본 출구에 가깝습니다. Clash TUN을 켠 직후 이 행들이 바뀌었는지, 게이트웨이가 실제 공유기·회사 게이트가 아니라 가상 인터페이스 쪽을 가리키는지 확인하세요. WSL2는 호스트가 NAT를 제공하므로, 호스트의 기본 경로가 꼬이면 리눅스 쪽에서도 같은 방향으로 증상이 전파됩니다.

임시로 특정 전략을 시험할 때는, 클라이언트에서 TUN을 끄고 시스템 프록시만으로 버티며 WSL 트래픽이 DIRECT 규칙을 타도록 두는 방법도 있습니다. 다만 터미널 도구가 프록시를 안 타는 경우가 있어 근본 해결이 아닐 수 있습니다. 장기적으로는 TUN을 쓸지 말지와 규칙에서 LAN·WSL 대역을 직결할지 설계를 같이 보는 것이 좋습니다.

3단계: TUN·가상 NIC 우선순위 다듬기

Clash가 만든 TUN 어댑터 이름은 빌드마다 다르지만, 장치 관리자·네트워크 어댑터 목록에서 가상 항목으로 보입니다. 인터페이스 메트릭이 물리 NIC·WSL 브리지보다 과도하게 낮으면(숫자상 더 우선), 의도치 않게 모든 기본 트래픽이 그쪽으로 몰릴 수 있습니다. 반대로 메트릭이 너무 높으면 TUN이 거의 안 타고 “켰는데도 앱이 직결”처럼 보이기도 합니다.

조정은 어댑터 속성·PowerShell의 Set-NetIPInterface 등으로 가능하지만, 값을 바꾸기 전에 현재 값을 메모해 두세요. 일부 환경에서는 Clash를 재시작할 때마다 메트릭이 다시 잡히기도 하므로, 클라이언트 쪽 TUN 스택 옵션(예: system·gvisor·mixed)을 바꿔 보는 것도 TUN 가이드에서 권장하는 1차 실험과 맞닿아 있습니다. 다른 상용 VPN과 동시에 켜 두었다면, 한쪽만 켠 상태에서 재현 여부를 먼저 확인하는 것이 안전합니다.

4단계: MTU·단편화 의심하기

작은 요청은 되는데 큰 전송·HTTPS·git clone만 걸리거나, 특정 네트워크(테더링·사내망)에서만 죽는 패턴은 경로 MTU 문제일 때가 많습니다. TUN·PPPoE·추가 캡슐화가 붙으면 실효 MTU가 줄어드는데, 단편화가 막혀 있으면 중간에서 조용히 실패합니다.

WSL 안에서 임시로 eth0 MTU를 낮춰 보는 실험은 진단에 도움이 됩니다. 예를 들어 1280이나 1400처럼 단계를 낮추며 ping과 curl을 다시 시험해 보세요. 값이 낮아질수록 안정해지면 MTU 쪽을 의심할 근거가 생깁니다. Windows 측에서도 대상에 대해 크기를 키우며 ping을 보내는 방식으로(플랫폼별 옵션 차이 있음) 단편화 한계를 가늠할 수 있습니다. 장기 적용은 재부팅 후에도 유지되는지 확인해야 하며, 근본적으로는 Clash 쪽 터널·노드 경로와 회선 특성을 함께 봐야 합니다.

5단계: WSL2가 물려 받는 DNS

WSL2는 기본적으로 Windows가 넘겨 준 DNS를 사용합니다. /etc/resolv.conf가 가리키는 서버가 Clash의 fake-ip·로컬 DNS 리스너·회사 내부 전용 주소일 때, 리눅스 쪽 해석 결과와 Windows 브라우저가 보는 결과가 달라질 수 있습니다. “IP는 나오는데 연결이 안 된다”면 라우팅과 별도로 DNS도 같이 의심하세요.

Clash의 DNS 모드·fake-ip-filter·도메인 규칙 순서는 TUN 가이드의 DNS 절과 연결됩니다. WSL 전용으로는 일시적으로 공용 DNS(환경 정책이 허용할 때만)로 바꿔 비교 실험을 할 수 있으나, 영구 설정은 조직 보안 정책과 충돌하지 않게 선택해야 합니다.

6단계: 규칙(분할) 설계와 WSL 트래픽

개발망·사내망 대역·도커 브리지·가상 스위치 대역을 DIRECT로 두지 않으면, WSL에서 나온 트래픽이 불필요하게 해외 노드를 한 바퀴 돌다 지연·차단되는 경우가 있습니다. 구독에 포함된 국내·LAN 예외 규칙이 오래됐다면 최신 대역을 반영했는지 확인하세요. 반대로 “모든 것을 직결”로만 두면 프록시가 필요한 목적지는 호스트 브라우저와 WSL CLI가 서로 다른 경로를 타 혼란이 생길 수 있으니, 목적지 유형별로 그룹을 나누는 편이 유지보수에 유리합니다.

분할 규칙 작성의 기본 축은 규칙 분할 가이드에서 다룹니다. WSL 이슈만 별도로 볼 때는 “규칙을 많이 넣는다”보다 라우팅·MTU·DNS 층을 먼저 정리했는지가 우선입니다.

한 페이지 체크리스트

• Clash 종료·프록시만·TUN만·둘 다 네 조합 중 어디서만 깨지는지 기록한다.
• Windows route print -4와 Get-NetIPInterface로 0.0.0.0 행과 메트릭을 캡처한다.
• WSL에서 ip route·ip link·curl -v로 실패 지점을 구체화한다.
• TUN·다른 VPN·Hyper-V 가상 어댑터가 동시에 활성인지 확인한다.
• MTU를 단계적으로 낮춰 재현이 사라지는지 본다.
• /etc/resolv.conf와 Clash DNS·fake-ip 설정을 같이 본다.
• LAN·사내 대역 DIRECT 규칙 유효성을 확인한다.

마무리

정리하면, Windows 11에서 Clash와 WSL2를 병행할 때의 끊김은 대개 “한 번에 재설치”로 풀리기보다, 기본 라우트·가상 NIC 우선순위·MTU·DNS 상속이 겹친 결과로 나타나는 경우가 많습니다. 증상을 네 가지 조합으로 가른 뒤, 표와 로그에 남긴 값을 전후 비교하면 같은 문제를 다시 만났을 때도 시간을 덜 씁니다.

비슷한 범주의 도구들과 비교해 보면, Clash·Mihomo 계열은 규칙과 DNS 표현이 유연해 “호스트는 프록시, 특정 대역은 직결” 같은 정책을 세밀하게 유지하기 좋습니다. GUI에서 시작하고 필요할 때만 YAML을 손대는 방식이면 부담도 적습니다.

지금 환경에 맞는 클라이언트로 바로 점검해 보시려면 Clash를 무료로 다운로드해 설치한 뒤, 위 체크리스트 순서대로 TUN·라우팅·MTU를 좁혀 보시길 권합니다. 안정적인 병행 사용은 설정이 맞을 때 비로소 체감됩니다.