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

두 방식의 작동 원리부터 이해하기

Clash를 사용하기 전에, 네트워크 트래픽이 어떤 방식으로 프록시 프로그램에 "흡수"되는지 이해하는 것이 어떤 스위치 이름을 외우는 것보다 훨씬 중요합니다. Clash와 그 파생 커널인 Clash Meta(mihomo)는 서로 완전히 다른 두 가지 경로를 제공합니다. 하나는 "시스템 프록시", 다른 하나는 "TUN 모드"입니다. 둘 다 같은 목적을 달성합니다. 즉 기기에서 발생하는 네트워크 요청을 Clash의 규칙 엔진으로 전달해 다시 내보내는 것인데, 개입하는 계층이 완전히 다르기 때문에 적용 범위, 호환성, 설정 난이도가 크게 달라집니다.

시스템 프록시는 운영체제 차원에서 제공하는 설정 인터페이스로, 해당 프로토콜을 지원하는 프로그램에게 "HTTP/HTTPS 요청을 먼저 이 주소와 포트로 보내라"고 알려주는 방식입니다. Windows와 macOS는 모두 시스템 프록시 설정 항목을 내장하고 있으며, 브라우저나 일부 다운로드 도구, IDE의 네트워크 모듈이 이 설정을 읽어들입니다. 반면 TUN 모드는 완전히 다른 접근 방식입니다. 시스템 내부에 가상 네트워크 인터페이스(Virtual Network Interface)를 생성하며, 운영체제는 이 가상 어댑터를 실제 네트워크 출구처럼 취급합니다. 라우팅 테이블에 따라 이 출구를 거쳐야 하는 모든 IP 패킷은 어떤 프로세스에서 발생했든, 어떤 프로토콜을 사용하든 이 가상 어댑터로 먼저 유입된 뒤 Clash 커널이 이를 해석하고 규칙을 매칭해 해당 노드로 전달합니다.

시스템 프록시: 가볍지만 태생적인 사각지대

시스템 프록시의 장점은 설정이 간단하고 리소스 사용량이 적으며 켜고 끄기가 자유롭다는 점입니다. 대부분의 사용자가 Clash를 처음 접할 때 사용하는 방식도 바로 이것입니다. 다만 이 방식은 애플리케이션이 자발적으로 "협조"한다는 전제 위에서 작동합니다. 프로그램이 시스템 또는 환경 변수에 설정된 프록시 주소를 스스로 읽어와 해당 주소로 연결해 요청을 전달해야 합니다. 즉 이 규칙을 따르는 프로그램만 트래픽이 정상적으로 처리됩니다.

바로 여기서 문제가 발생합니다. 모든 네트워크 프로그램이 시스템 프록시 설정을 읽어들이는 것은 아니며, 흔히 우회가 발생하는 경우는 다음과 같습니다.

• 일부 CLI 도구나 백그라운드 서비스는 시스템 프록시 환경 변수를 읽지 않아, HTTP_PROXY/HTTPS_PROXY를 별도로 수동 설정해야 합니다.
• 일부 애플리케이션은 하드코딩된 직접 연결 로직을 사용하거나 비표준 포트로 통신하기 때문에 시스템 프록시 설정이 전혀 작동하지 않습니다.
• UDP 트래픽(예: 일부 실시간 통신, 게임 가속 시나리오)은 대부분 시스템 프록시의 처리 범위 밖에 있습니다. 시스템 프록시는 기본적으로 TCP 기반의 HTTP/HTTPS 요청을 대상으로 설계되었기 때문입니다.
• 모바일 앱 생태계는 더욱 다양해서, 많은 앱이 시스템 저수준 네트워크 라이브러리를 직접 사용해 연결하며 애플리케이션 계층 프록시 설정을 그대로 건너뜁니다.

다시 말해 시스템 프록시는 일종의 "신사협정"과 같습니다. 협조하는 프로그램은 순순히 트래픽을 전달하지만, 협조하지 않는 프로그램은 여전히 직접 연결됩니다. 이는 Clash를 실행 중인데도 특정 클라이언트가 "프록시에 연결되지 않음"으로 표시되거나 접속 결과가 예상과 다른 이유를 잘 설명해줍니다. 대부분 규칙 설정이 잘못된 게 아니라, 해당 프로그램이 처음부터 시스템 프록시를 경유하지 않은 것이 원인입니다.

TUN 모드: 네트워크 계층에서의 통합 처리

