이 글에서는 Windows 데스크톱용 v2rayN을 기준으로 설명합니다. 먼저 노드와 로컬 프록시가 정상인지 확인한 다음, 관리자 권한으로 TUN을 켜고 라우팅, DNS, 대상 앱을 점검합니다. 여기서 ‘전체 트래픽 처리’란 TUN이 받아들이는 트래픽의 범위가 넓어진다는 뜻이지, 모든 연결이 프록시를 거친다는 의미는 아닙니다. 실제 적용 범위는 라우팅 규칙, 제외 항목, IPv6 설정에 따라 달라집니다.
1. TUN과 시스템 프록시의 차이: 트래픽이 들어오는 경로와 분기 방식
시스템 프록시는 프록시 주소를 시스템 설정에 등록하고, 각 앱이 이 설정을 사용할지 결정하는 방식입니다. 브라우저는 대체로 설정을 따르지만 일부 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 자동으로 적용되지 않습니다. 따라서 브라우저에서 특정 사이트에 접속된다고 해서 다른 프로그램도 같은 프록시 경로를 사용한다고 볼 수는 없습니다.
TUN은 IP 패킷을 받는 3계층 가상 네트워크 인터페이스입니다. TUN을 켜면 클라이언트가 운영체제의 라우팅과 연동해 조건에 맞는 패킷을 TUN으로 전달합니다. 그러면 TUN을 구동하는 코어가 연결을 처리하고, 규칙에 따라 아웃바운드를 선택합니다. 모든 앱에 HTTP 프록시 포트를 열어 주는 방식은 아닙니다.
| 비교 항목 | 시스템 프록시 | TUN 모드 |
|---|---|---|
| 트래픽 유입 경로 | 앱이 로컬 프록시 주소로 직접 연결 | 운영체제가 라우팅 조건에 맞는 패킷을 가상 인터페이스로 전달 |
| 앱의 프록시 설정 지원 | 앱이 시스템 설정을 따르거나 프록시를 직접 지정해야 함 | 일반적으로 앱에 프록시 설정 기능이 없어도 사용 가능 |
| 권한 | 현재 사용자 프록시 설정 변경은 대개 관리자 권한이 필요하지 않음 | 인터페이스 생성 및 라우팅 설정에는 대개 권한 상승이 필요함 |
| 아웃바운드 선택 | 프록시 코어의 라우팅 규칙으로 결정 | 실제로 실행 중인 코어의 라우팅 규칙으로 결정 |
따라서 ‘전체’에는 적어도 두 가지 의미가 있습니다. 더 많은 앱을 프록시 처리 경로로 끌어들이는 것과, 해당 경로에 들어온 연결을 모두 프록시 아웃바운드로 보내는 것입니다. TUN은 주로 첫 번째 문제를 해결합니다. LAN 직접 연결, 대상 주소 제외 규칙, 다른 가상 네트워크 어댑터의 전용 경로에 따라 일부 연결은 TUN을 우회할 수 있습니다.
2. 시작 전 확인 사항: 노드, 코어, 로컬 포트
먼저 일반 프록시 모드가 정상 작동하는지 확인한 다음 TUN을 켜세요. TUN은 작동하지 않는 구독, 잘못된 VLESS 매개변수, 서로 맞지 않는 TLS 설정을 고쳐 주지 않습니다. 현재 노드부터 연결되지 않는다면 가상 네트워크 어댑터를 추가해도 더 많은 앱에 장애가 퍼질 뿐입니다.
- 활성 서버 확인: 서버 목록에서 연결이 확인된 항목을 선택해 활성 서버로 지정합니다. 구독 업데이트가 완료됐다는 것은 목록을 가져왔다는 뜻일 뿐, 서버에 연결할 수 있다는 의미는 아닙니다.
- 로컬 리스닝 확인: ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트와 관련 옵션을 확인하세요. 인터페이스 버전에 따라 메뉴 그룹 이름이 다를 수 있으므로 현재 화면에 표시된 항목을 기준으로 확인합니다.
- TUN을 구동하는 코어 확인: v2rayN은 클라이언트이며 단일 코어가 아닙니다. TUN 기능은 일반적으로 sing-box가 처리합니다. 일반 프록시에서 Xray를 사용한다고 해서 TUN 인바운드도 Xray가 생성하는 것은 아닙니다. 클라이언트에 필요한 코어 파일이 모두 있는지 확인하고, 시작 로그에서 실제 프로세스 정보를 살펴보세요.
- 현재 네트워크 환경 기록: 사용 중인 VPN, 사내 네트워크 도구, 가상 머신 네트워크 어댑터를 기록해 두세요. 처음 확인할 때는 기본 경로를 변경하는 소프트웨어를 여러 개 동시에 실행하지 않는 것이 좋습니다.
요점: 재현 가능한 프록시 기준 상태부터 만들기
먼저 로컬 프록시를 명시한 요청으로 노드를 확인하고, 이어서 프록시를 지정하지 않은 동일한 요청으로 TUN을 확인하세요. 같은 대상을 사용해야 ‘노드가 작동하지 않음’과 ‘트래픽이 TUN에 들어가지 않음’을 구분할 수 있습니다.
3. Windows에서 TUN 켜기: 관리자 권한, 활성화, 로그 확인
처음 설정할 때는 컴퓨터 앞에서 직접 작업하세요. 원격 데스크톱에만 의존해 라우팅을 변경하지 않는 것이 좋습니다. 네트워크가 끊기면 원격 연결도 함께 끊길 수 있습니다. 아래 단계는 메인 화면에 TUN 스위치가 있는 v2rayN을 기준으로 합니다. 사용 중인 버전에서 메뉴 위치가 다르면 매개변수 설정의 TUN 관련 화면을 확인하세요. 메뉴 이름이 버전마다 동일하다고 가정하지 마세요.
- 설정을 저장하고 클라이언트를 종료합니다. 먼저 TUN을 끈 다음 트레이 메뉴에서 v2rayN을 종료하세요. 이전 프로세스가 리스닝 포트를 계속 사용하거나 실행 상태를 유지하는 일을 방지할 수 있습니다.
- 관리자 권한으로 다시 실행합니다. v2rayN 프로그램을 마우스 오른쪽 버튼으로 클릭하고 Windows의 ‘관리자 권한으로 실행’을 선택해 시스템 권한을 허용하세요. 현재 설치 방식에 지원되는 권한 상승 방법이 있다면 권한 승인이 완료됐는지도 확인합니다.
- 활성 노드와 라우팅 모드를 선택합니다. 먼저 작동이 확인된 노드를 사용하세요. 규칙의 동작을 직접 설명할 수 있는 분기 규칙을 유지하고, 첫 테스트에서 출처를 모르는 규칙 세트를 함께 가져오지 마세요.
- 테스트를 분리하기 위해 시스템 프록시를 해제합니다. 메인 화면이나 트레이의 시스템 프록시 메뉴에서 시스템 프록시 해제를 선택하세요. 브라우저가 여전히 시스템 프록시로 접속해 TUN 미작동을 가리는 상황을 방지하기 위한 조치이며, 모든 환경에서 반드시 필요한 조건은 아닙니다.
- 메인 화면에서 TUN 스위치를 켭니다. 코어가 시작될 때까지 기다린 뒤 인터페이스 생성, 라우팅 설정, 시작 실패 관련 로그를 확인하세요. 스위치가 켜져 있다는 표시만으로 클라이언트가 상태를 기록했다고 볼 수 있을 뿐, 데이터 경로가 정상이라는 뜻은 아닙니다.
- 인터페이스를 확인하고 새 요청을 보냅니다. Windows 네트워크 어댑터 목록에 가상 인터페이스가 추가됐는지 확인한 다음, TUN으로 처리할 앱을 실행하세요. 이미 연결된 장시간 연결은 첫 테스트에 적합하지 않습니다. 연결을 끊었다가 새로 연결하세요.
관리자 권한은 인터페이스와 라우팅을 설정할 권한을 부여할 뿐, 서버의 UDP 지원 여부를 바꾸거나 모든 프로토콜 매개변수를 자동으로 호환되게 만들지는 않습니다. 로그에 지원하지 않는 필드가 표시되면 권한 설정을 더 추가하지 말고, 클라이언트가 생성한 설정과 함께 사용하는 코어가 호환되는지 확인하세요.
4. TUN 작동 확인: 브라우저 하나만으로 판단하지 않기
아래 명령은 Windows PowerShell에서 실행합니다. 첫 번째 명령은 로컬 SOCKS 리스닝 주소가 127.0.0.1:10808이라고 가정합니다. 실제 포트가 다르면 반드시 바꾸세요. curl.exe를 사용하는 이유는 실행 파일을 명시해 명령 별칭에 따른 인수 해석 차이를 피하기 위해서입니다.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/
Get-NetAdapter
route print
Resolve-DnsName example.com- 첫 번째 명령으로 노드 기준 상태를 확인합니다:
socks5h를 사용하면 대상 도메인 이름을 SOCKS 프록시 측에서 조회합니다. 로컬에서 다른 프록시 프로토콜만 열려 있다면 실제 리스닝 유형에 맞춰 명령을 조정하세요. 이 명령만으로 노드가 작동하지 않는다고 판단할 수는 없습니다. - 두 번째 명령으로 앱의 프록시 설정을 제외합니다:
--noproxy "*"를 지정하면 curl은 앱 수준의 프록시 설정을 사용하지 않습니다. 하지만 운영체제의 TUN 라우팅을 우회하지는 않습니다. TUN을 켠 뒤 이 명령으로 요청이 완료되는지 확인하세요. - 세 번째와 네 번째 명령으로 시스템 상태를 확인합니다: 가상 인터페이스의 존재 여부와 라우팅 변경 여부를 살펴보세요. TUN은 기본 경로를 분할하거나 다른 방식으로 트래픽을 처리할 수 있으므로, 기존 기본 경로가 남아 있다는 이유만으로 실패라고 판단하면 안 됩니다.
- 다섯 번째 명령으로 이름 조회를 확인합니다: 현재 시스템의 조회 결과나 오류를 확인하는 명령입니다. 브라우저 내장 암호화 DNS도 같은 경로를 사용한다고 보장하지는 않습니다.
example.com은 여기서 명령 구문을 보여 주기 위한 예시일 뿐입니다. 대상에 직접 연결할 수 있다면 요청 성공만으로 프록시 아웃바운드가 선택됐다고 볼 수 없습니다. 해당 요청의 대상 주소와 시간, 코어 라우팅 로그를 함께 살펴 어느 규칙이 적용됐는지 확인하세요. 필요한 경우 동일한 테스트 대상을 기준으로 TUN을 끈 상태와 켠 상태를 비교합니다.
요점: TUN 유입 성공과 프록시 아웃바운드 성공은 따로 확인
새 연결이 TUN에 들어오는지 먼저 확인한 다음, 로그에서 예상한 아웃바운드가 선택됐는지 확인하세요. 직접 연결 규칙이 적용됐다면 외부 IP가 바뀌지 않았더라도 가상 네트워크 어댑터가 작동하지 않는다고 단정할 수 없습니다.
5. 라우팅, DNS, UDP: 혼동하기 쉬운 세 가지 경계
TUN이 연결을 받아도 라우팅 규칙은 여전히 적용됩니다. 프린터 연결이 실패하거나 프록시 서버로 향하는 연결이 다시 TUN으로 들어와 순환하지 않도록 LAN 주소, 필요한 로컬 서비스, 프록시 서버 자체 연결에 올바른 직접 연결 또는 제외 경로를 지정해야 합니다. 우선 클라이언트가 생성한 설정을 사용하세요. 다른 곳에서 가져온 필드 하나를 현재 설정 파일에 억지로 추가하지 마세요.
| 확인 대상 | 발생할 수 있는 문제 | 확인 방법 |
|---|---|---|
| LAN 주소 | 공유 폴더, 프린터, 라우터 관리 페이지 트래픽이 실수로 프록시를 통해 전달됨 | 실제 LAN 대역을 확인하세요. 예: 192.168.1.0/24. 이는 예시이며 현재 네트워크 정보를 대신하지 않습니다 |
| DNS 요청 | 이름 조회와 접속 경로가 일치하지 않아 시간 초과가 발생하거나 현재 아웃바운드에 적합하지 않은 주소가 반환됨 | TUN의 DNS 설정과 리졸버 연결 가능 여부를 확인하고, 브라우저가 별도의 암호화 DNS를 사용하는지도 살펴보세요 |
| IPv6 | IPv4만 처리할 경우 일부 연결이 IPv6 경로로 빠져나갈 수 있음 | IPv6 주소와 라우팅, TUN 지원 범위를 함께 확인하세요. IPv4 대상 하나만 테스트해서는 안 됩니다 |
| UDP | 웹은 되지만 음성 채팅, 게임, QUIC 연결은 실패함 | TUN, 선택한 아웃바운드, 서버 경로가 해당 UDP 트래픽을 지원하는지 확인하세요 |
DNS 가로채기는 일반 DNS 요청을 코어의 리졸버로 보내는 과정에서 흔히 발생합니다. 하지만 대상 포트 53만 확인해서는 DoH 같은 암호화 DNS를 모두 파악할 수 없습니다. 앱이 HTTPS로 직접 이름을 조회하면 해당 연결은 일반 HTTPS 트래픽처럼 보입니다. 문제를 진단할 때는 ‘이름 조회를 누가 담당하는지’와 ‘조회 요청이 어느 경로로 나가는지’를 따로 기록하세요.
설정 형식도 서로 섞어 쓰면 안 됩니다. TUN은 클라이언트가 코어 기능을 구성하는 방식이지, tun이라는 범용 V2Ray JSON 최상위 필드가 아닙니다. sing-box, Xray, V2Fly는 설정 형식과 지원 범위가 서로 다릅니다. 설정을 직접 관리하기 전 로그에서 실제로 불러온 코어를 확인한 뒤 해당 코어의 필드를 살펴보세요. 기본 구조는 JSON 설정 매뉴얼을 참고하되, 코어가 다른 설정을 그대로 붙여 넣지 마세요.
- 분기 규칙을 확인할 때는 한 번에 규칙 하나만 변경하고 적용된 아웃바운드를 기록하세요.
- DNS를 확인할 때는 새로 조회하세요. 기존 캐시와 연결이 설정 변경을 가릴 수 있습니다.
- UDP를 확인할 때는 대상 앱에서 실제 세션을 사용하세요. HTTP 요청 성공으로 음성 채팅이나 게임이 되는지 대신 확인할 수는 없습니다.
6. 자주 발생하는 문제와 TUN 종료 후 복구 확인
시작 실패부터 트래픽 경로, 개별 앱 순서로 확인하세요. 문제가 발생한 시각 전후의 로그를 보관하고 권한 오류, 인터페이스 생성 실패, 주소 충돌, DNS 시간 초과, 아웃바운드 연결 오류를 중점적으로 살펴보세요. 로그를 공유하기 전에는 구독 주소, 인증 정보 등 민감한 내용을 삭제하세요.
TUN 스위치를 켠 직후 다시 꺼지나요?
먼저 코어 시작 로그를 확인하세요. 권한 부족이면 클라이언트를 종료하고 관리자 권한으로 다시 실행하세요. 설정 필드 오류라면 함께 사용하는 코어와 생성된 설정이 맞는지 확인합니다. 주소 또는 인터페이스 충돌이 표시되면 실행 중인 다른 터널을 먼저 종료한 뒤 다시 시도하세요. 인터페이스 생성을 연속해서 반복하지 마세요.
TUN을 켠 뒤 모든 사이트가 열리지 않으면 DNS부터 바꿔야 하나요?
먼저 TUN을 끄고 기존 네트워크가 복구되는지 확인한 다음, 로컬 프록시를 명시해 현재 노드를 테스트하세요. 노드가 정상이라면 TUN 로그와 라우팅을 확인하고 마지막으로 DNS를 점검합니다. 도메인 조회 시간 초과만 발생한다면 리졸버 주소와 해당 아웃바운드를 확인하세요. 노드, 라우팅, DNS를 한꺼번에 바꾸지 마세요.
웹은 되는데 게임이나 음성 채팅은 연결되지 않나요?
앱을 완전히 종료했다가 다시 연결해 이전 세션을 사용하지 않도록 하세요. 그런 다음 앱에 직접 연결 규칙이 적용되는지, 서버 경로가 UDP를 지원하는지, 방화벽이 해당 프로세스를 차단하는지 확인하세요. TUN이 패킷을 받는다고 해서 원격 서버가 앱에 필요한 트래픽을 전달할 수 있는 것은 아닙니다.
v2rayN을 종료한 뒤에도 네트워크가 정상으로 돌아오지 않으면 어떻게 하나요?
클라이언트를 다시 실행해 TUN을 정상적으로 끈 다음 시스템 프록시를 해제하고 종료하세요. Windows 프록시 설정이 여전히 로컬 리스닝 주소를 가리키는지 확인하고, 가상 인터페이스와 라우팅 상태도 살펴보세요. 그래도 복구되지 않으면 작업 내용을 저장한 뒤 시스템을 다시 시작할 수 있습니다. 회사 장비라면 먼저 관리자에게 문의하고 네트워크 어댑터를 일괄 삭제하지 마세요.
안정적으로 사용하기 위해 필요한 것은 간단합니다. 검증된 노드 하나, 동작을 설명할 수 있는 규칙 세트, 작동하는 이름 조회 설정, TUN을 정상적으로 끌 수 있는 방법을 유지하세요. 클라이언트나 코어를 업데이트한 뒤에는 스위치 상태만 보는 것보다 같은 테스트를 다시 실행하는 편이 확실합니다. 브라우저만 프록시가 필요하다면 시스템 프록시로 충분한 경우가 많습니다. 프록시 설정을 따르지 않는 앱이 있을 때 TUN을 사용하세요.