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

이 글의 핵심

이 글은 Windows용 v2rayN을 기준으로 설명합니다. 시스템 프록시는 작동하지만 터미널이나 일부 앱에서 규칙에 따라 연결되지 않는 경우에 유용합니다. 먼저 노드를 확인하고, 관리자 권한으로 TUN을 켠 다음 트래픽 처리 범위와 라우팅 결과, DNS를 차례로 점검합니다. TUN은 트래픽을 처리 경로로 전달하는 기능이지 모든 연결을 반드시 프록시로 보내는 기능은 아닙니다. macOS와 Linux는 플랫폼별 권한 및 네트워크 관리 방식을 따라야 합니다.

TUN 가상 어댑터와 시스템 프록시의 차이

시스템 프록시는 해당 설정을 지원하는 앱에 로컬 프록시 주소를 전달합니다. 브라우저에서는 대체로 사용할 수 있지만, 일부 터미널 프로그램이나 게임, 자체적으로 연결을 설정하는 앱은 이 설정을 읽지 않습니다. TUN은 3계층 가상 네트워크 인터페이스를 만들고 시스템 라우팅과 함께 IP 패킷을 로컬 네트워크 처리 구성 요소로 전달합니다. 따라서 HTTP 또는 SOCKS 프록시 설정을 지원하지 않는 프로그램도 더 폭넓게 처리할 수 있습니다.

앱의 네트워크 요청 시스템 라우팅 TUN 인터페이스에서 수신 규칙에 따라 트래픽 분기 직접 연결 또는 프록시

‘전체 트래픽 처리’는 트래픽이 들어오는 범위를, ‘전체 프록시’는 나가는 경로를 설명합니다. 서로 다른 설정입니다. TUN이 받은 연결도 도메인, 대상 IP 등 지원되는 조건에 따라 직접 연결하거나 프록시로 보내고 차단할 수 있습니다. 로컬 네트워크나 루프백 주소, 명시적으로 제외한 경로는 TUN을 거치지 않을 수 있습니다. 스위치가 켜졌다는 이유만으로 모든 트래픽이 처리된다고 단정하지 마세요.

비교 항목	시스템 프록시	TUN 모드
트래픽 진입 방식	앱이 로컬 프록시 포트에 연결	시스템 라우팅이 IP 패킷을 가상 인터페이스로 전달
앱 지원 여부	앱이 시스템 프록시를 지원하거나 프록시를 직접 설정해야 함	대개 앱마다 프록시 주소를 설정할 필요 없음
권한	현재 사용자 프록시 설정은 보통 관리자 권한이 필요하지 않음	인터페이스 생성 및 라우팅 변경에는 보통 관리자 권한 필요
UDP 지원	HTTP 시스템 프록시는 일반 UDP 트래픽을 처리할 수 없음	TUN 구성 요소, 프로토콜, 서버 지원 여부에 따라 다름
주요 점검 항목	수신 포트, 앱의 프록시 설정	인터페이스, 라우팅, DNS, 아웃바운드 연결

시작 전: 노드와 로컬 포트 확인

먼저 TUN을 끄고 시스템 프록시나 앱의 수동 프록시 설정으로 노드를 테스트합니다. 구독을 가져왔다는 것은 설정을 읽었다는 뜻일 뿐, 원격 서버에 연결할 수 있다는 의미는 아닙니다. VMess, VLESS 등의 연결 매개변수와 전송 방식, TLS 설정이 서버와 일치해야 합니다. 일반 프록시 연결부터 실패한다면 먼저 노드 문제를 해결해 가상 어댑터 문제와 혼동하지 않도록 하세요.

10808

이 글의 로컬 프록시 포트 예시

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

443

HTTPS에서 자주 사용하는 대상 포트

위 포트는 프로토콜 설명과 테스트를 위한 예시이며, 성능 측정값이나 v2rayN의 기본 수신 포트를 보장하는 값이 아닙니다. ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인하세요. 메뉴 구성은 버전에 따라 달라질 수 있습니다. 해당 포트에서 HTTP 프록시 연결을 받는 것을 확인한 뒤 아래 명령을 실행하세요. 예시는 수신 주소가 127.0.0.1, 포트가 10808이라고 가정합니다.

curl.exe --proxy http://127.0.0.1:10808 --head --connect-timeout 10 https://www.example.com/

HTTP 응답 헤더가 도착하면 이번 요청의 프록시 연결이 성립한 것입니다. 모든 웹사이트나 UDP가 작동한다는 뜻은 아닙니다.
로컬 포트 연결 실패 메시지가 나오면 코어 실행 여부, 수신 포트 일치 여부, 다른 프로세스의 포트 점유 여부를 먼저 확인하세요.
핸드셰이크 또는 원격 연결 오류가 표시되면 코어 로그를 확인하고 노드 설정, 시스템 시간, 서버 매개변수를 점검하세요.
현재 시스템 프록시, 라우팅 모드, DNS 설정을 기록하고 네트워크를 대신 처리하는 다른 도구는 끄세요. 문제가 생겼을 때 되돌릴 수 있는 기준 상태를 남겨두는 것이 좋습니다.

