V2Ray 설정 가이드: 설치부터 라우팅과 TUN까지

1단계 · 기본 개념 익히기

핵심 개념과 트래픽 흐름

인터페이스, 코어, 서버를 구분하세요

설정을 시작하기 전에 클라이언트를 두 부분으로 나눠 이해하세요. 그래픽 인터페이스는 서버, 구독, 규칙을 관리하고, 프록시 코어는 설정을 읽어 로컬 포트를 열고 연결을 처리하며 출구를 선택합니다. 창이 열린다는 것은 인터페이스가 정상이라는 뜻일 뿐, 코어가 실행 중이라는 의미는 아닙니다. 연결이 되는지 확인하려면 트레이 아이콘이나 스위치 색상만 보지 말고 실행 로그, 로컬 포트의 리스닝 상태, 실제 접속 결과를 차례로 확인하세요.

V2Ray는 Project V 프록시 생태계의 기술 체계이며, V2Fly는 관련 코어 개발을 이어가고 Xray는 별도의 코어 발전 경로를 따릅니다. v2rayN은 여러 코어를 버전에 따라 사용할 수 있는 데스크톱 GUI 클라이언트입니다. v2rayNG는 주로 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트 이름과 프로토콜 이름은 서로 다르며, 같은 인터페이스에서 설정한 내용도 모든 코어에서 동작하는 것은 아닙니다.

요청 흐름에 따라 설정 위치 파악하기

일반적인 흐름은 앱이 요청을 보내고, 시스템 프록시나 가상 네트워크 인터페이스가 트래픽을 로컬 진입점으로 전달한 뒤, 코어가 라우팅 규칙에 따라 직접 연결·프록시·차단 중 하나를 선택하는 방식입니다. 선택된 출구가 연결을 처리하고 원격 서버는 프록시 출구의 서버 역할을 합니다. 클라이언트를 설치해도 원격 서비스가 자동으로 제공되지는 않습니다. 구독 주소, 서버 정보와 이용 권한은 사용자가 적법한 방법으로 확보해야 하며, 이 사이트의 다운로드 페이지는 클라이언트 다운로드 경로를 제공합니다.

‘노드’는 보통 GUI 클라이언트에서 서버 연결 매개변수 묶음을 가리키며, 주소, 포트, 프로토콜, 인증 정보와 전송 보안 설정을 포함합니다. VMess, VLESS, Trojan, Shadowsocks는 프로토콜 이름이고 WebSocket, gRPC 등은 전송 방식입니다. TLS와 REALITY는 전송 보안과 관련됩니다. 매개변수는 서버 설정에 맞춰 함께 구성해야 합니다. 두 노드에 모두 VLESS라고 표시되어도 보안 설정을 임의로 바꿔 끼울 수는 없습니다.

항목	역할	흔한 오해
로컬 진입점	앱에서 전달된 연결을 받음	로컬 리스닝 포트를 서버 포트로 착각
프록시 출구	원격 서버에 연결해 트래픽을 전달	인터페이스를 열면 연결된 것으로 착각
라우팅 규칙	연결이 처리될 경로를 선택	전역 프록시를 모든 앱의 트래픽 처리로 오해
DNS	도메인을 해석하고 관련 정책을 판단	모든 DNS 조회 실패를 노드 문제로 판단

최소한의 검증 절차 만들기

처음에는 목표를 하나만 정하세요. 선택한 서버를 통해 앱 하나에서 요청 하나를 보내는 것입니다. 다른 프록시 프로그램을 끄고 기기 시간이 정확한지 확인한 다음 서버를 선택하고 시스템 프록시를 켜세요. DNS, 라우팅 템플릿, TUN은 동시에 변경하지 마세요. 최소 경로가 검증되어야 이후 설정을 비교할 기준이 생깁니다. 여러 항목을 한꺼번에 바꾸면 문제가 어느 계층에서 발생했는지 파악하기 어렵습니다.

검증 결과는 세 가지로 나눠 보세요. 코어가 시작되지 않는다면 로컬 설정, 권한, 포트를 먼저 확인합니다. 코어는 시작되지만 프록시 연결이 실패하면 서버 매개변수, 구독 상태와 네트워크 연결을 확인합니다. 일부 앱만 실패한다면 시스템 프록시를 따르는 앱인지, 라우팅 규칙이 어떻게 적용됐는지 살펴봅니다. 인터페이스의 지연 시간 테스트는 특정 테스트 경로의 성공 여부만 보여 줍니다. 실제 서비스 접속이나 다운로드 속도를 대신하지는 않습니다.

2단계 · 도구 선택하기

클라이언트와 설치 파일 선택

데스크톱에서는 v2rayN 우선 사용

Windows, macOS, Linux에서는 v2rayN을 우선 사용하세요. 비슷한 구독, 서버, 라우팅 관리 방식으로 일상적인 설정을 처리할 수 있습니다. 선택할 때는 운영체제, 프로세서 아키텍처, 패키지 형식 순으로 확인하세요. 파일명이 짧거나 용량이 작다고 더 적합한 것은 아닙니다. 아키텍처나 실행 종속성이 맞지 않으면 설치, 실행, 코어 호출 단계에서 문제가 드러납니다.

Windows 다운로드에는 Desktop과 클래식 WPF 버전이 있습니다. Desktop은 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 운영체제에서 비슷한 방식으로 사용하려는 경우에 적합합니다. WPF 버전은 기존 Windows 데스크톱 인터페이스를 이어가므로 익숙한 작업 흐름을 선호하는 사용자에게 알맞습니다. 버전에 따라 메뉴 위치와 종속성이 다를 수 있으므로 특정 버전의 스크린샷을 모든 버전에 적용되는 메뉴 안내로 보면 안 됩니다.

