Clash TUN 모드 활성화 방법: 전체 트래픽 가로채기 원리와 설정 단계

TUN 모드는 어떻게 전체 트래픽을 가로챌까

일반적인 Clash 시스템 프록시 모드는 운영체제에 HTTP 또는 SOCKS 프록시 주소를 설정합니다. 브라우저와 시스템 프록시 설정을 따르는 앱은 연결을 Clash에 넘기지만, 일부 게임·명령줄 프로그램·스토어 클라이언트·자체 네트워크 스택을 사용하는 소프트웨어는 대상 주소에 직접 연결할 수 있습니다. 따라서 시스템 프록시가 켜져 있어도 이러한 프로그램의 트래픽이 반드시 규칙 엔진으로 들어오는 것은 아닙니다.

TUN 모드는 다른 경로를 사용합니다. Clash Meta(현재는 mihomo라는 코어 이름으로 흔히 불림)는 시스템에 가상 네트워크 인터페이스를 만들고 라우팅 규칙과 함께 조건에 맞는 IP 트래픽을 해당 인터페이스로 보냅니다. 코어는 패킷의 대상 정보를 읽은 뒤 설정의 규칙, 프록시 그룹과 노드에 따라 직접 연결, 프록시 또는 차단을 결정합니다. 앱 입장에서는 일반 네트워크 연결을 시작할 뿐이므로 HTTP 프록시를 별도로 지원할 필요가 없습니다.

“전체 트래픽 가로채기”는 코어로 들어오는 트래픽의 범위를 뜻하며, 모든 연결이 하나의 프록시 노드를 거쳐야 한다는 의미는 아닙니다. TUN은 트래픽을 Clash로 보내고, 최종 경로는 실행 모드와 규칙이 결정합니다. 규칙 모드에서는 사설망 주소, 중국 본토 사이트, 프록시 사이트와 차단 도메인에 서로 다른 정책을 적용할 수 있습니다. 전역 모드에서는 코어가 프록시 가능한 트래픽을 전역 프록시 그룹으로 보내는 경우가 많고, 직접 연결 모드에서는 코어로 들어온 트래픽도 바로 허용될 수 있습니다.

TUN 활성화 전 버전·권한·설정 점검

먼저 클라이언트가 사용하는 코어가 TUN을 지원하는지 확인합니다. 최신 Clash Meta 또는 mihomo 코어는 일반적으로 TUN, 자동 라우팅과 DNS 연동 기능을 비교적 충실히 제공합니다. 오래된 Clash 코어, 유지 관리가 중단된 GUI 클라이언트 또는 기능이 축소된 모바일 구현은 일부 설정 항목이 없을 수 있습니다. 설정 파일을 성공적으로 가져왔다고 해서 현재 코어가 모든 TUN 옵션을 인식한다는 뜻은 아닙니다. 클라이언트의 코어 이름과 버전, 시작 로그를 함께 확인해야 합니다.

시스템 권한

가상 인터페이스 생성, 라우팅 테이블 수정과 DNS 설정에는 일반적으로 권한 상승이 필요합니다. Windows 클라이언트는 서비스 모드 또는 관리자 권한으로 작업할 수 있고, macOS는 네트워크 확장, VPN 구성 또는 보조 서비스 승인을 요구합니다. Linux에서는 root, CAP_NET_ADMIN, 시스템 서비스와 해당 라우팅 권한이 필요한 경우가 많습니다. 권한 요청을 거부한 뒤에는 화면의 TUN 스위치가 켜진 것처럼 보여도 로그에 인터페이스 생성 실패 또는 라우팅 기록 실패가 나타날 수 있습니다.

권한은 클라이언트가 제공하는 서비스 설치, 권한 부여 또는 네트워크 확장 메뉴를 통해 처리해야 합니다. 관리자 권한으로 반복 재시작하면 권한 문제인지 판단하는 데는 도움이 되지만, 장기적으로는 클라이언트가 명확히 지원하는 백그라운드 서비스 방식을 사용하는 편이 좋습니다.

구독과 로컬 오버라이드

