v2rayN TUN 모드 설정 가이드: 가상 네트워크 어댑터로 전체 트래픽 처리하기

이 글의 핵심 내용

브라우저는 연결되는데 명령줄 도구나 다른 프로그램은 직접 연결된다면, 먼저 시스템 프록시와 TUN이 각각 어떤 트래픽을 처리하는지 구분해야 합니다. 이 글에서는 Windows용 v2rayN을 예로 들어 노드 확인, 권한 확보, 가상 네트워크 어댑터 활성화, 라우팅 및 DNS 점검, 테스트와 복구 순서로 설명합니다. 프록시가 필요한 트래픽은 올바른 경로로 보내고, 로컬 네트워크 접속은 유지하세요. 트래픽을 처리한다는 것이 모든 연결을 반드시 프록시로 보내야 한다는 뜻은 아닙니다.

시스템 프록시와 TUN: 진입 경로는 달라도 출구는 라우팅으로 결정

시스템 프록시는 운영체제에 로컬 프록시 주소를 등록하는 방식입니다. 이 설정을 따르는 앱은 요청을 v2rayN의 로컬 수신 포트로 보내지만, 시스템 프록시를 무시하는 프로그램은 직접 연결합니다. 브라우저에서 웹사이트가 열린다고 해서 터미널 도구, 게임, 백그라운드 서비스도 프록시를 거친다고 단정할 수는 없습니다.

TUN은 네트워크 계층에서 트래픽을 받습니다. 클라이언트가 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 조건에 맞는 IP 트래픽을 이 인터페이스로 보내면, 관련 코어가 TCP, UDP, DNS 처리와 출구 선택을 담당합니다. 보통 앱에 프록시 주소를 직접 입력할 필요는 없지만, 기존 VPN이나 특정 네트워크 어댑터에 바인딩된 프로그램, 우선순위가 더 높은 라우트에 따라 처리 결과가 달라질 수 있습니다.

시스템 프록시: 먼저 기본 동작 확인

권장

설정 범위가 좁아 구독 노드, 로컬 수신 포트, 브라우저 접속이 모두 정상인지 먼저 확인하기 좋습니다. 권장하는 것은 문제 해결의 시작점이지, 모든 상황에 적용할 최종 설정은 아닙니다.

적합한 경우: 주로 브라우저를 사용하거나 HTTP·SOCKS 프록시를 지원하는 앱을 사용하는 환경

TUN: 프록시 설정을 따르지 않는 프로그램도 처리

가상 네트워크 어댑터와 라우팅으로 트래픽을 받습니다. 권한, DNS, UDP 지원, 로컬 네트워크 예외를 추가로 확인해야 하며, 스위치가 켜져 있는지만 봐서는 충분하지 않습니다.

적합한 경우: 터미널 도구, 일부 데스크톱 프로그램, 네트워크 트래픽을 통합 분기해야 하는 환경

판단 기준: 진입 경로를 정한 뒤 라우팅 정책 선택

시스템 프록시로 충분하다면 우선 그대로 사용하세요. 특정 프로그램이 프록시를 우회하는 경우에만 TUN을 켜면 됩니다. TUN을 켠 뒤에도 트래픽 분기는 가능하며, 해당하는 전역 프록시 규칙을 선택해야 조건에 맞는 트래픽이 프록시 출구로 모입니다.

시작 전 확인: 노드, 권한, 포트별 역할

먼저 v2rayN에서 구독 정보를 갱신하고 노드를 선택해 활성 서버로 설정합니다. 시스템 프록시를 통해 실제로 사용할 웹사이트에 접속해 노드 연결뿐 아니라 요청 처리까지 정상인지 확인하세요. 지연 시간 테스트에 결과가 나와도 모든 대상에 접속할 수 있다는 뜻은 아니며, UDP가 정상이라는 증거도 아닙니다.

아래 포트 번호는 각 포트의 역할을 구분하기 위한 예시이며, 모든 설정을 같은 값으로 바꾸라는 뜻은 아닙니다. v2rayN의 로컬 수신 포트는 「설정」→「매개변수 설정」에 표시된 실제 값을 확인하세요. 구독 노드의 원격 포트는 서비스 제공자가 정하므로 예시에 맞추려고 변경하지 마세요.

