VMess
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 인증과 데이터 보호 기능을 포함합니다. 노드에서는 보통 UUID로 사용자를 식별합니다. 연결하려면 사용자 식별자뿐 아니라 전송 방식과 관련 매개변수도 일치해야 합니다. 시스템 시간 차이가 인증에 영향을 줄 수 있으므로 핸드셰이크가 계속 실패한다면 기기의 시간 동기화도 확인하세요.
V2Ray 용어 사전
프로토콜·코어·라우팅
자주 쓰이는 용어 24개를 설정 단계별로 설명합니다. 연결 프로토콜, 실행 코어, 트래픽 경로를 구분한 뒤 클라이언트 항목을 대조해 문제를 찾아보세요.
처음 설정한다면 사용 가이드를 먼저 읽어보세요. 이미 오류가 발생했다면 문제 해결에서 바로 확인할 수 있습니다. 이 페이지의 용어명은 고정 앵커로 인용할 수 있습니다.
protocol / transport
프로토콜과 전송
프로토콜은 인증과 전달 방식을 정하고, 전송 설정은 데이터가 어떤 방식으로 전달될지 결정합니다.
VLESS
VLESS는 경량 인증과 전달에 중점을 두며, 자체적으로 범용 데이터 암호화를 제공하지 않아 보통 TLS 또는 REALITY와 함께 사용합니다. 설정의 protocol, flow, 전송 보안은 서로 다른 항목입니다. VLESS라는 이름만으로 노드 설정이 완전하다고 볼 수 없습니다. 구체적인 지원 기능은 코어 구현에 따라 달라지며 클라이언트와 서버의 매개변수가 일치해야 합니다.
Trojan
Trojan은 일반적으로 TLS 연결 위에서 동작하며 비밀번호로 사용자를 인증하고, 전송 보호는 TLS가 담당합니다. 주소, 포트, 비밀번호가 정확해도 인증서 검증이 통과된다는 보장은 없습니다. 서버 이름도 배포 설정과 일치해야 합니다. 문제를 진단할 때는 비밀번호 인증 실패, TLS 핸드셰이크 실패, 대상 서버 연결 실패를 구분하세요.
전송 계층 설정
여기서는 TCP나 WebSocket처럼 프록시 프로토콜이 사용하는 전달 방식을 뜻하며, Xray 설정에서는 보통 streamSettings와 관련됩니다. WebSocket을 선택해도 경로와 관련 요청 매개변수는 서버 설정과 일치해야 하므로 전송 이름만 바꾸면 안 됩니다. TLS와 REALITY는 전송 보안 설정이므로 전달 방식과 혼동하지 마세요. 프로토콜을 바꿔도 이 매개변수들은 자동으로 수정되지 않습니다.
ecosystem / core
코어와 생태계
생태계, 코어, 그래픽 인터페이스는 각각 역할이 다릅니다. 호환성 문제를 진단할 때는 실제로 실행 중인 코어를 확인해야 합니다.
Project V
Project V는 모듈형 네트워크 프록시 도구를 중심으로 형성된 프로젝트 생태계를 뜻하며, V2Ray는 그 안의 주요 프로젝트 이름입니다. 특정 데스크톱 앱의 메뉴 이름도 아니고 관련 클라이언트가 모두 같은 기능을 제공한다는 뜻도 아닙니다. 설정 문제를 논의할 때는 클라이언트 이름, 실행 코어, 관련 기능을 구체적으로 밝혀 “V2Ray”라는 말만으로 뭉뚱그리지 마세요.
Xray-core
Xray-core는 프로토콜, 인바운드·아웃바운드, 라우팅, DNS 등을 처리하는 프록시 코어로, 그래픽 클라이언트가 연결을 위해 실행할 수 있습니다. VLESS, REALITY, Vision 등의 지원 여부는 화면에 해당 옵션이 표시되는지만 볼 것이 아니라 실제 코어 버전과 매개변수로 확인해야 합니다. 두 코어 개발 흐름의 관계는 Xray-core와 V2Fly 차이 비교에서 더 자세히 확인할 수 있습니다.
V2Fly
V2Fly는 V2Ray 프로젝트의 커뮤니티와 코어 개발 흐름을 이어가며 Xray-core와 역사적 연관이 있지만, 이후 기능과 설정 세부 사항은 서로 달라졌습니다. 한 코어에서 불러올 수 있는 설정이라고 해서 다른 코어도 모든 항목을 지원하는 것은 아닙니다. Android용 v2flyNG는 이 개발 흐름에 해당하는 그래픽 클라이언트로 사용할 수 있으며, 선택하기 전에 구독에 필요한 프로토콜을 확인하세요.
그래픽 클라이언트
그래픽 클라이언트는 노드 목록, 구독 그룹, 프록시 전환, 로그 확인 등의 기능을 제공합니다. 예를 들면 데스크톱용 v2rayN과 Android용 v2rayNG가 있습니다. 일반적으로 사용자 설정을 코어 설정으로 변환하므로 메뉴 이름과 JSON 키가 그대로 일치하지 않을 수 있습니다. 인터페이스 앱 업데이트, 코어 업데이트, 규칙 파일 업데이트는 서로 다른 작업이므로 호환성 문제가 생기면 각각 확인하세요.
interface / traffic entry
클라이언트와 인터페이스
먼저 앱의 트래픽이 클라이언트로 전달되는지 확인한 다음, 코어가 어떤 출구를 통해 보내는지 확인하세요.
시스템 프록시
시스템 프록시는 운영체제 설정에 로컬 프록시 주소를 등록하며, 해당 설정을 읽는 앱에만 적용됩니다. 일부 명령줄 도구, 독립 네트워크 구성요소, 자체 프록시 설정을 사용하는 소프트웨어는 자동으로 따르지 않습니다. 활성화했는데도 브라우저가 직접 연결된다면 원격 노드가 작동하지 않는다고 단정하지 말고 앱의 프록시 설정과 로컬 수신 포트를 확인하세요.
TUN 모드
TUN은 가상 네트워크 인터페이스로 IP 패킷을 받은 뒤 프록시 프로그램에서 처리하며, 일반적으로 시스템 프록시와 적용 범위가 다릅니다. 실제 작동에는 시스템 권한, 라우팅, DNS 설정이 함께 필요하므로 스위치를 켰다고 처리 경로 전체가 구성된 것은 아닙니다. 다른 가상 네트워크 소프트웨어와 함께 사용할 때는 라우팅 충돌, 인터페이스 선택, 로컬 네트워크 접근을 중점적으로 확인하세요.
인바운드 · Inbound
인바운드는 코어가 연결을 받는 진입점으로, 브라우저에서 사용하는 로컬 HTTP 또는 SOCKS 수신 포트 등이 해당하며 설정에서는 inbounds로 표시됩니다. 수신 주소에 따라 진입점에 접근할 수 있는 기기가 결정되고, 포트는 앱 설정과 일치해야 합니다. 이 컴퓨터에서만 사용할 경우 로컬 수신을 유지하세요. 로컬 네트워크에 공개하기 전에는 접근 제어와 인증 요건을 명확히 해야 합니다.
아웃바운드 · Outbound
아웃바운드는 코어가 트래픽을 다음 경로로 보내는 방식을 정하며, 프록시 전달·직접 연결·차단 등이 해당하고 설정에서는 outbounds로 표시됩니다. 라우팅은 outboundTag로 아웃바운드를 참조합니다. 태그는 이름일 뿐이며, direct라는 태그 자체가 직접 연결 동작을 만들지는 않습니다. 규칙의 참조와 아웃바운드 정의가 일치하지 않으면 설정 오류가 발생하거나 예상과 다른 출구를 사용할 수 있습니다.
subscription / measurement
구독과 노드
설정 가져오기, 서버 연결, 테스트 결과는 각각 별도로 확인해야 합니다.
구독
구독은 노드 설정을 일괄적으로 가져오는 주소 또는 콘텐츠이며, 업데이트하면 보통 해당 그룹의 노드 목록이 새로고침됩니다. 업데이트 성공은 요청과 콘텐츠 처리가 완료됐다는 뜻일 뿐, 노드 연결이나 모든 노드의 사용 가능 여부를 보장하지 않습니다. 구독 주소에 접근 정보가 포함될 수 있으므로 공개하지 않는 것이 좋습니다. 업데이트에 실패하면 구독 업데이트 문제 해결 안내에서 주소, 네트워크, 형식 문제를 구분해 확인하세요.
노드
노드는 클라이언트에서 연결에 사용할 수 있는 서버 설정 묶음으로, 보통 주소, 포트, 프로토콜, 인증, 전송, 보안 설정이 포함됩니다. 표시 이름은 식별을 돕지만 이름에 적힌 지역이 실제 서버 위치나 출구 경로를 결정하지는 않습니다. 가져온 설정에 서버 이름이나 공개 키 등 필수 매개변수가 빠져 있으면 주소와 포트에 연결할 수 있어도 핸드셰이크가 완료되지 않을 수 있습니다.
지연 시간
지연 시간은 특정 테스트 방식으로 왕복 통신을 완료하는 데 걸리는 시간입니다. 수치를 보기 전에 어떤 항목을 측정했는지 확인하세요. TCP 포트 연결에 성공했다는 것은 해당 시점에 포트에 접근할 수 있다는 뜻일 뿐, 전체 프록시 요청 검증을 대신하지 않습니다. 지연 시간이 짧아도 처리량이 높다는 보장은 없습니다. 다운로드 속도는 대역폭, 패킷 손실, 대상 서비스, 경로 혼잡의 영향도 받습니다.
실제 연결 지연 시간
실제 연결 지연 시간은 일반적으로 선택한 프록시 설정으로 테스트 주소에 요청을 보내 완료 시간을 측정하는 값입니다. 구체적인 방식은 클라이언트 구현에 따라 다릅니다. 실제 연결 과정을 더 많이 반영할 수 있지만 테스트 대상, 제한 시간, 현재 네트워크 상태의 영향을 받습니다. 한 번 실패했다고 바로 노드를 사용할 수 없다고 판단하지 말고 로그를 확인하고 다른 대상으로 다시 테스트하세요. 처음 연결한다면 첫 연결 확인 절차를 참고하세요.
routing / name resolution
라우팅과 DNS
규칙은 경로를 선택하고 DNS는 이름을 해석합니다. 서로 영향을 주지만 같은 기능은 아닙니다.
라우팅 규칙과 트래픽 분기
트래픽 분기는 도메인, IP, 포트, 인바운드 등의 조건에 따라 연결에 사용할 아웃바운드를 선택하는 과정이며, 규칙은 일반적으로 설정된 순서대로 적용됩니다. 범위가 넓은 규칙을 너무 앞에 두면 뒤의 세부 조건이 적용되지 않을 수 있습니다. 일치하는 규칙이 없을 때 사용할 기본 출구도 확인해야 합니다. domainStrategy는 도메인이 언제 IP 조회에 사용될지에 영향을 줍니다. 예를 들어 IPIfNonMatch는 도메인 규칙에 일치하지 않은 뒤 IP를 조회해 다시 매칭합니다.
GeoIP
GeoIP는 태그별로 정리된 IP 주소 집합이며 geoip:private 같은 표현식으로 매칭할 수 있습니다. 태그는 데이터베이스에 포함된 주소 범위를 뜻하며 현재 연결의 실제 위치를 실시간으로 측정한 값이 아닙니다. 도메인 기반 연결이 IP 규칙에 일치하는지는 해석 전략의 영향도 받습니다. 데이터를 업데이트한 뒤에는 규칙이 실제로 사용 가능한 태그를 참조하는지도 확인하세요.
GeoSite
GeoSite는 용도, 서비스, 지역 등의 태그로 정리한 도메인 집합이며 geosite:cn 같은 형식으로 참조하는 경우가 많습니다. 도메인 매칭을 보조하지만 도메인을 IP로 해석하지는 않으며 특정 서비스의 모든 도메인을 포함한다고 보장할 수도 없습니다. 태그 지원 여부는 사용 중인 규칙 데이터베이스에 따라 달라집니다. 관련 파일 업데이트 방법은 GeoIP 및 GeoSite 업데이트 안내에서 확인하세요.
FakeDNS
FakeDNS는 앱에 가상 IP 주소를 반환하고 프로그램 내부에서 해당 주소와 원래 도메인의 대응 관계를 관리해, 이후 연결을 도메인 기준으로 처리할 수 있게 합니다. 이 주소는 대상 웹사이트의 실제 주소가 아니므로 연결은 대응 관계를 복원할 수 있는 처리 경로로 들어가야 합니다. DNS 처리만 켜고 트래픽을 함께 가로채지 않으면 접속이 실패할 수 있습니다. 모드를 전환한 뒤에는 시스템과 앱에 남은 이전 DNS 캐시도 확인하세요.
security / verification
보안과 암호화
인증, 전송 암호화, DNS 경로는 각각 따로 확인해야 하며 하나의 스위치로 모든 문제를 판단해서는 안 됩니다.
TLS
TLS는 암호화된 전송 채널을 만들고 인증서 등의 방식으로 상대방의 신원을 확인합니다. 서버 이름, 인증서 체인, 시스템 시간이 검증 결과에 영향을 줍니다. 이 중 serverName에는 서버 배포와 무관한 도메인을 임의로 입력하면 안 됩니다. 인증서 오류가 발생하면 이름, 시간, 서버 설정을 확인하고 인증서 검증을 건너뛰는 것을 장기적인 해결책으로 삼지 마세요.
REALITY
REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 독립적인 노드 프로토콜 이름은 아닙니다. 서버 이름, 공개 키, 짧은 ID 등의 클라이언트 매개변수는 서버 요구사항과 일치해야 하며 보안 유형만 REALITY로 바꿔서는 전환이 완료되지 않습니다. 핸드셰이크 방식과 적용 조건은 REALITY와 XTLS Vision 작동 원리에서 더 자세히 확인할 수 있습니다.
XTLS Vision
Vision은 VLESS에서 흔히 xtls-rprx-vision으로 표시되는 흐름 제어 방식으로, 조건에 맞는 TLS 트래픽 처리를 최적화하는 데 주로 사용됩니다. 지원되는 전송 방식과 TLS 또는 REALITY를 함께 사용해야 하며 클라이언트와 서버 모두 이를 지원해야 합니다. 독립적인 프로토콜도, 모든 연결을 빠르게 만드는 스위치도 아닙니다. 매개변수가 일치하지 않으면 먼저 연결 또는 핸드셰이크 문제가 나타납니다.
DNS 누수
DNS 누수는 도메인 조회가 예상한 해석 경로를 따르지 않는 현상입니다. 예를 들어 지정한 원격 DNS에서 처리해야 할 조회가 로컬 네트워크를 통과할 수 있습니다. 시스템 DNS, 브라우저의 보안 DNS, 클라이언트 내장 DNS, 트래픽 분기 규칙을 함께 확인해야 하며 검사 페이지에 표시된 해석기 이름만 보고 판단해서는 안 됩니다. 일부 도메인의 로컬 해석이 원래 허용된 설정이라면 해당 조회가 반드시 이상 동작인 것은 아닙니다. 실제 동작이 예상한 범위에 맞는지가 중요합니다.
용어를 실제 설정에 적용하기
먼저 문제가 어느 단계에 속하는지 확인한 뒤 관련 설정을 살펴보세요. 가져오기 성공, 포트 접근 가능, 프록시 요청 성공은 각각 따로 확인해야 하는 상태입니다.
아직 첫 연결을 완료하지 못했다면 구독 가져오기 및 프록시 모드 가이드부터 시작해 설정 확인, 노드 선택, 앱 요청 테스트 순서로 진행하세요. 연결은 되지만 일부 앱에서 적용되지 않는다면 관련 없는 항목을 계속 바꾸기보다 시스템 프록시, TUN, 인바운드, 라우팅을 먼저 대조하세요.
시간 초과, DNS 조회 실패, 클라이언트 오류가 발생하면 문제 해결에서 증상에 따라 확인하세요. 로그를 공유하기 전에는 구독 주소, 사용자 식별자, 비밀번호 등 인증 정보를 삭제하고 오류 유형, 발생 단계, 관련 설정 이름만 남기세요.