구독은 주로 노드, 프록시 그룹과 규칙을 제공하며 현재 기기에 적합한 TUN 설정까지 포함하지 않을 수 있습니다. 일부 GUI 클라이언트는 TUN 매개변수를 앱 설정에 저장한 뒤 실행 시 설정을 생성하고, 다른 클라이언트는 YAML의 tun 섹션을 직접 읽습니다. 구독으로 생성된 파일을 수동 편집하면 다음 구독 업데이트에서 변경 사항이 덮어써질 수 있습니다. 안정적인 방법은 클라이언트의 오버라이드, 믹스인 또는 설정 패치 기능을 사용하고 정상적으로 시작되는 원본 설정을 별도로 보관하는 것입니다.

네트워크 환경

• 현재 사용하는 Wi-Fi, 유선 네트워크 또는 모바일 핫스팟을 기록하고 다른 VPN이 켜져 있지 않은지 확인합니다.
• 컴퓨터에서 가상 머신, 컨테이너 네트워크, 게임 가속기 또는 기업용 보안 소프트웨어가 실행 중인지 확인합니다.
• 도메인 해석 장애가 발생했을 때 복구할 수 있도록 현재 DNS 설정을 보관합니다.
• 구독의 노드 중 일반 시스템 프록시 모드에서 연결 가능한 노드가 하나 이상 있는지 확인합니다.
• 문제 해결 중 설정이 바뀌지 않도록 몇 분 동안 설정 파일 자동 업데이트를 일시 중지합니다.

Clash Meta 및 mihomo TUN 설정 단계

GUI 클라이언트에서는 보통 네트워크, 서비스 모드 또는 TUN 설정 화면에서 활성화할 수 있습니다. 먼저 클라이언트가 요구하는 서비스 구성 요소를 설치한 다음 TUN을 켜고, 로그에 가상 인터페이스·라우팅·DNS 리스닝 관련 기록이 나타나는지 확인하세요. 클라이언트에서 네트워크 스택을 선택할 수 있다면 고급 매개변수를 한꺼번에 바꾸기보다 호환성이 균형 잡힌 옵션부터 테스트하는 것이 좋습니다.

mihomo YAML 설정을 직접 관리한다면 다음 기본 구조에서 시작할 수 있습니다. 버전에 따라 지원 필드와 기본값이 달라질 수 있으므로 최종적으로는 현재 코어가 출력하는 설정 오류와 클라이언트 설명을 기준으로 판단해야 합니다.

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true
  strict-route: true

기본 필드 설명

system은 시스템 네트워크 스택을 사용하는 경향이 있어 성능과 시스템 프로토콜 호환성이 좋은 편입니다. gvisor는 사용자 공간 네트워크 스택을 사용하므로 환경에 따라 격리와 호환성이 다르게 나타날 수 있습니다. mixed는 프로토콜에 따라 조합된 방식으로 처리합니다. 적합한 선택은 운영체제, 코어 버전, UDP 앱과 로컬 보안 소프트웨어에 따라 달라집니다. 웹페이지는 정상인데 게임 음성 채팅, UDP 요청 또는 특정 프로그램에 문제가 있다면 한 번에 하나의 스택 옵션만 바꾼 뒤 코어를 다시 시작해 결과를 비교하세요.

순서대로 활성화하기

1. 클라이언트가 지원하는 안정적인 코어로 업데이트하고 현재 설정이 정상적으로 로드되는지 확인합니다.
2. 클라이언트에 필요한 시스템 서비스, 네트워크 확장 또는 가상 네트워크 인터페이스 구성 요소를 설치하거나 활성화합니다.
3. TUN을 켜고 먼저 자동 라우팅과 외부 인터페이스 자동 감지를 사용합니다.
4. 규칙 모드를 유지하고 이미 작동이 확인된 프록시 노드를 정책으로 선택합니다.
5. 코어를 다시 시작한 뒤 설정 필드, 권한, 인터페이스 또는 라우팅 오류가 보고되는지 확인합니다.
6. 브라우저, 터미널 명령과 원래 시스템 프록시를 따르지 않던 앱을 각각 테스트합니다.
7. 기본 연결이 안정된 뒤 엄격한 라우팅을 활성화하거나 네트워크 스택을 조정합니다.

설정을 변경한 뒤에는 코어를 완전히 다시 로드해야 합니다. 텍스트 편집기에서 YAML만 저장하고 클라이언트는 이전 실행 설정을 계속 사용하는 것이 흔한 오판 원인입니다. 클라이언트 로그의 설정 로드 시간, 코어 시작 시간과 현재 작동 모드를 통해 새 설정이 적용되었는지 확인할 수 있습니다.

