TUN 모드와 시스템 프록시의 차이: 트래픽 가로채기 원리와 모드 선택 가이드

핵심부터 보면: 차이는 프록시 규칙이 아니라 트래픽 진입점에 있습니다

시스템 프록시와 TUN 모드는 모두 연결을 Clash 또는 mihomo로 전달한 뒤, 규칙에 따라 프록시 노드, 직접 연결 또는 차단을 선택합니다. 실제 차이는 규칙 매칭 전에 발생합니다. 시스템 프록시는 애플리케이션이 직접 요청을 로컬 프록시 포트로 보내기를 기다리지만, TUN 모드는 가상 네트워크 인터페이스와 시스템 라우팅을 통해 트래픽을 받습니다.

따라서 같은 구독, 같은 규칙, 같은 노드라도 두 모드에서 결과가 달라질 수 있습니다. 브라우저는 시스템 프록시로 정상 접속되는데 게임 런처만 직접 연결된다면, 대개 규칙 오류가 아니라 게임 런처가 운영체제의 프록시 설정을 읽지 않기 때문입니다. TUN으로 전환하면 해당 연결이 mihomo로 들어와 규칙이 처리할 수 있습니다.

비교 항목	시스템 프록시	TUN 모드
트래픽 진입점	애플리케이션이 시스템 프록시 설정을 읽은 뒤 로컬 HTTP 또는 SOCKS 포트에 연결	운영체제 라우팅이 네트워크 패킷을 가상 네트워크 어댑터로 전달
일반적인 적용 범위	브라우저, 시스템 프록시를 따르는 데스크톱 프로그램	브라우저, 명령줄 프로그램, 게임 런처 및 더 많은 UDP 애플리케이션
권한 요구 사항	대개 일반 사용자 권한만 필요	서비스 설치, 네트워크 확장 기능 또는 관리자 권한 필요
UDP 처리	애플리케이션이 SOCKS5 UDP를 직접 사용하는지에 따라 달라짐	네트워크 계층에서 UDP를 받은 뒤 커널과 노드 지원 여부에 따라 처리
장애 영향 범위	주로 프록시 설정을 읽는 애플리케이션에 영향	라우팅 또는 DNS 설정에 문제가 있으면 기기 전체의 네트워크 연결에 영향을 줄 수 있음
적합한 사용 환경	웹 브라우징, 문서 작업, 일반적인 데스크톱 업무	시스템 프록시를 읽지 않는 프로그램, UDP 트래픽, 통합 트래픽 분기

시스템 프록시의 작동 방식: 애플리케이션이 로컬 포트에 직접 연결

Clash 클라이언트에서 「시스템 프록시」를 활성화하면 운영체제에 저장된 프록시 주소가 변경됩니다. 일반적으로 HTTP 및 HTTPS 프록시를 127.0.0.1:7890으로 지정합니다. 설정에 mixed-port: 7890을 사용하면 하나의 포트에서 HTTP와 SOCKS5 요청을 모두 받을 수 있습니다. 포트 번호는 변경할 수 있으며, 7890은 클라이언트에서 흔히 사용하는 기본값일 뿐입니다.

애플리케이션은 요청을 보내기 전에 먼저 이 설정을 읽어야 합니다. 이후 브라우저나 데스크톱 프로그램은 127.0.0.1:7890에 연결하고, 프록시 커널에 대상 도메인과 포트를 전달합니다. mihomo는 요청을 받은 뒤 DOMAIN-SUFFIX, GEOIP, IP-CIDR, 최종 규칙 등을 차례로 확인하고 해당 정책 그룹을 선택합니다.

일반적으로 시스템 프록시를 읽는 프로그램

Chrome, Edge, Safari 등 시스템 네트워크 설정을 사용하는 브라우저.
대부분의 시스템 HTTP 네트워크 인터페이스를 사용하는 데스크톱 애플리케이션.
「시스템 프록시 사용」옵션을 명시적으로 제공하는 프로그램.
환경 변수나 자체 설정으로 프록시를 지정하는 명령줄 도구.

시스템 프록시를 자주 우회하는 프로그램

자체 네트워크 스택을 구현했거나 독립적인 프록시 옵션을 내장한 프로그램.
일부 게임, 게임 런처, 음성 프로그램 및 업데이트 서비스.
Windows 및 macOS의 시스템 프록시 설정을 읽지 않는 명령줄 프로그램.
일부 실시간 통신 및 온라인 게임을 포함해 UDP 패킷을 직접 전송하는 애플리케이션.
시스템 서비스로 실행되며 독립적인 네트워크 세션을 사용하는 백그라운드 프로세스.

