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

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

시스템 프록시는 앱에 프록시 주소와 포트를 알려주는 설정입니다. 브라우저는 이 설정을 읽어 로컬 HTTP 프록시 포트로 요청을 보낼 수 있지만, 자체적으로 연결을 만드는 게임이나 명령줄 도구, 일부 데스크톱 프로그램은 설정을 전혀 참조하지 않을 수 있습니다. 따라서 시스템 프록시를 켰다고 모든 프로그램의 연결이 Clash를 거치는 것은 아닙니다.

TUN은 네트워크 계층에서 동작하는 가상 인터페이스입니다. 클라이언트가 인터페이스를 만들고 시스템 라우팅을 조정하면, 조건에 맞는 IP 패킷이 코어로 전달됩니다. 코어는 TCP·UDP 등의 연결을 처리하고 규칙에 따라 직접 연결하거나 프록시를 사용하거나 차단합니다. 앱에서 프록시 주소를 따로 설정할 필요는 대개 없지만, 라우팅 제외 설정과 앱 제외 설정, 플랫폼 제한의 영향을 받을 수 있습니다.

이 문서의 YAML 예시는 Clash Meta의 후속 프로젝트인 mihomo를 기준으로 합니다. Clash의 브랜치마다 설정 항목과 플랫폼 지원이 다를 수 있으므로, 먼저 클라이언트의 ‘정보’ 또는 코어 정보에서 코어 이름을 확인한 다음 해당 코어의 문서를 참고하세요. 화면에 TUN 스위치가 있더라도 구형 코어가 아래의 모든 설정 항목을 지원한다는 뜻은 아닙니다.

가상 네트워크 어댑터·라우팅 테이블·DNS의 연동

연결 처리 순서

1. 앱이 도메인 이름을 조회하거나 IP 주소에 직접 연결합니다.
2. 운영체제가 라우팅 테이블을 기준으로 출구를 선택합니다. 자동 라우팅을 켜면 해당 트래픽이 TUN 인터페이스로 전달됩니다.
3. 코어가 대상 주소를 확인하고 DNS 매핑, 규칙, 선택적 트래픽 스니핑 정보를 함께 사용해 연결을 판별합니다.
4. 프록시 규칙에 해당하는 연결은 선택한 노드를 통해 전송되고, 직접 연결은 실제 네트워크 인터페이스를 통해 전송됩니다.

코어가 프록시 서버로 보내는 연결은 실제 출구를 통해 나가야 하며, 다시 코어로 들어오면 안 됩니다. auto-detect-interface는 실제 아웃바운드 인터페이스를 자동으로 식별해 라우팅 루프가 생길 위험을 줄입니다. Wi-Fi를 바꾸거나 유선 네트워크를 연결하거나 다른 VPN을 켜고 끈 뒤에는 인터페이스 선택이 달라질 수 있으므로 로그와 라우팅을 다시 확인하세요.

DNS 하이재킹이 모든 암호화 DNS를 가로채는 것은 아닙니다

dns-hijack를 사용하면 조건에 맞는 DNS 트래픽을 코어의 DNS 모듈로 전달할 수 있습니다. 예를 들어 UDP 53과 TCP 53이 이에 해당합니다. 브라우저가 HTTPS로 외부 DNS 서비스에 연결하면 요청은 보통 443 포트를 사용하므로 일반적인 53 포트 DNS 질의에 해당하지 않습니다. 따라서 any:53 한 줄만으로 모든 도메인 조회가 처리된다고 단정할 수 없습니다.

fake-ip를 사용하면 코어가 매핑 주소를 반환하고, 이후 연결에서 도메인 이름을 복원합니다. 예시에 나온 198.18.0.1/16은 내부 매핑에 사용하는 전용 테스트 주소 대역이며 프록시 서버 주소가 아닙니다. 실제 DNS 응답에 의존하는 LAN 기기나 앱은 도메인별로 fake-ip-filter를 설정해야 할 수 있습니다. 많은 도메인을 한꺼번에 제외하지 마세요.

mihomo TUN 설정과 stack 선택

