VMess, VLESS, Trojan, SS 및 REALITY 선택 가이드

1. 프로토콜 선택 프레임워크: 먼저 설정 계층을 분리하기

프로토콜 이름만으로는 완전한 연결 구성을 알 수 없습니다

클라이언트 목록의 VMess, VLESS, Trojan, Shadowsocks는 우선 애플리케이션 계층 프록시 프로토콜을 의미합니다. 실제 연결에는 주소와 포트, 사용자 인증 정보, 전송 방식, 보안 계층, 도메인, 선택적 경로 등이 함께 포함됩니다. 프로토콜 이름만 비교해서는 두 설정을 서로 바꿔 쓸 수 있는지 판단할 수 없으며, 연결 속도도 바로 추정할 수 없습니다. 예를 들어 VLESS는 일반 TCP 위에서 실행할 수도 있고 TLS, WebSocket, gRPC 또는 REALITY와 조합할 수도 있습니다. 이러한 조합은 핸드셰이크 과정, 인증서 요구 사항, 데이터 캡슐화, 클라이언트 지원 범위가 서로 다릅니다.

선택할 때는 하나의 설정을 네 계층으로 나누어 보세요. 첫째는 VLESS의 UUID, Trojan의 비밀번호, Shadowsocks의 암호화 방식과 비밀번호 같은 프로토콜 및 인증 계층입니다. 둘째는 TCP, WebSocket, gRPC처럼 데이터를 전달하는 전송 방식입니다. 셋째는 표준 TLS 또는 REALITY 같은 보안 및 신원 확인 계층입니다. 넷째는 클라이언트와 코어로, v2rayN, v2rayNG 또는 v2flyNG가 화면의 입력값을 Xray와 V2Fly가 읽을 수 있는 설정으로 변환합니다. 어느 한 계층이라도 맞지 않으면 연결 직후 종료되거나, 핸드셰이크가 시간 초과되거나, 가져온 뒤 일부 필드가 사라질 수 있습니다.

선호보다 기존 설정을 먼저 확인하세요

클라이언트 사용자가 받는 것은 대개 이미 매개변수가 정해진 공유 링크나 구독입니다. 이때 올바른 순서는 더 최신처럼 보이는 프로토콜을 먼저 고른 뒤 기존 설정을 바꾸는 것이 아니라, 서버가 제공한 프로토콜과 전송 조합을 확인하고 이를 완전히 인식할 수 있는 클라이언트와 코어를 선택하는 것입니다. 서버가 VMess라면 클라이언트에서도 VMess로 가져와야 합니다. 서버가 VLESS와 REALITY를 사용한다면 VLESS 지원뿐 아니라 공개 키, 짧은 ID, 지문, 서버 이름 같은 REALITY 필드도 저장할 수 있어야 합니다. 클라이언트의 드롭다운만 바꾼다고 서버의 기능이 달라지지는 않습니다.

서버와 클라이언트를 모두 선택할 수 있다면 호환 범위, 설정 복잡도, 기기 성능, 유지 관리 비용 순으로 판단하세요. 여러 클라이언트에서 공유해야 한다면 모든 환경에서 안정적으로 해석할 수 있는 조합을 우선 선택하세요. Xray 전용 기능이 필요하다면 모든 기기가 호환되는 Xray 코어를 실행하는지 확인하고, 성능이 낮은 기기에서는 불필요한 다중 캡슐화를 줄이세요. 여기서 ‘더 단순하다’는 필드와 경로 계층이 적고 문제를 추적할 범위가 명확하다는 뜻이지, 어떤 네트워크 환경에서도 특정 프로토콜이 반드시 더 빠르다는 의미는 아닙니다.

2. VMess, VLESS, Trojan, Shadowsocks의 설계 차이와 선택 기준

VMess: 완전한 인증 구조와 시간 동기화 요구 사항

VMess는 Project V 초기 프로토콜 체계에서 시작했으며, 하나의 프로토콜 안에서 사용자 식별, 요청 정보 전달, 데이터 보호를 처리하는 것을 목표로 했습니다. 설정에서는 보통 UUID를 사용자 식별자로 사용하고 추가적인 프로토콜 핸드셰이크 구조를 포함합니다. VMess는 V2Fly와 Xray 계열 모두에서 폭넓은 역사적 호환성을 갖고 있어 오래된 구독과 기존 배포 환경에서 여전히 많이 사용됩니다. 기존 설정을 유지해야 하거나 서버를 당장 변경하기 어렵거나 여러 기기에서 이미 검증된 환경이라면, 새로운 이름을 좇아 마이그레이션하기보다 VMess를 계속 사용하는 편이 안정적일 수 있습니다.

VMess 인증 과정은 클라이언트와 서버의 시간이 허용 범위 안에서 일치해야 합니다. 기기 시간, 시간대 또는 자동 시간 동기화에 문제가 있으면 주소와 포트가 모두 올바른데도 인증에 실패할 수 있습니다. 문제를 확인할 때는 먼저 시스템 자동 시간 설정을 복구한 다음 UUID, alterId 호환 필드와 전송 매개변수를 확인하세요. 최신 설정에서는 일반적으로 기존 alterId 설계에 의존하지 않지만, 과거 구독을 가져올 때는 해당 필드가 보일 수 있습니다. 클라이언트에 필드가 표시된다고 해서 서버가 여전히 같은 방식으로 동작한다는 뜻은 아니므로, 마이그레이션할 때는 현재 서버 설정을 기준으로 판단해야 합니다.

VLESS: 프로토콜 역할을 간소화하고 기능을 조합 계층에 맡기기

VLESS는 Xray 생태계의 주요 프로토콜 중 하나로, 프로토콜 자체가 데이터 암호화를 모두 담당하지 않고 전송 보안을 TLS, REALITY 또는 별도의 보안 계층에 맡기는 데 중점을 둡니다. VLESS는 UUID 등으로 사용자를 식별하지만, 그 자체만으로 모든 보안 보호를 제공하는 폐쇄형 솔루션으로 이해해서는 안 됩니다. 실제 배포에서는 전송 방식과 보안 계층을 함께 설명해야 합니다. 예를 들어 VLESS over TCP with TLS 또는 VLESS over TCP with REALITY와 같은 형태입니다.