10808

로컬 프록시 수신 포트 예시: 실제 값은 매개변수 설정에서 확인

일반 DNS 조회에 주로 사용하는 포트

443

HTTPS 및 DoH에 주로 사용하는 포트

관리자 권한: Windows에서 가상 네트워크 어댑터를 만들고 라우트를 추가하려면 일반적으로 권한 상승이 필요합니다. v2rayN을 종료한 다음 「관리자 권한으로 실행」으로 다시 시작하고, Windows 권한 확인 창이 나타나면 승인을 선택하세요.
실행 구성 요소: 설치 패키지에 TUN 실행에 필요한 구성 요소가 포함되어 있는지 확인하세요. 일반적인 v2rayN 버전에서는 sing-box가 TUN 진입을 처리합니다. 노드가 Xray를 사용하더라도 TUN 인터페이스를 Xray가 직접 만든다는 뜻은 아닙니다.
네트워크 충돌: 먼저 다른 VPN이나 유사한 가상 네트워크 어댑터의 트래픽 처리 기능을 끄세요. 처음부터 기본 라우트를 여러 개 겹쳐 설정한 뒤 어느 프로그램이 트래픽을 받는지 추측하지 마세요.
복구를 위한 기록: 현재 시스템 프록시 상태, 라우팅 모드, DNS 설정을 기록해 두세요. 첫 테스트에서는 설정 한 묶음만 변경해야 쉽게 복구할 수 있습니다.

v2rayN에서 TUN 켜기: 순서대로 설정하고 확인

일반 프록시가 정상적으로 작동하는지 확인한 다음 TUN을 켜세요. 처음 설정을 확인할 때는 시스템 프록시를 해제해 테스트 프로그램이 TUN만 사용하게 하는 편이 좋습니다. 시스템 프록시가 계속 적용되는 상태에서 가상 네트워크 어댑터가 트래픽을 처리한다고 잘못 판단하는 일을 막을 수 있습니다. 이는 문제를 분리하기 위한 방법일 뿐, 두 진입 경로를 항상 동시에 사용할 수 없다는 뜻은 아닙니다.

종료 후 관리자 권한으로 실행: 시스템 트레이에서 v2rayN을 완전히 종료한 뒤 프로그램을 마우스 오른쪽 버튼으로 클릭하고 「관리자 권한으로 실행」을 선택하세요. 기본 창만 닫으면 백그라운드 프로세스가 계속 실행될 수 있습니다.
활성 노드 확인: 서버 목록에서 활성 서버가 바뀌지 않았는지 확인하세요. 구독을 다시 추가해야 한다면 「구독 그룹」→「구독 그룹 설정」에서 주소를 저장한 뒤 업데이트를 실행하세요.
로컬 설정 확인: 「설정」→「매개변수 설정」에서 로컬 수신 포트를 기록하세요. 현재 버전에 TUN 설정 페이지가 있다면 우선 기본 스택과 기본 MTU를 사용하고, 여러 실험 설정을 동시에 변경하지 마세요.
시스템 프록시 해제: 메인 화면이나 시스템 트레이의 「시스템 프록시」 메뉴에서 「시스템 프록시 해제」를 선택하세요. 테스트 프로그램에 별도의 프록시 주소나 프록시 환경 변수가 설정되어 있지 않은지도 확인하세요.
TUN 활성화: 메인 화면에서 「TUN 사용」 스위치를 켜세요. 사용 중인 버전에서 설정 메뉴에 TUN 항목이 있다면 해당 버전에 표시된 메뉴를 따르세요. 로그에 네트워크 어댑터 생성, 코어 시작, 라우트 설정 오류가 나타나는지 확인하세요.
실제 요청 확인: 앱에 프록시를 설정하지 않은 프로그램으로 대상에 접속한 뒤 라우팅, DNS, 접속 로그를 함께 살펴 출구를 확인하세요. 확인을 마친 다음 시스템 프록시를 계속 사용할지 결정하면 됩니다.

