V2Ray 용어 정리: 프로토콜·구독·라우팅 규칙

PROTOCOL / TRANSPORT

프로토콜과 전송

프로토콜은 인증과 데이터 형식을 정하고, 전송 방식은 데이터를 전달하는 방법을 정하며, 보안 계층은 연결을 보호합니다. 노드 매개변수는 각 계층을 나눠 확인해야 하며 프로토콜 이름만으로 호환 여부를 판단할 수 없습니다.

VMess

VMess Protocol

VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 인증과 데이터 보호 기능을 포함합니다. 클라이언트와 서버에서 사용자 식별자, 전송 방식, 보안 매개변수를 서로 일치시켜야 합니다. 시스템 시간이 크게 어긋나면 인증에 영향을 줄 수 있으므로 핸드셰이크에 실패하면 시간 설정도 확인하세요.

VLESS

VLESS Protocol

VLESS는 사용자 인증과 트래픽 캡슐화를 담당하는 경량 프록시 프로토콜이며, 자체적으로 데이터 암호화를 제공하지 않습니다. 연결 보호는 일반적으로 TLS나 REALITY 같은 보완 기능이 담당합니다. 노드를 확인할 때는 전송 방식, 보안 계층, 흐름 제어 필드도 살펴보세요. 한 VLESS 노드의 매개변수를 다른 노드에 그대로 적용해서는 안 됩니다.

Trojan

Trojan Protocol

Trojan은 보통 TLS와 함께 사용하는 프록시 프로토콜로, 비밀번호로 인증합니다. 설정할 때 비밀번호, 서버 주소, 포트, TLS 서버 이름을 모두 확인해야 합니다. 서버 주소는 서버를 찾는 데 사용하고 서버 이름은 핸드셰이크와 인증서 확인에 사용하므로 둘이 다를 수 있습니다. 인증서 확인을 끄는 것은 매개변수를 올바르게 수정하는 방법이 아닙니다.

REALITY

Transport Security

REALITY는 Xray 생태계의 전송 보안 기능이며 독립적인 프록시 프로토콜은 아닙니다. VLESS와 함께 사용하는 경우가 많으며, 연결하려면 서버가 요구하는 공개 키, 서버 이름, 짧은 ID 등의 매개변수를 맞춰야 합니다. 공개 키와 클라이언트 지문은 서로 다른 필드입니다. 가져온 뒤에도 오류가 발생하면 GUI에서 저장되는지만 확인하지 말고 코어가 해당 기능을 지원하는지 살펴보세요.

전송 방식

Transport

전송 방식은 TCP, WebSocket, gRPC처럼 프록시 프로토콜의 데이터를 어떤 방식으로 전달할지 정합니다. VMess, VLESS 같은 프록시 프로토콜과는 서로 다른 설정 계층입니다. WebSocket에는 경로와 Host가 필요할 수 있고, gRPC에는 서비스 이름이 필요할 수 있습니다. 주소와 인증 정보가 맞더라도 전송 매개변수가 일치하지 않으면 연결할 수 없습니다.

전체 설정 가이드 보기

PROJECT / CORE

코어와 생태계

V2Ray는 특정 코어를 가리킬 수도 있고 도구 생태계 전반을 논할 때 쓰일 수도 있습니다. 프로젝트, 코어, 클라이언트를 구분해야 기능을 어느 계층에서 제공하는지 알 수 있습니다.

Project V

Project V Ecosystem

Project V는 네트워크 프록시 기능을 중심으로 구성된 프로젝트 및 도구 생태계이며, V2Ray는 그중 중요한 구성 요소입니다. GUI 클라이언트, 코어, 설정 형식은 각각 다른 역할을 합니다. ‘V2Ray 공식 사이트’를 검색할 때는 프로젝트 문서, 코어 자료, 클라이언트 사용 안내 중 무엇이 필요한지 먼저 확인하세요. 서로 다른 프로젝트의 화면과 매개변수를 혼용하지 않는 것이 좋습니다.

프로젝트 소개 보기

V2Fly

V2Fly Community

V2Fly는 V2Ray 관련 코드와 문서를 지속적으로 관리하는 커뮤니티 프로젝트입니다. V2Fly가 관리하는 v2fly-core는 일반적으로 V2Ray 코어라고 부르며, 프로토콜 처리와 라우팅, DNS 등의 기능을 담당합니다. v2flyNG는 해당 코어 계열을 사용하는 Android 클라이언트입니다. 이름이 비슷해도 다른 클라이언트와 설정 옵션이 완전히 같지는 않습니다.

Xray

Xray Core

Xray는 V2Ray에서 발전한 프록시 코어 프로젝트로, 프로토콜, 라우팅, 전송 보안 기능을 제공합니다. V2Fly와 기술적 기반을 공유하지만 기능과 설정 지원 범위가 완전히 같지는 않습니다. v2rayNG는 Xray 코어를 사용합니다. REALITY 같은 설정을 다룰 때는 클라이언트 이름만 보고 판단하지 말고 실제 코어의 기능을 확인하세요.

GUI 클라이언트

Graphical Client

