Android Clash TUN 모드 원리와 설정 방법: 모든 앱 트래픽 가로채기

TUN 모드는 어떤 문제를 해결하나요?

일반적인 HTTP 또는 SOCKS 프록시는 앱이 연결을 프록시 포트로 전달해야 작동합니다. 예를 들어 브라우저는 Android의 프록시 설정을 읽을 수 있고, 수동 설정을 지원하는 다운로드 도구는 로컬 127.0.0.1:7890 포트에 연결할 수 있습니다. 하지만 일부 게임, 푸시 서비스, 명령줄 도구, UDP 기반 앱은 시스템 HTTP 프록시를 읽지 않으므로 트래픽이 인터넷에 직접 연결될 수 있습니다. TUN 모드는 바로 이러한 트래픽 가로채기의 빈틈을 해결합니다.

Android에서 TUN을 활성화하면 Clash Meta for Android는 시스템이 제공하는 VpnService를 통해 가상 네트워크 인터페이스를 생성합니다. 앱이 보낸 IP 패킷은 먼저 이 인터페이스로 들어가고, mihomo 코어가 대상 주소·도메인·프로토콜·앱 정보를 식별한 뒤 설정의 규칙과 대조하여 DIRECT, REJECT 또는 특정 프록시 정책 그룹을 선택합니다. 네트워크 계층의 패킷을 처리하므로 각 앱이 HTTP 또는 SOCKS 프록시를 개별적으로 지원할 필요가 없습니다.

TUN 모드에서 하나의 연결은 어떤 과정을 거치나요?

앱이 도메인 해석을 요청하면 DNS 조회가 설정된 DNS 하이재킹 규칙에 의해 처리됩니다.
mihomo는 DNS 모드에 따라 실제 주소 또는 Fake-IP 주소를 반환하고 도메인 매핑을 저장합니다.
앱이 대상 주소에 TCP, UDP 또는 QUIC 연결을 설정하면 패킷이 Android 가상 네트워크 인터페이스로 들어갑니다.
코어는 연결에 해당하는 도메인과 프로세스 정보를 복원한 다음 위에서 아래 순서로 rules를 대조합니다.
일치한 정책 그룹이 실제 노드를 선택하고, DIRECT 규칙은 현재 물리 네트워크 인터페이스를 통해 직접 전송합니다.
응답 데이터는 원래 경로를 따라 앱으로 전달되므로 앱 자체는 프록시 포트나 노드 주소를 알 필요가 없습니다.

따라서 ‘모든 앱 트래픽 가로채기’란 제외되지 않은 모든 앱이 먼저 가상 네트워크 인터페이스를 거친다는 의미이지, 모든 연결이 반드시 프록시를 사용한다는 뜻은 아닙니다. 최종 동작은 여전히 규칙이 결정합니다. LAN 주소, 중국 본토 사이트 또는 지정 앱은 DIRECT로 유지할 수 있고, 광고 도메인은 REJECT할 수 있으며, 프록시 규칙과 일치한 연결만 노드로 전달됩니다.

TUN과 시스템 프록시 모드의 차이

시스템 프록시와 TUN은 같은 계층에 있는 두 가지 스위치가 아닙니다. 시스템 프록시는 주로 HTTP 프록시 주소를 알리며, 앱이 해당 설정을 따르는지에 따라 적용 여부가 결정됩니다. 반면 TUN은 IP 계층에서 연결을 가로채므로 적용 범위가 더 넓습니다. 웹 브라우징이나 API 디버깅만 필요하다면 시스템 프록시가 설정이 간단하고 추가 오버헤드도 적습니다. 게임, 메신저, UDP 또는 프록시 주소를 입력할 수 없는 앱에는 TUN이 더 적합합니다.

비교 항목	시스템 HTTP/SOCKS 프록시	TUN 모드
가로채는 계층	앱 계층의 프록시 요청	IP 패킷과 가상 네트워크 인터페이스
앱의 협조	앱이 시스템 프록시를 읽거나 포트를 직접 입력해야 함	일반적으로 앱에서 프록시 옵션을 제공할 필요가 없음
UDP 지원	앱과 프록시 프로토콜에 따라 다름	mihomo TUN 스택이 통합 처리 가능
DNS 일관성	앱이 로컬 프록시를 우회해 직접 해석할 수 있음	DNS 하이재킹으로 코어에 통합 전달 가능
Android 권한	로컬 포트만 사용할 때는 VPN 권한이 필요하지 않을 수 있음	VPN 연결 설정을 반드시 허용해야 함
호환성 위험	일부 앱은 프록시를 완전히 무시함	다른 VPN, 프라이빗 DNS 또는 LAN 검색과 충돌할 수 있음

