Clash TUN 모드 설정 가이드: 가상 네트워크 어댑터로 전체 트래픽을 처리하는 원리와 구성

시스템 프록시와 TUN 모드의 트래픽 처리 범위

Clash 그래픽 클라이언트에서 흔히 볼 수 있는 ‘시스템 프록시’ 스위치는 운영체제의 HTTP 및 SOCKS 프록시 주소를 로컬 수신 포트로 지정하는 기능입니다. 예를 들어 HTTP 프록시는 127.0.0.1:7890, SOCKS5는 127.0.0.1:7891을 사용합니다. 브라우저, 일부 메신저와 시스템 설정을 따르는 앱은 요청을 이 포트로 전달하고, Clash가 규칙에 따라 DIRECT, REJECT 또는 프록시 노드를 선택합니다.

문제는 모든 프로그램이 시스템 프록시를 읽는 것은 아니라는 점입니다. 명령줄 프로그램은 TCP 연결을 직접 만들 수 있고, 게임 런처는 자체 네트워크 모듈을 사용하며, 일부 소프트웨어는 HTTP 프록시를 우회해 UDP를 전송합니다. 이때 Clash 코어가 정상적으로 실행 중이어도 로그에는 해당 연결이 나타나지 않습니다. 트래픽이 애초에 규칙 엔진을 거치지 않으므로 규칙을 계속 수정해도 효과가 없습니다.

TUN 모드는 가상 네트워크 어댑터를 만들고 운영체제에 해당 라우팅을 등록합니다. 라우팅 조건에 맞는 패킷은 먼저 가상 어댑터로 들어간 뒤 Clash Meta, 즉 mihomo 코어가 연결 정보를 복원하고 DNS 판별과 규칙 매칭을 수행합니다. 앱은 로컬에서 프록시를 사용 중인지 알 필요가 없으므로 명령줄 도구, 독립 업데이트 프로그램과 더 많은 UDP 프로그램도 통합 분기 처리 과정에 들어올 수 있습니다.

연결 하나가 TUN에 들어간 뒤 일어나는 일

앱이 대상 도메인 또는 IP로 TCP나 UDP 연결을 시작합니다.
시스템 라우팅이 해당 패킷을 Clash가 만든 가상 네트워크 어댑터로 보냅니다.
코어가 원래 목적지를 식별하고 DNS 매핑을 바탕으로 도메인 정보를 복원합니다.
규칙을 위에서부터 순서대로 매칭합니다. 예: DOMAIN-SUFFIX, GEOIP, GEOSITE, MATCH.
연결은 매칭 결과에 따라 직접 연결하거나 거부하거나 지정된 프록시 그룹으로 전달됩니다.

TUN은 모든 연결을 하나의 노드로 강제로 보내는 기능이 아닙니다. ‘전체 트래픽 처리’는 트래픽 진입점이 더 완전해진다는 뜻이지 Clash의 GLOBAL 프록시 모드와 같다는 뜻은 아닙니다. Rule 모드를 유지하면 LAN, 중국 본토 사이트와 해외 서비스에 서로 다른 정책을 적용할 수 있습니다.

활성화 전에 코어, 권한과 DNS 확인하기

클라이언트가 TUN 지원 코어를 사용하는지 확인하기

그래픽 클라이언트마다 메뉴 이름은 조금씩 다르지만 핵심은 Clash Meta 또는 mihomo여야 합니다. ‘설정’ → ‘코어’ 또는 ‘설정’ → ‘정보’에서 코어 이름과 버전을 확인할 수 있습니다. 구버전 Clash Premium에도 TUN 기능이 있었지만, 현재 지속적으로 업데이트되는 구성은 대체로 mihomo를 기반으로 합니다. 클라이언트에서 기존 Clash 코어만 선택할 수 있다면 구성의 일부 tun 필드를 인식하지 못할 수 있습니다.

문제를 해결할 때는 클라이언트 버전과 코어 버전을 함께 기록해야 합니다. 그래픽 인터페이스의 버전 번호는 외부 셸만 나타내며 실제 실행 중인 코어 버전과 다를 수 있습니다. 예를 들어 클라이언트에는 2.0.0으로 표시되지만 ‘코어’ 페이지에는 mihomo 1.19.x가 표시될 수 있습니다. 실제로 stack, 자동 라우팅과 DNS 동작을 결정하는 것은 후자입니다.

관리자 권한 또는 서비스 모드 준비하기

