Clash TUN 모드 설정 방법과 원리: 가상 네트워크 인터페이스로 전체 트래픽 처리

TUN 모드와 시스템 프록시: 트래픽을 가져오는 방식이 다릅니다

Clash의 시스템 프록시와 TUN 모드는 애플리케이션의 연결을 코어로 전달하는 서로 다른 방법입니다. 시스템 프록시는 앱에 로컬 HTTP 또는 SOCKS 프록시 주소를 알려 주고, TUN은 3계층 가상 네트워크 인터페이스를 만들어 운영체제의 라우팅을 통해 조건에 맞는 IP 패킷을 코어로 보냅니다. 어느 쪽도 노드 프로토콜이 아니며 구독에 포함된 프록시 서버를 대체하지 않습니다.

브라우저는 대체로 시스템 프록시 설정을 따르지만, 일부 게임과 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 이 설정을 읽지 않습니다. 브라우저는 프록시를 사용하더라도 다른 프로그램은 직접 연결할 수 있습니다. TUN은 앱이 HTTP 프록시를 지원하지 않아도 트래픽을 처리할 수 있지만, 적용 범위는 라우팅, 제외 설정, 권한 및 프로토콜 지원에 따라 달라집니다.

비교 항목	시스템 프록시	TUN 모드
연결 방식	앱이 로컬 프록시 포트에 연결	시스템 라우팅이 IP 패킷을 가상 네트워크 인터페이스로 전달
일반적인 진입점	예: 로컬 혼합 포트 7890	TUN 인터페이스와 해당 라우팅 사용, 앱에서 프록시 포트를 입력할 필요 없음
UDP 트래픽	일반적으로 시스템 HTTP 프록시로는 처리할 수 없음	처리할 수 있지만 출구 노드도 UDP를 지원해야 함
필요한 권한	대개 사용자 프록시 설정만 변경	데스크톱은 해당 시스템 권한 필요, Android는 VPN 권한 필요
주요 영향	설정을 따르지 않는 앱은 프록시 우회	다른 VPN, 가상 네트워크 인터페이스 또는 라우팅 규칙과 충돌할 수 있음

가상 네트워크 인터페이스, 라우팅, 출구 연결의 흐름

웹사이트에 접속하는 TCP 연결을 예로 들어 보겠습니다. 앱이 먼저 대상 IP를 확인하면 운영체제가 라우팅 테이블을 조회합니다. 자동 라우팅이 활성화된 경우 처리 조건을 만족하는 패킷은 TUN 인터페이스로 전달됩니다. 코어는 대상 주소와 사용할 수 있는 도메인 정보를 확인하고 규칙을 순서대로 적용한 뒤, 직접 연결 또는 프록시 출구 연결을 설정합니다.

앱에서 패킷 전송: 앱은 일반 네트워크 연결을 그대로 사용하며 127.0.0.1:7890을 입력할 필요가 없습니다.
라우팅 경로 선택: 코어가 설정한 라우팅에 따라 어떤 주소를 가상 네트워크 인터페이스로 보낼지 결정합니다. 물리 인터페이스, LAN 라우팅, 제외 규칙도 판단에 영향을 줍니다.
프로토콜 처리: TUN 프로토콜 스택이 수신한 IP 트래픽을 처리한 뒤 규칙 및 출구 모듈로 전달합니다.
출구 선택: 적용된 정책은 DIRECT, 차단 정책 또는 특정 프록시 그룹일 수 있으며, 항상 같은 노드를 사용하는 것은 아닙니다.
응답 전달: 코어는 응답을 앱으로 돌려보내는 한편, 프록시 서버 연결은 실제 네트워크 출구를 통해 전송되도록 해 TUN으로 다시 들어가는 루프를 방지합니다.

따라서 ‘TUN이 켜짐’은 트래픽 진입에 필요한 설정 일부가 적용됐다는 뜻일 뿐입니다. 노드 연결 실패, 잘못된 프록시 그룹 선택, DNS 시간 초과, 잘못된 출구 인터페이스 설정 등으로 앱에 오류가 계속 발생할 수 있습니다. 문제를 진단할 때는 가상 네트워크 인터페이스 생성 여부, 연결의 코어 진입 여부, 최종 출구 선택을 각각 확인해야 합니다. 스위치 색상만 보고 판단하지 마세요.

DNS 가로채기와 fake-ip: 도메인 규칙에 필요한 정보 유지

대부분의 앱은 도메인을 IP 주소로 변환한 다음 연결합니다. DNS 쿼리가 코어를 완전히 우회하면 코어에는 대상 IP만 보여 도메인 규칙을 바로 적용하기 어려울 수 있습니다. DNS를 코어에서 처리하면 내부 DNS 모듈로 쿼리를 전달하고, 캐시 매핑 등의 도메인 식별 방식과 함께 트래픽 분류에 필요한 정보를 얻을 수 있습니다.