기존 설정을 이어 쓸 필요가 없다면 Desktop 버전을 선택한 뒤 설치 파일 안내에 따라 실행 종속성을 준비하세요. WPF 버전을 안정적으로 사용 중이라면 인터페이스가 달라진다는 이유만으로 서둘러 옮길 필요는 없습니다. 버전을 바꾸기 전 필요한 정보를 내보내고 현재 설정을 기록하세요. 두 프로그램은 별도 디렉터리를 사용하게 하고, 같은 설정 디렉터리를 번갈아 쓰거나 두 코어가 같은 리스닝 포트를 동시에 사용하지 않도록 주의하세요.

플랫폼	선택할 다운로드	확인할 항목
Windows	v2rayN Desktop 또는 WPF	시스템 설정의 시스템 종류 및 실행 종속성 안내
macOS	v2rayN ARM64 또는 x64	‘이 Mac에 관하여’의 칩 또는 프로세서 정보
Android	v2rayNG, 대안은 v2flyNG	기기 아키텍처와 구독에 필요한 코어 기능
Linux	v2rayN deb 또는 rpm	배포판의 패키지 관리 체계와 프로세서 아키텍처

Android는 코어와 아키텍처에 맞춰 선택

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 동작을 확인해야 하거나 관련 설정이 이미 있다면 v2flyNG를 고려하세요. 두 클라이언트는 서로 다른 테스트 환경으로 사용할 수 있지만 동시에 연결하지 마세요. 일반적으로 시스템은 현재 사용자 공간에서 VPN 터널 하나만 허용합니다. 나중에 실행한 도구가 기존 연결을 대체할 수 있어 스위치는 켜져 있지만 실제 경로가 바뀌는 상황이 생길 수 있습니다.

대부분의 최신 Android 스마트폰은 ARM64 아키텍처를 사용합니다. 기기에서 지원되는지 확인한 뒤 arm64 패키지를 선택하세요. 아키텍처를 모르면 범용 버전을 고려하고, 설치 결과와 기기 정보를 확인하세요. 앱이 설치됐다고 해서 구독의 모든 프로토콜 매개변수를 지원하는 것은 아닙니다. 클라이언트, 코어, 서버 기능이 서로 맞아야 합니다. 지원되지 않는 필드가 있다면 범용 설치 파일을 반복해서 바꾸기보다 필요한 기능부터 확인하세요.

시스템 호환성과 설정 호환성 구분하기

macOS에서는 Apple Silicon이 ARM64, Intel 프로세서가 x64에 해당합니다. Linux에서는 해당 Debian 계열 패키지 관리 환경에 deb를, RPM 계열 환경에 rpm을 사용하세요. Linux ARM64 패키지에는 ARM64 시스템이 필요합니다. 배포판 이름이 같다는 이유만으로 x64 패키지를 설치하면 안 됩니다. 시스템 라이브러리, 데스크톱 환경, 권한 관리 차이도 실행에 영향을 줄 수 있으므로 패키지 형식을 맞추는 것은 첫 단계일 뿐입니다.

클라이언트를 선택한 뒤 운영체제, 아키텍처, 인터페이스 종류, 코어 종류를 기록해 두세요. 문제를 해결할 때 반복해서 필요한 정보입니다. 다운로드는 다운로드 센터에서 진행하고, 서로 다른 출처의 안내를 섞지 마세요. 구독에 필요한 기능이 불분명하면 제공자에게 프로토콜과 전송 매개변수를 문의하세요. 이 장의 선택 기준은 호환성과 사용 방식이지, 클라이언트 이름으로 서버 품질을 판단하는 것이 아닙니다.

3단계 · 실행 환경 준비하기

설치, 권한, 로컬 리스닝

프로그램과 코어를 안정적으로 실행하기

Windows에서는 설치 파일이나 압축을 푼 프로그램을 고정된 폴더에 둔 다음 클라이언트를 실행하세요. 압축 파일로 배포되는 경우 완전히 압축을 푼 뒤 실행해야 합니다. 압축 미리 보기 창에서 프로그램을 바로 실행하지 마세요. 설정, 로그, 코어 파일이 상대 경로를 사용할 수 있어 임시 경로에서 실행하면 설정이 사라지거나 파일을 찾지 못할 수 있습니다. 폴더 경로는 간단하게 유지하고 특별한 쓰기 권한이 필요한 위치는 피하세요.

처음 실행할 때 실행 환경이 없다는 안내가 나오면 현재 설치 파일의 요구 사항에 맞게 처리하세요. 다른 인터페이스 버전의 종속성 안내를 그대로 적용하면 안 됩니다. 필요한 환경을 설치한 뒤 다시 실행하고 로그에서 코어 시작 실패, 설정 파싱 오류, 리스닝 실패가 있는지 확인하세요. 일반적인 시스템 프록시 연결에는 클라이언트를 계속 관리자 권한으로 실행할 필요가 없습니다. 가상 네트워크 인터페이스나 서비스 설치 등 실제로 권한이 필요한 작업에서만 안내에 따라 허용하세요.

macOS에 설치할 때는 앱을 고정된 응용 프로그램 폴더로 옮기고, 처음 열 때 표시되는 안내는 운영체제의 보안 확인 절차에 따라 처리하세요. 앱 하나를 실행하기 위해 시스템 보안 기능 전체를 끄지 마세요. Linux에서 설치 후 인터페이스가 열리지 않으면 터미널에서 해당 프로그램을 실행하거나 데스크톱 실행 로그를 확인해 그래픽 종속성 문제와 프록시 코어 오류를 구분하세요. 해결 방법이 서로 다르며 구독을 다시 가져와도 시스템 라이브러리는 설치되지 않습니다.

