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

사용할 앱에 맞춰 트래픽 처리 방식 선택

브라우저나 시스템 프록시 설정을 따르는 데스크톱 앱만 사용한다면 먼저 시스템 프록시를 이용하세요. 프록시 설정을 읽지 않는 프로그램, 일부 게임 또는 UDP 트래픽까지 처리해야 한다면 TUN을 고려할 수 있습니다. TUN은 일반적으로 더 많은 트래픽을 처리하지만, 라우팅·권한·DNS 설정과 다른 VPN의 영향에 따라 실제 작동 여부가 달라집니다.

두 방식의 차이는 ‘트래픽을 어떻게 커널에 전달하느냐’에 있습니다. ‘최종적으로 어떤 노드를 거치느냐’의 차이는 아닙니다. 트래픽이 Clash 또는 mihomo에 들어온 뒤에는 규칙과 정책 그룹을 거칩니다. TUN을 켠다고 전역 프록시가 활성화되는 것은 아니며, DIRECT 규칙에 해당하는 연결은 계속 직접 연결됩니다.

시스템 프록시와 TUN의 트래픽 처리 원리

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

시스템 프록시는 보통 127.0.0.1:7890과 같은 프록시 주소를 운영체제에 등록합니다. 이 설정을 읽는 앱은 요청을 로컬에서 수신 대기 중인 포트로 전달합니다. HTTPS 사이트는 일반적으로 HTTP 프록시의 CONNECT 메서드로 터널을 만듭니다. 그렇다고 사이트 연결이 HTTP로 낮춰지는 것은 아닙니다.

앱이 시스템 설정을 읽는지는 앱에서 사용하는 네트워크 라이브러리에 따라 다릅니다. 일부 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY 등의 환경 변수만 읽고, 일부 앱은 자체 프록시 설정을 사용합니다. Windows의 일반 사용자 프록시 설정과 WinHTTP 설정도 서로 다릅니다. 서비스 프로세스가 데스크톱 사용자의 프록시 설정을 따르지 않을 수도 있습니다.

TUN: 라우팅을 통해 IP 패킷을 가상 네트워크 인터페이스로 전달

TUN은 3계층 가상 네트워크 인터페이스를 만들고, 라우팅을 통해 조건에 맞는 IP 패킷을 커널로 전달합니다. 앱이 HTTP나 SOCKS 프록시를 인식하지 않아도 되므로, 원래 TCP 또는 UDP 연결을 직접 만드는 프로그램도 트래픽 분류 대상에 포함될 수 있습니다.

그렇다고 모든 트래픽이 자동으로 처리되는 것은 아닙니다. 더 구체적인 기존 경로, 다른 VPN의 정책 라우팅, 네트워크 인터페이스 바인딩, IPv6 설정에 따라 실제 경로가 달라질 수 있습니다. TUN이 모든 프로토콜의 프록시 처리를 보장하는 것도 아닙니다. UDP는 선택한 아웃바운드 노드와 서버의 지원이 필요하므로, TCP가 된다는 이유만으로 UDP도 된다고 판단하면 안 됩니다.

비교 항목	시스템 프록시	TUN 모드
트래픽 진입 경로	앱이 HTTP 또는 SOCKS 수신 포트에 직접 연결	시스템 라우팅이 패킷을 가상 네트워크 인터페이스로 전달
앱 요구 사항	프록시 설정을 지원하거나 프록시를 직접 지정해야 함	일반적으로 앱에서 프록시 옵션을 제공할 필요가 없음
UDP 트래픽	일반적인 시스템 HTTP 프록시 설정으로는 일반 UDP 트래픽을 처리할 수 없음	처리할 수 있지만 아웃바운드와 라우팅 지원 여부에 따라 달라짐
실행 권한	일반 로컬 포트에서 수신 대기하는 데 보통 관리자 권한이 필요하지 않음	일반적으로 권한 상승, 서비스 모드 또는 네트워크 관리 권한이 필요함
DNS 동작	앱이 시스템 DNS를 계속 사용하거나 프록시에 DNS 조회를 맡길 수 있음	DNS 가로채기와 내장 리졸버를 함께 사용해 통합 처리 가능
주요 충돌 요인	포트 충돌, 앱이 시스템 설정을 무시하는 경우	VPN 라우팅, 가상 네트워크 인터페이스, DNS, 방화벽

DNS 동작은 두 모드의 주요 차이점

