V2Ray 프로토콜 가이드와 코어 선택 기준

설정 계층: 프로토콜·전송·보안

클라이언트의 노드 이름은 보통 한 줄이지만 실제 연결은 여러 계층의 설정으로 결정됩니다. 프록시 프로토콜은 인증과 요청 형식을 정하고, 전송 방식은 데이터를 전달할 수단을 정하며, 보안 계층은 연결 암호화와 상대방 인증을 담당합니다. 주소와 포트는 서비스 접속 지점을 가리킵니다. 이 항목들을 함께 이해해야 이름이 모두 VLESS인 노드라도 설정을 서로 바꿔 쓸 수 없는 이유를 알 수 있고, 화면의 선택 항목 하나를 완전한 프로토콜로 오해하지 않을 수 있습니다.

노드 설정에서 확인할 계층

VMess·VLESS·Trojan·Shadowsocks는 프록시 프로토콜이고, TCP·WebSocket·gRPC 등은 전송 방식이며, TLS와 REALITY는 보안 설정에 해당합니다. REALITY는 VLESS와 동급의 프록시 프로토콜이 아닙니다. 클라이언트에서 별도 항목으로 표시되는 경우는 흔히 쓰이는 조합을 쉽게 입력하도록 한 것입니다. 해당 항목을 선택해도 기반 프로토콜을 확인해야 하며, 목록의 이름만으로 연결 방식을 판단해서는 안 됩니다.

설정을 입력할 때는 먼저 주소, 포트, 프록시 프로토콜, 인증 정보를 정한 다음 전송 방식과 보안 설정을 확인하세요. UUID는 VMess와 VLESS에서 흔히 쓰는 사용자 식별자이고, Trojan은 비밀번호를 사용하며, Shadowsocks는 암호화 방식과 해당 방식의 요구 조건에 맞는 키가 필요합니다. 모두 문자열처럼 보여도 의미가 다르므로 한 프로토콜의 비밀번호를 다른 프로토콜의 사용자 식별자 칸에 복사하면 안 됩니다. 편집 창에서 저장된다는 것은 입력값이 화면 검사를 통과했다는 뜻일 뿐, 서버가 설정을 받아들인다는 의미는 아닙니다.

접속 주소와 서버 이름은 다를 수 있습니다

주소는 클라이언트가 실제로 접속하는 대상으로, 도메인이나 IP를 사용할 수 있습니다. SNI 또는 서버 이름은 TLS 핸드셰이크와 인증에 사용되며 접속 주소와 다를 수 있습니다. WebSocket의 Host와 경로는 애플리케이션 계층 전송 설정입니다. 서비스 제공자가 이 항목들을 다르게 지정했을 수 있으므로 모두 같은 도메인으로 통일해 연결 문제를 해결하려 해서는 안 됩니다. 포트도 프로토콜 종류를 결정하지 않습니다. 흔히 쓰는 포트는 배포 관행일 뿐이며, 어떤 포트든 서버의 수신 설정과 일치해야 합니다.

전송 계층의 추가 항목은 선택한 유형에 맞춰 확인해야 합니다. WebSocket은 보통 경로와 Host가 일치해야 하고, gRPC는 서비스 이름이 맞아야 합니다. 일반 TCP에는 이런 항목을 추가할 필요가 없습니다. 기존 노드의 전송 방식을 바꾸면 이전 값이 무시될 수도 있지만, 설정 생성에 계속 반영될 수도 있습니다. 가장 안전한 방법은 올바른 유형의 노드를 새로 만들고 원본과 대조해 하나씩 입력하는 것입니다. 기존 항목에서 여러 드롭다운을 반복해서 바꾸는 방식은 피하세요.

노드 설정이 올바르더라도 모든 앱이 프록시를 사용하는 것은 아닙니다

노드 설정은 클라이언트와 서버 사이의 연결을 다룹니다. 앱의 트래픽이 클라이언트로 들어오는지는 시스템 프록시, TUN 또는 앱 자체의 프록시 설정에 달려 있습니다. 유입된 뒤 어떤 출구를 사용할지는 라우팅 규칙이 결정합니다. 따라서 브라우저는 연결되지만 다른 앱은 연결되지 않는다고 해서 프로토콜이 잘못됐다고 볼 수는 없습니다. 먼저 해당 앱의 트래픽이 프록시로 들어오는지 확인하고 라우팅과 DNS를 점검하세요. UUID를 바꾸거나 인증서 검증을 끄고 암호화 방식을 조정하는 것은 그다음입니다.

로그도 계층별로 확인하세요. 파싱 오류는 연결 전에 발생하고, 시간 초과는 접속 단계에서 발생할 수 있으며, TLS 인증 오류는 보안 계층과 관련되고, 인증 실패는 대개 프로토콜 설정을 가리킵니다. 하나의 로그 결과에 여러 원인이 있을 수 있으므로 발생 시점을 함께 살펴봐야 합니다. 원본으로 가져온 항목은 그대로 보관하고 한 번에 한 항목만 바꾼 뒤 기록하면 설정 오류와 일시적인 네트워크 문제를 구분할 수 있습니다. 그래야 설정을 계속 바꾸다 정상 상태로 돌아가기 어려워지는 일을 막을 수 있습니다.

VMess와 VLESS: 인증 및 암호화의 차이

VMess는 Project V 생태계에서 비교적 일찍 자리 잡은 프록시 프로토콜로, 설계 단계부터 사용자 인증과 데이터 보호를 프로토콜에 포함했습니다. 이를 보면 V2Ray가 단순한 시스템 프록시 스위치가 아닌 이유를 알 수 있습니다. 코어는 사용자를 식별하고 목적지 주소를 포함해 프로토콜 형식에 맞게 데이터를 처리해야 합니다. VMess는 이후 AEAD 인증 방식을 도입해 기존 인증 설계의 부담을 줄였습니다. 이 배경은 주로 오래된 설정 항목을 이해하기 위한 것으로, 과거 호환 모드를 계속 사용하라는 뜻은 아닙니다.