리스닝 주소와 포트 확인하기

설정에서 로컬 혼합 리스닝 포트를 찾아 현재 값을 기록하세요. 이 가이드에서는 예시로 10808을 사용하지만 실제 값은 클라이언트에 표시된 내용을 따르세요. 혼합 진입점은 일반적으로 HTTP와 SOCKS 요청을 모두 인식하지만, 지원 범위는 클라이언트와 코어 설정에 따라 달라집니다. 우선 로컬 기기에서만 사용할 수 있도록 루프백 주소에 바인딩하세요. LAN 공유가 꼭 필요하지 않다면 LAN 연결 허용을 켜거나 모든 네트워크 인터페이스에서 수신하도록 설정하지 마세요.

로그에 포트 사용 중이라는 메시지가 있으면 권한을 계속 바꾸기보다 어떤 프로세스가 리스닝 중인지 확인하세요. 아래 명령은 연결과 리스닝 정보를 조회할 뿐 프로세스를 종료하지 않습니다. Windows에서는 리스닝 항목과 PID를 확인하고, Linux에서는 로컬 리스닝 행을 확인합니다. macOS에서는 기본 제공 포트 조회 도구를 사용하세요. 출력이 없더라도 명령 권한, 조회한 포트와 실제 설정이 일치하는지 확인해야 합니다.

# Windows PowerShell
netstat -ano | findstr :10808

# Linux
ss -lntp 'sport = :10808'

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

충돌한 프로세스가 이전 클라이언트라면 먼저 정상 종료하세요. 다른 필수 서비스라면 현재 클라이언트에서 사용 중이 아닌 포트로 변경합니다. 저장하고 코어를 다시 시작한 뒤 새 포트가 리스닝 중인지 확인하세요. 프록시를 수동으로 설정한 앱의 포트도 함께 변경해야 합니다. 자세한 확인 방법은 로컬 리스닝 포트 사용 중 문제 해결을 참고하세요. 프로세스 번호만 보고 시스템 서비스를 무작정 종료하지 마세요.

Android 최초 권한 승인

Android에서 설치 후 처음 연결하면 VPN 권한을 요청합니다. 이는 시스템 트래픽을 로컬에서 처리하기 위한 인터페이스이며 원격 서버에 연결됐다는 뜻은 아닙니다. 권한을 승인한 뒤에도 클라이언트 로그와 실제 접속 결과를 확인하세요. 설치 오류가 발생하면 아키텍처 불일치, 운영체제 버전 제한, 서명 충돌, 파일 다운로드 미완료를 먼저 구분하세요. 기존 앱을 먼저 삭제하면 기존 설정과 구독까지 함께 사라질 수 있습니다.

4단계 · 연결 정보 관리하기

구독 가져오기, 업데이트, 노드 확인

구독 주소를 구독 그룹에 추가하기

구독 주소는 클라이언트가 서버 설정을 가져오는 경로이며 접근 인증 정보가 포함되는 경우가 많습니다. 복사할 때 전체 주소를 보존하고 쿼리 매개변수를 삭제하지 마세요. 공개 게시판에 링크를 올리지도 마세요. 가져오기 전에 출처와 사용 권한을 확인하고, 복사한 내용에 공백, 줄바꿈, 따옴표, 메신저가 덧붙인 설명이 섞이지 않았는지 살펴보세요. 구독에는 읽을 수 있는 설정 내용이 필요합니다. 서비스 안내 페이지나 로그인해야 하는 관리 콘솔 주소는 사용할 수 없습니다.

v2rayN에서 구독 그룹 관리 화면을 열고 새 그룹을 만든 다음 알아보기 쉬운 이름을 적고 구독 주소를 붙여 넣어 저장하세요. 메인 화면으로 돌아가 해당 그룹의 구독을 업데이트하고 서버 목록이 추가됐는지 확인합니다. 인터페이스 버전에 따라 메뉴 이름은 조금 다를 수 있지만 순서는 같습니다. 먼저 출처를 저장하고, 내용을 가져온 뒤 서버를 선택하세요. 구독 주소를 수동 서버의 ‘주소’ 필드에 잘못 넣지 마세요.

v2rayNG와 v2flyNG에서는 구독 그룹 설정에 주소를 추가한 뒤 메인 화면으로 돌아가 구독을 업데이트할 수 있습니다. QR 코드나 클립보드로 가져오면 정적 서버 항목 하나만 추가될 수 있으며, 지속적으로 업데이트되는 구독이 만들어지는 것은 아닙니다. 가져온 뒤 그룹 정보를 확인하고 이후 관리를 구독 업데이트로 할지 수동 교체로 할지 파악하세요. 그룹 이름은 관리용일 뿐 서버 프로토콜이나 코어 동작을 바꾸지 않습니다.

업데이트 실패 시 응답 내용부터 확인하기

구독 업데이트는 보통 네트워크 요청과 내용 파싱 두 단계로 진행됩니다. 요청 시간이 초과되면 주소에 접근할 수 있는지, 현재 업데이트가 직접 연결인지 프록시를 통하는지 확인하세요. 파싱에 실패하면 응답 형식이 지원되는지 살펴봅니다. 서버에서 로그인 페이지, 오류 페이지, 사용량 안내가 반환되면 요청 자체가 성공했더라도 서버 설정으로 가져올 수 없습니다. 클라이언트에 업데이트 완료가 표시된 뒤에도 작업이 끝났다는 메시지만 보지 말고 항목 수 변화와 오류 안내를 확인하세요.

