V2Ray Configuration Reference

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

실제 설정 경로를 기준으로 주요 용어를 정리하고 프로토콜, 코어, 클라이언트 기능과 테스트 지표를 구분합니다. 각 항목에서 해결하는 문제, 필요한 매개변수와 혼동하기 쉬운 인접 개념을 설명합니다.

5 개 분류

28 개 핵심 용어

4 개 지원 플랫폼

Quick Index

로마자 및 영문 색인

원하는 용어를 알고 있다면 바로 이동할 수 있습니다. 영문 프로토콜 이름은 원문 표기를 유지하고, 기능명은 한국어에서 흔히 쓰는 순서로 정리했습니다.

01

프로토콜 및 암호화

프로토콜은 클라이언트와 서버가 데이터를 인증하고 캡슐화하며 전송하는 방식을 정합니다. 구독에 표시된 프로토콜 이름만으로 연결 품질을 판단할 수 없으며, 보안 계층·전송 방식·서버 매개변수의 일치 여부도 중요합니다.

VMess: Project V 생태계에서 사용하는 프록시 프로토콜입니다. 클라이언트와 서버는 동일한 사용자 식별자, 포트, 전송 방식 및 보안 매개변수를 사용해야 하며, 하나라도 맞지 않으면 핸드셰이크가 실패할 수 있습니다. VMess는 프로토콜 이름이지 클라이언트 이름이 아니며, 어떤 그래픽 인터페이스로 관리되는 노드인지 판단하는 기준도 아닙니다.

VLESS: 구조가 간결한 프록시 프로토콜로, 자체적으로 데이터 암호화를 추가하지 않으며 TLS 또는 REALITY 같은 보안 계층과 함께 사용하는 경우가 많습니다. 설정 시 주소·포트·사용자 식별자뿐 아니라 흐름 제어, 보안 방식, 서버 이름 등의 필드도 확인해야 합니다. 하나의 구독에 VLESS와 VMess가 함께 있을 수 있으며, 클라이언트는 각 노드의 프로토콜에 따라 처리합니다.

Trojan: 비밀번호를 주요 인증 정보로 사용하며 일반적으로 TLS 위에서 동작하는 프록시 프로토콜입니다. 클라이언트에는 서버 주소, 포트, 비밀번호, 서버 이름 및 인증서 검증 옵션이 자주 사용됩니다. Trojan 노드에 VMess 또는 VLESS 인증 필드를 그대로 적용할 수 없으므로 가져온 뒤에도 구독이 제공한 프로토콜 유형을 유지해야 합니다.

Shadowsocks: 사전 공유 비밀번호와 지정된 암호화 방식을 사용하는 프록시 프로토콜입니다. 서버 주소, 포트, 비밀번호와 암호화 방식이 핵심이며 양쪽에서 동일한 매개변수를 사용해야 합니다. SOCKS 로컬 프록시와는 다른 개념입니다. 전자는 클라이언트와 서버 사이의 프로토콜을, 후자는 앱이 로컬 클라이언트에 연결할 때 사용하는 인터페이스를 가리키는 경우가 많습니다.

REALITY: Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 구독 노드에는 보통 서버 이름, 공개 키, 짧은 식별자와 지문 등의 매개변수가 함께 포함되므로 수동 입력 시 항목별로 대조해야 합니다. REALITY는 독립적인 노드 프로토콜이 아니므로 설정 화면의 완전한 조합도 대개 VLESS를 프로토콜 유형으로 표시합니다.

02

코어 및 생태계

그래픽 클라이언트는 인터페이스·구독·시스템 설정을 담당하고, 코어는 실제 프로토콜 연결·DNS·라우팅을 처리합니다. 프로젝트명, 코어 포크, 클라이언트 이름을 구분하면 설정이 어느 계층에서 실행되는지 파악하기 쉽습니다.

