TUN 모드가 해결하는 문제

많은 사용자가 Clash나 Mihomo를 먼저 깔고 구독을 넣은 뒤, 시스템 프록시(System Proxy)만 켜서 «연결 테스트는 되는데 특정 앱은 전혀 안 된다»는 경험을 합니다. 브라우저와 일부 데스크톱 앱은 OS가 내려 주는 HTTP·SOCKS 프록시 설정을 잘 따르지만, 터미널 도구·특정 게임·일부 메신저·배경 동기화 클라이언트는 프록시 환경 변수를 무시하거나 UDP 위주로 통신해 시스템 프록시 체인 밖으로 새어 나갑니다.

TUN 모드는 이런 틈을 줄이기 위한 접근입니다. 운영체제에 가상 네트워크 인터페이스를 올리고, 라우팅 규칙에 따라 패킷을 Mihomo 처리 파이프라인으로 보냅니다. 개념적으로는 «앱마다 SOCKS 주소를 넣는 대신, OS가 흐름을 한 번에 넘긴다»에 가깝습니다. 그래서 문서에서는 흔히 시스템에 가까운 전역 프록시전역에 가까운 터널이라고 말합니다. 다만 이 표현은 사용자 편의를 위한 설명이지, 운영체제의 모든 커널 경로가 100퍼센트 동일하게 가로채진다는 뜻은 아닙니다. 플랫폼 정책·다른 VPN·관리 소프트웨어가 끼면 예외가 생깁니다.

이 글은 Mihomo(구 Clash Meta) 계열 코어를 쓰는 그래픽 클라이언트, 특히 Clash Verge Rev(Windows·macOS)와 FlClash(Android) 사용자를 기준으로 합니다. 배포판마다 메뉴 이름은 조금씩 다르지만 «구독·프로필», «연결·대시보드», «설정·실험 기능»으로 나뉘는 큰 줄기는 같습니다. 화면이 다르면 같은 의미의 스위치를 찾아 대응하면 됩니다.

TUN은 편의를 주는 대신 권한 요구와 라우팅 충돌 가능성이 커집니다. 회사·학교 장비나 MDM이 걸린 PC에서는 정책 위반이 될 수 있으니, 먼저 내부 규정을 확인하는 것이 안전합니다.

시스템 프록시와 TUN, 무엇부터 켤까?

실무 순서는 대부분 다음이 안전합니다. 먼저 구독 프로필이 활성화되어 있고, Rule 모드에서 노드 그룹이 정상 응답하는지 확인합니다. 그다음 시스템 프록시로 브라우저를 테스트해 «규칙 분류가 의도대로인지» 짧게 검증합니다. 여기서 이미 DNS 해석이 이상하거나 모든 트래픽이 막히면, TUN을 켠다고 해결되지 않는 경우가 많습니다. 기본 한글·영문 판별, 직접 연결 대역, 아웃바운드 태그가 맞는지부터 고치는 편이 빠릅니다.

시스템 프록시로 충분한 경우도 많습니다. 문서 작업·웹 회의·대부분의 데스크톱 브라우저는 OS 설정만으로도 Mihomo와 잘 맞습니다. 반대로 curl이나 git처럼 자체 설정을 요구하는 CLI, 프록시를 무시하는 게임 런처, 일부 P2P·음성 채널이 UDP 고정으로 동작하는 프로그램은 TUN 없이는 계속 «직접 연결처럼 보이는» 현상이 남습니다. 사용자 입장에서는 «같은 Wi-Fi인데 앱만 튕긴다»로 느껴지죠.

TUN을 켠 뒤에도 Rule을 유지하는 것이 중요합니다. Global과 TUN을 동시에 켜면 사실상 모든 목적지가 선택한 노드로 몰리기 쉬워, 국내 금융·OTT·캠퍼스 포털까지 불필요하게 우회하며 속도와 안정성을 깎습니다. «전역에 가깝게» 잡는다는 말은 «모든 앱을 같은 정책으로 본다»와 같지 않습니다. 스플릿 터널링을 살리는 쪽이 대역도 아끼고 지연도 줄입니다.

