TUN 모드와 시스템 프록시의 차이: 트래픽 가로채기 계층과 작동 방식 비교

핵심 차이: 프록시 설정과 가상 네트워크 어댑터는 서로 다른 계층에 있다

시스템 프록시와 TUN 모드는 모두 트래픽을 Clash Meta(mihomo) 코어로 전달하지만 진입점이 다릅니다. 시스템 프록시는 운영체제에 HTTP, HTTPS 또는 SOCKS 프록시 주소를 등록합니다. 예를 들어 127.0.0.1:7890과 같습니다. 앱은 이 설정을 읽은 뒤 요청을 로컬 프록시 포트로 직접 전달합니다. 반면 TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅 규칙에 따라 조건에 맞는 IP 패킷을 코어로 보냅니다.

이 차이가 적용 범위를 결정합니다. 브라우저, 시스템 업데이트 도구, 많은 데스크톱 앱은 대체로 시스템 프록시를 읽으므로 시스템 프록시만 켜도 충분합니다. 일부 게임 런처, 명령줄 프로그램, UDP 기반 통신 앱, 자체 네트워크 스택을 구현한 앱은 시스템 프록시를 무시할 수 있습니다. 이때는 TUN이 트래픽을 가로채기 쉽습니다.

비교 항목	시스템 프록시	TUN 모드
가로채기 진입점	운영체제 프록시 설정 또는 앱 내부 프록시 설정	가상 네트워크 어댑터와 시스템 라우팅 테이블
주요 프로토콜	HTTP、HTTPS、SOCKS	IP 계층의 TCP 및 UDP 트래픽
앱의 협조	앱이 프록시 설정을 읽어야 함	앱이 대체로 프록시 존재를 인식할 필요가 없음
활성화 권한	대개 일반 사용자 권한	관리자 권한 또는 네트워크 확장 권한이 필요한 경우가 많음
문제 해결 범위	포트, 앱 프록시 설정, 프로토콜 지원 여부	가상 네트워크 어댑터, 라우팅, DNS, 방화벽, 인터페이스 충돌
적합한 사용 사례	브라우저 및 일반 데스크톱 앱	게임, 명령줄 도구, UDP 앱, 전체 트래픽 가로채기

시스템 프록시가 요청을 mihomo로 전달하는 방식

앱이 프록시 주소를 직접 읽어야 함

클라이언트에서 “시스템 프록시” 스위치를 켜면 클라이언트가 로컬 프록시 주소를 운영체제에 기록합니다. Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 현재 설정을 확인할 수 있습니다. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 인터페이스→「세부사항」→「프록시」에서 HTTP, HTTPS, SOCKS 항목을 확인할 수 있습니다.

mihomo의 혼합 포트가 7890이라고 가정하면, 브라우저는 시스템 설정을 읽은 뒤 요청을 127.0.0.1:7890으로 보냅니다. 코어는 도메인, 대상 주소, 연결 정보를 가져온 다음 rules를 위에서부터 순서대로 매칭하고, 최종적으로 DIRECT, REJECT 또는 특정 정책 그룹을 선택합니다. 시스템 프록시는 “요청을 받아들이는” 역할만 하며 규칙 모드, 노드 선택, DNS 정책을 바꾸지는 않습니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

mixed-port는 HTTP와 SOCKS 요청을 모두 받습니다. 일반적인 기본값은 7890이지만 클라이언트에 따라 7897, 7899 또는 다른 포트가 할당될 수 있습니다. 설정을 확인할 때는 예시 포트가 아니라 클라이언트에 표시된 실제 리슨 포트를 기준으로 삼아야 합니다.

시스템 프록시를 우회할 수 있는 프로그램

앱이 연결 로직을 직접 구현하고 운영체제 프록시 설정을 명시적으로 무시하는 경우
명령줄 도구가 환경 변수를 읽지 않거나 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY가 설정되지 않은 경우
게임이나 실시간 통신 프로그램이 주로 UDP를 사용하는 경우. 시스템 HTTP 프록시는 이러한 데이터를 전달할 수 없습니다.
샌드박스, 가상 머신, 컨테이너 또는 서브시스템이 독립적인 네트워크 환경을 사용해 호스트의 프록시 주소를 직접 상속하지 못하는 경우
앱이 SOCKS만 지원하지만 시스템에는 HTTP 프록시만 등록되어 있거나, 반대로 HTTP 프록시만 읽는 경우