이러한 역할 분리는 VLESS 설정에서 Xray의 flow 같은 기능을 쉽게 조합할 수 있게 하고 일부 중복 처리도 줄여 줍니다. 대신 옵션 사이에 명확한 제약이 있습니다. 서버에 flow가 설정되어 있지 않다면 클라이언트가 임의로 추가할 수 없습니다. REALITY를 사용할 때는 공개 키, 짧은 ID, 서버 이름을 함께 제공해야 하며, 표준 TLS를 사용할 때는 인증서의 신원에 맞춰 도메인을 확인해야 합니다. VLESS의 장점은 Xray 기능 조합과 명확한 프로토콜 계층에 있으며, ‘VLESS를 선택한다’는 한 가지 동작만으로 모든 연결이 자동으로 개선되는 것은 아닙니다.

Trojan: 비밀번호 인증과 표준 TLS의 조합

Trojan은 보통 비밀번호를 사용자 인증 정보로 사용하고 TLS에 의존해 보안 연결을 설정합니다. 구조는 비교적 직관적입니다. 클라이언트가 TLS 서버에 연결한 뒤 프로토콜 계층에서 인증과 대상 정보를 제출합니다. 설정에서 중요한 것은 비밀번호 필드 자체보다 도메인, 서버 이름, 인증서 검증, 포트가 서로 일치하는 관계를 이루는지입니다. 주소만 다른 호스트로 바꾸고 원래 서버 이름을 유지하거나 필요한 보안 옵션을 끄면 기존 신원 확인 로직이 깨질 수 있습니다.

Trojan은 여러 코어 생태계에서 지원 기반을 갖추고 있어 표준 TLS 설정을 이미 사용하면서 매개변수 구조를 명확하게 유지하려는 환경에 적합합니다. 그렇다고 모든 TLS 서비스를 의미하는 것은 아니며, 일반 HTTPS 주소를 Trojan 노드로 바로 사용할 수도 없습니다. 가져온 뒤에는 보안 항목이 여전히 TLS인지, SNI가 빠지지 않았는지, 비밀번호가 잘리지 않았는지 확인하세요. 구독 변환 도구가 ‘주소, 포트, 비밀번호’만 남기고 전송 계층 필드를 누락했다면 목록에 항목이 표시되더라도 원래 설정을 재현하지 못합니다.

Shadowsocks: 가벼운 구조와 암호화 방식의 일치

Shadowsocks는 흔히 SS로 줄여 부르며, 핵심 필드는 서버, 포트, 암호화 방식, 비밀번호입니다. 계층 조합이 많은 VLESS나 VMess 설정에 비해 기본 Shadowsocks 항목은 필드가 적어 설정을 이해하기 쉽습니다. 성능은 선택한 암호화 방식, 구체적인 구현, 프로세서 명령어 지원, 네트워크 품질에 따라 달라집니다. 최신 AEAD 암호화 방식은 데이터 기밀성과 무결성을 명확하게 제공하지만, 클라이언트와 서버는 정확히 같은 방식 이름과 비밀번호를 사용해야 합니다.

Shadowsocks 생태계에는 다양한 확장 기능과 플러그인 조합이 존재합니다. 기본 SS 지원이 특정 확장 기능까지 지원한다는 뜻은 아니며, 구독 가져오기에 성공했다고 확장 필드가 보존된다는 뜻도 아닙니다. v2rayN 또는 Android 클라이언트를 사용할 때는 항목 편집 화면에서 암호화 방식, 플러그인 매개변수, 추가 전송 항목을 확인하세요. 세 클라이언트 사이에서 설정을 옮겨야 한다면 기본 필드가 대체로 더 쉽게 일치하지만, 특정 플러그인을 사용하는 항목은 각 클라이언트에서 따로 검증해야 합니다. 선택할 때는 ‘프로토콜 호환성’과 ‘확장 기능 호환성’을 구분해 기록하세요.

3. 전송 방식, TLS, REALITY: 조합 관계와 필드 범위

TCP, WebSocket, gRPC는 데이터를 어떻게 전달하는가

전송 방식은 프로토콜 데이터를 하위 연결에 어떻게 담을지 결정합니다. TCP는 일반적으로 추가 캡슐화가 적고 매개변수가 비교적 단순합니다. WebSocket은 HTTP 업그레이드 과정 위에서 양방향 데이터를 전달하며, 설정에는 경로와 Host가 자주 포함됩니다. gRPC는 HTTP/2 의미 체계를 기반으로 하며 서비스 이름과 다중화 관련 설정이 대표적인 필드입니다. 이 셋은 클라이언트 선호만으로 바꿀 수 있는 ‘속도 단계’가 아닙니다. 서버도 같은 전송을 수신하고 동일한 매개변수를 사용해야 합니다. WebSocket 항목을 TCP로 바꾼다고 동등한 설정이 만들어지는 것은 아닙니다.

전송 계층이 성능에 미치는 영향은 핸드셰이크 횟수, 캡슐화 오버헤드, 연결 재사용 방식, 중간 네트워크 장비의 동작에서 발생합니다. 짧은 연결이 많은 환경에서는 연결 수립 비용이 더 크게 드러나고, 지속적인 대용량 전송에서는 회선 품질, 혼잡 제어, 서버 부하가 더 중요할 수 있습니다. WebSocket 경로는 한 글자씩 정확히 일치해야 하며 gRPC 서비스 이름도 생략할 수 없습니다. 클라이언트의 Host, SNI, 주소가 비슷해 보여도 역할은 다릅니다. 주소는 서버를 찾는 데 사용되고, Host는 애플리케이션 계층 요청 정보이며, SNI는 TLS 핸드셰이크의 서버 이름입니다.

표준 TLS: 인증서 신원과 서버 이름

