V2Ray 용어집 - 프로토콜, 코어, 구독 및 라우팅 개념

찾아보는 방법

먼저 분류로 범위를 좁힌 다음, 용어 설명에 언급된 관련 설정을 이어서 확인하세요. 프로토콜 이름은 “어떤 형식으로 연결하는가”를, 코어 이름은 “어떤 프로그램이 설정을 실행하는가”를, 클라이언트 이름은 “어떤 그래픽 화면으로 코어를 관리하는가”를 설명합니다.

D · DNS F · FakeDNS G · GeoIP R · REALITY T · TUN V · VLESS X · Xray

01 · PROTOCOL

프로토콜 및 암호화

프로토콜은 인증과 데이터 교환 형식을 정의하고, TLS와 REALITY 같은 방식은 전송 계층의 인증 또는 암호화를 처리합니다. 설정을 가져올 때는 프로토콜 유형과 해당 매개변수가 함께 맞아야 합니다.

VMess 프로토콜

VMess는 Project V 생태계에서 초기에 널리 사용된 프로토콜로, 사용자 식별자와 시간 정보를 이용해 인증합니다. 설정에는 보통 서버 주소, 포트, UUID, 추가 ID, 전송 방식이 포함됩니다.

클라이언트와 서버의 핵심 필드는 일치해야 합니다. 시스템 시간이 크게 어긋났거나 사용자 식별자가 틀렸거나 전송 계층 매개변수가 다르면 인증 단계에서 연결이 종료될 수 있습니다.

VLESS 프로토콜

VLESS는 사용자 인증과 전송 계층 설정을 분리한 경량 인증 프로토콜입니다. 자체적으로 완전한 전송 암호화를 제공하지 않으므로 실제 설정에서는 TLS 또는 REALITY와 함께 사용하는 경우가 많습니다.

주요 필드에는 UUID, flow, encryption, network, security가 있습니다. XTLS Vision을 사용할 때는 클라이언트와 서버의 flow 값이 서로 맞아야 합니다.

Trojan 프로토콜

Trojan은 비밀번호로 클라이언트를 인증하며 일반적으로 TLS 연결 위에서 동작합니다. 클라이언트에는 서버 주소, 포트, 비밀번호, 인증서와 일치하는 서버 이름을 입력해야 합니다.

연결 실패를 점검할 때는 비밀번호, SNI, 시스템 시간, 인증서 체인을 각각 확인해야 합니다. 포트에 연결된다고 해서 TLS 핸드셰이크와 프로토콜 인증이 완료된 것은 아닙니다.

REALITY 전송 보안

REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 구성하는 경우가 많습니다. 클라이언트 설정에는 보통 serverName, publicKey, shortId, spiderX, 지문 유형이 포함됩니다.

publicKey와 shortId는 서버 설정에서 가져오고, serverName은 핸드셰이크에 사용합니다. 어느 한 필드라도 일치하지 않으면 핸드셰이크가 중단되거나 연결 직후 종료될 수 있습니다.

XTLS Vision 흐름 제어

XTLS Vision은 Xray의 흐름 제어 방식 중 하나이며, 일반적인 설정 값은 xtls-rprx-vision입니다. 보통 VLESS의 flow 필드에 지정해 코어가 연결 데이터를 처리하는 방식을 정합니다.

단독으로 사용할 수 있는 노드 프로토콜은 아닙니다. 서버, 클라이언트, 사용 중인 코어 버전이 동일한 흐름 제어 설정을 지원해야 합니다.

TLS 암호화 계층

TLS는 네트워크 연결에 암호화와 서버 인증을 제공하며 웹과 다양한 프록시 전송에 널리 사용됩니다. V2Ray 클라이언트의 관련 필드로는 security, serverName, allowInsecure, 지문 설정이 있습니다.

인증서 도메인, SNI, 서버 주소가 항상 같은 값인 것은 아니지만 서버 배포 방식에 맞아야 합니다. 시스템 시간이 잘못되면 유효한 인증서도 아직 유효하지 않거나 만료된 것으로 판단될 수 있습니다.

02 · CORE

코어 및 클라이언트

코어는 설정을 읽고 실제 연결을 처리하며, 클라이언트는 구독, 노드, 로그, 시스템 프록시 등의 그래픽 조작 기능을 제공합니다. 역할이 다르므로 클라이언트가 특정 설정을 제공하더라도 해당 코어의 처리 능력이 필요합니다.

Project V 기술 생태계

Project V는 프록시 프로토콜, 라우팅 기능, 네트워크 도구를 중심으로 형성된 오픈 소스 기술 생태계입니다. 초기 V2Ray의 설정 구조와 핵심 개념은 이후 여러 코어와 클라이언트의 중요한 기반이 되었습니다.

