Clash TUN 모드 설정 방법: 전체 트래픽 라우팅 원리와 플랫폼별 설정

TUN 모드의 트래픽 처리 원리

일반적인 시스템 프록시 모드는 운영체제가 애플리케이션에 HTTP 또는 SOCKS 프록시 주소를 알려 주는 방식에 의존합니다. 브라우저, 일부 다운로드 도구와 시스템 네트워크 설정을 따르는 프로그램은 연결을 Clash에 자동으로 전달하지만, 게임 클라이언트, 명령줄 프로그램, 독립 업데이트 프로그램 및 자체 네트워크 스택을 사용하는 앱은 대상 주소에 직접 접속할 수 있습니다. 따라서 클라이언트 화면에 “시스템 프록시가 켜짐”으로 표시되어도 이러한 연결은 프록시 포트를 우회할 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 규칙과 함께 지정된 트래픽을 해당 인터페이스로 보냅니다. Clash 코어는 가상 인터페이스에서 IP 패킷을 읽어 연결 대상을 복원한 뒤, 설정 파일의 프록시 규칙에 따라 DIRECT, REJECT 또는 특정 프록시 정책을 선택합니다. 반환 데이터도 같은 경로를 통해 애플리케이션으로 전달되므로, 앱은 로컬 프록시 포트를 알 필요가 없고 HTTP 또는 SOCKS를 별도로 지원하지 않아도 됩니다.

여기서 말하는 “전체 트래픽 처리”는 Clash로 유입되는 트래픽의 범위를 뜻하며, 프록시 모드인 GLOBAL과 같은 의미가 아닙니다. TUN을 활성화해도 Rule 규칙 모드를 사용할 수 있습니다. 로컬 네트워크 주소는 직접 연결하고, 특정 도메인은 프록시로 보내며, 광고 도메인은 거부하고, 나머지 연결은 기본 규칙으로 처리할 수 있습니다. 처리 가능한 연결을 선택한 프록시 정책으로 일괄 전송하려면 실행 모드를 Global로 전환해야 합니다.

TUN은 주로 3계층 IP 트래픽을 처리합니다. 도메인 매칭은 DNS 조회 결과와 코어의 도메인 매핑 방식에도 영향을 받으며, UDP·QUIC·IPv6의 완전한 지원 여부는 클라이언트가 사용하는 코어, 노드 프로토콜, 시스템 권한 및 설정에 따라 달라집니다. 최신 mihomo 코어는 일반적으로 비교적 완전한 TUN 기능을 제공하지만, 데스크톱 클라이언트마다 설정 항목을 노출하는 방식은 서로 다릅니다.

TUN 활성화 전 점검 항목

먼저 현재 구독이 정상적으로 작동하는지 확인합니다. 사용 가능한 노드를 선택하고 시스템 프록시만 켠 상태에서 웹페이지에 접속한 뒤, 규칙 목록이 예상한 정책에 매칭되는지 확인하세요. 구독 자체의 파싱에 실패했거나 노드에 연결할 수 없거나 규칙 설정이 잘못된 상태라면 TUN을 켜도 문제 범위만 넓어질 뿐 기본 연결 문제가 해결되지는 않습니다.

클라이언트 코어 확인: 클라이언트의 코어 정보 또는 정보 페이지를 확인합니다. 최신 mihomo 코어는 TUN, 자동 라우팅 및 DNS 하이재킹 등의 매개변수를 지원하지만, 구형 Clash 코어 또는 기능이 간소화된 클라이언트는 일부 옵션이 없을 수 있습니다.
현재 설정 보관: 사용 중인 설정 파일을 내보내거나 구독 이름, 프록시 모드 및 DNS 설정을 기록해 둡니다. YAML을 수정할 때는 공백 들여쓰기를 일관되게 유지해야 하며, 탭으로 들여쓰기를 대신할 수 없습니다.
권한 부여 방식 확인: Windows에서는 일반적으로 서비스 모드 또는 관리자 권한으로 가상 네트워크 인터페이스를 관리하고, macOS에서는 관리자 승인이 필요할 수 있으며, Linux에서는 대개 root 권한이나 프로세스에 네트워크 관리 권한을 부여해야 합니다.
다른 VPN 종료: 한 시스템에서 여러 가상 네트워크 인터페이스 도구를 동시에 실행하면 기본 라우팅, DNS 및 방화벽 규칙이 충돌하기 쉽습니다. 모바일 플랫폼에서는 일반적으로 한 번에 하나의 시스템 VPN 채널만 활성화할 수 있습니다.
로컬 네트워크 환경 기록: 프린터, NAS, 개발 장비 또는 사내 네트워크에 접속해야 한다면 해당 주소 대역을 기록해 두고, 활성화 후 이러한 직접 연결 리소스를 중점적으로 확인합니다.

