V2Ray 프로토콜 및 코어
기술 가이드

프로토콜·전송·보안 계층을 먼저 분리하세요

노드는 단순한 프로토콜 이름이 아닙니다

클라이언트 목록에 “VLESS” 또는 “VMess”라고 표시되는 것은 연결 구조의 일부일 뿐입니다. 완전한 노드에는 최소한 서버 주소, 포트, 사용자 인증 정보, 프록시 프로토콜, 하위 전송 방식과 보안 매개변수가 포함됩니다. VLESS를 예로 들면 TCP에서 직접 실행할 수도 있고 WebSocket, gRPC 등의 전송 위에 올릴 수도 있습니다. 외부 계층에는 표준 TLS를 사용하거나 REALITY를 조합할 수 있습니다. 둘 다 VLESS인 노드라도 전송 계층과 보안 계층이 다르면 핸드셰이크 횟수, 첫 패킷 크기, 연결 재사용 방식과 장애 양상이 달라집니다.

계층별로 이해하면 문제 범위를 빠르게 좁힐 수 있습니다. 클라이언트에 “연결 시간 초과”가 표시될 때 원인은 도메인 해석, TCP 연결, TLS 핸드셰이크, REALITY 매개변수 불일치 또는 프록시 프로토콜 인증일 수 있습니다. VMess와 VLESS만 반복해서 바꿔도 잘못된 서버 이름, 포트 또는 전송 경로는 달라지지 않습니다. 네트워크 계층에 도달 가능한지 확인한 뒤 보안 계층의 핸드셰이크를 확인하고, 마지막으로 프로토콜 인증 정보와 라우팅 규칙을 점검하는 순서가 올바릅니다.

일반적인 연결 스택 조합

VMess는 사용자 식별자와 시간 기반 인증을 포함하며 VMess over TCP, VMess over WebSocket에 TLS를 추가하는 조합이 흔합니다. VLESS는 프로토콜 계층을 더 가볍게 구성하고 기밀성과 서버 신원 확인을 보통 TLS 또는 REALITY에 맡깁니다. Trojan은 Trojan over TLS 형태가 일반적이며 보호된 연결 안에서 인증 정보를 전달합니다. Shadowsocks는 약정된 AEAD 암호화 방식으로 데이터 스트림을 직접 보호하고 설정 항목이 비교적 집중되어 있습니다. REALITY는 VMess나 VLESS와 동급의 프록시 프로토콜이 아니라 Xray 계열의 전송 보안 방식이며, VLESS와 가장 자주 조합됩니다.

WebSocket, gRPC, HTTPUpgrade, 네이티브 TCP도 인증 프로토콜은 아닙니다. 이들은 데이터를 하위 연결에 어떻게 담을지 결정합니다. WebSocket은 검증된 HTTP 인프라와 호환되지만 프레임 캡슐화 비용이 추가됩니다. gRPC는 HTTP/2를 기반으로 다중화와 스트리밍에 적합하지만 클라이언트, 서버 및 중간 경로가 일관되게 동작해야 합니다. 네이티브 TCP는 경로가 짧고 매개변수가 적어 문제를 찾기 쉽습니다. QUIC 계열 전송은 UDP 위에서 동작하므로 네트워크의 UDP 품질과 시간 초과 정책에 따라 결과가 달라지며, 이론적 특성만으로 판단할 수 없습니다.

비교할 때 다른 변수는 동일하게 유지하세요

프로토콜 테스트에서는 변수를 통제해야 합니다. 서버 하드웨어, 회선, 암호화 알고리즘, 전송 방식, 동시 연결 수와 테스트 대상은 최대한 동일해야 합니다. 가까운 곳의 VLESS 노드와 먼 곳의 VMess 노드를 직접 비교하면 두 전체 연결 경로의 결과만 알 수 있으며 프로토콜 자체가 더 빠르다는 증거가 되지 않습니다. 다운로드 속도는 서버 출구 대역폭과 대상 사이트의 속도 제한에도 영향을 받습니다. 짧은 연결 테스트는 핸드셰이크 비용의 영향을 크게 받고, 장시간 대용량 전송은 지속 처리량과 CPU 사용량을 더 잘 보여줍니다.

클라이언트의 “지연 시간”도 구분해서 봐야 합니다. ICMP ping, TCP 연결 시간, 실제 프록시 핸드셰이크, 프록시를 통한 테스트 주소 접속은 서로 다른 지표입니다. 자세한 원리는 지연 시간 측정 원리 해설을 참고하세요. 선택할 때는 목록에서 가장 작은 숫자보다 실제 연결의 안정성, 자주 쓰는 앱의 정상 작동 여부, 연속 사용 후 리소스 변화를 우선 확인해야 합니다.

다섯 가지 방식의 배경과 설계상의 선택

VMess: 완성도 높은 인증과 폭넓은 호환성

VMess는 Project V 생태계 초기에 형성된 핵심 프로토콜 중 하나입니다. 사용자 신원, 요청 메타데이터, 동적 인증을 프로토콜 구조에 포함하며 설정에서 가장 흔히 사용하는 신원 필드는 UUID입니다. VMess의 강점은 매개변수가 가장 적다는 데 있지 않고, 오랜 기간 축적된 클라이언트 지원과 설정 경험에 있습니다. 기존 구독, 패널 출력 및 오래된 설정이 여전히 VMess를 기반으로 하는 경우가 많아 기존 환경과의 호환성이 필요할 때 안정적인 선택이 될 수 있습니다.

VMess 인증은 시스템 시간과 연관됩니다. 기기 시간 오차가 너무 크면 주소, 포트, UUID가 모두 맞아도 인증을 완료하지 못할 수 있습니다. 따라서 “같은 노드가 한 기기에서는 작동하지만 다른 기기에서는 즉시 실패”하는 경우 자동 시간 동기화를 점검 항목에 포함해야 합니다. VMess에는 여러 암호화 또는 보안 옵션도 있습니다. 클라이언트의 자동 값은 보통 코어 기능에 맞추기 위한 것이며, 수동 지정 시 서버 지원 여부를 확인해야 합니다. 오래된 가이드의 고정값을 모든 설정에 그대로 적용해서는 안 됩니다.

