Clash TUN 모드란? 가상 네트워크 카드로 전체 트래픽을 관리하는 원리와 설정 방법

TUN이 필요한 이유: 시스템 프록시의 세 가지 사각지대

대부분의 Clash 클라이언트는 기본적으로 시스템 프록시 방식으로 동작합니다. 코어가 로컬에서 HTTP/SOCKS 혼합 포트를 열고, 이 주소를 운영체제의 프록시 설정에 등록하는 방식입니다. 배포는 간단하지만 구조적으로 세 가지 사각지대가 있습니다.

• 설정을 따르는 앱만 처리됩니다. 프록시를 사용할지는 각 앱이 자체적으로 결정하며, 시스템 프록시 설정을 읽는 프로그램만 트래픽을 코어에 넘깁니다. git, curl, npm, docker 같은 다수의 커맨드라인 도구, 대부분의 게임, 일부 데스크톱 소프트웨어는 이 설정을 읽지 않아 트래픽이 그대로 프록시를 우회합니다.
• TCP만 처리합니다. 시스템 프록시는 UDP와 ICMP를 다루지 못하므로 음성 통화, 온라인 게임, QUIC 등 UDP 기반 트래픽은 관리 대상에서 벗어납니다.
• DNS는 여전히 로컬 통신사 경로를 탑니다. 앱이 직접 도메인을 해석하며, 그 결과가 오염될 수 있고, 오염된 잘못된 IP를 프록시에 넘겨도 소용이 없습니다.

TUN 모드의 접근 방식은 관리 지점을 애플리케이션 계층에서 네트워크 계층으로 옮기는 것입니다. 코어가 가상 네트워크 카드를 하나 만들고, 운영체제가 모든 아웃바운드 IP 패킷을 여기로 라우팅하게 함으로써 애플리케이션은 이를 전혀 인지하지 못한 채 동작합니다.

동작 원리: 가상 네트워크 카드가 전체 트래픽을 처리하는 방식

TUN은 운영체제가 제공하는 3계층 가상 네트워크 장치로, 원시 IP 패킷이 오갑니다. 2계층에 해당하는 버전은 TAP이라 부르며 이더넷 프레임을 처리합니다. Clash 계열 코어(mihomo 등)가 사용하는 것은 TUN입니다.

TUN을 켜면 코어는 다음 세 가지 작업을 순서대로 수행합니다.

1. 장치 생성. Windows에서는 wintun 드라이버를 로드해 가상 네트워크 카드를 만들고, macOS에서는 utun 장치를 생성하며, Linux에서는 /dev/net/tun을 엽니다.
2. 라우팅 접수. 시스템 라우팅 테이블을 수정해 기본 라우트를 가상 네트워크 카드로 향하게 하고(auto-route), 동시에 물리 네트워크 카드를 실제 출구로 기록합니다(auto-detect-interface).
3. 패킷 단위 처리. 코어가 가상 네트워크 카드에서 IP 패킷을 읽어 TCP 세션을 재구성하고 UDP 전달 매핑을 만든 뒤, 설정된 규칙(DOMAIN-SUFFIX, GEOIP, IP-CIDR, MATCH 등)에 따라 해당 연결을 프록시 노드로 보낼지, 직접 연결할지, 아니면 차단할지 결정합니다.

프로토콜 스택(stack) 선택

원시 IP 패킷을 TCP/UDP 스트림으로 복원하려면 TCP/IP 프로토콜 스택이 필요한데, mihomo는 세 가지를 제공합니다. gVisor는 사용자 공간 구현으로 호환성이 가장 좋고, system은 운영체제 프로토콜 스택을 재사용해 오버헤드가 더 적으며, mixed는 TCP는 system, UDP는 gVisor로 처리하는 절충안입니다. 데스크톱 클라이언트는 보통 gVisor 또는 mixed를 기본값으로 사용하며, 일반적인 사용에서는 굳이 바꿀 필요가 없습니다.

fake-ip와의 연동

