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

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

브라우저에서는 접속되는데 터미널, 게임 또는 특정 데스크톱 앱에서는 연결되지 않는다면, 해당 앱이 시스템 프록시 설정을 따르지 않는 경우가 많습니다. 시스템 프록시는 이를 지원하는 앱에 지정된 HTTP 또는 SOCKS 주소로 요청을 보내도록 안내합니다. 앱이 직접 연결하거나 프록시 설정을 무시하는 경우, 또는 해당 프록시가 처리하지 않는 UDP 통신을 사용하는 경우에는 시스템 프록시만 켜서는 부족합니다.

TUN은 시스템에 3계층 가상 네트워크 인터페이스를 만들고, 라우팅을 통해 조건에 맞는 IP 패킷을 코어로 전달합니다. mihomo는 데이터를 받은 뒤 대상 주소, 도메인 정보와 규칙에 따라 직접 연결할지 프록시를 사용할지 결정합니다. 따라서 앱에서 프록시 주소를 따로 설정할 필요가 없는 경우가 많지만, 코어에 인터페이스 생성 및 라우팅 변경 권한이 있어야 합니다.

비교 항목	시스템 프록시	TUN 모드
트래픽 유입 방식	앱이 프록시 프로토콜로 리스닝 포트에 연결	시스템 라우팅이 IP 패킷을 가상 인터페이스로 전달
앱 호환성	앱 지원 또는 수동 설정 필요	일반적으로 앱이 프록시 설정을 인식하지 않아도 됨
권한	일반적으로 네트워크 어댑터 생성 권한 불필요	데스크톱에서는 보통 관리자, root 또는 권한이 부여된 서비스 필요
UDP	앱과 프록시 연결 방식에 따라 다름	가로챌 수 있지만 프록시 노드와 프로토콜도 지원해야 함
적용 범위	프록시를 사용하지 않는 연결은 우회할 수 있음	라우팅, 제외 항목, IPv6 및 다른 VPN의 영향을 받음

시작 전 확인: 코어, 노드, 복구 방법

‘Clash 클라이언트’는 인터페이스를 가리키는 이름일 뿐, 내장 코어가 모두 같다는 뜻은 아닙니다. 이 문서의 YAML은 mihomo용이므로 모든 원본 Clash 또는 구형 Premium 코어에서 그대로 사용할 수 있는 범용 설정이 아닙니다. 먼저 클라이언트의 ‘정보’ 또는 ‘코어 정보’에서 실제 코어를 확인하세요. 코어를 직접 실행하는 경우 버전 출력을 확인할 수 있습니다.

mihomo -v
mihomo -t -f config.yaml

두 번째 명령은 현재 코어가 설정을 파싱할 수 있는지 확인할 뿐, 노드가 작동하거나 라우팅이 올바른지는 검증하지 않습니다. 프로그램을 찾을 수 없다는 메시지가 나오면 실제 실행 파일 경로를 사용하세요. Windows PowerShell에서는 현재 디렉터리의 프로그램을 보통 .\mihomo.exe로 실행합니다.

현재 정상적으로 작동하는 설정과 오버라이드 파일을 보관하세요. 구독을 업데이트하면 구독 파일에 직접 입력한 변경 사항이 덮어써질 수 있으므로, 클라이언트에서 제공하는 병합 또는 오버라이드 기능을 사용하는 것이 좋습니다.
먼저 시스템 프록시 모드에서 노드가 작동하는지 확인하세요. 웹페이지에 한 번 이상 접속해 보고, 게임·음성 통화 또는 QUIC가 필요하다면 노드의 UDP 지원 여부도 확인하세요.
다른 VPN, 게임 가속기와 구형 프록시 코어를 일시 중지하세요. 첫 테스트에서는 여러 도구가 동시에 기본 라우팅을 변경하지 않도록 합니다.
TUN을 끄는 방법을 미리 확인하세요. 원격 서버를 관리한다면 라우팅 변경으로 유일한 SSH 연결이 끊기지 않도록 콘솔이나 다른 복구 경로를 준비하세요.