명령줄 프로그램은 흔한 예입니다. 시스템 프록시를 사용한 뒤에도 curl이 직접 연결된다면 로컬 프록시를 명시해 먼저 확인할 수 있습니다.

curl --proxy http://127.0.0.1:7890 https://example.com

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

프록시를 명시하면 접속되지만 명령을 직접 실행하면 접속되지 않는다면 mihomo 포트와 규칙은 대체로 정상이며, 문제는 프로그램이 시스템 프록시를 읽는지 여부에 집중됩니다. 이때 바로 노드나 구독을 조정할 필요는 없습니다.

TUN 모드가 TCP, UDP, DNS를 가로채는 방식

가상 인터페이스와 자동 라우팅

TUN 모드가 시작되면 클라이언트가 가상 네트워크 인터페이스를 만듭니다. mihomo는 auto-route를 통해 라우팅을 추가하고 대상 트래픽을 해당 인터페이스로 보낼 수 있습니다. 앱은 여전히 대상 서버에 직접 연결한다고 생각하지만, 패킷은 먼저 mihomo로 들어갑니다. 코어가 연결 대상 복원과 규칙 매칭을 수행한 뒤 직접 연결 또는 프록시 아웃바운드로 전송합니다.

mihomo v1.19 계열에서 사용할 수 있는 필드를 예로 들면 기본 설정에 다음 항목을 포함할 수 있습니다. 그래픽 클라이언트는 대개 이러한 필드를 자동으로 관리하므로, 직접 편집하기 전에 구독 업데이트 시 클라이언트가 설정을 덮어쓰는지 확인해야 합니다.

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

enable은 TUN 인터페이스의 활성화 여부를 제어합니다.
stack은 네트워크 스택 구현을 선택합니다. mixed는 여러 처리 방식을 조합하므로 일반적인 시작점으로 적합합니다.
dns-hijack은 조건에 맞는 DNS 요청을 mihomo DNS 모듈로 전달합니다.
auto-route는 필요한 라우팅을 자동으로 추가해 라우팅 테이블을 수동으로 관리하는 부담을 줄입니다.
auto-detect-interface는 현재 기본 출구 인터페이스(예: Wi-Fi 또는 유선 네트워크 어댑터)를 식별하려고 시도합니다.
strict-route는 라우팅 제약을 강화해 트래픽이 TUN을 우회할 가능성을 낮춥니다. 다만 기업용 VPN이나 가상 머신 네트워크와의 충돌이 드러날 수도 있습니다.

TUN이 가로채는 것은 시스템 라우팅에 따라 가상 인터페이스로 들어온 패킷입니다. 어떤 상황에서도 기기의 모든 연결을 처리한다는 뜻은 아닙니다. 코어 자체의 연결, 로컬 네트워크 예약 주소, 명시적으로 제외된 라우팅, 다른 VPN이 먼저 가로챈 트래픽, 운영체제가 제한하는 특수 서비스는 여전히 다른 경로를 사용할 수 있습니다.

DNS가 TUN 문제 해결에서 중요한 이유

앱은 보통 연결을 시작하기 전에 도메인을 확인합니다. DNS 조회가 로컬 네트워크를 통해 이루어지고 이후 TCP 연결만 TUN으로 들어가면, 해석 결과와 프록시 출구 위치가 일치하지 않거나 규칙이 IP만 인식하거나 오염된 결과가 캐시되는 문제가 생길 수 있습니다. TUN을 켠 뒤에는 mihomo의 DNS 모듈, dns-hijack, 규칙 설정이 서로 맞물려 있는지 함께 확인해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