TUN 모드의 접근 방식은 훨씬 근본적입니다. 애플리케이션이 "협조할 의향이 있는지"에 의존하지 않고, 운영체제의 네트워크 프로토콜 스택 단계에 가상 네트워크 어댑터를 삽입하고 라우팅 테이블 규칙과 결합해 기기에서 발생하는 거의 모든 조건에 맞는 IP 패킷을 이 가상 인터페이스로 유도합니다. 패킷이 가상 어댑터에 진입하면 Clash Meta(mihomo) 커널이 사용자 공간에서 프로토콜 해석(일반적으로 gVisor 또는 시스템 네이티브 스택 두 가지 방식으로 구현), 도메인 매칭, 규칙 판단을 거쳐 어떤 프록시 노드로 보낼지 또는 직접 연결할지를 결정합니다.

처리가 애플리케이션 계층이 아닌 네트워크 계층에서 이루어지기 때문에 TUN 모드는 애플리케이션을 거의 가리지 않습니다. 브라우저, CLI 도구, 게임 클라이언트, 시스템 자체의 백그라운드 서비스까지 라우팅 규칙에 맞는 트래픽이라면 모두 일괄적으로 관리되며, 기존 시스템 프록시가 처리하지 못했던 UDP 트래픽도 포함됩니다. 게임이나 음성 통신, 크로스 플랫폼 클라이언트를 세밀하게 분리 라우팅하려는 사용자들이 결국 TUN 모드로 전환하는 이유가 바로 여기에 있습니다.

호환성과 안정성의 실제 차이

적용 범위가 넓다고 해서 TUN 모드에 대가가 없는 것은 아닙니다. 트래픽이 네트워크 계층에서 캡처되어 사용자 공간 프로토콜 스택에서 처리된 뒤 다시 전달되는 과정에서 패킷은 한 단계 더 많은 캡슐화와 해석을 거치게 되며, 이론적으로는 약간의 성능 오버헤드가 발생할 수 있습니다. 저성능 기기나 지연에 극도로 민감한 환경에서는 체감될 수 있습니다. 또한 가상 어댑터는 로컬 라우팅 테이블, 방화벽 규칙, VPN 클라이언트와 서로 영향을 줄 가능성이 있습니다.

• 기기에서 다른 VPN 소프트웨어나 가상 네트워크 도구를 동시에 실행 중이면 라우팅 테이블 충돌이 발생해 일부 트래픽이 비정상적으로 처리될 수 있으므로, 여러 가상 어댑터 도구를 동시에 켜지 않는 것을 권장합니다.
• 일부 사내망 환경이나 보안 소프트웨어는 새로 추가된 가상 네트워크 인터페이스를 차단하거나 경고를 표시할 수 있으므로, TUN 모드를 처음 켜기 전에 소속 네트워크 환경의 정책을 확인하는 것이 좋습니다.
• 운영체제별로 TUN 장치 구현 방식이 다릅니다. Windows는 Wintun 드라이버에 의존하고 macOS는 시스템 네트워크 확장 프레임워크를 사용하는 등 설정 경로와 권한 요청 방식이 약간씩 다르지만, 최종 사용자가 체감하는 온오프 경험은 대체로 동일합니다.

이에 비해 시스템 프록시는 이런 하위 계층 리스크가 없습니다. 설정 즉시 적용되고 끄면 즉시 복원되며, 문제가 생겼을 때 원인 파악도 훨씬 직관적입니다. 대부분 특정 프로그램이 프록시 설정을 읽지 않은 경우입니다. 이 때문에 시스템 프록시는 지금도 가벼운 사용 환경에서 기본 선택지로 남아 있습니다.

적용 범위 한눈에 비교하기

시스템 프록시를 잘 우회하는 프로그램들

특정 프로그램의 트래픽이 프록시 규칙대로 처리되지 않는다면 대부분 다음 유형에 해당합니다.

1. 커맨드라인 및 개발 도구: 패키지 매니저, 빌드 도구 등은 기본적으로 시스템 프록시를 읽지 않는 경우가 많아 환경 변수나 도구 자체의 프록시 옵션을 별도로 설정해야 합니다.
2. 자체 네트워크 스택을 사용하는 클라이언트: 일부 메신저나 클라우드 동기화 소프트웨어는 연결 속도를 높이기 위해 자체적으로 네트워크 요청 로직을 구현해 시스템 프록시 인터페이스를 거치지 않습니다.
3. 게임과 음성 통신: 많은 게임이 실시간 데이터 전송에 UDP를 사용하는데, 시스템 프록시는 UDP 지원이 전반적으로 미흡하거나 없어서 이런 트래픽은 대부분 TUN 모드로만 처리할 수 있습니다.
4. 시스템 백그라운드 서비스 및 업데이트 구성 요소: 운영체제 자체의 업데이트 확인, 텔레메트리 전송 등 백그라운드 프로세스는 보통 사용자가 설정한 프록시를 거치지 않습니다.

