Clash TUN 모드 완전 가이드: 투명 프록시와 시스템 레벨 트래픽 제어

TUN 모드란 무엇인가요?

TUN(Tunnel) 모드는 Clash·mihomo 코어가 운영체제에 가상 네트워크 인터페이스를 만들고, 그 인터페이스를 통과하는 IP 패킷을 사용자가 정한 규칙(rules)에 따라 프록시 그룹으로 보내는 동작 방식을 말합니다. 브라우저처럼 HTTP CONNECT나 시스템 “프록시 서버” 설정을 따르는 프로그램만이 아니라, 프록시 개념이 없는 게임·스토어 클라이언트·터미널 도구의 트래픽도 같은 규칙 엔진 아래에서 다룰 수 있게 됩니다. 이 때문에 “앱마다 프록시를 켤 필요 없이” 한 번에 시스템 수준에서 트래픽을 나누고 싶을 때 TUN이 자주 선택됩니다.

반대로 말하면, TUN은 커널 근처에서 동작하므로 관리자 권한이나 가상 어댑터 설치, 라우팅 테이블 변경 같은 시스템 수준의 개입이 동반됩니다. 설정이 잘못되면 일시적으로 전체 인터넷이 끊기거나 DNS가 순환하는 문제도 생길 수 있어, “편의”와 “위험도”가 함께 올라가는 모드라고 이해하시면 됩니다. 기능 개요는 문서 개요 페이지에서 함께 확인해 보시고, 코어 측면의 변화는 mihomo 마이그레이션 가이드와 연결해 읽으면 전체 그림이 잡힙니다.

시스템 프록시·Mixed 포트와의 차이

시스템 프록시는 운영체제에 “HTTP/HTTPS/SOCKS로 나가라”라고 알려 주는 방식입니다. 잘 따르는 앱은 편하지만, 시스템 설정을 무시하는 프로그램은 그대로 직접 연결(DIRECT)로 나갈 수 있습니다. Mixed 포트 하나로 HTTP와 SOCKS를 함께 받는 구성은 흔하지만, 역시 “앱이 그 포트를 쓰도록” 설정되어 있어야 합니다.

TUN 모드는 이런 “앱의 협조”에 덜 의존합니다. 가상 인터페이스 뒤로 들어온 트래픽을 코어가 가로채 GeoIP·도메인·IP 대역 규칙에 따라 분기합니다. 그래서 “스토어 앱이 프록시를 모른다”, “터미널에서 curl이 직접 나간다” 같은 상황을 줄이는 데 유리합니다. 대신 OS 전체에 영향이 크므로, 회사 PC처럼 그룹 정책으로 네트워크가 잠긴 환경에서는 사용이 제한될 수 있습니다.

투명 프록시: 패킷은 어떻게 흐르나요?

TUN을 켜면 코어는 보통 utun(macOS), wintun(Windows), tun(Linux) 같은 드라이버를 통해 가상 NIC를 만듭니다. 운영체제는 특정 목적지로 가는 패킷을 이 인터페이스로 보내도록 라우팅 테이블을 조정합니다. Clash는 들어온 IP 패킷을 해석해 목적지에 맞는 정책(예: 국내 IP는 DIRECT, 나머지는 프록시)을 적용하고, 필요하면 TCP/UDP 세션을 프록시 프로토콜로 변환해 업스트림 노드로 넘깁니다.

이 과정에서 DNS가 빠지면 “접속은 되는데 도메인만 이상하다”는 유형의 문제가 생깁니다. 그래서 TUN 설정에는 종종 DNS 가로채기(dns-hijack)가 함께 등장합니다. 운영체제나 앱이 보내는 DNS 쿼리를 Clash의 DNS 모듈로 끌어와 fake-ip 또는 redir 계열 처리와 맞추는 식입니다. DNS와 TUN은 한 세트로 설계하는 것이 안전합니다.

설정 파일에서 TUN 켜기 (mihomo 예시)

아래는 널리 쓰이는 mihomo 계열에서 권장되는 형태의 예시입니다. 환경에 따라 일부 키는 클라이언트 GUI에서만 켜지고 YAML에는 자동 반영되기도 합니다.

# mihomo / Clash Meta family — TUN example
tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true
  strict-route: true

stack: mixed: 시스템 스택과 사용자 공간 처리의 장점을 섞은 모드로, 호환성 면에서 많은 환경에서 기본 권장으로 쓰입니다.
dns-hijack: DNS 질의를 코어로 모읍니다. any:53은 대표적인 전역 가로채기 패턴입니다.
auto-route / auto-detect-interface: 라우팅과 물리 인터페이스 선택을 자동화합니다.
strict-route: TUN을 우회하는 “샛길”을 줄이려는 목적에 가깝습니다. 환경에 따라 끄거나 켜야 할 때도 있으니 문제가 생기면 조건부로 해제해 보세요.

