TUN 모드가 하는 일

많은 사용자가 Clash를 처음 켤 때 「시스템 프록시」만 켜 두고 사용합니다. 이 방식은 대부분의 데스크톱 브라우저처럼 운영체제가 제공하는 HTTP·SOCKS 프록시 설정을 따르는 프로그램에는 잘 맞습니다. 그러나 게임 런처, 일부 전자 메일 클라이언트, 터미널에서 돌아가는 curl이나 git, 그리고 프록시 환경 변수를 무시하는 백그라운드 서비스는 시스템 프록시 밖으로 그대로 나가기 쉽습니다.

TUN 모드는 이런 틈을 줄이기 위해 설계되었습니다. Clash(Mihomo) 코어가 가상의 네트워크 인터페이스(TUN 디바이스)를 만들고, 운영체제의 라우팅 테이블을 조정해 「이제 이 트래픽은 가상 카드를 통과한다」고 알려 줍니다. 그 결과 애플리케이션이 자체적으로 프록시를 지원하지 않아도, 커널이 먼저 패킷을 Clash로 넘기고 Clash가 규칙(rules)에 따라 노드로 보낼지 직접 연결할지 결정합니다. 말하자면 전역에 가까운 트래픽 인터셉션이 가능해집니다.

이 글에서는 TUN이 시스템 프록시와 어떻게 다른지, Windows와 macOS에서 안전하게 켜는 순서, 그리고 DNS·스택 옵션을 건드릴 때 자주 생기는 문제를 한국어 사용자 관점에서 풀어 설명합니다. 기본 설치와 구독 반영은 문서 페이지의 설치·설정 가이드와 함께 보시면 흐름이 더 매끄럽습니다.

ℹ️
용어: 「글로벌 모드」라는 표현은 클라이언트 UI에서 모든 도메인을 프록시 그룹으로 보내는 프리셋을 가리키는 경우가 많고, TUN은 그와 별개로 패킷이 들어오는 경로를 바꿉니다. TUN을 켠 뒤에도 규칙 기반으로 국내 사이트는 직접 연결(DIRECT)로 두는 것이 일반적입니다.

시스템 프록시와 비교하면

시스템 프록시는 운영체제가 앱에게 「HTTP 프록시 주소는 여기, 포트는 여기」라고 알려 주는 방식입니다. 앱이 그 정보를 읽고 스스로 프록시 프로토콜로 연결해야 하므로, 무시하는 앱은 예외 없이 직접 회선으로 나갑니다. 반면 TUN은 라우팅 계층에서 동작하므로, 앱이 의식하지 않아도 패킷이 먼저 Clash 쪽 인터페이스로 들어옵니다.

장점은 명확합니다. UDP 기반 게임, QUIC, 일부 VoIP, 터미널 도구 등 프록시 미지원이어도 규칙만 맞으면 노드를 탈 수 있습니다. 단점은 권한과 드라이버가 필요하고, 설정이 잘못되면 순간적으로 전체 인터넷이 끊긴 것처럼 보일 수 있다는 점입니다. 또 다른 VPN이나 필터 드라이버와 동시에 켜 두면 경로가 꼬이기도 하므로, TUN을 켤 때는 불필요한 가상 어댑터나 「전체 터널」형 앱을 잠시 끄고 테스트하는 것이 좋습니다.

전 트래픽을 「완전히」 넘긴다는 말의 의미

현실에서는 「물리적으로 100퍼센트 모든 바이트」를 한 코어가 다 가져간다고 말하기 어렵습니다. 운영체제 예외 경로, 하드코딩된 로컬 대역, 방화벽 정책, 관리자 권한 밖 프로세스 등 변수가 있기 때문입니다. 다만 사용자 입장에서 일상적으로 쓰는 앱의 대부분이 같은 규칙 세트를 통과하도록 만들고 싶다면, TUN이 시스템 프록시보다 훨씬 가깝습니다.

