V2Ray 프로토콜 가이드와 클라이언트 선택

판단 기준 세우기

프록시 프로토콜, 전송 방식, 보안 계층부터 구분하기

클라이언트의 한 노드는 여러 계층의 조합입니다

v2rayN, v2rayNG 또는 v2flyNG에서 노드를 확인하면 인터페이스는 보통 프로토콜, 주소, 포트, 전송 방식, 보안 설정을 하나의 편집 양식에 함께 표시합니다. 이 요소들이 하나의 연결을 구성하지만 담당하는 역할은 서로 다릅니다. VMess, VLESS, Trojan, Shadowsocks는 주로 클라이언트의 인증 방식, 애플리케이션 트래픽의 캡슐화 방식, 서버의 연결 식별 방식을 정의합니다. TCP, WebSocket, gRPC 같은 전송 항목은 데이터를 어떤 운반 방식으로 보낼지 결정하고, TLS와 REALITY는 보안 및 핸드셰이크 계층에 해당합니다. 이 이름들을 모두 서로 대체 가능한 “프로토콜 모델”로 보면 잘못 비교하기 쉽습니다. 예를 들어 VLESS는 TCP, gRPC 등의 전송과 조합할 수 있고 다양한 보안 설정도 사용할 수 있습니다. REALITY는 보통 주소만 단독으로 입력해 작동하는 프록시 프로토콜이 아니라 VLESS 등의 인바운드·아웃바운드 구조와 함께 사용하는 보안 계층 방식입니다.

설정을 확인할 때는 바깥쪽 계층부터 안쪽으로 읽어 보세요. 먼저 서버 주소와 포트를 확인하면 “어디로 연결하는가”를 알 수 있습니다. 다음으로 전송 방식을 보면 “데이터가 어떻게 도착하는가”를 확인할 수 있습니다. 이어서 보안 계층과 핸드셰이크 매개변수는 “연결이 어떻게 보호된 세션을 구성하는가”를 설명합니다. 마지막으로 사용자 식별자, 비밀번호 또는 암호화 방식은 “서버가 이 사용자의 데이터를 어떻게 식별하고 처리하는가”를 결정합니다. 클라이언트는 구독을 가져온 뒤 보통 이 항목들을 자동으로 입력하므로 매번 하나씩 수정할 필요는 없습니다. 하지만 계층 구조를 이해하면 불완전한 가져오기, 잘못된 프로토콜 선택, 서로 맞지 않는 매개변수를 파악하는 데 도움이 됩니다.

이름이 같아도 조합이 완전히 같은 것은 아닙니다

둘 다 VLESS로 표시된 노드라도 실제 동작은 크게 다를 수 있습니다. 하나는 일반 TCP와 TLS를 사용하고 다른 하나는 gRPC와 REALITY를 사용할 수 있으며, 핸드셰이크 횟수, 연결 재사용 방식, 인증서 요구 사항, 사용 가능한 코어가 모두 다릅니다. 반대로 VMess와 VLESS는 인증 구조가 다르지만 동일한 하위 TCP 또는 WebSocket 전송을 사용할 수 있어 네트워크 경로에서 일부 동작이 비슷할 수 있습니다. 속도를 비교할 때 프로토콜 이름만 보면 회선 품질, 서버 부하, 전송 캡슐화, 보안 계층의 차이를 프로토콜 자체의 차이로 잘못 판단하기 쉽습니다.

프로토콜 선택은 모든 옵션을 켜는 일이 아닙니다. 캡슐화 계층을 추가할 때마다 보통 추가 헤더, 버퍼, 상태 관리가 필요하고, 반대로 계층을 줄이면 현재 배포에 필요한 핸드셰이크 기능이나 호환성을 잃을 수 있습니다. 올바른 방법은 서버 설정으로 가능한 조합을 먼저 정한 다음, 클라이언트 코어가 완전히 해석할 수 있고 기기 부담도 적절한 조합을 고르는 것입니다. 클라이언트의 프로토콜 항목은 서버와 일치해야 합니다. VMess 노드의 이름만 VLESS로 바꿀 수 없으며, 기존 TLS 매개변수를 그대로 둔 채 REALITY 옵션만 켠다고 해결되지도 않습니다.

지연 시간, 대역폭, 안정성은 서로 다른 지표입니다

클라이언트의 지연 시간 테스트는 보통 특정 탐색 연결을 설정하는 데 걸린 시간만 반영하며 지속적인 다운로드 속도와 같지 않습니다. 대역폭은 서버의 외부 회선, 네트워크 경로, 혼잡 제어, 단말 성능에 좌우됩니다. 안정성은 일정 시간 동안 패킷 손실, 재연결, 속도 급변이 발생하는지를 관찰해야 합니다. 한 번의 지연 시간 테스트에서 몇 밀리초가 줄었다고 해서 장시간 연결, 동영상 전송, 대량 동시 요청에 더 적합하다고 단정할 수는 없습니다. 선택할 때는 먼저 설정이 올바른지 확인한 뒤 같은 기기, 같은 네트워크 시간대, 같은 경로에서 비교해 환경 변화를 프로토콜 차이로 오해하지 않도록 하세요.

이 가이드에서는 서로 다른 역할을 설명하기 위해 “프록시 프로토콜”, “전송 방식”, “보안 계층”, “코어”라는 네 가지 용어를 사용합니다. 이 계층 구조를 유지하면 클라이언트의 복잡해 보이는 옵션도 추적 가능한 연결 흐름으로 바뀝니다. 새로운 이름을 접했을 때도 다른 이름보다 빠른지부터 묻기보다 어느 계층에 속하는지, 무엇을 대체하는지, 무엇에 의존하는지를 먼저 확인할 수 있습니다.

프로토콜의 배경과 범위

VMess, VLESS, Trojan, Shadowsocks 및 REALITY의 설계상 트레이드오프

VMess: 완성도 높은 인증 구조와 넓은 호환성

VMess는 Project V 생태계에서 클라이언트와 서버가 협력하는 방식이 비교적 일찍 정립된 프로토콜입니다. 사용자 식별자와 시간 관련 정보를 인증에 활용하며 데이터를 프로토콜 계층에서 캡슐화합니다. 장점은 축적된 설정 자료가 많고 V2Fly와 Xray 계열 모두 폭넓게 지원한다는 점입니다. 기존 구독과 운영 환경도 여전히 VMess를 중심으로 구성된 경우가 많습니다. 기존 서버를 유지하면서 여러 구형 클라이언트를 함께 연결해야 하는 환경에서는 캡슐화를 최소화하는 것보다 VMess의 호환성이 더 중요할 수 있습니다.

