Clash TUN 모드 설정 방법: 가상 네트워크 인터페이스로 전체 트래픽 처리하기

시스템 프록시와 TUN: 트래픽 진입 경로의 차이

브라우저는 인터넷에 연결되는데 명령줄 도구, 게임 또는 다른 앱이 Clash 연결 목록에 표시되지 않는다면 먼저 트래픽 진입 경로를 확인하세요. 시스템 프록시는 127.0.0.1:7890 같은 프록시 주소를 앱에 제공합니다. 앱이 이 설정을 사용해야 요청이 로컬 프록시로 전달됩니다. 직접 연결하거나 환경 변수만 읽는 앱, 별도의 네트워크 설정을 사용하는 프로그램은 시스템 프록시를 따르지 않을 수 있습니다.

TUN은 3계층 가상 네트워크 장치입니다. 운영체제가 라우팅 테이블에 따라 IP 패킷을 가상 네트워크 인터페이스로 보내면 mihomo가 패킷을 읽어 연결을 식별하고 트래픽 분기 규칙을 적용합니다. 앱마다 HTTP 또는 SOCKS 프록시를 지원할 필요가 없으므로, 일반적인 직접 연결 앱의 TCP·UDP 트래픽까지 처리하는 데 적합합니다.

시작 전 점검: 코어, 구독, 권한

Clash는 여러 클라이언트와 코어 생태계를 통칭하는 경우가 많으며, 모든 설치 패키지가 동일한 TUN 설정을 지원하는 것은 아닙니다. 이 문서의 YAML 예시는 mihomo, 즉 흔히 Clash Meta 코어라고 부르는 제품을 기준으로 합니다. 구버전 Clash나 다른 포크, 모바일 클라이언트는 설정 키나 구성 경로가 다를 수 있으므로 제품 이름만으로 호환성을 판단하지 마세요.

1. 코어를 확인하세요. 클라이언트의 정보, 코어 정보 또는 실행 로그에서 mihomo 표시를 찾으세요. 화면에 TUN 스위치가 없다면 먼저 클라이언트가 해당 기능을 지원하는지 확인하고, 출처를 알 수 없는 설정을 무작정 추가하지 마세요.
2. 먼저 구독을 확인하세요. 시스템 프록시로 접속해 사용 가능한 노드가 하나 이상 있는지, 정책 그룹에 유효한 노드가 선택되어 있는지 확인하세요. TUN은 트래픽 진입 경로를 처리하는 기능이지, 만료된 구독이나 노드 인증 오류를 해결해 주지는 않습니다.
3. 기존 설정을 기록하세요. 시스템 프록시 포트, 현재 DNS, 사용 중인 VPN, 로컬 네트워크 대역을 저장해 두세요. 처음 설정할 때는 로컬에서 복구할 수 있는 경로를 남겨 두고, 원격 SSH 세션에서 기본 경로를 바로 수정하지 마세요.
4. 시스템 권한을 준비하세요. Windows에서는 보통 서비스 모드나 관리자 권한이 필요합니다. macOS에서는 클라이언트 안내에 따라 권한이 필요한 보조 구성요소를 설치해야 합니다. Linux에서는 /dev/net/tun에 접근할 수 있어야 하며 네트워크를 관리할 권한도 필요합니다.

Clash TUN을 테스트하기 전에 가상 네트워크 인터페이스를 사용하는 다른 VPN을 먼저 종료하세요. 여러 클라이언트가 동시에 기본 경로를 추가하거나 DNS를 변경하면 트래픽 경로가 반복해서 바뀔 수 있습니다. 함께 사용해야 한다면 각각 따로 정상 작동하는지 확인한 뒤 제외 경로와 출구 인터페이스를 하나씩 설정하세요.

gvisor, system, mixed 네트워크 스택

tun.stack은 가상 네트워크 인터페이스의 트래픽을 어떤 프로토콜 스택으로 처리할지 정하는 옵션입니다. 노드 프로토콜 옵션이 아니며 Trojan 노드를 VLESS 노드로 바꾸지도 않습니다. mihomo에서 흔히 사용하는 값은 gvisor, system, mixed이며, 실제 지원 여부는 사용하는 코어 빌드에 따라 다릅니다.

