Clash TUN 모드 설정 가이드: 전체 트래픽 가로채기 원리와 구성 점검

TUN 모드는 어떤 문제를 해결하나요?

일반적인 시스템 프록시는 애플리케이션이 운영체제의 프록시 설정을 직접 읽어야 작동합니다. 브라우저, 일부 다운로드 도구와 일반적인 데스크톱 애플리케이션은 대개 이 방식으로 HTTP 또는 HTTPS 요청을 Clash에 전달할 수 있습니다. 하지만 게임 런처, 명령줄 프로그램, 독립 업데이트 프로그램과 자체 네트워크 스택을 사용하는 애플리케이션은 대상 주소에 직접 연결할 수 있습니다. 이 경우 시스템 프록시를 켜도 해당 연결은 Clash를 거치지 않습니다.

TUN 모드는 가상 네트워크 인터페이스를 만들고 운영체제에 해당 라우팅 정보를 추가합니다. 라우팅 조건에 맞는 IP 패킷은 먼저 가상 인터페이스로 들어간 뒤 Clash 또는 mihomo 코어가 연결 대상 식별, 규칙 매칭을 수행하고 직접 연결 또는 프록시 출구를 선택합니다. 네트워크 계층의 트래픽 진입점을 처리하므로 일반적으로 시스템 프록시보다 적용 범위가 넓습니다.

“TUN 가로채기”와 Clash의 “전체 모드”는 같은 설정이 아닙니다. TUN은 트래픽이 코어로 들어갈 수 있는지를 결정하고, 규칙·전체·직접 연결 등의 실행 모드는 코어에 들어온 뒤 어떤 출구를 선택할지를 결정합니다. TUN을 켠 상태에서도 규칙 모드를 사용해 중국 본토 주소는 직접 연결하고 특정 도메인은 프록시로 보낼 수 있으며, 문제를 확인할 때는 일시적으로 전체 모드로 전환할 수도 있습니다.

가상 네트워크 어댑터가 트래픽을 가로채는 실제 경로

애플리케이션이 연결을 시작하면 운영체제는 먼저 로컬 라우팅 테이블을 조회합니다. TUN이 활성화되고 자동 라우팅이 적용되면 클라이언트는 가상 인터페이스로 향하는 라우팅을 추가하는 동시에 LAN, 기본 게이트웨이와 필수 시스템 주소에 대한 접근 경로를 유지합니다. 패킷이 TUN 인터페이스에 도착하면 코어가 연결 정보를 복원하고 대상을 규칙 엔진에 전달합니다.

애플리케이션이 도메인 확인을 요청하면 DNS 조회가 시스템 확인기 또는 Clash DNS 모듈로 전달됩니다.
운영체제는 라우팅 테이블에 따라 대상 연결을 가상 네트워크 어댑터로 보냅니다.
Clash는 도메인, 대상 IP, 포트, 프로세스 정보 또는 규칙 집합을 기준으로 매칭합니다.
일치한 정책 그룹이 사용할 프록시 노드 또는 직접 연결 출구를 선택합니다.
아웃바운드 연결은 실제 네트워크 어댑터를 통해 전송되고, 반환 데이터는 다시 가상 인터페이스를 거쳐 애플리케이션으로 전달됩니다.

이 경로에서는 DNS와 라우팅이 일관되게 유지되어야 합니다. 도메인을 외부 DNS가 직접 확인하고 규칙이 도메인 분류에 의존한다면 코어가 확인된 IP만 보게 되어 예상한 도메인 규칙이 매칭되지 않을 수 있습니다. mihomo의 Fake-IP 강화 모드를 사용하면 DNS 모듈이 도메인에 제어된 가상 주소를 반환하고 내부에 도메인과 연결의 매핑을 저장합니다. 애플리케이션이 이 주소에 연결하면 코어가 원래 도메인을 복원한 뒤 도메인 규칙을 적용할 수 있습니다.

Fake-IP가 모든 환경에 적합한 것은 아닙니다. LAN 기기 검색, 일부 게임, 기업 내부망 도메인과 실제 주소를 기준으로 판단하는 프로그램은 제외 목록에 추가해야 할 수 있습니다. 클라이언트가 지원한다면 Redir-Host로 변경할 수도 있습니다. 선택 기준은 도메인 규칙 인식이 안정적인지, LAN 서비스에 접근할 수 있는지입니다.

