TUN 모드 설정 방법: 가상 네트워크 어댑터로 전체 트래픽을 가로채는 원리와 구성 절차

이 글 한눈에 보기

VMess, VLESS 또는 구독 노드로 정상 연결할 수 있지만 일부 프로그램이 프록시를 사용하지 않는 경우에 적합합니다. 트래픽이 가로채지는 계층부터 시작해 v2rayN 7.x와 v2rayNG 1.10.x의 설정 경로, 라우팅, DNS 처리, 확인 방법과 종료 후 복구 절차를 차례로 설명합니다.

TUN 모드와 시스템 프록시의 연결 방식 차이

시스템 프록시와 TUN 모드는 서로 다른 계층의 문제를 해결합니다. 시스템 프록시는 보통 운영체제에 HTTP 또는 SOCKS 프록시 주소를 입력하는 방식이며, v2rayN의 대표적인 로컬 HTTP 포트는 10809입니다. 브라우저, 다운로드 도구, 메신저처럼 이 설정을 직접 읽는 프로그램만 트래픽을 클라이언트로 보냅니다. 시스템 프록시를 무시하는 프로그램, 직접 연결로 고정된 런처, 일부 명령줄 도구는 여전히 인터넷에 직접 접속할 수 있습니다.

TUN 모드는 가상 네트워크 어댑터를 만들고 시스템 라우팅을 조정해 대상 IP 트래픽이 먼저 가상 인터페이스로 들어가게 합니다. 클라이언트는 패킷을 읽은 뒤 Xray 또는 v2fly 코어에 전달하고, 코어가 도메인 스니핑, DNS 조회와 라우팅 분할을 수행합니다. 앱에서 HTTP 프록시를 지원하거나 127.0.0.1과 포트 번호를 별도로 입력할 필요가 없으므로 여러 프로세스를 한꺼번에 처리해야 할 때 적합합니다.

앱 요청 발생 TUN 어댑터 캡처 대상 도메인 복원 규칙에 따른 라우팅 프록시 또는 직접 연결

“전체 트래픽을 가로챈다”는 말이 “모든 연결이 반드시 프록시 노드를 거친다”는 뜻은 아닙니다. TUN은 패킷을 클라이언트에 전달할 뿐이며, 프록시·직접 연결·차단 중 무엇을 선택할지는 라우팅 규칙이 결정합니다. 예를 들어 사설 네트워크 주소, 프린터 주소와 한국 국내 사이트는 직접 연결로 유지하고, 프록시 규칙에 해당하는 요청만 VMess 또는 VLESS 아웃바운드로 보낼 수 있습니다. 가로채는 범위와 아웃바운드 정책은 별개의 개념입니다.

시스템 프록시: 설정이 간단하며 HTTP 또는 SOCKS 프록시를 명확히 지원하는 데스크톱 프로그램에 적합합니다.
TUN 모드: 시스템 프록시를 읽지 않는 프로세스까지 처리하며 TCP, UDP와 DNS 요청을 한곳에서 다룰 수 있습니다.
전체 프록시: 라우팅 결정의 한 방식으로, 가로챈 외부 트래픽을 우선 프록시 아웃바운드로 보냅니다.
규칙 기반 라우팅: 도메인, IP, 포트 또는 프로세스 등의 조건에 따라 서로 다른 아웃바운드를 선택합니다.

Windows에서 v2rayN TUN 모드 켜기

아래 절차는 v2rayN 7.x를 기준으로 합니다. 세부 버전에 따라 버튼이 메인 창 상단이나 트레이 메뉴로 이동할 수 있지만 핵심 항목은 TUN, 라우팅과 DNS입니다. 가상 네트워크 어댑터를 처음 만들 때는 관리자 권한이 필요합니다. 권한 상승 없이 실행하면 화면에는 전환 완료로 표시되더라도 로그에 인터페이스 생성 또는 라우팅 기록 실패가 나타날 수 있습니다.

