Clash TUN 모드와 시스템 프록시 차이: 트래픽 처리 방식 비교

먼저 결론: 차이는 ‘전역 여부’가 아니라 트래픽이 들어오는 경로

브라우저와 시스템 프록시 설정을 따르는 앱만 프록시를 사용하면 된다면 시스템 프록시부터 사용하세요. 프록시 설정을 읽지 않는 명령줄 도구나 게임, 기타 UDP 트래픽까지 처리해야 한다면 TUN을 고려할 수 있습니다. 두 방식은 트래픽이 Clash 코어로 들어오는 경로를 결정합니다. Rule, Global, Direct는 코어에 들어온 뒤 트래픽을 어떤 경로로 보낼지 결정하므로, 이 두 개념을 혼동하면 안 됩니다.

TUN을 켜도 규칙에 따라 DIRECT로 처리되는 연결은 직접 연결됩니다. 시스템 프록시를 켠 상태에서 Global을 선택해도 모든 프로세스가 자동으로 프록시 설정을 따르는 것은 아닙니다. “전역 모드를 켰는데 게임이 왜 그대로지?”라는 문제는 노드를 바꾸기 전에 게임 연결이 코어에 들어오는지부터 확인해야 합니다.

시스템 프록시: 앱이 로컬 프록시 포트에 직접 연결

요청 경로와 로컬 포트

시스템 프록시는 보통 HTTP, HTTPS 등의 프록시 주소를 운영체제 설정에 등록합니다. 이 설정을 읽는 앱은 먼저 로컬 프록시 포트에 연결하고, 이후 코어가 대상 주소와 규칙에 따라 연결을 설정합니다. 로컬 혼합 포트 127.0.0.1:7890를 예로 들면 경로는 다음과 같습니다.

시스템 프록시 설정을 따르는 앱
  → 127.0.0.1:7890(HTTP / SOCKS 혼합 포트)
  → 코어 규칙 및 프록시 그룹
  → DIRECT 또는 선택한 프록시 노드
  → 대상 서비스

여기서 7890은 예시일 뿐, 모든 클라이언트가 이 포트를 사용하는 것은 아닙니다. 클라이언트 설정이나 현재 적용된 구성에서 mixed-port, port, socks-port 값을 확인하세요. HTTP 포트를 SOCKS 포트처럼 임의로 사용할 수 없습니다. 혼합 포트만 두 프록시 프로토콜을 모두 지원합니다.

HTTPS, UDP, 브라우저 확장 프로그램의 한계

HTTPS: 앱은 보통 HTTP CONNECT를 통해 대상 서버로 터널을 만듭니다. 일반적인 프록시 전달은 코어가 웹페이지의 TLS 내용을 복호화한다는 뜻이 아니며, 정상적인 프록시 사용을 위해 루트 인증서를 설치할 필요도 없습니다.
UDP: 운영체제의 HTTP 프록시 설정은 범용 UDP 전달 경로가 아닙니다. SOCKS5에는 UDP ASSOCIATE 기능이 있지만, 앱에서 이를 구현해야 하며 프록시 측과 노드도 지원해야 합니다.
브라우저: 브라우저 확장 프로그램, PAC, 자체 정책이 시스템 설정을 덮어쓸 수 있습니다. 웹페이지가 열린다고 해서 모든 연결이 같은 경로를 이용하는 것은 아닙니다. QUIC 등의 전송 방식도 브라우저의 구현과 정책에 따라 달라집니다.
터미널: 많은 명령줄 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽거나 자체 프록시 옵션만 사용합니다. 데스크톱 시스템 프록시 설정을 자동으로 따르지는 않습니다.

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 시스템 프록시를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인하세요. 설정이 등록된 것은 확인할 수 있지만, 특정 앱이 실제로 이를 사용한다는 뜻은 아닙니다.

TUN: 가상 네트워크 인터페이스로 IP 패킷 수신

TUN은 네트워크 계층에 가상 인터페이스를 제공합니다. 클라이언트나 코어가 라우팅을 설정해 조건에 맞는 IP 패킷을 이 인터페이스로 보냅니다. 코어의 프로토콜 스택이 TCP와 UDP를 처리한 뒤 규칙에 따라 아웃바운드 연결을 설정합니다. 앱에서 HTTP 또는 SOCKS 프록시를 별도로 지원할 필요가 없어, 일반적으로 시스템 프록시보다 더 많은 트래픽을 처리할 수 있습니다.

앱에서 보낸 IP 패킷
  → 운영체제 라우팅
  → TUN 가상 인터페이스
  → 코어 프로토콜 스택, DNS 매핑 및 규칙 매칭
  → DIRECT 또는 프록시 노드
  → 물리 네트워크 인터페이스를 통해 최종 연결

