V2Ray 용어 한눈에 보기: 프로토콜·구독·라우팅·DNS

PROTOCOL / TRANSPORT SECURITY

프로토콜과 전송

프록시 프로토콜과 전송 보안 방식을 구분한 뒤, 서버에서 제공한 매개변수 전체를 확인하세요.

VMess

VMess는 Project V 생태계의 프록시 프로토콜입니다. 사용자 식별자로 인증하며, 데이터 캡슐화도 프로토콜에서 처리합니다. 특정 전송 방식과 같은 뜻은 아니므로 VMess로 표시된 설정이라도 전송 매개변수는 다를 수 있습니다. 인증에 실패하면 서버 주소만 확인하지 말고 사용자 식별자, 시스템 시간, 서버 요구 사항을 함께 점검하세요.

VLESS

VLESS는 가벼운 프록시 프로토콜로, 자체 데이터 암호화 계층은 제공하지 않습니다. 연결 보호는 보통 TLS나 REALITY 같은 방식으로 처리합니다. VLESS라는 이름만 확인하지 말고 전송 유형, 서버 이름, 보안 설정도 점검해야 합니다. 일부 조합은 특정 코어 기능에 의존하므로 공유 링크를 가져올 수 있더라도 현재 코어에서 연결이 된다는 뜻은 아닙니다.

Trojan

Trojan은 일반적으로 TLS로 연결을 보호하고 비밀번호로 프록시 인증을 수행합니다. 서버 이름, 인증서 검증, 전송 매개변수도 서버 설정과 일치해야 하며, 비밀번호만 맞다고 해결되는 것은 아닙니다. 인증서 오류가 발생하면 시스템 시간, 서버 이름, 서버 인증서를 확인하세요. 인증서 검증을 끄는 방법을 장기적인 해결책으로 삼지 않는 것이 좋습니다.

읽기: 고급 설정

REALITY

REALITY는 Xray 생태계의 전송 보안 방식이며, VMess나 VLESS와 같은 독립 프록시 프로토콜이 아닙니다. 연결하려면 서버에서 제공한 공개 키, 서버 이름, 짧은 ID 등의 매개변수가 일치해야 하며, 구체적인 항목은 설정 형식에 따라 달라집니다. 보안 옵션만 REALITY로 바꾸고 나머지 매개변수를 그대로 두면 올바른 설정이 되기 어렵습니다.

코어와 생태계

프로젝트 이름은 기술의 출처를, 클라이언트 이름은 사용자가 조작하는 프로그램을 가리킵니다. 서로 바꿔 쓸 수 없습니다.

Project V

Project V는 V2Ray의 모듈형 프록시 체계를 이해하는 데 필요한 프로젝트 배경입니다. 핵심 구조는 트래픽 수신, 규칙 매칭, 트래픽 전송을 각각 나누어 처리하는 것입니다. 일상적으로 사용하는 그래픽 클라이언트는 이 체계 위에서 서버 관리와 시스템 연동 기능을 제공합니다. 기술 자료를 읽을 때는 프로젝트 구조, 코어 설정, 클라이언트 인터페이스 중 무엇을 설명하는지 구분하세요.

Xray

Xray는 V2Ray에서 발전한 뒤 자체 프로토콜과 전송 특성을 갖추었습니다. v2rayNG는 Xray 코어를 사용하지만, 클라이언트 인터페이스에서 설정할 수 있는 기능은 코어 통합 방식에 따라서도 달라집니다. 코어를 선택할 때는 서버에서 필요한 기능을 기준으로 판단하세요. 두 프로젝트의 공통된 역사를 이유로 Xray와 V2Fly의 설정을 그대로 바꿔 쓸 수 있다고 보면 안 됩니다.

읽기: 클라이언트 비교

V2Fly / V2Ray

V2Fly