성능 차이는 어떻게 이해해야 하나요?

TUN은 패킷이 사용자 공간 코어로 들어가 규칙을 대조하고 전달되는 단계를 추가하지만, 일반적으로 속도 저하의 가장 큰 원인은 아닙니다. 노드 대역폭, 해외 회선, 암호화 프로토콜, 통신사 혼잡, UDP 품질이 더 쉽게 병목을 만듭니다. Android 14, Wi-Fi 6, LAN 기준 속도 312 Mbps인 테스트 기기에서 같은 노드는 명시적 HTTP 프록시 사용 시 286 Mbps, TUN mixed 스택 사용 시 274 Mbps를 기록했으며 노드 지연 시간은 각각 41ms와 43ms였습니다. 약 4%의 차이는 대략적인 수준을 보여주기 위한 것으로, 다른 기기에도 그대로 적용되는 고정된 결론은 아닙니다.

TUN을 켠 뒤 속도가 200 Mbps에서 20 Mbps로 떨어지거나 지연 시간이 50ms에서 300ms로 늘었다면, 정상적인 TUN 전달 오버헤드만 원인으로 보지 말고 먼저 노드, MTU, UDP, DNS와 네트워크 전환 상태를 확인해야 합니다.

Clash Meta for Android에서 TUN 활성화하기

아래 경로는 Clash Meta for Android 2.11 계열의 화면을 기준으로 설명합니다. 분기 버전에 따라 ‘네트워크’가 ‘서비스’ 또는 ‘오버라이드’로 표시될 수 있지만, 핵심 항목은 TUN, 라우팅, DNS 하이재킹, 앱별 트래픽 분할입니다. 시작하기 전에 유효한 구독을 가져오고 사용 가능한 설정을 선택한 다음, 프록시 페이지에서 하나 이상의 정책 그룹에 유효한 노드가 선택되어 있는지 확인하세요.

1단계: 설정과 실행 모드 확인

‘설정’ 페이지를 열고 업데이트가 정상적으로 완료된 구독 설정을 선택합니다.
‘프록시’로 이동해 자주 사용하는 정책 그룹에서 노드를 선택한 다음 지연 시간 테스트를 한 번 실행합니다.
‘설정’ → ‘오버라이드’ → ‘규칙 모드’로 이동해 Rule을 선택합니다. Global은 대부분의 연결을 하나의 프록시로 보내고, Direct는 프록시 규칙을 우회합니다.
홈으로 돌아가 현재 실행 중인 서비스를 잠시 중지하여 네트워크 매개변수를 수정할 때 기존 세션이 유지되지 않도록 합니다.

2단계: TUN과 자동 라우팅 활성화

‘설정’ → ‘네트워크’ → ‘TUN 모드’로 이동해 TUN을 켭니다.
‘자동 라우팅’ 또는 auto-route를 켜서 코어가 가상 인터페이스에 필요한 라우팅을 설정하도록 합니다.
‘인터페이스 자동 감지’ 또는 auto-detect-interface를 켜면 Wi-Fi와 모바일 데이터가 전환된 뒤 출구 인터페이스를 다시 선택합니다.
TUN 스택은 우선 mixed를 선택하세요. 특정 기기에서 호환성 문제가 발생할 때만 system 또는 gVisor를 각각 테스트합니다.
홈으로 돌아가 서비스를 시작한 뒤 Android에 표시되는 연결 요청에서 허용을 선택합니다.

3단계: 실제로 트래픽을 가로채는지 확인

Android 상태 표시줄에 VPN 아이콘이 표시되고 클라이언트 홈 화면에 실행 중 상태가 나타나야 합니다.
‘로그’를 열고 새 도메인에 접속하면 DNS, 규칙 일치, 정책 그룹 기록이 표시되어야 합니다.
시스템 프록시를 읽지 않는 앱으로 전환해 해당 앱의 연결도 로그에 기록되는지 확인합니다.
클라이언트를 종료했을 때 공인 출구가 복구되고 다시 켰을 때 현재 정책에 따라 바뀐다면 라우팅이 전환된 것입니다.
예를 들어 192.168.1.1 같은 LAN 게이트웨이에 접속해 사설 네트워크 연결이 DIRECT로 처리되는지 확인합니다.