PowerShell에서 아래 두 개의 읽기 전용 명령으로 네트워크 어댑터와 IPv4 라우트를 확인할 수 있습니다. 시스템 설정은 변경되지 않습니다. 가상 인터페이스 이름에 특정 문구가 들어간다고 단정하지 말고 활성화 전후의 변화를 비교하세요. 일부 TUN 구현은 기존 기본 라우트를 바꾸는 대신 더 구체적인 라우트 두 개를 추가할 수 있습니다.

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric |
  Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

가상 인터페이스가 나타나는 것은 첫 단계일 뿐입니다. 로그에서 인터페이스가 정상이라고 나오는데도 앱 요청이 해당 처리 경로에 들어가지 않는다면 라우트 우선순위, 앱의 물리 네트워크 어댑터 바인딩 여부, 요청이 규칙에 따라 직접 연결되도록 설정됐는지 확인하세요.

라우팅 분기: 로컬 네트워크는 유지하고 프록시 연결의 루프 방지

‘TUN이 전체 트래픽을 받는다’는 것은 진입 범위를 말하고, ‘전역 프록시’는 출구 정책을 말합니다. TUN을 켜도 네트워크 저장 장치, 프린터, 사내 서비스는 직접 연결되도록 설정할 수 있습니다. 그 외 대상은 도메인, IP, 규칙 집합에 따라 프록시로 보낼 수 있습니다. 모든 대상을 원격 프록시로 강제하면 오히려 로컬 네트워크 장치에 접속하지 못할 수 있습니다.

구성 방식: 일상적인 트래픽 분기와 단기 진단은 분리

일상적인 트래픽 분기

필요에 따라 로컬 네트워크와 사설 IP 주소는 직접 연결합니다.
프록시가 필요한 대상에는 프록시 출구 규칙을 명확하게 적용합니다.
직접 연결용 DNS와 프록시용 DNS를 각각 설정합니다.
노드 서버 연결이 되돌아오지 않도록 루프 방지 설정을 유지합니다.

단기 진단

시스템 프록시를 해제해 TUN 진입 경로만 분리합니다.
테스트 대상에 임시로 프록시 규칙을 지정합니다.
로그에서 규칙이 적용됐는지와 출구를 확인합니다.
테스트를 마치면 일상적인 트래픽 분기 설정으로 복구합니다.

먼저 지정한 대상이 프록시를 통하는지 확인한 다음 규칙 적용 범위를 넓히세요. 출구 확인을 한 번 했다고 모든 앱이 정상인지 검증된 것은 아닙니다.

대상 또는 주소	설정 방향	이유
`192.168.0.0/16`	내부 네트워크 환경에 맞게 직접 연결	가정용 라우터, 프린터, 네트워크 저장 장치에 주로 사용합니다.
`10.0.0.0/8`	회사 네트워크 또는 VPN 설정부터 확인	사설 IP 대역이 회사 VPN에서 제공될 수 있으므로 무조건 물리 네트워크 어댑터로 보내면 안 됩니다.
현재 연결된 노드 서버	올바른 물리 네트워크 출구 또는 제외 규칙 유지	프록시 자체의 연결을 같은 터널로 다시 보내면 연결 루프가 발생할 수 있습니다.
프록시가 필요한 서비스 대상	프록시 출구 규칙을 명확하게 적용	우선순위가 더 높은 직접 연결 규칙에 먼저 걸리지 않도록 합니다.

VMess와 VLESS는 노드 프로토콜이지, 가상 네트워크 어댑터를 통하는지 정하는 스위치가 아닙니다. TUN이 UDP 트래픽을 받은 뒤에도 다음 연결 경로가 해당 트래픽의 전달을 지원해야 합니다. 게임이나 음성 앱에 문제가 있다면 가상 네트워크 어댑터만 반복해서 켜고 끄지 말고 노드 프로토콜, 서버 측 정책, 방화벽을 확인하세요.

DNS 연동: 도메인 조회 경로와 연결 경로를 함께 확인

DNS는 도메인이 어떤 주소로 변환되는지 결정하고, 라우팅은 이후 연결이 어디로 나갈지 결정합니다. 원격 DNS 주소만 설정한다고 DNS 조회가 프록시를 통한다고 보장되지는 않습니다. 웹사이트의 접속 출구가 달라졌더라도 브라우저 자체의 암호화 DNS, 시스템 DNS, 다른 앱의 DNS 조회가 모두 같은 경로를 사용하는 것은 아닙니다.