현재 문서를 읽을 때는 생태계 이름, 코어 프로젝트, 그래픽 클라이언트를 구분해야 합니다. 서로 관련되어 있지만 같은 소프트웨어 이름의 다른 표현은 아닙니다.

Xray 코어

Xray는 V2Ray 생태계의 코어 분기 중 하나로, VLESS, REALITY, XTLS Vision 등의 기능을 지원합니다. v2rayN과 v2rayNG는 연결, 라우팅, DNS 설정 처리에 Xray를 자주 사용합니다.

클라이언트 화면의 “코어 전환”은 하위 실행 프로그램을 바꾼다는 뜻입니다. 전환하기 전에 현재 노드의 프로토콜, 전송 방식, 설정 필드를 대상 코어가 지원하는지 확인해야 합니다.

V2Fly 코어

V2Fly는 Project V 커뮤니티가 지속적으로 관리하는 코어 계열로, V2Ray 설정 구조를 이어받아 인바운드, 아웃바운드, 라우팅, DNS, 정책 모듈을 제공합니다.

Xray와 기본 개념을 상당 부분 공유하지만 지원 범위와 세부 필드는 다를 수 있습니다. 설정을 복사할 때는 실제 사용 중인 코어의 문서와 시작 로그를 기준으로 삼아야 합니다.

v2rayN 데스크톱 클라이언트

v2rayN은 Windows, macOS, Linux용 그래픽 클라이언트로, 구독, 노드, 시스템 프록시, 라우팅 규칙, 코어를 관리할 수 있습니다. 데스크톱 버전과 기존 WPF 버전은 UI 기술이 다르지만 기본 사용 흐름은 비슷합니다.

클라이언트 자체가 설정을 생성하고 코어 프로세스를 제어합니다. 시작에 실패하면 노드만 반복해서 바꾸기보다 클라이언트 안내와 코어 로그를 함께 확인해야 합니다.

v2rayNG Android 클라이언트

v2rayNG는 Android 그래픽 클라이언트로, 일반적으로 Xray 코어와 함께 사용합니다. 구독, QR 코드 또는 공유 링크 가져오기, 노드 전환, 라우팅 모드, 앱별 프록시를 지원합니다.

시스템 절전 제한, 백그라운드 실행 정책, 로컬 가상 네트워크 권한이 지속적인 연결에 영향을 줍니다. 연결이 끊기면 노드 매개변수뿐 아니라 이러한 시스템 설정도 확인해야 합니다.

v2flyNG Android 클라이언트

v2flyNG는 V2Fly 코어 계열을 사용하는 Android 그래픽 클라이언트로, 일반적인 모바일 클라이언트와 비슷한 방식으로 조작합니다. V2Fly의 설정 동작이나 프로토콜 호환성이 필요한 환경에 적합합니다.

v2flyNG를 선택할 때는 노드의 프로토콜과 전송 방식이 V2Fly 코어에서 지원되는지 확인해야 합니다. 특정 코어 전용 필드가 포함된 설정은 가져온 뒤 시작되지 않을 수 있습니다.

03 · SUBSCRIPTION

구독 및 노드

구독은 설정을 일괄 배포하고, 노드는 하나의 구체적인 연결 기록을 나타냅니다. 구독을 업데이트하면 원격 콘텐츠를 다시 읽으므로 로컬 이름 변경, 필터, 그룹 설정을 업데이트 정책과 함께 고려해야 합니다.

구독 설정 출처

구독은 서비스 제공자가 생성한 노드 모음 주소입니다. 클라이언트가 구독 내용을 읽으면 공유 링크 또는 구조화된 설정을 해석해 업데이트 가능한 노드 목록을 만듭니다.

구독 업데이트 실패는 주소가 완전히 복사되지 않았거나, 링크가 변경되었거나, 네트워크 요청이 실패했거나, 반환 형식을 지원하지 않을 때 자주 발생합니다. 업데이트 로그를 보면 요청 오류와 해석 오류를 구분할 수 있습니다.

노드 서버 설정

노드는 클라이언트에 저장된 하나의 서버 설정으로, 일반적으로 주소, 포트, 프로토콜, 사용자 식별자, 전송 매개변수를 포함합니다. 노드 이름은 식별을 위한 라벨일 뿐 하위 연결 인증에는 사용되지 않습니다.

같은 구독 안에서도 노드마다 프로토콜이나 전송 방식이 다를 수 있습니다. 노드 매개변수를 복사할 때 서버 주소와 포트만 복사해서는 안 됩니다.

지연 시간 응답 소요 시간