사용할 수 있는 프록시를 아직 설정하지 않았다면 우선 일반적인 직접 연결로 업데이트하세요. 현재 네트워크에서 구독 주소에 접근할 수 없고 사용할 수 있는 서버가 이미 있다면 프록시를 통한 업데이트를 시도할 수 있습니다. 아직 가져오지 않은 서버를 통해서만 구독에 접근하도록 설정하지 마세요. 시작 단계에서 의존성이 생깁니다. 업데이트 전에 사용 가능한 기존 항목을 남겨 두세요. 먼저 모두 지운 뒤 출처에 문제가 생기면 연결과 문제 해결 기준을 한꺼번에 잃게 됩니다.

서버를 선택한 뒤 실제 연결 확인하기

가져오기에 성공하면 현재 코어와 호환되는 서버 하나를 선택해 활성화하세요. 우선 실제 연결 지연 시간 테스트로 명백히 실패하는 설정을 걸러낸 뒤 브라우저나 명령줄에서 실제 요청을 확인합니다. 테스트 결과는 대상, DNS, 네트워크 경로와 시간에 따라 달라지므로 고정된 성능 지표가 아닙니다. 목록에서 가장 작은 숫자만 보고 선택하지 말고, 한 번의 실패로 구독 전체가 영구적으로 사용할 수 없다고 판단하지도 마세요.

같은 그룹의 항목 대부분이 실패하면 기기 시간, 구독 유효성, 프로토콜 지원 여부부터 확인하세요. 한 항목만 실패할 때는 해당 항목의 주소, 포트, 보안 설정과 전송 매개변수를 비교합니다. 구독에서 자동 생성된 주요 필드를 임의로 수정하지 마세요. 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 실험용 설정을 보존해야 한다면 별도의 수동 항목으로 복사해 용도를 표시하고 구독 원본과 혼동하지 않도록 하세요.

업데이트 후 활성 서버가 여전히 목록에 있는지 확인하세요. 출처 이름이 바뀌거나 항목이 삭제되면 기존 선택이 무효가 될 수 있고, 그룹 필터 때문에 목록이 비어 보일 수도 있습니다. 추가 점검은 구독 파싱 실패 및 빈 목록 점검표를 참고하세요. 이 장의 완료 기준은 구독 출처를 관리할 수 있고 활성 서버가 명확하며 실제 요청으로 연결을 확인한 항목이 하나 이상 있는 것입니다.

5단계 · 앱 트래픽 연결하기

시스템 프록시, 수동 프록시, 전역 모드

시스템 프록시로 브라우저부터 확인하기

활성 서버를 선택한 뒤 v2rayN에서 ‘시스템 프록시 자동 설정’ 또는 이에 해당하는 기능을 켜세요. 이 기능은 운영체제의 프록시 설정을 변경해 앱이 참조하도록 합니다. 앱은 이 설정을 따를지 선택할 수 있습니다. 일반적인 브라우저는 대체로 시스템 설정을 사용하지만 일부 터미널 도구, 다운로드 프로그램, 게임은 자체 네트워크 방식을 사용할 수 있습니다. 브라우저는 연결되는데 다른 앱이 실패하면 서버를 바꾸기 전에 연결 방식을 확인하세요.

‘시스템 프록시 지우기’는 보통 클라이언트가 설정한 시스템 진입점 정보를 되돌리는 기능이며 코어가 종료됐다는 뜻은 아닙니다. ‘시스템 프록시 변경 안 함’은 운영체제에 원래 설정된 값을 유지할 수 있습니다. 메뉴 세부 사항은 클라이언트 화면을 기준으로 확인하세요. 정상 종료 전에 필요하지 않은 시스템 프록시를 복원하세요. 특히 프로세스를 강제 종료하면 안 됩니다. 시스템이 계속 로컬 포트를 가리키는데 리스닝 프로그램이 중지되면 프록시를 따르는 앱은 접속할 수 없습니다.

트래픽 처리 범위와 출구 정책을 구분하기

‘전역 프록시’는 의미가 모호해 오해하기 쉽습니다. 클라이언트 라우팅에서는 보통 코어에 들어온 트래픽을 우선 프록시 출구로 보내는 뜻이며, 모든 앱의 트래픽이 코어에 들어온다는 보장은 없습니다. 시스템 프록시는 일부 앱이 진입하는 방식을 정하고, 라우팅 모드는 진입한 연결의 출구를 정하며, TUN은 트래픽 처리 범위를 바꿉니다. 서로 다른 계층의 기능이므로 ‘전역’ 버튼 하나로 모두 설명할 수 없습니다.

방식	변경되는 위치	확인할 사항
시스템 프록시	앱이 참조하는 시스템 진입점	앱이 설정을 따르는지 여부
수동 프록시	개별 앱의 프록시 주소	프로토콜, 주소, 포트가 일치하는지
전역 라우팅	코어 내부의 출구 선택	연결이 코어에 들어왔는지
TUN 트래픽 처리	시스템 네트워크 계층의 트래픽 진입점	라우팅, 권한, DNS가 함께 작동하는지

앱 하나가 HTTP 또는 SOCKS 프록시를 지원한다면 루프백 주소와 로컬 리스닝 포트를 직접 입력할 수 있습니다. 이렇게 하면 더 넓은 범위의 트래픽을 처리하도록 설정하지 않고도 해당 앱의 연결 경로를 제어할 수 있습니다. 먼저 앱이 요구하는 프로토콜을 확인한 뒤 주소를 입력하세요. 혼합 리스닝 진입점이라고 해서 모든 포트가 서로 바꿔 쓸 수 있는 것은 아닙니다. 원격 서버 주소를 일반 앱의 로컬 HTTP 프록시 주소로 입력하지 마세요.