Project V: 네트워크 프록시 프로토콜, 라우팅 기능 및 관련 도구를 중심으로 형성된 오픈 소스 기술 생태계입니다. V2Ray 설정 체계, VMess 등의 프로토콜과 후속 코어 포크가 이 발전 과정과 관련되어 있습니다. 특정 설치 프로그램 하나를 가리키는 말은 아닙니다.

V2Ray: Project V 생태계에서 널리 쓰이는 핵심 프로그램 및 설정 체계의 이름이며, 관련 클라이언트 생태계를 통칭하는 말로도 사용됩니다. 엄밀히 말하면 V2Ray 코어와 v2rayN, v2rayNG 같은 그래픽 클라이언트는 같은 소프트웨어가 아닙니다. 클라이언트는 코어 기능을 감싸고 구독 업데이트, 노드 선택, 시스템 프록시 제어 등의 진입점을 제공합니다.

V2Fly: V2Ray 기술 노선을 이어 가는 커뮤니티 유지 프로젝트로, v2ray-core 및 관련 사양 구현을 제공합니다. v2flyNG 등의 클라이언트 이름에 포함된 v2fly는 이 코어 생태계를 가리킵니다. 설정 호환성 문제가 생기면 화면 이름만 보지 말고 클라이언트 버전, 코어 포크와 프로토콜 매개변수를 함께 확인해야 합니다.

Xray: V2Ray 설정 체계와 밀접한 관련이 있는 코어 포크로, VLESS와 REALITY 등을 지원하며 일부 그래픽 클라이언트에서 사용됩니다. Xray는 코어이지 구독 서비스나 특정 연결 모드가 아닙니다. 클라이언트 화면에서 지원하는 프로토콜 범위는 보통 포함된 코어와 클라이언트 자체의 설정 적용 방식에 따라 달라집니다.

v2rayN: Windows, macOS, Linux용 그래픽 클라이언트로, 구독·노드·시스템 프록시·라우팅·TUN 등의 기능을 관리합니다. v2rayN은 화면의 설정을 코어가 읽을 수 있는 실행 설정으로 변환합니다. 문제를 점검할 때는 클라이언트 동작, 생성된 설정 로직과 코어 로그를 나누어 확인할 수 있습니다.

03

구독 및 노드

구독은 설정을 일괄 배포하고 업데이트하는 문제를 해결하며, 노드는 실제로 선택할 수 있는 개별 연결 기록입니다. 클라이언트의 로컬 목록은 업데이트에 따라 바뀌므로 수동으로 수정하기 전에 이후 업데이트가 해당 내용을 덮어쓸지 확인해야 합니다.

구독: 서비스 제공자가 생성한 설정 모음 주소로, 클라이언트는 이 주소에서 노드 정보를 가져옵니다. 구독 주소 자체는 보통 직접 연결할 수 있는 노드가 아니라 노드 목록의 출처입니다. 가져온 뒤 업데이트를 실행해야 클라이언트가 내용을 요청해 로컬 데이터베이스에 기록합니다.

노드: 클라이언트에서 선택할 수 있는 개별 서버 연결 설정으로, 주소·포트·프로토콜·인증 및 전송 매개변수를 포함합니다. 노드 이름은 식별을 위한 정보일 뿐 실제 연결 동작은 내부 설정 필드가 결정합니다. 노드를 선택한 뒤에는 코어를 실행하고 사용 환경에 따라 시스템 프록시 또는 TUN 모드를 활성화해야 합니다.

구독 그룹: 서로 다른 구독 출처를 나누어 관리하는 클라이언트 기능으로, 메모·업데이트 주기·필터 조건을 각각 설정할 수 있습니다. 그룹을 사용하면 노드 출처를 구분하고 특정 구독만 업데이트하기 쉽습니다. 그룹을 삭제하면 해당 출처에 속한 노드에도 영향을 주는 경우가 많으므로 작업 전에 클라이언트가 표시하는 범위를 확인해야 합니다.