VPN 아이콘만 보인다고 해서 규칙과 DNS가 모두 올바르다는 뜻은 아닙니다. 더 신뢰할 수 있는 방법은 실시간 로그를 함께 확인하는 것입니다. 일반적인 로그에는 대상 도메인, 대상 포트, 일치한 규칙과 아웃바운드 정책이 표시됩니다. 예를 들어 HTTPS 연결이 DOMAIN-SUFFIX와 일치한 뒤 ‘노드 선택’ 정책 그룹으로 전달되는 식입니다. 로그에 도메인 없이 IP 주소만 표시된다면 DNS 하이재킹 또는 도메인 스니핑 설정을 추가로 확인해야 하는 경우가 많습니다.

DNS 하이재킹과 Fake-IP 설정

TUN이 연결을 가로챈 뒤에도 DNS는 규칙 정확도를 좌우하는 핵심 단계입니다. 앱이 DNS 조회를 지정 서버로 직접 보내거나 Android 프라이빗 DNS가 별도의 암호화 채널을 사용하면 코어에 대상 IP만 보일 수 있어 도메인 규칙과 트래픽 분할 효과가 떨어집니다. DNS 하이재킹의 목적은 일반적인 53번 포트 조회를 mihomo DNS 모듈이 통합 처리하도록 하는 것이지, 모든 DNS 요청을 하나의 공용 서버로 강제 전송하는 것이 아닙니다.

읽기 쉬운 mihomo 설정 구조

mixed-port: 7890
mode: rule
log-level: info

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*.com"

any:53은 일반적인 UDP 및 TCP DNS 조회를 가로채는 데 사용합니다. listen: 0.0.0.0:1053은 mihomo DNS 모듈의 수신 위치이므로 기기의 다른 서비스가 사용하는 포트와 중복되지 않아야 합니다. 198.18.0.1/16은 벤치마크용으로 예약된 주소 대역이며, Fake-IP 모드에서는 이 범위에서 임시 주소를 반환한 뒤 코어가 이를 원래 도메인으로 매핑합니다. 앱이 이 임시 주소에 연결하면 규칙 엔진이 도메인을 복원해 정확하게 대조할 수 있습니다.

Fake-IP와 Redir-Host 중 무엇을 선택할까요?

Fake-IP: 도메인 매핑이 직접적이고 규칙 대조 효율이 높아 일반적인 모바일 사용에 적합하며, 대부분의 TUN 설정에서 우선 선택할 만합니다.
Redir-Host: 앱에 실제 해석 주소를 반환하므로 실제 IP에 의존하는 일부 LAN 또는 기업용 앱과의 호환성이 좋지만, 도메인 복원 능력은 캐시와 스니핑에 더 크게 의존합니다.
Fake-IP 필터: LAN 도메인, 시간 동기화, 기기 검색 또는 특정 로그인 도메인에 문제가 발생하면 명확한 도메인을 fake-ip-filter에 추가할 수 있습니다. 범위가 지나치게 넓은 와일드카드 규칙을 바로 추가하는 것은 피하세요.

Android 프라이빗 DNS 처리 방법

Android의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프라이빗 DNS’는 DNS over TLS를 사용하며, 대상 포트는 보통 853으로 일반적인 53번 포트 조회에 해당하지 않습니다. TUN을 켠 뒤 일부 도메인이 오래 대기한다면 먼저 프라이빗 DNS를 ‘자동’으로 바꾸고 Clash 서비스를 다시 시작해 테스트하세요. 문제가 프라이빗 DNS에서 비롯된 것으로 확인된 뒤 유지 여부를 결정하면 되며, 연결이 정상일 때 무조건 끌 필요는 없습니다.

앱별 트래픽 분할, LAN 및 UDP 설정

TUN은 기본적으로 넓은 범위의 트래픽을 가로채지만, Android 클라이언트에서는 일반적으로 앱별 포함 또는 제외를 선택할 수 있습니다. 앱별 트래픽 분할은 규칙 엔진에 들어가기 전에 적용되고, Clash 규칙은 코어에 들어온 연결의 출구를 결정합니다. 두 기능은 서로 다른 계층에서 작동하므로 앱을 제외하면 해당 앱은 도메인 규칙과 정책 그룹의 제어를 받지 않습니다.

앱별 트래픽 가로채기 범위 설정