GUI 클라이언트는 노드 표시, 구독 관리, 설정 생성, 코어 실행 제어를 담당합니다. v2rayN은 데스크톱용이며 v2rayNG와 v2flyNG는 Android용입니다. 화면의 ‘구독 업데이트’, ‘활성 노드 설정’, ‘시스템 프록시’는 서로 다른 작업입니다. 가져오기에 성공했다고 해서 트래픽이 선택한 노드로 전달되는 것은 아닙니다.

클라이언트 선택 보기

프록시 코어

Proxy Core

프록시 코어는 실제 연결, 프로토콜, 라우팅을 처리하는 실행 구성 요소이고 GUI는 사용자가 작업을 관리하도록 돕습니다. 코어 실행에 실패하면 클라이언트 창이 정상적으로 열려도 프록시 연결을 만들지 못할 수 있습니다. 문제를 해결할 때는 먼저 실행 로그를 확인해 설정 필드 오류, 로컬 수신 포트 충돌, 실행 구성 요소 누락을 구분한 뒤 해당 설정을 조정하세요.

문제 해결 문답 보기

CLIENT / SUBSCRIPTION

클라이언트와 구독

구독은 설정을 가져오는 출처이고 노드는 연결 매개변수이며, 테스트 결과는 특정 조건에서 측정한 값입니다. 이 세 가지를 구분하면 업데이트 실패, 노드 연결 불가, 테스트 시간 초과의 원인을 찾기 쉽습니다.

구독 URL

Subscription URL

구독 URL은 클라이언트가 여러 노드 설정을 가져오는 주소이며, 보통 접근 인증 정보가 포함된 URL입니다. 구독을 가져오면 업데이트할 출처가 저장되고, 구독 업데이트를 실행해야 해당 출처에서 노드 정보를 다시 가져옵니다. 예시 주소는 https://example.com/sub?token=xxxx입니다. 실제 주소는 비공개 정보로 취급하고 공개 스크린샷이나 로그에 포함하지 마세요.

구독 가져오기 안내 보기

노드

Server Profile

노드는 서버에 연결하는 데 필요한 설정 정보로, 보통 주소, 포트, 프로토콜, 인증, 전송 매개변수를 포함합니다. 클라이언트에 표시되는 노드 이름은 메모일 뿐 실제 연결 방식에는 영향을 주지 않습니다. 이름을 바꿔도 서버 주소는 보통 그대로입니다. 구독으로 생성된 노드 매개변수를 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다.

구독 그룹

Subscription Group

구독 그룹은 출처나 용도에 따라 노드를 정리하고 해당 구독의 업데이트 설정을 저장하는 데 사용합니다. 그룹을 업데이트하면 일반적으로 해당 출처의 항목만 새로 고쳐지며, 기존 항목을 바꾸거나 유지하는 방식은 클라이언트 구현에 따라 다릅니다. 그룹 이름에는 출처 메모나 용도를 적고 접근 인증 정보는 포함하지 않는 것이 좋습니다. 같은 주소를 여러 번 가져오면 중복 그룹이 생길 수도 있습니다.

실제 연결 지연 시간

Connection Latency Test

실제 연결 지연 시간은 선택한 프록시 경로를 통해 테스트 주소에 요청을 보내 측정한 시간을 말합니다. 테스트 주소, DNS, 핸드셰이크, 네트워크 부하, 클라이언트의 측정 방식에 따라 값이 달라질 수 있습니다. 다운로드 속도와는 다르며 TCP 연결 테스트와 직접 비교할 수도 없습니다. 테스트가 실패하면 대상 주소가 실제로 응답하는지 확인하고 실행 로그를 살펴보세요.

라우팅과 트래픽 분기

라우팅은 ‘연결이 코어에 들어온 뒤 어느 아웃바운드로 보낼지’를 처리합니다. 시스템 프록시와 TUN은 트래픽을 가져오고, 라우팅 규칙은 보낼 경로를 선택하므로 서로 대체할 수 없습니다.

라우팅 규칙

Routing Rules

라우팅 규칙은 도메인, IP, 포트, 인바운드 등의 조건에 따라 연결이 사용할 아웃바운드를 선택합니다. 일반적으로 규칙은 위에서 아래로 확인하며, 먼저 일치한 규칙이 연결 경로를 결정합니다. 규칙을 작성할 때는 구체적인 예외를 포괄적인 규칙보다 앞에 두고, 어떤 규칙에도 일치하지 않는 트래픽의 기본 경로를 확인하세요. 일부 규칙을 수정해 다른 연결에 영향을 주지 않도록 주의해야 합니다.

라우팅 규칙 안내 보기

GeoIP

IP Address Sets

라우팅 설정에서 GeoIP는 보통 태그로 참조할 수 있는 IP 주소 목록을 뜻합니다. geoip:private는 사설 또는 예약 주소 관련 목록이며, 실제 범위는 사용하는 데이터 파일에 따라 달라집니다. 이 규칙은 IP를 대상으로 합니다. 입력값이 도메인뿐이라면 먼저 도메인을 조회할지 여부가 라우팅의 domainStrategy 설정에 따라 달라집니다.

