2026-09-15 고급 활용 예상 읽기 시간 12분

Clash TUN 모드 자세히 알아보기

가상 네트워크 인터페이스와 라우팅 테이블을 바탕으로 TUN 모드가 시스템 프록시를 지원하지 않는 프로그램의 트래픽을 처리하는 원리를 설명하고, 플랫폼별 설정 방법과 권한 확인 사항을 안내합니다.

1. 시스템 프록시와 TUN은 트래픽을 가로채는 지점이 다릅니다

브라우저에서는 웹사이트에 접속되는데 터미널 도구, 게임 또는 업데이트 프로그램은 연결에 실패한다면 먼저 해당 앱이 프록시를 사용하는지 확인해야 합니다. 시스템 프록시는 운영체제 설정에 프록시 주소를 지정하는 방식입니다. 앱이 이 설정을 직접 읽고 따라야 요청이 Clash로 전달됩니다. 프로그램이 직접 TCP 또는 UDP 연결을 만들면 시스템 프록시를 켜도 연결 경로는 바뀌지 않는 경우가 많습니다.

TUN은 IP 패킷을 처리하는 3계층 가상 네트워크 인터페이스입니다. TUN을 켜면 커널과 클라이언트가 인터페이스를 만들고 라우팅을 조정해 조건에 맞는 패킷을 프록시 코어로 전달합니다. 앱이 HTTP 프록시나 SOCKS 프록시를 이해할 필요는 없지만, 라우팅과 권한이 올바르고 코어가 해당 트래픽을 지원해야 합니다.

방식	트래픽이 들어오는 지점	테스트에 적합한 상황
시스템 프록시	앱이 시스템 프록시 설정을 읽음	브라우저, 시스템 설정을 따르는 데스크톱 앱
명시적 프록시	앱에서 로컬 프록시 주소를 지정	`curl --proxy`, 터미널 환경 변수
TUN 모드	가상 네트워크 인터페이스와 시스템 라우팅	시스템 프록시 설정을 따르지 않는 프로그램, 지원되는 UDP 트래픽

이 문서의 YAML 필드는 mihomo를 기준으로 합니다. 구형 Clash 코어, 각종 포크, 모바일 앱에 포함된 코어는 지원 기능이 서로 다를 수 있습니다. 문제를 진단하기 전에 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 실제로 실행 중인 코어 이름을 확인하세요. 앱 이름에 Clash가 들어 있는지만으로 판단하지 마세요.

2. 패킷, 라우팅, DNS는 어떻게 연동되나요?

앱에서 외부 연결까지의 흐름

앱이 도메인 이름을 조회한 뒤 대상 IP에 연결을 요청합니다.
운영체제가 라우팅 테이블을 확인하고, TUN 라우팅 조건에 맞는 패킷을 가상 인터페이스로 보냅니다.
mihomo가 패킷을 읽고 대상 주소, 도메인 매핑, 규칙 일치 결과를 바탕으로 처리 정책을 선택합니다.
코어가 물리 네트워크 인터페이스를 통해 직접 연결 또는 프록시 연결을 만들고 응답을 앱에 전달합니다.

라우터, Wi-Fi 또는 모바일 네트워크에 연결하는 역할은 여전히 물리 네트워크 인터페이스가 맡습니다. TUN은 실제 네트워크 연결을 대체하지 않으며 노드 대역폭을 저절로 높여 주지도 않습니다. 코어의 자체 연결이 TUN으로 다시 들어가 순환하지 않도록 해야 합니다. 자동 출구 인터페이스 감지, 인터페이스 바인딩, 라우팅 처리가 이와 관련됩니다. 다른 VPN을 함께 사용하면 두 프로그램이 기본 경로나 정책 라우팅을 놓고 충돌할 수 있습니다.

DNS가 연결 성공 여부를 좌우하는 이유

규칙은 도메인 이름을 기준으로 매칭할 수 있지만 네트워크 패킷에는 주로 IP 주소가 담깁니다. DNS 요청이 코어를 거치지 않으면 도메인 매핑 정보가 불완전해질 수 있습니다. 코어 DNS를 활성화하고 일반 DNS 요청을 코어로 전달하면 도메인 규칙과 연결 기록을 서로 대응시키는 데 도움이 됩니다.

fake-ip 모드에서는 앱에 합성 주소를 반환할 수 있습니다. 예를 들어 198.18.0.1/16 대역에서 주소를 할당한 뒤 코어가 매핑 정보를 이용해 대상 도메인을 복원합니다. 이 주소는 대상 사이트의 실제 주소가 아니며 노드 IP로 간주해서도 안 됩니다. 일부 기기 검색, LAN 서비스 또는 실제 DNS 응답에 의존하는 앱은 예외 처리가 필요할 수 있으므로 해당 도메인에 맞춰 fake-ip-filter를 설정하세요.

