Clash TUN 모드 설정 방법: 가상 네트워크 인터페이스로 트래픽을 처리하는 원리와 OS별 설정

TUN과 시스템 프록시: 트래픽을 받는 지점의 차이

Clash TUN 모드는 가상 네트워크 인터페이스로 IP 패킷을 받아 커널에서 해석하고 규칙을 적용한 뒤 아웃바운드 연결을 만듭니다. 시스템 프록시는 앱에 HTTP 또는 SOCKS 프록시 연결 지점을 제공하므로 앱이 프록시 설정을 따라야 합니다. 브라우저는 연결되는데 명령줄 도구, 게임 또는 일부 데스크톱 앱은 프록시를 사용하지 않는다면 노드가 아니라 트래픽을 받는 방식에 문제가 있을 수 있습니다.

이 문서의 설정은 Clash Meta를 계승해 발전한 mihomo 커널을 기준으로 합니다. 이름에 Clash가 들어간 클라이언트라도 같은 커널을 사용한다고 볼 수 없으며, 구버전 Clash와 Premium, mihomo의 설정 기능도 서로 동일하지 않습니다. 시작하기 전에 클라이언트의 커널 정보나 시작 로그에서 mihomo가 실행 중인지 확인하고, 현재 커널이 지원하는 설정 항목을 기준으로 적용하세요.

비교 항목	시스템 프록시	TUN 모드
트래픽 처리 지점	앱의 프록시 인터페이스	시스템 라우팅 및 가상 네트워크 인터페이스
앱에서 필요한 설정	시스템 프록시를 따르거나 별도로 설정해야 함	해당 라우팅 경로를 지나는 트래픽을 처리할 수 있음
UDP 트래픽	일반적인 HTTP 시스템 프록시로는 일괄 처리할 수 없음	처리 가능. 단, 프록시 아웃바운드에서 UDP를 지원해야 함
필요한 권한	일반적으로 네트워크 인터페이스 생성 권한은 필요하지 않음	일반적으로 관리자 권한, 특권 서비스 또는 네트워크 권한이 필요함
트래픽 분기 기준	커널 규칙으로 결정	커널 규칙으로 결정

시작 전 확인: 노드, 권한, 설정 유지 방식

기본 연결을 확인합니다. 먼저 시스템 프록시로 접속 가능한 사이트를 열어 구독을 가져왔고 정책 그룹에 사용할 수 있는 노드가 있는지 확인하세요. TUN으로 만료된 구독, 노드 인증 실패 또는 서버 오프라인 문제를 해결할 수는 없습니다.
적용 중인 설정을 백업합니다. 현재 모드, DNS 설정, 기존 라우팅을 기록해 두세요. 클라이언트가 구독 내용으로 실행 설정을 생성하는 경우, 생성된 파일을 직접 수정하면 업데이트 후 변경 사항이 사라질 수 있습니다. 클라이언트에서 제공하는 오버라이드, 병합 또는 영구 설정 기능을 사용하세요.
다른 트래픽 처리 도구를 잠시 중지합니다. 기본 경로, DNS, 방화벽 규칙이 충돌하지 않도록 다른 VPN, 가속기, 가상 네트워크 프록시를 먼저 종료하세요. 문제 해결 후 하나씩 다시 켜면 됩니다.
로컬에서 조작할 수 있는 방법을 확보합니다. 라우팅 변경으로 원격 데스크톱이나 SSH 연결이 끊길 수 있습니다. 처음 켤 때는 기기 앞에서 직접 조작하고, 유일한 원격 연결에서 라우팅을 바로 변경하지 마세요.

메뉴 이름은 클라이언트마다 다릅니다. 실제로 특권 서비스가 작동하는지, TUN 스위치가 켜져 있는지, 실행 설정에 올바른 tun 항목이 있는지 확인하세요. 화면에서 스위치가 켜진 것만으로 가상 네트워크 인터페이스가 만들어졌다고 단정할 수 없습니다.

mihomo TUN 설정: stack, 라우팅, DNS

다음은 기존 mihomo 설정에 병합해 사용할 수 있는 예시이며, 노드와 정책 그룹까지 포함한 전체 구독 설정은 아닙니다. 기존 프록시와 규칙은 유지하고 트래픽 처리 지점과 DNS 설정만 보여 줍니다. 최상위에 dns 또는 tun 항목이 이미 있다면 필드를 병합하고 같은 키를 중복 선언하지 마세요.

mode: rule

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

stack: 먼저 mixed를 사용하고 문제가 있으면 전환