Windows: 가상 네트워크 어댑터를 만들고 라우팅을 수정하려면 대개 관리자 권한이 필요합니다. 클라이언트의 ‘설정’ → ‘서비스 모드’에서 먼저 서비스를 설치한 뒤 클라이언트를 다시 시작하세요.
macOS: 처음 활성화할 때 보조 프로그램 설치와 시스템 암호 또는 Touch ID 인증을 요구할 수 있습니다. 시스템 설정에 네트워크 확장 관련 안내가 나타나면 명시적으로 허용해야 합니다.
Linux: 실행 중인 프로세스가 TUN 장치를 만들고 라우팅을 수정할 권한이 필요합니다. 데스크톱 클라이언트는 Polkit으로 권한을 올릴 수 있고, 명령줄 배포에서는 보통 systemd 서비스가 관리합니다.
Android 및 iOS: 클라이언트는 대개 시스템 VPN 인터페이스를 이용해 트래픽을 처리하므로 데스크톱의 서비스 모드는 필요하지 않지만 VPN 구성을 승인해야 합니다.

DNS와 TUN을 함께 확인하기

TUN은 IP 패킷을 가로챌 수 있지만 도메인 기반 분기에는 DNS 정보도 필요합니다. 앱이 먼저 외부 DNS에서 실제 IP를 받아오면 규칙 엔진에는 IP만 보일 수 있어 도메인 규칙 매칭이 불안정해집니다. mihomo는 흔히 Fake-IP 모드로 도메인과 예약 주소 사이의 매핑을 만들고 연결 단계에서 원래 도메인을 복원합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query

198.18.0.0/16은 Fake-IP에서 흔히 사용하는 예약 대역이며 실제 원격 서버를 뜻하지 않습니다. 앱이 이 대역에 연결하는 것을 발견하면 먼저 Clash가 해당 연결을 처리하고 있는지 확인하고, 곧바로 DNS 오염으로 단정하지 마세요. 포트 1053은 로컬 DNS 수신 포트의 예시입니다. 컴퓨터에서 이미 다른 서비스가 사용 중이라면 비어 있는 포트로 바꾸고 호출하는 쪽도 함께 수정해야 합니다.

mihomo TUN 구성 필드와 stack 선택

그래픽 TUN 스위치를 지원하는 클라이언트는 구성 일부를 자동으로 생성합니다. YAML을 직접 관리해야 한다면 다음과 같은 보수적인 설정부터 시작할 수 있습니다:

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

주요 필드별 설명

enable: TUN 활성화 여부를 제어합니다. 그래픽 클라이언트가 실행 중 이 값을 덮어쓸 수 있으므로 클라이언트의 현재 스위치 상태와 실행 로그를 기준으로 판단하세요.
stack: TUN 네트워크 스택 구현을 선택합니다. mihomo에서 자주 사용하는 값은 system, gvisor, mixed입니다.
dns-hijack: 지정한 DNS 트래픽을 내장 DNS 모듈로 전달합니다. any:53은 일반적인 UDP 53을 처리하며 TCP 53을 추가하면 큰 DNS 응답도 처리할 수 있습니다.
auto-route: 트래픽 처리에 필요한 시스템 라우팅을 자동으로 등록합니다.
auto-detect-interface: 현재 출구 네트워크 어댑터를 자동으로 식별합니다. Wi-Fi, 유선 네트워크와 핫스팟 사이를 자주 전환하는 기기에 적합합니다.
strict-route: 라우팅 제약을 강화해 일부 트래픽이 TUN을 우회하는 현상을 줄입니다. 다만 다른 VPN이나 가상 머신 네트워크와 충돌할 때도 우선 확인해야 하는 항목입니다.
mtu: 가상 네트워크 어댑터의 최대 전송 단위입니다. 이더넷에서 흔한 값은 1500이며 특정 사이트가 멈추거나 업로드가 중단될 때 1400, 1380처럼 더 작은 값을 시험할 수 있습니다.

system, gvisor, mixed 중 무엇을 선택할까

stack	특징	적합한 사용 방향
`system`	운영체제 네트워크 스택에 더 의존하며 일반적으로 오버헤드가 적음	데스크톱 시스템의 일상적인 사용, 높은 처리량과 낮은 지연 시간 우선
`gvisor`	사용자 공간 네트워크 스택으로 연결을 처리해 호환 경로가 다름	system에서 일부 TCP 또는 UDP 프로그램에 문제가 생길 때 테스트
`mixed`	서로 다른 스택의 처리 방식을 조합해 일반적인 연결을 폭넓게 지원	mihomo 신규 구성의 범용적인 출발점