TLS는 상위 프로토콜에 암호화된 통신 채널과 서버 신원 확인을 제공합니다. 설정의 서버 이름은 보통 인증서로 검증할 수 있는 이름과 일치해야 하지만, 연결 주소는 도메인일 수도 있고 특정 설정에서는 다른 주소일 수도 있습니다. 클라이언트가 기본 인증을 수행하면 인증서 유효 기간, 신뢰 체인, 이름 일치를 확인합니다. 인증서 오류가 발생하면 시스템 시간, SNI, 도메인 철자, 서버 인증서 설정을 먼저 확인하세요. 검증 기능을 끄는 것은 신원 확인 조건 자체를 바꾸므로 일반적인 해결 방법으로 사용해서는 안 됩니다.

ALPN은 TLS 핸드셰이크에서 HTTP/2 또는 HTTP/1.1 같은 상위 프로토콜을 협상하는 데 사용됩니다. 수동 입력이 필요한지는 전송 조합과 서버 설정에 따라 달라집니다. 구독에서 ALPN을 제공했다면 원래 값을 유지하세요. 명확한 요구가 없다면 ‘매개변수가 많을수록 좋다’는 이유로 임의로 추가하지 않는 편이 좋습니다. 클라이언트에서 여러 값을 선택할 수 있다고 해서 서버가 모든 조합을 받아들인다는 뜻은 아닙니다. 마찬가지로 지문 옵션은 TLS 클라이언트 핸드셰이크 특성을 나타내는 연결 구현 세부 정보이므로 사용 중인 코어와 서버 구성에 맞아야 합니다.

REALITY: Xray 보안 계층과 필수 매개변수

REALITY는 Xray 체계의 보안 계층 기능으로, 보통 VLESS 같은 설정과 함께 사용됩니다. 독립적인 프록시 프로토콜이 아니므로 클라이언트에서 항목을 만들 때 프로토콜 유형은 VLESS로 표시되고 보안 항목에서 REALITY를 선택할 수 있습니다. 일반적인 매개변수에는 서버 이름, 공개 키, 짧은 ID, 클라이언트 지문이 포함되며 일부 조합에서는 flow도 사용합니다. 공개 키는 클라이언트가 REALITY 서버의 신원을 확인하는 데 사용되고, 짧은 ID는 서버 설정과의 매칭에 사용되며, 서버 이름은 핸드셰이크 의미 체계에 참여합니다. 구독 변환 과정에서 어느 필드 하나라도 누락되면 핸드셰이크가 완료되지 않을 수 있습니다.

공개 키와 UUID는 서로 다른 역할을 합니다. UUID는 VLESS 사용자 인증에 속하고 REALITY 공개 키는 보안 계층의 신원 확인에 속하므로 서로 바꿔 쓸 수 없습니다. 짧은 ID는 보통 정해진 형식의 16진수 문자열이며 길이와 허용 값은 서버가 결정합니다. 클라이언트에서는 원문 그대로 저장하고 임의로 0을 채우거나 대소문자 구조를 바꾸지 마세요. 서버 이름도 단순한 메모가 아니라 서버 설정과 일치해야 하는 값입니다. v2rayN에서 REALITY 항목을 편집할 때는 프로토콜, 주소, 포트, 사용자 ID, security, SNI, publicKey, shortId, fingerprint, flow 순서로 확인하세요.

{
  "protocol": "vless",
  "address": "server.example.com",
  "port": 443,
  "id": "00000000-0000-4000-8000-000000000001",
  "network": "tcp",
  "security": "reality",
  "serverName": "www.example.com",
  "publicKey": "서버에서 제공한 값으로 예시 공개 키를 교체하세요",
  "shortId": "1a2b3c4d",
  "fingerprint": "chrome",
  "flow": "xtls-rprx-vision"
}

위 조각은 필드 간 계층을 보여 주기 위한 예시이며 바로 연결할 수 있는 노드가 아닙니다. 실제 값은 해당 서버 설정에서 가져와야 합니다. 클라이언트 화면은 중국어 필드명을 사용할 수도 있고, 이러한 내용이 ‘전송 설정’, ‘TLS 설정’, ‘REALITY 설정’ 패널에 나뉘어 있을 수도 있지만 필드의 의미는 같습니다. 공유 링크의 매개변수 이름은 축약형일 수도 있습니다. 예를 들어 pbk는 공개 키, sid는 짧은 ID, fp는 지문을 의미합니다. 수동으로 대조할 때는 먼저 필드 매핑을 만든 뒤 누락 여부를 판단하세요.

4. 연결 속도, 리소스 사용량, 모바일 배터리

프로토콜 오버헤드는 전체 소요 시간의 일부일 뿐입니다

사용자가 체감하는 연결 속도는 도메인 조회, 네트워크 왕복 시간, 핸드셰이크, 서버 부하, 회선 혼잡, 전송 캡슐화, 기기 처리 성능이 함께 결정합니다. 프로토콜은 그중 일부에만 영향을 줍니다. 두 설정이 서로 다른 프로토콜을 사용하면서 서버 위치, 출구 부하, 회선 품질도 다르다면 속도 측정 결과만으로 프로토콜의 우열을 증명할 수 없습니다. 신뢰할 수 있는 비교를 하려면 서버, 포트 경로, 테스트 시간, 대상 리소스, 클라이언트 버전을 최대한 동일하게 유지하고 연결 수립 시간, 지속 전송, 실패 후 재시도 상황을 반복해서 관찰해야 합니다.

기본 TCP 전송은 일반적으로 애플리케이션 계층 캡슐화가 적지만 모든 환경에서 최저 지연을 보장하지는 않습니다. WebSocket과 gRPC는 해당 프로토콜 계층의 처리를 추가하는 대신 연결 재사용과 중간 경로의 동작도 바꿉니다. TLS와 REALITY 모두 핸드셰이크와 암호 연산이 필요하지만 최신 데스크톱 프로세서는 대개 이를 빠르게 처리합니다. 저전력 모바일 기기에서는 안정적인 연결을 유지하는 것보다 연결이 자주 끊겼다 다시 연결되는 상황이 전력 소모를 더 크게 만들 수 있습니다. 따라서 불필요한 재시도를 줄이고 시스템 시간을 정확히 유지하며 잘못된 도메인 조회를 피하는 것이 단일 암호 연산의 차이를 따지는 것보다 실질적인 효과가 큽니다.

CPU, 메모리, 연결 수