‘웹페이지가 열린다’고 해서 DNS도 의도대로 처리된다는 뜻은 아닙니다. 시스템 프록시를 켜도 일부 앱은 운영체제에 먼저 도메인을 조회한 다음 프록시에 연결합니다. 다른 앱은 도메인 조회를 프록시에 직접 맡깁니다. SOCKS도 로컬 DNS 조회와 원격 DNS 조회 방식이 다르므로, 테스트할 때는 어떤 방식을 사용했는지 명시해야 합니다.

53번 포트 가로채기와 암호화 DNS의 범위

mihomo의 dns-hijack는 조건에 맞는 기존 DNS 요청을 내장 DNS로 전달할 수 있습니다. 흔히 사용하는 any:53은 UDP 53번 포트에 적용되며, TCP 53번 포트도 처리하려면 tcp://any:53을 추가할 수 있습니다. 이 설정이 모든 도메인 조회를 자동으로 인식한다는 뜻은 아닙니다.

브라우저의 DoH는 HTTPS를 사용하고, DoT는 일반적으로 TCP 853번 포트를, DoQ는 일반적으로 UDP 853번 포트를 사용합니다. 53번 포트 가로채기를 설정했다고 해서 이 요청들이 자동으로 내장 DNS를 거치지는 않습니다. 연결 자체는 TUN에 들어갈 수 있지만, 암호화된 조회 내용이 커널 DNS로 전달되는 것은 아닙니다. 도메인 기반 트래픽 분류가 제대로 작동하는지는 도메인 매핑과 스니핑 설정에도 달려 있습니다.

fake-ip가 반환한 주소는 DNS 오류가 아닙니다

fake-ip를 사용하면 내장 DNS가 매핑 주소를 반환할 수 있습니다. 흔히 쓰이는 대역은 198.18.0.0/16이며, 커널은 이후 연결을 원래 도메인에 연결합니다. 198.18.x.x 주소가 보인다고 바로 DNS를 바꾸지 마세요. 앱의 트래픽이 여전히 TUN으로 처리되는지, 매핑이 유효한지 먼저 확인해야 합니다.

DNS 모드를 변경한 뒤에는 테스트 앱을 완전히 종료했다가 다시 실행해 이전 연결과 캐시를 사용하지 않도록 하세요.
Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. 브라우저에 별도의 캐시가 남아 있을 수도 있습니다.
로컬 네트워크 장치 이름과 기업 내부 도메인에는 연결 가능한 내부 DNS를 사용하세요. 모든 조회를 공용 DNS 리졸버로 보내면 안 됩니다.
IPv4 테스트는 정상인데 IPv6가 실패한다면 IPv6 라우팅과 DNS 응답을 각각 확인하세요. A 레코드만 확인해서는 안 됩니다.

mihomo 설정 및 활성화 절차

정상 작동하는 설정을 먼저 백업한 다음 트래픽 처리 방식을 변경하세요. 아래는 필드를 기존 설정에 병합하는 예시이지, 전체 구독 설정이 아닙니다. 기존 proxies, proxy-groups, rules는 유지하세요. 기존 파일에 tun 또는 dns가 있다면 해당 맵에 병합해야 합니다. 최상위 필드 이름을 중복해서 만들지 마세요.

먼저 로컬 프록시 진입점 확인

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

mixed-port를 사용하면 HTTP와 SOCKS가 포트를 공유합니다. allow-lan: false는 다른 로컬 네트워크 기기에 프록시 서비스를 공개하지 않도록 설정합니다. TUN으로 이 기기의 트래픽을 처리하는 데 LAN 접근 허용은 필요하지 않습니다. 여기서 mode: rule은 규칙 기반 분류를 유지하는 설정이며, 노드나 규칙 자체를 대신하지 않습니다.

그다음 TUN 및 DNS 필드 병합

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

예시에 표시된 공용 DNS 주소 두 개는 구체적인 업스트림 설정 예시일 뿐, 모든 네트워크에 적합한 것은 아닙니다. 기업 내부망, 학교 네트워크 또는 별도의 DNS 정책을 사용하는 환경에서는 실제 요구 사항에 맞춰 업스트림과 도메인 조회 정책을 설정하세요. listen의 1053은 내장 DNS의 수신 포트입니다. 시스템 프록시 포트가 아니며, 이 필드만으로 시스템 DNS가 해당 포트로 자동 변경되지도 않습니다.

