심화 원리 예상 읽기 시간 11분

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

시스템 프록시와 가상 네트워크 어댑터의 트래픽 처리 방식을 비교하고, 명령줄·게임·UDP 지원 범위와 상황별 설정 방법을 설명합니다.

시스템 프록시와 TUN: 차이는 트래픽이 커널에 들어오는 지점

어떤 옵션을 켤지 판단하려면 먼저 두 가지를 구분해야 합니다. 앱의 연결이 Clash 커널에 들어오는지, 들어온 뒤 어떤 규칙으로 처리되는지입니다. 시스템 프록시와 TUN은 주로 첫 번째 문제를 해결하고, 규칙 모드·전역 모드·정책 그룹 선택은 두 번째 문제를 다룹니다. TUN을 켜도 모든 연결이 프록시 노드를 거치는 것은 아니며, 시스템 프록시를 켜도 모든 앱이 이 설정을 사용하는 것은 아닙니다.

이 글은 데스크톱 클라이언트와 Clash Meta의 후속 프로젝트인 mihomo 커널을 기준으로 설명합니다. 클라이언트마다 옵션 이름, 권한 요청, 설정 병합 방식이 다를 수 있으며, 구형 Clash 커널은 같은 TUN 설정 항목을 지원하지 않을 수도 있습니다. 클라이언트 이름만 볼 것이 아니라 커널 정보에서 실제 실행 중인 커널을 확인한 뒤 설정을 대조하는 편이 정확합니다.

시스템 프록시: 앱이 로컬 포트로 연결을 전달

시스템 프록시를 켜면 클라이언트가 보통 운영체제의 프록시 주소를 127.0.0.1:7890 같은 로컬 주소로 바꿉니다. 이 설정을 따르는 브라우저나 데스크톱 앱은 해당 주소에 연결합니다. 커널은 HTTP 프록시 요청이나 HTTPS CONNECT 터널 요청을 받은 뒤 규칙에 따라 직접 연결하거나 노드를 통해 전달합니다.

핵심은 앱이 실제로 해당 설정을 따르는지입니다. Windows 사용자 프록시 설정은 WinHTTP 설정과 같지 않습니다. 백그라운드 서비스, 일부 업데이트 프로그램, 명령줄 도구는 별도의 설정을 사용할 수 있습니다. Linux 데스크톱 환경의 프록시 옵션도 모든 프로그램에 강제로 적용되는 것은 아닙니다. 따라서 브라우저에서 접속된다고 해서 터미널, 게임, 백그라운드 프로세스까지 트래픽이 처리된다고 단정할 수 없습니다.

TUN 모드: 가상 네트워크 어댑터와 라우팅으로 IP 트래픽 처리

TUN은 가상의 3계층 네트워크 인터페이스를 제공합니다. 클라이언트나 커널이 인터페이스를 만들고 라우팅을 설정하면, 경로 조건에 맞는 IP 패킷이 TUN으로 들어와 커널에서 처리됩니다. 앱은 로컬 프록시 포트를 알 필요도, HTTP 프록시 설정을 지원할 필요도 없습니다. 따라서 더 많은 명령줄 프로그램, 게임, UDP 앱의 트래픽을 처리할 수 있습니다.

다만 ‘더 많은 트래픽을 처리한다’고 해서 모든 트래픽을 무조건 가로채는 것은 아닙니다. 라우팅 제외 설정, 특정 인터페이스에 바인딩된 연결, IPv6 설정, 다른 VPN, LAN 트래픽에 따라 결과가 달라질 수 있습니다. TUN은 이더넷 브리지가 아니므로 브로드캐스트 검색이나 모든 링크 계층 프로토콜이 프록시 노드를 통해 전송된다고 볼 수도 없습니다.

지원 범위 비교: 브라우저, 명령줄, 게임, UDP

주요 사용 사례와 트래픽 처리 조건
사용 사례 시스템 프록시 TUN 모드
브라우저 웹 트래픽 브라우저가 시스템 설정을 따르면 보통 충분합니다. 라우팅 범위에 포함된 연결을 처리할 수 있습니다. DNS와 QUIC도 확인해야 합니다.
curl, Git 등 명령줄 도구 자동으로 적용된다고 단정할 수 없습니다. 프록시 주소를 명시할 수 있습니다. 도구마다 프록시를 설정할 필요는 보통 없지만 라우팅과 실행 환경을 확인해야 합니다.
게임과 음성 채팅 HTTP 시스템 프록시를 사용하지 않는 프로그램이 많아 처리 범위가 제한적입니다. TUN에 들어온 TCP와 UDP를 처리할 수 있으며, 노드도 해당 트래픽을 지원해야 합니다.
컨테이너, 가상 머신, WSL 각 환경 안에서 프록시를 설정해야 하는 경우가 많습니다. 가상 네트워크 구성에 따라 달라집니다. 호스트의 설정만으로 모든 트래픽이 처리되지는 않습니다.
LAN 접속 시스템 프록시 예외 목록으로 우회할 수 있습니다. 라우팅 제외 설정과 커널의 직접 연결 규칙을 함께 확인해야 합니다.