아래 예시는 기존 설정에 추가하는 내용이며, 노드·프록시 그룹·라우팅 규칙은 포함하지 않으므로 완전한 구독 설정을 대체할 수 없습니다. 먼저 설정을 백업한 다음 클라이언트가 지원하는 덮어쓰기 또는 병합 기능으로 추가하세요. 그래야 구독 업데이트 때 로컬 수정 사항이 사라지는 것을 방지할 수 있습니다. 같은 이름의 항목이 이미 있다면 내용을 병합하고, YAML 최상위에 dns나 tun을 중복해서 작성하지 마세요.

mixed-port: 7890
mode: rule

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

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

• mixed-port: 7890은 이 예시에서 HTTP/SOCKS 혼합 프록시 연결에 사용하는 포트입니다. TUN이 패킷을 받는 포트가 아닙니다. 사용하지 않는 다른 포트로 바꿔도 가상 인터페이스의 라우팅은 직접 달라지지 않습니다.
• listen: 127.0.0.1:1053은 코어 DNS의 로컬 리스닝 주소입니다. 시스템 DNS에 ‘127.0.0.1:1053’을 입력하라는 뜻은 아닙니다. 대부분의 시스템 DNS 설정은 서버 IP만 허용하며 포트가 포함된 주소는 지원하지 않습니다.
• auto-route는 관련 라우트를 자동으로 추가하고, auto-detect-interface는 실제 아웃바운드 인터페이스를 식별합니다. 노드 지연 시간을 측정하거나 노드를 자동 선택하는 기능은 아닙니다.
• 예시의 DNS 서버는 설정 항목의 구조를 설명하기 위한 것입니다. 실제 환경에서는 네트워크 연결성, DNS 정책, 개인정보 보호 요구사항을 고려해 업스트림 서버를 선택하세요. 예시 주소를 모든 네트워크에 적용되는 고정값으로 간주하면 안 됩니다.

system·gvisor·mixed의 차이

특정 stack을 ‘항상 가장 빠른 모드’로 단정하지 마세요. 처리량, CPU 사용량, 호환성은 운영체제와 코어 빌드, 노드 프로토콜, 앱 부하에 따라 달라집니다. 문제를 확인할 때는 같은 노드와 테스트 대상을 유지하고 stack 설정만 한 번에 하나씩 바꾼 다음 연결을 새로 만들어 비교하세요. 기존 연결이 종료되지 않았다면 테스트 결과에 이전 처리 경로가 반영될 수 있습니다.

Windows: 서비스 권한 및 가상 네트워크 어댑터 확인

Windows 10과 Windows 11에서 가상 인터페이스를 만들고 라우팅을 수정하려면 필요한 권한이 있어야 합니다. 데스크톱 클라이언트는 보통 관리자 권한으로 실행하거나 백그라운드 서비스를 통해 코어를 실행합니다. ‘시작 시 실행’과 ‘서비스 모드’는 서로 다른 설정입니다. 서비스를 설치한 뒤에는 실제로 실행 중인지도 확인하세요.

1. 먼저 TUN을 끄고 설정을 가져온 다음 사용할 수 있는 노드를 선택하세요. 시스템 프록시로 테스트 페이지를 열어 구독과 노드가 정상 작동하는지 확인합니다.
2. 클라이언트 설정에서 ‘서비스 모드’를 찾아 안내에 따라 서비스를 설치하고 시작하거나, 클라이언트 안내에 따라 관리자 권한으로 실행하세요. Windows 사용자 계정 컨트롤 창이 표시되면 프로그램 경로를 확인합니다.
3. 시스템 프록시를 잠시 끈 다음 ‘가상 네트워크 어댑터 모드’ 또는 ‘TUN’을 켜세요. 이렇게 하면 시스템 프록시의 효과를 TUN이 작동한 결과로 잘못 판단할 가능성을 줄일 수 있습니다.
4. 「설정」→「네트워크 및 인터넷」→「고급 네트워크 설정」을 열어 네트워크 어댑터가 변경되었는지 확인하세요. 인터페이스 이름은 클라이언트와 코어 설정에 따라 다르므로 반드시 Clash라는 이름일 필요는 없습니다.
5. 클라이언트의 연결 목록을 열고 프록시를 따로 설정하지 않은 프로그램을 실행해 해당 연결이 표시되고 규칙이 적용되는지 확인하세요.

더 자세히 확인하려면 PowerShell에서 다음 읽기 전용 명령을 실행하세요. 작업 표시줄의 연결 아이콘만 보는 대신 새로 생긴 인터페이스, 라우트의 인터페이스 인덱스, DNS 서버를 확인해야 합니다.

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-DnsClientServerAddress
Get-NetTCPConnection -State Listen -LocalPort 7890