이처럼 구조가 완전한 만큼 클라이언트가 처리해야 할 프로토콜 로직도 많습니다. 시스템 시간이 크게 어긋나면 인증이 실패할 수 있고, WebSocket 같은 전송을 사용할 때는 경로, Host, 보안 계층 매개변수도 서로 일치해야 합니다. VMess는 “켜기만 하면 자동으로 맞는” 범용 형식이 아니므로 구독에서 전송 항목이 누락되면 연결에 실패합니다. 새로 배포하면서 구형 클라이언트 호환성이 필요하지 않다면 구조가 더 간결한 VLESS도 함께 검토할 수 있지만, 기존 VMess 노드를 반드시 이전해야 한다는 뜻은 아닙니다. 안정적으로 동작하는 설정을 바꿀지는 실제 부하, 유지 관리 비용, 클라이언트 지원 범위를 기준으로 결정해야 합니다.

VLESS: 인증과 암호화 역할의 분리

VLESS는 사용자 인증과 전송 보안의 역할을 분리합니다. 프로토콜 자체가 별도의 콘텐츠 암호화 로직을 중복해서 담당하지 않고 TLS, REALITY 등의 외부 계층에 보안 기능을 맡깁니다. 이 설계는 전달 경로를 명확하게 만들고 Xray 생태계에서 다양한 흐름 제어 및 보안 방식을 조합하기 쉽게 합니다. VLESS는 UUID 계열 식별자를 사용자 인증에 자주 사용하지만 식별자만으로 완전한 노드가 구성되는 것은 아닙니다. 전송 방식, 보안 계층, 서버 이름, 선택적 흐름 제어가 서버 설정과 하나씩 대응해야 합니다.

역할 분리의 장점은 불필요한 중복 처리를 줄이고 계층별로 독립적인 발전을 가능하게 한다는 점입니다. 대신 정확한 설정 조합이 더 중요해집니다. 클라이언트 인터페이스에서 VLESS를 선택할 수 있다고 해서 현재 코어가 구독에 포함된 모든 확장 필드를 지원하는 것은 아닙니다. 특히 노드에 REALITY, 공개 키, 짧은 식별자, 특정 흐름 제어가 포함되어 있다면 해당 필드를 완전히 인식할 수 있는 Xray 계열 코어를 우선 사용하세요. 이해하기 어려운 매개변수를 직접 삭제한다고 “호환 모드”가 되는 것이 아니라 핸드셰이크가 깨질 수 있습니다.

Trojan: 비밀번호 인증 중심의 간결한 구조

Trojan은 비밀번호로 사용자를 인증하며 보통 TLS와 함께 사용합니다. 매개변수 모델이 비교적 직관적이어서 서버, 포트, 비밀번호, 서버 이름, 인증서 관련 설정이 핵심을 이룹니다. 명확한 TLS 배포를 원하고 Trojan을 지원하는 여러 클라이언트 사이에서 이전하려는 사용자에게 이해하기 쉬운 구조입니다. 다만 서버 인증서, 도메인, 시스템 시간이 정상이어야 합니다. 인증서 이름 불일치, 잘못된 SNI, 비정상적인 시스템 시간은 프록시 인증 전에 TLS 핸드셰이크를 중단시킬 수 있습니다.

Trojan과 VLESS는 단순히 어느 쪽이 빠른지로 비교할 수 없습니다. 비슷한 네트워크 경로를 거칠 수 있고 둘 다 TLS를 사용할 수도 있습니다. 실제 차이는 인증 구조, 조합 가능한 확장 기능, 서버 구현, 클라이언트 코어에서 더 크게 발생합니다. 구독 제공자가 안정적인 Trojan 노드를 제공하고 클라이언트가 이를 완전히 가져온다면 이름이 다르다는 이유만으로 프로토콜을 바꿀 필요는 없습니다. 프로토콜은 클라이언트만으로 변환할 수 없으며, 다른 유형으로 바꾸려면 그에 맞는 서버 설정이 필요합니다.

Shadowsocks: 경량 데이터 암호화 프록시

Shadowsocks는 흔히 SS로 줄여 부르며 서버 주소, 포트, 비밀번호, 암호화 방식이 주요 매개변수입니다. 구조가 간결하고 클라이언트와 서버 구현이 널리 제공되어 설정 흐름이 짧거나 기기 리소스가 제한적이고 기존 호환성이 필요한 환경에 적합합니다. 핵심은 단순히 “가볍다”고 기억하는 것이 아니라 양쪽이 완전히 동일한 암호화 방식을 지원하는지 확인하는 것입니다. 구형 방식과 최신 AEAD 방식은 호환성과 구현 요구 사항이 다르며, 클라이언트 목록에 특정 항목이 있다고 해서 서버도 같은 방식을 사용한다는 뜻은 아닙니다.

Shadowsocks 공유 링크에는 핵심 매개변수를 담을 수 있지만 플러그인이나 추가 전송 정보는 서로 다른 확장 형식을 사용할 수 있습니다. 구독 변환 과정에서 주소, 포트, 비밀번호만 남으면 추가 매개변수가 사라질 수 있습니다. 따라서 가져온 뒤에는 노드 이름이 보이는지만 확인하지 말고 암호화 방식과 플러그인 필드를 점검해야 합니다. VMess와 VLESS처럼 성능은 여전히 네트워크 경로와 서버 구현의 영향을 받으므로, 프로토콜 구조가 간결하다고 모든 환경에서 처리량이 더 높아지는 것은 아닙니다.

REALITY: 보안 핸드셰이크 방식이며 독립된 노드 유형이 아닙니다

REALITY는 주로 Xray 생태계에서 사용되며 보안 핸드셰이크와 신원 확인 문제를 처리합니다. 실제 설정에서는 VLESS와 REALITY를 함께 사용하는 경우가 많아 클라이언트 목록에서 REALITY가 강조되기도 하지만, 하위 프록시 프로토콜은 별도로 확인해야 합니다. 대표적인 매개변수로 서버 이름, 공개 키, 짧은 식별자, 선택적 지문 등이 있으며 서버가 생성해 제공하는 연동 정보입니다. 공개 키나 짧은 식별자에서 한 글자라도 빠지거나 서버 이름이 일치하지 않으면 핸드셰이크가 즉시 실패할 수 있습니다.