명시적 프록시로 비교 테스트하기

아래 두 명령은 HTTP와 SOCKS 방식으로 같은 예시 사이트에 접속합니다. 포트는 현재 리스닝 설정과 맞춰야 합니다. Windows에서는 일부 터미널 환경에서 같은 이름의 명령이 다르게 동작할 수 있으므로 curl.exe를 사용하세요. socks5h는 대상 도메인을 프록시 쪽에서 처리하도록 하지만 최종 DNS 경로는 코어 설정에 따라 달라집니다. 명령 실행에 성공하면 해당 요청 경로가 작동한다는 뜻이지 모든 앱이 프록시를 사용한다는 뜻은 아닙니다.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

macOS와 Linux에서는 명령 이름을 curl로 바꿔 사용할 수 있습니다. 명시적 프록시 테스트 결과를 기록한 뒤 브라우저와 비교하세요. 명령은 성공하지만 브라우저가 실패하면 브라우저 확장 프로그램, 별도 프록시 설정, 기존 연결을 확인합니다. 둘 다 실패하면 로컬 리스닝과 프록시 출구를 다시 확인하세요. 브라우저 캐시 페이지로 연결 성공 여부를 판단하지 말고, 필요하면 새 창을 열어 방문한 적 없는 페이지에 요청하세요.

Android의 VPN 모드는 시스템 인터페이스를 통해 트래픽을 연결하며 앱별 프록시 설정도 실제 처리 범위에 영향을 줍니다. 처음 확인할 때는 테스트할 브라우저를 제외하지 말고 연결을 확인한 뒤 필요에 따라 앱 범위를 좁히세요. 이 장을 마치면 ‘앱 트래픽이 프록시에 들어오지 않는 문제’와 ‘프록시에 들어온 뒤 출구에서 실패하는 문제’를 구분할 수 있어야 합니다. 빠른 설정은 사용 가이드에서, 이상 증상은 문제 해결에서 확인하세요.

6단계 · 출구 경로 제어하기

라우팅 규칙, DNS, 분할 라우팅 확인

빈 규칙 대신 내장 모드부터 시작하기

시스템 프록시 검증을 마친 뒤 클라이언트에서 제공하는 라우팅 모드를 선택하세요. 처음에는 내장 템플릿을 사용하고 ‘직접 연결’, ‘프록시’, ‘차단’의 의미를 이해한 다음 예외를 추가하는 편이 좋습니다. 직접 연결은 기기의 네트워크로 대상에 연결한다는 뜻이지 트래픽이 코어를 전혀 거치지 않는다는 의미는 아닙니다. 차단은 일치하는 연결을 의도적으로 거부하는 것으로 연결 장애와 다릅니다. 전역 모드는 진단용 비교에 쓸 수 있지만 모든 세부 규칙을 장기간 대체할 필요는 없습니다.

규칙은 보통 순서대로 검사하며 먼저 일치한 규칙이 경로를 결정합니다. 상단의 넓은 규칙이 도메인에 먼저 적용되면 아래의 더 구체적인 규칙은 실행되지 않을 수 있습니다. 새 규칙을 추가하기 전에 대상, 원하는 출구, 배치 위치를 정리한 다음 로그를 확인하세요. 도메인, 주소 범위, 프로세스 예외를 한꺼번에 겹쳐 추가하지 마세요. 접속이 복구되더라도 어떤 규칙이 효과가 있었는지 알기 어렵습니다.

구성 예시의 적용 범위 파악하기

아래는 V2Ray / Xray 형식의 라우팅 조각 예시이며 단독 실행 가능한 전체 설정이 아닙니다. 전체 설정에 direct라는 직접 연결 출구와 proxy라는 프록시 출구가 정의되어 있다고 가정합니다. 예시는 특정 도메인과 사설 주소를 직접 연결하도록 하는 방법만 보여 줍니다. 다른 출구 태그를 사용한다면 함께 수정해야 합니다. GUI 클라이언트가 자동 생성하는 설정을 그대로 덮어쓰면 저장 시 다시 생성될 수 있습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

도메인 규칙의 domain:example.com은 해당 도메인과 하위 도메인을 일치시키는 표현이며 임의의 URL 경로를 지정하는 데는 적합하지 않습니다. 프록시 라우팅은 보통 암호화된 웹페이지의 구체적인 경로를 볼 수 없으므로 전체 URL을 도메인 규칙에 입력할 수 없습니다. 사설 주소 규칙은 LAN 서비스를 유지하는 데 유용하지만 모든 특수 용도 주소를 포함하지는 않습니다. 실제로는 클라이언트가 관리하는 완전한 템플릿을 우선 사용하고 필요한 예외만 추가하세요.

DNS는 규칙에서 활용할 수 있는 정보를 결정합니다

DNS는 도메인을 주소로 변환하며 주소 기반 규칙의 판단 조건에도 영향을 줍니다. 예시의 AsIs는 IP 규칙 일치만을 위해 도메인을 적극적으로 조회하지 않는다는 뜻이지, 전체 연결 과정에서 DNS를 전혀 사용하지 않는다는 의미는 아닙니다. 앱이 해석된 주소만 코어에 전달하면 도메인 규칙이 직접 적용되지 않을 수 있습니다. 반대로 도메인 정보만 있고 해석 결과가 없다면 일부 주소 판단에는 추가 정책이 필요합니다.