VLESS: 프로토콜 계층을 단순화하고 외부 보안 계층에 의존

VLESS는 프로토콜 자체가 부담하는 암호화와 인증을 줄이는 데 중점을 둡니다. 가벼운 신원 확인과 프록시 요청 표현은 유지하면서 전송 기밀성은 주로 TLS 또는 REALITY 같은 보안 계층에 맡깁니다. 이 방식은 중복 암호화 가능성을 줄이고 프로토콜 계층과 보안 계층의 역할을 명확하게 합니다. 대신 설정은 UUID만으로 끝나지 않습니다. 흐름 제어, 전송 방식, 보안 유형, 서버 이름, 공개 키 등의 필드가 최종 연결에 영향을 줍니다.

VLESS 자체가 곧 “암호화됨”을 의미하지는 않습니다. 구독에 VLESS가 표시되면 security 필드를 계속 확인해야 합니다. TLS를 사용한다면 서버 이름과 인증서의 관계를 확인하고, REALITY를 사용한다면 공개 키, 짧은 식별자, 지문, 서버 이름도 확인해야 합니다. 클라이언트 화면에서 이 필드가 여러 영역에 나뉘어 있으면 주소와 UUID만 복사하기 쉽습니다. 그 결과 노드는 저장되지만 연결은 생성되지 않을 수 있습니다.

Trojan: TLS를 기본 구성으로 사용하는 방식

Trojan의 일반적인 설정은 비밀번호로 신원을 인증하고 TLS로 연결을 보호합니다. 개념적으로는 먼저 TLS 핸드셰이크를 정상 완료한 뒤 보호된 데이터 안에서 인증과 프록시 요청을 처리합니다. 사용자가 특히 확인해야 할 필드는 서버 주소, 포트, 비밀번호, 서버 이름, 인증서 검증 설정입니다. 도메인과 인증서가 일치하지 않으면 프로토콜 인증이 시작되기도 전에 TLS 계층에서 연결이 종료됩니다.

Trojan의 실제 성능은 TLS 세션, 네트워크 왕복 시간, 하위 구현에 크게 좌우됩니다. 이름이 단순하다고 해서 VMess나 VLESS보다 반드시 리소스를 적게 사용하는 것은 아닙니다. 장시간 연결에서는 핸드셰이크 비용이 지속 전송에 분산되지만, 짧은 연결이 많으면 TLS 세션 재사용과 클라이언트 연결 풀이 더 중요합니다. Trojan을 비교할 때는 클라이언트 로그에서 실패가 TLS 단계인지 인증 단계인지 확인해야 합니다.

Shadowsocks: 간결한 암호화 프록시 구조

Shadowsocks는 흔히 SS라고 줄여 부릅니다. 비밀번호와 암호화 방식으로 세션에 필요한 정보를 파생하며, 최신 설정에서는 현재 코어가 지원하는 AEAD 방식을 사용해야 합니다. 설정 필드가 적고 데이터 경로가 직접적이어서 구성 복잡도를 낮추고 싶은 환경에 적합합니다. 다만 암호화 방식 이름은 정확히 일치해야 합니다. 비슷한 이름을 같은 알고리즘으로 착각하거나 클라이언트 코어에 구현되지 않은 방식을 사용하면 연결에 실패합니다.

Shadowsocks 구독 표현에는 여러 역사적 형식이 있습니다. 어떤 링크는 방식, 비밀번호, 호스트, 포트를 직접 포함하고, 어떤 링크는 플러그인 매개변수를 추가합니다. 클라이언트가 기본 SS를 인식한다고 해서 모든 플러그인 조합까지 인식하는 것은 아닙니다. 가져온 후 “암호화 방식”과 “플러그인” 필드가 완전한지 확인하세요. 노드 이름이 목록에 표시된다는 이유만으로 파싱 성공으로 판단해서는 안 됩니다.

REALITY: 독립 프록시 프로토콜이 아닌 보안 방식

REALITY는 Xray 기능 체계에 속하며 보통 VLESS와 조합됩니다. 클라이언트에 “VLESS REALITY”라고 표시되는 것은 VLESS가 프록시 의미를 담당하고 REALITY가 전송 보안을 담당한다는 뜻입니다. 핵심 매개변수는 서버 공개 키, 짧은 식별자, 서버 이름, 클라이언트 지문입니다. 공개 키는 인증서 파일이 아니며 짧은 식별자도 사용자 UUID가 아닙니다. 각각 역할이 다르므로 서로 바꾸면 사용할 수 있는 연결이 만들어지지 않습니다.

REALITY는 설정 정확도가 높게 요구되지만 일상적인 사용이 복잡하다는 뜻은 아닙니다. 구독이 완전하고 클라이언트 코어가 지원하며 중간 도구가 필드를 삭제하지 않았다면 가져온 뒤 바로 연결되는 경우가 많습니다. 문제는 주로 오래된 클라이언트가 필드를 인식하지 못하거나, 구독 변환기가 새 매개변수를 삭제하거나, 수동 입력 시 publicKey, shortId, serverName의 위치를 잘못 지정할 때 발생합니다. V2Fly 코어를 사용하는 클라이언트라면 대상 방식이 지원 범위에 속하는지 먼저 확인해야 하며 모든 Xray 확장이 바로 실행된다고 가정해서는 안 됩니다.

연결 속도·처리량·리소스 사용량

첫 패킷 속도는 주로 핸드셰이크 경로의 영향을 받습니다

사용자가 느끼는 “로딩 속도”는 보통 DNS 조회, 하위 연결, 전송 핸드셰이크, 보안 핸드셰이크, 프로토콜 인증, 대상 사이트 응답이 함께 결정합니다. 프로토콜 계층은 그중 일부에 불과합니다. 왕복 지연 시간이 큰 경로에서는 상대 응답을 기다리는 핸드셰이크가 한 번만 늘어도 첫 패킷 시간이 크게 증가합니다. 지연 시간이 낮은 로컬 네트워크에서는 체감 차이가 매우 작을 수 있습니다. TLS 세션 복구, HTTP/2 연결 재사용, 코어 연결 풀도 결과를 바꿉니다.