REALITY의 가치는 모든 TLS 사용 방식을 대체하는 데 있지 않고 특정 핸드셰이크 및 배포 모델에 있습니다. 호환되는 Xray 코어와 정확한 구독 필드가 필요하며, 노드 이름에 REALITY가 포함되어 있다고 V2Fly 계열 코어가 같은 기능을 자동으로 얻는 것은 아닙니다. 사용하기 전에 클라이언트가 실제로 어떤 코어를 사용하는지 확인하고 구독에 필요한 매개변수가 모두 포함되어 있는지 살펴보세요. 핸드셰이크 비용과 XTLS Vision의 전달 경로를 더 이해하려면 REALITY와 XTLS Vision 기술 설명을 읽어 보세요.

성능 판단

연결 속도, 처리량, 전달 경로를 비교하는 방법

핸드셰이크 비용은 최초 연결에 영향을 주지만 지속 속도를 완전히 결정하지는 않습니다

새 웹 페이지를 열 때 단말은 먼저 도메인 확인, 서버와의 TCP 또는 기타 전송 연결, 보안 핸드셰이크, 프록시 인증을 차례로 완료한 뒤 대상 요청을 전송할 수 있습니다. 프로토콜과 보안 계층은 이 흐름의 일부 단계에 영향을 줍니다. VMess는 자체 인증과 캡슐화를 처리하고, VLESS는 프로토콜 구조가 더 간결하지만 외부에서 TLS나 REALITY를 사용하면 해당 핸드셰이크를 수행해야 합니다. Trojan은 보통 TLS에 의존하고, Shadowsocks는 선택한 암호화 방식에 따라 데이터 처리 상태를 구성합니다. 최초 연결 차이는 대개 밀리초 단위이며, 네트워크 왕복 거리가 길수록 경로 지연이 로컬 프로토콜 처리보다 더 크게 나타납니다.

지속 전송 단계에서는 각 데이터 블록이 복사, 암호화, 캡슐화, 버퍼링을 몇 번 거치는지가 더 중요합니다. 코어 구현, 운영체제 네트워크 스택, 전송 조합이 모두 영향을 줍니다. 일부 흐름 제어 방식은 특정 조건에서 중복 암호화나 데이터 복사를 줄이려 하지만 클라이언트, 서버, 외부 조건이 모두 맞아야 작동합니다. 클라이언트에서 흐름 제어 이름 하나만 선택하고 서버에 같은 기능이 없으면 일반 연결로 자동 전환되지 않고 보통 연결에 실패합니다.

전송 방식이 프록시 프로토콜 이름보다 실제 성능을 더 크게 바꿀 수 있습니다

일반 TCP는 캡슐화 단계가 짧아 직접적인 전달을 원하는 설정에 적합합니다. WebSocket은 프레임과 경로 등의 필드를 추가하며, 해당 웹 서비스 배포 구조와 연동할 수 있다는 장점이 있지만 추가 캡슐화와 중간 계층이 처리량과 지연 시간에 영향을 줍니다. gRPC는 HTTP/2를 기반으로 스트림과 연결 관리 기능을 제공하므로 적절한 서버 환경에서 장시간 연결을 구성하기 좋지만 올바른 서비스 이름과 HTTP/2 지원이 필요합니다. 한 노드는 TCP, 다른 노드는 WebSocket을 사용한다면 둘 다 VLESS라고 적혀 있어도 테스트 결과를 VLESS 자체의 차이로 볼 수 없습니다.

연결 재사용도 신중하게 이해해야 합니다. 재사용하면 여러 논리 요청이 더 적은 하위 연결을 공유해 반복적인 핸드셰이크를 줄일 수 있지만, 하위 연결에서 혼잡이나 패킷 손실이 발생하면 여러 요청이 함께 영향을 받을 수 있습니다. 브라우저와 최신 애플리케이션 자체가 이미 연결 풀이나 HTTP/2를 사용하므로 프록시 계층에서 재사용을 추가해도 항상 이득이 되지는 않습니다. 기본 설정으로 시작하고 짧은 연결이 많아 핸드셰이크 비용이 뚜렷할 때 재사용을 테스트하세요. 웹 페이지 최초 로딩, 지속 다운로드, 다중 작업 동시 실행을 각각 관찰해야 하며 한 번의 지연 시간만 보아서는 안 됩니다.

재현 가능한 비교 방법 세우기

유효한 테스트를 위해 변수를 통제해야 합니다. 같은 기기, 같은 네트워크, 비슷한 시간대에 여러 노드를 테스트하세요. 프로토콜을 비교하려면 가능한 한 서버 위치, 부하, 전송 방식을 비슷하게 맞추는 것이 좋습니다. 각 항목에서 최초 로딩, 지속 전송, 네트워크 전환 후 복구를 관찰하세요. 지연 시간 테스트는 접근할 수 없거나 왕복 시간이 지나치게 긴 노드를 걸러내는 데 유용하지만 최종 판단은 실제 애플리케이션 사용을 기준으로 해야 합니다. 결과 변동이 크다면 먼저 테스트를 반복하고 회선 시간대를 확인하세요. Mux, 라우팅, DNS, 프로토콜을 한꺼번에 바꾸면 어떤 변경이 영향을 주었는지 알 수 없습니다.

v2rayN의 데스크톱 환경은 보통 프로세서와 메모리가 더 여유로워 복잡한 규칙과 동시 연결을 감당할 수 있습니다. 반면 Android의 v2rayNG와 v2flyNG는 배터리 정책, 백그라운드 제한, 네트워크 전환의 영향을 함께 받습니다. 데스크톱 테스트 결과를 모바일에 그대로 적용할 수는 없습니다. 전체 속도가 떨어졌다면 노드, 회선, 로컬 설정의 세 계층으로 나누어 확인하세요. 관련 절차는 V2Ray 속도 저하 계층별 점검을 참고할 수 있습니다. 먼저 문제가 연결 설정, 지속 처리량, 라우팅 선택 중 어디에 속하는지 확인한 뒤 프로토콜 조합을 바꾸세요.