마지막 명령은 이 예시의 프록시 포트가 리스닝 중인지 확인할 뿐 TUN이 정상이라는 증거는 아닙니다. 로그에 권한 부족이 표시되면 먼저 서비스 권한을 해결하세요. 포트가 이미 사용 중이라면 어떤 프로세스가 포트를 점유하는지 확인합니다. 인터페이스 생성 실패를 해결하려고 시스템 방화벽 전체를 바로 끄지 마세요.

macOS: 보조 서비스 및 utun 라우팅 확인

macOS 클라이언트는 보통 특권 보조 서비스를 이용해 TUN을 만들거나 관리하며, 일부는 시스템 네트워크 확장을 사용합니다. 권한 부여 방법은 클라이언트 구현에 따라 다르므로 특정 앱의 메뉴 경로를 모든 앱에 그대로 적용하면 안 됩니다. 다운로드하고 설치할 때는 Apple Silicon용과 Intel용도 구분하세요.

1. 먼저 시스템 프록시로 노드를 확인한 다음 클라이언트 안내에 따라 보조 서비스를 설치하거나 네트워크 확장을 승인하세요. 관리자 암호를 입력하기 전에 권한 요청이 현재 설치한 클라이언트에서 온 것인지 확인합니다.
2. TUN을 켭니다. 백그라운드 구성요소를 허용하라는 시스템 안내가 표시되면 「시스템 설정」→「일반」→「로그인 항목 및 확장 프로그램」으로 이동해 해당 항목을 확인하세요. 메뉴 이름은 macOS 버전에 따라 조금 다를 수 있습니다.
3. 시스템 프록시를 잠시 끈 뒤 테스트 앱을 다시 열고, 클라이언트에서 연결이 계속 코어로 전달되는지 확인하세요.
4. 잠자기 모드에서 복귀하거나 네트워크를 전환한 뒤 다시 테스트하세요. 복귀 후에만 문제가 생긴다면 당시 아웃바운드 인터페이스와 코어 로그를 기록한 다음 TUN을 재시작해 확인합니다.

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
scutil --dns

utun 인터페이스는 다른 시스템 서비스나 VPN에서도 사용할 수 있습니다. utun0이 보인다고 해서 현재 클라이언트의 인터페이스라는 뜻은 아니며, 번호도 고정되어 있지 않습니다. TUN을 켜기 전후의 인터페이스와 라우팅 변화를 비교하고 클라이언트 로그도 함께 확인하세요. 라우트 조회는 대상 IP의 경로만 보여 주므로 모든 도메인 조회나 IPv6 트래픽이 코어로 전달되는지까지 단독으로 증명하지는 못합니다.

Android: VPN 권한, 앱별 범위, 백그라운드 제한

Android 클라이언트는 보통 시스템 VpnService를 통해 가상 인터페이스를 제공하며, 일반적으로 root 권한은 필요하지 않습니다. 처음 연결할 때 시스템 VPN 권한 대화상자가 표시됩니다. Android의 ‘VPN 모드’는 데스크톱 TUN과 목적은 비슷하지만, 인터페이스와 라우팅은 대개 앱이 관리합니다. 따라서 데스크톱용 auto-route 설정을 그대로 복사하지 마세요.

1. 구독을 가져오고 프록시 그룹을 선택한 다음 연결을 시작하세요. 시스템 VPN 권한 창에 표시된 앱 이름을 확인한 뒤 허용합니다.
2. 클라이언트의 앱별 분할 설정을 확인하세요. ‘선택한 앱만 프록시’를 사용하면 선택되지 않은 앱은 VPN 아이콘이 표시되더라도 프록시를 자동으로 거치지 않습니다.
3. Android 13에서 일반적으로 「설정」→「네트워크 및 인터넷」→「VPN」으로 이동해 현재 VPN을 확인할 수 있습니다. 제조사별 시스템에서는 ‘연결 및 공유’ 같은 다른 메뉴에 있을 수 있으므로 설정에서 ‘VPN’을 검색해 보세요.
4. 클라이언트의 시스템 앱 정보로 이동해 「배터리」 또는 「앱 배터리 사용량」에서 필요에 따라 백그라운드 실행을 허용하세요. 화면을 잠근 뒤에만 연결이 끊긴다면 먼저 배터리 절약과 백그라운드 제한을 확인합니다.
5. ‘VPN 상시 연결’ 또는 ‘VPN을 사용하지 않는 연결 차단’을 켰다면 먼저 클라이언트가 안정적으로 다시 연결되는지 확인하세요. 후자를 켜면 VPN 연결이 끊겼을 때 인터넷 접속 자체가 차단될 수 있습니다.