dns-hijack은 조건에 맞는 DNS 트래픽을 가로채며, 모든 암호화 DNS를 처리하는 것은 아닙니다.
브라우저에 내장된 DoH는 보통 HTTPS를 사용하므로 53 포트만 가로채서는 처리할 수 없습니다.
앱에 이미 캐시된 DNS 응답은 바로 사라지지 않습니다. DNS 설정을 변경한 뒤에는 테스트할 앱을 다시 시작하고, 필요하면 시스템 DNS 캐시도 비우세요.

3. mihomo 설정과 시작 전 점검

먼저 TUN을 끄고 로컬 혼합 포트로 구독, 노드, 규칙이 작동하는지 확인하세요. 아래 예시는 127.0.0.1:7890을 로컬 프록시 주소로 사용합니다. 클라이언트에 표시된 포트가 다르면 테스트 명령도 그에 맞게 바꾸세요. 노드 자체가 연결되지 않는다면 먼저 노드나 구독 문제를 해결해야 가상 네트워크 인터페이스 문제로 잘못 판단하지 않습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

Windows PowerShell에서는 curl.exe를 사용하세요. 구버전 환경에서 curl이 다른 명령으로 해석되는 일을 방지할 수 있습니다. HTTP 응답을 받으면 해당 프록시 요청이 대상 서버에 도달한 것입니다. 다만 모든 사이트, UDP 또는 TUN이 정상이라는 뜻은 아닙니다.

기존 설정에 병합할 예시

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

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

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

필드	용도	확인 사항
`stack: mixed`	mihomo에서 시스템 및 사용자 공간 네트워크 스택을 함께 사용	`mixed-port`가 아닙니다. 서로 다른 개념입니다.
`auto-route`	TUN을 가리키는 경로를 자동으로 추가	시스템 권한이 필요하며 기존 VPN 경로와 충돌할 수 있음
`auto-detect-interface`	출구 인터페이스를 자동으로 감지	여러 네트워크 인터페이스, 가상 머신, VPN 환경에서는 실제 출구를 확인해야 함
`dns.listen`	로컬 DNS 리스너 제공	`1053`으로 설정해도 시스템이 자동으로 이 포트를 사용하지 않습니다. DNS 가로채기나 별도의 전달 설정이 필요합니다.

GUI 클라이언트는 최종 설정 파일을 생성하는 경우가 많습니다. 구독 캐시 파일을 직접 수정하면 구독 업데이트 후 변경 사항이 사라질 수 있으므로 클라이언트의 오버라이드, 설정 병합 또는 TUN 메뉴를 우선 사용하세요. 최상위 tun이나 dns 키를 중복으로 추가하지 마세요. 수정한 뒤에는 편집기 내용만 확인하지 말고 실행 설정과 시작 로그도 점검하세요.

4. 플랫폼별 설정 방법과 권한

Windows: 서비스 권한을 확인한 뒤 가상 네트워크 인터페이스 활성화

사용 중인 클라이언트 설정에서 ‘서비스 모드’ 또는 서비스 설치 메뉴를 찾아 안내에 따라 관리자 권한을 부여하세요. 일부 클라이언트는 관리자 권한으로 직접 실행하는 방법도 지원합니다. 클라이언트 안내에 따라 적절한 방식을 선택하세요.
서비스가 정상적으로 실행되는지 확인한 뒤 ‘TUN 모드’ 또는 ‘가상 네트워크 인터페이스 모드’를 켜세요. Clash Verge Rev에서는 ‘설정’에서 ‘서비스 모드’와 ‘가상 네트워크 인터페이스 모드’ 메뉴를 찾을 수 있습니다. 배포판에 따라 메뉴 그룹 이름은 다를 수 있습니다.
로그에서 권한 부족, 장치 생성 실패, 경로 추가 실패가 있는지 확인하세요. 화면의 스위치가 켜졌다는 것은 설정 요청이 전달됐다는 뜻일 뿐, 코어가 트래픽을 성공적으로 처리한다는 의미는 아닙니다.
Get-NetAdapter로 네트워크 인터페이스를 확인하고 route print로 TUN을 켜기 전후의 경로를 비교하세요. 일부 구현은 분할 경로나 정책 라우팅을 사용하므로 눈에 보이는 기본 경로가 직접 바뀌지 않을 수 있습니다.

