Clash TUN 모드 후 Windows에서 인터넷이 안 될 때:
라우팅 테이블·방화벽·DNS 단계별 점검

1. 증상 구분: 전체 단절과 부분 차단

Clash TUN 모드는 트래픽을 가상 네트워크 인터페이스로 넘겨 규칙에 따라 처리합니다. Windows에서 “켜자마자 전부 안 된다”와 “구글만 열리고 국내 사이트만 안 된다”처럼 패턴이 나뉘면 원인 후보가 달라집니다.

전역 단절(브라우저·DNS 조회·ping까지 모두 이상)이면 기본 게이트웨이가 틀어졌거나 TUN 인터페이스가 올라오지 않았거나, 방화벽이 코어 프로세스의 트래픽을 막는 경우를 의심합니다. 일부 사이트만 실패하면 규칙(RULE)·DNS(fake-ip·redir-host)·노드 지연 쪽을 먼저 봅니다.

비교 기준으로 시스템 프록시만 켠 상태와 TUN만 켠 상태를 번갈아 보세요. 시스템 프록시는 잘 되는데 TUN에서만 막히면 라우팅·가상 어댑터·WFP(Windows Filtering Platform) 쪽 문제일 가능성이 큽니다. 반대로 둘 다 같이 막히면 상류 노드·구독·프로필 전체를 의심합니다. 클라이언트 선택과 기본 개념은 Windows용 Clash 비교 글과 설정 문서를 함께 참고하면 좋습니다.

2. TUN과 시스템 프록시의 차이

시스템 프록시는 HTTP/HTTPS를 지원하는 앱이 OS 설정을 따를 때만 효과가 있습니다. 반면 TUN은 OS 레벨에서 가상 인터페이스를 만들어 더 넓은 범위의 트래픽을 잡을 수 있습니다. 그 대신 라우트를 추가·수정하므로 다른 VPN·회사 보안 에이전트와 충돌하기 쉽습니다.

GUI에서 “TUN 켜기”만 하고 config.yaml의 tun 섹션(스택, DNS 하이재킹, 자동 라우트 등)이 코어 버전과 맞지 않으면 로그에 오류가 남거나 조용히 실패할 수 있습니다. 설정 후에는 반드시 재시작한 뒤 클라이언트 로그에서 “TUN”·“route”·“adapter” 키워드를 확인하세요.

3. 코어·가상 어댑터·권한

Windows는 TUN용 드라이버(예: Wintun) 설치와 관리자 권한이 필요한 경우가 많습니다. 설치가 불완전하면 어댑터가 생기지 않거나 잠깐 생겼다가 사라집니다. 장치 관리자에서 알 수 없는 네트워크 어댑터가 늘지 않는지, Clash를 재설치했을 때 동일 증상이 반복되는지 확인하세요.

클라이언트를 일반 사용자로만 실행하면 TUN 생성이 실패하는 빌드도 있습니다. “관리자 권한으로 실행”이나 서비스 모드에서 해결되는지 비교해 보세요. 백신·샌드박스가 코어 실행 파일을 격리하면 어댑터 생성 단계에서 멈출 수 있으므로, 테스트 목적이라면 잠시 예외를 두고 재현 여부를 보는 것도 방법입니다.

로그에서 볼 것

코어 로그에 start tun·create tun 성공 메시지가 있는지, 실패 시 errno·윈도우 오류 코드가 무엇인지 적어 두면 다음 검색이 빨라집니다.

4. 라우팅 테이블 점검

TUN이 켜지면 기본 경로가 바뀌거나, 특정 대역이 터널 인터페이스로 보내질 수 있습니다. 잘못된 기본 게이트웨이가 남으면 모든 패킷이 엉뚱한 곳으로 가 “완전 끊김”처럼 보입니다.

관리자 권한 명령 프롬프트나 PowerShell에서 route print로 IPv4 테이블을 확인합니다. TUN 활성화 전후를 스크린샷하거나 텍스트로 비교하면 어떤 인터페이스가 기본 경로를 가져갔는지 한눈에 들어옵니다. 또한 0.0.0.0/0이나 LAN 대역(192.168.0.0 등)에 예상치 못한 항목이 생겼는지 봅니다.

다른 상용 VPN이 같은 방식으로 기본 경로를 잡고 있으면 한쪽만 켜야 합니다. 둘 다 TUN/가상 어댑터를 쓰면 충돌이 빈번합니다. Hyper-V 기본 스위치·Docker Desktop·가상머신 브리지가 동시에 켜져 있을 때도 우선순위가 꼬일 수 있으니, 문제가 날 때는 가상화 스택을 잠시 끄고 재시도해 보세요.

5. DNS·fake-ip

