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

먼저 트래픽 처리 방식을 선택한 다음 프록시 규칙을 확인하세요

브라우저와 일반 웹 요청: 먼저 시스템 프록시를 사용하고, 애플리케이션이 운영체제의 프록시 설정을 읽는지 확인하세요.
curl, Git, 개발 도구: 먼저 프록시 포트를 명시적으로 설정하세요. 도구가 프록시를 지원하지 않거나 트래픽을 통합 처리해야 한다면 TUN을 고려하세요.
게임, 음성 통화, UDP 앱: TUN을 우선 검토하고, 아웃바운드 프로토콜과 노드 서버, 네트워크 경로가 UDP를 지원하는지 확인하세요.
회사 VPN, 컨테이너, 가상 머신을 함께 사용하는 경우: 먼저 라우팅과 DNS를 확인하고 여러 트래픽 처리 도구를 무작정 겹쳐 사용하지 마세요.

Clash Meta는 일반적으로 mihomo 커널 생태계를 가리킵니다. 클라이언트 UI에서는 구독을 가져오고 설정을 관리하거나 기능을 전환하며, 커널은 연결을 수신하고 규칙을 매칭해 아웃바운드 연결을 설정합니다. 시스템 프록시와 TUN은 트래픽이 들어오는 서로 다른 경로이지, 구독 두 개나 노드 두 개가 아닙니다.

시스템 프록시: 앱이 로컬 포트에 직접 연결

시스템 프록시를 켜면 보통 127.0.0.1:7890 같은 로컬 프록시 주소가 운영체제 설정에 등록됩니다. 이 설정을 읽는 앱은 해당 포트로 요청을 전달합니다. 포트는 클라이언트에서 현재 적용 중인 설정과 일치해야 합니다. 예시의 7890이 모든 클라이언트에서 고정으로 쓰이는 값은 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule

이 설정은 mihomo가 혼합 포트에서 HTTP와 SOCKS 프록시 요청을 받도록 합니다. 하지만 이것만으로 운영체제의 시스템 프록시가 켜지는 것은 아닙니다. 클라이언트의 ‘시스템 프록시’ 버튼이 나머지 설정을 담당합니다. 시스템 프록시 UI에는 보통 HTTP 프록시 포트를 입력하며, 그렇다고 모든 프로그램이 SOCKS를 자동으로 사용하는 것은 아닙니다.

브라우저에서는 보통 잘 작동하는 이유

일반적인 데스크톱 환경에서 Chrome과 Edge는 보통 시스템 프록시 설정을 읽습니다. Firefox는 별도의 네트워크 설정을 사용할 수 있으므로 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 ‘시스템 프록시 설정 사용’을 선택했는지 확인하세요. 브라우저 확장 프로그램이 프록시 설정을 덮어쓸 수도 있으니 문제 해결 시 확장 프로그램의 프록시 권한도 확인해야 합니다.

터미널에서 직접 연결되는 경우가 많은 이유

터미널에서 실행되는 프로그램은 각자 네트워크 연결 방식을 결정하므로 데스크톱 프록시 설정을 읽는다고 단정할 수 없습니다. 먼저 프록시를 명시하는 옵션으로 테스트하면 ‘도구가 프록시를 사용하지 않음’과 ‘노드 연결 실패’를 구분할 수 있습니다.

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

현재 셸 세션에서 프록시를 사용하려면 다음 환경 변수를 설정하세요. HTTPS 요청도 HTTP 프록시의 CONNECT 터널을 통해 전송되므로 https_proxy 값에 http://를 사용할 수 있습니다.

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

# 테스트가 끝나면 현재 세션 설정을 해제합니다
unset http_proxy https_proxy

위 명령은 일반적인 POSIX 셸용이며 PowerShell 문법이 아닙니다. 모든 프로그램이 이 환경 변수를 따르는 것도 아니며, 일부 개발 도구는 별도로 설정해야 합니다. SOCKS 테스트에서 대상 도메인의 DNS 조회를 프록시 서버에 맡기려면 curl --proxy socks5h://127.0.0.1:7890을 사용할 수 있습니다. 여기서 h는 프록시 서버가 대상 도메인을 조회한다는 뜻입니다.

