TUN 모드와 시스템 프록시 중 무엇을 선택할까: 두 트래픽 가로채기 방식의 원리 비교

결론부터: 브라우저에는 시스템 프록시, 전체 트래픽 가로채기에는 TUN

시스템 프록시와 TUN 모드는 서로 다른 프록시 프로토콜이 아니라, 로컬 연결을 Clash 또는 Mihomo 코어에 전달하는 두 가지 방식입니다. 최종적으로 직접 연결할지 어떤 노드를 선택할지는 여전히 설정의 규칙, 정책 그룹, 현재 실행 모드가 결정합니다. 두 방식의 핵심 차이는 트래픽이 어느 지점에서 코어로 들어가며 어떤 앱이 처리 대상에 포함되는지입니다.

주로 웹을 탐색하거나 시스템 프록시를 지원하는 데스크톱 앱을 사용한다면 먼저 시스템 프록시를 켜는 편이 적합합니다. 시작이 빠르고 권한 요구가 낮으며, 끈 뒤 원래 상태로 되돌리기도 쉽습니다. 명령줄 도구, 게임 런처, 일부 스토어 클라이언트, UDP 앱처럼 시스템 프록시를 읽지 않는 경우에는 TUN 모드로 가로채기 범위를 넓히세요.

시스템 프록시의 작동 원리: 앱이 직접 연결을 로컬 포트로 전달

시스템 프록시를 켜면 Clash 클라이언트가 운영체제의 HTTP, HTTPS 또는 SOCKS 프록시 주소를 로컬 수신 포트로 지정합니다. 일반적인 설정은 mixed-port: 7890이며, 하나의 포트에서 HTTP와 SOCKS5 연결을 모두 받을 수 있습니다. 오래된 설정에서는 port: 7890과 socks-port: 7891을 각각 사용하기도 합니다. 이 포트는 로컬 앱과 프록시 코어 사이의 진입점일 뿐, 원격 노드의 포트가 아닙니다.

앱이 시스템 프록시 설정을 직접 읽고 따라야 연결이 Clash로 들어옵니다. Chrome, Edge, Safari와 시스템 네트워크 프레임워크를 기반으로 하는 많은 데스크톱 소프트웨어가 일반적으로 이 방식을 사용합니다. 앱이 127.0.0.1:7890에 연결되면 코어가 대상 도메인 또는 주소를 읽고, DOMAIN-SUFFIX, IP-CIDR, 규칙 세트와 최종 규칙에 따라 DIRECT, REJECT 또는 프록시 정책 그룹을 선택합니다.

시스템 프록시가 적용되었는지 확인하는 방법

• Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」를 열고, 수동 프록시 서버가 127.0.0.1 및 클라이언트에 표시된 포트를 가리키는지 확인하세요.
• macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크→「세부사항」→「프록시」를 열고 웹 프록시와 보안 웹 프록시 항목을 확인하세요.
• ClashX에서는 메뉴 막대 아이콘에서 「시스템 프록시로 설정」 상태를 확인하고, 현재 설정이 실행 중인지도 확인하세요.
• Mihomo 그래픽 클라이언트를 사용할 때는 「설정」→「Clash 설정」의 혼합 포트도 함께 확인하세요. 클라이언트 버전에 따라 메뉴 이름이 약간 다를 수 있습니다.

브라우저는 되는데 터미널은 연결되지 않는 이유

curl, Git, npm, pip 등 명령줄 도구의 시스템 프록시 처리 방식은 서로 다릅니다. 일부 버전은 환경 변수를 읽지만, 별도 설정이 필요한 도구도 있습니다. 임시로 테스트하려면 현재 터미널에서 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 설정하고 로컬 포트를 명시하세요.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

curl -I https://example.com

socks5h의 h는 SOCKS 프록시 서버에서 도메인 이름을 해석한다는 뜻입니다. 터미널이 로컬에서 먼저 도메인을 해석해 결과가 달라지는 문제를 줄일 수 있습니다. Windows PowerShell에서는 $env:HTTPS_PROXY="http://127.0.0.1:7890"을 사용해 현재 세션에 변수를 설정할 수 있습니다. 터미널을 닫으면 임시 변수는 새 세션에 영향을 주지 않습니다.

TUN 모드의 작동 원리: 가상 네트워크 카드가 IP 트래픽을 수신

TUN 모드는 가상 3계층 네트워크 인터페이스를 만들고, 라우팅 테이블을 통해 조건에 맞는 IP 패킷을 해당 인터페이스로 보냅니다. Mihomo 코어는 패킷의 출발지 주소, 목적지 주소, 전송 프로토콜을 읽고 연결 정보를 복원한 뒤 프록시 규칙을 적용합니다. 앱이 보는 것은 일반 네트워크 연결이므로 HTTP나 SOCKS 프록시를 이해하거나 시스템 프록시 설정을 직접 읽을 필요가 없습니다.

