브라우저는 연결되는데 데스크톱 프로그램은 연결되지 않는다면, 먼저 해당 앱이 시스템 프록시를 따르는지 확인한 뒤 TUN 모드를 고려하세요. 이 글에서는 Windows용 v2rayN을 기준으로 권한 준비, 가상 네트워크 어댑터를 통한 트래픽 처리, 라우팅과 DNS의 관계, 활성화 후 확인 및 복구 순서를 설명합니다. macOS는 권한 부여와 네트워크 확장 방식이 다르므로 해당 플랫폼 빌드에서 제공하는 기능을 사용하고, Windows의 관리자 실행 절차를 그대로 적용하지 마세요.
시스템 프록시와 TUN: 트래픽을 처리하는 지점의 차이
시스템 프록시는 앱에 로컬 프록시 주소를 제공합니다. 시스템 프록시 설정을 참조하는 브라우저와 데스크톱 프로그램은 요청을 해당 주소로 보내지만, 자체적으로 연결을 만들거나 별도의 네트워크 설정을 사용하는 프로그램은 계속 인터넷에 직접 연결할 수 있습니다. 따라서 시스템 프록시를 설정했다고 해서 컴퓨터의 모든 프로그램이 프록시를 통과하는 것은 아닙니다.
TUN은 운영체제에 3계층 가상 네트워크 인터페이스를 만들고, 라우팅을 통해 조건에 맞는 IP 패킷을 처리 엔진으로 전달합니다. 앱에서 HTTP 또는 SOCKS 프록시를 직접 지원하지 않아도 트래픽을 처리할 수 있습니다. 여기서 ‘전체’란 트래픽 처리 범위를 뜻하며, 모든 연결이 원격 노드로 전송된다는 의미는 아닙니다. 최종적으로 직접 연결할지, 프록시를 사용할지, 차단할지는 라우팅 규칙에 따라 결정됩니다.
v2rayN은 관리 인터페이스이며, 프로토콜 연결과 TUN 트래픽 처리는 실제로 실행 중인 코어와 설정에 따라 달라집니다. 빌드마다 함께 제공되는 처리 방식이 다를 수 있으므로, 인터페이스에 표시된 노드 유형만으로 TUN 백엔드를 판단할 수 없습니다. VLESS와 VMess는 프록시 프로토콜이고 TUN은 트래픽이 들어오는 경로입니다. 서로 대체하는 기능이 아니며, TUN을 켜기 위해 구독의 모든 노드를 다른 프로토콜로 바꿀 필요도 없습니다.
시작 전 준비: 노드, 포트, 권한 확인
먼저 TUN을 끈 상태에서 노드가 정상적으로 작동하는지 확인하세요. 기본 프록시 연결부터 실패한다면 TUN을 켜도 문제 범위만 넓어질 뿐, 잘못된 구독 정보나 서버 주소, 보안 계층 매개변수 문제는 해결되지 않습니다. 현재 라우팅 및 DNS 설정을 캡처하고 로컬 수신 주소를 기록해 두면, 문제가 생겼을 때 원래 상태로 되돌려 테스트하기 쉽습니다.
- 노드 확인: 가져온 노드 하나를 활성 서버로 선택한 뒤 브라우저에서 실제로 접속해 보세요. 지연 시간 테스트에 한 번 성공했다고 해서 웹, DNS, UDP 연결까지 정상이라는 뜻은 아닙니다.
- 수신 포트 확인: 「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인하세요. 세부 메뉴는 버전에 따라 다를 수 있습니다. PC의 프록시 포트와 서버 포트를 혼동하지 말고, TUN을 켜기 위해 수신 주소를 모든 네트워크 인터페이스로 변경하지 마세요.
- 권한 준비: Windows에서 가상 네트워크 어댑터를 만들고 라우팅을 변경하려면 보통 관리자 권한이 필요합니다. v2rayN을 정상적으로 종료한 다음 프로그램을 마우스 오른쪽 버튼으로 클릭하고 「관리자 권한으로 실행」을 선택해 시스템 안내에 따라 권한을 부여하세요.
- 다른 네트워크 도구 점검: 처음 테스트할 때는 기본 경로를 변경하는 다른 터널이나 네트워크 가속 프로그램을 일시 중지하세요. 회사 기기가 네트워크 정책으로 관리된다면 먼저 승인을 받으세요. 엔드포인트 보안을 우회하려고 시도하지 마세요.
로컬 포트에는 반드시 사용해야 하는 공통 값이 없습니다. 위의 10808은 테스트용 예시일 뿐입니다. 현재 설정에서 다른 포트를 사용한다면 명령어, 앱 내 프록시 설정, 로그 확인에 실제 포트를 사용하세요. 일반적으로 PC의 TUN 트래픽 처리를 위해 라우터의 인바운드 포트를 열 필요는 없습니다.
v2rayN에서 TUN 켜기: 단계별 설정
버전에 따라 스위치 이름은 「TUN 활성화」 또는 「TUN 모드」로 표시될 수 있고, 설정 페이지의 메뉴 구성도 달라질 수 있습니다. 아래 안내는 기능을 기준으로 설명합니다. 메인 창의 TUN 스위치와 「설정」의 TUN 구성 항목을 찾아보세요. 특정 버전의 버튼 위치를 공통 기준으로 여기지 마세요.
- 기본 프록시 상태를 먼저 확인합니다. TUN을 끈 상태에서 현재 활성 노드로 실제 접속을 테스트하세요. 접속에 실패하면 노드와 구독 문제를 해결한 뒤 다음 단계로 진행합니다.
- 필요한 권한으로 다시 실행합니다. Windows에서는 관리자 권한으로 실행한 뒤, 백그라운드에 남은 이전 인스턴스가 로컬 포트를 사용 중인지 확인하세요. 관리자 권한으로 실행하는 인스턴스는 하나만 두고 프로그램을 두 개 동시에 실행하지 마세요.
- TUN 설정을 확인합니다. 「설정」에서 현재 버전의 TUN 설정 페이지를 여세요. 처음 사용할 때는 기본 네트워크 스택, MTU, 인터페이스 매개변수를 유지하고, 자동 라우팅 옵션이 원하는 트래픽 처리 범위에 맞는지 확인하세요. 여러 고급 설정을 한꺼번에 바꾸지 마세요.
- 라우팅 정책을 정합니다. 필요한 규칙 모드를 선택하고 LAN 직접 연결 규칙을 유지하세요. 프린터, 네트워크 저장 장치, 회사 내부망에 연결해야 한다면 관련 IP 대역과 도메인도 확인해야 합니다.
- 메인 창에서 TUN을 켭니다. 코어 로그에서 권한 부족, 설정 파싱 실패, 포트 충돌 오류가 없는지 확인한 다음, 시스템에 해당 가상 인터페이스와 라우팅 경로가 생성되었는지 살펴보세요.
- TUN만 따로 테스트합니다. TUN이 실행된 것을 확인한 뒤 v2rayN의 시스템 프록시를 해제하거나 끄고, 원래 시스템 프록시를 따르지 않던 프로그램으로 접속해 보세요. 일반 프록시 연결 성공을 TUN 작동 성공으로 착각하지 않도록 합니다.
활성화 직후 인터넷이 끊기면 우선 TUN을 끄세요. 노드, 네트워크 스택, DNS 모드를 연달아 바꾸지 마세요. 기본 상태로 되돌린 후 첫 번째 오류를 확인하고 다음 변경 사항을 결정하세요. 가상 네트워크 어댑터가 보인다는 것은 인터페이스 생성에 성공한 적이 있다는 뜻일 뿐, 처리 엔진이 계속 실행 중이라는 의미는 아닙니다.
DNS와 라우팅: 트래픽 처리 경로와 이름 확인 경로를 함께 점검하세요
앱은 도메인에 접속할 때 보통 먼저 DNS로 IP 주소를 확인한 다음 대상에 연결합니다. TUN이 연결을 처리한다고 해서 모든 도메인 조회까지 같은 경로를 거치는 것은 아닙니다. 일반 DNS는 UDP 또는 TCP 53번 포트를 주로 사용하지만, 앱에 내장된 암호화 DNS는 HTTPS로 전송될 수 있습니다. 53번 포트 요청만 처리했다는 이유로 브라우저의 DNS 경로까지 바뀌었다고 판단할 수는 없습니다.
DNS 확인 항목
- 시스템 DNS 조회
- 현재 네트워크 어댑터의 DNS 출처와 클라이언트의 트래픽 처리 설정 확인
- 상위 DNS 서버 연결
- DNS 서버가 아직 연결되지 않은 프록시에 의존하는지 확인
- 앱 내 DNS 조회
- 브라우저의 보안 DNS는 시스템 설정을 따른다고 가정하지 말고 별도로 확인
- 캐시 영향
- 설정 변경 후 새 연결로 다시 테스트하고, 필요하면 시스템 캐시를 비우세요
시스템 DNS, 브라우저의 DNS, 클라이언트 DNS를 한꺼번에 바꾸지 마세요. 한 번에 하나씩 변경하고 결과를 확인하세요.
라우팅 확인 항목
- LAN
- 실제 네트워크 대역에 맞춰 직접 연결을 유지하세요. 예: 192.168.1.0/24
- 원격 연결
- 노드 서버로 나가는 연결이 다시 TUN 처리 경로에 들어가지 않도록 설정
- IPv6
- IPv4만 테스트하지 말고 트래픽 처리 및 분기 범위 확인
- 규칙 우선순위
- 앞쪽 규칙이 대상 연결에 먼저 적용되는지 확인
대역 예시는 공통 설정이 아닙니다. 내부 네트워크에서 다른 주소를 사용한다면 실제 라우팅과 네트워크 구성에 맞추세요.
원격 노드의 도메인을 사용하는 경우 DNS 조회 루프도 방지해야 합니다. DNS 서버는 프록시를 통해서만 접속할 수 있는데 프록시 연결을 만들려면 먼저 노드 도메인을 확인해야 한다면, 시작 단계에서 멈출 수 있습니다. 클라이언트에서 제공하는 적절한 기본 설정을 사용해 시작에 필요한 도메인을 먼저 조회할 수 있도록 하세요. 모든 DNS 요청을 임의로 하나의 아웃바운드 경로에 강제하지 마세요.
일부 설정은 FakeDNS 또는 fake-ip와 같은 방식으로 도메인을 합성 주소에 임시 매핑한 뒤 처리 엔진에서 실제 대상으로 복원합니다. 이런 주소는 다른 도구에서 바로 접속할 수 없을 수 있으며, 모드를 바꾸면 이전 DNS 캐시 때문에 잠시 문제가 생길 수도 있습니다. 현재 코어가 해당 기능을 지원하는지, 설정과 어떻게 연동되는지 확인하기 전에는 튜토리얼에 나왔다는 이유만으로 켜지 마세요.
- 도메인이 조회되지 않음: 노드를 바꾸기 전에 DNS 요청, 상위 서버 연결, 캐시부터 확인하세요.
- 도메인은 조회되지만 연결 시간이 초과됨: 라우팅 규칙 적용, 노드의 아웃바운드 연결, 대상 프로토콜 지원을 확인하세요.
- LAN 이름만 조회되지 않음: 내부 DNS, 검색 도메인, LAN 직접 연결 규칙을 확인하세요.
- 일부 프로그램만 문제 발생: 해당 프로그램의 프록시, 암호화 DNS, 네트워크 인터페이스 바인딩 설정을 확인하세요.
활성화 후 확인: 스위치 상태만으로 판단하지 마세요
확인은 세 가지로 나눠야 합니다. 일반 프록시가 작동하는지, TUN이 대상 프로그램의 연결을 받는지, 해당 연결이 예상한 아웃바운드 경로에 매칭되는지 확인하세요. 시스템 프록시를 끈 상태에서 대상 프로그램을 테스트한 뒤 로그를 확인합니다. 규칙에서 직접 연결을 지정했다면 외부 IP 주소가 바뀌지 않아도 정상일 수 있습니다.
| 확인 항목 | 테스트 방법 | 확인할 내용 |
|---|---|---|
| 일반 프록시 기준 테스트 | TUN을 끄고 로컬 프록시를 명시해 같은 대상에 접속 | 노드, 수신 포트, 원격 연결 문제부터 확인 |
| TUN만으로 트래픽 처리 확인 | TUN을 켜고 시스템 프록시를 끈 다음 같은 대상에 접속 | 로그에서 대상 연결과 예상한 아웃바운드 경로가 나타나는지 확인 |
| LAN 접속 | 정상 작동이 확인된 라우터 관리 주소나 내부 서비스에 접속 | 내부망 직접 연결 규칙이 포괄적인 규칙에 덮이지 않았는지 확인 |
| DNS 및 듀얼 스택 | 도메인 조회 결과를 확인하고 IPv4와 IPv6 연결을 각각 살펴보기 | 한 주소 체계만 확인한 뒤 모두 정상이라고 판단하지 않기 |
| UDP를 사용하는 앱 | 실제로 UDP를 사용하는 기능을 테스트 | TCP 웹 접속에 성공해도 UDP 아웃바운드 연결이 된다는 뜻은 아닙니다 |
Windows에서는 아래 명령어로 라우팅 및 DNS 조회 결과를 확인할 수 있습니다. 프록시 테스트 명령은 로컬 10808 포트에서 SOCKS 서비스를 제공해야 합니다. 포트나 프로토콜이 다르면 현재 수신 설정에 맞게 수정하세요. 예시 대상은 명령어 사용법을 보여 주기 위한 것으로, 한 번의 접속 결과만으로 네트워크 전체를 진단할 수는 없습니다.
route print
ipconfig /all
nslookup example.com
curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/
curl.exe --noproxy "*" https://example.com/두 번째 curl 요청은 앱 계층의 프록시 설정을 우회하지만 시스템 라우팅을 우회하지 않으므로 TUN을 통과할 수 있습니다. 물리 네트워크의 직접 연결 상태를 확인하려면 먼저 TUN을 끈 뒤 실행하세요. 로그를 공유할 때는 구독 주소, 계정 식별 정보, 노드 인증 정보를 가리세요. 진단에 필요한 정보는 보통 오류 유형, 대상 연결, 규칙 적용 여부이며 전체 설정은 필요하지 않습니다.
자주 묻는 문제와 종료 후 복구
스위치를 켜자마자 꺼집니다. 어디부터 확인해야 하나요?
시작 로그에서 첫 번째 오류를 확인하세요. Windows에서는 기존 인스턴스를 종료한 뒤 관리자 권한으로 실행합니다. 그래도 실패한다면 권한 거부, 가상 인터페이스 생성 실패, 설정 파싱 오류 중 무엇인지 구분하세요. 문제를 찾는 대신 시스템 보호 기능을 계속 꺼 두지 마세요.
브라우저는 되는데 게임이나 음성 통화는 연결되지 않아요.
먼저 대상 연결이 TUN에 들어오고 예상한 규칙이 적용되는지 확인한 뒤, 노드와 서버가 해당 UDP 전달을 지원하는지 살펴보세요. 웹 접속은 주로 TCP를 확인하므로 음성 통화나 게임의 UDP 경로가 정상이라는 뜻은 아닙니다. 앱 실행기와 실제 프로세스가 서로 다른 대상에 연결할 수도 있습니다.
활성화한 뒤 프린터와 내부망 서비스를 찾을 수 없어요.
먼저 TUN을 끄고 서비스에 원래 접속할 수 있었는지 확인한 뒤, 현재 네트워크 대역, 내부 DNS, 직접 연결 규칙을 점검하세요. 서비스 검색에 브로드캐스트나 멀티캐스트가 필요할 수 있으므로 인터넷 프록시 규칙만 추가해서 해결하려 하지 마세요. 필요하다면 클라이언트에서 지원하는 방법으로 관련 인터페이스나 대역을 제외하세요.
TUN을 끈 뒤에도 인터넷에 연결되지 않으면 어떻게 하나요?
먼저 중지된 로컬 포트를 가리키는 시스템 프록시 설정을 해제한 다음 클라이언트를 정상 종료하세요. 시스템 DNS와 라우팅이 복구되었는지 확인합니다. Windows에서 DNS를 변경한 뒤에는 ipconfig /flushdns를 실행해 캐시를 비울 수 있습니다. 그래도 문제가 계속되면 네트워크에 다시 연결하거나 시스템을 재시작해 보세요. 가상 네트워크 어댑터를 모두 바로 삭제하지 마세요.
안정적으로 사용하려면 네트워크 스택을 자주 바꾸기보다 검증된 설정을 기록해 두는 편이 좋습니다. 활성 노드, 라우팅 모드, DNS 방식, 시스템 프록시 상태, 다른 터널 프로그램의 사용 여부를 적어 두세요. 문제가 생기면 기록을 참고해 설정을 하나씩 복구하는 것이 모든 매개변수를 한꺼번에 초기화하는 것보다 원인을 찾기 쉽습니다.
- 일시 중지: TUN을 끄고 가상 라우팅 경로가 제거되었는지 확인한 뒤 일반 시스템 프록시를 켤지 결정하세요.
- 완전히 종료: 더 이상 사용하지 않는 시스템 프록시 설정을 해제한 뒤 v2rayN을 종료하세요. 앱이 중지된 로컬 포트에 계속 연결하는 일을 방지할 수 있습니다.
- 문제 계속 확인: 민감 정보를 가린 오류 로그를 저장하고, 설정을 한 번에 하나씩 변경한 뒤 같은 대상으로 다시 테스트하세요.