mihomo TUN 기본 설정과 항목별 의미

아래 내용은 정상 작동 중인 설정에 추가하는 최상위 설정 조각이며, 노드와 프록시 그룹까지 포함한 전체 구독 파일이 아닙니다. 기존에 tun 또는 dns 항목이 있다면 필드를 병합하고, 같은 최상위 키를 중복으로 추가하지 마세요. 첫 검증은 IPv4만 대상으로 진행하고, 연결 상태를 확인한 뒤 IPv6를 별도로 점검하세요.

mode: rule
log-level: info
ipv6: false

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
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

여기서 사용하는 두 DNS 주소는 일반 DNS 업스트림 설정 예시일 뿐이므로, 현재 네트워크에서 접속 가능한 주소로 조정해야 합니다. 일반 DNS 쿼리는 암호화되지 않습니다. DNS 분기와 노드 도메인 해석 설정을 이미 잘 구성했다면 기존 설계를 유지하고, 이 입문용 설정으로 전체를 대체하지 마세요.

항목	기능 및 확인 사항
`enable`	TUN 시작을 요청합니다. 시작 성공 여부는 권한, 인터페이스와 로그도 확인해야 합니다.
`auto-route`	트래픽을 TUN으로 보내는 라우팅을 자동 설정하지만, 모든 제외 경로가 사라지는 것은 아닙니다.
`auto-detect-interface`	실제 아웃바운드 네트워크 어댑터를 자동으로 식별합니다. 여러 어댑터를 사용하거나 다른 VPN이 실행 중이면 결과를 확인해야 합니다.
`dns-hijack`	TUN으로 들어오는 대상 포트 53의 UDP DNS를 예시로 가로챕니다. 암호화된 DNS를 모두 가로채는 것은 아닙니다.
`listen`	로컬 DNS 리스닝 주소입니다. 1053은 예시 포트이며 시스템 DNS에 입력해야 하는 포트가 아닙니다.
`fake-ip-range`	도메인 매핑에 사용할 주소를 할당합니다. 앱이 이 주소를 받아도 코어를 통해 처리되어야 합니다.

198.18.0.1/16이 속한 주소 대역은 벤치마크 테스트용입니다. 원격 웹사이트의 실제 IP나 일반 공인 노드 주소가 아닙니다. 앱이 Fake-IP를 캐시한 상태에서 코어를 종료해도 해당 캐시를 계속 사용하면 일시적으로 접속이 되지 않을 수 있습니다. 관련 앱을 종료하고 DNS 캐시를 비운 뒤 다시 테스트하세요.

stack 선택 방법: system, gvisor, mixed

system: 주로 시스템 네트워크 스택을 사용해 연결을 처리합니다. 우선 클라이언트 권장값으로 테스트할 때 적합하지만, 실제 동작은 운영체제와 네트워크 환경에 따라 다릅니다.
gvisor: 사용자 공간 네트워크 스택을 사용합니다. 특정 앱에서 호환성 문제가 생기면 비교용으로 선택할 수 있지만, 더 빠르거나 안정적이라고 단정할 수는 없습니다.
mixed: TCP는 system 경로, UDP는 gVisor 경로를 사용합니다. 혼합 처리 방식이며 프록시 설정 두 개를 동시에 실행하는 것은 아닙니다.

플랫폼과 코어 버전에 따라 stack 지원 여부와 제한이 다를 수 있습니다. 변경한 뒤에는 설정을 먼저 검사하고 시작 로그를 확인하세요. stack, DNS 업스트림, 노드를 한꺼번에 바꾸지 마세요. 접속이 복구되더라도 어떤 변경이 효과가 있었는지 파악하기 어렵습니다.

Windows: 코어에 네트워크 어댑터 생성 권한 부여