mihomo TUN 설정 매개변수

대부분의 그래픽 클라이언트는 TUN 스위치를 제공하며 기본 매개변수도 자동으로 생성합니다. YAML을 직접 관리해야 한다면 간단한 설정부터 시작한 뒤 시스템 환경에 맞춰 엄격한 라우팅, MTU 등의 옵션을 추가하세요. 아래는 일반적인 구조이며 실제로 사용할 수 있는 필드는 클라이언트에 통합된 코어 버전을 기준으로 확인해야 합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  mtu: 1500

enable 및 stack

enable은 TUN 기능의 활성화 여부를 제어합니다. stack은 코어가 네트워크 데이터를 처리하는 방식을 결정하며, mihomo에서 흔히 사용하는 값은 system, gvisor, mixed입니다. 시스템 스택은 일반적으로 성능이 직접적이고, gVisor 사용자 공간 네트워크 스택은 일부 환경에서 호환성이 더 좋으며, mixed는 TCP와 UDP를 조합해 처리합니다. 클라이언트가 권장값을 제공한다면 우선 기본 설정을 유지하세요. 특정 앱이 연결되지 않거나 UDP에 문제가 생길 때만 항목을 하나씩 바꿔 테스트하는 것이 좋습니다.

auto-route 및 auto-detect-interface

auto-route는 코어가 필요한 라우팅을 자동으로 추가해 시스템 트래픽을 가상 인터페이스로 보냅니다. auto-detect-interface는 실제 외부 연결용 네트워크 인터페이스를 식별하여 프록시 서버 연결이 다시 TUN으로 들어가는 루프를 방지합니다. 유선, 무선 및 모바일 핫스팟 사이를 전환한 뒤 모든 연결이 갑자기 끊기면 먼저 TUN을 다시 시작해 코어가 외부 인터페이스를 재판단하도록 하세요.

dns-hijack 및 DNS 설정

dns-hijack의 any:53은 기존 53번 포트의 DNS 조회를 가로채 도메인 해석이 Clash 규칙과 일관되게 처리되도록 합니다. 암호화 DNS는 사용하는 포트와 프로토콜이 다르므로 앱에 내장된 DoH나 DoT를 직접 가로챌 수는 없습니다. 코어 DNS 모듈을 활성화하지 않은 채 DNS 하이재킹만 설정하면 조회에 실패할 수도 있으므로, 설정의 dns.enable과 nameserver, fallback 또는 정책 기반 해석 항목이 유효한지도 함께 확인해야 합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

fake-ip 모드는 도메인에 예약 주소 대역의 매핑 주소를 반환하고, 코어가 이를 바탕으로 도메인 정보를 유지하며 규칙을 매칭합니다. 일부 로컬 네트워크 장치, 게임 로그인 서비스 또는 실제 DNS 응답값에 의존하는 프로그램은 fake-ip과 호환되지 않을 수 있습니다. 관련 도메인을 필터 목록에 추가하거나 클라이언트가 지원하는 다른 강화 모드로 전환하세요. fake-ip 주소 대역을 임의로 변경한 뒤 로컬 네트워크 라우팅과 같은 대역을 사용하면 주소 충돌이 발생하므로 주의해야 합니다.

strict-route 및 MTU