도메인 스니핑은 지원되는 트래픽에서 대상 정보를 보완할 수 있지만 모든 프로토콜의 도메인을 복원할 수 있는 것은 아니며 앱 콘텐츠를 복호화한다는 뜻도 아닙니다. 브라우저의 보안 DNS, 앱 자체 DNS, 시스템 캐시 때문에 실제 경로가 예상과 다를 수 있습니다. 문제를 확인할 때는 먼저 DNS 해석 단계와 연결 단계 중 어디서 실패했는지 확인한 뒤 해석 정책을 조정하세요. 공용 DNS로 무작정 바꿔도 잘못된 인증 매개변수나 실행되지 않는 코어는 해결되지 않습니다.

라우팅을 확인하려면 직접 연결되어야 할 대상 하나와 프록시를 거쳐야 할 대상 하나를 선택해 각각 새 요청을 보내고, 로그에서 대상과 출구 태그를 확인하세요. 웹페이지에 표시된 주소만으로는 부족합니다. 페이지가 여러 도메인을 사용할 수 있기 때문입니다. 규칙을 바꾼 뒤에는 새 연결을 만들어야 합니다. 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 한 번에 한 항목만 조정하고 변경 전후의 설정 요약을 저장해 두면 실패 시 되돌릴 수 있습니다.

7단계 · 트래픽 처리 범위 넓히기

TUN 모드, 권한, 복구

TUN이 정말 필요한지 먼저 확인하기

앱이 시스템 프록시를 따르지 않고 사용할 수 있는 수동 프록시 설정도 없을 때 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 프록시 처리 경로로 전달하므로 일반 프록시 설정으로 연결하기 어려운 여러 앱을 지원할 수 있습니다. 변경되는 것은 트래픽 진입 범위이지, 사용할 수 없는 서버나 잘못된 인증 정보, 호환되지 않는 프로토콜이 해결되는 것은 아닙니다. 일반 시스템 프록시 연결이 검증되지 않았다면 먼저 기본 연결을 해결한 뒤 이 계층을 추가하세요.

v2rayN의 TUN 기능은 버전, 실행 구성 요소, 운영체제에 따라 다르며 스위치 위치와 서비스 요구 사항도 달라질 수 있습니다. 켜기 전에 현재 코어, 로컬 포트, 라우팅 모드, DNS 설정을 기록하고 TUN을 끈 뒤 복구할 방법을 남겨 두세요. 오래된 안내에 버튼이 없다는 이유만으로 정체를 알 수 없는 코어를 조합하거나 프로그램 파일을 교체하지 마세요. 현재 설치 파일이 지원하는 기능과 화면 안내를 먼저 확인하세요.

진입점을 하나만 사용해 처음 검증하기

처음 켜기 전에 다른 프록시 프로그램과 불필요한 가상 네트워크 도구를 종료하세요. 필요하지 않은 시스템 프록시를 지운 뒤 클라이언트 안내에 따라 TUN을 켜고 필요한 권한이나 서비스를 승인합니다. 이렇게 하면 트래픽이 어느 진입점을 통과하는지 파악하기 쉽습니다. 일부 환경에서는 두 진입점을 함께 사용할 수 있지만 첫 검증에서는 겹쳐 쓰지 않는 편이 좋습니다. 여러 진입점, 가상 네트워크 인터페이스, 자동 라우팅을 동시에 바꾸면 문제를 찾기 어려워집니다.

켜고 나서 로그에 가상 인터페이스 생성 실패, 권한 부족, 라우팅 추가 실패, DNS 바인딩 충돌이 있는지 확인하세요. 인터페이스가 만들어지지 않았다면 서버를 계속 바꿔도 소용이 없습니다. 인터페이스가 생성됐지만 모든 접속이 실패하면 TUN을 끄고 기존 시스템 프록시가 작동하는지 확인하세요. 복구된다면 기본 출구는 정상일 가능성이 높으므로 모든 구독을 다시 가져오기보다 트래픽 처리 경로를 중심으로 점검해야 합니다.

증상	먼저 확인	복구 방법
켜자마자 스위치가 다시 꺼짐	권한, 서비스, 인터페이스 생성 로그	TUN을 끄고 기본 설정 유지
모든 도메인 접속 실패	DNS 경로와 라우팅 순환 여부	기존 DNS 설정을 복구한 뒤 비교
LAN 기기에 접속할 수 없음	사설 주소 예외와 로컬 라우팅	트래픽 처리를 끄고 로컬 네트워크 확인
절전 모드 후 연결 불가	네트워크 전환, 가상 인터페이스, 서비스 상태	인터페이스와 연결 다시 설정

DNS, UDP, 로컬 서비스도 함께 확인하기

TUN 환경에서 DNS 요청은 시스템 해석, 코어 해석, 가상 주소 매핑 등 여러 경로를 사용할 수 있으므로 실제 설정을 확인해야 합니다. 다른 코어의 DNS 필드를 그대로 복사하지 마세요. 웹은 되지만 음성 통화나 게임 등에서 문제가 생기면 UDP가 진입점부터 프록시 출구까지 지원되는지 확인하세요. 가상 인터페이스를 켠다고 원격 서버의 UDP 전달 기능까지 보장되는 것은 아닙니다.