단말 부담

리소스 사용량, 모바일 전력 소모, 백그라운드 연결

프로세서 부담은 전체 데이터 경로에서 발생합니다

프로토콜 자체는 전체 리소스 소비의 일부만 차지합니다. 암호화 알고리즘, 보안 핸드셰이크, 전송 캡슐화, DNS 조회, 라우팅 규칙 매칭, 연결 로그, 그래픽 인터페이스가 모두 프로세서와 메모리를 사용합니다. Shadowsocks는 구조가 간결해 경량으로 여겨지는 경우가 많지만 실제 부담은 암호화 방식과 기기가 하드웨어 기능을 활용하는지에 따라 달라집니다. VLESS가 프로토콜 계층의 중복 처리를 줄여도 외부 TLS, REALITY 또는 전송 계층에는 여전히 연산이 필요합니다. VMess에 프로토콜 로직이 한 계층 더 있다고 해서 최신 데스크톱에서 반드시 체감 가능한 병목이 생기는 것은 아닙니다. 고처리량, 저전력 기기, 다수의 동시 연결에서만 차이가 더 뚜렷하게 나타나는 경우가 많습니다.

메모리 사용량은 연결 수, 버퍼, 라우팅 규칙 규모, 로그 수준과 밀접한 관련이 있습니다. 많은 도메인 규칙과 여러 아웃바운드를 포함한 설정은 단일 노드 직접 연결보다 보통 더 많은 메모리를 사용합니다. 상세 로그를 켜면 더 많은 연결 이벤트를 기록해 쓰기 작업도 늘어날 수 있습니다. 문제 해결이 끝나면 일상적인 필요에 맞는 로그 수준으로 되돌려 과도한 기록을 장기간 남기지 마세요. 클라이언트 창의 사용량과 코어 프로세스의 사용량은 구분해서 봐야 합니다. v2rayN의 그래픽 인터페이스와 실제 프록시 코어는 역할이 다르므로 창을 트레이로 내려도 코어가 시스템 프록시 트래픽을 계속 처리할 수 있습니다.

모바일 전력 소모는 주로 깨우기 빈도와 네트워크 상태의 영향을 받습니다

Android 기기의 배터리 소모는 “암호화를 사용하는가”만으로 판단할 수 없습니다. 장시간 연결을 유지하면 네트워크 모듈이 주기적으로 작동하고, 짧은 연결을 자주 만들면 핸드셰이크와 깨우기 횟수가 늘어납니다. 신호가 약하면 무선 모듈이 송신 전력을 높일 수도 있습니다. Wi-Fi와 모바일 네트워크 사이를 전환하면 기존 연결이 끊어져 다시 설정되므로 추가 소모가 발생합니다. 시스템이 v2rayNG 또는 v2flyNG의 백그라운드 동작을 제한하면 연결이 일시 중지될 수 있고, 사용자가 앱을 다시 열 때 재연결이 한꺼번에 발생해 불안정하거나 짧은 리소스 급증이 나타날 수 있습니다.

프로토콜 선택이 전력에 미치는 영향은 같은 트래픽 조건에서 관찰해야 합니다. 경량 캡슐화가 일부 연산을 줄일 수 있지만 노드 불안정으로 계속 재연결되면 절약한 연산량이 네트워크 깨우기로 빠르게 상쇄됩니다. 이론적으로 처리 단계가 적지만 실제로 자주 끊기는 방식보다 안정적인 연결을 오래 유지하는 방식이 더 적은 전력을 사용하는 경우가 많습니다. 연결 재사용은 하위 연결 수를 줄일 수 있지만, 모바일 네트워크 전환 후 공유 연결의 복구가 원활하지 않으면 여러 요청이 함께 재시도될 수도 있습니다. 모바일에서는 적당한 규칙 규모와 서버가 명확히 지원하는 기본 전송을 사용하고, 먼저 안정적으로 운영한 뒤 항목별로 조정하는 것이 좋습니다.

v2rayNG와 v2flyNG의 리소스 차이는 코어 기능과 함께 판단해야 합니다

v2rayNG는 Xray 코어를 사용하므로 구독에 VLESS, REALITY 또는 Xray 확장 기능이 포함된 경우에 적합합니다. v2flyNG는 v2fly 코어를 사용하므로 VMess, Shadowsocks 등 V2Fly 호환 설정이 중심인 환경에 더 알맞습니다. 둘을 설치 파일 크기나 한 번의 백그라운드 사용량만으로 평가해서는 안 됩니다. v2flyNG가 노드에 필요한 REALITY 필드를 해석하지 못하면 유휴 사용량이 낮아도 목표 연결을 완료할 수 없습니다. 반대로 구독이 기본 VMess만 제공한다면 복잡한 확장 기능이 속도를 자동으로 개선하지도 않습니다.

모바일 리소스를 관찰할 때는 최소한 화면 켜짐, 화면 꺼짐, 네트워크 전환, 지속 전송의 네 가지 상태를 포함하세요. 시스템 배터리 통계는 일정 기간의 전체 추세를 확인하는 데 적합하며 몇 분간의 표본으로 결론을 내리기에는 부족합니다. 프록시가 발생시킨 트래픽과 특정 애플리케이션 자체의 트래픽도 구분해야 합니다. 동영상 재생, 클라우드 동기화, 대용량 파일 업데이트는 원래 네트워크를 많이 사용하며 클라이언트는 이를 전달할 뿐입니다. 대기 중 배터리 소모가 비정상적이면 먼저 앱의 지속적인 요청, 노드의 반복 재연결, 지나치게 잦은 구독 업데이트를 확인한 뒤 프로토콜과 코어를 살펴보세요.

리소스 사용량을 줄이는 조정 순서

먼저 필요하지 않은 상세 로그와 반복 속도 측정을 끄고, 실패한 노드, 지나치게 잦은 구독 업데이트, 과도하게 큰 라우팅 규칙을 줄이세요. 그다음 잦은 재연결이 있는지 관찰하고, 마지막으로 전송 방식과 프로토콜 조합을 비교합니다. 한 번에 하나만 바꾸고 충분히 긴 관찰 기간을 유지하세요. 기기가 유휴 상태일 때 메모리가 다소 높더라도 시스템에 메모리 회수 압박이 없고 연결이 안정적이라면 숫자를 낮추기 위해 코어를 자주 재시작할 필요는 없습니다. 최신 운영체제는 사용 가능한 메모리를 캐시에 활용하므로 지속적인 증가, 끊김, 비정상 발열, 연결 반복이 실제로 주의할 대상입니다.

