원리 해설·clashsupport.com

원리 해설 2026-06-11 약 9분

TUN 모드와 시스템 프록시의 차이: 트래픽 처리 계층, 호환성 차이와 선택 가이드

시스템 프록시는 애플리케이션이 스스로 HTTP/SOCKS 포트 설정을 지켜준다는 전제 위에서 동작한다. 단 하나의 프로세스라도 이를 무시하면 트래픽은 규칙을 건너뛴 채 곧바로 외부로 나간다. TUN 모드는 접근 방식 자체가 다르다. 시스템 안에 가상 네트워크 카드를 하나 만들어, 운영체제가 트래픽을 "다른 네트워크 카드로 보낼 데이터"로 취급해 라우팅하게 만든다. 애플리케이션이 프록시를 인식하는지와 무관하게, 데이터 패킷은 일단 이 가상 카드를 거친 뒤에야 목적지가 결정된다. 이 글에서는 두 방식의 동작 원리, 처리 범위, 성능 부담을 정리하고 CLI 도구·게임·UWP 앱 같은 구체적인 상황에서 무엇을 선택해야 하는지 안내한다.

시스템 프록시의 동작 원리: 애플리케이션 계층의 자발적 협조

시스템 프록시는 본질적으로 운영체제가 제공하는 환경 변수 또는 레지스트리 항목의 집합으로, "HTTP 트래픽을 어떤 주소와 포트로 보내야 하는지"를 기록한다. Clash 계열 클라이언트가 시스템 프록시를 켜면 이 설정이 자신이 열어둔 port(HTTP) 또는 socks-port(SOCKS5)로 향하게 되고, 브라우저나 네트워크 설정을 지원하는 대부분의 앱은 요청을 보내기 전에 이 값을 읽어 스스로 Clash가 열어둔 포트로 연결을 만들며, 이후 Clash가 규칙에 따라 트래픽을 분류한다.

이 방식의 핵심은 "자발적 협조"에 있다. 애플리케이션이 프록시 설정을 능동적으로 읽고 따르는 것에 의존하기 때문에, 어떤 프로그램이 시스템 프록시를 읽지 않으면(예: 구버전 Java 프로그램, 일부 게임 클라이언트, 환경 변수를 기본적으로 무시하는 CLI 도구) 그 트래픽은 곧바로 물리 네트워크 카드를 통해 나가버리고 Clash의 규칙 판단을 완전히 건너뛰게 된다. 이는 Clash의 결함이 아니라 시스템 프록시라는 방식 자체의 한계다. 협조할 의사가 있는 프로세스만 관리할 수 있는 방식이기 때문이다.

참고

시스템 프록시는 UDP 트래픽 지원도 제한적이며 대부분의 상황에서 TCP만 다룬다. UDP를 프록시로 보내야 하는 경우(일부 게임, 음성 통화 등)에는 시스템 프록시로는 처리하기 어려운데, 이것이 많은 사용자가 TUN 모드로 넘어가는 직접적인 이유다.

TUN 모드의 동작 원리: 네트워크 계층의 가상 네트워크 카드

TUN 모드의 접근 방식은 완전히 다르다. 애플리케이션을 설득하는 대신, 운영체제의 네트워크 계층에 가상 네트워크 인터페이스(virtual network interface)를 직접 하나 붙인다. 활성화하면 Clash Meta(mihomo 커널)는 utun(macOS), Meta 또는 유사한 이름(Windows/Linux)의 가상 네트워크 카드를 만들고, 시스템 라우팅 테이블을 수정해 기본 경로나 일부 서브넷의 트래픽을 이 가상 카드로 보내도록 지정한다.

이후 운영체제 입장에서 판단하는 것은 "특정 앱이 프록시를 쓸지 여부"가 아니라 "이 데이터 패킷이 어느 네트워크 카드로 나가야 하는가"다. 이는 커널 라우팅 계층의 결정이며 애플리케이션이 프록시를 인식하는지와는 무관하다. 데이터 패킷이 가상 네트워크 카드로 들어오면 mihomo 커널이 사용자 영역에서 이를 파싱해 완전한 TCP/UDP 연결로 복원한 뒤 프록시 규칙에 따라 전달한다. 판단 지점이 네트워크 계층으로 내려가 있기 때문에, 거의 모든 프로세스가 발생시키는 트래픽이 이 가상 카드에 붙잡히며 "어떤 프로그램이 협조하지 않는" 문제 자체가 생기지 않는다.

# config.yaml에서 TUN 모드를 켜기 위한 기본 필드
tun:
  enable: true
  stack: system   # system / gvisor / mixed 중 선택
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

