2026년 10월 14일 고급 설정 예상 읽는 시간 12분

Clash TUN 모드 설정 방법과 원리: 전체 트래픽을 커널로 전달

가상 네트워크 인터페이스가 트래픽을 처리하는 원리와 시스템 프록시의 차이를 알아보고, 플랫폼별 TUN 설정과 Fake-IP, auto-route 구성 방법을 확인하세요.

TUN이 트래픽을 처리해도 모든 연결이 프록시를 거치는 것은 아닙니다

Clash TUN 모드는 시스템에 가상 3계층 네트워크 인터페이스를 만들고, 라우팅을 통해 조건에 맞는 IP 패킷을 커널로 전달합니다. 커널은 대상 주소와 포트, 확인 가능한 도메인 정보를 읽은 뒤 규칙에 따라 DIRECT, 프록시 노드 또는 다른 정책을 선택합니다. 브라우저뿐 아니라 시스템 프록시 설정을 따르지 않는 명령줄 도구, 게임, 일부 데스크톱 앱도 같은 규칙 처리 경로를 이용할 수 있습니다.

제목의 ‘전체 트래픽’은 처리 범위를 뜻하며, 클라이언트의 Global 모드를 의미하지 않습니다. TUN을 켜도 Rule 모드를 사용할 수 있습니다. LAN 연결은 직접 연결하고, 지정 도메인은 프록시로 보내며, 나머지 연결은 마지막 MATCH 규칙으로 처리할 수 있습니다. 라우팅 제외 항목, 앱 자체 VPN, 다른 네트워크 네임스페이스, 일부 시스템 트래픽은 처리 범위에 포함되지 않을 수 있습니다.

시스템 프록시와 TUN의 처리 범위 비교

비교 항목	시스템 프록시	TUN
트래픽 유입 방식	앱이 HTTP 또는 SOCKS 프록시 포트에 직접 연결	시스템 라우팅이 IP 패킷을 가상 네트워크 인터페이스로 전달
앱 지원 여부	앱이 설정을 읽거나 프록시를 직접 구성해야 함	대체로 앱의 프록시 프로토콜 지원이 필요하지 않음
UDP 트래픽	일반적인 시스템 HTTP 프록시 설정으로는 처리할 수 없음	처리할 수 있지만 프록시 노드와 프로토콜도 UDP를 지원해야 함
권한 요구 사항	대개 사용자 프록시 설정만 변경하면 됨	네트워크 인터페이스 생성, 라우팅 설정 또는 시스템 VPN 인터페이스 호출 필요
DNS 경로	앱이나 시스템이 자체적으로 DNS를 조회할 수 있음	DNS 리디렉션과 커널 DNS를 함께 사용할 수 있지만 별도 검증 필요

TUN은 네트워크 속도를 높이는 기능이 아닙니다. 노드 혼잡, UDP 연결 불가, 잘못된 규칙 매칭은 가상 네트워크 인터페이스로 바꾼다고 해결되지 않습니다. 먼저 일반 프록시로 같은 노드에 연결되는지 확인한 다음 처리 범위를 넓히면 노드 문제와 로컬 라우팅 문제를 구분하기 쉽습니다.

시작 전 확인: 커널, 권한, 설정 파일 출처

아래 YAML은 해당 필드를 지원하는 mihomo용이며, mihomo는 Clash Meta 이후 사용되는 커널 이름입니다. 구형 Clash 커널, 모바일 앱 래퍼, GUI 클라이언트는 설정 지원 범위가 서로 다를 수 있습니다. 클라이언트 이름에 Clash가 들어간다고 해서 모든 설정을 그대로 사용할 수 있는 것은 아닙니다.

현재 커널 버전을 확인하세요.클라이언트의 ‘정보’ 또는 ‘커널’ 화면에서 버전 문자열을 기록해 두세요. unknown field, unsupported stack 같은 오류가 발생하면 노드를 계속 바꾸기 전에 해당 버전에서 지원하는 필드인지 확인하세요.
현재 설정을 백업하세요.사용 중인 설정 파일과 Rule 모드, DNS, TUN 설정 화면을 보관하세요. 이전 상태로 되돌려야 한다면 먼저 TUN을 끈 뒤 원래 설정을 복원하세요.
설정 변경 위치를 확인하세요.구독 설정은 업데이트할 때 덮어쓰일 수 있습니다. 클라이언트에서 제공하는 오버라이드, 설정 병합 또는 TUN 설정 패널을 우선 사용하세요. 구독 캐시 파일을 직접 수정하면 임시로만 적용되는 경우가 많습니다.
다른 VPN은 잠시 종료하세요.먼저 트래픽이 하나의 경로로만 처리되도록 설정하세요. 기업용 VPN, 게임 가속기, 다른 TUN 클라이언트가 동시에 기본 경로를 바꾸면 문제 원인을 파악하기 어렵습니다.

