v2rayN TUN 모드 설정 방법과 원리: 가상 네트워크 어댑터로 트래픽 처리

핵심 내용

v2rayN은 데스크톱 클라이언트이며, TUN은 시스템 프록시를 사용하지 않는 앱의 트래픽까지 처리합니다. 이 글에서는 Windows 데스크톱을 기준으로 노드 연결 확인, 권한 설정, 가상 어댑터 활성화, 라우팅 검증 순서로 설정한 뒤 DNS, 로컬 네트워크, 종료 후 복구 문제를 살펴봅니다. 다른 데스크톱 플랫폼은 권한 부여 방식이 다르므로 Windows의 관리자 실행 절차를 그대로 적용하지 마세요.

1. TUN 가상 네트워크 어댑터와 시스템 프록시의 차이

시스템 프록시는 앱에 프록시 연결 지점을 제공합니다. 브라우저처럼 시스템 설정을 따르는 소프트웨어는 요청을 로컬 프록시 포트로 전달하지만, 자체적으로 연결을 만들거나 시스템 설정을 무시하는 앱은 계속 직접 연결할 수 있습니다. 따라서 브라우저는 접속되는데 명령줄 도구는 안 되는 경우, 노드 문제라기보다 두 프로그램이 서로 다른 네트워크 경로를 사용하기 때문일 수 있습니다.

TUN은 시스템 네트워크 계층에 가상 인터페이스를 만들고, 라우팅을 통해 조건에 맞는 IP 패킷을 처리 커널로 전달합니다. 보통 앱마다 프록시 주소를 따로 입력할 필요가 없습니다. 여기서 ‘전체 트래픽 처리’는 적용 범위를 뜻하며, 모든 연결이 원격 노드를 거쳐야 한다는 의미는 아닙니다. TUN으로 들어온 연결도 규칙에 따라 직접 연결하거나 프록시로 보내거나 차단할 수 있습니다.

앱에서 요청 전송 시스템 라우팅으로 전달 TUN 어댑터에서 포착 규칙에 따라 트래픽 분기 직접 연결 또는 프록시

v2rayN은 인터페이스, 설정 생성, 프로세스 관리를 담당하고 실제 트래픽 전달은 커널이 수행합니다. 일반적인 데스크톱 버전은 sing-box로 TUN을 구현하지만, 구성은 버전과 설정에 따라 달라질 수 있습니다. ‘TUN이 켜졌다’고 해서 Xray의 모든 기능이 자동으로 적용되는 것은 아닙니다. VMess와 VLESS는 노드 프로토콜이고 REALITY는 보안 전송 방식입니다. 이들은 가상 네트워크 드라이버가 아니므로 TUN으로 전환한다고 구독을 다시 가져올 필요도 없습니다.

비교 항목	시스템 프록시	TUN 모드
적용 위치	앱의 프록시 설정	시스템 라우팅 및 가상 인터페이스
앱에서 필요한 설정	프록시 설정을 읽거나 직접 구성해야 함	대체로 앱별 설정이 필요하지 않음
UDP 지원	프록시 연결 방식과 앱에 따라 다름. HTTP 프록시만으로 모든 트래픽을 처리할 수는 없음	커널, 노드, 서버가 모두 지원해야 함
필요한 권한	일반적으로 가상 네트워크 어댑터를 만들 필요 없음	인터페이스 생성 및 라우팅 변경 권한 필요

2. 시작 전 노드·권한·로컬 연결 지점 확인

먼저 TUN을 끄고 시스템 프록시를 사용해 노드 하나로 HTTPS 페이지가 정상적으로 열리는지 확인합니다. 노드 자체가 작동하지 않는다면 가상 어댑터를 추가해도 문제 원인만 늘어납니다. 구독 가져오기는 구독 설정 가이드를 참고하세요. 연결에 실패하면 먼저 문제 해결의 로그 확인 방법을 살펴보세요.

현재 설정 기록: 사용 중인 노드, 라우팅 모드, 로컬 수신 포트, 사용자 지정 DNS를 적어 둡니다. 구독 주소나 노드 인증 정보가 포함된 설정은 로컬에만 저장하고 공개적으로 공유하지 마세요.
다른 네트워크 경로 제어 기능 종료: 다른 VPN 연결과 기본 라우팅을 변경하는 도구를 잠시 끕니다. 회사 원격 접속을 반드시 사용해야 한다면 네트워크 설정을 변경해도 되는지 먼저 확인하세요.
권한 확인: Windows에서 v2rayN을 완전히 종료한 뒤 프로그램을 마우스 오른쪽 버튼으로 클릭하고 ‘관리자 권한으로 실행’을 선택합니다. 권한 요청이 표시되면 승인하세요. 창을 닫아도 트레이로 최소화될 수 있으므로 트레이 메뉴에서 완전히 종료해야 합니다.
실행 파일 확인: 로그에 TUN 관련 커널 또는 드라이버 파일이 없다고 표시되면 시스템 아키텍처에 맞는 전체 배포 패키지를 사용하세요. 출처를 알 수 없는 동적 라이브러리를 따로 내려받아 추가하지 마세요.