명령줄 도구는 특히 오판하기 쉽습니다. 예를 들어 Windows 터미널에서 curl을 실행할 때의 동작은 curl의 빌드 방식, 환경 변수, 명령 인자에 따라 달라집니다. 프록시 포트가 실제로 작동하는지 명확히 테스트하려면 다음 명령을 직접 실행할 수 있습니다:

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --proxy socks5h://127.0.0.1:7890 https://example.com/

두 번째 명령의 socks5h는 도메인 조회도 SOCKS5 프록시 측에서 처리한다는 뜻입니다. socks5만 입력하면 curl이 로컬에서 먼저 도메인을 조회한 뒤 조회된 IP에 연결할 수 있습니다. 두 방식에 따라 도메인 규칙의 매칭 여부가 달라집니다.

시스템 프록시 모드의 주요 장점

활성화와 비활성화가 빠르고, 일반적으로 라우팅 테이블을 수정할 필요가 없습니다.
로컬 네트워크 접속, 프린터 서비스, 가상 머신 네트워크에 미치는 영향이 적습니다.
장애 범위가 명확합니다. 시스템 프록시를 끄면 다른 설정의 영향을 받지 않는 애플리케이션은 직접 연결로 복구됩니다.
구독, 노드, 규칙 그룹, 로컬 포트가 정상인지 먼저 확인하는 데 적합합니다.

TUN 모드의 작동 방식: 가상 네트워크 어댑터, 라우팅, 프로토콜 스택

TUN은 3계층 가상 네트워크 인터페이스입니다. 활성화하면 클라이언트가 가상 네트워크 어댑터를 만들고, 라우팅 규칙에 따라 조건에 맞는 IPv4 또는 IPv6 패킷을 해당 인터페이스로 보냅니다. mihomo는 TUN 인터페이스에서 IP 패킷을 읽어 TCP, UDP, DNS 등의 트래픽을 식별한 뒤 대상 주소, 도메인 매핑, 규칙을 바탕으로 트래픽을 분기합니다.

시스템 프록시는 애플리케이션이 이미 구성한 프록시 요청을 처리하지만, TUN은 네트워크 계층에 더 가까운 원시 패킷을 받습니다. 애플리케이션은 로컬에 프록시 포트가 있다는 사실을 알 필요도, 「프록시 사용」옵션을 제공할 필요도 없습니다. 이것이 TUN이 더 많은 프로그램을 적용할 수 있는 이유입니다.

‘전체 가로채기’가 모든 패킷을 반드시 프록시 노드로 보낸다는 뜻은 아닙니다. 로컬 네트워크 대역, mihomo 자체 연결, 기본 출구 인터페이스, 명시적으로 제외한 프로세스는 TUN을 우회해야 라우팅 루프를 피할 수 있습니다. 트래픽이 mihomo로 들어온 뒤에도 규칙에 따라 DIRECT를 선택해 로컬 네트워크로 직접 보낼 수 있습니다.

읽기 쉬운 mihomo TUN 설정

mixed-port: 7890
mode: rule

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

enable: TUN 인터페이스를 활성화합니다.
stack: TUN에서 사용할 프로토콜 스택을 선택합니다. mihomo의 일반적인 옵션은 system, gvisor, mixed이며, 사용 가능한 값은 현재 커널 버전의 문서를 기준으로 확인해야 합니다.
auto-route: 필요한 라우팅을 자동으로 설정해 라우팅 테이블을 수동으로 추가하는 작업을 줄입니다.
auto-detect-interface: Wi-Fi나 유선 네트워크 어댑터처럼 현재 기본 출구를 자동으로 식별합니다.
dns-hijack: 53번 포트로 전송되는 기존 DNS 질의를 받아 mihomo DNS 모듈에서 처리합니다.
strict-route: 더 엄격한 라우팅 처리를 사용합니다. 활성화하기 전에 가상 머신, 로컬 네트워크, 다중 네트워크 어댑터 환경을 확인해야 합니다.

GUI 클라이언트는 보통 이러한 필드를 대신 생성합니다. Windows에서는 일반적으로 「설정」→「시스템 설정」→「서비스 모드」로 이동해 먼저 시스템 서비스를 설치한 다음, 「설정」→「네트워크 설정」에서 TUN을 활성화합니다. 클라이언트에 따라 메뉴 이름이 「Service Mode」, 「관리자 서비스」 또는 「가상 네트워크 어댑터」로 표시될 수 있습니다. macOS 클라이언트는 대개 네트워크 확장 기능 추가를 요청하며, 시스템 계정 암호를 한 번 입력해야 합니다.