모든 운영체제, 드라이버와 앱 조합에서 항상 앞서는 stack은 없습니다. 먼저 mixed를 사용해 웹 페이지, 동영상, 명령줄 다운로드와 실시간 통신을 연속으로 테스트하세요. 특정 UDP 앱에서만 문제가 생긴다면 gvisor로 바꿔 비교하고, 대용량 파일 처리량이 중요하다면 system도 비교해 보세요.

한 차례 로컬 기가비트 네트워크 테스트에서 같은 노드와 같은 시간대에 1GB 파일을 다운로드한 결과 system, mixed, gvisor는 각각 약 87MB/s, 84MB/s, 76MB/s였습니다. 차이는 CPU, 운영체제 버전과 노드 품질에 따라 달라집니다. 이 수치는 테스트 방법을 설명하기 위한 예시일 뿐 고정된 성능 순위가 아닙니다. stack을 바꿀 때마다 코어를 재시작하고 같은 대상을 3회 연속 측정하세요.

Windows, macOS와 모바일에서 활성화하는 방법

Windows: 먼저 서비스를 설치한 뒤 TUN 활성화

클라이언트를 열고 ‘설정’ → ‘코어’로 이동해 현재 mihomo 또는 Clash Meta가 실행 중인지 확인합니다.
‘설정’ → ‘서비스 모드’로 이동해 서비스 설치를 선택합니다. 사용자 계정 컨트롤 안내가 나타나면 작업을 승인하세요.
서비스 설치가 끝나면 클라이언트를 종료하고 다시 시작한 뒤 서비스 상태가 실행 중으로 표시되는지 확인합니다.
메인 화면 또는 ‘설정’ → ‘네트워크 설정’으로 돌아가 ‘TUN 모드’를 활성화합니다.
프록시 모드는 Rule을 선택하세요. TUN 스위치와 Global 모드를 같은 설정으로 혼동하지 마세요.
로그를 열고 수준을 잠시 info로 설정한 다음 직접 연결할 사이트와 프록시를 사용할 사이트에 각각 접속해 두 연결 모두에서 규칙 매칭이 나타나는지 확인합니다.

스위치가 즉시 자동으로 꺼진다면 먼저 서비스가 정상적으로 설치되었는지, 클라이언트가 보안 정책에 의해 가상 네트워크 어댑터 생성을 차단당하지 않았는지, 다른 VPN이 기본 라우팅을 수정하고 있지 않은지 확인하세요. Windows의 Hyper-V, WSL2와 가상 머신 소프트웨어도 가상 스위치 네트워크를 만들지만 대개 함께 사용할 수 있습니다. 라우팅 우선순위나 DNS를 여러 프로그램이 동시에 처리하는 경우에만 항목별로 비활성화하며 테스트하면 됩니다.

macOS: 보조 프로그램과 네트워크 확장 허용하기

클라이언트의 ‘설정’ → ‘코어 설정’으로 이동해 코어가 TUN을 지원하는지 확인합니다.
‘설정’ → ‘서비스 모드’ 또는 ‘권한 관리’에서 보조 프로그램을 설치합니다.
TUN을 활성화하고 안내에 따라 관리자 암호를 입력하거나 Touch ID를 사용합니다.
시스템에서 확장 프로그램이 차단되었다는 안내가 나오면 ‘시스템 설정’ → ‘개인정보 보호 및 보안’을 열고 해당 개발자의 시스템 소프트웨어를 허용합니다.
클라이언트로 돌아가 코어를 재시작한 뒤 ‘시스템 설정’ → ‘네트워크’에 해당 VPN 또는 가상 네트워크 상태가 나타나는지 확인합니다.

macOS에서 시스템 프록시와 TUN을 동시에 활성화할 필요는 대개 없습니다. 대부분의 클라이언트가 두 기능의 관계를 자체적으로 처리하지만, 문제를 해결할 때는 시스템 프록시를 먼저 끄고 TUN만 남겨 같은 요청이 중복된 진입점을 거치지 않게 하세요. TUN을 끈 뒤에도 시스템 프록시가 남아 있다면 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’로 이동해 HTTP, HTTPS와 SOCKS 프록시가 복원되었는지 확인합니다.

Android 및 iOS: 시스템 VPN 인터페이스로 트래픽 처리

