Clash Verge RevWindows 11에 올려 설치·첫 연결까지 끝낸 뒤에도, 여전히 일부 프로그램만 프록시를 타지 않는다고 느끼는 경우가 많습니다. 이때 검색 의도는 보통 두 갈래로 모입니다. 첫째, 가능하면 전역에 가깝게 트래픽을 한 코어 아래로 모으고 싶다. 둘째, 그 과정에서 DNS 누수·도메인 매칭 실패·fake-ip와 실제 해석 불일치 같은 부수 문제를 피하고 싶다는 것입니다. 이 글은 범용 완전 설정이 아니라 TUN 모드DNS, 그리고 Wintun·관리자 권한만 분리해 순서대로 짚습니다. 이미 구독·노드 전환까지 맞춰 두었다면 프로필 자체는 건드리지 않아도 되고, 출구 줄과 규칙이 살아 있는지 전제로 합니다.

왜 TUN인가: 시스템 프록시와 무엇이 다른지

Windows에서 흔히 켜 두는 것은 시스템 프록시입니다. 브라우저나 WinHTTP 프로필을 따르는 앱은 여기서 잘 따라옵니다. 그러나 자체 소켓을 열거나 프록시 환경 변수를 무시하는 프로세스, UWP 계열 일부, 특정 게임·런처·개발 도구는 HTTP 프록시 훅만으로는 빗나갑니다. TUN은 OS에 가상 네트워크 인터페이스를 하나 올려, 라우팅·패킷 단에서 코어가 개입할 여지를 만듭니다. 말 그대로 “한 겹 아래”에서 잡는 방식이라, 전역에 가깝게 돌리고 싶을 때 선택지가 됩니다.

대신 부작용도 분명합니다. 라우팅 테이블과 DNS 질의 경로가 바뀌므로 회사 VPN이나 다른 상용 VPN과 동시에 켜 두면 충돌이 잦고, 잘못된 프로필이면 로컬 LAN이나 내부 전용 이름이 끊길 수 있습니다. “스위치 하나로 끝나는 앱”과 달리, 어떤 트래픽을 DIRECT로 남길지가 프로필 규칙과 같이 봐야 안전합니다.

시작 전에 맞출 것: 빌드, 백신, 다른 VPN

아래를 먼저 적어 두면 같은 증상을 두 번 보지 않습니다.

  • Windows 11 최신 누적 업데이트와 Clash Verge Rev 최신 릴리스. 내장 Mihomo 버전이 구버전이면 TUN 스택 옵션이 문서와 다를 수 있습니다.
  • Windows Defender 방화벽 또는 제3자 백신이 클라이언트·코어 실행 파일을 차단하지 않았는지. 첫 실행 때만 허용하고 이후 업데이트에 막히는 패턴도 있습니다.
  • 동시에 켜 둔 WireGuard/OpenVPN/WARP 등 다른 터널 앱은 끕니다. 둘 다 TUN 후보를 잡으려 하면 어댑터 이름 충돌·라우팅 꼬임이 납니다.
  • Hyper-V·다른 가상 스위치를 쓰는 개발 환경이면, 브리지·내부망 라우팅이 특수합니다. 회사 장비에서는 IT 정책으로 가상 어댑터 추가 자체가 막힐 수 있습니다.

1단계: Wintun과 관리자 권한 준비

Windows에서 Clash 계열이 말하는 TUN 스택은 대개 Wintun 사용자 공간 드라이버에 기대거나, 제공업체가 번들한 모듈을 설치합니다. 설치 프로그램이 한 번이라도 실패했다면 장치 관리자에 알 수 없는 장치·경고가 남을 수 있습니다. 그 상태에서 토글만 반복하면 로그에 어댑터 생성 실패 같은 메시지가 맴돌고 끝납니다.