• gvisor: 사용자 공간 네트워크 스택으로 연결을 처리합니다. 호환성 문제를 점검할 때 비교 대상으로 사용하기 좋지만, 모든 시스템에서 더 안정적이라고 단정할 수는 없습니다.
• system: 운영체제의 네트워크 스택으로 연결을 처리합니다. 성능과 호환성은 운영체제, 드라이버, 네트워크 환경에 따라 달라지므로 모든 기기에서 더 빠르다고 볼 수는 없습니다.
• mixed: mihomo에서 두 가지 처리 방식을 함께 사용합니다. TCP는 system, UDP는 gvisor로 처리합니다. 이는 네트워크 스택 조합이며 HTTP와 SOCKS 요청을 함께 받는 mixed-port와는 관계가 없습니다.

네트워크 스택 전환 판단하기

한 번에 옵션 하나만 바꾼 뒤 코어를 재시작하고 새 연결로 테스트하세요. 웹은 정상인데 음성 통화나 게임이 실패하면 먼저 노드의 UDP 지원 여부와 규칙 적용 결과를 확인한 다음 네트워크 스택을 비교하세요. 모든 연결이 패널에 표시되지 않는다면 권한과 라우팅부터 살펴봐야 합니다. 이때 gvisor와 system을 반복해서 바꿔도 근본 원인을 찾기 어렵습니다.

mihomo TUN 설정: 라우팅과 DNS 함께 구성하기

아래는 기존 설정에 합쳐 사용할 구성 조각이며 전체 구독 설정이 아닙니다. 노드, 정책 그룹, 트래픽 분기 규칙이 정의되어 있지 않으므로 정상 작동하는 전체 설정을 대신할 수 없습니다. 최상위에 이미 tun 또는 dns가 있다면 키가 중복되어 파서에서 덮어쓰이지 않도록 필드를 병합하세요.

mixed-port: 7890
allow-lan: false
mode: rule

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

예시의 업스트림 DNS 주소 두 개는 구체적인 설정 예시일 뿐, 모든 네트워크에 권장되는 값은 아닙니다. 사용 중인 네트워크에서 접속할 수 있고 요구 사항에 맞는 DNS 서비스를 선택하세요. 구독에 이미 완성된 DNS 정책이 있다면 업스트림과 도메인 분기 구성을 유지하고 필요한 TUN 필드만 추가하는 것이 좋습니다.

auto-route와 auto-detect-interface

auto-route: true는 코어가 트래픽을 TUN으로 보내는 경로를 자동으로 설정합니다. auto-detect-interface: true는 실제 출구 인터페이스를 자동으로 찾아 프록시 연결이 물리 네트워크를 통해 전송되도록 해, 트래픽이 다시 자체 TUN으로 들어가는 문제를 줄입니다. 네트워크 인터페이스가 여러 개이거나 가상 머신 브리지, 기업 VPN, Wi-Fi와 유선 연결을 함께 사용하는 경우 자동 감지가 잘못된 인터페이스를 선택할 수 있으므로 로그도 확인하세요.

라우팅 테이블에 0.0.0.0/0이 있는지만 확인해서는 안 됩니다. 플랫폼에 따라 더 구체적인 분할 경로, 별도 테이블 또는 정책 라우팅으로 트래픽을 처리할 수 있습니다. 라우팅 조회 결과와 클라이언트 연결 기록을 함께 확인해 적용 여부를 판단하세요.

dns-hijack, 1053, fake-ip

dns-hijack은 조건에 맞는 DNS 트래픽을 mihomo 내장 DNS로 전달합니다. 예시의 any:53은 일반적인 UDP 53 조회를 처리합니다. TCP 53도 처리해야 한다면 코어 지원 여부를 확인한 뒤 tcp://any:53을 추가할 수 있습니다. 모든 DNS 프로토콜을 제어하는 스위치는 아니며, 브라우저가 HTTPS로 보내는 DoH 요청을 자동으로 식별해 가로채지도 않습니다.

127.0.0.1:1053은 예시 DNS 수신 주소입니다. 시스템 DNS에 포트가 포함된 문자열을 입력하라는 뜻은 아닙니다. 대부분의 시스템 DNS 설정은 IP 주소만 받습니다. TUN의 트래픽 처리 경로, DNS 수신 포트, 시스템 DNS 설정은 각각 구분해서 이해해야 합니다.

fake-ip는 도메인에 가상 주소를 할당한 뒤 코어가 도메인과 연결의 대응 관계를 저장하는 방식입니다. 예시 주소 풀인 198.18.0.1/16은 테스트용으로 예약된 주소 대역이므로, 이 범위의 주소가 조회된다고 DNS 오류인 것은 아닙니다. 실제 DNS 응답이 필요한 로컬 네트워크 서비스에는 적절한 fake-ip-filter와 DNS 분기 규칙을 적용하세요. 모든 도메인을 한꺼번에 제외할 필요는 없습니다.