V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트이며, v2flyNG는 이 계열의 코어를 사용합니다. Xray와 공통된 역사가 있지만 이후 기능, 설정 문법, 지원 범위는 다를 수 있습니다. 사용자 지정 설정을 적용할 때는 자료가 어떤 코어와 버전을 대상으로 하는지 확인하세요. 다른 코어의 예제를 그대로 실행 가능한 설정으로 간주하지 마세요.

비교: Xray

Core / GUI

코어

코어는 프로토콜 협상, 프록시 연결, 라우팅, 관련 DNS 처리를 실제로 수행하는 프로그램 구성 요소입니다. 그래픽 클라이언트는 설정을 저장하고 코어를 실행하며 로그를 표시합니다. 따라서 인터페이스가 열리더라도 코어가 정상적으로 실행된다는 보장은 없습니다. 시작에 실패하면 먼저 코어 로그에서 필드 오류나 포트 충돌을 확인한 뒤 클라이언트 설정을 조정해야 하는지 판단하세요.

읽기: 설정 계층

SUBSCRIPTION / SERVER PROFILE

구독과 노드

가져오기는 설정 항목을 등록하는 단계입니다. 업데이트와 연결 검증은 그다음에 각각 진행해야 합니다.

Subscription

구독은 클라이언트가 지정된 주소에서 서버 설정 목록을 가져와 업데이트하는 관리 방식이며, 코어에서 공통으로 사용하는 최상위 설정 키는 아닙니다. 구독 응답은 인코딩된 링크 목록이나 클라이언트 호환 형식으로 제공될 수 있으며, 형식이 맞지 않으면 파싱에 실패합니다. 구독 주소에 접근 정보가 포함될 수 있으므로 민감한 정보로 취급하고 스크린샷, 공개 로그, 공유 문서에 노출하지 마세요.

읽기: 구독 가져오기 단계

Node / Server Profile

노드

노드는 클라이언트에서 원격 프록시 연결 설정 하나를 가리킬 때 흔히 쓰는 말입니다. 보통 주소, 포트, 인증 정보, 프로토콜, 전송 매개변수가 포함됩니다. 노드 이름은 목록에서 항목을 구분하기 위한 것으로, 서버의 실제 위치나 성능을 판단하는 기준이 아닙니다. 이름이 다른 두 항목이 같은 서버를 가리킬 수도 있으므로 비교할 때는 이름이 아니라 실제 연결 정보를 확인하세요.

구독 업데이트

구독 업데이트는 구독 주소에 다시 요청을 보내 서버 설정을 파싱하고 동기화하는 과정입니다. 업데이트에 성공해도 노드 연결 테스트까지 통과한 것은 아닙니다. 동기화 과정에서 구독 항목을 직접 수정한 내용이 덮어써질 수 있으므로 중요한 변경 사항은 미리 백업하거나 별도 설정으로 저장하세요. 업데이트에 실패하면 요청 실패, 응답 내용 오류, 형식 비호환을 구분해서 확인하고 모든 그룹을 반복해서 삭제하지 마세요.

읽기: 구독 관리

MATCH / DISPATCH

라우팅과 트래픽 분기

규칙은 매칭 조건을, 아웃바운드는 트래픽을 처리할 대상을, 규칙 데이터는 재사용할 수 있는 매칭 집합을 정의합니다.

routing.rules

라우팅 규칙

라우팅 규칙은 도메인, 목적지 주소, 포트, 인바운드 등의 조건으로 아웃바운드를 선택하며, 주로 routing.rules에 설정합니다. 규칙은 보통 순서대로 확인하므로 포괄적인 조건을 앞에 두면 뒤의 세부 규칙이 매칭되지 않을 수 있습니다. 수정 후에는 대상 아웃바운드 태그가 실제로 존재하는지 확인하고, 도메인 해석 방식이 매칭 과정에 미치는 영향도 함께 살펴보세요.

읽기: 라우팅 규칙 실전 가이드

Traffic Policy

트래픽 분기

