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

이 글의 핵심 내용

이 글에서는 Windows 데스크톱용 v2rayN을 기준으로 설명합니다. 먼저 시스템 프록시로 노드가 작동하는지 확인하고, 관리자 권한으로 TUN을 켠 뒤 라우팅·DNS·앱 연결을 각각 점검합니다. 브라우저는 연결되지만 명령줄 도구나 다른 프로그램은 프록시를 사용하지 않는 경우에 유용합니다. TUN이 트래픽을 가져오더라도 최종적으로 직접 연결할지 프록시를 사용할지는 라우팅 규칙에 따라 달라집니다.

시스템 프록시와 TUN: 트래픽을 가로채는 위치가 다릅니다

시스템 프록시는 시스템 설정을 따르는 프로그램에 로컬 프록시 주소를 전달합니다. 앱이 요청을 프록시 수신 포트로 보내면 클라이언트가 이를 전달합니다. 자체 네트워크 스택이나 별도의 프록시 설정을 사용하거나 UDP 연결을 직접 만드는 프로그램은 이 설정을 우회할 수 있습니다. 브라우저에서 웹 페이지가 열린다고 해서 다른 프로그램도 프록시를 사용한다고 볼 수는 없습니다.

TUN은 네트워크 계층에 가상 인터페이스를 제공합니다. 시스템 라우팅이 조건에 맞는 IP 패킷을 이 인터페이스로 보내면 TUN 백엔드가 처리해 직접 연결 또는 프록시 아웃바운드로 전달합니다. 앱이 HTTP나 SOCKS 프록시를 지원하지 않아도 사용할 수 있지만, 모든 네트워크 프로토콜과 주소가 빠짐없이 전달되는 것은 아닙니다.

앱 요청 시스템 라우팅 TUN 처리 규칙 매칭 직접 연결 또는 프록시

여기서 ‘전체’가 가리키는 두 가지 범위를 구분해야 합니다. TUN이 트래픽을 가져오는 범위와 라우팅 규칙이 프록시를 적용하는 범위는 별개입니다. TUN을 켜도 로컬 네트워크, 사설 IP 또는 규칙에서 지정한 대상은 직접 연결될 수 있습니다. TUN이 처리할 수 있는 모든 공인망 연결에 프록시를 사용하려면 스위치 상태만 볼 것이 아니라 현재 라우팅 모드와 기본 아웃바운드도 확인해야 합니다.

시작 전 확인: 포트·노드·라우팅 기준 기록하기

먼저 v2rayN에서 가져온 노드를 선택해 활성 서버로 지정한 다음 시스템 프록시를 사용해 실제 웹 페이지에 접속해 봅니다. 지연 시간 측정 결과만으로는 충분하지 않습니다. 테스트 성공은 해당 탐색 경로가 작동한다는 뜻일 뿐, DNS와 TLS, 실제 서비스 트래픽까지 모두 정상이라는 뜻은 아닙니다. 이 단계에서 실패하면 노드 주소, 인증 정보, 전송 설정과 서버 상태부터 확인하세요.

10808

이 글에서 사용하는 로컬 프록시 포트 예시

일반 DNS 조회 포트

443

HTTPS 대상 포트 예시

10808은 아래 예시에만 사용하는 테스트 값입니다. 먼저 ‘설정’ → ‘매개변수 설정’을 열고 로컬 수신 포트 항목을 찾아 실제 포트로 명령의 값을 바꾸세요. 버전에 따라 혼합 수신 포트를 제공하거나 SOCKS와 HTTP 포트를 따로 표시할 수 있습니다. 해당 포트가 HTTP 프록시를 지원하는지 확인한 경우에만 아래 HTTP 프록시 테스트 명령을 사용하세요.

현재 활성 노드, 라우팅 모드와 시스템 프록시 상태를 기록하고 필요하면 클라이언트 설정을 백업합니다.
기본 라우팅이나 DNS를 이미 처리 중인 다른 VPN, 네트워크 가속기와 프록시 프로그램을 종료하고, 기준 테스트에는 하나만 사용합니다.
현재 배포 패키지에 필요한 코어 구성 요소가 포함되어 있는지 확인합니다. 로그에 실행 파일이 없다고 표시되면 구성 요소를 먼저 갖추세요. TUN을 반복해서 켰다 끄지 마세요.
회사 장비에서는 가상 인터페이스 생성이 네트워크 및 엔드포인트 보안 정책상 허용되는지 먼저 확인하세요. 보안 프로그램을 끄는 방식으로 관리 정책을 우회하지 마세요.