fake-ip 모드는 예약 주소 대역에서 임시 주소를 할당하고, 코어가 매핑 정보를 바탕으로 원래 도메인을 복원합니다. 일부 로컬 네트워크 장치 검색, 프린터 서비스, 오래된 게임 또는 실제 DNS 응답에 의존하는 소프트웨어에는 fake-ip가 적합하지 않을 수 있습니다. 이 경우 fake-ip-filter로 해당 도메인을 제외하거나 클라이언트 기능에 맞는 다른 강화 모드를 사용해야 합니다.

호환성, 성능, 권한 사이에서 어떻게 선택할까

적용 범위만이 유일한 기준은 아님

시스템 프록시의 장점은 동작이 명확하다는 점입니다. 앱이 로컬 포트에 연결하고 mihomo 로그에서 요청 도메인, 규칙 매칭, 정책 그룹 결과를 직접 확인할 수 있습니다. 시스템 프록시를 끄면 운영체제가 원래 설정으로 돌아가므로 라우팅 테이블과 가상 인터페이스에 미치는 영향도 적습니다. 일상적인 웹 이용, 코드 호스팅, 일반 데스크톱 소프트웨어에는 대체로 이 방식이 적합합니다.

TUN의 가치는 호환성과 통합된 트래픽 가로채기에 있습니다. 프록시 설정을 읽지 않는 TCP 앱을 처리할 수 있고 다양한 UDP 환경도 지원합니다. 대신 데이터가 가상 인터페이스, 네트워크 스택 변환, 라우팅 판단을 거치므로 문제를 해결할 때 드라이버, 권한, DNS, 다른 네트워크 소프트웨어까지 고려해야 합니다.

성능 차이는 동일한 조건에서 측정해야 함

동일한 Windows 11 24H2 기기, 동일한 노드, mihomo v1.19.x, 규칙 모드, DNS 설정으로 HTTPS 요청 100회를 실행하면 시스템 프록시와 TUN의 연결 시간 중앙값 차이는 수 밀리초에 불과할 수 있습니다. 한 번의 로컬 테스트에서는 시스템 프록시 중앙값이 184ms, TUN이 189ms였습니다. 더 먼 노드로 바꾸자 두 방식 모두 420ms를 넘었습니다. 이는 일반적으로 가로채기 방식보다 노드 경로와 대상 서버가 지연 시간에 더 큰 영향을 준다는 뜻입니다.

테스트할 때는 최소한 노드, 규칙, DNS, 대상 URL, 네트워크 인터페이스를 고정하고 50~100회의 결과를 각각 기록하세요. 속도 측정 페이지를 한 번 실행해 최고치만 비교하면 캐시, 혼잡, 서버 부하를 TUN 오버헤드로 오해하기 쉽습니다.

웹페이지와 다운로드 속도가 이상할 때: 동일한 노드에서 직접 연결, 시스템 프록시, TUN을 차례로 비교합니다.
게임 지연 시간이 이상할 때: UDP가 가로채졌는지와 규칙이 게임 서버를 예상한 정책 그룹으로 보냈는지를 함께 확인합니다.
CPU 사용량이 이상할 때: TUN 스위치만 보지 말고 연결 수, 로그 수준, 규칙 규모, DNS 조회량을 확인합니다.
대기 중 배터리 소모가 클 때: 백그라운드 연결 빈도, 로컬 네트워크 브로드캐스트, 클라이언트의 가상 인터페이스 지속 재생성 여부를 확인합니다.

플랫폼별 권한 차이

Windows에서 가상 네트워크 어댑터를 만들고 라우팅을 추가하거나 네트워크 구성 요소를 설치하려면 대개 관리자 권한이 필요합니다. macOS에서는 네트워크 확장 또는 VPN 구성을 허용해야 합니다. Linux에서는 일반적으로 CAP_NET_ADMIN 권한이 필요하며 TUN 장치 생성과 정책 라우팅 변경이 허용되어야 합니다. Android와 iOS의 그래픽 클라이언트는 대개 시스템 VPN 인터페이스를 사용해 유사한 방식으로 트래픽을 가로채므로, 시스템 상태 표시줄에 VPN 아이콘이 나타납니다.