포트 53 가로채기의 범위

mihomo의 TUN 설정에서 dns-hijack은 목적지 포트가 53인 DNS 트래픽을 가로채도록 지정할 수 있습니다. any:53은 보통 UDP DNS에, tcp://any:53은 TCP DNS에 사용됩니다. 모든 암호화 DNS를 가로채는 범용 설정은 아닙니다. 앱 자체 DoH는 보통 HTTPS 포트 443을 사용하고, DoT는 보통 포트 853을 사용하므로 포트 53을 설정해도 자동으로 코어의 DNS 쿼리로 전환되지 않습니다.

fake-ip는 실제 서버 주소가 아닙니다

fake-ip 모드는 조건에 맞는 도메인에 198.18.0.0/16 범위와 같은 예약 주소 대역의 매핑 주소를 반환합니다. 앱이 이 주소에 연결하면 코어가 매핑을 통해 도메인을 찾아 규칙을 적용하고 실제 출구 연결을 처리합니다. 이는 로컬 매핑 방식이며, 원격 웹사이트의 실제 주소가 해당 대역으로 바뀐다는 뜻은 아닙니다.

LAN 도메인: 라우터 관리 주소, 프린터, 사내 서비스는 실제 DNS 응답이 필요할 수 있습니다. 내부 DNS 설정과 함께 fake-ip-filter 또는 도메인별 DNS 정책을 사용하세요.
캐시 잔류: TUN을 끈 뒤에도 앱이 캐시에 남은 fake-ip 주소를 사용하면 일시적으로 연결되지 않을 수 있습니다. 해당 앱을 다시 시작하고 필요하면 시스템 DNS 캐시를 비우세요.
브라우저의 암호화 DNS: 문제를 진단할 때는 먼저 브라우저의 사용자 지정 보안 DNS를 잠시 끄고 DNS 경로를 통일하세요. 원인을 확인한 뒤 설정을 유지할지 결정하면 됩니다.
IPv6: IPv4 연결이 된다고 해서 IPv6도 처리된다는 뜻은 아닙니다. 코어, DNS, 라우팅, 노드가 모두 IPv6를 지원하는지 확인하세요.

mihomo 설정 예시: 코어를 확인한 뒤 필드 병합

아래 설정 조각은 해당 필드를 지원하는 mihomo 코어용입니다. Clash는 클라이언트 생태계에서 널리 쓰이는 이름이지만, 클라이언트마다 포함된 코어가 다릅니다. 원본 Clash도 빌드에 따라 동작이 달라 이 설정을 그대로 적용할 수는 없습니다. 먼저 클라이언트의 ‘정보’ 화면이나 실행 로그에서 코어 이름을 확인하고, 그래픽 설정이 해당 필드를 덮어쓰는지도 살펴보세요.

이 설정 조각은 DNS와 TUN만 보여 주며 노드, 프록시 그룹, 라우팅 규칙은 포함하지 않습니다. 완성된 구독 설정으로 바로 가져올 수 없습니다. 기존 설정의 해당 최상위 필드에 병합하고 dns: 또는 tun:이 중복되지 않도록 하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

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

필드	기능 및 확인 사항
`listen: 127.0.0.1:1053`	로컬 DNS 수신 주소입니다. 1053은 프록시 포트가 아니며 시스템이 자동으로 이 주소를 사용한다는 뜻도 아닙니다.
`stack: mixed`	지원되는 mihomo 빌드에서는 TCP와 UDP를 서로 다른 프로토콜 스택으로 처리하도록 함께 설정합니다. 호환성 문제가 있으면 현재 코어 문서를 참고해 다른 스택을 시험해 보세요.
`auto-route`	트래픽을 가져오는 라우팅을 자동으로 설정합니다. 끄면 보통 라우팅을 직접 관리해야 하므로, 처음 문제를 진단할 때 기본 조치로 권장하지 않습니다.
`auto-detect-interface`	출구 인터페이스를 자동으로 감지합니다. 활성 네트워크 어댑터가 여러 개라면 실제 출구를 확인해야 합니다.
`default-nameserver`	DNS 업스트림의 도메인을 확인하는 데 사용합니다. 예시의 업스트림은 현재 네트워크에서 연결 가능해야 하며, 예시 주소를 모든 네트워크에 공통으로 쓸 수 있는 정답으로 간주하면 안 됩니다.

Windows·macOS·Android에서 TUN 켜기

Windows: 서비스 또는 관리자 권한 설정부터 확인