TUN은 대개 fake-ip 모드와 함께 동작합니다. 애플리케이션의 DNS 조회는 코어가 가로채고(dns-hijack), 코어는 198.18.0.0/16 대역 안의 가상 주소를 반환하면서 이를 도메인과 매핑해 기록합니다. 이후 애플리케이션이 이 가상 주소로 연결을 시도하면 코어가 실제 도메인을 역추적해 도메인 기반 규칙으로 정확히 분산 처리합니다. 이로써 두 가지 이점을 얻습니다. 첫째는 로컬 DNS 오염을 피할 수 있고, 둘째는 IP 패킷만 발생하는 상황에서도 도메인 기반 분산 처리가 그대로 작동한다는 점입니다.

TUN 모드와 시스템 프록시 비교

두 방식은 서로 충돌하지 않습니다. 대부분의 클라이언트는 시스템 프록시를 기본 안전망으로 유지할 것을 권장합니다. 시스템 프록시를 따르는 앱은 애플리케이션 계층 경로를 타고, 나머지 트래픽은 TUN이 네트워크 계층에서 받아냅니다.

플랫폼별 설정 방법

Windows (Clash Verge Rev 기준)

1. 설정 화면에서 「서비스 모드」(Service Mode)를 찾아 설치를 클릭합니다. 이 서비스는 시스템 서비스로 상시 실행되며 가상 네트워크 카드 생성을 담당합니다. 설치 후에는 메인 프로그램을 매번 관리자 권한으로 실행할 필요가 없습니다.
2. 설정으로 돌아가 「TUN 모드」 스위치를 켭니다.
3. 처음 활성화할 때 방화벽에 막히면 wintun 가상 네트워크 카드를 허용해 줍니다.

macOS

Clash Verge Rev나 ClashX Meta에서 TUN(향상 모드) 스위치를 켜면 시스템이 로그인 비밀번호를 요구합니다. 이는 utun 장치를 생성하기 위한 권한 있는 헬퍼를 설치하는 데 사용됩니다. 한 번 승인하면 이후에는 다시 묻지 않습니다.

Linux

TUN 장치를 만들려면 CAP_NET_ADMIN 권한이 필요합니다. root로 코어를 실행하거나, 코어 바이너리에 권한을 부여하면 됩니다.

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

Android와 iOS

모바일에는 별도의 스위치가 없습니다. Android 클라이언트(Clash Meta for Android, FlClash 등)는 시스템 VpnService를 기반으로 동작하고, iOS 클라이언트(Clash Plus 등)는 Network Extension의 Packet Tunnel을 기반으로 동작합니다. 이 둘은 본질적으로 가상 네트워크 카드 방식입니다. 이 때문에 모바일에서는 모든 앱의 트래픽을 전역적으로 처리할 수 있습니다.

직접 설정 작성 (심화)

mihomo 설정 파일을 직접 관리한다면 다음과 같이 설정하면 됩니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

auto-route는 기본 라우트를 관리하고, auto-detect-interface는 실제 출구 네트워크 카드를 식별하는 역할을 하며, 둘 다 반드시 필요합니다. dns-hijack은 53번 포트로 오는 DNS 조회를 코어로 가로챕니다.

TUN을 켜기 적합한 상황

• 게임과 실시간 음성 통화: UDP 트래픽은 TUN만 처리할 수 있으며, 사용 중인 노드가 UDP 포워딩을 지원해야 합니다.
• 커맨드라인과 개발 도구: git clone, curl, 패키지 매니저, 컨테이너 이미지 다운로드 등 시스템 프록시 설정을 읽지 않는 작업들.
• 프록시 설정을 따르지 않는 클라이언트: 일부 중국산 소프트웨어, 오래된 프로그램, 네트워크 스택이 하드코딩된 앱.
• 프로세스 기반 분산 처리: TUN이 트래픽을 처리하면 코어가 연결이 어느 프로세스에서 발생했는지 알 수 있어 PROCESS-NAME 규칙과 함께 세밀한 분산 처리를 할 수 있습니다.

반대로 일상적인 웹 브라우징이 주된 사용자라면 TUN을 켜든 안 켜든 큰 차이가 없으며, 시스템 프록시만으로도 충분하므로 굳이 켤 필요는 없습니다.