활성화 전 코어, 구독 및 권한 확인

먼저 클라이언트가 사용하는 코어가 TUN을 지원하는지 확인하세요. 현재 널리 사용되는 mihomo 코어는 TUN, 자동 라우팅, 인터페이스 자동 감지와 다양한 프로토콜 처리를 지원하지만, 그래픽 클라이언트마다 표시되는 옵션 이름은 다릅니다. 일부 클라이언트는 TUN을 “설정” 또는 “서비스 모드”에 배치하고, 먼저 시스템 서비스를 설치해야 하는 경우도 있습니다. 업데이트가 중단된 구형 클라이언트는 오래된 코어를 포함할 수 있어 구성 필드와 운영체제 호환성이 다를 수 있습니다.

1. 유효한 구독 업데이트 및 불러오기

TUN은 트래픽 진입점만 바꿀 뿐, 작동하지 않는 노드를 복구하지는 않습니다. 활성화하기 전에 구독을 수동으로 업데이트하고 현재 구성이 불러와졌는지 확인한 다음 정책 그룹에서 연결 가능한 노드를 선택하세요. 먼저 시스템 프록시로 브라우저 접속을 테스트할 수 있습니다. 일반 프록시로도 연결되지 않는다면 구독 주소, 노드 상태, 정책 그룹 선택과 로컬 네트워크부터 확인해야 합니다.

2. 시스템 권한 준비

가상 네트워크 어댑터를 만들고 라우팅을 수정하려면 일반적으로 높은 권한이 필요합니다. Windows 클라이언트는 서비스를 설치하거나 최초 설정을 관리자 권한으로 완료해야 할 수 있고, macOS는 네트워크 확장 또는 VPN 구성 권한을 요청합니다. Android 클라이언트는 대개 시스템 VPN 인터페이스로 트래픽을 가로채며 VPN 연결 확인 창을 표시합니다. 권한을 승인한 뒤에는 시스템 팝업만 믿지 말고 클라이언트로 돌아가 TUN 상태를 확인하세요.

3. 기존 네트워크 설정 기록

활성화 전에 사용 중인 VPN, 가상 머신 네트워크 어댑터, 회사 보안 클라이언트, DNS 도구와 기본 게이트웨이를 기록해 두세요. 여러 프로그램이 기본 라우팅이나 DNS를 동시에 수정하면 나중에 실행된 프로그램이 먼저 실행된 프로그램의 설정을 덮어쓸 수 있습니다. 문제를 확인할 때는 트래픽 가로채기 도구 하나만 남겨 기본 연결을 확인한 뒤 다른 프로그램을 하나씩 다시 활성화하세요.

Clash TUN 모드 활성화 단계

클라이언트마다 화면의 명칭은 다르지만 실행 흐름은 대체로 같습니다. 다음 순서는 mihomo 코어를 사용하는 일반적인 데스크톱 클라이언트에 적용할 수 있습니다. 그래픽 스위치를 제공한다면 우선 화면에서 변경하세요. YAML을 직접 편집할 때는 설정 저장 과정에서 해당 구성 구간이 덮어쓰이지 않는지 먼저 확인해야 합니다.

클라이언트를 시작하고 현재 구독을 업데이트한 뒤 구성 파일에 파싱 오류가 없는지 확인합니다.
프록시 또는 정책 그룹 화면에서 연결 가능한 노드를 선택하고 실행 모드는 “규칙”으로 유지합니다.
설정 페이지에서 TUN, 가상 네트워크 어댑터 또는 트래픽 가로채기 관련 옵션을 찾습니다.
화면에서 서비스 모드, 보조 서비스 또는 네트워크 확장 설치를 요구하면 먼저 설치와 시스템 권한 승인을 완료합니다.
TUN을 켜고 자동 라우팅을 활성화합니다. 인터페이스 자동 감지를 지원한다면 함께 켜도 됩니다.
클라이언트 상태 영역에서 TUN이 실행 중인지 확인합니다. “권한 승인 대기” 또는 “시작 실패” 상태에 머물러서는 안 됩니다.
시스템 프록시를 끈 상태에서 한 번 테스트하여, 원래 프록시를 읽지 않던 애플리케이션도 규칙에 따라 연결되는지 확인합니다.

