Clash TUN 모드 설정 방법: 가상 네트워크 어댑터로 전체 트래픽을 처리하는 원리와 절차

TUN과 시스템 프록시: 트래픽 진입 방식은 달라도 분기 규칙은 그대로 적용

브라우저에서는 사이트가 열리는데 터미널, 게임 또는 특정 데스크톱 프로그램은 연결되지 않는다면 해당 프로그램이 시스템 프록시를 사용하지 않는 경우가 많습니다. 시스템 프록시는 앱에 HTTP 또는 SOCKS 프록시 주소를 제공하며, 이 설정을 읽을지는 앱에 따라 다릅니다. 반면 TUN은 가상 네트워크 어댑터를 만들고 라우팅을 통해 IP 패킷을 프록시 코어로 전달하므로, 앱마다 프록시 설정을 지원할 필요가 없습니다.

여기서 말하는 '전체 트래픽 처리'는 트래픽이 들어오는 범위를 뜻하며, 모든 연결이 프록시 노드를 거친다는 의미는 아닙니다. mode: rule을 사용하면 TUN으로 들어온 연결에도 rules가 적용되어 DIRECT, 프록시 정책 그룹 또는 REJECT로 각각 처리할 수 있습니다. 로컬 네트워크, 제외 경로, 다른 VPN, IPv6 경로도 실제로 처리되는 범위에 영향을 줄 수 있습니다.

비교 항목	시스템 프록시	TUN 모드
트래픽 진입 방식	앱이 로컬 프록시 포트에 연결	시스템 라우팅이 가상 네트워크 어댑터로 연결
앱 지원 여부	앱에서 프록시를 지원하고 사용해야 함	대개 앱에 프록시 주소를 따로 입력할 필요 없음
UDP 트래픽	앱과 프록시 프로토콜의 지원 여부에 따라 제한	코어에서 처리할 수 있지만, 출구 노드도 UDP를 지원해야 함
필요한 권한	대개 사용자 프록시 설정만 변경하면 됨	네트워크 어댑터 생성 및 라우팅 변경을 위한 시스템 권한 필요
트래픽 분기 방식	코어로 전달된 후 현재 모드에 따라 처리	코어로 전달된 후 현재 모드에 따라 처리

활성화 전 확인: 노드, 권한, 설정 덮어쓰기

먼저 시스템 프록시로 구독과 노드가 정상 작동하는지 확인한 다음 TUN을 활성화하세요. 문제가 발생해도 구독 내용이나 노드 연결을 동시에 의심하지 않고 가상 네트워크 어댑터, 라우팅, DNS 문제로 범위를 좁힐 수 있습니다. 현재 모드, 정책 그룹 선택, DNS 설정을 기록하고 정상 연결되는 설정을 백업해 두는 것이 좋습니다.

기본 연결 확인: 규칙 모드에서 정상 작동이 확인된 노드를 선택한 뒤 프록시가 필요한 웹사이트를 열어 보세요. 노드 지연 시간 테스트에 성공해도 테스트 대상에 연결된다는 의미일 뿐, 실제 웹사이트 접속을 보장하지는 않습니다.
코어 권한 확인: 데스크톱에서는 서비스 모드나 보조 서비스 상태를 확인하고, Android에서는 VPN 권한을 승인하세요. 일반 사용자 권한으로 실행된 코어는 가상 네트워크 어댑터를 만들지 못할 수 있습니다.
다른 VPN은 잠시 종료: 기업용 VPN, 게임 가속 프로그램, 다른 TUN 클라이언트가 라우팅을 변경할 수 있습니다. 우선 클라이언트 하나만 실행한 상태에서 기준을 확인한 뒤 함께 사용할 수 있는지 테스트하세요.
설정 편집 위치 확인: 클라이언트에서 제공하는 설정 덮어쓰기 또는 설정 병합 기능을 우선 사용하세요. 구독 캐시 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다.
실제 적용된 설정 확인: 화면의 스위치가 tun.enable, stack 또는 DNS 설정을 덮어쓸 수 있습니다. 저장한 뒤 편집기 내용뿐 아니라 실행 중인 설정도 확인하세요.

