어떤 증상을 이 글이 다루나

대표적인 패턴은 다음과 같습니다. 대시보드에서는 노드 지연이 정상으로 보이거나 테스트 버튼은 통과하는데, Clash TUN을 켜는 순간 브라우저·앱·윈도우 업데이트까지 한꺼번에 응답이 없어집니다. 반대로 TUN을 끄고 시스템 프록시만 쓰면 다시 접속이 되거나, 다른 VPN 클라이언트를 종료하면 갑자기 살아나기도 합니다. 이런 경우 원인은 “노드 품질”보다 Windows에서 트래픽이 어떤 인터페이스로 나가는지, 그리고 방화벽·다른 터널 소프트웨어가 경로를 가로막는지에 더 가깝습니다.

아래 순서는 위에서 아래로 좁혀 가는 구조입니다. 한 단계에서 원인이 드러나면 그 지점에서 멈추고 설정을 정리한 뒤, 필요할 때만 다음 단계로 넘어가면 됩니다. 클라이언트 설치·프로필 개념은 Clash Verge Rev Windows·macOS 가이드와 같은 흐름이며, 규칙·DNS 전체 그림은 YAML 설정 심화 글과 맞물립니다.

1단계: 시스템 프록시와 TUN·실행 모드를 동시에 켜 두지 않기

TUN은 가상 NIC를 통해 가능한 한 많은 트래픽을 코어로 끌어들이려 하고, 시스템 프록시는 OS에 HTTP/HTTPS 프록시 주소를 등록하는 방식입니다. 클라이언트마다 UI 표현은 다르지만, “시스템 프록시 켜짐 + TUN 켜짐” 상태가 겹치면 이중 경로·예기치 않은 루프·일부 앱만 멈추는 현상이 나올 수 있습니다. 우선 한쪽만 남기고 테스트해 보세요. 보통은 TUN만 사용하거나, TUN 없이 시스템 프록시만 사용하는 편이 단순합니다.

또한 코어의 mode가 global로 고정돼 있으면 국내 트래픽까지 전부 노드로 보내려 해 지연이 커지고, 규칙이 기대와 다르게 보일 수 있습니다. 분할 라우팅을 쓰는 경우 rule 모드인지, 프록시 그룹에서 실제로 사용할 노드가 선택됐는지 함께 확인하세요. 모드와 UI 스위치는 클라이언트마다 이름이 다르므로, “프록시 켜짐” 표시만 보지 말고 어떤 방식(프록시/TUN)이 활성인지를 구분하는 것이 중요합니다.

2단계: 다른 VPN·가상 어댑터·“기업용” 네트워크 소프트웨어 종료

Windows에서는 상용 VPN, 원격 업무용 터널, 일부 백신·트래픽 필터가 각자 가상 어댑터와 라우트를 추가합니다. Clash TUN도 유사한 역할을 하므로 동시에 두 개 이상의 터널이 기본 경로를 잡으려 할 때 전체 연결이 끊기거나 한쪽만 살아 있는 것처럼 보일 수 있습니다. 테스트할 때는 다른 VPN을 완전히 종료하고, 가능하면 트레이 아이콘과 작업 관리자에서 관련 프로세스가 남았는지 확인하세요.

Hyper-V·WSL·가상화 스위치를 쓰는 개발 환경에서는 브리지·내부 스위치가 예상 밖의 인터페이스 순위를 바꾸기도 합니다. 당장 개발 VM이 필요 없다면 해당 가상 스위치를 끈 상태에서 Clash만 켜고 비교해 보는 것도 방법입니다. 회사 PC라면 보안 에이전트가 네트워크 스택을 고정해 두었을 수 있어, 개인 설정과 충돌하면 IT 정책을 먼저 확인하는 편이 안전합니다.

3단계: 관리자 권한·Wintun·서비스(서비스 모드) 설치 여부

TUN은 커널에 가까운 계층에서 동작하므로 Windows에서는 관리자 권한으로 실행하거나, 클라이언트가 안내하는 서비스 모드·Wintun 드라이버 설치가 필요한 경우가 많습니다. 설치 과정에서 건너뛰었거나, 업데이트 후 드라이버 서명·경로가 꼬이면 “TUN 토글은 켜지는데 실제로 트래픽이 안 붙는” 상태가 됩니다. 클라이언트 설정 화면에서 TUN 관련 오류나 코어 로그에 tun·wintun 키워드가 반복되는지 확인하세요.

UAC 창을 매번 허용하기 번거롭다면 공식 문서에 따라 서비스로 등록하는 방식을 검토할 수 있습니다. 다만 권한 상승은 보안 경계를 넓히므로, 신뢰할 수 있는 빌드만 사용하고, 문서 허브와 릴리스 노트에서 요구 권한을 함께 읽는 것이 좋습니다. 설치 패키지는 다운로드 페이지에서 받는 것을 권장합니다.

