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

TUN과 시스템 프록시의 차이

브라우저에서는 접속되는데 명령줄 도구는 시간 초과가 발생하거나, 웹페이지는 열리는데 게임이나 데스크톱 프로그램은 직접 연결되는 경우가 있습니다. 이럴 때는 노드를 바꾸기 전에 트래픽이 어디로 들어가는지부터 확인하세요. Windows 시스템 프록시는 해당 설정을 읽는 프로그램에 지정된 HTTP 프록시로 요청을 보내도록 안내할 뿐입니다. 프로그램이 시스템 프록시를 사용하지 않으면 해당 설정을 켜도 트래픽이 자동으로 Clash에 들어가지 않습니다.

TUN은 네트워크 계층에 가상 네트워크 어댑터를 추가하고, 라우팅을 통해 처리 대상인 IP 패킷을 커널로 전달합니다. 프로그램은 HTTP 프록시를 지원하거나 프록시 설정을 제공할 필요가 없습니다. 커널은 전달받은 트래픽에 규칙을 적용해 직접 연결, 프록시 연결 또는 차단 여부를 결정합니다.

가상 네트워크 어댑터가 연결을 처리하는 방식

연결 과정은 네 단계로 나눠 볼 수 있습니다. 먼저 데이터가 커널에 들어왔는지 확인하고, 다음으로 어떤 규칙이 적용됐는지 살핀 뒤, 마지막으로 노드 성능을 점검하세요. 가상 네트워크 어댑터가 표시되는 것만으로 트래픽 처리가 완료됐다고 볼 수는 없습니다.

1. 프로그램이 요청을 보냅니다.프로그램이 대상 IP로 TCP 또는 UDP 데이터를 전송합니다. 도메인 이름을 사용하는 경우 먼저 이름을 조회합니다.
2. Windows가 라우팅을 선택합니다.클라이언트에서 자동 라우팅을 활성화하면 대상 트래픽이 TUN 인터페이스로 들어가도록 관련 경로가 추가됩니다. 더 구체적인 경로, 제외 주소, 다른 VPN의 설정에 따라 결과가 달라질 수 있습니다.
3. 커널이 트래픽을 식별하고 규칙을 적용합니다.DNS 매핑 등의 정보를 바탕으로 도메인을 확인한 다음, 도메인·IP·프로세스 규칙에 따라 정책을 선택합니다. 도메인을 확인할 수 없으면 도메인 규칙이 적용되지 않을 수 있습니다.
4. 실제 외부 연결을 시작합니다.직접 연결 트래픽은 물리 네트워크 어댑터를 통해 나가고, 프록시 트래픽은 선택한 노드를 거쳐 전달됩니다. 클라이언트 자체의 외부 연결이 다시 TUN으로 들어와 루프가 생기지 않도록 해야 합니다.

따라서 TUN이 물리 네트워크 어댑터를 대체하는 것은 아닙니다. Wi-Fi와 이더넷은 실제 네트워크 연결을 담당하고, 가상 네트워크 어댑터는 지정된 트래픽을 커널로 전달합니다. 노드가 UDP를 지원하지 않으면 TUN을 켜도 UDP 전달 기능이 생기지 않습니다. 게임, 음성 통화, QUIC의 사용 가능 여부는 노드 프로토콜, 서버 설정과 네트워크 환경에 따라 달라집니다.

시작 전 확인: 클라이언트와 서비스 모드

먼저 기본 연결이 되는지 확인

• 신뢰할 수 있는 출처의 구독을 가져오고, 구독 파일만 내려받는 데 그치지 말고 클라이언트에서 실제로 사용할 설정을 선택하세요.
• 프록시 그룹에서 노드를 직접 선택한 다음, 먼저 시스템 프록시를 사용해 브라우저가 정상적으로 연결되는지 확인하세요.
• 현재 수신 포트를 확인하세요. 흔히 쓰는 예시는 7890이지만 실제 값은 클라이언트 설정을 기준으로 해야 합니다. 다른 사용자의 포트를 그대로 적용하지 마세요.
• 가상 네트워크 어댑터 여러 개가 동시에 라우팅을 변경하지 않도록 다른 VPN, 네트워크 가속기와 별도의 프록시 클라이언트를 잠시 종료하세요.
• 기존 설정, DNS 설정과 VPN 정보를 저장해 두세요. 원격으로 접속 중인 컴퓨터에서는 라우팅을 성급하게 바꾸지 말고 가능하면 로컬에서 작업하세요.

서비스 모드는 TUN 설정이 아닙니다