이 때문에 TUN은 더 많은 프로그램을 처리할 수 있습니다. 자체 네트워크 스택을 사용하는 게임 런처, 시스템 프록시를 무시하는 명령줄 프로그램, UDP를 사용하는 앱도 TUN 가로채기 경로에 들어올 수 있습니다. 다만 “TUN을 켜면 모든 데이터가 반드시 원격 노드를 거친다”는 뜻은 아닙니다. 로컬 네트워크 주소, 제외 라우팅, DIRECT 규칙, 프로세스 규칙, 클라이언트 설정에 따라 최종 경로가 달라집니다.

Mihomo 기본 TUN 설정

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

auto-route는 필요한 라우팅을 자동으로 추가하고, auto-detect-interface는 실제 외부 연결에 사용할 네트워크 카드를 식별하려고 시도합니다. dns-hijack는 조건에 맞는 53번 포트 DNS 요청을 코어의 DNS 모듈로 전달합니다. stack: mixed는 Mihomo에서 자주 사용하는 선택지로, 시스템 스택과 사용자 공간 처리 기능을 함께 활용합니다. 운영체제, 코어 버전, 클라이언트에 따라 system, gvisor, mixed를 지원할 수 있으므로 다른 코어의 동명 옵션을 그대로 옮겨 쓰면 안 됩니다.

적용 범위 비교: TCP, UDP, 로컬 네트워크와 프로세스 식별

TCP와 UDP의 차이

시스템 HTTP 프록시는 주로 TCP 기반 HTTP 및 HTTPS 연결을 처리합니다. SOCKS5 자체는 UDP 처리를 확장할 수 있지만, 앱이 SOCKS5 UDP 전달을 명시적으로 지원해야 합니다. 운영체제의 일반적인 “웹 프록시” 스위치는 모든 UDP 데이터를 SOCKS 포트로 자동 전달하지 않으므로 음성 통화, 실시간 게임, QUIC, 일부 DNS 요청이 시스템 프록시를 우회할 수 있습니다.

TUN은 IP 계층에서 TCP와 UDP를 모두 확인하므로 두 전송 프로토콜을 통합 처리해야 하는 환경에 더 적합합니다. 그래도 원격 노드 프로토콜이 해당 UDP 전달을 지원해야 하며, 정책 그룹의 실제 노드에서도 UDP 기능을 활성화해야 합니다. 로그에서 UDP 연결이 규칙에 일치한 뒤에도 실패한다면 TUN 스위치만 반복해서 바꾸지 말고 노드 프로토콜, 서버 설정, 네트워크 MTU를 계속 점검하세요.

로컬 네트워크 장치와 사설 주소

프린터, NAS, 라우터 관리 페이지는 보통 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12를 사용합니다. TUN을 켠 뒤에는 로컬 네트워크 직접 연결 규칙을 유지하고, 자동 라우팅이 이 대역을 잘못된 인터페이스로 보내지 않는지 확인하세요. 일반적인 규칙은 프록시 규칙보다 앞에 배치할 수 있습니다.

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

기업 내부망도 이러한 사설 주소를 사용한다면 대역을 직접 연결하는 것만으로는 부족하며 회사 VPN 인터페이스의 라우팅 우선순위도 올바른지 확인해야 합니다. “공용 인터넷은 되지만 사내 도메인이 열리지 않는” 경우에는 프록시 노드를 바로 수정하지 말고 먼저 TUN을 켜기 전후의 라우팅 테이블을 비교하세요.

프로세스 규칙의 신뢰성

TUN 모드에서는 지원되는 플랫폼에서 코어가 연결을 시작한 프로세스를 식별하고 PROCESS-NAME 또는 PROCESS-PATH와 일치시킬 수 있습니다. 하지만 프로세스 식별은 시스템 권한, 앱 샌드박스, 자식 프로세스 구조, 코어 구현의 영향을 받습니다. 브라우저 네트워크 서비스가 별도 프로세스로 실행되거나 컨테이너 트래픽이 호스트 프로세스로만 표시될 수도 있습니다. 핵심 분할 라우팅은 도메인, IP, 규칙 세트를 중심으로 구성하고 프로세스 규칙은 보조 수단으로 사용하는 것이 좋습니다.

DNS 처리 비교: 도메인은 어느 단계에서 해석되는가