코어 계열

V2Fly와 Xray의 관계, 기능 범위, 설정 호환성

공통된 출처가 기능 동기화를 의미하지는 않습니다

V2Fly와 Xray는 모두 Project V 생태계의 설정 모델과 다중 프로토콜 전달 방식을 이어받았기 때문에 인바운드가 로컬 또는 외부 연결을 받고, 아웃바운드가 트래픽을 목적지로 보내며, 라우팅이 도메인·주소·포트 등의 조건으로 아웃바운드를 선택한다는 기본 개념이 비슷합니다. VMess, Shadowsocks, SOCKS, HTTP 같은 일반적인 구조도 양쪽에서 상당한 공통 이해가 가능합니다. 한 코어에서 다른 코어로 옮길 때 “인바운드—라우팅—아웃바운드”라는 틀을 새로 배울 필요는 보통 없습니다.

하지만 두 코어는 이미 독립적으로 발전하는 별개의 계열입니다. 새 기능의 도입 시점, 필드 이름, 기본값, 확장 프로토콜이 항상 일치한다고 보장할 수 없습니다. Xray에서는 VLESS, REALITY, XTLS Vision 등의 조합이 흔하고 V2Fly는 자체 방향에 따라 프로토콜, 전송, 설정 기능을 유지합니다. JSON의 형태가 비슷하다고 모든 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다. 클라이언트가 노드를 표시한다고 해서 현재 선택한 코어가 해당 노드를 실행할 수 있다는 뜻도 아닙니다. 일부 클라이언트는 알 수 없는 필드를 먼저 저장했다가 코어를 실제로 시작할 때 지원하지 않거나 해석할 수 없다는 오류를 반환합니다.

세 클라이언트와 코어의 대응 관계

v2rayN은 Windows, macOS, Linux용 데스크톱 클라이언트로 구독 관리, 시스템 프록시, 라우팅 편집, 코어 호출 등을 담당하므로 데스크톱에서는 우선 이 클라이언트부터 고려할 수 있습니다. 여러 코어의 기능에 맞춰 설정을 구성할 수 있지만 특정 노드의 사용 가능 여부는 실제로 패키징되고 선택된 코어에 달려 있습니다. v2rayNG는 Android에서 Xray 코어를 주로 기반으로 하며 VLESS, REALITY 및 관련 Xray 설정에 적합합니다. v2flyNG는 v2fly 코어를 대상으로 하며 Android에서 V2Fly 기능이 필요할 때 선택할 수 있습니다.

그래픽 클라이언트가 곧 프로토콜 자체는 아닙니다. 클라이언트는 구독이나 양식을 코어 설정으로 변환하고 프로세스를 시작하며 시스템 네트워크 진입점을 조정합니다. 실제 프로토콜 해석과 데이터 전달은 코어가 담당합니다. “같은 노드가 한 클라이언트에서는 작동하지만 다른 클라이언트에서는 작동하지 않는” 경우 먼저 양쪽의 코어 계열과 설정 필드를 비교해야 하며 인터페이스 이름만 비교해서는 안 됩니다. 두 클라이언트가 같은 계열을 사용한다면 가져오기 과정, 버전이 지원하는 필드, 시스템 네트워크 권한을 확인하세요.

설정 호환성은 문법, 필드, 동작의 세 계층으로 나눌 수 있습니다

첫 번째는 문법 호환성으로 JSON을 해석할 수 있는지 확인하는 단계입니다. 파일의 문법이 올바르다는 것은 괄호, 따옴표, 데이터 형식이 기본적으로 합법적이라는 뜻일 뿐입니다. 두 번째는 필드 호환성으로 코어가 프로토콜 이름과 구체적인 키·값을 인식하는지 확인합니다. 세 번째는 동작 호환성으로 같은 이름의 필드가 두 구현에서 동일한 기본값, 경계 조건, 조합 제한을 갖는지 살펴봅니다. 이전할 때 첫 번째 단계만 통과하는 것으로는 부족합니다. 가장 안정적인 방법은 기존 코어의 전체 실행 설정을 그대로 복사하지 않고 대상 클라이언트가 구독을 바탕으로 설정을 다시 생성하게 하는 것입니다.

아래 조각은 VLESS 아웃바운드의 기본 계층 구조를 보여 주며 필드의 위치를 이해하기 위한 예시일 뿐입니다. 예시 주소와 사용자 식별자는 문서 시연용이므로 직접 연결할 수 없습니다. 실제 노드는 서버 요구 사항에 따라 전송 및 보안 설정을 추가해야 합니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-1111-1111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

여기서 protocol은 아웃바운드 프로토콜만 결정하며 전송 계층과 보안 계층을 대신하지 않습니다. REALITY 노드를 가져오면 서버 이름, 공개 키, 짧은 식별자, 지문, 흐름 제어 등의 정보도 나타납니다. 대상 코어가 해당 필드를 지원하지 않는다면 필드를 삭제해 강제로 실행해서는 안 됩니다. 올바른 방법은 이 조합을 지원하는 Xray 코어 클라이언트로 바꾸거나 서버가 별도로 제공하는 호환 노드를 사용하는 것입니다. 데스크톱 클라이언트 형태를 더 비교하려면 v2rayN 데스크톱 버전과 WPF 버전의 차이를 읽어 보세요.

데이터 교환

구독 형식, 공유 링크, 설정 필드 호환성

구독은 노드 목록이지 통합 프로토콜 표준이 아닙니다

클라이언트 구독은 보통 하나의 주소에서 노드 목록을 받아옵니다. 응답은 인코딩된 여러 줄의 공유 링크일 수도 있고 특정 구조의 설정일 수도 있습니다. 구독은 일괄 배포와 업데이트를 해결할 뿐 코어 간 기능 차이를 없애 주지는 않습니다. 하나의 구독 주소에 VMess, VLESS, Trojan, Shadowsocks 노드가 함께 포함될 수 있으며 클라이언트는 항목별로 인식한 뒤 자체 데이터 모델로 변환합니다. 인식할 수 없는 프로토콜은 건너뛸 수 있고 일부만 인식된 노드는 이름은 남지만 확장 필드가 사라질 수 있습니다.