Windows 설정 방법: 관리자 권한과 TUN 옵션

아래 내용은 ‘TUN 사용’ 스위치가 있는 v2rayN 화면을 기준으로 합니다. 데스크톱 버전과 WPF 버전, 릴리스에 따라 버튼 위치가 다를 수 있습니다. 일반적으로 메인 화면에서 TUN을 켜고, 관련 설정은 ‘설정’ → ‘매개변수 설정’의 TUN 항목에서 변경합니다. 현재 화면에 옵션이 없다면 클라이언트 버전과 배포 패키지 종류부터 확인하세요. Windows 네트워크 설정에서 같은 이름의 어댑터를 직접 만들지 마세요.

완전히 종료한 뒤 관리자 권한으로 실행합니다. 시스템 트레이 메뉴에서 v2rayN을 종료하고 기존 프로세스가 끝났는지 확인한 다음, 프로그램을 마우스 오른쪽 버튼으로 클릭해 ‘관리자 권한으로 실행’을 선택합니다. 창만 다시 열고 트레이 프로세스가 계속 실행 중이면 기존 권한으로 작동할 수 있습니다.
활성 노드를 확인합니다. 메인 화면에서 현재 서버와 라우팅 모드를 확인하세요. 실제 접속으로 작동이 검증된 노드를 그대로 사용하고, 처음 TUN을 켤 때 구독, 전송 방식, DNS를 동시에 바꾸지 마세요.
TUN 옵션을 확인합니다. 처음에는 클라이언트 기본 스택, MTU, 라우팅 설정을 유지하세요. 사용자 지정 설정을 사용하는 경우 자동 라우팅이 꺼져 있지 않은지 확인합니다. 꺼져 있으면 가상 인터페이스가 있어도 대상 연결을 처리하지 못할 수 있습니다.
시스템 프록시를 해제합니다. 클라이언트의 시스템 프록시 메뉴에서 설정을 해제해 TUN만 따로 확인할 수 있는 환경을 만듭니다. 둘을 함께 사용할 수 없는 것은 아니지만, 동시에 켜 두면 브라우저 테스트만으로 TUN이 작동하는지 확인하기 어렵습니다.
TUN을 켜고 로그를 확인합니다. 메인 화면에서 ‘TUN 사용’을 켠 뒤 권한 부족, 인터페이스 생성 실패, 코어 종료 또는 설정 구문 오류가 표시되는지 살펴보세요. 오류가 발생하면 먼저 스위치를 끄고 로그에서 처음 확인되는 명확한 오류부터 해결합니다.

라우팅과 DNS: 로컬 네트워크는 유지하고 아웃바운드 루프는 방지하기

TUN을 사용할 때는 기본적으로 해결해야 할 문제가 있습니다. 앱 트래픽은 터널로 들어가야 하지만, 프록시 코어가 서버에 연결하는 트래픽까지 다시 자신에게 무한히 전달되어서는 안 됩니다. 보통 클라이언트와 백엔드가 라우팅 제외나 인터페이스 바인딩 등으로 이를 처리합니다. 여러 프로그램이 동시에 트래픽을 가로채거나, 기본 경로를 수동으로 추가하거나, 사용자 지정 설정이 불완전하면 이 구조가 깨질 수 있습니다.

첫 검증 기준

트래픽 처리 방식: TUN만 켜고 시스템 프록시는 해제
활성 노드: 실제 접속으로 확인한 노드를 그대로 사용
TUN 스택 및 MTU: 현재 버전의 기본값 유지
DNS 설정: 클라이언트에서 작동이 확인된 설정을 유지하고 조회 서버는 바꾸지 않음

변수를 먼저 줄인 뒤 로그를 바탕으로 트래픽 처리, DNS 조회 또는 아웃바운드 문제를 찾습니다.

기준 테스트 통과 후 조정

로컬 네트워크 대상: 필요한 경우 192.168.0.0/16 등 사설 IP 대역에 직접 연결
프록시 서버: 연결이 TUN으로 중복 전달되지 않는지 확인
공인 IP 대상: 현재 라우팅 규칙에 따라 아웃바운드 선택
DNS 경로: DNS 서버에 연결할 수 있고 해당 아웃바운드 경로가 일치하는지 확인

여기 제시한 항목은 확인할 대상이며, 그대로 가져와 사용할 설정 키가 아닙니다. 구체적인 필드는 백엔드 버전에 따라 다릅니다.

