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

프로토콜 및 전송

연결 프로토콜과 보안 계층 조합

프로토콜은 클라이언트와 서버가 인증 정보와 데이터를 구성하는 방식을 정의합니다. 전송 매체와 보안 계층은 보통 별도의 설정 항목이므로, 같은 프로토콜 이름을 확인했더라도 TLS, REALITY, WebSocket, gRPC 등의 관련 필드를 추가로 살펴봐야 합니다.

VMess protocol: VMess는 Project V 생태계에서 초기에 사용된 클라이언트와 서버 간 통신 프로토콜입니다. 설정에는 보통 사용자 식별자, 서버 주소, 포트, 전송 방식이 포함됩니다. TCP, WebSocket 같은 하위 전송 매체와는 별개의 개념이므로 설정을 읽을 때 따로 확인해야 합니다.

VLESS protocol: VLESS는 구조가 간결한 통신 프로토콜로, 자체적으로 전송 계층 암호화를 제공하지 않습니다. 실제 설정에서는 TLS 또는 REALITY와 함께 사용하고 UUID로 사용자를 식별하는 경우가 많습니다. 연결 문제를 해결할 때는 프로토콜, 보안 계층, 전송 매개변수를 각각 확인해야 합니다.

Trojan protocol: Trojan은 TLS 연결을 통해 인증과 데이터를 전송하며, 인증 정보는 보통 비밀번호 필드로 입력합니다. 클라이언트 설정에는 서버 주소, 포트, 서버 이름 등의 매개변수도 필요합니다. TLS 핸드셰이크가 성공해도 인증 성공을 의미하지 않으므로 두 단계를 나누어 판단해야 합니다.

REALITY security layer: REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 클라이언트 설정에는 일반적으로 공개 키, 짧은 ID, 서버 이름, 핑거프린트가 포함됩니다. 보안 계층에 해당하며 VLESS를 대체하는 독립적인 애플리케이션 프로토콜은 아닙니다.

코어 및 클라이언트

설정 실행 계층과 그래픽 조작 계층

코어는 연결, 인바운드, 아웃바운드, 라우팅, DNS를 처리하고 그래픽 클라이언트는 이를 조작 가능한 화면으로 구성합니다. 클라이언트 이름과 코어 이름은 서로 바꿔 쓸 수 없으며, 같은 클라이언트도 버전과 설정에 따라 다른 코어를 사용할 수 있습니다.

V2Ray ecosystem: V2Ray는 Project V 생태계의 네트워크 도구 체계를 가리키는 경우가 많으며, 문맥에 따라 관련 코어를 뜻하기도 합니다. 설정은 보통 인바운드, 아웃바운드, 라우팅, DNS, 정책 모듈로 구성됩니다. 문서를 읽을 때는 생태계, 코어, 설정 형식 중 무엇을 의미하는지 문맥으로 판단해야 합니다.

V2Fly core family: V2Fly는 V2Ray 관련 기술 흐름을 이어가는 커뮤니티 프로젝트이자 코어 계열입니다. 설정 구조는 inbounds, outbounds, routing, dns 등의 모듈을 중심으로 구성됩니다. 일부 필드는 다른 코어 계열과 비슷하지만, 실제 지원 범위는 사용 중인 코어 버전을 기준으로 확인해야 합니다.

Xray core family: Xray는 V2Ray 설정 체계와 공통 개념이 많은 코어 계열입니다. VLESS, REALITY 등의 프로토콜과 보안 조합을 지원하며 그래픽 클라이언트가 이를 호출해 사용합니다. 필드를 인식하지 못한다면 먼저 클라이언트가 실제로 사용하는 코어 유형을 확인하세요.

v2rayN desktop client: v2rayN은 Windows, macOS, Linux용 그래픽 클라이언트입니다. 구독, 개별 서버 설정, 라우팅 규칙, DNS, 시스템 프록시 등을 관리하며, 화면의 옵션은 최종적으로 코어가 읽을 수 있는 실행 설정으로 변환됩니다.