VMess의 추가 ID와 암호화 방식

클라이언트에 ‘추가 ID’ 또는 alterId 항목이 남아 있을 수 있습니다. 최근의 일반적인 VMess 설정은 추가 ID를 0으로 두는 AEAD 경로를 사용합니다. 이 값은 노드 수를 뜻하지 않으며, 임의로 높인다고 보안 수준이 올라가지도 않습니다. 원본에서 다른 값을 요구한다면 서버와 사용 중인 코어가 해당 구형 방식을 여전히 지원하는지 먼저 확인하세요. 가져온 뒤 인증 문제가 생기면 원본 설정과 호환 범위를 점검하고, 숫자를 하나씩 바꿔 보며 맞추려 하지 마세요.

암호화 방식의 auto는 구현이 조건에 따라 적절한 방식을 선택한다는 뜻이지, 암호화를 끈다는 뜻이 아닙니다. 알고리즘별 효율은 프로세서 명령어 지원에 따라 달라지므로 특정 옵션이 항상 더 빠르다고 하드웨어와 무관하게 단정할 수 없습니다. 알고리즘을 직접 지정할 때도 프로토콜 구현의 지원 범위와 일치해야 합니다. 정상적으로 가져온 노드라면 막연한 추측으로 알고리즘을 바꾸기보다 원본 설정을 유지하는 편이 안전합니다. 비교하려면 두 설정 모두 서버가 지원하는지 먼저 확인하세요.

VMess는 시간 설정에 영향을 받으므로 기기의 시간이 맞지 않으면 주소, 포트, 사용자 식별자가 올바르더라도 인증에 실패할 수 있습니다. 비밀번호 오류로 단정하지 말고 시스템 자동 시간 설정과 시간대 표시를 확인하세요. 외부 전송에 TLS를 사용한다면 인증서 유효기간 검사에도 영향을 줍니다. 같은 시간 오류가 인증 문제와 인증서 오류로 모두 나타날 수 있습니다. 먼저 시스템 시간을 바로잡고 다시 연결하면 불필요한 설정 변경을 줄일 수 있습니다.

VLESS는 콘텐츠 보호를 외부 계층에 맡깁니다

VLESS는 사용자 식별자와 프록시 요청 형식은 유지하면서 프로토콜 계층을 간결하게 설계했습니다. 프로토콜 자체에서 콘텐츠 암호화를 중복 수행하지 않습니다. 일반적인 클라이언트 설정에서 encryption을 none으로 지정하는 것은 프로토콜 설정에 따른 것이며, 연결 전체를 평문으로 사용하라는 뜻이 아닙니다. 실제 연결에는 TLS 또는 지원되는 REALITY 설정 등 적절한 보안 전송을 함께 적용해야 합니다. VLESS의 none을 VMess의 암호화 드롭다운과 같은 의미로 보면 보안 경계를 잘못 판단하게 됩니다.

VLESS의 flow는 지원되는 흐름 제어 방식을 선택하는 항목이며 xtls-rprx-vision은 Vision을 가리킵니다. 이 문자열은 범용 가속 스위치가 아니며, 어떤 VLESS 전송 방식에나 넣을 수 있는 것도 아닙니다. 서버와 클라이언트 코어, 전송 방식이 함께 지원해야 합니다. 노드 원본에 flow가 없다면 화면에 항목이 있다는 이유만으로 임의로 입력하지 마세요. 원본에서 Vision을 명시했다면 이를 삭제하고도 기존 설정과 같다고 가정해서는 안 됩니다.

이름의 신구가 아니라 배포 조건으로 선택하세요

VMess 서버가 안정적으로 운영 중이라면 클라이언트에서 프로토콜만 VLESS로 바꾼다고 전환이 완료되는 것은 아닙니다. 서버에도 해당하는 수신 설정과 사용자 정보가 필요하며 공유 링크도 새로 생성해야 합니다. 반대로 새로 VLESS를 배포한다면 flow와 성능을 논의하기 전에 외부 보안 설정과 코어 지원 여부부터 정하세요. 프로토콜 이름이 더 새롭다고 현재 연결 품질까지 더 좋다는 보장은 없습니다. 서버 부하, 경로 품질, 전송 방식이 프로토콜 헤더의 작은 차이보다 큰 영향을 줄 수 있습니다.

VMess와 VLESS 노드를 문제 해결할 때는 정해진 순서로 확인하세요. 사용자 식별자가 온전한지, 프로토콜 유형이 서버 설정과 일치하는지 확인한 뒤 전송 방식, 보안 계층, 시스템 시간을 점검합니다. VMess에서는 추가 ID와 인증 호환성을, VLESS에서는 encryption과 flow가 원본에 맞는지 확인하세요. 원본 링크는 지원되는 코어에서 작동하지만 직접 입력한 항목은 작동하지 않는다면 서비스 장애로 단정하기 전에 누락된 설정이 있는지 비교하세요.

Trojan과 Shadowsocks: 서로 다른 보호 방식

Trojan과 Shadowsocks는 모두 클라이언트의 프로토콜 목록에서 자주 볼 수 있지만 연결을 보호하는 방식은 다릅니다. Trojan은 일반적으로 TLS 연결을 바탕으로 인증과 프록시 요청을 처리하고, Shadowsocks는 사전 공유 키와 대칭 암호화를 중심으로 동작합니다. 비교할 때는 인증 정보, 암호화가 적용되는 범위, 전송 설정을 함께 살펴봐야 합니다. 두 프로토콜을 비밀번호 형식만 다른 같은 노드로 취급해서는 안 됩니다. 서버에서 제공하는 유형에 맞춰 클라이언트에서도 해당 프로토콜을 선택해야 합니다.

Trojan: 비밀번호와 TLS를 함께 확인하세요