Windows에서 v2rayN TUN 켜기

v2rayN은 설정과 프로세스를 관리하는 인터페이스이며, TUN의 실제 처리는 함께 제공되는 구성 요소가 담당합니다. 스위치 위치, 네트워크 스택 옵션, 실행 방식은 버전마다 다를 수 있습니다. 데스크톱 인터페이스의 특정 옵션을 V2Fly나 Xray에서 공통으로 사용하는 설정 항목으로 간주하지 마세요. 현재 설치 패키지에 해당 버전에서 필요한 TUN 구성 요소가 포함되어 있는지 확인한 뒤 권한을 높이세요.

프로그램을 종료한 뒤 관리자 권한으로 실행합니다. 시스템 트레이에서 v2rayN을 종료하고 기존 프로세스가 완전히 끝났는지 확인합니다. 프로그램이나 바로 가기를 마우스 오른쪽 버튼으로 클릭한 다음 ‘관리자 권한으로 실행’을 선택하세요. 현재 버전에 관리자 권한으로 다시 시작하는 기능이 있다면 이를 사용해도 됩니다.
사용 가능한 노드를 선택합니다. 서버 목록에서 일반 프록시 테스트를 통과한 노드를 선택하고 현재 라우팅 모드를 확인하세요. 처음 테스트할 때는 기존 규칙을 유지하고 노드, DNS, 네트워크 스택을 한꺼번에 바꾸지 마세요.
시스템 프록시를 해제합니다. 메인 창이나 트레이의 시스템 프록시 메뉴에서 ‘시스템 프록시 해제’를 선택합니다. 이 단계는 두 경로가 동시에 작동해 문제 원인이 복잡해지는 것을 줄이기 위한 것입니다. 모든 버전에서 TUN을 켤 때 반드시 필요한 절차는 아닙니다.
TUN을 켭니다. 메인 화면에서 ‘Tun 활성화’ 또는 이에 해당하는 TUN 스위치를 찾아 켭니다. 화면마다 대소문자 표기가 다를 수 있습니다. 해당 메뉴가 없다면 플랫폼, 설치 패키지, 현재 버전의 문서를 확인하세요. 출처가 불분명한 네트워크 어댑터 드라이버는 설치하지 마세요.
시작 로그를 확인합니다. 권한 부족, 인터페이스 생성 실패, 라우팅 적용 실패가 없는지 확인하세요. 그런 다음 시스템 네트워크 인터페이스와 라우팅을 점검하고 프록시를 지정하지 않은 요청을 보내 봅니다.

라우팅 분기와 DNS: 트래픽 처리 이후의 경로

안정적인 설정을 위해서는 두 가지를 함께 확인해야 합니다. 연결이 어떤 아웃바운드 경로와 일치하는지, 도메인 주소를 어떤 DNS 경로로 조회하는지입니다. TUN이 연결을 받은 뒤에도 로컬 네트워크 접근을 허용하는 라우팅 정책을 유지해야 하며, 프록시 서버 자체의 연결이 다시 프록시 진입점으로 들어가 순환하지 않도록 해야 합니다. 현재 TUN 방식에 맞춰 클라이언트가 생성한 설정을 우선 사용하고, 다른 코어의 JSON을 그대로 붙여 넣지 마세요.

최초 트래픽 처리 기준

시스템 프록시: 해제: 테스트 범위 분리
TUN 스위치: 켜고 시작 로그 확인
로컬 주소: 루프백 및 로컬 네트워크 접근 유지
프록시 노드: 검증된 노드 사용

이 목록은 클라이언트 조작 점검표이며 가져오기 가능한 코어 설정 항목이 아닙니다.

DNS 점검 기준

일반 DNS 조회: UDP/TCP 53 처리 경로 확인
암호화된 DNS 조회: 앱 내 DoH 설정을 별도로 확인
DNS 조회 경로: 선택한 경로에서 DNS 업스트림에 연결할 수 있는지 확인
IPv6: IPv6 라우팅과 조회 결과도 함께 확인

일반 DNS만 처리한다고 해서 앱 내 암호화 DNS도 같은 정책으로 처리되는 것은 아닙니다.