v2rayN을 열고 먼저 구독을 업데이트한 뒤, 정상 작동이 확인된 노드를 선택합니다.
「설정」→「매개변수 설정」→「TUN 모드」로 이동해 TUN에서 사용할 코어와 네트워크 스택 옵션을 확인합니다.
설정을 저장하고 클라이언트를 완전히 종료한 다음, 시스템의 “관리자 권한으로 실행”을 사용해 다시 시작합니다.
메인 창 또는 트레이 메뉴에서 「TUN 모드」를 엽니다. 상태 표시줄에 실행 중으로 표시될 때까지 기다리고, 로그에서 가상 인터페이스와 라우팅 초기화가 완료되었는지 확인합니다.
라우팅 모드를 규칙 기반 라우팅으로 설정하고, 먼저 로컬 네트워크 직접 연결을 유지한 상태에서 브라우저와 기존에 시스템 프록시를 읽지 못하던 프로그램을 테스트합니다.

v2rayN 기본 매개변수

기준 버전: 7.x
SOCKS 포트: 10808
HTTP 포트: 10809
권한: 관리자 권한으로 실행
라우팅 방식: 규칙 기반 라우팅

로컬 프록시 포트는 일반 시스템 프록시에 사용됩니다. TUN 패킷은 가상 인터페이스가 처리하므로 두 항목을 같은 수신 진입점으로 보면 안 됩니다.

TUN 권장 초기 설정

로컬 네트워크: 직접 연결
DNS: TUN으로 처리
IPv4: 우선 확인
UDP: 노드 성능에 따름
시스템 프록시: 중복 전환 방지

먼저 변수를 최소화해 연결 경로를 확인한 뒤, 사용자 지정 DNS, 프로세스 규칙과 세부 도메인 그룹을 하나씩 추가하세요.

시작 후에는 버튼 색상만 보지 말고 먼저 로그를 확인하세요. 정상적인 과정에는 TUN 인터페이스 생성, 라우팅 규칙 적용과 코어 시작 성공이 포함됩니다. 로그가 포트 수신 단계에서 멈추면 10808과 10809를 다른 v2rayN 인스턴스가 사용 중인지 확인하세요. 인터페이스 생성 단계에서 멈춘다면 관리자 권한과 남아 있는 가상 네트워크 어댑터를 우선 점검합니다.

TUN을 테스트할 때는 시스템 프록시를 잠시 끄면 요청이 가상 네트워크 어댑터에서 처리되는지 확인하기 쉽습니다. 시스템 프록시를 끈 뒤에도 브라우저가 규칙에 따라 접속되고 로컬 네트워크 장치가 직접 연결된다면 TUN과 라우팅 규칙이 대체로 정상 작동하는 것입니다. 테스트가 끝난 뒤 두 가지 트래픽 처리 방식을 계속 번갈아 전환하면 어느 경로로 요청이 들어왔는지 판단하기 어려워집니다.

7.x

v2rayN 구성 기준

10808

일반 SOCKS 포트

10809

일반 HTTP 포트

1개

가상 네트워크 어댑터 추가

판단 기준: 시스템 프록시를 끈 뒤 확인

시스템 프록시가 켜진 상태에서만 테스트하면 TUN이 트래픽을 가로챘다는 증거가 되지 않습니다. 시스템 프록시를 끄고 TUN만 유지한 뒤 브라우저, 명령줄 프로그램과 로컬 네트워크 주소를 각각 테스트하면 원인을 더 쉽게 좁힐 수 있습니다.

Android에서 v2rayNG로 VPN 트래픽 가로채기

v2rayNG는 Android의 시스템 VPN 서비스를 통해 가상 네트워크 인터페이스를 만들며, 작동 계층은 데스크톱 TUN과 유사합니다. 연결을 누르면 시스템에 VPN 권한 확인 창이 표시됩니다. 권한을 허용하면 가로채기 범위에 해당하는 앱 트래픽이 v2rayNG로 들어가고, Xray 코어가 노드 설정과 라우팅 규칙에 따라 처리합니다.