여기서 stack은 가상 네트워크 카드의 구현 방식을 결정한다. system은 시스템 내장 TUN/TAP 드라이버를 사용해 성능이 좋지만 시스템 버전 요구사항이 있고, gvisor는 사용자 영역 네트워크 스택으로 호환성이 더 좋지만 처리량이 약간 낮으며, mixed는 비교적 최신 커널이 제공하는 절충안이다. auto-route는 라우팅 테이블을 자동으로 기록하는 기능으로, 끄면 수동으로 라우팅을 설정해야 하니 고급 사용자가 아니라면 켜두는 것을 권장한다.

두 방식의 처리 범위와 호환성 차이

처리 범위 측면에서 시스템 프록시는 프록시 설정을 능동적으로 읽는 프로세스만 관리할 수 있으며, 대표적으로 브라우저와 대부분의 데스크톱 앱 요청이 여기에 해당한다. 반면 시스템 서비스, 일부 백그라운드 프로세스, CLI 도구, 게임 클라이언트의 네트워크 모듈은 시스템 프록시를 읽지 않는 경우가 많아 트래픽이 그대로 우회된다. TUN 모드는 라우팅 계층에서 동작하기 때문에 이론적으로 IP 프로토콜 스택을 사용하는 모든 트래픽을 처리할 수 있으며, "프록시를 인식하지 못하는" 프로세스까지 포함한다.

다만 처리 범위가 넓다고 해서 호환성 비용이 없는 것은 아니다. 다음 몇 가지 상황은 주의가 필요하다.

  • 가상 머신과 컨테이너 네트워크: 가상 머신이 NAT나 브리지 네트워크를 사용하면 그 트래픽 경로가 호스트의 TUN 라우팅 테이블과 충돌해 가상 머신이 인터넷에 연결되지 않거나 경로가 잘못될 수 있다. 보통 route-exclude-address에 가상 머신 서브넷을 제외해야 한다.
  • 로컬 네트워크 접속: TUN을 켠 상태에서 프린터, NAS, 라우터 관리 페이지 같은 로컬 네트워크 장치에 접속할 때 직접 연결 규칙이나 로컬 대역 예외를 제대로 설정하지 않으면 트래픽이 프록시로 잘못 판단되어 접속에 실패할 수 있다.
  • VPN 소프트웨어와의 동시 사용: 두 개의 가상 네트워크 카드가 기본 경로를 동시에 차지하려 하면 서로 덮어쓰거나 연결이 끊기는 문제가 생기기 쉽다. 일반적으로 시스템 수준 VPN과 Clash의 TUN 모드를 동시에 켜는 것은 권장하지 않는다.
  • 관리자/시스템 권한 필요: 가상 네트워크 카드를 만들고 라우팅 테이블을 수정하는 작업은 모두 시스템 수준 작업이다. TUN 모드는 Windows에서 관리자 권한으로 실행해야 하고, macOS/Linux에서는 보통 sudo나 그에 대응하는 권한 부여 절차가 필요하다. 이는 "스위치만 켜면 되는" 시스템 프록시와는 다른 부분이다.

반면 시스템 프록시는 라우팅 테이블이나 가상 네트워크 카드를 다루지 않기 때문에 가상 머신이나 다른 VPN과 충돌할 일이 거의 없고 권한 요구사항도 낮다. 이것이 시스템 프록시가 호환성 면에서 갖는 장점이며, 문제는 오직 처리 범위가 완전하지 않다는 점뿐이다.

성능 부담과 안정성 비교

시스템 프록시의 전달 경로는 비교적 짧다. 애플리케이션이 Clash가 열어둔 포트로 직접 연결하고, Clash가 규칙을 판단한 뒤 목적지 서버로 전달한다. 중간에 사용자 영역 프록시 로직을 한 번만 거치며, 부담은 대부분 규칙 매칭과 암복호화에서 발생해 대다수 대역폭 환경에서는 영향이 크지 않다.

TUN 모드는 "네트워크 계층 캡처 + 프로토콜 복원" 단계가 하나 더 추가된다. 데이터 패킷이 먼저 가상 네트워크 카드로 들어가고, 커널 네트워크 스택이 처리한 뒤 mihomo 사용자 영역 프로그램이 이를 완전한 TCP/UDP 세션으로 파싱하고, 다시 프록시 규칙과 전달 로직을 거친다. 이 과정은 시스템 프록시보다 커널 영역과 사용자 영역 사이의 데이터 복사가 한 번 더 발생하며, 이론적으로 약간의 지연과 CPU 사용량 증가를 가져온다. 구체적인 정도는 stack 선택에 따라 다른데, system 스택은 보통 gvisor보다 시스템 프록시의 성능 수준에 더 가깝다. 일반적인 웹 브라우징이나 영상 시청에서는 이 차이가 거의 느껴지지 않지만, 소형 패킷이 많고 동시 연결이 많은 상황(일부 다운로드 도구, 블록체인 노드 동기화 등)에서는 차이가 더 뚜렷하게 나타날 수 있다.