mihomo는 system, gvisor, mixed 등의 TUN 프로토콜 스택을 제공합니다. mixed는 TCP에 system 스택, UDP에 gVisor 스택을 사용하므로 시작 설정으로 적합합니다. 호환성은 OS와 커널 빌드에 따라 달라질 수 있습니다. 연결 문제가 생기면 한 번에 스택 하나만 바꾸고 같은 대상에 다시 연결해 보세요. 노드, DNS, 라우팅을 동시에 변경하지 마세요.

스택을 바꿔도 노드의 전송 기능은 달라지지 않습니다. 로컬에서 UDP 트래픽을 처리하더라도 선택한 프록시 프로토콜이나 서버가 UDP 포워딩을 지원하지 않으면 게임 음성 채팅이나 QUIC 연결이 실패할 수 있습니다. 이 경우 가상 네트워크 인터페이스를 반복해서 설치하지 말고 아웃바운드 지원 여부를 확인하세요.

auto-route: 라우팅을 설정하는 기능이지 트래픽 분기 규칙을 바꾸는 기능은 아닙니다

auto-route: true를 설정하면 커널이 TUN으로 향하는 라우팅을 자동으로 구성합니다. auto-detect-interface: true는 아웃바운드 네트워크 인터페이스를 자동으로 찾아 프록시 서버 연결이 다시 TUN으로 들어오는 루프를 방지합니다. 유선·무선 네트워크와 가상 네트워크 인터페이스를 함께 사용하는 기기에서는 기존 라우팅의 영향으로 인터페이스를 잘못 감지할 수 있습니다. 아웃바운드 인터페이스를 직접 지정해야 한다면 실제 인터페이스 이름을 확인한 뒤 현재 커널에서 지원하는 설정 방식으로 지정하세요.

dns-hijack: 일반 DNS를 받아 처리하며 암호화 DNS까지 차단하는 것은 아닙니다

any:53은 TUN으로 들어오는 UDP 53번 포트 요청과 일치하고, tcp://any:53은 TCP 53번 포트에 해당합니다. 일치하는 트래픽은 커널 DNS로 전달되지만 브라우저에 내장된 DoH나 앱 자체 DoT가 일반 DNS로 자동 변환되지는 않습니다. 테스트 중에는 브라우저의 ‘보안 DNS’를 잠시 끄고 시스템 DNS 경로부터 확인하세요.

예시의 127.0.0.1:1053은 로컬 DNS 수신 주소입니다. 시스템 프록시 포트가 아니며 네트워크 인터페이스의 DNS 주소에 포트까지 입력할 필요도 없습니다. TUN 가로채기와 로컬 수신은 서로 다른 진입점입니다. fake-ip는 커널이 매핑에 사용할 가상 주소를 반환하므로, 198.18.0.0/16 범위의 조회 결과가 보인다고 해서 곧바로 오류라고 볼 수는 없습니다.

Windows: 서비스 권한부터 확인하고 가상 네트워크 인터페이스 점검

다른 VPN을 종료합니다. ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 기존 수동 프록시 설정을 기록해 두면 테스트 중 두 가지 트래픽 처리 방식을 혼동하지 않을 수 있습니다.
클라이언트에서 제공하는 서비스 모드를 설치하거나 켜고, Windows 사용자 계정 컨트롤 안내에 따라 권한을 허용하세요. 서비스 모드가 없다면 클라이언트 안내에 따라 관리자 권한으로 잠시 실행해 권한 문제인지 확인할 수 있습니다.
TUN을 켜고 규칙 모드를 유지한 채 로그에서 인터페이스 생성이나 라우팅 설정 실패 메시지가 있는지 확인하세요. 출처가 불분명한 곳에서 네트워크 드라이버를 따로 내려받아 클라이언트 구성 요소를 교체하지 마세요.
클라이언트에서 시스템 프록시를 끈 다음 아래 명령으로 인터페이스와 라우팅을 확인하고 실제 네트워크 연결을 테스트하세요. 테스트가 끝나면 필요에 따라 시스템 프록시를 다시 켜세요.

Get-NetAdapter -IncludeHidden |
  Format-Table Name, InterfaceDescription, Status

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

Resolve-DnsName example.com
curl.exe --noproxy "*" -I https://example.com

위 명령은 PowerShell에서 실행합니다. --noproxy "*"는 curl이 앱 수준 프록시 설정을 무시하게 하지만 시스템 라우팅을 우회하지는 않으므로 TUN 점검에 참고할 수 있습니다. 네트워크 인터페이스 이름은 클라이언트 설정에 따라 달라지므로 특정 이름이 나타나는지만으로 판단하지 마세요. 커널 연결 기록에 이번 요청이 표시되는지도 함께 확인하세요.