TUN에 더 높은 권한이 필요한 이유

가상 네트워크 어댑터 생성, 라우팅 테이블 수정, DNS 가로채기 설정은 모두 시스템 수준의 네트워크 작업입니다. Windows 클라이언트는 주로 백그라운드 서비스로 이를 수행하고, macOS는 네트워크 확장 기능을 사용하며, Linux는 CAP_NET_ADMIN 또는 root 권한이 필요합니다. 권한 처리가 일부만 완료되면 화면에는 TUN이 켜진 것으로 표시되지만 실제 라우팅은 가상 인터페이스로 향하지 않을 수 있습니다.

확인할 때 스위치 상태만 보지 마세요. Windows에서는 ipconfig와 route print를 실행해 가상 네트워크 어댑터와 기본 라우팅이 존재하는지 확인할 수 있습니다. macOS에서는 ifconfig와 netstat -rn, Linux에서는 ip addr와 ip route를 사용합니다. 인터페이스 이름은 클라이언트와 시스템에 따라 달라지므로 특정 이름만으로 판단해서는 안 됩니다.

두 모드의 차이가 크게 나타나는 지점은 DNS입니다

시스템 프록시 모드에서 브라우저가 도메인을 HTTP 프록시에 전달하면, mihomo는 도메인을 직접 받아 DOMAIN 또는 DOMAIN-SUFFIX 규칙과 매칭할 수 있습니다. 하지만 일부 애플리케이션은 로컬에서 먼저 DNS를 조회한 다음 IP에 직접 연결합니다. 이 경우 커널에는 대상 IP만 보이므로 도메인 규칙이 매칭에 참여하지 못할 수 있습니다.

TUN 모드는 mihomo DNS 모듈 및 Fake-IP와 함께 사용하는 경우가 많습니다. DNS 질의가 먼저 mihomo로 들어가면 커널이 도메인에 매핑 주소를 반환합니다. 애플리케이션이 이 주소에 연결할 때 mihomo가 원래 도메인을 복원하고 규칙을 적용합니다. 따라서 원래 IP만 노출되는 연결도 도메인 규칙을 계속 활용할 수 있습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

198.18.0.0/15는 벤치마크 용도로 예약된 주소 대역이며 Fake-IP 매핑에 자주 사용됩니다. 원격 서버의 실제 IP가 아닙니다. 연결 목록에 198.18.x.x가 보인다고 해서 애플리케이션이 해당 공인 주소에 접속 중이라는 뜻은 아닙니다. mihomo가 매핑 테이블을 통해 도메인을 복원하고 있다는 의미입니다.

Fake-IP 필터 범위를 무작정 넓히지 마세요

일부 로컬 네트워크 장치 검색, 기업 내부망, 게임 플랫폼 로그인, 실제 DNS 응답에 의존하는 프로그램은 fake-ip-filter에 추가해야 합니다. 하지만 필터 항목이 너무 많으면 도메인 매핑 범위가 줄어 연결이 다시 IP만으로 매칭될 수 있습니다. 문제를 해결할 때는 모든 주요 최상위 도메인을 일괄 필터링하지 말고 해당 도메인만 추가해야 합니다.

60초 비교 테스트로 DNS가 커널에 들어오는지 확인

TUN을 끄고 시스템 프록시만 유지한 뒤 클라이언트의 연결 기록을 삭제합니다.
대상 프로그램을 실행해 60초 동안 사용하면서 연결 페이지의 도메인 수, IP 연결 수, 규칙 매칭 항목을 기록합니다.
대상 프로그램을 종료하고 TUN을 활성화한 다음 연결 기록을 다시 삭제한 뒤 같은 작업을 반복합니다.
첫 번째 테스트에서 브라우저 도메인만 소수 기록되고 두 번째 테스트에서 대상 프로그램 프로세스, UDP 연결, 더 많은 도메인이 나타난다면 차이는 트래픽 진입점에서 발생한 것입니다.

Windows 11과 mihomo 1.19 계열 커널을 사용한 한 비교 테스트에서, 특정 런처는 시스템 프록시 모드로 60초 동안 웹 로그인 연결 7개만 기록했고 업데이트 프로세스의 TCP 연결 34개는 시스템 네트워크 어댑터에 직접 나타났습니다. TUN을 활성화하자 연결 페이지에 관련 연결 41개가 기록되었고, 그중 36개가 도메인 규칙으로 처리되었습니다. 이 수치는 테스트 방법을 설명하기 위한 예시이며 실제 연결 수는 프로그램 버전, 캐시 상태, 네트워크 환경에 따라 달라집니다.