다른 프록시 클라이언트를 종료하고, 현재 노드가 일반 시스템 프록시에서 작동하는지 확인하세요.
클라이언트에 서비스 모드가 있다면 인터페이스 안내에 따라 서비스를 설치하고 시작하세요. 서비스 모드가 없다면 프로그램 출처를 신뢰할 수 있는 경우 관리자 권한으로 클라이언트를 실행해 한 차례 테스트할 수 있습니다.
클라이언트의 TUN 설정에서 가상 네트워크 어댑터를 켜고, 로그에서 인터페이스 생성 및 라우팅 설정 성공 여부나 구체적인 실패 원인을 확인하세요. 클라이언트마다 메뉴 이름이 다르므로 스위치 색만 보고 성공 여부를 판단하지 마세요.
Win + R을 누르고 ncpa.cpl을 실행해 네트워크 어댑터를 확인하세요. 인터페이스 이름은 클라이언트나 설정에 따라 다르며 반드시 Clash라는 이름을 사용하는 것은 아닙니다.

검증할 때는 클라이언트의 시스템 프록시를 끄고 TUN만 켜세요. 그래야 브라우저가 시스템 프록시로 접속해 TUN 오류를 가리는 일을 막을 수 있습니다. Windows 11의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 상태를 확인하세요. 조직에서 관리하는 기기라면 조직 정책을 임의로 변경하지 마세요.

route print
ipconfig /all
curl.exe --noproxy "*" -I https://example.com

route print로 라우팅 상태를 확인하되, TUN을 가리키는 기존 형식의 기본 경로가 반드시 표시되어야 하는 것은 아닙니다. 구현에 따라 더 구체적인 네트워크 대역으로 트래픽을 가로챌 수도 있습니다. 테스트 중에는 클라이언트 연결 목록도 확인해 요청이 코어로 들어와 예상한 정책을 적용받는지 검증하세요. HTTP 응답을 받았다는 사실만으로는 대상에 접속할 수 있음을 보여줄 뿐, 프록시 노드를 통과했는지는 증명되지 않습니다.

macOS 및 Linux: 권한, 라우팅, DNS 확인

macOS 설정 방법

mihomo TUN을 지원하는 클라이언트를 사용하고, 화면 안내에 따라 보조 서비스를 설치하거나 권한을 부여하세요. 일반 사용자 권한으로 실행한 프로세스는 모든 네트워크 설정 작업을 직접 수행할 수 없는 경우가 많습니다.
TUN을 켠 뒤 로그를 확인하고 터미널에서 ifconfig와 netstat -rn을 실행하세요. 시스템에 utun 인터페이스가 여러 개 있을 수 있으므로, utun이 보인다는 것만으로 현재 클라이언트의 인터페이스라고 단정할 수 없습니다.
‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 이전 수동 프록시가 남아 있는지 확인하세요. 메뉴 이름과 위치는 시스템 버전에 따라 다를 수 있습니다.
시스템 프록시를 끄고 명시적 프록시가 설정되지 않은 앱에서 새 연결을 만든 다음, 코어의 연결 목록과 대조해 확인하세요.

웹페이지는 열리는데 로컬 네트워크 기기에 접속할 수 없다면 먼저 로컬 네트워크 트래픽에 적용되는 규칙과 라우팅을 확인한 뒤 제외할 네트워크 대역을 조정할지 판단하세요. 내부 네트워크 전체의 프록시 접속 실패를 DNS 문제로 오인하지 마세요.

Linux 설정 방법

Linux에서는 보통 root 권한 또는 이에 상응하는 네트워크 관리 권한이 필요하며, 시스템에 TUN 장치가 있어야 합니다. 먼저 /dev/net/tun이 있는지 확인하세요. 컨테이너나 최소 구성 시스템에서는 장치 접근이 제한될 수 있으므로, 프로세스를 root로 실행해도 인터페이스 생성이 보장되지는 않습니다.

ls -l /dev/net/tun
mihomo -t -f config.yaml
sudo mihomo -f config.yaml

# 다른 터미널에서 확인
ip link
ip rule
ip route show table all
resolvectl status