안정성 면에서 시스템 프록시에 문제가 생기면 보통 "특정 앱이 프록시를 타지 않는" 형태로 나타나며 영향 범위가 좁고 원인 파악도 쉽다. TUN 모드에서 문제가 생기면 라우팅 테이블 이상으로 인한 광범위한 인터넷 단절로 나타날 수 있으며, 복구 방법은 TUN을 끄거나 네트워크 서비스를 재시작하는 것뿐이라 원인 파악 비용이 상대적으로 크다. 이것이 대부분의 클라이언트가 TUN 모드를 기본으로 켜두지 않고 "고급 설정"에 넣어두는 이유다.

CLI 도구, 게임, UWP 앱에서는 어떻게 선택해야 할까

앱 유형마다 프록시 설정을 지원하는 정도가 크게 다르다. 대표적인 몇 가지 상황에 대한 권장 사항은 다음과 같다.

CLI 도구(curl, git, 패키지 관리자 등)

대부분의 CLI 도구는 기본적으로 시스템 프록시를 읽지 않고, 명시적으로 설정한 환경 변수에 의존한다. 예를 들면:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

환경 변수를 하나씩 설정하는 게 번거롭거나, 도구 자체가 환경 변수조차 인식하지 못하는 경우(일부 Go/Rust로 컴파일된 정적 바이너리 도구)라면 TUN 모드를 켜는 것이 훨씬 편하다. 도구마다 개별 설정을 할 필요 없이 가상 네트워크 카드가 통째로 처리해준다.

게임 클라이언트

많은 게임에서 런처와 게임 본체가 서로 다른 프로세스로 분리되어 있고, 대전 게임의 실시간 동기화 데이터처럼 UDP 전송을 대량으로 사용한다. 시스템 프록시는 UDP 지원이 제한적이라 대개 런처의 로그인 단계까지만 프록시를 타고, 실제 대전에 들어간 뒤의 트래픽은 여전히 물리 네트워크 카드를 통해 나간다. 대전 트래픽까지 규칙에 따라 분류하고 싶다면(예: 특정 전용선 노드를 통해 지연을 줄이는 경우) TUN 모드가 거의 유일하게 신뢰할 수 있는 방법이다. 네트워크 계층에서 TCP와 UDP를 한꺼번에 처리하기 때문이다. 다만 게임 가속 노드를 규칙에서 별도 그룹으로 분리해, 영화·다운로드 같은 대용량 트래픽 규칙 그룹에 대역폭을 빼앗기지 않도록 미리 신경 써야 한다.

UWP 앱(Windows 스토어 앱)

Windows의 UWP 앱은 독립된 네트워크 격리 컨테이너(Network Isolation) 안에서 실행되며, 기본적으로 시스템 프록시를 읽지도 않고 TUN 모드의 일반적인 라우팅 캡처 범위에도 포함되지 않는다. 이는 Windows 시스템 설계에 따른 샌드박스 격리이지 Clash 클라이언트가 놓친 부분이 아니다. 스토어 버전 브라우저나 메신저 같은 UWP 앱도 프록시를 타게 하려면 보통 CheckNetIsolation.exe 관련 명령으로 해당 앱의 네트워크 격리를 별도로 풀어주거나, 클라이언트에서 "UWP 앱의 루프백/네트워크 접근 허용" 같은 옵션을 찾아 켜야 한다. 이 단계는 시스템 프록시와 TUN 모드 모두 별도로 처리해야 하며, 어느 한쪽이 원래부터 호환되는 것은 아니다.

어떻게 선택할까: 간단한 판단 기준

일상적인 사용이 브라우저와 일반적인 데스크톱 앱에 집중되어 있다면 시스템 프록시만으로도 대부분의 상황을 처리할 수 있고, 설정이 간단하며 문제가 생겨도 원인을 찾기 쉬워 더 편한 기본 선택이 된다. 다음 상황 중 하나라도 해당한다면 TUN 모드로 전환을 고려해볼 만하다. CLI 도구가 자주 프록시를 필요로 하는데 환경 변수를 일일이 설정하기 싫은 경우, 게임이나 음성 통화 같은 UDP 트래픽도 규칙에 따라 분류해야 하는 경우, 특정 프로세스가 시스템 프록시를 읽지 않아 규칙이 무용지물이 되는 경우. 전환 전에는 가상 머신이나 다른 VPN 소프트웨어가 가상 네트워크 카드와 라우팅 충돌을 일으키지 않는지 먼저 확인하고, 클라이언트의 로컬 네트워크 직접 연결 규칙이 제대로 설정되어 있는지 점검해 켠 뒤에 내부 네트워크 장치 접속에 이상이 생기지 않도록 해야 한다.

Clash 다운로드