Windows에서 왜 TUN 모드를 쓰나
브라우저는 시스템 프록시 설정을 잘 따르지만, 일부 데스크톱 앱·콘솔 도구·게임 런처는 HTTP(S) 프록시 환경 변수를 무시하거나 UDP·ICMP까지 필요로 합니다. 이때 트래픽을 가상 네트워크 인터페이스(TUN) 쪽으로 모아 Clash·Mihomo 코어가 다시 규칙에 따라 분배하는 방식이 흔합니다. Windows 구현체 대부분은 WireGuard 계열에서 쓰이는 Wintun 드라이버에 의존하므로, “TUN이 안 된다”는 말은 곧 “가상 어댑터 스택이 제대로 안 올라왔다”는 뜻과 거의 같습니다.
이 글은 기술적 트러블슈팅에 한정하며, 관할 법규·조직 정책·서비스 약관 준수는 사용자 본인의 책임입니다. 회사 노트북이나 학교 PC에서는 내부 VPN·보안 에이전트와 충돌할 수 있으니 IT 가이드를 우선하세요.
Wintun과 ‘가상 어댑터’가 의미하는 것
Wintun은 커널 모드 미니포트 드라이버로, 사용자 모드 프로그램이 IP 패킷을 읽고 쓸 수 있는 가상 TUN 장치를 만듭니다. Clash 계열 GUI는 보통 첫 TUN 기동 시 드라이버를 등록하거나, 번들된 모듈을 설치합니다. 장치 관리자에 “Wintun” 혹은 클라이언트 이름이 붙은 네트워크 어댑터가 생기고, 라우팅 테이블에 기본 게이트웨이나 더 구체적인 목적지가 추가되는 패턴이 일반적입니다.
버전이 맞지 않거나 이전 설치가 깨져 있으면 “설치 실패” 로그만 남고 어댑터가 안 뜨는 경우가 있습니다. 반대로 어댑터는 떴는데 라우팅이 꼬이면 물리 NIC 쪽으로 나가야 할 관리 트래픽까지 터널 안으로 들어가 버려 전체가 끊긴 것처럼 보일 수 있습니다.
Wintun·드라이버 설치가 실패할 때
다음 항목을 위에서부터 확인해 보세요. 한 가지씩 바꾸고 다시 시도하는 편이 원인 파악에 유리합니다.
- 관리자 권한: TUN 기동은 드라이버 로드와 라우트 변경을 동반합니다. 설치형 클라이언트는 “관리자로 실행”을 켜 두거나, UAC 프롬프트를 허용해야 합니다.
- 서명·보안 정책: 일부 기업 환경은 테스트 서명만 허용하거나 서드파티 드라이버를 막습니다. 이 경우 개인 기기에서 검증하거나 정책 예외가 필요합니다.
- 백신·EDR·방화벽: 실시간 스캔이 드라이버 설치 파일을 격리하면 조용히 실패합니다. 일시 예외 후 재설치·재부팅을 고려하세요(조직 정책 범위 안에서).
- 중복·유령 어댑터: 과거 클라이언트를 지웠어도 Wintun 인스턴스가 남아 있으면 충돌이 납니다. 장치 관리자에서 사용하지 않는 가상 어댑터를 제거하고 재시도합니다. 제거 전 시스템 복원점을 만드는 것도 방법입니다.
- 클라이언트·코어 버전: GUI와 내장 Mihomo(Clash Meta) 버전이 너무 낮으면 최신 Windows 빌드에서 TUN 경로가 어긋날 수 있습니다. Verge 계열 튜토리얼에서 채널 업데이트 흐름을 함께 맞춰 두면 재현성이 좋아집니다.
오류 메시지에 access denied, failed to create interface, wintun 키워드가 보이면 로그와 함께 위 항목을 대조하면 됩니다.
TUN을 켠 직후 인터넷이 ‘전부’ 안 될 때
가장 흔한 패턴은 노드는 살아 있는데 기본 라우팅만 잘못된 경우와, DNS만 터널 밖으로 나가거나 터널 안에서 해석 실패하는 경우입니다. 아래 순서로 점검합니다.
- 프록시 모드와 혼동: TUN을 켠 상태에서 시스템 프록시도 중복 적용되면 예상과 다른 경로로 나갈 수 있습니다. GUI에서 “시스템 프록시”와 “TUN” 중 실제로 무엇이 켜졌는지 확인하세요.
- 글로벌·룰·다이렉트: 프로필이 전부 REJECT에 가깝게 묶이거나, 필수 도메인이 DIRECT인데 물리 회선이 막힌 경우에도 “완전 단절”로 보입니다. 간단히 규칙을 완화한 테스트 프로필으로 비교해 보세요.
- auto-route·strict-route: 자동 라우팅이 켜지면 기본 경로가 TUN 쪽으로 기울어집니다. strict-route 계열 옵션은 예외 라우트를 좁혀 루프나 블랙홀을 만들기 쉬우므로, 문제가 생기면 한 번 끄고 증상이 사라지는지 봅니다.
- 스택 구현체: gVisor·system 등 클라이언트마다 이름이 다릅니다. 한 스택에서만 끊기면 다른 스택으로 바꿔 보는 것이 빠른 분기 테스트입니다.
- 다른 VPN과 동시 사용: 상용 VPN, Zerotier, 회사 Split Tunnel VPN이 동시에 라우트를 만지면 충돌이 납니다. 다른 터널을 끄고 Clash만 남겨 재현 여부를 확인하세요.
라우팅·지연 튜닝과 겹치는 부분은 속도 최적화 가이드의 TUN·DNS 절을 참고하면 트레이드오프를 정리하기 쉽습니다.
DNS 하이재킹·fake-ip와 ‘이름은 되는데 페이지는 안 열림’
TUN 환경에서는 Clash 내장 DNS와 UDP 53 하이재킹이 함께 쓰이는 경우가 많습니다. OS가 여전히 공유기 DNS만 바라보면 규칙과 어긋나고, 반대로 터널 안의 리졸버가 막히면 이름 해석은 되는 것처럼 보였다가 연결만 실패하는 증상이 납니다.
dns.enable, enhanced-mode, nameserver 체인이 물리 회선·프록시 출구와 맞지 않으면 “인터넷 없음” 배너가 뜨기도 합니다. Windows 설정의 어댑터별 DNS, 브라우저의 보안 DNS(HTTPS)도 변수이므로, Clash 쪽 DNS 정책과 동시에 봐야 합니다. 자세한 설계는 DNS 유출 방지 가이드에서 이어집니다.
# tun + dns sketch — comments in English per project convention
tun:
enable: true
stack: system
auto-route: true
strict-route: false
dns-hijack:
- any:53
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.example/dns-query위는 이해를 돕는 축약 예시이며, 키 이름·기본값은 사용 중인 코어 버전 문서와 반드시 대조해야 합니다.
일부 프로그램만 프록시를 안 탈 때
TUN을 켰는데도 특정 앱만 직통한다면 다음을 의심합니다.
- 관리자 권한 프로세스: 사용자 권한으로만 올라온 터널과 권한이 다른 프로세스 사이의 격리.
- 하드코딩된 DNS·DoH: 앱이 OS 리졸버를 우회.
- 규칙상 DIRECT·PROCESS·DOMAIN-SUFFIX 예외: 게임 안티치트·은행·사내 포털이 예외 목록에 들어간 경우.
- Loopback·UWP: 일부 스토어 앱은 루프백 격리 정책의 영향을 받습니다.
이때는 “전부 TUN으로”를 고집하기보다, 민감 앱만 DIRECT로 두는 스플릿 설계가 안정적일 때가 많습니다. 목표를 “가시성 있는 정책”으로 두고 로그로 실제 매칭 규칙을 확인하세요.
긴급 복구: 아무것도 안 될 때
원격으로 도움을 받기 어렵고 화면만 멈춘 것 같다면, 우선 TUN 스위치를 끄고 클라이언트를 종료합니다. 그래도 라우트가 남았다면 PC를 재부팅하는 것이 가장 빠른 초기화입니다. 지속된다면 Windows 네트워크 진단에서 어댑터 재설정, 또는 관리자 권한 명령 프롬프트에서 Winsock 스택 재설정(공식 문서 절차)을 검토하세요. 클라이언트가 제공하는 비상 “라우트 복구” 버튼이 있다면 우선 사용합니다.
투명성·다운로드 채널
코어 변경과 이슈는 Mihomo GitHub 저장소에서 추적할 수 있습니다. 다만 설치 패키지는 서명·배포 관점에서 공식 다운로드 페이지를 거치는 편이 안전합니다. Wintun 자체의 라이선스·바이너리는 각 클라이언트가 번들하는 방식을 따릅니다.
정리
Windows에서 Clash TUN 문제는 대부분 드라이버 설치·권한·다른 VPN과의 라우팅 충돌·DNS 경로 네 축 중 하나에서 드러납니다. 증상이 “설치 단계”인지 “켠 직후 네트워크 전체”인지 먼저 갈라 쓰고, strict-route·스택·하이재킹을 한 번에 하나씩 바꿔 보면 밤샘 재설치를 줄일 수 있습니다. 규칙형 클라이언트는 GUI와 코어를 최신에 가깝게 맞춰 두면 파서·TUN 스택 동작도 안정적인 편입니다.
처음 설정하는 분은 Clash 사용 문서에서 기본 연결 흐름을 익힌 뒤, 이 글의 Windows TUN 축을 덧붙이면 디버깅 순서가 훨씬 명확해집니다.