VMess, VLESS, Trojan, Shadowsocks 모두 장시간 연결을 유지할 수 있지만 클라이언트와 앱의 연결 재사용 방식이 완전히 같지는 않습니다. 브라우저는 HTTP/2 또는 HTTP/3 세션을 재사용할 수 있고, 명령줄 도구는 연결을 자주 새로 만들 수 있으며, 메신저 앱은 소수의 장시간 연결을 유지합니다. 하나의 웹페이지를 테스트했다고 모든 앱을 대표할 수는 없습니다. 선택할 때는 짧은 연결 페이지, 지속 다운로드, 상시 실행 앱의 세 가지 동작을 최소한 확인해야 합니다.

지속 처리량은 대체로 회선과 암호화 성능이 좌우합니다

안정적인 전송이 시작되면 패킷 손실, 혼잡 제어, 서버 출구 대역폭, 기기의 단일 코어 성능, 암호화 구현이 프로토콜 헤더 크기보다 중요한 경우가 많습니다. VLESS의 프로토콜 계층이 가볍더라도 외부 전송에서 복사나 헤드 오브 라인 블로킹이 발생하면 최종 처리량이 더 높다고 보장할 수 없습니다. Shadowsocks는 데이터 경로가 간결하지만 선택한 암호화 방식이 하드웨어 가속을 지원하는지에 따라 저전력 기기의 CPU 사용량이 직접 달라집니다.

데스크톱 프로세서는 일반적으로 단일 코어 성능이 충분하므로 일반적인 웹 탐색과 동영상 환경에서는 네트워크 변동이 여러 방식의 차이를 덮어버리기 쉽습니다. 라우터, 저전력 호스트, 구형 Android 기기에서는 차이가 더 크게 나타납니다. 이때는 지속적인 고부하에서 CPU가 계속 최대 사용률에 도달하는지, 기기가 클럭을 낮추는지, 네트워크가 끊긴 뒤 빠르게 복구되는지를 확인해야 합니다. 한 번의 속도 측정 최고치만 봐서는 안 됩니다. 라우터 장비의 하드웨어 요구 사항은 라우터와 보조 라우터에서 V2Ray 코어 실행 개요에서 확인할 수 있습니다.

캡슐화 계층은 대역폭과 처리 비용을 늘립니다

네이티브 TCP는 보통 캡슐화 경로가 가장 짧습니다. WebSocket은 프레임 헤더와 HTTP 업그레이드 과정이 추가되지만 호환성이 검증되어 많은 환경에서 이 비용은 실제 데이터에 비해 작습니다. gRPC는 HTTP/2 기반으로 다중화를 활용할 수 있지만 흐름 제어 창, 연결 재사용, 중간 경로의 HTTP/2 처리 방식이 실제 성능에 영향을 줍니다. 전송 계층이 복잡할수록 확인할 매개변수가 많아지고, 장애 발생 시 로그를 계층별로 확인해야 합니다.

작은 패킷이 많은 앱은 캡슐화와 스케줄링의 영향을 더 쉽게 받습니다. 음성, 게임, 실시간 제어 트래픽은 지터와 패킷 손실에 민감하므로 평균 다운로드 속도가 사용 경험을 대표하지 않습니다. UDP를 프록시로 전달할 때는 프로토콜의 UDP 지원 여부, 클라이언트 기능 활성화 여부, 네트워크의 UDP 매핑 회수 빈도, 관련 도메인과 IP를 같은 출구로 보내는 라우팅 규칙을 함께 확인해야 합니다. 어느 한 부분이라도 일치하지 않으면 로그인은 되지만 실시간 기능이 작동하지 않을 수 있습니다.

재현 가능한 비교 방법 만들기

테스트할 때 기기, 네트워크, 서버 위치, 대상 파일을 고정하고 경로를 바꾸는 다른 프록시 도구는 끄세요. 먼저 실제 연결 테스트를 여러 번 연속 실행해 최솟값이 아닌 중앙값을 기록합니다. 그다음 충분히 긴 다운로드로 안정적인 처리량을 관찰하고, 마지막으로 클라이언트 프로세스와 코어 프로세스의 CPU 및 메모리 변화를 확인합니다. 두 프로토콜이 서로 다른 서버에서 제공된다면 노드 전체 품질만 평가할 수 있으며 프로토콜 설계에 원인을 돌릴 수 없습니다.

콜드 스타트와 웜 연결도 구분해야 합니다. 최초 실행에는 코어 로딩, DNS 캐시 생성, 보안 세션 생성이 포함되지만 이후 접속에서는 기존 연결을 재사용할 수 있습니다. 네트워크를 자주 전환하는 환경이라면 콜드 스타트와 재연결이 더 중요하고, 기기를 장시간 온라인 상태로 유지한다면 안정성과 백그라운드 리소스가 더 중요합니다. 모든 지표에서 항상 앞서는 프로토콜은 없습니다.

Android 기기의 배터리와 백그라운드 동작

배터리 소모는 암호화 연산만으로 결정되지 않습니다

모바일 기기의 프록시 배터리 소모는 무선 네트워크 깨우기, CPU 계산, 가상 네트워크 카드 전달, DNS 조회, 연결 유지, 앱 백그라운드 트래픽이 함께 만들어냅니다. 프로토콜 암호화는 그중 하나일 뿐입니다. 화면이 꺼진 뒤에도 많은 앱이 짧은 연결을 계속 만들면 셀룰러 네트워크가 저전력 상태에서 반복적으로 깨어나 프로토콜 자체보다 더 많은 전력을 사용할 수 있습니다. 반대로 안정적인 장시간 연결을 소수만 유지하면 TLS를 사용해도 전력 소모가 비교적 일정할 수 있습니다.