TUN 모드와 DNS 연동 방식

TUN은 IP 패킷을 가로채지만 규칙 매칭은 도메인에 의존하는 경우가 많습니다. 앱은 먼저 도메인을 조회한 뒤 반환된 IP에 연결합니다. DNS 조회가 Clash를 우회하면 코어에는 대상 IP만 보일 수 있어 도메인 규칙의 매칭 능력이 떨어집니다. 더 복잡한 경우에는 로컬 DNS가 적절하지 않은 주소를 반환하고, 프록시 노드가 위치한 네트워크에서는 실제로 다른 결과를 반환할 수 있습니다. 그러면 노드는 정상인데 특정 웹사이트만 열리지 않는 현상이 발생합니다.

mihomo의 DNS 모듈은 조회를 통합 처리하고 규칙 라우팅, Fake-IP 또는 Redir-Host 같은 향상 모드와 연동할 수 있습니다. 다음 구조는 각 부분의 관계를 설명하기 위한 것이며, DNS 서버 주소는 실제 네트워크와 설정 출처에 맞춰 선택해야 합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

Fake-IP 모드는 도메인에 예약 주소 대역의 임시 주소를 반환하고 코어 내부에 도메인 매핑을 저장합니다. 앱이 이 임시 주소에 연결하면 코어가 원래 도메인을 복원해 도메인 규칙을 적용할 수 있습니다. 이 방식은 규칙 매칭 정보를 유지하는 데 유리하지만, 실제 IP·로컬 네트워크 검색·기기 화면 공유 또는 특수 인증 절차에 의존하는 일부 앱은 필터 목록에 추가해야 할 수 있습니다. 필터 항목은 명확한 장애가 확인된 경우에만 하나씩 추가해야 하며, 지나치게 넓은 와일드카드 범위는 도메인 매핑 효과를 떨어뜨립니다.

dns-hijack의 any:53은 주로 기존 53 포트 DNS를 처리합니다. 앱 내장 암호화 DNS, 브라우저 DoH 또는 고정된 외부 DNS 방식은 같은 경로를 따르지 않을 수 있습니다. 문제를 확인할 때는 브라우저의 보안 DNS 기능을 잠시 끄고 시스템 조회가 먼저 Clash로 들어오게 하여 여러 DNS 방식이 동시에 작동하는 것이 원인인지 판단할 수 있습니다.

DNS 순환 피하기

코어가 상위 DNS 서버를 조회할 때 관련 트래픽도 올바른 출구를 선택해야 합니다. 상위 DNS의 도메인 자체가 아직 완료되지 않은 해석에 의존하거나, 조회가 라우팅 규칙에 의해 같은 리스닝 엔드포인트로 반복 전달되면 시작 단계에서 해석 루프가 발생할 수 있습니다. 설정이 복잡할수록 기본 DNS 서버, 프록시 노드 도메인 해석과 직접 연결 상위 서버의 접근 가능성을 확인해야 합니다. 로그에 반복해서 나타나는 DNS 시간 초과는 웹페이지 오류보다 문제를 더 명확히 보여주는 경우가 많습니다.

TUN 적용 여부를 확인하는 테스트 방법

화면의 스위치가 켜진 상태가 되는 것은 첫 단계일 뿐입니다. 완전한 검증을 위해서는 가상 인터페이스의 존재, 라우팅 기록 여부, 트래픽의 코어 유입, 규칙의 정상 매칭과 DNS 우회 여부를 함께 확인해야 합니다. 한 번에 하나의 질문에 답할 수 있도록 쉬운 테스트부터 단계적으로 진행하는 것이 좋습니다.