첫 실패 지점을 확인하기 쉽도록 처음에는 포그라운드에서 실행하세요. 장기간 실행할 때는 관리되는 서비스 설정을 사용하고, 문제 해결을 위해 디렉터리 내 모든 프로그램에 일괄적으로 권한을 부여하지 마세요. resolvectl은 systemd-resolved를 사용하는 시스템에서 쓸 수 있습니다. 다른 배포판에서는 실제 DNS 관리 방식을 확인하세요.

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

Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 처음 연결할 때 VPN 권한을 허용하고, 클라이언트의 앱 제외 또는 앱별 프록시 설정도 확인하세요. 제외된 앱은 TUN을 켜도 자동으로 규칙 처리 대상이 되지 않습니다. Android의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’에서 현재 연결을 확인할 수 있으며, 제조사별 설정에서는 ‘연결 및 공유’에 있을 수도 있습니다.

Android에서는 보통 동일한 사용자 또는 프로필 공간에서 활성 VPN 서비스를 하나만 유지할 수 있습니다. 로컬 방화벽, 광고 차단 도구 또는 다른 VPN이 같은 인터페이스를 사용하려 할 수 있습니다. ‘VPN 상시 사용’ 또는 ‘VPN 미사용 시 연결 차단’을 설정했다면 클라이언트를 끌 때 네트워크 연결이 어떻게 되는지 먼저 확인하세요. Android 비공개 DNS는 암호화된 연결을 사용하므로 포트 53 가로채기 규칙에 적용된다고 단정할 수 없습니다.

iOS에서는 해당 설정을 지원하는 클라이언트를 사용하고 시스템 VPN 권한을 허용해 터널을 연결해야 합니다. ‘설정’ → ‘일반’ → ‘VPN 및 기기 관리’에서 상태를 확인하세요. iOS 클라이언트가 mihomo를 사용하지 않거나 위 YAML 항목을 지원하지 않을 수 있습니다. 앱의 설정 형식을 따르고, 데스크톱 설정을 그대로 가져와 범용 설정으로 사용하지 마세요.

DNS, IPv6, UDP: 놓치기 쉬운 세 가지 점검 사항

포트 53 가로채기로 DoH와 DoT를 처리할 수는 없습니다

예시의 any:53은 일반 UDP DNS를 처리합니다. DNS over TLS는 보통 TCP 853 포트를 사용하고 DNS over HTTPS는 보통 HTTPS의 443 포트를 사용하므로, 이 설정만으로 두 방식이 코어 DNS 쿼리로 자동 전환되지는 않습니다. 문제를 진단할 때는 브라우저의 보안 DNS를 잠시 꺼서 비교하고, 결과를 확인한 뒤 최종 DNS 처리 방식을 결정하세요.

테스트할 때는 ‘도메인이 해석되는지’와 ‘연결이 코어로 들어가는지’를 각각 확인하세요. 예를 들어 nslookup example.com으로 DNS 응답을 확인할 수 있지만, 특정 브라우저도 같은 DNS 경로를 사용한다는 증거는 아닙니다. 도메인 규칙의 적용 여부는 코어가 해당 연결의 도메인 정보를 확인할 수 있는지에 따라서도 달라집니다.

AAAA 응답을 차단해도 시스템 IPv6가 비활성화되는 것은 아닙니다

예시의 IPv6 설정은 첫 진단을 단순화하기 위한 것이며, 시스템 전체의 우회 방지를 보장하지 않습니다. 앱이 캐시된 IPv6 주소, IP 주소를 직접 입력한 값 또는 다른 DNS 리졸버를 계속 사용할 수 있습니다. IPv6를 사용해야 한다면 코어의 IPv6 설정, TUN 라우팅, DNS 응답과 노드 지원 여부를 함께 확인하세요. IPv6가 필요하지 않더라도 적용되지 않은 시스템 IPv6 경로가 남아 있는지 점검해야 합니다.

UDP를 가로채도 아웃바운드 연결이 작동해야 합니다

