GLOSSARY

V2Ray 용어 해설과 용어 대조

클라이언트와 코어, 프로토콜과 전송, 구독과 노드, 라우팅과 분할, 네트워크와 포트, 로그와 진단의 여섯 갈래로 29개의 자주 쓰는 용어를 정리했습니다. 각 항목은 먼저 한 줄 정의를 제시하고, 이어서 설정에서의 위치와 사용 상황을 설명합니다.

이 페이지 활용법

먼저 분류 색인에서 원하는 장을 찾고, 용어 카드 아래의 상호 링크로 인접 개념으로 이동하면 됩니다. 용어와 설정 파일 필드의 대응 관계는 페이지 끝의 대조표에 모아 두었습니다.

CLIENTS & KERNELS · 5개

클라이언트와 코어

세 가지 그래픽 클라이언트가 인터페이스와 설정 관리를 맡고, 실제 전달은 Xray 또는 V2Fly 코어가 수행합니다. 두 코어는 대체 관계가 아니라 역할을 나눈 관계입니다.

v2rayN

데스크톱 3개 플랫폼 그래픽 클라이언트

Windows, macOS, Linux를 지원하는 V2Ray 그래픽 클라이언트로, 구독 관리와 노드 선택, 라우팅 설정, 로컬 수신 포트를 담당합니다. 자체적으로 프록시 프로토콜을 구현하지 않고 실제 전달은 Xray 또는 V2Fly 코어가 수행하며, 인터페이스는 설정을 생성하고 코어 프로세스를 관리할 뿐입니다. 데스크톱 버전과 클래식 WPF 버전 두 가지 인터페이스 형태를 제공합니다.

Xray 코어 로컬 수신 포트

v2rayNG

Android 그래픽 클라이언트

Android에서 실행되는 V2Ray 그래픽 클라이언트로 기본적으로 Xray 코어와 함께 사용합니다. 시스템 VPN 서비스 방식으로 트래픽을 처리하며 root 권한이 필요 없고, 구독과 라우팅, DNS 등 설정 항목은 데스크톱과 같은 구성 체계를 씁니다.

Xray 코어 라우팅 규칙

v2flyNG

Android 대체 클라이언트

역시 Android를 대상으로 하는 그래픽 클라이언트로, 실행 시 V2Fly 코어를 사용하며 인터페이스 구조는 v2rayNG와 비슷합니다. 노드가 오래된 VMess 파라미터를 쓰거나 V2Fly 전용 전송 조합이 필요할 때 대체 진입점으로 활용할 수 있습니다.

V2Fly 코어 VMess

Xray 코어

실제 전달을 담당하는 핵심

Project V 생태계의 코어 분기 중 하나로, 프로토콜 해석과 암호화, 라우팅 매칭, 아웃바운드 연결을 담당합니다. 클라이언트가 설정을 JSON으로 작성해 넘기면 이를 실행하며, 코어만 업그레이드하면 인터페이스를 바꾸지 않고도 새 프로토콜을 지원받을 수 있습니다.

VLESS XTLS Vision

V2Fly 코어

커뮤니티가 유지보수하는 또 다른 코어

Project V의 커뮤니티 유지보수 분기로, v2flyNG와 일부 데스크톱 클라이언트가 실행 코어로 사용합니다. Xray와 설정 구조는 대체로 호환되지만 지원하는 프로토콜 집합과 전송 옵션이 완전히 같지는 않으므로, 문제를 살필 때는 현재 어느 쪽이 실행 중인지 먼저 확인합니다.

v2flyNG VMess

PROTOCOLS & TRANSPORT · 5개

프로토콜과 전송

이 그룹의 용어는 설정 파일 앞부분에 등장합니다. 프로토콜은 신원을 어떻게 검증할지, 전송 계층은 데이터 패킷이 어떤 모양일지를 결정합니다.

VMess

타임스탬프 검증을 쓰는 프로토콜

V2Ray 초기 주력 프로토콜로, 클라이언트와 서버가 UUID와 타임스탬프로 신원을 검증하며 양쪽 시스템 시간이 대략 맞아야 합니다. 설정에는 보통 alterId 파라미터가 함께 들어가며, 최신 코어는 이를 호환 옵션으로 처리합니다.

공유 링크 V2Fly 코어

VLESS

상태 없는 경량 프로토콜

VMess와 달리 추가 암호화 계층과 타임스탬프 검증을 덜어내고 인증은 UUID에만 의존하므로 핸드셰이크가 짧고 오버헤드가 낮습니다. VLESS 자체는 암호화를 제공하지 않아 보통 TLS나 REALITY와 조합하며, 기밀성은 전송 계층이 담당합니다.

REALITY XTLS Vision

Trojan

표준 TLS를 사용하는 프로토콜

프록시 트래픽을 표준 TLS 연결 하나에 담아 보내며, 서버는 외부에서 평범한 HTTPS 사이트처럼 보이고 비밀번호가 맞지 않으면 실제 사이트 콘텐츠로 넘어갑니다. 설정 항목이 적고 주로 도메인과 인증서에 의존하므로 이미 인증서가 있는 환경에 적합합니다.