로컬 네트워크 주소는 실제 네트워크 구성에 맞춰 처리해야 합니다. 예를 들어 192.168.1.0/24는 가정용 공유기가 사용하는 대역일 수 있지만, 회사 네트워크에서는 다른 대역을 사용할 수 있습니다. 예시 대역 하나만 추가하고 모든 내부망이 처리된다고 생각하지 마세요. 라우팅 테이블을 확인해 프린터, 파일 서버, 내부 DNS의 대상 범위를 파악해야 합니다.

도메인 규칙은 도메인 정보가 어디서 오는지부터 확인합니다. 앱이 먼저 도메인을 조회한 뒤 IP 주소로 연결할 수 있습니다. 도메인 기반 규칙을 사용한다면 현재 TUN 방식에서 도메인 정보가 어떻게 보존되거나 복원되는지 확인하세요. 모든 연결에 도메인 정보가 포함된다고 가정하면 안 됩니다.
DNS 업스트림은 연결이 불가능한 상태에 의존해서는 안 됩니다. 프록시 노드 주소를 조회해야 연결할 수 있는 경우, ‘노드에 먼저 연결해야 노드 주소를 조회할 수 있는’ 시작 단계의 의존 관계를 피하세요.
IPv4와 IPv6를 각각 확인합니다. 웹페이지가 열린다고 해서 두 주소 체계 모두 예상한 경로를 이용하는 것은 아닙니다. IPv6에 트래픽 처리 라우팅이 없으면 앱이 다른 경로로 나갈 수 있습니다.
규칙을 바꾼 뒤에는 설정을 다시 불러옵니다. 클라이언트에서 설정을 저장하고 다시 불러온 다음 새 연결로 테스트하세요. 이미 연결된 장시간 연결은 이전 경로를 계속 사용할 수 있습니다.

TUN 확인: 인터페이스, 라우팅, 실제 연결

작업 표시줄 아이콘이나 가상 네트워크 어댑터 이름만 확인해서는 안 됩니다. 제대로 작동하는지 확인하려면 인터페이스가 생성되었는지, 대상 경로가 예상한 라우팅을 통과하는지, 연결 로그에 올바른 아웃바운드가 표시되는지 세 가지를 함께 대조해야 합니다. 인터페이스 이름은 구성 요소와 버전에 따라 달라지므로 모든 PC에 같은 이름이 표시되어야 하는 것은 아닙니다. 기본 경로보다 구체적인 네트워크 대역을 사용하는 경우도 있으므로 0.0.0.0/0 항목만 찾지 마세요.

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6
curl.exe --noproxy "*" --head --connect-timeout 10 https://www.example.com/

처음 세 명령은 PowerShell에서 실행합니다. 마지막 명령의 --noproxy "*"는 curl의 명시적 프록시 설정을 건너뛰고 요청을 시스템 라우팅에 맡깁니다. TUN을 우회하지는 않습니다. 요청이 성공해도 해당 대상에 현재 연결할 수 있다는 사실만 확인할 수 있습니다. 직접 연결인지 프록시인지 확인하려면 로그도 함께 살펴보세요.

테스트 대상	테스트 방법	판정 기준
프록시를 설정하지 않은 프로그램	앱에 별도로 설정된 프록시를 해제한 뒤 새 요청 실행	코어 로그에 해당 연결과 예상한 아웃바운드가 표시됨
로컬 네트워크 서비스	실제 게이트웨이, 프린터 또는 내부 사이트에 접속	로컬 서비스에 연결되고 원격 프록시로 잘못 전달되지 않음
도메인 조회	앱 캐시를 지운 뒤 테스트 도메인에 접속	DNS 로그, 연결 대상, 적용 정책이 서로 일치
UDP 앱	실제로 필요한 음성 통화 또는 기타 UDP 기능 사용	서버와 선택한 프로토콜이 지원하며 로그에 연속 오류가 없음

ping은 ICMP를 사용하므로 TCP나 UDP 프록시 테스트와는 다릅니다. 대상이 ping에 응답하지 않는다고 TUN이 작동하지 않는다고 볼 수 없습니다. 브라우저에서 웹페이지가 열려도 음성 통화, 게임, 모든 UDP 요청이 정상이라는 뜻은 아닙니다. 실제 앱에서 사용하는 전송 프로토콜에 맞춰 각각 테스트하세요.

TUN이 켜지지 않거나 인터넷이 끊길 때, 네트워크 어댑터 충돌 해결

‘권한 및 구성 요소 → 인터페이스 및 라우팅 → DNS → 원격 연결’ 순서로 확인하세요. 한 번에 하나의 설정만 바꾸고 문제가 발생한 시점 전후의 로그를 저장합니다. 가상 머신 네트워크, 회사 원격 접속 소프트웨어, 다른 가상 네트워크 어댑터는 문제없이 함께 사용할 수도 있습니다. 문제가 생기면 먼저 서로 트래픽을 처리하려는 기능을 중지하세요. 네트워크 어댑터를 한꺼번에 모두 삭제하지 마세요.