‘설정’ → ‘네트워크’ → ‘앱별 트래픽 분할’로 이동합니다.
‘선택한 앱만 프록시’를 선택하면 목록에 있는 앱만 TUN으로 들어갑니다.
‘선택한 앱 우회’를 선택하면 목록의 앱은 시스템 네트워크를 직접 사용하고 나머지 앱은 TUN으로 들어갑니다.
은행, 화면 미러링, 차량 연동 또는 기업 인증 앱에서 호환성 문제가 발생하면 먼저 해당 앱만 제외해 확인하세요. 한 번에 시스템 앱 전체를 제외하지 않는 것이 좋습니다.
앱 목록을 수정한 뒤 서비스를 중지하고 다시 시작하여 기존 연결을 모두 새로 설정합니다.

LAN 접근 유지

라우터, NAS, 프린터와 화면 미러링 기기에 접근할 때는 사설 주소 대역이 DIRECT로 처리되는지 확인해야 합니다. 일반적인 범위에는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 및 링크 로컬 주소 169.254.0.0/16가 포함됩니다. 규칙 세트를 사용하는 설정에는 보통 LAN 규칙이 이미 포함되어 있지만, 해당 규칙이 최종 MATCH 규칙보다 앞에 있는지 확인해야 합니다.

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - MATCH,노드 선택

UDP, QUIC 및 게임 연결

게임 음성 채팅, 실시간 대전, 영상 통화와 HTTP/3는 UDP를 자주 사용합니다. 노드 프로토콜과 서버가 실제로 UDP를 지원해야 하며, 클라이언트에서 TUN만 켠다고 서버 기능이 보완되지는 않습니다. 웹페이지는 정상인데 게임이 로그인 화면에서 멈추거나 음성 연결이 되지 않는다면 로그에서 대상이 UDP를 사용하는지, 선택한 정책 그룹의 노드가 UDP 전달을 허용하는지 확인하세요.

QUIC는 보통 UDP 443을 사용합니다. 회선의 UDP가 불안정하면 브라우저가 QUIC를 반복 시도해 처음 페이지를 여는 속도가 느리고 이후 TCP로 전환되는 현상이 나타날 수 있습니다. 문제를 확인할 때는 일시적으로 UDP,443을 거부하는 규칙을 사용하거나 브라우저에서 QUIC를 끄고 비교할 수 있지만, UDP 443 차단을 모든 설정의 장기 기본값으로 사용하는 것은 권장하지 않습니다.

TUN 활성화 후 자주 발생하는 문제 해결

서비스를 시작한 뒤 인터넷에 전혀 연결되지 않음

구독 다운로드만 완료한 것이 아니라 현재 설정이 실제로 선택되어 있는지 확인합니다.
‘프록시’ 페이지에서 지연 시간 테스트 결과가 표시되는 노드를 하나 선택합니다.
모드가 실수로 Direct로 설정되어 있지 않은지, 규칙 설정 마지막에 유효한 최종 규칙이 있는지 확인합니다.
로그에서 설정 구문 분석 실패, 포트 사용 중 또는 VPN 권한 거부가 표시되는지 확인합니다.
다른 VPN 유형 앱을 중지한 뒤 Clash 서비스를 다시 시작합니다.
TUN 스택을 mixed에서 system으로 바꾼 후 다시 테스트합니다.

IP 주소는 열리지만 도메인은 열리지 않음

이런 현상은 대개 DNS 문제를 가리킵니다. 먼저 dns.enable이 true인지 확인하고, DNS 서버가 현재 네트워크에서 연결 가능한지 점검하세요. 설정에서 DoH를 사용한다면 업스트림 도메인도 초기 해석을 완료할 수 있어야 합니다. 그다음 dns-hijack, Android 프라이빗 DNS, 로그의 timeout·SERVFAIL 또는 반복 조회 여부를 확인합니다.

활성화 후 배터리 소모나 발열이 눈에 띄게 증가함

TUN을 계속 실행하면 일정한 백그라운드 활동이 발생하지만, 지속적인 고전력 소모는 보통 연결 재시도를 동반합니다. ‘로그’에서 특정 도메인이 매초 반복 조회되는지, 노드가 계속 재연결되는지, UDP 세션이 지속적으로 실패하는지 확인하세요. Android 배터리 화면에서 클라이언트가 오랫동안 높은 CPU를 사용한다면 상세 로그 끄기, TUN 스택 변경, 문제가 있는 노드 비활성화를 순서대로 테스트하고, 프록시가 필요 없는 고빈도 LAN 앱은 제외해 보세요.

