TUN 모드 완벽 가이드: 글로벌 투명 프록시 원리와 설정 방법

Clash를 사용할 때 대부분의 사람이 가장 먼저 마주치는 문제는 다음과 같습니다. 왜 프록시를 켰는데도 게임은 여전히 국내 회선으로 연결될까요? 왜 git clone은 프록시를 거치지 않을까요? 왜 명령줄 도구는 별도로 설정해야 할까요? 이러한 문제의 근본 원인은 시스템 프록시의 동작 방식에 있습니다. 시스템 프록시는 모든 애플리케이션을 커버하지 못합니다. TUN 모드는 이 문제를 해결하는 궁극적인 방법이며, 본 글에서 이를 깊이 있게 이해해 보겠습니다.

시스템 프록시의 한계

「시스템 프록시」 모드의 동작 방식은 운영체제에 "HTTP/HTTPS 요청을 로컬 127.0.0.1:7890으로 보내달라"고 알리는 것입니다. 이 방식에는 근본적인 한계가 있습니다. 시스템 프록시 설정을 능동적으로 읽어 들이는 애플리케이션만이 이를 따른다는 점입니다.

브라우저(Chrome, Firefox, Safari)는 기본적으로 시스템 프록시 설정을 따르지만, 다음과 같은 유형의 프로그램은 대개 따르지 않습니다.

게임 클라이언트(Steam, Epic Games, 각종 온라인 게임 클라이언트)
명령줄 도구(git, curl, wget, npm, pip)
Windows UWP 앱(Microsoft Store에서 설치한 앱)
일부 Electron 앱 및 저수준 네트워크 라이브러리를 직접 호출하는 프로그램
UDP 프로토콜을 사용하는 거의 모든 프로그램(대다수의 게임과 화상 통화 포함)

또한 시스템 프록시는 HTTP/HTTPS 프로토콜의 트래픽만 프록시할 수 있을 뿐, 네이티브 TCP 연결과 UDP 트래픽은 처리하지 못합니다. 이는 이론적으로 "프록시를 지원하는" 앱이라 하더라도 그 UDP 트래픽은 프록시를 우회하여 직접 나간다는 것을 의미합니다.

TUN 모드의 동작 원리

TUN(Tunnel Network Interface)은 운영체제가 제공하는 일종의 가상 네트워크 어댑터 인터페이스입니다. 링크 계층에서 동작하는 TAP 인터페이스와 달리, TUN은 네트워크 계층(IP 계층)에서 동작하며 IP 데이터 패킷을 직접 읽고 쓸 수 있습니다.

Clash의 TUN 모드 동작 흐름은 다음과 같습니다.

Clash가 운영체제에 가상 네트워크 어댑터(일반적으로 Mihomo 또는 utun0이라는 이름)를 하나 생성하도록 요청합니다.
시스템 라우팅 테이블을 수정하여, 특정 목적지 IP 대역의 아웃바운드 트래픽을 이 가상 어댑터로 리디렉션합니다.
Clash 코어가 가상 어댑터에서 원본 IP 데이터 패킷을 읽어 들여, 목적지 주소와 프로토콜 유형을 파싱합니다.
TCP 트래픽의 경우 Clash가 로컬 TCP 연결을 만들어 데이터를 수신한 뒤, 규칙에 따라 프록시 노드로 전달하거나 직접 연결합니다. UDP 트래픽도 동일하게 처리합니다.
프록시 노드 또는 직접 연결 서버에서 돌아온 데이터를 다시 캡슐화하여 가상 어댑터에 기록하고, 운영체제가 요청을 보낸 애플리케이션으로 라우팅하도록 넘깁니다.

애플리케이션 계층이 아니라 네트워크 계층에서 트래픽을 가로채기 때문에, 프록시 프로토콜 지원 여부와 무관하게 모든 프로그램의 아웃바운드 네트워크 패킷이 포착되어 처리됩니다. 이것이 바로 TUN 모드가 진정한 글로벌 프록시를 실현할 수 있는 근본적인 이유입니다.

