서버를 가져온 뒤 브라우저에서는 연결되지만 터미널이나 다른 앱에서 시스템 프록시를 사용하지 못하는 경우에 적합합니다. 아래에서는 Windows 데스크톱 환경을 기준으로 노드 확인, 관리자 권한으로 실행, TUN 활성화, 라우팅 및 DNS 점검 순서로 설명하고, 비활성화 후 복구 방법도 안내합니다. TUN은 트래픽을 처리하는 범위를 넓히지만, 프록시를 사용할지는 라우팅 규칙에 따라 달라집니다.
TUN과 시스템 프록시: 진입점은 다르지만 트래픽 분기는 그대로
시스템 프록시는 앱에 127.0.0.1:10808 같은 로컬 프록시 주소를 제공합니다. 앱이 이 설정을 읽어야 요청을 프록시로 보낼 수 있습니다. 브라우저는 대체로 시스템 프록시를 사용할 수 있지만, 명령줄 프로그램은 환경 변수나 별도의 프록시 옵션이 필요할 수 있습니다. 따라서 브라우저에서는 접속되는데 터미널에서는 안 된다고 해서 반드시 노드가 끊긴 것은 아닙니다.
TUN은 3계층 가상 네트워크 인터페이스입니다. 시스템 라우팅은 조건에 맞는 IP 패킷을 이 인터페이스로 보내고, TUN을 담당하는 구성 요소가 연결을 처리해 아웃바운드를 선택합니다. 앱은 HTTP나 SOCKS 프록시를 이해할 필요가 없습니다. v2rayN은 설정 및 관리 인터페이스이며, 실제 패킷 수신과 해석, 전달은 실행된 커널 구성 요소가 담당합니다. 일반적인 버전은 sing-box 관련 구성 요소로 TUN을 구현합니다. 구체적인 내용은 현재 버전의 로그를 확인하세요. TUN을 켠다고 해서 Xray가 자체적으로 가상 네트워크 어댑터를 만드는 것은 아닙니다.
| 비교 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 트래픽 처리 진입점 | 로컬 HTTP 또는 SOCKS 수신 포트 | 가상 네트워크 어댑터와 시스템 라우팅 |
| 앱 호환성 | 앱에서 프록시 설정을 읽거나 직접 설정해야 함 | 대개 앱에서 프록시를 설정할 필요 없음 |
| 권한 | 일반 사용자 권한으로 설정 가능 | 인터페이스와 라우팅을 변경하려면 보통 관리자 권한 필요 |
| UDP 트래픽 | HTTP 시스템 프록시만으로는 처리할 수 없음 | 처리할 수 있지만 아웃바운드와 서버도 UDP를 지원해야 함 |
| 전체 트래픽의 프록시 여부 | 앱 설정과 라우팅 규칙에 따라 다름 | 처리 범위와 라우팅 규칙에 따라 다름 |
판단 기준: 먼저 앱에 TUN이 필요한지 확인
브라우저에서만 프록시가 필요하다면 먼저 시스템 프록시를 사용하세요. 터미널, 게임 또는 다른 앱에서 프록시를 설정할 수 없을 때 TUN을 테스트하면 됩니다. TUN을 켜도 직접 연결 규칙은 유지하세요. 트래픽을 가로챈다는 것이 모든 연결을 원격 노드로 보내야 한다는 뜻은 아닙니다.
시작 전 확인: 노드, 권한, 로컬 포트
먼저 v2rayN에서 연결이 확인된 서버를 선택하세요. 구독은 서버 설정을 배포하는 방식이고, VMess와 VLESS 등은 노드에서 사용하는 프로토콜이며, TUN은 로컬 트래픽의 진입점입니다. 서로 대체할 수 있는 개념이 아닙니다. 원래 연결되지 않는 노드는 TUN으로 바꿔도 연결되지 않습니다.
- 메인 화면의 서버 목록에서 대상 서버를 선택한 뒤 마우스 오른쪽 버튼 메뉴에서 활성 서버로 지정하세요. 먼저 시스템 프록시를 사용해 평소 안정적으로 접속되는 HTTPS 페이지를 열어 봅니다.
- 「설정」→「매개변수 설정」을 열고 로컬 수신 포트를 확인해 두세요. 버전에 따라 탭이나 항목 이름이 달라질 수 있으므로 현재 화면에 표시된 값을 기준으로 합니다. 아래의
10808은 예시입니다. - 시스템 라우팅을 처리 중인 다른 VPN이나 가상 네트워크 어댑터 도구는 잠시 종료하세요. 일반 네트워크 어댑터는 그대로 두고 시스템 장치를 한꺼번에 비활성화하지 마세요.
- 작업 중인 내용을 저장한 뒤 트레이의 백그라운드 프로세스를 포함해 v2rayN을 종료하세요. 프로그램을 마우스 오른쪽 버튼으로 클릭하고 「관리자 권한으로 실행」을 선택한 다음 시스템 권한 확인 창에서 승인합니다.
로컬 진입점 기록
- 수신 주소
- 127.0.0.1
- 예시 포트
- 10808, 실제 설정값 확인
- 확인 방법
- 먼저 시스템 프록시로 HTTPS 연결 테스트
- LAN 연결
- 로컬 TUN 사용 시 활성화 불필요
TUN을 켜려고 수신 주소를 모든 네트워크 어댑터로 변경하지 마세요.
TUN 시작 설정 기록
- 실행 권한
- Windows 관리자 권한
- 초기 라우팅
- 현재 작동하는 트래픽 분기 방식 유지
- 초기 MTU
- 현재 버전의 기본값 유지
- 로그에서 확인할 항목
- 인터페이스 생성, 라우팅 설정, DNS 오류
재현 가능한 기준 상태를 먼저 만든 뒤 네트워크 설정을 하나씩 변경하세요.
관리자 권한으로 실행해도 구성 요소가 없다는 메시지가 표시되면 설치 파일이 제대로 압축 해제되었는지, 보안 프로그램이 커널 파일을 격리했는지, 로그에 표시된 파일 경로가 실제로 있는지 확인하세요. 출처가 불분명한 곳에서 이름이 비슷한 드라이버 파일을 내려받지 마세요. 재설치가 필요하다면 이 사이트의 다운로드 페이지에서 운영체제에 맞는 설치 파일을 선택하세요.
TUN 켜기: 트래픽 진입점은 한 번에 하나씩 변경
v2rayN은 버전에 따라 메뉴 위치가 다릅니다. 일반적으로 메인 창 하단의 「TUN 활성화」 스위치에서 켤 수 있으며, 관련 옵션은 「설정」→「매개변수 설정」의 TUN 설정 영역에 있습니다. 현재 버전에서 TUN 설정이 별도 메뉴로 제공된다면 같은 이름의 메뉴를 선택하세요. 다른 버전의 화면을 따라 현재 버전에 없는 항목을 수정하지 마세요.
- 활성 서버를 확인하세요. 테스트 중 다른 연결을 사용하지 않도록 메인 화면에서 선택된 서버와 로그의 아웃바운드 설정을 확인합니다.
- 시스템 프록시를 해제하세요. 시스템 프록시 메뉴에서 「시스템 프록시 해제」를 선택하고 브라우저에 직접 설정한 프록시도 잠시 끕니다. 그래야 이후 테스트에서 이전 로컬 프록시가 아니라 TUN을 확인할 수 있습니다.
- TUN 기본 설정을 유지하세요. 처음부터 네트워크 스택, MTU, 라우팅 모드, DNS를 동시에 바꾸지 마세요. 기본 설정을 사용하면 현재 버전의 구성 생성 방식과 호환성을 유지하기 쉽습니다.
- 「TUN 활성화」를 켜세요. 커널이 시작될 때까지 기다린 뒤 가상 인터페이스 생성이나 라우팅 설치 관련 로그가 나오는지 확인합니다. 바로 종료되면 스위치를 반복해서 켜고 끄지 말고 첫 오류부터 해결하세요.
- 새 연결을 만드세요. 열려 있던 웹 페이지 탭이나 터미널 연결을 닫고 다시 접속합니다. 이미 연결된 장시간 연결은 설정을 전환해도 즉시 새 경로로 바뀌지 않을 수 있습니다.
원격 노드 주소까지 TUN으로 다시 보내지 마세요. 관리 프로그램은 보통 인터페이스 바인딩이나 우회 라우팅으로 루프를 방지하지만, 여러 네트워크 도구를 동시에 실행하면 이 설정이 꼬일 수 있습니다. 로그에서 같은 노드 주소로의 연결이 반복되고 시간 초과와 트래픽 증가가 동반되면 TUN을 끈 뒤 라우팅 충돌을 확인하세요.
DNS 설정: 이름 해석 실패와 연결 실패를 구분
DNS는 도메인 이름을 IP 주소로 변환하고, 라우팅은 연결을 보낼 경로를 결정합니다. TUN이 트래픽을 처리한다면 DNS 요청도 사용할 수 있는 경로가 있어야 합니다. 원격 DNS는 프록시를 거쳐야 하는데 프록시 노드의 도메인은 해당 원격 DNS로만 해석할 수 있다면, 시작 단계에서 의존성 순환이 발생할 수 있습니다.
- 노드 도메인 이름 해석: 시작할 때 사용할 수 있는 DNS 경로를 확보해야 합니다. 구독에 포함된 서버 도메인을 임시 IP로 함부로 바꾸지 마세요. 인증서 검증이나 서버 설정에 원래 도메인이 필요할 수 있습니다.
- 직접 연결 도메인 해석: DNS 결과가 직접 연결 경로와 맞아야 합니다. 특히 사내 네트워크 서비스, 프린터, 사내 도메인에 유의하세요.
- 프록시 연결 도메인 해석: 원격 DNS 서버에 프록시를 통해 접속하도록 설정했다면 먼저 노드 연결이 가능한지 확인해야 합니다.
- 브라우저의 보안 DNS: 브라우저가 자체적으로 암호화 DNS를 사용할 수 있으므로 브라우저와 터미널의 결과가 다르다고 해서 시스템 DNS 캐시가 손상된 것은 아닐 수 있습니다.
「설정」→「DNS 설정」 또는 현재 버전의 「매개변수 설정」에 있는 DNS 영역에서 먼저 기존 값을 기록한 뒤 직접 연결 및 원격 DNS 관련 옵션을 확인하세요. 항목은 커널과 버전에 따라 다르므로 별도 커널용 JSON 조각을 그래픽 인터페이스의 임의 입력란에 그대로 붙여 넣지 마세요. 처음 설정할 때는 해당 버전의 기본 구성을 우선 사용하세요.
# Windows PowerShell: 네트워크 어댑터 상태 및 DNS 설정 확인
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-DnsClientServerAddress -AddressFamily IPv4
# 시스템 DNS 경로를 확인합니다. 점검할 도메인으로 바꾸세요.
Resolve-DnsName example.com
# DNS 설정 변경 후 Windows DNS 캐시 비우기
ipconfig /flushdnsResolve-DnsName은 시스템 DNS 경로를 확인하는 명령이며 브라우저 내장 DNS 확인 결과를 보여 주지는 않습니다. 캐시를 비운 뒤에는 새 연결을 만들고 필요하면 테스트 앱을 재시작하세요. 주소는 확인되는데 HTTPS 연결이 시간 초과되면 DNS를 계속 바꾸기보다 노드, 라우팅, 방화벽을 점검하세요.
트래픽 처리 확인: 인터페이스, 라우팅, 앱을 교차 점검
스위치가 켜진 것만으로는 충분하지 않습니다. 켜기 전후의 네트워크 인터페이스와 라우팅을 비교하고, 프록시가 설정되지 않은 터미널에서 요청을 보낸 다음 v2rayN 로그를 확인하세요. 가상 인터페이스 이름과 인덱스는 버전과 로컬 환경에 따라 달라집니다. 특정 이름의 어댑터만 찾지 마세요.
# Windows PowerShell: IPv4 라우팅 및 인터페이스 인덱스 확인
Get-NetRoute -AddressFamily IPv4 |
Sort-Object InterfaceIndex, DestinationPrefix |
Format-Table DestinationPrefix, NextHop, InterfaceIndex, RouteMetric
# 현재 터미널에 프록시 환경 변수가 적용되어 있는지 확인
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
# curl에서 명시적 프록시를 사용하지 않고 새 HTTPS 연결 테스트
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/여기서 --noproxy "*"는 curl이 앱 수준의 프록시 설정을 사용하지 않게 할 뿐, 운영체제의 TUN 라우팅을 우회하지 않습니다. 규칙에 따라 테스트 도메인이 직접 연결로 지정되어 있다면 명령이 성공해도 현재 경로가 작동한다는 것만 확인할 수 있으며 원격 노드를 거쳤다는 뜻은 아닙니다. 프록시 아웃바운드를 테스트하려면 실제로 접속할 필요가 있고 프록시 규칙이 적용되는 대상을 선택한 뒤 연결 로그에서 아웃바운드를 확인하세요.
| 관찰 결과 | 우선 확인할 원인 | 다음 단계 |
|---|---|---|
| 새 인터페이스가 없고 시작 로그에 권한 오류가 표시됨 | TUN 생성 실패 | 백그라운드 프로세스를 종료한 뒤 관리자 권한으로 다시 실행 |
| 인터페이스는 있지만 대상 연결 관련 로그가 없음 | 라우팅이 적용되지 않았거나 규칙에서 대상이 제외됨 | 인터페이스 라우팅, 제외된 네트워크 대역, 다른 VPN을 확인 |
| 도메인 이름 해석은 실패하지만 노드 연결은 가능 | DNS 설정 또는 해석 경로에 문제 발생 | DNS 서버, 도메인 규칙, 브라우저 보안 DNS 확인 |
| 웹 페이지는 열리지만 UDP 앱은 실패 | UDP 아웃바운드 기능 또는 규칙이 맞지 않음 | 노드와 서버의 UDP 지원 여부를 확인한 뒤 방화벽 점검 |
| 작은 요청은 정상인데 대용량 파일 전송이 멈춤 | MTU 또는 네트워크 경로 호환성 문제일 수 있음 | 현재 값을 기록한 뒤 MTU를 낮춰 단독 테스트 |
판단 기준: 웹 페이지가 열리는지만 보지 말고 로그에서 아웃바운드 확인
테스트할 때 대상 도메인, 테스트 시간, 로그의 아웃바운드를 기록하세요. 연결에 성공했더라도 직접 연결 규칙이 적용된 경우와 프록시 규칙이 적용된 경우는 결과가 다릅니다. 속도와 안정성을 논하기 전에 실제 경로부터 확인하세요.
MTU가 의심된다면 기존 값을 기록한 뒤 TUN 설정의 MTU만 1400으로 바꿔 비교 테스트하고 TUN을 다시 시작하세요. 이 값은 문제 해결을 위한 출발점일 뿐 모든 네트워크에 최적인 값은 아닙니다. 개선되지 않으면 원래 값으로 되돌리세요. DNS, 네트워크 스택, 노드를 함께 바꾸면 어떤 변경이 영향을 줬는지 판단하기 어렵습니다.
자주 묻는 질문과 비활성화 후 네트워크 복구
TUN 활성화를 눌렀는데 스위치가 바로 꺼지는 이유는 무엇인가요?
먼저 로그를 열어 이번 시작 과정에서 가장 먼저 발생한 오류를 찾으세요. 권한 부족이면 모든 v2rayN 프로세스를 종료한 뒤 관리자 권한으로 실행합니다. 구성 요소가 없으면 설치 폴더와 격리 기록을 확인하고, 설정을 읽지 못하는 오류라면 방금 바꾼 TUN 설정을 우선 되돌리세요. 오류를 확인하지 않고 버튼만 반복해서 누르지 마세요.
TUN을 켜도 시스템 프록시를 활성화해야 하나요?
처음 테스트할 때는 시스템 프록시를 해제해 두 설정이 혼동되지 않게 하세요. TUN이 정상적으로 트래픽을 처리하면 일반 앱에서 로컬 프록시를 추가로 설정할 필요가 없는 경우가 많습니다. 특정 앱에 별도 프록시 설정이 필요하다면 따로 설정할 수 있지만, 테스트할 때는 어떤 진입점을 사용하는지 구분해야 합니다.
웹 페이지는 열리지만 사내 네트워크와 프린터에 연결되지 않으면 어떻게 하나요?
현재 트래픽 분기 설정에서 LAN 대상이 직접 연결되는지 확인하세요. 대표적인 사설 IPv4 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16입니다. 사내 도메인에는 내부 DNS가 필요할 수도 있습니다. 실제 주소와 회사 네트워크 요구사항을 확인한 뒤 규칙을 추가하세요. 회사 네트워크 전체를 원격 아웃바운드로 무작정 보내지 마세요.
IPv4는 정상인데 일부 웹사이트에서 연결이 멈춥니다. IPv6 문제일까요?
같은 대상을 지정해 curl.exe -4 -I https://example.com/과 curl.exe -6 -I https://example.com/을 각각 실행해 결과를 비교하고 IPv6 라우팅과 DNS 응답을 확인하세요. IPv6 경로가 실패한다면 TUN의 처리 범위, DNS 정책, 실제 네트워크 지원이 서로 맞도록 조정하세요. 한 번 연결이 멈췄다는 이유만으로 시스템 IPv6를 영구적으로 끄지 마세요.
v2rayN을 종료했는데도 인터넷이 끊겼습니다. 어떻게 복구하나요?
v2rayN을 다시 열어 먼저 「TUN 활성화」를 끄고, 시스템 프록시를 해제한 다음 프로그램을 정상 종료하세요. Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소가 남아 있지 않은지 확인합니다. 그래도 복구되지 않으면 현재 네트워크를 다시 연결하거나 시스템을 재시작하세요. 모든 네트워크 어댑터와 기본 라우팅을 바로 삭제하지 마세요.
평소에는 TUN을 먼저 끄고 프로그램을 종료하세요. 그래야 관리 프로그램이 임시 인터페이스와 라우팅을 정리할 수 있습니다. 절전 모드 해제, Wi-Fi 전환, 회사 VPN 연결 후에만 문제가 발생한다면 발생 조건을 기록하고 TUN을 재시작해 다시 확인하세요. 네트워크가 바뀌면 물리적 출구도 달라지므로 기존 인터페이스 바인딩과 연결을 새로 설정해야 할 수 있습니다.
- 문제를 문의하기 전에 v2rayN 버전, Windows 버전, TUN 관련 커널 버전, 최초 오류 발생 시간을 기록하세요.
- 재현 절차를 기록하세요. 시스템 프록시 해제 여부, 다른 VPN 종료 여부, 실패한 도메인 또는 앱을 함께 적습니다.
- 로그를 공유하기 전에 구독 주소, 사용자 식별 정보, 비밀번호, 노드 인증 정보를 삭제하고 오류 유형과 필요한 네트워크 상태만 남기세요.
클라이언트 및 플랫폼 선택
기기 운영체제에 맞는 v2rayN 설치 파일을 선택하세요. 설치 후 노드와 시스템 프록시가 정상적으로 작동하는지 확인한 다음 이 문서에 따라 TUN을 활성화합니다. 구독을 처음 가져오고 서버를 선택하는 방법은 사용 설명서를 참고하세요.