LAN 프린터, 네트워크 저장소, 사내망은 올바른 직접 연결 경로를 유지해야 합니다. TUN을 켠 뒤 로컬 기기와 프록시 대상에 각각 접속해 서로 영향을 주지 않는지 확인하세요. 기업 네트워크는 자체 DNS와 라우팅을 적용할 수 있으므로 이를 임의로 덮어쓰면 내부 서비스에 문제가 생길 수 있습니다. 이런 환경에서는 먼저 조직의 네트워크 정책을 확인하세요. IPv6도 별도의 처리 방침이 필요하며 IPv4 테스트가 성공했다고 모든 주소 체계가 올바르게 처리된다고 볼 수는 없습니다.

Android의 VPN 모드도 시스템 트래픽을 연결하지만 데스크톱 가상 네트워크 인터페이스의 드라이버나 관리자 권한 설정을 그대로 적용하면 안 됩니다. Android에서 흔한 문제는 VPN 권한, 앱 제외 목록, 백그라운드 제한, 다른 VPN 도구와의 충돌입니다. 이 장을 마치면 TUN이 필요한 이유를 설명하고 브라우저, 대상 앱, LAN 서비스에 접속해 확인할 수 있어야 합니다. TUN을 끈 뒤 기존 네트워크를 복구할 수 있어야 하며 스위치를 알 수 없는 상태로 계속 켜 두어서는 안 됩니다.

8단계 · 연결 상태 유지하기

구독 관리, 로그, 단계별 문제 해결

반복 가능한 일상 점검 만들기

일상적으로 사용할 때 설정을 자주 바꿀 필요는 없습니다. 연결에 문제가 생기면 발생 시각, 현재 네트워크, 클라이언트와 코어 종류, 활성 서버, 연결 방식, 라우팅 모드를 기록한 뒤 같은 요청을 한 번 더 시도하세요. 이렇게 하면 일시적인 네트워크 변화와 지속적인 설정 오류를 구분할 수 있습니다. 모바일 핫스팟과 유선·무선 네트워크의 결과가 다르다면 문제를 좁힐 단서가 됩니다. 비교할 때 서버와 DNS를 동시에 바꾸면 차이의 원인을 알 수 없습니다.

구독은 출처의 권장에 따르거나 실제 변경이 필요할 때 업데이트하면 됩니다. 짧은 간격으로 반복 요청할 필요는 없습니다. 업데이트 후 활성 서버가 여전히 유효한지, 로컬 예외 규칙이 보존됐는지 확인하세요. 클라이언트를 업그레이드하기 전에 필요한 설정을 백업하고 화면의 마이그레이션 안내를 읽으세요. 백업에는 인증 정보가 포함될 수 있으므로 안전한 위치에만 보관해야 합니다. 전체 설정을 일반 문서처럼 공개 공간에 동기화하거나 구독 링크를 문제 해결 메모에 적지 마세요.

로컬, 구독, 노드, 시스템 순으로 점검하기

첫 번째는 로컬입니다. 코어가 실행되는지, 리스닝 포트가 있는지, 기기 시간이 정확한지, 디스크에 쓸 수 있는지 확인하세요. 두 번째는 구독입니다. 업데이트 응답이 정상인지, 활성 항목이 만료되거나 삭제되지 않았는지, 프로토콜이 지원되는지 살펴봅니다. 세 번째는 서버입니다. 주소와 포트로 연결할 수 있는지, 인증 및 전송 매개변수가 맞는지 확인합니다. 네 번째는 시스템입니다. 앱 진입점, 시스템 프록시, 방화벽, 가상 네트워크 인터페이스, DNS 설정이 서로 일치하는지 확인하세요.

로그에서 명확한 단서를 찾으면 점검 순서를 좁힐 수 있지만 증거 확인은 건너뛰지 마세요. 예를 들어 리스닝 실패가 표시되면 포트를 먼저 처리하고, 인증 실패라면 인증 정보와 기기 시간을 확인합니다. 특정 앱만 연결되지 않는다면 앱의 진입 방식을 우선 점검하세요. 노드 연결 시간 초과 문제는 4단계 점검으로 연결 시간 초과 해결하기에서 이어서 확인할 수 있습니다. 시간 초과는 결과를 설명할 뿐, 원인이 반드시 원격 노드에 있다는 뜻은 아닙니다.

로그 또는 증상	점검할 위치	우선 조치
리스닝 실패	로컬 포트 또는 주소	포트를 사용하는 프로세스와 리스닝 설정 확인
도메인 조회 실패	DNS 서버와 조회 경로	현재 DNS 정책과 네트워크 확인
핸드셰이크 또는 인증 실패	시간, 매개변수, 서버 상태	설정 출처와 보안 필드 확인
브라우저는 연결되지만 다른 앱은 연결되지 않음	앱 진입 방식과 프로토콜 차이	명시적 프록시 비교 테스트부터 진행

필요한 시간대의 로그만 보관

로그 상세 수준을 일시적으로 높이면 대상 주소와 출구 경로를 확인하는 데 도움이 됩니다. 하지만 디버그 로그를 계속 보관하면 디스크 공간을 더 사용하고 접속 대상이 기록될 수도 있습니다. 실패한 요청이 발생한 시간대를 찾고 필요한 부분만 저장한 뒤 일반 로그 수준으로 되돌리세요. 공유 전 구독, 인증 정보, 개인 대상 주소를 삭제하되 오류 전후 맥락은 보존하세요. 마지막 ‘실패’ 한 줄만 잘라내면 진입점 문제인지 원격 연결 문제인지 구분하기 어렵습니다.