TUN이 DNS를 가로채는 설정(dns-hijack 등)과 클라이언트의 DNS 모드(fake-ip·redir-host)가 맞지 않으면 “사이트는 뜨는데 일부만 안 뜬다” 또는 “HTTPS만 실패” 같은 증상이 납니다. fake-ip를 쓰는 경우 브라우저·캐시와의 상호작용이 복잡하므로, 문제가 지속되면 한동안 redir-host로 바꿔 동작 차이를 비교해 보는 것이 좋습니다.

Windows의 “네트워크 어댑터 DNS”가 공유기와 Clash 내부 DNS를 중복으로 가리키면 루프나 타임아웃이 날 수 있습니다. TUN 사용 시에는 클라이언트 문서에 맞게 단일 DNS 해석 경로를 유지하는 편이 안전합니다.

도메인이 실제로 어디로 해석되는지 확인하려면 터미널에서 nslookup example.com을 TUN 켠 상태와 끈 상태로 비교하거나, Clash 로그의 DNS 쿼리 로그를 활용하세요.

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

Windows Defender 방화벽은 인바운드뿐 아니라 아웃바운드 규칙으로도 앱을 막을 수 있습니다. TUN으로 나가는 패킷이 “새 인터페이스에서 나가는 것”으로 보일 때 차단되는 사례가 있습니다. “Windows 보안 → 방화벽 → 앱이 방화벽을 통과하도록 허용”에서 Clash 실행 파일과 코어(예: mihomo.exe 등 실제 프로세스 이름)를 개인·공용 모두 허용했는지 확인하세요.

서드파티 백신·엔드포인트 제품은 WFP 필터를 추가로 설치해 Clash보다 먼저 패킷을 잡습니다. 이때는 클라이언트 예외 목록에 경로를 넣거나, 테스트로 해당 제품의 방화벽 모듈을 잠시 끄고 증상이 사라지는지 봅니다. 회사 PC는 그룹 정책으로 인터페이스 생성 자체가 막힐 수 있습니다.

순서

방화벽을 넓게 열기 전에 TUN 인터페이스가 살아 있고 라우트가 정상인지 먼저 확인하는 것이 좋습니다. 경로가 잘못된 상태에서 방화벽만 허용해도 인터넷은 돌아오지 않습니다.

7. 다른 VPN·가상화 충돌

WireGuard·OpenVPN·상용 VPN 클라이언트가 동시에 실행 중이면 TUN과 기본 경로가 끊임없이 덮어씌워집니다. 한 번에 하나의 터널 소프트웨어만 켜는 것이 원칙입니다.

Windows의 “가상 스위치”나 WSL2·Docker가 브리지 네트워크를 만들면 라우팅 우선순위가 바뀝니다. 증상이 특정 부팅 직후에만 나타난다면 최근에 설치한 가상화 도구를 의심하세요. Mixed Port·LAN·방화벽 글에서 다룬 것처럼, 방화벽과 바인드는 포트 프록시와도 연결되지만 TUN 문제와는 증상이 겹칠 수 있어 참고용으로 읽으면 좋습니다.

8. 증상별 빠른 표

아래는 첫 대응 순서를 정리한 것입니다. 자세한 설정명은 사용 중인 코어·GUI 버전에 맞춰 조정하세요.

한 단계씩 좁혀도 원인이 불명확하면, 동일 프로필로 TUN 대신 시스템 프록시만 사용하는 구성으로 일시 전환해 업무를 병행하고, 로그와 설정을 백업한 뒤 클라이언트를 최신으로 올리는 것을 권장합니다.

9. 요약·다음 단계

Windows에서 Clash TUN 관련 끊김은 “코어가 터널을 만들었는가 → 라우트가 올바른가 → DNS가 일관되는가 → 방화벽·보안 SW가 막지 않는가 → 다른 VPN이 경로를 덮지 않는가” 순으로 보면 대부분 구분할 수 있습니다. 증상을 전역/부분으로 나누는 것만으로도 다음 조치가 달라집니다.

규칙 기반 프록시는 로그와 설정이 분명해, 블랙박스형 VPN보다 원인 추적에 유리합니다. 동일 증상이 반복되면 route print 결과와 코어 로그 일부를 남겨 두면 업데이트 후에도 비교가 쉽습니다. 설치 패키지는 공식 다운로드 페이지에서 받는 것이 안전합니다.

오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 되고, 일상적인 설치·업데이트는 사이트에서 제공하는 클라이언트를 쓰는 편이 혼선이 적습니다. 같은 규칙이라도 UI가 정돈된 최신 빌드는 TUN 토글과 로그 보기가 수월해, 장시간 켜 두는 환경에서 체감 차이가 큽니다.

→ Clash를 무료로 다운로드하고 안정적인 설정 경험을 이어 가 보세요