관리자 권한은 선택이 아니라 전제인 경우가 많습니다. 우클릭 실행뿐 아니라, 작업 표시줄 자동 시작이 일반 권한으로 뜨면 사용자가 매번 수동 올림을 해야 할 수 있습니다. 실무에서는 바로가기·작업 스케줄러 중 편한 쪽으로 “항상 높임”을 맞춥니다만, 회사 표준 이미지에서는 정책으로 막힙니다.

: UAC 프롬프트가 귀찮다고 보안 프로그램이 “항상 허용”으로 덮어쓴 뒤, 조용히 업데이트만 막히는 사례가 있습니다. 허용 목록에는 실행 파일 경로 버전까지 같이 넣어 두는 편이 낫습니다.

2단계: Clash Verge Rev에서 TUN 켜기

빌드마다 메뉴 문자열이 조금 다르지만 흐름은 비슷합니다. 설정·시스템·TUN 혹은 가상 어댑터에 해당하는 스위치를 찾아 켭니다. 이때 함께 보이는 항목으로는 스택 종류, IPv6, 자동 라우팅, 엄격한 라우트 같은 이름이 있습니다. 프로필에서 이미 IPv6 OUT을 막아 두었는데 UI만 켜 두면 증상이 엇갈릴 수 있으니, RAW 편집과 UI 토글을 한 세트로 생각합니다.

  1. 트레이에서 코어가 실행 중인지 확인합니다. 멈춘 상태에서 TUN만 켜면 변화가 없습니다.
  2. TUN을 켠 뒤 적용·재시작이 따로 있으면 누릅니다. 일시적으로 인터넷이 끊겼다가 돌아오는 것은 라우팅이 갱신되는 일반적인 패턴입니다.
  3. ipconfig /all이나 설정 앱의 어댑터 목록에 새 가상 인터페이스가 보이는지 확인합니다. 이름은 환경마다 다릅니다.
  4. 로그에 repeat error가 쌓이면 권한·충돌부터 의심하고, 동시에 다른 VPN을 끕니다.

3단계: DNS와 fake-ip를 프로필과 맞추기

TUN을 켰다고 해서 DNS가 자동으로 이상해지는 것은 아니지만, 질의 경로가 코어로 붙는 순간 프로필의 dns 블록이 드러납니다. 여기서 많이 막히는 키가 enhanced-mode와 그 값인 fake-ip·redir-host입니다.

fake-ip는 로컬에서 일단 응답을 돌려 주고 규칙 매칭을 태우는 흐름에 강합니다. 지연을 줄이는 데 유리하지만, 내부 전용 도메인이나 스플릿 도메인이 섞인 환경에서는 예외가 길어질 수 있습니다. 반면 redir-host는 실제 해석에 더 가깝게 붙는 편이라, 집 NAS·프린터·사내 포털을 자주 쓰는 사용자에게는 디버깅이 수월한 경우가 있습니다. “어느 쪽이 정답”보다 내 프로필이 어떤 가정을 두고 짰는지가 중요합니다.

  • nameserverfallback 목록이 비어 있거나 막힌 DNS만 가리키면, TUN 이후에만 터지는 것처럼 보이기도 합니다.
  • TLS·HTTPS DNS를 쓸 때는 시스템 시간·인증서·회사 SSL 가시화 장비를 같이 봅니다.
  • sniffer나 SNI 기반 보조가 켜진 프로필은 fake-ip와 조합 규칙이 길어질 수 있어, 제공업체 문서의 권장 세트를 따르는 편이 안전합니다.
참고: 브라우저의 “시큐어 DNS”나 DoH 전용 확장은 OS DNS와 별도 길을 탈 수 있습니다. “TUN을 켰는데도 DNS만 이상하다”면 앱별 설정을 먼저 끕니다.

4단계: 연결 검증과 로그로 근거 남기기