리소스 사용량은 프로토콜 이름만으로 순위를 매길 수 없습니다. 코어는 연결 상태, 라우팅 규칙, DNS 캐시, 로그, 선택적 TUN 네트워크 스택을 유지해야 하며, 클라이언트 화면은 구독 업데이트, 목록 렌더링, 통계 표시도 수행합니다. 동시 연결이 많거나 정규식 규칙이 복잡하거나 로그 수준이 지나치게 상세하거나 상태 확인이 잦으면 CPU 깨우기와 메모리 사용량이 증가합니다. 기본 Shadowsocks 설정은 보통 필드가 적어 처리 경로를 이해하기 쉽고, VLESS도 간결한 전송과 조합하면 추가 오버헤드를 낮게 유지할 수 있습니다. 다중 전송 계층과 복잡한 라우팅은 더 많은 상태 관리가 필요합니다.

데스크톱에서 리소스 사용량을 관찰할 때는 v2rayN 그래픽 프로세스와 Core 프로세스를 구분해야 합니다. 화면의 메모리 증가가 반드시 프로토콜 코어의 문제를 의미하는 것은 아니며 그 반대도 마찬가지입니다. 먼저 자동 업데이트와 추가 검사를 중지한 뒤 같은 설정으로 다시 테스트하면 백그라운드 작업의 영향을 판단할 수 있습니다. 일상 사용에서는 필요한 정보만 로그에 남기고, 문제를 확인할 때만 상세도를 일시적으로 높인 뒤 완료 후 되돌리세요. 전체 액세스 로그를 계속 기록하면 디스크 쓰기와 처리 부담이 늘고 실제 오류 행을 찾기도 어려워집니다.

Android 기기의 배터리 사용량 판단

Android의 v2rayNG 또는 v2flyNG는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 배터리 소모는 암호화뿐 아니라 네트워크 유지, 애플리케이션 트래픽 총량, 무선 네트워크 전환, DNS 요청, 백그라운드 깨우기에서도 발생합니다. 화면을 끈 뒤 연결이 자주 재수립된다면 먼저 시스템의 백그라운드 실행 제한, 네트워크 전환, 구독 자동 업데이트 빈도를 확인하세요. 불안정한 회선을 그대로 둔 채 프로토콜만 바꾸는 것으로는 재연결에 따른 배터리 소모를 해결하기 어렵습니다.

TUN 또는 VPN이 트래픽을 어느 범위까지 처리하는지도 작업량에 영향을 줍니다. 기기의 모든 애플리케이션 트래픽이 클라이언트로 들어오면 코어가 처리해야 할 연결이 늘어납니다. 시스템 기능과 실제 필요에 따라 불필요한 백그라운드 애플리케이션의 트래픽을 줄이면 전체 작업량을 낮출 수 있습니다. 라우팅 규칙이 지나치게 크거나 도메인 조회가 필요한 규칙이 많으면 판단 비용도 증가하지만, 일반적인 규모에서는 보통 가장 먼저 확인할 병목이 아닙니다. 더 효과적인 점검 순서는 연결이 안정적으로 유지되는지 확인하고, 반복 재시도가 있는지 관찰한 다음 로그 수준, 자동 업데이트, DNS, 라우팅을 확인하고 마지막으로 프로토콜 조합을 비교하는 것입니다.

프로토콜 선택은 안정성, 호환성, 유지 관리 비용을 우선하고 성능 데이터는 동일 조건에서 얻은 보조 근거로 활용해야 합니다. 기존 VMess 설정이 오랫동안 안정적이라면 VLESS로의 마이그레이션은 긴급한 작업이 아닙니다. REALITY 또는 특정 Xray flow가 필요하다면 코어 업그레이드와 모든 기기의 호환성 확인을 마이그레이션 계획에 포함하세요. 리소스 사용량이 비정상적으로 높다면 도움말 센터의 장애 분류를 참고해 확인하고, 프로토콜, DNS, 라우팅, 시스템 프록시를 동시에 바꾸지 않아 비교 기준을 잃지 않도록 하세요.

5. V2Fly와 Xray 코어 계열의 관계

공통 기반과 독립적인 발전

V2Fly와 Xray는 모두 Project V 생태계의 설정 개념과 다중 프로토콜 프록시 기능을 이어받았기 때문에 VMess, 일부 VLESS, Shadowsocks, 라우팅 규칙, 아웃바운드 구조에서 비슷한 개념을 볼 수 있습니다. 이후 두 프로젝트는 독립적인 유지 관리 방향으로 발전했으며 기능 추가, 필드 의미, 구현 세부 사항이 항상 일치하지는 않습니다. 공통 기반은 많은 기본 설정 구조가 비슷한 이유를 설명해 주지만, 두 코어가 모든 확장 기능에서 완전히 호환된다는 결론으로 이어지지는 않습니다.

Xray는 REALITY, XTLS Vision 등의 기능을 집중적으로 발전시켰고 Xray 클라이언트 생태계에 해당 필드가 자리 잡았습니다. V2Fly는 자체 릴리스, 프로토콜 구현, 기능 방향을 유지합니다. 일반 사용자에게 가장 중요한 결론은 기본 VMess, Shadowsocks, 표준 전송 설정은 코어 간 마이그레이션 가능성이 비교적 높지만, Xray 전용 보안 계층, flow 또는 특정 확장 필드를 사용하는 설정은 Xray Core를 명확히 선택해야 한다는 점입니다. 설정 파일을 해석할 수 있다는 것은 문법 수준에서 성립할 가능성이 있다는 뜻일 뿐, 실행 의미까지 동일하다는 보장은 아닙니다.

세 클라이언트와 코어의 역할

v2rayN은 이 사이트에서 데스크톱용으로 우선 추천하는 클라이언트이며 Windows, macOS, Linux를 지원하고 서버 목록, 구독 그룹, 라우팅 설정, 시스템 프록시, Core 유형 관리 등의 그래픽 기능을 제공합니다. REALITY가 포함된 VLESS 설정을 사용할 때는 v2rayN에서 해당 기능을 지원하는 Xray Core를 선택하고 가져온 뒤 보안 필드가 모두 존재하는지 확인하세요. 데스크톱에서 여러 구독, 세부 라우팅, 시스템 프록시를 함께 관리해야 한다면 v2rayN의 통합 설정 구조가 주요 관리 도구로 적합합니다.