strict-route는 라우팅 제약을 강화해 일부 시스템에서 트래픽 우회를 줄이는 데 도움이 되지만, 회사 VPN·가상 머신 인터페이스·특수 라우팅 간 충돌을 더 쉽게 드러낼 수 있습니다. 먼저 클라이언트 기본값을 사용하고 기본 연결이 안정적인지 확인한 후 활성화하세요. MTU는 단일 패킷의 크기를 제어합니다. 웹페이지는 열리지만 업로드가 멈추거나 일부 사이트에서 계속 시간 초과가 발생하거나 게임이 로그인 후 끊긴다면 1400~1500 범위의 값을 테스트해 볼 수 있습니다. 한 번에 하나의 매개변수만 변경하고 다시 연결하세요.

Windows·macOS·Linux 및 모바일 플랫폼 설정

Windows: 서비스 모드 및 가상 네트워크 인터페이스

Windows 그래픽 클라이언트에서는 보통 설정 페이지, 서비스 모드 페이지 또는 메인 화면의 네트워크 스위치에서 TUN을 설정합니다. 먼저 클라이언트가 제공하는 서비스 구성 요소를 설치한 다음 관리자 권한으로 설치를 승인하세요. 서비스 모드를 사용하면 백그라운드 서비스가 가상 네트워크 인터페이스 생성과 라우팅 변경을 담당하므로, 평소 클라이언트를 시작할 때 전체 UI 프로세스의 권한을 매번 높일 필요가 없습니다.

실행 중인 다른 VPN, 게임 가속기 및 네트워크를 가로챌 수 있는 보안 도구를 종료합니다.
클라이언트 설정에서 Service Mode, 서비스 모드 또는 시스템 서비스를 설치하거나 활성화합니다.
Rule 모드를 선택하고 구독 노드를 사용할 수 있는지 확인한 다음 TUN Mode를 켭니다.
시스템 권한 요청을 승인하고 가상 네트워크 인터페이스 생성이 완료될 때까지 기다립니다.
웹페이지, 명령줄 도구, 대상 애플리케이션 및 로컬 네트워크 리소스를 차례로 테스트합니다.

스위치가 즉시 원래 상태로 돌아가면 서비스가 실행 중인지 확인하고, 클라이언트 로그에 인터페이스 생성, 라우팅 기록 또는 드라이버 접근 실패가 표시되는지 살펴보세요. Windows의 Hyper-V, WSL 및 가상 머신 소프트웨어는 가상 스위치와 네트워크 인터페이스를 추가하지만, 이러한 구성 요소가 존재한다고 해서 반드시 충돌하는 것은 아닙니다. 라우팅 테이블과 실제 외부 인터페이스를 기준으로 판단해야 하며 모든 가상 어댑터를 바로 삭제해서는 안 됩니다.

macOS: 권한 승인 및 utun 인터페이스

macOS 클라이언트는 일반적으로 시스템 네트워크 확장 또는 권한이 있는 보조 프로세스를 통해 TUN을 설정합니다. 처음 활성화할 때 관리자 암호, VPN 구성 또는 네트워크 확장 승인 요청이 나타날 수 있습니다. 승인을 완료하면 시스템 네트워크 설정에서 해당 VPN 상태를 확인할 수 있으며, 터미널에서 ifconfig를 실행하면 새로운 utun 인터페이스가 표시될 수도 있습니다.

TUN이 연결되었지만 트래픽이 없다면 먼저 시스템에서 다른 VPN이 활성화되어 있는지 확인한 다음, 클라이언트가 프록시 서버 자체의 연결을 다시 가상 인터페이스로 보내고 있지 않은지 확인하세요. 기업 네트워크 구성 프로파일을 사용하는 Mac은 관리자 정책의 제한을 받을 수 있습니다. 이러한 제한은 시스템 관리 범위에서 처리해야 하며, 클라이언트를 반복해서 재설치해도 정책 결과가 바뀌지는 않습니다.

Linux: 권한·라우팅 및 포워딩

