고급 활용 2026-06-03 예상 읽기 시간 9분

TUN 모드 원리와 활성화 방법: 전체 트래픽을 장악하는 올바른 방법

TUN 가상 네트워크 어댑터와 시스템 프록시의 차이를 설명하고, 어떤 프로그램이 반드시 TUN 모드에 의존해야 프록시를 경유할 수 있는지, 그리고 각 플랫폼에서 TUN을 활성화할 때 필요한 권한과 DNS 관련 주의사항을 정리합니다.

시스템 프록시와 TUN 모드의 경계

SECTION / PROXY VS TUN

시스템 프록시(System Proxy)는 운영체제 차원의 설정으로, 본질적으로는 시스템이나 애플리케이션 실행 환경에 프록시 주소 정보를 기록하는 방식입니다(HTTP_PROXY / HTTPS_PROXY 등 환경 변수, 또는 Windows의 WinINet/WinHTTP 설정 항목, macOS의 네트워크 환경설정 등). 프로그램이 네트워크 요청을 보낼 때 이 설정을 읽어 실제로 프록시 포트로 트래픽을 전달해야만 비로소 "프록시를 경유"한 것이 됩니다. 이는 일종의 **협의 기반** 전달 방식으로, 프록시 적용 여부는 대상 프로그램의 협조 여부에 달려 있습니다.

TUN 모드는 완전히 다릅니다. Clash Meta(mihomo)에서 TUN을 활성화하면 시스템 내에 가상 네트워크 어댑터를 생성합니다(Windows에서는 Wintun 드라이버에 의존하며, macOS/Linux에서는 각각 utun/tun0 디바이스에 대응합니다). 그리고 시스템 기본 라우트를 이 가상 어댑터로 지정합니다. 이후 네트워크 계층을 통과하는 모든 IP 패킷은—어느 프로세스에서 발생했든, 프록시의 존재를 인지하고 있든 없든—먼저 가상 네트워크 어댑터에 의해 가로채져 Clash 코어가 규칙에 따라 처리하게 됩니다. 이는 **네트워크 계층에서의 강제적인 장악**이며, 어떤 프로그램의 자발적인 협조에도 의존하지 않습니다.

한 문장으로 정리하면: 시스템 프록시는 "경유할지 말지"를 결정하는 것이고, TUN 모드는 "경유하든 안 하든 반드시 나를 거쳐야 한다"는 것입니다.

NOTE / 참고

TUN 모드는 시스템 프록시를 대체하는 "강화판"이 아니라, 별도의 전달 경로입니다. 대부분의 클라이언트에서 두 방식은 공존할 수 있지만, 동시에 활성화할 경우 라우팅 테이블이 서로 덮어쓰지는 않는지 주의가 필요합니다. 문제 진단 비용을 줄이기 위해 둘 중 하나만 사용하는 것을 권장합니다.

TUN이 있어야만 프록시를 경유할 수 있는 트래픽

SECTION / WHO NEEDS TUN

다음과 같은 상황에서는 시스템 프록시가 적용되지 않으며, TUN 모드만이 이를 커버할 수 있습니다:

UDP 중심 프로토콜. 시스템 프록시 메커니즘은 주로 HTTP/HTTPS(TCP 기반)를 대상으로 설계되어 있어, 많은 온라인 게임, 음성 통화(VoIP), 일부 화상 회의 소프트웨어는 UDP로 직접 연결되며 시스템 프록시 설정을 읽지 않습니다.
커맨드라인 및 백그라운드 서비스. 많은 CLI 도구(패키지 매니저, 일부 빌드 스크립트)와 시스템 데몬 프로세스는 프록시 환경 변수를 확인하지 않거나, 추가로 --proxy 파라미터를 지정해야만 프록시를 경유하는 경우가 있어 설정이 번거롭고 누락되기 쉽습니다.
소켓을 직접 하드코딩하는 애플리케이션. 일부 데스크톱 클라이언트나 모바일 앱은 하위 소켓 API를 직접 호출하여 시스템 프록시 설정을 완전히 우회합니다. 일부 메신저나 클라우드 동기화 도구에서 흔히 볼 수 있습니다.
ICMP 및 비일반 프로토콜. Ping, Traceroute 등 ICMP 기반 탐지 트래픽과 일부 P2P 프로토콜 역시 시스템 프록시의 처리 범위에 포함되지 않습니다.
가상머신 및 컨테이너 내부 트래픽. 호스트 머신의 시스템 프록시는 일반적으로 가상머신이나 컨테이너에 자동으로 전달되지 않지만, TUN 모드는 호스트의 라우팅 계층에서 가로채므로 네트워크 모드 설정과 함께 사용하면 이 트래픽까지 커버할 수 있습니다.