일반적으로 같은 사용자 계정이나 업무 프로필에서는 VpnService 기반 앱 하나만 활성 상태로 유지할 수 있습니다. 다른 VPN이나 로컬 VPN을 사용하는 필터링·패킷 캡처 앱을 시작하면 현재 연결이 대체될 수 있습니다. 이럴 때는 구독을 반복해서 다시 가져오기보다 시스템에서 현재 허용된 VPN 앱이 무엇인지 확인하세요.

TUN을 켠 뒤 인터넷이 안 될 때: 연결 단계별 점검

노드 문제와 트래픽 처리 문제를 먼저 구분하세요

TUN을 끄고 시스템 프록시를 다시 켠 뒤 같은 노드로 같은 대상에 접속해 보세요. 그래도 실패하면 노드, 구독 또는 프록시 그룹부터 확인합니다. 시스템 프록시는 정상인데 TUN만 실패한다면 권한, 라우팅, DNS, 다른 VPN을 점검하세요. 포트와 stack, DNS를 한꺼번에 바꾸는 것보다 원인을 좁히기 쉽습니다.

• 브라우저는 되지만 게임이 연결되지 않음: 게임 연결이 클라이언트에 표시되는지, 노드가 UDP를 지원하는지, 규칙이 대상을 예상한 프록시 그룹으로 보내는지 확인하세요. HTTP 웹페이지가 열린다고 UDP 출구도 정상이라는 뜻은 아닙니다.
• IP 주소로는 연결되지만 도메인 접속에 실패함: DNS 로그, 시스템 DNS 설정, 브라우저의 보안 DNS를 확인하세요. nslookup example.com으로 조회 결과를 확인할 수 있지만, 브라우저가 암호화 DNS를 사용할 때의 경로와 다를 수 있습니다.
• LAN 프린터나 NAS에 연결할 수 없음: 사설 IP 라우팅, 도메인 조회, 규칙을 확인하세요. 사설망 연결은 올바르게 직접 연결되거나 라우팅에서 제외되어야 합니다. 직접 연결 규칙을 하나 추가하는 것만으로 잘못된 시스템 라우팅이 해결되지 않을 수 있습니다.
• 일부 웹페이지가 오래 기다린 뒤 열림: IPv4와 IPv6가 서로 다른 출구를 사용하는지 확인한 다음 MTU를 점검하세요. 고정 MTU 값을 무작정 적용하지 말고 터널이 중첩되어 있거나 경로에서 패킷 분할 문제가 발생하는지 먼저 확인합니다.
• 클라이언트를 재시작해야만 복구됨: 이전 서비스, 중복 실행된 코어 프로세스, 다른 VPN이 동시에 실행 중인지 확인하고 오류 발생 시간을 기록하세요. 증상만으로 stack 문제라고 단정하지 마세요.

확인 및 원상 복구 순서

제대로 확인하려면 세 가지 증거가 모두 있어야 합니다. 인터페이스나 라우팅이 예상대로 변경되었는지, 프록시를 따로 설정하지 않은 앱의 연결이 코어에 들어오는지, 규칙 적용과 최종 출구가 예상과 일치하는지 확인하세요. VPN 아이콘이나 프록시 포트의 리스닝 상태, 노드 지연 시간만으로는 검증이 끝났다고 볼 수 없습니다.

원상 복구하려면 먼저 클라이언트에서 TUN을 끄고 인터페이스와 라우트가 정리될 때까지 기다린 다음 기존 방식대로 시스템 프록시를 복원하세요. Android에서 VPN이 아닌 연결 차단을 켰다면 해당 스위치도 확인해야 합니다. 그래도 인터넷에 연결되지 않으면 시스템에 수동 DNS나 프록시 주소, 다른 VPN 설정이 남아 있는지 살펴보세요. 소유자를 확인할 수 없는 네트워크 어댑터를 바로 삭제하지 마세요.

자주 묻는 질문