Trojan 비밀번호는 프로토콜 인증에 사용되고 TLS 인증서는 서버의 신원을 확인합니다. 두 항목은 서로 다른 문제를 해결합니다. 비밀번호가 맞아도 인증서 이름이 일치하지 않으면 해결되지 않고, 인증서가 유효하다고 비밀번호까지 맞는 것은 아닙니다. 클라이언트에서 접속 주소와 SNI를 별도로 입력할 수 있습니다. IP로 접속하더라도 서버에서 요구하는 서버 이름을 입력해야 합니다. 비밀번호만 복사하고 SNI를 빠뜨리면 실제 비밀번호 인증 단계에 도달하기 전에 TLS 단계에서 연결이 멈출 수 있습니다.

‘인증서 검증 건너뛰기’는 중요한 신원 확인을 포기하는 설정이므로 일반적인 해결 방법으로 사용해서는 안 됩니다. 인증서 오류가 발생하면 시스템 시간, 서버 이름, 인증서 체인, 서버 설정 순으로 점검하세요. 사용자 지정 신뢰 방식을 쓴다면 누가 인증서를 발급했으며 클라이언트가 어떻게 신뢰를 설정하는지 명확히 해야 합니다. 검증을 계속 끄는 데 의존하지 마세요. 노드 원본에서 검증을 끄도록 요구한다면 배포 이유를 추가로 확인해야 합니다. 화면의 스위치가 프로토콜의 필수 조건이라고 볼 수는 없습니다.

Trojan은 코어에 따라 지원되는 전송 조합이 다를 수 있습니다. 기본 프로토콜 이름이 같다고 WebSocket, gRPC 또는 다른 부가 기능을 모두 지원하는 것은 아닙니다. 원본에 전송 유형이 지정되어 있다면 경로, 서비스 이름, 보안 설정을 빠짐없이 유지해야 합니다. Trojan이 TLS와 자주 함께 쓰인다는 이유로 전송 계층 항목을 무시하지 마세요. TLS 핸드셰이크가 성공해도 전송 접속 설정이 맞지 않으면 연결이 끊기거나 계속 대기할 수 있습니다.

Shadowsocks: 암호화 방식에 따라 키 조건이 달라집니다

Shadowsocks는 비교적 간결한 암호화 프록시 연결을 목표로 설계되었습니다. 초기 방식과 이후의 AEAD 방식은 형식과 보안 특성이 다릅니다. 클라이언트에 구형 방식 목록이 남아 있는 것은 주로 호환성 때문이며, 모든 방식이 새 배포에 적합하다는 뜻은 아닙니다. 노드를 선택할 때는 메모에 적힌 ‘고속’ 같은 표현보다 정확한 방식 이름이 중요합니다. 방식에 따라 양쪽의 데이터 처리 방법과 현재 코어의 연결 인식 여부가 결정됩니다.

Shadowsocks 2022 방식은 2022-blake3-aes-128-gcm처럼 키와 세션 처리도 개선했습니다. 이때 비밀번호는 길이에 제한이 없는 일반적인 문구가 아닙니다. 해당 방식에서 요구하는 길이의 키와 지정된 인코딩 형식이 필요하며, 전통적인 비밀번호 파생 방식과 다릅니다. 서버에서 제공한 키는 그대로 사용하세요. 기억하기 쉬운 짧은 문구로 바꾸거나 인코딩된 값을 다시 인코딩해서는 안 됩니다. 방식 이름과 키 형식이 맞지 않으면 설정 저장에 성공해도 실제 실행 단계에서 연결이 실패합니다.

일부 Shadowsocks 공유 링크에는 플러그인 정보도 포함됩니다. 플러그인은 추가 의존 항목이므로 모든 코어나 GUI 클라이언트가 바로 해석할 수 있는 것은 아닙니다. 가져오기 도구가 주소와 비밀번호는 읽었지만 플러그인 매개변수는 무시하면 항목이 완전해 보여도 실제 연결 경로는 달라집니다. 이때는 클라이언트 지원 문서를 확인하고 플러그인 설정이 변환되거나 유지됐는지 살펴보세요. 암호화 방식만 바꿔서는 빠진 플러그인 기능을 보완할 수 없습니다. 플러그인 설정을 TLS의 서버 이름 칸에 잘못 입력해서도 안 됩니다.

UDP와 성능은 별도로 검증하세요

두 프로토콜에서 UDP가 잘 작동하는지는 코어 구현, 서버 설정, 로컬 트래픽 연결 방식에도 영향을 받습니다. 웹페이지가 열린다는 사실은 일부 TCP 요청만 확인한 것으로 음성 통화, 게임 또는 다른 UDP 앱이 정상이라는 증거가 아닙니다. 실제로 사용할 앱을 선택해 테스트하고 트래픽이 프록시로 들어오는지, 라우팅에서 예상한 출구를 선택하는지 확인하세요. 일부 배포는 TCP 서버만 준비되어 있으므로 클라이언트에서 TUN을 켜도 서버의 UDP 지원이 생기지는 않습니다.

자원이 제한된 기기에서는 Shadowsocks의 대칭 암호화 경로가 부담이 적을 수 있지만, 실제 성능은 알고리즘, 하드웨어, 구현에 따라 달라집니다. Trojan은 TLS 연결을 맺을 때 핸드셰이크가 필요하지만 연결을 오래 유지하면 그 비용이 분산될 수 있습니다. 따라서 짧은 요청의 응답 시간과 장시간 다운로드를 나누어 살펴보세요. 이미 안정적인 서비스가 있다면 검증된 설정을 우선 유지하고, 새로 선택할 때는 앱 종류, 키 관리, 코어 지원을 기준으로 삼으세요.

REALITY와 Vision: 관련 설정을 함께 확인하세요

REALITY는 Xray 생태계의 보안 전송 방식으로 VLESS와 함께 자주 사용되며, Vision은 관련 연결에서 쓰이는 흐름 제어 방식입니다. 두 기능은 서로 다른 문제를 다루므로 ‘REALITY 사용’과 ‘Vision 사용’을 같은 작업으로 보면 안 됩니다. 클라이언트가 두 기능을 묶은 메뉴를 제공하더라도 흔한 설정을 한곳에 모아 보여주는 것뿐입니다. 실제 설정에는 프록시 프로토콜, 전송 방식, 보안 방식, flow를 각각 반영해야 하며 선택한 코어가 이를 지원해야 합니다.