UDP 지원 여부는 TUN 옵션만으로 판단할 수 없습니다

일반 HTTP 시스템 프록시를 설정해도 임의의 앱에서 UDP가 자동으로 노드를 거치지는 않습니다. SOCKS5에는 UDP 릴레이 기능이 있지만, 앱과 로컬 프록시 엔드포인트가 모두 이를 지원하고 실제로 사용해야 합니다. 시스템에 HTTP 프록시 주소만 입력한다고 이 경로가 자동으로 생기지는 않습니다.

TUN은 라우팅 조건에 맞는 UDP 패킷을 커널로 전달할 수 있지만, 이후 전송은 아웃바운드 프로토콜, 노드 설정, 원격 서비스, 방화벽의 제약을 받습니다. udp: true로 설정해도 원래 UDP를 지원하지 않는 아웃바운드 연결에 기능이 생기는 것은 아닙니다. 게임 로그인은 되지만 음성이 작동하지 않는다면 웹페이지 하나만 테스트하지 말고 음성 연결을 따로 확인하세요.

사용 사례별 설정: 먼저 시스템 프록시를 쓰고, 빠진 앱은 추가로 처리

웹과 일반 데스크톱 앱: 시스템 프록시부터 사용

주로 웹을 이용하고 브라우저가 시스템 프록시 설정을 따른다면 TUN은 끄고 시스템 프록시와 규칙 모드부터 사용해 보세요. 변경 범위가 작아 문제가 생겼을 때 로컬 포트, 규칙, 노드 중 어디에 원인이 있는지 파악하기도 쉽습니다. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 프록시 서버를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’를 확인하세요. 메뉴 이름은 OS 버전에 따라 조금씩 다를 수 있습니다.

로컬 주소는 보통 127.0.0.1이며, 포트는 클라이언트의 실제 설정을 확인해야 합니다. 여기서는 예시로 7890을 사용했지만 모든 클라이언트의 기본 포트가 아닙니다. 클라이언트가 다른 포트에서 수신 중이라면 시스템 프록시, 터미널 환경 변수, 앱 내 수동 프록시 설정도 같은 값으로 바꿔야 합니다.

터미널과 개발 도구: 필요한 명령에만 프록시 지정

한 번의 다운로드에만 프록시를 적용하고 싶다면 기기 전체의 트래픽을 처리할 필요 없이 해당 명령에 프록시 엔드포인트를 지정하면 됩니다. 다음 명령은 로컬 HTTP 프록시를 통해 HTTPS 터널을 만들 수 있는지 확인합니다. Windows PowerShell에서는 예전 환경의 동명 별칭과 충돌하지 않도록 curl.exe를 사용하세요.

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

이 방법으로 확인할 수 있는 것은 해당 요청이 지정된 프록시 엔드포인트를 사용했다는 사실뿐입니다. 게임이나 다른 터미널 작업까지 처리된다는 뜻은 아닙니다. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 같은 환경 변수를 사용하는 경우 도구가 해당 변수를 지원하는지, NO_PROXY에서 대상 주소가 제외되어 있지 않은지도 확인하세요. 변수 이름의 HTTPS는 보통 대상 요청 유형을 뜻하며, 로컬 프록시 주소를 반드시 https://로 적어야 한다는 의미는 아닙니다.

게임, 음성 채팅, 프록시 미지원 앱: 필요하면 TUN 사용

앱이 시스템 프록시를 사용하지 않고 자체 프록시 설정도 지원하지 않는다면 TUN으로 처리 범위를 넓힐 수 있습니다. 켜기 전에 클라이언트에 가상 네트워크 어댑터 생성과 라우팅 변경 권한이 있는지 확인하세요. Windows에서는 서비스 모드나 권한 상승으로 처리할 수 있고, macOS와 Linux에서는 클라이언트의 보조 프로그램과 권한 구성에 따라 달라집니다. 모든 플랫폼에서 앱 전체를 항상 관리자 권한으로 실행해야 한다고 볼 필요는 없습니다.