TUN: 가상 네트워크 인터페이스로 IP 트래픽 수신

TUN은 운영체제에 3계층 가상 네트워크 인터페이스를 만들고 라우팅 규칙과 함께 사용해 조건에 맞는 IP 트래픽을 mihomo로 전달합니다. 앱은 HTTP 프록시 프로토콜을 따로 처리하지 않고 평소처럼 TCP 또는 UDP 연결을 만들 수 있습니다. 커널은 트래픽을 받은 뒤 설정에 따라 직접 연결하거나 차단하거나 프록시 노드로 전달합니다.

TUN은 시스템 프록시보다 더 넓은 범위의 트래픽을 처리하는 경우가 많지만, 모든 네트워크 환경에서 ‘모든 앱에 적용되는 스위치’는 아닙니다. 라우팅 제외 설정, 다른 VPN, 네트워크 네임스페이스, 가상 머신 네트워크, 운영체제 권한 등이 실제 적용 범위에 영향을 줄 수 있습니다.

최소 설정 예시

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

enable: TUN 활성화를 요청합니다. 인터페이스를 만들 수 있는지는 권한과 실행 환경에도 달려 있습니다.
stack: mixed: 혼합 프로토콜 스택을 선택합니다. 일반적으로 TCP는 시스템 스택이, UDP는 gVisor 스택이 처리하며 프록시 노드 프로토콜을 의미하지는 않습니다.
auto-route: 필요한 라우트를 자동으로 설정합니다. 다른 VPN과 충돌하는 상황에서 기본 동작을 무작정 유지하지 마세요.
auto-detect-interface: 아웃바운드 인터페이스를 자동으로 식별합니다. 네트워크 인터페이스가 여러 개이거나 VPN을 함께 사용하는 경우 실제로 선택된 인터페이스를 확인해야 합니다.
dns-hijack: 조건에 맞는 일반 DNS 요청을 커널 DNS 모듈로 전달합니다. 앱 내부의 DoH나 DoT를 직접 복호화하지는 않습니다.

Windows에서는 보통 관리자 권한이나 클라이언트가 설치한 서비스 구성 요소가 필요합니다. Linux에서는 적절한 네트워크 관리 권한과 TUN 장치가 필요하고, macOS에서는 클라이언트에 맞는 승인 절차를 거쳐야 합니다. 클라이언트마다 메뉴 이름은 다르므로 TUN을 켜기 전에 ‘서비스 모드’ 또는 권한 안내가 완료되었는지 확인하세요. 스위치가 켜졌다는 사실만으로 가상 인터페이스와 라우트가 생성되었다고 판단해서는 안 됩니다.

브라우저·명령줄·UDP 처리 범위 비교

트래픽 유형	시스템 프록시	TUN 모드
브라우저 HTTP / HTTPS	앱이 시스템 설정을 읽으면 처리 가능	라우팅 범위에 포함되면 처리 가능
curl, Git 등 명령줄 도구	옵션, 환경 변수 또는 도구 설정이 필요한 경우가 많음	보통 앱마다 프록시 포트를 입력할 필요 없음
게임·음성 통화 UDP	일반 HTTP 시스템 프록시로는 보통 처리되지 않음	수신할 수 있지만 아웃바운드 경로도 UDP를 지원해야 함
LAN 및 프린터	프록시 우회 목록에 따라 다름	라우팅 제외 설정과 직접 연결 규칙에 따라 다름
컨테이너 및 가상 머신	각 환경에서 별도로 설정해야 하는 경우가 많음	가상 네트워크 토폴로지와 포워딩 경로에 따라 다름

UDP 트래픽을 처리할 수 있어도 노드가 이를 전달할 수 있다는 뜻은 아닙니다