1. 시작 로그 확인: 설정 해석 실패, 권한 부족, 가상 인터페이스 생성 실패 또는 라우팅 기록 실패가 없는지 확인합니다.
2. 일반 웹페이지 확인: 직접 연결 규칙과 프록시 규칙에 해당하는 사이트를 방문하고 연결 목록에서 어떤 정책이 매칭되는지 확인합니다.
3. 시스템 프록시를 읽지 않는 프로그램 테스트: 시스템 프록시를 끄고 TUN만 남긴 뒤 터미널 다운로드 도구 또는 대상 앱을 실행합니다.
4. 연결 기록 확인: 도메인, 대상 주소, 프로세스 정보와 최종 정책을 대조하여 트래픽이 실제로 코어를 통과하는지 확인합니다.
5. UDP 테스트: UDP에 실제로 의존하는 앱으로 짧게 테스트하여 현재 네트워크 스택의 호환성을 판단합니다.
6. 로컬 네트워크 확인: 라우터, NAS 또는 프린터 주소를 열어 사설망 대역이 잘못 프록시되지 않는지 확인합니다.
7. 네트워크 전환: Wi-Fi에서 핫스팟으로 전환한 뒤 기본 인터페이스와 라우팅이 자동으로 갱신되는지 다시 확인합니다.

연결 기록은 “가로채지 못한 경우”와 “가로챈 뒤 규칙이 잘못된 경우”를 구분하는 핵심 단서입니다. 대상 앱을 실행해도 새 연결이 전혀 나타나지 않는다면 TUN 인터페이스, 라우팅, 앱 우회와 권한을 먼저 확인하세요. 연결은 나타났지만 잘못된 정책이 선택되었다면 규칙 순서, 도메인 식별과 프록시 그룹을 점검해야 합니다. 정책은 올바르지만 연결이 시간 초과된다면 노드, DNS, MTU, 방화벽과 원격 서비스까지 확인하세요.

규칙 모드에서의 판단

규칙은 위에서 아래로 매칭되며, 일반적으로 일치하는 순간 이후 규칙 검사를 중단합니다. TUN을 사용해도 이 기본 순서는 바뀌지 않습니다. 프록시로 보내야 할 도메인이 직접 연결 규칙에 매칭되었다면 해당 트래픽이 도메인, 대상 IP 또는 프로세스 정보 중 어떤 형태로 규칙 엔진에 들어왔는지 확인해야 합니다. 범위가 넓은 IP-CIDR, GEOIP 또는 앞쪽에 배치된 직접 연결 규칙이 뒤의 더 구체적인 처리를 덮어쓸 수 있습니다. 기본 처리 규칙은 보통 규칙 목록의 마지막에 둡니다.

일반적인 충돌과 단계별 문제 해결 순서

TUN을 켠 뒤 인터넷이 완전히 끊김

먼저 TUN을 끄고 기본 네트워크가 즉시 복구되는지 확인한 다음 코어 로그를 확인하세요. 인터넷이 완전히 끊기는 현상은 인터페이스 생성 후 코어가 정상적으로 실행되지 않거나, 기본 라우팅이 잘못 지정되었거나, DNS가 응답하지 않거나, 권한 상태가 완전하지 않을 때 주로 발생합니다. 복구를 테스트할 때는 먼저 strict-route를 끄고 auto-route와 auto-detect-interface를 유지한 뒤 다른 VPN을 잠시 종료하세요. 유선과 무선 네트워크가 동시에 연결되어 있다면 코어가 실제로 외부 인터넷에 접근할 수 있는 기본 인터페이스를 인식했는지 확인해야 합니다.

브라우저는 되지만 게임 또는 음성 채팅이 실패함

브라우저는 주로 TCP와 HTTPS를 사용하지만 게임, 실시간 음성 채팅과 일부 메신저 기능은 UDP를 사용합니다. 이때는 UDP 연결이 코어로 들어오는지, 노드가 해당 전송을 지원하는지, 현재 TUN 네트워크 스택이 앱에 적합한지 확인해야 합니다. system, gvisor, mixed를 전환할 때는 한 번에 하나씩 테스트하세요. DNS, 노드와 규칙을 동시에 바꾸면 개선 원인을 판단할 수 없습니다.

활성화 후 로컬 네트워크에 접근할 수 없음

사설 주소 대역이 계속 직접 연결로 처리되는지 확인하고, 엄격한 라우팅이 로컬망의 출구를 바꾸었는지 점검하세요. 일반적인 사설망 대역으로는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 있지만, 실제 기기는 링크 로컬 주소, IPv6 로컬망 주소 또는 특정 멀티캐스트 프로토콜을 사용할 수도 있습니다. 기기 IP 주소는 직접 열리지만 기기 이름으로 접근할 수 없다면 로컬 DNS, mDNS 또는 Fake-IP 필터 문제일 가능성이 큽니다.