먼저 TUN을 끈 상태에서 현재 구독으로 시스템 프록시를 통해 대상 사이트에 정상 접속되는지 확인하세요. 이 단계에서 실패하면 먼저 노드 또는 구독 문제를 해결해야 합니다.
클라이언트에서 서비스 모드, 서비스 설치 또는 권한 관련 설정을 찾으세요. 백그라운드 서비스를 지원하는 클라이언트는 보통 처음 한 번 관리자 권한 승인이 필요합니다. 다른 방식은 클라이언트를 관리자 권한으로 실행해야 할 수 있으므로 클라이언트 안내를 따르세요.
다른 VPN의 자동 연결을 끄고 클라이언트에서 ‘TUN 모드’를 켜세요. 로그에 인터페이스 생성, 라우팅 추가 또는 DNS 수신 오류가 있는지 확인합니다.
시스템 프록시를 잠시 끈 다음 일반 앱과 원래 시스템 프록시를 따르지 않던 앱을 테스트하세요. 시스템 프록시가 작동한 것을 TUN이 작동한 것으로 착각하지 않도록 합니다.

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 시스템 프록시 설정을 확인할 수 있습니다. 문제를 진단할 때 route print로 라우팅을, PowerShell의 Get-NetAdapter로 네트워크 어댑터를 확인하세요. 가상 네트워크 인터페이스 이름은 클라이언트마다 다르므로 특정 이름 하나만으로 성공 여부를 판단하면 안 됩니다.

macOS: 보조 서비스 권한과 네트워크 출구 확인

클라이언트와 코어가 TUN을 지원하는지 확인하세요. 안내에 따라 필요한 특권 보조 서비스를 설치하거나 권한을 허용합니다. 시스템 프록시 스위치를 TUN 스위치로 혼동하지 마세요.
TUN을 켠 뒤 클라이언트 로그와 시스템 라우팅을 확인하세요. 터미널에서 ifconfig로 인터페이스를, netstat -rn으로 라우팅을 확인할 수 있습니다.
Wi-Fi, 유선 네트워크 또는 모바일 핫스팟으로 전환한 다음 다시 테스트하세요. 이전 출구가 계속 선택되면 먼저 코어를 재시작하거나 TUN을 다시 켜고 인터페이스 감지 결과를 확인하세요.

시스템 프록시는 보통 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 찾을 수 있습니다. 시스템에 utun 인터페이스가 나타났다고 해서 현재 클라이언트가 만든 것이라고 단정할 수는 없습니다. 다른 네트워크 서비스도 같은 종류의 인터페이스를 만들 수 있으므로 활성화 시각과 로그를 함께 확인하세요.

Android: VPN 권한이 트래픽 진입 경로입니다

Android 클라이언트는 보통 시스템 VpnService로 가상 네트워크 인터페이스를 만듭니다. 처음 연결할 때 시스템 VPN 권한 요청이 표시되며, 권한이 없으면 해당 트래픽 경로를 만들 수 없습니다. 이는 클라이언트에 root 권한을 부여하는 것도, 구독 연결이 성공했다는 뜻도 아닙니다.

구독을 가져오고 사용 가능한 정책을 선택한 다음 클라이언트의 연결 버튼을 누르고 시스템 VPN 권한을 허용하세요.
앱별 라우팅 또는 우회 목록에서 대상 앱이 제외되지 않았는지 확인하세요. 일부 클라이언트는 ‘선택한 앱만 프록시’와 ‘선택한 앱 우회’를 구분합니다.
시스템 설정에서 항상 켜진 VPN과 ‘VPN 없이 연결 차단’과 같은 옵션을 확인하세요. 제조사마다 명칭이 다르며, 이런 설정이 다른 클라이언트의 연결을 막을 수 있습니다.
화면을 끈 뒤 연결이 끊긴다면 백그라운드 실행 및 배터리 최적화 제한을 확인하세요. 시스템이 프로세스를 중지하는 문제를 DNS를 반복해서 바꾸며 감추지 마세요.

일반적으로 같은 Android 사용자 계정 또는 업무 프로필에서는 VPN 서비스를 하나만 활성화할 수 있습니다. VPN 인터페이스를 사용하는 방화벽, 필터링 도구, 프록시 클라이언트는 서로의 연결을 대체할 수 있습니다. 데스크톱용 YAML의 TUN 필드가 Android 클라이언트에서 유효한 설정 경로라는 보장도 없으므로 클라이언트 설정을 우선 사용하세요.

TUN을 켠 뒤 인터넷에 연결되지 않을 때: 단계별 점검

한 번에 하나씩 변경하고, 변경 전 설정을 보관하세요. 모든 앱이 실패하는지, 특정 도메인만 실패하는지, UDP 기능만 실패하는지 먼저 구분해야 합니다. 각 증상에 따라 점검할 부분이 다릅니다.