Mihomo 입장에서 TUN이 하는 일

Mihomo는 YAML에서 tun 섹션과 rules·dns·프로바이더 정의를 함께 읽습니다. TUN이 활성화되면 코어는 OS에 허용된 방식으로 인터페이스를 만들고, 들어온 IP 패킷을 사용자가 고른 스택(구현과 빌드에 따라 Linux의 스택 모드와 유사한 옵션 이름이 노출되기도 함)에 맞춰 처리합니다. 최종적으로는 MATCH까지 내려온 흐름이 아웃바운드 체인으로 붙고, DIRECT면 로컬 라우팅으로, 프록시면 TLS·QUIC 등 프로토콜 핸드셰이크가 원격 노드 쪽에서 이어집니다.

여기서 흔한 오해는 «TUN을 켰으니 DNS도 저절로 안전하다»는 가정입니다. 브라우저의 보안 DNS, OS의 분리 DNS, 특정 앱이 내장한 DoH 클라이언트가 동시에 돌면, 화면상 분류와 실제 질의 경로가 어긋날 수 있습니다. 그래서 TUN을 켠 날에는 프로필의 DNS 섹션과 클라이언트의 DNS 보조 옵션을 같이 봐야 합니다. 가정용이라면 쉬운 우선순위부터: 다른 VPN을 끄고, 브라우저의 «보안 DNS 전용»을 잠시 꺼서 증상이 바뀌는지 비교해 보세요.

아래는 개념 예시이며, 구독 파일마다 정책 이름과 스니펫이 다릅니다. 핵심은 tun.enable가 켜졌을 때 코어가 라우팅 캡처를 시도한다는 점입니다.

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true

Windows에서 auto-route류 옵션이 어떻게 반영되는지, macOS에서 시스템 확장 허용이 필요한지는 버전과 빌드 차이가 있습니다. UI가 YAML을 대신 켜 주기도 하므로, 최종 값은 클라이언트가 생성한 런타임 설정이나 로그 메시지와 함께 보는 것이 정확합니다.

Windows에서 Clash Verge Rev로 TUN 켜기

  1. 최신 안정 빌드를 설치하고, 방화벽 프롬프트에서 개인 네트워크 허용 여부를 회사 정책에 맞게 선택합니다.
  2. 구독 프로필을 활성화한 뒤 Rule 모드에서 노드 지연 테스트가 정상인지 확인합니다.
  3. 설정 화면에서 TUN 또는 동등한 스위치를 찾아 켭니다. 첫 실행 때 UAC 창이 뜨면 허용합니다.
  4. 장치 관리자나 네트워크 어댑터 목록에 가상 인터페이스가 생겼는지, 대시보드에 TUN 상태가 표시되는지 확인합니다.
  5. 문제가 반복되면 «관리자 권한 실행» 또는 앱이 제공하는 헬퍼·서비스 설치 항목을 검토합니다.

Windows는 다른 보안·가상화 소프트웨어와 겹칠 때 증상이 갈립니다. 예를 들어 구형 샌드박스, 일부 트래픽 검사 드라이버, 동시에 설치된 다른 VPN 클라이언트가 라우팅 표를 덮어쓰면 TUN이 꺼졌다 켜졌다를 반복하거나, 특정 프로토콜만 빠져 나갑니다. 이때는 한 번에 하나의 터널만 유지하고 재부팅 후 순서를 바꿔 켜 보며 원인을 좁히는 편이 빠릅니다.

macOS에서 권한·보안 프롬프트 다루기