음성 통화나 게임이 작동하지 않으면 연결 목록에 해당 UDP 세션이 나타나는지 먼저 확인한 뒤, 규칙에서 선택한 노드가 UDP를 지원하는지 살펴보세요. 브라우저의 QUIC도 UDP를 사용합니다. 웹페이지가 TCP로 대체 연결되어 열린다고 해서 UDP 연결도 정상이라는 뜻은 아닙니다. 웹 속도 테스트 한 번으로 게임이나 음성 앱의 연결을 대신 검증하지 마세요.

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

증상	먼저 확인할 항목	다음 단계
켜자마자 꺼짐	설정 파싱 오류, 서비스 미시작, 권한 부족	설정 검사를 실행하고 인터페이스 생성과 관련된 첫 오류를 확인하세요.
켜면 모든 네트워크 연결이 끊김	잘못 선택된 아웃바운드 인터페이스, 다른 VPN과의 충돌, 노드 접속 불가	TUN을 꺼서 네트워크를 복구한 뒤 트래픽을 가로채는 도구 하나만 남기세요.
IP 주소로는 접속되지만 도메인은 접속되지 않음	DNS 업스트림 접속 불가, 리스너 충돌, DNS 경로가 가로채지지 않음	1053 포트 리스닝과 DNS 로그를 확인하세요. 먼저 모든 규칙을 바꾸지는 마세요.
웹은 되지만 게임은 안 됨	UDP 아웃바운드, 규칙 정책, 앱 제외 항목	UDP 세션과 실제로 선택된 노드를 확인하세요.
Wi-Fi를 바꾼 뒤 연결되지 않음	네트워크 변경 후 아웃바운드 인터페이스와 라우팅이 갱신되지 않음	TUN 세션을 다시 시작하고 새로 식별된 물리 네트워크 어댑터를 확인하세요.
TUN을 꺼도 인터넷에 연결되지 않음	시스템 프록시, 라우팅 또는 Fake-IP 캐시가 남아 있음	먼저 클라이언트를 종료한 뒤 프록시와 라우팅을 확인하고 마지막으로 캐시를 비우세요.

MTU가 의심될 때만 별도로 조정하세요. 작은 요청은 정상인데 큰 응답이나 특정 웹사이트에서 멈추는 현상이 나타날 수 있지만, 노드나 네트워크 경로 문제일 수도 있습니다. 현재 값을 기록한 뒤 mtu: 1400으로 비교 테스트할 수 있습니다. 이 값은 진단을 시작하기 위한 기준일 뿐, 모든 유선·모바일 네트워크와 VPN 중첩 환경에 최적인 값은 아닙니다.

DNS 캐시 문제가 확인되면 Windows에서는 ipconfig /flushdns를 실행할 수 있습니다. systemd-resolved를 사용하는 Linux에서는 sudo resolvectl flush-caches를 실행하세요. 캐시 삭제로 잘못된 라우팅이 복구되거나 사용할 수 없는 노드가 정상화되지는 않습니다. 점검을 마친 뒤 임시 디버그 로그 수준을 info로 되돌리고, 로그를 공유하기 전에 구독 주소, 토큰과 기타 민감한 정보를 제거하세요.

완료 기준: 연결 하나로 전체 경로 검증

시스템 프록시와 앱 내부의 명시적 프록시를 끄고 새 연결을 시작하세요.
코어에서 해당 연결을 찾아 대상, TCP 또는 UDP 유형, 적용된 규칙과 아웃바운드 정책을 확인하세요.
직접 연결되어야 하는 대상과 프록시를 사용해야 하는 대상을 각각 테스트하세요. 웹페이지 하나만 확인해서는 안 됩니다.
로컬 네트워크 접속, 네트워크 전환, TUN을 끈 뒤의 복구 상태를 확인하세요.

이 네 단계를 모두 통과해야 트래픽 가로채기, 규칙 및 아웃바운드가 기본적으로 연결되었다고 볼 수 있습니다. 그다음 IPv6, 앱 제외 또는 세부 라우팅 설정을 추가하되, 한 번에 하나씩 변경하고 되돌릴 수 있도록 기록을 남기세요. 각 항목에 대한 자세한 설명은 전체 설정 가이드의 TUN 설정과 DNS 설정에서 확인할 수 있습니다.