TUN 모드는 가상 네트워크 어댑터를 생성하고 시스템 라우팅 테이블을 수정해야 하며, 이 두 작업 모두 관리자 권한(Windows UAC 권한 상승) 또는 Root/sudo(Linux/macOS) 권한이 필요합니다. 이는 프로그램이 "과도한 권한을 요구하는" 것이 아니라, 운영체제의 보안 메커니즘에 따라 정해진 것입니다.

fake-ip: TUN 모드의 DNS 해법

TUN 모드에서는 DNS 처리 방식이 매우 중요해지며, 가장 문제가 발생하기 쉬운 부분이기도 합니다. 먼저 전통적인 DNS 흐름을 살펴보겠습니다.

애플리케이션 → DNS 조회: example.com → 실제 IP 203.0.113.1 획득 → 해당 IP로 TCP 연결 시도

문제는 다음과 같습니다. Clash가 TUN 계층에서 203.0.113.1로 향하는 TCP 연결 요청을 가로챌 때, IP 주소만 보일 뿐 이 연결이 어떤 도메인에 해당하는지 알 수 없다는 점입니다. 그런데 Clash의 규칙 시스템은 도메인 매칭(DOMAIN-SUFFIX, DOMAIN-KEYWORD)에 크게 의존하므로, 도메인이 없으면 올바르게 라우팅할 수 없습니다.

fake-ip 모드는 이 문제를 우아하게 해결하는 방법입니다.

애플리케이션이 example.com에 대한 DNS 조회를 시작합니다.
Clash가 이 DNS 조회를 가로채 즉시 가짜 IP(예: 198.18.0.1)를 반환하고, 내부적으로 198.18.0.1 → example.com 매핑 관계를 기록합니다.
애플리케이션은 가짜 IP를 받아 198.18.0.1로 TCP/UDP 연결을 시도합니다.
Clash가 TUN 계층에서 이 연결 요청을 가로채 내부 매핑 테이블을 조회하여, 목적지가 example.com임을 알아냅니다.
Clash가 도메인 규칙에 따라 프록시로 보낼지 직접 연결할지 결정합니다. 프록시로 보낼 경우, 프록시 노드가 목적지에서 실제 DNS 해석을 완료합니다. 직접 연결할 경우, Clash가 실제 DNS를 다시 조회한 뒤 연결을 수립합니다.

fake-ip의 핵심 장점은 다음과 같습니다. 민감한 도메인의 DNS 조회가 전적으로 프록시 노드 측에서 완료되어 DNS 유출을 완전히 방지합니다. 동시에 Clash가 도메인 정보를 파악하고 있으므로 규칙 매칭의 정확도가 크게 향상됩니다.

TUN 모드 켜기

Clash Verge Rev(Windows / macOS)

클라이언트를 열고 왼쪽의 「설정」 아이콘을 클릭합니다.
「TUN 모드」(또는 「Tun Mode」) 스위치를 찾아 클릭하여 켭니다.
시스템에서 권한 요청 창이 뜨면 Windows에서는 「예」를 클릭하고, macOS에서는 시스템 비밀번호를 입력하여 확인합니다.
최초 활성화 시 백그라운드에서 가상 네트워크 어댑터 드라이버(Mihomo)를 설치하므로 5~10초 정도 기다립니다.
클라이언트 상태가 「TUN 활성화됨」으로 바뀌면, 이때부터 모든 아웃바운드 트래픽을 Clash가 제어합니다.

전체 YAML 설정(Mihomo 코어)

tun:
  enable: true
  stack: mixed        # mixed / system / gvisor
  dns-hijack:
    - any:53          # hijack all DNS queries
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  nameserver:
    - https://1.1.1.1/dns-query    # Cloudflare DoH
    - https://8.8.8.8/dns-query    # Google DoH
  fallback:
    - https://1.0.0.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

TUN Stack 모드 상세 해설

TUN의 stack 파라미터는 포착된 네트워크 패킷을 어떻게 처리할지를 결정하며, 성능·호환성·안정성에 직접적인 영향을 미칩니다.