10808

로컬 프록시 연결 지점 예시. 실제 값은 설정에 따라 다릅니다.

일반적인 DNS 목적지 포트

443

일반적인 HTTPS 목적지 포트

이 세 숫자는 로컬 연결 지점, 도메인 조회, 웹사이트 연결을 구분하기 위한 것입니다. 방화벽에서 전부 열어야 하는 포트가 아닙니다. 문제를 해결하려고 로컬 수신 주소를 127.0.0.1에서 0.0.0.0으로 바꾸지 마세요. TUN이 로컬 앱의 트래픽을 처리하는 데 프록시 연결 지점을 로컬 네트워크에 공개할 필요는 없습니다.

3. v2rayN에서 TUN을 켜는 순서

데스크톱 버전에 따라 설정 메뉴 위치가 달라질 수 있습니다. 일반적인 인터페이스에서는 ‘설정’ → ‘매개변수 설정’에서 ‘TUN 모드 설정’을 찾을 수 있고, 메인 창에 ‘TUN 사용’ 스위치가 바로 표시되기도 합니다. 아래 단계는 기능 이름을 기준으로 진행하세요. 해당 항목이 없다면 현재 버전과 플랫폼을 확인하고, 다른 버전의 화면을 보고 생소한 항목을 변경하지 마세요.

확인한 노드 선택. 현재 선택된 노드가 맞는지 확인하고, 시스템 프록시로 웹 페이지 접속 테스트를 완료합니다.
네트워크 경로를 하나로 정리. 먼저 시스템 프록시를 ‘시스템 프록시 해제’로 전환하고 클라이언트 커널은 계속 실행해 둡니다. 이때 잠시 프록시 대상에 접속할 수 없는 것은 정상이며, 다음 단계에서 TUN으로 전환합니다.
TUN 기본 설정 유지. 처음 켤 때 프로토콜 스택, MTU, 인터페이스 이름, DNS 정책을 한꺼번에 변경하지 마세요. 현재 버전의 기본 설정으로 재현 가능한 기준 상태를 먼저 만듭니다.
‘TUN 사용’ 켜기. 로그에 인터페이스 생성, 커널 시작, 라우팅 초기화 메시지가 나타나는지 확인합니다. 스위치가 켜져 있다는 표시는 인터페이스 상태만 보여 줄 뿐이므로 실제 접속 테스트가 필요합니다.
가상 인터페이스 확인. Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘고급 네트워크 설정’에서 네트워크 어댑터를 확인합니다. 아래 읽기 전용 명령을 사용해도 됩니다.
연결 확인 후 설정 변경. 웹 페이지와 대상 앱이 모두 연결되는지 확인한 다음 사용자 지정 라우팅을 하나씩 적용합니다. 설정을 하나 바꿀 때마다 테스트해 여러 변수를 한꺼번에 변경하지 않도록 합니다.

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

위 명령은 PowerShell에서 실행하며 어댑터와 라우팅 정보를 읽기만 합니다. 커널마다 인터페이스 이름이 다르고, 라우팅을 넘겨받을 때 여러 개의 구체적인 접두사가 사용될 수도 있습니다. 0.0.0.0/0 경로가 하나 있는지만으로 성공 여부를 판단하지 말고 인터페이스 상태, 시작 로그, 실제 연결 기록을 함께 확인하세요.

4. 라우팅 분기와 DNS를 함께 설정

TUN을 켠 뒤에도 적절한 트래픽 분기를 유지해야 합니다. 로컬 네트워크 기기, 사내 네트워크, 노드 서버로 향하는 연결은 올바른 경로를 사용해야 합니다. 모든 주소를 무조건 프록시로 다시 보내면 라우팅 루프가 생길 수 있습니다. 일반적인 버전은 프록시 아웃바운드의 인터페이스 선택이나 우회를 처리하지만, 사용자 지정 설정, 여러 가상 어댑터, 복잡한 정책 라우팅은 이 관계를 깨뜨릴 수 있습니다.

라우팅 확인 항목

로컬 네트워크: 사설 IP 주소와 실제 내부 네트워크 대역이 직접 연결되는지 확인
프록시 대상: 현재 규칙에 따라 프록시 아웃바운드로 연결
기본 출구: 규칙에 일치하지 않는 트래픽의 처리 방식 지정
노드 연결: 노드 서버 연결이 프록시 라우팅 루프에 다시 들어가지 않도록 설정

내장 라우팅을 먼저 사용한 뒤 필요한 내부 네트워크 대역만 추가하세요.

