VMess
VMess ProtocolProject V 생태계의 프록시 프로토콜로, 인증과 데이터 보호 기능을 제공하며 노드 설정에는 대개 사용자 ID가 포함됩니다. VMess는 여러 전송 방식과 조합할 수 있지만, 프로토콜이 같다고 다른 설정까지 같은 것은 아닙니다. 설정을 가져온 뒤에는 서버에서 제공한 값을 그대로 유지하고 기기의 시간을 정확하게 맞춰야 시간 차이로 인증이 실패하는 일을 막을 수 있습니다.
V2Ray / 클라이언트 용어 색인
V2Ray 용어 정리
프로토콜, 코어, 실행 모드는 같은 설정 화면에 함께 표시되곤 하지만 각각 하는 일은 다릅니다. 이 페이지에서는 자주 쓰는 용어를 다섯 가지로 나눠 뜻과 클라이언트 설정에서의 역할을 설명합니다. 각 항목에는 바로 이동할 수 있는 링크가 있어 저장하거나 공유하기 편리합니다.
프로토콜, 전송 보안, 코어를 구분한 다음 설정 호환성을 확인하세요. 이 페이지에서는 항목과 개념을 설명합니다. 단계별 설정 방법은 클라이언트 설정 가이드에서, 설계 차이와 선택 기준은 프로토콜·코어 기술 참고 자료에서 확인하세요.
프로토콜·전송
프로토콜은 양쪽에서 프록시 데이터를 주고받는 방식을 정하고, 전송 방식은 데이터를 전달하는 방법을 정합니다. TLS와 REALITY는 전송 보안을 담당합니다. 노드 이름에 여러 키워드가 함께 있는 것은 자연스러운 일이며, 서로 바꿔 쓸 수 있는 설정으로 보면 안 됩니다.
VLESS
VLESS Protocol간결한 구조의 프록시 프로토콜로, 프로토콜 자체에는 완전한 전송 암호화 기능이 없어 실제 환경에서는 TLS 또는 REALITY와 함께 사용하는 경우가 많습니다. 클라이언트의 사용자 ID, 전송 방식, 흐름 제어, 보안 설정은 서버 설정과 맞아야 합니다. VMess 노드의 유형을 VLESS로 바꾸는 것만으로 전환이 완료되지는 않습니다. 두 프로토콜은 각각 유효한 서버 설정이 필요합니다.
Trojan
Trojan Protocol일반적으로 TLS 연결을 기반으로 하며 비밀번호로 인증하는 프록시 프로토콜입니다. 비밀번호가 맞는 것만으로는 충분하지 않으며 서버 이름, 인증서 검증, 전송 설정도 일치해야 합니다. 핸드셰이크 오류가 발생하면 비밀번호만 반복해서 바꾸기보다 인증 정보와 TLS 설정을 따로 확인하세요.
Shadowsocks
SS / Shadowsocks사전 공유 키와 지정된 암호화 방식을 사용하는 프록시 프로토콜로, SS라고 줄여 부르기도 합니다. 암호화 방식은 클라이언트에서 성능을 위해 임의로 고르는 옵션이 아니며 서버 설정과 일치해야 합니다. 프로토콜 버전에 따라 키 형식과 기능 요구사항이 다를 수 있으므로 가져오기에 실패하면 클라이언트와 코어가 해당 방식을 지원하는지 먼저 확인하세요.
REALITY
전송 보안Xray 생태계의 전송 보안 방식입니다. 흔히 VLESS와 REALITY를 조합해 사용하므로 VLESS와 같은 계층의 프록시 프로토콜은 아닙니다. 설정에는 공개 키, 서버 이름, 짧은 ID 등이 포함되며 세부 항목은 클라이언트 화면에 따라 다를 수 있습니다. 하나의 유효한 설정에 함께 포함된 값을 사용하고, 여러 노드에서 항목을 가져와 조합하지 마세요.
TLS
Transport Layer Security연결을 암호화하고 상대를 인증하는 보안 프로토콜로, 브라우저에서 HTTPS에 접속할 때도 사용합니다. 노드의 연결 주소와 TLS 서버 이름은 서로 다를 수 있으며, 서버 이름은 보통 인증서 검증에 사용됩니다. 인증서 오류가 발생하면 이름, 시스템 시간, 인증서 상태를 먼저 확인하고, 검증 생략을 상시 해결책으로 사용하지 마세요.
코어·생태계
클라이언트는 설정을 조작하는 창구이고, 코어는 실제 네트워크 설정을 실행하는 프로그램입니다. 화면에 어떤 항목이 표시된다고 해서 선택한 코어가 해당 기능을 실행할 수 있는 것은 아닙니다. 호환성을 비교할 때는 클라이언트 버전, 코어 종류, 구체적인 기능을 함께 확인해야 합니다.
Project V
V2Ray 관련 오픈 소스 생태계V2Ray 등의 구성 요소를 중심으로 발전한 오픈 소스 네트워크 도구 생태계로, 하나의 통일된 화면을 가진 데스크톱 프로그램을 뜻하지는 않습니다. v2rayN 같은 그래픽 클라이언트는 구독 관리, 노드 선택, 프록시 켜기·끄기를 조작할 수 있는 화면으로 제공하고, 실제 실행은 코어에 맡깁니다. 이 관계를 이해하면 화면 설정 문제와 코어 실행 문제를 구분하기 쉽습니다.
Xray
Xray-core / 네트워크 코어V2Ray 관련 코드에서 파생되어 독자적인 기능 개발이 이어진 코어입니다. REALITY 등의 기능은 Xray 생태계와 밀접하게 관련되어 있습니다. v2rayNG는 Xray를 사용하며, v2rayN은 설정을 확인해 실제로 사용하는 코어를 파악해야 합니다. 두 코어가 일부 개념을 공유하더라도 고급 설정이나 전체 설정이 바로 호환된다고 보장할 수는 없습니다.
V2Fly
V2Ray Core / 커뮤니티 유지보수 프로젝트V2Ray 코어를 이어서 유지보수하는 커뮤니티 프로젝트입니다. 클라이언트에서 해당 코어를 소문자 v2fly로 표시하기도 합니다. v2flyNG는 이 코어를 사용하는 안드로이드 클라이언트 대안으로, 기존 설정이 코어와 맞는 경우에 적합합니다. 선택할 때는 실제 프로토콜과 전송 방식 지원 여부를 확인하고, 코어 이름만으로 어느 쪽이 더 적합한지 판단하지 마세요.
클라이언트 설정
이 옵션은 앱 트래픽이 클라이언트에 들어오는 방식과 로컬 프록시 진입점에 접근할 수 있는 대상을 결정합니다. 트래픽이 클라이언트에 들어온 뒤에도 라우팅 규칙에 따라 출구가 선택됩니다. 따라서 프록시를 켜는 것과 전역 라우팅을 선택하는 것은 별개의 작업입니다.
시스템 프록시
System Proxy운영체제가 앱에 제공하는 프록시 설정으로, 이 설정을 따르는 앱만 사용합니다. v2rayN의 ‘시스템 프록시 자동 설정’은 일반적으로 시스템 프록시가 로컬 리스너를 가리키게 합니다. 기기의 모든 연결을 가로채는 기능은 아닙니다. 특정 앱이 여전히 직접 연결된다면 먼저 시스템 프록시를 지원하는지 확인한 뒤 앱 자체 프록시 설정이나 다른 연결 방식을 고려하세요.
TUN 모드
Virtual Network Interface가상 네트워크 인터페이스로 시스템 IP 트래픽을 받아 코어에서 처리하는 실행 방식으로, 일반적으로 시스템 프록시만 사용하는 것보다 더 많은 앱에 적용됩니다. 실제 적용 범위는 시스템 라우팅, 실행 권한, DNS 설정에 따라 달라지므로 모든 연결이 반드시 같은 출구를 사용한다고 볼 수는 없습니다. 다른 가상 네트워크 도구와 함께 사용할 때는 라우팅 충돌도 확인해야 합니다.
로컬 리스너
Local Listener / SOCKS / HTTP브라우저나 다른 앱이 연결할 수 있도록 클라이언트가 기기에서 여는 프록시 진입점입니다. SOCKS와 HTTP가 일반적인 진입점 유형입니다. 리슨 주소는 접근 가능한 기기를 결정하고 포트 번호는 진입점을 사용하는 앱의 설정과 일치해야 합니다. 로그에 포트 사용 중 오류가 표시되면 원격 노드를 바꾸기 전에 클라이언트가 중복 실행 중인지 확인하세요.
LAN 연결 허용
LAN Access같은 LAN에 있는 다른 기기가 이 기기의 프록시 진입점에 접속하도록 허용하는 설정입니다. 현재 클라이언트가 LAN 기기에 연결하도록 하는 스위치가 아닙니다. 설정을 켠 뒤에는 올바른 리슨 주소와 방화벽 규칙이 필요하며, 다른 기기에는 이 컴퓨터의 LAN 주소를 입력해야 합니다. 이 기기에서만 사용한다면 보통 켤 필요가 없습니다. 공유할 때는 접근 범위를 제한하고 인증 사용도 고려하세요.
구독·노드
구독은 설정을 여러 개 가져오는 데 사용하고, 노드는 하나의 구체적인 연결 설정을 의미합니다. 테스트는 연결 상태를 확인하는 기능입니다. 구독 업데이트, 노드 선택, 테스트 실행은 서로 대체할 수 없으므로 문제가 생기면 어느 단계에서 실패했는지 먼저 확인하세요.
구독
Subscription여러 노드 설정을 가져오고 이후 업데이트하는 데 사용하는 주소 또는 데이터로, 클라이언트가 지원하는 형식에 따라 내용을 해석합니다. 구독 업데이트에 성공했다는 것은 설정을 가져와 해석했다는 뜻일 뿐, 모든 노드의 연결을 보장하지는 않습니다. 링크에 계정 식별 정보가 포함될 수 있으므로 공개하지 마세요. 업데이트에 실패하면 먼저 주소가 완전한지 확인한 뒤 로그에서 연결 오류나 형식 오류를 살펴보세요.
노드
Node / Server Profile클라이언트에서 원격 서버에 연결하는 데 필요한 설정 묶음으로, 서버 주소만을 뜻하지는 않습니다. 전체 설정에는 포트, 사용자 ID 또는 비밀번호, 전송 방식, TLS 또는 REALITY 설정이 포함될 수 있습니다. 노드 메모는 식별을 돕는 이름일 뿐, 실제 위치나 프로토콜 기능, 연결 품질을 판단하는 근거가 되지 않습니다.
구독 그룹
Subscription Group클라이언트에서 구독과 노드를 출처나 용도별로 정리하는 관리 단위로, 설정 업데이트와 필터링, 정리에 유용합니다. 그룹 메모는 일반적으로 연결 인증에 사용되지 않으며 특정 사이트의 출구를 자동으로 바꾸지도 않습니다. 그룹을 삭제하기 전에 노드도 함께 삭제되는지, 나중에 원래 구독 주소가 필요한지 확인하세요. 정리 작업을 연결 설정 변경으로 오해하지 않도록 주의해야 합니다.
지연 시간
Latency특정 테스트 방식에서 요청을 보내고 응답을 받기까지 걸리는 시간이며, 보통 밀리초로 표시합니다. ICMP, TCP, HTTP 테스트는 측정하는 구간이 다르므로 같은 방식과 대상으로 비교해야 합니다. 지연 시간이 짧다고 다운로드 속도가 반드시 빠른 것은 아닙니다. 시간 초과도 테스트 대상이나 방식의 제한 때문에 발생할 수 있으므로 그것만으로 노드가 작동하지 않는다고 단정할 수 없습니다.
실제 연결 지연 시간
Real Connection Latency현재 프록시 설정으로 테스트 대상에 실제 요청을 보내 측정한 시간입니다. 포트 연결만 확인하는 테스트보다 앱 요청에 가까운 결과를 얻을 수 있습니다. 구체적인 측정 범위는 클라이언트 구현에 따라 달라지며 프록시 핸드셰이크, DNS, 대상의 응답 시간이 포함될 수 있습니다. 결과는 해당 시점의 연결 경로만 보여 주므로 장시간 사용 경험을 대신하거나 다운로드 속도를 직접 예측하지는 못합니다.
라우팅·DNS
라우팅은 연결의 경로를 처리하고 DNS는 도메인 이름을 해석하며, 두 기능은 서로 영향을 줍니다. 문제를 확인할 때는 도메인이 주소로 변환되는 과정, 연결이 규칙과 일치하는 과정, 최종 출구를 각각 추적해야 합니다. 한 곳만 바꾼 뒤 전체 경로가 바뀌었다고 판단하지 마세요.
라우팅 규칙
Routing Rules도메인, IP, 포트 등의 조건에 따라 연결의 출구를 선택하는 규칙 모음입니다. 출구는 직접 연결, 프록시, 차단 중 하나일 수 있습니다. 일반적인 코어는 순서대로 규칙을 확인해 처음 일치하는 규칙을 적용하므로, 앞에 있는 포괄적인 규칙이 뒤의 구체적인 규칙을 가릴 수 있습니다. 규칙을 수정할 때는 대상 도메인이 목록에 있는지만 보지 말고 일치 조건, 순서, 기본 출구를 함께 확인하세요.
분할 라우팅
Traffic Splitting연결마다 서로 다른 출구를 할당하는 방식으로, 라우팅 결과를 설명하는 용어이지 암호화 프로토콜은 아닙니다. 클라이언트의 ‘중국 본토 우회’, ‘블랙리스트’, ‘전역’ 등의 프리셋은 라우팅 정책을 묶어 간편하게 선택하도록 해 줍니다. 프리셋의 규칙은 버전이나 설정에 따라 달라질 수 있으므로 세밀하게 제어하려면 실제 규칙을 확인해야 합니다.
GeoIP
IP Address Dataset라우팅 규칙에서 참조하는 IP 주소 목록으로, 지역이나 기타 속성에 따라 분류하는 경우가 많습니다. 분류는 데이터베이스를 바탕으로 하며 서버의 실제 위치를 실시간으로 측정한 결과가 아닙니다. 주소 할당이나 공유 인프라의 변화도 판단에 영향을 줄 수 있습니다. 도메인 연결에서 IP를 먼저 확인한 뒤 규칙과 비교할지는 코어의 도메인 해석 방식에 따라 달라집니다.
GeoSite
Domain Dataset서비스, 용도, 기타 분류에 따라 정리한 도메인 목록으로, 라우팅에서 도메인을 일치시키는 데 사용합니다. IP를 분류하는 GeoIP와는 다릅니다. 규칙이 적용되려면 일반적으로 코어가 대상 도메인을 알아야 하므로 대상 IP만 있는 경우에는 일치하지 않을 수 있습니다. 사이트 하나가 여러 리소스 도메인을 사용할 수도 있으므로 페이지 본문은 열리는데 이미지가 표시되지 않는다면 관련 도메인의 경로도 확인해야 합니다.
DNS
Domain Name System도메인을 IP 주소 등의 레코드로 변환하는 시스템으로, 운영체제, 브라우저, 프록시 코어가 각각 DNS 조회에 관여할 수 있습니다. 클라이언트의 직접 DNS와 원격 DNS는 보통 서로 다른 상황에 사용되지만, 항목 이름만으로 조회가 지정된 출구를 통과한다고 보장할 수는 없습니다. 설정을 확인할 때는 리졸버 주소, 조회 경로, 결과가 이후에 어떻게 쓰이는지를 구분해 살펴보세요.
FakeDNS
Synthetic IP Mapping도메인에 가상 IP를 할당하고 매핑 정보를 저장하는 방식입니다. 이후 해당 주소로 연결할 때 코어가 원래 도메인 정보를 복원할 수 있습니다. 트래픽 가로채기와 라우팅을 함께 설정해야 하며, 반환된 가상 주소를 원격 서버의 실제 주소로 보면 안 됩니다. 모드를 전환한 뒤에도 앱이 이전 매핑을 사용한다면 DNS 캐시를 비우거나 연결을 다시 설정해야 할 수 있습니다.
DNS 누출
DNS LeakDNS 조회가 예상한 경로로 전송되지 않아 의도하지 않은 경로에서 처리되는 현상입니다. 검사 페이지에 표시되는 리졸버 이름은 실제 분할 라우팅 설정과 함께 판단해야 하며, 이름이 다르다는 이유만으로 설정 오류라고 단정할 수는 없습니다. 브라우저의 보안 DNS, 시스템 DNS, 코어 DNS, 조회 출구를 모두 확인하세요. 의도적으로 직접 연결하는 도메인의 조회와 예상치 못한 우회는 구분해야 합니다.