특정 애플리케이션이 "프록시를 켜도 여전히 직접 연결된다"면, 대부분 위의 경우에 해당하며, TUN 모드를 활성화하는 것이 가장 직접적인 해결책입니다.

플랫폼별 활성화 방법과 권한 요구사항

SECTION / PLATFORM SETUP

TUN 모드는 가상 네트워크 어댑터를 생성하고 시스템 라우팅 테이블을 수정해야 하므로, 3대 플랫폼 모두에서 더 높은 권한을 요구하며 세부 사항은 각기 다릅니다.

Windows에서 가상 네트워크 어댑터를 생성하려면 Wintun 드라이버가 필요하며, 주요 클라이언트(Clash Verge, Clash for Windows 파생판)는 설치 시 또는 TUN을 처음 활성화할 때 이 드라이버를 자동으로 설치합니다. 활성화 단계:

관리자 권한으로 클라이언트를 실행합니다(우클릭 후 "관리자 권한으로 실행"을 선택하거나, 설정에서 "관리자 권한으로 시작" 옵션을 켭니다).
설정 패널에서 TUN 모드 스위치를 찾아 활성화합니다. 최초 활성화 시 드라이버 설치 또는 네트워크 어댑터 권한 요청 팝업이 나타나면 허용을 클릭합니다.
Windows 방화벽이 가상 네트워크 어댑터의 아웃바운드 규칙을 차단한 경우, Windows Defender 방화벽에서 해당 드라이버의 네트워크 유형을 수동으로 허용해야 합니다(보통 최초 팝업에서 "개인 네트워크"를 선택하면 됩니다).

관리자 권한 없이 실행하는 것이 Windows에서 TUN 모드가 켜지지 않는 가장 흔한 원인이며, 스위치를 켜자마자 자동으로 다시 꺼지는 증상으로 나타납니다.

Linux에서 tun0 디바이스를 생성하려면 CAP_NET_ADMIN 권한이 필요합니다. 가장 간단한 방법은 root 권한으로 코어 프로세스를 실행하거나, 바이너리 파일에 개별적으로 해당 권한을 부여하는 것입니다:

sudo modprobe tun
sudo setcap cap_net_admin=eip /path/to/mihomo

setcap 방식을 사용하면 클라이언트 전체를 root 권한으로 실행할 필요 없이 코어 프로세스만 네트워크 관리 권한을 얻을 수 있어 최소 권한 원칙에 더 부합합니다. GUI 클라이언트(일부 GTK/Qt 기반 래퍼 등)는 대개 설정에서 "TUN 권한 부여" 버튼을 제공하며, 내부적으로 위와 같은 명령을 실행합니다.

CAUTION / 주의

TUN 모드는 클라이언트에게 전체 라우팅을 장악할 수 있는 권한을 부여합니다. 반드시 공식 채널을 통해서만 클라이언트를 다운로드하고 출처를 확인하며, 출처가 불명확한 프로그램에 관리자 권한이나 CAP_NET_ADMIN을 부여하지 마세요.

DNS 처리: fake-ip, 하이재킹, 라우팅 루프

SECTION / DNS BEHAVIOR

TUN 모드를 활성화하면 DNS 조회 역시 가상 네트워크 어댑터에 의해 가로채집니다. 이는 TUN 모드에서 문제가 가장 자주 발생하는 부분이기도 합니다. 설정 파일에서는 보통 DNS 하이재킹과 해석 정책을 명시적으로 선언해야 합니다:

