시스템 프록시로 잡히지 않는 트래픽, TUN이면 가능하다
먼저 자주 혼용되는 두 개념의 차이를 명확히 짚어보겠습니다. 시스템 프록시(System Proxy)와 TUN 모드는 같은 문제를 서로 다른 층위에서 해결합니다. 시스템 프록시의 원리는 운영체제나 브라우저가 읽는 프록시 설정 항목을 수정하는 것입니다—Windows의 "네트워크 및 인터넷" 설정에 있는 HTTP/HTTPS 프록시 주소, 또는 환경 변수 HTTP_PROXY/HTTPS_PROXY 같은 것들이죠. 프로그램이 이 규칙을 따르고 프록시 설정을 자발적으로 읽어들이면 트래픽이 Clash가 리스닝 중인 포트로 전달됩니다. 하지만 프로그램이 이를 읽지 않거나 고정된 연결 방식을 쓰는 경우(일부 게임 클라이언트, CLI 도구, 일부 UWP 앱, 시스템 업데이트 서비스에서 흔히 발생), 시스템 프록시는 이를 통제할 수 없습니다.
TUN 모드는 접근 방식이 다릅니다. 프로그램에게 프록시를 쓰라고 "설득"하는 대신, 운영체제 네트워크 스택 안에 가상 네트워크 어댑터(Virtual Network Adapter)를 만들고 시스템 기본 라우트를 이 가상 어댑터로 향하게 합니다. 이렇게 하면 브라우저든 백그라운드 서비스든, 프록시 설정을 인식하지 못하는 프로그램이든 모든 아웃바운드 트래픽이 먼저 이 가상 어댑터를 거치고, 이후 Clash(또는 Clash Meta / mihomo 코어)가 유저 스페이스에서 이를 읽고 파싱해 규칙에 따라 분기 처리합니다. 이것이 바로 "전체 트래픽 인터셉트"입니다—대상이 특정 앱의 애플리케이션 레벨 설정이 아니라 기기 전체의 네트워크 레이어라는 점이 핵심입니다.
흔한 오해 하나를 짚어보겠습니다. TUN 모드는 "더 강력한 시스템 프록시"가 아니라 완전히 다른 구현 방식입니다. 시스템 프록시는 애플리케이션 레이어 프로토콜(HTTP/HTTPS CONNECT)에 머무르지만, TUN은 네트워크 레이어(IP 패킷)에서 동작합니다. 따라서 TCP/UDP 기반의 모든 트래픽—게임, VoIP, DNS 조회 자체까지—을 처리할 수 있습니다. 그래서 일부 상황—예를 들어 UDP 트래픽을 프록시해야 하거나 기기 상의 모든 프로그램을 일괄 처리해야 하는 경우—에서는 TUN 모드만이 이를 가능하게 합니다.
가상 네트워크 어댑터가 트래픽을 "가로채는" 방식: 세 가지 핵심 단계
TUN 모드의 동작 흐름을 이해하면 이후 발생할 수 있는 문제를 진단하는 데 도움이 됩니다. 전체 과정은 세 단계로 나눌 수 있습니다.
- 가상 네트워크 어댑터 생성: 클라이언트가 시스템 하위 레벨 인터페이스(Windows에서는 주로 Wintun 드라이버, macOS에서는 utun 인터페이스)를 호출해
Clash,utun같은 이름의 가상 네트워크 어댑터를 생성하고, 여기에 사설 IP 대역을 할당합니다. - 라우팅 테이블 조정: 클라이언트가 시스템의 기본 라우트 또는 일부 라우팅 규칙을 이 가상 어댑터로 향하게 변경하는 동시에, Clash 자체 프로세스와 로컬 게이트웨이로 향하는 직결 라우트는 유지해 트래픽이 순환 참조에 빠지지 않도록 합니다.
- 유저 스페이스 전달 및 분기 처리: 운영체제가 데이터 패킷을 가상 네트워크 어댑터로 보내면, Clash 코어가 유저 스페이스에서 이 IP 패킷들을 읽어 구체적인 TCP/UDP 세션으로 복원한 뒤, 설정 파일의 규칙(도메인 매칭, IP 대역 매칭, GeoIP 등)에 따라 직결, 특정 프록시 노드 경유, 또는 차단 여부를 판단합니다.
이 때문에 TUN 모드는 더 높은 시스템 권한을 필요로 합니다—라우팅 테이블 수정과 가상 네트워크 어댑터 생성은 Windows에서는 관리자 권한, macOS에서는 sudo 또는 시스템 확장 승인이 필요합니다. 이는 소프트웨어가 "권한을 남용"하는 것이 아니라, 가상 네트워크 어댑터 기술 자체가 운영체제 하위 리소스에 접근해야 하는 필수 요건입니다.
TUN 모드를 켜기 전에 기기에 가상 네트워크 어댑터를 생성하는 다른 소프트웨어(다른 프록시 도구, 일부 VPN 클라이언트 등)가 동시에 실행 중이지 않은지 먼저 확인하세요. 두 개의 가상 네트워크 어댑터가 동시에 라우팅 테이블을 점유하면 대부분 네트워크 단절이나 트래픽이 빠져나가지 못하는 문제가 발생합니다. 충돌하는 소프트웨어를 완전히 종료한 뒤 TUN을 켜는 것을 권장합니다.
Windows에서 TUN 모드 켜는 전체 절차
Windows 클라이언트마다 화면 구성은 조금씩 다르지만, 핵심 스위치와 순서는 동일합니다. 아래는 일반적인 흐름입니다.
- 클라이언트 코어가 Clash Meta 또는 mihomo인지 확인하세요(일부 구버전 Clash Premium 코어는 TUN을 지원하지 않으므로 클라이언트를 업그레이드하거나 코어를 전환하면 됩니다).
- 클라이언트 메인 화면을 열고 "프록시 설정" 또는 "네트워크" 패널에서 TUN 모드 스위치를 찾습니다. 처음 켤 때 보통 Wintun 드라이버 설치 안내가 뜨는데, 허용을 클릭하세요.
- 클라이언트에 "서비스 모드"(Service Mode) 옵션이 있다면 함께 설치하는 것을 권장합니다. 서비스 모드는 TUN 관련 작업이 Windows 서비스 형태로 백그라운드에 상시 상주하도록 해줍니다. 매번 관리자 권한으로 클라이언트를 재시작하지 않아도 TUN을 켤 수 있고, 사용자가 로그아웃한 뒤 TUN 어댑터가 비정상 상태가 되는 것도 방지할 수 있습니다.
- TUN 스위치를 켜면 클라이언트가 관리자 권한으로 재시작할 것을 안내합니다. 확인을 누르면 되고, 처음 시작할 때 1~2초 정도 라우팅 전환이 느껴질 수 있습니다.
- "프록시 모드" 패널로 이동해 현재 규칙 모드(Rule)인지 확인하세요. 전체 직결 모드가 아니어야 TUN이 인터셉트한 트래픽이 구독의 분기 규칙에 따라 처리되고, 무조건 전부 프록시를 거치거나 전부 직결되지 않습니다.
제어판 → 네트워크 및 공유 센터 → 어댑터 설정 변경
Clash / Mihomo라는 이름의 가상 네트워크 어댑터가 "연결됨" 상태로 보여야 합니다
켠 뒤에 네트워크 어댑터 목록에 해당 가상 어댑터가 나타나지 않는다면 Wintun 드라이버 설치 실패나 보안 소프트웨어의 차단이 원인일 가능성이 큽니다. 관리자 권한으로 클라이언트를 한 번 더 재시작해보거나, 서드파티 보안 소프트웨어의 드라이버 차단 기능을 임시로 끄고 다시 시도해보세요.
macOS에서 TUN 모드 켜기: 시스템 확장 승인이 핵심
macOS는 시스템 레벨에서 네트워크 확장 생성에 대해 더 엄격한 심사 절차를 두고 있어, macOS에서 TUN 모드를 켤 때는 보통 "시스템 확장 승인" 단계가 하나 더 필요합니다.
- 클라이언트 설정에서 TUN 모드 스위치를 켭니다. 처음 켤 때 시스템에서 "시스템 확장이 차단됨" 안내가 뜹니다.
- "시스템 설정 → 개인정보 보호 및 보안"으로 이동해 하단에서 해당 클라이언트에 대응하는 시스템 확장 허용 안내를 찾아 허용을 클릭합니다.
- 일부 macOS 버전에서는 재부팅해야 시스템 확장이 적용됩니다. 재부팅 후 클라이언트를 다시 엽니다.
- TUN 스위치를 다시 켜면 클라이언트가 utun 가상 인터페이스 생성과 라우팅 테이블 수정을 위해 관리자 비밀번호를 요청합니다. 비밀번호를 입력해 확인하세요.
- 활성화에 성공하면 터미널에서
ifconfig또는networksetup -listallnetworkservices를 실행해utun계열 인터페이스가 나타나는지 확인할 수 있습니다.
ifconfig | grep utun
# 정상이라면 아래와 비슷한 결과가 보입니다
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
macOS에서 시스템 확장이 반복적으로 거부된다면 "시스템 설정 → 개인정보 보호 및 보안 → 보안"에서 "App Store에서 다운로드한 앱만 허용"이 켜져 있는지 먼저 확인하세요. 일부 보안 정책은 정상적인 네트워크 확장 승인 요청까지 함께 차단하므로, 일시적으로 완화한 뒤 다시 시도해보세요.
TUN이 실제로 작동하는지 확인하기: 스위치 상태만 보지 말 것
스위치가 "켜짐" 상태라는 것이 트래픽이 실제로 예상대로 인터셉트되고 있다는 뜻은 아닙니다. 여기서 신뢰할 수 있는 두 가지 확인 방법을 소개합니다. 첫 번째는 DNS 조회가 하이재킹되는지 확인하는 것입니다—TUN 모드에서는 DNS 조회 자체도 Clash 코어를 거쳐 처리되어야 도메인 기반 규칙이 정확히 매칭됩니다.
nslookup example.com
# 반환 결과의 응답 서버 주소를 확인하세요
# Clash 코어 설정에서 지정한 DNS 리스닝 주소(198.18.0.2 같은 fake-ip 대역)가 표시된다면
# DNS 조회가 이미 TUN에 의해 인터셉트되어 시스템 기본 DNS로 바로 가지 않았다는 뜻입니다
두 번째 방법은 클라이언트의 연결 패널이나 트래픽 패널에서 직접 확인하는 것입니다. TUN을 켠 뒤에는 브라우저의 프록시 설정을 거치지 않는 소프트웨어(시스템 기본 날씨 앱, 일부 CLI 도구 등)의 연결 기록도 목록에 나타나야 합니다. 시스템 프록시 설정을 명확히 지원하지 않는 프로그램을 열었는데도 여전히 네트워크에 전혀 연결되지 않거나 트래픽이 패널에 나타나지 않는다면, TUN이 제대로 인터셉트하지 못한 것이므로 라우팅 테이블이 다른 소프트웨어에 점유되었는지, 서비스 모드가 정상적으로 실행 중인지 다시 확인해야 합니다.
또한 fake-ip 모드에서는 일부 내부망 접속, LAN 기기 검색 관련 기능이 영향을 받을 수 있습니다. LAN 기기에 정상적으로 접속해야 한다면 설정 파일에서 LAN IP 대역에 별도로 직결 규칙을 지정하거나, fake-ip-filter를 사용해 해당 도메인과 주소 대역을 제외해 LAN 접속이 잘못 프록시되는 것을 막아야 합니다.
TUN을 켠 뒤 자주 발생하는 문제들
- 켠 즉시 네트워크가 끊김: 대부분 라우팅 테이블 충돌입니다. 가상 네트워크 어댑터를 생성할 수 있는 다른 소프트웨어를 먼저 끄고 클라이언트를 재시작한 뒤 다시 켜세요.
- 일부 앱에 접속이 안 되고 인증서 오류가 발생: 클라이언트에서 MitM(중간자 패킷 캡처) 관련 기능도 함께 켜져 있다면 Clash가 생성한 루트 인증서를 추가로 설치하고 신뢰해야 하며, 이는 TUN 모드 자체와는 무관합니다. 먼저 설정에서 MitM 관련 옵션을 끈 뒤 원인을 파악해보세요.
- Windows에서 재부팅할 때마다 매번 관리자 권한으로 다시 열어야 함: 서비스 모드가 제대로 설치되지 않았다는 뜻입니다. 설정 패널로 돌아가 서비스 구성 요소를 다시 설치하세요.
- LAN 내 다른 기기들끼리 서로 찾지 못함: 규칙 목록에서 LAN 주소 대역(192.168.0.0/16, 10.0.0.0/8 등)이 직결로 설정되어 있는지 확인하고, 필요하다면 규칙을 수동으로 추가하세요.
종합하면, TUN 모드는 시스템 프록시가 원천적으로 갖는 커버리지 사각지대 문제를 해결하며, 원리적으로는 가상 네트워크 어댑터와 라우팅 테이블 조정에 의존합니다. 설정 측면에서는 시스템 프록시를 켜는 것보다 드라이버 설치와 권한 승인이라는 두 단계가 더 필요합니다. 어댑터 생성, 라우팅 조정, 유저 스페이스 분기 처리라는 이 세 단계를 이해하고 있으면, 구체적인 오류가 발생했을 때 대부분 어느 단계에서 문제가 생겼는지 짚어낼 수 있고, 무작정 클라이언트를 재설치하지 않아도 됩니다.