Clash의 규칙 엔진은 TUN으로 들어온 연결도 동일하게 처리합니다. GEOIP로 국내 IP는 DIRECT, 해외 도메인은 선택한 프록시 그룹으로 보내는 식의 분할이 가능합니다. 즉 「전역 프록시」를 UI에서 선택했다고 해서 반드시 모든 트래픽이 해외 노드로만 가는 것은 아니며, YAML의 rules가 최종 판사입니다. TUN은 그 판사 앞까지 패킷을 확실히 데려오는 역할에 가깝습니다.

설정 파일에서의 tun 블록 개요

GUI 클라이언트는 스위치 하나로 TUN을 켜 주지만, 내부적으로는 config.yaml의 tun 섹션이 갱신됩니다. Mihomo 계열에서 자주 보이는 옵션은 다음과 같습니다. 값은 환경에 맞게 조정해야 하며, 아래는 이해를 돕는 예시입니다.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  # strict-route: true   # use when you need tighter routing control
  dns-hijack:
    - any:53

stack에는 system, gvisor, mixed 등이 있으며, 플랫폼과 코어 버전에 따라 권장값이 다릅니다. 연결이 불안정하면 스택을 바꿔 보는 것이 실무에서 가장 빠른 진단 방법 중 하나입니다. auto-route와 auto-detect-interface는 기본 게이트웨이를 자동으로 잡아 주는 편의 기능이지만, 복수 VPN을 쓰는 환경에서는 충돌 소지가 있으니 그때는 수동 라우팅 문서를 함께 참고하는 것이 안전합니다.

Windows에서 TUN 켜기

Windows에서는 Wintun 계열 드라이버가 함께 설치되는 빌드를 쓰는 경우가 많습니다. Clash Verge Rev나 FlClash 등을 다운로드 페이지에서 설치했다면, 첫 TUN 시도 시 UAC(사용자 계정 컨트롤) 창이 뜨는 것이 정상입니다. 관리자 권한 없이는 가상 어댑터가 올라가지 않아 「켰는데 전부 끊긴다」는 증상이 나올 수 있습니다.

권장 순서

  1. 기존에 다른 상용 VPN이 켜져 있다면 잠시 종료합니다.
  2. 클라이언트를 관리자 권한으로 실행한 뒤, 설정에서 TUN 또는 「가상 어댑터」 항목을 활성화합니다.
  3. 장치 관리자에 새 네트워크 어댑터가 생겼는지 확인합니다. 이름은 빌드마다 다르지만 Clash·Wintun 등과 연관된 표기가 흔합니다.
  4. 브라우저뿐 아니라 PowerShell에서 curl https://ipinfo.io/ip 등을 실행해 IP가 기대한 경로로 바뀌는지 확인합니다.
⚠️
주의: TUN을 켠 채로 잘못된 규칙만 있으면 루프에 빠져 DNS조차 나가지 못할 수 있습니다. 원격 구성을 많이 수정한다면, 물리 케이블·테더링 등 복구 경로를 마련한 뒤 시도하세요.

macOS에서 TUN 켜기

macOS는 시스템 확장·헬퍼 도구에 대한 승인이 엄격합니다. 메뉴 막대형 클라이언트는 헬퍼 설치를 요구하며, 비밀번호 입력 후에야 TUN이 안정적으로 동작하는 경우가 많습니다. 최신 macOS에서는 「시스템 설정 → 개인정보 보호 및 보안」에서 차단된 확장을 허용해야 하는 단계가 추가되기도 합니다.

Apple 실리콘과 Intel 맥 모두에서, 한 번 헬퍼 설치에 실패하면 이후에도 TUN만 꺼진 채로 남는 경우가 있습니다. 이때는 공식 문서나 사용 중인 클라이언트의 FAQ에 따라 헬퍼를 제거 후 재설치하는 절차를 밟는 것이 빠릅니다. Safari는 되는데 특정 앱만 직행한다면, 해당 앱이 자체 프록시를 강제하는지와 별개로 TUN 경로에 올라탔는지를 먼저 확인해 보세요.

