Clash TUN 모드 완전 정리: 가상 네트워크 어댑터가 전체 트래픽을 처리하는 원리와 활성화 방법

NT-02.1시스템 프록시가 "전체를 커버하지 못하는" 이유

Clash의 기본 동작 방식은 시스템 프록시(System Proxy)입니다. 클라이언트가 시스템 네트워크 설정에 HTTP/HTTPS 프록시 주소를 기록하면, OS가 이 주소를 애플리케이션에 알려주고 애플리케이션이 이를 따를지 스스로 결정합니다. 이 "따를지 말지"가 핵심입니다 — 시스템 프록시는 본질적으로 하나의 권고 사항일 뿐 강제 전달이 아닙니다. 대부분의 GUI 브라우저와 흔한 메신저는 시스템 프록시 설정을 읽고 그대로 따르지만, 명령줄 도구(`curl`, `git`, `ping`), 일부 게임, 오래된 클라이언트, 일부 안드로이드/iOS 앱은 시스템 프록시 설정을 무시하고 OS의 하위 네트워크 인터페이스로 직접 패킷을 보내는 경우가 많습니다.

그래서 자주 발생하는 현상이 있습니다: 브라우저에서는 프록시 속도 테스트가 정상이고 목표 사이트에도 접속되는데, 터미널에서 같은 주소로 `curl`을 실행하면 그대로 타임아웃이 나거나, 어떤 앱이 설정에서 "시스템 프록시 사용"을 체크했는데도 실제 패킷을 캡처해 보면 트래픽이 전혀 프록시 포트를 거치지 않는 식입니다. 이는 설정 오류가 아니라 시스템 프록시 메커니즘 자체의 커버 범위가 제한적이기 때문입니다 — 이 설정을 "자발적으로 읽고 따르는" 프로세스만 커버할 수 있습니다.

TUN 모드가 해결하는 것이 바로 이 커버 범위 문제입니다. 애플리케이션이 "자발적으로" 프록시 설정을 읽어주길 기다리지 않고, OS 네트워크 스택의 더 하위 계층에 가상 네트워크 어댑터를 만들고 시스템 라우팅 테이블을 이 어댑터로 향하게 함으로써, 거의 모든 아웃바운드 트래픽이 우회할 수 없게 만듭니다.

NT-02.2가상 네트워크 어댑터가 트래픽을 가로채는 방식

TUN(Tunnel, 터널 장치)은 OS가 제공하는 가상 네트워크 인터페이스 유형으로, 물리적 네트워크 어댑터나 Wi-Fi 어댑터처럼 시스템의 네트워크 인터페이스 목록에 나타나고 자체 IP 주소를 가지지만, 실제 물리적 링크는 없으며 송수신되는 패킷은 이를 생성한 사용자 모드 프로그램이 직접 처리합니다. Clash Meta(mihomo 코어)에서 TUN 모드를 켜면 시스템에 이런 가상 네트워크 어댑터를 만들고, 시스템 라우팅 테이블을 조정해 기본 라우트나 지정한 대역의 트래픽을 이 가상 어댑터로 보냅니다.

이후 애플리케이션이 보내는 IP 패킷은 프록시의 존재를 "알고 있든 모르든" 먼저 시스템 라우팅 판단을 거쳐 TUN 가상 어댑터로 전달됩니다. mihomo 코어는 사용자 모드에서 이 원본 패킷을 읽어 목적지 주소와 프로토콜 정보를 복원하고, 규칙 세트에 따라 해당 정책 그룹을 매칭한 뒤 실제 네트워크 인터페이스를 통해 선택된 노드로 전달합니다. 응답 패킷도 같은 경로로 되돌아와 TUN 어댑터를 통해 요청을 보낸 프로세스에 전달됩니다. 이 과정은 애플리케이션 입장에서는 투명합니다 — 목표 서버와 직접 통신한다고 생각하지만, 실제로는 모든 패킷이 커널의 규칙 판정을 거칩니다.

이것이 TUN 모드가 흔히 "전역 투명 프록시"라 불리는 이유이기도 합니다. TUN은 네트워크 계층에서 동작하고 시스템 프록시는 애플리케이션 계층 프로토콜(HTTP/SOCKS) 위에서 동작합니다. 더 낮은 계층에서 동작한다는 것은 커버 범위가 더 넓어진다는 뜻이지만, 문제를 진단할 때 접근 방식도 바꿔야 한다는 뜻입니다 — "이 앱에 프록시 옵션이 있는가"가 아니라 "이 기기의 트래픽이 올바르게 라우팅되고 있는가"를 봐야 합니다.