직접 연결 대상: 현재 네트워크에 맞는 DNS 서버를 사용하고 조회 경로가 직접 연결 정책과 일치하는지 확인하세요. 내부 도메인은 라우터나 회사 DNS가 필요할 수 있으며, 공개 DNS 서버가 응답하지 않을 수도 있습니다.
프록시 대상: 관련 DNS 조회도 프록시 출구를 통하도록 설정하세요. DoH를 사용하는 경우 HTTPS 주소를 입력하는 것뿐 아니라 DNS 서버 연결이 실제로 어떤 출구를 이용하는지도 확인해야 합니다.
초기 도메인 조회: 노드나 DoH 서버가 도메인으로 지정되어 있다면 먼저 해당 도메인을 조회할 수 있어야 합니다. ‘프록시에 연결하려면 DNS가 필요한데 DNS는 프록시 연결이 먼저여야 한다’는 순환 의존을 피하세요.
DNS 가로채기: TUN으로 들어오는 일반 DNS 조회를 코어에서 처리합니다. 주로 조건에 맞는 DNS 트래픽을 대상으로 하며, 앱이 직접 만드는 모든 암호화 DNS 연결까지 자동으로 처리한다는 뜻은 아닙니다.
FakeDNS: 가상 주소 매핑으로 도메인 정보를 유지하며, 호환되는 진입 방식과 규칙이 함께 처리해야 합니다. TUN을 처음 켤 때는 동시에 활성화하지 않아도 됩니다. 사용한다면 종료 후 남은 캐시를 정리하세요.

예를 들어 앱이 로컬 네트워크 라우터의 53번 포트로 도메인을 조회하고 사설 IP 규칙이 해당 연결을 직접 보내도록 설정되어 있으면, DNS 조회가 프록시를 우회할 수 있습니다. 이 동작이 예상치 못한 정보 노출인지는 트래픽 분기 설계를 기준으로 판단해야 합니다. 내부 도메인에 내부 DNS를 사용하는 것은 일반적인 요구 사항이고, 프록시 대상이 로컬 네트워크의 DNS를 사용하는 경우에는 추가 확인이 필요합니다.

해결 방법: DNS 조회 실패와 연결 실패를 구분

로그에서 먼저 대상 주소를 얻었는지 확인한 다음 연결에 어떤 출구가 적용됐는지 살펴보세요. 주소를 얻지 못했다면 DNS를 점검하고, 주소가 있는데 연결 시간이 초과되면 규칙, 노드, 전송 경로를 확인하세요. 두 문제를 모두 TUN 탓으로 돌리지 마세요.

TUN 활성화 실패, 인터넷 끊김, 특정 앱만 접속 불가: 증상별 해결 방법

설정을 바꾸기 전에 오류 정보를 저장하세요. 로그의 ‘권한 부족’, ‘인터페이스 생성 실패’, ‘포트 사용 중’, ‘연결 시간 초과’는 서로 다른 단계를 가리킵니다. 노드, DNS, MTU, 네트워크 스택을 한꺼번에 바꾸면 원인을 파악하기 어려워집니다.

TUN을 켜자마자 네트워크 어댑터 생성에 실패합니다. 어떻게 해야 하나요?

먼저 시스템 트레이에서 v2rayN을 완전히 종료한 뒤 관리자 권한으로 다시 실행하세요. 보안 프로그램이 관련 구성 요소를 차단하는지, 설치 패키지에 필요한 구성 요소가 모두 있는지 확인합니다. 계속 실패하면 로그에 표시된 구체적인 오류를 기록하세요. 물리 네트워크 어댑터를 삭제하거나 모든 라우트를 한꺼번에 지우지 마세요.

스위치는 켜져 있는데 모든 웹사이트에 접속할 수 없나요?

먼저 TUN을 끄고 기존 시스템 프록시가 여전히 작동하는지 확인하세요. 일반 프록시가 정상이라면 TUN 로그, 노드 출구의 루프 방지, DNS 초기 조회를 집중적으로 살펴보세요. 일반 프록시도 작동하지 않는다면 노드나 네트워크 문제부터 해결하세요.