REALITY의 인증 방식

일반적인 TLS 배포에서는 인증서 체인과 서버 이름을 통해 신뢰를 설정합니다. REALITY는 별도의 핸드셰이크와 인증 방식을 사용하므로 클라이언트에 서버가 제공한 공개 키 등의 매개변수가 필요하며 설정에 따라 인증에 참여합니다. 따라서 TLS의 이름만 바꾼 방식도 아니고 ‘인증서 오류 무시’ 스위치의 대체 기능도 아닙니다. 이 차이를 이해하면 일반 TLS 노드의 인증서 설정을 REALITY 노드에 그대로 적용하는 실수를 피할 수 있습니다.

publicKey는 관련 핸드셰이크를 클라이언트가 검증하는 데 필요한 공개 키이며 서버에 입력하는 개인 키가 아닙니다. shortId는 배포 설정의 식별자 매개변수로, 보통 16진수 형식이며 서버가 허용하는 값과 일치해야 합니다. UUID는 계속해서 VLESS 사용자 식별자로 사용됩니다. 이 값들은 모두 무작위 문자열처럼 보여도 서로 바꿔 쓸 수 없습니다. 길이가 비슷해 보여도 인코딩과 처리 규칙이 다릅니다.

serverName 또는 SNI는 서버 설정에서 허용한 값이어야 합니다. 접속 가능한 웹사이트 도메인이라면 아무거나 입력해도 되는 것이 아닙니다. fingerprint는 chrome 등 지원되는 클라이언트 핸드셰이크 지문을 지정합니다. 이는 핸드셰이크 동작을 나타낼 뿐 클라이언트가 브라우저를 실행하거나 해당 브라우저를 설치해야 한다는 뜻은 아닙니다. 지문 선택은 코어의 지원 범위에도 영향을 받으므로 브라우저 제품 이름을 임의로 입력했다고 유효한 값이 되는 것은 아닙니다.

Vision은 추가 암호화 계층이 아닙니다

Vision은 데이터 흐름 처리에 중점을 두며, 특히 프록시 연결 안에서 TLS 트래픽을 전달할 때의 동작과 관련됩니다. 추가 인증 비밀번호도 아니고 독립적인 프록시 프로토콜도 아닙니다. 일반적인 VLESS 설정에서는 xtls-rprx-vision으로 해당 흐름 제어 방식을 지정하며, 서버 설정 및 지원되는 전송 방식과 일치해야 합니다. WebSocket을 비롯한 임의의 전송 조합에 복사해서는 안 됩니다. 클라이언트에서 부적절한 조합을 저장할 수 있더라도 코어가 거부하거나 연결을 완료하지 못할 수 있습니다.

REALITY와 Vision은 함께 쓰이는 경우가 많지만 필요한 조건은 각각 확인할 수 있습니다. 보안 방식은 서버 배포에서 정하고, flow는 양쪽에서 지원하는 흐름 제어 설정으로 결정됩니다. 둘 다 클라이언트가 단독으로 정할 수 없습니다. Vision이 없는 REALITY 노드라면 원본 설정을 유지하세요. Vision이 명시된 노드라면 가져오는 과정에서 flow가 누락되지 않았는지 확인합니다. 홍보 문구만 보고 설정을 추가하면 원래 올바른 설정에 호환성 문제가 생길 수 있습니다.

가져오기 실패와 핸드셰이크 실패는 구분해서 해결하세요

링크를 가져올 수 없다면 먼저 클라이언트가 REALITY 항목과 현재 공유 형식을 인식하는지 확인하세요. 가져오기는 성공했지만 코어가 알 수 없는 항목이라고 보고한다면 설정 생성 또는 코어 호환 단계의 문제입니다. 핸드셰이크에 실패하면 주소, 포트, 사용자 식별자, 공개 키, 서버 이름, shortId를 확인하세요. 서버가 배포에 필요한 대상에 접근하지 못해도 핸드셰이크에 문제가 생길 수 있습니다. 클라이언트는 자체 설정을 확인할 수 있을 뿐, 공개 키를 바꿔 서버의 네트워크 조건을 해결할 수는 없습니다.

구독을 업데이트한 뒤 설정 항목이 달라졌다면 노드 편집 화면을 다시 확인하세요. 특히 보안 방식, flow, 공개 키 관련 항목을 살펴봐야 합니다. 이전 노드의 공개 키를 새 노드에 이어 붙이지 말고 주소가 같다는 이유로 서버 설정까지 그대로라고 단정하지 마세요. 직접 관리해야 한다면 원본으로 가져온 항목을 비교용으로 보관하세요. REALITY 노드는 Xray 기능 지원 여부를 우선 확인해야 합니다. 클라이언트가 VLESS를 지원한다는 이유만으로 해당 보안 및 흐름 제어 조합도 지원한다고 판단해서는 안 됩니다.

연결 성능·리소스 사용량·모바일 배터리

프로토콜 성능에 절대적인 순위는 없습니다. 사용자가 말하는 ‘빠르다’는 연결 수립, 웹페이지 첫 응답, 다운로드 속도, 연결 끊김 후 복구 속도 중 무엇을 뜻하는지에 따라 다릅니다. 각 지표에 영향을 주는 요인이 달라 한 번의 속도 측정으로 모두 판단할 수 없습니다. 프록시 프로토콜의 헤더와 암호화는 연결 경로의 일부일 뿐입니다. DNS 조회, 서버와의 거리, 전송 핸드셰이크, 혼잡 제어, 서버 부하가 더 큰 제약이 될 수도 있습니다.

짧은 연결과 긴 연결은 비용을 다르게 살펴보세요

