VMess
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 식별자로 인증하며 최신 설정에서는 보통 AEAD 방식을 사용합니다. 여러 전송 방식과 조합할 수 있으므로 VMess라는 이름만 보고 TCP나 WebSocket 중 어떤 연결을 사용하는지 알 수는 없습니다. 클라이언트와 서버의 인증 정보가 일치해야 하며, 시스템 시간이 크게 어긋나도 연결에 실패할 수 있습니다.
VLESS의 암호화 범위와 비교 →glossary
V2Ray 용어,한눈에 보기
연결 설정부터 트래픽 출구까지 계층별로 용어를 찾아보세요. 자주 쓰이는 개념 30가지를 뜻과 범위, 혼동하기 쉬운 점과 함께 설명합니다. 프로토콜 이름만으로 성능을 단정하지 않습니다.
설정을 살펴볼 때는 먼저 클라이언트, 코어, 프록시 프로토콜, 전송 계층, 보안 계층을 구분한 다음 구독 출처와 트래픽의 입구 및 출구를 확인하세요. 실제 설정 방법은 빠른 시작에서, 자세한 설명은 사용 안내서에서 확인할 수 있습니다.
protocols
연결 방식,프로토콜과 전송
프로토콜은 데이터 캡슐화와 인증 방식을, 전송 계층은 데이터를 전달하는 방식을, 보안 계층은 연결 보호를 담당합니다. 세 항목을 구분해 살펴보세요.
VLESS
VLESS는 프록시 데이터의 캡슐화와 인증을 담당합니다. 프로토콜 자체는 콘텐츠를 암호화하지 않으므로 보통 TLS 또는 REALITY와 함께 사용합니다. 사용자 식별자, 전송 유형, 보안 계층, 흐름 제어 매개변수가 맞아야 연결할 수 있습니다. 기존 노드에서 프로토콜 이름만 VLESS로 바꿔서는 안 되며, 서버도 이에 맞게 설정해야 합니다.
보안 계층 관련 용어 보기 →Trojan
Trojan은 일반적으로 TLS 연결을 기반으로 하며 비밀번호로 인증하는 프록시 프로토콜입니다. 서버 주소, 비밀번호, TLS 서버 이름은 각각 다른 용도로 사용됩니다. 비밀번호가 맞더라도 인증서 검증에 성공한다는 보장은 없습니다. 연결에 실패하면 인증 오류, TLS 핸드셰이크 오류, 하위 네트워크 연결 불가를 구분해 확인하세요.
TLS의 역할 알아보기 →Shadowsocks
Shadowsocks는 사전 공유 키를 사용하는 암호화 프록시 프로토콜입니다. 연결 양쪽에서 호환되는 암호화 방식과 키를 사용해야 합니다. 프로토콜 버전과 암호화 방식에 따라 필요한 매개변수가 다를 수 있으므로 이름이 비슷하다는 이유로 서로 바꿔 쓸 수는 없습니다. 가져온 설정의 암호화 방식은 유지하고, 문제 해결을 위해 임의로 변경하지 않는 것이 좋습니다.
노드 설정 항목 확인 →전송 계층
여기서 전송 계층은 프록시 프로토콜 데이터를 전달하는 연결 방식을 뜻합니다. TCP, WebSocket, gRPC 등이 있으며 프록시 프로토콜과는 다릅니다. WebSocket 경로와 요청 호스트, gRPC 서비스 이름은 연결에 필요한 값일 수 있습니다. 전송 방식은 서버 배포 설정에 따라 선택해야 하며, 서버 설정과 분리해 어느 방식이 더 빠른지 비교할 수는 없습니다.
전체 설정 설명 보기 →cores
인터페이스와 실행,코어와 클라이언트
인터페이스에서 옵션을 저장할 수 있다고 해서 현재 코어가 해당 옵션을 지원한다는 뜻은 아닙니다. 호환성 문제를 해결하려면 클라이언트와 실제로 실행 중인 코어를 함께 확인해야 합니다.
Project V
Project V는 V2Ray를 중심으로 형성된 오픈소스 프록시 도구 생태계로, 프로토콜과 설정 및 관련 구현을 포함합니다. 일상적으로 V2Ray라고 할 때는 이 생태계를 가리키기도 하고 코어 프로그램만 뜻하기도 합니다. 문맥을 살펴보고 생태계 이름을 특정 GUI 클라이언트로 오해하지 않도록 주의하세요.
생태계와 프록시 코어 구분하기 →프록시 코어
프록시 코어는 연결, 프로토콜 처리, DNS, 라우팅 규칙을 실제로 실행하는 프로그램입니다. GUI 클라이언트는 설정을 생성하고 코어를 실행합니다. 코어가 시작되지 않으면 인터페이스에 노드가 있어도 사용할 수 있는 로컬 프록시가 만들어지지 않습니다. 인터페이스의 옵션을 계속 바꾸기보다 실행 로그를 확인하면 어느 계층에서 실패했는지 파악하는 데 도움이 됩니다.
GUI 클라이언트의 역할 보기 →Xray
Xray는 V2Ray 관련 코드에서 발전한 오픈소스 프록시 코어로, VLESS, REALITY, XTLS Vision 등의 기능을 제공합니다. 실제 지원 기능은 코어 버전과 빌드, 설정 조합에 따라 달라지므로 코어 이름만 보고 모든 매개변수를 사용할 수 있다고 단정해서는 안 됩니다. v2rayNG는 Xray 코어를 사용합니다. 데스크톱 v2rayN은 현재 노드와 코어 설정을 함께 확인해야 합니다.
REALITY 매개변수 알아보기 →V2Fly
V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트이며, 코어는 보통 V2Fly Core라고 부릅니다. Xray와 같은 생태계에서 시작했지만 기능 발전 방향과 설정 지원은 완전히 같지 않습니다. v2flyNG는 V2Fly 코어를 사용하는 Android 클라이언트입니다. 특정 코어 기능을 사용하려면 설정이 해당 코어와 호환되는지 먼저 확인하세요.
Android 클라이언트 선택 보기 →GUI 클라이언트
GUI 클라이언트는 노드 목록, 구독 관리, 프록시 모드, 로그 등을 다루는 인터페이스를 제공해 설정을 직접 편집할 필요를 줄여줍니다. 이 사이트에서는 데스크톱용 v2rayN과 Android용 v2rayNG, v2flyNG를 소개합니다. 같은 설정도 클라이언트마다 이름과 위치가 다를 수 있으므로 현재 화면과 사용 중인 코어를 기준으로 확인하세요.
클라이언트와 플랫폼 확인 →subscription
설정 가져오기,구독과 노드
구독은 설정을 배포하고 노드는 연결 정보를 설명합니다. 테스트 결과는 한 번의 측정값일 뿐, 실제 앱에서의 연결을 확인해 주지는 않습니다.
구독
구독은 하나의 주소로 여러 노드 설정을 가져오고 업데이트하는 방식이며, 개별 노드와는 다릅니다. 구독 그룹을 추가한 뒤 업데이트해야 노드 목록에 표시되는 경우가 많습니다. 업데이트에 실패했다고 해서 기존 노드까지 사용할 수 없는 것은 아닙니다. 구독 링크에는 접속 정보가 포함될 수 있으므로 민감 정보로 보관하고, 로그를 공유할 때 함께 공개하지 마세요.
구독 가져오기 단계 보기 →노드
노드는 원격 프록시 서비스에 연결하기 위한 설정 묶음으로, 보통 주소, 포트, 프로토콜, 인증 정보, 전송 및 보안 설정을 포함합니다. 목록에 표시되는 이름은 노드를 구분하기 위한 것으로 연결 설정을 자동으로 바꾸지는 않습니다. 가져오기에 성공했다는 것은 클라이언트가 설정을 인식했다는 뜻일 뿐입니다. 서버 접속 여부와 인증 정보, 관련 매개변수가 올바른지 확인해야 합니다.
연결 테스트의 범위 확인 →공유 링크와 QR 코드
공유 링크는 노드 설정을 텍스트로 인코딩한 것이며, QR 코드는 보통 같은 텍스트를 다른 형태로 담습니다. 공유 링크 하나를 가져와도 구독처럼 설정이 자동으로 업데이트되지는 않으므로, 이후 설정이 바뀌면 다시 가져오거나 직접 수정해야 합니다. 링크와 QR 코드에 인증 정보가 포함될 수 있으니 화면을 공유할 때 전체 내용을 가리세요.
Android 가져오기 안내 보기 →지연 시간
지연 시간은 한 번의 왕복 테스트에 걸리는 시간입니다. 테스트 방식에 따라 측정 대상은 달라집니다. TCP 테스트는 주로 포트 연결에 걸리는 시간만 측정할 수 있으며, 프록시 인증이나 웹 요청까지 확인하지는 않습니다. 결과를 비교할 때는 같은 방식과 대상, 비슷한 네트워크 환경을 사용하세요. 지연 시간이 짧다고 대역폭이 높다는 뜻은 아닙니다.
실제 연결 지연 시간과 비교 →실제 연결 지연 시간
클라이언트의 실제 연결 지연 시간은 보통 프록시를 통해 테스트 대상에 연결하고 요청을 보내 측정하므로, 단순 포트 테스트보다 실제 사용 경로에 가깝습니다. 테스트 대상, DNS, 핸드셰이크, 네트워크 상태가 결과에 영향을 줄 수 있으며, 구체적인 측정 범위는 클라이언트 구현에 따라 다릅니다. 테스트 실패가 모든 대상에 연결할 수 없다는 뜻은 아니며, 테스트에 성공해도 모든 앱이 프록시를 사용한다는 보장은 없습니다.
앱 트래픽이 프록시를 거치는지 확인 →routing
트래픽 출구,라우팅과 분기
라우팅은 코어에 들어온 트래픽만 처리합니다. 규칙이 적용되는지는 순서와 조건, 당시 코어에서 확인할 수 있는 정보에 따라 달라집니다.
라우팅 규칙
라우팅 규칙은 도메인, IP, 포트, 프로토콜 등의 조건에 따라 트래픽의 출구를 선택합니다. 일반적인 설정에서는 규칙을 순서대로 확인해 처음 일치하는 항목을 적용합니다. 규칙 안의 여러 조건을 어떻게 조합하는지는 사용 중인 코어의 문법에 따라 다릅니다. 보통 구체적인 예외 규칙을 더 넓은 범위의 규칙보다 앞에 두고, 수정 후 로그에서 실제 출구를 확인하는 것이 좋습니다.
라우팅 설정 항목 보기 →GeoIP
GeoIP는 지역이나 유형별로 정리한 IP 주소 목록입니다. 예를 들어 규칙에서 geoip:cn을 참조할 수 있습니다. 이 규칙은 주소를 기준으로 일치 여부를 판단하며 도메인 접미사나 서비스 운영 회사의 등록 지역을 확인하지 않습니다. IP 할당과 데이터 목록은 바뀔 수 있으므로 규칙에 문제가 있으면 대상의 DNS 결과와 사용 중인 데이터의 적합성도 확인하세요.
GeoSite
GeoSite는 유형별로 정리한 도메인 목록이며 설정에서 geosite:cn 같은 태그로 참조하는 경우가 많습니다. 사이트가 위치한 국가를 매번 온라인으로 판단하는 기능이 아니라, 불러온 분류 데이터에 따라 도메인을 찾습니다. 분류 이름의 존재 여부와 포함된 도메인은 실제 데이터 파일에 따라 다릅니다. 태그를 올바르게 입력해도 해당 데이터가 있어야 사용할 수 있습니다.
트래픽 분기
트래픽 분기는 규칙에 따라 트래픽마다 다른 출구를 선택하는 기능입니다. 직접 연결, 프록시 사용, 차단 등이 가능합니다. ‘전역’이나 ‘중국 본토 우회’는 보통 클라이언트가 제공하는 라우팅 프리셋이지 새로운 프록시 프로토콜이 아닙니다. 전역 라우팅도 클라이언트에 들어온 트래픽에만 영향을 줍니다. 시스템 프록시를 따르지 않는 앱은 자체 네트워크 경로를 사용할 수 있습니다.
트래픽 입구와 출구 구분하기 →아웃바운드와 outboundTag
아웃바운드는 코어가 트래픽을 내보내는 방식이며, outboundTag는 정의된 아웃바운드의 태그를 참조합니다. 설정에 자주 등장하는 direct, proxy는 일반적으로 쓰이는 태그 이름일 뿐이며 실제 동작은 해당 아웃바운드 정의에 따라 달라집니다. 존재하지 않는 태그를 참조하거나 다른 설정의 이름을 가져다 쓰면 실행 오류나 예상치 못한 출구가 발생할 수 있습니다.
proxy / tun
트래픽 입구,시스템 프록시와 TUN
먼저 앱이 어떤 방식으로 트래픽을 클라이언트에 전달하는지 확인한 뒤 DNS와 라우팅을 살펴보세요. 트래픽 입구 설정과 라우팅 프리셋은 별개의 문제입니다.
시스템 프록시
시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정입니다. 이 설정을 따르는 앱만 트래픽을 로컬 프록시로 전달합니다. 브라우저, 터미널 도구, 게임마다 시스템 프록시 지원 여부가 다르므로 웹페이지가 열린다고 모든 프로그램이 프록시를 사용한다고 볼 수는 없습니다. Linux 데스크톱의 네트워크 프록시 설정과 명령줄 환경 변수도 각각 확인해야 합니다.
프록시 사용 설정 단계 보기 →로컬 SOCKS 및 HTTP 프록시
SOCKS와 HTTP는 클라이언트가 기기에서 제공하는 두 가지 프록시 연결 방식입니다. 앱에서 호환되는 유형, 주소, 포트를 사용해야 합니다. 127.0.0.1은 현재 기기 자체를 가리키며 원격 노드 주소가 아닙니다. 포트는 클라이언트의 실제 설정을 확인하세요. 프록시 측에서 도메인을 조회하는지는 프로토콜과 앱 구현에 따라 다르므로 SOCKS를 설정했다는 이유만으로 DNS 경로가 바뀌었다고 단정할 수 없습니다.
TUN 모드
TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 클라이언트 구성 요소에서 처리합니다. 보통 시스템 프록시보다 더 많은 트래픽을 다룰 수 있지만, 기기의 모든 트래픽이 반드시 프록시를 거친다는 뜻은 아닙니다. 권한, 시스템 라우팅, DNS, 제외 규칙이 관련될 수 있습니다. 사용 후 문제가 생기면 네트워크를 가로채는 다른 프로그램을 먼저 끄고 로그와 라우팅 변경 사항을 확인하세요.
TUN 설정 및 관리 보기 →FakeDNS
FakeDNS는 도메인 조회에 가상 IP를 반환하고 해당 주소와 원래 도메인의 매핑을 저장해 이후 연결 처리에 사용합니다. 가상 IP는 대상 서버의 실제 주소가 아니므로 트래픽 가로채기와 매핑 복원 기능이 함께 작동해야 합니다. FakeDNS로 조회한 뒤 연결이 가로채기 경로를 우회하면 앱이 가상 IP로 접속을 시도해 연결에 실패할 수 있습니다.
DNS 설정 항목 보기 →DNS 누출
DNS 누출은 도메인 조회가 예상한 경로로 전송되지 않고 다른 리졸버나 네트워크 출구에서 처리되는 현상입니다. 앱 자체의 암호화 DNS, 시스템 리졸버, 클라이언트 DNS가 동시에 사용될 수 있습니다. 웹 트래픽이 프록시를 거친다고 DNS 조회도 같은 경로를 사용한다는 보장은 없습니다. 문제를 확인할 때는 조회를 시작한 주체, 사용한 리졸버, 조회 연결의 출구를 각각 살펴보세요.
DNS 문제 해결 안내 보기 →security
인증과 보호,암호화와 보안 계층
인증 정보는 연결 상대의 신원을 확인하고 보안 계층은 전송을 보호합니다. 매개변수는 서버 설정과 일치해야 하며, 설정 오류를 감추기 위해 검증을 건너뛰어서는 안 됩니다.
TLS
TLS는 연결을 암호화하고 서버를 인증하며 전송 데이터의 무결성을 보호합니다. 일반적인 설정에서는 인증서로 서버의 신원을 확인합니다. 연결 주소와 인증서 검증에 사용할 서버 이름은 다를 수 있지만, 검증 이름은 인증서 및 서버 설정과 일치해야 합니다. 인증서 오류가 발생하면 시스템 시간, 서버 이름, 인증서 신뢰 체인을 확인하세요. 인증서 검증을 계속 건너뛰는 설정은 피해야 합니다.
서버 이름의 의미 알아보기 →REALITY
REALITY는 Xray가 제공하는 보안 계층 방식입니다. 클라이언트는 공개 키 등의 매개변수로 서버를 검증하며, 서버 도메인에 일반 인증서를 설치할 필요가 없습니다. 공개 키, 서버 이름, shortId 등의 매개변수는 서버 설정과 일치해야 하며 임의로 조합할 수 없습니다. REALITY는 프록시 프로토콜이 아니며, 모든 TLS 설정에 비해 연결 성능이 반드시 더 좋다는 뜻도 아닙니다.
VLESS와 역할 구분하기 →XTLS Vision
XTLS Vision은 특정 VLESS 설정에서 사용하는 Xray의 흐름 제어 방식입니다. 조건에 맞으면 TLS 트래픽의 중복 암호화 부담을 줄일 수 있습니다. 설정에 자주 쓰이는 흐름 제어 값은 xtls-rprx-vision입니다. 이는 별도의 전송 프로토콜이 아니며 REALITY와도 다릅니다. 사용하려면 클라이언트와 서버, 전송 방식의 조합이 모두 조건을 충족해야 합니다.
SNI와 serverName
SNI는 TLS 핸드셰이크에 포함되는 서버 이름 정보입니다. 클라이언트의 serverName 매개변수는 보통 핸드셰이크 이름과 인증서 검증에 관련됩니다. 노드의 연결 주소와 같은 값이 아니며, WebSocket 요청의 Host 필드와 단순히 바꿔 쓸 수도 없습니다. IP 주소로 연결하더라도 올바른 핸드셰이크를 위해 지정된 서버 이름을 입력해야 할 수 있습니다.
UUID와 인증 정보
UUID는 VMess 또는 VLESS의 사용자 식별자로 사용할 수 있으며, Trojan 비밀번호와 Shadowsocks 키는 다른 인증 방식을 사용합니다. UUID의 텍스트 형식만으로 노드의 품질을 판단할 수 없고 공개해도 된다는 뜻도 아닙니다. 노드 설정 전체가 있으면 다른 사람이 해당 서비스를 이용할 수 있습니다. 도움을 요청할 때는 인증 항목과 구독 링크, QR 코드를 가리고 민감하지 않은 오류 정보는 남기세요.
설정 및 문제 해결 문답 보기 →