핸드셰이크 노드

REALITY

대상 사이트 인증서를 빌려 쓰는 핸드셰이크

클라이언트가 핸드셰이크 단계에서 실제 대상 사이트와 직접 TLS 협상을 마치므로 도메인과 인증서를 따로 발급받을 필요가 없습니다. 서버는 핸드셰이크를 전달하고 개인 키를 보유할 뿐이며 인증서 체인은 자연스럽게 신뢰할 수 있지만, 대상 사이트가 오랫동안 안정적으로 접속 가능해야 한다는 조건이 따릅니다.

핸드셰이크 VLESS

XTLS Vision

전송 계층 트래픽 셰이핑

TLS 레코드 계층 특성을 겨냥해 트래픽을 셰이핑하는 기법 모음으로, 분할과 패딩을 조절해 암호화 트래픽의 길이 분포를 일반 웹 접속에 가깝게 만듭니다. TLS 또는 REALITY와 함께 써야 하며 단독으로 켜도 의미가 없습니다.

VLESS REALITY

SUBSCRIPTION & NODES · 4개

구독과 노드

노드가 어디에서 오고 어떻게 갱신되며 개별 설정이 어떤 형태인지, 이 그룹의 용어는 가져오기 단계를 다룹니다.

구독 링크

노드 설정을 배포하는 주소

노드 목록을 반환하는 URL로, 클라이언트가 요청하면 응답 내용을 여러 노드로 파싱합니다. 링크에는 보통 사용자를 식별하는 토큰 파라미터가 붙으므로 계정 자격 증명과 같아 공개적으로 공유하지 않는 것이 좋습니다.

구독 업데이트 공유 링크

구독 업데이트

노드 목록 다시 가져오기

클라이언트가 구독 링크로 노드 목록을 다시 요청하고 새 결과로 로컬의 기존 항목을 교체하는 과정입니다. 대부분의 클라이언트가 수동 업데이트와 정기 업데이트를 지원하며, 노드를 바꾸기 전에 한 번 갱신하면 이미 내려간 주소로 접속하는 일을 피할 수 있습니다.

구독 링크 노드

노드

아웃바운드 연결의 목적지

노드 하나를 온전히 설명하려면 서버 주소, 포트, 프로토콜, 전송 방식, 인증 파라미터가 필요합니다. 클라이언트는 노드를 목록으로 정리하고, 연결할 때 라우팅 규칙이 어떤 트래픽을 어느 노드로 보낼지 결정합니다.

라우팅 규칙 실제 연결 지연

ROUTING & SPLIT · 5개

라우팅과 분할

트래픽을 프록시로 보낼지 직접 연결할지 결정하는 매칭 체계 전체로, 순서와 매칭 대상이 이해의 두 가지 핵심입니다.

라우팅 규칙

트래픽 방향을 정하는 매칭 표

순서대로 매칭하는 조건의 묶음으로, 각 규칙에 매칭 대상(도메인, IP, 포트, 프로세스)과 일치했을 때의 동작(프록시, 직접 연결, 차단)이 적혀 있습니다. 위에서 아래로 매칭하며 첫 번째로 일치한 규칙에서 멈추므로 규칙 순서가 결과를 좌우합니다.

GeoIP GeoSite 트래픽 분할

트래픽 분할

목적지에 따라 경로 선택

일부 트래픽은 프록시로, 나머지는 직접 연결로 보내는 처리 방식입니다. 보통 중국 본토 도메인과 IP 대역을 직접 연결로 지정하고 나머지를 프록시로 보내, 노드 부담을 줄이면서 로컬 서비스가 우회되는 일도 막습니다.

라우팅 규칙 인바운드와 아웃바운드

GeoIP

IP 소속 지역으로 매칭

코어에 내장되거나 별도로 붙는 IP 위치 데이터베이스로, 라우팅 규칙에서 geoip:cn 같은 형태로 참조합니다. 특정 IP가 어느 지역에 속하는지를 알려주므로 IP로 직접 연결하는 대상에 유효하고, 도메인 대상은 주소를 먼저 해석해야 매칭됩니다.

라우팅 규칙 GeoSite

GeoSite

사이트 도메인 집합으로 매칭

사이트별로 분류해 정리한 도메인 목록으로, 규칙에서는 geosite:category-ads 같은 형태로 씁니다. 도메인 접미사를 하나씩 나열하는 것보다 흔한 사이트 그룹을 일괄 처리하기에 적합하며, 데이터베이스는 코어와 함께 갱신할 수 있습니다.

라우팅 규칙 GeoIP

인바운드와 아웃바운드

트래픽의 양 끝

인바운드는 트래픽이 어디로 코어에 들어오는지, 예를 들어 로컬 SOCKS 포트나 TUN 가상 인터페이스를 뜻하고, 아웃바운드는 트래픽이 어떤 방식으로 나가는지, 예를 들어 특정 노드나 직접 연결을 뜻합니다. 라우팅 규칙은 인바운드와 아웃바운드 사이에서 선택하는 역할을 합니다.