이 때문에 TUN에는 더 높은 권한이 필요한 경우가 많습니다. 가상 인터페이스 생성, 라우팅 변경, DNS 하이재킹에는 관리자 권한, 시스템 서비스 또는 Linux의 해당 네트워크 권한이 필요할 수 있습니다. 단순히 프록시 주소를 다른 포트로 바꾸는 기능이 아닙니다.

TUN을 켜도 모든 네트워크 공간이 처리되는 것은 아닙니다

자동 라우팅에는 제외 대상이 있을 수 있으며, 다른 VPN이 라우팅을 먼저 차지할 수도 있습니다. LAN, 특정 인터페이스, IPv6, 가상 머신, 컨테이너는 각각 확인해야 합니다. 특히 WSL2, Docker, 가상 머신의 트래픽은 별도의 네트워크 공간이나 가상 스위치를 먼저 거칠 수 있습니다. 호스트에서 TUN을 켰다고 해서 해당 환경의 DNS와 라우팅까지 올바르게 설정된 것은 아닙니다.

지원 범위 비교: 브라우저, 명령줄, 게임, LAN

사용 사례	시스템 프록시	TUN
브라우저 HTTP / HTTPS	대체로 사용 가능. 확장 프로그램과 PAC의 설정 덮어쓰기 여부 확인 필요	라우팅을 통해 트래픽이 코어에 들어오면 규칙에 따라 분기
curl, Git 등 터미널 도구	환경 변수 또는 명시적인 프록시 옵션이 필요한 경우가 많음	앱 프록시 옵션은 대개 불필요하지만, 실제 실행 환경의 라우팅 확인 필요
게임 UDP 및 음성 채팅	일반적인 HTTP 시스템 프록시로는 대개 처리할 수 없음	UDP를 받을 수 있지만, 이후 처리에는 노드와 서버의 지원도 필요
LAN 프린터, NAS	운영체제의 프록시 우회 목록을 통해 직접 연결하는 경우가 많음	LAN 규칙, 라우팅 제외 대상, 방화벽 확인 필요
필요 권한 및 변경 범위	주로 앱이 읽을 수 있는 프록시 설정 변경	가상 인터페이스, 라우팅, DNS 처리까지 영향을 줄 수 있음

게임에서 “TUN이 트래픽을 받는다”와 “게임에 적합한 노드를 사용한다”는 별개의 문제입니다. 노드가 UDP를 지원해야 하고 서버에서도 관련 트래픽 전달을 허용해야 합니다. 게임 서버 지역, 왕복 지연 시간, 지터, 패킷 손실, NAT 동작도 플레이 품질에 영향을 줍니다. 프록시 대시보드에서 HTTP 지연 시간이 60ms로 나와도 게임 UDP의 왕복 지연 시간이 60ms라는 뜻은 아니며, 음성 채팅의 안정성을 판단하는 근거도 될 수 없습니다.

사용 전 확인: 권한, 라우팅, DNS, 노드 지원

순서대로 현재 상태 저장

현재 상태 기록: 적용 중인 구성을 저장하고 시스템 프록시 포트, DNS 설정, 다른 VPN의 상태를 기록하세요. 원격으로 네트워크를 관리하는 경우에는 먼저 네트워크를 복구할 대체 수단이 있는지 확인하세요.
코어 확인: 클라이언트의 코어 정보나 로그에서 mihomo 사용 여부와 버전을 확인하세요. 클라이언트 이름만으로 같은 TUN 설정 항목을 지원한다고 판단할 수 없습니다.
권한 확인: 클라이언트가 제공하는 서비스 모드나 권한 안내에 따라 설정하세요. 서비스를 설치했는데도 실패한다면 스위치만 반복해서 전환하지 말고, 시작 로그에서 인터페이스 생성 실패, 권한 부족, 라우팅 설정 오류를 확인하세요.
충돌하는 경로를 일시적으로 비활성화: 문제를 확인하는 동안 다른 VPN과 시스템 프록시를 끄고 TUN만 남겨 두세요. 여러 경로가 동시에 활성화되면 테스트 트래픽이 어디로 가는지 확인하기 어렵습니다.
출구 인터페이스 확인: Wi-Fi, 유선 네트워크, 핫스팟을 전환한 뒤 자동으로 인식된 출구 인터페이스가 올바른지 확인하세요. 출구 인터페이스가 잘못되면 연결이 실패하거나 심각한 경우 라우팅 루프가 발생할 수 있습니다.

mihomo 설정 조각의 의미