로컬 네트워크 규칙에 192.168.0.0/16만 적는 것으로는 충분하지 않습니다. 실제 네트워크에 맞춰 10.0.0.0/8, 172.16.0.0/12 등의 주소와 IPv6 로컬 네트워크 범위도 확인하세요. 프린터, 파일 공유, 게이트웨이 관리 페이지는 필요에 따라 직접 연결해야 합니다. ‘로컬 네트워크 우회’라는 이름만 보고 모든 대상이 포함된다고 단정하지 마세요.

DNS도 별도로 확인해야 합니다. 일반 UDP/TCP 53 조회와 앱 자체의 암호화 DNS는 경로가 다릅니다. 브라우저에서 별도의 DNS 서버를 사용하면 시스템 조회 결과와 다를 수 있습니다. FakeIP를 사용 중이라면 합성 주소가 표시된다고 해서 반드시 조회 오류인 것은 아닙니다. 백엔드에서 해당 주소를 도메인에 다시 연결할 수 있는지 확인하세요. 연결할 수 없는 DNS 서버 문제를 캐시 삭제로 해결하려 하지 마세요.

트래픽 처리 확인: 브라우저 새로고침만으로 판단하지 않기

테스트할 때는 브라우저에 수동으로 입력한 프록시를 해제하고 시스템 프록시도 꺼져 있는지 확인하세요. 기존 연결이 이전 경로를 계속 사용하는 일을 막으려면 대상 앱을 완전히 종료한 뒤 다시 실행합니다. 아래 명령은 프록시를 명시한 연결과 일반 시스템 네트워크 연결을 구분하는 데 사용합니다. 테스트 도메인은 반복 가능한 HTTPS 요청을 위한 것으로, 특정 사이트가 프록시 규칙을 따르는지 판단하는 용도가 아닙니다.

# Windows PowerShell에서 실행
# 10808이 HTTP 프록시를 지원한다고 확인된 경우에만 첫 번째 명령 사용
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:10808 https://example.com

# curl이 프록시를 직접 사용하지 않도록 하고 시스템 라우팅으로 처리
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com

# 현재 인터페이스와 IPv4·IPv6 라우팅 확인
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6

# 시스템 DNS 조회 결과를 별도로 확인
Resolve-DnsName example.com

먼저 스위치를 끄고 켠 결과를 비교합니다. TUN을 끈 상태에서 프록시를 명시하지 않은 요청을 실행한 다음, TUN을 켜고 다시 시도하세요. 클라이언트 로그에 해당 앱의 새 연결이 기록되는지도 확인합니다. 한 번 성공했다고 해서 경로가 바뀌었다고 단정할 수는 없습니다.
매칭된 아웃바운드를 확인합니다. 테스트 대상이 규칙에 따라 원래 직접 연결되도록 설정되어 있을 수 있습니다. 프록시 경로를 확인하려면 프록시 사용이 명확히 지정된 대상을 선택하고 연결 기록이나 해당 수준의 라우팅 로그를 확인하세요.
IPv4와 IPv6를 나눠 테스트합니다. 필요하면 요청에 -4, -6 옵션을 각각 추가하세요. 한쪽만 성공한다면 노드가 작동하지 않는다고 단정하지 말고 해당 주소 계열의 트래픽 처리와 아웃바운드 지원을 확인합니다.
문제가 발생한 앱을 따로 테스트합니다. 웹과 명령줄 테스트를 통과한 뒤 실제로 문제가 있던 프로그램을 확인하세요. UDP 지원 여부는 TUN 백엔드, 노드 프로토콜, 서버에 따라 달라지며 HTTPS 테스트 결과만으로 판단할 수 없습니다.

가상 인터페이스를 가리키는 0.0.0.0/0 경로가 있는지만 확인하지 마세요. 자동 라우팅은 더 구체적인 분할 경로를 사용할 수 있습니다. 목적지 주소, 접두사 길이, 인터페이스를 함께 확인해 실제로 어떤 경로가 선택되는지 살펴보세요. 필요한 경우에만 로그 상세 수준을 잠시 높이고, 공유하기 전에는 노드 주소와 인증 정보, 개인 접속 기록이 담긴 내용을 삭제하세요.

자주 발생하는 문제: 권한·트래픽 처리·DNS·아웃바운드 순으로 확인

TUN을 켜자마자 오류가 나고 스위치가 다시 꺼지나요?