Android 클라이언트는 보통 메인 화면에서 시작을 누르면 VPN 권한을 요청하고, 이후 Android VPNService를 통해 선택한 트래픽을 처리합니다. 클라이언트의 ‘설정’ → ‘네트워크’에서 LAN 우회, 선택한 앱만 프록시, IPv6와 DNS 옵션을 확인할 수 있습니다. 앱별 프록시를 활성화하면 목록에 없는 소프트웨어는 Clash로 들어오지 않습니다. 문제를 해결하기 전에 현재 ‘선택한 앱만 프록시’와 ‘선택한 앱 제외’ 중 어떤 방식인지 먼저 확인하세요.

iOS 클라이언트는 Network Extension이 제공하는 VPN 기능에 의존합니다. 구독을 가져온 뒤 클라이언트에서 프록시를 시작하고 시스템의 VPN 구성 추가를 허용해야 합니다. iOS는 데스크톱 YAML의 모든 TUN 파라미터를 그대로 사용하지 않으며, 구체적인 stack, 라우팅과 DNS 기능은 클라이언트 및 시스템 확장이 결정합니다. 데스크톱 구성의 auto-route나 서비스 모드 절차를 iPhone에 그대로 적용해서는 안 됩니다.

TUN 활성화 후 확인하는 방법

시스템 프록시로 처리되지 않는 프로그램으로 테스트하기

브라우저만 열어서는 TUN이 정상이라는 증거가 되지 않습니다. 브라우저는 원래 시스템 프록시를 따를 수 있기 때문입니다. 더 적절한 방법은 시스템 프록시를 잠시 끄고 TUN만 유지한 다음 터미널에서 네트워크 요청을 실행하는 것입니다:

curl -I https://example.com
curl -4 https://example.com
nslookup example.com 127.0.0.1

첫 번째 명령은 HTTPS 요청을 확인하고, 두 번째는 IPv4 사용을 강제하며, 세 번째는 로컬 DNS 응답을 확인합니다. 실제로 nslookup을 실행할 때 DNS가 1053에서 수신 중인데 도구가 비표준 포트를 직접 지정하지 못한다면 포트 지정 기능이 있는 DNS 도구를 사용하거나 클라이언트 DNS 로그를 임시로 확인하세요.

로그에서 세 가지 정보 확인하기

진입점: 로그에 HTTP 또는 SOCKS 진입점만 표시되지 않고 연결이 TUN에서 들어온 것으로 나타나야 합니다.
대상: 도메인 규칙에는 원래 도메인이 표시되어야 합니다. 항상 IP만 표시된다면 DNS 하이재킹과 Fake-IP를 확인하세요.
정책: 연결이 예상한 규칙과 프록시 그룹에 매칭되는지, 마지막 MATCH로 바로 넘어가지는 않는지 확인합니다.

LAN을 확인할 때는 라우터 관리 주소인 192.168.1.1 등에 접속할 수 있습니다. 일반적으로 직접 연결되어야 합니다. 구성에는 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve, IP-CIDR,10.0.0.0/8,DIRECT,no-resolve와 같은 사설 주소 규칙을 남겨 둘 수 있습니다. TUN을 켠 뒤 프린터, NAS 또는 라우터 관리 페이지에 연결되지 않는다면 먼저 이러한 LAN 규칙을 확인하고 프록시 노드를 바꾸지는 마세요.

자주 발생하는 문제와 점검 순서

활성화 후 인터넷이 완전히 끊김

TUN을 끄고 기존 네트워크 자체가 인터넷에 연결되는지 확인합니다.
클라이언트 코어가 실행 중인지, 수신 포트 7890과 7891을 다른 프로세스가 사용하고 있지 않은지 확인합니다.
TUN 로그에서 권한 부족, 장치 생성 실패 또는 라우팅 등록 실패가 나타나는지 확인합니다.
다른 VPN, 게임 가속기와 네트워크 필터링 도구를 잠시 비활성화한 뒤 코어를 다시 시작합니다.
strict-route를 잠시 false로 바꿔 비교 테스트합니다. 네트워크가 복구되면 충돌하는 라우팅을 확인하세요.
구독에 사용 가능한 노드가 하나 이상 있는지 확인하고 노드 지연 시간 테스트를 직접 실행합니다.

웹 페이지는 열리지만 게임이나 음성 연결이 실패함

웹 페이지는 주로 TCP를 사용하지만 실시간 음성, 일부 게임과 QUIC는 UDP를 사용합니다. 먼저 프록시 노드 자체가 UDP를 지원하는지 확인한 뒤 프록시 그룹과 노드 설정에서 UDP가 허용되는지 확인하세요. stack을 mixed, system, gvisor 사이에서 하나씩만 바꿔 비교하고 DNS와 규칙은 동시에 수정하지 마세요.