구독 업데이트: 클라이언트가 구독 주소에 다시 요청을 보내고 응답 내용으로 노드 목록을 갱신하는 과정입니다. 클라이언트 프로그램 업그레이드와는 다르며 서버 설정을 자동으로 수정하지도 않습니다. 업데이트 후 노드 수, 이름 또는 매개변수가 바뀌는 것은 대개 구독 소스가 새로 반환한 내용 때문입니다.

노드 필터링: 노드 이름에 포함된 지역, 배율, 프로토콜 또는 사용자 지정 키워드에 따라 구독 내용을 필터링하는 관리 방법입니다. 필터링은 목록의 불필요한 항목을 줄일 뿐 노드 자체의 연결 품질을 높이지는 않습니다. 제외 규칙을 사용할 때는 키워드 범위를 확인해 필요한 노드까지 숨기지 않도록 해야 합니다.

04

라우팅 및 트래픽 분할

라우팅 시스템은 먼저 연결 대상을 식별한 다음 규칙 순서에 따라 아웃바운드를 선택합니다. 도메인 조회가 어느 계층에서 이루어지는지, 앱이 시스템 프록시를 따르는지, TUN이 트래픽을 가로채는지에 따라 실제 매칭에 사용되는 정보가 달라집니다.

라우팅 규칙: 도메인, IP, 포트, 프로토콜 또는 프로세스 등의 조건에 따라 트래픽을 직접 연결하거나 프록시를 사용하거나 차단하도록 결정하는 매칭 규칙입니다. 규칙은 보통 순서대로 평가되며 먼저 일치한 결과가 이후 처리에 영향을 줍니다. 규칙을 수정한 뒤에는 명확한 테스트 대상으로 확인해야 하며 노드 표시 상태만으로 분할 결과를 판단해서는 안 됩니다.

트래픽 분할: 서로 다른 목적지의 트래픽을 각기 다른 아웃바운드 방식으로 보내는 설정 방식입니다. 예를 들어 일부 연결은 직접 접속하고 나머지는 선택한 노드를 통해 처리할 수 있습니다. 트래픽 분할은 단일 스위치가 아니라 매칭 데이터, 규칙 우선순위, DNS 정책과 아웃바운드 설정이 함께 구성합니다.

GeoIP: IP 주소의 지역 정보를 기준으로 라우팅 매칭에 사용하는 데이터 모음입니다. 대상이 이미 IP로 해석되었거나 규칙이 IP 주소를 직접 처리할 때만 작동합니다. IP 할당 정보는 네트워크 자원 변경에 따라 달라지므로 데이터 버전이 다르면 같은 규칙도 다른 결과를 낼 수 있습니다.

GeoSite: 도메인 범주별로 정리한 규칙 데이터 모음으로, 라우팅 엔진이 여러 도메인을 일괄 매칭할 수 있습니다. 도메인 규칙을 처리하는 기능이며 GeoIP의 주소 소속 판단과는 다릅니다. 실제 사용 시 분류명, 매칭 방식과 규칙 순서를 확인해 도메인 집합과 IP 집합을 혼동하지 않도록 해야 합니다.

시스템 프록시: 클라이언트가 운영체제의 프록시 설정을 변경해 해당 설정을 따르는 앱이 HTTP 또는 SOCKS 요청을 로컬 프록시 포트로 보내도록 합니다. 모든 프로그램이 시스템 프록시를 읽는 것은 아니므로 클라이언트에 ‘사용’으로 표시되어도 모든 트래픽이 가로채진 것은 아닙니다. 브라우저와 일반적인 데스크톱 앱은 보통 이 방식으로 테스트를 시작하는 것이 좋습니다.

TUN 모드: 가상 네트워크 인터페이스를 통해 더 많은 시스템 트래픽을 가로채는 동작 방식으로, 시스템 프록시 설정을 읽지 않는 앱에 적합합니다. TUN 모드는 라우팅 테이블, DNS 및 가상 네트워크 카드 권한과 관련되므로 활성화하기 전에 일반 노드 연결이 정상인지 확인해야 합니다. 활성화 후 네트워크에 문제가 생기면 먼저 TUN을 끄고 권한·DNS·라우팅 설정을 각각 점검할 수 있습니다.