첫 테스트에서는 시스템 프록시를 끄고 TUN만 켜면, 브라우저가 이전 프록시 포트로 연결되는 변수를 줄일 수 있습니다. 이는 트래픽 처리 여부를 확인하기 위한 것으로, 시스템 프록시와 TUN을 반드시 동시에 사용할 수 없다는 뜻은 아닙니다. 테스트가 끝난 뒤 클라이언트 권장 사항에 따라 함께 켤지 결정하세요.

mihomo 설정: TUN, Fake-IP, auto-route

아래는 기존 설정에 병합하는 최상위 설정 예시이며, 전체 구독 설정이 아닙니다. 기존 proxies, proxy-groups, rules는 유지하세요. 기존 파일에 dns 또는 tun이 있다면 해당 항목에 내용을 병합하고 같은 이름의 최상위 키를 중복으로 만들지 마세요. 예시의 mixed-port는 7890, DNS 수신 주소는 127.0.0.1:1053이며 용도가 서로 다릅니다.

mixed-port: 7890
mode: rule

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

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

각 필드의 역할

stack: mixed: 이 값을 지원하는 mihomo에서는 시스템 네트워크 스택과 사용자 공간 네트워크 스택을 함께 사용합니다. 현재 클라이언트가 지원하지 않으면 해당 커널 문서를 확인해 system 또는 gvisor를 선택하세요. 스택을 바꾸는 것이 모든 문제의 해결책은 아닙니다.
auto-route: true: 커널이 트래픽을 TUN으로 보내는 데 필요한 경로를 자동으로 설정합니다. 관리자 권한을 대신하지 않으며 외부 VPN 경로까지 모두 처리한다고 보장하지도 않습니다.
auto-detect-interface: true: 실제 외부 연결에 사용할 인터페이스를 찾아 프록시 트래픽이 다시 TUN으로 들어가는 일을 방지합니다. 네트워크 어댑터가 여러 개이거나 핫스팟, 기업 VPN을 사용하는 환경에서는 감지 결과를 확인해야 합니다.
dns-hijack: TUN으로 들어와 대상에 해당하는 일반 53번 포트 DNS 요청을 커널 DNS로 전달합니다. 예시에는 UDP와 TCP의 53번 포트 요청이 모두 포함되어 있습니다.
enhanced-mode: fake-ip: 가상 주소를 반환하고 커널에 도메인 매핑을 저장합니다. 해당 주소로 연결하면 커널이 도메인을 확인해 트래픽을 분기할 수 있습니다.

198.18.0.1/16은 벤치마크용 주소 대역이며 실제 웹사이트의 IP 주소가 아닙니다. 조회 결과에 이런 주소가 표시되는 것은 Fake-IP의 정상적인 동작입니다. 사용 중인 네트워크도 이 대역을 쓴다면 주소 충돌을 먼저 확인하세요. 가상 주소를 일반 공인 IP처럼 고정 직결 경로에 추가하면 안 됩니다.

Fake-IP 필터와 암호화 DNS의 범위

fake-ip-filter에 지정한 도메인은 실제 주소로 응답하지만, 해당 연결이 자동으로 DIRECT 처리되는 것은 아닙니다. LAN 서비스는 규칙에서 올바르게 분기해야 합니다. 예시의 *.local도 mDNS 멀티캐스트 검색을 대체하지 않습니다. 프린터나 화면 공유 장치를 찾을 수 없다면 로컬 네트워크 권한과 멀티캐스트 경로도 확인하세요.

브라우저에 내장된 DoH는 보통 443번 포트, DoT는 주로 853번 포트를 사용하므로 위의 53번 포트 리디렉션으로는 직접 처리되지 않습니다. 진단할 때는 브라우저의 ‘보안 DNS’와 Android의 ‘비공개 DNS’를 잠시 끄고 시스템 DNS 경로를 먼저 테스트한 다음, 장기적으로 사용할 DNS 방식을 결정하세요.

플랫폼별 TUN 설정 순서

Windows: 서비스 설치 후 가상 네트워크 인터페이스 켜기