v2rayNG는 Xray 코어를 사용하므로 VLESS, REALITY 등 Xray 기능이 필요한 구독에 적합합니다. v2flyNG는 v2fly 코어를 사용하며 V2Fly 설정을 대상으로 하는 선택지가 될 수 있습니다. 두 클라이언트 모두 Android VPN 인터페이스를 통해 트래픽을 인계할 수 있습니다. 실제 배터리 소모는 라우팅 범위, 앱 수, DNS 정책, 연결 상태에 따라 달라지므로 클라이언트 이름이나 프로토콜 이름만으로 판단할 수 없습니다.

가상 네트워크 카드 모드와 시스템 프록시의 차이

Android 클라이언트는 보통 시스템이 제공하는 VPN 인터페이스를 통해 앱 트래픽을 전달합니다. 각 패킷이 사용자 공간 처리, 라우팅 판단, 아웃바운드 연결을 거치므로 규칙이 복잡하고 동시 연결이 많을수록 스케줄링 부담이 커집니다. 데스크톱의 v2rayN은 시스템 프록시만 설정할 수도 있고, 시스템 프록시를 따르지 않는 프로그램까지 TUN 모드로 인계할 수도 있습니다. TUN의 원리와 권한 요구 사항은 TUN 모드로 전체 트래픽을 인계하는 설정 안내를 참고하세요.

모바일 기기에서 모든 앱을 항상 프록시로 보낼 필요는 없습니다. 클라이언트가 앱별 분할 라우팅을 지원한다면 실제로 필요한 앱만 선택해 불필요한 백그라운드 트래픽을 줄이세요. 라우팅 규칙도 이해하기 쉽게 유지해야 합니다. 먼저 LAN과 필요한 직접 연결을 정의하고, 그다음 프록시 규칙을 처리한 뒤 기본 출구를 설정하세요. 중복되거나 서로 덮어쓰는 규칙이 많으면 유지 관리와 장애 분석이 모두 어려워집니다.

연결 유지·재연결·네트워크 전환

Wi-Fi와 셀룰러 네트워크를 전환하면 기존 TCP 연결은 보통 다시 만들어야 합니다. 클라이언트가 무효 연결을 너무 오래 유지하면 앱이 오래 기다리게 되고, 지나치게 자주 탐지하고 재연결하면 깨우기 횟수가 늘어납니다. 이 동작을 프로토콜 하나가 결정하지는 않습니다. 코어의 연결 관리, Android 백그라운드 제한, 앱 자체의 재시도 정책이 모두 관여합니다. 안정적으로 사용할 때는 주기가 지나치게 짧은 연결 테스트를 여러 개 동시에 켜지 않는 것이 좋습니다.

WebSocket, gRPC, 네이티브 TCP는 네트워크 전환 후 복구 방식이 다르지만 결과는 앱이 요청을 다시 시작하는지에 따라 달라집니다. QUIC 또는 다른 UDP 기반 전송은 연결 의미가 다르지만 모바일 네트워크가 UDP 매핑을 더 적극적으로 회수할 수 있습니다. 화면 잠금 후 복구가 느리다면 먼저 클라이언트의 백그라운드 실행이 시스템에 의해 제한되는지 확인한 다음, 로그에서 네트워크 접근 불가, DNS 시간 초과, 원격 연결 종료 중 무엇인지 확인하세요.

DNS 정책은 깨우기와 실패 재시도에 영향을 줍니다

DNS 설정이 일치하지 않으면 중복 조회, 시간 초과, 폴백이 발생합니다. 클라이언트에 로컬 DNS, 원격 DNS, 시스템 DNS, 앱 자체 암호화 DNS를 동시에 설정하면 요청 경로가 예상보다 복잡해질 수 있습니다. 어떤 도메인을 로컬에서 해석하고 어떤 도메인을 프록시 출구에서 해석할지 명확히 정하는 편이 안정적입니다. 같은 종류의 조회를 여러 규칙이 동시에 처리하지 않도록 하세요. 노드 서버가 도메인을 사용하는 경우 서버 연결에 필요한 해석이 프록시 경로 자체를 다시 거치며 순환하지 않는지도 확인해야 합니다.

“브라우저는 작동하지만 일부 앱이 계속 배터리를 소모”한다면 해당 앱이 해석에 실패하는 도메인에 반복적으로 접속하는지, 현재 프록시 방식이 인계하지 않는 네트워크 인터페이스를 사용하는지 확인하세요. 코어 로그에 반복되는 시간 초과 행은 배터리 통계의 단일 비율보다 원인 파악에 더 유용한 경우가 많습니다. 같은 대상에 대한 빠른 재시도가 계속 기록된다면 프로토콜을 바로 바꾸기보다 라우팅 또는 DNS를 먼저 수정해야 합니다.

의미 있는 배터리 비교 방법

두 설정을 비교할 때는 같은 기기, 같은 네트워크, 비슷한 업무 트래픽을 사용해야 합니다. 충전 상태, 화면 밝기, 신호 세기, 백그라운드 동기화가 결과를 방해할 수 있습니다. 최소한 평소 사용 주기 하나를 완전히 관찰하고 시스템 배터리 통계, 클라이언트 로그, 기기 온도를 함께 확인하세요. 짧게 페이지를 연 뒤 배터리 변화를 보는 방식만으로는 무선 통신과 프로토콜 계산의 영향을 분리할 수 없습니다.

리소스 사용량을 줄이려면 먼저 불필요한 연결을 줄이고, 프록시 대상 앱 범위를 좁히며, DNS 시간 초과를 수정하고, 기기에서 잘 지원되는 암호화 구현을 선택하세요. 프로토콜 계층은 호환성과 안정성을 전제로 판단해야 합니다. 이론상 헤더가 더 작더라도 현재 클라이언트에서 계속 오류와 재연결을 일으키는 방식은 실제 배터리 소모가 더 나아질 수 없습니다.

V2Fly와 Xray의 코어 계열 관계

공통 기반과 서로 다른 발전 방향

V2Fly와 Xray는 모두 Project V 기술 생태계에서 비롯되었으며 인바운드, 아웃바운드, 라우팅, DNS, 정책, 전송 설정 등 유사한 설정 개념을 많이 공유합니다. 두 코어 모두 VMess, Shadowsocks 등의 일반적인 설정을 처리할 수 있고 구조화된 설정으로 연결 관계를 표현합니다. 비슷하다고 완전히 같은 것은 아닙니다. 각자 발전하면서 새로운 프로토콜 기능, 전송 옵션, 필드 이름, 기본 동작에 차이가 생깁니다.