DNS와 fake-ip를 TUN과 함께 쓸 때

트래픽을 가로채도 DNS가 애매하면 「사이트는 뜨는데 이상한 지역으로 간다」는 현상이 납니다. Clash는 dns 블록에서 enhanced 모드나 fake-ip를 쓸 수 있는데, TUN과 조합할 때는 dns-hijack으로 53번 포트를 코어로 끌어오는 구성이 자주 등장합니다. 이유는 앱이 시스템 리졸버 대신 고정 DNS를 쓰더라도 터널 안에서 일관되게 처리하려는 목적입니다.

초보자에게는 GUI의 기본 DNS 프리셋을 유지한 채 TUN만 먼저 켜 보고, 문제가 없으면 점진적으로 fake-ip-filter 등을 조정하는 방식이 부담이 적습니다. 한 번에 여러 옵션을 바꾸면 원인 분석이 어려워집니다.

자주 겪는 문제와 점검 순서

전체 인터넷이 끊긴 것처럼 보인다

Windows에서는 관리자 권한과 드라이버 설치 실패를 의심합니다. macOS에서는 헬퍼·시스템 확장 승인을 다시 확인합니다. 그다음 tun의 auto-route와 다른 VPN의 전체 트래픽 모드가 겹치는지 봅니다.

브라우저만 되고 터미널은 안 된다

시스템 프록시만 켜져 있을 가능성이 큽니다. TUN 스위치가 실제로 ON인지, 코어 로그에 TUN 관련 오류가 없는지 확인하세요.

지연 시간이 갑자기 나빠진다

스택 변경(gvisor ↔ system), MTU 이슈, 또는 특정 노드의 UDP 처리 품질을 의심합니다. 동일 노드에 시스템 프록시만 켰을 때와 비교해 보는 것이 좋습니다.

✅
팁: 규칙 세트를 크게 바꾼 뒤에는 클라이언트의 연결 로그를 잠시 켜 두고, 어떤 도메인이 어떤 정책으로 매칭되는지 확인하면 「전역처럼 보이지만 사실 DIRECT」 같은 오해를 줄일 수 있습니다.

보안과 신뢰할 수 있는 클라이언트

TUN은 네트워크 스택에 깊게 관여하므로, 출처가 분명한 클라이언트와 구독을 쓰는 것이 중요합니다. 오픈 소스라고 해서 빌드마다 동일하지는 않으니, 가능하면 검증된 릴리스와 체크섬을 확인하고, 불필요한 서드파티 플러그인은 줄이는 편이 안전합니다. 소스 코드와 이슈 트래커는 신뢰 형성에 도움이 되므로, 설치와 별도로 GitHub 저장소를 참고하는 것도 좋습니다. 다만 일상 설치용 패키지는 공식 다운로드 페이지를 우선하는 것이 혼선을 줄입니다.

정리

TUN 모드는 「모든 앱이 프록시 API를 구현해 주기를 기다리지 않고도」 넓은 범위의 트래픽을 Clash 규칙 아래로 가져오는 실용적인 방법입니다. 설정 비용은 시스템 프록시보다 크지만, 한 번 이해해 두면 게임·개발 도구·UWP까지 한 번에 다루는 경험이 가능해집니다.

동일한 Mihomo 코어를 쓰는 여러 GUI는 세부 스위치 이름만 다를 뿐 개념은 같습니다. 규칙은 YAML로 명확히 남기고, TUN은 그 규칙이 실제 패킷에 적용되도록 연결해 주는 다리라고 기억하면 설정이 수월합니다. 다른 도구에 비해 한 앱에서 구독·규칙·TUN까지 정리되는 편이라, 매일 켜고 끄는 부담도 상대적으로 적은 편입니다.

지금 환경에 맞는 설치 파일은 Clash 공식 다운로드 페이지에서 고를 수 있습니다. → Clash를 무료로 내려받아 TUN까지 포함한 매끄러운 프록시 경험을 바로 확인해 보세요.