지연 시간은 데이터가 로컬 장치에서 대상까지 왕복하는 데 걸리는 시간으로, 보통 밀리초로 표시합니다. 로컬 네트워크, 경로, 서버 부하, 테스트 대상의 영향을 받습니다.

클라이언트마다 포트 탐색, HTTP 요청 또는 전체 프록시 연결로 테스트할 수 있으므로 결과를 직접 비교할 수 없습니다. 한 번의 측정값이 장기적인 연결 성능을 의미하는 것도 아닙니다.

실제 연결 지연 시간 전체 연결 테스트

실제 연결 지연 시간은 프록시를 통해 실제 연결을 만든 뒤 지정된 테스트 대상에 접속해 측정합니다. 단순히 서버 포트를 확인하는 것보다 프로토콜 인증, 전송 핸드셰이크, 아웃바운드 접속이 정상인지 잘 보여줍니다.

테스트 실패는 전체 경로의 어느 한 단계가 완료되지 않았다는 뜻이지만, 결과만으로 장애 위치를 확정할 수는 없습니다. 클라이언트 로그를 함께 확인해 DNS, 핸드셰이크, 라우팅 정보를 점검해야 합니다.

구독 그룹 노드 관리

구독 그룹은 서로 다른 구독 출처와 노드 모음을 분류하는 클라이언트 관리 단위입니다. 그룹마다 독립적인 업데이트 주소, 활성화 상태, 필터 조건, 업데이트 기록을 가질 수 있습니다.

여러 구독에 비슷한 노드 이름이 포함되어 있을 때 그룹을 이용하면 설정 출처를 확인하기 쉽습니다. 그룹을 삭제하면 해당 구독으로 생성된 노드도 함께 삭제되는 경우가 많으므로 로컬 관리 규칙을 먼저 확인해야 합니다.

04 · ROUTING

라우팅 및 트래픽 분할

라우팅 모듈은 프로토콜 인증을 수행하지 않고, 요청을 어느 아웃바운드로 보낼지 결정합니다. 규칙 범위와 순서, 도메인 해석 결과, 클라이언트 실행 모드가 최종 매칭에 영향을 줍니다.

라우팅 규칙 매칭 조건

라우팅 규칙은 도메인, IP, 포트, 네트워크 유형, 프로토콜 또는 프로세스 정보를 기준으로 연결을 어느 아웃바운드로 보낼지 결정합니다. 일반적인 아웃바운드는 프록시, 직접 연결, 차단이며 구체적인 이름은 클라이언트가 생성한 설정에 따라 달라집니다.

규칙은 보통 위에서 아래 순서로 매칭됩니다. 더 구체적인 범위의 규칙을 일반 규칙보다 앞에 배치해야 하며, 그렇지 않으면 앞의 광범위한 조건이 먼저 적용될 수 있습니다.

트래픽 분할 트래픽 배분

트래픽 분할은 서로 다른 네트워크 요청을 각기 다른 아웃바운드가 처리하도록 구성하는 방식입니다. 예를 들어 도메인 범주, IP 범위, 앱 프로세스, 대상 포트에 따라 경로를 다르게 지정할 수 있습니다.

트래픽 분할 결과는 규칙 내용뿐 아니라 DNS 해석과 실행 모드에도 좌우됩니다. 문제를 점검할 때는 요청이 도메인으로 라우팅 판단에 들어오는지 IP로 들어오는지 확인해야 합니다.

GeoIP IP 규칙 집합

GeoIP는 IP 주소의 지역 또는 네트워크 유형별로 정리한 데이터 집합으로, 라우팅 설정에서 IP 매칭 조건으로 사용할 수 있습니다. 대량의 네트워크 대역을 수동으로 관리하는 부담을 줄여 줍니다.

주소 할당은 변경될 수 있으므로 GeoIP 데이터는 정기적으로 업데이트해야 합니다. 라우팅 단계에서 대상 IP를 확인할 수 있을 때만 해당 규칙이 매칭에 참여할 수 있습니다.

GeoSite 도메인 규칙 집합

GeoSite는 용도 또는 범주별로 정리한 도메인 모음으로, 관련 웹사이트 그룹을 일괄 매칭할 때 자주 사용합니다. 전체 도메인, 하위 도메인, 특정 범주를 포함할 수 있으며 실제 범위는 데이터 집합에 따라 달라집니다.

GeoSite는 도메인 정보를 매칭하고 GeoIP는 IP를 매칭하므로 같은 단계에서 동작하지 않습니다. 복잡한 트래픽 분할 설정에서는 두 종류의 규칙을 함께 사용하는 경우가 많습니다.