Xray는 VLESS, 흐름 제어, REALITY 등의 방향에서 관련 기능을 제공하므로 v2rayN과 v2rayNG는 이런 노드를 처리할 때 Xray를 자주 사용합니다. v2flyNG는 v2fly 코어를 대상으로 하며 구독 자체가 V2Fly 기능에 맞게 생성된 경우에 더 적합합니다. 클라이언트 화면은 설정을 입력하는 창일 뿐이며, 실제 연결 가능 여부는 현재 실행되는 코어가 해당 필드를 이해하는지에 달려 있습니다.

설정이 비슷해도 그대로 교환할 수 있는 것은 아닙니다

기본 아웃바운드 구조는 두 계열에서 매우 유사할 수 있지만 확장 필드가 호환성의 경계를 만듭니다. 예를 들어 REALITY 설정이 포함된 Xray 설정은 외부 형식이 JSON이라는 이유만으로 V2Fly가 읽을 수 있다고 추정할 수 없습니다. 알 수 없는 필드는 시작 단계에서 즉시 오류를 일으키거나 무시되어 예상과 다른 동작을 만들 수 있습니다. 설정을 마이그레이션할 때는 실행할 코어 이름만 바꾸지 말고 기능별로 하나씩 확인해야 합니다.

양쪽이 같은 프로토콜 이름을 지원하더라도 전송 세부 사항은 다를 수 있습니다. network, security, flow, streamSettings, TLS 매개변수, DNS 구조를 확인해야 합니다. 클라이언트가 설정을 자동 생성하면 선택한 코어에 맞춰 필드를 조정하지만, 완전한 JSON을 수동으로 가져올 때는 이러한 변환이 없을 수 있습니다. 따라서 일반 사용자는 여러 코어에 걸친 대형 설정 파일을 장기간 관리하기보다 구독 또는 공유 링크를 가져와 클라이언트가 실행 설정을 생성하도록 하는 편이 좋습니다.

v2rayN·v2rayNG·v2flyNG의 대응 관계

데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 우선 선택할 수 있습니다. 구독 관리, 시스템 프록시, 라우팅 모드, 코어 로그 창을 제공해 다양한 데스크톱 환경을 통합 관리하기 좋습니다. Android에서 구독에 VLESS, REALITY 또는 Xray 의존 필드가 포함되어 있다면 v2rayNG를 우선 사용하세요. 구독이 V2Fly 기능에 맞게 출력되거나 V2Fly 동작을 확인해야 한다면 v2flyNG를 선택할 수 있습니다.

이 세 클라이언트는 세 가지 프로토콜을 뜻하지 않습니다. 클라이언트는 화면, 설정 생성, 시스템 네트워크 인계, 코어 프로세스 관리를 담당하고, 코어는 설정을 해석해 트래픽을 전달하며, 프로토콜은 클라이언트 코어와 서버가 데이터를 교환하는 방식을 설명합니다. 세 계층을 나누어 보면 문제가 명확해집니다. 공유 링크를 가져오지 못하는 것은 클라이언트 파싱 문제이고, 코어 시작 실패는 설정 호환성 문제이며, 핸드셰이크 실패는 보통 프로토콜 또는 보안 계층에서 점검합니다.

로그로 호환성 문제 판단

코어 시작에 실패하면 마지막에 반복되는 종료 메시지가 아니라 로그의 첫 번째 오류부터 읽으세요. 알 수 없는 필드, 인식할 수 없는 프로토콜 유형, 필수 매개변수 누락, JSON 문법 오류는 보통 시작 단계에서 명확히 나타납니다. 자세한 방법은 로그 첫 줄에서 코어 시작 실패 원인 찾기를 참고하세요. 코어가 이미 시작되었지만 연결에 실패한다면 DNS, 다이얼링, TLS, 인증 관련 행을 계속 확인합니다.

설정을 마이그레이션한 뒤 일부 노드만 작동하지 않는다면 작동하는 노드와 작동하지 않는 노드를 프로토콜, 보안 계층, 전송 계층별로 분류하세요. 모든 REALITY 노드가 실패하고 VMess는 정상이라면 코어 기능을 먼저 확인합니다. 같은 프로토콜에서 특정 전송만 실패한다면 streamSettings를 우선 점검합니다. 모든 노드가 시작되지 않는다면 설정 파일 전체 구조, 포트 사용 여부, 권한을 확인하세요. 이렇게 분류하는 편이 노드를 하나씩 삭제하고 다시 만드는 것보다 효과적입니다.

구독 형식과 공유 링크 호환성

구독은 컨테이너일 뿐 프로토콜이 아닙니다

구독 링크는 보통 여러 노드 설명을 반환합니다. 노드는 VMess, VLESS, Trojan, Shadowsocks일 수 있고 클라이언트 전용 필드를 포함할 수도 있습니다. 구독 주소 자체는 콘텐츠 위치만 지정할 뿐 내부 프로토콜을 알려주지 않습니다. 클라이언트는 구독을 업데이트한 뒤 텍스트를 다운로드하고, 인코딩과 형식을 확인한 다음 각 노드를 로컬 설정으로 변환해야 합니다. 어느 단계에서든 실패하면 사용자에게 “노드 없음”으로 표시될 수 있습니다.

일반적인 콘텐츠에는 여러 공유 링크, 인코딩된 링크 모음, 구조화된 설정이 포함됩니다. 확장 필드와 조합 형식을 처리하는 범위는 클라이언트마다 다릅니다. 구독 서비스가 REALITY 매개변수를 출력하더라도 중간 변환 과정에서 기본 VLESS 필드만 남기면 노드는 표시되지만 공개 키, 짧은 식별자, 지문이 사라집니다. 이는 완전히 파싱에 실패하는 것보다 발견하기 어렵습니다.

공유 링크로 표현할 수 있는 정보