tun:
  enable: true
  stack: system
  dns-hijack:
    - "any:53"
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

dns-hijack은 외부로 나가는 모든 53번 포트 DNS 요청을 강제로 가로채 Clash 코어에게 처리를 맡긴다는 의미로, 규칙을 우회해 해외 서버나 변조된 DNS 서버에 직접 연결되는 것을 방지합니다. fake-ip 모드는 각 도메인에 사설 대역 내의 가짜 IP를 할당하며, 애플리케이션 측에서는 이 가짜 IP를 보게 됩니다. 실제 연결이 이루어질 때 코어가 진짜 출구 IP로 바꿔주는 방식으로, 실제 해석 결과를 기다리지 않고도 도메인 기준으로 규칙을 매칭할 수 있다는 장점이 있습니다.

자주 발생하는 문제 진단 방향:

DNS 유출. 직접 연결 트래픽의 DNS 요청이 가로채지지 않는 경우(예: 브라우저가 여전히 시스템 기본 DNS를 사용 중), dns-hijack이 해당 포트를 커버하고 있는지, 그리고 시스템 네트워크 설정에서 고정 DNS 서버가 수동 지정되어 충돌을 일으키고 있는지 확인하세요.
라우팅 루프. TUN 모드에서는 프록시 노드 서버 자체로의 연결이 다시 TUN 네트워크 어댑터를 경유해서는 안 됩니다. 그렇지 않으면 "프록시가 자기 자신에게 연결"되는 무한 루프가 발생합니다. 클라이언트는 보통 auto-detect-interface 옵션이나 명시적인 프로세스 제외 규칙을 통해 이를 방지하므로, 수동으로 설정할 경우 이 항목이 켜져 있는지 반드시 확인해야 합니다.
VPN 클라이언트와의 충돌. TUN 모드와 다른 VPN 소프트웨어를 동시에 실행하면 두 프로그램이 기본 라우트를 서로 다투게 되며, 한쪽이 간헐적으로 작동을 멈추는 증상으로 나타납니다. 두 가지를 동시에 활성화하지 않는 것을 권장합니다.

TUN 모드가 정상적으로 작동하는지 확인하는 방법

SECTION / VERIFICATION

TUN 모드를 활성화한 후에는 클라이언트의 스위치 상태만으로 판단하지 말고, 다음 순서로 확인해 보는 것을 권장합니다:

가상 네트워크 어댑터 존재 여부 확인. Windows에서는 "네트워크 연결"을 열어 "Mihomo", "Clash" 등의 이름을 가진 어댑터가 새로 생겼는지 확인합니다. macOS/Linux에서는 ifconfig 또는 ip addr 명령으로 utun / tun0 디바이스가 나타나는지 확인합니다.
기본 라우트 확인. Windows에서는 route print, macOS/Linux에서는 netstat -rn 또는 ip route를 사용해 기본 라우트가 물리 네트워크 어댑터가 아닌 가상 네트워크 어댑터로 지정되어 있는지 확인합니다.
시스템 프록시를 따르지 않는 도구로 테스트. 예를 들어 터미널에서 프록시 파라미터 없이 curl을 실행하거나, 규칙상 "프록시가 필요"하다고 판정된 도메인에 명령줄로 직접 Ping을 보내 예상한 출구로 나가는지 관찰합니다.
클라이언트의 연결 로그 확인. 대부분의 클라이언트는 "연결" 또는 "로그" 패널에서 각 연결의 인바운드 유형을 표시합니다. TUN 모드로 이루어진 연결은 보통 HTTP/SOCKS가 아니라 TUN으로 표시되므로, 이를 통해 어떤 경로가 실제로 작동하는지 확인할 수 있습니다.

위의 모든 점검을 통과했는데도 특정 애플리케이션이 여전히 프록시를 경유하지 않는다면, 해당 애플리케이션이 시스템 차원에서 특정 네트워크 인터페이스에 고정 바인딩되어 있거나 사용자 지정 DNS를 사용하고 있을 가능성이 큽니다. 이 경우 Clash 설정을 계속 조정하기보다 해당 프로그램의 네트워크 설정을 별도로 점검해야 합니다.