TUN 모드와 시스템 프록시의 차이: 두 트래픽 인터셉트 방식의 동작 원리 비교
시스템 프록시는 앱이 설정을 읽어야 동작하지만, TUN은 가상 네트워크 카드로 전체 트래픽을 네트워크 계층에서 가로챕니다. 두 방식의 구현 원리와 성능 차이를 비교하고, CLI 도구·게임에 TUN이 필요한 이유를 설명합니다.
두 가지 방식의 본질적인 차이
Clash 클라이언트는 트래픽을 프록시로 전달하는 두 가지 방식을 제공합니다: 시스템 프록시(System Proxy)와 TUN 모드입니다. 많은 사람이 이를 '어느 쪽이 더 좋은가'를 고르는 단순한 선택지로 여기지만, 실제로 두 방식은 완전히 다른 계층에서 동작하며 서로 다른 문제를 해결합니다. 이 계층 차이를 이해해야 왜 어떤 앱은 프록시 설정을 바꿔도 반영되지 않고, 어떤 CLI 도구는 아무리 설정해도 연결되지 않는지 알 수 있습니다.
시스템 프록시는 운영체제가 제공하는 설정 인터페이스로, 본질적으로는 시스템이나 브라우저에 'HTTP/HTTPS 프록시 서버 주소' 항목을 기록하는 것에 불과합니다. 이는 애플리케이션 계층에서 동작합니다: 이 설정을 읽어들여 해당 주소로 요청을 전달하려는 프로그램만 트래픽이 프록시를 거치고, 이 설정을 읽지 않는 프로그램은 원래의 네트워크 경로를 그대로 사용하며 프록시와는 전혀 관계가 없습니다.
TUN 모드는 완전히 다릅니다. 클라이언트가 시스템에 가상 네트워크 카드(Virtual Network Interface)를 생성하고, 시스템 라우팅 테이블을 수정해 기기의 대부분 또는 전체 아웃바운드 트래픽을 이 가상 네트워크 카드로 먼저 보낸 다음 Clash 코어에 전달하도록 합니다. 이 과정은 네트워크 계층에서 일어나며 어떤 애플리케이션의 협조도 필요하지 않습니다 — 패킷이 외부로 나가기만 하면 상위 계층이 어떤 프로그램이든, 어떤 프로토콜을 쓰든 무조건 가상 네트워크 카드를 거치게 됩니다.
시스템 프록시의 동작 경로와 한계
시스템 프록시의 구현 경로는 세 단계로 나눌 수 있습니다: 클라이언트가 HTTP/SOCKS 혼합 포트를 실행하고(Clash에서 기본 mixed-port 값은 보통 7890), 클라이언트가 이 포트를 시스템이나 브라우저의 프록시 설정 항목에 기록하며, 애플리케이션이 네트워크 요청을 보낼 때 이 설정을 조회해 요청을 해당 포트로 전달합니다. 전체 흐름에서 핵심은 세 번째 단계입니다 — 이 '전달' 과정은 '애플리케이션의 자발적 협조'로 이루어지며, 시스템이 강제하는 것이 아닙니다.
대부분의 GUI 브라우저와 일반적인 데스크톱 앱은 시스템 프록시 설정을 정상적으로 읽어들이므로, 시스템 프록시 모드만으로도 일상적인 웹 브라우징, 메신저, 대부분의 데스크톱 소프트웨어를 충분히 커버할 수 있습니다. 다만 몇 가지 명확한 한계가 있습니다:
- 시스템 프록시 설정을 따르지 않는 프로그램은 영향을 받지 않습니다. 일부 CLI 도구, 일부 게임 클라이언트, 그리고 자체 네트워크 라이브러리로 직접 연결하는 일부 앱에서 흔히 나타납니다.
- HTTP/HTTPS 및 일부 SOCKS 트래픽만 커버하며, UDP 위주의 프로토콜(UDP에 의존하는 일부 게임이나 영상 통화 등)은 처리하지 못합니다. 단, 프로그램 자체가 SOCKS5 UDP 릴레이를 지원하는 경우는 예외입니다.
- PAC 또는 시스템 수준 설정 항목에 의존하며, 운영체제마다 구현 방식이 달라 macOS, Windows, Linux 데스크톱 환경마다 프록시 설정 진입점이 다르고 동작에도 약간의 차이가 있습니다.
TUN 모드가 네트워크 계층에서 트래픽을 가로채는 방식
TUN은 Tunnel 가상 네트워크 장치의 약자로, 운영체제 커널이 제공하는 네트워크 인터페이스 유형입니다. 실제 네트워크 카드와 거의 동일하게 동작합니다 — 자체 IP 주소를 가지고, 라우팅 테이블에서 참조될 수 있으며, 방화벽 규칙과도 매칭될 수 있습니다. 차이점은 물리적 하드웨어에 연결되지 않고, 송수신되는 패킷을 사용자 모드 프로그램(여기서는 Clash / Clash Meta 코어)이 읽고 처리한다는 점입니다.
TUN 모드를 켜면 클라이언트는 세 가지 작업을 수행합니다: 가상 네트워크 카드를 생성하고 내부 IP를 할당하며, 시스템 기본 라우트 또는 일부 라우트를 이 가상 네트워크 카드로 향하게 하고, 이 카드로 들어오는 패킷을 코어 내부에서 가로채 프록시 규칙에 따라 전달합니다. 라우팅 계층에서 이미 트래픽을 가상 네트워크 카드로 유도했기 때문에, 시스템 네트워크 스택을 거쳐 요청을 보내는 모든 프로그램은 '프록시'라는 개념을 알든 모르든 이 인터셉트를 피할 수 없습니다. 이것이 TUN 모드가 흔히 '전역 트래픽 인터셉트'로 불리는 이유입니다.
이 계층 차이를 직관적으로 보여주는 설정 예시로, 다음은 Clash Meta(mihomo) 설정에서 TUN과 관련된 대표적인 필드입니다:
tun:
enable: true
stack: system
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: trueauto-route는 라우팅 테이블 항목을 자동으로 기록하는 역할을 하고, dns-hijack은 DNS 조회도 함께 코어 내부로 가로채 처리함으로써 트래픽은 프록시를 거치는데 DNS 해석은 실제 출구를 그대로 노출하는 상황을 막아줍니다. 이 두 항목이 함께 작동해야 비로소 '전역 인터셉트'라는 이름에 걸맞은 동작이 됩니다 — 시스템 프록시 모드는 DNS 조회를 가로챌 수 없다는 점이 두 방식의 실질적인 프라이버시 차이이기도 합니다.
CLI 도구와 게임에서 TUN이 자주 필수인 이유
CLI 도구(일부 패키지 관리자, 버전 관리 도구, 커스텀 스크립트 등)는 대체로 시스템 프록시 설정을 읽지 않고, 사용자가 직접 --proxy 인자를 전달하거나 HTTP_PROXY/HTTPS_PROXY 환경 변수를 설정해야만 동작합니다. 도구 자체가 이런 인자를 지원하지 않으면 시스템 프록시 설정은 그 도구에게 보이지 않는 존재이며, 유일하게 프록시를 통해 통신하게 만들 수 있는 방법은 TUN입니다 — TUN이 가로채는 대상은 라우팅 계층의 패킷이므로, 도구가 프록시에 '협조할 의사'가 있는지는 전혀 중요하지 않습니다.
게임 클라이언트의 상황도 비슷하지만, 원인은 조금 더 복잡합니다:
- 많은 게임의 네트워크 모듈이 하위 소켓 인터페이스를 직접 호출해 연결을 시작하며, 시스템이나 브라우저의 프록시 설정 항목을 완전히 건너뜁니다.
- 게임 대전, 음성 통신, 일부 리소스 다운로드는 UDP를 대량으로 사용하는데, 시스템 프록시가 기본적으로 커버하는 HTTP/HTTPS 시나리오는 UDP 지원이 제한적입니다.
- 일부 게임 클라이언트는 안티치트 또는 네트워크 환경 감지를 수행해 알려진 시스템 프록시 포트 특징을 직접 차단하지만, 가상 네트워크 카드 같은 시스템 계층 네트워크 인터페이스는 특별히 처리하지 않습니다.
이 세 가지 요인이 겹치면서 '시스템 프록시를 켰는데도 게임은 여전히 직접 연결되는' 현상이 흔히 발생하며, TUN 모드로 전환하면 트래픽이 즉시 올바르게 가로채집니다. 이 때문에 많은 클라이언트가 TUN 모드를 별도 항목으로 두고, 튜토리얼에서도 게임·CLI 상황에는 TUN을 우선 사용하도록 특별히 강조합니다.
성능과 안정성 차이는 미리 알아둘 것
TUN 모드는 커버 범위가 넓지만, 그 대가로 사용자 모드와 커널 모드 사이의 데이터 복사·처리 단계가 하나 더 추가됩니다. 이론적으로 시스템 프록시보다 지연과 CPU 사용량이 조금 더 높아지며, 트래픽이 큰 상황(대용량 파일 다운로드, 4K 영상 등)에서는 그 차이를 더 쉽게 체감할 수 있습니다. 시스템 프록시는 경로가 더 짧기 때문에 보통 경량 시나리오에서 더 가볍게 동작합니다. 실제 사용에서는 이 차이가 대부분의 사람에게 눈에 띄지 않지만, 기기 성능이 제한적이거나 지연에 매우 민감한 경우(예: 경쟁 게임)라면 개인적으로 비교 테스트를 해본 뒤 어떤 모드를 장기적으로 사용할지 결정하는 것이 좋습니다.
또한 TUN 모드는 시스템 라우팅 테이블을 수정하기 때문에, 드물게 다른 VPN 소프트웨어, 가상 머신 네트워크, 사내망 클라이언트와 라우팅 충돌이 발생할 수 있으며, 이런 경우 켜고 나면 네트워크에 전혀 연결되지 않거나 일부 주소만 접근 가능한 증상으로 나타납니다. 이런 상황을 만나면 먼저 라우팅 테이블을 수정하는 다른 네트워크 도구가 동시에 실행 중인지 확인하고, 그중 하나를 종료하면 대체로 문제를 특정할 수 있습니다. 시스템 프록시는 라우팅 테이블을 건드리지 않으므로 이런 충돌이 거의 없어 호환성이 더 안정적입니다.
어떻게 선택할까: 두 모드의 적용 시나리오
'어느 쪽이 더 좋은가'를 고민할 필요는 없습니다. 두 방식은 원래부터 서로 다른 시나리오를 위해 설계된 것이므로, 아래 기준에 따라 선택하면 됩니다:
- 일상적인 웹 브라우징, 주요 메신저와 데스크톱 앱 사용이라면 시스템 프록시로 충분합니다. 경로가 짧고 리소스 사용량도 낮습니다.
- CLI 도구, SDK, 패키지 관리자를 사용해야 하는데 도구 자체가 시스템 프록시 설정을 인식하지 못한다면, 도구마다 개별적으로 프록시 파라미터를 찾을 필요 없이 바로 TUN을 켜면 됩니다.
- 프록시를 거쳐야 하는 게임을 플레이하거나, 게임이 UDP를 많이 사용해 시스템 프록시 상태에서 지연이 비정상적으로 발생한다면 TUN을 먼저 시도해 보세요.
- 특정 앱이 프록시 설정을 무시하고 직접 연결한다는 의심이 든다면, 먼저 시스템 프록시 모드와 패킷 캡처 도구를 함께 사용해 확인한 뒤, TUN으로 전환해 이 경로를 완전히 막을지 결정하면 됩니다.
대부분의 클라이언트(예: Clash Verge Rev, FlClash, Clash Nyanpasu)는 설정에서 시스템 프록시와 TUN 모드를 각각 독립적인 스위치로 제공하며, 둘을 동시에 켜도 서로 충돌하지 않습니다. 다만 동시에 켰을 때 실제로 적용되는 인터셉트 계층은 TUN이 우선입니다. 클라이언트를 막 설치했다면 먼저 기본값인 시스템 프록시 모드로 노드와 규칙이 정상 동작하는지 확인한 뒤, 개별 애플리케이션의 연결 상황에 따라 TUN을 추가로 켜야 할지 결정하는 것을 권장합니다.