v2rayNG 1.10.x를 기준으로 먼저 구독을 가져오고 노드 지연 시간을 테스트합니다. 「설정」→「VPN 설정」에서 VPN 모드, 앱 프록시 범위, 로컬 네트워크 우회와 로컬 DNS 관련 옵션을 확인합니다. 메인 화면으로 돌아가 노드를 선택한 뒤 연결을 누르고, 처음 실행할 때 시스템 VPN 연결 요청을 허용합니다.

「구독 설정」에서 전체 구독 주소를 저장하고 업데이트를 실행한 뒤 사용 가능한 노드를 선택합니다.
「설정」→「VPN 설정」으로 이동해 VPN 트래픽 가로채기를 켜 둡니다.
전체 기기에서 트래픽을 처리하려면 앱별 프록시만 사용 옵션을 켜지 마세요. 범위를 줄여야 할 때 앱 목록을 만드세요.
로컬 네트워크 우회를 켜서 라우터 관리 페이지나 로컬 네트워크 서비스에 접속할 때 우회 경로를 거치지 않도록 합니다.
메인 화면으로 돌아가 연결한 뒤 상태 표시줄에 시스템 VPN 표시가 나타나는지 확인하고 DNS와 웹 접속을 테스트합니다.

v2rayNG 전체 기기 트래픽 처리

기준 버전: 1.10.x
실행 코어: Xray
처리 방식: 시스템 VPN
앱 범위: 모든 앱
로컬 네트워크: 권장 우회

먼저 전체 연결 경로를 확인하기에 적합하며, 안정성이 확인된 뒤 앱 범위를 좁히는 것이 좋습니다.

앱별 할당

진입 경로: VPN 설정
모드: 앱 프록시
선택 방식: 지정 또는 제외
DNS: 코어 설정 따름
UDP: 노드 지원 필요

목록의 적용 방향을 반드시 확인하세요. 지정 앱과 제외 앱은 결과가 정반대입니다.

v2flyNG를 사용하는 경우에도 트래픽 처리 방식은 시스템 VPN 서비스에 의존하지만 실행 코어는 v2fly입니다. 구독의 VMess, VLESS와 전송 매개변수는 클라이언트와 코어가 함께 지원해야 합니다. TUN 또는 VPN 트래픽 처리는 진입 경로만 바꿀 뿐 서버 주소, UUID, 전송 계층이나 TLS 매개변수를 자동으로 수정하지 않습니다.

DNS, 라우팅과 UDP 설정 핵심

TUN 생성은 성공했지만 도메인이 열리지 않는다면 노드 연결보다 DNS 요청이 다른 경로로 나가는 것이 흔한 원인입니다. 앱이 잘못된 주소를 먼저 받으면 이후 연결이 프록시를 거쳐도 실패합니다. 도메인 조회와 실제 트래픽이 같은 분할 규칙을 따르도록 구성하고, 시스템 DNS·클라이언트 DNS·브라우저 자체 DNS가 동시에 경쟁하지 않게 하세요.

v2rayN에서 「설정」→「매개변수 설정」으로 들어가 DNS와 라우팅 구성을 확인합니다. 도메인 규칙을 사용한다면 코어가 매칭할 수 있도록 도메인 정보를 유지하세요. 너무 일찍 IP만 전달되면 도메인 기반 라우팅 규칙이 적용되지 않을 수 있습니다. 스니핑을 켜면 일부 TCP 또는 HTTP 트래픽에서 대상 도메인을 복원할 수 있지만, 모든 DNS 문제를 해결하는 대체 수단은 아닙니다.

확인 대상	정상 동작	이상 동작	처리 방향
DNS 요청	코어가 규칙에 따라 조회	조회 시간 초과 또는 연결할 수 없는 주소 반환	클라이언트 DNS 경로 통일
로컬 네트워크 주소	게이트웨이와 장치에 직접 접속	라우터 관리 페이지가 열리지 않음	사설 주소를 직접 연결에 추가
UDP 트래픽	노드와 아웃바운드 모두 지원	음성 또는 실시간 연결 실패	노드의 UDP 지원 여부 확인
도메인 규칙	로그에 예상 아웃바운드 표시	모든 요청이 기본 규칙으로 처리됨	순서와 스니핑 결과 확인