stack: mixed는 혼합 프로토콜 스택을 선택합니다. 지원 여부는 커널에 따라 다릅니다. 호환성 문제가 생기면 커널 문서를 참고해 다른 스택과 비교하세요.
auto-route: true는 TUN으로 트래픽이 들어가도록 라우팅을 자동 설정합니다. 다른 VPN의 경로가 반드시 우선순위에서 밀린다는 뜻은 아닙니다.
auto-detect-interface: true는 인터넷 연결에 사용할 인터페이스를 자동으로 식별합니다. 네트워크 인터페이스가 여러 개이거나 테더링 및 VPN을 함께 사용하는 경우 실제 출구 인터페이스를 확인하세요.
dns.enable과 tun.enable은 서로 다른 스위치입니다. TUN을 켰다고 내장 DNS도 반드시 켜지는 것은 아닙니다.

순서대로 시작하고 확인하기

기존 노드가 시스템 프록시에서 정상 작동하는지 확인한 뒤 다른 VPN을 잠시 끄고, 기존 네트워크 설정을 기록해 두세요.
클라이언트 안내에 따라 서비스를 설치하거나 관리자 권한을 부여한 다음 TUN을 켜세요. 모바일 기기에서는 보통 시스템 VPN 권한을 승인해야 합니다.
설정을 다시 불러오고 시작 로그에서 필드 오류, 권한 부족, 네트워크 인터페이스 생성 실패 또는 포트 충돌이 있는지 확인하세요.
시스템 프록시를 잠시 끄고 TUN만 켠 상태에서 브라우저와 원래 프록시 설정을 따르지 않던 앱을 각각 테스트하세요.
연결 기록에서 대상, 일치한 규칙, 최종 정책을 확인하세요. 트래픽이 커널에 들어오는 것뿐 아니라 의도한 경로로 나가는지도 확인해야 합니다.

두 가지 테스트로 포트와 라우팅 문제 구분

테스트할 때는 한 번에 조건 하나만 바꾸세요. 아래 명령은 같은 HTTPS 주소를 사용해 프록시를 명시하는 경로와 앱 레벨 프록시를 사용하지 않는 경로를 비교합니다. Windows PowerShell에서는 일부 환경의 curl 별칭이 매개변수에 영향을 줄 수 있으므로 curl.exe를 사용하는 것이 좋습니다.

테스트 1: HTTP 프록시 진입점만 확인

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

TUN을 끈 상태에서 실행하는 것이 좋습니다. --noproxy ""는 이번 요청에서 프록시 우회 목록을 비우고 로컬 7890 포트를 명시적으로 사용합니다. 연결이 거부되면 먼저 포트가 수신 대기 중인지, 커널이 실행 중인지 확인하세요. 프록시가 요청을 받았지만 대상 연결이 시간 초과되면 노드, 규칙, 대상 사이트를 확인하세요.

테스트 2: TUN 트래픽 처리 경로만 확인

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

시스템 프록시를 끄고 TUN을 켠 다음 실행하세요. --noproxy "*"는 curl이 앱 레벨 프록시를 사용하지 않게 하지만, 운영체제의 TUN 라우팅을 우회하지는 않습니다. 실행 후 커널의 연결 기록을 확인하세요. 명령이 성공했다는 사실만으로 프록시를 거쳤다고 단정할 수는 없습니다. 대상에 직접 연결되었을 수도 있습니다.

이 두 명령은 HTTPS 요청만 테스트하며 게임의 UDP, 음성 통화 또는 QUIC은 확인하지 않습니다. 이런 환경을 테스트하려면 실제 앱에서 세션을 만들고, 해당 UDP 연결이 표시되는지, 어떤 규칙에 일치하는지, 아웃바운드가 UDP를 지원하는지 확인해야 합니다.

라우팅 및 DNS 상태 확인

# Windows
route print
ipconfig /all
netsh winhttp show proxy

# Linux
ip rule show
ip route show table all
resolvectl status

# macOS
scutil --proxy
scutil --dns
netstat -rn

아래 명령은 상태를 확인할 뿐 네트워크 설정을 변경하지 않습니다. Linux의 resolvectl은 해당 도구를 제공하는 시스템에서만 사용할 수 있습니다. 도구가 없다면 현재 네트워크 관리자의 DNS 설정을 확인하세요. 자동 라우팅은 별도의 라우팅 테이블을 만들 수 있으므로 기본 라우팅 테이블만 확인해서는 충분하지 않습니다.

자주 발생하는 오류와 호환성 문제 해결

시스템 프록시는 작동하지만 TUN을 켜면 인터넷에 연결되지 않음