Windows, macOS, Linux에서 TUN 켜기

클라이언트마다 메뉴 이름은 다를 수 있으므로 아래 단계는 기능별 경로를 기준으로 안내합니다. 화면에 TUN, 네트워크 스택, DNS 처리 옵션이 있다면 해당 메뉴를 우선 사용하세요. 많은 클라이언트가 실행 중 설정 파일을 다시 생성하므로 생성된 파일을 직접 수정해도 다음 실행 때 변경 사항이 사라질 수 있습니다. 구독 업데이트가 수동 변경을 덮어쓸 수도 있으니 클라이언트의 지속성 오버라이드나 병합 기능을 사용하세요.

Windows: 서비스 권한과 가상 네트워크 인터페이스

1. 구독을 가져온 뒤 시스템 프록시로 대상 서비스에 접속할 수 있는지 확인하고, 다른 VPN은 잠시 끄세요.
2. 클라이언트 설정에서 서비스 모드 메뉴를 찾아 안내에 따라 서비스를 설치하고 시작하세요. 다른 권한 상승 방식을 사용하는 클라이언트라면 해당 안내에 따라 관리자 권한을 승인하세요.
3. TUN을 켜고 코어가 지원하는 네트워크 스택을 선택한 뒤 설정을 적용하세요. 드라이버 설치나 네트워크 장치 권한을 요청하는 메시지가 표시되면 현재 사용 중인 클라이언트에서 보낸 안내인지 확인하세요.
4. PowerShell을 열어 새 가상 네트워크 인터페이스와 IPv4 경로를 확인하세요. 클라이언트 로그에서도 권한 부족, 장치 생성 실패, 경로 추가 실패 메시지가 있는지 살펴보세요.

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix,InterfaceAlias,NextHop,RouteMetric

네트워크 인터페이스 이름은 클라이언트와 설정에 따라 달라지므로 반드시 Clash라는 이름일 필요는 없습니다. 인터페이스가 표시되더라도 장치가 생성되었다는 뜻일 뿐, 앱 트래픽이 프록시 정책에 적용되었다는 증거는 아닙니다.

macOS: 보조 구성요소와 utun 인터페이스

1. 사용 중인 클라이언트와 코어가 TUN을 지원하는지 확인하고, 필요한 권한 보조 구성요소를 설치하세요.
2. 클라이언트에서 TUN 또는 이에 해당하는 가상 네트워크 인터페이스 기능을 켜고, 시스템 권한 요청이 표시되면 안내에 따라 승인하세요.
3. 아래 명령으로 인터페이스, 라우팅, 시스템 DNS를 확인한 다음 활성화 전 결과와 비교하세요.

ifconfig
netstat -rn -f inet
scutil --dns

macOS에는 utun 인터페이스가 여러 개 있을 수 있으며 다른 VPN이나 시스템 기능도 이를 생성합니다. utun이 보인다고 해서 Clash 인터페이스라고 단정하거나 같은 유형의 인터페이스를 모두 수동으로 삭제하지 마세요. 기능을 켜고 끄기 전후의 차이, 라우팅, 로그를 확인해 소유자를 판단하세요.

Linux: TUN 장치와 네트워크 관리 권한

데스크톱 클라이언트는 보통 서비스 프로세스를 통해 권한을 높입니다. 명령줄로 실행하는 경우 프로세스에 TUN 생성 및 라우팅 관리 권한이 있어야 하며, 흔히 CAP_NET_ADMIN이 필요합니다. 코어 기능, 서비스 제한, 실행 방식에 따라 추가 권한도 확인하세요. 임의의 capabilities 목록을 그대로 적용하지 마세요.

test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
resolvectl status

resolvectl은 systemd-resolved를 사용하는 시스템에서 쓸 수 있습니다. 명령이 없다고 해서 TUN에 문제가 있는 것은 아닙니다. 컨테이너에서 실행하려면 호스트가 TUN 장치와 필요한 네트워크 권한을 제공해야 하므로, 컨테이너 안에서 root로 실행하는 것만으로는 부족할 수 있습니다. 첫 테스트는 로컬에서 진행해 라우팅 변경으로 원격 관리 연결이 끊기는 일을 피하세요.

Android와 iOS: 시스템 VPN 권한

Android 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 처리하므로 데스크톱용 네트워크 드라이버 설치 절차를 그대로 따를 필요가 없습니다. 호환되는 설정을 가져온 뒤 VPN 또는 가상 네트워크 인터페이스 실행 방식을 선택하고, 첫 연결 시 시스템 VPN 권한을 승인하세요. 앱별 프록시를 사용한다면 대상 앱이 처리 범위에 포함되는지 확인하세요. 제외된 앱은 데스크톱 예시의 auto-route를 켰다고 자동으로 포함되지 않습니다.