구버전 Clash for Windows에서는 서비스 관리 메뉴가 보통 General → Service Mode 옆의 톱니바퀴 버튼에 있습니다. 관리 창을 연 뒤 Install을 눌러 서비스를 설치하고 안내에 따라 Windows 권한을 확인하세요. 배포 버전에 따라 버튼 위치와 상태 문구가 다를 수 있습니다. 메뉴를 찾지 못하면 사용 중인 버전을 먼저 확인하고 출처가 불분명한 드라이버를 반복해서 설치하지 마세요.

서비스 모드는 백그라운드 프로세스가 높은 권한이 필요한 작업을 수행하도록 합니다. TUN 설정은 가상 네트워크 어댑터를 통해 트래픽을 처리합니다. 서비스를 설치한 뒤에도 서비스가 실행 중인지 확인하고 TUN Mode를 켜야 합니다. 둘은 서로 대체할 수 없으며, 그래픽 인터페이스 전체를 항상 관리자 권한으로 실행해야 한다는 뜻도 아닙니다.

다른 클라이언트를 사용한다면 설정에서 실제 ‘서비스 모드’, ‘시스템 서비스’ 또는 ‘TUN 모드’ 메뉴를 찾아보세요. 구버전 화면을 그대로 따라 하기 위해 클라이언트를 다운그레이드하지 마세요. 서비스 설치 중 오류가 발생하면 전체 오류 메시지와 커널 로그를 기록하고 권한, 보안 프로그램의 차단 기록, 기존 서비스 잔여 항목을 확인하세요. 시스템 보안 기능을 무작정 끄지 마세요.

mihomo TUN 설정과 DNS 가로채기

아래는 mihomo를 위한 설정 항목 예시이며, 단독으로 가져올 수 있는 완전한 구독 설정이 아닙니다. 노드, 프록시 그룹과 분류 규칙이 포함되어 있지 않으므로 기존 설정을 대체할 수 없습니다. 구버전 Clash for Windows는 모든 항목을 지원하지 않을 수 있습니다. 클라이언트가 화면에서 TUN 및 DNS 설정을 생성한다면 구독 갱신 후 수정 사항이 사라지지 않도록 설정 화면이나 오버라이드 기능을 우선 사용하세요.

mode: rule
mixed-port: 7890

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:
    - 223.5.5.5
    - 119.29.29.29

주요 설정 항목의 역할

• auto-route: 커널이 트래픽을 처리하는 데 필요한 경로를 자동으로 설정합니다. 네트워크 어댑터만 만들고 라우팅이 제대로 설정되지 않으면 프로그램 트래픽이 이를 우회할 수 있습니다.
• auto-detect-interface: 외부 연결에 사용할 인터페이스를 자동으로 찾습니다. 네트워크 어댑터가 여러 개 있거나 회사 VPN, 유선·무선 연결을 함께 사용하는 경우 로그에서 실제 출구를 확인해야 합니다.
• stack: mixed: mihomo에서 혼합 프로토콜 스택을 사용합니다. 스택 지원 여부와 구현은 커널 버전에 따라 다르므로 특정 프로그램에서 호환성 문제가 생길 때 문서를 확인해 다른 지원 옵션과 비교하세요.
• dns-hijack: 처리 대상 범위에 들어오는 지정 포트의 DNS 트래픽을 내장 DNS로 전달합니다. 여기에는 UDP 53과 TCP 53을 각각 설정했지만, 모든 암호화 DNS를 식별한다는 뜻은 아닙니다.
• listen: 127.0.0.1:1053: 내장 DNS가 로컬 루프백 주소의 1053 포트에서 요청을 받도록 설정합니다. Windows DNS 서버 주소에 포트가 포함된 문자열을 입력하라는 뜻이 아닙니다.
• fake-ip: 도메인에 가상 주소를 할당해 커널이 이후 연결을 도메인과 연결할 수 있도록 합니다. 예시 주소 풀은 198.18.0.1/16이며 노드 주소가 아닙니다.

예시에 나온 두 상위 DNS 서버는 설정 항목 구조를 보여 주기 위한 일반 DNS 주소입니다. 모든 네트워크에 적합하거나 암호화된 조회를 제공한다는 뜻은 아닙니다. 실제로 적용할 때는 상위 DNS 서버에 연결할 수 있는지, 노드 도메인 조회, 분할 DNS, 회사 내부 도메인 등을 고려해야 합니다. 이러한 설정이 필요하면 설정 참고 자료를 확인하고 예시를 범용 최적 설정으로 간주하지 마세요.

DNS가 규칙 적용에 영향을 주는 이유