따라서 “구독 업데이트 성공”은 클라이언트가 응답을 받아 처리했다는 뜻일 뿐 목록의 모든 노드가 현재 코어에 맞는다는 의미는 아닙니다. 업데이트 후에는 노드 수가 적절한지, 프로토콜 유형이 표시되는지, 핵심 매개변수가 남아 있는지 확인하세요. 구독에 원래 REALITY 노드가 포함되어 있었지만 v2flyNG에 해당 기능이 없다면 이는 코어의 범위 문제이며 반복 업데이트로 해결되지 않습니다. 같은 구독을 v2rayNG에서 가져왔을 때 정상적으로 인식된다면 차이가 코어 기능이나 변환 계층에 있다는 뜻입니다.

공유 링크에 담을 수 있는 정보는 프로토콜과 확장 규약에 따라 달라집니다

일반적인 링크는 vmess://, vless://, trojan://, ss://처럼 프로토콜 이름으로 시작합니다. 링크 본문에는 서버, 포트, 인증 정보, 일부 전송 매개변수가 포함됩니다. VLESS와 Trojan은 추가 매개변수를 쿼리 문자열에 넣고 노드 메모를 끝에 붙이는 경우가 많습니다. VMess의 전통적인 공유 형식은 구조화된 필드 묶음을 인코딩해 링크에 넣고, Shadowsocks 링크는 암호화 방식, 비밀번호, 주소, 포트를 중심으로 구성합니다. 클라이언트마다 확장 매개변수의 이름과 디코딩 허용 범위가 다를 수 있습니다.

링크를 수동으로 복사할 때는 프로토콜 접두사부터 끝까지 모두 복사해야 하며 주소와 사용자 식별자만 남겨서는 안 됩니다. 링크의 물음표, 해시, 슬래시, 퍼센트 기호는 구조적 의미가 있어 메신저나 텍스트 편집기를 거치며 잘리거나 바뀔 수 있습니다. QR 코드도 링크를 그래픽으로 표현한 것일 뿐 스캔에 성공했다고 내용이 완전하다는 뜻은 아닙니다. 가져온 뒤 노드 상세 정보를 열고 서버가 제공한 정보와 비교해 전송, 보안 계층, SNI, 경로, 서비스 이름, 공개 키, 짧은 식별자, 흐름 제어를 확인하세요.

일반 필드와 연결 계층의 대응

구독 업데이트와 로컬 수정의 관계

많은 클라이언트는 구독을 업데이트할 때 같은 구독 그룹의 노드를 원격 내용으로 덮어씁니다. 구독 노드를 직접 수정하면 다음 업데이트에서 변경 사항이 사라질 수 있습니다. 로컬 조정을 장기간 유지해야 한다면 클라이언트가 로컬 노드로 복사하기, 구독별 독립 규칙 설정 등을 지원하는지 확인하거나 서버에서 원본 데이터를 수정해야 합니다. 중요한 수정 사항을 구독 노드의 임시 편집에만 남겨 두지 마세요. 라우팅 규칙, 시스템 프록시 설정, 클라이언트 환경 설정은 보통 로컬 설정에 속해 노드 업데이트로 덮어쓰이지 않지만, 실제 동작은 클라이언트 인터페이스 안내를 기준으로 판단해야 합니다.

구독이 업데이트되지 않으면 먼저 시스템 시간, 네트워크, 구독 주소가 정상인지 확인한 뒤 클라이언트 로그의 HTTP 상태와 해석 메시지를 점검하세요. 노드 업데이트 직후 모두 작동하지 않는다면 즉시 클라이언트를 재설치하지 말고 업데이트 전후의 프로토콜, 주소, 포트, 보안 필드를 비교해야 합니다. 일부 노드만 실패한다면 해당 노드의 매개변수나 서버 상태에 문제가 집중되어 있을 가능성이 큽니다. 구체적인 순서는 노드 시간 초과 및 연결 불가 단계별 점검을 참고하세요.

클라이언트 간 이전은 원본 구독을 우선 사용하세요

v2rayN에서 v2rayNG로 이전하거나 v2rayNG와 v2flyNG 사이를 전환할 때는 원본 구독 또는 완전한 공유 링크를 우선 가져오세요. 대상 클라이언트가 자체 코어에 맞춰 설정을 생성하게 하는 방식입니다. 특정 클라이언트가 내보낸 실행 JSON을 직접 복사하면 로컬 포트, 플랫폼 경로, 전용 라우팅, 지원되지 않는 필드가 함께 들어갈 수 있습니다. 이전이 끝나면 먼저 기본 노드 하나로 테스트한 뒤 복잡한 규칙을 가져오세요. 이렇게 하면 “노드 호환성”과 “로컬 라우팅 호환성”을 나누어 확인할 수 있어 여러 변수를 한꺼번에 도입하는 일을 피할 수 있습니다.

선택 경로

기기, 구독 기능, 사용 환경별 프로토콜 선택

먼저 서버 기능으로 선택 범위를 정합니다

프로토콜은 클라이언트만으로 결정할 수 없습니다. 서버가 VMess만 제공한다면 클라이언트의 유형을 VLESS로 바꿔도 사용할 수 있는 연결이 생기지 않습니다. 구독에 REALITY 공개 키와 짧은 식별자가 없다면 옵션을 켜서 해당 매개변수를 만들어 낼 수도 없습니다. 따라서 첫 단계는 모든 이름 중 이론적으로 최적인 것을 고르는 일이 아니라 서버가 실제로 제공하고 현재 클라이언트 코어가 완전히 지원하는 조합을 추리는 것입니다. 이 교집합에 속한 노드만 속도, 리소스, 유지 관리 비용을 계속 비교할 가치가 있습니다.

두 번째로 기존 기기나 여러 클라이언트에서 함께 사용할 필요가 있는지 확인합니다. 기존 V2Fly 환경과 호환해야 한다면 VMess 또는 양쪽이 지원하는 Shadowsocks 설정이 일관성을 유지하기 쉽습니다. 모든 기기가 Xray 코어를 사용하고 서버도 VLESS와 REALITY를 명확히 제공한다면 이러한 조합을 우선 테스트할 수 있습니다. Trojan은 서버에 완전한 TLS 설정이 있고 클라이언트가 인증서와 서버 이름을 올바르게 처리할 수 있을 때 적합합니다. 선택은 현재 조건을 중심으로 해야 하며 프로토콜 이름을 등급처럼 취급해서는 안 됩니다.