권한 요청에 성공했다고 해서 라우팅이 반드시 올바른 것은 아닙니다. Wi-Fi에서 유선 네트워크로 전환하거나 가정용 네트워크에서 핫스팟으로 바꾸거나 절전 모드에서 깨어난 뒤 기본 인터페이스가 달라지면 자동 감지 결과를 다시 설정해야 할 수 있습니다. “부팅 직후에는 정상인데 네트워크를 바꾸면 연결이 끊기는” 경우 TUN을 끄고 3~5초 기다린 다음 다시 켜면서 로그의 기본 인터페이스를 확인하세요.

사용 사례에 따라 시스템 프록시와 TUN 선택

시스템 프록시를 우선 사용할 상황

주로 브라우저, 이메일, 메신저, 일반 개발 도구를 사용하는 경우
특정 요청이 mihomo로 들어갔는지 빠르게 확인하고 싶은 경우
기기에서 기업용 VPN을 함께 실행하며 두 도구가 기본 라우팅을 두고 경쟁하지 않기를 원하는 경우
소수의 앱만 프록시를 사용하고 나머지 앱은 기존 네트워크 경로를 유지하려는 경우
현재 계정에 가상 네트워크 어댑터 또는 네트워크 확장 권한을 부여하기 어려운 경우

특정 앱에 별도의 프록시 설정이 있다면 전체 시스템 프록시를 켜지 않고 127.0.0.1과 실제 혼합 포트만 입력할 수도 있습니다. 이렇게 하면 영향 범위를 하나의 앱으로 제한할 수 있어 브라우저 설정, 다운로드 도구 또는 개발 환경을 디버깅할 때 유용합니다.

TUN을 활성화하는 편이 적합한 상황

앱이 시스템 프록시를 명확히 무시하지만 연결에는 규칙 적용이 필요한 경우
일부 게임, 음성 통화 또는 실시간 통신 트래픽처럼 UDP를 가로채야 하는 경우
명령줄 도구, 데스크톱 앱, 백그라운드 서비스가 동일한 규칙을 따르기를 원하는 경우
앱에 HTTP 또는 SOCKS 프록시 주소를 입력할 수 없는 경우
원래 직접 연결 IP만 보이는 연결에 도메인 규칙을 적용해야 하고 관련 DNS 설정을 이미 구성한 경우

많은 클라이언트에서는 시스템 프록시와 TUN을 동시에 켤 수 있습니다. 그렇다고 동일한 연결에 효과가 두 배로 적용되는 것은 아니며 오히려 판단 경로가 늘어납니다. 시스템 프록시를 지원하는 앱은 먼저 로컬 포트에 연결하고 나머지 트래픽은 TUN이 가로챕니다. 처음 설정할 때는 한 번에 한 방식만 활성화하고 안정성을 확인한 뒤 조합이 필요한지 결정하는 것이 좋습니다.

인터넷 끊김, 프록시 누락, 연결 실패 시 문제 해결 방법

시스템 프록시 문제 해결 단계

mihomo 코어가 실행 중이고 클라이언트 상태가 “코어 중지”가 아닌지 확인합니다.
로컬 리슨 포트가 시스템 프록시에 입력한 값과 일치하는지 확인합니다. 예: 127.0.0.1:7890
Windows의 「설정」→「네트워크 및 인터넷」→「프록시」에서 주소와 포트를 확인하고, macOS 네트워크 프록시 화면에서 활성화된 프로토콜을 확인합니다.
curl --proxy로 프록시를 명시해 요청하여 “로컬 포트 오류”와 “앱이 프록시를 읽지 않음”을 구분합니다.
클라이언트 로그 수준을 일시적으로 info 또는 debug로 높여 요청이 표시되는지, 어느 규칙과 매칭되는지 확인합니다.
규칙 모드로 전환한 뒤 확실히 작동하는 정책 그룹을 선택해 모드 문제를 포트 문제로 오해하지 않도록 합니다.