설정을 가져오고 Rule 모드를 선택한 뒤, 먼저 시스템 프록시로 노드 연결을 확인하세요.
클라이언트 설정에서 ‘서비스 모드’를 찾으세요. 서비스 설치 버튼이 있으면 안내에 따라 관리자 권한을 승인하세요. 서비스 모드를 지원하지 않는 클라이언트는 관리자 권한으로 실행해야 할 수 있습니다.
‘TUN 모드’ 또는 ‘가상 네트워크 인터페이스’ 스위치를 켜세요. 메뉴 이름은 클라이언트마다 다릅니다. ‘시스템 프록시’ 스위치를 TUN으로 착각하지 마세요.
로그에서 가상 네트워크 인터페이스 생성과 라우팅 설정이 성공했는지 확인한 다음, 시스템 프록시를 끄고 단독으로 테스트하세요.

route print 명령으로 라우팅을 확인할 수 있습니다. 인터페이스 이름과 경로 접두사는 커널 및 시스템 버전에 따라 달라지므로 특정 이름이 표시되어야 한다고 고집할 필요는 없습니다. 로그에 access denied 또는 operation not permitted가 표시되면 DNS 주소를 바꾸지 말고 권한이나 서비스 상태부터 해결하세요.

macOS: 보조 서비스와 라우팅 권한 확인

TUN을 지원하는 클라이언트에서 필요한 보조 서비스를 설치한 다음 TUN을 켜세요. 시스템에서 네트워크 확장 또는 백그라운드 서비스 권한을 요청하면 앱 이름을 확인한 뒤 승인하세요. 클라이언트마다 권한 부여 방식은 다를 수 있습니다. Wi-Fi, 이더넷, 핫스팟을 전환한 뒤에는 외부 연결 인터페이스가 올바른지 다시 확인하세요.

터미널에서 netstat -rn으로 라우팅을, scutil --dns로 시스템 리졸버를 확인할 수 있습니다. 시스템에 utun 인터페이스가 여러 개 있을 수 있으므로 utun이 보인다는 사실만으로 Clash의 트래픽 처리가 성공했다고 판단할 수 없습니다. 클라이언트의 연결 기록도 함께 확인하세요.

Linux: 네트워크 인터페이스 장치와 네트워크 관리 권한 구분

/dev/net/tun이 있는지 확인하세요. 라우팅을 자동으로 설정하려면 보통 네트워크 관리 권한이 필요하며, 관리되는 서비스에 CAP_NET_ADMIN을 부여하는 방식 등을 사용할 수 있습니다. 실행을 위해 데스크톱 클라이언트 전체에 불필요한 고권한을 계속 부여하지 마세요. 컨테이너에서는 TUN 장치와 관련 권한도 명시적으로 열어야 합니다. 호스트에서 사용할 수 있다고 컨테이너 안에서도 사용 가능한 것은 아닙니다.

ip rule, ip route show table all, resolvectl status 명령으로 각각 정책 라우팅, 전체 라우팅 테이블, DNS 확인 상태를 점검하세요. 기본 라우팅 테이블만 보면 커널이 만든 정책 라우팅을 놓칠 수 있습니다.

Android 및 iOS: 시스템 VPN 권한 사용

Android에서 이 기능을 지원하는 클라이언트는 보통 VpnService로 트래픽을 처리합니다. 연결을 누른 뒤 시스템 VPN 요청을 승인하고, ‘앱별 프록시’에서 테스트할 앱이 제외되어 있지 않은지 확인하세요. 배터리 백그라운드 제한으로 화면을 잠근 뒤 연결이 끊길 수 있습니다. VPN 항상 사용과 ‘VPN 없이 연결 차단’은 별도의 시스템 정책이므로 기본 연결이 안정된 후에 켜세요.

iOS 및 iPadOS에서는 해당 설정 형식을 지원하는 클라이언트를 선택하고, 시스템 VPN 설정 권한을 승인해 네트워크 확장을 시작하세요. 데스크톱의 드라이버 설치나 관리자 권한 획득 절차를 그대로 적용할 수는 없습니다. 모바일 앱은 라우팅과 DNS를 자체 관리하거나 데스크톱의 tun 필드를 무시할 수 있으므로, 지원하는 설정 범위를 확인하세요. 시스템 VPN에 연결되더라도 구독 설정의 모든 규칙이 호환되는 것은 아닙니다.

트래픽 처리 확인: 유입, DNS, 출구를 각각 테스트

웹페이지 하나가 열린다고 해서 TUN, DNS, 규칙이 모두 예상대로 작동한다고 볼 수는 없습니다. 아래 순서대로 테스트하고, 매번 조건을 하나씩만 바꾸면서 앱, 대상 도메인, 적용된 규칙, 실제 출구를 기록하세요.