스위치를 켜자마자 자동으로 꺼집니다. 어떻게 해야 하나요?

먼저 관리자 권한으로 실행했는지 확인한 다음 로그에서 인터페이스 생성 실패, 파일 누락, 권한 오류를 찾으세요. 현재 설치 패키지에 필요한 구성 요소가 포함되어 있고 보안 정책에 의해 격리되지 않았는지도 확인합니다. 실패한다는 이유만으로 네트워크 스택을 반복해서 바꾸지 말고, 시작 과정에서 처음 발생한 오류부터 확인하세요.

TUN을 켠 뒤 모든 웹페이지가 열리지 않습니다. DNS 문제인가요?

꼭 그렇지는 않습니다. 먼저 TUN을 끄고 기존 로컬 프록시 연결을 다시 테스트하세요. 여전히 연결되지 않는다면 노드부터 확인합니다. 일반 프록시가 정상이라면 TUN 라우팅과 DNS 로그를 비교하세요. 이름 조회 시간 초과가 발생한 경우 DNS 업스트림 연결 가능 여부, 조회 경로, 노드 도메인의 연결 전 조회를 중점적으로 확인합니다.

웹은 되지만 음성 통화나 게임에 연결할 수 없습니다. 어떻게 해야 하나요?

앱이 실제로 UDP를 사용하는지 확인하고 현재 프록시 프로토콜과 서버가 해당 트래픽을 지원하는지 살펴보세요. 로그에 해당 대상이 기록되는지 확인한 뒤 방화벽도 점검합니다. TCP 웹 연결이 성공해도 UDP 테스트를 대신할 수 없습니다. 로컬 수신 포트만 바꿔서는 서버의 지원 기능을 보완할 수 없습니다.

TUN을 켠 뒤 회사 내부망이나 프린터에 연결할 수 없나요?

먼저 TUN을 끄고 연결이 복구되는지 확인한 다음 대상 내부망 대역과 현재 라우팅이 겹치는지 살펴보세요. 실제 네트워크 대역에 맞춰 직접 연결 또는 우회 규칙을 추가합니다. 회사 원격 접속을 계속 사용해야 한다면 조직의 네트워크 정책에 따라 라우팅을 조정하세요. 관리 대상 네트워크 설정을 덮어쓰지 마세요.

창을 닫았는데도 인터넷이 끊긴 상태입니다. 어떻게 복구하나요?

먼저 창 닫기와 프로그램 종료를 구분하세요. 시스템 트레이의 프로세스는 계속 실행 중일 수 있습니다. 메인 창을 다시 열어 TUN을 끄고 시스템 프록시를 해제한 다음 트레이에서 프로그램을 종료하세요. 프로세스가 비정상 종료되었다면 다시 실행한 뒤 정상적으로 종료합니다. 문제가 계속 남으면 라우팅 정보를 저장하고 시스템을 재시작해 확인하세요.

TUN 종료 및 재현 가능한 설정 기록

테스트가 끝나면 운영체제, 클라이언트 버전, 현재 노드 프로토콜, TUN 설정, 라우팅 모드, DNS 업스트림, 문제 발생 시 처음 나타난 오류를 간단히 기록하세요. 구독 주소나 연결 자격 증명, 사용자 식별 정보가 포함된 전체 설정을 공개하지 마세요. ‘켜면 작동하지 않음’이라고만 적기보다 어떤 단계를 바꾼 뒤 동작이 달라졌는지 알 수 있도록 기록해야 합니다.

TUN을 끄고 관련 프로세스나 인터페이스가 중지되었다는 로그가 표시될 때까지 기다린 뒤 일반 네트워크가 복구되었는지 확인합니다.
시스템 프록시를 계속 사용한다면 시스템 프록시 모드를 별도로 설정하세요. 클라이언트를 종료할 때는 시스템 프록시를 해제한 상태로 유지합니다.
로컬 네트워크와 자주 사용하는 사이트를 다시 테스트하고 기본 경로를 다른 도구가 계속 사용하고 있지 않은지 확인합니다.
기준 상태가 안정적인 것을 확인한 뒤 사용자 지정 트래픽 분기 규칙이나 고급 옵션을 하나씩 켜세요. 서로 덮어쓰는 규칙 세트를 한꺼번에 가져오지 마세요.

TUN은 더 많은 트래픽을 처리 경로에 넣을 수 있지만, 최종 동작은 라우팅, DNS, 아웃바운드 기능에 따라 달라집니다. 설정 항목을 추가로 확인하려면 설정 항목 설명을 참고하세요. 클라이언트가 생성한 TUN 설정을 모든 코어에서 사용할 수 있는 공통 config.json으로 착각하지 마세요.