Clash TUN 모드와 시스템 프록시 차이: 트래픽 처리 방식과 사용 사례

핵심 차이: 앱이 프록시에 연결할까, 라우팅으로 가상 네트워크 어댑터에 전달할까

시스템 프록시는 앱의 지원이 필요하고, TUN은 운영체제 라우팅을 이용합니다. 두 방식의 적용 범위를 판단하는 출발점입니다. 시스템 프록시는 보통 시스템 네트워크 설정에 로컬 HTTP 프록시 주소를 지정합니다. 이 설정을 지원하는 앱은 Clash의 로컬 수신 포트에 연결되고, 이후 커널이 규칙을 적용합니다. 시스템 설정을 무시하거나 별도의 프록시 설정을 사용하거나 직접 네트워크 연결을 생성하는 프로그램은 이 경로를 이용하지 않을 수 있습니다.

TUN은 3계층 가상 네트워크 인터페이스를 만들어 라우팅 조건에 맞는 IP 패킷을 커널로 전달합니다. 앱이 로컬 프록시 주소를 알 필요가 없어 직접 인터넷에 연결하는 프로그램도 더 폭넓게 처리할 수 있습니다. 하지만 TUN을 켰다고 해서 모든 트래픽이 원격 노드를 경유하는 것은 아닙니다. 라우팅 제외 항목, 다른 VPN, 인터페이스 우선순위와 프록시 규칙에 따라 실제 경로가 달라집니다.

클라이언트, 커널, 구독의 역할

클라이언트: 시스템 프록시 전환, 서비스 관리, 설정 편집, 연결 목록 기능을 제공합니다. 프로젝트마다 메뉴 이름과 권한 부여 방식은 다를 수 있습니다.
커널: 프로토콜 처리, DNS, 규칙 매칭, TUN 네트워크 스택을 담당합니다. Clash, Clash Premium, Clash Meta(이후 mihomo라는 이름 사용)의 기능을 동일하다고 볼 수는 없습니다.
구독: 노드나 전체 설정을 제공합니다. 정책 그룹, 규칙, DNS에 영향을 줄 수 있지만, 가상 네트워크 어댑터에 필요한 운영체제 권한을 대신하지는 않습니다.

이 문서의 설정 필드는 mihomo를 기준으로 합니다. 먼저 클라이언트의 커널 정보나 시작 로그에서 실제 실행 중인 커널을 확인한 뒤, 해당 필드의 지원 여부를 살펴보세요. 앱 이름만 보고 TUN 지원 여부를 판단하지 마세요.

시스템 프록시: 브라우저에 적합하지만 명령줄 도구는 별도 확인 필요

Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」→「수동 프록시 설정」에서 시스템 프록시 주소를 확인할 수 있습니다. 클라이언트의 HTTP 또는 mixed 수신 포트가 7890이라고 가정하면, 주소에는 보통 127.0.0.1, 포트에는 7890을 입력합니다. 포트는 예시일 뿐이므로 현재 적용 중인 설정과 일치하는지 확인해야 합니다.

브라우저는 대체로 시스템 프록시를 사용하지만, 브라우저 확장 프로그램이나 별도 프록시 설정, 우회 목록에 따라 결과가 달라질 수 있습니다. 시스템의 사용자 프록시 설정과 WinHTTP 설정도 서로 다른 방식입니다. 브라우저가 인터넷에 연결된다고 해서 백그라운드 서비스와 모든 데스크톱 앱이 같은 프록시를 사용한다고 단정할 수는 없습니다.

curl로 ‘노드 사용 가능 여부’와 ‘시스템 프록시 적용 여부’ 구분하기

아래 두 명령은 Windows 터미널에서 사용할 수 있습니다. 첫 번째는 HTTP 프록시를 명시하고, 두 번째는 직접 요청을 보냅니다. 두 번째 명령의 프록시 사용 여부는 환경 변수 등의 설정에 따라 달라지므로, 반드시 직접 연결하는 비교 기준으로 보면 안 됩니다.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --connect-timeout 10 -I https://example.com