Wi-Fi에서 모바일 데이터로 전환한 뒤 인터넷이 끊김

auto-detect-interface가 활성화되어 있는지 확인합니다. 네트워크가 전환되면 기존 연결이 모두 매끄럽게 이전되지는 않으므로 일부 앱은 세션을 다시 설정해야 합니다. 1분이 지나도 복구되지 않으면 서비스를 중지했다가 다시 시작하세요. 라우팅 옵션이 지나치게 엄격하게 설정되어 있지 않은지, 설정에 기존 Wi-Fi 게이트웨이가 고정 출구로 지정되어 있지 않은지도 확인해야 합니다.

LAN 기기를 검색할 수 없음

화면 미러링과 기기 검색은 mDNS, SSDP 또는 브로드캐스트에 의존하는 경우가 많습니다. 먼저 기기 IP를 직접 열 수 있는지 확인한 뒤 사설 네트워크 주소 규칙을 점검하세요. IP 접속은 되지만 자동 검색이 실패한다면 화면 미러링 앱을 우회 목록에 추가하거나 UDP 5353과 같은 LAN 검색 트래픽에 DIRECT를 적용할 수 있습니다. 모든 UDP를 프록시로 보내면 브로드캐스트 데이터가 로컬 네트워크 밖으로 나갈 수 있으므로 피해야 합니다.

일부 앱에서 로그인 반복 또는 인증 코드 오류가 발생함

먼저 로그에서 로그인 API가 어떤 정책과 일치했는지 확인합니다. 앱의 기본 도메인, 인증 코드 도메인, 위험 제어 API가 서로 다른 지역의 노드를 사용하면 세션 불일치가 발생할 수 있습니다. 관련 도메인을 하나의 정책 그룹에 묶고 노드를 고정한 뒤 앱의 실패한 세션을 삭제하고 다시 시도하세요. 실제 DNS 주소에 의존하는 앱이라면 전체 DNS 강화 모드를 끄지 말고 명확한 도메인에만 Fake-IP 필터를 추가할 수 있습니다.

장기간 사용에 적합한 설정 원칙

일상적인 사용에서는 Rule 모드를 선택해 프록시, 직접 연결, 거부 동작을 규칙으로 명확하게 결정합니다.
TUN 스택은 mixed로 시작하고 재현 가능한 호환성 문제가 있을 때만 system 또는 gVisor로 전환합니다.
자동 라우팅과 인터페이스 자동 감지를 유지해 Wi-Fi, 핫스팟, 모바일 데이터 전환 후 연결이 끊기는 현상을 줄입니다.
연결 가능한 암호화 업스트림을 사용하고 로그를 통해 해석 반복과 지속적인 타임아웃이 없는지 확인합니다.
LAN 주소 규칙을 최종 규칙보다 앞에 배치하고 NAS, 프린터와 라우터 관리 페이지는 DIRECT로 유지합니다.
충돌이 확인된 앱만 제외하여 실제 트래픽 가로채기 범위가 예상과 달라지지 않도록 합니다.
TUN, DNS 또는 앱 목록을 변경한 뒤 서비스를 다시 시작해 기존 연결과 이전 DNS 캐시의 영향을 제거합니다.

TUN의 핵심 가치는 모든 트래픽을 기계적으로 하나의 노드로 보내는 데 있지 않고, mihomo에 통합되고 관찰 가능한 트래픽 진입점을 제공하는 데 있습니다. 가상 네트워크 인터페이스가 트래픽을 가로채고, DNS 모듈이 도메인 정보를 유지하며, 규칙이 목적지를 결정하고, 정책 그룹이 출구를 선택합니다. 이 네 가지 계층을 기준으로 점검하면 클라이언트를 계속 바꾸거나 스위치를 무작정 전환하는 것보다 문제를 빠르게 찾을 수 있습니다.

프록시를 지원하는 브라우저로 특정 서비스에 접속하는 것만 필요하다면 명시적 HTTP 또는 SOCKS 프록시로 충분합니다. 게임, UDP, 백그라운드 서비스와 시스템 프록시를 읽지 않는 앱까지 포함해야 할 때 TUN을 활성화하세요. 선택 기준은 가로채기 범위여야 하며, 모든 상황에서 TUN을 켜야 하는 성능 옵션으로 보아서는 안 됩니다.