먼저 시스템 트레이에서 프로그램을 완전히 종료한 다음 관리자 권한으로 실행하세요. 로그에서 가장 먼저 나타나는 인터페이스, 권한 또는 코어 시작 오류를 확인합니다. 구성 요소가 없거나 설정 항목이 호환되지 않는 문제라면 해당 배포 패키지를 수정하거나 사용자 지정 TUN 설정을 되돌리세요. 관리자 권한으로 설정 구문 오류를 해결할 수는 없습니다.

시스템 프록시는 작동하는데 TUN을 켠 뒤 인터넷이 완전히 끊기나요?

다른 VPN과 네트워크 가속기를 종료하고 트래픽을 처리하는 프로그램은 하나만 남기세요. TUN을 끄고 기준 상태가 복구되는지 먼저 확인한 뒤, 켰을 때의 라우팅 변화와 서버 연결 로그를 살펴봅니다. 프록시 서버 연결까지 중복으로 처리된다면 노드를 계속 바꾸지 말고 사용자 지정 라우팅 제외 항목을 확인하세요.

연결은 되지만 도메인 이름 조회가 계속 실패하나요?

Resolve-DnsName example.com으로 시스템 DNS 조회를 따로 확인한 다음 클라이언트 DNS 로그와 DNS 서버로 향하는 아웃바운드를 점검하세요. 설정을 바로잡은 것을 확인한 경우에만 ipconfig /flushdns를 실행해 이전 캐시를 지웁니다. 브라우저에서 별도의 DNS를 사용한다면 해당 설정도 따로 확인하세요.

TUN을 켠 뒤 프린터나 사내 네트워크에 접속할 수 없나요?

사내 네트워크 대상의 실제 주소를 기록하고 사설 IP 대역 직접 연결 규칙과 네트워크 어댑터 경로를 확인하세요. 사내용 도메인은 내부 DNS가 필요할 수도 있습니다. 이런 도메인을 공용 DNS 서버에 보내면 올바른 결과를 얻지 못하는 경우가 많습니다. 설정을 바꾸기 전에 기존 구성을 저장하고, 회사 네트워크 전체를 무작정 프록시에 넣지 마세요.

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

먼저 해당 프로그램이 다른 인터페이스에 별도로 바인딩되어 있지 않은지 확인한 다음 UDP 연결 로그와 노드의 UDP 지원 여부를 살펴보세요. 작은 패킷은 계속 통과하지만 큰 패킷에서 연결이 멈추는 경우에만 MTU나 경로 MTU를 추가로 확인합니다. 근거가 없다면 MTU 변경을 첫 번째 해결책으로 삼지 마세요.

끄고 되돌리기: 트래픽 처리를 해제한 뒤 클라이언트 종료

TUN을 더 이상 사용하지 않으려면 v2rayN에서 먼저 ‘TUN 사용’을 끄고 일반 네트워크 접속이 복구됐는지 확인한 다음 클라이언트를 종료하세요. 시스템 프록시로 되돌리려면 로컬 프록시 수신이 정상인지 확인한 후 클라이언트에서 시스템 프록시를 다시 설정합니다. 이렇게 하면 가상 네트워크 경로와 앱 프록시 경로를 구분할 수 있어, 종료된 프로세스를 가리키는 시스템 프록시 주소가 남는 문제를 방지할 수 있습니다.

TUN을 정상적으로 끄고 로그에서 백엔드 종료와 라우팅 정리가 완료됐는지 확인합니다.
더 이상 사용하지 않는 시스템 프록시 설정을 해제하고 대상 앱을 다시 열어 테스트합니다.
비정상 종료 후에도 인터넷이 끊기면 클라이언트를 다시 실행해 TUN을 정상적으로 한 번 켰다 끄거나 시스템을 재부팅한 다음 남은 경로를 확인합니다.
정체를 모르는 가상 네트워크 어댑터를 바로 삭제하거나 라우팅 테이블을 전부 비우고 모든 네트워크 인터페이스를 초기화하지 마세요. 다른 업무용 네트워크 설정까지 손상될 수 있습니다.

TUN은 앱 트래픽이 클라이언트로 들어오는 방식을 처리합니다. 노드의 연결 가능 여부, 도메인 조회 방식, 규칙에 따라 선택되는 아웃바운드는 각각 별개의 문제입니다. ‘시스템 프록시 기준 확인 → TUN만 따로 검증 → 대상 앱 재테스트’ 순서로 결과를 기록하면 여러 설정을 한꺼번에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 라우팅 규칙과 DNS는 고급 설정에서 자세히 알아보고, 용어는 용어집을 참고하세요.