시스템 프록시 환경의 DNS 동작은 앱과 프록시 유형에 따라 달라집니다. 브라우저가 암호화 DNS를 직접 활성화할 수도 있고, 운영체제에 먼저 질의한 뒤 해석된 IP에 연결할 수도 있습니다. SOCKS5 클라이언트는 도메인 해석을 프록시에 맡길 수도 있습니다. 도메인이 Clash에 들어오기 전에 이미 IP로 변환되면 코어는 목적지 IP로만 매칭할 수 있어 도메인 규칙의 가시성이 스니핑 및 매핑 상태의 영향을 받습니다.

TUN은 Mihomo DNS 모듈, DNS 하이재킹, Fake IP와 함께 사용하는 경우가 많습니다. Fake IP 모드는 예약 주소 대역에서 임시 주소를 반환합니다. 예를 들어 기본값으로 198.18.0.0/16이 자주 사용되며, 이후 매핑 관계를 통해 원래 도메인을 복원합니다. 따라서 앱이 IP 연결만 시작하더라도 도메인 규칙을 계속 적용할 수 있고, 로컬 해석 경로와 프록시 경로가 달라지는 문제도 줄일 수 있습니다.

Fake IP는 원격 DNS가 아니다

Fake IP는 로컬 코어가 도메인 매핑을 관리하는 방식이며, 실제 상위 DNS에 질의할 때는 nameserver, proxy-server-nameserver, 규칙 DNS, 현재 프록시 설정을 따릅니다. 노드 서버의 도메인도 사용 가능한 해석 경로가 필요합니다. 그렇지 않으면 “노드 주소를 해석하려면 먼저 노드에 연결해야 하는” 순환 의존이 발생합니다.

• 웹 페이지에서 인증서 도메인 오류가 발생하면 다른 소프트웨어가 DNS를 변조하고 있지 않은지, Fake IP 매핑이 여전히 유효한지 확인하세요.
• 로컬 네트워크 장치에 호스트 이름으로 접근할 수 없다면 관련 도메인을 Fake IP 필터 목록에 추가하거나 로컬 네트워크 도메인용 DNS를 별도로 구성하세요.
• 앱에 DoH가 내장되어 있으면 일반적인 53번 포트 하이재킹만으로 해당 질의를 가로채지 못할 수 있습니다. 브라우저의 보안 DNS 설정과 규칙 일치 여부를 확인하세요.
• 절전 모드에서 복귀한 뒤 많은 도메인이 잠시 실패한다면 먼저 설정을 다시 불러오고 운영체제 DNS 캐시를 갱신한 다음 TUN 인터페이스 재생성이 필요한지 판단하세요.

권한, 호환성, 성능 부담 비교

권한 요구 사항

시스템 프록시는 보통 현재 사용자의 네트워크 프록시 설정만 수정하면 됩니다. 반면 TUN은 가상 네트워크 카드를 만들고 라우팅 테이블을 변경하거나 시스템 네트워크 확장을 호출하므로 Windows에서는 관리자 승인이 필요할 수 있고, macOS에서는 네트워크 확장 또는 보조 서비스 승인이 필요할 수 있습니다. Linux에서는 일반적으로 CAP_NET_ADMIN, root 권한 또는 systemd가 프로세스에 부여한 해당 권한이 필요합니다.

권한은 출처와 버전을 확인한 현재 클라이언트에만 부여해야 합니다. TUN 스위치를 누르자마자 다시 꺼진다면 먼저 클라이언트 서비스 상태와 코어 로그를 확인하세요. 인터페이스 생성 실패가 표시될 때 시스템 권한을 점검하면 됩니다. 설정 파일을 반복해서 재설치해도 드라이버, 서비스, 권한 부여 문제는 해결되지 않는 경우가 많습니다.

VPN, 가상 머신, 컨테이너와의 공존

기업 VPN과 TUN은 모두 가상 인터페이스를 만들고 기본 라우팅을 추가할 수 있습니다. 나중에 시작한 소프트웨어가 라우팅 우선순위를 바꾸면 연결 루프, 사내망 단절, 잘못된 네트워크 카드로의 트래픽 전송이 발생할 수 있습니다. 일반적으로 기업 VPN에 먼저 연결한 뒤 Clash TUN을 시작하고, auto-detect-interface 또는 클라이언트의 인터페이스 옵션으로 실제 출구를 확인합니다. 회사 정책상 라우팅 변경이 허용되지 않는다면 시스템 프록시가 더 안전합니다.

WSL2, Docker Desktop, Parallels, VMware는 자체 가상 네트워크 대역을 관리합니다. 호스트의 TUN이 가상 머신 내부의 모든 트래픽까지 자동으로 처리한다고 보장할 수 없고, 가상 머신이 호스트를 게이트웨이로 인식할 수도 있습니다. 호스트 시스템, 가상 네트워크 카드, 게스트 시스템의 기본 라우팅을 각각 확인해야 하며 호스트 브라우저 결과만으로 판단해서는 안 됩니다.