v2rayNG는 Android에서 Xray 기능을 중심으로 사용하는 클라이언트로, 데스크톱 v2rayN과 VLESS, REALITY 같은 Xray 설정을 공유하기에 적합합니다. v2flyNG는 V2Fly 코어 계열을 중심으로 하며 해당 코어가 지원하는 VMess, Shadowsocks 및 기타 호환 설정에 적합합니다. 두 이름은 비슷하지만 화면의 필드가 비슷하다는 이유만으로 기능까지 같다고 판단해서는 안 됩니다. 서버 항목이 Xray 전용 필드에 의존한다면 v2rayNG를 우선 사용하고, V2Fly 동작이 필요하거나 기존 V2Fly 설정을 기준으로 삼는다면 v2flyNG를 선택하세요.

설정 호환성의 세 가지 계층

호환성은 문법, 기능, 동작의 세 계층으로 나누어 판단해야 합니다. 문법 호환은 JSON 필드나 공유 링크를 인식할 수 있다는 뜻이고, 기능 호환은 코어가 해당 프로토콜, 전송, 보안 계층을 실제로 구현한다는 뜻입니다. 동작 호환은 같은 설정이 DNS, 라우팅, 연결 재사용, 오류 처리에서 기대한 결과를 내는지 의미합니다. 많은 마이그레이션 문제는 첫 번째 계층을 세 번째 계층으로 착각해서 발생합니다. 예를 들어 가져오기 도구가 항목을 성공적으로 생성했지만 지원되지 않는 필드를 무시하고 연결 시점에야 문제가 드러날 수 있습니다.

설정 파일을 옮길 때는 아웃바운드 태그, 라우팅 참조, DNS 구조도 확인해야 합니다. 프로토콜 노드 자체가 작동한다고 기존 라우팅 규칙까지 그대로 복사할 수 있는 것은 아닙니다. 규칙의 outboundTag는 실제로 존재하는 아웃바운드 태그를 가리켜야 하며, DNS 조회 정책과 도메인 해석 방식도 분기 판단에 영향을 줄 수 있습니다. 그래픽 클라이언트를 사용할 때는 클라이언트 화면에서 설정을 만들거나 가져와 현재 Core에 맞는 구조를 생성하도록 하세요. 특정 필드를 확인해야 할 때만 설정을 내보내 읽기 전용으로 비교하는 것이 좋습니다.

xray run -test -config ./config.json

위 테스트 명령은 설치된 Xray Core가 설정 문법을 확인하도록 하는 것이며 실제 연결 테스트를 대신하지 않습니다. 명령이 성공했다는 것은 설정이 기본 해석을 통과했다는 뜻이지 주소에 연결할 수 있거나 인증 정보가 올바르거나 보안 계층 핸드셰이크가 반드시 성공한다는 의미는 아닙니다. v2rayN 사용자는 보통 로그에서 Core 시작 결과를 바로 확인할 수 있습니다. 수동 명령은 알 수 없는 필드, JSON 구조, 태그 참조 오류를 찾을 때 더 유용합니다. 테스트할 때는 클라이언트가 실제로 생성한 임시 설정 복사본을 사용해 실행 중인 설정 파일을 수정하지 않도록 하세요.

6. 구독 형식, 공유 링크, 필드 호환성

구독은 설정 컨테이너이지 프로토콜이 아닙니다

구독 주소는 여러 노드 또는 클라이언트 설정을 반환하는 데 사용되며, 구독 자체가 VMess나 VLESS 같은 프록시 프로토콜은 아닙니다. 하나의 구독에 여러 프로토콜 항목이 함께 포함될 수도 있고, 특정 클라이언트만 인식할 수 있는 구조일 수도 있습니다. ‘구독 업데이트 성공’은 클라이언트가 요청과 기본 해석을 완료했다는 뜻일 뿐입니다. 항목 수, 프로토콜 유형, 메모, 전송 방식, 보안 필드가 완전한지도 확인해야 합니다. 목록이 비어 있다면 주소 접근 실패, 빈 응답, 지원하지 않는 형식, 그룹 필터 오류를 구분하세요.

일반적인 공유 링크는 vmess://, vless://, trojan://, ss://처럼 프로토콜 방식으로 시작합니다. 방식마다 매개변수 구성은 다릅니다. VLESS와 Trojan 링크는 보통 쿼리 매개변수에 전송, 보안 계층, SNI, 지문 등을 포함할 수 있습니다. VMess의 과거 형식은 여러 JSON 필드를 인코딩해 링크에 넣는 경우가 많고, Shadowsocks 링크는 암호화 방식, 비밀번호, 주소, 포트를 중심으로 저장하며 플러그인 매개변수를 추가할 수도 있습니다. 복사 중 잘림, 이스케이프 변경, QR 코드 인식 누락이 발생하면 필드가 사라질 수 있습니다.

범용 구독과 클라이언트 전용 형식

범용 구독은 보통 여러 줄의 공유 링크 또는 인코딩된 링크 모음입니다. 구조가 직관적이고 여러 클라이언트 사이에서 전달하기 쉽지만, 복잡한 라우팅, DNS, 클라이언트 전용 정책을 완전히 표현하기 어렵다는 한계가 있습니다. 클라이언트 전용 설정에는 그룹, 규칙, 화면 옵션을 포함할 수 있지만 다른 클라이언트로 옮길 때 노드 본체만 보존되는 경우가 많습니다. 구독 형식을 선택할 때는 공유 목적을 먼저 정하세요. 서버 항목만 동기화할 것인지, 라우팅과 DNS 정책까지 함께 옮길 것인지에 따라 달라집니다.