웹페이지를 열 때 여러 연결이 발생할 수 있습니다. 데이터 전송에 앞서 도메인 조회, TCP 연결, TLS 핸드셰이크에 시간이 들고 전송 방식에 따라 별도의 연결 과정이 추가되기도 합니다. 연결 재사용은 이런 비용을 분산할 수 있지만 프로토콜, 앱, 코어가 모두 지원해야 합니다. 짧은 요청이 많은 환경에서는 연결 수립 비용이 두드러질 수 있고, 장시간 다운로드는 대체로 경로 용량, 혼잡, 서버 처리 능력의 영향을 더 많이 받습니다. 핸드셰이크가 적다고 다운로드 속도까지 반드시 빨라지는 것은 아닙니다.

WebSocket은 애플리케이션 계층의 캡슐화를 추가하고, gRPC는 보통 HTTP/2 연결 동작에 의존합니다. 각 방식은 배포 편의성이나 연결 재사용 측면의 장점이 있지만 추가 처리도 필요합니다. 사용 여부는 프로토콜 이름 자체가 아니라 서버 접속 지점과 네트워크 조건에 따라 결정하세요. 같은 서버 주소를 유지한 채 전송 방식만 마음대로 바꾸며 테스트해서는 안 됩니다. 서버가 해당 유형으로 수신 대기하지 않을 수 있기 때문입니다. 그런 실패는 성능 차이가 아니라 배포 설정 불일치를 나타냅니다.

암호화와 메모리 사용량 이해하기

프로세서의 AES 명령어 지원, 알고리즘 구현 품질, 단일 코어 성능에 따라 암호화 비용이 달라집니다. 코어의 메모리 사용량에는 동시 연결 수, 버퍼, DNS 캐시, 라우팅 데이터 규모가 영향을 줍니다. 클라이언트 프로세스의 사용량이 커 보인다면 GUI와 코어 하위 프로세스도 구분해서 확인해야 합니다. 유휴 상태에서 한 번 측정한 메모리 수치만으로 특정 프록시 프로토콜이 더 가볍다고 판단할 수 없습니다. 같은 연결 수와 부하에서 변화를 비교해야 합니다.

다중화는 연결 수립 비용의 일부를 줄일 수 있지만 트래픽을 공유 채널에 모으면 차단과 복구 동작이 달라질 수 있습니다. 모든 노드에서 켜야 하는 가속 옵션이 아니며 UDP나 일부 흐름 제어 조합에서는 구현 차이도 있습니다. 원본이나 코어 설명에 명확한 권장 사항이 없다면 기본 설정을 먼저 사용하세요. 켠 뒤 동시 요청에서만 문제가 생긴다면 원래 설정으로 되돌린 다음 다중화와 관련이 있는지 확인하세요. 서버 비밀번호부터 바꾸지 마세요.

모바일 배터리 소모는 프로토콜만으로 결정되지 않습니다

모바일 기기의 무선 통신 활성화, 백그라운드 앱 요청, 연결 유지 동작은 배터리 사용량에 큰 영향을 줍니다. 가벼운 프로토콜이라도 자주 재연결하면 안정적인 연결보다 배터리를 더 소모할 수 있습니다. Wi-Fi와 모바일 데이터 사이를 전환하면 기존 연결이 끊겨 코어가 다시 연결해야 합니다. 짧은 시간 동안 반복 측정하거나 노드를 자주 바꾸는 것도 리소스를 더 사용합니다. 따라서 한 번의 수동 속도 테스트에서 발생한 배터리 소모를 프로토콜 탓으로 돌리기보다 평소 사용 중의 추이를 확인하세요.

v2rayNG와 v2flyNG는 Android의 VpnService를 통해 트래픽을 받고, 앱별 설정으로 프록시 처리 대상 앱을 정합니다. 불필요한 앱의 트래픽을 제외하는 것이 프로토콜을 바꾸는 것보다 직접적인 해결책일 수 있습니다. 시스템 절전 정책이 백그라운드 서비스를 중지하면 화면을 잠근 뒤 연결이 끊길 수 있습니다. 필요한 백그라운드 실행을 시스템 설정에서 허용하고, 계속 트래픽을 발생시키는 앱이 있는지도 확인하세요. 백그라운드 제한과 배터리 과다 소모를 같은 문제로 혼동하지 마세요.

반복 가능한 테스트 방법을 정하세요

먼저 짧은 요청을 테스트하고, 그다음 지속적인 전송을 확인한 뒤 대기 상태와 네트워크 전환을 살펴보세요. 연결 성공 여부, 안정적으로 유지되는지, 프로세서 부하가 뚜렷한지만 기록해도 충분합니다. 프로토콜에 통일된 점수를 억지로 매길 필요는 없습니다. 각 테스트를 반복하고 구독 업데이트나 다른 다운로드를 동시에 진행하지 마세요. 도메인 요청만 느리다면 DNS를 별도로 점검하고, UDP 앱만 문제라면 트래픽 유입, 라우팅, 서버 지원을 확인하세요.

배터리를 비교할 때는 화면 밝기와 앱 부하를 비슷하게 맞추고 충분히 긴 시간 관찰하세요. 화면을 켜 둔 사용과 백그라운드 대기도 구분해야 합니다. VpnService 권한, 절전 예외, 앱별 프록시 설정은 v2rayNG 안드로이드 설정 핵심에서 확인할 수 있습니다. 연결이 안정적이고 기기 부하가 감당할 만하다면 이론적인 프로토콜 비용을 줄이려고 자주 옮길 필요는 없습니다. 실제로 관리하기 쉬운지도 선택 비용에 포함됩니다.

V2Fly와 Xray: 계보와 호환 범위

Project V 생태계는 프록시 연결, 라우팅, 전송 기능 등을 설정 가능한 코어로 구성합니다. V2Fly는 V2Ray 프로젝트의 관련 개발을 이어가고, Xray는 이 기술 체계에서 갈라져 나와 자체 기능을 발전시켰습니다. 공통된 설정 개념과 역사를 공유하더라도 모든 설정이 같다는 뜻은 아닙니다. 각 프로젝트가 발전하면서 프로토콜 지원, 전송 구현, 보안 기능, 설정 항목 구조에 차이가 생길 수 있습니다.

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

