VMess
프로토콜과 전송 방식 · 프록시 프로토콜VMess는 Project V 생태계의 프록시 프로토콜로, 연결 설정에는 사용자 식별 정보와 서버 주소 등이 포함됩니다. TCP나 WebSocket과 같은 전송 방식과는 다릅니다. 하나의 프로토콜도 여러 전송 방식과 조합할 수 있습니다. 가져온 설정으로 연결되지 않는다면 주소와 포트만 확인하지 말고 인증 정보, 전송 설정, 기기 시간도 함께 점검하세요.
설정 상황에 맞춰 개념을 찾아보세요. 먼저 프로토콜, 코어, 클라이언트의 차이를 구분한 뒤 구독, 프록시 모드, 라우팅 규칙의 관계를 이해할 수 있습니다.
프로토콜은 양쪽이 통신하는 방식을 정하고, 전송 방식과 보안 계층은 연결을 전달하고 보호하는 방법을 정합니다. 세 가지를 각각 확인해야 합니다.
VMess는 Project V 생태계의 프록시 프로토콜로, 연결 설정에는 사용자 식별 정보와 서버 주소 등이 포함됩니다. TCP나 WebSocket과 같은 전송 방식과는 다릅니다. 하나의 프로토콜도 여러 전송 방식과 조합할 수 있습니다. 가져온 설정으로 연결되지 않는다면 주소와 포트만 확인하지 말고 인증 정보, 전송 설정, 기기 시간도 함께 점검하세요.
VLESS는 가벼운 프록시 프로토콜로, 자체적으로 데이터를 암호화하지 않습니다. 일반적으로 TLS나 REALITY 같은 보안 메커니즘과 함께 사용합니다. 설정의 사용자 식별자, 흐름 제어 옵션, 보안 매개변수를 서버와 일치시켜야 합니다. 기존 설정에서 프로토콜 이름만 VLESS로 바꿔서는 프로토콜을 전환할 수 없습니다.
Trojan은 일반적으로 TLS로 연결을 보호하고 비밀번호로 인증합니다. 서버 주소, 비밀번호, 서버 이름, 인증서 검증 옵션이 모두 연결 결과에 영향을 줄 수 있습니다. 인증서 오류가 발생하면 먼저 서버 이름과 기기 시간을 확인하세요. 인증서 검증을 끄는 것은 일반적인 해결 방법으로 권장되지 않습니다.
REALITY는 Xray 생태계의 전송 보안 메커니즘입니다. VMess, VLESS와 나란히 쓰이는 독립 프록시 프로토콜은 아니며, 흔히 VLESS와 조합합니다. 공개 키, 짧은 ID, 서버 이름 등의 매개변수를 정확히 맞춰야 합니다. 클라이언트에 해당 항목이 표시된다고 해서 현재 사용하는 코어가 그 조합을 지원하는 것은 아닙니다.
클라이언트는 조작 인터페이스를 제공하고, 코어는 실제 통신을 처리합니다. 지원 여부는 소프트웨어 이름만이 아니라 현재 실행 중인 구성 요소를 기준으로 확인해야 합니다.
코어는 설정을 해석하고 연결을 설정하며 DNS와 라우팅 로직을 실행합니다. 그래픽 클라이언트는 설정을 가져오고 편집한 뒤 실행하는 역할을 합니다. 인터페이스가 정상적으로 시작됐다고 해서 코어도 정상 실행 중이라는 뜻은 아닙니다. 문제를 확인할 때는 인터페이스 오류와 코어 실행 로그를 구분하고, 사용 중인 코어가 해당 프로토콜과 전송 매개변수를 처리할 수 있는지 확인하세요.
Xray는 V2Ray와 기술적 뿌리를 공유하는 코어 프로젝트로, 독자적인 프로토콜과 전송 기능을 발전시켜 왔습니다. v2rayNG는 Xray 코어를 사용하며, v2rayN도 해당 코어를 호출해 연결을 처리할 수 있습니다. 구체적인 기능은 코어 버전과 클라이언트 호환성에 따라 달라지므로 특정 버전의 지원 여부를 모든 배포판에 적용할 수는 없습니다.
V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트로, 코어와 관련 기술 생태계를 관리합니다. v2flyNG는 이 코어 계열을 사용합니다. V2Fly와 Xray는 기술적 뿌리를 공유하지만 기능 목록이 완전히 같지는 않습니다. 기존 설정에 필요한 프로토콜과 전송 기능을 기준으로 선택하고, 두 프로젝트의 설정 파일을 자유롭게 바꿔 쓸 수 있다고 가정하지 마세요.
sing-box는 독립적인 프록시 플랫폼이자 코어 프로젝트이며, v2rayN의 일부 기능은 이를 호출해 실행할 수 있습니다. Xray와 설정 구조, 규칙 표현 방식, 기능 구현이 다르므로 설정 파일을 직접 함께 사용할 수 없습니다. 그래픽 인터페이스에서 코어를 전환할 때는 클라이언트가 현재 연결 설정과 라우팅 설정을 빠짐없이 변환할 수 있는지도 확인하세요.
먼저 트래픽이 클라이언트로 들어오는 방식을 확인한 다음, 유입된 트래픽에 적용할 처리 규칙을 살펴보세요. 시스템 프록시, PAC, TUN은 서로 다른 계층에서 동작합니다.
시스템 프록시는 운영체제에 프록시 주소를 등록해 시스템 설정을 따르는 앱의 요청을 클라이언트로 전달합니다. 일부 앱은 별도의 네트워크 설정을 사용하므로 시스템 프록시를 켜도 모든 트래픽이 처리되는 것은 아닙니다. 클라이언트를 종료한 뒤에도 브라우저가 중지된 로컬 프록시 포트를 가리킨다면 남아 있는 시스템 프록시 설정을 지우세요.
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받은 뒤 프록시 구성 요소에 전달합니다. 시스템 프록시 설정을 따르지 않는 앱까지 처리해야 할 때 유용합니다. 별도의 권한, 라우팅, DNS 설정이 필요한 경우가 많으며, 시스템 프록시의 적용 범위를 단순히 넓히는 스위치는 아닙니다. 다른 가상 네트워크 도구와 함께 실행할 때는 라우팅 충돌에 유의하세요.
PAC는 자동 프록시 설정을 지원하는 앱에서 스크립트를 사용해 직결할지 프록시를 사용할지 결정합니다. 판단 기준은 요청 주소나 호스트 이름인 경우가 많습니다. 프록시로 전달된 연결만 클라이언트 코어의 라우팅 절차로 이어집니다. 따라서 PAC가 직결로 판단하는 과정과 코어 규칙이 직결로 판단하는 과정은 별개이므로 각각 확인해야 합니다.
코어 전환은 클라이언트가 실제로 호출하는 런타임 구성 요소를 바꾸는 것이며, 서버나 구독 출처를 바꾸는 작업은 아닙니다. 전환 전에 프로토콜, 보안 메커니즘, DNS, 규칙 형식을 대상 코어가 처리할 수 있는지 확인하세요. 전환 후 기존 설정이 작동하지 않으면 먼저 정상 작동이 확인된 조합으로 되돌리고 로그를 살펴보세요. 여러 매개변수를 한꺼번에 바꾸면 원인을 찾기 어렵습니다.
구독은 설정을 업데이트하는 진입점이고, 노드는 개별 연결 설정입니다. 설정 출처를 관리하는 일과 현재 연결을 선택하는 일은 서로 다릅니다.
구독은 하나의 주소를 통해 여러 설정을 가져오며, 이후 업데이트에서 원본의 추가·삭제 및 매개변수 변경 사항을 반영할 수 있습니다. 주소에 접근 자격 증명이 포함될 수 있으므로 비밀번호처럼 안전하게 보관하고, 화면 캡처나 로그를 공유할 때는 가리세요. 업데이트 실패는 가져오기 또는 구문 분석 단계에 문제가 있다는 뜻일 뿐, 이미 가져온 모든 연결이 사용할 수 없다는 의미는 아닙니다.
노드는 클라이언트에서 연결 설정 하나를 가리킬 때 흔히 쓰는 말입니다. 보통 서버 주소, 포트, 인증 정보, 프로토콜, 전송 매개변수가 포함됩니다. 표시 이름은 메모일 뿐 서버 위치나 회선 특성을 정확히 나타내지 않을 수 있습니다. 노드 사용 가능 여부는 이름만으로 판단하지 말고 실제 연결 테스트와 로그를 함께 확인하세요.
공유 링크는 보통 vmess:// 또는 vless:// 같은 프로토콜 접두사가 붙으며, 연결 설정 하나를 담습니다. 클립보드에서 가져올 때 편리하지만 구독처럼 원본 변경 사항이 계속 동기화되지는 않습니다. 복사할 때는 전체 내용을 보존하세요. 메신저에서 내용이 잘리거나 불필요한 공백이 들어가거나 문자가 잘못 이스케이프되면 파싱에 실패할 수 있습니다.
구독 그룹은 출처별로 주소와 가져온 설정을 정리해 각각 업데이트하고 이름을 바꾸거나 쉽게 찾도록 합니다. 그룹 자체가 부하 분산을 뜻하거나 현재 연결 실패 시 자동으로 전환해 주는 것은 아닙니다. 구독에서 가져온 항목을 직접 수정하기 전에 다음 업데이트에서 변경 내용이 덮어써지는지 확인하세요. 오래 유지해야 하는 설정은 별도로 저장하는 것이 좋습니다.
규칙이 연결의 경로를 결정합니다. 도메인 데이터, IP 데이터, 기본 아웃바운드를 함께 구성해야 하며 서로 대체할 수는 없습니다.
라우팅 규칙은 도메인, IP, 포트 등의 조건에 따라 연결에 직결, 프록시 또는 다른 아웃바운드를 지정합니다. 일반적인 설정은 규칙을 순서대로 검사하므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다. 어떤 규칙에도 맞지 않으면 기본 아웃바운드가 적용됩니다. 특정 웹사이트의 경로를 확인할 때는 규칙 순서와 기본 처리 정책을 모두 살펴보세요.
GeoIP는 라우팅에서 보통 범주별로 정리된 IP 주소 범위 데이터를 가리키며, 규칙이 대상 주소의 분류를 판단하는 데 사용합니다. IP 주소 하나만으로 웹사이트의 운영 주체나 모든 접속 경로를 정확히 추론할 수는 없습니다. 웹사이트가 콘텐츠 전송 네트워크를 사용하면 주소가 바뀔 수 있으며, 규칙 결과는 실제로 확인된 IP 주소와 데이터셋 업데이트 여부에도 영향을 받습니다.
GeoSite는 범주별로 정리된 도메인 매칭 데이터로, 관련 도메인 그룹을 같은 아웃바운드로 보낼 때 사용할 수 있습니다. 분류 범위는 데이터셋에 따라 달라지며 웹사이트의 실시간 상태를 확인하는 기능은 아닙니다. 하나의 페이지가 여러 도메인에 의존할 수 있으므로 기본 도메인이 규칙에 일치하더라도 이미지, 로그인, 미디어 리소스가 같은 경로를 사용한다고 볼 수는 없습니다.
트래픽 분기는 규칙에 따라 연결마다 다른 경로를 적용하는 방식입니다. 예를 들어 로컬 네트워크 주소는 직결하고 지정한 도메인은 프록시로 보낼 수 있습니다. 속도 측정 후 노드를 선택하는 기능과는 다르며 모든 연결의 속도를 자동으로 높여 주지도 않습니다. 먼저 분명한 기본 정책을 설정한 뒤 예외를 단계적으로 추가하고, 접속 결과와 로그로 규칙 적용 여부를 확인하세요.
테스트 결과는 특정 경로와 조건에서 얻은 값만 보여 줍니다. 연결, DNS 조회, 전송 속도를 각각 확인하고 하나의 지표로 모든 상황을 판단하지 마세요.
지연 시간은 테스트 요청을 보낸 뒤 응답을 받을 때까지 걸리는 시간입니다. 도구마다 측정하는 경로가 다르므로 ICMP 테스트, TCP 연결 설정, 프록시를 통한 웹페이지 접속 결과를 같은 값으로 볼 수는 없습니다. 지연 시간이 짧아도 다운로드 속도가 빠르다고 보장할 수 없습니다. 지속적인 전송 속도에는 대역폭, 혼잡도, 서버 부하, 대상 사이트 상태도 영향을 줍니다.
실제 연결 지연 시간은 일반적으로 클라이언트가 선택한 프록시 설정으로 테스트 주소에 실제 요청을 보내 측정한 시간입니다. 구체적인 측정 범위는 구현 방식에 따라 달라집니다. 단순한 포트 연결 확인보다 실제 사용 환경에 가깝지만 테스트 대상 하나만 반영합니다. 시간 초과는 DNS, 인증, 핸드셰이크, 대상 주소 연결 불가 등으로 발생할 수 있으므로 로그를 함께 확인하세요.
FakeDNS는 도메인에 가상 IP를 할당하고 도메인과 주소의 매핑을 유지해, 프록시 구성 요소가 이후 연결에서 도메인 정보를 복원하도록 합니다. 가상 주소는 웹사이트의 실제 서버 주소가 아니므로 연동되는 구성 요소가 이어서 처리해야 합니다. DNS 요청과 연결 트래픽이 서로 다른 경로를 사용하면 매핑을 활용하지 못해 DNS 조회는 성공했지만 접속은 실패할 수 있습니다.
DNS 누수는 도메인 조회가 예상한 경로로 처리되지 않는 상황을 말합니다. 예를 들어 연결은 프록시를 거치지만 DNS 조회는 기존 리졸버로 전송될 수 있습니다. 시스템 DNS, 클라이언트 DNS, 브라우저에 내장된 암호화 DNS가 각각 작동할 수 있으므로 따로 확인하세요. 모든 로컬 DNS 조회를 문제로 단정하기보다 실제 조회가 어디를 거치는지 확인하는 것이 중요합니다.