로컬 프록시 포트와 TUN은 서로 다른 진입 방식입니다. 예시의 mixed-port: 7890은 앱이 HTTP/SOCKS 프록시에 연결할 때 사용하며, DNS 수신 포트 1053은 DNS 서비스용입니다. 7890을 변경해도 가상 네트워크 어댑터 생성 실패는 해결되지 않습니다. 브라우저의 프록시 설정에 DNS 수신 포트를 입력하지 마세요.

Windows, macOS, Linux, Android에서 TUN 활성화하기

Windows: 서비스를 먼저 실행한 뒤 TUN 활성화

Clash Verge Rev의 일반적인 화면을 예로 들면, '설정' → '서비스 모드'로 이동해 안내에 따라 서비스를 설치하고 시스템 권한을 승인하세요. 서비스가 실행된 뒤 'TUN 모드'를 켭니다. 버전에 따라 관련 옵션이 설정 카드에 표시되는 등 메뉴 이름과 위치가 달라질 수 있습니다. 스위치가 켜져 있는지만 보지 말고 서비스가 실제로 실행 중인지 확인하세요.

활성화한 뒤 Windows의 '설정' → '네트워크 및 인터넷' → '고급 네트워크 설정'에서 어댑터를 확인하거나 아래 PowerShell 명령을 실행하세요. 가상 네트워크 어댑터 이름은 설정에서 지정할 수 있으므로 이름에 Clash가 포함되지 않을 수도 있습니다. 어댑터가 보이는 것은 첫 단계일 뿐이며, 로그에서 라우팅과 DNS 초기화가 성공했는지도 확인해야 합니다.

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
route print

로그에 권한 부족 또는 장치 생성 실패가 표시되면 서비스가 올바르게 설치되었는지 먼저 확인하세요. 관리자 권한으로 실행하면 진단에 도움이 될 수 있지만, 평소에는 클라이언트가 지원하는 서비스 방식으로 코어를 실행하는 것이 좋습니다. 방화벽은 해당 프로그램이나 서비스에 필요한 권한만 허용하세요. 시스템 방화벽 전체를 계속 끄는 것은 권장하지 않습니다.

macOS: 보조 서비스와 네트워크 권한 확인

mihomo TUN을 지원하는 클라이언트를 선택하고 설정 화면의 안내에 따라 보조 서비스를 설치한 다음 TUN을 활성화하세요. 시스템 권한 요청이 표시되면 프로그램 출처를 확인한 뒤 승인합니다. 서비스 설치 후에도 스위치가 켜진 상태로 유지되지 않으면 클라이언트 로그와 '시스템 설정' → '네트워크'의 네트워크 서비스 상태를 확인하세요. 일부 권한 요청은 '시스템 설정' → '개인정보 보호 및 보안'에 표시됩니다.

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1

macOS에서 흔히 볼 수 있는 가상 인터페이스 이름은 utun 뒤에 숫자가 붙는 형태지만, 시스템이나 다른 VPN도 같은 종류의 인터페이스를 만들 수 있습니다. utun 인터페이스가 나타났다는 이유만으로 현재 클라이언트가 트래픽을 처리한다고 단정하지 말고, 시작 로그와 대상 주소의 라우팅을 함께 확인하세요.

Linux: TUN 장치와 서비스 권한 확인

Linux에서는 일반적으로 /dev/net/tun 장치가 사용 가능해야 하며 인터페이스 생성과 라우팅 변경 권한도 필요합니다. 배포판 패키지, 데스크톱 클라이언트, 독립 코어 서비스마다 권한 부여 방식이 다르므로 각 프로젝트의 서비스 설치 안내를 따르세요. 컨테이너에서는 장치 연결과 네트워크 권한이 추가로 필요하므로 일반 데스크톱 절차를 그대로 적용할 수 없습니다.

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

라우팅을 확인할 때는 정책 라우팅과 모든 라우팅 테이블을 함께 살펴보세요. 일부 구현은 기본 라우팅 테이블의 기본 경로를 단순히 교체하지 않으므로 ip route만 실행하면 실제 트래픽 처리 경로를 놓칠 수 있습니다. 절차를 줄이려고 상시 실행 서비스를 모두 최고 권한으로 실행하지 마세요.