필드 간 관계를 설명하기 위한 mihomo 구성 예시는 다음과 같습니다. 실제로 사용할 수 있는 필드는 클라이언트에 내장된 코어 버전에 따라 다르며, 그래픽 클라이언트가 생성한 구성은 해당 화면과 로그를 기준으로 판단해야 합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

enable은 TUN의 시작 여부를 제어하고, auto-route는 코어가 필요한 라우팅을 자동으로 추가하도록 합니다. auto-detect-interface는 현재 실제 아웃바운드 인터페이스를 식별하며, stack은 TUN 패킷에 사용할 네트워크 스택 구현을 결정합니다. 일부 클라이언트는 system, gVisor 또는 mixed 등의 옵션을 제공합니다. 지원 여부는 플랫폼과 코어 버전에 따라 달라집니다. 일반적으로는 클라이언트 기본값을 사용하고, 특정 UDP·성능 또는 호환성 문제가 있을 때만 변경하세요.

예시의 공용 DNS는 필드 구조를 보여주기 위한 용도일 뿐입니다. 실제 환경에서는 로컬 네트워크에서 접근 가능한 확인 서비스를 사용하거나 구독 및 클라이언트 안내에 따라 DoH, DoT를 설정할 수 있습니다. 핵심은 DNS 요청이 확인 서비스에 안정적으로 도달하고 규칙 매칭 경로와 일관성을 유지하는 것입니다.

DNS, 라우팅 및 규칙으로 가로채기 결과 확인

스위치가 활성화로 표시된다고 해서 모든 경로가 정상이라는 뜻은 아닙니다. 클라이언트 로그를 먼저 확인하고, 다음으로 DNS와 라우팅을 점검한 뒤 구체적인 애플리케이션을 확인하는 단계별 검증이 필요합니다. 이를 통해 가상 네트워크 어댑터가 시작되지 않은 것인지, 규칙이 잘못된 출구를 선택한 것인지, 대상 애플리케이션 자체의 제한인지 구분할 수 있습니다.

클라이언트 로그 확인

TUN을 시작한 뒤 로그에서 권한 부족, 인터페이스 생성 실패, 라우팅 기록 실패 또는 포트 사용 중 메시지가 있는지 확인합니다. 이어서 대상 애플리케이션을 열면 로그에 해당 연결 기록이 나타나야 합니다. 기록이 전혀 없다면 일반적으로 트래픽이 TUN으로 들어오지 않은 것입니다. 기록은 있지만 연결에 실패한다면 규칙 매칭, 노드 상태와 DNS를 계속 확인하세요.

도메인 확인 점검

시스템 DNS 조회를 한 번 실행해 결과가 반환되는지 확인합니다. Fake-IP 모드에서는 일부 일반 도메인이 설정 범위 내의 가상 주소를 반환할 수 있으며, 이는 매핑 과정의 일부이지 대상 서버의 실제 주소가 바뀐 것이 아닙니다. 모든 도메인 요청이 시간 초과된다면 DNS 수신 대기, 상위 확인기, 방화벽과 다른 DNS 소프트웨어를 점검하세요.

규칙 매칭 확인

연결 목록 또는 로그에서 테스트 도메인을 찾아 예상한 규칙과 정책 그룹에 매칭되었는지 확인합니다. 규칙 모드에서는 앞선 규칙에 매칭되지 않은 연결을 최종 규칙이 처리하는 경우가 많습니다. 최종 규칙이 직접 연결을 가리키면 TUN이 트래픽을 가로채더라도 해당 연결은 로컬 네트워크에서 직접 전송됩니다.

TCP, UDP 및 LAN을 각각 테스트

브라우저 접속은 주로 TCP와 DNS를 검증할 뿐 모든 상황을 확인하지는 못합니다. UDP가 필요한 애플리케이션도 테스트하고 라우터 관리 주소, 프린터 또는 LAN 서비스에 접속해 보세요. 외부 연결은 정상이지만 LAN에 접근할 수 없다면 LAN 주소가 자동 라우팅에 잘못 가로채였는지, 클라이언트에 사설 주소 우회 설정이 있는지 확인하세요.

