1. TUN으로 트래픽을 처리해도 모든 연결이 프록시를 거치는 것은 아닙니다
브라우저는 인터넷에 연결되지만 게임이나 터미널 도구가 Clash 연결 목록에 나타나지 않는다면, 해당 앱이 시스템 프록시를 사용하지 않을 수 있습니다. 시스템 프록시는 앱에 HTTP 또는 SOCKS 프록시 주소를 알려주는 방식입니다. 반면 TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 통해 IP 패킷을 코어로 전달하므로, 앱이 프록시 프로토콜을 지원하지 않아도 트래픽을 처리할 수 있습니다.
이 문서의 설정 항목은 mihomo 코어를 사용하는 클라이언트를 기준으로 설명합니다. Clash는 클라이언트 생태계에서 널리 쓰이는 이름일 뿐, 같은 이름을 쓰는 모든 클라이언트나 구버전이 동일한 TUN 기능을 지원하는 것은 아닙니다. 설정 전에 ‘정보’ 또는 ‘코어’ 화면에서 클라이언트 버전, 코어 이름, 코어 버전을 확인하세요. 구형 Clash 코어를 사용 중이라면 mihomo 옵션을 그대로 적용하지 마세요.
‘전체 트래픽’에도 예외가 있습니다. 제외된 앱이나 서브넷, 처리 대상으로 설정되지 않은 IPv6 트래픽, 다른 VPN의 전용 라우팅은 TUN을 우회할 수 있습니다. LAN 접속, 멀티캐스트 검색, 시스템 예약 트래픽도 모두 원격 프록시를 거쳐야 하는 것은 아닙니다. 작동 여부는 토글 색상만 보지 말고 연결 기록과 실제 라우팅을 함께 확인하세요.
2. 시작 전 확인: 노드, 권한, 다른 VPN
- 먼저 현재 설정이 작동하는지 확인하세요. 구독을 가져오고 설정과 사용 가능한 노드를 선택한 뒤, 시스템 프록시를 켜서 접속 가능한 HTTPS 페이지를 엽니다. 노드 자체가 연결되지 않는다면 TUN으로 해결할 수 없습니다.
- 현재 설정을 저장하세요. 설정을 백업하고 시스템 프록시, DNS, TUN, 서비스 모드의 기존 상태를 기록합니다. 구독 주소, 액세스 토큰, 노드 비밀번호를 공개 로그에 올리지 마세요.
- 다른 VPN은 잠시 종료하세요. 가속기, 기업용 터널, 다른 프록시 클라이언트도 포함됩니다. 기본 경로나 DNS 설정을 동시에 변경할 수 있으므로, 기업 관리 기기라면 먼저 관리 정책을 확인하세요.
- 프록시 프로토콜 지원 여부를 확인하세요. TUN이 UDP를 받을 수 있어도 선택한 노드와 서버가 UDP 전달을 지원한다는 뜻은 아닙니다. 게임, 음성 통화, QUIC은 각각 따로 확인해야 합니다.
데스크톱 클라이언트에서 가상 네트워크 인터페이스를 만들거나 라우팅을 설정하려면 보통 관리자 권한, root 권한 또는 권한이 제한된 보조 프로세스가 필요합니다. Android는 시스템 VPN 권한을 사용하므로 데스크톱의 ‘서비스 모드’와 다르며, 일반적으로 기기 root 권한도 필요하지 않습니다.
3. 플랫폼별 실행 방법과 권한 차이
아래 데스크톱 안내는 Clash Verge Rev와 같은 mihomo GUI 클라이언트에서 흔히 볼 수 있는 메뉴 구성을 기준으로 합니다. 배포판에 따라 ‘TUN 모드’가 ‘가상 네트워크 모드’로 표시될 수 있습니다. 같은 메뉴가 없다면 현재 버전의 안내를 확인하고, 출처가 불분명한 범용 드라이버 패치는 다운로드하지 마세요.
Windows: 서비스를 설치한 뒤 가상 네트워크 인터페이스 켜기
- ‘설정’ → ‘서비스 모드’로 이동해 설치 또는 활성화를 실행한 다음, Windows UAC 창에서 권한을 허용합니다. 해당 버전에서 서비스 메뉴가 ‘설정’ → ‘시스템 설정’ 아래에 있다면 실제 화면의 메뉴를 따르세요.
- 서비스 상태가 실행 중인지 확인한 뒤 ‘설정’ → ‘TUN 모드’ 또는 ‘가상 네트워크 모드’에서 스위치를 켭니다. 처음 켠 뒤 인터페이스가 초기화될 때까지 기다리고, 연속해서 켰다 끄지 마세요.
- 로그에서 권한 거부, 인터페이스 생성 실패, 경로 추가 실패가 있는지 확인하세요. Windows 클라이언트는 Wintun 등의 구성 요소를 사용할 수 있으며, 드라이버 파일의 제공 방식은 클라이언트마다 다릅니다.
- ‘연결’ 화면을 열고 이전에 시스템 프록시를 사용하지 않던 앱을 실행해 새 연결 기록이 생기는지 확인합니다. 해당 연결에 적용된 규칙과 정책 그룹도 확인하세요.
서비스 모드는 권한이 필요한 작업을 제한된 백그라운드 서비스에서 수행하도록 합니다. 서비스 모드를 켰다고 프록시가 반드시 실행되는 것은 아닙니다. 화면에 ‘서비스 설치됨’으로 표시되는데도 실패한다면 서비스가 실행 중인지, 코어 프로세스가 시작됐는지, 보안 소프트웨어가 네트워크 구성 요소를 차단하는지 확인하세요. 방화벽을 계속 꺼 두는 방식으로 해결하지 마세요.
macOS: 보조 서비스 권한을 허용하고 utun 인터페이스 확인하기
- 클라이언트의 ‘설정’ → ‘서비스 모드’에서 보조 서비스를 설치하거나 복구하고, 시스템 안내에 따라 관리자 인증 정보를 입력합니다. 관리자 비밀번호를 구독 가져오기 창이나 노드 설정에 입력하지 마세요.
- ‘TUN 모드’를 켜고 클라이언트에 필요한 시스템 권한을 허용합니다. 권한 창의 내용은 클라이언트 구현 방식과 macOS 버전에 따라 다를 수 있습니다.
- 터미널에서
ifconfig로 인터페이스를 확인하고netstat -rn으로 라우팅을 확인하세요. macOS에서는 일반적으로utun인터페이스를 사용합니다.
시스템에는 원래 utun 인터페이스가 여러 개 있을 수 있으므로, utun이 보인다고 현재 Clash가 트래픽을 처리 중이라는 뜻은 아닙니다. 활성화 전후의 라우팅 변화와 클라이언트 로그를 함께 확인하세요. macOS의 일반적인 TUN 구현은 시스템 인터페이스를 사용하므로 Windows의 Wintun 설치 방법을 적용하면 안 됩니다.
Linux: TUN 장치와 네트워크 관리 권한 확인하기
GUI 클라이언트에서는 기본 제공 서비스 모드를 우선 사용하세요. mihomo를 직접 실행하는 경우에는 배포판 문서에 따라 systemd 서비스와 권한을 설정합니다. 장치가 있는지 확인하려면 다음 명령을 실행하세요.
ls -l /dev/net/tun
ip link show
ip route show
ip -6 route show/dev/net/tun이 없다면 커널의 TUN 지원 여부, 모듈 로드 상태, 컨테이너에 장치가 전달됐는지 확인하세요. 인터페이스 생성과 라우팅 변경에는 보통 CAP_NET_ADMIN이 필요합니다. 컨테이너에서 root로 실행하더라도 필요한 권한이 없을 수 있습니다. GUI 클라이언트 전체에 광범위한 영구 권한을 부여하지 마세요.
활성화한 뒤 ip rule show와 라우팅 테이블을 확인해 NetworkManager, 컨테이너 네트워크, 다른 VPN의 규칙과 충돌하는지 점검하세요. 일부 mihomo 버전은 Linux 전용 auto-redirect를 제공하지만, 모든 플랫폼에서 필요한 설정은 아닙니다. 모든 기기에 무조건 추가하지 마세요.
Android: VPN 연결을 허용하고 앱별 설정 확인하기
- mihomo 기반 Android 클라이언트에서 설정을 가져온 다음 홈 화면의 시작 또는 연결 버튼을 누릅니다.
- 처음 시작할 때 시스템의 ‘연결 요청’ 창에서 VPN 연결을 허용하세요. Android 클라이언트는 보통
VpnService로 가상 인터페이스를 만들므로 데스크톱 드라이버를 따로 설치할 필요가 없습니다. - 클라이언트 ‘설정’에서 ‘접근 제어’ 또는 ‘앱별 프록시’를 확인하세요. ‘선택한 앱만 프록시 사용’이 켜져 있다면 선택하지 않은 앱은 트래픽 처리 대상에서 제외됩니다.
- 앱을 백그라운드로 보낸 뒤 연결이 끊긴다면 시스템 ‘설정’ → ‘앱’ → 해당 클라이언트 → ‘배터리’에서 백그라운드 제한을 확인하세요. 메뉴 이름은 시스템마다 다를 수 있습니다.
Android에서는 일반적으로 동일한 사용자 프로필에서 VpnService 기반 VPN을 하나만 동시에 사용할 수 있습니다. 다른 VPN, 광고 차단기, 가속기를 시작하면 현재 연결이 대체될 수 있습니다. ‘VPN 상시 연결’과 ‘VPN 미연결 시 연결 차단’은 시스템 수준 설정입니다. 잘못 설정하면 인터넷이 끊길 수 있으므로 기본 작동을 확인한 뒤에만 활성화하세요.
4. stack 선택: system, gvisor, mixed
stack은 TUN 내부에서 네트워크 트래픽을 처리하는 프로토콜 스택 옵션이지, 프록시 프로토콜이나 노드 종류가 아닙니다. mihomo에서 흔히 사용하는 값은 system, gvisor, mixed이며, 실제 지원 여부는 코어 빌드와 플랫폼에 따라 다릅니다.
| 옵션 | 주요 차이 | 선택 기준 |
|---|---|---|
system | 시스템 프로토콜 스택 기반 구현으로 트래픽 처리 | 클라이언트 기본값이고 연결에 문제가 없다면 그대로 사용하세요. |
gvisor | 사용자 공간 네트워크 프로토콜 스택 사용 | 호환성 문제가 발생하면 비교 테스트용으로 사용할 수 있습니다. |
mixed | mihomo에서 TCP는 system, UDP는 gvisor 사용 | TCP와 UDP를 각각 확인해야 하며, 웹페이지 테스트만으로 판단할 수 없습니다. |
특정 stack을 ‘게임에 가장 좋은 설정’으로 단정하지 마세요. 우선 클라이언트 기본값을 유지하고, 특정 앱에서 연결 문제가 생기면 한 번에 옵션 하나만 바꾼 뒤 TUN을 다시 시작해 테스트하세요. MTU도 같은 원칙을 따릅니다. 기본값을 사용하고, 대용량 패킷 전송 정체나 터널 캡슐화 문제 등 분명한 징후가 있을 때만 조정하세요. 지연 시간이 한 번 높게 나왔다고 9000으로 바꾸지 마세요.
5. DNS 하이재킹 설정: 53번 포트의 쿼리 전달
앱은 먼저 도메인을 IP 주소로 변환한 다음 연결을 시작합니다. DNS 쿼리가 예상한 해석 경로로 전달되지 않으면 도메인 규칙이 제대로 적용되지 않거나, 잘못된 주소가 반환되거나, 연결 시간이 초과될 수 있습니다. TUN의 dns-hijack은 지정된 기존 DNS 요청을 코어의 DNS 모듈로 전달합니다. 여기서 ‘하이재킹’은 로컬에서 요청 경로를 바꾸는 것이며 원격 웹사이트를 수정하는 것이 아닙니다.
mihomo 설정 예시
아래 예시는 IPv4 TUN, 자동 라우팅, UDP/TCP 53번 포트 가로채기를 활성화합니다. 구독 설정 전체를 대체하는 완전한 설정 파일은 아닙니다. 먼저 백업한 다음 클라이언트에서 지원하는 덮어쓰기 또는 병합 기능으로 적용하세요. 기존에 tun이나 dns 항목이 있다면 내용을 병합하고, YAML 최상위에 같은 이름의 키를 중복해서 만들지 마세요.
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
- 119.29.29.29auto-route: 코어가 트래픽 처리에 필요한 경로를 자동으로 설정합니다. 제외된 경로나 다른 소프트웨어가 선점한 경로까지 처리한다고 보장하지는 않습니다.auto-detect-interface: 외부로 연결할 인터페이스를 자동으로 선택합니다. 여러 네트워크 인터페이스, 핫스팟, 기업 VPN 환경에서는 결과를 확인해야 합니다.any:53과tcp://any:53: 각각 기존 UDP 및 TCP DNS 쿼리에 적용됩니다. 실제 적용 범위는 해당 트래픽이 TUN으로 들어오는지에 따라 달라집니다.127.0.0.1:1053: 로컬 DNS 수신 주소입니다. 시스템 DNS 설정에 1053번 포트가 붙은 주소를 직접 지정할 수는 없는 경우가 많으며, 이 예시는 TUN으로 쿼리를 전달합니다.nameserver: 예시에는 기존 DNS 업스트림 두 곳이 지정되어 있습니다. 실제로는 네트워크 접근성, 개인정보 보호 요구사항, 분할 DNS 구성에 맞춰 선택해야 하며 모든 네트워크에서 사용할 수 있는 것은 아닙니다.
Fake-IP의 예약 주소는 매핑용입니다
위 설정에서는 DNS가 198.18.0.0/16 범위의 매핑 주소를 반환하고, 코어가 연결을 도메인에 다시 연결할 수 있습니다. 이 주소는 대상 웹사이트의 실제 공인 IP가 아닙니다. LAN 기기 검색, 특정 게임, 내부 도메인에서 호환성 문제가 생기면 전체 DNS 설정을 삭제하지 말고 해당 도메인을 fake-ip-filter에 추가하거나 클라이언트에서 지원하는 다른 DNS 모드를 사용하세요.
Android의 ‘비공개 DNS’도 별도로 고려해야 합니다. 앱이 코어 DNS를 우회해 다른 경로로 이름을 해석한다면 연결과 분할 라우팅 결과를 확인하세요. IPv6도 처음부터 끝까지 설정해야 합니다. 이 예시에는 IPv6 트래픽 처리 방법이 없으므로 IPv6까지 처리된다고 볼 수 없습니다. 듀얼 스택을 켜기 전에 코어, 라우팅, DNS 응답, 노드 지원 여부를 확인하세요.
6. 3단계 점검: 인터페이스, 연결 기록, DNS
- 인터페이스와 라우팅을 확인하세요. 로그에서 TUN이 반복 재시도되는 것이 아니라 정상적으로 시작됐는지 확인합니다. Windows에서는
route print, macOS에서는netstat -rn, Linux에서는ip route show로 변경 사항을 확인하세요. 구현 방식에 따라 분할 경로나 정책 라우팅을 사용하므로 기본 경로가 직접 교체되지 않을 수도 있습니다. - 시스템 프록시를 사용하지 않는 앱이 코어에 들어오는지 확인하세요. 앱 자체의 프록시 설정을 끈 뒤 연결을 다시 시도하고 Clash의 ‘연결’ 화면을 확인합니다. 데스크톱에서는 비교를 위해 시스템 프록시를 잠시 끄고 TUN만 사용할 수 있습니다. 기업 관리 기기의 설정은 임의로 변경하지 마세요.
- DNS 응답과 규칙 적용 결과를 확인하세요. 캐시에 없는 도메인을 조회하고 로그, DNS 응답, 후속 연결 결과가 일치하는지 확인합니다. Fake-IP 모드에서 매핑 주소가 표시되는 것은 오류가 아닙니다. 연결이 수립되는지, 예상한 정책이 적용되는지가 중요합니다.
다음 명령으로 HTTPS 요청을 한 번 테스트할 수 있습니다. 연결 경로를 확인하는 용도이며 속도 측정이나 실제 성능을 보장하지 않습니다.
curl --noproxy "*" -I --connect-timeout 10 https://example.com--noproxy "*"는 curl의 일반 프록시 설정을 우회해 TUN 경로를 확인할 때 사용합니다. Windows PowerShell에서는 명령 별칭 차이를 피하려면 curl.exe를 명시하세요. 테스트 후 연결 목록에서 대상 도메인, 적용된 규칙, 아웃바운드 정책을 확인해야 합니다. 명령이 성공했다는 사실만으로 원격 프록시를 거쳤다고 단정할 수 없습니다.
7. 자주 발생하는 문제와 안전한 복구 방법
TUN을 켠 뒤 모든 웹사이트에 접속할 수 없음
먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음 서비스 권한, 현재 설정, DNS 업스트림 연결, 다른 VPN을 점검하세요. TUN을 꺼도 도메인 조회가 되지 않는다면 남아 있는 수동 DNS 또는 시스템 프록시 설정을 확인하고, 작업 전에 기록한 상태로 복원하세요. 클라이언트를 재설치하면서 노드, stack, DNS까지 한꺼번에 바꾸면 원인을 찾기 어렵습니다.
웹은 열리지만 게임이나 음성 통화가 작동하지 않음
먼저 관련 프로세스가 연결 목록에 나타나는지, 다음으로 노드가 UDP를 지원하는지 확인하세요. 브라우저에서 웹페이지가 열린다는 사실은 일부 TCP 또는 HTTPS 경로만 정상이라는 뜻일 수 있습니다. Android에서는 게임이 앱별 규칙에서 제외됐는지 확인하고, 데스크톱에서는 게임이 특정 네트워크 인터페이스에 연결돼 있는지와 다른 가속기의 라우팅이 있는지 살펴보세요.
LAN 프린터, NAS 또는 기업 도메인에 연결할 수 없음
대상에 직접 연결해야 하는지, 기업 VPN 경로를 사용해야 하는지 먼저 확인한 뒤 관련 규칙, DNS 해석 정책 또는 TUN 라우팅 제외를 조정하세요. 규칙의 DIRECT와 라우팅 제외는 다릅니다. DIRECT는 코어가 트래픽을 처리한 뒤 직접 연결하고, 라우팅 제외는 지정한 트래픽이 TUN에 들어오지 않게 합니다. 내부 도메인이 기업 DNS에 의존한다면 공용 DNS 업스트림으로 대체하기 어렵습니다.
클라이언트를 종료한 뒤에도 네트워크가 복구되지 않음
클라이언트를 다시 열고 TUN을 정상적으로 끈 다음 종료해 프로그램이 정리 작업을 수행하도록 하세요. 이후 시스템 프록시, DNS, 남아 있는 서비스 상태를 확인합니다. 서버를 원격으로 조작할 때는 기본 경로를 바꾸면 SSH 연결이 끊길 수 있으므로 콘솔이나 별도 대역 외 접속 수단을 미리 준비하세요. 유일한 관리 연결에서 바로 설정을 시험하지 마세요.