먼저 TUN 권한, 네트워크 인터페이스 생성, 출구 라우팅을 확인하세요. TUN을 끈 뒤 네트워크가 복구되는지 확인하고, 다시 TUN만 켜서 테스트하세요. 회사 VPN에 연결했을 때만 실패한다면 노드를 계속 바꾸기보다 라우팅과 내부 DNS 설정을 조정해야 하는 경우가 많습니다.

기본 경로를 함부로 삭제하거나 정체를 알 수 없는 네트워크 서비스를 종료하지 마세요. 원격 데스크톱 환경에서 TUN 경로를 변경하면 원격 연결이 끊길 수 있습니다. 로컬에서 조작할 방법이나 설정을 되돌릴 방안을 먼저 준비하세요.

브라우저는 되지만 명령줄 도구나 게임은 연결되지 않음

시스템 프록시만 켠 상태라면 해당 앱이 프록시 진입점을 사용하지 않는 경우가 많습니다. 명령줄 도구는 프록시를 명시해 먼저 확인하고, 게임은 UDP를 사용하는지와 노드가 해당 트래픽을 지원하는지 확인하세요. TUN을 켠 뒤에도 연결되지 않으면 문제를 무조건 ‘트래픽 처리 실패’로 단정하지 말고 연결 기록을 살펴보세요.

내부 네트워크 장치, 프린터 또는 회사 도메인에 연결할 수 없음

먼저 연결 라우팅 문제인지 이름 조회 문제인지 구분하세요. 장치 IP로는 접속할 수 있지만 이름으로는 안 된다면 내부 DNS를 중점적으로 확인하세요. IP로도 연결할 수 없다면 로컬 네트워크 라우팅과 규칙을 살펴보세요. 대상을 DIRECT로 설정하면 커널에 들어온 뒤의 아웃바운드 방식만 결정됩니다. 앱의 브로드캐스트 또는 멀티캐스트 탐색 문제까지 해결되는 것은 아닙니다.

두 모드를 동시에 켜도 되나요?

일부 클라이언트는 시스템 프록시와 TUN을 동시에 켤 수 있습니다. 일반적으로 커널은 루프백을 방지하도록 자체 아웃바운드를 처리하지만, 두 모드를 함께 사용하면 더 안정적이라고 볼 수는 없습니다. 문제를 해결할 때는 먼저 각 방식을 따로 확인하세요. 계속 사용할 때는 필요한 트래픽 처리 범위에 맞춰 스위치를 선택하세요. 다른 프록시 프로그램이나 VPN을 함께 실행하면 진입점이 불명확해지고 라우팅 충돌이 생길 가능성이 더 큽니다.

Android와 iOS에도 데스크톱 설정을 그대로 적용해도 되나요?

그렇지 않습니다. 모바일 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 처리하는 경우가 많으며, 권한 승인·앱 제외·백그라운드 실행 규칙은 플랫폼과 클라이언트에 따라 달라집니다. 일반적인 모바일 기기에서는 사용자 수준 VPN 연결을 한 번에 하나만 유지할 수 있는 경우가 많습니다. 이 문서의 YAML은 모바일 시스템 권한을 대신할 수 없으며, 다른 클라이언트가 같은 필드를 지원한다고 보장하지도 않습니다.

사용 사례에 맞춰 필요한 설정만 유지

브라우저와 일반 데스크톱 앱: 먼저 시스템 프록시를 사용하고 앱이 실제로 해당 설정을 읽는지 확인하세요.
개발 도구와 터미널: 먼저 도구 자체의 프록시 옵션을 사용하세요. 여러 도구의 트래픽을 한꺼번에 처리해야 할 때 TUN을 검토하면 됩니다.
게임, 음성 통화 및 프록시를 지원하지 않는 프로그램: TUN을 사용할 수 있지만 UDP, 노드 지원 여부, 규칙을 각각 확인해야 합니다.
기업 VPN, 여러 네트워크 인터페이스, 복잡한 내부망: 먼저 라우팅과 DNS를 기록한 다음 어떤 연결을 처리할지 정하세요. 여러 네트워크 계층을 한 번에 변경하지 마세요.

안정적인 설정은 대상 앱이 의도한 진입점을 사용하고, DNS가 네트워크 환경에 맞게 조회되며, 올바른 규칙이 적용되고, 트래픽 처리를 끈 뒤 네트워크가 복구되는 상태입니다. 설정 필드를 확인하려면 설정 레퍼런스를, 일반적인 연결 문제는 FAQ를 참고해 항목별로 점검하세요.