v2rayN, v2rayNG, v2flyNG 사이에서 가장 안정적인 방식은 모든 클라이언트가 지원하는 노드 필드를 구독에 포함하고 각 클라이언트에서 로컬 라우팅을 따로 관리하는 것입니다. 데스크톱의 시스템 프록시 방식, Android의 시스템 VPN 처리 방식, 애플리케이션별 분기 기능은 서로 다릅니다. 전체 클라이언트 설정을 하나의 구독으로 억지로 포장하면 의미가 달라지기 쉽습니다. 노드 구독은 주소, 프로토콜, 전송을 담당하고 기기 로컬 설정은 프록시 처리, DNS, 라우팅을 담당하는 방식이 문제를 추적하기 쉽습니다.

구독 변환의 이점과 정보 손실

구독 변환은 한 컨테이너 형식을 다른 형식으로 정리하거나 이름 변경, 필터링, 그룹화를 수행할 수 있습니다. 하지만 대상 형식이 원본 필드를 표현할 수 있을 때만 무손실 변환이 가능합니다. VLESS REALITY 항목은 security, SNI, publicKey, shortId, fingerprint, flow를 보존해야 하고, WebSocket은 path와 Host를, gRPC는 serviceName을 보존해야 합니다. 변환 후 대상 템플릿에 해당 필드가 없으면 도구가 오류를 알리는 대신 필드를 무시할 수 있습니다.

변환 결과를 확인할 때 노드 메모만 비교하지 마세요. 각 프로토콜에서 하나 이상의 항목을 무작위로 선택해 편집 화면을 열고 프로토콜, 주소, 포트, 인증 필드, 전송, 보안 계층, 확장 매개변수를 하나씩 확인한 뒤 연결을 테스트하세요. 원본 구독과 변환 구독은 서로 다른 그룹에 넣어 같은 이름의 노드가 덮어쓰이지 않게 하세요. 모든 프로토콜 유형이 정상 작동하는 것을 확인한 뒤 일상 사용 그룹으로 전환하세요. 변환 후 VLESS는 가져올 수 있지만 REALITY가 실패한다면 구독을 반복해서 업데이트하기보다 보안 계층의 추가 매개변수를 먼저 확인하세요.

업데이트, 덮어쓰기, 로컬 수정

구독 노드는 보통 원격 콘텐츠로 관리됩니다. 클라이언트에서 구독 항목을 직접 수정해도 다음 업데이트 때 구독 원래 값으로 돌아갈 수 있습니다. 장기간 유지해야 하는 사용자 지정 설정은 별도의 로컬 항목이나 클라이언트가 지원하는 오버라이드 규칙에 보관하세요. 수정하기 전에 항목을 복사하고 메모를 변경하면 비교 기준을 남길 수 있습니다. 시스템 프록시, 라우팅 모드, 활성 그룹만 조정하는 경우에는 보통 클라이언트 로컬 상태에 해당하므로 노드 프로토콜 필드를 수정할 필요가 없습니다.

구독 업데이트에 실패하면 먼저 주소가 완전한지, 해당 그룹이 활성화되어 있는지 확인한 다음 클라이언트 로그에서 HTTP 상태, 해석 오류, 인증서 오류를 확인하세요. 구독 주소를 ‘서버 수동 추가’의 주소 필드에 붙여 넣지 말고, 단일 공유 링크를 반드시 정기 업데이트할 수 있는 구독으로 착각하지도 마세요. 전체 작업 흐름은 시작 가이드의 구독 가져오기 단계를 참고하세요. 목록이 비어 있거나 그룹을 선택하는 문제는 도움말 센터에서 계속 확인할 수 있습니다.

7. v2rayN, v2rayNG, v2flyNG에서 프로토콜 선택 적용하기

v2rayN: 먼저 Core를 확인하고 노드 편집 페이지를 점검하세요

v2rayN은 데스크톱에서 주로 사용하는 클라이언트입니다. 노드를 가져온 뒤 먼저 설정에서 Core 유형을 확인하고 서버 편집 페이지를 열어 필드를 점검하세요. VMess는 사용자 ID, 전송 방식, 보안 항목을 중점적으로 확인합니다. VLESS는 encryption, flow와 REALITY 또는 TLS 패널을 추가로 확인해야 합니다. Trojan은 비밀번호, TLS, 서버 이름을 확인하고 Shadowsocks는 암호화 방식과 비밀번호를 확인합니다. 클라이언트 목록의 메모는 식별용일 뿐 프로토콜 인증에 참여하지 않으므로 메모가 정상적으로 표시된다고 설정이 완전하다는 뜻은 아닙니다.

연결을 활성화하기 전에는 노드 설정과 시스템 프록시 설정을 분리해서 보세요. 활성 서버를 선택하는 것은 Core가 사용할 아웃바운드 설정을 결정하고, 시스템 프록시는 시스템 프록시를 지원하는 애플리케이션의 요청을 클라이언트로 전달할지 결정하며, 라우팅 규칙은 연결을 프록시 아웃바운드, 직접 연결 아웃바운드 또는 다른 설정된 출구로 보낼지 결정합니다. 세 단계는 이어져 있지만 서로 다릅니다. 노드 테스트가 실패하면 먼저 프로토콜 로그를 확인하고, 노드는 연결되었지만 애플리케이션이 처리되지 않으면 시스템 프록시를 확인하세요. 일부 도메인이나 경로만 예상과 다를 때 라우팅을 점검하면 됩니다.

v2rayNG: 공유 링크의 전체 매개변수를 확인하세요

v2rayNG에서 VLESS REALITY 링크를 가져올 때는 설정 세부 정보에서 보안 유형, SNI, 공개 키, 짧은 ID, 지문, flow가 모두 존재하는지 확인하세요. QR 코드 인식 또는 클립보드 가져오기 후 어느 필드가 비어 있다면 원래 공유 내용을 다시 확인하고 다른 노드에서 임의로 복사하지 마세요. 노드마다 공개 키와 짧은 ID는 각 서버에 연결되어 있으므로 비슷하게 보여도 서로 섞어 쓸 수 없습니다. VMess 항목은 기기 시간과 전송 매개변수를 추가로 확인하고, Shadowsocks 항목은 암호화 방식을 중점적으로 확인하세요.