v2rayNG Android client: v2rayNG는 Android용 그래픽 클라이언트로, 일반적으로 Xray 코어를 사용합니다. 구독이나 공유 링크를 가져올 수 있고 앱별 프록시, 라우팅, DNS 등을 설정할 수 있습니다. 백그라운드 동작은 시스템 배터리 정책과 네트워크 권한의 영향도 받습니다.

구독 및 노드

설정 출처, 서버 항목 및 테스트 결과

구독은 설정을 일괄 전달하고, 노드는 클라이언트에 저장된 개별 서버 기록이며, 지연 시간은 특정 테스트 방식으로 얻은 결과입니다. 세 가지는 서로 다른 문제를 다룹니다. 구독 업데이트 성공이 모든 노드의 연결 가능성을 보장하지 않으며, 지연 시간이 낮다고 실제 사용 과정의 안정성이 보장되는 것도 아닙니다.

구독 subscription: 구독은 서버에서 일괄 제공하는 설정 모음으로, 클라이언트가 구독 주소를 통해 서버 항목을 가져옵니다. 구독을 업데이트하면 원격 내용을 다시 분석한 뒤 클라이언트 규칙에 따라 기존 기록과 병합하거나 교체합니다. 구독 링크 만료, 형식 변경, 네트워크 요청 실패는 모두 업데이트 결과에 영향을 줍니다.

노드 server profile: 노드는 클라이언트 목록에 저장된 개별 서버 연결 설정입니다. 보통 주소, 포트, 프로토콜, 인증 정보, 전송 방식, 보안 매개변수를 포함합니다. 노드는 화면에서 사용하는 편의상 명칭이며, 설정 파일에서는 보통 하나의 아웃바운드 또는 연관 필드 묶음에 해당합니다.

지연 시간 latency: 지연 시간은 클라이언트가 테스트를 시작한 뒤 응답을 받을 때까지 걸리는 시간이며, 보통 밀리초로 표시합니다. 테스트 기능에 따라 TCP 연결, HTTP 응답 또는 다른 단계만 확인할 수 있으므로 결과를 단순히 서로 비교해서는 안 됩니다. 지연 시간은 주로 응답 속도를 보여주며 실제 전송 성능을 단독으로 나타내지는 않습니다.

실제 연결 지연 시간 real delay: 실제 연결 지연 시간은 실제 사용 과정에 가까운 연결을 수립해 응답 시간을 측정합니다. 일반적으로 코어 아웃바운드, 프로토콜 핸드셰이크, 대상 요청의 더 많은 단계를 포함합니다. 테스트 대상, 제한 시간, 현재 네트워크 상태가 최종 수치에 영향을 줍니다.

라우팅 및 트래픽 분할

트래픽 매칭 순서와 아웃바운드 선택

라우팅 모듈은 프로토콜 매개변수를 변경하지 않고 연결을 어느 아웃바운드에서 처리할지 판단합니다. 규칙은 보통 순서대로 매칭되며 도메인, IP, 포트, 인바운드 태그가 함께 판단에 사용될 수 있습니다. 따라서 규칙 위치와 이름 해석 결과가 최종 경로에 영향을 줍니다.

라우팅 규칙 routing rule: 라우팅 규칙은 도메인, IP, 포트, 프로토콜 또는 인바운드 태그에 따라 트래픽을 어느 아웃바운드로 보낼지 결정합니다. 여러 규칙은 보통 설정 순서대로 매칭되며 먼저 일치한 규칙이 이후 처리에 영향을 줍니다. 규칙을 수정한 뒤에는 설정을 저장하고 현재 코어를 재시작하거나 다시 불러와야 합니다.

트래픽 분할 traffic routing: 트래픽 분할은 서로 다른 대상의 트래픽을 조건에 따라 다른 아웃바운드에서 처리하도록 하는 설정 방식입니다. 일반적인 조건으로 도메인 분류, IP 범위, 앱 인바운드, 대상 포트가 있습니다. 결과는 규칙 순서, DNS 해석 결과, 각 아웃바운드 설정의 정확성에 좌우됩니다.