아래 예시는 TUN과 DNS의 연동 설정만 보여 줍니다. 노드, 구독 제공자, 전체 분기 규칙은 포함하지 않으므로 그대로는 인터넷에 연결할 수 있는 완전한 설정이 아닙니다. 기존 설정에 항목을 병합하고 최상위 dns 또는 tun 키를 중복 생성하지 마세요. 클라이언트가 관리하는 항목은 클라이언트의 오버라이드 기능을 우선 사용하세요.

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
  nameserver:
    - https://dns.alidns.com/dns-query

stack: mixed는 프로토콜 스택 옵션입니다. mixed-port와는 다르며, “시스템 프록시도 함께 켜는” 설정도 아닙니다. 사용 가능한 스택과 플랫폼별 동작은 현재 코어 문서를 확인하세요.
auto-route는 코어가 라우팅을 설정해 트래픽을 처리하도록 합니다. auto-detect-interface는 아웃바운드 인터페이스를 찾는 옵션입니다. 여러 네트워크 인터페이스를 사용하거나 다른 VPN이 설치된 환경에서는 직접 확인해야 합니다.
dns-hijack의 any:53은 TUN으로 들어오는 일반 UDP DNS 요청을 처리합니다. TCP 53도 처리하려면 현재 코어의 지원 여부를 확인한 뒤 tcp://any:53을 설정하세요.
127.0.0.1:1053은 코어의 DNS 리슨 주소입니다. 운영체제 DNS 설정에 포트가 포함된 주소를 그대로 입력할 수 있다는 뜻은 아닙니다.
198.18.0.1/16은 여기서 사용하는 Fake-IP 주소 풀입니다. 합성 주소가 반환되어도 DNS 오류는 아닙니다. 단, 이후 연결이 매핑 정보를 보유한 코어로 다시 들어와야 합니다.

예시에서는 특정 DoH 업스트림을 사용하지만, 연결 가능 여부는 현재 네트워크와 DNS 아웃바운드 설정에 따라 달라집니다. 네트워크 연결이 끊긴 상태에서 DNS 옵션을 연이어 바꾸지 마세요. 먼저 DNS 요청이 코어에 들어오는지 확인한 다음 업스트림의 응답 및 연결 오류를 점검하세요.

DNS와 IPv6: TUN을 켜도 직접 연결되는 주요 원인

일반 DNS 처리만으로 암호화 DNS까지 처리되는 것은 아닙니다

UDP/TCP 53 하이재킹 규칙으로 임의의 HTTPS 연결 안에 있는 DoH 요청을 바로 식별할 수는 없습니다. DoT 요청도 자동으로 코어 DNS 질의로 바뀌지 않습니다. 브라우저에서 ‘보안 DNS’를 사용하면 자체 DNS 경로를 이용할 수 있습니다. 해당 연결 자체는 TUN을 거치더라도 코어에 같은 도메인 매핑 정보가 전달되지 않을 수 있습니다.

도메인 규칙이 예상과 다르게 적용되면 브라우저의 사용자 지정 보안 DNS를 잠시 끄고 연결을 새로 만든 뒤, 코어에 도메인과 해당 규칙이 기록되는지 확인하세요. 원인을 파악한 다음 어떤 DNS 정책을 사용할지 결정하고, 설명하기 어려운 설정 여러 개를 계속 겹쳐 쓰지 마세요.

IPv4가 정상이어도 IPv6까지 정상이라는 뜻은 아닙니다

대상 서버가 A 레코드와 AAAA 레코드를 모두 제공하면 앱이 IPv6를 우선 사용할 수 있습니다. IPv4 라우팅만 확인했다면 IPv6 트래픽은 다른 경로를 이용할 수 있습니다. IPv4와 IPv6 테스트 결과, 라우팅, 연결 기록을 각각 확인하세요. IPv6만 실패한다면 노드 전체에 문제가 있다고 단정하지 말고, 로컬 IPv6 연결과 관련 코어 설정을 확인하세요.

Fake-IP도 전체 경로가 올바르게 연결되어야 합니다. DNS가 합성 주소를 반환했는데 앱 연결이 TUN을 우회하면, 해당 주소는 일반 서버 주소처럼 공용 인터넷에서 접근할 수 없는 경우가 많습니다. 모드를 바꾼 뒤 일부 앱에서 계속 연결이 실패한다면 먼저 해당 앱의 DNS 또는 연결 캐시를 지우고, 시스템 DNS가 중지된 로컬 서비스 주소를 계속 가리키지 않는지 확인하세요.

확인 절차: ‘코어 유입’과 ‘프록시 경유’를 나눠 테스트

1단계: 로컬 프록시 포트에 직접 연결해 테스트

먼저 TUN을 끄고 코어는 실행한 상태로 둔 다음, 아래 명령으로 예시 혼합 포트에 명시적으로 연결하세요. --noproxy ""는 이번 요청의 우회 목록을 비워 NO_PROXY의 영향을 막습니다. Windows PowerShell에서는 구형 환경의 동명 별칭과 충돌하지 않도록 명령어를 curl.exe로 입력할 수 있습니다.

curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com

이 테스트는 명시적인 프록시 포트와 해당 요청의 아웃바운드 경로만 확인합니다. 시스템 프록시가 적용됐거나 UDP를 사용할 수 있다는 뜻은 아닙니다. 실패한다면 가상 인터페이스부터 조사하지 말고 포트 리슨 상태, 규칙, 노드를 먼저 확인하세요.

2단계: TUN만 켜고 이번 요청의 명시적 프록시 사용 중지

시스템 프록시를 끄고 TUN을 켠 뒤 다음 명령을 실행하세요. --proxy ""는 이번 curl 요청의 프록시 설정을 비활성화하고, --noproxy "*"는 앱 계층의 프록시를 사용하지 않도록 합니다. 운영체제의 TUN 라우팅을 우회하는 옵션은 아닙니다.

curl -4 -I --connect-timeout 10 --max-time 20 --proxy "" --noproxy "*" https://example.com
curl -6 -I --connect-timeout 10 --max-time 20 --proxy "" --noproxy "*" https://example.com

클라이언트의 ‘Connections’ 또는 연결 목록에서 해당 시간대의 요청을 찾고, ‘Logs’에서 규칙, 프록시 그룹, 최종 아웃바운드 경로를 비교하세요. 일부 UI는 TUN 인바운드 유형을 표시합니다. 표시되지 않으면 가상 인터페이스의 트래픽 카운터와 라우팅을 함께 확인할 수 있습니다. 웹페이지가 성공적으로 열렸다는 사실만으로는 TUN 처리 여부를 증명할 수 없습니다. 원래 직접 연결이 가능했을 수도 있습니다.

3단계: 실제 앱으로 UDP 확인

게임 서버에 접속하거나 음성 채팅을 시작하고 테스트 시간을 기록한 뒤, 연결 목록에서 UDP 연결, 대상 주소, 적용 규칙, 프록시 경로를 확인하세요. 연결이 코어에 들어왔지만 DIRECT에 매칭되면 해당 규칙을 조정하세요. 노드에 매칭되었는데도 계속 시간 초과가 발생하면 노드의 UDP 지원과 서버 측 제한을 확인하세요. 브라우저 속도 테스트나 ICMP ping으로 이 단계를 대신할 수 없습니다.

문제 진단과 원상 복구: 한 번에 한 항목만 변경

브라우저는 되는데 터미널은 안 됨: 시스템 프록시를 사용하는 경우 터미널 환경 변수와 프로그램의 프록시 옵션을 먼저 확인하세요. TUN을 사용하는 경우 터미널이 컨테이너, WSL2 또는 원격 호스트에서 실행되는지 확인하세요.
TUN을 켜자마자 인터넷 연결이 끊김: 먼저 TUN을 끄고 기존 상태를 복구한 다음, 서비스 권한, 가상 인터페이스 생성, 기본 라우팅, 물리 출구, DNS 업스트림을 확인하세요. 라우팅 충돌을 피하려면 다른 VPN도 잠시 종료하세요.
게임이 프록시를 거치지만 더 느려짐: 게임 서버까지의 경로, UDP 패킷 손실과 지터를 확인하고 같은 시간대의 직접 연결과 프록시 연결 결과를 비교하세요. HTTP 지연 시간만으로 게임용 노드를 선택하지 마세요.
NAS나 프린터에 연결할 수 없음: LAN 주소 대역이 직접 연결 규칙에 매칭되는지, 라우팅 제외가 필요한지 확인하고 로컬 방화벽도 점검하세요. DIRECT는 코어의 아웃바운드 결정일 뿐, 패킷이 가상 인터페이스를 완전히 우회한다는 뜻은 아닙니다.
클라이언트를 종료한 뒤 네트워크에 문제가 생김: 시스템 프록시가 종료된 포트를 계속 가리키는지, DNS가 중지된 로컬 리슨 주소를 가리키는지, TUN 라우팅과 가상 인터페이스가 정상적으로 복구되었는지 확인하세요.

선택 기준은 간단합니다. 앱이 프록시 설정을 따르고 웹 접속이 주된 목적이라면 시스템 프록시를 사용하세요. 프록시를 인식하지 못하는 프로그램이나 UDP까지 처리해야 한다면 TUN을 켜고 권한, 라우팅, DNS, 노드 지원을 하나씩 확인하세요. 지원 범위가 넓어진다고 속도가 반드시 빨라지는 것은 아닙니다. 모든 연결이 어떤 경로로 들어오고 나가는지 설명할 수 있어야 설정이 완료된 것입니다.