Linux에서는 시스템이 /dev/net/tun을 제공하고 프로세스가 인터페이스 생성 및 라우팅 변경을 수행할 수 있어야 합니다. root로 실행하는 방법은 단기 확인에는 사용할 수 있지만, 장기적으로는 systemd 서비스, 컨테이너 권한 또는 capabilities를 통해 필요한 권한만 명시적으로 부여하는 편이 적합합니다. 최소 구성 시스템, 컨테이너 및 제한된 서버에서는 커널이 TUN 장치를 활성화했는지도 확인해야 합니다.

ls -l /dev/net/tun
ip addr show
ip route show
ip rule show

다음 명령으로 장치 노드, 가상 인터페이스, 기본 라우팅 및 정책 라우팅을 확인할 수 있습니다. Linux에서 흔한 문제로는 nftables와 iptables 규칙의 동시 사용, Docker 브리지 주소 대역 중복, 서버에 이미 존재하는 정책 라우팅, 방화벽에서 TUN 인터페이스 트래픽을 허용하지 않는 경우 등이 있습니다. 문제를 진단할 때는 기존 네트워크 규칙을 먼저 저장하세요. 원격 서버에서 방화벽이나 기본 라우팅을 바로 초기화하면 관리 연결이 끊길 수 있습니다.

Android 및 iOS: 시스템 VPN 채널

모바일 클라이언트는 일반적으로 Android VPNService 또는 Apple Network Extension을 이용해 로컬 VPN 채널을 만듭니다. 화면에 표시되는 이름은 “VPN”, “강화 모드” 또는 “TUN” 등으로 다를 수 있습니다. 처음 연결할 때는 시스템 VPN 권한 승인이 필요합니다. Android에서는 클라이언트 기능에 따라 앱별 프록시를 설정하거나 앱을 제외할 수 있으며, iOS와 iPadOS의 세부 옵션은 클라이언트 구현과 시스템 권한에 따라 달라집니다.

모바일 운영체제는 일반적으로 하나의 일반 VPN 구성만 활성 상태로 유지할 수 있으므로 Clash 계열 클라이언트는 회사 VPN이나 다른 프록시 도구와 채널을 동시에 사용할 수 없습니다. 시스템의 절전 정책이 백그라운드 클라이언트를 일시 중지하면 화면을 잠근 뒤 일정 시간이 지나 연결이 끊길 수도 있습니다. 클라이언트의 백그라운드 실행 권한을 허용하고 DNS를 중복으로 변경하는 네트워크 도구를 동시에 사용하지 마세요.

TUN이 트래픽을 처리하는지 확인하는 방법

스위치 상태만으로는 연결 경로가 완전한지 판단하기 어렵습니다. 신뢰할 수 있는 확인 방법은 가상 인터페이스, 클라이언트 로그, 규칙 매칭 및 실제 애플리케이션 연결을 함께 점검하는 것입니다. 다음 순서로 진행하는 것이 좋습니다:

시스템에 새로운 TUN, utun 또는 클라이언트 가상 인터페이스가 나타났는지 확인하고 인터페이스가 활성 상태인지 점검합니다.
클라이언트의 연결 목록을 열고 원래 시스템 프록시를 따르지 않던 프로그램으로 요청을 보낸 뒤, 해당 대상 주소나 프로세스 기록이 표시되는지 확인합니다.
규칙 매칭 결과를 확인합니다. 로컬 네트워크 주소는 LAN 또는 사설 주소 규칙에 따라 직접 연결되고, 대상 사이트는 예상한 정책 그룹으로 들어가야 합니다.
시스템 프록시를 일시적으로 끄고 TUN은 유지한 다음 브라우저와 명령줄 연결을 테스트합니다. 연결이 계속 클라이언트에 기록된다면 트래픽이 시스템 프록시에만 의존해 코어로 들어간 것이 아닙니다.
TCP, UDP, IPv4, IPv6 및 DNS를 각각 테스트합니다. 모든 노드가 동일한 UDP 또는 IPv6 기능을 지원하는 것은 아니므로 노드의 한계와 TUN 문제를 구분해야 합니다.