프록시 옵션을 사용하지 않는 앱을 테스트하세요.시스템 프록시를 끄고 터미널의 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 등 환경 변수도 지운 다음 아래 명령을 실행하세요. 연결 기록에 해당 연결이 표시되어야 합니다.
커널 DNS를 테스트하세요.로컬 1053 포트에 질의해 응답을 확인하세요. 필터에 지정되지 않은 일반 도메인은 Fake-IP 모드에서 대개 198.18 대역 주소로 응답합니다.
시스템 DNS를 테스트하세요.시스템 기본 DNS 조회를 직접 실행하고 로그에서 커널을 거치는지 확인하세요. 1053 포트에 직접 질의해 성공하더라도 DNS 리스너가 작동한다는 뜻일 뿐, 시스템 요청이 리디렉션된다는 뜻은 아닙니다.
규칙에 따른 출구를 확인하세요.직접 연결되어야 하는 대상과 프록시를 거쳐야 하는 대상에 각각 접속하고, 연결 기록의 규칙과 정책 그룹을 확인하세요. 커널로 들어갔다는 사실을 프록시 노드를 사용했다는 뜻으로 혼동하지 마세요.

# Windows PowerShell: 현재 세션에 프록시 환경 변수가 없는지 먼저 확인
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
curl.exe --noproxy "*" -I https://example.com
nslookup example.com

# macOS / Linux: curl의 --noproxy는 명시적 프록시를 우회하지만 TUN은 우회하지 않습니다
curl --noproxy '*' -I https://example.com
dig @127.0.0.1 -p 1053 example.com A
nslookup example.com

도구가 설치되어 있지 않다면 명령 실행을 위해 시스템을 변경할 필요는 없습니다. 클라이언트의 DNS 조회 기능을 대신 사용하세요. UDP를 테스트할 때는 UDP 지원을 확인한 노드와 앱 환경을 선택하세요. 일반 HTTPS 웹페이지가 열린다고 게임 UDP나 QUIC도 사용할 수 있다는 뜻은 아닙니다.

자주 발생하는 문제: 권한, 라우팅, DNS 순으로 점검

증상	우선 확인할 항목	해결 방법
켜자마자 인터넷 연결이 끊김	서비스 권한, 외부 연결 인터페이스, 다른 VPN	먼저 TUN을 꺼서 네트워크를 복구한 뒤 시작 로그와 라우팅 오류를 확인하세요.
IP 주소로는 연결되지만 도메인 접속은 실패	DNS 업스트림 연결 가능 여부, 53번 포트 처리	로컬 1053 포트와 시스템 DNS를 각각 테스트해 실패 지점을 찾으세요.
브라우저는 되지만 게임은 연결되지 않음	UDP 지원 여부, 앱별 제외 설정, 적용된 규칙	연결 기록을 확인한 뒤 노드의 UDP 지원 여부를 테스트하세요.
LAN 장치에 접속할 수 없음	사설 네트워크 경로, DIRECT 규칙, 주소 충돌	먼저 실제 LAN 대역을 직접 연결하도록 설정한 뒤 라우팅 제외가 필요한지 확인하세요.
절전 모드 또는 네트워크 전환 후 작동하지 않음	기본 인터페이스 변경 여부, 백그라운드 서비스 상태	TUN에 다시 연결하고 인터페이스 감지 및 DNS 상태를 확인하세요.

strict-route를 처음부터 무작정 추가하지 마세요

일부 mihomo 설정은 strict-route를 지원하며 라우팅 제약을 강화합니다. 플랫폼에 따라 DNS 경로에도 영향을 줄 수 있고 LAN, 가상 머신 또는 다른 VPN에 대한 연결 가능성을 바꿀 수 있습니다. 먼저 최소 설정으로 동작을 확인한 뒤 현재 커널 문서와 필요에 맞춰 추가하세요. ‘프록시를 더 확실하게 만드는’ 범용 옵션으로 이해하면 안 됩니다.

종료 후에도 인터넷이 안 될 때 복구하는 방법

먼저 클라이언트에서 TUN을 꺼 커널이 라우팅을 정상적으로 제거하도록 한 다음 클라이언트를 종료하세요. 시스템 프록시가 더 이상 수신하지 않는 127.0.0.1:7890을 가리키고 있는지, DNS에 수동 설정이 남아 있는지도 확인하세요. 그런 다음 네트워크에 다시 연결하고, 필요하면 클라이언트의 서비스 복구 기능을 사용하세요. 기업 장치에서는 업무용 네트워크 설정까지 삭제될 수 있으므로 라우팅 테이블 전체를 직접 지우지 마세요.