브라우저의 QUIC를 잠시 끄고 확인할 수도 있습니다. 끈 뒤 웹 페이지가 안정되면 UDP 경로에 문제가 집중되어 있을 수 있고, TCP도 불안정하다면 MTU를 계속 확인해야 합니다. 특정 페이지가 중간에 멈추거나 텍스트는 열리지만 이미지가 멈추는 현상은 경로 MTU 불일치에서 자주 발생합니다. 1500에서 1400으로 낮춰 코어를 재시작한 뒤 테스트해 보세요. 처음부터 지나치게 작은 값으로 낮추는 것은 권장하지 않습니다.

DNS는 정상적으로 응답하지만 규칙이 계속 IP에만 매칭됨

먼저 enhanced-mode가 fake-ip인지 확인한 다음 dns-hijack이 UDP와 TCP 53을 모두 처리하는지 확인합니다. 일부 앱은 DoH나 DoT를 사용하므로 일반적인 53 포트 하이재킹만으로는 암호화된 DNS 내용을 읽을 수 없습니다. 규칙으로 앱이 외부 DoH에 직접 연결하지 못하게 하거나 앱이 시스템 DNS를 사용하도록 설정할 수 있습니다. 정상적인 HTTPS도 443 포트를 사용하므로 모든 443 포트를 무작정 차단하지 마세요.

fake-ip-filter는 LAN 장치 검색, 일부 시간 동기화와 특수 로그인 서비스처럼 실제 주소가 꼭 필요한 도메인을 제외할 때 적합합니다. 필터 범위가 너무 넓으면 많은 도메인이 Fake-IP 매핑을 우회해 도메인 기반 분기 효과가 약해집니다. 최상위 도메인 전체를 바로 필터링하지 말고 로그를 보며 항목별로 추가하세요.

절전 모드에서 깨어나거나 Wi-Fi를 전환한 뒤 연결이 끊김

유선에서 Wi-Fi로 전환하면 기본 출구 인터페이스와 라우팅이 바뀔 수 있습니다. auto-detect-interface: true를 활성화하면 mihomo가 출구 인터페이스를 자동으로 식별하지만, 일부 시스템은 상태를 갱신하려면 코어를 다시 시작해야 합니다. 권장 순서는 TUN 일시 중지, 네트워크 전환, 시스템이 새 IP를 받을 때까지 대기, 코어 재시작, TUN 재활성화입니다.

깨어날 때마다 같은 문제가 발생한다면 문제 전후의 기본 라우팅과 DNS 주소를 기록하세요. Windows에서는 route print와 ipconfig /all, macOS에서는 route -n get default와 scutil --dns를 사용할 수 있습니다. 결과를 비교하면 클라이언트를 반복해서 재설치하는 것보다 충돌 원인을 빠르게 찾을 수 있습니다.

재사용 가능한 구성 순서

TUN을 처음 구성할 때는 절차를 고정하는 것이 좋습니다. 먼저 노드가 작동하는지 확인하고 Rule 모드에서 시스템 프록시가 정상인지 확인합니다. 그다음 시스템 서비스 설치 또는 네트워크 확장 권한을 승인하고, mixed, 자동 라우팅과 인터페이스 자동 인식으로 TUN을 활성화합니다. 마지막으로 DNS 하이재킹과 Fake-IP를 보완하세요. 단계마다 로그와 접속 결과를 확인합니다.

안정화된 뒤에 성능을 최적화하세요. 먼저 기본 설정에서 지연 시간, 다운로드 속도와 CPU 사용량을 기록한 다음 stack 또는 MTU만 하나씩 바꿉니다. 지연 시간 테스트는 최소 20회 연속 실행하고, 대용량 파일 테스트는 같은 대상과 같은 시간대를 유지하세요. 노드 부하 변화가 stack 차이보다 큰 경우가 많으므로 한 번의 측정만으로 장기 성능을 판단할 수 없습니다.

TUN의 가치는 더 많은 트래픽을 하나의 규칙 시스템으로 보내는 데 있으며, 규칙·구독·DNS 구성을 대신하는 데 있지 않습니다. 진입점 처리, 도메인 식별, 규칙 매칭과 노드 연결이 모두 정상이어야 가상 네트워크 어댑터 모드가 제대로 구성된 것입니다.