체감만으로 판단하면 원인을 놓칩니다. 아래를 최소 세트로 권합니다.

  1. 브라우저로 일반 사이트와 IP 직접 확인 사이트를 같이 열어, 기대한 노드 국가가 맞는지 봅니다.
  2. curl 같은 CLI가 있다면 프록시 환경 변수 없이 동작하는지 확인합니다. 시스템 프록시만 켰을 때와 TUN 켰을 때 차이가 나야 합니다.
  3. Verge의 로그에서 실제로 어떤 policy·아웃바운드를 탔는지 줄 단위로 확인합니다. “느리다”는 감정보다 어느 줄을 탔는지가 먼저입니다.
  4. 문제가 DNS인지 라우팅인지 갈라내려면, 동일 도메인에 대해 시스템 해석코어 로그의 질의를 비교합니다.

자주 보는 오류와 역추적 순서

  • Access denied / 권한 부족: 관리자 실행·UAC·백신 행동 차단부터 봅니다.
  • TUN already in use 류: 다른 VPN·가상화 스위치·이전 세션이 점유 중인지 종료합니다.
  • 일부 사이트만 안 열림: fake-ip 예외·규칙 순서·DNS 폴백을 의심합니다. 캐시만 지우고 반복하지 말고 로그를 봅니다.
  • IPv6 경로만 이상: OS IPv6 켜짐·프로필 OUT·UI IPv6 토글을 한 묶음으로 맞춥니다.
  • WSL·Docker Desktop: 가상 브리지와 라우팅이 추가됩니다. 개발 중이라면 Microsoft 문서와 Clash 규칙을 같이 적어 두는 편이 낫습니다.

자주 묻는 질문

질: TUN 없이 시스템 프록시만으로는 부족한가요?
답: 브라우저와 WinHTTP를 따르는 앱은 충분한 경우가 많습니다. 자체 스택을 쓰는 터미널·게임 런처·일부 Store 앱은 TUN으로 잡는 편이 확실합니다.

질: fake-ip와 redir-host 중 무엇을 써야 하나요?
답: fake-ip는 규칙 매칭·지연 면에서 강점이 있고, 내부 NAS·전용 DNS 예외가 많으면 redir-host나 세분 설정을 검토합니다. 프로필 가정과 어긋나면 증상이 국소적으로만 납니다.

질: 관리자 권한 없이 TUN이 안 켜질 때는?
답: 가상 어댑터와 라우팅 변경에 권한이 필요합니다. 바로가기 고상 승격이나 회사 정책을 확인합니다.

질: Wintun 오류가 반복될 때는?
답: 다른 VPN 점유·드라이버 경고·잔재 드라이버를 확인하고, 재부팅 후 Verge·모듈을 최신으로 맞춘 뒤 방화벽을 재검토합니다.

한 가지 기능만 깊게 파도 Clash 호환 줄이 편한 이유

상용 VPN 앱은 버튼 한 번에 터널을 올리지만, 도메인·앱별로 다른 출구를 유지해야 할 때는 내부 동작을 숨겨 디버깅이 어려워지는 편입니다. 업데이터가 멈춘 포크 패키지에 오래 묶여 있으면, 새 구독 문법과 TUN 스택 옵션을 동시에 맞추느라 시간이 더 들기도 합니다.

반면 같은 YAML 호환 규격을 전제로 한 Clash 라인업은 클라이언트만 교체해도 패널이 주는 레시피를 그대로 이어 붙이기 쉽고, 오늘 정리한 Wintun·권한·TUN 스위치·DNS·fake-ip 검증은 다른 OS 글과도 대응 개념이 같아 학습 비용이 누적됩니다. 어느 한 앱을 대신 홍보하기보다, 출처와 로그로 스스로 근거를 남기는 습관이 장기적으로 가장 안전합니다. 아래 링크에서 최신 클라이언트를 골라 두면 이번 흐름을 그대로 반복 적용하기 쉽습니다.

최신 Clash 클라이언트를 받아 Windows 11에서 TUN과 DNS 설정을 마무리하기 →