VMess 공유 내용에는 일반적으로 주소, 포트, 사용자 식별자, 전송 및 보안 설정이 포함됩니다. VLESS 링크는 encryption, security, type, flow, serverName, publicKey, shortId 등의 정보를 쿼리 매개변수로 표현합니다. Trojan 링크에는 비밀번호, 주소, 포트 및 TLS 관련 매개변수가 필요합니다. Shadowsocks 링크는 주로 암호화 방식, 비밀번호, 서버, 포트를 표현하며 플러그인 매개변수를 추가할 수도 있습니다.

링크 매개변수 이름은 명확히 구분됩니다. VLESS REALITY를 예로 들면 pbk는 보통 서버 공개 키, sid는 짧은 식별자, sni는 서버 이름, fp는 클라이언트 지문에 해당합니다. 일부 클라이언트 화면에는 전체 이름이 표시되지만 구독에서는 짧은 매개변수를 사용합니다. 가져온 뒤에는 표시 순서를 추측하지 말고 필드 의미를 대조해야 합니다.

vless://사용자_식별자@example.invalid:443?encryption=none&security=reality&type=tcp&sni=www.example.invalid&fp=chrome&pbk=예시_공개_키&sid=예시_짧은_식별자#VLESS-REALITY-예시

위 구조는 필드 위치를 설명하기 위한 것이며 도메인과 신원 정보는 명시적인 예시 값입니다. 실제 노드에서는 서버가 제공한 전체 매개변수를 사용해야 합니다. 링크를 수동으로 편집할 때는 URL 인코딩에도 주의하세요. 노드 이름의 공백, 한글, 특수 기호는 올바르게 인코딩해야 하며 비밀번호에 예약 문자가 포함되어 있다면 보이는 텍스트를 그대로 이어 붙여서는 안 됩니다.

가져오기에 성공했다고 설정이 완전한 것은 아닙니다

클라이언트가 노드 레코드를 만들었다는 것은 최상위 형식을 인식했다는 뜻일 뿐입니다. 다음으로 노드 상세 정보를 열어 프로토콜 유형, 주소, 포트, 신원 필드, 전송 방식, 보안 계층을 확인해야 합니다. WebSocket은 path와 Host, gRPC는 serviceName, TLS는 serverName, REALITY는 publicKey, shortId, fingerprint, flow를 점검하세요.

구독을 업데이트한 뒤 기존 노드는 작동하지만 새 노드만 작동하지 않는다면 두 노드의 필드 차이를 비교하고 클라이언트 코어 기능을 확인하세요. 모든 노드가 사라졌다면 먼저 구독 응답이 비어 있는지, 주소가 잘렸는지, 클라이언트가 현재 형식을 인식하는지 확인합니다. 자주 발생하는 여섯 가지 원인과 점검 순서는 구독 링크 만료 또는 파싱 실패 자가 점검 안내를 참고하세요.

구독 업데이트와 로컬 수정의 덮어쓰기 관계

대부분의 클라이언트는 구독을 업데이트할 때 구독 그룹을 기준으로 노드를 다시 생성합니다. 수동으로 수정한 내용은 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지할 사용자 지정 라우팅, DNS, 시스템 프록시 설정은 개별 구독 노드를 수정하지 말고 클라이언트가 제공하는 독립 설정 영역에 저장하세요. 문제를 확인하기 위해 노드를 임시 수정할 때는 로컬 노드로 복사하고 이름을 바꾸어 구독 원본과 혼동하지 않는 것이 좋습니다.

노드 이름은 안정적인 식별자가 아닙니다. 구독 제공자는 이름이나 정렬 순서를 바꿀 수 있고, 클라이언트는 주소, 프로토콜 또는 내부 식별자로 중복을 제거할 수 있습니다. 문제를 분석할 때는 “두 번째 노드”라고만 말하지 말고 프로토콜, 서버, 포트, 핵심 전송 매개변수를 기록하세요. 로그의 대상 주소와 아웃바운드 태그가 대응 관계를 파악하는 데 더 적합합니다.

클라이언트 선택에서는 필드 보존 여부를 확인하세요

데스크톱에서는 v2rayN을 사용하면 한 화면에서 여러 프로토콜의 필드와 실행 로그를 확인할 수 있습니다. Android 구독에 Xray 확장이 포함되어 있다면 v2rayNG를 사용하고, V2Fly 설정을 명확히 대상으로 한다면 v2flyNG를 사용하세요. 구독에 여러 프로토콜이 함께 있다면 클라이언트가 노드별 필드를 그대로 보존해야 하며 모든 노드를 하나의 프로토콜로 강제 변환해서는 안 됩니다.

복잡한 구독에서는 여러 변환 단계를 반복하는 것보다 대상 클라이언트에 원본 구독을 직접 가져온 뒤 프로토콜별로 노드를 하나씩 추출해 확인하는 방법이 가장 안전합니다. 필드가 완전한지 확인한 후 연결 테스트를 진행하세요. 형식 변환이 한 번 늘어날 때마다 필드 누락, 기본값 변경, 인코딩 오류의 가능성도 늘어납니다.

프로토콜 매개변수 확인과 문제 해결

주소·포트·신원 필드

모든 프로토콜의 문제 해결은 가장 기본적인 세 항목에서 시작합니다. 서버 주소가 해석되는지, 포트가 올바른지, 신원 필드가 완전한지 확인하세요. VMess와 VLESS는 UUID를 사용하는 경우가 많고, Trojan은 비밀번호, Shadowsocks는 비밀번호와 암호화 방식을 사용합니다. 복사할 때 앞뒤 공백은 제거하되 내부 문자는 바꾸지 마세요. 포트는 유효한 숫자여야 하며 서버가 수신 대기 중인 포트와 일치해야 합니다.

서버 주소가 도메인이라면 먼저 클라이언트가 있는 네트워크에서 해석되는지 확인하세요. 설정에 IP와 serverName을 함께 입력했다면 두 값의 용도가 다르다는 점을 이해해야 합니다. IP는 연결 대상을 결정하고 serverName은 TLS 또는 REALITY 핸드셰이크에 사용됩니다. serverName을 IP로 바꾸면 보안 계층이 실패할 수 있고, 연결 주소를 인증서 도메인으로 바꾸면 실제 회선이 달라질 수도 있습니다.