데스크톱에서는 관리 기능과 장기 안정성을 우선 고려하세요

Windows, macOS, Linux에서는 v2rayN을 우선 사용할 수 있습니다. 데스크톱 환경에서는 브라우저, 개발 도구, 커뮤니케이션 앱, 시스템 업데이트가 동시에 실행되는 경우가 많으므로 명확한 시스템 프록시, 라우팅 규칙, 로그 접근성이 중요합니다. 구독이 VLESS와 REALITY를 제공하고 현재 Xray 코어가 이를 완전히 지원한다면 현대적인 조합으로 테스트할 수 있습니다. 이미 VMess, Trojan, Shadowsocks 노드가 안정적으로 작동한다면 이름을 좇아 이전할 필요 없이 계속 사용해도 됩니다.

데스크톱에서는 TUN과 시스템 프록시의 차이도 고려해야 합니다. 시스템 프록시는 시스템 설정을 따르는 애플리케이션에 주로 영향을 주고, TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리합니다. 둘 다 로컬 트래픽 진입점이며 원격 노드의 기존 프로토콜을 바꾸지는 않습니다. 특정 애플리케이션이 프록시를 사용하지 않는다면 먼저 진입점과 라우팅을 확인해야 하며 VMess나 VLESS로 바꿀 문제가 아닐 수 있습니다. 복잡한 라우팅에서 발생하는 규칙 매칭과 DNS 동작이 프로토콜 차이보다 사용 결과에 더 큰 영향을 줄 수도 있습니다.

Android에서는 먼저 코어를 맞춘 뒤 백그라운드 안정성을 확인하세요

구독이 Xray 기능을 중심으로 하고 VLESS, REALITY 또는 특정 flow 필드를 포함한다면 v2rayNG를 우선 사용하세요. 구독이 V2Fly 지원 범위의 VMess, Shadowsocks 등의 노드 위주이고 v2fly 코어를 사용하려면 v2flyNG를 선택할 수 있습니다. 선택한 뒤에는 화면이 꺼졌을 때와 네트워크를 전환했을 때 연결이 복구되는지 관찰하세요. 노드가 전면에서는 정상인데 백그라운드에서 자주 끊긴다면 먼저 시스템 백그라운드 정책과 배터리 제한을 확인해야 하며, 곧바로 프로토콜 불안정으로 단정하지 마세요.

모바일에서는 실패한 노드와 복잡한 테스트 규칙을 많이 남겨 두지 않는 것이 좋습니다. 노드 목록이 지나치게 길면 관리 비용이 늘고 자동 선택이나 속도 측정이 네트워크를 깨울 수 있습니다. 검증된 노드를 소수만 남겨 용도별로 구독 그룹을 구성하는 편이 프로토콜 유형을 계속 추가하는 것보다 효과적입니다. 클라이언트를 다운로드할 때 최근 주류 Android 기기는 보통 arm64 아키텍처를 선택하며 아키텍처를 확인할 수 없다면 범용 버전을 사용할 수 있습니다. 구체적인 파일은 다운로드 센터의 Android 섹션에서 확인하세요.

목표별 권장 확인 순서

환경을 떠나 모든 상황에 최적인 단일 프로토콜은 없습니다

VLESS의 역할 분리는 최신 Xray 조합에 적합하고, VMess는 성숙한 기존 호환성을 제공하며, Trojan은 비밀번호와 TLS 구조가 직관적이고, Shadowsocks는 경량 배포에 편리합니다. REALITY는 특정 보안 핸드셰이크 모델을 위한 방식입니다. 각각 다른 제약을 해결합니다. 선택할 때는 서버가 무엇을 제공하는지, 클라이언트 코어가 무엇을 지원하는지, 구독 필드가 완전한지, 기기 리소스와 백그라운드 조건이 어떤지, 실제 경로가 안정적인지의 다섯 가지 질문에 순서대로 답하세요. 이 다섯 가지가 명확해지면 프로토콜 이름 자체는 더 이상 신비롭지 않습니다.

그래도 결정하기 어렵다면 용도가 다른 노드 두 개를 남겨 두세요. 하나는 안정성과 호환성을 우선하고 다른 하나는 새 조합을 테스트하는 용도로 사용합니다. 테스트 노드를 충분히 검증한 뒤 주 노드를 교체하세요. 프로토콜, 전송, DNS, 라우팅, 시스템 진입점을 동시에 바꾸지 마세요. 한 번에 한 계층만 변경하고 연결 설정, 지속 전송, 재연결 결과를 변경 전후로 기록해야 재사용 가능한 결론을 얻을 수 있습니다.

실전 점검

프로토콜 이전, 매개변수 확인, 문제 해결

이전하기 전에 작동하는 기준 설정을 보존하세요

프로토콜을 이전할 때 가장 흔한 문제는 기존 노드를 충분히 확인하기 전에 새 설정으로 덮어쓰는 것입니다. 시작하기 전에 현재 작동하는 노드의 클라이언트, 코어 계열, 프로토콜, 전송 방식, 보안 계층을 기록하고 원본 구독 주소를 보존하세요. 이전 목적도 명확히 해야 합니다. 기존 VMess를 서버가 새로 제공한 VLESS로 바꾸는 것인지, REALITY를 사용하기 위해 v2flyNG에서 v2rayNG로 전환하는 것인지, 데스크톱 설정을 다른 기기로 옮기는 것인지에 따라 확인 범위가 달라집니다.

서버가 기존 노드와 새 노드를 함께 제공한다면 새 노드를 별도 항목으로 먼저 가져오고 기존 항목을 직접 편집하지 마세요. 연결에 성공한 뒤 도메인 접속, 지속 전송, 네트워크 전환, 자주 사용하는 애플리케이션을 차례로 테스트하고 교체 여부를 결정합니다. 이렇게 하면 새 매개변수가 잘못되어도 이미 작동하는 기준으로 돌아갈 수 있습니다. 서버가 더 이상 기존 설정을 제공하지 않는다면 새 구독 원문을 완전히 보존해야 하며 여러 클라이언트 사이에서 반복적으로 내보내고 가져오다가 필드가 손실되지 않도록 하세요.