DNS 확인 항목

직접 연결 DNS 조회: 현재 네트워크에서 접근 가능한 조회 경로 선택
프록시 DNS 조회: DNS 서버에 지정된 출구를 통해 연결할 수 있는지 확인
초기 DNS 조회: 노드 도메인을 아직 연결되지 않은 프록시를 통해 조회하도록 설정하지 않기
IPv6: DNS 조회 결과와 실제 IPv6 라우팅 지원 여부 일치

문제 해결 중에는 기본 DNS 설정을 유지하고 연결이 확인된 후 변경하세요.

DNS에서 흔히 발생하는 문제는 순환 의존성입니다. 노드에 연결하려면 노드 도메인을 먼저 조회해야 하는데, 그 조회 요청도 반드시 해당 노드를 거치도록 설정한 경우입니다. 공용 DNS 주소를 계속 바꾸기보다 노드 도메인을 처음 조회할 수 있는 경로를 마련하세요. 암호화 DNS를 사용한다면 DNS 서버 도메인의 초기 조회 경로도 고려해야 합니다.

로컬 네트워크 예시: 프린터 주소가 192.168.1.50이라면 해당 네트워크 대역인 192.168.1.0/24가 로컬 네트워크로 연결되는지 확인하세요. 프린터 이름만 등록하고 실제 조회 결과를 확인하지 않으면 안 됩니다.
앱 자체 DNS: 브라우저의 보안 DNS는 별도의 HTTPS 요청을 사용할 수 있으므로 53번 포트의 DNS 트래픽을 처리한다고 해서 보안 DNS까지 포함된다고 볼 수는 없습니다. 문제를 확인할 때 브라우저 설정을 기록하고, 필요하면 일시적으로 시스템 DNS를 사용하세요.
IPv6 예시: 도메인에서 AAAA 레코드를 받았지만 사용 가능한 IPv6 출구가 없으면 한동안 기다린 뒤 연결이 전환될 수 있습니다. 클라이언트의 IPv6 정책을 변경하기 전에 네트워크에서 IPv6를 지원하는지 확인하세요. 시스템 네트워크 어댑터 설정만 바꾸지 마세요.

5. 스위치 상태가 아니라 TUN 작동 여부 확인

검증할 때는 ‘트래픽이 TUN으로 들어오는지’와 ‘분기 규칙이 올바른지’를 모두 확인해야 합니다. 먼저 시스템 프록시가 해제되어 있고 대상 앱에도 프록시가 수동 설정되어 있지 않은지 확인한 다음, 접속 가능한 것으로 알려진 사이트를 방문합니다. 그렇지 않으면 브라우저가 기존 프록시 연결 지점을 계속 사용해도 접속될 수 있으므로 TUN이 작동한다는 근거가 되지 않습니다.

HTTPS 테스트: 접속 가능한 HTTPS 사이트를 열고 클라이언트 로그에 해당 연결이 기록되는지 확인합니다. 웹페이지 캐시가 연결 문제를 가릴 수 있으므로 필요하면 한 번도 방문하지 않은 페이지를 새로고침하세요.
대상 프로그램 테스트: 원래 시스템 프록시를 사용하지 않던 앱을 열고 연결 결과와 연결 로그를 확인합니다. 앱이 가상 머신이나 컨테이너에서 실행된다면 호스트의 TUN이 별도 네트워크까지 처리한다고 단정하지 마세요.
트래픽 분기 테스트: 직접 연결되어야 하는 내부 주소와 프록시를 거쳐야 하는 도메인에 각각 접속하고, 로그에 기록된 규칙과 아웃바운드를 비교합니다. 공인 IP 확인은 해당 요청의 경로만 보여 줄 뿐 모든 앱의 연결 상태를 나타내지는 않습니다.
UDP 테스트: 대상 앱에서 UDP가 필요한 경우에만 기능을 확인하세요. TCP 웹페이지가 정상적으로 열려도 UDP가 지원된다는 뜻은 아닙니다. 서버 정책이나 노드의 전송 방식에 따라 UDP가 제한될 수 있습니다.

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

한 번의 지연 시간 테스트를 속도 평가의 근거로 삼지 마세요. 노드 목록에 표시되는 지연 시간은 보통 특정 방식으로 측정한 값이며 영상 재생 속도나 게임 왕복 지연을 뜻하지 않습니다. 차이를 어느 계층에서 비롯됐는지 확인하려면 노드, 네트워크, 대상은 그대로 두고 시스템 프록시와 TUN만 바꿔 비교하세요.

6. TUN을 켠 뒤 인터넷에 연결되지 않을 때 자주 묻는 질문

TUN을 켜자마자 인터넷이 끊기면 무엇부터 바꿔야 하나요?