사용 환경에 따라 시스템 프록시와 TUN 선택

브라우저와 일반 데스크톱 프로그램만 처리한다면: 먼저 시스템 프록시

주요 요구 사항이 웹 접속, 코드 저장소, 문서 검색, 프록시 설정을 지원하는 메신저라면 시스템 프록시가 대체로 더 간단합니다. 먼저 구독 업데이트가 가능한지, 노드 지연 시간을 측정할 수 있는지, 로컬 7890 포트가 수신 중인지 확인한 다음 규칙 모드가 올바르게 매칭되는지 살펴보세요. 이 단계에서는 가상 네트워크 어댑터와 DNS 가로채기를 함께 도입할 필요가 없습니다.

프로그램에 프록시 옵션이 없다면: TUN 사용

게임 런처, 스토어 클라이언트, 시스템 업데이트 구성 요소, 일부 Electron 애플리케이션은 시스템 프록시를 우회할 수 있습니다. 연결 페이지에서 대상 프로세스가 전혀 보이지 않는다면 규칙 그룹을 바꿔도 효과가 없습니다. 이때 TUN을 활성화해 트래픽을 먼저 커널로 보낸 뒤 도메인, IP, 포트 또는 프로세스 규칙에 따라 분기합니다.

UDP를 처리해야 한다면: TUN 우선 검토

음성 통화, 실시간 통신, 온라인 게임, QUIC 기반 연결은 UDP를 사용합니다. 기존 HTTP 시스템 프록시는 임의의 UDP 패킷을 직접 받을 수 없지만 TUN은 네트워크 계층에서 UDP를 가져올 수 있습니다. 이후 프록시 노드를 통해 전송할 수 있는지는 프록시 프로토콜, 서버, 클라이언트 커널의 UDP 지원 여부에 따라 달라집니다.

개발 환경과 명령줄 도구: 두 방식 모두 사용 가능

소수의 명령만 프록시를 사용하면 환경 변수를 명시적으로 설정해 적용 범위를 제어하는 편이 쉽습니다:

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

Windows PowerShell에서는 현재 세션에 다음과 같이 설정할 수 있습니다:

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

컨테이너, 패키지 관리자, 여러 개발 서비스에 통합 트래픽 분기가 필요하면 환경 변수를 하나씩 관리하기가 복잡해지므로 TUN이 더 간편할 수 있습니다. 다만 Docker, WSL, 가상 머신, 호스트는 서로 다른 네트워크 대역을 사용할 수 있으므로 활성화 후 컨테이너 DNS, 포트 매핑, 로컬 네트워크 접속을 확인해야 합니다.

Wi-Fi, 유선 네트워크, 핫스팟을 자주 전환한다면: 자동 출구부터 확인

TUN은 올바른 기본 출구에 의존합니다. 네트워크를 전환한 뒤 연결이 끊기면 클라이언트의 「설정」→「네트워크 설정」→「인터페이스 자동 감지」를 먼저 켜거나 설정에서 auto-detect-interface: true를 사용해 보세요. 다중 네트워크 어댑터 기기에서 자동 감지가 불안정하면 인터페이스를 명시적으로 지정하고, 네트워크가 바뀔 때마다 라우팅을 확인해야 합니다.

TUN 활성화 후 인터넷이 되지 않을 때의 점검 순서

TUN 장애가 발생했다고 노드 목록부터 반복해서 바꾸는 것은 효율적이지 않습니다. 먼저 가상 인터페이스와 DNS를 확인한 뒤 규칙과 노드를 점검하면 로컬 네트워크 문제와 원격 연결 문제를 더 빠르게 구분할 수 있습니다.

1단계: 커널, 서비스, 가상 네트워크 어댑터 확인

클라이언트 커널이 TUN을 지원하는 mihomo 버전인지 확인하고, 커널이 정상적으로 시작되었는지 점검합니다.
클라이언트의 「설정」→「시스템 설정」에서 서비스 모드 또는 관리자 서비스가 설치되어 있는지 확인합니다.
TUN을 끄고 3초간 기다린 뒤 다시 켜면서 로그에 권한, 라우팅 또는 인터페이스 생성 오류가 나타나는지 확인합니다.
시스템 네트워크 인터페이스 목록을 확인해 TUN 활성화 전후로 가상 인터페이스가 실제로 추가되었는지 점검합니다.