NT-02.3활성화 전에 정리해야 할 설정 항목 3가지

TUN 모드는 스위치 하나로 끝나는 게 아니라, 설정 파일에서 보통 아래 항목들이 함께 관련됩니다. 의미를 이해해두면 나중에 문제를 진단할 때 시간을 크게 아낄 수 있습니다.

1. enable: TUN 기능 전체 스위치, 불리언 값입니다. 이 항목을 켜야 가상 네트워크 어댑터가 생성됩니다.
2. stack: 사용자 모드 네트워크 스택 구현을 선택합니다. 흔한 값은 system, gvisor, mixed입니다. 코어 버전마다 지원하는 값이 다르므로 보통은 문서에서 권장하는 기본값을 우선 사용하고, 호환성 문제가 생기면 다른 값으로 바꿔 비교해 보세요.
3. dns-hijack: TUN 계층에서 DNS 조회 요청을 가로챌지 여부로, 보통 리스닝 주소와 포트 형태로 씁니다(예: any:53). 이 항목은 아래에서 다룰 DNS 처리와 직결되며, 잘못 설정하면 도메인 해석 오류나 분기 규칙 실패로 이어질 수 있습니다.

또한 TUN 모드에서도 트래픽 분기 판단은 여전히 규칙 세트에 의존하며, 시스템 프록시 모드와 동일한 rules 설정을 공유합니다. 차이는 "트래픽이 커널로 들어오는 방식"일 뿐, "커널이 트래픽을 분기하는 방식"이 아닙니다. 즉 TUN을 켠다고 기존 규칙이 무효화되지는 않지만, 그동안 시스템 프록시 모드에서는 드러나지 않았던 트래픽이 새로 노출될 수 있습니다.

NT-02.4플랫폼별 활성화 절차

클라이언트마다 화면 진입 경로는 다르지만, 내부적으로는 모두 mihomo 코어의 TUN 파라미터를 호출하므로 기본 흐름은 동일합니다.

Windows

1. 사용 중인 클라이언트 코어가 Clash Meta / mihomo인지 확인하세요(일부 구형 Clash 코어 기반 클라이언트는 TUN을 지원하지 않습니다).
2. 클라이언트 설정에서 "TUN 모드" 또는 "Tun Mode" 스위치를 찾습니다. 처음 켤 때 보통 관리자 권한 요청 창이 뜨는데, 허용해야 합니다.
3. 클라이언트를 비관리자 권한으로 실행해 스위치가 작동하지 않는다면, "관리자 권한으로 실행"으로 다시 시작해야 합니다.
4. 활성화 후 시스템 "네트워크 연결" 목록에 새로 추가된 가상 네트워크 어댑터가 보이며, 이름에는 보통 Mihomo나 Meta라는 문구가 포함됩니다.

macOS

1. 클라이언트 설정에서 TUN 모드를 켜면 시스템에서 "네트워크 확장" 또는 "시스템 확장" 승인 알림이 표시됩니다.
2. 「시스템 설정 → 개인정보 보호 및 보안」또는「시스템 설정 → 네트워크 → VPN 및 필터」로 이동해 해당 확장을 수동으로 허용하세요. macOS 버전에 따라 팝업 위치가 조금씩 다릅니다.
3. 승인이 끝나면 TUN 스위치를 다시 켭니다. 클라이언트 설치 시 네트워크 확장 권한을 이미 처리한 경우라면 이 단계는 건너뛰어도 됩니다.

Android

1. Android에서는 TUN 모드가 시스템 VPN 서비스 인터페이스에 대응하며, 켤 때 "연결 요청" 형태의 시스템 승인 대화상자가 뜨면 허용하면 됩니다.
2. 승인 후 상태 표시줄에 VPN 아이콘이 상시 표시됩니다. 이는 시스템 차원의 알림일 뿐 이상 증상이 아닙니다.
3. 다른 VPN 계열 앱을 함께 설치했다면, 시스템은 보통 한 번에 하나의 VPN 서비스만 활성화를 허용하므로 두 앱이 서로 자리를 뺏을 수 있습니다.