Windows에서는 route print 또는 PowerShell의 Get-NetAdapter로 인터페이스를 확인할 수 있고, macOS에서는 route -n get default와 ifconfig를 사용할 수 있으며, Linux에서는 ip route와 ip rule을 사용할 수 있습니다. 진단할 때는 기본 라우팅이 하나 보인다는 이유만으로 설정이 올바르다고 판단하지 말고 활성화 전후의 차이를 비교해야 합니다.

일반적인 충돌과 단계별 문제 해결

활성화 후 모든 앱에서 인터넷에 연결할 수 없음

먼저 TUN을 끄고 시스템 네트워크가 복구되는지 확인한 다음 프록시 노드 자체를 점검합니다. 이어서 로그에 인터페이스 생성 실패, 기본 네트워크 인터페이스 식별 오류, 라우팅 루프 또는 DNS 시간 초과가 나타나는지 확인하세요. 장치가 유선과 무선 네트워크에 동시에 연결되어 있다면 실제 외부 인터페이스 하나만 남긴 뒤 TUN을 다시 활성화해 보세요. 인터페이스를 수동 지정하는 것은 자동 감지가 실패한 뒤의 방법으로 사용해야 하며, 네트워크 인터페이스 이름이 바뀌면 설정도 함께 업데이트해야 합니다.

웹페이지는 열리지만 게임 또는 음성 통화가 연결되지 않음

이 경우에는 보통 UDP를 점검해야 합니다. 선택한 노드와 프로토콜이 UDP를 지원하는지, 정책 그룹이 TCP에만 적합한 경로를 선택하고 있지는 않은지 확인하고, 클라이언트에 해당 UDP 세션 기록이 남는지도 살펴보세요. 앱이 QUIC을 사용한다면 앱 내 QUIC을 일시적으로 비활성화해 비교 테스트할 수 있지만, 최종적으로는 노드 기능, 규칙 매칭 및 TUN 스택 호환성을 기준으로 원인을 찾아야 합니다.

활성화 후 NAS·프린터 또는 라우터에 접속할 수 없음

사설 주소 대역이 잘못 프록시로 전송되고 있는지 확인합니다. 일반적인 로컬 네트워크 대역에는 10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16이 있지만, 기업 내부망은 다른 주소를 사용할 수도 있습니다. 설정에서 로컬 네트워크 라우팅을 직접 연결하도록 허용하고 fake-ip 주소 대역이 실제 네트워크와 겹치지 않는지 확인하세요. 도메인으로는 접속할 수 없지만 IP로는 접속된다면 로컬 도메인 해석과 fake-ip 필터를 중점적으로 점검해야 합니다.

절전 모드 또는 Wi-Fi 전환 후 연결이 끊김

네트워크가 복구된 뒤 실제 외부 인터페이스와 기본 라우팅이 변경되었지만 TUN은 이전 상태를 유지하고 있을 수 있습니다. 먼저 TUN을 중지하고 시스템이 새 IP와 DNS를 할당받을 때까지 기다린 다음 다시 활성화하세요. 문제가 자주 발생한다면 클라이언트가 지원하는 안정적인 최신 코어 버전으로 업그레이드하고 자동 인터페이스 감지가 활성화되어 있는지 확인합니다. 모바일 기기에서는 백그라운드 실행 및 절전 제한도 점검해야 합니다.

Docker·가상 머신 또는 회사 VPN과 충돌함

먼저 각 가상 네트워크 인터페이스가 사용하는 주소 대역과 라우팅 우선순위를 비교합니다. Docker 브리지, 가상 머신 NAT, 회사 VPN 및 TUN이 동일한 네트워크 대역을 선언하면 시스템이 트래픽을 잘못된 인터페이스로 보낼 수 있습니다. 해결 방법으로는 로컬 가상 네트워크 대역 조정, 사내 네트워크에 대한 명시적 직접 연결 라우팅 추가, 사용하지 않는 네트워크 구성 요소 종료 또는 동시에 실행할 수 없는 환경에서 상황별 전환 등이 있습니다. DNS, 라우팅, MTU 및 방화벽을 한꺼번에 크게 변경하면 어떤 조정이 효과가 있었는지 파악하기 어려우므로 피해야 합니다.