연결 실패 시 연결 설정 흐름을 역순으로 확인하세요

첫 단계는 네트워크 대상을 확인하는 것입니다. 주소에 불필요한 공백이 없는지, 포트가 숫자인지, 도메인이 해석되는지, 기기에서 대상 포트까지 기본 연결이 가능한지 확인하세요. Windows에서는 PowerShell에서 다음 명령으로 TCP 포트 연결 여부를 확인할 수 있습니다. 예시 도메인은 실제 서버 주소로 바꿔야 합니다:

Test-NetConnection example.com -Port 443

macOS와 Linux에서는 시스템에 포함된 도구로 같은 종류의 점검을 수행할 수 있습니다:

nc -vz example.com 443

포트에 접근할 수 없다면 프로토콜 인증은 아직 시작되지 않은 상태이므로 주소, 네트워크 경로, 서버 수신 대기를 먼저 처리해야 합니다. 포트에는 접근할 수 있지만 코어가 핸드셰이크 실패를 보고한다면 시스템 시간, 보안 계층, SNI, 인증서 또는 REALITY 매개변수를 확인하세요. 핸드셰이크는 성공했지만 인증에 실패한다면 UUID, 비밀번호, 암호화 방식, 사용자 설정을 중점적으로 확인합니다. 연결은 되지만 목적지에 접근할 수 없다면 DNS, 라우팅, 로컬 프록시 진입점을 확인하세요. 계층별로 점검하면 처음부터 클라이언트를 재설치하거나 프로토콜을 무작정 바꾸는 일을 피할 수 있습니다.

프로토콜별 자주 발생하는 오류 지점

VMess에서는 시스템 시간, 사용자 식별자, alterId 계열의 기존 필드, 전송 매개변수가 같은 설정에서 가져온 것인지 특히 확인해야 합니다. VLESS에서는 UUID가 올바르지만 보안 계층, flow, 전송 방식이 맞지 않는 경우가 흔합니다. Trojan은 비밀번호, SNI, 인증서 관련 조건을 확인해야 합니다. Shadowsocks는 비밀번호와 암호화 방식이 완전히 일치해야 하며 추가 플러그인 매개변수도 누락되어서는 안 됩니다. REALITY 조합은 공개 키, 짧은 식별자, 서버 이름, 지문, flow를 함께 확인해야 하며 어느 항목도 추측으로 입력해서는 안 됩니다.

로그의 “해석 실패”와 “연결 시간 초과”는 의미가 다릅니다. 해석 실패는 보통 설정 문법이나 필드를 코어가 받아들이지 못했다는 뜻입니다. 인증 실패는 해당 프로토콜 처리 단계까지 도달했다는 뜻이고, 연결 시간 초과는 주소, 포트, 네트워크 경로에서 발생했을 수 있습니다. 핸드셰이크 오류는 TLS, REALITY, 전송 협상과 관련된 경우가 많습니다. 오류를 확인한 뒤 먼저 발생 단계를 찾고 매개변수를 점검하세요. 로그의 마지막 한 줄만 보면 맥락이 부족할 수 있으므로 같은 연결이 시작될 때의 기록까지 앞쪽으로 확인하되, 평소에는 가장 상세한 로그를 계속 켜 둘 필요가 없습니다.

연결은 성공했지만 애플리케이션이 통하지 않을 때 로컬 진입점을 확인하세요

노드에 연결됨으로 표시되는 것은 코어가 시작되었거나 특정 탐색이 통과했다는 뜻일 뿐입니다. 브라우저, 명령줄 도구, 기타 애플리케이션이 프록시를 거치는지는 시스템 프록시, TUN, 애플리케이션 자체 프록시, 라우팅 규칙에 따라 달라집니다. 한 브라우저는 되지만 다른 프로그램은 되지 않는다면 로컬 진입점 문제일 가능성이 큽니다. 모든 도메인이 실패하지만 주소로 직접 접속하면 된다면 DNS를 확인하세요. 일부 사이트만 잘못된 출구로 나간다면 도메인 및 주소 규칙의 매칭 순서를 확인해야 합니다.

라우팅 규칙은 코어 설정 순서나 클라이언트 생성 로직에 따라 처리됩니다. 범위가 넓은 규칙을 앞에 두면 뒤의 정밀한 규칙이 가려질 수 있습니다. 문제를 해결할 때는 클라이언트가 제공하는 단순 프록시 모드로 임시 전환해 노드 자체가 작동하는지 확인한 뒤 사용자 지정 라우팅을 단계적으로 복원하세요. 라우팅 문제를 VLESS, VMess, Trojan의 프로토콜 문제로 오해하지 마세요. 로컬 SOCKS 또는 HTTP 포트를 바꿨다면 해당 포트를 사용하는 애플리케이션의 설정도 함께 변경해야 합니다.

다시 활용할 수 있는 점검 기록 만들기

완전한 기록에는 기기 플랫폼, 클라이언트, 코어 계열, 노드 프로토콜, 전송, 보안 계층, 테스트 시간대, 오류가 발생한 단계가 포함되어야 하며 실제 비밀번호나 사용자 인증 정보는 저장할 필요가 없습니다. “포트 접근 가능, 핸드셰이크 실패”라고 기록하는 것이 단순히 “노드가 작동하지 않음”이라고 쓰는 것보다 유용합니다. “Wi-Fi에서는 정상이나 네트워크 전환 후 자동 복구되지 않음”이라는 기록도 한 번의 지연 시간보다 모바일 문제를 찾는 데 도움이 됩니다. 몇 차례 문제를 해결하면 자신의 환경에 맞는 고정 점검 순서를 만들 수 있습니다.

처음 설정하는 경우 시작 가이드로 돌아가 구독 가져오기와 기본 설정으로 기준 환경을 먼저 만드세요. 문제가 최초 설치와 시스템 프록시에만 발생한다면 v2rayN 최초 설치 및 초기 설정을 참고할 수 있습니다. 클라이언트를 다시 선택해야 한다면 데스크톱은 v2rayN부터 시작하고, Android는 Xray 또는 V2Fly 코어 요구 사항에 따라 v2rayNG나 v2flyNG를 선택한 뒤 다운로드 센터에서 해당 플랫폼으로 이동하세요.