TUN 가상 네트워크 어댑터와 시스템 프록시 비교: 트래픽 처리 범위와 선택 기준
시스템 프록시는 앱이 설정을 따를 때만 적용되지만, TUN은 네트워크 계층에서 트래픽을 처리합니다. 적용 범위와 권한, 호환성을 비교하고 선택 기준을 안내합니다.
1. 트래픽을 가져오는 방식과 프록시 분기는 다릅니다
시스템 프록시와 TUN은 앱에서 발생한 연결을 Clash 코어로 전달하는 같은 문제를 다룹니다. 연결이 코어에 들어온 뒤에는 규칙, 정책 그룹, 노드에 따라 직접 연결하거나 프록시를 사용하거나 차단합니다. 따라서 TUN을 켠다고 전체 트래픽이 프록시를 거치는 것은 아니며, 시스템 프록시를 쓴다고 규칙 모드만 사용할 수 있는 것도 아닙니다.
이 글에서는 Clash Meta(mihomo) 코어를 기준으로 TUN을 설명합니다. 클라이언트마다 토글 위치, 서비스 설치 방식, 기본 포트가 다르며 구버전 Clash 클라이언트는 아래 설정 항목을 모두 지원하지 않을 수 있습니다. 설정 전에 앱 이름에 Clash가 있는지만 보지 말고, 클라이언트의 코어 정보에서 실제 실행 중인 코어가 mihomo인지 확인하세요.
대표적인 연결 경로 두 가지
- 시스템 프록시: 브라우저가 시스템 프록시 설정을 읽고 로컬 HTTP 프록시 포트로 연결을 보낸 뒤, 코어가 트래픽을 분기합니다.
- TUN: 앱은 일반적인 방식으로 IP 연결을 시작하고, 운영체제 라우팅이 조건에 맞는 패킷을 가상 네트워크 어댑터로 전달하면 코어가 처리합니다.
- 앱별 프록시: Git, 명령줄 도구, 메신저 등에 SOCKS5 또는 HTTP 주소를 직접 입력합니다. 시스템 프록시 토글에 의존하지 않는 세 번째 연결 방식입니다.
2. 적용 범위 비교: 브라우저, 명령줄, UDP
시스템 프록시는 앱이 읽어 사용하는 설정일 뿐, 네트워크 계층에서 트래픽을 가로채는 기능은 아닙니다. Windows의 네트워크 API 종류, 앱 자체 네트워크 라이브러리, macOS 앱의 프록시 설정 지원 여부에 따라 동작이 달라질 수 있습니다. 브라우저에서 연결된다고 해서 같은 기기의 모든 앱도 프록시에 연결된 것은 아닙니다.
| 대상 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 시스템 설정을 따르는 브라우저 | 대체로 연결 가능하며 웹 브라우징에 적합 | 대체로 연결 가능하지만 라우팅과 규칙의 영향을 받음 |
| curl, Git, 빌드 도구 | 시스템 설정을 읽지 않을 수 있어 환경 변수나 앱별 설정이 필요한 경우가 많음 | 대개 앱마다 프록시 주소를 설정할 필요가 없음 |
| 게임, 음성 통화, QUIC | HTTP 시스템 프록시는 일반적으로 UDP 연결을 처리하지 않음 | 지원되는 UDP 트래픽을 처리할 수 있지만 노드와 연결 경로도 UDP를 지원해야 함 |
| 로컬 네트워크 프린터, NAS | 프록시 우회 목록과 앱 동작에 따라 다름 | 로컬 라우팅, 직접 연결 규칙, 주소 제외 설정을 확인해야 함 |
| 다른 기기의 트래픽 | 이 기기에만 설정해도 다른 기기의 트래픽까지 자동으로 처리되지 않음 | 이 기기에서 TUN을 켜도 자동으로 로컬 네트워크 게이트웨이가 되지는 않음 |
UDP 지원 여부는 전체 연결 경로를 확인해야 합니다
HTTP 프록시 포트는 범용 UDP 터널이 아닙니다. SOCKS5 프로토콜에는 UDP 릴레이가 정의되어 있지만, 앱이 이를 구현하는지, 클라이언트가 지원하는지, 출구 노드가 처리할 수 있는지는 각각 별도로 확인해야 합니다. TUN은 더 많은 UDP 트래픽을 코어로 전달할 수 있지만, UDP를 지원하지 않는 노드에 UDP 기능을 추가해 주지는 않습니다.
예를 들어 HTTP/3는 UDP 443을 사용하는 경우가 많습니다. 웹페이지가 TCP로 열린다고 해서 QUIC 연결도 정상이라고 볼 수는 없습니다. 게임 로그인은 되지만 음성이 작동하지 않는다면 로그인과 음성 연결의 대상 주소, 프로토콜, 정책을 각각 확인하세요. 지연 시간 테스트 결과 하나만으로 판단하면 안 됩니다.
3. 권한과 설정: 프록시 포트와 가상 네트워크 어댑터
시스템 프록시: 로컬 수신 주소부터 확인
아래에서는 127.0.0.1:7890을 예시 주소로 사용합니다. 모든 클라이언트가 이 포트를 기본값으로 쓰는 것은 아닙니다. mihomo의 mixed-port는 하나의 포트에서 HTTP와 SOCKS 요청을 모두 받을 수 있습니다. 실제 값은 클라이언트에 표시된 혼합 포트나 현재 적용된 설정에서 확인하세요.
# mihomo 설정 예시: 로컬 혼합 프록시 주소
mixed-port: 7890
allow-lan: false
mode: ruleWindows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’에서 주소와 포트를 확인할 수 있습니다. 클라이언트가 자동 구성 스크립트로 시스템 프록시를 설정하는 경우도 있으므로 수동 프록시 항목만 확인해서는 안 됩니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인하세요. 표시된 주소와 포트는 클라이언트의 수신 포트와 일치해야 합니다.
이 기기에서만 사용할 때는 루프백 주소를 유지하세요. 브라우저 연결 문제를 해결하려고 수신 주소를 모든 네트워크 인터페이스로 변경하면 안 됩니다. 로컬 네트워크에 프록시를 공개하는 것은 별도의 설정이며, 접근 제어와 방화벽 구성도 필요합니다.
TUN: 라우팅 설정과 백그라운드 서비스 권한
TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정해야 하므로, 데스크톱 클라이언트는 보통 관리자 권한이나 특권 서비스의 도움을 받습니다. Windows 클라이언트는 서비스 모드를 먼저 설치해야 할 수 있고, macOS 클라이언트는 특권 보조 프로그램이나 네트워크 확장을 사용할 수 있습니다. 권한 승인 방식은 구현에 따라 다르며, 모든 macOS Clash 클라이언트가 같은 네트워크 확장 권한을 요청하는 것은 아닙니다.
# mihomo TUN 설정 예시: 전체 구독 설정이 아님
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53stack: mixed는 현재 mihomo 구현에서 시스템 TCP 스택과 gVisor UDP 스택을 함께 사용합니다. 사용 가능한 값과 호환성은 사용 중인 코어 버전에 맞춰 확인해야 합니다.auto-route: true는 관련 라우트를 자동으로 설정합니다. 가상 네트워크 어댑터 생성에 성공해도 라우트 설치까지 성공한 것은 아닙니다.auto-detect-interface: true는 출구 인터페이스를 자동으로 감지하는 옵션입니다. Wi-Fi, 유선 네트워크, 다른 VPN을 함께 사용하는 경우 실제 출구를 확인해야 합니다.dns-hijack는tun아래에 설정하는 항목입니다. 예시에서는 UDP와 TCP의 53번 포트 요청을 각각 지정해 내장 DNS 모듈로 전달합니다.
4. DNS와 IPv6: TUN을 켜도 트래픽이 빠져나가는 이유
트래픽 처리와 도메인 이름 조회는 함께 확인해야 합니다. 앱은 도메인을 조회한 다음 연결을 시작합니다. DNS 요청이 다른 경로로 빠지면 도메인 조회에 실패하거나, 규칙에 도메인 정보가 반영되지 않거나, 예상과 다른 대상으로 연결될 수 있습니다. 가상 네트워크 어댑터가 표시된다는 사실만으로 DNS 경로가 올바르다고 단정할 수는 없습니다.
53번 포트 하이재킹이 모든 DNS를 처리하지는 않습니다
위의 dns-hijack 예시는 일반 DNS를 대상으로 합니다. 브라우저의 DNS over HTTPS는 HTTPS 연결을 사용하고, DNS over TLS는 보통 TCP 853을 사용합니다. 53번 포트 하이재킹을 설정해도 이 요청이 자동으로 코어의 DNS 조회로 바뀌지는 않습니다. 문제를 확인할 때는 브라우저의 보안 DNS를 잠시 끄고 같은 조건에서 비교한 뒤, 장기 설정을 결정하세요.
이 TUN 예시는 활성화된 mihomo DNS 모듈과 함께 사용해야 합니다. 예를 들어 dns.enable: true를 설정하고 사용할 수 있는 상위 DNS 서버를 유지하세요. fake-ip와 redir-host는 DNS 처리 모드이지 TUN을 대체하는 기능이 아닙니다. Fake-IP를 사용할 때도 실제 앱과의 호환성을 고려해 필터 목록을 설정해야 합니다.
IPv6는 별도로 확인해야 합니다
네트워크에서 IPv4와 IPv6를 모두 제공하지만 현재 클라이언트가 한쪽만 제대로 처리한다면 앱이 다른 주소 유형을 우선 사용할 수 있습니다. 문제를 확인할 때는 두 주소 유형을 따로 테스트하고, 코어의 IPv6 설정, DNS의 AAAA 응답, 시스템 라우팅을 확인하세요. IPv4 테스트 한 번만으로 모든 연결이 TUN을 거친다고 판단하지 마세요.
5. 확인 방법: 한 번에 연결 방식 하나만 변경
‘앱별 프록시 → 시스템 프록시 → TUN’ 순서로 확인하는 것이 좋습니다. 테스트 중에는 같은 정책 그룹과 노드를 사용하고 다른 프록시나 VPN은 끄세요. 연결 방식을 전환한 뒤에는 새 연결을 만들어 브라우저의 연결 재사용이 결과에 영향을 주지 않도록 합니다. 아래 명령은 공개 예시 사이트를 사용해 방법을 보여 주며, 응답 시간은 실제 측정 결과가 아닙니다.
- 포트 연결 확인.TUN을 끄고 명령에 로컬 프록시를 명시해 테스트하세요. 여기서 실패하면 가상 네트워크 어댑터를 조정하기 전에 코어, 포트, 노드부터 확인하세요.
- 시스템 프록시 확인.시스템 프록시를 켜고 설정을 따르는 브라우저에서 같은 대상에 접속하세요. 클라이언트의 연결 목록에서 대상 도메인, 일치한 규칙, 정책 경로를 확인합니다.
- TUN 확인.시스템 프록시를 끄고 TUN만 유지하세요. 명령줄에서 앱별 프록시를 사용하지 않고 대상에 접속한 다음 연결 기록을 확인하고, 필요한 경우 시스템 라우팅도 점검합니다.
- 실제 사용 환경 확인.게임, 음성 통화, 로컬 네트워크 접속 등 필요한 기능을 직접 테스트하세요. 웹페이지가 열린다는 사실만으로 UDP나 로컬 리소스 연결을 확인할 수는 없습니다.
# Windows PowerShell: 구버전 PowerShell의 curl 별칭을 피하려면 curl.exe 사용
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://example.com/
# TUN 비교 테스트: curl 프록시 설정을 사용하지 않음
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com/
# IPv4와 IPv6를 각각 테스트
curl.exe -4 -I --connect-timeout 10 --noproxy "*" https://example.com/
curl.exe -6 -I --connect-timeout 10 --noproxy "*" https://example.com/macOS와 Linux에서는 명령의 curl.exe를 curl로 바꾸면 됩니다. --noproxy "*"는 curl이 앱별 프록시를 사용하지 않게 할 뿐, TUN을 우회하지는 않습니다. HTTP 응답을 받았다는 사실은 해당 요청에 응답이 왔다는 것만 보여 줍니다. 프록시 노드를 거쳤는지는 코어 연결 기록이나 출구 주소 확인을 통해 검증해야 합니다.
Windows에서는 route print로 라우트를 확인할 수 있습니다. macOS에서는 route -n get 1.1.1.1로 지정한 IPv4 대상의 라우트를 확인하고, Linux에서는 ip route get 1.1.1.1로 라우팅 경로를 확인할 수 있습니다. 시스템마다 인터페이스 라우트나 정책 라우트를 사용할 수 있으므로 특정 기본 라우트가 반드시 보여야 한다고 판단해서는 안 됩니다.
6. 호환성과 선택 기준: 필요한 범위만 처리하기
시스템 프록시를 우선 고려할 상황
- 주로 브라우저를 사용하고 다른 앱은 기존 네트워크 경로를 유지해야 하는 경우
- 업무용 기기에서 기업 VPN을 사용 중이라 기기 전체의 라우트를 자동으로 바꾸기 어려운 경우
- 일부 개발 도구만 프록시를 사용하면 되는 경우. 도구에서 HTTP 또는 SOCKS5 주소를 설정할 수 있습니다.
TUN을 고려할 상황
- 대상 앱이 시스템 프록시를 따르지 않고 앱 자체 프록시 설정도 제공하지 않는 경우
- UDP를 사용하는 앱을 지원 범위 내에서 처리해야 하며, 노드가 해당 기능을 지원하는지 확인한 경우
- 여러 앱의 연결을 코어로 모은 뒤 도메인, IP, 프로세스 등의 규칙에 따라 분기하려는 경우
TUN과 다른 VPN을 함께 사용하면 기본 라우트, DNS, 네트워크 대역 중복, 응답 경로 충돌이 발생하기 쉽습니다. 예를 들어 기업 네트워크도 사설 IP 주소를 사용한다면 ‘모든 사설망 직접 연결’ 규칙이 기업 VPN에 필요한 라우트를 우회시킬 수 있습니다. 먼저 기업 네트워크의 대상 대역을 기록하고, 클라이언트가 지원하는 라우트 제외 및 규칙 기능에 맞춰 설정하세요. 일반적인 사설망 규칙 하나를 완전한 해결책으로 간주하면 안 됩니다.
두 연결 방식을 함께 켤 수는 있지만, 문제를 해결하는 동안에는 권장하지 않습니다. 앱에서 로컬 프록시에 직접 연결하면 루프백 경로를 사용하고 다른 앱은 TUN을 거칠 수 있습니다. 그러면 한쪽 토글을 껐는데도 연결되는 현상을 설명하기 어려워집니다. 주요 연결 방식 하나만 유지하면 권한, DNS, 포트, 규칙 중 어디에 문제가 있는지 파악하기 쉽습니다.
추가 설정은 플랫폼 가이드에서 운영체제별 차이를 확인하고, 사용 설명서에 따라 구독을 가져오고 규칙 모드를 설정하세요. 최종 판단은 클라이언트 화면의 ‘켜짐’ 표시 하나가 아니라 대상 앱의 실제 연결 기록을 기준으로 해야 합니다.