Android와 iOS: 플랫폼별 트래픽 처리 방식 구분

Android 그래픽 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리하며, 처음 연결할 때 VPN 권한을 요청합니다. mihomo를 지원하는 클라이언트라면 설정을 가져온 뒤 VPN/TUN 실행 방식을 활성화하고, 시스템 상태 표시줄에 VPN 아이콘이 표시되는지 확인하세요. Android에서는 일반적으로 VPN 서비스를 한 번에 하나만 사용할 수 있으므로 다른 VPN을 실행하면 현재 연결이 끊길 수 있습니다.

일부 앱만 연결되지 않는다면 클라이언트의 앱 접근 제어 또는 앱별 프록시 설정을 확인하세요. 제외된 앱은 트래픽 처리 범위에 들어오지 않을 수 있습니다. iOS 클라이언트는 대개 Network Extension으로 트래픽 처리 기능을 제공하며, 설정 형식과 지원 항목은 클라이언트마다 다릅니다. 데스크톱용 mihomo YAML을 모든 iOS 클라이언트의 활성화 방법으로 그대로 사용하지 마세요.

TUN 설정 예시: stack, auto-route, DNS 리다이렉션

아래 내용은 기존 mihomo 설정에 병합해 사용하는 최상위 설정 조각이며, 전체 설정 파일이 아닙니다. 노드, 구독 제공자, 정책 그룹, 규칙이 포함되어 있지 않으므로 기존 설정의 해당 항목을 유지해야 합니다. 기존 파일에 dns 또는 tun이 있다면 항목을 병합하세요. 같은 이름의 최상위 키를 하나 더 추가하면 안 됩니다.

mode: rule
mixed-port: 7890

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

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
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.cloudflare.com/dns-query

항목	예시 값	용도 및 주의 사항
`enable`	`true`	TUN 활성화를 요청합니다. 시스템 권한이 있어야 합니다.
`stack`	`mixed`	TCP는 system 스택, UDP는 gVisor 스택을 사용합니다.
`auto-route`	`true`	트래픽 처리에 필요한 경로를 자동으로 설정합니다. 모든 연결이 프록시 노드를 선택한다는 뜻은 아닙니다.
`auto-detect-interface`	`true`	외부로 나가는 인터페이스를 자동으로 감지합니다. 네트워크 어댑터나 VPN이 여러 개라면 감지 결과를 확인하세요.
`dns-hijack`	`any:53`	TUN으로 들어오는 UDP 53 요청을 처리해 내장 DNS로 전달합니다.
`enhanced-mode`	`fake-ip`	매핑 주소를 사용해 도메인과 이후 연결을 연결합니다.

stack 선택 방법

system: 시스템 네트워크 스택을 사용합니다. 호환성 테스트용으로 적합하며, 동작은 운영체제와 환경에 따라 다릅니다.
gvisor: 사용자 공간 네트워크 스택을 사용합니다. 특정 시스템 스택 문제를 비교 테스트할 때 사용할 수 있지만, 모든 기기에서 더 빠르다고 보장할 수는 없습니다.
mixed: TCP는 system, UDP는 gVisor로 처리합니다. 우선 이 설정으로 시작한 뒤 로그와 앱 동작을 확인해 조정할 수 있습니다.

한 번에 설정 항목 하나만 바꾸고 다시 연결한 뒤 같은 앱으로 테스트하세요. 게임 음성 채팅이 작동하지 않는다면 노드 프로토콜, 서버, 외부 네트워크가 UDP를 지원하는지도 확인해야 합니다. stack을 바꿔도 출구 노드에 없는 기능을 추가할 수는 없습니다.

default-nameserver는 DNS 업스트림의 도메인을 확인할 때 사용하고, proxy-server-nameserver는 프록시 서버 도메인을 확인할 때 사용합니다. 예시에서 이 두 종류의 조회를 분리한 이유는 시작 시 발생하는 DNS 조회 의존성 순환을 줄이기 위해서입니다. 실제로는 현재 네트워크에서 연결할 수 있고 개인정보 보호 요구사항에 맞는 리졸버를 선택하세요. DoH 업스트림과의 HTTPS 연결이 프록시를 거치는지는 DNS 라우팅 관련 설정에도 달려 있습니다. URL에 https가 있다고 해서 연결 경로를 단정할 수는 없습니다.