TLS와 서버 이름

TLS 설정에서 serverName은 보통 서버 신원 확인과 핸드셰이크에 사용됩니다. 서버 설정 및 인증서와의 관계가 일치해야 합니다. 클라이언트에 “인증서 검증 건너뛰기” 같은 옵션이 있더라도 일반적인 해결책으로 사용해서는 안 됩니다. 인증서 오류는 도메인, 시간, 인증서 체인, 중간 네트워크에 문제가 있음을 나타내는 경우가 많습니다. 검증을 끄면 근본 원인을 가리고 이후 마이그레이션도 더 어려워집니다.

시스템 시간도 인증서 유효 기간 판단에 영향을 줍니다. 여러 TLS 노드가 동시에 실패하고 비TLS 노드는 정상이라면 기기 시간, 시간대, 인증서 관련 로그를 확인하세요. 특정 도메인 하나만 실패한다면 해당 노드의 serverName, 대상 주소, 서버 인증서 설정을 중점적으로 확인합니다.

REALITY의 핵심 매개변수 네 가지

REALITY 클라이언트 설정에서는 publicKey, shortId, serverName, fingerprint를 정확히 이해해야 합니다. publicKey는 서버의 해당 키에서 가져오고, shortId는 서버가 허용한 값 중 하나이며, serverName은 서버 설정에 맞아야 합니다. fingerprint는 클라이언트 핸드셰이크 지문 유형을 뜻합니다. VLESS의 신원 UUID는 별도로 존재하므로 publicKey로 대체할 수 없습니다.

flow 필드도 VLESS 설정에 관여할 수 있습니다. 서버와 클라이언트는 호환되는 값을 사용해야 합니다. 구독에 flow가 명시되어 있다면 그대로 가져오고, 서버에서 해당 흐름 제어를 활성화하지 않았다면 다른 노드의 사례를 보고 임의로 추가하지 마세요. 잘못된 flow는 기본 연결이 성립한 뒤에도 데이터 전송을 방해할 수 있으며, 로그가 클라이언트의 일반 오류 메시지보다 구체적인 단서를 제공하는 경우가 많습니다.

WebSocket·gRPC와 경로 필드

WebSocket에서는 주로 path와 Host를 확인합니다. path가 슬래시로 시작하는지, 쿼리 부분을 포함하는지는 서버의 원래 값을 따라야 합니다. Host와 TLS serverName은 같을 수도 있지만 서로 다른 역할을 할 수도 있습니다. gRPC에서는 serviceName을 확인하고 다중화 등의 옵션을 클라이언트와 서버가 동일하게 이해하는지 확인하세요. WebSocket의 path를 gRPC serviceName에 입력하면 이름은 비슷해 보여도 프로토콜 동작은 완전히 달라집니다.

연결 로그에서 하위 TCP 연결과 TLS는 성공했지만 이후 HTTP 상태 오류가 반환되거나 스트림이 종료된다면 전송 경로를 중점적으로 확인해야 합니다. 서버 앞에 역방향 프록시가 있다면 해당 업그레이드 또는 HTTP/2 전달을 지원하는지도 확인하세요. 클라이언트는 설정에 지정된 요청을 보낼 뿐 올바른 경로를 자동으로 추론하지 않습니다.

최소 변수법으로 문제를 해결하세요

먼저 설정이 완전하다는 것을 확인한 노드 하나를 선택하고, 사용자 지정 라우팅과 추가 DNS 규칙을 끈 뒤 클라이언트 기본 프록시 모드로 기본 연결을 테스트하세요. 기본 연결이 성공하면 라우팅, TUN, 앱별 분할 라우팅, 사용자 지정 DNS를 하나씩 다시 활성화합니다. 처음부터 프로토콜, 전송, 라우팅, 시스템 프록시를 동시에 변경하면 실패 원인을 판단할 수 없습니다.

로그는 최초 오류부터 읽어야 합니다. 반복 재연결은 비슷한 행을 많이 만들며 마지막에는 프로세스 종료나 컨텍스트 취소만 기록되는 경우가 많습니다. 로그를 지운 뒤 코어를 시작하고 명확한 대상에 접속해 오류가 나타나면 중지하는 깨끗한 테스트를 한 번 저장하세요. 그러면 DNS, 다이얼링, 핸드셰이크, 인증을 시간순으로 배열할 수 있습니다.

사용 환경에 맞는 프로토콜과 클라이언트 선택

기존 구독은 원래 설정을 우선 유지하세요

구독에 이미 작동하는 노드가 있다면 원래 프로토콜과 매개변수 그대로 가져오는 것이 원칙입니다. 특정 이름을 얻기 위해 수동 변환하지 마세요. VMess 노드는 유형만 바꾼다고 VLESS가 되지 않으며, Trojan 비밀번호를 Shadowsocks 비밀번호로 그대로 사용할 수도 없습니다. 프로토콜 변환에는 서버가 해당 수신 설정과 매개변수를 함께 제공해야 하며 클라이언트만 수정해서는 변환이 완료되지 않습니다.

데스크톱 사용자는 먼저 v2rayN을 선택한 뒤 구독 내용에 맞는 노드를 고르세요. Android에서 VLESS, REALITY 또는 다른 Xray 확장을 사용하는 경우 v2rayNG를 사용하고, 구독이 V2Fly 코어에 맞게 생성되었다면 v2flyNG를 사용할 수 있습니다. 해당 설치 경로는 클라이언트 다운로드 페이지에 모아 두었으며 Windows, macOS, Android, Linux 플랫폼을 안내합니다.

기존 환경과의 호환성이 필요하면 VMess를 선택하세요

기존 서버, 구독 시스템, 클라이언트가 VMess를 안정적으로 지원한다면 새로운 프로토콜이 등장했다는 이유만으로 즉시 마이그레이션할 필요는 없습니다. VMess는 설정 자료와 호환 경험이 풍부해 기존 WebSocket, TLS, TCP 조합을 계속 사용해야 하는 환경에 적합합니다. 시스템 시간, UUID, 전송 필드, 보안 설정을 중점적으로 관리해야 합니다.