프록시를 명시한 요청은 성공하지만 일반 요청은 실패한다면, 노드를 바로 바꾸기보다 터미널 환경 변수와 앱의 프록시 지원 여부부터 확인하세요.
127.0.0.1:7890에 연결할 수 없다는 메시지가 표시되면 수신 포트, 커널 상태, 로컬 방화벽을 확인하세요.
로컬 프록시 연결은 성공했지만 이후 TLS 또는 원격 연결이 실패한다면 노드 핸드셰이크, DNS, 규칙 매칭 기록을 확인하세요.

macOS 또는 Linux에서는 환경 변수를 지정해 단일 명령을 실행할 수 있습니다. 예: HTTPS_PROXY=http://127.0.0.1:7890 curl -I https://example.com. 변수 이름은 HTTPS 요청에 사용할 프록시 설정을 나타내며, 프록시 주소에는 HTTP 프로토콜을 사용할 수 있습니다. 그렇다고 로컬 수신 포트에 TLS를 반드시 활성화해야 하는 것은 아닙니다. 대소문자별 변수 이름과 SOCKS 지원 여부는 도구마다 다르므로 해당 도구의 문서를 확인하세요.

TUN 모드: 더 많은 연결을 처리하지만 권한과 라우팅 설정이 필요

TUN은 IP 패킷을 받아 커널 네트워크 스택에서 TCP, UDP 등의 트래픽을 처리한 뒤 설정에 따라 아웃바운드 연결을 생성합니다. 게임이나 명령줄 도구가 HTTP 프록시에 직접 연결하도록 설정할 필요가 없어 앱별 프록시를 구성할 수 없는 경우에 적합합니다. 인터페이스 생성, 라우팅 조정, DNS 처리를 위해 클라이언트에 관리자 권한이나 서비스 모드 또는 해당 시스템의 권한 승인이 필요할 수 있습니다.

mihomo 최소 설정 필드 예시

아래는 설정 일부이며 전체 구독이 아닙니다. 기존 노드, 정책 그룹, 규칙, DNS 모듈이 올바르게 구성되어 있다고 가정합니다. 클라이언트가 오버라이드 방식으로 최종 설정을 생성할 수 있으므로, 구독 업데이트로 덮어써질 수 있는 원본 파일만 수정하지 말고 실제 적용된 설정을 확인하세요.

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

enable: TUN 기능을 활성화합니다. 인터페이스 생성에 실패하면 먼저 권한과 서비스 로그를 확인하세요.
stack: 네트워크 스택 구현을 선택합니다. mixed는 mihomo의 선택지 중 하나이며, 모든 구형 커널에 그대로 적용할 수는 없습니다.
auto-route: 트래픽 처리에 필요한 라우팅을 자동으로 설정합니다. 모든 인터페이스와 예외 경로를 포괄한다는 뜻은 아닙니다.
auto-detect-interface: 아웃바운드 인터페이스 선택을 돕습니다. 여러 VPN을 동시에 실행하면 수동 확인이 필요할 수 있습니다.
dns-hijack: 조건에 맞는 DNS 요청을 커널 DNS 모듈로 전달합니다. 위 예시는 UDP 53 포트에 해당하며, 모든 암호화 DNS를 포함하지는 않습니다.

사용 사례 비교: 명령줄 도구·게임·UWP 앱에 적합한 방식

사용 사례	시스템 프록시 동작	TUN 사용 조건
브라우저 웹 페이지	대체로 사용 가능, 확장 프로그램과 우회 항목 확인 필요	처리할 수 있지만 웹 브라우징만 한다면 보통 활성화할 필요 없음
curl, Git 등 도구	프록시 매개변수나 환경 변수를 별도로 지정해야 하는 경우가 많음	라우팅 적용 범위에 따라 앱별 설정을 줄일 수 있음
UDP를 사용하는 게임 연결	일반적으로 HTTP 시스템 프록시로는 처리할 수 없음	UDP 아웃바운드 지원과 올바른 규칙 필요
격리된 UWP 앱	루프백 제한으로 로컬 프록시에 접근하지 못할 수 있음	로컬 HTTP 프록시 경로를 우회할 수 있지만 실제 동작 확인 필요
LAN 및 기업 네트워크 리소스	프록시 우회 목록을 사용할 수 있음	LAN 라우팅, DNS, VPN 충돌 확인 필요

게임: 먼저 UDP 지원을 확인한 뒤 지연 시간 비교