GeoIP IP dataset: GeoIP는 IP 주소의 지리적 소속 집합을 기준으로 매칭하는 데이터 분류입니다. 보통 라우팅 규칙의 IP 조건으로 사용하며, 먼저 대상 도메인의 해석 결과를 얻어야 합니다. 데이터 파일 버전에 따라 주소 분류 범위가 달라질 수 있어 업데이트 후 매칭 결과가 바뀔 수 있습니다.

GeoSite domain dataset: GeoSite는 용도나 범주별로 정리한 도메인 집합으로, 라우팅 및 DNS 규칙에서 참조할 수 있습니다. 도메인 규칙을 매칭하는 기능이며 GeoIP의 주소 소속 판단과는 다릅니다. 구체적인 분류 이름과 포함 내용은 클라이언트가 사용하는 데이터 파일에 따라 달라집니다.

TUN 모드 virtual interface: TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 수신해 시스템 프록시 설정을 읽지 않는 일부 앱에도 적용할 수 있습니다. 라우팅 테이블, DNS 가로채기, 가상 인터페이스 권한이 관련되므로 일반 시스템 프록시보다 설정 범위가 넓습니다. 사용 시 다른 가상 네트워크 도구가 같은 트래픽을 중복으로 가로채지 않도록 해야 합니다.

시스템 프록시 system proxy: 시스템 프록시는 운영체제가 호환 앱에 제공하는 프록시 주소 및 포트 설정입니다. v2rayN은 보통 이를 클라이언트의 로컬 수신 포트로 지정하고 코어가 해당 아웃바운드를 선택하도록 합니다. 시스템 프록시를 읽지 않는 프로그램은 별도로 설정하거나 상황에 따라 TUN 모드를 사용해야 합니다.

DNS 및 이름 해석

도메인 조회, 매핑 주소 및 해석 경로

DNS 설정은 도메인 조회를 어느 리졸버로 보낼지, 결과를 어떻게 필터링할지, 조회 요청을 어느 경로로 전송할지를 결정합니다. 라우팅 규칙이 도메인이나 IP에 의존한다면 DNS 결과도 매칭에 사용될 수 있으므로 이름 해석과 트래픽 분할을 함께 점검해야 합니다.

DNS name resolution: DNS는 도메인을 IP 주소로 변환하는 기본 서비스입니다. V2Ray 설정에서는 여러 DNS 서버를 지정하고 도메인 분류, 조회 유형, 예상 주소 범위에 따라 선택 순서를 정할 수 있습니다. 시스템 DNS, 코어 DNS, 앱 자체 해석이 동시에 존재할 수 있으므로 실제 조회 경로를 명확히 파악해야 합니다.

FakeDNS address mapping: FakeDNS는 먼저 앱에 매핑 주소를 반환한 뒤 코어가 매핑 관계에 따라 원래 도메인을 복원하고 트래픽을 처리합니다. 이 방식은 IP 트래픽을 가로챌 때 도메인 정보를 유지하는 데 도움이 됩니다. 매핑 주소 풀, TUN 설정, 라우팅 규칙이 서로 맞물려야 합니다.

DNS 누출 unexpected resolver path: DNS 누출은 도메인 조회가 예상한 해석 경로로 전달되지 않고 시스템이나 다른 네트워크 구성 요소를 통해 다른 리졸버로 직접 전송되는 현상입니다. 주요 점검 대상은 브라우저 내장 보안 DNS, 시스템 DNS, TUN 가로채기 범위, 코어 라우팅입니다. 이는 경로가 이탈한 상태를 뜻하며 일반적인 이름 해석 실패와는 다릅니다.

