VMess
VMess protocol
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 식별자 등의 매개변수로 인증합니다. V2Ray 설정과 구독 항목에서 자주 볼 수 있습니다. 설정할 때는 주소, 포트, 사용자 식별자, 전송 방식, 보안 옵션을 함께 확인해야 하며 프로토콜 이름만 봐서는 안 됩니다. 오래된 안내서의 호환성 매개변수가 현재 버전에 적용되지 않을 수 있습니다. 인증에 실패하면 기기의 시간이 정확한지도 확인하세요.
V2Ray / 설정 참고 자료
V2Ray 용어집
설정 주제별로 용어를 찾아보세요. 먼저 프로토콜, 전송 방식, 코어를 구분한 뒤 구독, 라우팅, DNS가 연결의 어느 부분을 제어하는지 확인하세요.
용어 26개를 정리했습니다. 각 항목에는 고유 앵커가 있어 문제 해결 기록에 링크를 복사해 사용할 수 있습니다. 실제 설정 이름과 기능 지원 여부는 현재 사용하는 클라이언트와 코어를 기준으로 확인하세요.
프로토콜 및 전송 방식
프로토콜, 전송 방식, 보안 메커니즘 구분하기
서버 설정 하나에 보통 이 세 가지 유형의 매개변수가 함께 들어갑니다. 프로토콜 이름이 같더라도 경로, 흐름 제어, 보안 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다.
VLESS
VLESS protocol
VLESS는 가벼운 프록시 프로토콜로, 자체적인 콘텐츠 암호화 계층은 제공하지 않으며 보통 TLS나 REALITY 같은 보안 메커니즘과 함께 사용합니다. 항목에 지정된 사용자 식별자, 흐름 제어, 전송 설정은 서버 설정과 일치해야 하며 다른 설정에서 그대로 가져다 쓸 수 없습니다. 클라이언트에서 해당 VLESS 설정을 사용할 수 있는지 확인하려면 실제 코어가 조합된 기능을 지원하는지도 살펴봐야 합니다.
Trojan
Trojan protocol
Trojan은 일반적으로 TLS로 연결을 보호하고 비밀번호로 프록시 인증을 수행합니다. 여기서 말하는 Trojan은 네트워크 프로토콜이며, 이름만으로 파일의 성격을 판단하는 것은 아닙니다. 비밀번호는 인증을 담당하고 서버 이름과 인증서 검증은 별도의 연결 검사를 수행하므로 서로 대신할 수 없습니다. 항목을 가져온 뒤 핸드셰이크 오류가 발생하면 인증서 검증을 바로 끄기보다 보안 설정과 인증 매개변수를 따로 확인하세요.
REALITY
REALITY transport security
REALITY는 Xray 생태계의 전송 보안 메커니즘이며 VLESS와 나란히 놓이는 독립적인 프록시 프로토콜은 아닙니다. 클라이언트에는 보통 서버에서 제공한 서버 이름, 공개 키, 짧은 ID 등의 매개변수가 필요하며 전송 방식과 코어 요구 사항도 충족해야 합니다. REALITY 공개 키를 사용자 식별자나 비밀번호 입력란에 넣지 마세요. 필드가 잘못되면 값이 온전해도 올바른 설정이 되지 않습니다.
전송 방식
Transport · TCP / WebSocket / gRPC
전송 방식은 프록시 연결에서 데이터를 전달하는 방법을 정하며, TCP, WebSocket, gRPC 등이 있습니다. VMess, VLESS 같은 프록시 프로토콜과는 서로 다른 계층입니다. 전송 방식을 선택한 뒤 경로, Host, 서비스 이름 등을 입력해야 할 수 있으며 서버 설정과 일치해야 합니다. 전송 방식 이름은 성능 순위가 아닙니다. 문제를 해결할 때는 먼저 매개변수가 일치하는지 확인한 다음 네트워크 환경과 구현 차이를 살펴보세요.
코어 및 클라이언트
설정을 실제로 처리하는 구성 요소 확인하기
그래픽 클라이언트는 설정을 관리하고 생성하며, 코어는 연결을 처리합니다. 인터페이스 프로그램 업데이트와 코어 업데이트는 서로 다른 작업일 수 있습니다.
Project V
Project V ecosystem
Project V는 네트워크 프록시 기능을 중심으로 형성된 오픈 소스 프로젝트 생태계입니다. V2Ray는 그 핵심 소프트웨어이며, 관련 도구는 인바운드, 아웃바운드, 라우팅을 조합해 연결을 처리합니다. 자료에 등장하는 Project V, V2Ray, V2Fly, Xray는 같은 계층의 이름이 아닙니다. 설정 예시를 참고할 때는 먼저 대상 프로젝트와 버전을 확인한 뒤 현재 클라이언트에서 해당 필드를 생성하거나 불러올 수 있는지 살펴보세요.
V2Fly
V2Fly / V2Ray core
V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트이며, 일상적인 대화에서는 해당 코어 분기를 가리키는 이름으로도 쓰입니다. 코어는 설정을 해석하고 연결을 구축하며 라우팅을 수행합니다. 구독 버튼을 제공하는 그래픽 인터페이스와는 다릅니다. 두 설정이 모두 V2Ray 설정으로 표시되더라도 형식과 기능 지원 범위를 확인하세요. 다른 코어에서 추가된 필드를 그대로 사용할 수 있다고 가정하지 마세요.
Xray-core
Xray core
Xray-core는 V2Ray에서 파생된 독립 코어 프로젝트로, 프록시 프로토콜, 전송, 인바운드, 아웃바운드, 라우팅 등을 실제로 처리합니다. V2Fly와 공통된 배경이 있지만 이후 기능, 필드, 호환 범위가 완전히 같지는 않습니다. 클라이언트에서 코어를 바꿀 수 있더라도 변경 전에 현재 항목의 프로토콜 확장과 사용자 지정 설정을 확인하세요. 코어 교체를 일반적인 연결 문제 해결법으로 간주해서는 안 됩니다.
v2rayN
Windows / macOS / Linux
v2rayN은 서버 관리, 구독 업데이트, 시스템 프록시, 라우팅 설정 등을 제공하는 데스크톱 그래픽 클라이언트이며, 연결 처리는 함께 제공되는 구성 요소에 맡깁니다. 데스크톱 버전과 클래식 WPF 버전은 인터페이스가 다르므로 사용 중인 버전에 맞는 메뉴와 기능을 확인해야 합니다. 문제를 해결할 때는 “V2Ray가 연결되지 않음”이라고만 기록하기보다 클라이언트 이름, 코어 유형, 프록시 모드를 각각 기록하면 원인을 찾기 쉽습니다.
v2rayNG
Android · Xray
v2rayNG는 Android 그래픽 클라이언트입니다. 이 페이지에서는 Xray 코어 사용 사례를 설명하며, 시스템 VPN 인터페이스를 통해 앱 연결을 처리하는 경우가 많습니다. 시스템 권한, 앱별 프록시 설정, 제조사의 백그라운드 제한이 실제 동작에 영향을 줄 수 있으므로 서버 항목만 확인해서는 안 됩니다. 상태 표시줄에 VPN 아이콘이 보이는 것은 트래픽 처리 인터페이스가 설정되었다는 뜻일 뿐, 원격 서버, DNS, 대상 사이트까지 모두 연결되었다는 의미는 아닙니다.
v2flyNG
Android · V2Fly
v2flyNG는 V2Fly 코어를 사용하는 Android 그래픽 클라이언트로, 코어 요구 사항에 따라 선택할 수 있는 대안입니다. v2rayNG와 이름이 비슷하고 가져오기나 연결 과정 일부도 유사하지만, 프로토콜 확장을 똑같이 지원한다는 뜻은 아닙니다. 설정을 옮길 때는 먼저 코어 호환성을 확인하고 구독 파싱과 프록시 설정을 살펴보세요. 인터페이스가 비슷하다고 설정까지 반드시 호환되는 것은 아닙니다.
구독 및 노드
설정 출처와 연결 테스트 구분하기
구독 업데이트 성공, 서버 항목 존재, 테스트 주소 접속 성공은 각각 다른 확인 결과이며 서로 대신할 수 없습니다.
구독
Subscription
구독은 원격 주소에서 서버 설정 목록을 받아 배포하는 방식입니다. 클라이언트가 업데이트를 수행한 뒤 항목을 파싱하고 저장합니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 스크린샷, 로그, 문의 글에 전체 주소가 노출되지 않도록 하세요. 업데이트 성공은 이번에 데이터를 가져와 파싱했다는 뜻일 뿐, 모든 항목의 연결 가능성을 보장하지 않습니다. 항목이 비어 있다면 그룹의 필터 조건과 응답 형식도 확인하세요.
노드
Server profile
노드는 보통 클라이언트에 등록된 서버 설정 항목을 뜻하며 주소, 포트, 프로토콜, 인증, 전송 등의 매개변수를 포함합니다. 독립된 물리 서버 한 대에 해당한다고 볼 수는 없습니다. 표시 이름은 구분을 위한 라벨일 뿐, 실제 접속 위치나 경로 구조를 증명하지 않습니다. 특정 노드를 점검할 때는 이름이나 아이콘, 한 번의 테스트 결과만으로 상태를 판단하지 말고 설정 필드와 연결 로그를 확인하세요.
구독 그룹
Subscription group
구독 그룹은 구독 출처와 관련 서버 항목을 정리하는 데 사용하며, 클라이언트는 그룹별로 업데이트 주소, 필터 조건, 자동 업데이트 정책을 저장할 수 있습니다. 그룹 이름 자체는 라우팅 규칙이 아니며 자동 장애 조치나 로드 밸런싱을 의미하지도 않습니다. 구독 업데이트 후 항목 수가 크게 바뀌었다면 다시 가져오기 전에 해당 그룹의 필터 조건과 업데이트 결과를 확인하세요. 수동으로 조정한 항목이 덮어쓰이지 않도록 주의해야 합니다.
지연 시간
Latency
지연 시간은 지정한 테스트에 걸린 시간으로, 테스트 방식과 대상, 측정 시작점 및 종료점을 함께 고려해야 합니다. TCP 연결과 웹페이지 요청 한 건의 완료는 같은 측정이 아닙니다. 연결 시간이 짧다고 해서 지속적인 다운로드 속도가 빠르다고 단정할 수 없으며 처리량 테스트를 대신할 수도 없습니다. 결과를 비교할 때는 같은 대상과 테스트 방식을 사용하고 네트워크 변동을 고려하세요. 한 번 측정한 값으로 장기적인 성능을 판단하지 마세요.
실제 연결 지연 시간
Real connection latency
실제 연결 지연 시간은 보통 클라이언트가 선택한 프록시를 통해 테스트 주소에 접속해 소요 시간을 기록하는 값으로, 서버 포트만 확인하는 것보다 실제 프록시 요청에 가깝습니다. 그래도 결과는 DNS, 핸드셰이크, 테스트 대상, 구현 방식에 영향을 받습니다. 클라이언트마다 측정값이 다를 수 있으므로 서로 직접 비교하기 어렵습니다. 테스트가 실패하면 프록시 경로 문제와 대상 사이트 접속 불가를 구분하세요. 테스트에 성공해도 모든 앱이 프록시를 사용한다는 뜻은 아닙니다.
라우팅 및 트래픽 분기
연결이 어디로 들어오고 어디로 나가는지 확인하기
시스템 프록시는 일부 앱의 연결 유입 방식을 제어합니다. 연결이 코어로 들어온 뒤에는 라우팅 조건이 아웃바운드를 결정합니다. 계층별로 먼저 확인한 다음 규칙을 수정하세요.
라우팅 규칙
routing.rules / outboundTag
라우팅 규칙은 도메인, IP, 포트, 인바운드 등의 조건에 따라 아웃바운드를 선택합니다. 규칙의 outboundTag는 정의된 아웃바운드 태그를 가리킵니다. 코어는 보통 규칙을 순서대로 확인하며 먼저 일치하는 규칙이 연결 경로를 결정합니다. 같은 규칙 안에서 조건을 어떻게 조합하는지는 코어 문서에서 확인해야 합니다. 일치하는 규칙이 없으면 해당 설정의 기본 동작을 따릅니다. 따라서 문제를 해결할 때는 규칙 순서, 태그 존재 여부, 기본 아웃바운드를 함께 확인하세요.
트래픽 분기
Traffic routing
트래픽 분기는 조건에 따라 연결별로 프록시, 직접 연결, 차단 등의 아웃바운드를 선택하는 방식입니다. 대상 도메인이나 주소, 그 밖에 식별 가능한 정보를 기준으로 판단할 수 있습니다. 클라이언트의 “전역” 표시는 보통 라우팅 사전 설정의 하나이며, 모든 앱의 트래픽이 클라이언트로 들어왔다는 뜻은 아닙니다. 트래픽 분기를 확인할 때는 먼저 연결 유입 방식을 확인한 뒤 대상이 어떤 규칙과 일치하는지 살펴보세요. 트래픽이 유입되지 않는 문제를 라우팅 오류로 오인하지 않도록 주의하세요.
GeoIP
geoip:cn
GeoIP는 라우팅 규칙에서 참조하는 IP 주소 데이터 모음으로, 보통 지역이나 용도별로 분류됩니다. 예를 들어 geoip:cn은 해당 데이터의 주소 모음을 참조합니다. 도메인 문자열이 아니라 IP를 기준으로 일치하며, 도메인을 먼저 조회해야 하는지는 라우팅의 도메인 처리 정책에 따라 다릅니다. 데이터 버전, 대상의 DNS 조회 결과, IP 주소의 소속 변경이 모두 규칙 일치 결과에 영향을 줄 수 있습니다. 분류 라벨을 실시간 위치 정보로 간주해서는 안 됩니다.
GeoSite
geosite:category-ads-all
GeoSite는 라우팅에서 참조하는 도메인 데이터 모음으로, 서비스, 사이트, 용도별로 분류할 수 있습니다. 예를 들어 geosite:category-ads-all은 특정 분류의 도메인 목록을 참조합니다. 해당 분류의 존재 여부와 포함 도메인은 현재 불러온 데이터 파일에 따라 다르므로 라벨 이름만 보고 범위를 추측할 수 없습니다. 규칙이 적용되지 않는다면 데이터가 제대로 로드되었는지, 분류를 사용할 수 있는지, 앞선 규칙이 먼저 일치했는지 확인하세요.
시스템 프록시
System proxy
시스템 프록시는 운영체제가 앱에 제공하는 프록시 주소 설정입니다. 클라이언트가 이 주소를 로컬 수신 포트로 지정하면 해당 설정을 따르는 앱이 연결을 프록시로 전달할 수 있습니다. 일부 프로그램은 자체 프록시 설정을 사용하거나 직접 연결하므로 시스템 프록시를 켜도 기기 전체의 트래픽이 처리되는 것은 아닙니다. 시스템 프록시와 코어 라우팅의 “전역” 모드는 서로 다른 계층입니다. 클라이언트를 종료한 뒤에도 인터넷에 연결되지 않으면 시스템 프록시 설정이 남아 있는지 확인하세요.
DNS 및 TUN
DNS 조회 경로와 트래픽 처리 범위 확인하기
DNS는 주소를 조회하는 방법을 정하고, TUN은 일부 연결을 받아들이는 방식을 정합니다. FakeDNS와 스니핑은 이후 처리에 필요한 도메인 정보를 제공합니다.
DNS
Domain Name System
DNS는 도메인을 IP 주소 등의 레코드로 변환합니다. 브라우저, 운영체제, 프록시 코어가 각각 DNS 쿼리를 보내고 캐시를 관리할 수 있습니다. 설정된 DNS 서버, 쿼리의 아웃바운드, 도메인 처리 정책이 함께 연결 결과에 영향을 주므로 DNS 주소 하나만 바꿔도 모든 앱의 조회 경로가 바뀌는 것은 아닙니다. 문제를 해결할 때는 먼저 누가 쿼리를 보내고 어느 아웃바운드를 사용하는지 확인한 다음, 조회 실패와 부적절한 주소, 연결 실패를 구분하세요.
TUN 모드
TUN virtual network interface
TUN 모드는 가상 네트워크 인터페이스로 IP 패킷을 받아 프록시 구성 요소로 전달합니다. 시스템 프록시를 따르지 않는 일부 프로그램도 처리할 수 있습니다. 실제로 처리되는 범위는 시스템 라우팅, 제외 항목, 권한, 구성 요소 구현에 따라 달라지며, TUN을 켰다고 모든 연결이 프록시 아웃바운드로 나가는 것은 아닙니다. 처음 설정할 때는 DNS와 루프백 우회를 함께 확인하고, 여러 VPN이나 가상 네트워크 구성 요소가 기본 경로를 두고 충돌하지 않도록 주의하세요.
FakeDNS
Fake DNS
FakeDNS는 앱에 가상 주소를 반환하고 가상 주소와 원래 도메인의 매핑을 관리합니다. 이후 프록시 구성 요소가 도메인을 복원해 연결을 처리합니다. 트래픽 가로채기와 매핑 복원이 함께 동작해야 하므로, 일반 공용 DNS 주소처럼 설정한 뒤 모든 프로그램에서 사용할 수 있다고 기대해서는 안 됩니다. 앱에 이전 캐시가 남아 있거나 관련 트래픽이 프록시를 우회하면 가상 주소가 제대로 처리되지 않을 수 있습니다. 설정을 바꾼 뒤에는 DNS 조회와 연결 경로를 다시 확인하세요.
DNS 누출
DNS leak
DNS 누출은 DNS 쿼리가 예상한 경로나 리졸버를 벗어나는 현상입니다. 예를 들어 지정한 아웃바운드를 통해 조회하려 했지만 실제로는 앱이 다른 리졸버에 직접 쿼리를 보낼 수 있습니다. 누출 여부는 의도한 정책을 기준으로 판단해야 합니다. 직접 연결하는 도메인을 로컬에서 조회하는 것이 반드시 잘못된 설정은 아닙니다. 점검할 때는 시스템 DNS, 브라우저의 암호화 DNS, 앱 내장 DNS, 프록시 DNS를 모두 살펴보세요. 한 번의 검사 페이지 결과만으로 모든 앱의 동작을 확인할 수는 없습니다.
트래픽 스니핑
sniffing
트래픽 스니핑은 연결 초기 데이터에서 프로토콜이나 확인 가능한 대상 도메인 정보를 찾아 라우팅에 참고할 수 있도록 합니다. 코어에 유입될 때 대상 IP만 있는 연결에 자주 사용됩니다. 암호를 해독하는 기능은 아니며 모든 암호화 트래픽에서 도메인을 복원할 수 있는 것도 아닙니다. 결과는 트래픽 특성과 구현 방식에 따라 달라집니다. 라우팅 판단에 사용하는 옵션과 연결 대상 변경을 제어하는 옵션은 서로 다를 수 있으므로 현재 코어 문서를 확인해 설정하세요.