Clash TUN 모드 심화: 원리, 설정 포인트, 그리고 자주 겪는 문제

한국 사용자 커뮤니티에서 「브라우저만 프록시 탄다」「특정 프로그램은 계속 직접 붙는다」라고 할 때 가장 먼저 거론되는 게 TUN 모드(가상 네트워크 어댑터 기반 투명 캡처)입니다. 이 글은 시스템 프록시와 무엇이 다른지, Mihomo(Clash Meta) 계열에서 왜 DNS·라우트 설정이 한 번에 엮이는지, 그리고 설치 직후 자주 재현되는 실패 패턴을 검색·질문 순서에 맞춰 정리합니다.

TUN이란 무엇이고, 왜 “시스템 프록시만으로는” 부족한가

대부분의 데스크톱 Clash 클라이언트는 기본적으로 HTTP/HTTPS/SOCKS 형태의 로컬 리스너를 띄우고, 운영체제의 시스템 프록시 설정을 그 포트로 돌립니다. 크롬·엣지처럼 WinHTTP/시스템 설정을 따르는 앱은 잘 따라오지만, 자체 TLS 스택을 쓰거나 프록시 환경 변수를 무시하는 게임 런처, 일부 스토어 앱, 터미널 도구는 그대로 직접 연결을 시도합니다.

TUN은 이름 그대로 커널 수준의 가상 인터페이스를 만들고, 운영체제의 라우팅 테이블을 통해 “이 터널로 보낼 트래픽”을 넓게 잡는 방식입니다. 사용자 공간의 “특정 포트로만 보내기”가 아니라, 설계에 따라 전체 스택에 가깝게 보이는 트래픽을 코어가 받아 rules에 맞게 분기합니다. 그래서 검색어로는 Clash 투명 프록시, TUN 가상 어댑터, 프록시 우회 앱 같은 표현과 맞물립니다.

다만 TUN이 만능은 아닙니다. 관리자 권한·드라이버/헬퍼·다른 VPN·보안 제품과의 우선순위 싸움이 생기고, DNS가 어디서 해석되는지에 따라 “연결은 되는데 이름만 깨진다” 같은 증상이 납니다. 먼저 전체 흐름은 Clash 기본 튜토리얼에서 익힌 뒤, 이 문서에서 TUN만 덧씌우는 편이 진단이 빠릅니다.

동작 원리: 패킷이 어디로 흘러가나

단순화하면, TUN을 켠 상태에서 코어는 가상 인터페이스 뒤에서 IP 패킷을 받아 자신의 프록시 체인으로 넘깁니다. rules에서 매칭되면 지정한 proxy-groups로, DIRECT면 원래 회선으로 나가게 됩니다. 이 때 중요한 건 “어떤 주소로 나갈지”를 DNS가 어디서 결정하느냐인데, Clash·Mihomo는 fake-ip, redir-host, 시스템 DNS 등 스택 설정과 강하게 묶입니다.

예를 들어 브라우저는 잘 되는데 터미널의 curl만 이상하다면, 브라우저는 DNS over HTTPS를 쓰고 터미널은 OS 리졸버를 쓰는 식의 이중 경로일 수 있습니다. TUN을 켠다고 해서 이런 차이가 한 번에 사라지지는 않으므로, 증상을 나눠 보면 라우트 문제인지 DNS 문제인지가 갈립니다.

게임·음성·실시간 통신처럼 UDP 비중이 큰 앱은 시스템 프록시만으로는 빠지는 경우가 많고, TUN이나 클라이언트별 프로세스 규칙을 함께 봐야 합니다. 반대로 은행·DRM이 강한 서비스는 보안 정책상 비정상 경로를 막기도 하니, “우회가 안 된다”와 “정상 차단”을 구분할 필요가 있습니다.

설정에서 실제로 건드리는 것: tun 블록의 의미

배포되는 프로필마다 키 이름이 조금씩 다르지만, Mihomo 계열에서는 대개 YAML에 tun 섹션이 있고 enable·stack·auto-route·dns-hijack 류의 옵션이 등장합니다. 여기서 흔한 실수는 GUI에서 스위치만 켠 뒤 YAML 충돌을 안 본 채 “왜 반응이 없지?”로 넘어가는 것입니다.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  # dns-hijack, inet4/inet6 route, mtu 등은 빌드·OS에 따라 문서 확인

stackgvisor, system, mixed 등 후보가 있고, 플랫폼·버전에 따라 안정적인 조합이 다릅니다. “한 번 잘 돌아가던 설정”이 OS 마이너 업데이트 후 흔들리면, 스택과 MTU, 인터페이스 자동 탐지 옵션부터 의심하는 편이 좋습니다. 자세한 키 이름은 항상 사용 중인 코어 버전의 공식 문서를 기준으로 하세요.

규칙 쪽은 프록시 그룹(proxy-groups) 가이드에서 다룬 것처럼, TUN은 “잡아 온 트래픽을 어느 그룹으로 보낼지”를 바꾸지 않습니다. 잡기분기는 다른 층입니다. 그룹·규칙을 손댔다면 이름 불일치로 조용히 엉뚱한 출구로 가는지도 함께 확인합니다.

DNS와 TUN: fake-ip를 쓸 때 검색으로 많이 남는 증상