네트워크 전환, 시스템 절전, 백그라운드 정리 때문에 기존 연결이 끊길 수 있습니다. 데스크톱에서는 시스템 프록시가 현재 리스닝 포트를 가리키는지 확인한 뒤 코어를 다시 시작해 새 연결을 만드세요. Android에서는 백그라운드 제한과 VPN 상태를 확인합니다. 문제가 생겼다고 앱 데이터를 바로 지우지 마세요. 가장 중요한 설정 비교 기준을 잃을 수 있습니다. 재시작 후 잠시 정상화되더라도 재시작 자체를 원인 해결로 간주하지 말고 문제가 발생하는 조건을 계속 기록하세요.

9단계 · 확장하고 되돌아보기

고급 설정과 장기 학습 경로

설명 가능한 규칙부터 확장하기

앞의 8개 장을 마친 뒤에는 매개변수를 더 많이 모으기보다 각 설정을 설명하고 검증하며 되돌릴 수 있도록 하는 것이 중요합니다. 예를 들어 특정 도메인을 직접 연결하거나, 앱 하나에 수동 프록시를 설정하거나, 네트워크가 바뀐 뒤에도 연결을 유지하는 등 구체적인 요구 하나를 선택하세요. 기대하는 경로를 적고 현재 설정과 어떤 차이가 있는지 확인합니다. 요구 범위가 좁을수록 테스트하기 쉽고 정상 작동 중인 다른 서비스에 영향을 줄 가능성도 낮아집니다.

설정 구조를 익힐 때는 인바운드, 아웃바운드, 라우팅, DNS, 로그 사이의 참조 관계부터 살펴보세요. 태그는 설정 내부의 이름이므로 참조 위치와 일치해야 합니다. 같은 이름의 필드라도 코어마다 의미가 다를 수 있습니다. GUI 클라이언트의 고급 설정은 우선 인터페이스에서 저장하세요. 설정 생성과 덮어쓰기 규칙을 충분히 이해한 뒤에만 사용자 정의 설정을 고려해야 합니다. 그렇지 않으면 다음 저장 작업에서 수동 수정 내용이 사라질 수 있습니다.

동일한 조건에서 코어 비교하기

v2rayN의 멀티 코어 기능은 호환성 확인에 유용하지만 코어 변경을 무작정 문제 해결 버튼처럼 사용하지 마세요. 새 코어가 대상 프로토콜, 전송 방식, 보안 필드를 지원하는지 확인한 뒤 네트워크, 서버, 테스트 대상을 그대로 유지하고 코어만 바꾸세요. 실행 결과와 실제 요청 결과를 기록합니다. 특정 기능이 지원되지 않으면 적절한 코어 또는 설정으로 돌아가세요. 설정 파싱만 통과시키려고 중요한 보안 필드를 삭제하지 마세요.

다른 기기로 옮길 때도 한 단계씩 진행하세요. 운영체제와 아키텍처에 맞는 클라이언트를 설치하고, 구독을 다시 설정해 활성 서버를 확인한 뒤 라우팅 예외와 연결 설정을 옮깁니다. 프로그램 디렉터리 전체를 다른 플랫폼에 그대로 복사할 수 있다고 가정하지 마세요. 파일 경로, 권한, 인터페이스 이름, 시스템 프록시 방식이 다를 수 있습니다. 옮긴 뒤에는 직접 연결 대상, 프록시 대상, 로컬 서비스에 각각 접속해 이전 규칙에 잘못된 가정이 포함되지 않았는지 확인하세요.

설정 실험은 작은 변경으로 진행하기

고급 설정을 실험할 때는 목표, 변경 항목, 검증 결과, 복구 방법을 짧게 기록하세요. 실제 인증 정보는 적지 마세요. 아래 목록은 변경 전후 점검 순서로 바로 활용할 수 있습니다. 복잡한 네트워크 구성도보다 실용적입니다. 예상과 다른 결과가 나오면 즉시 되돌릴지, 다음에 어느 계층만 바꿀지 판단할 수 있어 불필요한 매개변수를 계속 추가하지 않게 됩니다.

이번에 해결할 문제를 하나로 정하고 현재 사용 가능한 기준 설정을 기록합니다.
대상 코어가 지원하는 필드를 확인하고 변경 전 필요한 설정을 저장합니다.
항목 하나만 변경하고 연결을 다시 만든 뒤 로그에서 실제 경로를 확인합니다.
프록시 대상, 직접 연결 대상, LAN 서비스에 접속해 영향을 받은 범위를 기록합니다.
실패하면 되돌린 뒤 다시 테스트합니다. 성공하면 일반 로그 수준과 일상 설정으로 복구합니다.

원격 DNS, 도메인 스니핑, IPv6, UDP는 다음 단계에서 각각 학습할 수 있습니다. DNS를 조사할 때는 연결 방식과 서버를 고정하고, UDP를 살펴볼 때는 서버 지원 여부부터 확인하세요. IPv6는 주소 체계, 조회 결과, 라우팅을 함께 점검해야 합니다. 모든 주제를 한꺼번에 켜면 원인을 설명하기 더 어려운 시스템만 남습니다. 설정 항목이 늘어날수록 관찰 가능한 로그와 명확한 테스트 대상이 필요합니다.

성능도 기준을 정해 비교해야 합니다. 지연 시간, 연결 수립 시간, 처리량, 안정성은 서로 다른 질문에 답하므로 한 번의 지연 시간 테스트로 전체 사용 경험을 판단할 수 없습니다. 다운로드가 느린 이유는 대상 사이트, 네트워크 혼잡, 연결 재사용, 기기 부하일 수 있습니다. 조건을 고정하고 반복해서 관찰해야 비교할 수 있습니다. 처음 연결을 확인하는 자세한 방법은 실제 연결 테스트와 프록시 적용 확인을 참고하세요. 목록 정렬만으로 전체 문제를 진단할 수는 없습니다.