두 진입 방식을 함께 켤 수도 있지만, 처음 문제를 확인할 때는 각각 따로 테스트하는 편이 좋습니다. 시스템 프록시가 켜져 있으면 TUN이 트래픽을 처리하지 못해도 브라우저가 로컬 포트를 통해 동작해 ‘웹은 정상’으로 보일 수 있습니다. TUN을 확인하려면 시스템 프록시를 잠시 끄고 테스트 프로그램 자체의 프록시 설정도 지운 다음 연결 로그를 살펴보세요.

mihomo TUN 설정: 라우팅, DNS, 규칙은 각각 다른 역할

다음은 필드의 용도를 이해하기 위한 일부 설정 예시입니다. 해당 필드를 지원하는 mihomo 커널용이며, 단독으로 실행할 수 있는 완전한 구독 설정은 아닙니다. 클라이언트 UI가 같은 필드를 생성하거나 덮어쓸 수 있으므로 수정 전에 설정을 백업하고, 수정 후에는 최종 적용 설정을 확인해 구독 업데이트로 수동 설정이 덮이지 않도록 하세요.

mixed-port: 7890
mode: rule

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

DNS도 별도로 설정해야 합니다

위 예시에는 완전한 dns 설정이 포함되어 있지 않습니다. 실제로 사용하려면 커널 DNS가 활성화되어 있는지, 업스트림 리졸버에 연결할 수 있는지, fake-ip 또는 redir-host 같은 해석 모드가 기존 설정과 호환되는지도 확인해야 합니다. fake-ip에서 자주 쓰이는 주소 대역은 198.18.0.0/16입니다. 이 주소는 연결 매핑에 사용하는 주소이므로 대상 웹사이트의 실제 서버 주소로 오해하지 마세요.

브라우저의 보안 DNS, 앱 내 DoH, DoT는 53번 포트를 수신한다고 해서 일반 DNS 조회처럼 자동 처리되지 않습니다. 도메인 규칙이 적용되지 않거나 해석 결과가 이상하다면 먼저 DNS 조회가 어디에서 이뤄지는지 확인한 뒤 브라우저 설정이나 커널 DNS 규칙을 조정하세요. DNS 문제를 감추려고 노드만 계속 바꾸지는 마세요.

직접 연결과 프록시 연결은 여전히 규칙으로 결정됩니다

트래픽이 커널에 들어온 뒤에도 규칙 모드에서는 설정된 규칙에 따라 정책이 적용됩니다. 도메인 규칙, IP 규칙, 마지막의 MATCH 기본 규칙이 아웃바운드 경로를 결정하며 TUN이 이 로직을 우회하지는 않습니다. DNS 매핑과 스니핑 등의 방식에 따라 도메인 규칙 적용 가능 여부가 달라지므로, 대상 IP만 있는 모든 연결에서 원래 도메인을 알아낼 수 있다고 가정해서는 안 됩니다.

LAN 프린터, NAS, 사내 네트워크에는 보통 직접 연결 경로가 필요합니다. 예를 들어 192.168.1.10에 접속한다면 올바르게 제외되었는지 또는 직접 연결 규칙에 매칭되는지 확인하세요. 자동 라우팅 때문에 패킷이 커널에 들어오지 않는다면 커널 규칙을 바꿔도 해당 연결은 달라지지 않습니다. 먼저 문제가 발생한 계층부터 찾아야 합니다.

반복 가능한 점검: 진입 경로 문제, 분기 규칙 오류, 노드 문제 구분

  1. 기본 상태를 기록합니다. 로컬 포트, 실행 중인 커널, 현재 정책 그룹, 대상 도메인을 적어 둡니다. 먼저 브라우저에서 고정된 대상을 열어 보고, 테스트할 때마다 노드와 DNS, 트래픽 처리 방식을 한꺼번에 바꾸지 마세요.
  2. 시스템 프록시만 테스트합니다. TUN을 끄고 시스템 프록시를 켠 다음 앞에서 안내한 명시적 프록시 명령으로 다시 확인합니다. 명령은 정상인데 브라우저에서 실패한다면 브라우저 자체의 프록시 설정, 시스템 예외 목록, 확장 프로그램 설정부터 살펴보세요.
  3. TUN만 테스트합니다. 시스템 프록시를 끄고 테스트 프로그램의 프록시 설정을 지운 뒤 TUN을 켜고 새 연결을 시도합니다. 로그에 대상, 네트워크 유형, 매칭된 규칙, 아웃바운드 정책이 표시되는지 확인하세요.
  4. 라우팅과 DNS를 확인합니다. Windows에서는 route print, Linux에서는 ip route와 ip rule, macOS에서는 netstat -rn을 확인할 수 있습니다. 가상 네트워크 어댑터 아이콘만 보고 트래픽 처리 성공 여부를 판단하지 마세요.
  5. UDP는 따로 확인합니다. 실제 게임이나 음성 기능에서 연결을 시도하고 클라이언트 연결 목록에서 해당 UDP 세션을 찾으세요. 웹페이지 테스트나 ICMP ping 결과만으로 프록시 경로의 UDP 연결을 확인할 수는 없습니다.