자주 발생하는 충돌과 해결법

다른 VPN, 가속기와의 공존

VPN 계열 도구는 모두 기본 라우트를 자신이 관리하려고 하므로, 두 개를 동시에 켜면 대개 라우팅 테이블이 서로 덮어써져 양쪽 모두 작동하지 않게 됩니다. 같은 시점에는 하나의 도구만 관리자 역할을 하도록 두세요. 반드시 공존해야 한다면 다른 도구에서 로컬 네트워크 대역과 노드 서버 주소를 우회 목록에 추가하세요.

트래픽 루프백

코어 자신이 프록시 서버로 보내는 트래픽이 다시 TUN으로 라우팅되면 루프가 형성되어, 켜는 순간 전체 네트워크가 끊기는 현상이 나타납니다. auto-detect-interface의 역할이 바로 코어의 아웃바운드 트래픽을 물리 네트워크 카드에 바인딩해 가상 네트워크 카드를 피하는 것입니다. 라우팅 테이블을 직접 수정할 때는 노드 서버 IP가 반드시 물리 출구를 통하도록 해야 합니다.

브라우저 DoH가 DNS 가로채기를 우회하는 문제

Chrome, Edge의 「보안 DNS」는 도메인 해석을 DoH 서버로 넘기는데(443 포트 사용), 코어의 dns-hijack이 이 조회를 잡아내지 못해 fake-ip가 무력화되고, 결과적으로 도메인 기반 규칙이 브라우저에는 적용되지 않는 현상이 나타납니다. 해결책은 브라우저의 보안 DNS를 끄고 해석을 코어에 돌려주는 것입니다.

내부망 주소에 접속되지 않는 문제

기본 라우트가 넘어가면 회사 내부망, 학교 네트워크, 라우터 관리 페이지에 접속이 안 될 수 있습니다. 규칙에 내부망 대역에 대한 IP-CIDR 직접 연결 규칙을 추가하세요.

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

가상 머신, WSL2, Docker

Windows에서는 Hyper-V 가상 스위치와 TUN 라우팅이 충돌할 수 있어 WSL2 네트워크가 끊기거나 컨테이너가 외부 네트워크에 접속하지 못하는 문제가 발생합니다. 가상 네트워크 카드의 인터페이스 메트릭 값을 조정해 WSL2 트래픽이 올바르게 처리되도록 하거나, 클라이언트 설정에서 Hyper-V 대역을 제외하세요.

TUN을 켠 후 인터넷 접속이 전혀 안 되는 경우

1. auto-route와 auto-detect-interface가 모두 활성화되어 있는지 확인하세요.
2. 다른 프록시 도구의 「향상 모드」, 「전역 라우팅」 같은 기능을 종료한 뒤 다시 시도하세요.
3. 클라이언트 로그를 확인해 가상 네트워크 카드가 정상적으로 생성되었는지, 권한 오류가 없는지 확인하세요.
4. 여전히 접속이 안 되면 TUN 스위치를 끄세요. 대부분의 클라이언트는 라우팅 테이블을 자동으로 복원합니다. 복원되지 않으면 네트워크 서비스를 재시작하거나 시스템을 재부팅하세요.

자주 묻는 질문

마무리

TUN 모드는 프록시 처리 지점을 애플리케이션 계층에서 네트워크 계층으로 내려보냅니다. 가상 네트워크 카드 하나가 모든 아웃바운드 IP 패킷을 받아내고, 코어가 규칙에 따라 연결 단위로 분산 처리합니다. 이는 시스템 프록시가 다루지 못하는 세 가지 트래픽 문제를 해결합니다. 프록시 설정을 따르지 않는 앱, UDP, 그리고 오염된 DNS입니다. 일상적인 브라우징은 시스템 프록시만으로 충분하며, 게임이나 커맨드라인 도구, 완고한 클라이언트를 다룰 때 TUN을 켜고, 다른 VPN 도구, 브라우저 DoH, 내부망 대역과의 충돌에 유의하면 됩니다.