활성화 후 확인: 트래픽 진입, 규칙, DNS를 각각 점검

테스트할 때는 시스템 프록시를 잠시 끄고 TUN은 활성화된 상태로 유지하세요. 브라우저가 여전히 로컬 포트로 연결해 트래픽 처리 실패를 가리지 않도록 하기 위해서입니다. 테스트 프로그램 자체의 프록시 설정도 해제하세요. 일반 웹사이트부터 확인한 뒤 시스템 프록시를 사용하지 않는 프로그램을 테스트하고, 클라이언트의 '연결' 또는 '로그' 화면에서 해당 대상을 살펴보세요.

코어에 연결이 들어오는지 확인: 새 연결을 시작하고 연결 화면에 대상 도메인이나 IP가 표시되는지 확인하세요. 브라우저가 기존 연결을 재사용하면 새 기록이 바로 생기지 않을 수 있으므로 페이지를 닫고 다시 시도하세요.
규칙 적용 확인: 일치한 규칙과 최종 정책을 살펴보세요. 중국 본토 사이트는 직접 연결되고 해외 서비스는 프록시 그룹을 사용하더라도 TUN을 통한 트래픽 처리는 정상일 수 있습니다.
도메인 조회 확인: 클라이언트에 DNS 조회 기능이 있다면 해당 기능을 우선 사용하세요. 로컬 DNS 수신 포트에 직접 조회를 보내 내장 DNS가 응답하는지 확인할 수도 있습니다.
UDP 확인: 실제 음성 채팅, 게임 또는 다른 UDP 앱으로 테스트하세요. HTTP 웹페이지에 한 번 접속한 것만으로 UDP가 정상이라고 볼 수는 없습니다.

# macOS / Linux: 예시의 로컬 DNS 수신 포트 테스트
dig @127.0.0.1 -p 1053 example.com A

# 도메인 접속 성공 여부 확인
curl -I https://example.com

Fake-IP를 사용한다면 198.18.0.0/16 범위의 주소가 조회 결과로 나오는 것은 정상적인 매핑일 수 있으므로 곧바로 DNS 오류로 판단하지 마세요. 도메인이 필터 목록에 있으면 실제 주소가 반환될 수도 있습니다. 매핑 주소에 ping이 되는지를 웹사이트 접속 여부의 유일한 기준으로 삼지 마세요.

공인 IP 또는 DNS 확인 사이트는 해당 사이트가 관찰한 요청만 보여 줍니다. 예상한 출구 IP가 표시되더라도 모든 앱, DNS 요청, IPv6 트래픽이 처리된다는 보장은 없습니다. 앱 연결 기록, 규칙 적용 결과, 시스템 라우팅을 함께 확인해야 합니다.

TUN 활성화 후 인터넷에 연결되지 않을 때: 순서대로 문제 찾기

1단계: TUN을 끄고 기본 네트워크 확인

TUN을 꺼도 인터넷에 연결되지 않는다면 먼저 Wi-Fi, 게이트웨이, 구독 또는 노드 문제를 해결하세요. TUN을 끄자마자 연결이 복구된다면 현재 설정을 백업하고 TUN 시작 로그에서 권한, 인터페이스, 라우팅, DNS 오류를 중점적으로 확인하세요. 로그 수준을 일시적으로 log-level: debug로 설정해 한 번 재현한 뒤 평소 수준으로 되돌리세요. 연결 정보가 불필요하게 장기간 기록되는 것을 방지할 수 있습니다.

2단계: 네트워크 어댑터 생성과 외부 연결 경로 확인

로그에 permission denied, operation not permitted 등의 메시지가 있으면 서비스 권한을 다시 확인하세요. 네트워크 어댑터가 여러 개인 환경에서는 자동 감지된 외부 연결 인터페이스도 확인해야 합니다. 다른 VPN이나 현재 가상 네트워크 어댑터가 아니라 실제로 인터넷에 연결된 인터페이스여야 합니다. 자동 감지 결과가 잘못된 것을 확인한 뒤에만 현재 코어에서 지원하는 방식으로 외부 연결 인터페이스를 지정하세요.