시스템 프록시 TUN 모드

NETWORK & PORTS · 6개

네트워크와 포트

코어가 로컬에 여는 진입점, 트래픽을 처리하는 두 가지 방식, 그리고 해석 요청이 향할 곳을 다룹니다.

로컬 수신 포트

코어가 로컬에 여는 진입점

코어가 로컬에서 수신 대기하는 포트로, 보통 SOCKS 10808과 HTTP 10809 조합을 씁니다. 브라우저나 시스템이 트래픽을 이 포트로 보내면 코어가 라우팅 규칙에 따라 전달하며, 다른 프로그램이 포트를 점유하면 클라이언트 실행이 실패하고 그 원인이 로그에 기록됩니다.

SOCKS5 시스템 프록시

SOCKS5

범용 프록시 프로토콜

TCP와 UDP 전달을 지원하는 프록시 프로토콜로, 트래픽을 프록시 측에 넘기는 일만 하고 상위가 HTTP인지 다른 프로토콜인지는 따지지 않습니다. 데스크톱 클라이언트의 로컬 진입점은 보통 SOCKS5를 중심으로 하며 호환성이 가장 좋습니다.

로컬 수신 포트 시스템 프록시

시스템 프록시

운영체제가 트래픽을 전달

클라이언트가 운영체제의 프록시 설정을 바꿔 HTTP와 SOCKS 요청을 로컬 수신 포트로 보냅니다. 시스템 프록시를 따르는 프로그램에만 적용되며, 네트워크 설정을 직접 읽는 애플리케이션은 여전히 직접 연결하므로 이때는 TUN 모드로 바꿔야 합니다.

로컬 수신 포트 TUN 모드

TUN 모드

가상 인터페이스로 전체 트래픽 처리

코어가 가상 네트워크 인터페이스를 만들고 기본 경로를 그쪽으로 돌리면 애플리케이션 트래픽이 네트워크 계층에서 일괄 처리되어 각 프로그램의 프록시 설정에 의존하지 않습니다. 대신 더 높은 시스템 권한이 필요하고 DNS 처리도 따로 설정해야 하며, 그렇지 않으면 해석 오류가 생기기 쉽습니다.

시스템 프록시 FakeDNS

FakeDNS

가짜 주소로 도메인 정보 확보

코어가 도메인에 대해 예약 주소 대역의 가짜 IP를 먼저 반환하고, 애플리케이션이 실제로 연결을 시작할 때 매핑 관계로 도메인을 복원해 라우팅 규칙에 넘깁니다. IP 기반으로 시작된 연결도 도메인 분할의 혜택을 받게 되며, 대신 로컬 DNS 캐시를 함께 정리해야 합니다.

TUN 모드 DNS 누출

DNS 누출

해석 요청이 프록시 경로를 우회

애플리케이션은 연결을 맺기 전에 DNS 질의를 한 번 하는데, 이 질의가 프록시 경로가 아니라 로컬 네트워크로 나가면 대상 도메인이 로컬 리졸버에 노출됩니다. 보통 코어에서 DNS 서버를 명시적으로 지정하거나 TUN 모드가 DNS 트래픽을 처리하도록 합니다.

TUN 모드 FakeDNS

LOGS & DIAGNOSIS · 4개

로그와 진단

문제가 생겼을 때 무엇을 먼저 보고 어떤 수치를 비교할지, 이 그룹의 용어는 점검 절차의 출발점입니다.

실행 로그

코어가 출력하는 실행 기록

코어가 시작, 설정 로드, 연결 수립, 오류 정보를 시간 순서로 기록하며 문제를 파악하는 1차 자료가 됩니다. 로그의 타임스탬프, 아웃바운드 태그, 오류 키워드를 보면 문제를 구체적인 단계로 좁힐 수 있습니다.

로그 레벨 핸드셰이크

로그 레벨

기록의 상세 수준 제어

흔한 값으로 warning, info, debug가 있으며 레벨이 자세할수록 기록이 많아지고 로그 파일도 빠르게 커집니다. 평소에는 info면 충분하고, 특정 문제를 재현할 때만 잠시 debug로 올렸다가 확인이 끝나면 되돌립니다.

실행 로그 핸드셰이크

실제 연결 지연

종단 간 가용성 지표

클라이언트가 실제로 노드에 연결을 한 번 시도하고 응답을 기다려 측정한 왕복 시간으로, 핸드셰이크와 인증이 포함됩니다. ping보다 실제 체감에 가깝지만 테스트할 때마다 연결 비용이 발생하며, 노드를 쓸 수 없으면 타임아웃으로 나타납니다.

노드 핸드셰이크

핸드셰이크

연결 수립 전 협상 과정

데이터를 주고받기 전에 클라이언트와 서버가 신원을 확인하고 암호화 파라미터를 협상하는 과정입니다. 핸드셰이크 소요 시간은 첫 연결 속도에 그대로 드러나며, TLS와 REALITY, XTLS가 중점적으로 최적화하는 지점이기도 합니다.