TUN 모드 자주 묻는 질문

TUN을 켠 후에도 시스템 프록시를 켜야 하나요?

일반적으로 시스템 프록시에 동시에 의존할 필요는 없습니다. TUN이 가상 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 이미 처리하기 때문입니다. 일부 클라이언트는 특정 앱과의 호환성을 위해 두 기능을 함께 켤 수 있지만, 이는 TUN 작동 여부를 판단하는 필수 조건이 아닙니다. 문제를 확인할 때는 시스템 프록시를 끄고 TUN만 유지한 상태에서 연결 목록을 관찰해 보세요.

TUN 모드를 사용하면 모든 트래픽이 프록시 노드를 거치나요?

규칙 모드가 자동으로 변경되지는 않습니다. TUN은 트래픽이 Clash로 들어오는 방식을 결정하고, Rule·Global·Direct는 유입된 트래픽을 처리하는 방식을 결정합니다. Rule 모드에서는 연결이 설정 파일의 규칙을 위에서부터 차례로 매칭하며 직접 연결, 거부 또는 프록시 정책으로 각각 처리할 수 있습니다.

활성화 후 클라이언트에 TUN 장치 생성 실패가 표시되는 이유는 무엇인가요?

흔한 원인으로는 시스템 권한 부족, 서비스 구성 요소 미설치, TUN 장치 사용 불가, 기존 VPN의 인터페이스 점유 또는 네트워크 변경을 차단하는 보안 정책이 있습니다. 먼저 로그의 구체적인 오류를 확인한 뒤 서비스 상태와 시스템 권한 승인을 점검하세요. 스위치를 반복해서 누르는 것만으로는 해결되지 않습니다.

system, gvisor 및 mixed 중 무엇을 선택해야 하나요?

현재 플랫폼에 맞춰 클라이언트가 제공하는 기본값을 우선 사용하세요. 기본 네트워크는 정상이지만 특정 TCP 또는 UDP 앱에 문제가 생길 때 다른 스택으로 전환해 비교합니다. 코어 버전과 운영체제에 따라 결과가 다를 수 있으므로 모든 기기에 적용되는 고정된 선택은 없습니다.

TUN 모드가 앱에 내장된 암호화 DNS도 처리할 수 있나요?

기존 53번 포트의 DNS는 dns-hijack으로 처리할 수 있지만, 앱에 내장된 DoH 또는 DoT는 암호화 연결을 사용하므로 any:53만으로 직접 가로챌 수 없습니다. 앱에서 별도의 보안 DNS를 끄거나 도메인 규칙, 정책 및 시스템 수준의 관리 기능을 통해 처리해야 합니다.

안정적으로 활성화하는 권장 순서

먼저 시스템 프록시 환경에서 구독, 노드 및 Rule 모드가 정상적으로 작동하는지 확인한 다음 필요한 서비스를 설치하고 TUN을 활성화합니다. 첫 테스트에서는 자동 라우팅, 자동 인터페이스 감지 및 기본 DNS 설정만 유지하고 브라우저, 명령줄, UDP 앱 및 로컬 네트워크 리소스가 규칙에 따라 모두 접속되는지 확인하세요. 이후 실제 문제에 따라 stack, strict-route, MTU 또는 fake-ip 필터를 조정합니다.

TUN의 핵심 가치는 기존에 프록시를 사용하지 않던 앱의 연결도 하나의 규칙 체계로 처리하는 데 있습니다. 안정성은 라우팅, DNS, 권한 및 프록시 노드가 함께 작동하는지에 달려 있으므로, 문제를 진단할 때는 “가상 인터페이스가 생성되었는가”, “트래픽이 코어로 유입되는가”, “규칙이 매칭되는가”, “노드가 데이터를 전송할 수 있는가”를 네 단계로 나누어 확인해야 합니다. 모든 옵션을 반복해서 전환하는 것보다 단계별로 확인하는 편이 문제 지점을 찾기 쉽습니다.