프록시 프로토콜
VMess
VMess는 Project V 생태계의 프록시 프로토콜로, 인증과 데이터 암호화 기능을 제공합니다. 설정할 때 사용자 ID, 서버 주소, 전송 설정을 맞춰야 하며 주소와 포트만 입력해서는 충분하지 않습니다. 시스템 시간이 크게 어긋나면 인증에 영향을 줄 수 있으므로 인증 오류가 발생하면 기기 시간이 정확한지도 확인하세요.
프로토콜 · 필드 · 설정
V2Ray 용어집
먼저 프로토콜, 전송 방식, 코어를 구분한 다음 설정 필드를 찾아보세요. 아래 27개 항목은 설정 계층별로 분류했으며, 용어 이름을 페이지 내 링크로 바로 사용할 수 있습니다.
매개변수를 수정하려면 설정 레퍼런스 →를 확인하고, 처음 서버 설정을 가져온다면 사용 가이드 →부터 읽어보세요.
프로토콜과 전송 방식
프록시 프로토콜은 데이터를 구성하고 인증하는 방식을 정하고, 전송 방식은 연결을 전달하는 방법을 정하며, 보안 계층은 암호화와 상대방 인증을 담당합니다. 이름만 보고 서로 대체할 수 있는 개념은 아닙니다.
프록시 프로토콜
VLESS
VLESS는 자체적으로 데이터 암호화를 제공하지 않는 경량 프록시 프로토콜이며, 보통 TLS 또는 REALITY와 함께 사용합니다. 클라이언트와 서버의 사용자 ID, 전송 방식, 해당되는 흐름 제어 매개변수가 서로 일치해야 합니다. 공유 링크가 vless://로 시작하더라도 프로토콜 종류만 알 수 있을 뿐, 보안 계층과 전송 방식의 전체 조합까지 확인할 수는 없습니다.
프록시 프로토콜
Trojan
Trojan은 보통 TLS 연결 위에서 동작하며 비밀번호로 인증합니다. 비밀번호가 맞더라도 연결 설정 전체가 올바른 것은 아닙니다. 서버 이름, 인증서 검증, 전송 방식이 모두 일치해야 합니다. 인증서 오류가 발생하면 도메인, 시간, 인증서 체인을 먼저 확인하고, 오류를 피하려고 인증서 검증을 바로 끄는 것은 권장하지 않습니다.
전송 보안
REALITY
REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 나란히 놓이는 독립적인 프록시 프로토콜이 아닙니다. 클라이언트의 공개 키, 서버 이름, 짧은 ID 등의 매개변수를 서버 설정과 일치시켜야 합니다. 세부 필드는 코어 버전에 따라 달라집니다. 화면에서 보안 유형만 바꿔서는 일반 TLS 설정을 제대로 작동하는 REALITY 설정으로 변환할 수 없습니다.
전송 보안
TLS
TLS는 연결에 전송 암호화, 무결성 보호, 상대방 인증을 제공합니다. 서버 주소로 IP를 사용할 수 있지만 인증서 검증에 쓰는 서버 이름은 실제 인증서 및 서버 요구 사항에 맞아야 합니다. 화면의 ‘안전하지 않은 연결 허용’은 보통 인증서 검증과 관련된 옵션이며, 연결 품질이나 속도를 높이는 일반적인 설정이 아닙니다.
전송 방식
WebSocket
WebSocket은 프록시 데이터를 전달할 수 있지만, 프록시 사용자 인증 방식 자체를 정하지는 않습니다. 사용할 때는 경로, Host, 포트와 리버스 프록시의 연결 전달 설정이 올바른지 확인해야 합니다. 설정의 서버 이름, HTTP Host, 연결 주소는 서로 다른 역할을 할 수 있으므로 도메인처럼 보인다는 이유만으로 모두 같은 값으로 입력해서는 안 됩니다.
코어와 생태계
클라이언트 화면은 관리 기능을 제공하고, 코어는 실제 처리를 담당합니다. 특정 프로토콜을 사용할 수 있는지 판단할 때는 클라이언트가 해당 설정을 생성할 수 있는지와 실제로 호출되는 코어가 이를 지원하는지 모두 확인해야 합니다.
프로젝트 배경
Project V
Project V는 V2Ray의 모듈형 네트워크 프록시 설계와 관련 생태계를 이해하기 위한 배경 개념이지, 클라이언트의 연결 모드가 아닙니다. 관련 기술은 인바운드, 아웃바운드, 라우팅, 전송 기능을 각각 다른 모듈로 나눕니다. 자료를 읽을 때는 ‘V2Ray’라는 통칭만으로 호환성을 판단하지 말고, 어떤 코어와 버전을 다루는지 확인하세요.
코어 프로젝트
V2Fly
V2Fly는 V2Ray 코어를 유지 관리하는 커뮤니티 프로젝트이며, 코어는 프로토콜 연결, 라우팅, DNS 등의 실제 작업을 처리합니다. v2flyNG는 관련 코어 기능을 호출하는 Android 그래픽 클라이언트로, 둘은 서로 다른 소프트웨어 계층에 속합니다. 설정 문서의 필드는 해당 코어의 형식과 버전에 맞춰 확인해야 하며, 다른 코어에서 추가된 기능을 그대로 적용할 수는 없습니다.
코어 프로젝트
Xray
Xray는 V2Ray 기술 체계에서 출발해 독자적인 프로토콜과 전송 기능을 발전시켜 왔으며, REALITY는 그 생태계의 대표적인 기능입니다. Xray와 V2Fly는 설정 구조 일부가 비슷하지만 모든 필드와 동작이 같은 것은 아닙니다. 기능이 작동하지 않는다면 그래픽 클라이언트 버전뿐 아니라 실제 실행 중인 Xray 코어 버전도 확인하세요.
애플리케이션 계층
그래픽 클라이언트
그래픽 클라이언트는 구독 가져오기, 서버 선택, 로그 확인, 매개변수 설정 등의 화면을 제공하며 보통 코어가 실행할 설정을 생성합니다. 이 사이트에서 다루는 v2rayN은 데스크톱 플랫폼용이고, v2rayNG와 v2flyNG는 Android용입니다. 화면에 설정 항목이 보인다는 것은 가져오기에 성공했다는 뜻일 뿐, 코어가 실행되거나 실제 연결이 확인되었다는 의미는 아닙니다.
클라이언트 선택 보기 →실행 방식
코어 전환
코어 전환은 클라이언트가 호출하는 네트워크 처리 프로그램을 바꾸는 작업이지, 화면 테마를 바꾸는 것이 아닙니다. 전환 전에 대상 코어가 현재 프로토콜, 보안 계층, 라우팅 설정을 지원하는지 확인해야 하며, 전환 후에는 설정을 다시 불러와야 하는 경우가 많습니다. 특정 코어 전용 기능은 클라이언트에 같은 이름의 옵션이 남아 있어도 다른 코어에서 자동으로 작동하지 않습니다.
코어 적용 범위 보기 →설정 파일 구조
먼저 트래픽이 어디로 들어오는지 확인한 다음, 규칙이 트래픽을 어디로 보내는지 살펴보세요. 아래 필드 이름은 JSON과 로그에서 검색하기 쉽도록 원래 대소문자를 유지합니다.
설정 파일 구조
inbounds · 인바운드
inbounds는 인바운드 배열로, 앱이나 다른 기기에서 들어오는 연결을 코어가 처리하는 방식을 정의합니다. 일반적인 설정에는 리스닝 주소, 포트, 프로토콜, 트래픽 스니핑 등이 포함되며 SOCKS와 HTTP를 로컬 진입점으로 사용할 수 있습니다. 로컬 루프백 주소에서 수신하는 경우와 모든 네트워크 인터페이스에서 수신하는 경우는 접근 범위가 다릅니다. LAN에 진입점을 열기 전에는 인증과 방화벽 설정을 확인하세요.
설정 파일 구조
outbounds · 아웃바운드
outbounds는 아웃바운드 배열로, 프록시 서버를 통한 전송, 직접 연결, 차단 등 트래픽 처리 방식을 정의합니다. 화면의 서버 목록을 단순히 복사한 것이 아니라 코어가 실제로 선택할 수 있는 출구 목록입니다. 라우팅 규칙이 참조하는 아웃바운드는 실제로 존재해야 합니다. 일반적인 V2Ray / Xray 설정에서는 규칙과 일치하지 않은 트래픽이 보통 첫 번째 아웃바운드를 사용합니다.
설정 객체 참조
tag와 outboundTag
tag는 설정 객체의 이름을 지정하고, 라우팅의 outboundTag는 대상 아웃바운드의 같은 이름 태그를 참조합니다. 태그는 식별자일 뿐입니다. 예를 들어 direct라는 이름의 아웃바운드도 실제 직접 연결 프로토콜을 설정해야 합니다. 이름만으로 직접 연결이 만들어지지는 않습니다. 참조할 때는 철자와 대소문자를 일치시켜 규칙이 존재하지 않는 출구를 가리키지 않도록 하세요.
전송 설정
streamSettings
streamSettings는 연결의 전송 방식과 보안 설정을 구성합니다. 사용자 ID나 비밀번호 등의 프로토콜 인증 매개변수와는 별도입니다. 내부에는 전송 유형, TLS, REALITY 설정 객체 등이 들어갈 수 있으며 구체적인 구조는 코어 버전에 따라 다릅니다. 설정을 복사할 때는 서버 요구 사항을 전체적으로 확인하고, 호환되지 않는 하위 필드를 남긴 채 전송 이름만 바꾸지 마세요.
인바운드 처리
sniffing · 트래픽 스니핑
sniffing은 보통 인바운드에 설정하며, 연결 초기 데이터 일부를 분석해 프로토콜이나 도메인 단서를 찾아 이후 라우팅을 돕습니다. 암호화된 내용을 복호화하는 기능은 아니며 모든 연결에서 도메인을 식별할 수 있는 것도 아닙니다. 코어에 따라 라우팅 보조 옵션과 대상 재정의 동작이 다를 수 있으므로, 사용 설정 후 로그에서 규칙이 실제로 어떤 정보를 사용했는지 확인하세요.
라우팅과 DNS
분할 라우팅은 일치 조건, 규칙 순서, 사용할 수 있는 도메인 정보에 따라 달라집니다. DNS는 도메인 해석을 담당하며 아웃바운드 선택과는 다릅니다. 두 기능은 함께 작동해야 하지만 같은 스위치로 취급해서는 안 됩니다.
트래픽 경로
라우팅 규칙과 분할 라우팅
분할 라우팅은 도메인, IP, 포트, 인바운드 태그 등의 조건에 따라 연결별 출구를 선택하는 과정입니다. 일반적인 필드 규칙은 순서대로 확인하며 먼저 일치하는 적용 가능 규칙이 목적지를 결정하므로, 구체적인 규칙을 포괄적인 규칙보다 앞에 두는 것이 보통입니다. 한 규칙에 여러 조건을 함께 지정했다면 조건 간 결합 방식도 확인해야 합니다. 모든 조건을 선택 사항처럼 처리해서는 안 됩니다.
라우팅 설정 보기 →IP 규칙 데이터
GeoIP
GeoIP는 IP 주소 범위를 범주나 지역별로 묶어 제공하며, 라우팅에서 geoip:private 같은 태그로 참조할 수 있습니다. 사용할 수 있는 태그와 적용 범위는 로컬 데이터 파일에 따라 다르며, 모든 데이터 소스에 같은 내용이 들어 있는 것은 아닙니다. IP 주소의 등록 지역이 웹사이트 서버의 실제 위치를 뜻하지도 않습니다. 공유 주소나 주소 변경이 있는 경우 도메인 규칙도 함께 확인하세요.
도메인 규칙 데이터
GeoSite
GeoSite는 범주별로 정리한 도메인 규칙 모음으로, 라우팅에 geosite:cn 같은 형식으로 사용합니다. 도메인을 기준으로 일치시키며 대상 IP가 어느 지역에 속하는지 조회하지 않습니다. 연결에 IP 정보만 있다면 관련 규칙이 일치하지 않을 수 있습니다. 데이터가 업데이트되면 범주 적용 범위도 달라질 수 있으므로 규칙을 바꾸기 전에 클라이언트가 실제로 불러온 데이터 파일을 확인하세요.
라우팅 도메인 해석 전략
domainStrategy
routing.domainStrategy는 라우팅 규칙을 확인할 때 도메인을 해석할지, 해석한다면 언제 할지를 제어합니다. 일반적인 값은 AsIs, IPIfNonMatch, IPOnDemand입니다. 예를 들어 IPIfNonMatch는 도메인 규칙과 일치하지 않을 때 도메인을 해석해 IP 규칙을 확인합니다. 다른 객체의 동명 필드는 실제 연결 단계에 영향을 줄 수 있으므로 여기서 설명한 의미를 그대로 적용해서는 안 됩니다.
도메인 매핑
FakeDNS
FakeDNS는 도메인에 합성 IP를 할당하고 매핑을 저장해, 연결을 가로챈 프록시 프로그램이 대상 도메인을 복원하도록 돕습니다. 이 IP는 웹사이트의 실제 서버 주소를 해석한 결과가 아니며, 연동되는 처리 경로에서 식별해야 합니다. FakeDNS만 켜고 해당 연결을 올바르게 가로채지 못하면 접속이 실패할 수 있으므로 DNS 조회 경로, 라우팅, 캐시를 함께 확인하세요.
DNS 해석 경로
DNS 누출
DNS 누출은 도메인 조회가 예상한 해석 경로를 우회하는 현상이며, DNS 해석 실패와는 다릅니다. 시스템 리졸버, 브라우저의 보안 DNS, 앱 자체 리졸버, 가로채지 않은 조회가 결과에 영향을 줄 수 있습니다. 문제를 확인할 때는 예상 리졸버와 실제 조회 출구를 파악해야 합니다. 웹페이지에 접속된다는 사실만으로 DNS 요청이 설계한 경로를 따르고 있다고 볼 수는 없습니다.
DNS 설정 보기 →구독과 클라이언트
구독은 설정을 제공하고 노드는 설정 항목이며, 프록시 모드는 앱이 코어에 연결되는 방식을 정합니다. 테스트 결과는 측정 방법과 함께 해석해야 하며, 한 번의 측정으로 장기적인 품질을 판단해서는 안 됩니다.
설정 출처
구독
구독은 클라이언트가 서버 설정 모음을 가져오는 업데이트 경로로, 보통 하나의 주소에서 클라이언트가 인식할 수 있는 설정을 제공합니다. 구독 주소에 접근 자격 증명이 포함될 수 있으므로 공개 스크린샷에 넣거나 다른 사람에게 전달하지 않는 것이 좋습니다. 구독을 업데이트하면 설정을 다시 가져오지만, 메모를 덮어쓰는지, 직접 수정한 내용을 보존하는지, 사용할 수 없는 항목을 삭제하는지는 클라이언트와 그룹 설정에 따라 다릅니다.
구독 관리 보기 →서버 설정 항목
노드
노드는 클라이언트에 저장된 서버 연결 설정 한 개를 흔히 부르는 말입니다. 일반적으로 주소, 포트, 프로토콜, 인증 정보, 전송 매개변수가 포함됩니다. 목록에 표시되는 이름은 대개 메모일 뿐 서버 위치, 대역폭, 운영 주체를 보장하지 않습니다. 이름이 서로 다른 두 항목이 같은 서버를 가리킬 수도 있습니다. 중복 설정을 확인할 때는 실제 매개변수를 비교하세요.
연결 테스트
지연 시간과 실제 연결 지연
지연 시간은 측정 방법과 함께 해석해야 합니다. TCP 연결 시간과 프록시를 거쳐 웹페이지를 요청하는 시간은 서로 다른 구간을 측정합니다. ‘실제 연결 지연’은 보통 선택한 프록시를 통해 지정된 테스트 주소에 접속하며, 핸드셰이크와 응답 대기 시간이 포함될 수 있습니다. 구체적인 동작은 클라이언트에 따라 다릅니다. 수치가 낮아도 지속적인 다운로드 속도가 빠르다는 뜻은 아니며, 시간 초과는 테스트 주소, DNS, 인증서 문제로 발생할 수도 있습니다.
앱 연결 방식
시스템 프록시
시스템 프록시는 클라이언트가 운영체제에 로컬 프록시 주소와 포트를 등록하는 기능으로, 일반적으로 해당 설정을 따르는 앱에만 적용됩니다. 클라이언트의 ‘전역’ 또는 ‘규칙’ 라우팅 설정과는 다른 계층이며, 시스템 프록시를 설정했다고 모든 트래픽이 코어를 거치는 것은 아닙니다. 앱이 프록시를 직접 지정하거나 독립 네트워크 스택을 사용한다면 연결 경로를 별도로 확인해야 합니다.
시스템 프록시 안내 보기 →네트워크 트래픽 가로채기
TUN 모드
TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 라우팅 조건에 맞는 IP 트래픽을 수신합니다. 시스템 프록시를 읽지 않는 앱도 프록시 처리 경로로 보낼 수 있습니다. 일반적으로 추가 권한, 라우팅 변경, DNS 가로채기가 필요하며 구체적인 동작은 클라이언트와 사용 중인 코어에 따라 다릅니다. TUN은 모든 V2Ray / Xray JSON에 공통으로 적용되는 단일 스위치가 아니며, 모든 연결이 프록시 아웃바운드를 사용한다는 뜻도 아닙니다.
TUN 설정 적용 범위 보기 →