Android의 연결 버튼은 시스템 VPN 처리를 시작할 뿐 노드 프로토콜을 바꾸지는 않습니다. 연결 후 모든 애플리케이션에서 네트워크가 되지 않는다면 먼저 로그에서 Core가 시작되었는지, 설정 해석을 통과했는지, 핸드셰이크가 완료되었는지 확인하세요. 특정 애플리케이션만 다르게 동작한다면 시스템 제한과 애플리케이션별 분기를 점검하세요. 여러 프로토콜 항목을 빠르게 전환하면 로그가 뒤섞이므로 문제를 확인할 때는 이미 점검한 하나의 노드를 고정하고 현재 로그 시간을 지우거나 기록한 뒤 명확한 연결 작업을 한 번 실행하세요.

v2flyNG: V2Fly 기능 범위에 맞춰 항목을 선택하세요

v2flyNG는 Android에서 V2Fly 코어를 사용하는 클라이언트로 적합합니다. 가져오기 전에 설정이 Xray 전용 기능에 의존하는지 먼저 판단하세요. 기본 VMess, 지원되는 Shadowsocks, V2Fly가 구현한 프로토콜과 전송은 실제 설정에 맞춰 확인할 수 있습니다. REALITY 또는 특정 Xray flow가 포함된 VLESS 항목은 프로토콜 이름이 표시된다는 이유만으로 호환된다고 판단해서는 안 됩니다. 하나의 구독에 여러 유형의 항목이 섞여 있다면 별도 그룹을 만들어 검증된 호환 노드만 v2flyNG에서 사용하세요.

두 Android 클라이언트를 비교할 때는 같은 기본 호환 설정을 사용하고 DNS, 라우팅, 네트워크 조건을 비슷하게 유지해야 합니다. 한쪽에서 가져온 뒤 필드가 사라진다면 단순히 네트워크 문제로 보지 말고 형식 또는 기능 비호환으로 기록해야 합니다. 클라이언트 선택의 목표는 모든 기기에 같은 앱을 강제하는 것이 아니라 코어 기능에 맞추는 것입니다. Xray 설정은 v2rayNG를 우선하고 V2Fly 설정은 v2flyNG를 우선하는 명확한 분담이 반복적인 변환보다 유지 관리에 유리합니다.

로그에서 설정 계층을 추적하기

로그 오류는 보통 단계별로 분류할 수 있습니다. 설정 해석 단계에서는 알 수 없는 필드, 형식 오류, 존재하지 않는 아웃바운드 태그 등이 나타납니다. DNS와 연결 단계에서는 이름 해석 실패, 연결 거부, 시간 초과가 나타납니다. TLS와 REALITY 단계에서는 인증서 이름, 키, 핸드셰이크 문제가 나타나며, 프로토콜 인증 단계는 UUID, 비밀번호, 서버 사용자 설정과 관련됩니다. 먼저 실패 단계를 정한 뒤 해당 필드로 돌아가는 것이 무작정 하나씩 바꾸는 것보다 효율적입니다.

문제를 해결하는 동안 한 번에 하나의 변수만 바꾸세요. 예를 들어 먼저 프로토콜과 전송을 유지한 채 SNI만 수정하고, 다시 테스트한 뒤 공개 키를 확인합니다. Core, 노드, DNS, 라우팅 모드를 동시에 바꾸면 성공해도 실제 원인을 알 수 없고 실패 범위만 커집니다. 다른 사람에게 문제를 설명해야 한다면 클라이언트 이름, Core 계열, 프로토콜, 전송, 보안 계층, 오류 단계, 로그의 주요 오류 유형을 기록하고 인증 정보는 숨기세요.

아직 해당 클라이언트를 설치하지 않았다면 클라이언트 페이지에서 Windows, macOS, Android, Linux에 맞는 패키지를 선택하세요. 데스크톱 환경에서는 v2rayN을 우선 사용하고, Android에서는 Xray와 V2Fly 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택하세요. 설치 후 구독 가져오기, 시스템 프록시, 연결 확인은 시작 가이드의 범위이며, 이 장에서는 프로토콜 선택 결과를 클라이언트 설정에 적용하는 방법만 다룹니다.

8. 사용 환경별 선택, 마이그레이션, 장애 발생 시 복귀

기존 설정이 안정적이라면 프로토콜을 유지하고 변경을 줄이세요

이미 안정적으로 사용 중인 VMess, Trojan, Shadowsocks 설정은 프로토콜 이름이 바뀌었다는 이유만으로 바로 마이그레이션할 필요가 없습니다. 먼저 현재 클라이언트, Core, 전송, 보안 계층, DNS, 라우팅 기준을 기록한 뒤 마이그레이션으로 해결하려는 구체적인 문제가 무엇인지 평가하세요. 기기만 바꾸는 것이 목적이라면 새 기기에 같은 설정을 가져와 필드를 확인하면 됩니다. REALITY나 Vision을 사용하려는 목적이라면 서버와 클라이언트를 함께 변경하는 작업이므로 기존 노드를 덮어쓰지 말고 별도의 테스트 항목을 만들어야 합니다.

안정적인 설정은 비교 가능한 기준을 제공합니다. 새 항목의 테스트가 실패하면 기존 항목으로 돌아가 로컬 네트워크, 시스템 프록시, 클라이언트 전체가 여전히 작동하는지 확인할 수 있습니다. 기존 항목도 동시에 실패한다면 문제는 새 프로토콜 자체에 있지 않을 수 있습니다. 마이그레이션 중에는 기존 구독 그룹, 기존 Core 설정 기록, 주요 필드 목록을 보존하면 어느 계층에서 변화가 발생했는지 빠르게 판단할 수 있습니다. 새 설정이 모든 대상 기기에서 검증된 뒤 기존 항목 사용을 단계적으로 중단하세요.

데스크톱 멀티플랫폼: v2rayN과 공통 기능을 중심으로

Windows, macOS, Linux 데스크톱에서 조작 방식을 통일해야 한다면 v2rayN으로 구독과 라우팅을 관리하는 것을 우선 고려하세요. 프로토콜 선택은 세 데스크톱 환경 모두에서 안정적으로 실행되는 Core와 전송 조합을 먼저 고른 뒤 플랫폼 차이를 살펴야 합니다. 표준 보안 계층을 사용하는 기본 VLESS, 기존 VMess, Trojan, 기본 Shadowsocks는 서버 매개변수에 따라 하나씩 검증하세요. REALITY를 사용할 때는 각 플랫폼의 v2rayN이 호환되는 Xray Core를 호출하고 전체 필드를 저장할 수 있는지 확인해야 합니다.