이런 문제를 겪을 때 프로그램마다 일일이 프록시 설정 항목을 찾아 확인하기보다, 차라리 TUN 모드로 전환해 네트워크 계층에서 "처리 범위 부족" 문제를 한 번에 해결하는 것이 효율적입니다.

TUN 모드로 전환해야 하는 상황

위 비교를 종합하면 비교적 명확한 판단 기준을 세울 수 있습니다.

• 단순히 일상적인 웹 서핑이나 소수 애플리케이션의 프록시 요구만 있다면 시스템 프록시로 충분하며 설정도 훨씬 간편합니다.
• 기기에서 시스템 프록시 규칙을 따르지 않는 프로그램(CLI 도구, 게임, 일부 메신저)이 많이 실행되고 있거나 UDP 트래픽을 규칙에 따라 분리 라우팅해야 한다면 TUN 모드가 더 확실한 해결책입니다.
• 프로세스별로 세밀하게 라우팅을 나누고 싶다면(예: 특정 앱은 직접 연결시키고 나머지는 프록시를 거치게), TUN 모드와 Clash Meta(mihomo)의 프로세스 규칙(process-name)을 결합하면 애플리케이션 계층에서는 불가능한 세밀도를 구현할 수 있습니다.
• 사내망이나 보안 소프트웨어가 엄격한 환경에서는 가상 어댑터가 차단되는지 먼저 확인한 뒤 TUN 모드 활성화 여부를 결정해, 정상적인 업무용 네트워크에 영향을 주지 않도록 하는 것이 좋습니다.

설정 파일상의 실제 차이

설정 파일 관점에서 보면 시스템 프록시는 Clash 설정에 별도로 선언할 필요 없이 클라이언트 화면의 스위치 하나로 시스템 API를 직접 호출해 처리됩니다. 반면 TUN 모드는 보통 설정 파일에 관련 필드를 명시적으로 선언해야 합니다. 예를 들어 활성화 여부, 프로토콜 스택 종류, DNS 처리 여부 등입니다. Clash Meta(mihomo)의 일반적인 작성 예시는 다음과 같습니다.

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

auto-route는 라우팅 테이블을 자동으로 설정해 트래픽을 가상 어댑터로 유입시킬지 여부를 결정하고, dns-hijack은 DNS 조회를 처리해 일부 도메인 해석이 규칙 매칭을 우회하는 것을 방지합니다. 대부분의 GUI 클라이언트에서는 이런 필드가 화면상의 간단한 스위치로 이미 캡슐화되어 있어 일반 사용자가 직접 설정 파일을 작성할 필요는 없지만, 그 의미를 알아두면 간헐적인 연결 오류를 파악하는 데 도움이 됩니다.

자주 묻는 질문

TUN 모드를 켜면 시스템 프록시도 계속 켜둬야 하나요?보통 동시에 켤 필요는 없습니다. TUN 모드의 처리 범위는 이미 시스템 프록시가 담당하는 부분을 포함하고 있으며, 둘을 동시에 켜면 라우팅 판단이 뒤섞일 수 있으므로 하나만 선택하는 것을 권장합니다.

TUN 모드를 켜면 모든 트래픽이 느려지나요?추가적인 캡슐화와 해석 과정에서 어느 정도 오버헤드가 발생하는 것은 사실이지만, 대부분의 최신 기기에서는 이 오버헤드가 크게 체감되지 않습니다. 속도 차이는 대개 처리 방식보다 프록시 노드 자체의 회선 품질에서 비롯됩니다.

모바일에도 TUN 모드가 있나요?Android는 보통 VpnService 인터페이스를 통해 비슷한 효과를 구현하며, 개념적으로는 데스크톱의 가상 어댑터 방식과 동일하게 애플리케이션 계층에서 처리하지 못하는 트래픽까지 처리할 수 있습니다. iOS는 네트워크 확장 프레임워크를 통해 동일한 기능을 구현합니다.