맥은 사용자 경험이 매끈해 보이지만, 시스템 확장·네트워크 필터 권한이 빠지면 TUN이 조용히 실패하는 경우가 있습니다. 최초 실행 때 설정 앱의 보안 섹션으로 유도되는 링크를 따라 허용 목록에 넣고, 재시도합니다. 회사 관리 프로필이 있으면 관리자에게 필터 확장 설치가 막혀 있는지 문의해야 합니다.

  1. Apple Silicon과 Intel 빌드를 섞지 말고 아키텍처에 맞는 패키지를 설치합니다.
  2. 앱을 응용 프로그램 폴더로 옮기고 첫 실행 시 게이트키퍼 경고가 있으면 제어–클릭으로 열기를 한 번 실행합니다.
  3. TUN 스위치를 켠 뒤 필요한 네트워크 권한을 모두 승인합니다.
  4. Wi-Fi 프로필이나 기업 VPN과 충돌하면 그 순간에는 하나만 활성화합니다.

macOS의 프록시 설정 UI는 여전히 존재하므로, 디버깅 때 Safari·curl이 각각 어디를 보는지 헷갈릴 수 있습니다. 시스템 설정에서 수동 프록시가 남아 있지는 않은지도 확인하세요. Mihomo 쪽 Rule과 OS 전역 설정이 이중으로 걸리면 루프가 생깁니다.

Android: VPN 권한이 곧 TUN 자리

Android는 일반 앱이 패킷을 직접 캡처하기 어렵기 때문에, 거의 모든 «전역 프록시 유사» 흐름이 VPNService 슬롯을 탑니다. FlClash 같은 Mihomo 내장 앱은 연결 버튼을 누르면 시스템이 VPN 권한 대화상자를 띄우고, 승인 후 트래픽이 터널로 들어옵니다. 이는 데스크톱의 TUN 스위치와 목적이 같습니다.

  1. 배터리 최적화 예외를 주어 백그라운드에서 연결이 끊기지 않게 합니다.
  2. 제조사별 «자동 시작·앱 잠금» 메뉴에서 강제 종료를 피합니다.
  3. 다른 광고 차단 VPN이나 회사용 클라이언트와 동시에 켜지 않습니다.

모바일 데이터와 Wi-Fi를 오가며 재연결할 때 간헐적으로 DNS 캐시가 꼬이면, 비행기 모드 토글이나 연결 재시작으로 빠르게 초기화할 수 있습니다. 증상이 특정 앱에만 있으면 해당 앱의 «Wi-Fi만 사용»·데이터 세이버 옵션도 함께 봅니다.

Rule·DNS를 같이 봐야 하는 이유

TUN은 트래픽을 코어로 모을 뿐, 어디로 보낼지는 여전히 규칙이 결정합니다. DOMAIN-SUFFIX·GEOIP·IP-CIDR 조합이 흔합니다. 국내 대역을 DIRECT로 두고 나머지를 프록시 그룹으로 보내는 패턴은 대역폭을 아낍니다. 반대로 GEOIP 데이터베이스가 오래되었거나 예외 대역이 잘못 잡히면, 사용자가 보기에 «이상하게 느린」 경로가 생깁니다.

DNS는 규칙의 입력이 되기도 합니다. fake-ip 계열 전략을 쓰는 프로필이라면, 브라우저가 실제 End-to-End 검증을 기대하는 경로와 코어의 응답이 어긋나지 않게 클라이언트 옵션과 맞춰야 합니다. 증상이 복잡하면 우선 단순화해서 «한 가지 DNS 소스만 남기고» 비교 실험을 하는 것이 정신 건강에 이롭습니다.

rules:
  - GEOIP,KR,DIRECT
  - MATCH,Proxy

KR은 ISO 국가 코드 예시이며, 구독 파일마다 CN·JP 등 다른 GEOIP 행과 순서가 다를 수 있습니다. 핵심은 국내 대역을 DIRECT로 두고 나머지를 프록시 그룹으로 넘기는 패턴입니다.

Provider YAML을 수동으로 깨끗이 편집하는 것보다, 클라이언트의 머지·오버라이드 기능으로 예외를 추가하는 편이 업데이트 때 덜 고생합니다. 한 줄 실수로 전체 MATCH가 막히는 사고가 흔합니다.

문제 해결 체크리스트