라우팅 규칙은 순서대로 매칭되므로 명확한 조건을 기본 규칙보다 앞에 배치해야 합니다. 일반적인 초기 순서는 사설 IP 직접 연결, 로컬 네트워크 도메인 직접 연결, 프록시가 필요한 도메인의 프록시 연결, 마지막으로 매칭되지 않은 요청을 기본 규칙으로 처리하는 방식입니다. 규칙이 많을수록 웹페이지가 열리는지만 보고 추측하지 말고 로그에서 실제 매칭 항목을 확인해야 합니다.

UDP 사용 가능 여부는 앱, 클라이언트, 실행 코어, 프로토콜 설정과 서버 성능에 따라 달라집니다. TUN이 UDP 패킷을 캡처할 수 있어도 선택한 VMess 또는 VLESS 노드가 이를 완전히 전달한다는 뜻은 아닙니다. 웹페이지는 정상인데 실시간 음성이나 게임 연결에 문제가 있다면 UDP 로그를 따로 확인하고, UDP 지원이 확인된 다른 노드로 교차 테스트하세요.

구성 순서: 먼저 DNS를 통일한 뒤 라우팅 확대

TUN을 처음 켤 때는 로컬 네트워크 직접 연결과 기본 프록시 규칙 하나만 유지하세요. DNS, TCP와 UDP 연결이 기본적으로 정상인지 확인한 뒤 도메인 그룹, 프로세스 조건과 사용자 지정 아웃바운드를 추가하면 변수를 크게 줄일 수 있습니다.

자주 발생하는 문제와 복구 절차

TUN 문제는 “가상 네트워크 어댑터가 생성되었는가”부터 확인한 다음 라우팅, DNS, 코어와 노드를 점검해야 합니다. 무작정 구독을 바꾸면 실제 원인을 놓치기 쉽습니다. 특히 클라이언트가 비정상 종료된 뒤 남은 라우팅 때문에 모든 네트워크가 작동하지 않을 수 있으므로, 이때는 먼저 TUN을 끄고 클라이언트를 완전히 종료하세요.

TUN을 켜자마자 인터넷이 끊기면 어떻게 하나요?

먼저 TUN을 끄고 v2rayN을 종료한 뒤 네트워크 어댑터를 다시 활성화하세요. 이후 관리자 권한으로 클라이언트를 실행해 인터페이스 생성 또는 라우팅 기록 단계에서 실패했는지 로그를 확인합니다. 네트워크가 끊긴 상태에서 여러 번 연속 실행하지 마세요.

브라우저는 되는데 특정 프로그램만 직접 연결되면 어떻게 하나요?

시스템 프록시를 끄고 TUN만 유지한 상태에서 다시 시도하세요. 해당 프로그램이 독립 네트워크 서비스, 특정 네트워크 어댑터 또는 특수 UDP 채널을 사용하는지도 확인합니다. Android에서는 「설정」→「VPN 설정」에서 해당 앱이 제외되지 않았는지도 확인해야 합니다.

연결은 성공했지만 모든 도메인이 시간 초과되면 어떻게 하나요?

먼저 확실히 연결 가능한 IP를 직접 테스트한 뒤 클라이언트 DNS 로그를 확인하세요. 브라우저에서 별도로 설정한 DNS를 끄고 코어가 조회를 처리하도록 통일한 다음, 53번 포트 요청을 다른 네트워크 도구가 가로채지 않는지 확인합니다.

로컬 네트워크 프린터와 라우터 페이지가 열리지 않으면 어떻게 하나요?

라우팅 설정에서 사설 주소 대역과 로컬 네트워크 도메인을 직접 연결로 처리하고 로컬 네트워크 우회를 켜세요. 변경 후 TUN에 다시 연결한 다음 게이트웨이 주소와 장치 주소를 각각 테스트합니다.

클라이언트를 종료해도 네트워크가 복구되지 않으면 어떻게 하나요?

프로세스가 완전히 종료되었는지 확인하고 물리 네트워크 어댑터를 사용하지 않음으로 설정했다가 다시 활성화하세요. 그런 다음 시스템 프록시가 여전히 127.0.0.1:10809을 가리키는지 확인합니다. 필요하면 시스템을 재시작해 남은 가상 인터페이스와 임시 라우팅을 정리하세요.