로그에 액세스 거부가 표시되면 먼저 서비스 권한을 확인하세요. 인터페이스는 있지만 요청이 커널로 들어오지 않는다면 라우팅, 다른 VPN, 보안 소프트웨어의 차단 기록을 살펴보세요. 방화벽 전체를 끄는 것은 장기적인 해결책이 아닙니다.

macOS: 보조 서비스 권한을 허용하고 utun 인터페이스 확인

macOS에서 TUN 인터페이스를 만들고 라우팅을 조정하려면 적절한 권한이 필요합니다. 데스크톱 클라이언트는 일반적으로 특권 보조 서비스를 사용합니다. 앱 안내에 따라 설치하거나 권한을 허용하고, 시스템 안내가 표시되면 ‘시스템 설정’ → ‘개인정보 보호 및 보안’에서 확인하세요. 배포 방식에 따라 권한 부여 방법이 다르므로 시스템에 특정 스위치가 없다는 이유만으로 설치 실패라고 판단하지 마세요.

먼저 일반 프록시 모드에서 노드를 확인한 다음 클라이언트가 제공하는 특권 보조 서비스와 TUN을 켭니다.
TUN만 따로 확인하려면 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’에서 HTTP, HTTPS, SOCKS 프록시 상태를 확인하세요.
터미널에서 인터페이스, 라우팅, DNS를 확인하고 커널 연결 기록에서 테스트 요청에 적용된 규칙과 아웃바운드를 확인하세요.

ifconfig
netstat -rn -f inet
scutil --dns
curl --noproxy '*' -I https://example.com

utun 인터페이스는 시스템 기능이나 다른 VPN에서도 만들 수 있으므로 인터페이스 개수만으로 Clash TUN 작동 여부를 판단할 수 없습니다. 켜기 전후의 라우팅 변경과 로그 시간을 비교하세요. macOS는 인터페이스와 도메인별로 DNS 해석기를 할당하므로 시스템 DNS 상태를 점검할 때는 /etc/resolv.conf만 확인하는 것보다 scutil --dns를 사용하는 편이 적절합니다.

Linux: /dev/net/tun과 서비스 실행 계정 확인

Linux에서는 TUN 장치를 사용할 수 있어야 하며 인터페이스 생성과 라우팅 변경에 필요한 권한도 있어야 합니다. 일반적으로 CAP_NET_ADMIN이 필요하지만, 구체적인 요건은 커널 기능, 서비스 샌드박스, 실행 환경에 따라 달라집니다. 데스크톱 클라이언트는 함께 제공되는 서비스로 해당 작업을 수행할 수 있습니다. mihomo를 직접 실행한다면 검토된 서비스 설정을 사용하고, 출처가 불분명한 바이너리에 임의로 권한을 부여하지 마세요.

ls -l /dev/net/tun
ip -br link
ip route show table all
ip rule show
resolvectl status

resolvectl은 systemd-resolved를 사용하는 시스템에서 사용할 수 있습니다. 다른 배포판에서는 실제 DNS 해석 서비스를 확인하세요. mihomo.service라는 systemd 유닛이 설치되어 있다면 다음 명령으로 서비스 상태와 이번 시작 로그를 확인할 수 있습니다. 유닛 이름이 다르면 설치 시 사용한 이름을 기준으로 하세요.

systemctl status mihomo.service
journalctl -u mihomo.service -b --no-pager -n 100

라우팅을 확인할 때 기본 라우팅 테이블만 보지 마세요. 자동 라우팅이 정책 라우팅과 함께 작동할 수 있으므로 ip rule show와 모든 라우팅 테이블도 확인해야 합니다. 컨테이너 안의 root 계정이 호스트 전체 권한을 갖는 것은 아닙니다. 컨테이너에 TUN 장치를 올바르게 노출하고 필요한 권한도 설정해야 하며, 권한을 검토하는 대신 특권 컨테이너를 바로 활성화하지 마세요.

검증 절차: 트래픽 처리, 규칙, 아웃바운드를 따로 확인