결과	우선 확인할 항목	해결 방향
TUN을 시작한 직후 꺼짐	권한, 서비스 구성 요소, 가상 네트워크 어댑터	권한을 다시 승인하고 시작 로그 확인
애플리케이션 연결 로그가 없음	자동 라우팅, 기본 인터페이스, 다른 VPN	단일 가로채기 도구만 남긴 뒤 라우팅 재구성
로그에는 연결이 있지만 도메인 시간 초과	DNS 수신 대기 및 상위 확인기	DNS 구성과 방화벽 규칙 확인
브라우저는 정상인데 게임은 실패	UDP, 네트워크 스택, 게임 프로세스 규칙	UDP 로그를 확인하고 다른 스택 테스트
외부 네트워크는 정상인데 LAN 연결 끊김	사설 주소 라우팅, 인터페이스 선택	LAN 우회와 자동 라우팅 조정

일반적인 충돌과 복구 순서

TUN 문제는 주로 권한, DNS, 라우팅과 애플리케이션 충돌의 네 가지 계층에서 발생합니다. 처리할 때는 정해진 순서를 지키고 클라이언트를 바로 재설치하지 마세요. 각 단계를 마칠 때마다 다시 테스트하고 로그가 어떻게 바뀌는지 확인하세요.

TUN은 켜졌지만 기기가 인터넷에 연결되지 않음

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인합니다. 그런 다음 선택한 프록시 노드와 최종 규칙을 점검하세요. 직접 연결과 프록시 모두 실패한다면 DNS가 현재 접근할 수 없는 주소로 설정되어 있지 않은지 확인합니다. 기본 네트워크가 복구되면 클라이언트를 다시 시작하고 자동 라우팅을 활성화하세요. 그래도 실패하면 다른 VPN, 가상 머신 네트워크 관리 도구와 별도 DNS 프로그램을 일시적으로 종료합니다.

재부팅 또는 네트워크 전환 후 작동하지 않음

유선 네트워크에서 Wi-Fi로 전환하거나 핫스팟에 연결하고 기기를 깨운 뒤에는 기본 출구 인터페이스가 바뀔 수 있습니다. 인터페이스 자동 감지를 켜면 수동 설정을 줄일 수 있지만, 클라이언트에서 TUN을 다시 구성해야 할 수도 있습니다. TUN을 껐다가 다시 켜고 새 기본 게이트웨이가 인식되었는지 확인하세요. 네트워크를 자주 전환하는 기기에서는 더 이상 존재하지 않는 인터페이스 이름을 구성에 고정하지 않는 것이 좋습니다.

LAN 기기에 접근할 수 없음

프린터, NAS와 라우터 관리 페이지는 대개 사설 주소 또는 로컬 도메인을 사용합니다. 규칙에서 해당 주소의 직접 연결을 허용하는지 확인하고 LAN 트래픽이 프록시 출구로 잘못 전송되지 않는지 점검하세요. 도메인 기반 LAN 서비스는 로컬 DNS 또는 멀티캐스트 검색에 의존할 수도 있습니다. 필요한 경우 해당 도메인을 Fake-IP 제외 항목에 추가하고 로컬 확인 경로를 유지하세요.

일부 애플리케이션이 연결을 반복하거나 로그인이 비정상적임

먼저 연결 로그에서 대상 도메인과 출구를 확인합니다. 애플리케이션이 실제 IP, LAN 루프백 또는 특수한 UDP 동작에 의존한다면 해당 도메인이나 프로세스에 더 정확한 직접 연결 규칙을 설정할 수 있습니다. 규칙은 광범위한 규칙보다 앞에 배치하여 앞선 도메인 접미사나 규칙 집합에 먼저 매칭되지 않도록 하세요. 변경 후 연결을 다시 생성해야 하며, 기존 연결에 새 정책이 항상 자동 적용되는 것은 아닙니다.

클라이언트를 종료해도 네트워크가 복구되지 않음