다른 VPN·가상 머신·컨테이너와 충돌

여러 네트워크 도구가 가상 인터페이스를 만들고 기본 라우팅을 수정할 수 있습니다. 기업용 VPN, 게임 가속기, 가상 머신 브리지, Docker 또는 컨테이너 서브넷은 TUN 자동 라우팅과 겹칠 수 있습니다. 문제를 확인할 때는 먼저 다른 트래픽 가로채기 도구를 종료하고 Clash TUN만 정상적으로 실행되는지 확인한 뒤 하나씩 다시 켜세요. 두 도구를 반드시 함께 사용해야 한다면 각 인터페이스가 처리할 네트워크 대역을 명확히 나누고, 서로의 가상망을 기본 출구로 지정하지 않도록 해야 합니다.

절전 모드 또는 네트워크 전환 후 작동하지 않음

노트북이 절전 모드에서 깨어나거나 Wi-Fi가 전환되거나 핫스팟을 바꾸면 기본 인터페이스와 게이트웨이가 달라질 수 있습니다. auto-detect-interface가 출구를 감지하더라도 클라이언트가 모든 시스템 이벤트 직후 라우팅을 즉시 재구성하지는 않을 수 있습니다. 먼저 클라이언트를 재설치하기보다 코어를 다시 시작해 보세요. 코어 재시작만으로 복구된다면 클라이언트의 네트워크 변경 감지, 백그라운드 실행 권한과 서비스 상태를 추가로 확인해야 합니다.

구독 업데이트 후 TUN 설정이 사라짐

대개 구독으로 생성된 파일에 매개변수를 직접 작성했으며, 업데이트 과정에서 클라이언트가 해당 파일을 다시 내려받아 교체했다는 뜻입니다. TUN과 DNS 매개변수를 클라이언트가 지원하는 오버라이드 레이어, 믹스인 설정 또는 독립적인 전역 설정으로 옮겨야 합니다. 변경 후 구독을 한 번 수동으로 업데이트하고 코어를 다시 시작한 뒤에도 매개변수가 남아 있어야 저장 위치가 올바르다고 확인할 수 있습니다.

계층별로 문제 범위 좁히기

단계별 문제 해결의 핵심은 비교 가능한 결과를 남기는 것입니다. 한 번에 변수 하나만 변경하고, 변경 후 코어를 다시 시작하며, 로그에서 처음 나타난 명확한 오류를 기록하세요. 클라이언트를 바로 재설치하면 일부 현장 정보가 사라지고 문제가 권한·라우팅·DNS·노드 중 어디에서 비롯되었는지도 설명할 수 없습니다.

TUN 일상 사용 설정 권장 사항

기본 설정을 마친 뒤 매개변수를 계속 추가할 필요는 없습니다. 자동 라우팅, 명확한 DNS 구성, 이해하기 쉬운 규칙과 안정적인 노드가 실험적인 옵션을 많이 사용하는 것보다 유지 관리하기 쉽습니다. 브라우저와 일반 데스크톱 소프트웨어만 사용하는 기기라면 시스템 프록시만으로도 주요 요구 사항을 충족할 수 있습니다. 명령줄 프로그램, 게임 또는 특정 앱이 시스템 프록시를 따르지 않을 때 TUN을 활성화하는 편이 더 적절합니다.

TUN을 장기간 사용하는 기기는 코어 업데이트 후 필드 변경 사항을 정기적으로 확인하고, 업데이트 전에 정상 작동하는 설정을 보관해야 합니다. 문제가 발생하면 먼저 업데이트 전후의 코어 버전, 네트워크 스택과 DNS 동작을 비교하세요. 클라이언트 화면의 설정 이름은 다를 수 있지만, 기본 원리는 인터페이스·라우팅·DNS·규칙·노드라는 다섯 단계로 이해할 수 있습니다.

최종 설정의 목표는 모든 트래픽을 기계적으로 프록시로 보내는 것이 아닙니다. 가로채야 할 연결이 안정적으로 규칙 엔진에 들어오게 한 뒤 용도에 따라 직접 연결, 프록시 또는 차단을 선택하는 것입니다. 이를 이해하면 TUN, 전역 모드와 규칙 모드의 차이가 명확해지고 노드 장애를 가상 네트워크 인터페이스 문제로 오해하는 일도 줄어듭니다.