TUN 모드가 하는 일은 무엇인가요?
TUN은 운영체제에 가상의 네트워크 인터페이스를 만들고, 그 인터페이스를 통해 나가는 IP 패킷을 사용자 공간에서 돌아가는 Clash·Mihomo 같은 엔진이 가로채서 규칙에 따라 DIRECT로 보낼지, 특정 프록시 아웃바운드로 보낼지 결정하는 방식입니다. 브라우저가 시스템 프록시 설정을 따르든 말든, 애플리케이션이 자체적으로 DNS를 붙잡든 말든, 라우팅 테이블과 방화벽 규칙이 TUN 쪽으로 흐름을 넘기기만 하면 대부분의 TCP·UDP 세션이 같은 파이프라인을 타게 됩니다.
반대로 말하면 TUN은 만능이 아닙니다. 커널·보안 소프트웨어·다른 VPN·기업용 NAC가 경로를 고정해 두면 충돌이 나고, 일부 샌드박스된 앱은 애초에 일반 프로세스와 다른 네임스페이스를 쓰기도 합니다. 그럼에도 「시스템 프록시만 켰는데 터미널 도구나 특정 게임 런처가 직통한다」는 불만을 줄이는 데는 TUN이 가장 직관적인 레버입니다.
시스템 프록시와 TUN, 무엇이 다를까요?
시스템 프록시는 주로 프록시를 존중하는 앱에만 효력이 있습니다. 크롬·사파리처럼 OS 설정을 따르는 클라이언트는 잘 따라오지만, Go·Rust로 빌드된 CLI, 일부 Electron 앱, 자체 네트워크 스택을 가진 게임은 빈 환경에서 직접 소켓을 열어 버립니다. 이때 트래픽은 여전히 물리 NIC로 나가므로 규칙 엔진 밖으로 새어 나갈 수 있습니다.
TUN은 한 걸음 앞에서 IP 레이어 근처에서 패킷을 넘겨 받는 그림에 가깝습니다. 구현체와 OS 조합에 따라 세부는 다르지만, 사용자 입장에서는 「가상 어댑터 뒤에서 Clash가 라우팅을 도와준다」고 이해하시면 됩니다. 그래서 전역 분기나 UDP가 섞인 앱을 다룰 때 시스템 프록시보다 안정적인 경우가 많습니다. 다만 관리자 권한·프로필 서명·보안 제품 예외 등 운영 비용이 함께 늘어난다는 점은 감안해야 합니다.
누수는 보통 어디에서 생기나요?
사용자들이 말하는 누수는 크게 세 갈래로 나눌 수 있습니다. 첫째, 프록시 우회입니다. 앱이 시스템 설정을 무시하고 직접 연결하면 규칙이 적용되지 않습니다. 둘째, DNS 누수입니다. 도메인이 로컬 스텁 리졸버·ISP DNS로 먼저 나가면 관측 지점이 달라지고, fake-ip와 실제 목적지 불일치로 인해 「프록시를 탔는데도 이상하다」는 체감이 생기기도 합니다. 셋째, 규칙 매칭 실패입니다. GEO·도메인 목록이 오래되었거나, 스니핑이 꺼져 있어 SNI 없이 IP만 보이는 연결은 의도와 다른 아웃바운드로 떨어질 수 있습니다.
TUN을 켠다고 이 세 가지가 한 번에 사라지지는 않습니다. 특히 DNS는 tun 섹션과 dns 섹션, 그리고 운영체제의 스텁 리졸버(Windows의 Smart Multi-Homed Name Resolution, macOS의 mDNSResponder 등)가 동시에 개입합니다. 코어 업그레이드 가이드에서도 강조했듯이, DNS와 TUN을 동시에 크게 바꾸면 원인 분리가 어려우므로 한 축씩 검증하는 편이 안전합니다.
켜기 전에 확인할 전제 조건
첫째, 클라이언트가 사용하는 바이너리가 TUN 지원 빌드인지 확인하세요. 커뮤니티 GUI는 대부분 번들에 포함해 두지만, 경량 포크나 구형 빌드는 기능이 빠져 있을 수 있습니다. 둘째, OS 계정에 가상 어댑터 생성·라우트 변경을 허용할 만큼의 권한이 있어야 합니다. Windows에서는 관리자 승격 UAC, macOS에서는 시스템 확장·프로필 승인, Linux에서는 CAP_NET_ADMIN 또는 동등한 권한 모델이 관련됩니다.
셋째, 이미 실행 중인 다른 TUN·VPN·필터 드라이버가 있으면 순서를 정리해야 합니다. 같은 계층에서 두 제품이 라우트를 번갈아 덮어쓰면 「켜지는데 인터넷만 안 된다」는 증상이 흔합니다. 넷째, 회사 노트북처럼 MDM·Zero Trust 에이전트가 항상 켜져 있는 환경에서는 정책 위반으로 징계를 받을 수 있으니, 사용 가능 여부를 문서로 확인한 뒤 진행하십시오.
DNS와 TUN을 같이 설계하기
실무에서 가장 많이 지치는 구간이 DNS입니다. fake-ip를 쓰면 앱이 받은 가짜 주소를 기준으로 세션이 열리고, 코어가 다시 도메인 정보를 복원해 규칙에 태웁니다. 이 파이프라인은 강력하지만, 로컬 개발 서버·사내망 호스트명·캐스트 DNS 같은 예외와 부딪히면 혼란이 생깁니다. 반대로 redir-host 계열에 가깝게 두면 이해는 쉬운데, 일부 앱의 병렬 리졼브 때문에 체감 지연이 늘 수 있습니다.
권장 흐름은 다음과 같습니다. (1) TUN을 켜기 전에 현재 DNS가 어디로 나가는지 한 번 관찰합니다. (2) 코어의 DNS 섹션에서 업스트림과 도메인별 폴리시를 최소 구성으로 맞춥니다. (3) TUN을 켠 뒤에도 OS가 여전히 자체 캐시를 쓰는지 확인하고, 필요하면 해당 OS 문서에 맞춰 스텁을 정리합니다. (4) 문제가 생기면 TUN만 끄고 DNS만 남겨 보거나, 그 반대로 좁혀 가며 재현 조건을 적어 둡니다.
설정 파일에서 자주 보는 키(개념 정리)
실제 키 이름은 코어 버전과 클라이언트 프리셋에 따라 조금씩 다릅니다. 여기서는 Mihomo·Clash Meta 계열 문서에 흔히 등장하는 개념만 짚습니다. tun 블록의 enable 스위치, stack(시스템별 gVisor·mixed 등 선택지), auto-route·strict-route 류의 라우팅 보조 플래그, 그리고 inet4/inet6 address로 가상 대역을 고정하는 옵션이 대표적입니다. IPv6를 쓰는 회선이라면 IPv4만 열어 두고 IPv6가 비슷한 경로로 새는 경우도 있으니, 환경에 맞게 켜고 끄는 것이 좋습니다.
YAML을 직접 만지기보다 GUI에서 TUN 토글만 쓰는 경우가 많은데, 이때도 내부적으로는 위 옵션들이 합성되어 있습니다. 업데이트 후 갑자기 연결이 끊기면 릴리스 노트에서 TUN 관련 변경을 먼저 찾아보세요. 벤더 중립적인 문서 흐름은 문서 허브의 고급 설정 파트와 함께 보시면 구성 의도를 더 빨리 파악할 수 있습니다.
플랫폼별로 자주 걸리는 발목
Windows
WSL·Docker Desktop·가상화 스위치가 켜진 환경에서는 가상 스위치와 기본 게이트웨이가 복잡하게 얽힙니다. Clash 계열이 올리는 라우트가 다른 소프트웨어에 의해 덮어씌워지면 순간적으로 루프백이나 blackhole로 빠지기도 합니다. 방화벽 프로필이 도메인·개인·공용으로 나뉘어 있을 때 실행 파일 허용 규칙이 빠지면 패킷이 조용히 버려지는 일도 있으니, 문제가 반복되면 이벤트 뷰어와 방화벽 로그를 함께 보십시오.
macOS
최근 macOS는 커널 확장 대신 네트워크 확장 계열 경로를 선호합니다. 처음 설치한 앱이 시스템 설정에서 개인정보 보호·보안 항목에 막혀 있으면 TUN이 생성되지 않습니다. iCloud 프라이빗 릴레이나 다른 필터 VPN과 동시에 켜면 DNS 순서가 뒤섞이기 쉬우니, 한 번에 하나씩만 활성화해 테스트하세요.
Linux
배포판마다 네트워크 매니저(systemd-networkd, NetworkManager 등)가 라우트를 재적용하는 타이밍이 달라 TUN이 잠깐 떴다가 사라지는 현상이 보고됩니다. 데스크톱과 서버 무헤드 이미지의 차이도 큽니다. 컨테이너 호스트에서 직접 TUN을 쓰는 경우는 네임스페이스까지 고려해야 하므로, 일반 사용자 시나리오와는 별도의 체크리스트가 필요합니다.
안전하게 켜는 순서(권장 롤아웃)
-
1단계: 작동 중인 프로필 백업
GUI보내기나 YAML 원본을 복사해 두고, 문제가 생기면 즉시 되돌릴 수 있게 합니다. -
2단계: 시스템 프록시만으로 충분한지 재확인
브라우저 위주라면 TUN 없이도 규칙이 잘 먹는 경우가 많습니다. 불필요한 TUN은 충돌 표면만 넓힙니다. -
3단계: DNS를 먼저 안정화
TUN을 켜기 전에 도메인 분기가 기대대로인지 로그로 확인합니다. 스니핑·fake-ip를 동시에 켠다면 예외 도메인을 미리 넣어 둡니다. -
4단계: TUN 토글 ON → 즉시 연결 테스트
일반 웹, UDP가 있는 앱, 사내망 자원까지 세트로 시험합니다. 실패하면 스택 옵션을 바꿔 보거나 auto-route 관련 플래그를 조정합니다. -
5단계: 재부팅·슬립 이후 재검증
일부 드라이버는 재기동 후 순서가 달라집니다. 업데이트 직후 한 번 더 확인하는 습관이 장애 시간을 줄입니다.
증상별 트러블슈팅
TUN을 켜자마자 전체 망이 끊긴다
라우트 루프나 DNS 블랙홀 가능성이 큽니다. 우선 TUN을 끄고 복구한 뒤, strict-route·auto-route 조합과 기본 게이트웨이 중복을 의심하세요. 다른 VPN이 자동 재연결 중이면 일시적으로 비활성화합니다.
특정 앱만 여전히 직통한다
앱이 고정 IP로 붙거나, 자체 인증서 고정·핀닝을 사용하는 경우입니다. 가능하면 해당 앱의 프록시 설정을 명시하고, 불가능하면 분할 터널링 정책을 문서화해 예외로 관리합니다.
해상도는 되는데 기대한 노드를 안 탄다
규칙 우선순위·GEO 데이터·스니핑 설정을 다시 확인하세요. rule-provider·rule-set 가이드에서 캐시를 비우는 절차도 함께 보시면 도움이 됩니다.
정리
TUN 모드는 「시스템 프록시가 닿지 않는 구멍」을 메우는 강력한 도구지만, DNS·라우팅·보안 소프트웨어와 함께 움직이는 시스템 급 기능입니다. 한 번에 모든 옵션을 켜기보다 백업과 단계적 검증으로 굴리면, 재현하기 어려운 간헐 장애를 크게 줄일 수 있습니다. 규칙 품질이 좋을수록 TUN의 이점이 분명해지고, 규칙이 어긋나 있으면 오히려 모든 트래픽이 한 아웃바운드에 몰리거나 반대로 직통이 늘어나는 부작용도 생깁니다.
브라우저만 쓰는 가벼운 환경과, 터미널·게임·스트리밍이 섞인 무거운 환경은 요구 사항이 다릅니다. 전자는 시스템 프록시로도 충분한 경우가 많고, 후자는 TUN과 DNS 튜닝을 같이 설계할 때 체감이 좋아집니다. 여러 클라이언트를 거쳐 왔다면 UI 일관성과 코어 업데이트 주기까지 포함해 비교해 보시길 권합니다. Mihomo 기반 배포는 프로토콜·규칙 세트 확장과 TUN 스택 개선이 한 묶음으로 따라오는 경우가 많아, 장기적으로 운영 부담을 줄이는 선택이 되는 경우가 많습니다.