게임 다운로드에는 보통 TCP/HTTPS가 사용되지만, 실제 게임 플레이에는 UDP가 쓰일 수 있습니다. 런처에서 다운로드가 성공했다고 해서 게임 연결도 처리되고 있다는 뜻은 아닙니다. 연결 목록에서 프로세스, 대상 주소, 네트워크 유형별로 규칙이 적용되는지 확인하고, 정책 그룹에서 최종 선택한 노드가 UDP를 지원하는지 살펴보세요. 일부 게임은 NAT, 지역 매칭, 부정행위 방지 정책의 영향도 받으므로 TUN이 이런 조건을 개선한다고 보장할 수는 없습니다.

노드 목록에서 측정한 HTTP 지연 시간만으로 게임 지연 시간을 판단할 수도 없습니다. 같은 서버와 비슷한 시간대에 직접 연결과 프록시 연결을 각각 5분간 테스트하고, 게임 내 지연 시간과 패킷 손실을 기록해 보세요. 예를 들어 ‘웹 탐지 80ms, 게임 플레이 140ms’는 측정 대상이 서로 다른 경우를 보여주는 예일 뿐, 설정 오류의 근거가 되지는 않습니다. 같은 지표끼리 전후 변화를 비교하세요.

UWP: 루프백 제한과 네트워크 장애 구분하기

AppContainer로 격리된 일부 앱은 로컬 루프백 프록시에 직접 접근할 수 없습니다. 이런 경우 앱별 루프백 예외를 설정해야 합니다. 문제를 확인한다고 모든 앱에 일괄 허용을 적용하지 마세요. 먼저 대상 앱이 실제로 이 제한을 받는지 확인한 뒤, 클라이언트에서 제공하는 도구나 Windows의 해당 관리 기능을 사용하세요. TUN을 사용하면 앱이 로컬 HTTP 프록시에 직접 접속하지 않게 될 수 있지만, 로그인 서비스, 인증서, 앱 자체 DNS, 원격 지역 제한까지 해결된다고 보장할 수는 없습니다.

DNS와 Fake-IP: TUN을 켰다고 DNS 누수가 해결되는 것은 아닙니다

DNS는 도메인 이름의 해석 방식을 정하고, 커널이 도메인 규칙에 따라 연결을 매칭할 수 있는지에도 영향을 줍니다. Fake-IP 모드는 도메인에 가상 주소를 반환하고 이후 연결에서 매핑을 이용해 도메인 정보를 복원합니다. 원격 노드나 암호화 프로토콜은 아닙니다. Fake-IP와 TUN은 함께 사용하는 경우가 많지만 서로 다른 기능입니다.

시스템 프록시를 사용할 때 HTTP CONNECT 요청은 보통 대상 도메인 처리를 프록시에 맡길 수 있지만, 앱이 자체적으로 DNS를 조회하거나 별도 DNS를 사용할 수도 있습니다. TUN에서는 라우팅과 DNS 하이재킹을 통해 기존 DNS 요청을 커널로 전달할 수 있습니다. 하지만 브라우저 내장 DoH, Android 비공개 DNS 또는 다른 암호화 DNS 경로까지 any:53을 설정했다는 이유만으로 같은 해석 정책에 모두 포함되지는 않습니다.

클라이언트의 최종 설정에서 DNS 모듈이 활성화되어 있는지 확인하고 enhanced-mode와 업스트림 DNS 설정을 살펴보세요.
시스템 리졸버, 브라우저 보안 DNS, 다른 VPN을 확인해 각 요청을 어떤 구성 요소가 처리하는지 파악하세요.
모드를 바꾼 뒤 앱 연결을 다시 설정하고, 필요하면 DNS 캐시를 비워 이전 조회 결과가 판단에 영향을 주지 않게 하세요.
DNS 로그와 연결 로그를 함께 확인해 트래픽 경로를 파악하세요. 탐지 웹페이지에 표시된 리졸버의 위치만으로 판단하지 마세요.

탐지 페이지에 현지 통신사의 DNS 리졸버가 표시되면 추가로 확인해야 한다는 신호이지, 그것만으로 결론을 내릴 수는 없습니다. 분할 라우팅 설정에 따라 직접 연결 도메인은 의도적으로 현지 DNS를 사용할 수 있습니다. 지정된 경로로 해석해야 하는 도메인이 실제로 예상과 다른 경로를 사용했는지가 핵심입니다.

확인 순서: 트래픽 처리 설정은 한 번에 하나씩 변경