클라이언트를 종료한 뒤 웹페이지가 열리지 않는다면, 시스템 프록시 주소가 이미 리슨을 중단한 로컬 포트를 가리키고 있을 가능성이 큽니다. 먼저 운영체제의 수동 프록시를 끈 다음 클라이언트를 다시 시작하세요. 그래픽 클라이언트의 “시스템 프록시 복원” 기능으로 남은 설정을 정리할 수도 있습니다.

TUN 모드 문제 해결 단계

시스템 프록시를 끄고 TUN만 남겨 경로의 변수를 줄입니다.
클라이언트에 관리자 권한, 네트워크 확장 권한 또는 Linux 네트워크 관리 권한이 있는지 확인합니다.
가상 인터페이스가 정상적으로 생성되었는지, 로그에 라우팅 추가 실패가 표시되는지 확인합니다.
기본 출구가 현재 사용하는 Wi-Fi, 유선 네트워크 어댑터 또는 모바일 핫스팟으로 감지되었는지 확인합니다.
다른 VPN, 게임 가속기, 라우팅을 변경하는 가상 네트워크 소프트웨어를 일시적으로 종료합니다.
IP 주소와 도메인을 각각 테스트합니다. IP는 연결되지만 도메인이 실패하면 DNS를 우선 확인합니다.
라우터 관리 페이지 같은 로컬 네트워크 주소를 테스트합니다. 접속되지 않으면 사설 네트워크 대역 규칙과 엄격한 라우팅 설정을 확인합니다.
TUN을 끈 뒤 라우팅이 복구될 때까지 기다렸다가 다시 켜서 이전 인터페이스 상태가 남지 않도록 합니다.

로그에 연결 기록은 있지만 대상에 도달할 수 없다면 규칙 결과, 노드 상태, DNS를 중점적으로 확인합니다. 해당 앱의 연결 기록이 로그에 전혀 없다면 시스템 라우팅, 인터페이스 충돌, 앱이 다른 네트워크 환경을 사용하는지 확인합니다. 이렇게 원인을 나누어 판단하는 편이 설정을 바로 삭제하는 것보다 더 많은 정보를 제공합니다.

현상	우선 확인할 항목	검증 방법
브라우저는 되지만 게임은 안 됨	UDP 가로채기와 게임 규칙	시스템 프록시를 끄고 TUN만 활성화
IP는 접속되지만 도메인은 실패	DNS 하이재킹과 nameserver	DNS 요청과 응답 결과를 로그에서 확인
TUN 활성화 후 로컬 네트워크 연결 끊김	사설 네트워크 대역 라우팅과 strict-route	게이트웨이 주소를 테스트하고 DIRECT 규칙 확인
Wi-Fi 전환 후 연결 끊김	기본 인터페이스 감지	TUN을 재생성하고 출구 인터페이스 확인
클라이언트 종료 후 인터넷 연결 불가	남은 시스템 프록시 또는 라우팅	수동 프록시를 끄고 기본 라우팅 복원

결론: 최소한의 트래픽 가로채기 범위부터 설정

시스템 프록시는 대부분의 브라우저와 데스크톱 앱에 적합합니다. 설정 진입점이 명확하고 필요한 권한이 적으며, 문제가 생기면 “앱 설정—로컬 포트—규칙—노드” 순서로 단계별 확인이 가능합니다. TUN 모드는 UDP, 명령줄 프로그램, 프록시 설정을 따르지 않는 소프트웨어까지 다뤄야 할 때 적합합니다. 가상 네트워크 어댑터와 라우팅으로 더 넓은 트래픽을 가로채는 대신 DNS, 인터페이스 선택, 라우팅 충돌까지 문제 해결 범위에 포함됩니다.

실제로는 먼저 규칙 모드에서 시스템 프록시를 활성화하고 구독, 노드, 정책 그룹, DNS가 모두 작동하는지 확인하세요. 그다음 시스템 프록시를 우회하는 앱에만 TUN을 켜면 됩니다. 가로채기 범위가 넓을수록 설정 경계와 문제 해결 순서를 명확하게 유지해야 합니다.