3단계: DNS 문제와 연결 문제 구분

내장 DNS 조회가 시간 초과되면 dns.enable, 1053 포트 사용 여부, 업스트림 DNS 연결 가능 여부, 설정 적용 상태를 확인하세요. 조회는 성공하지만 웹사이트에 연결되지 않는다면 프록시 노드, 규칙, TLS 연결 로그를 살펴보세요. 'IP는 열리지만 도메인은 열리지 않는다'는 비교는 단서일 뿐입니다. 많은 웹사이트가 올바른 Host와 TLS SNI를 요구하며, IP 주소로 직접 접속해도 정상적으로 실패할 수 있습니다.

4단계: VPN, IPv6, 특수 라우팅 충돌 확인

다른 VPN을 종료한 뒤 다시 테스트하세요. IPv6 연결에서만 문제가 발생한다면 IPv6 DNS 응답, 시스템 라우팅, 노드의 외부 연결 지원이 일치하는지 확인해야 합니다. 진단을 위해 IPv6를 일시적으로 제한할 수는 있지만, 장기 해결책으로 사용할 때는 그 사실을 명확히 기록하세요. 회사 내부망이나 로컬 네트워크 장치에 연결할 수 없다면 해당 대역이 트래픽 처리 대상인지, 기존 규칙이 직접 연결을 선택하는지 확인하세요.

5단계: 마지막으로 stack과 MTU 조정

연결은 되지만 대용량 파일 전송이 멈추거나 일부 웹페이지가 계속 로드되거나 특정 UDP 앱에 문제가 있다면 stack을 하나씩 바꿔 테스트하세요. 경로 MTU가 의심된다면 기존 설정을 바탕으로 tun.mtu: 1400을 테스트하고 개선 여부를 기록하세요. 1400은 문제 해결을 위한 시작값이지 모든 네트워크에 최적인 값은 아닙니다. DNS, MTU, 규칙, 노드를 한꺼번에 변경하면 어떤 변경으로 문제가 해결됐는지 알기 어렵습니다.

연결 복구와 평소 사용: 확인 가능한 복구 경로 마련

원래 상태로 되돌려야 한다면 먼저 TUN을 끄고 코어가 종료되거나 다시 로드될 때까지 기다린 다음 필요에 따라 시스템 프록시를 켜세요. 정상적으로 종료되면 자동으로 만든 라우팅은 대개 정리됩니다. 클라이언트가 비정상 종료된 뒤에도 네트워크가 복구되지 않으면 해당 서비스나 클라이언트를 다시 시작한 뒤 남아 있는 인터페이스와 경로를 확인하세요. 라우팅 테이블에 익숙하지 않다면 시스템 경로를 한꺼번에 삭제하지 마세요.

브라우저 프록시만 필요: 시스템 프록시로 충분한 경우가 많습니다. 설정 범위가 좁고 문제를 진단하기도 쉽습니다.
터미널이나 데스크톱 프로그램의 트래픽 처리 필요: TUN이 더 적합하지만 권한, DNS, 규칙이 모두 정상인지 확인해야 합니다.
게임이나 음성 채팅 사용: TUN뿐 아니라 노드의 UDP 지원, 외부 연결 네트워크, 실제 앱 연결도 확인해야 합니다.
기업용 VPN을 자주 사용: 실행 순서, 외부 연결 인터페이스, 로컬 네트워크 접속을 각각 테스트하세요. 한 번 정상 작동했다고 계속 호환된다고 볼 수는 없습니다.

설정을 마친 뒤에는 클라이언트 이름, 코어 정보, 시스템 버전, 활성화한 설정 항목, 재현 절차를 기록해 두세요. 클라이언트를 바꾸거나 구독을 업데이트한 뒤에는 설정 덮어쓰기가 유지되는지 실행 설정을 다시 확인하세요. 프록시 진입 방식과 자주 쓰는 설정 항목은 사용 가이드에서, 포트와 설정 구조는 고급 가이드의 포트 안내에서 확인할 수 있습니다.