Linux

1. TUN 장치를 만들려면 CAP_NET_ADMIN 권한이 필요하며, GUI 클라이언트는 보통 sudo나 권한 승인 방식으로 코어 프로세스를 실행해야 합니다.
2. 명령줄에서 mihomo 코어를 실행할 때 권한 없이 바로 시작하면 로그에 TUN 장치 생성 실패가 기록되니, 실행 방식을 확인해야 합니다.
3. 일부 배포판은 기본적으로 방화벽(ufw, firewalld 등)이 켜져 있으므로, 가상 네트워크 어댑터의 포워딩을 막는 별도 규칙이 없는지 확인하세요.

NT-02.5활성화 후 자주 겪는 문제 진단

TUN 모드는 새로운 라우팅 계층을 추가하기 때문에, 아래와 같은 문제들이 자주 발생합니다.

• 활성화 후 인터넷이 전혀 안 되는 경우: 대부분 라우팅 테이블이 완전히 넘어간 상태에서 규칙 설정 오류나 코어 프로세스 비정상 종료로 가상 네트워크 어댑터가 "라우트만 점유하고 실제 전달은 안 되는" 상태가 원인입니다. 먼저 TUN을 끄고 시스템 프록시로 기본 연결을 확인한 뒤, TUN 설정 항목을 따로 점검하세요.
• 일부 대역에서 로컬 네트워크 기기에 접근이 안 되는 경우: TUN 모드가 기본적으로 모든 라우트를 가져가면 프린터, NAS 등 로컬 네트워크 기기 접속에 영향을 줄 수 있습니다. 규칙에서 로컬 네트워크 대역(예: 192.168.0.0/16, 10.0.0.0/8)에 직접 연결(DIRECT) 정책을 설정해 프록시 라우팅에서 제외해야 합니다.
• 다른 VPN 소프트웨어와의 충돌: 같은 기기에서 회사 VPN이나 다른 가상 네트워크 어댑터 기반 도구를 함께 실행하면 둘이 기본 라우트를 다투게 되어 간헐적 연결 끊김이나 라우트 튀는 현상이 나타날 수 있습니다. 동시에는 하나의 가상 네트워크 어댑터 계열 도구만 활성화해두는 것을 권장합니다.
• DNS 해석 이상: dns-hijack과 fake-ip를 함께 설정하지 않으면 도메인 해석이 여전히 기존 로컬 DNS를 사용해, 도메인 기준으로 매칭되는 분기 규칙이 작동하지 않을 수 있습니다. "인터넷은 되는데 분기가 이상한" 형태로 나타납니다.

NT-02.6TUN이 필요한 상황, 굳이 필요 없는 상황

TUN 모드는 "전역이니까 무조건 좋은" 선택지가 아니며, 켤지 여부는 실제 필요에 따라 결정해야 합니다.

• 명령줄 도구, 개발 환경, 게임 클라이언트 등 브라우저가 아닌 프로그램을 프록시로 돌려야 할 때, TUN이 현재 가장 확실한 방법입니다.
• 평소 브라우저와 흔한 메신저만 쓰고 이들이 시스템 프록시를 제대로 읽어들인다면, 시스템 프록시 모드를 계속 쓰는 편이 더 편하고 문제 발생 시 진단 범위도 더 짧습니다.
• 회사 사내망이나 이미 다른 VPN 클라이언트가 상시 실행 중인 기기에서는 TUN을 켤 때 신중해야 하며, 기존 네트워크 정책과 충돌하지 않는지 먼저 확인해야 합니다.
• 모바일 기기의 배터리와 안정성이 걱정된다면, 먼저 데스크톱에서 규칙 세트가 제대로 설정됐는지 검증한 뒤 휴대폰에서 상시 켜둘지 결정하세요.

전체적으로 TUN 모드가 해결하는 것은 "커버 범위" 문제이고, 시스템 프록시가 해결하는 것은 "필요한 만큼이면 충분한" 일상 시나리오입니다. 두 방식이 네트워크 스택 계층에서 어떻게 다른지 이해해두면, "어떤 앱이 프록시를 안 타는" 문제를 만났을 때 클라이언트를 반복 재시작하며 시행착오를 겪는 대신 어느 모드로 전환해야 할지 빠르게 판단할 수 있습니다.