4단계: 라우팅 테이블·기본 게이트웨이·충돌하는 기본 경로

TUN을 켜면 시스템에 새로운 인터페이스와 라우트가 추가되고, 기본 게이트웨이 우선순위가 바뀔 수 있습니다. 다른 소프트웨어가 이미 0.0.0.0/0을 가로채고 있거나, Clash 쪽 라우트가 잘못 추가되면 “전부 안 됨”에 가까운 증상이 납니다. 관리자 권한 명령 프롬프트에서 route print로 IPv4 테이블을 확인하고, TUN 전후로 어떤 항목이 추가·변경되는지 비교해 보세요.

메트릭이 비정상적으로 높거나, 동일 목적지에 서로 다른 인터페이스가 경쟁하면 패킷이 엉뚱한 곳으로 나갈 수 있습니다. 일부 환경에서는 TUN을 끈 뒤에도 라우트가 남아 “한동안만” 끊기는 것처럼 보이기도 하므로, 클라이언트를 완전히 종료한 후 테이블이 정리되는지 확인하는 것이 좋습니다. IPv6를 쓰는 회선이라면 IPv4만 터널에 넣고 IPv6는 다른 경로로 새는 경우도 있어, 듀얼 스택 환경에서는 IPv6 설정을 잠시 끄고 재현 여부를 보는 진단도 도움이 됩니다.

5단계: Windows Defender 방화벽·백신·제3자 필터

Clash 실행 파일·코어 프로세스·가상 어댑터 트래픽이 방화벽에서 차단되면, TUN을 켠 상태에서만 전부 막히는 것처럼 보일 수 있습니다. “개인 네트워크”와 “공용 네트워크” 프로필이 바뀌었거나, 보안 제품이 새 실행 파일마다 다시 묻는 경우도 흔합니다. Windows 보안 센터에서 해당 앱에 대한 아웃바운드 허용 여부를 확인하고, 기업용 백신이 네트워크 필터 드라이버를 싣고 있다면 예외 정책이 필요한지 살펴보세요.

일부 “최적화” 유틸리티나 광고 차단용 필터가 WFP(Windows Filtering Platform) 수준에서 패킷을 건드리면 TUN과 겹칠 때 충돌이 큽니다. 문제가 재현될 때만 해당 소프트웨어를 잠시 끄고 비교하면 원인 분리가 빨라집니다. 로그에 특정 PID가 반복해서 차단된다면 그 프로세스 이름을 기준으로 역추적하면 됩니다.

6단계: TUN 스택·DNS·IPv6·코어 로그로 마무리 확인

설정 파일의 tun 절에서 stack 값(system, gvisor, mixed 등)은 환경마다 안정성이 다릅니다. 한 스택에서만 끊긴다면 다른 값으로 바꿔 보는 것이 실무에서 자주 쓰는 완화책입니다. DNS는 Fake-IP·도메인 규칙과 맞물리므로, TUN을 켠 뒤에만 이름 해석이 실패한다면 YAML 가이드의 DNS·Fake-IP 절과 함께 코어 로그의 DNS 관련 메시지를 확인하세요.

마지막으로 클라이언트가 제공하는 코어 로그에서 에러 한두 줄만 포착해도 원인 범위가 크게 줄어듭니다. “권한 없음”, “어댑터 생성 실패”, “라우트 추가 실패”, “TLS 핸드셰이크 실패”는 각각 다른 층의 문제이므로, 동일 증상이라도 메시지를 기준으로 나누어 대응하는 것이 좋습니다. 장기적으로는 규칙·구독·모드를 한눈에 관리할 수 있는 그래픽 클라이언트를 쓰면 재현·복구가 수월합니다. 설치·갱신은 Clash 다운로드 페이지를 기준으로 잡으면 버전 혼선을 줄일 수 있습니다.

정리

Clash TUN은 “전역에 가깝게” 트래픽을 끌어오는 강력한 모드이지만, 그만큼 Windows의 라우팅·권한·다른 터널·방화벽과 맞물릴 여지가 큽니다. 증상이 생기면 노드부터 갈아엎기보다, 시스템 프록시와의 중복을 끊고, 다른 VPN을 비운 뒤, 관리자·Wintun·서비스를 확인하고, 라우트와 방화벽을 거친 다음 스택·DNS·로그로 마무리하는 순서가 가장 낭비가 적습니다.

동일한 코어를 쓰더라도 GUI마다 스위치 이름과 기본값이 다르니, 한 번 정상 동작하는 조합을 찾으면 그때의 모드 조합을 메모해 두는 것이 이후 A/S에 도움이 됩니다. 최신 빌드와 플랫폼별 패키지는 공식 배포 채널을 통해 받는 것이 안전합니다. → Clash를 무료로 내려받아 Windows 환경에서 다시 한 번 단계별로 점검해 보세요.