회사나 학교에서 관리하는 기기에서 가상 네트워크 인터페이스 또는 백그라운드 서비스를 설치할 수 없다면 기기 관리자에게 권한 정책을 확인하세요. 테스트를 위해 시스템 방화벽 전체를 끄지 마세요. 먼저 클라이언트와 코어의 허용 규칙을 확인하고 로그에서 실패한 단계를 찾으세요.

macOS: 보조 서비스 승인 및 출구 확인

데스크톱 클라이언트는 TUN 인터페이스 생성, 라우팅 조정, DNS 설정을 위해 권한이 있는 보조 서비스를 설치하거나 승인받아야 하는 경우가 많습니다. 앱 안내에 따라 시스템 권한을 승인한 뒤 TUN을 켜세요. ifconfig로 utun 인터페이스를 확인할 수 있지만 macOS 자체와 다른 VPN도 같은 유형의 인터페이스를 만들 수 있으므로, 인터페이스가 존재한다는 사실만으로 현재 클라이언트가 생성했다고 단정할 수 없습니다.

ifconfig
route -n get 1.1.1.1
scutil --dns

시작 로그, 경로 조회, 연결 기록을 함께 확인해 결과를 판단하세요. 회사 VPN, 다른 네트워크 확장 프로그램, 네트워크 필터 도구를 사용 중이라면 기존 상태를 기록한 뒤 한 번에 한 가지씩 비교하세요. utun 번호만으로 충돌 원인을 단정하지 마세요.

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

데스크톱 GUI 클라이언트는 서비스가 권한을 제공할 수 있습니다. mihomo를 명령줄에서 실행한다면 인터페이스 생성과 경로 설정에 필요한 권한이 있어야 합니다. root 서비스로 실행하는 방법이 흔하며 배포 환경에 따라 capability를 설정할 수도 있습니다. 다만 바이너리에 권한 하나만 추가하면 모든 DNS 및 라우팅 환경에서 작동한다고 볼 수는 없습니다.

ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all
resolvectl status

resolvectl은 systemd-resolved를 사용하는 시스템에서만 쓸 수 있습니다. 컨테이너에서는 프로세스 권한뿐 아니라 TUN 장치 전달과 네트워크 capability 설정도 필요합니다. 컨테이너 안에서 enable: true만 설정해서는 충분하지 않습니다. 원격 서버에서 경로를 변경하기 전에 보조 관리 연결이나 콘솔 접속 방법을 확보해 새 규칙으로 SSH 응답 경로가 바뀌는 상황에 대비하세요.

Android 및 iOS: 시스템 VPN 연결 방식 사용

Android에서는 Clash 계열 클라이언트가 보통 시스템 VPN 권한을 통해 기기 트래픽을 처리하므로 데스크톱의 서비스 설치 절차를 따를 필요가 없습니다. 처음 연결할 때 시스템 VPN 확인 창에서 허용하고, 앱별 프록시 목록도 확인하세요. 제외된 앱은 규칙을 전체 모드로 설정해도 클라이언트로 전달되지 않습니다. 다른 VPN 앱이 이미 연결 중이면 현재 연결이 만들어지지 않을 수도 있습니다.

Android의 ‘항상 사용 VPN’과 ‘VPN 없이 연결 차단’ 설정은 연결이 끊겼을 때의 동작을 바꿉니다. 차단 기능을 켜면 클라이언트를 종료했을 때 기기가 일시적으로 인터넷에 연결되지 않을 수 있으니 복구 방법을 먼저 확인하세요. iOS에서는 해당 기능을 지원하는 클라이언트가 Network Extension으로 VPN 구성을 만들며, 시스템 안내에 따라 권한을 부여해야 합니다. 데스크톱용 mihomo의 TUN 필드를 모든 iOS 클라이언트에서 통용되는 설정으로 간주하면 안 됩니다.

5. 스위치가 아니라 트래픽 처리 여부 확인

TUN을 테스트할 때는 시스템 프록시를 일시적으로 끄고 테스트 터미널의 프록시 환경 변수도 제거하세요. 그래야 요청이 실제로는 명시적 프록시를 통해 성공하는 상황을 피할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌리세요. 아래 명령은 이번 curl 요청에서 프록시 설정을 무시하지만, 운영체제 라우팅을 통해 TUN으로 전달될 수 있습니다.

curl --noproxy "*" --connect-timeout 10 -I https://example.com