웹은 열리지만 게임이나 음성 통화는 연결되지 않나요?

프로그램이 다른 네트워크 어댑터에 바인딩되어 있지 않은지 확인한 다음 UDP 요청이 코어에 전달되는지 살펴보세요. 노드의 UDP 지원 여부, 서버의 전달 허용 여부, 대상에 잘못된 규칙이 적용됐는지 확인해야 합니다. TCP 웹 접속이 성공해도 UDP 테스트를 대신할 수는 없습니다.

TUN을 켠 뒤 프린터나 로컬 네트워크 저장 장치가 보이지 않나요?

먼저 대상 사설 IP 대역에 직접 연결 규칙이 적용되는지 확인하세요. 네트워크 검색에는 브로드캐스트나 멀티캐스트가 필요할 수 있어 원격 프록시만으로는 복구되지 않습니다. 먼저 장치의 실제 로컬 IP 주소로 접속한 뒤 검색 기능만 영향을 받았는지 확인하세요.

TUN을 껐는데도 인터넷에 연결되지 않나요?

먼저 시스템 프록시를 해제하고 가상 인터페이스와 라우트가 제거됐는지 확인한 다음 DNS 캐시를 정리하세요. 프로세스가 비정상 종료되어 네트워크 상태가 남아 있다면 작업 중인 내용을 저장하고 시스템을 재시작하세요. 정체를 모르는 라우트 항목을 먼저 수동으로 삭제하지 마세요.

Windows에서 DNS 캐시를 지우려면 터미널에서 아래 명령을 실행하세요. 이 명령은 시스템 캐시만 삭제하며 잘못된 라우트를 수정하거나 모든 앱의 DNS 캐시를 자동으로 지우지는 않습니다. 필요한 경우 브라우저나 테스트 앱을 다시 시작하세요.

ipconfig /flushdns

최종 점검과 복구: 스위치 상태만 보지 말고 실제 처리 확인

계속 사용할 수 있는 설정이라면 프록시 대상에 접속할 수 있고, 직접 연결 대상도 정상이며, DNS 경로가 설계대로 동작하고, 종료 후 네트워크가 복구되어야 합니다. 테스트할 때는 실제 사용하는 프로그램을 선택하고, 시스템 프록시를 따르지 않는 앱도 최소 하나 포함하세요. 브라우저만 반복해서 여는 것으로는 충분하지 않습니다.

진입 경로 확인: 시스템 프록시와 앱에 직접 입력한 프록시를 해제한 상태에서도 지정한 프로그램이 TUN을 통해 프록시가 필요한 대상에 접속할 수 있습니다.
출구 확인: 출구 조회 결과와 로그를 함께 보고 테스트 대상에 예상한 규칙이 적용됐는지 확인하세요. 분기 규칙이 다르면 대상마다 출구가 달라도 문제는 아닙니다.
로컬 네트워크 확인: 라우터 관리 페이지, 저장 장치 또는 업무에 필요한 내부 서비스에 접속해 예외 규칙이 정상적으로 적용되는지 확인하세요.
DNS 확인: 시스템과 앱의 DNS 설정을 각각 확인하세요. 테스트 결과는 트래픽 분기 설계와 일치해야 하며 DNS 서버 이름만으로 판단해서는 안 됩니다.
복구 확인: TUN을 끈 뒤 일반 네트워크가 복구되는지 확인하고, 필요하면 시스템 프록시를 다시 설정하세요. 복구되지 않으면 추가 설정을 시험하기 전에 남은 네트워크 상태부터 해결하세요.

TUN은 클라이언트가 처리할 수 있는 트래픽 범위를 넓혀 주지만 모든 네트워크 제한을 자동으로 해결하지는 않습니다. 진입 경로, DNS 조회, 규칙, 출구를 차례로 확인하면 코어를 계속 바꾸거나 구독을 반복해서 가져오는 것보다 문제를 찾기 쉽습니다. 기본 구독과 시스템 프록시 설정은 입문 가이드에서 확인하세요. 라우팅과 DNS 개념을 자세히 살펴보려면 전체 문서를 참고하세요.