플랫폼 간 동기화는 클라이언트 폴더 전체를 복사하는 것과 다릅니다. 시스템 프록시 구현, 인증서 저장소, 네트워크 인터페이스, 시작 시 자동 실행 방식은 플랫폼마다 다르므로 각각 설정하는 편이 좋습니다. 구독은 노드를 동기화하고, 라우팅 규칙은 업무에 맞는 읽기 쉬운 규칙 집합으로 관리하며, 시스템 설정은 각 기기에 남겨 두세요. Linux 데스크톱 배포와 자동 시작은 기술 문서 v2rayN Linux 데스크톱 설치를 참고하고, 프로토콜 필드는 이 페이지의 계층별 방법으로 확인하세요.

Android와 데스크톱 공유: 먼저 코어 공통 범위를 확인하세요

데스크톱 v2rayN과 Android v2rayNG가 설정을 공유할 때는 Xray 기능의 공통 범위가 가장 명확하며 VLESS REALITY가 필요한 환경에 적합합니다. Android에서 v2flyNG를 사용한다면 V2Fly가 명확히 지원하는 프로토콜과 전송을 선택하고 Xray 전용 매개변수를 공통 설정에 넣지 마세요. 하나의 구독에 여러 유형의 노드를 포함할 수 있지만, ‘Xray 설정’과 ‘V2Fly 호환 설정’처럼 메모나 그룹으로 코어 요구 사항을 표시해 프로토콜 이름만 보고 잘못 선택하지 않도록 하는 것이 좋습니다.

모바일에서는 안정적인 연결과 백그라운드 동작을 특히 확인해야 합니다. 데스크톱에서는 정상인데 Android에서 실패한다면 먼저 가져온 뒤 필드를 비교하고, 그다음 시스템 VPN 시작과 기기 네트워크를 확인하세요. 곧바로 서버 문제라고 단정하지 마세요. Android에서 연결은 되지만 배터리 소모가 크다면 앞서 설명한 순서에 따라 재연결, 네트워크 전환, 자동 업데이트, 로그를 확인하고 암호화 프로토콜부터 바꾸지는 마세요. 여러 기기에서 선택할 때의 목표는 매개변수 일치, 코어 호환, 명확한 장애 범위입니다.

복잡한 구독: 프로토콜별로 표본을 뽑아 검증하세요

구독에 VMess, VLESS, Trojan, Shadowsocks가 함께 포함되어 있다면 목록의 첫 항목만 테스트해서는 안 됩니다. 먼저 프로토콜별로 분류하고 각 유형에서 필드가 완전한 항목을 하나씩 선택하세요. 그다음 전송 방식별로 분류해 TCP, WebSocket 또는 구독에서 실제로 제공하는 다른 방식을 최소 하나씩 포함하고, 마지막으로 TLS와 REALITY를 따로 확인하세요. 이렇게 하면 문제가 특정 노드, 특정 프로토콜, 특정 전송, 전체 구독 형식 중 어디에 있는지 판단할 수 있습니다. 테스트 결과는 그룹이나 메모에 기록해 단기 기억에 의존하지 마세요.

같은 프로토콜에서 REALITY 항목만 실패한다면 Xray Core와 REALITY 매개변수를 확인하세요. 모든 WebSocket 항목이 실패하고 TCP가 정상이라면 path, Host, TLS를 비교해야 합니다. 모든 프로토콜이 해석되지 않는다면 구독 응답과 형식 계층으로 돌아가세요. 계층별로 분류하면 관련 없는 변경을 줄일 수 있습니다. 프로토콜과 클라이언트의 차이를 더 폭넓게 비교하려면 v2rayN, v2rayNG, v2flyNG 선택법을 참고하세요.

마이그레이션 실행 목록과 복귀 조건

정식 마이그레이션은 준비, 병행 검증, 전환, 관찰의 네 단계로 나눌 수 있습니다. 준비 단계에서는 기존 설정을 기록하고 사용 가능한 그룹을 삭제하지 않습니다. 병행 단계에서는 새 항목을 추가해 같은 네트워크 조건에서 해석, 핸드셰이크, 지속 연결, 자주 쓰는 애플리케이션을 테스트합니다. 전환 단계에서는 활성 노드만 바꾸고 DNS와 라우팅은 그대로 둡니다. 관찰 단계에서 새 라우팅이나 시스템 설정을 점진적으로 적용합니다. 각 단계에 복귀 지점을 명확히 두면 문제가 생겨도 전체 설정을 다시 만들 필요 없이 기존 활성 노드로 돌아갈 수 있습니다.

복귀 조건에는 대상 클라이언트가 필요한 필드를 저장하지 못하는 경우, Core가 필요한 기능을 구현하지 않은 경우, 구독 업데이트가 로컬 수정을 계속 덮어쓰는 경우, 모바일에서 연결이 자주 끊겼다 다시 연결되는 경우, 여러 플랫폼 중 하나라도 핵심 기기에서 안정적으로 실행되지 않는 경우가 포함됩니다. 복귀는 프로토콜의 우열을 판단하는 것이 아니라 현재 조합이 호환 요구를 충족하지 못했다는 뜻입니다. 기존 방식을 유지한 채 서버, 구독 형식, 클라이언트 설정을 각각 수정한 뒤 다음 검증을 시작할 수 있습니다.

프로토콜 결정을 마쳤다면 시작 가이드에서 구독 가져오기, 노드 선택, 시스템 프록시, 연결 확인을 진행하세요. 연결 실패, 빈 목록, 라우팅 미적용 문제가 발생하면 도움말 센터에서 오류 단계에 따른 해결 방법을 찾을 수 있습니다. 중국 본토와 해외 트래픽의 분할 라우팅을 추가로 설계해야 한다면 v2rayN 중국 본토·해외 분할 라우팅 실전을 참고해 노드 프로토콜과 라우팅 정책을 분리해서 관리하세요.