VMess
프로토콜 유형
VMess는 Project V 생태계의 프록시 프로토콜로, 인증과 데이터 보호 기능을 포함합니다. 서버와 포트 외에도 사용자 식별자, 전송 방식, 보안 계층 등의 매개변수가 서로 일치해야 연결할 수 있습니다. 인증 과정에서 시스템 시간이 사용되므로 기기 시간이 크게 어긋나면 연결에 실패할 수 있습니다. 주소만 확인해서는 문제를 찾기 어렵습니다.
프로토콜 선택 가이드 보기 →V2Ray / 개념 빠른 참고
V2Ray 용어집
설정 항목의 이름부터 살펴보고 프록시 프로토콜, 코어, 전송 방식과 보안 계층을 구분하세요.
프로토콜 유형
프록시 프로토콜은 클라이언트와 서버의 인증 및 데이터 교환 방식을 규정합니다. 이름이 같다고 해서 연결 설정 전체가 동일한 것은 아닙니다.
VLESS
프로토콜 유형
VLESS는 프록시 요청과 사용자 식별을 처리하는 경량 프록시 프로토콜로, 자체적으로 페이로드를 암호화하지 않습니다. 실제 배포에서는 보통 TLS나 REALITY 같은 보안 계층과 함께 사용합니다. VLESS를 선택했다고 암호화 설정까지 완료된 것은 아닙니다. 일부 흐름 제어 옵션은 특정 코어와 매개변수 조합이 필요하므로 가져온 뒤 항목별로 확인하세요.
VLESS와 REALITY의 차이 →Trojan
프로토콜 유형
Trojan은 일반적으로 TLS 연결을 기반으로 하며 비밀번호로 프록시 인증을 수행합니다. 비밀번호가 맞는 것만으로는 충분하지 않습니다. 서버 이름, 인증서 검증, 전송 방식도 서버 설정과 일치해야 합니다. 링크를 가져온 뒤 핸드셰이크에 실패한다면 비밀번호만 반복해서 바꾸지 말고 TLS 설정과 프로토콜 인증을 나눠 점검하세요.
TLS의 역할 보기 →Shadowsocks / SS
프로토콜 유형
Shadowsocks는 흔히 SS로 줄여 부르며, 사전 공유 키를 사용하는 암호화 프록시 프로토콜입니다. 암호화 방식과 프로토콜 세대에 따라 키 형식과 구현 요구사항이 다르므로 클라이언트가 서버에서 지정한 방식을 지원해야 합니다. 양쪽 화면에 Shadowsocks 옵션이 있다는 이유만으로 호환된다고 볼 수 없으며, 서로 다른 형식의 키를 혼용해서도 안 됩니다.
프로토콜 호환성 안내 보기 →코어와 생태계
클라이언트는 화면과 설정을 관리하고, 코어는 연결 및 라우팅을 처리합니다. 생태계의 이름이 구체적인 소프트웨어 패키지 이름과 같지는 않습니다.
Project V
코어와 생태계
Project V는 V2Ray의 기원과 모듈형 프록시 도구 설계를 이해하기 위한 배경 개념이지, 특정 프록시 프로토콜이 아닙니다. 이 생태계를 이야기할 때는 코어 프로그램, 프로토콜 구현, GUI 클라이언트 중 무엇을 가리키는지 구분해야 합니다. V2Ray 관련 이름을 검색했다면 이름만 보고 설치 패키지를 고르기보다 소프트웨어가 담당하는 계층부터 확인하는 편이 정확합니다.
클라이언트와 코어의 역할 보기 →Xray
코어와 생태계
Xray는 V2Ray 코드 기반에서 발전한 프록시 코어로, 자체 프로토콜·전송·보안 기능을 유지 관리합니다. REALITY 등의 기능은 해당 구현과 버전에서 지원해야 하며, 다른 코어가 같은 설정을 그대로 받아들인다고 가정할 수 없습니다. 코어를 바꾸기 전에는 클라이언트가 새 코어에 필요한 항목을 생성할 수 있는지 확인하고, 기존에 작동하는 설정도 보관하세요.
코어별 차이 참고하기 →V2Fly
코어와 생태계
V2Fly는 V2Ray 관련 구현을 지속적으로 관리하는 커뮤니티 프로젝트입니다. 클라이언트의 V2Fly 코어 옵션은 보통 이 프로젝트가 관리하는 코어 프로그램을 뜻합니다. Xray와 공통된 이력이 있지만 기능 발전 방향, 필드, 설정 형식이 모두 같다고 볼 수는 없습니다. v2flyNG는 GUI 클라이언트 이름이며 V2Fly 코어 자체와 동일한 개념이 아닙니다.
Xray의 역할과 비교하기 →GUI 클라이언트
코어와 생태계
GUI 클라이언트는 구독 가져오기, 노드 선택, 라우팅 편집, 시스템 통합 등을 위한 화면을 제공하고 실제 네트워크 처리는 코어가 담당합니다. v2rayN은 데스크톱 플랫폼용이며, v2rayNG와 v2flyNG는 Android용입니다. 세부 기능은 통합된 코어에 따라 달라집니다. 화면에 특정 필드가 표시되더라도 현재 선택한 코어나 서버가 해당 조합을 지원한다는 뜻은 아닙니다.
플랫폼별 클라이언트 보기 →전송과 암호화
프록시 프로토콜, 전송 캡슐화, 보안 계층은 각각 다른 역할을 설명합니다. 이 중 하나만 선택했다고 전체 연결 방식까지 결정되는 것은 아닙니다.
TLS
전송과 암호화
TLS는 통신의 암호화, 무결성 보호, 인증을 제공합니다. 프록시 설정의 서버 이름은 핸드셰이크와 인증서 검증에 사용되는 경우가 많습니다. 연결 주소와 검증에 사용하는 이름은 다를 수 있지만 서버 배포 설정과 일치해야 합니다. 인증서 검증을 끄면 인증 보안이 약해지므로 인증서 오류가 발생하면 이름, 인증서 체인, 기기 시간을 먼저 확인하세요.
보안 계층 설정 범위 보기 →REALITY
전송과 암호화
REALITY는 Xray 생태계의 전송 보안 메커니즘으로, VMess나 VLESS와 같은 계층의 독립적인 프록시 프로토콜이 아닙니다. 일반적인 설정에는 VLESS와 REALITY가 함께 표시되며, 각각 프록시 프로토콜과 보안 계층을 나타냅니다. 공개 키, 서버 이름, 짧은 ID 등의 항목은 서버 요구사항에 맞게 입력해야 합니다. 일반 TLS 설정의 이름만 바꿔 사용할 수는 없습니다.
VLESS 용어로 돌아가기 →전송 방식
전송과 암호화
전송 방식은 프록시 데이터를 어떤 연결로 전달하거나 어떤 형식으로 캡슐화하는지를 설명합니다. 예를 들어 TCP를 직접 사용하거나 WebSocket, gRPC 형식을 사용할 수 있습니다. 필요한 경로, 서비스 이름, 요청 헤더는 전송 방식에 따라 달라지며 모든 프록시 프로토콜과 보안 계층이 모든 조합을 지원하는 것은 아닙니다. 같은 이름의 옵션이 있어도 클라이언트와 서버 코어의 실제 지원 범위를 확인해야 합니다.
프로토콜과 전송 조합 보기 →멀티플렉싱 / Mux
전송과 암호화
멀티플렉싱은 여러 논리 데이터 스트림을 적은 수의 하위 연결에 실어 반복적인 연결 설정 비용을 줄이는 방식입니다. 모든 상황에서 속도를 높이는 기능은 아니며, 하위 연결에 문제가 생기면 여러 요청이 동시에 영향을 받을 수도 있습니다. 코어마다 구현과 호환 조건이 다를 수 있으므로 프로토콜 조합, 네트워크 상태, 실제 앱 테스트를 바탕으로 사용 여부를 판단하세요.
연결 테스트의 한계 알아보기 →구독과 링크
단일 설정과 설정 모음을 가져오는 경로는 서로 다릅니다. 가져오기 성공, 업데이트 성공, 실제 연결 가능 여부도 각각 별도로 확인해야 합니다.
구독 URL
구독과 링크
구독 URL은 여러 연결 설정을 가져오는 주소입니다. 클라이언트가 요청을 보내면 반환된 내용을 파싱합니다. URL에는 접근 권한을 나타내는 정보가 포함되는 경우가 많으므로 민감 정보로 취급하고 공개 스크린샷이나 도움 요청 글에 노출하지 마세요. 클라이언트마다 구독 형식과 확장 필드 지원이 다르므로 주소에 접속할 수 있더라도 내용을 올바르게 가져온다는 보장은 없습니다.
구독 가져오기 방법 보기 →노드
구독과 링크
노드는 클라이언트에서 선택 가능한 연결 설정 하나를 흔히 부르는 말입니다. 일반적으로 서버, 포트, 인증, 전송, 보안 계층 매개변수가 포함됩니다. 노드 하나가 물리 서버 하나를 독점한다는 뜻은 아니며, 표시 이름은 알아보기 쉽도록 붙인 라벨일 뿐입니다. 설정의 중복이나 동등 여부는 이름, 지역 설명, 목록 순서가 아니라 실제 매개변수로 비교해야 합니다.
노드 공유 형식 알아보기 →공유 링크
구독과 링크
공유 링크는 연결 설정을 특정 URI 형식으로 인코딩한 텍스트입니다. 예를 들어 vmess://, vless://, trojan://로 시작합니다. 보통 단일 설정을 나타내며, 설정 모음을 주기적으로 가져오는 구독 URL과는 다릅니다. QR 코드는 같은 텍스트를 다른 형태로 표시한 것일 뿐이므로 스캔해 가져오려면 클라이언트가 해당 프로토콜과 필드를 지원해야 합니다.
구독 업데이트
구독과 링크
구독 업데이트는 원격 내용을 다시 가져와 로컬 연결 설정을 새로 고치는 작업이며, 클라이언트나 코어를 업그레이드하는 것과는 다릅니다. 업데이트에 따라 노드 이름, 매개변수, 사용 가능한 목록이 바뀔 수 있으므로 구독 노드를 수정하기 전에는 클라이언트가 직접 수정한 내용을 어떻게 보존하는지 확인하세요. 업데이트에 실패하면 주소 요청 오류, 호환되지 않는 응답 형식, 지원되지 않는 개별 필드를 구분해 점검해야 합니다.
설치 및 설정 문제 보기 →라우팅 분기
도메인 매칭, IP 매칭, DNS 해석은 서로 영향을 줍니다. 규칙을 확인할 때는 순서와 조건, 최종 출구를 함께 살펴보세요.
라우팅 규칙
라우팅 분기
라우팅 규칙은 도메인, 대상 IP, 포트 등의 조건에 따라 연결이 사용할 출구를 선택합니다. 일반적으로 설정 순서대로 규칙을 확인하므로 앞선 규칙이 일치하면 뒤의 규칙은 적용되지 않을 수 있습니다. 어떤 규칙에도 일치하지 않는 트래픽은 기본 정책에 따라 처리됩니다. 문제를 확인할 때는 먼저 트래픽이 코어에 전달됐는지 살펴본 뒤 조건과 일치 여부를 확인하세요. 규칙 이름만으로 결과를 판단할 수는 없습니다.
라우팅 선택 및 매칭 안내 보기 →GeoIP
라우팅 분기
GeoIP는 여기서 보통 지역이나 사전 정의된 범주별로 정리된 IP 주소 모음을 뜻합니다. geoip:cn은 흔히 사용하는 참조 형식입니다. 분류 결과는 데이터 출처와 업데이트 시점에 좌우되며, 서버의 실제 물리적 위치를 실시간으로 측정한 값이 아닙니다. 대상이 공유 주소를 사용하거나 서비스 배포가 바뀌면 IP 분류가 특정 웹사이트의 용도에 대한 예상과 다를 수 있습니다.
GeoSite
라우팅 분기
GeoSite는 서비스, 용도 또는 기타 범주별로 정리한 도메인 규칙 모음입니다. geosite:cn은 흔히 사용하는 참조 형식입니다. 분류 태그는 코어가 자동으로 알아내는 값이 아니라 호환되는 데이터 파일에서 제공해야 하며, 적용 범위는 데이터 출처에 따라 달라집니다. GeoIP와 매칭 대상이 다르므로 도메인 범주를 해당 서비스의 모든 IP 주소 모음으로 이해해서는 안 됩니다.
라우팅 분기
라우팅 분기
라우팅 분기는 정책에 따라 트래픽을 직접 연결, 프록시, 차단 등의 출구로 보내는 방식이지 새로운 프록시 프로토콜이 아닙니다. 화면의 규칙 모드는 보통 미리 설정된 라우팅 규칙을 활성화하지만, 모드 이름과 구체적인 동작은 클라이언트마다 다를 수 있습니다. 규칙 모드를 선택해도 모든 앱이 프록시를 통과하는 것은 아닙니다. 트래픽이 들어오는 경로는 시스템 프록시, TUN 또는 앱 자체 설정에 따라 결정됩니다.
트래픽이 클라이언트로 들어오는 경로 알아보기 →DNS
라우팅 분기
DNS는 도메인을 IP 등의 레코드로 변환합니다. 프록시 환경에서는 앱, 운영체제, 코어가 모두 해석 과정에 관여할 수 있습니다. 어떤 리졸버를 선택하는지, 조회가 어느 경로로 나가는지, 라우팅 단계에서 도메인과 IP 중 무엇을 사용하는지에 따라 결과가 달라집니다. DNS 주소 하나만 바꿔도 모든 앱이 같은 경로를 이용하는 것은 아니므로 캐시, 브라우저 설정, 코어의 해석 정책도 함께 확인하세요.
예상 DNS 경로에서 벗어나는 문제 알아보기 →클라이언트 설정
먼저 트래픽을 처리하는 범위를 이해한 뒤 실행 모드를 선택하세요. 테스트 지표는 문제를 찾는 데 도움이 되지만 실제 앱으로 확인하는 과정을 대신하지는 않습니다.
시스템 프록시
클라이언트 설정
시스템 프록시는 앱이 읽도록 운영체제에서 제공하는 프록시 설정으로, 보통 클라이언트가 수신 대기하는 로컬 주소와 포트를 가리킵니다. 이 설정을 따르는 앱만 해당 경로로 요청을 전달하므로 시스템 프록시를 켠다고 모든 네트워크 트래픽이 처리되는 것은 아닙니다. 앱 자체 프록시, 별도 네트워크 스택, 다른 프록시 도구의 설정에 따라 최종 경로가 달라질 수 있습니다.
시스템 프록시 설정 방법 보기 →TUN 모드
클라이언트 설정
TUN 모드는 가상 네트워크 인터페이스로 IP 패킷을 받아 프록시 구성 요소에 전달하므로 시스템 프록시만 설정하는 것보다 더 넓은 범위의 트래픽을 처리할 수 있습니다. 추가 권한과 라우팅·DNS 설정이 필요할 수 있으며, 기기의 모든 연결이 반드시 프록시를 거친다는 뜻은 아닙니다. 다른 가상 네트워크 도구와 함께 사용한다면 라우팅 충돌과 프록시 자체 트래픽의 루프백 문제도 확인하세요.
트래픽 처리 모드와 라우팅 정책 구분하기 →FakeDNS
클라이언트 설정
FakeDNS는 도메인에 예약된 주소 풀의 가상 IP를 할당하고 매핑을 저장해 둡니다. 이후 트래픽을 처리할 때 이 매핑을 통해 도메인을 복원할 수 있습니다. 반환된 주소는 대상 서버의 실제 IP가 아니며, 앱이 해당 주소에 접속하면 관련 구성 요소가 후속 처리를 해야 합니다. 사용 조건, 주소 풀, 라우팅 설정이 서로 맞아야 합니다. 매핑을 인식하지 못하는 경로로 가상 IP가 전달되면 연결에 실패할 수 있습니다.
DNS와 라우팅의 관계 보기 →DNS 누수
클라이언트 설정
DNS 누수는 예상한 해석 경로를 벗어나 조회가 발생하는 현상입니다. 예를 들어 코어가 처리하도록 설정한 조회가 시스템 리졸버를 통해 나갈 수 있습니다. 판단하기 전에 사용할 리졸버, 전송 방식, 조회 경로를 명확히 해야 하며 리졸버가 표시하는 지역만으로 결론을 내려서는 안 됩니다. 브라우저의 별도 암호화 DNS, 앱 자체 DNS, 여러 네트워크 인터페이스로 인해 경로가 달라질 수도 있습니다.
DNS 해석 및 연결 문제 보기 →지연 시간
클라이언트 설정
지연 시간은 특정 측정 작업에 걸린 시간을 뜻하지만 TCP 연결, ICMP 탐지, HTTP 요청은 서로 다른 과정을 측정합니다. TCP 연결 시간이 짧더라도 프록시 인증이나 TLS 핸드셰이크, 대상 웹사이트 접속에 성공한다는 보장은 없습니다. 설정을 비교할 때는 같은 측정 방식과 대상을 사용하고, 한 번의 결과만으로 순위를 매기기보다 안정성과 실제 앱 사용 경험도 고려하세요.
실제 연결 테스트의 의미 보기 →실제 연결 지연 시간
클라이언트 설정
실제 연결 지연 시간은 일반적으로 클라이언트가 선택한 프록시 설정을 통해 테스트 주소에 요청을 보내고 걸린 시간을 기록한 값입니다. 측정 범위는 구현에 따라 달라집니다. 서버 포트만 확인하는 것보다 실제 프록시 접속에 가깝지만, 해당 대상과 측정 시점의 네트워크 상태만 나타냅니다. 테스트에 실패하면 로그를 살펴 DNS 해석, 핸드셰이크, 요청 단계 중 어디서 문제가 생겼는지 구분하세요. 테스트에 성공해도 모든 사이트에 접속할 수 있다는 뜻은 아닙니다.
연결 후 확인 단계 보기 →