처음 문제를 점검할 때 TUN, 시스템 프록시, DNS 모드, 노드를 한꺼번에 바꾸지 마세요. 변수가 많으면 네트워크가 복구되어도 원인을 특정하기 어렵습니다. 먼저 정상 작동이 확인된 노드 하나를 고정한 다음 아래 순서대로 확인하세요.

로컬 진입점 확인: TUN을 끄고 프록시 매개변수를 명시해 테스트 주소에 접속합니다. 예시 포트 7890을 현재 커널이 실제로 수신하고 있는지 확인하세요.
시스템 프록시 확인: 시스템 프록시를 켜고 브라우저에서 새 연결을 만든 다음, 연결 목록에 대상 도메인과 적용 규칙이 표시되는지 확인하세요.
TUN만 따로 확인: 시스템 프록시와 앱에 직접 지정한 프록시를 잠시 끄고 TUN을 활성화한 뒤 대상 앱을 다시 실행해 기존 연결이 재사용되지 않도록 하세요.
아웃바운드 확인: 적용된 규칙과 정책 그룹, 최종 노드를 확인하세요. 연결이 커널에 들어왔다는 사실만으로 원격 프록시를 경유한다고 볼 수는 없습니다.
실제 사용 결과 확인: 브라우저는 웹 페이지, 게임은 실제 플레이, 터미널은 대상 저장소나 API로 테스트하세요. 하나의 속도 측정 결과로 모든 사용 사례를 대신 확인하지 마세요.

TUN을 켠 뒤 인터넷 연결이 끊김

먼저 TUN을 끄고 기본 네트워크가 복구되는지 확인하세요. 그런 다음 인터페이스 생성 여부, 서비스 권한, 다른 VPN의 기본 라우트 선점 여부, DNS 연결 상태를 차례로 확인합니다. 로그에 연결 재시도가 반복되면 노드 서버 주소의 DNS 조회와 아웃바운드 경로가 루프를 형성하는지도 살펴보세요. 인터페이스 선택 오류를 감추기 위해 라우팅 규칙을 계속 추가하지 마세요.

LAN 프린터 또는 기업 내부망에 연결할 수 없음

192.168.10.0/24처럼 실제 내부망 대역을 기록한 뒤 직접 연결 규칙과 라우팅 제외 설정을 확인하세요. 프록시 규칙의 DIRECT는 커널에 들어온 뒤 직접 아웃바운드로 연결하라는 뜻입니다. 라우팅 제외는 패킷이 TUN으로 들어오지 않게 할 수 있으므로 서로 다른 계층의 설정입니다. 기업 VPN은 전용 DNS가 필요할 수도 있으므로 IP 규칙 하나를 추가했다고 점검이 끝난 것은 아닙니다.

선택 가이드: 필요한 처리 범위에 맞춰 복잡도를 높이세요

주로 웹 페이지에 접속: 시스템 프록시를 우선 사용하고 브라우저 연결 기록으로 적용 여부를 확인하세요.
개발 도구 몇 개만 사용: 각 도구에 HTTP 또는 SOCKS 프록시를 직접 설정하세요. 적용 범위가 명확하고 재현하기 쉽습니다.
시스템 프록시를 따르지 않는 앱이 여러 개: TUN을 고려하고 권한, DNS, UDP, LAN 접근을 중점적으로 확인하세요.
기업 VPN도 함께 실행: 먼저 조직의 네트워크 요구 사항을 확인하고 라우팅과 DNS가 함께 작동하는지 테스트하세요. 두 가상 네트워크가 문제없이 겹쳐 쓸 수 있다고 가정하지 마세요.

안정적으로 작동하는 것을 확인한 뒤에는 클라이언트 설계에 따라 시스템 프록시와 TUN을 함께 사용할 수 있지만, 문제를 해결하는 동안에는 각각 따로 테스트해야 합니다. 두 기능을 동시에 켜도 반드시 프록시 처리가 중복되는 것은 아니며, 처리 범위가 자동으로 넓어지는 것도 아닙니다. 일부 앱은 로컬 프록시에 직접 연결하고 다른 연결은 가상 네트워크 어댑터를 거칠 수 있습니다. 스위치를 더 많이 켜기보다 경로를 명확하게 하나씩 확인하는 것이 중요합니다.