증상	우선 확인할 항목	구체적인 조치
스위치가 바로 꺼지거나 인터페이스 생성 실패	권한, 서비스 상태, 인터페이스 충돌	첫 오류 로그를 확인하고 서비스가 시작됐는지 살펴보세요. 다른 VPN을 잠시 끈 뒤 다시 시도합니다.
도메인 접속 실패	DNS 업스트림 및 DNS 가로채기 경로	DNS 시간 초과 로그를 확인하세요. `nslookup example.com`으로 시스템 조회 결과를 살펴볼 수 있지만, 이것만으로 브라우저의 DNS 경로를 입증할 수는 없습니다.
웹은 되지만 음성 채팅이나 게임이 안 됨	UDP 출구 지원, 규칙, MTU	노드 프로토콜과 서버가 UDP를 지원하는지 확인하세요. 먼저 연결 기록을 살펴본 다음 현재 코어 문서에 따라 MTU를 조정합니다.
프린터, NAS 또는 내부 도메인에 연결할 수 없음	LAN 라우팅 및 내부 DNS	실제 네트워크 대역, 직접 연결 규칙, TUN 라우팅 제외 항목을 확인해 내부 네트워크 전체가 원격 노드로 전송되지 않도록 하세요.
연결은 되지만 출구가 잘못됨	모드, 적용 규칙, 프록시 그룹	연결 기록에서 적용된 규칙과 전체 정책 경로를 확인하세요. `DIRECT` 또는 잘못된 기본 정책이 적용됐는지 살펴봅니다.
TUN을 꺼도 인터넷이 안 됨	남아 있는 프록시 설정, DNS 캐시, 라우팅	클라이언트를 종료한 뒤 시스템 프록시를 확인하고, 영향을 받은 앱을 재시작한 다음 라우팅이 복구됐는지 확인하세요.

LAN 제외와 DIRECT는 서로 다른 계층의 설정입니다

규칙에서 내부 주소에 DIRECT를 지정하면 연결이 코어에 들어온 뒤 직접 연결을 선택합니다. 반면 TUN 라우팅 계층에서 대역을 제외하면 트래픽이 아예 코어에 들어오지 않을 수 있습니다. 두 설정은 용도가 다릅니다. 회사 VPN을 사용하는 경우에는 사내 네트워크 대역과 DNS 설정 전달 방식을 먼저 확인하세요. 모든 사설 주소를 제외하는 목록을 그대로 복사하지 않는 것이 좋습니다.

MTU와 이중 VPN 충돌은 나중에 확인하세요

일부 대용량 응답이나 업로드, 특정 UDP 세션만 멈출 때 경로 MTU를 추가로 확인하면 됩니다. MTU를 무조건 낮춰도 DNS 연결 불가나 노드 장애는 해결되지 않습니다. 두 VPN이 동시에 기본 라우팅을 변경하면 루프가 생기거나 출구가 바뀔 수 있습니다. 먼저 각각 단독으로 정상 작동하는지 확인한 다음 고급 라우팅 조합을 검토하세요.

TUN 활성화 후 점검 목록 및 되돌리기

진입 경로 확인: 시스템 프록시를 끄고 TUN은 켠 상태에서 대상 앱을 테스트한 뒤, 연결 기록에 해당 연결이 나타나는지 확인하세요.
라우팅 규칙 확인: 직접 연결되어야 하는 대상과 프록시를 사용해야 하는 대상에 각각 접속하고, 기록에서 적용 규칙과 정책 경로를 확인하세요. 출구 IP 조회는 참고용일 뿐 모든 앱의 트래픽이 처리된다는 증거는 아닙니다.
DNS 확인: 도메인 조회가 성공하는지, fake-ip 또는 실제 주소 중 예상한 방식으로 응답하는지, 내부 도메인에 정상 접속할 수 있는지 확인하세요.
필요한 기능 확인: 음성 채팅, 게임 또는 필요한 UDP 기능을 직접 테스트하세요. ping은 ICMP를 사용하므로 결과만으로 TCP·UDP 프록시 경로의 정상 여부를 판단할 수 없습니다.
복구 상태 확인: TUN을 끄고 일반 네트워크 연결이 복구됐는지 확인하세요. Windows에서는 필요에 따라 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비우고, 이전 주소를 사용 중인 앱도 다시 시작하세요.

브라우저와 시스템 프록시를 따르는 앱만 프록시를 사용하면 된다면 시스템 프록시가 설정을 확인하고 관리하기 더 쉽습니다. 프록시 설정을 읽지 않는 프로그램까지 처리하거나 UDP를 통합 관리해야 한다면 TUN을 켜고, 검증된 복구 설정을 따로 보관하세요. 안정적인 설정은 스위치가 많은 것이 아니라 진입 경로, DNS, 규칙, 출구를 모두 설명할 수 있는 설정입니다.