한국어 포럼에서 자주 보는 질문이 「사이트는 뜨는데 IP 위치가 이상하다」「로컬 NAS만 안 붙는다」입니다. dnsenhanced-modefake-ip 범위, 그리고 nameserver/fallback 구성이 LAN·사내 도메인과 충돌하면 이런 형태가 납니다. TUN을 켜면 OS의 DNS 요청까지 코어 쪽으로 흘러오게 만들 수 있는데, 이때 스플릿 도메인·도메인 화이트리스트를 안 두면 “전부 프록시로 보내려다 내부망이 깨진다”는 패턴도 나옵니다.

정리하면, TUN 문제라고 착각하기 쉬운 것 중 상당수는 순수 DNS 정책 문제입니다. 로그에 어떤 도메인이 어떤 모드로 처리됐는지를 병행하고, 브라우저 DoH만 켜 둔 상태와 비교해 보세요.

Windows에서 특히 자주 나오는 실패 순서

  • 관리자 권한·UAC: TUN 드라이버 설치나 라우트 변경이 막히면 스위치는 켜져도 트래픽이 안 잡힙니다. 클라이언트를 한 번 관리자로 실행해 보되, 보안 정책상 불가하면 정책을 먼저 확인합니다.
  • 다른 VPN·기업용 보안 클라이언트: 둘 다 기본 게이트웨이나 가상 어댑터를 잡으려 하면 순서에 따라 한쪽만 살아남습니다. “어제까지 됐는데 오늘 안 된다”면 최근에 깐 제로 트러스트·백신 네트워크 필터부터 의심합니다.
  • 스마트스크린·서명: 설치 파일이 막혀 헬퍼만 불완전하게 올라간 경우입니다. 공식 다운로드 경로에서 받았는지, 릴리스 노트에 맞는 빌드인지 확인합니다.

macOS·Linux에서의 체크 포인트

macOS는 권한·시스템 확장·방화벽 프롬프트가 단계별로 뜹니다. 한 단계라도 스킵되면 “반쯤만” 동작하는 것처럼 보입니다. Linux 배포판은 네임스페이스·systemd-resolved·NetworkManager와의 상호작용이 제각각이라, 동일 YAML이라도 호스트마다 튜닝이 필요할 수 있습니다.

게임·UDP·P2P를 쓸 때의 현실적인 기대치

TUN을 켰다고 해서 모든 UDP가 이상적으로 중계되는 것은 아닙니다. 노드 측이 해당 프로토콜을 지원하지 않거나, 게임 서버가 지역·ASN을 엄격히 보면 프록시 구간에서 지연이나 차단이 생깁니다. 이때는 특정 프로세스나 IP 대역만 직접 연결으로 보내는 예외 규칙을 두는 편이 낫습니다. “한 방에 전부 프록시”보다 예외를 문서화해 두는 쪽이 장기적으로 덜 고생합니다.

문제가 생겼을 때의 최소 진단 루틴

  1. 클라이언트·코어 버전을 최신 안정권으로 맞추고, 변경 로그에서 TUN·DNS 관련 항목을 읽습니다.
  2. TUN만 끄고 시스템 프록시만으로 증상이 사라지는지 확인해 캡처 경로 문제인지 가립니다.
  3. 동일 프로필에서 DNS 모드를 단순화해(예: 일시적으로 split 관련 의심 줄 제거) 재현성을 봅니다.
  4. 다른 VPN·필터를 끄고 단일 스택만 남겼을 때 동작하는지 확인합니다.

마이그레이션 직후라면 Clash for Windows → Verge Rev 가이드에서 다룬 포트·Override·시스템 프록시 순서와 함께 보는 것이 좋습니다. 예전 CFW 시절에는 TUN을 거의 안 쓰다가 Verge에서 켠 경우, 프로필에 tun 관련 키가 빠졌거나 구버전 문법이 남아 있는 경우도 흔합니다.

자주 묻는 질문

TUN만 켜면 속도가 느려지나요?

가상 인터페이스와 사용자 공간 스택을 한 번 더 거치므로 이론상 오버헤드는 있습니다. 다만 체감은 노드 품질·암호화·RTT에 더 크게 좌우되는 경우가 많습니다. 수치가 유의미하게 나쁘다면 스택 옵션·MTU·노드 프로토콜을 함께 보세요.

회사 PC에서 TUN이 막히는데 우회할 수 있나요?

보안·MDM 정책으로 가상 어댑터 생성이 금지된 환경은 기술적으로 막힌 것이지, Clash 설정만으로 “풀리는” 유형이 아닙니다. 업무 망에서는 IT 정책을 우선하세요.

모바일 이야기는 왜 거의 안 나오나요?

Android·iOS는 VPN API와 앱 샌드박스가 달라 데스크톱 TUN과 1:1로 대응하지 않습니다. 모바일 전용 클라이언트 문서를 보는 편이 정확합니다.

정리하면, TUN은 「안 따라오는 트래픽을 넓게 잡는 도구」이고, 그 다음이 규칙·DNS·노드 품질의 영역입니다. 한 번 설정해 두면 매일 쓰는 경로가 훨씬 예측 가능해지지만, 처음에는 권한·충돌·DNS 세 가지를 순서대로 점검하는 것이 시간을 아낍니다. → 유지보수되는 Clash 계열 클라이언트를 내려받고, TUN까지 포함한 스택을 직접 맞춰 보세요.