iOS 클라이언트는 일반적으로 시스템 네트워크 확장 기능을 사용합니다. 먼저 앱이 해당 설정 형식을 지원하는지 확인한 다음 시스템 VPN 구성을 추가하고 연결 권한을 승인하세요. 데스크톱용 mihomo TUN 필드를 전부 iOS 공통 설정으로 간주해서는 안 됩니다. Clash 구독을 지원하는 앱이라고 해서 모두 mihomo 코어를 사용하는 것도 아닙니다.

모바일 기기에서는 일반적으로 같은 유형의 VPN 터널 두 개를 동시에 사용할 수 없습니다. 연결 직후 끊긴다면 노드 프로토콜을 계속 바꾸기보다 다른 VPN, 주문형 연결 규칙, 시스템 백그라운드 제한을 먼저 확인하세요.

트래픽 처리 확인: 연결 기록, DNS, UDP

시스템 프록시로 인한 오판부터 배제하기

클라이언트의 시스템 프록시 스위치를 일시적으로 끄고 TUN은 유지하세요. 프록시를 따로 설정하지 않은 프로그램에서 새 요청을 보내고, 연결 패널에서 프로세스, 대상, 적용 규칙, 출구 정책을 확인하세요. 아래 명령을 실행해 curl이 명시적 프록시를 사용하지 않도록 할 수도 있습니다. 다만 이는 해당 요청이 명시적 프록시를 사용하지 않게 할 뿐, TUN이 트래픽을 처리한다는 사실을 단독으로 증명하지는 않습니다.

curl --noproxy '*' -I https://example.com

페이지에 접속되고 연결 기록에서 해당 요청을 찾을 수 있다면 적용된 정책을 확인하세요. DIRECT가 적용되는 것은 정상적인 규칙 결과이지 TUN 오류가 아닙니다. 노드를 바꿔도 이미 열린 장기 연결은 기존 경로를 계속 사용할 수 있으므로 새 연결을 만들어 테스트하세요.

DNS와 UDP를 각각 확인하기

• DNS: 시스템 DNS 조회 도구로 캐시되지 않은 도메인을 조회하고 코어 로그를 확인하세요. 브라우저에서 보안 DNS를 사용하면 시스템의 UDP 53 경로를 거치지 않을 수 있습니다.
• UDP: 음성 통화, 게임 또는 QUIC를 실제로 사용하는 앱으로 연결 목록을 확인하세요. 웹페이지가 TCP 443으로 열린다고 UDP 443까지 사용할 수 있다는 뜻은 아닙니다.
• IPv6: 듀얼 스택 네트워크에서는 IPv4와 IPv6를 각각 확인하세요. IPv4만 처리하도록 설정하면 일부 앱이 다른 IPv6 경로를 우선 사용할 수 있습니다.
• 로컬 네트워크: 라우터 관리 페이지, 프린터, 내부 도메인에 접속해 보세요. 직접 연결해야 하는 대상 주소에는 명확한 규칙을 설정해야 하며, 특수한 네트워크에서는 경로 제외도 필요할 수 있습니다.

TUN을 켠 뒤 인터넷이 끊길 때: 단계별 점검과 복구

복구하려면 먼저 클라이언트에서 TUN을 끈 다음 클라이언트를 정상 종료하고, 시스템 프록시가 여전히 127.0.0.1:7890을 가리키는지 확인하세요. 프록시 프로세스가 종료됐는데 시스템 프록시가 계속 켜져 있으면 브라우저에서 연결 오류가 발생할 수 있습니다. 이는 TUN 경로가 남아 있는 문제와는 별개입니다.

이어서 이전에 기록한 DNS 설정을 복원하고 현재 네트워크 연결을 끊었다가 다시 연결하세요. 라우팅 문제가 계속되면 백그라운드 서비스가 실행 중인지 확인하고, 필요하면 시스템을 재시작해 네트워크 상태를 복구하세요. 용도를 모르는 경로나 네트워크 인터페이스를 한꺼번에 삭제하지 마세요. 기업 네트워크, 가상 머신, 다른 VPN이 사용 중일 수 있습니다.

설정 구조를 더 정리하려면 Clash 설정 안내를 참고하세요. 사용할 클라이언트를 아직 정하지 못했다면 클라이언트 선택 가이드에서 플랫폼과 코어 지원 여부를 확인해 보세요.