도메인 규칙을 적용하려면 도메인 정보가 필요합니다. 앱이 암호화된 DNS 조회를 직접 수행하거나 이전 캐시를 사용해 IP에 바로 연결하면 커널이 예상한 도메인 매핑을 얻지 못할 수 있습니다. 53번 포트로 전송되는 DNS를 가로채더라도 HTTPS 기반 DoH나 TLS 기반 DoT까지 자동으로 처리할 수는 없습니다. 브라우저의 보안 DNS, 프로그램 내장 DNS 조회 기능, Windows의 암호화 DNS 설정에 따라 실제 조회 경로가 달라질 수 있습니다.

문제를 확인할 때는 테스트 앱의 사용자 지정 보안 DNS를 잠시 끄고 시스템 DNS를 사용해 비교한 뒤 테스트를 마치면 설정을 복구하세요. 한 번의 조회 결과만으로 ‘DNS 유출’이라고 단정하지 말고, 모든 도메인이 fake-ip로 조회되는 것을 성공 기준으로 삼지도 마세요. 로컬 네트워크 장치 이름, 회사 내부 도메인, 일부 특수 앱은 클라이언트 문서에 따라 예외나 별도 상위 DNS 서버를 설정해야 할 수 있습니다.

설정 순서: 한 번에 하나씩 변경

1. 기본 프록시 연결을 확인합니다.규칙 모드를 유지하고 연결이 검증된 노드를 선택하세요. 이 단계에서는 TUN을 켜지 말고 구독과 노드에 문제가 없는지 먼저 확인합니다.
2. 서비스를 설치하고 실행합니다.클라이언트의 서비스 관리 메뉴에서 설치한 뒤 상태가 정상인지 확인하세요. 서비스가 시작되지 않으면 권한 문제나 남은 서비스를 먼저 해결하고 설정을 추가하지 마세요.
3. TUN을 켭니다.권한 부족, 인터페이스 생성 실패, 경로 추가 실패, DNS 포트 충돌 등의 오류가 로그에 나타나는지 확인하세요. 오류가 있으면 TUN을 끄고 로그를 보관하세요.
4. 시스템 프록시를 끄고 분리 테스트를 합니다.이 단계는 연결이 TUN을 통해 처리되는지 확인하기 위한 것으로, 시스템 프록시와 TUN을 함께 사용할 수 없다는 뜻은 아닙니다. 시스템 프록시가 켜져 있으면 브라우저 연결이 성공한 이유가 HTTP 프록시일 수 있습니다.
5. 테스트 연결을 새로 만듭니다.테스트 프로그램을 완전히 종료한 뒤 다시 열거나 요청을 새로 보내세요. 기존 연결이나 DNS 캐시가 TUN을 켜기 전 경로를 계속 사용할 수 있습니다.
6. 연결 정보를 확인합니다.클라이언트의 연결 목록에서 대상, 적용된 규칙과 정책 경로를 확인하세요. 검증이 끝나면 평소 사용 방식에 따라 시스템 프록시를 켤지 결정하면 됩니다.

웹 브라우징만 필요하고 시스템 프록시로 충분하다면 처리 범위를 넓히기 위해 굳이 TUN을 켤 필요는 없습니다. 트래픽 처리 계층이 추가되면 로컬 네트워크 검색, 회사 네트워크, 절전 모드 복귀, 여러 네트워크 어댑터 간 전환에서 생기는 호환성 문제도 확인해야 합니다.

Windows에서 확인하기: 네트워크 어댑터, 경로, 연결 기록

설정 스위치의 색상만 보고 판단하지 마세요. 가상 인터페이스, 라우팅 변경, 실제 연결을 차례로 확인해 서로 대조해야 합니다. 아래 명령은 상태 확인용이며 네트워크 어댑터를 변경하거나 경로를 삭제하지 않습니다.

1단계: 인터페이스와 경로 확인

PowerShell을 열고 TUN을 끈 상태와 켠 상태에서 아래 명령을 각각 실행하세요. 추가된 인터페이스와 경로를 비교하되 가상 네트워크 어댑터 이름이 항상 같은 것은 아닙니다.

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

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

Get-DnsClientServerAddress -AddressFamily IPv4

인터페이스가 추가된 것은 단서일 뿐 결론은 아닙니다. TUN은 여러 경로를 통해 주소 범위를 처리할 수 있으므로 익숙한 기본 경로 하나만 추가되는 형태가 아닐 수도 있습니다. 다른 VPN이 더 구체적인 경로를 설정했는지도 살펴보세요. 실제 트래픽이 IPv6를 사용하는 경우 위의 IPv4 출력만으로는 모든 트래픽이 처리된다고 확인할 수 없습니다.

2단계: 명시적 프록시를 거치지 않고 요청 보내기

시스템 프록시를 끈 상태에서 아래 요청을 실행하세요. --noproxy "*"는 환경 변수에 설정된 프록시를 포함해 curl이 명시적 프록시를 사용하지 않도록 합니다. 운영체제의 TUN 라우팅을 우회하는 옵션은 아닙니다.

curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/

HTTP 응답이 돌아오면 요청이 성공했다는 것만 확인할 수 있습니다. 대상에 직접 연결됐을 수도 있으므로 프록시를 거쳤다는 증거는 아닙니다. 클라이언트의 연결 목록을 바로 열어 대상 도메인이나 주소로 요청을 찾고, 적용된 규칙과 최종 정책이 DIRECT인지 노드인지 확인하세요. 요청이 너무 빨리 사라진다면 클라이언트 로그도 확인하세요. 연결 기록 여부는 로그 설정에 따라 달라집니다.

3단계: 실제로 처리할 프로그램 확인

이전에 시스템 프록시를 사용하지 않던 프로그램을 다시 시작해 네트워크 작업을 한 번 수행하고 연결 목록에 나타나는지 확인하세요. 브라우저 테스트로 게임의 UDP 연결을 확인할 수는 없으며, TCP 요청이 성공해도 음성 통화 채널이 작동한다는 뜻은 아닙니다. 원격 출구를 확인하려면 신뢰할 수 있는 출구 IP 조회 서비스를 사용하고 연결 정보와 대조하세요. 웹페이지에 표시된 지역만으로 시스템 전체를 판단하지 마세요.

IPv6도 별도로 확인해야 합니다. 클라이언트의 IPv6 및 라우팅 설정, 시스템이 IPv6 주소를 받았는지, 대상이 AAAA 레코드를 사용하는지 확인하세요. 테스트하지 않은 상태에서 모든 IPv6가 처리된다고 단정하지 말고, IPv6 전체 비활성화를 기본 해결책으로 삼지도 마세요.

자주 발생하는 문제와 점검 순서

로컬 네트워크 문제는 계층별로 확인해야 합니다. 사설 IP 대역을 DIRECT로 지정하면 커널에 들어온 뒤의 외부 연결 정책만 바뀌며, 해당 대역의 트래픽이 가상 네트워크 어댑터를 완전히 우회하는 것은 아닙니다. 브로드캐스트, 멀티캐스트 또는 특수 검색 프로토콜에 의존하는 장치는 라우팅 제외 설정도 필요할 수 있습니다. 네트워크 대역은 실제 환경에 맞게 입력해야 하며 모든 가정용 네트워크가 192.168.1.0/24라고 가정하지 마세요.

DNS를 변경했는데도 이전 결과가 계속 사용된다면 필요한 정보를 저장한 뒤 ipconfig /flushdns를 실행해 Windows DNS 캐시를 지우고 테스트 앱을 다시 시작하세요. 이 명령은 브라우저 내부 캐시를 모두 지우지 않으며 잘못된 상위 DNS 서버나 라우팅 문제를 해결하지도 않습니다. 네트워크 초기화 명령을 연달아 실행하는 방식으로 문제를 해결하려 하지 마세요.

끄기 및 원상 복구 확인

테스트에 실패하면 먼저 TUN을 끈 다음 클라이언트에서 정상적으로 종료하거나 관련 서비스를 중지하세요. Windows 11에서는 ‘설정 → 네트워크 및 인터넷 → 프록시 → 수동 프록시 설정’에 로컬 프록시가 남아 있는지 확인하세요. Windows 10에서는 ‘설정 → 네트워크 및 인터넷 → 프록시’에서 해당 설정을 확인할 수 있습니다. 회사에서 설정한 프록시라면 기존 설정을 덮어쓰지 마세요.

• 트래픽 처리를 중지한 뒤 일반 웹페이지와 로컬 네트워크 장치가 테스트 전 상태로 복구됐는지 확인하세요.
• DNS를 직접 수정했다면 기록해 둔 기존 값으로 복구하세요. 무조건 자동으로 가져오도록 바꾸지 마세요.
• 인터페이스와 경로를 다시 확인해 다른 VPN이나 프록시가 계속 트래픽을 처리하고 있지 않은지 살펴보세요.
• 문제를 문의할 때는 운영체제 버전, 클라이언트 및 커널 버전, 오류 발생 시간, 민감 정보를 가린 로그를 첨부하세요. 구독 주소, 액세스 토큰과 노드 인증 정보는 삭제하세요.

TUN 설정을 확인할 때는 세 가지를 살펴보세요. 처리 대상 프로그램의 트래픽이 실제로 커널에 들어오는지, 연결에 예상한 규칙이 적용되는지, 종료 후 네트워크가 정상적으로 복구되는지입니다. 노드를 반복해서 바꾸기보다 트래픽 진입 경로, DNS, 규칙과 외부 연결을 나눠 확인하면 문제를 더 쉽게 찾을 수 있습니다.