2단계: 노드만 바꾸지 말고 DNS 확인

nslookup example.com을 실행해 조회 결과가 반환되는지 확인합니다.
Fake-IP 모드에서 198.18.x.x가 반환되는 것은 일반적인 현상입니다.
DNS가 시간 초과되면 53번 포트 가로채기, 클라이언트 DNS 스위치, 상위 DNS 주소를 확인합니다.
도메인은 실패하지만 IP에 직접 접속하면 응답이 오는 경우 문제는 대개 DNS 경로에 있습니다.

3단계: 라우팅 루프 차단

mihomo가 프록시 서버에 접속하는 연결은 실제 물리 네트워크 어댑터를 통해 나가야 합니다. 이 연결이 다시 TUN으로 들어가면 루프가 발생합니다. auto-detect-interface는 대부분의 단일 네트워크 어댑터 환경을 처리할 수 있지만, VPN, 가상 머신, 다중 회선, 여러 기본 라우팅이 공존하는 환경에서는 실제 출구와 라우팅 우선순위를 확인해야 합니다.

4단계: 로컬 네트워크와 예약 주소 확인

라우터 관리 페이지, NAS, 프린터, 화면 전송 장치는 대개 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 대역에 있습니다. 이러한 연결은 일반적으로 직접 연결로 유지해야 합니다. 규칙에 다음과 같이 명시할 수 있습니다:

- 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

5단계: 일시적으로 변수를 줄이기

문제를 점검할 때는 작동이 확인된 노드 하나만 남기고 추가 스크립트와 복잡한 오버라이드를 끈 뒤 간단한 규칙으로 TCP, UDP, DNS를 확인하세요. 기본 연결이 복구되면 규칙 세트, 프로세스 규칙, DNS 필터 항목을 하나씩 다시 추가합니다. 여러 스위치를 한 번에 바꾸면 어떤 항목이 변화를 일으켰는지 판단하기 어렵습니다.

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

대부분의 클라이언트에서는 두 스위치를 동시에 켤 수 있지만 일반적으로 그럴 필요는 없습니다. TUN을 켜면 브라우저 트래픽이 이미 가상 네트워크 어댑터를 통해 mihomo로 들어갈 수 있습니다. 여기에 시스템 프록시까지 활성화하면 브라우저가 먼저 로컬 프록시 포트에 연결하므로 로컬 연결과 이후 출구가 TUN 루프를 올바르게 피해야 합니다. 완성도 높은 클라이언트는 이러한 세부 사항을 처리하지만, 진입점이 두 개면 문제를 파악하기가 더 어려워집니다.

더 명확한 방법은 단계별로 활성화하는 것입니다. 일상적인 웹 접속에는 시스템 프록지만 켜고, 시스템 프록시를 읽지 않는 프로그램을 만났을 때는 시스템 프록시를 끈 뒤 TUN만 별도로 테스트하세요. TUN이 안정적으로 작동하는 것을 확인한 다음 클라이언트 안내에 따라 시스템 프록시를 유지할지 결정합니다. 전환할 때는 연결 페이지를 관찰해 동일한 요청이 비정상적으로 반복되지 않는지 확인하세요.

실제로 적용할 수 있는 선택 목록

브라우저 접속이 중심이라면: 시스템 프록시.
특정 명령 하나만 프록시를 사용한다면: 명령 인자 또는 환경 변수.
대상 프로그램이 연결 페이지에 나타나지 않는다면: TUN.
UDP가 필요하거나 여러 애플리케이션을 통합 처리해야 한다면: TUN.
가상 머신, 기업 내부망, 다중 네트워크 어댑터 환경이라면: 먼저 시스템 프록시를 사용하고 TUN은 좁은 범위에서 검증.
TUN 활성화 후 인터넷이 끊긴다면: 가상 네트워크 어댑터, DNS, 라우팅 루프, 로컬 네트워크 규칙 순서로 확인.

최종 판단 기준은 어느 스위치의 적용 범위가 더 넓은지가 아니라, 대상 트래픽이 안정적으로 커널에 들어오는지, 규칙이 예상대로 매칭되는지, 직접 연결해야 할 리소스를 계속 사용할 수 있는지입니다. 시스템 프록시는 변경을 최소화한 애플리케이션 계층 연결에 적합하고, TUN은 네트워크 계층의 통합 가로채기에 적합합니다. 먼저 처리할 애플리케이션과 프로토콜을 정한 뒤 진입점을 선택하는 것이 노드를 반복해서 바꾸는 것보다 효과적입니다.