먼저 클라이언트 프로세스와 서비스가 모두 종료되었는지 확인한 다음 시스템 프록시 또는 VPN 구성을 끕니다. 운영체제는 일반적으로 클라이언트가 만든 임시 라우팅을 정리합니다. 비정상 종료 후에도 문제가 남으면 실제 네트워크 어댑터를 비활성화했다가 다시 활성화하거나 시스템을 재부팅하여 네트워크 상태를 재구성할 수 있습니다. 기본 네트워크가 복구된 뒤 클라이언트를 시작하고, 잔여 상태에서 여러 트래픽 가로채기 도구를 계속 전환하지 마세요.

TUN, 시스템 프록시와 실행 모드 조합 방법

브라우저와 프록시 설정을 명시적으로 지원하는 데스크톱 프로그램만 사용한다면 시스템 프록시 구성이 간단하고 점검 범위도 작습니다. 게임, 터미널 도구, 스토어 앱 또는 시스템 프록시를 읽지 않는 소프트웨어까지 가로채야 할 때 TUN을 활성화하세요. 일부 클라이언트는 시스템 프록시와 TUN을 동시에 켤 수 있지만 반드시 함께 사용해야 한다는 뜻은 아닙니다. 테스트 단계에서는 시스템 프록시를 끄고 TUN만으로 적용 범위를 확인할 수 있습니다.

일상적인 사용에는 보통 “TUN 가로채기 + 규칙 모드”를 선택합니다. TUN은 트래픽을 코어로 보내고, 규칙 모드는 도메인·주소와 규칙 집합에 따라 트래픽을 분기합니다. 전체 모드는 특정 실패가 규칙 때문인지 짧은 시간 확인할 때 적합하지만, 계속 전체 모드를 사용하면 세밀한 분기 로직을 건너뛰게 됩니다. 직접 연결 모드는 애플리케이션이 로컬 네트워크에서 대상에 접근할 수 있는지 확인할 때 사용할 수 있습니다.

모바일 기기의 TUN은 대개 시스템 VPN 인터페이스로 구현되며, 일반적으로 한 번에 하나의 시스템 수준 VPN 연결만 유지할 수 있습니다. 따라서 Clash 계열 클라이언트를 켜면 다른 VPN 앱의 연결이 끊길 수 있습니다. 데스크톱 운영체제에서는 여러 가상 인터페이스가 동시에 존재할 수 있지만 기본 라우팅, DNS와 인터페이스 우선순위가 서로 영향을 줍니다. 안정적인 구성은 주된 트래픽 가로채기 도구를 하나로 명확히 정하는 것입니다.

활성화 후 전체 점검 목록

구독이 업데이트되었고 현재 구성을 정상적으로 불러올 수 있습니다.
정책 그룹에서 사용 가능한 노드를 선택했으며 규칙 모드의 최종 규칙이 예상대로 설정되어 있습니다.
시스템 서비스, 네트워크 확장 또는 VPN 권한 승인을 완료했습니다.
TUN 상태가 실행 중으로 표시되고 인터페이스 생성 또는 라우팅 기록 오류가 로그에 없습니다.
DNS 조회가 완료되고 도메인 규칙을 식별하여 매칭할 수 있습니다.
시스템 프록시를 끈 뒤에도 프록시 설정을 읽지 않는 애플리케이션의 연결 로그가 생성됩니다.
TCP, UDP와 LAN 접근을 각각 테스트했습니다.
네트워크 전환 또는 기기 절전 해제 후에도 기본 출구 인터페이스가 올바르게 식별됩니다.
다른 VPN, 가상 머신과 DNS 도구가 현재 라우팅을 중복해서 수정하지 않습니다.
TUN을 끄고 클라이언트를 종료한 뒤 기본 네트워크가 복구됩니다.

위 점검을 완료하면 TUN 경로를 네 부분으로 명확히 나눌 수 있습니다. 시스템 권한은 가상 인터페이스를 만들고, 라우팅은 패킷을 코어로 보내며, DNS는 규칙이 식별할 수 있는 대상 정보를 제공하고, 정책 그룹은 최종 출구를 결정합니다. 문제가 발생하면 이 네 부분을 순서대로 확인하는 편이 구성을 반복해서 재설치하거나 노드를 계속 바꾸는 것보다 효과적입니다.