v2rayN은 데스크톱 클라이언트로 노드 관리, 구독, 설정 화면, 실행 제어를 담당하고 실제 연결은 호출된 코어가 처리합니다. v2rayNG는 Android용이며 보통 Xray 코어를 사용합니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 화면이 비슷해도 기반 기능은 같지 않을 수 있습니다. 노드 실행 가능 여부를 확인할 때는 클라이언트가 설정 항목을 올바르게 입력할 수 있는지와 코어가 생성된 설정을 인식하는지를 모두 확인해야 합니다.

데스크톱에서는 노드, 라우팅, 시스템 연결 방식을 한곳에서 관리할 수 있어 v2rayN을 우선 사용합니다. 그렇다고 가져온 모든 항목이 자동으로 호환된다는 뜻은 아닙니다. 여러 코어를 전환하려면 클라이언트 버전과 실행 환경이 해당 기능을 지원해야 합니다. 코어를 바꾼 뒤에는 트레이 아이콘이 나타나는지만 보지 말고 현재 노드와 라우팅을 다시 확인하세요. Android에서 클라이언트를 바꿀 때도 구독 형식, 앱 트래픽 유입, 프로토콜 옵션을 다시 살펴봐야 합니다.

설정 개념은 비슷해도 항목을 그대로 바꿔 쓸 수 있는 것은 아닙니다

일반적인 JSON 설정에는 인바운드, 아웃바운드, 라우팅, DNS가 들어갈 수 있지만 각 항목의 의미는 대상 코어 기준으로 확인해야 합니다. 특정 기능이 한쪽에서만 지원되기도 하고, 양쪽 모두 지원하더라도 설정 형식이 다를 수 있습니다. 원본 JSON을 다른 코어에 복사하기 전에 프로토콜, 전송, 보안 설정을 확인하고 라우팅과 DNS도 점검하세요. 실행될 때까지 오류가 난 항목을 하나씩 지우는 방식은 피해야 합니다.

REALITY와 Vision은 코어를 선택할 때 Xray 지원 여부를 확인해야 하는 대표적인 기능입니다. V2Fly가 기본 프록시 프로토콜을 지원한다고 해서 Xray 확장 조합까지 모두 지원하는 것은 아닙니다. 반대로 Xray가 일부 V2Ray 형식의 설정을 인식한다고 해서 과거 항목이나 앞으로 추가될 항목까지 모두 유효한 것도 아닙니다. 공유 링크를 클라이언트가 변환하면 코어 간 형식 차이가 드러나지 않을 수 있지만, 네이티브 JSON에서는 차이가 바로 나타납니다.

라우팅 예시로 살펴보는 공통 개념

아래는 라우팅 부분의 JSON 예시입니다. 사설 주소는 direct로 보내고 나머지 TCP·UDP 트래픽은 proxy로 보내는 규칙을 나타냅니다. 대상 코어의 전체 설정에 병합해야 하며, 같은 이름의 아웃바운드가 이미 정의되어 있어야 합니다. geoip 분류에 필요한 데이터도 이용할 수 있어야 합니다. 연결 인증 정보는 포함되어 있지 않으며 단독으로 실행 가능한 노드 설정도 아닙니다. 이 예시는 규칙 순서를 설명하며 클라이언트가 생성한 전체 설정을 덮어쓰면 안 됩니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

규칙은 보통 순서대로 적용되므로 앞에 있는 조건이 뒤의 규칙 실행 여부에 영향을 줍니다. AsIs는 IP 조건에 맞추기 위해 도메인 요청의 IP를 능동적으로 조회하지 않습니다. 따라서 이 사설 주소 규칙을 ‘최종적으로 사설 IP로 해석되는 모든 도메인은 direct로 연결된다’고 이해하면 안 됩니다. DNS 조회 결과에 따라 라우팅하려면 domainStrategy를 추가로 살펴보세요. 자세한 설정은 domain·ip·geosite 및 규칙 우선순위에서 확인할 수 있습니다.

업데이트와 전환은 되돌릴 수 있게 진행하세요

클라이언트 업데이트는 GUI, 가져오기 로직, 코어 기능 중 일부 또는 여러 요소에 영향을 줄 수 있습니다. 작동하는 설정을 보관하고 업데이트 뒤에도 이전과 같은 코어를 사용 중인지 확인하세요. 모든 기능에 일률적으로 적용되는 버전 기준을 임의로 정하지 말고 현재 릴리스 안내와 실제 설정 지원 여부를 따르세요. 업데이트 후 일부 노드만 작동하지 않는다면 해당 노드의 프로토콜 조합을 먼저 비교하고, 모든 노드가 작동하지 않는다면 실행 환경, 권한, 설정 생성 과정을 확인하세요.

로그에 알 수 없는 프로토콜이나 항목이 표시되면 기능 지원과 설정 문법을 확인하세요. 연결 시간 초과만으로 코어에 기능이 없다고 단정해서는 안 됩니다. 다른 코어로 바꿔 문제가 사라져도 클라이언트가 다른 설정까지 함께 변경했는지 확인하세요. 데스크톱 설치 파일이나 Android 클라이언트를 찾는다면 설치 파일 페이지에서 플랫폼과 아키텍처를 확인하세요. 이 페이지는 기능 호환 범위를 설명하며 코어를 별도로 다운로드하는 절차는 다루지 않습니다.

구독 및 공유 형식: 가져온 뒤 호환성 확인

구독은 노드를 배포하는 방식이지 새로운 프록시 프로토콜이 아닙니다. 하나의 구독에 여러 프로토콜의 항목이 포함될 수도 있고, 특정 클라이언트에서 인식하는 설정만 제공될 수도 있습니다. 구독 주소에 요청해 응답을 받았다는 사실만으로 응답 형식을 파싱할 수 있다고 보장되지는 않습니다. 클라이언트에 몇 개의 노드가 표시되더라도 일부 항목만 가져온 것일 수 있습니다. 전송 및 보안 설정이 모두 유지됐는지, 현재 코어에서 지원되는지도 추가로 확인해야 합니다.