mixed(권장): TCP 트래픽은 시스템 네이티브 네트워크 스택으로 처리하고, UDP 트래픽은 gVisor 사용자 공간 구현으로 처리합니다. 호환성과 성능 사이에서 최상의 균형을 이루며, 대다수 사용자에게 적합합니다.
system: TCP와 UDP를 모두 운영체제 네트워크 스택에 맡깁니다. 성능이 가장 뛰어나고 CPU 점유율이 가장 낮지만, Linux의 일부 커널 버전에서는 호환성 문제가 있을 수 있습니다. 극한의 성능을 추구하는 서버 환경에 권장합니다.
gvisor: TCP와 UDP를 모두 사용자 공간에서 완전한 네트워크 스택으로 에뮬레이션합니다(Google gVisor 프로젝트). 호환성이 가장 좋아 모든 엣지 케이스를 처리할 수 있지만, CPU와 메모리 오버헤드가 mixed보다 20~40% 높습니다. mixed 모드에서 이상한 문제가 발생할 때 전환하여 시도해 볼 수 있습니다.

자주 묻는 질문과 문제 해결

로컬 네트워크 기기(프린터, NAS, 라우터 관리 페이지)에 접근할 수 없음

TUN 모드는 auto-route를 통해 모든 트래픽을 제어하므로, 로컬 네트워크 IP 대역의 트래픽도 프록시 출구로 라우팅되어 자연히 로컬 기기에 도달하지 못합니다. 규칙 파일의 맨 앞부분에 다음과 같은 직접 연결 규칙을 추가하면 됩니다.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # ... 기타 규칙

Clash를 종료한 후 네트워크가 끊김

Clash를 종료하기 전에 반드시 설정에서 TUN 스위치를 먼저 끄고, 프로그램이 라우팅 테이블 항목을 정리할 기회를 주어야 합니다. 이미 네트워크가 끊겼다면 Clash를 다시 켜고 → TUN을 끈 뒤 → 프로그램을 종료하세요. 또는 장치 관리자(Windows)에 들어가 Mihomo라는 이름의 가상 네트워크 어댑터를 비활성화하고 네트워크를 재시작하면 복구됩니다.

fake-ip-filter 화이트리스트가 부족함

로컬 개발 도메인(예: localhost, *.test), 기업 내부망 도메인, 일부 국내 앱(QQ, 위챗)의 특수 서비스 도메인이 fake-ip 처리를 거치면 연결이 실패할 수 있습니다. 이러한 도메인을 fake-ip-filter 목록에 추가하면, Clash가 가짜 IP를 반환하는 대신 실제 DNS 해석을 수행합니다.

TUN 모드를 켠 후 CPU 점유율이 높아짐

이는 정상적인 현상입니다. TUN 모드는 모든 네트워크 패킷을 사용자 공간에서 처리해야 하므로, 시스템 프록시 모드보다 CPU 오버헤드가 10~30% 높습니다. CPU 점유율이 비정상적으로 높다면(20% 초과) 다음을 시도해 보세요. stack을 gvisor에서 mixed로 전환하기, 다량의 UDP 트래픽(예: P2P)이 Clash를 거치고 있지 않은지 확인하기.

정리

TUN 모드는 Clash에서 가장 강력하고 가장 완전한 프록시 모드입니다. 가상 네트워크 어댑터를 통해 네트워크 계층에서 모든 트래픽을 가로채고, fake-ip DNS 메커니즘과 결합하여 도메인 기반의 정확한 라우팅을 구현함으로써, 시스템 프록시 모드의 제한적인 커버리지 문제를 완전히 해결합니다.

일상적인 브라우저 사용에는 시스템 프록시 모드만으로도 충분합니다. 하지만 게임, 명령줄 도구 또는 모든 앱의 트래픽을 프록시해야 한다면 TUN 모드가 유일한 선택지입니다. 로컬 네트워크 직접 연결 규칙과 fake-ip-filter 화이트리스트를 잘 설정해 두면, TUN 모드는 매우 안정적으로 동작할 수 있습니다.