먼저 TUN을 끄고 기존 시스템 프록시를 복구해 노드 연결을 확인하세요. 연결이 바로 복구되면 관리자 권한, 가상 인터페이스 생성 실패, 라우팅 충돌을 우선 확인합니다. 여전히 연결되지 않으면 노드와 로컬 커널부터 점검하세요. 조건을 한 번에 하나씩 바꾸고 모든 네트워크 어댑터를 먼저 삭제하지 마세요.

로그에 access denied가 표시됩니다. 프로그램을 다시 시작하면 해결되나요?

권한이 부족할 수 있습니다. 트레이에서 프로그램을 완전히 종료한 뒤 관리자 권한으로 실행하세요. 그래도 오류가 나면 거부된 작업이 인터페이스 생성, 라우팅 변경, 파일 읽기 중 무엇인지 확인합니다. 관리되는 기기라면 보안 정책도 확인해야 하며, 테스트를 위해 방화벽 전체를 끄는 것은 피하세요.

웹페이지는 열리지만 프린터와 사내 네트워크에 연결되지 않나요?

사설 IP가 직접 연결되는지 확인하고 회사에서 실제로 사용하는 네트워크 대역도 확인하세요. 일부 사내 네트워크는 추가 라우팅이나 전용 DNS를 사용하므로 일반적인 사설 대역만 허용하는 것으로 충분하지 않을 수 있습니다. 먼저 TUN을 끈 상태와 비교한 뒤 조직의 네트워크 정책에 맞춰 라우팅을 추가하세요.

로그에 DNS 시간 초과가 계속 표시되고 노드를 바꿔도 해결되지 않나요?

현재 버전의 기본 DNS 설정으로 되돌리고 로컬 네트워크와 DNS 출구에 연결할 수 있는지 확인하세요. 노드 도메인 조회가 초기 연결 경로와 순환되는지, 브라우저 보안 DNS와 IPv6 설정은 어떤지 점검합니다. ping이 실패했다고 DNS나 프록시가 작동하지 않는다고 단정할 수는 없습니다. 대상이 ICMP에 응답하지 않을 수도 있습니다.

절전 모드에서 깨어난 뒤 연결이 끊겼습니다. 다시 설치해야 하나요?

먼저 TUN을 껐다가 다시 켜 커널이 물리 네트워크 인터페이스를 새로 확인하도록 합니다. Wi-Fi 전환, 유선 네트워크 연결 변경, 절전 모드로 인해 출구 인터페이스가 달라질 수 있습니다. 그래도 해결되지 않으면 클라이언트를 정상적으로 종료한 뒤 다시 시작하고, 네트워크 변경 전후의 로그를 보관하세요. 바로 재설치할 필요는 없습니다.

7. TUN 사용에 적합한 상황과 안전한 종료 순서

브라우저만 프록시를 사용한다면 시스템 프록시로 충분한 경우가 많고 설정도 간단합니다. 시스템 설정을 따르지 않는 데스크톱 앱 여러 개에 동일한 라우팅 규칙을 적용하거나, 앱에서 UDP를 사용해야 할 때 TUN을 고려하세요. TUN은 네트워크 처리 범위를 넓힐 뿐 노드 대역폭을 높이거나 서버 연결 불가, 만료된 구독, 잘못된 프로토콜 매개변수를 자동으로 해결하지 않습니다.

정상 종료: 먼저 TUN을 끄고 커널이 관련 라우팅을 정리할 때까지 기다린 다음 트레이에서 v2rayN을 종료하세요. 시스템 프록시를 계속 사용하려면 해당 모드를 다시 켭니다.
비정상 종료 후: 클라이언트를 다시 시작한 뒤 TUN을 한 번 켰다가 꺼 프로그램이 정리 작업을 완료하도록 합니다. Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 설정이 남아 있는지도 확인하세요.
복구되지 않는 경우: 로그를 보관하고 시스템을 재시작한 뒤 물리 네트워크를 확인하세요. 인터넷에서 찾은 경로 일괄 삭제 명령을 그대로 실행하면 사내 네트워크나 필요한 연결까지 삭제될 수 있습니다.
설정 완료 후: 연결 가능한 노드, 라우팅 모드, DNS 정책, 테스트 결과를 기록해 두세요. 이후 업데이트하거나 네트워크를 바꾼 뒤 문제가 생기면 이 기준을 따라 항목별로 비교할 수 있습니다.

판단 기준은 간단합니다. 시스템 프록시를 해제한 뒤에도 대상 앱이 예상대로 연결되고, 직접 연결해야 하는 대상은 프록시를 거치지 않으며, 종료 후 시스템 네트워크가 정상으로 복구되어야 합니다. 이 세 가지를 확인한 다음 사용자 지정 규칙을 하나씩 추가하면 처음부터 복잡한 설정을 구성하는 것보다 관리하기 쉽습니다.