포트 충돌은 주로 로컬 HTTP, SOCKS 또는 제어 인터페이스에 영향을 줍니다. Windows에서는 먼저 터미널에서 10808과 10809를 수신 중인 프로세스를 확인한 뒤 기존 인스턴스를 종료할지 포트를 변경할지 결정하세요. 포트를 변경했다면 시스템 프록시 설정도 함께 업데이트해야 합니다. 그렇지 않으면 시스템이 계속 이전 포트로 요청을 보내 TUN이나 노드가 작동하지 않는 것처럼 보입니다.

netstat -ano | findstr :10808
netstat -ano | findstr :10809
tasklist | findstr <PID>

종료할 때는 먼저 클라이언트에서 TUN을 끈 다음 프로그램을 종료하세요. 코어 프로세스를 바로 강제 종료하지 마세요. 정상적으로 종료하면 임시 라우팅을 취소하고 가상 인터페이스를 해제합니다. TUN과 시스템 프록시를 전환할 때도 한쪽을 완전히 끄고 네트워크를 확인한 뒤 다른 방식을 켜야 합니다.

TUN 또는 Android 시스템 VPN 연결을 끕니다.
v2rayN, v2rayNG 또는 v2flyNG를 완전히 종료합니다.
시스템 프록시에 127.0.0.1:10809이 남아 있지 않은지 확인합니다.
직접 연결 네트워크, 로컬 네트워크 게이트웨이와 DNS 조회를 테스트합니다.
클라이언트를 다시 시작하고 한 번에 한 가지 방식만 사용해 재검사합니다.

TUN이 실제로 트래픽을 가로채는지 확인

“연결됨” 상태만 확인해서는 안 됩니다. 전체 테스트에는 시스템 프록시를 지원하는 프로그램 하나, 시스템 프록시를 읽지 않는 프로그램 하나, 로컬 네트워크 주소 하나와 UDP 기능 하나가 포함되어야 합니다. 네 가지 결과를 통해 가상 어댑터 처리, 규칙 기반 라우팅, 로컬 네트워크 우회와 UDP 전달이 각각 정상인지 확인할 수 있습니다.

시스템 프록시를 끄고 TUN만 유지한 뒤 일반 웹페이지가 계속 열리는지 확인합니다.
기존에 시스템 프록시를 사용하지 않던 프로그램을 실행하고 코어 로그에 해당 대상이 나타나는지 확인합니다.
라우터 게이트웨이 또는 로컬 네트워크 장치에 접속해 요청이 직접 연결 규칙에 매칭되는지 확인합니다.
DNS를 점검해 조회 요청과 프록시 트래픽이 예상한 경로를 사용하는지 확인합니다.
실시간 음성 또는 다른 UDP 환경을 테스트해 지속적인 시간 초과가 없는지 확인합니다.

최종 판단은 로그를 기준으로 해야 합니다. v2rayN에서는 메인 화면의 실행 로그에서 인바운드, 대상 주소와 아웃바운드 태그를 확인할 수 있습니다. v2rayNG에서는 로그 페이지에서 연결 수립과 라우팅 결과를 확인합니다. 대상 요청 자체가 나타나지 않으면 문제는 트래픽 처리 범위나 시스템 라우팅에 있습니다. 요청은 나타나지만 아웃바운드가 잘못되었다면 규칙 문제입니다. 아웃바운드가 올바른데도 연결에 실패하면 노드와 대상 네트워크를 점검하세요.

TUN은 “앱이 프록시 설정을 따르지 않는” 진입 경로 문제를 해결하는 데 적합합니다. 구성이 안정되면 클라이언트 버전, 구독 업데이트 시각, 현재 노드, 라우팅 모드, DNS 설정과 로컬 포트를 명확한 기준으로 기록해 두세요. 이후 문제가 발생하면 한 번에 변수 하나만 바꾸고 변경 전후의 로그를 남기는 편이 반복 설치보다 원인을 찾기 쉽습니다.