게임과 음성 통화는 UDP를 자주 사용하고, 브라우저의 HTTP/3도 보통 UDP 443 포트에서 동작하는 QUIC을 사용합니다. TUN은 트래픽이 들어오는 경로를 제공할 수 있지만, 노드 프로토콜과 클라이언트의 노드 설정, 서버 지원, 네트워크 사업자 환경이 모두 요구 사항을 충족해야 합니다. 일반 HTTP 프록시는 이런 UDP 트래픽을 직접 전달하지 못하는 경우가 많습니다. UDP를 지원하는 SOCKS 클라이언트는 별도의 명시적 프록시 경로입니다.

따라서 ‘웹은 되는데 게임은 안 됨’이 반드시 TUN 문제라는 뜻은 아닙니다. 먼저 연결 기록에서 게임의 대상 주소와 프로토콜, 최종 정책을 확인한 다음 해당 노드가 UDP를 지원하는지 살펴보세요. 노드 지연 시간 테스트는 대개 특정 테스트 대상에 대한 결과만 보여 주므로 게임 UDP 연결이 가능하다는 증거가 되지 않습니다.

DNS, fake-ip, 규칙 매칭의 관계

시스템 프록시와 TUN 모두 도메인을 처리해야 하지만, 도메인 정보를 얻는 방식은 다릅니다. HTTP CONNECT나 SOCKS의 도메인 요청은 대상 도메인을 프록시에 직접 전달할 수 있습니다. 반면 TUN이 처음 받는 것은 IP 패킷입니다. 도메인 규칙을 안정적으로 적용하려면 커널이 DNS 매핑이나 스니핑 등을 통해 도메인을 연결해야 하며, 대상 IP만 보고 웹사이트 이름을 추측하는 방식으로는 부족합니다.

fake-ip 모드에서는 커널이 앱에 198.18.0.1/16 범위의 합성 주소를 반환하고 실제 도메인과의 매핑을 저장할 수 있습니다. 연결이 커널에 들어오면 도메인을 기준으로 규칙을 매칭합니다. 이 주소 대역은 노드의 출구 주소가 아니므로 ‘DNS가 예약 주소를 반환한다’는 이유만으로 DNS 조회가 실패했다고 판단해서는 안 됩니다.

자주 놓치는 세 가지 사항

앱 자체의 암호화 DNS: 브라우저가 HTTPS를 통해 DNS를 조회하면 일반적인 53번 포트 DNS 가로채기로는 조회 내용을 직접 읽을 수 없습니다. 문제를 확인하는 동안 시스템 DNS를 일시적으로 통일해 결과를 비교해 보세요.
오래된 DNS 캐시: 모드를 바꾼 뒤에도 앱이 이전에 캐시한 실제 IP나 합성 주소를 사용할 수 있습니다. 테스트 앱을 재시작하고 필요하면 시스템 DNS 캐시를 비운 다음 새 연결을 만드세요.
LAN 도메인: 라우터 관리 페이지, NAS, 사내 도메인은 내부 DNS를 지정하거나 실제 도메인에 맞춰 fake-ip 필터를 설정해야 할 수 있습니다. 직접 연결 규칙만 추가해서는 DNS 문제가 해결되지 않을 수도 있습니다.

Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 비울 수 있지만, 모든 앱의 자체 캐시까지 자동으로 지워지는 것은 아닙니다. 브라우저와 명령줄의 결과가 다르면 각각의 DNS 설정과 연결 기록을 확인하세요. DNS, 노드, 규칙을 한꺼번에 바꾸지는 마세요.

트래픽 처리가 적용되는지 네 단계로 확인하기

1. 규칙과 노드 고정하기

먼저 Rule 모드를 유지하고 사용할 수 있는 노드를 하나 직접 선택하세요. 테스트 중에는 정책 그룹의 자동 전환을 일시 중지해 노드 변경이 결과에 영향을 주지 않게 합니다. 7890처럼 클라이언트에 적용된 포트를 기록하고, 구독의 정책 그룹 이름이 규칙에서 참조하는 이름과 일치하는지도 확인하세요.

2. 시스템 프록시만 따로 확인하기