트래픽 분기는 트래픽 특성에 따라 직접 연결, 프록시, 차단 등의 경로를 선택하는 정책이며, 일반적으로 라우팅 규칙으로 구현합니다. 모든 연결을 같은 원격 서버로 보내거나 가장 빠른 서버를 자동으로 선택하는 기능과는 다릅니다. 분기 결과를 확인하려면 직접 연결과 프록시를 사용해야 하는 대상을 각각 점검하고, 로그에서 실제 사용된 아웃바운드를 확인하세요.

GeoIP

GeoIP 규칙 데이터는 IP 주소를 지역이나 다른 집합별로 분류해 주소 매칭에 활용합니다. 분류 결과는 데이터 출처와 업데이트 시점에 따라 달라지므로 서버의 실제 위치를 정확하게 증명하지는 않습니다. 도메인 규칙과 주소 규칙의 적용 결과는 DNS 해석 방식에도 영향을 받으므로 GeoIP 항목만 추가한다고 해서 원하는 트래픽 분기가 보장되지는 않습니다.

GeoSite

GeoSite는 사이트나 카테고리별로 도메인을 분류한 매칭 데이터이며, 각 집합에는 여러 형식의 도메인 규칙이 포함될 수 있습니다. 이 데이터는 도메인 정보를 매칭하며 사이트가 최종적으로 연결되는 모든 IP 주소를 매칭하는 것은 아닙니다. 사용 전 현재 데이터 파일에 대상 카테고리가 포함되어 있는지 확인하세요. 매칭이 예상과 다르면 클라이언트가 라우팅에 사용할 도메인 정보를 유지하거나 복원하는지도 살펴보세요.

비교: GeoIP

RESOLUTION / NETWORK STACK

DNS와 네트워크 스택

도메인 해석과 서비스 트래픽은 서로 연관되어 있지만 경로는 다를 수 있으므로 각각 확인해야 합니다.

DNS / Resolver

DNS

DNS는 도메인을 주소 등의 레코드로 변환하며, DNS 요청이 거치는 경로와 이후 서비스 연결 경로는 다를 수 있습니다. 운영체제, 브라우저, 클라이언트, 원격 서버가 모두 해석 과정에 관여할 수 있으므로 DNS 설정 한 곳을 바꿔도 모든 앱에 적용되는 것은 아닙니다. 문제를 확인할 때는 먼저 요청을 보내는 주체와 사용 중인 리졸버를 파악한 뒤 요청이 예상한 경로로 라우팅되는지 점검하세요.

읽기: DNS 설정 최적화

FakeDNS / Mapping

FakeDNS

FakeDNS는 도메인에 가상 주소를 할당하고 매핑 정보를 유지합니다. 이후 트래픽이 프록시 처리 과정에 들어오면 이 정보를 바탕으로 원래 도메인을 확인합니다. 가상 주소는 대상 서버의 실제 주소가 아니며, DNS 가로채기와 트래픽 진입점이 함께 작동해야 합니다. 관련 모드를 끈 뒤에도 앱에 이전 매핑이 남아 있다면 DNS 캐시를 비우거나 앱을 재시작한 후 다시 확인하세요.

DNS 유출

DNS 유출은 DNS 요청이 의도한 경로를 따르지 않고 다른 리졸버에 전달되는 현상입니다. 먼저 어떤 경로를 의도했는지 명확히 해야 합니다. 프록시가 연결된 상태라도 모든 DNS 요청이 통제된다고 볼 수 없으며, 브라우저의 암호화 DNS가 별도 경로를 사용할 수도 있습니다. 확인할 때는 시스템 설정, 앱 설정, DNS 로그를 함께 살펴보고 단 한 번의 웹 테스트 결과에만 의존하지 마세요.

비교: 시스템 프록시 적용 범위

TUN / Virtual Interface

TUN 모드

