VMess
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 인증과 데이터 전송 방식을 포함합니다. 설정에는 사용자 식별자와 암호화 옵션이 자주 등장합니다. 여러 전송 방식과 조합할 수 있으므로 프로토콜 이름만으로는 연결 설정 전체를 파악할 수 없습니다. 클라이언트와 서버는 호환되는 프로토콜을 사용하고 인증 정보도 일치시켜야 합니다. 시스템 시간이 맞지 않으면 인증 과정에 영향을 줄 수 있습니다.
REFERENCE / TERMINOLOGY
V2Ray 용어집
프로토콜, 코어, 트래픽 진입점, JSON 필드를 설정 단계별로 확인하세요.
같은 설정 이름도 코어나 설정 단계에 따라 의미가 다를 수 있습니다. 이 페이지에서는 각 개념과 적용 범위를 설명합니다. 실제 값은 사용 중인 코어와 클라이언트 화면을 함께 확인하세요. 각 용어 카드에는 고유 앵커가 있어 주소를 복사해 해당 항목을 바로 찾을 수 있습니다.
PROTOCOL / TRANSPORT
프로토콜과 전송 방식
프록시 프로토콜은 통신 규약을 정하고, 전송 방식은 데이터를 전달하며, 보안 계층은 연결을 보호합니다. 서로 대체할 수 있는 개념이 아닙니다.
VLESS
VLESS는 자체적으로 데이터를 암호화하지 않는 가벼운 프록시 프로토콜로, 일반적으로 TLS나 REALITY 같은 보안 계층과 함께 사용합니다. 노드의 사용자 식별자, 전송 방식, 보안 매개변수, 필요한 경우 흐름 제어 옵션까지 한꺼번에 확인해야 합니다. VLESS와 VMess는 프로토콜 이름만 바꿔 서로 전환할 수 있는 설정이 아닙니다. 서버도 해당 조합을 지원해야 합니다.
Trojan
Trojan은 일반적으로 TLS 연결을 통해 프록시 트래픽을 전달하며 비밀번호로 인증합니다. 서버 주소와 포트뿐 아니라 서버 이름과 인증서 검증 설정도 확인해야 합니다. 주소는 연결을 설정하는 데 쓰이고 서버 이름은 TLS 핸드셰이크에 사용되므로 역할이 다릅니다. 인증서 오류가 반드시 비밀번호 입력 오류를 뜻하지는 않습니다.
REALITY
REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 나란히 놓이는 독립 프록시 프로토콜이 아닙니다. 서버에서 제공한 공개 키, 짧은 ID, 서버 이름 등의 매개변수를 확인하고 클라이언트 코어가 해당 설정을 지원하는지도 살펴야 합니다. 일반 TLS와 매개변수 구조가 다르므로 인증서 설정을 그대로 적용하거나 프로토콜 이름만으로 연결 방식을 추측해서는 안 됩니다.
전송 방식
전송 방식은 프록시 프로토콜의 데이터를 어떤 방식으로 전달하는지 나타냅니다. 대표적인 방식으로 네이티브 TCP, WebSocket, gRPC가 있습니다. WebSocket은 경로와 요청 호스트 이름을, gRPC는 서비스 이름을 설정할 수 있으며 서버 설정과 일치해야 합니다. 전송 옵션은 많다고 좋은 것이 아니며, 전송 방식을 바꾼다고 모든 노드와 호환되는 것도 아닙니다. 지원 범위는 프로토콜, 코어, 서버 구성에 따라 달라집니다.
KERNEL / ECOSYSTEM
코어와 생태계
클라이언트는 조작 화면을 제공하고 코어는 연결을 실행합니다. 이름이 비슷하다고 지원 기능까지 같은 것은 아닙니다.
Project V
Project V는 모듈형 네트워크 프록시 도구를 중심으로 형성된 프로젝트 및 기술 생태계이며, V2Ray는 그 핵심 구성 요소입니다. 일상적인 대화에서 “V2Ray”는 관련 도구 전반을 가리키기도 하고 코어만을 뜻하기도 하므로, 안내를 읽을 때 문맥을 구분해야 합니다. 프로토콜 지원이나 필드 호환 여부는 생태계 이름만으로 판단하지 말고 실제 사용하는 코어를 확인하세요.
V2Fly
V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트입니다. 코어는 프록시 프로토콜 처리, 라우팅 규칙 매칭, DNS 등의 기능을 담당합니다. v2flyNG는 Android용 GUI 클라이언트 중 하나로, 클라이언트 이름과 코어 이름은 서로 다른 계층을 가리킵니다. 설정 예제를 참고할 때는 설정 형식과 코어 버전을 확인하고, 과거의 모든 필드가 현재 환경에서도 유효하다고 가정하지 마세요.
Xray
Xray는 V2Ray 기술 체계에서 발전한 코어 프로젝트로, 자체적인 프로토콜과 보안 계층, 설정 방식을 발전시켜 왔습니다. v2rayNG는 Xray 코어를 사용하며, 데스크톱 클라이언트에서 사용할 코어는 실제 설정을 확인해야 합니다. 두 코어가 비슷한 JSON 구조를 지원하더라도 일부 필드, 기본값, 지원 조합은 다를 수 있으므로 옮길 때 항목별로 확인하세요.
GUI 클라이언트와 코어
v2rayN, v2rayNG, v2flyNG는 구독, 연결 매개변수, 실행 설정을 관리하는 GUI를 제공합니다. 코어는 설정을 읽어 실제 통신을 처리합니다. 클라이언트는 보통 화면에서 선택한 옵션을 바탕으로 실행 설정을 생성하므로, 생성된 파일을 직접 수정해도 다음 실행 때 덮어써질 수 있습니다. 문제를 진단할 때는 클라이언트 설정과 코어 로그를 함께 기록해 화면 설정 저장 문제와 코어 실행 문제를 구분하세요.
CLIENT / SUBSCRIPTION
클라이언트와 구독
구독은 연결 매개변수를 제공하고, 프록시 진입점은 앱 트래픽이 코어로 들어오는 방식을 정합니다. 지연 시간 테스트 결과는 특정 테스트 조건에서만 의미가 있습니다.
구독
구독은 연결 설정을 일괄로 가져오는 콘텐츠 또는 주소입니다. 클라이언트에서 구독을 업데이트하면 노드 정보를 다시 불러옵니다. 단일 노드 공유 링크와는 다르며, 어떤 코어에서든 바로 실행할 수 있는 완전한 JSON 설정과도 다릅니다. 구독 주소에는 접근 권한을 확인할 수 있는 정보가 포함될 수 있으므로 공개하지 마세요. 업데이트한 뒤에는 현재 선택한 노드가 여전히 있는지도 확인해야 합니다.
노드
노드는 클라이언트에 저장된 원격 연결 매개변수 모음을 가리키는 일반적인 표현입니다. 보통 주소, 포트, 프로토콜, 인증 정보, 전송 보안 설정이 포함됩니다. 표시 이름은 구분을 위한 메모일 뿐, 실제 트래픽 출구 위치나 네트워크 품질을 보장하지 않습니다. 같은 서버에서 여러 설정을 제공할 수도 있으므로, 동일한 연결인지 판단할 때는 이름이 아니라 설정 내용을 비교하세요.
시스템 프록시
시스템 프록시는 로컬 프록시 주소를 운영체제에 등록해 해당 설정을 참조하는 앱에 적용합니다. “모든 트래픽이 프록시를 통과한다”는 뜻도, 코어의 전역 라우팅을 의미하는 것도 아닙니다. 일부 앱은 별도의 네트워크 설정을 사용합니다. 로컬 수신 포트를 변경한 뒤에는 시스템 프록시 설정도 함께 바뀌었는지 확인하세요. 클라이언트를 종료한 뒤에도 사용할 수 없는 주소가 남아 있으면 해당 앱이 연결되지 않을 수 있습니다.
TUN 모드
TUN 모드는 가상 네트워크 인터페이스로 IP 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱의 트래픽을 전달할 때 주로 사용합니다. 적용 범위는 라우팅, 권한, DNS 설정, 클라이언트 구현에 따라 달라지며 모든 트래픽이 원격 프록시를 통과한다는 뜻은 아닙니다. 사용하기 전에 다른 가상 네트워크 어댑터나 네트워크 도구가 라우팅을 함께 처리하는지 확인하세요. 문제가 생기면 TUN을 먼저 끄고 원인을 좁혀 볼 수 있습니다.
TCP 지연 시간과 실제 연결 지연 시간
TCP 지연 시간은 일반적으로 서버 포트에 TCP 연결을 설정하는 데 걸리는 시간을 측정하며, 이것만으로 프록시 인증 성공 여부를 판단할 수는 없습니다. 실제 연결 지연 시간은 선택한 프록시를 통해 테스트 주소에 접속해 측정하며, 핸드셰이크, DNS 조회, 대상 사이트, 테스트 구현 방식의 영향을 받습니다. 두 결과를 같은 기준으로 단순 비교하지 마세요. 노드를 선택할 때는 실제 앱 사용 성능, 안정성, 트래픽 요금 조건도 함께 살펴야 합니다.
ROUTING / DNS
라우팅과 DNS
DNS 조회는 주소를 알아내고, 규칙은 트래픽이 나갈 출구를 정합니다. 분기 결과를 확인할 때는 도메인, IP, 실제 요청 경로를 함께 살펴보세요.
라우팅 규칙과 트래픽 분기
라우팅 규칙은 도메인, IP, 포트, 인바운드 태그 등의 조건에 따라 아웃바운드를 선택합니다. 트래픽 분기는 이런 조건에 맞춰 트래픽을 서로 다른 출구로 보내는 방식입니다. 일반적으로 규칙은 순서대로 매칭되며 먼저 일치하는 규칙이 적용됩니다. 따라서 조건이 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 시스템 프록시는 일부 트래픽이 코어로 들어올지를 결정할 뿐이며, 코어에 들어온 트래픽의 경로는 라우팅 설정으로 정해야 합니다.
GeoIP
GeoIP는 이러한 설정에서 보통 라우팅 규칙에 사용하는 IP 주소 분류 데이터를 뜻하며, geoip:private와 같은 표현식으로 해당 목록을 참조할 수 있습니다. IP 분류 데이터는 실시간 위치 정보가 아니며 도메인을 IP로 변환하지도 않습니다. 규칙에서 대상 IP를 실제로 확인해 해당 매칭 절차를 거쳐야 목록이 적용될 수 있습니다. 데이터 업데이트에 따라 적용 범위도 달라질 수 있습니다.
GeoSite
GeoSite는 관련 도메인을 하나씩 관리하지 않고 묶음으로 참조할 수 있도록 범주별로 정리한 도메인 규칙 모음입니다. 범주 이름만으로 포함된 항목을 알 수는 없습니다. 같은 서비스에서도 로그인, 미디어, 정적 리소스 도메인이 서로 다른 목록에 들어 있을 수 있습니다. 트래픽 분기가 누락되면 먼저 실제 요청 도메인을 확인한 뒤 데이터에 포함되어 있는지, 앞선 규칙이 요청을 가로채지 않는지 살펴보세요.
FakeDNS
FakeDNS는 도메인에 가상 IP를 할당하고 매핑 정보를 저장해, 트래픽이 코어에 들어온 뒤 도메인 정보를 복원할 수 있게 합니다. DNS 가로채기, 트래픽 진입, 매핑 복원이 함께 작동해야 하므로 DNS 서버만 바꾼다고 사용할 수 있는 기능은 아닙니다. 앱에 이전 매핑이 캐시되어 있거나 트래픽이 해당 처리 경로를 거치지 않으면 연결에 실패할 수 있습니다. 문제를 확인할 때는 캐시와 가로채기 적용 범위를 함께 살펴보세요.
DNS 누출
DNS 누출은 일반적으로 쿼리가 예정된 조회 경로를 벗어나는 현상입니다. 예를 들어 지정한 DNS 서버에서 처리할 것으로 예상했지만 운영체제나 브라우저의 다른 조회 방식이 쿼리를 보낼 수 있습니다. 먼저 의도한 조회 경로를 확인한 다음 브라우저의 암호화 DNS, 운영체제 DNS, 코어 DNS의 역할을 살펴보세요. 검사 페이지에 표시된 DNS 서버 이름은 단서일 뿐, 그 정보만으로 모든 트래픽의 출구를 단정할 수는 없습니다.
JSON / CONFIGURATION
설정 파일 필드
필드 이름은 상위 객체와 함께 살펴봐야 의미를 알 수 있습니다. 설정 조각을 복사하기 전에 인바운드, 아웃바운드, 최상위 설정 중 어디에 속하는지 확인하세요.
inbounds
inbounds는 트래픽 진입점을 정의하는 배열입니다. 각 항목에서 수신 주소, 포트, 프로토콜, 태그를 설정할 수 있습니다. 이 배열은 코어가 앱의 요청을 받는 방식을 설명하며 원격 서버 목록이 아닙니다. 로컬에서 사용할 때는 수신 주소의 범위를 확인하세요. 루프백 주소에서 수신하는 경우와 모든 네트워크 인터페이스에서 수신하는 경우의 접근 범위는 다릅니다. 연결 문제를 해결하려고 노출 범위를 함부로 넓혀서는 안 됩니다.
outbounds
outbounds는 트래픽 출구를 정의하는 배열로, 원격 프록시, 직접 연결, 차단 등의 처리 방식을 포함할 수 있습니다. 라우팅 규칙은 아웃바운드 태그로 해당 항목을 참조하므로 태그를 정확히 일치시켜야 합니다. 일반적인 설정에서는 어떤 규칙에도 매칭되지 않은 트래픽이 첫 번째 아웃바운드를 사용합니다. 배열 순서를 바꾸면 기본 경로가 달라질 수 있으므로 실제 코어의 동작을 확인하세요.
sniffing
sniffing은 보통 인바운드 객체에 위치하며, 지원되는 프로토콜 핸드셰이크나 요청 정보에서 도메인 단서를 추출해 라우팅이나 대상 처리에 활용합니다. 범용 복호화 기능이 아니며 모든 연결의 도메인을 복원할 수도 없습니다. 활성화했을 때의 영향은 대상 범위, 라우팅에만 사용 등의 옵션에 따라 달라집니다. 스니핑을 켰다고 모든 도메인 규칙이 적용되는 것은 아닙니다.
domainStrategy
domainStrategy의 의미는 이 필드가 속한 객체를 기준으로 해석해야 합니다. routing 안에서는 라우팅 규칙을 매칭할 때 도메인을 IP로 조회할지 제어합니다. 흔히 사용하는 값에는 AsIs, IPIfNonMatch, IPOnDemand가 있지만, 시스템 DNS 전체를 켜고 끄는 옵션은 아닙니다. 다른 객체에 같은 이름의 필드가 있더라도 값의 종류가 다를 수 있으므로 설정 단계 간에 그대로 복사하지 마세요.
allowInsecure
allowInsecure는 일부 TLS 설정에 사용됩니다. true로 설정하면 인증서 검증이 느슨해지지만, 신뢰 체인이나 서버 이름의 근본적인 문제를 해결하지는 못합니다. 인증서 오류가 발생하면 먼저 시스템 시간, 인증서 체인, 설정된 서버 이름을 확인하세요. 일반적인 설정에서는 인증서 검증을 유지해야 하며, 검증을 끄는 것을 보편적인 연결 최적화 방법으로 사용해서는 안 됩니다.
policy
policy는 연결 시간 제한, 사용자 등급 정책, 일부 통계 옵션에 사용하는 설정 객체입니다. routing과 역할이 다르며 도메인이나 IP에 따라 출구를 선택하지 않습니다. 핸드셰이크 시간 제한이나 유휴 연결 매개변수를 조정하기 전에 오류가 어느 단계에서 발생하는지 확인하세요. 시간 제한을 늘리는 것만으로 인증 오류, 포트 연결 실패, 잘못된 규칙 참조를 해결할 수는 없습니다.