연결 기록 확인: 명령을 실행한 뒤 클라이언트의 ‘연결’ 화면에서 대상 도메인이나 IP를 찾아 적용된 규칙과 실제 출구 정책을 확인하세요.
경로 변경 확인: TUN을 끈 상태와 켠 상태의 경로 및 정책 라우팅을 비교해 다른 가상 네트워크 인터페이스가 출구로 잘못 선택되지 않았는지 확인하세요.
실제 앱으로 테스트: 원래 시스템 프록시를 따르지 않던 프로그램을 실행하고 새 연결이 만들어지는지 확인하세요. 이미 연결된 장시간 연결은 끊었다가 다시 연결해야 합니다.
UDP 별도 테스트: 실제로 UDP 트래픽을 발생시키는 앱으로 확인하세요. HTTP 요청이 성공해도 게임, 음성 통화, QUIC이 정상이라고 볼 수는 없습니다.

연결 기록에 DIRECT가 표시된다면 트래픽은 코어에 들어왔지만 규칙에서 직접 연결을 선택했을 수 있습니다. 이는 트래픽 처리 실패와 다릅니다. 반대로 브라우저에서 페이지가 열리는데 연결 기록에 해당 요청이 없다면 브라우저 확장 프로그램, 내장 프록시, 캐시 또는 다른 VPN의 영향을 먼저 확인하세요.

6. 흔한 문제는 발생 계층별로 해결

증상	먼저 확인할 항목	다음 조치
TUN을 켠 뒤 인터넷이 전혀 안 됨	권한, 출구 인터페이스, DNS, 라우팅 루프	TUN을 끄고 네트워크를 복구한 뒤 시작 로그를 보며 항목별로 다시 활성화
도메인 접속 실패, 일부 IP는 연결 가능	DNS 리스너, 가로채기, 상위 DNS 서버 연결 여부	코어 DNS 로그를 확인하고 브라우저의 보안 DNS 설정을 점검
웹은 되지만 게임 또는 음성 통화가 안 됨	UDP 지원, 규칙에 따른 출구, 서버 설정	노드가 UDP를 지원하는지 확인하고 해당 연결이 코어에 들어오는지 확인
LAN 기기 접속 이상	사설망 규칙, DNS 매핑, 라우팅 제외 설정	실제 네트워크 대역에 맞춰 직접 연결 규칙을 설정하고, 트래픽 처리에서 제외해야 할 때만 라우팅 제외 설정
일부 IPv6 연결만 실패	시스템 IPv6 경로와 코어 설정	IPv4와 IPv6 테스트를 비교하고 우회 경로나 출구 미지원 여부 확인

직접 연결 규칙과 라우팅 제외는 서로 다릅니다

예를 들어 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve는 트래픽이 코어에 들어온 뒤 직접 연결을 선택한다는 뜻입니다. 운영체제 수준에서 TUN 처리를 제외하는 설정은 아닙니다. 프린터 검색, 브로드캐스트, 멀티캐스트가 필요하다면 앱의 검색 방식과 클라이언트 지원 여부도 고려해야 합니다. TCP 직접 연결 규칙 하나만 추가한다고 문제가 모두 해결되는 것은 아닙니다.

MTU를 가장 먼저 조정하지 마세요

일부 사이트에서 로딩이 멈추거나 큰 파일 전송이 끊기는데 작은 요청은 정상일 때만 DNS, 노드, 규칙 문제를 배제한 뒤 경로 MTU를 확인하세요. 현재 값이 1500이라면 원래 값을 기록하고 1400으로 임시 변경해 비교해 볼 수 있습니다. 이 값은 진단을 위한 변수일 뿐 모든 네트워크에 권장되는 값은 아닙니다. 개선이 없다면 원래대로 되돌리세요. 프로토콜 스택, DNS, MTU를 한꺼번에 변경하면 원인을 파악하기 어렵습니다.

TUN을 끈 뒤 원래 설정 복원

먼저 클라이언트에서 TUN을 끄고 인터페이스와 자동 경로가 정리될 때까지 기다립니다.
기존 시스템 프록시, DNS, 다른 VPN 설정을 복원하고 테스트 연결을 다시 만듭니다.
여전히 연결되지 않는다면 남아 있는 경로와 DNS 설정을 확인하세요. 알 수 없는 시스템 경로를 직접 삭제하지 말고 클라이언트나 서비스를 정상적으로 재시작하는 방법부터 시도하세요.

안정적인 설정이라면 세 가지를 설명할 수 있어야 합니다. 어떤 트래픽이 가상 네트워크 인터페이스로 들어가는지, DNS를 어디서 조회하는지, 각 연결이 최종적으로 어떤 정책을 사용하는지입니다. 이 내용을 로그와 대조하면 전체 모드를 반복해서 전환하거나 노드를 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 시스템 프록시를 따르지 않는 프로그램까지 처리해야 할 때만 TUN에 필요한 권한과 라우팅 변경을 적용하세요. 브라우저와 명시적 프록시만으로 충분하다면 기존 연결 방식을 계속 사용해도 됩니다.