공유 링크·Base64·네이티브 JSON

공유 링크는 보통 vmess://, vless://, trojan://, ss://처럼 프로토콜 접두사로 유형을 표시합니다. 유형마다 주소, 인증 정보, 추가 매개변수를 담는 위치가 다릅니다. VMess 링크에는 인코딩된 JSON이 자주 들어가고, VLESS와 Trojan은 URI 쿼리 매개변수를 주로 사용합니다. 접두사만 바꿔 서로 변환할 수 있는 형식이 아닙니다. 복사할 때는 전체 내용을 유지하고 특수 문자와 매개변수 인코딩에 특히 주의하세요.

Base64는 여러 공유 링크를 하나의 구독 응답으로 묶는 데 자주 쓰입니다. Base64 자체는 인코딩일 뿐 연결을 암호화하지 않습니다. 텍스트를 디코딩해도 완전하게 실행 가능한 코어 설정을 얻는 것은 아니며 모든 링크가 유효하다는 뜻도 아닙니다. 클라이언트가 각 프로토콜을 파싱하고 아웃바운드를 생성해야 합니다. 가져오기 전에 콘텐츠 출처를 확인하고 인증 정보가 포함된 구독을 알 수 없는 서비스에 업로드하지 마세요. 로컬 파싱과 원격 변환은 개인정보 보호 범위가 다릅니다.

네이티브 JSON에는 노드뿐 아니라 인바운드, 라우팅, DNS, 로그, 여러 아웃바운드가 포함될 수 있으며 특정 코어나 클라이언트의 동작 방식을 전제로 하는 경우가 많습니다. 단일 공유 링크와 담고 있는 정보의 양이 다릅니다. 전체 JSON을 공유 링크로 바꾸면 여러 전역 설정에 대응하는 항목이 없고, 공유 링크를 JSON으로 바꾸면 로컬 트래픽 유입과 라우팅을 추가해야 합니다. 변환은 정보를 그대로 보존하지 않으므로 노드 정보만 유지할지 전체 실행 정책을 유지할지 먼저 정하세요.

누락되기 쉬운 설정과 인코딩 주의 사항

최신 보안 설정, flow, 핸드셰이크 지문, 특정 전송 항목은 구형 가져오기 도구나 단순 변환기에서 무시될 수 있습니다. 노드 이름, 주소, 사용자 식별자가 남아 있어도 설정 일부가 이미 빠졌을 수 있습니다. REALITY 노드를 가져온 뒤에는 편집 창에서 모든 항목을 확인하세요. 플러그인이 포함된 Shadowsocks 링크도 플러그인 정보가 유지됐는지 점검해야 합니다. 메모가 보존됐다고 설정까지 온전하다는 뜻은 아니며, 설정 항목 대조를 대신할 수도 없습니다.

URI의 특수 문자는 형식에 맞게 인코딩해야 합니다. 비밀번호, 경로, 메모에 구분 문자가 들어갈 때 특히 주의하세요. 직접 조합하면 비밀번호 일부가 쿼리 매개변수로 해석되거나 경로 문자가 바뀔 수 있습니다. 가져오기에 실패하면 문장 부호를 계속 지우지 말고 클라이언트의 클립보드 또는 파일 가져오기 기능을 먼저 사용하세요. 공유 형식에 따라 구현 차이가 있을 수 있으므로 특정 항목을 파싱하지 못한다면 모든 링크를 직접 다시 쓰기보다 제공자에게 대상 클라이언트를 확인하세요.

구독 업데이트 실패와 연결 실패는 구분하세요

구독 업데이트에 실패하면 먼저 주소가 완전한지, 만료되지는 않았는지, 요청을 보낼 수 있는지, 업데이트 요청에 프록시가 필요한지 확인하세요. 노드 연결은 되지만 업데이트가 실패한다면 구독 서버에 접근하는 조건이 다를 수 있습니다. 업데이트는 성공하지만 노드 연결이 실패한다면 노드 설정과 서버 상태를 확인해야 합니다. 시스템 시간이 맞지 않으면 구독 요청의 TLS 인증에도 영향을 줄 수 있습니다. 구독 요청 오류를 프록시 프로토콜 자체의 문제로 보지 마세요.

자동 업데이트로 노드 목록이 바뀌며 직접 수정한 설정은 다음 업데이트 때 덮어써질 수 있습니다. 시험한 설정을 계속 유지해야 한다면 별도의 항목이나 그룹에 복사하고 원본 변경 사항을 더 이상 자동으로 반영하지 않는다는 점을 분명히 하세요. 구독을 바꾼 뒤에는 현재 선택된 노드도 다시 확인해야 합니다. 클라이언트가 항상 올바른 항목을 자동 선택한다고 가정하지 마세요. 업데이트 요청과 간격 설정은 구독 업데이트 실패의 주요 원인에서 확인할 수 있습니다.

다른 클라이언트로 옮길 때는 적은 수의 노드로 가져오기를 테스트한 뒤 UDP, 라우팅, 앱 트래픽 유입을 확인하고 나머지를 옮기세요. 코어 교체, 구독 변환, DNS 변경을 한꺼번에 하면 어떤 단계에서 문제가 생겼는지 파악하기 어렵습니다. 세 가지 형식의 구조와 변환 범위는 Base64 구독·네이티브 JSON·공유 링크 비교에서 확인할 수 있습니다. 구독에 포함된 인증 정보는 민감한 설정으로 취급하고, 문제 해결용 화면을 공유하기 전에 가리세요.

사용 환경에 따른 선택과 설정 확인 절차

프로토콜 선택은 우선 서버 지원 여부에 달려 있으며 클라이언트 선호는 그다음입니다. 사용할 수 있는 서버가 하나뿐이라면 새로운 프로토콜 이름을 좇기보다 올바르게 가져와 안정적으로 사용하는 것이 중요합니다. 배포 방식을 선택할 수 있다면 유지 관리 조건, 단말 기능, 앱 종류, 성능 요구 사항을 비교하세요. 다음 절차에서는 선택과 문제 해결을 함께 다룹니다. 호환되지 않는 조합을 먼저 제외하고 트래픽 유입과 라우팅을 확인한 다음 반복 가능한 테스트로 전환할 가치가 있는지 판단하세요.