단계적으로 마이그레이션할 계획이라면 서버에서 신구 접속 지점을 병행 제공하고 같은 회선과 기기에서 테스트하세요. 기능과 안정성을 먼저 확인한 다음 구독을 전환합니다. 마이그레이션 중에도 작동하는 기존 설정을 보존하면 새 프로토콜 문제와 서버 전체 문제를 구분할 수 있습니다.

계층을 명확히 구성하려면 VLESS를 선택하세요

VLESS는 가벼운 프로토콜 계층을 TLS, REALITY 등의 보안 계층과 명확히 조합하려는 환경에 적합합니다. 표준 TLS를 사용한다면 인증서, serverName, 전송 설정이 완전해야 합니다. REALITY를 사용한다면 Xray 코어와 일치하는 공개 키, 짧은 식별자, 지문, 흐름 제어 매개변수가 필요합니다. 장점은 VLESS라는 이름 자체가 아니라 완전한 연결 스택을 합리적으로 구성하는 데서 나옵니다.

v2rayN과 v2rayNG에 VLESS 공유 링크를 가져온 뒤 streamSettings를 추출해 확인하세요. 구독이 변환된 경우에는 특히 REALITY 매개변수가 삭제되지 않았는지 확인해야 합니다. 설정이 정확하면 일상적인 조작은 다른 프로토콜보다 복잡하지 않습니다. 다만 설정 출처가 불완전하면 기본 VMess보다 확인해야 할 필드가 많아집니다.

TLS 설정을 중심으로 구성한다면 Trojan을 고려하세요

서버가 Trojan 방식으로 비밀번호와 TLS 매개변수를 제공한다면 클라이언트에서 해당 노드를 그대로 사용하면 됩니다. 선택의 핵심은 인증서와 서버 이름의 정확성, TLS 세션의 안정성, 현재 전송 방식과 서버 설정의 일치 여부입니다. Trojan은 명확한 비밀번호 인증과 TLS 연결 구조를 선호하는 환경에 적합하지만 인증서, 네트워크, 서버 설정이라는 기본 요구 사항을 우회할 수는 없습니다.

짧은 연결이 많은 환경에서는 첫 패킷과 세션 재사용을 확인하고, 지속 다운로드 환경에서는 안정적인 처리량을 확인하세요. 프로토콜 구조만으로 성능을 추정하지 마세요. Trojan 노드와 다른 프로토콜 노드가 서로 다른 서버에 있다면 테스트 결과는 주로 전체 회선 차이를 반영합니다.

설정 항목을 줄이고 싶다면 Shadowsocks를 고려하세요

Shadowsocks의 기본 설정은 주소, 포트, 비밀번호, 암호화 방식에 집중되어 있습니다. 클라이언트가 지원하는 최신 AEAD 방식을 서버가 제공하고 복잡한 확장에 의존하지 않는 환경에 적합합니다. 저전력 기기에서는 선택한 알고리즘의 구현 성능도 확인해야 하며, “매개변수가 적다”는 사실을 “모든 기기에서 더 빠르다”와 동일시해서는 안 됩니다.

공유 링크에 플러그인 매개변수가 포함되어 있다면 클라이언트가 해당 플러그인과 옵션을 지원하는지 확인하세요. 기본 SS는 가져왔지만 플러그인 필드가 사라지면 노드가 작동하지 않을 수 있습니다. UDP 앱을 사용한다면 클라이언트, 코어, 서버, 네트워크 경로가 모두 해당 전달을 지원하는지도 별도로 확인해야 합니다.

모바일에서는 안정적인 연결과 명확한 분할 라우팅을 우선하세요

Android 기기에서는 프로토콜 차이보다 백그라운드 제한, 신호 세기, DNS 재시도로 인한 차이가 더 큰 경우가 많습니다. 먼저 클라이언트 코어가 명확히 지원하는 노드를 선택하고, 불필요한 프록시 대상 앱을 제한하며, 라우팅 규칙을 단순하게 유지하고, 네트워크 전환 후 복구 상태를 확인하세요. 화면 잠금 후 문제가 생겼다고 바로 프로토콜 탓으로 돌려서는 안 됩니다.

장시간 백그라운드 실행이 필요하다면 안정적이고 잦은 재연결이 없는 완전한 설정을 선택하세요. 한 번의 속도 측정은 높지만 핸드셰이크 재시도가 계속되는 노드는 백그라운드 기본 연결로 적합하지 않습니다. 로그에서 재연결 원인을 확인한 뒤 매개변수 수정, 전송 방식 변경, 노드 교체 중 하나를 결정하세요.

최종 결정 순서

첫째, 서버가 실제로 제공하는 프로토콜과 전체 매개변수를 확인합니다. 둘째, 대상 클라이언트와 코어가 해당 조합을 지원하는지 확인합니다. 셋째, 가져온 뒤 필드가 완전한지 대조합니다. 넷째, 실제 연결, 지속 처리량, 자주 쓰는 앱으로 안정성을 테스트합니다. 다섯째, CPU, 메모리, 배터리, 네트워크 전환을 관찰합니다. 이 순서를 따르면 형식 파싱 문제를 프로토콜 문제로 오판하는 것을 막고, 단 한 번의 지연 시간 수치로 장기 사용 경험을 대신하는 일도 피할 수 있습니다.

설치, 구독, 연결만 완료하면 된다면 빠른 시작 가이드를 따라 진행하세요. 설치 패키지가 필요하면 V2Ray 클라이언트 다운로드 페이지로 이동하세요. 구독 파싱, 코어 시작, 지연 시간 지표 문제가 있다면 이 페이지에 연결된 전문 문서를 계속 읽어보세요. 프로토콜 선택에는 서버, 코어, 네트워크 조건을 벗어난 만능 답이 없으며 이론적 차이보다 완전한 호환성과 안정적인 실행을 우선해야 합니다.