명시적 프록시 변수를 제외해야 한다면 다음 명령을 사용할 수 있습니다. 다만 --noproxy "*"는 curl이 명시적 프록시 경로를 우회하게 할 뿐입니다. TUN이 켜져 있다면 시스템 라우팅을 통해 해당 연결이 커널로 들어갈 수 있으므로 ‘직접 연결을 보장하는’ 명령이라고 할 수 없습니다.

curl --noproxy "*" --connect-timeout 10 -I https://example.com

기존 연결을 명시적으로 끊고 다시 테스트하는 것도 중요합니다. 브라우저 연결 풀, 게임의 장기 연결, DNS 캐시는 설정을 바꾸기 전 상태를 유지할 수 있습니다. 옵션을 바꾼 뒤 기존 연결에서 데이터가 계속 전송된다고 해서 새 연결도 같은 경로를 사용한다는 뜻은 아닙니다.

자주 묻는 질문: 권한, VPN 함께 사용하기, 종료 후 네트워크 복구

TUN을 켠 뒤 기기 전체에서 인터넷이 끊기는 이유는 무엇인가요?

먼저 TUN을 꺼서 기본 상태로 되돌린 뒤 커널 로그, DNS 업스트림, 라우팅을 각각 확인하세요. 가상 인터페이스는 만들어졌지만 커널이 트래픽을 제대로 처리하지 못하거나, 라우팅이 잘못된 아웃바운드 인터페이스를 가리키면 연결이 끊길 수 있습니다. 도메인 접속만 실패하고 IP 주소로는 응답이 있다면 DNS부터 확인하세요. 이는 원인을 좁히는 단서일 뿐 모든 서비스에 통용되는 접속 테스트는 아닙니다.

TUN과 회사 VPN을 함께 켜도 되나요?

두 프로그램의 라우팅, DNS, 보안 정책에 따라 달라지므로 함께 사용할 수 있다고 보장할 수 없습니다. 두 프로그램이 모두 기본 경로를 변경하면 설정이 서로 덮어쓰이거나 비정상적인 경로가 생길 수 있습니다. 먼저 각각의 기능을 따로 확인하고 회사 내부망 대역, 기본 경로, DNS가 바뀌었는지 살펴보세요. 조직에서 관리하는 기기라면 정해진 네트워크 정책을 따르고, 라우팅을 무작정 삭제하거나 보안 설정을 변경하지 마세요.

클라이언트를 종료한 뒤에도 브라우저에서 프록시 연결 오류가 뜨는 이유는 무엇인가요?

시스템 프록시가 종료된 127.0.0.1:7890을 계속 가리키고 있을 수 있습니다. 시스템 프록시 설정에 해당 주소가 남아 있는지 확인하고 브라우저 자체 프록시 설정도 살펴보세요. TUN 문제라면 클라이언트를 다시 실행한 뒤 TUN을 정상적으로 종료해 라우팅을 정리하도록 하세요. 네트워크 구성을 모르는 상태에서 가상 네트워크 어댑터와 시스템 경로를 한꺼번에 삭제하는 것은 권장하지 않습니다.

TUN 모드가 시스템 프록시보다 항상 빠른가요?

그렇지 않습니다. 두 방식의 주된 차이는 트래픽 처리 범위이며 실제 속도는 노드 대역폭, 경로 혼잡, 패킷 손실, DNS, MTU, 기기 성능의 영향을 받습니다. 대상, 노드, 시간대, 전송 유형을 최대한 동일하게 맞춰야 비교할 만한 결과를 얻을 수 있습니다. TUN은 커널에 들어오지 않던 앱에 프록시 경로를 제공하는 기능입니다. 같은 연결 자체를 빠르게 만드는 기능으로 이해해서는 안 됩니다.

설정은 간단하게 시작하면 됩니다. 웹은 시스템 프록시를 우선 사용하고, 일부 명령줄 작업은 프록시를 명시적으로 지정하세요. 프록시를 지원하지 않는 앱이나 UDP까지 처리해야 할 때 TUN을 켜면 됩니다. 한 번에 한 요소만 바꾸고 연결 로그로 진입 경로와 규칙을 확인한 다음 노드 상태를 점검하는 편이 모든 옵션을 동시에 켜는 것보다 원인을 찾기 쉽습니다.

Clash 다운로드기기에 맞는 클라이언트 선택