이 글은 v2rayN에서 노드에 정상적으로 연결할 수 있지만 일부 프로그램이 시스템 프록시를 사용하지 않는 경우에 적합합니다. TUN이 트래픽을 처리하는 방식, 활성화 전 점검 항목, Windows·macOS·Linux의 권한 처리 방법, Xray 라우팅 규칙으로 직접 연결·프록시·차단 출발지를 구성하는 방법을 차례로 설명합니다.
TUN 모드와 시스템 프록시의 트래픽 처리 범위
시스템 프록시는 운영체제에 HTTP 또는 SOCKS 프록시 주소를 등록하는 방식입니다. 예를 들어 v2rayN에서 흔히 사용하는 로컬 혼합 포트는 127.0.0.1:10808입니다. 브라우저와 시스템 프록시 설정을 따르는 데스크톱 프로그램은 요청을 이 포트로 전달하지만, 직접 연결을 만들거나 고정적으로 직접 연결을 사용하거나 시스템 프록시를 읽지 않는 프로그램은 이를 우회할 수 있습니다. 따라서 시스템 프록시를 켰다고 해서 모든 프로세스의 네트워크 트래픽이 Xray 코어로 들어가는 것은 아닙니다.
TUN 모드는 가상 3계층 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 대상 트래픽을 해당 인터페이스로 보냅니다. 클라이언트는 IP 패킷을 읽어 연결 정보를 복원한 뒤 분할 라우팅 규칙으로 프록시, 직접 연결 또는 차단 여부를 판단합니다. 애플리케이션에서 프록시 주소를 따로 입력할 필요가 없으므로 게임 플랫폼, 명령줄 도구, 사용자 지정 네트워크 스택을 사용하는 프로그램도 한 번에 처리하기 쉽습니다.
두 모드는 단순한 우열 관계가 아닙니다
- 시스템 프록시: 변경 범위가 작고 켜고 끄기 쉬워 브라우저, 업무용 소프트웨어, 프록시 설정을 명시적으로 지원하는 프로그램에 적합합니다.
- TUN 모드: 더 넓은 범위의 트래픽을 처리하지만 가상 네트워크 인터페이스 생성, 라우팅 설정, 권한 상승이 필요합니다. 프록시를 개별 설정할 수 없거나 일관된 분할 라우팅이 필요한 애플리케이션에 적합합니다.
- 전체 트래픽: 트래픽이 먼저 TUN 처리 경로로 들어간다는 뜻이며, 모든 대상이 원격 프록시를 사용해야 한다는 의미는 아닙니다. 최종 출발지는 라우팅 규칙이 결정합니다.
- 로컬 루프백:
127.0.0.0/8, LAN 주소와 클라이언트 자체 연결은 올바르게 제외해야 프록시가 다시 프록시를 거치는 순환을 막을 수 있습니다.
TUN이 필요한지 판단하려면 먼저 시스템 프록시를 끄고 대상 프로그램을 테스트해 보세요. 프로그램이 시스템 프록시 전환에 전혀 영향을 받지 않지만 트래픽에 일관된 규칙을 적용해야 한다면 TUN이 더 적합합니다. 평소 브라우저만 사용한다면 ‘전체’라는 표현만 보고 가상 인터페이스와 라우팅 계층을 추가할 필요는 없습니다.
활성화 전 버전·노드·포트 점검
문제 해결은 TUN을 반복해서 전환하는 것보다 노드 사용 가능 여부부터 확인해야 합니다. 먼저 일반 시스템 프록시 모드에서 노드를 선택하고 접속 가능한 테스트 페이지를 연 다음, v2rayN 코어 로그에 인증 실패, TLS 핸드셰이크 실패, 연결 시간 초과가 없는지 확인하세요. 노드 자체가 작동하지 않으면 TUN은 문제 범위만 넓힐 뿐입니다.
다음 값은 v2rayN 7.15.x 데스크톱 환경의 점검 기준으로 활용할 수 있습니다. 세부 버전에 따라 메뉴 이름이나 자동 생성 대역이 달라질 수 있지만 포트 사용 여부, 기본 라우팅, DNS 처리 여부를 판단하는 방법은 같습니다.
- 서버 목록에서 사용 가능 여부를 확인한 VMess 또는 VLESS 노드를 두 번 클릭해 활성 서버로 설정합니다.
- 「설정」→「매개변수 설정」으로 이동해 로컬 수신 포트가 다른 프록시 프로그램과 겹치지 않는지 확인합니다. 로그에 address already in use가 표시되면 해당 포트를 사용하는 프로세스를 먼저 종료하거나 로컬 포트를 사용하지 않는 값으로 변경하세요.
- 시스템 날짜, 시간, 시간대를 정확하게 맞추세요. TLS와 Reality 연결은 정상적인 시스템 시간에 의존하므로 시간이 크게 어긋나면 핸드셰이크 단계에서 실패할 수 있습니다.
- 현재 네트워크 상태를 기록해 두세요. 사용 중인 네트워크 인터페이스, 기본 게이트웨이, DNS 주소를 포함하면 비정상 종료 후 남은 것이 라우팅인지 DNS인지 가상 인터페이스인지 판단하기 쉽습니다.
- 가상 네트워크 인터페이스를 만들거나 기본 라우팅을 변경하는 다른 네트워크 도구는 잠시 종료하세요. 두 처리 규칙이 우선순위를 놓고 충돌하는 것을 막을 수 있습니다.
v2rayN TUN 설정의 핵심 매개변수
v2rayN 7.x에서는 「설정」→「매개변수 설정」에서 TUN 관련 설정으로 이동한 뒤, 저장하고 메인 화면에서 「TUN 모드」를 활성화할 수 있습니다. 일부 버전에서는 스위치가 메인 창 상단이나 트레이 메뉴에 있지만 결과는 같습니다. TUN 인바운드를 지원하는 코어를 시작하고 가상 네트워크 인터페이스를 만든 다음 라우팅을 설정합니다.
매개변수는 한 번에 너무 많이 바꾸지 않는 것이 좋습니다. 첫 테스트에서는 자동 라우팅과 인터페이스 자동 감지를 유지하고, 실제 충돌이 있는 항목만 조정하세요. 기본 연결이 성공한 뒤 MTU, 엄격한 라우팅, DNS 정책을 차례로 조정하면 연결 이상을 일으킨 항목을 더 빠르게 찾을 수 있습니다.
기본 트래픽 처리
- 자동 라우팅
- 활성화
- 인터페이스 자동 감지
- 활성화
- IPv4 대역
- 172.19.0.1/30
- MTU
- 9000부터 테스트
대역은 일반적인 자동 설정 예시일 뿐입니다. 회사 내부망과 겹치면 사용되지 않는 사설 대역으로 변경하세요.
DNS 처리
- 원격 확인
- 프록시 사용
- 직접 연결로 확인
- 로컬 DNS
- 조회 포트
- 53
- 캐시
- 활성 상태 유지
프록시 도메인과 직접 연결 도메인은 각각에 맞는 확인 경로를 사용해 DNS 결과와 출발지 방향이 어긋나지 않도록 하세요.
엄격한 라우팅
- Strict Route
- 필요할 때 활성화
- LAN 우회
- 유지
- 기본 인터페이스
- 자동 감지
- 루프백 주소
- 처리하지 않음
엄격한 라우팅은 우회 트래픽을 줄일 수 있지만, 여러 네트워크 인터페이스·가상 머신·기업 네트워크에서는 추가 테스트가 필요합니다.
호환성 조정
- 초기 MTU
- 9000
- 장애 테스트 값
- 1500
- 보수적 테스트 값
- 1400
- 변경 단위
- 100~200
연결은 되지만 일부 페이지가 오래 로드될 때 MTU를 단계적으로 낮춰 보세요. 첫 번째 점검 항목으로 삼지는 않는 것이 좋습니다.
활성화 후 확인 절차
- 매개변수를 저장하고 메인 화면으로 돌아온 뒤, 사용 가능한 노드를 선택한 상태로 유지합니다.
- TUN 모드를 활성화하고 시스템 권한 요청을 승인한 다음 상태 표시줄에 코어가 정상 실행 중으로 표시될 때까지 기다립니다.
- 코어 로그를 확인하세요. TUN 인터페이스 생성과 라우팅 설정 정보가 보여야 하며 permission denied 또는 route add failed가 연속해서 나타나서는 안 됩니다.
- 브라우저의 수동 프록시 설정을 끈 뒤 테스트 대상에 접속해 요청이 여전히 규칙에 따라 연결되는지 확인합니다.
- 직접 연결로 지정한 도메인 하나와 프록시로 지정한 도메인 하나를 테스트해 TUN 처리와 라우팅 분할이 동시에 적용되는지 검증합니다.
Windows·macOS·Linux의 권한 차이
TUN은 네트워크 인터페이스와 시스템 라우팅을 조작하므로 일반 사용자 권한만으로는 부족한 경우가 많습니다. 세 데스크톱 플랫폼의 목적은 같지만 권한을 부여하는 방식은 다릅니다. 권한이 부족하면 스위치가 자동으로 원래 상태로 돌아가거나 가상 인터페이스가 나타나지 않거나, 인터페이스 생성 단계에서 로그에 오류가 바로 기록되는 현상이 나타납니다.
| 플랫폼 | 첫 활성화 시 핵심 사항 | 정상 결과 | 자주 발생하는 문제 |
|---|---|---|---|
| Windows | 사용자 계정 컨트롤 안내를 확인하고 v2rayN이 관리자 권한으로 네트워크 인터페이스와 라우팅을 설정하도록 허용합니다. | 네트워크 어댑터에 TUN 가상 인터페이스가 나타나고 라우팅 테이블에 해당 인터페이스를 가리키는 항목이 추가됩니다. | 권한 요청 취소, 이전 가상 인터페이스 잔존, 다른 네트워크 도구의 라우팅 사용 |
| macOS | 시스템 안내에 따라 관리자 인증 정보를 입력하고 utun 인터페이스 생성 및 라우팅 변경을 허용합니다. | 시스템에 새 utun 인터페이스가 나타나고 자동 라우팅에 따라 기본 트래픽이 해당 인터페이스로 들어갑니다. | 권한 요청 미완료, 백그라운드 코어 종료, 여러 기본 라우팅 간 우선순위 충돌 |
| Linux | 실행 중인 사용자에게 CAP_NET_ADMIN 권한이 있는지 확인하거나, 관련 코어를 통제된 상승 권한으로 시작합니다. | tun 인터페이스가 생성되고 라우팅 테이블에서 해당 기본 라우팅 또는 정책 라우팅을 확인할 수 있습니다. | /dev/net/tun을 사용할 수 없음, 권한 미부여, 네트워크 관리 서비스가 DNS 설정을 덮어씀 |
Windows 권장 작업 순서
- 이전 버전의 v2rayN 프로세스를 완전히 종료한 뒤 현재 버전을 실행해 두 코어가 동시에
10808을 수신하지 않도록 합니다. - 먼저 노드에 연결해 시스템 프록시를 테스트한 다음 TUN을 활성화하고, 권한 확인이 표시되면 승인을 완료합니다.
- 가상 인터페이스는 존재하지만 트래픽이 없으면 시스템 라우팅 정보를 열어 물리 게이트웨이를 가리키는 더 높은 우선순위의 기본 라우팅이 있는지 확인합니다.
- TUN을 종료한 뒤 가상 인터페이스와 임시 라우팅이 정리되었는지 확인하고, 그 후 관련 드라이버를 다시 설치하거나 재설정할지 결정합니다.
macOS·Linux 추가 점검
- macOS에서 여러 네트워크 서비스를 사용하는 경우 실제 외부 연결이 무선 네트워크인지 유선 네트워크인지 확인하세요. 인터페이스 자동 감지 결과가 실제 출구와 일치해야 합니다.
- Linux 데스크톱 환경에서는 NetworkManager 또는 systemd-resolved가 DNS를 관리할 수 있습니다. TUN이 라우팅을 처리하지만 도메인 연결이 실패한다면 DNS 확인 경로를 별도로 점검하세요.
- 절전 모드 진입, 네트워크 전환, 유선에서 무선으로 변경한 뒤에는 기존 기본 인터페이스가 작동하지 않을 수 있습니다. 이때 TUN을 껐다가 다시 켜 클라이언트가 출구를 재감지하도록 하세요.
- 컨테이너와 가상 머신 네트워크는 별도의 사설 대역을 사용하는 경우가 많습니다. TUN 주소와 겹치면 기본 라우팅을 더 추가하지 말고 먼저 TUN 대역을 변경하세요.
TUN 활성화 후 라우팅 테이블의 변화
새 기본 라우팅 하나로 기존 게이트웨이를 덮어쓰면 프록시 코어 자체도 TUN으로 되돌아가 순환이 발생할 수 있습니다. 실제 구현에서는 보통 물리 출구를 유지하면서 IPv4 기본 공간을 0.0.0.0/1과 128.0.0.0/1처럼 더 구체적인 두 라우팅으로 나눕니다. 접두사 길이가 더 길기 때문에 이 두 라우팅은 기존 0.0.0.0/0보다 우선하며, 일반 애플리케이션 트래픽은 TUN으로 들어가고 원격 서버로 향하는 코어 연결은 제외 규칙을 통해 실제 게이트웨이를 사용합니다.
다음은 구조를 이해하기 위한 단순화된 출력이며 모든 장치가 같은 인터페이스 이름과 게이트웨이를 사용하는 것은 아닙니다. 핵심은 ‘기존 기본 게이트웨이가 남아 있는지’와 ‘더 구체적인 처리 라우팅이 TUN을 가리키는지’라는 두 가지 특징을 확인하는 것입니다.
대상 네트워크 게이트웨이 또는 인터페이스
0.0.0.0/0 192.168.1.1
0.0.0.0/1 tun0
128.0.0.0/1 tun0
192.168.1.0/24 로컬 물리 네트워크 인터페이스
127.0.0.0/8 로컬 루프백
DNS도 라우팅 방향에 맞춰야 합니다. 도메인을 먼저 로컬 네트워크에서 확인한 뒤 연결은 프록시를 통해 나가면 해당 출구에 맞지 않는 주소를 받을 수 있습니다. 반대로 모든 DNS를 프록시로 보내면 LAN 호스트 이름을 확인하지 못할 수 있습니다. 더 안정적인 방법은 프록시 도메인을 원격으로 확인하고 LAN 및 명확한 직접 연결 도메인은 로컬에서 확인하게 하며, DNS 조회 자체도 정해진 출발지를 우회하지 않도록 하는 것입니다.
TUN과 Xray 라우팅 분할의 연동 방식
TUN은 ‘트래픽이 클라이언트로 들어오는 방식’을 해결하고, Xray 라우팅은 ‘들어온 트래픽이 어느 출발지로 나가는지’를 해결합니다. TUN을 전체 프록시 스위치로만 보면 분할 라우팅 규칙의 역할을 놓치게 됩니다. 일상적인 설정에서는 최소한 프록시, 직접 연결, 차단의 세 결과를 구분하고 우선순위가 높은 특수 규칙을 일반 규칙보다 앞에 배치해야 합니다.
예를 들어 LAN 주소와 장치 관리 페이지는 먼저 직접 연결로 처리하고, 프록시가 필요한 도메인 목록은 프록시 출발지로 보내며, 광고나 명확히 접속할 필요가 없는 도메인은 차단 출발지로 보낼 수 있습니다. 나머지 트래픽은 마지막에 기본 정책으로 처리합니다. 규칙은 순서대로 매칭되므로 앞에서 이미 일치한 연결은 뒤의 규칙을 계속 실행하지 않습니다.
권장 규칙 우선순위
- 클라이언트 자체 및 노드 주소: 코어 연결이 다시 TUN으로 들어가는 것을 막기 위해 실제 물리 출구를 통해 연결해야 합니다.
- 루프백 및 LAN:
127.0.0.0/8, 일반적인 사설 주소 대역, 로컬 장치 도메인은 보통 직접 연결로 설정합니다. - 차단 규칙: 명확히 거부해야 하는 도메인이나 프로토콜에는 block 출발지를 사용해 불필요한 연결을 줄입니다.
- 프록시 규칙: 도메인 목록, 대상 주소, 포트 또는 프로토콜로 매칭한 뒤 현재 프록시 출발지로 보냅니다.
- 기본 규칙: 마지막으로 일치하지 않은 항목을 direct로 보낼지 proxy로 보낼지 결정해 출발지가 없는 연결이 발생하지 않도록 합니다.
규칙을 변경한 뒤에는 도메인 요청과 직접 IP 요청을 각각 테스트하세요. 도메인만 실패하면 DNS와 도메인 규칙을 먼저 확인하고, 도메인과 IP가 모두 실패하면 노드·라우팅 테이블·권한을 먼저 점검하세요. 특정 LAN 장치만 접속되지 않는다면 사설 주소 대역이 실수로 프록시 출발지로 전송되고 있는지 확인합니다.
자주 발생하는 문제와 단계별 복구 방법
TUN 문제는 ‘권한 및 인터페이스, 라우팅, DNS, MTU, 분할 라우팅 규칙’ 순서로 처리해야 합니다. 한 번에 한 항목만 변경하고 조정할 때마다 연결을 다시 설정하세요. 노드 교체, DNS 변경, MTU 감소, 규칙 재배치를 동시에 하면 네트워크가 복구되어도 실제 원인을 확인할 수 없습니다.
TUN을 켠 직후 모든 네트워크가 끊기면 어떻게 하나요?
먼저 TUN을 끄고 v2rayN을 종료한 다음 물리 네트워크 인터페이스를 다시 활성화하세요. 복구 후 로그에서 권한 및 route add failed 관련 정보를 확인하고, 다른 가상 네트워크 도구가 기본 라우팅을 동시에 변경하고 있지 않은지 점검합니다.
IP에는 접속되지만 도메인을 입력하면 열리지 않나요?
대개 DNS 확인 경로 문제입니다. 「설정」→「매개변수 설정」에서 TUN의 DNS 설정을 확인하고 프록시 도메인은 프록시를 통해 확인하도록 설정하세요. 로컬 53 포트를 다른 DNS 서비스가 독점하고 있지 않은지도 확인해야 합니다.
일반 웹페이지는 열리지만 다운로드나 로그인이 계속 멈추나요?
먼저 MTU를 9000에서 1500으로 낮춰 다시 시도하고, 문제가 계속되면 1400도 테스트하세요. 조정 후 정상화된다면 현재 접속 네트워크나 중간 경로가 큰 캡슐화 패킷을 안정적으로 처리하지 못하는 것입니다.
활성화 후 라우터 관리 페이지에 접속할 수 없나요?
라우터가 속한 대역을 직접 연결에 추가하세요. 예를 들어 게이트웨이가 192.168.1.1이면 192.168.1.0/24를 direct로 지정하고 LAN 우회 옵션이 켜져 있는지 확인합니다.
클라이언트를 종료해도 네트워크가 복구되지 않나요?
v2rayN과 코어 프로세스가 모두 종료되었는지 확인한 뒤 현재 물리 네트워크 인터페이스를 사용 안 함으로 설정했다가 다시 활성화하세요. DNS가 계속 이상하면 네트워크에 다시 연결해 DHCP로 게이트웨이와 DNS를 받고, 작동하지 않는 수동 주소는 남겨 두지 마세요.
최소 문제 해결 체크리스트
- 시스템 프록시 모드에서 노드 사용 가능 여부를 확인했는가.
- TUN 가상 인터페이스가 정상적으로 생성되었고 로그에 권한 오류가 없는가.
- 기존 물리 기본 게이트웨이가 유지되고 처리 라우팅이 올바른 인터페이스를 가리키는가.
- IP로 직접 접속한 결과와 도메인으로 접속한 결과가 다른가.
- LAN, 루프백 주소, 노드 서버 주소가 올바르게 제외되었는가.
- MTU를 1500으로 낮춘 뒤 대용량 파일 전송과 로그인 요청이 정상화되었는가.
- TUN을 끄고 클라이언트를 종료한 뒤 임시 라우팅과 DNS 설정이 철회되었는가.
기본 연결이 안정된 것을 확인한 뒤 엄격한 라우팅을 단계적으로 활성화하고 DNS 규칙을 세분화하거나 분할 조건을 추가하세요. 브라우저 프록시만 필요한 환경에서는 시스템 프록시가 보통 관리하기 쉽습니다. 프록시 설정을 읽지 않는 데스크톱 프로그램이 여러 개라면 TUN과 명확한 direct·proxy·block 규칙을 함께 사용해야 제어 가능한 전체 트래픽 처리가 가능합니다.