FakeDNS: 도메인에 임시 예약 주소를 반환한 뒤 이후 연결 단계에서 도메인 정보를 복원하는 DNS 처리 방식입니다. TUN 모드 및 도메인 기반 트래픽 분할과 함께 사용하면 대상 IP만 제공되는 연결도 원래 도메인에 따라 규칙을 매칭할 수 있습니다. FakeDNS 주소는 내부 매핑 결과이며 대상 서버의 실제 주소가 아닙니다.

05

연결 및 진단

진단 지표는 테스트 방식과 함께 해석해야 합니다. Ping, 실제 연결 지연 시간과 다운로드 속도 측정은 서로 다른 단계를 관찰합니다. 연결에 실패하면 구독 내용, 노드 매개변수, 코어 로그, 시스템 트래픽 가로채기 방식과 DNS 경로를 순서대로 확인해야 합니다.

지연 시간: 데이터가 한 번 왕복하는 데 걸리는 시간으로, 보통 밀리초 단위로 표시합니다. 테스트 방식마다 포함되는 경로가 다르므로 테스트 유형을 제외한 수치만으로 비교할 수 없습니다. Ping이 낮다고 프록시 핸드셰이크가 빠르다는 뜻은 아니며 다운로드 대역폭이 높다고 바로 추정할 수도 없습니다.

실제 연결 지연 시간: 클라이언트가 프록시 노드를 통해 실제 연결 요청을 완료하는 데 걸린 시간으로, 프록시 핸드셰이크와 대상 연결 과정이 포함됩니다. 서버 네트워크의 도달 가능성만 확인하는 Ping보다 일상적인 웹페이지 접속의 연결 단계에 가깝습니다. 테스트 실패는 전체 프록시 경로가 수립되지 않았음을 뜻하는 경우가 많지만, 구체적인 원인은 로그와 함께 확인해야 합니다.

다운로드 속도 측정: 실제 데이터를 전송해 노드의 가용 처리량을 추정하는 테스트 방식입니다. 결과는 테스트 대상, 로컬 네트워크, 노드 부하, 전송 프로토콜과 테스트 시간대의 영향을 받습니다. 실제 트래픽이 발생하므로 실제 연결 지연 시간이 통과된 뒤 대용량 파일 전송이나 동영상 로딩 성능을 판단할 때 적합합니다.

DNS 누수: 프록시 연결은 활성화되었지만 일부 도메인 조회가 예상과 다른 DNS 경로를 통해 전송되는 현상입니다. 프록시 노드 연결 가능 여부와는 별개의 문제입니다. 점검할 때는 앱의 조회 방식, 시스템 DNS, 클라이언트 DNS 설정과 TUN의 가로채기 범위를 확인해야 하며 단순히 노드만 바꿔서는 안 됩니다.

핸드셰이크: 클라이언트와 서버가 프로토콜 세션을 수립하고 필요한 매개변수를 협상하는 단계입니다. 인증 정보, TLS, 서버 이름, 공개 키 또는 전송 계층 설정이 일치하지 않으면 보통 이 단계에서 오류가 드러납니다. 로그의 핸드셰이크 실패 메시지는 화면의 일반적인 연결 실패보다 구체적이므로 점검 범위를 좁히는 데 유용합니다.

패킷 손실: 전송 중 데이터 패킷이 목적지에 도달하지 못하는 현상입니다. 지속적인 패킷 손실은 연결 재시도, 속도 변동, 음성 끊김 또는 세션 중단을 일으킬 수 있지만 간헐적인 테스트 결과는 로컬 무선 네트워크 때문일 수도 있습니다. 서로 다른 시간대에 반복 테스트하고 로컬 회선, 서버 회선과 대상 사이트 회선을 구분해 판단해야 합니다.