트래픽이 들어오는지 확인합니다. 시스템 프록시를 끄고 앞서 안내한 curl 요청을 실행한 다음 커널 연결 기록을 확인하세요. 대상 도메인이나 IP가 보이면 요청이 커널로 들어온 것입니다. 웹페이지가 열리는지만으로는 충분히 확인할 수 없습니다.
규칙을 확인합니다. 직접 연결되어야 하는 서비스와 프록시를 거쳐야 하는 서비스에 각각 접속해 적용된 규칙, 정책 그룹, 최종 노드를 기록하세요. TUN이 정상적으로 작동해도 DIRECT에 매칭될 수 있습니다. 이는 트래픽 분기 결과이지 트래픽 처리 실패가 아닙니다.
DNS를 확인합니다. 먼저 시스템 DNS 조회를 테스트한 다음 DNS 유출 검사를 진행하세요. 검사 사이트에 표시되는 주소는 재귀 DNS 서버의 출구이므로 프록시 출구 IP와 다를 수 있습니다. 사전에 설정한 DNS 경로에 맞는지 확인하세요.
IPv6를 확인합니다. 시스템에서 IPv6를 사용한다면 IPv4와 IPv6의 접속 결과 및 커널 기록을 각각 확인하세요. IPv4만 확인해서는 IPv4와 IPv6 트래픽이 모두 처리된다고 볼 수 없습니다.
UDP를 확인합니다. 실제로 사용하는 게임, 음성 통화 또는 HTTP/3 지원 앱으로 다시 테스트하고 노드의 UDP 지원 여부를 확인하세요. 일반 웹페이지의 TCP 요청이 성공해도 UDP가 정상이라는 뜻은 아닙니다.

‘켜기 전, 켠 후, 끈 후’ 세 가지 결과를 기록하는 것이 좋습니다. 시스템 프록시 상태, 적용 규칙, DNS 상위 서버, 오류 로그를 함께 적어 두세요. 지연 시간은 노드, 대상 사이트, 네트워크 경로, 캐시의 영향을 받으므로 한 번의 속도 테스트만으로 TUN이 시스템 프록시보다 빠르다고 판단할 수 없습니다.

자주 발생하는 문제와 안전하게 되돌리는 방법

증상	우선 확인할 항목	해결 방법
켜자마자 인터넷 연결이 끊김	인터페이스 권한, 라우팅 루프, 상위 DNS 접속 가능 여부	TUN을 꺼서 연결을 복구한 뒤 시작 로그를 항목별로 확인
도메인 접속은 실패하지만 IP로는 연결됨	커널 DNS, 53번 포트 가로채기, 앱의 암호화 DNS	노드를 바꾸지 말고 DNS 경로만 따로 점검
브라우저는 정상인데 게임은 연결되지 않음	UDP 아웃바운드, 노드 지원 기능, 대상 규칙	UDP 연결 기록과 서버 지원 여부 확인
LAN 기기에 접속할 수 없음	사설망 라우팅, 대상 주소, 도메인 매핑	해당 서브넷에 맞춰 라우팅 제외 또는 직접 연결 규칙 설정
Wi-Fi를 바꾼 뒤 문제가 발생함	아웃바운드 인터페이스 감지, 이전 라우팅, 네트워크 변경 로그	네트워크가 안정되면 커널을 재시작하고 라우팅을 다시 확인

LAN 직접 연결과 TUN 처리 제외는 서로 다른 설정입니다

사설 IP 주소를 DIRECT에 매칭하면 트래픽이 커널에 들어온 뒤 직접 아웃바운드로 나간다는 뜻입니다. 해당 서브넷을 TUN 라우팅에서 제외하면 트래픽이 커널을 거치지 않습니다. 두 방식은 로그에서 확인할 수 있는 정보와 DNS 동작이 다릅니다. 프린터, NAS, 사내 네트워크에 문제가 생기면 먼저 대상의 실제 주소와 서브넷을 확인하세요. 한 기기의 문제를 해결하려고 범위가 불분명한 주소 대역 전체를 제외하지 마세요.

종료 후 복구 순서

먼저 TUN을 끄고 클라이언트가 인터페이스와 라우팅을 제거할 때까지 기다린 다음 기존 시스템 프록시와 DNS 설정을 복구하세요. 그래도 연결되지 않으면 클라이언트를 정상 종료하고 남아 있는 프록시, 라우팅, 다른 VPN 상태를 확인하세요. 라우팅 테이블 전체를 바로 지우지 마세요. DNS나 fake-ip 설정을 바꾼 뒤에도 이전 주소가 계속 사용된다면 설정이 올바른지 확인하고 시스템 DNS 캐시를 비운 다음 관련 앱을 재시작하세요.

검증된 설정을 하나 보관하세요. 커널 종류, TUN 스택, DNS 상위 서버, 아웃바운드 인터페이스 선택, 필요한 LAN 예외를 명확히 기록해야 합니다. 이후 구독을 업데이트할 때는 의도한 항목만 변경하세요. 트래픽 처리나 DNS 설정을 바꿀 때마다 같은 순서로 다시 테스트하면 설정, 노드, 시스템 네트워크 중 무엇이 원인인지 구분할 수 있습니다.