성능 부담은 환경에 따라 다릅니다

TUN은 가상 인터페이스를 통한 송수신, 프로토콜 스택 처리, 규칙 판정을 추가하므로 이론적으로 앱이 로컬 프록시 포트에 직접 연결하는 것보다 경로가 깁니다. 하지만 일반적인 웹 탐색에서는 그 차이가 원격 노드 지연보다 작은 경우가 많습니다. 다음 수치는 특정 환경에서의 비교 예시이며 모든 장치에 적용되지는 않습니다: Windows 11 24H2, Mihomo 1.19.8, Ryzen 7 7840U, 유선 기가비트 네트워크에서 동일한 노드와 규칙으로 10회 연속 테스트.

이 예시에서는 TUN 사용 시 첫 패킷 지연이 약 0.8ms 늘고 다운로드 처리량이 약 4.2% 감소했습니다. 그러나 원격 노드 부하, 암호화 프로토콜, 네트워크 카드 오프로딩, MTU에 따라 더 큰 변동이 생길 수 있습니다. 저전력 장치에서는 한 번의 속도 측정 최고값보다 연속 전송 중 CPU 사용률과 온도를 확인하는 편이 중요합니다.

단계별 선택과 문제 해결: 여러 스위치를 동시에 바꾸지 않기

방법 1: 먼저 시스템 프록시 확인

1. 클라이언트를 시작하고 설정을 불러온 뒤 로컬 혼합 포트가 7890인지 또는 화면에 표시된 실제 값인지 확인하세요.
2. 규칙 모드를 선택하고 테스트 도메인에 해당하는 정책 그룹을 사용 가능한 노드 하나로 먼저 고정하세요.
3. 시스템 프록시를 켜고 브라우저로 테스트 페이지에 접속하면서 연결 로그에 도메인과 정책 이름이 나타나는지 확인하세요.
4. 브라우저가 정상적으로 연결되면 터미널, 스토어 클라이언트 또는 대상 앱을 각각 테스트하고 어떤 프로그램이 로그에 나타나지 않는지 기록하세요.
5. 실제로 적용 범위의 누락이 있을 때만 시스템 프록시 테스트 항목을 끄고 TUN을 켜세요. 두 경로가 동시에 존재해 판단을 방해하지 않도록 해야 합니다.

방법 2: TUN을 켠 뒤 확인할 네 가지

1. 로그에서 TUN 인터페이스가 성공적으로 생성되었는지, 권한·라우팅·장치 사용 중 오류가 없는지 확인하세요.
2. 기본 라우팅과 실제 출구 인터페이스를 확인하고, 프록시 서버 연결이 다시 TUN으로 들어가 루프를 만들지 않는지 점검하세요.
3. DNS 로그를 확인해 질의가 Mihomo DNS 모듈로 들어가고 예상한 도메인 규칙과 일치하는지 확인하세요.
4. TCP, UDP, 로컬 네트워크 주소, 절전 모드 복귀를 각각 테스트하세요. 웹 페이지 하나가 열리는지만으로 완료 여부를 판단해서는 안 됩니다.

일반적인 증상과 해결 방향

최종 선택: 모드의 강도가 아닌 앱 적용 범위로 결정

시스템 프록시는 프록시 설정을 명확히 지원하는 브라우저와 데스크톱 앱에 적합합니다. 라우팅 테이블에 미치는 영향이 작아 일상적인 기본 방식으로 사용하기 좋고, 노드와 규칙이 정상인지 빠르게 확인하기도 쉽습니다. 터미널 도구를 가끔만 사용한다면 환경 변수를 별도로 설정하면 되므로 TUN을 계속 켤 필요가 없습니다.

TUN은 UDP, 시스템 프록시를 무시하는 프로그램, 복잡한 DNS 분할 라우팅을 처리하거나 여러 종류의 앱을 통합적으로 가로채야 하는 환경에 더 적합합니다. TUN이 제공하는 것은 노드 속도 향상이 아니라 더 완전한 트래픽 진입점입니다. 그만큼 권한, 가상 네트워크 카드, DNS, 라우팅 충돌도 함께 관리해야 합니다.

실제 설정은 “시스템 프록시는 항상 켜고 TUN은 필요할 때만” 사용하는 방식이 좋습니다. 처음 구성할 때는 시스템 프록시, 노드 선택, 규칙 일치를 먼저 정상 작동시킨 뒤 TUN으로 범위를 넓히세요. 문제가 생기면 트래픽 진입점, DNS, 라우팅, 규칙, 노드 기능 순서로 단계별 점검하는 편이 전역 모드, 규칙 모드, 여러 스위치를 번갈아 바꾸는 것보다 원인을 찾기 쉽습니다.