프로토콜과 전송 방식
VMess
프록시 프로토콜 · 사용자 식별자 인증
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 식별자를 통해 인증하며 자체적인 프로토콜 보안 메커니즘을 포함합니다. 기기 시간이 크게 어긋나면 인증에 영향을 줄 수 있으므로, 연결 문제를 점검할 때 시스템 시간 동기화 상태를 확인하세요. VMess와 전송 방식은 서로 다른 계층이므로 사용자 식별자가 같아도 전체 설정이 동일하다는 뜻은 아닙니다.
CONCEPT REFERENCE / 25 TERMS
V2Ray 용어 가이드
설정 계층에 따라 용어를 확인하세요. 프로토콜은 통신 규칙을 정하고, 코어는 연결을 처리하며, 클라이언트는 설정을 관리합니다. 라우팅은 아웃바운드를 선택하고 DNS는 도메인을 조회합니다. 먼저 개념을 구분한 뒤 매개변수를 조정하세요.
사용 순서에 따라 가이드 읽기 →PROTOCOL / TRANSPORT
프로토콜과 전송 방식
프로토콜 이름만으로 속도를 알 수 없으며, 특정 전송 방식이 자동으로 포함되는 것도 아닙니다. 설정을 가져온 뒤에도 클라이언트와 선택한 코어가 해당 조합을 지원하는지 확인해야 합니다.
프로토콜과 전송 방식
VLESS
경량 프록시 프로토콜
VLESS는 사용자 식별자로 인증합니다. 프로토콜 자체로는 전송 구간을 완전히 암호화하지 않으며, 실제 보안 수준은 TLS나 REALITY 같은 보안 계층과 설정에 따라 달라집니다. flow 설정도 서버와 코어의 지원 여부에 맞춰야 합니다. VLESS를 선택할 때는 프로토콜 이름만 믿기보다 전체 매개변수 조합을 확인하세요.
프로토콜과 전송 방식
Trojan
프록시 프로토콜 · 비밀번호 인증
Trojan은 주로 TLS 연결 위에서 동작하며 비밀번호로 인증합니다. 서버 주소와 포트, 비밀번호, 서버 이름을 각각 확인해야 합니다. 연결 주소와 인증서의 도메인이 서로 다른 역할을 할 수도 있습니다. 인증서 검증에 실패하면 이름과 인증서 체인, 기기 시간을 확인하세요. 평소에 검증을 끄는 방식으로 해결해서는 안 됩니다.
프로토콜과 전송 방식
REALITY
전송 보안 메커니즘
REALITY는 Xray 생태계의 전송 보안 메커니즘으로, VLESS와 나란히 쓰이는 독립 프록시 프로토콜이 아닙니다. VLESS와 함께 사용하는 경우가 많으며, 클라이언트가 해당 기능을 지원하고 서버에서 제공한 공개 키, 서버 이름, 짧은 ID 등의 매개변수가 일치해야 합니다. 클라이언트마다 필드 이름이 다를 수 있으므로 일반 TLS 설정에 그대로 적용하지 마세요.
프로토콜과 전송 방식
전송 방식
Transport · TCP / WebSocket / gRPC
전송 방식은 프록시 프로토콜이 데이터를 전달하는 방법을 말하며, TCP, WebSocket, gRPC 등이 있습니다. WebSocket의 경로와 요청 호스트, gRPC의 서비스 이름 등은 서버 설정과 일치해야 합니다. 전송 방식을 바꾸려면 보통 서버 설정도 함께 조정해야 하며, 클라이언트에서 옵션 하나만 바꾸는 것으로 끝나지 않습니다.
CORE / ECOSYSTEM
코어와 생태계
프로젝트, 클라이언트, 코어는 서로 다른 구성 요소입니다. 기능 설명을 확인할 때는 클라이언트 이름뿐 아니라 실제로 실행되는 코어와 버전도 함께 확인하세요.
코어와 생태계
Project V
모듈형 네트워크 프록시 생태계
Project V는 모듈형 네트워크 프록시 기능을 중심으로 형성된 프로젝트와 생태계이며, V2Ray는 이 기술 체계를 이해하는 주요 출발점입니다. 특정 GUI 클라이언트의 이름도, 통합 구독 서비스도 아닙니다. V2Ray 공식 사이트나 클라이언트 출처를 검색할 때는 코어 프로젝트, GUI 프로젝트, 문서를 제공하는 지식 사이트를 구분하세요.
코어와 생태계
V2Fly
V2Ray 커뮤니티 코어 프로젝트
V2Fly는 V2Ray 코어의 발전을 잇는 커뮤니티 프로젝트로, 인바운드·아웃바운드·라우팅·DNS 등의 기능을 제공합니다. v2flyNG는 이 코어 체계를 사용하는 안드로이드 GUI 클라이언트 중 하나입니다. 지원되는 프로토콜과 설정 형식, 기능은 실제 코어 버전을 기준으로 확인해야 하며, 화면에 필드가 보인다는 이유만으로 사용할 수 있다고 판단해서는 안 됩니다.
코어와 생태계
Xray
독자적으로 발전한 프록시 코어
Xray는 V2Ray 기술 체계에서 비롯되어 공통 개념을 바탕으로 독자적인 기능을 발전시켰으며, REALITY도 관련 기능 중 하나입니다. 일부 프로토콜과 필드가 V2Fly와 비슷하더라도 설정이 완전히 호환된다고 단정할 수는 없습니다. 코어를 바꾼 뒤에는 로그와 생성된 설정을 확인하고, 특히 전용 필드가 유효한지 점검하세요.
코어와 생태계
프록시 코어
코어 · 연결을 실제로 처리하는 구성 요소
프록시 코어는 연결, 프로토콜, 라우팅, 도메인 조회를 실제로 처리하고, GUI 클라이언트는 설정과 실행 상태를 관리합니다. 클라이언트 화면이 업데이트되어도 코어가 함께 업데이트되는 것은 아니며, 화면에서 설정을 저장할 수 있다고 해서 현재 코어가 실행할 수 있다는 뜻도 아닙니다. 문제를 찾을 때는 GUI 조작 오류와 코어 실행 오류를 나눠 확인하세요.
코어와 생태계
GUI 클라이언트
v2rayN / v2rayNG / v2flyNG
GUI 클라이언트는 창과 메뉴, 스위치를 통해 구독, 서버 설정, 프록시 연결을 관리합니다. v2rayN은 데스크톱용이며 v2rayNG와 v2flyNG는 안드로이드용입니다. 세부 기능은 코어와 앱 버전에 따라 다릅니다. 클라이언트 이름은 프로토콜 이름과 다르며, 한 클라이언트에서 여러 프로토콜의 설정을 관리할 수도 있습니다.
운영체제에 맞는 클라이언트 선택 →CLIENT / SUBSCRIPTION
클라이언트와 구독
설정 출처를 먼저 확인한 다음 가져오고 업데이트하세요. 목록에 서버 항목이 표시된다는 것은 설정을 인식했다는 뜻일 뿐, 연결 경로가 실제로 작동하는지 검증된 것은 아닙니다.
클라이언트와 구독
구독
구독 · 설정 배포 방식
구독은 하나의 주소에서 서버 설정 목록을 가져와 업데이트하는 방식입니다. 클라이언트가 응답에 사용된 형식을 지원해야 합니다. 구독 주소에 접속 정보가 포함될 수 있으므로 스크린샷이나 로그, 문의 내용을 공유할 때 전체 주소를 가리세요. 구독 변환은 설정 표현 형식만 바꾸며, 새 서버를 만들거나 코어에 원래 없던 프로토콜 기능을 추가하지 않습니다.
클라이언트와 구독
노드
노드 · 단일 서버 설정
노드는 클라이언트에서 서버 연결 설정 하나를 가리킬 때 흔히 쓰는 말입니다. 일반적으로 주소, 포트, 프로토콜, 인증, 전송 매개변수가 포함됩니다. 목록에 표시되는 이름은 라벨일 뿐, 서버의 실제 위치나 네트워크 품질을 정확히 나타내지 않을 수 있습니다. 이름이 다른 두 설정이 같은 주소를 가리킬 수도 있으므로 실제 매개변수를 비교하세요.
클라이언트와 구독
구독 그룹
구독 그룹 · 출처별 관리
구독 그룹을 사용하면 출처별로 설정을 정리해 개별 업데이트와 검색, 삭제를 편리하게 할 수 있습니다. 보통 클라이언트의 관리 단위일 뿐, 트래픽 경로를 자동으로 결정하거나 라우팅 규칙이 참조하는 아웃바운드 태그와 같은 역할을 하지 않습니다. 구독으로 생성된 항목을 직접 수정하기 전에는 업데이트 시 변경 사항이 덮어써지는지 확인하고, 필요하면 별도 설정으로 저장하세요.
클라이언트와 구독
시스템 프록시
시스템 프록시 · 앱 연결 방식
시스템 프록시는 운영체제 설정을 통해 해당 설정을 따르는 앱을 클라이언트의 로컬 수신 포트에 연결합니다. 일부 앱은 자체 네트워크 설정을 사용하므로 시스템 프록시를 켜도 모든 트래픽이 클라이언트에 들어오는 것은 아닙니다. 연결된 트래픽의 아웃바운드는 코어의 라우팅 규칙이 선택합니다. 시스템 프록시 스위치와 전체 프록시·우회 같은 라우팅 모드를 혼동하지 마세요.
프록시 모드 문서 보기 →클라이언트와 구독
실제 연결 지연 시간
연결 테스트 · 프록시 경로 측정
실제 연결 지연 시간은 보통 클라이언트가 프록시 경로를 통해 테스트 대상에 접속할 때 측정한 시간입니다. 핸드셰이크 단계가 포함되는지는 구현에 따라 다릅니다. 포트 연결만 확인하는 TCP 테스트와 다르며, 파일 다운로드 속도로 바로 환산할 수도 없습니다. 결과를 비교하려면 테스트 대상과 네트워크 환경, 측정 방식을 동일하게 유지하세요. 한 번 실패했다고 설정이 작동하지 않는다고 단정할 수는 없습니다.
ROUTING / OUTBOUND
라우팅과 트래픽 분기
트래픽은 먼저 코어에 들어온 뒤 매칭 조건에 따라 아웃바운드가 선택됩니다. 라우팅을 점검할 때는 규칙 순서와 사용할 수 있는 도메인 정보, 데이터셋 내용을 함께 확인하세요.
라우팅과 트래픽 분기
라우팅 규칙
라우팅 규칙 · 조건 매칭
라우팅 규칙은 도메인, IP, 포트, 네트워크 유형, 인바운드 태그 등의 조건에 따라 아웃바운드를 선택합니다. 일반적으로 필드 규칙은 순서대로 적용되므로, 구체적인 조건을 포괄적인 조건보다 앞에 배치해 먼저 매칭되는 일을 방지해야 합니다. 규칙 간 순서와 한 규칙 안의 여러 필드가 결합되는 방식은 다르므로, 변경 전에 매칭 로직부터 확인하세요.
라우팅과 트래픽 분기
트래픽 분기
트래픽 라우팅 · 조건별 경로 선택
트래픽 분기는 트래픽 특성에 따라 직접 연결, 프록시, 차단 등의 처리 경로를 선택하는 정책입니다. 일반적으로 전체 모드는 코어에 들어온 트래픽을 우선 프록시 아웃바운드로 보내는 것을 뜻하며, 모든 앱의 트래픽을 자동으로 가져오는 것은 아닙니다. 우회 모드는 규칙에 따라 일부 트래픽을 직접 연결하며, 실제 결과는 메뉴 이름이 아니라 클라이언트가 생성한 라우팅 규칙에 따라 달라집니다.
라우팅과 트래픽 분기
GeoIP
IP 주소 분류 데이터
GeoIP는 라우팅 조건에서 사용할 수 있도록 IP 주소를 범주별로 정리합니다. 예를 들어 geoip:private는 사설 IP 범위를 매칭하는 데 자주 사용됩니다. 결과는 데이터셋의 내용과 업데이트 상태에 따라 달라지며, 서버의 실제 위치를 실시간으로 측정하는 기능은 아닙니다. 대상이 도메인인 경우 IP 규칙을 적용할 수 있는지는 도메인 전략과 조회 결과에도 달려 있습니다.
라우팅과 트래픽 분기
GeoSite
도메인 분류 데이터
GeoSite는 도메인을 범주별로 정리합니다. 예를 들어 geosite:cn을 도메인 매칭 조건으로 사용할 수 있으며, 태그의 구체적인 내용은 데이터셋에 따라 달라집니다. 관리자가 등록한 도메인 목록을 기준으로 매칭하므로, 접속 시점에 서버가 있는 지역을 조회하는 기능은 아닙니다. 도메인 목록과 IP 목록은 용도가 다르며 같은 대상도 두 규칙에서 분류 결과가 다를 수 있습니다.
라우팅과 트래픽 분기
아웃바운드 태그
tag / outboundTag
아웃바운드 객체는 tag로 식별자를 선언하고, 라우팅 규칙은 outboundTag를 사용해 해당 객체를 참조합니다. direct, proxy, block은 흔히 사용하는 이름이며 실제 동작은 객체의 프로토콜과 설정에 따라 달라집니다. 태그 이름을 입력한다고 아웃바운드가 자동으로 생성되는 것은 아니므로 참조 대상이 실제 설정과 일치해야 합니다.
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}DNS / TRAFFIC CAPTURE
DNS와 TUN
도메인 조회와 트래픽 연결 방식은 서로 영향을 줍니다. 설정을 변경하기 전 복구할 수 있는 설정을 보관하세요. 네트워크 인터페이스와 라우팅, DNS 리졸버를 동시에 바꾸면 원인을 찾기 어려워질 수 있습니다.
DNS와 TUN
TUN 모드
가상 네트워크 인터페이스를 통한 연결
TUN 모드는 가상 네트워크 인터페이스와 시스템 라우팅을 이용해 트래픽을 받아들이므로 시스템 프록시를 따르지 않는 일부 앱도 처리할 수 있습니다. 관리자 권한이나 네트워크 관련 권한이 필요할 수 있으며, 실제 적용 범위는 클라이언트 구현과 시스템 라우팅에 따라 다릅니다. TUN을 켠다고 모든 트래픽이 강제로 프록시를 거치는 것은 아닙니다. 트래픽 분기와 DNS, 로컬 네트워크 예외, 다른 네트워크 프로그램과의 충돌도 함께 확인하세요.
DNS와 TUN
FakeDNS
가상 IP와 도메인 매핑
FakeDNS는 앱에 가상 IP를 반환하고 해당 주소와 원래 도메인의 매핑을 저장합니다. 이후 연결에서 도메인을 복원해 라우팅에 활용할 수 있습니다. 공개 DNS 리졸버가 아니며, 도메인이 실제로 해당 IP로 해석됐다는 뜻도 아닙니다. DNS 연결과 트래픽 가로채기가 함께 작동해야 합니다. 관련 모드를 종료한 뒤에도 앱이 가상 주소를 캐시하고 있다면 도메인을 다시 조회하거나 앱을 재시작해야 할 수 있습니다.
DNS와 TUN
DNS 누출
예상한 경로를 벗어난 도메인 조회
DNS 누출은 도메인 조회 요청이 예상한 경로로 처리되지 않고 다른 리졸버나 인터페이스를 통해 전송되는 현상입니다. 먼저 예상한 정책을 확인한 뒤 운영체제와 브라우저의 별도 조회, 코어 DNS, 앱 캐시를 점검하세요. 테스트 페이지에 표시된 리졸버의 지역만으로 누출을 단정할 수는 없습니다. 중요한 것은 요청이 실제로 어떤 경로를 거쳤는지입니다.
DNS와 TUN
도메인 전략
routing.domainStrategy
라우팅의 domainStrategy는 매칭 중 도메인을 언제 조회해 IP 규칙을 적용할지 제어합니다. 예를 들어 IPIfNonMatch는 도메인이 규칙에 매칭되지 않을 때 조회를 시도한 뒤 계속 매칭합니다. 아웃바운드 연결에 사용할 주소를 선택하는 전략은 아니므로, 이름이 같거나 비슷한 필드도 설정에서 어느 계층에 있는지 확인해야 합니다. 이 값을 바꿔도 전체 DNS 설정이 완료되는 것은 아닙니다.
DNS와 TUN
트래픽 스니핑
스니핑 · 대상 정보 추출
트래픽 스니핑은 일부 연결의 프로토콜 특성에서 대상 도메인 등의 정보를 추출해 대상 IP만 포함된 연결도 도메인 기반 라우팅에 활용할 수 있게 합니다. 앱 콘텐츠를 복호화하는 기능은 아니며, 식별 범위는 프로토콜과 암호화 방식에 따라 달라집니다. 라우팅에만 사용하는지, 대상 주소를 다시 쓰는지는 설정에 따라 다르므로 호환성 문제가 발생하면 적용 범위를 확인하세요.
개념에서 설정까지
용어를 통해 설정 계층을 파악한 뒤, 구체적인 메뉴 경로와 점검 순서는 관련 문서를 확인하세요. 버전에 따라 화면 이름이 달라지면 매개변수의 의미와 실행 로그를 기준으로 판단하세요.
최초 설치와 설정 가져오기
클라이언트 선택, 구독 가져오기, 연결 방식 설정, 연결 확인 순으로 진행하고 한 번에 한 계층만 변경하세요.
사용 가이드 읽기 →라우팅과 문제 해결
먼저 트래픽이 코어에 들어오는지 확인한 다음 규칙 매칭과 아웃바운드 연결을 점검하세요. DNS 문제를 프로토콜 선택 탓으로 바로 돌리지 마세요.
자주 묻는 질문 보기 →