GeoSite

Domain Name Sets

GeoSite는 태그별로 정리된 도메인 목록으로, 특정 도메인 유형을 라우팅 조건으로 지정할 때 사용합니다. geosite:category-ads-all은 분류 목록을 참조하는 표현이지 실제 도메인 이름이 아닙니다. 목록 내용은 데이터 관리자가 정하므로 이름이 같더라도 파일 출처와 업데이트 상태를 확인해야 합니다. 도메인 분류만으로는 실제 규칙이 적용된 로그를 확인할 수 없습니다.

domainStrategy

Routing Domain Strategy

domainStrategy는 IP 규칙을 적용하기 위해 라우팅에서 도메인을 언제 조회할지 결정하는 필드입니다. AsIs, IPIfNonMatch, IPOnDemand는 서로 다른 조회 시점을 나타냅니다. DNS 서버 주소를 지정하는 설정이 아니며 프록시나 직접 연결을 정하지도 않습니다. 같은 이름의 필드가 다른 설정 객체에 있으면 해당 객체의 맥락에 맞춰 해석해야 합니다.

아웃바운드 태그

Outbound Tag

아웃바운드 태그는 설정에서 아웃바운드에 지정하는 이름이며, 라우팅은 outboundTag로 해당 태그를 참조합니다. direct, proxy, block은 흔히 사용하는 이름일 뿐 태그에 고정된 기능이 있는 것은 아닙니다. 규칙을 복사할 때는 대상 태그가 실제로 존재하는지, 해당 아웃바운드의 프로토콜과 용도가 예상에 맞는지 확인해야 합니다.

관련 용어: 규칙 적용과 연결 경로

NETWORK / DNS

네트워크와 시스템 프록시

앱 트래픽과 DNS 요청은 서로 다른 경로를 이용할 수 있습니다. 설정을 확인할 때는 앱이 클라이언트로 들어오는지, 라우팅이 올바른 경로를 선택하는지, DNS 요청을 누가 보내는지 각각 확인하세요.

시스템 프록시

System Proxy

시스템 프록시는 운영체제의 프록시 설정이 클라이언트의 로컬 수신 주소를 가리키도록 합니다. 이 설정을 사용할지는 각 앱이 결정하므로, 시스템 프록시를 켜도 모든 프로그램의 트래픽이 프록시를 통과하는 것은 아닙니다. v2rayN의 ‘시스템 프록시 자동 설정’은 주로 이 연결 지점을 조정합니다. 터미널 도구나 자체 프록시 설정이 있는 브라우저는 별도로 설정을 확인해야 합니다.

비교: TUN 모드

TUN 모드

Virtual Network Interface

TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 클라이언트로 전달하며, 일반적으로 시스템 프록시보다 더 많은 연결을 처리합니다. 어떤 연결을 직접 연결하거나 프록시 처리 또는 차단할지는 라우팅 및 제외 규칙에 따라 결정됩니다. 활성화할 때 추가 권한이 필요할 수 있고 다른 가상 네트워크 어댑터와 라우팅 충돌이 발생할 수도 있습니다. ‘TUN 사용’이 모든 연결을 프록시 아웃바운드로 보낸다는 뜻은 아닙니다.

DNS 조회

Domain Name System

DNS 조회는 도메인 이름을 연결에 필요한 IP 주소로 변환하며 다른 레코드를 반환하기도 합니다. 운영체제, 브라우저, 프록시 코어가 각각 다른 조회 경로를 사용할 수 있습니다. V2Ray DNS를 설정할 때는 노드 서버 주소의 조회와 대상 웹사이트의 조회를 구분하고 DNS 요청의 아웃바운드 정책도 확인해야 합니다. DNS 리졸버 주소 하나만 바꾸는 것으로 해결되지 않을 수 있습니다.

FakeDNS

Synthetic DNS Mapping

FakeDNS는 도메인에 내부에서 사용할 합성 IP를 할당하고 도메인과 합성 주소의 대응 관계를 저장합니다. 이후 연결이 관련 처리 경로로 들어오면 코어가 이 대응 정보를 이용해 도메인 정보를 복원할 수 있습니다. 합성 주소는 대상 서버의 실제 주소가 아닙니다. DNS와 연결 경로가 서로 맞지 않거나 앱에 이전 캐시가 남아 있으면 조회는 성공해도 연결에 실패할 수 있습니다.

DNS 누출

DNS Leak

DNS 누출은 조회 요청이 예상한 경로를 따르지 않고 다른 DNS 리졸버나 네트워크 출구를 통해 처리되는 현상입니다. 판단할 때는 설정된 DNS 정책과 비교해야 하며 웹페이지에 표시되는 출구 IP만으로 결론을 내릴 수는 없습니다. 브라우저의 암호화 DNS, 시스템 리졸버, 코어 DNS가 함께 사용될 수 있으므로 설정과 로그를 하나씩 확인하세요. 직접 연결된 DNS 조회를 모두 이상으로 간주해서는 안 됩니다.

DNS 문제 해결 문답 보기