TUN 모드는 가상 네트워크 인터페이스로 IP 트래픽을 받은 뒤 클라이언트의 네트워크 스택에서 처리합니다. 시스템 프록시를 직접 사용할 수 없는 앱을 위한 방식입니다. 실제로 가로채는 범위는 라우팅, 권한, 제외 항목, DNS 설정에 따라 달라지며 모든 트래픽이 반드시 프록시 아웃바운드로 들어가는 것은 아닙니다. 사용하기 전에 트래픽을 가로채는 다른 도구와 충돌하지 않는지 확인하고, 모드를 끄고 네트워크를 복구하는 방법을 알아두세요.

읽기: v2rayN TUN 모드

CLIENT / CONNECTION TEST

클라이언트 기능

트래픽 가로채기 방식, 속도 측정 결과, 트래픽 진입점은 각각 다른 단계를 설명합니다. 하나의 상태만으로 전체 동작을 검증할 수는 없습니다.

System Proxy

시스템 프록시

시스템 프록시는 운영체제에 프록시 주소와 포트를 등록해 해당 설정을 따르는 앱에서 사용하게 합니다. 모든 네트워크 트래픽을 자동으로 가로채지는 않습니다. 앱에 별도의 프록시 설정이 있는 경우도 있고 프록시를 사용하지 않고 직접 연결하는 경우도 있으므로 각각 확인해야 합니다. 클라이언트를 종료한 뒤 웹 페이지에 접속할 수 없다면 시스템 프록시가 더 이상 수신하지 않는 로컬 포트를 가리키는지 확인하세요.

관련 항목: 로컬 인바운드 포트

Latency / Test Method

지연 시간

지연 시간은 특정 대상과 조건에서 테스트해 기록한 시간 지표로, 네트워크 왕복 시간, TCP 연결 설정 시간, 앱 요청 처리 시간 등을 측정할 수 있습니다. 측정 방식마다 포함되는 연결 단계가 다르므로 결과를 직접 비교할 수 없으며 다운로드 속도를 추정하는 지표도 아닙니다. 서버를 비교할 때는 측정 방식, 대상, 네트워크 환경을 동일하게 맞추고 한 번의 최저값이 아닌 여러 차례의 결과를 살펴보세요.

비교: 실제 연결 지연 시간

Real Connection Test

실제 연결 지연 시간

실제 연결 지연 시간은 보통 클라이언트가 선택한 프록시를 통해 실제 테스트 요청을 보내 측정한 시간입니다. 구체적인 측정 범위는 클라이언트 구현과 테스트 주소에 따라 달라집니다. 단순한 포트 연결 여부보다 더 많은 단계를 확인하지만, 여전히 해당 테스트 요청 한 번의 결과일 뿐입니다. 테스트에 성공한 뒤에도 실제 앱을 사용해 라우팅, DNS, 접속 동작이 예상대로인지 확인해야 합니다.

읽기: 연결 확인 방법

inbounds

인바운드

인바운드는 코어가 앱 트래픽을 받는 진입점입니다. 로컬 SOCKS 또는 HTTP 리스닝 포트가 흔하며, 설정 항목은 inbounds입니다. 클라이언트가 실행 중인 기기에서 요청을 받는 방식을 나타내며 원격 노드의 서버 포트와는 다릅니다. 해당 기기에서만 사용한다면 리스닝 주소를 확인하세요. 다른 네트워크 인터페이스까지 열기 전에는 접근 제어와 외부 노출 범위를 명확히 파악해야 합니다.

아웃바운드

아웃바운드는 코어가 트래픽을 다음 홉이나 목적지로 보내는 방식을 정의합니다. 원격 프록시, 직접 연결, 차단 등이 있으며, 설정 항목은 outbounds입니다. 라우팅 규칙은 보통 outboundTag로 특정 아웃바운드를 참조하므로 태그가 정확히 일치해야 합니다. 트래픽이 코어에 들어왔는데 예상대로 전달되지 않는다면 매칭된 규칙과 해당 아웃바운드의 연결 매개변수를 함께 확인하세요.

읽기: 규칙과 아웃바운드 연결