백업을 먼저 하세요. config.yaml을 수정하기 전에 복사본을 두면, TUN 실험 중 네트워크가 불안정해져도 빠르게 이전 상태로 되돌릴 수 있습니다.

DNS·fake-ip와 함께 쓰기

TUN을 쓸 때는 dns.enable: true와 enhanced-mode(예: fake-ip)를 규칙 세트와 함께 맞추는 것이 중요합니다. fake-ip는 도메인에 대해 가짜 IP를 빨리 부여해 규칙 매칭을 단순화하지만, NTP·LAN·특정 게임처럼 가짜 주소가 맞지 않는 경우 fake-ip-filter에 예외를 넣어야 합니다. 또한 DNS 쿼리가 프록시와 다시 엮이며 무한 루프가 생기지 않도록, 코어 자신의 관리 IP·로컬 도메인은 DIRECT 쪽 규칙으로 빼 주는 패턴이 흔합니다.

# DNS fragment sketch (adjust to your profile)
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"

필터 목록과 업스트림 DNS 목록은 개인정보·정책에 맞게 선택하세요. 공용 DNS만으로는 지역별 최적 경로가 달라질 수 있습니다.

플랫폼별로 알아둘 점

Windows

Wintun 드라이버 설치나 UAC 승인이 필요할 수 있습니다. 백신이 드라이버 로드를 막으면 TUN이 시작되지 않습니다. 다른 VPN과 동시에 켜면 라우팅이 충돌할 수 있으니, 한 번에 하나의 “전체 터널”류 도구만 사용하는 편이 안전합니다.

macOS

시스템 확장·프로필 권한 요청이 뜨는 경우가 있습니다. 최신 클라이언트는 안내 절차를 내장한 경우가 많습니다. Little Snitch 등 방화벽과 함께 쓸 때는 lo·utun 관련 규칙을 확인하세요.

Linux

CAP_NET_ADMIN 등 권한이 필요할 수 있습니다. 일부 배포판에서는 ip route 규칙이 빠르게 바뀌므로, 스크립트로 네트워크를 건드리는 다른 서비스와 충돌하지 않는지 점검하세요.

자주 겪는 문제

권한 오류·TUN 디바이스 생성 실패

관리자 권한 실행, 드라이버 재설치, 보안 소프트웨어 예외 등을 순서대로 확인합니다. Linux에서는 바이너리에 capability를 부여하는 방식이 문서화되어 있는 경우가 많습니다.

인터넷 전체 단절·DNS 루프

dns-hijack과 fake-ip-filter, 그리고 프록시 그룹의 업스트림 도메인이 서로를 가리키면 순환이 날 수 있습니다. 이때는 DNS 모드를 잠시 normal에 가깝게 낮추거나, 문제가 되는 도메인을 필터에 추가해 원인을 좁힙니다.

일부 트래픽만 우회됨

strict-route 끄기, 물리 인터페이스 자동 탐지 오류 수정, 혹은 해당 앱이 VPN 분할 터널링을 쓰는지 확인합니다. 기업용 Zero Trust 클라이언트와의 공존은 특히 까다롭습니다.

TUN은 시스템 전체 트래픽에 가깝게 영향을 줍니다. 공용 PC·업무 망에서는 정책을 위반하지 않는지 반드시 확인하세요.

정리: 규칙을 믿을 수 있을 때 TUN이 빛납니다

TUN 모드의 가치는 “한 앱씩 설정”하지 않고도 동일한 규칙 집합으로 트래픽을 정리할 수 있다는 데 있습니다. 반대로 규칙·DNS·라우팅 중 하나라도 어긋나면 영향 범위도 크므로, 단계적으로 켜 보고 시스템 프록시만으로 충분한지 먼저 비교해 보는 것을 권합니다. 최신 mihomo 코어와 잘 맞는 GUI에서는 슬라이더 한 번으로 TUN을 켜고 끄고, DNS 예외를 시각적으로 관리할 수 있어 학습 비용이 줄어듭니다. 비슷한 도구들 가운데에서도 Clash 계열은 규칙 표현력과 커뮤니티 자료 측면에서 균형이 잘 잡혀 있는 편입니다.

→ Clash 공식 클라이언트 무료 다운로드 — TUN·규칙·구독을 한 화면에서 다루고 싶다면, 문서만 읽는 것보다 최신 빌드를 받아 직접 체험해 보는 것이 가장 빠릅니다.