TUN을 끄고 시스템 프록시를 켜세요. 새 브라우저 연결을 만든 다음 앞에서 사용한 curl --proxy 명령을 실행합니다. 연결 패널에서 테스트 요청이 나타나는지, 어떤 규칙에 매칭되는지, 최종적으로 어떤 정책을 사용하는지 확인하세요. 브라우저는 접속되지만 일반 curl의 연결 기록이 없다면 명령줄 도구가 프록시를 직접 사용하지 않는 경우가 많습니다.

3. TUN만 따로 확인하기

시스템 프록시를 끄고 테스트 터미널에 설정한 프록시 환경 변수를 해제한 다음 TUN을 켜세요. 이전에 ALL_PROXY, all_proxy 또는 도구별 프록시를 설정했다면 함께 확인해야 합니다. 그런 다음 프록시 옵션 없이 명령을 실행해 명시적 프록시 연결 성공을 TUN 성공으로 착각하지 않도록 합니다.

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

Windows에서는 route print, Linux에서는 ip route와 ip rule, macOS에서는 netstat -rn으로 라우팅을 확인할 수 있습니다. 플랫폼마다 자동 라우팅 방식이 다르므로 모두 같은 기본 라우트가 나타나야 하는 것은 아닙니다. 가상 인터페이스가 생성되고 대상 트래픽이 예상대로 커널에 전달되는지가 중요합니다.

4. 규칙과 출구 확인하기

먼저 연결 기록에서 요청이 커널에 들어왔는지 확인한 다음 최종 정책을 살펴보세요. 규칙이 프록시를 지정한다면 신뢰할 수 있는 IP 조회 서비스로 출구 IP를 비교할 수 있습니다. 규칙이 직접 연결을 지정했다면 출구 IP가 바뀌지 않는 것이 정상입니다. 웹 페이지를 한 번 열어 보거나 상태 표시줄 아이콘, 노드 지연 시간만 확인해서는 전체 경로가 올바르다고 입증할 수 없습니다.

모드 선택과 문제 복구

시스템 프록시와 TUN을 동시에 켜도 되나요?

가능하지만 문제를 확인할 때는 한 가지 트래픽 처리 방식만 사용하는 편이 좋습니다. 둘을 동시에 켜면 일부 앱은 로컬 프록시 포트에 연결하고 나머지는 TUN을 통해 연결해 진입 경로를 파악하기 어려워집니다. 정상적으로 설정했다면 같은 요청이 원격 프록시를 두 번 거친다는 뜻은 아닙니다. 다른 VPN이나 잘못된 아웃바운드 라우팅, DNS 설정으로 연결이 순환하는 상황을 주의하세요.

TUN을 켠 뒤 NAS나 회사 VPN에 연결할 수 없음

먼저 TUN을 끄고 기존 네트워크가 복구되는지 확인한 다음 LAN 대역과 회사 VPN 라우트, 내부 DNS를 점검하세요. 프록시 규칙의 DIRECT는 커널의 아웃바운드 연결 방식을 결정하고, 라우팅 제외 설정은 트래픽이 TUN에 들어오는지를 결정하므로 서로 다른 계층에서 작동합니다. 실제 네트워크 구성에 맞게 해결 방법을 선택해야 하며, 모든 사설 주소 대역을 아무 노드로나 보내서는 안 됩니다.

클라이언트를 종료한 뒤에도 인터넷에 연결할 수 없음

시스템 프록시가 더 이상 요청을 받지 않는 127.0.0.1:7890을 계속 가리키는지 확인하세요. 필요하면 남아 있는 수동 프록시 설정을 끄세요.
클라이언트에서 TUN을 정상적으로 끄고 가상 인터페이스와 자동 라우트가 제거되었는지 확인한 다음 프로그램을 종료하세요.
VPN, 네트워크 인터페이스, DNS 설정을 확인하고 테스트 전에 기록해 둔 상태로 복구하세요. 시스템 라우트를 전부 지우지는 마세요.

설정을 더 진행하기 전에 전체 문서에서 규칙, DNS, TUN 설명을 확인하세요. 복구할 수 있도록 기존 설정을 보관하고 한 번에 설정 블록 하나씩만 변경하면 문제가 발생한 계층을 더 빠르게 찾을 수 있습니다.