TUN 모드 가상 네트워크 인터페이스

TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 가로채며, 시스템 프록시 설정을 읽지 않는 일부 앱에도 적용할 수 있습니다. 클라이언트는 인터페이스로 들어온 데이터를 코어에 전달하고 라우팅 규칙에 따라 아웃바운드를 선택합니다.

활성화할 때는 가상 인터페이스 권한, DNS 가로채기, 라우팅 테이블, 로컬 네트워크 접근을 확인해야 합니다. 다른 네트워크 도구가 시스템 라우팅을 동시에 수정하면 규칙이 서로 덮어쓸 수 있습니다.

시스템 프록시 운영체제 설정

시스템 프록시는 운영체제가 제공하는 프록시 설정 창구입니다. v2rayN에서 시스템 프록시를 활성화하면 로컬 수신 주소가 시스템 설정에 기록되고, 이후 해당 설정을 따르는 앱의 요청이 클라이언트로 전달됩니다.

모든 프로그램이 시스템 프록시를 읽는 것은 아니므로 적용 범위는 일반적으로 TUN 모드보다 좁습니다. 클라이언트를 종료하기 전에 시스템 프록시 상태를 복원하면 이미 닫힌 로컬 포트로 앱이 계속 접속하는 일을 막을 수 있습니다.

05 · NETWORK

네트워크 기초

DNS, SNI, 로컬 수신 포트는 서로 다른 처리 단계에 있습니다. 도메인이 어떻게 해석되는지, TLS가 서버 이름을 어떻게 선택하는지, 앱이 트래픽을 클라이언트로 어떻게 전달하는지 이해하면 연결 문제를 찾는 데 도움이 됩니다.

DNS 도메인 해석

DNS는 도메인 이름을 IP 주소로 변환하는 기본 네트워크 서비스입니다. V2Ray 코어는 시스템 해석 결과를 사용할 수도 있고, 설정에 따라 서로 다른 도메인을 지정된 DNS 서버로 보낼 수도 있습니다.

DNS 설정은 도메인 접속과 라우팅 판단에 영향을 줍니다. 해석 결과가 예상과 다르면 조회 서버, 조회 경로, 캐시 상태, DNS 트래픽에 대한 라우팅 규칙의 처리 방식을 확인해야 합니다.

FakeDNS 도메인 매핑

FakeDNS는 앱에 매핑 주소를 반환하고 코어에 해당 주소와 원래 도메인의 관계를 보존합니다. 이후 연결이 코어로 들어오면 도메인을 복원해 도메인 기반 라우팅 규칙을 계속 적용할 수 있습니다.

TUN 모드와 함께 사용하는 경우가 많으며, 일반 공용 DNS의 해석 결과를 제공하기보다 도메인 정보를 보존하는 데 목적이 있습니다. 주소 풀은 실제 로컬 네트워크 대역과 겹치지 않도록 설정해야 합니다.

DNS 누수 조회 경로 이탈

DNS 누수는 지정된 경로에서 처리해야 할 조회가 실제로는 시스템 또는 다른 해석 경로를 통해 전송되는 현상입니다. 도메인 해석과 트래픽 분할 정책이 어긋나거나 앱이 다른 대상 주소를 받을 수 있습니다.

문제를 점검할 때는 시스템 DNS, 클라이언트 DNS, 브라우저 자체 해석 설정, TUN 적용 범위를 확인해야 합니다. 특정 서버 주소 하나만 바꿔서는 모든 조회 경로가 바뀌지 않을 수 있습니다.

SNI 서버 이름 표시

SNI는 TLS 핸드셰이크에서 대상 서버 이름을 지정하는 필드로, 클라이언트 설정에서는 보통 serverName에 해당합니다. 서버는 이 이름에 따라 인증서와 해당 사이트 설정을 선택할 수 있습니다.

SNI가 일치하지 않으면 인증서 도메인 오류나 핸드셰이크 실패가 발생할 수 있습니다. 문제를 점검할 때는 노드에 입력한 값과 서버의 실제 배포 매개변수를 하나씩 대조해야 합니다.

로컬 수신 포트 인바운드 진입점

로컬 수신 포트는 클라이언트가 로컬 장치에서 열어 앱 트래픽을 받는 포트입니다. SOCKS, HTTP, 혼합 인바운드는 각각 다른 포트를 사용할 수 있으며 클라이언트가 통합 관리할 수도 있습니다.

포트를 다른 프로그램이 사용 중이면 코어가 해당 인바운드를 시작하지 못하는 경우가 많습니다. 로그에 address already in use와 같은 메시지가 표시되면 점유 프로그램을 종료하거나 로컬 포트를 변경해야 합니다.