데스크톱과 모바일의 기본 환경을 각각 정하세요

데스크톱에서는 v2rayN으로 노드를 관리하고 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택한 뒤 사용할 코어를 확인하세요. 일반적인 브라우저 사용은 시스템 프록시로 먼저 확인하고 시스템 프록시를 따르지 않는 앱이 있다면 TUN을 고려할 수 있습니다. TUN은 로컬 트래픽 유입 방식을 바꿀 뿐 서버 프로토콜을 바꾸지 않으며 잘못된 공개 키나 비밀번호도 고쳐 주지 않습니다. 먼저 일반 연결을 정상 작동시키면 이후 트래픽 유입 설정의 문제를 더 쉽게 찾을 수 있습니다.

Android에서는 특히 Xray 기능이 필요할 때 v2rayNG를 우선 사용하고, V2Fly용 설정이 필요한 경우 v2flyNG를 고려할 수 있습니다. 두 클라이언트 모두 실제 프로토콜 지원 여부를 확인해야 하며 설치에 성공했다고 노드 호환성까지 보장되는 것은 아닙니다. 처음 사용하려면 VpnService 권한을 허용해야 하고, 화면 잠금 후 안정적으로 작동하는지도 백그라운드 제한을 확인해야 합니다. 앱별 프록시 범위를 사용 목적에 맞추세요. 프록시로 들어오지 않은 앱을 프로토콜 오류로 오해하지 않도록 주의해야 합니다.

앱 종류와 관리 조건에 맞춰 조합을 선택하세요

짧은 요청이 많은 환경에서는 연결 수립과 DNS를, 지속적인 전송에서는 처리량과 안정성을, 실시간 통신에서는 UDP와 네트워크 전환을 중점적으로 확인하세요. 리소스가 제한된 기기라면 대칭 암호화 비용과 동시 연결 수를 살펴볼 수 있지만, 유휴 메모리 화면을 한 번 캡처한 것만으로 결론을 내려서는 안 됩니다. 표준 TLS 인증서를 사용할 수 있고 유지 관리 절차가 갖춰져 있다면 해당 TLS 방식을 우선 고려할 수 있습니다. REALITY를 사용한다면 공개 키, 서버 이름, 관련 설정을 안정적으로 관리해야 합니다.

VMess나 Shadowsocks 서버가 안정적으로 운영 중이라면 클라이언트의 드롭다운만 바꾸는 것으로는 전환할 수 없습니다. 서버에서 해당 프로토콜을 새로 제공해야 합니다. VLESS를 선택할 때는 보안 계층과 flow를 함께 정하고, Trojan은 비밀번호와 인증서 신원을 확인하며, Shadowsocks는 방식과 키 형식을 점검하세요. 장기적으로는 설정이 더 복잡하더라도 관리 능력이 부족한 조합보다 담당자가 계속 이해하고 올바르게 갱신할 수 있는 조합이 더 적합합니다.

연결 문제는 발생 단계별로 범위를 좁히세요

첫 번째 단계에서는 가져오기와 실행을 확인합니다. 노드가 있는지, 올바른 항목이 선택됐는지, 코어가 정상 실행 중인지, 로그에 알 수 없는 항목이 표시되는지 살펴보세요. 두 번째 단계에서는 접속과 핸드셰이크를 확인합니다. 주소 확인, 포트 연결 가능 여부, 서버 이름, 시스템 시간을 점검하세요. 세 번째 단계에서는 인증과 전송을 확인합니다. 사용자 식별자, 비밀번호, 암호화 방식, 경로, 공개 키, flow를 대조하세요. 각 단계에서 먼저 원본 설정을 복원하고 검증되지 않은 ‘최적화’를 여러 개 겹쳐 적용하지 마세요.

연결은 됐는데 웹페이지가 열리지 않는다면 앱 트래픽 유입, 라우팅 출구, DNS를 확인하세요. IP를 직접 사용하는 요청과 도메인 요청을 비교할 수 있지만 대상이 해당 방식의 접근을 허용하는지도 살펴봐야 합니다. 일부 앱만 작동하지 않는다면 시스템 프록시를 따르는지, 앱별 목록에 포함됐는지, UDP에 의존하는지 확인하세요. 프로토콜을 바꾸기 전에 문제가 로컬 트래픽 유입, 프록시 연결, 대상 서비스 중 어디에서 생겼는지 판단하면 불필요한 테스트를 줄일 수 있습니다.

작동하는 설정과 검증 기록을 보관하세요

기본 설정을 정한 뒤 프로토콜, 전송 방식, 보안 방식, 코어, 트래픽 유입 방식만 기록하세요. 인증 정보를 공개 노트에 적을 필요는 없습니다. 변경할 때는 한 번에 한 요소만 조정하고 원본으로 가져온 항목을 보관하세요. 클라이언트나 구독을 업데이트한 뒤에는 자주 쓰는 앱, 특히 백그라운드 실행과 UDP를 다시 확인하세요. 일시적인 네트워크 변동이 있을 때 모든 설정을 한꺼번에 바꾸지 마세요. 먼저 테스트를 반복하고 로그를 살펴 문제가 재현되는지 확인한 다음 추가 조치를 취하세요.

이 페이지는 선택의 호환 범위를 이해하기 위한 자료입니다. 전체 사용 순서는 빠른 시작 안내를 참고하세요. 자주 묻는 사용 문제는 자주 묻는 질문에서, 설정 항목의 의미는 용어집에서 확인할 수 있습니다. 최종적으로는 출처가 분명하고 설정 항목이 서로 일치하며 코어가 지원하고 실제 앱에서 연결을 확인한 구성을 사용해야 합니다. 추상적인 프로토콜 순위표보다 안정성, 유지 관리 편의성, 실제 작업 수행 여부가 적합성을 판단하는 기준입니다.