인터넷 전체가 끊긴 것처럼 보임

TUN이 올라온 직후 라우팅 고리가 꼬였는지 확인합니다. 다른 VPN·가상 스위치·하이퍼바이저 브리지가 동시에 있으면 우선 비활성화하고 Clash만 켠 상태에서 재현 여부를 봅니다. Windows에서는 route print에 익숙하다면 변경 전후를 비교해 볼 수 있습니다.

특정 앱만 여전히 우회되지 않음

앱이 자체 인증서 고정·프로세스 분리·로컬 프록시를 또 다른 포트에서 여는 경우가 있습니다. 이런 프로그램은 사용자 규칙에 맞춰 예외 DIRECT를 주거나, 아예 대상 앱 설정에서 별도 프록시를 지정해야 할 수도 있습니다. «모든 것이 TUN 덕에 자동»이라는 기대는 앱 생태계가 복잡해질수록 깨집니다.

지연은 낮은데 끊김만 잦음

지연 테스트 수치와 실제 UDP 세션 안정성은 다를 수 있습니다. 음성·실시간 화면 공유는 특히 그렇습니다. 우선 MTU·회선 품질·노드 지역을 바꿔 보고, 필요하면 해당 앱만 일시적으로 다른 아웃바운드 그룹으로 보내는 규칙을 실험합니다.

로그에 권한·인터페이스 오류가 반복

관리자 권한·시스템 확장·안드로이드 VPN 재승인을 다시 확인합니다. 업데이트 직후 첫 실행에서만 나타나는 경우도 있으니, 릴리스 노트를 읽고 캐시 삭제 후 재설치 같은 절차가 권장되는지 봅니다.

자주 묻는 질문

Linux나 서버 헤드리스에서도 같은 개념인가요?

네, 다만 GUI 대신 Netfilter·nftables·systemd-networkd 등과 맞물립니다. Mihomo 단독 바이너리를 쓸 때는 문서의 TUN 관련 플래그와 권한(캡abilities) 안내를 그대로 읽어야 합니다. 이 글은 데스크톱·모바일 사용자 중심이라 세부는 다루지 않습니다.

Rule 없이 TUN만 켜도 되나요?

기술적으로는 가능하지만 실무에서는 비추천입니다. 국내 필수 서비스까지 해외 회선으로 돌아가 지연·CAPTCHA·위치 검증 문제를 부르기 쉽습니다. Rule이 있는 구독을 쓰고, 예외만 최소한으로 추가하세요.

회사 PC에서 써도 되나요?

자산 소유권과 보안 정책이 우선입니다. 분류 네트워크를 우회하면 징계·계약 위반 사유가 될 수 있습니다. 개인 장비에서만 따라 하세요.

클라이언트 선택이 TUN 경험을 가른다

TUN은 코어 기능이지만, 그 위에 얹는 셸 앱이 관리자 권한 재시도·헬퍼 설치·로그 가독성·업데이트 속도를 어떻게 풀어 주느냐가 체감 안정성을 나눕니다. 오래된 포크나 출처 불명 빌드는 최신 Mihomo의 TUN 수정분을 따라오지 못해 동일한 YAML이라도 드물게 패닉을 일으키기도 합니다.

반대로 릴리스 주기가 짧고, TUN 토글과 DNS 보조 옵션을 한 화면에서 정리해 주는 클라이언트는 초보도 «어디를 눌러야 하는지»를 덜 헤맙니다. 시스템 프록시만으로는 부족한 앱을 쓰는 사용자일수록 이런 차이가 중요해집니다. 공식 사이트의 플랫폼별 다운로드 페이지는 아키텍처별 패키지를 한곳에 모아 첫 설치 시간을 줄이도록 구성되어 있습니다. 여기서 검증된 빌드를 고르면 TUN까지 포함한 설정 루프가 짧아지는 편이 Clash·Mihomo 생태계의 실질적인 장점입니다.

플랫폼에 맞는 Clash를 무료로 받고 TUN까지 빠르게 구성해 보기 →