DoH DNS over HTTPS: DoH는 HTTPS를 통해 DNS 조회를 전송하며, DNS 서버는 보통 URL로 표시합니다. 설정 시 해당 URL의 도메인을 초기 단계에서 어떻게 해석하는지와 조회 요청을 어느 아웃바운드로 보낼지 확인해야 합니다. DoH 주소만 입력한다고 모든 DNS 트래픽의 라우팅이 자동으로 결정되지는 않습니다.

보안 및 암호화

식별 필드, 핸드셰이크 매개변수 및 전송 보호

인증 필드는 연결의 신원을 식별하고 TLS 같은 보안 계층은 전송을 보호하므로, 두 요소는 설정에서 서로 다른 역할을 합니다. 문제를 해결할 때는 주소 연결, 프로토콜 인증, 보안 핸드셰이크, 앱 요청을 여러 단계로 나누어 단일 오류만으로 전체 설정을 추측하지 않도록 해야 합니다.

TLS transport security: TLS는 연결에 암호화와 신원 인증을 제공하며 VLESS, Trojan 등의 설정과 함께 사용하는 경우가 많습니다. 클라이언트 필드에는 보통 서버 이름, 인증서 검증, 애플리케이션 계층 프로토콜, 핑거프린트가 포함됩니다. 서버 이름은 핸드셰이크 검증에 사용되므로 서버 주소의 단순한 반복 값으로 보면 안 됩니다.

UUID identifier: UUID는 고정된 형식의 16진수 문자로 구성된 식별자로, VMess, VLESS 등의 설정에서 사용자 식별 필드로 자주 사용됩니다. 서버 주소나 로컬 수신 포트가 아닙니다. 복사할 때 전체 문자와 하이픈 구조를 그대로 유지해야 합니다.

핑거프린트 TLS fingerprint: 핑거프린트는 관련 클라이언트 설정에서 일반적으로 TLS 핸드셰이크 특성을 뜻합니다. 일부 코어에서는 사전 설정값을 선택해 클라이언트 핸드셰이크 동작을 조정할 수 있습니다. 이 필드는 보안 계층 및 서버 설정과 함께 사용해야 하며 서버 이름, 공개 키, 인증 정보를 대신할 수 없습니다.

전송 암호화 encryption layer: 전송 암호화는 클라이언트와 서버 사이에서 전달되는 데이터를 보호하며 프로토콜 인증 및 전송 매체와 구분해야 합니다. TLS, REALITY, 프로토콜 필드는 서로 다른 설정 계층에 있으며 조합 방식은 서버 설정에 따라 결정됩니다. 클라이언트 로컬 수신 포트의 암호화 여부는 별개의 문제입니다.

읽는 방법

화면의 명칭을 설정 계층으로 되돌려 보기

그래픽 클라이언트는 여러 설정 필드를 하나의 스위치나 드롭다운 옵션으로 묶어 표시합니다. 예를 들어 “TUN 사용”은 가상 인터페이스, DNS 가로채기, 라우팅 테이블, 로컬 인바운드를 동시에 포함할 수 있습니다. 문제가 발생하면 먼저 시스템 프록시와 TUN 중 무엇을 사용하는지 확인한 다음 요청이 클라이언트로 들어오는지 점검하세요.

프로토콜 이름만으로는 전체 연결 방식을 알 수 없습니다. VLESS를 예로 들면 보안 계층이 TLS인지 REALITY인지, 전송 방식은 무엇인지, 서버 이름과 사용자 식별자가 일치하는지 추가로 확인해야 합니다. 필드를 프로토콜, 전송, 보안, 라우팅 계층으로 나누어 점검하면 노드를 계속 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.

구독 업데이트는 설정 내용을 가져오는 작업일 뿐 모든 서버 설정이 연결된다는 것을 증명하지 않습니다. 업데이트에 실패했다면 먼저 링크 형식과 요청 과정을 확인하세요. 가져오기는 성공했지만 연결되지 않는다면 노드 필드, 코어 로그, 시스템 시간, DNS, 라우팅 설정을 점검해야 합니다.

V2Ray 프로토콜·코어·설정 용어집

주제별로 찾기