V2Ray 프로토콜과 코어
선택 가이드

설정 계층: 프로토콜은 연결 전체가 아닙니다

설정을 네 가지 계층으로 나눠 보세요

클라이언트에 표시되는 프로토콜 이름은 연결 과정의 일부만 설명합니다. 앱이 요청을 로컬 프록시로 보내면 코어가 라우팅 규칙에 따라 아웃바운드를 정합니다. 그런 다음 프록시 프로토콜이 대상 주소와 인증 정보를 감싸고, 선택한 전송 방식으로 원격 서버에 연결합니다. 보안 계층은 이 전송을 보호합니다. 따라서 VLESS, TCP, TLS는 하나의 설정에 함께 들어갈 수 있습니다. 서로 충돌하는 항목도 아니고 같은 항목을 대신할 수도 없습니다. 설정 호환성을 판단할 때는 목록의 프로토콜 이름만 볼 것이 아니라 각 계층을 함께 확인해야 합니다.

로컬 연결과 원격 프로토콜도 구분해야 합니다. 브라우저가 컴퓨터의 HTTP 또는 SOCKS 포트에 연결한다고 해서 원격 서버도 같은 프로토콜을 사용하는 것은 아닙니다. 시스템 프록시는 보통 시스템 설정을 따르는 앱에 요청을 로컬 프록시로 보내도록 알려줄 뿐, 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. 가상 네트워크 어댑터 모드는 네트워크 계층에 더 가까운 곳에서 트래픽을 받아들여 적용 범위와 권한, DNS 처리 방식이 다릅니다. 특정 앱에서 접속이 안 된다면 먼저 요청이 코어에 들어오는지 확인한 뒤 원격 프로토콜을 점검하세요.

전송 방식과 보안 계층의 역할

TCP는 신뢰성 있는 바이트 스트림을 제공합니다. WebSocket은 연결을 맺을 때 HTTP 업그레이드 과정을 거치고, gRPC는 HTTP/2 기반으로 데이터를 전송합니다. 이들은 연결 방식과 중간 장비의 지원 조건을 바꾸지만 사용자 인증 프로토콜을 대신하지는 않습니다. 경로, 서비스 이름, 요청 헤더는 보통 전송 설정에 해당하며 비밀번호가 아닙니다. 클라이언트는 WebSocket을 사용하도록 설정했는데 서버가 일반 TCP로 수신한다면 주소, 포트, 사용자 ID가 맞더라도 반복해서 재시도해 해결할 수 없습니다. 먼저 양쪽의 전송 유형을 일치시켜야 합니다.

TLS는 서버를 인증하고 전송을 보호합니다. 인증서 이름, 서버 이름 표시(SNI), 인증서 신뢰 체인이 모두 관련됩니다. REALITY는 별도의 보안 계층 방식이며 지원 범위는 코어에 따라 다릅니다. 모든 항목을 서로 그대로 바꿔 쓸 수 있는 것은 아닙니다. 서비스 이름에 TLS가 들어 있다고 해서 올바른 보안 계층이 설정됐다고 단정할 수 없습니다. 화면의 옵션, 내보낸 설정 항목, 실행 로그를 확인하세요. 프록시 주소는 IP일 수 있지만 인증에는 도메인을 사용할 수 있습니다. 두 항목은 역할이 다르므로 보기 좋게 맞추려고 같은 값으로 바꾸지 마세요.

계층별로 문제 찾기

설정을 받았다면 다음 순서로 항목을 정리하세요. 연결 주소와 포트, 프로토콜과 인증, 전송 유형, 보안 계층, 추가 흐름 제어 설정입니다. 그런 다음 라우팅, DNS, 로컬 프록시 모드를 확인합니다. 앞의 항목은 원격 연결을 올바르게 설정할 수 있는지 결정하고, 뒤의 항목은 어떤 요청을 연결에 보낼지와 도메인을 어디서 해석할지를 결정합니다. 모든 옵션을 한꺼번에 바꾸면 우연히 접속이 복구되더라도 무엇이 효과가 있었는지 알기 어렵습니다. 구독을 갱신한 뒤 같은 문제가 다시 생길 수도 있습니다. 원본 설정을 보관하고 한 번에 한 계층씩 바꾸면 결과를 재현하기 쉽습니다.

로그도 계층별로 읽을 수 있습니다. 연결이 거부되면 먼저 주소, 포트, 서버 수신 상태를 확인하세요. 핸드셰이크가 실패하면 보안 계층과 전송 방식을, 인증이 실패하면 사용자 정보를 확인합니다. 다만 이는 우선 확인할 항목이지 확정적인 원인 진단은 아닙니다. 서버가 먼저 연결을 끊어도 연결 중단으로 표시될 수 있습니다. 같은 시각에 발생한 오류와 현재 설정을 대조하고, 백그라운드의 다른 요청 오류를 해당 연결의 문제로 오해하지 마세요. 오류 키워드에 대한 자세한 설명은 Xray 코어 실행 로그로 문제 찾기를 참고하세요.

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

VMess는 왜 프로토콜에 더 많은 기능을 담았을까요?

VMess는 Project V 초기에 중요한 역할을 한 프로토콜입니다. 사용자 인증과 데이터 보호 등의 기능을 프로토콜 설계에 포함해 다양한 전송 환경에서 프록시 연결을 만들 수 있도록 했습니다. 단순히 원래 요청에 비밀번호 항목을 추가하는 방식이 아니라 핸드셰이크와 데이터 캡슐화에 고유한 규칙이 있습니다. 따라서 클라이언트와 서버가 같은 프로토콜을 이해해야 합니다. 실제 오버헤드는 암호화 구현, 프로세서 성능, 외부 전송 방식, 연결 재사용 여부에 따라 달라집니다. 등장 시기가 이르다는 이유만으로 더 느리다고 볼 수 없으며, 프로토콜 이름만으로 회선의 실제 대역폭을 알 수도 없습니다.

최신 VMess 설정은 보통 AEAD 인증 방식을 사용합니다. 오래된 가이드에서 자주 보이는 추가 ID 매개변수는 과거 호환성에 관한 내용이므로 현재의 튜닝 옵션으로 삼기에는 적절하지 않습니다. 오래된 링크를 가져온 뒤 형식이 오래됐거나 인증에 실패한다는 메시지가 나오면 추가 ID를 무작정 바꾸기보다 설정 제공자에게 현재 형식을 확인하세요. VMess는 시간 동기화도 필요합니다. 기기에 표시된 날짜와 시간대, 실제 시스템 시간은 구분해야 하며 인증에 영향을 주는 것은 실제 시간이 정확한지 여부입니다. 암호화 옵션을 바꾸기보다 시스템 시간을 바로잡고 로그를 확인하는 편이 낫습니다.

VLESS는 어떤 기능을 외부에 맡길까요?

VLESS는 프로토콜 구조를 가볍게 유지하도록 설계되어 VMess와 같은 데이터 암호화 기능을 프로토콜 내부에서 담당하지 않고 외부 보안 계층과 함께 사용합니다. 사용자 ID는 인증에 쓰이지만 그 자체로 전송 내용을 보호하는 완전한 수단은 아닙니다. 따라서 흔히 VLESS와 TLS 또는 REALITY를 함께 설정합니다. VLESS를 선택했다고 보안 설정을 생략할 수 있는 것은 아닙니다. 클라이언트의 프로토콜 항목에 ‘암호화 안 함’과 같은 표시가 있더라도 이는 해당 계층을 설명하는 것이며, 신뢰할 수 없는 네트워크에서 연결 전체를 평문으로 전송해도 된다는 뜻은 아닙니다.

UUID는 흔히 사용하는 사용자 ID 형식입니다. 가져올 때 공백, 줄바꿈, 전각 문자가 섞이지 않도록 원래 값을 그대로 유지하세요. 클라이언트에서 새 ID를 만들 수는 있지만 로컬에서 생성해도 서버 설정까지 바뀌지는 않습니다. 인증 정보는 서버에 등록된 값과 일치해야 합니다. 혼동하기 쉬운 또 다른 항목은 흐름 제어입니다. 이는 전체 연결을 빠르게 만드는 스위치도 아니고 모든 VLESS 조합에 필요한 것도 아닙니다. 서버가 해당 설정을 명시적으로 제공하고 현재 코어와 전송 조합이 지원할 때만 원래 값대로 사용하세요. 잘 모르겠다면 가져온 값을 그대로 두고 흐름 제어 이름을 임의로 만들지 마세요.

VMess와 VLESS, 실제로 어떻게 선택할까요?

안정적으로 작동하는 VMess 설정이 있다면 다른 프로토콜이 더 자주 언급된다는 이유만으로 옮길 필요는 없습니다. 마이그레이션은 명확한 호환성 요구나 서버 유지보수 계획, 실제로 측정된 문제를 근거로 결정하세요. 클라이언트가 특정 프로토콜을 지원한다는 것은 해당 설정을 처리할 수 있다는 뜻이지, 설정 제공자가 그 프로토콜을 서버에 배포했다는 뜻은 아닙니다. 반대로 VLESS 설정을 받았다면 VMess의 모든 항목을 찾을 필요가 없습니다. 프로토콜마다 인증과 캡슐화 구조가 다르므로 매개변수가 빠졌다고 해서 가져오기에 실패한 것은 아닐 수 있습니다. 다른 프로토콜의 화면을 하나씩 채우지 말고 같은 프로토콜의 항목 설명을 확인하세요.

v2rayN에서 확인하려면 먼저 서버 편집 창을 열어 프로토콜 유형을 확인한 다음 전송 방식, 보안 계층, 흐름 제어를 살펴보세요. v2rayNG에서도 같은 순서로 확인하면 됩니다. 클라이언트 업데이트에 따라 화면의 항목 이름이 달라질 수 있으므로 이름보다 필드의 의미를 기준으로 판단하세요. 코어를 바꾼 뒤 연결이 되지 않으면 UUID를 지웠다 다시 만들기보다 변경 전후의 코어 이름과 오류를 기록하세요. 되돌릴 때는 정상 작동이 확인된 설정 전체를 복구하세요. 한 항목을 계속 수정하는 것보다 명확한 비교 기준을 두는 편이 차이를 찾기 쉽습니다.

보안 계층과 전송 설정이 올바른지 확인한 다음에야 리소스 사용량을 비교할 의미가 있습니다. 짧은 웹 요청은 도메인 조회와 핸드셰이크에 시간이 더 걸릴 수 있고, 지속적인 다운로드는 대역폭, 혼잡도, 암호화 처리량의 영향을 더 받습니다. 부하 유형에 따라 결과가 달라질 수 있습니다. 일반 사용자는 설정 제공자가 꾸준히 관리하고 클라이언트가 완전히 인식하며 필드를 수동으로 보완할 필요가 없는 조합을 우선 선택하세요. 프로토콜 선택의 목적은 설정의 모호함을 줄이는 것이지, 모든 항목에서 가장 짧거나 최신처럼 보이는 이름을 고르는 것이 아닙니다.

Trojan과 SS: 비밀번호 외에 확인할 사항

Trojan은 TLS 설정 전체가 중요합니다

Trojan은 일반적으로 TLS 연결 안에서 인증과 프록시 요청을 처리하고, 검증된 TLS 구현으로 전송을 보호합니다. 클라이언트에는 보통 서버 주소, 포트, 비밀번호, 서버 이름이 필요하지만 항목이 적다고 검증 과정까지 간단한 것은 아닙니다. 인증서에 해당 이름이 포함되어 있는지, 유효 기간이 지나지 않았는지, 서버가 전체 인증서 체인을 제공하는지에 따라 연결이 달라집니다. 비밀번호가 맞는데 인증서 검증에 실패했다면 비밀번호 계층의 문제가 아닙니다. 보안 연결이 성립하지 않은 것인지, 연결은 됐지만 인증에 실패한 것인지 먼저 구분한 뒤 점검할 항목을 정하세요.

서버 주소와 서버 이름 표시(SNI)는 서로 다를 수 있습니다. 주소는 연결할 대상을 정하고, 서버 이름은 TLS 핸드셰이크와 인증서 이름 검증에 쓰입니다. 설정 제공자가 IP 주소와 도메인 이름을 함께 줬다면 브라우저에서 해당 IP로 익숙한 페이지가 열리지 않는다는 이유만으로 프록시 설정이 잘못됐다고 판단하지 마세요. 프록시 서버의 응답 방식은 일반 웹사이트와 다를 수 있습니다. 원래 값을 유지하고 클라이언트 로그에서 핸드셰이크 결과를 확인한 뒤 제공자에게 필요한 서버 이름을 물어보세요. 흔히 쓰이는 도메인을 임의로 입력해서는 안 됩니다.

인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 서버 신원 확인이 약해질 뿐 아니라 시스템 시간 오류, 잘못된 이름, 서버 인증서 구성 문제를 가릴 수 있습니다. 한 기기에서만 실패한다면 시스템 시간과 신뢰 설정을 먼저 비교하고, 모든 기기에서 실패한다면 서버 설정을 우선 확인하세요. 핸드셰이크 중에는 애플리케이션 계층 프로토콜 협상이 필요할 수도 있습니다. 클라이언트와 서버가 값을 지정하도록 요구한다면 그에 맞게 입력하세요. ‘옵션이 많을수록 호환성이 높다’며 값을 전부 추가해서는 안 됩니다.

Shadowsocks는 암호화 방식과 키가 서로 맞아야 합니다

Shadowsocks는 클라이언트 화면에서 SS로 줄여 표시되는 경우가 많으며, 비교적 간결한 암호화 프록시 방식으로 트래픽을 처리합니다. 실제 호환성은 비밀번호뿐 아니라 암호화 방식과 프로토콜 세대에도 달려 있습니다. 기존 AEAD 방식과 최신 방식은 키 형식, 인증 처리, 코어 지원 여부가 다를 수 있습니다. 이름이 같은 방식을 선택하고 아무 문자열이나 입력한다고 해서 올바른 설정이 되는 것은 아닙니다. 제공자가 지정한 암호화 방식과 키를 한 세트로 취급하고, 비밀번호만 복사한 뒤 취향에 따라 방식을 바꾸지 마세요.

일부 최신 방식은 일반 비밀번호가 아니라 정해진 길이와 인코딩의 키를 요구합니다. 클라이언트의 ‘비밀번호’ 표시는 공통 인터페이스용 이름일 뿐, 임의의 문자열을 모두 허용한다는 뜻은 아닙니다. 가져오기에 실패했다면 메신저에서 내용이 잘리지 않았는지, 특수 문자가 제대로 인코딩됐는지, 현재 코어가 해당 방식을 구현하는지 확인하세요. 끝 문자를 지우거나 다른 문자로 바꾸고 재인코딩하면 올바른 키가 손상될 수 있습니다. 클라이언트가 설정을 저장할 수 있어도 코어가 이를 반드시 받아들이는 것은 아니므로 시작 시 설정 검사 결과를 확인하는 편이 낫습니다.

플러그인, 전송 방식, 프로토콜 기능은 별개입니다

SS 공유 링크에 플러그인 매개변수가 포함되어 있다면 현재 클라이언트가 해당 플러그인 방식을 인식하고 실행할 수 있는지 확인해야 합니다. 코어가 특정 암호화 방식을 기본 지원하는 것과 클라이언트가 외부 플러그인을 호출하는 것은 별개의 기능입니다. 플러그인을 계속 바꿔 가며 시험하는 방법은 권장하지 않습니다. 제공자에게 기본 프로토콜 연결이 필요한지, 특정 캡슐화가 적용된 조합이 필요한지 먼저 확인하세요. 클라이언트에서 지원하지 않는다면 전송 경로 항목에 플러그인 이름을 넣지 말고 양쪽에서 지원하는 설정을 선택하세요. 이름이 비슷한 필드라도 역할은 다를 수 있습니다.

두 프로토콜의 실제 사용 범위도 다릅니다. TCP 웹 접속이 정상이라고 해서 UDP 앱도 작동한다고 볼 수 없습니다. UDP 전달은 서버 기능과 라우팅, 로컬 연결 방식에도 영향을 받습니다. 먼저 일반 웹사이트로 기본 연결을 확인하고, 필요한 앱은 별도로 테스트하세요. 일상 서비스에 안정적으로 접속하는 것이 목적이라면 출처가 분명한 설정 하나를 유지하는 편이 좋습니다. 특정 앱의 네트워크 동작까지 지원해야 한다면 UDP, 도메인 조회, 시스템 트래픽 처리 범위를 확인 항목에 넣으세요. 모든 차이를 프로토콜 속도 탓으로 돌리지 마세요.

REALITY: 보안 계층과 매개변수의 관계

REALITY는 별도의 프록시 프로토콜이 아닙니다

REALITY는 VLESS와 함께 쓰이는 경우가 많지만 두 기능의 역할은 다릅니다. VLESS는 프록시 인증과 요청을 처리하고, REALITY는 외부 보안 핸드셰이크를 담당합니다. TLS 관련 메커니즘을 바탕으로 자체 인증과 핸드셰이크 처리를 적용하며, 일반 웹사이트의 인증서 구성과 동일하지 않습니다. 이 차이를 알면 ‘서버 유형 VLESS’와 ‘보안 계층 REALITY’를 중복 설정으로 오해하지 않을 수 있습니다. 다른 프로토콜 설정의 보안 옵션을 REALITY로 바꾸면 서버가 자동으로 받아들일 것이라고 기대해서도 안 됩니다. 조합은 클라이언트와 서버 양쪽에서 지원해야 합니다.

일반적인 REALITY 클라이언트 설정에는 연결 주소, 서버 이름, 공개 키 매개변수, 짧은 ID, 클라이언트 지문이 포함되며 흐름 제어 설정이 추가될 수도 있습니다. 각 항목은 서버 설정과 대응합니다. 공개 키 매개변수는 클라이언트 측 인증 계산에 사용하며 서버 개인 키를 입력하는 곳이 아닙니다. 서버 개인 키를 구독이나 공유 링크에 넣어서는 안 됩니다. 버전에 따라 화면의 항목 이름이 달라질 수 있으므로 용도와 제공자 안내를 기준으로 확인하세요. ‘키’라는 단어만 보고 같은 내용을 관련 입력란에 모두 붙여 넣지 마세요.

서버 이름, 공개 키, 짧은 ID

서버 이름은 핸드셰이크에 사용되며 서버에서 허용한 설정과 일치해야 합니다. 임의로 입력하는 메모도 아니고 실제 연결 주소와 반드시 같은 것도 아닙니다. 서버에는 핸드셰이크 대상 등 별도의 설정이 있으며 클라이언트에서 일방적으로 바꿀 수 없습니다. 완성된 설정을 받았다면 클라이언트가 필요한 값을 제대로 보존했는지 확인하세요. 이름을 보고 대상 사이트를 추측해 다른 도메인으로 바꾸지 마세요. 바꾼 도메인이 열리더라도 현재 REALITY 서버 설정과 일치한다는 뜻은 아닙니다.

짧은 ID는 보통 16진수 문자열로 표시되며 서버와 구현이 요구하는 형식에 맞아야 합니다. 빈 값을 허용하는지는 서버 설정에 따라 달라지므로 비어 있으면 무조건 누락된 것이라고 볼 수 없습니다. 직접 입력할 때는 문자가 유효한지, 길이가 조건에 맞는지 확인하고 공백이나 전각 문자가 섞이지 않도록 하세요. 공개 키도 원래 값 그대로 가져오고 편집기에서 자동으로 삽입한 줄바꿈이 함께 저장되지 않도록 주의해야 합니다. 구독 갱신 전에는 작동했는데 갱신 후 실패한다면 먼저 인증 관련 항목이 바뀌었는지, 이전 수동 설정이 남아 있는지 비교하세요.

지문, 흐름 제어, 문제 해결 순서

클라이언트 지문은 일반적으로 코어의 핸드셰이크 구현 옵션을 통해 적용됩니다. 화면에 다양한 이름이 표시된다고 해서 현재 실행 중인 코어가 모두 지원하는 것은 아닙니다. ‘지원하지 않는 지문’ 또는 초기화 오류가 발생하면 실제 코어와 설정 출처부터 확인하세요. 흐름 제어도 별도로 봐야 합니다. REALITY의 다른 이름이 아니며 REALITY를 켰다고 임의로 입력할 수 있는 것도 아닙니다. 조합마다 지원 범위가 다르므로 특히 전송 방식을 바꿀 때는 흐름 제어가 여전히 유효한지 확인하세요. 이전 설정의 고급 옵션을 통째로 복사하지 마세요.

문제 해결은 세 단계로 나눌 수 있습니다. 첫째, 지정된 주소와 포트에 연결할 수 있는지 확인합니다. 둘째, 보안 핸드셰이크가 완료되는지 살펴보고 서버 이름, 공개 키, 짧은 ID, 지문을 확인합니다. 셋째, 사용자 인증과 흐름 제어, 실제 프록시 요청을 점검합니다. 같은 핸드셰이크 오류도 여러 원인으로 발생할 수 있으므로 한 줄짜리 오류 메시지만 보고 공개 키가 잘못됐다고 단정하지 마세요. 먼저 다른 구독 그룹에 같은 이름의 항목이 사용되고 있지 않은지 확인하고, 변경 사항을 코어가 다시 불러왔는지 확인한 다음 오류 시각과 연결 시도를 대조하세요.

REALITY를 사용하려면 설정 제공자가 해당 구성을 관리하고 현재 클라이언트가 설정을 모두 가져올 수 있어야 합니다. 일반 TLS의 인증서 옵션을 전부 그대로 옮겨야 하는 것도 아니고, 매개변수 출처를 확인하지 않아도 된다는 뜻도 아닙니다. v2rayN 또는 v2rayNG에서는 정상적으로 가져온 원래 값을 우선 유지하세요. 가져오기 도구가 보안 계층을 인식하지 못한다고 일반 TLS로 바꿔 화면을 채우지 마세요. 먼저 클라이언트와 코어의 호환성을 해결한 뒤 양쪽에서 지원하는 다른 설정으로 바꿀지 검토하세요.

V2Fly와 Xray: 클라이언트 뒤에서 작동하는 코어

그래픽 인터페이스와 프록시 코어는 서로 다른 프로젝트입니다

이 생태계를 이해하려면 Project V부터 살펴보면 됩니다. V2Fly 커뮤니티는 V2Ray 코어 개발과 유지보수를 이어 왔으며, Xray는 관련 코드 기반에서 갈라져 나와 자체 기능과 설정 세부 사항을 발전시켰습니다. 공통 기반 덕분에 기본 개념과 일부 설정 구조는 비슷하지만 새 기능이 항상 함께 추가되는 것은 아닙니다. 두 코어를 다운로드 주소만 다른 기능이 완전히 같은 파일로 이해해서는 안 됩니다. 화면에 ‘V2Ray’라고 표시된다는 이유만으로 실제 실행 중인 코어를 판단할 수도 없습니다. 실행 상태와 로그에 표시된 코어 이름을 확인하는 편이 정확합니다.

v2rayN은 데스크톱용 그래픽 클라이언트로 서버 목록, 구독 관리, 프록시 모드, 코어 실행 등을 담당합니다. 실제 프로토콜 연결은 호출된 코어가 처리합니다. v2rayNG는 Android에서 흔히 사용하는 Xray 코어 클라이언트이며, v2flyNG는 V2Fly 코어를 사용하려는 경우에 적합합니다. 세 클라이언트는 서로 다른 프록시 프로토콜이 아닙니다. 모바일에서는 데스크톱처럼 다른 코어 파일을 앱에 임의로 넣는다고 같은 기능을 사용할 수 있는 것도 아닙니다. 각 앱의 빌드와 지원 범위를 기준으로 선택하세요.

구조가 비슷해도 설정을 마음대로 바꿔 쓸 수는 없습니다

두 코어 모두 인바운드, 아웃바운드, 라우팅, DNS 등의 개념을 사용하고 기본 항목 일부도 비슷하므로 간단한 설정은 어느 정도 옮길 수 있습니다. 하지만 REALITY, 특정 흐름 제어, 새로운 전송 구현, 확장 매개변수가 포함되어 있다면 현재 코어가 지원하는지 확인해야 합니다. JSON을 읽을 수 있다고 해서 안에 든 모든 옵션을 이해하는 것은 아닙니다. 차이에 따라 시작할 때 오류가 날 수도 있고, 클라이언트가 변환할 수도 있으며, 실제 연결을 시도한 뒤에야 문제가 드러날 수도 있습니다. 설정 저장은 첫 단계일 뿐, 호환성이 확인된 것은 아닙니다.

클라이언트 계층에서 설정을 변환할 수도 있다는 점도 유의하세요. 그래픽 클라이언트는 자체 형식으로 항목을 저장한 뒤 실행 시 코어 설정을 생성하는 경우가 많습니다. 구독에서 보이는 값이 최종 파일에 그대로 들어간다고 보장할 수 없습니다. 사용자 지정 설정 모드는 그래픽 인터페이스의 라우팅과 DNS 생성 로직 일부를 건너뛸 수도 있습니다. 화면의 옵션을 바꿨는데 동작이 달라지지 않는다면 해당 항목이 사용자 지정 설정을 사용하는지, 그 모드에서 전역 설정을 적용하는지 먼저 확인하세요. 같은 기능의 스위치를 계속 추가하면 적용되지 않는 설정만 늘어날 수 있습니다.

마이그레이션 전후 비교할 기준을 남겨 두세요

코어를 바꾸기 전에 정상 작동이 확인된 클라이언트 설정을 저장하고 프로토콜, 전송 방식, 보안 계층, DNS, 라우팅 모드를 기록하세요. 새 코어를 처음 실행할 때는 양쪽에서 명확히 지원하는 단순한 설정으로 기본 연결을 확인한 뒤 사용자 지정 라우팅을 복구하는 편이 좋습니다. 복잡한 규칙과 실험적인 전송 방식, 여러 고급 항목을 한꺼번에 옮기면 실패 원인을 구분하기 어렵습니다. 코어 시작 실패를 원격 서버 문제로 오해하지 마세요. 설정 문법이나 지원하지 않는 매개변수 때문에 코어가 수신 대기 상태에 들어가지 못했을 수도 있습니다.

버전별 지원 여부는 실제 설치 환경을 기준으로 확인하되 모든 상황에 영구적으로 적용되는 지원표를 만들 필요는 없습니다. 클라이언트, 코어, 구독 형식은 서로 다른 시점에 업데이트됩니다. 최신 코어가 어떤 옵션을 지원해도 현재 클라이언트에서 가져오기를 지원하지 않을 수 있습니다. 반대로 클라이언트 화면에 항목이 먼저 표시되더라도 실행 파일이 이를 구현했다고 보장할 수 없습니다. 호환성 경계에서 문제가 생기면 ‘최신 버전에서 안 된다’고만 말하기보다 클라이언트 이름, 실제 코어 이름, 프로토콜 조합, 오류 요약을 함께 제시해야 원인을 찾기 쉽습니다.

일상적인 선택은 간단하게 할 수 있습니다. 데스크톱에서는 v2rayN을 사용하고 Android에서는 설정에 따라 v2rayNG 또는 v2flyNG를 선택하세요. 이름이 비슷하다는 이유로 고급 설정을 다른 코어로 옮기지 마세요. 오픈소스는 코드와 유지보수 과정을 살펴볼 수 있다는 뜻이지, 모든 파생 프로젝트의 동작이 같다는 뜻은 아닙니다. 프로젝트 관계는 Project V·V2Fly·Xray 생태계 살펴보기에서, 플랫폼별 사용 방식은 세 클라이언트 비교에서 확인하세요.

연결 속도, 리소스 사용량, Android 배터리

‘빠르다’를 단계별로 나눠 보세요

연결 속도는 여러 요소로 나눠 볼 수 있습니다. 도메인 조회 시간, 서버 연결 시간, 보안 핸드셰이크 시간, 첫 응답까지 걸리는 시간, 지속 전송 처리량입니다. 프로토콜은 이 중 일부에 영향을 주지만 회선과 서버가 더 큰 영향을 미치는 경우가 많습니다. 웹페이지가 빨리 열려도 다운로드 속도가 빠르다고 볼 수 없으며, 다운로드 처리량이 높아도 짧은 연결의 응답이 빠른 것은 아닙니다. 프로토콜을 비교할 때는 어떤 단계를 측정했는지 먼저 밝히세요. 서로 다른 지표를 하나의 ‘지연 시간’ 숫자로 묶으면 지나치게 단순한 결론으로 이어질 수 있습니다.

결과를 해석할 수 있도록 기기, 네트워크, 서버 위치, 접속 대상, 테스트 시간을 가능한 한 동일하게 유지하세요. 테스트 전에는 구독 자동 갱신, 백그라운드 대용량 전송, 잦은 상태 확인을 중지하고 라우팅 모드와 DNS 정책도 똑같이 설정합니다. 한 설정은 오전에, 다른 설정은 저녁에 따로 측정하지 말고 두 설정을 번갈아 테스트하세요. 연결 재사용, 도메인 캐시, TLS 세션 재개가 이후 결과를 바꿀 수 있으므로 첫 요청과 그다음 요청을 모두 확인해야 합니다. 재현할 수 없는 소수점 수치보다 전반적인 추세를 기록하는 것으로 충분합니다.

CPU·메모리 사용량과 연결 재사용은 낮을수록 좋은 게 아닙니다

암호화 연산, 데이터 복사, 전송 캡슐화, 연결 수는 모두 리소스를 사용합니다. 특정 암호화 기능을 하드웨어로 가속할 수 있는지가 프로토콜 헤더 크기보다 중요할 수도 있습니다. 외부 계층에 TLS를 사용할 때 내부 암호화 여부도 작업량에 영향을 주지만, 프로토콜이 요구하는 보호 기능을 임의로 끄면 안 됩니다. 메모리 사용량은 활성 연결, 버퍼, DNS 캐시, 규칙 집합에 따라 늘어날 수 있습니다. 프로세스 사용량이 잠깐 증가하면 연결이 종료된 뒤 줄어드는지 먼저 확인하세요. 정상적인 캐시를 메모리 누수로 오해하거나 유휴 상태의 화면만 보고 코어를 비교하지 마세요.

연결 재사용은 새 연결을 반복해서 만드는 오버헤드를 줄일 수 있지만 여러 요청이 같은 연결을 공유하면서 혼잡이나 오류의 영향을 함께 받을 수도 있습니다. 재사용을 켰을 때 더 빨라지는지는 구현, 전송 방식, 앱 부하에 따라 다르므로 모든 설정에 통하는 최적 스위치는 없습니다. 특정 흐름 제어나 전송 조합에서는 재사용 방식이 제한될 수도 있습니다. 안정적으로 작동하는 설정은 기본값을 유지하고 반복해서 확인되는 짧은 연결 문제에 한해 한 항목씩 비교하세요. 재사용, 동시 연결 수, 버퍼 크기를 한꺼번에 늘린 뒤 짧은 시간의 변화를 특정 항목의 효과라고 단정하지 마세요.

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

모바일 네트워크의 배터리 소모는 무선 통신이 활성 상태인 시간과 큰 관련이 있습니다. 잦은 연결 유지 신호, 반복되는 재연결, 지속적인 상태 확인, 백그라운드 앱의 짧은 요청은 데이터가 적어도 네트워크를 계속 깨워 배터리를 소모할 수 있습니다. 화면이 꺼진 뒤 시스템의 백그라운드 제한으로 앱이 절전 상태에 들어갔다가 깨어나면 다시 연결할 수도 있습니다. 따라서 긴 다운로드에서 전력 소모가 적은 프로토콜이 대기 상태에서도 밤새 더 효율적이라고 단정할 수 없습니다. 화면을 켜고 사용할 때와 화면을 끄고 대기할 때를 나눠 관찰하고 앱 사용 습관과 네트워크 유형을 비슷하게 유지하세요. 상황 차이를 프로토콜 탓으로 돌리지 마세요.

가상 네트워크 어댑터의 트래픽 처리 범위, 앱별 분할 터널링, DNS 조회도 모바일 부하를 바꿀 수 있습니다. 전체 트래픽을 처리하면 더 많은 백그라운드 연결이 코어를 통과할 수 있고 앱이나 규칙에 따라 분리하면 경로와 조회 횟수가 달라집니다. 라우팅 규칙이 지나치게 넓거나 DNS가 반복해서 실패하면 요청과 재시도가 늘어날 수 있습니다. 배터리가 빨리 닳으면 먼저 오류가 계속 발생하는지, 네트워크가 자주 전환되는지, 연결 확인 간격이 지나치게 짧은지 살펴본 다음 프로토콜을 확인하세요. 백그라운드 배터리 소모를 줄이려고 클라이언트의 백그라운드 실행을 전부 막으면 시스템에는 프록시 연결이 남아 있지만 실제 연결은 중단되는 상황이 생길 수 있습니다.

다음 순서로 확인해 보세요. 먼저 설정을 안정화하고 불필요하게 자주 실행되는 테스트를 중지한 뒤 백그라운드 실행 권한을 확인합니다. 마지막으로 프로토콜 조합을 비교하세요. 일반 사용 시간과 대기 시간을 모두 포함하고 연결이 끊겼다가 재시도되는지 살펴보세요. 특정 앱에서만 배터리를 많이 사용한다면 코어를 바로 바꾸기보다 해당 앱의 백그라운드 동작도 확인해야 합니다. 연결은 되어 있는데 웹페이지가 열리지 않는다면 연결 후 웹페이지가 열리지 않을 때 확인할 항목을 참고하세요. 접속 실패로 재시도가 계속되면 배터리 측정 결과도 달라질 수 있습니다.

구독 형식: 가져온 뒤에도 확인할 사항

공유 링크, 구독 목록, 전체 설정 파일

공유 링크 하나는 보통 서버 한 곳의 정보를 설명하고 구독 주소는 여러 서버 항목이나 클라이언트가 인식하는 콘텐츠를 반환합니다. 전체 코어 설정은 또 다른 형식으로 로컬 인바운드, 여러 아웃바운드, DNS, 라우팅을 함께 정의할 수 있습니다. 파일 확장자만 바꾸면 서로 전환되는 같은 형식이 아닙니다. 클라이언트의 ‘클립보드에서 가져오기’와 ‘구독 주소 추가’도 서로 다른 데이터를 처리합니다. 구독 URL을 단일 서버 링크처럼 가져오면 형식을 인식할 수 없다는 메시지가 표시될 수 있고, 코어 JSON 전체를 구독 주소 입력란에 넣어도 온라인 구독으로 바뀌지 않습니다.

프로토콜별 공유 링크는 항목을 인코딩하는 방식이 다르고 일부는 오래된 형식과 차이가 있습니다. 메모에 들어간 한국어와 특수문자, 공백은 올바르게 인코딩해야 합니다. 일부 내용은 Base64로 표현되지만 이는 구독 내용을 숨기는 암호화가 아닙니다. 링크를 복사할 수 있더라도 메신저로 전달하는 과정에서 원본이 유지된다고 보장할 수 없습니다. 가져온 항목 수가 예상과 다르면 원본에서 다시 복사해 설명 문구, 줄바꿈, 끝의 문장 부호가 섞이지 않았는지 확인한 뒤 클라이언트의 파싱 메시지를 살펴보세요. 낯선 변환 도구에 내용을 바로 넣지 마세요.

항목 수가 같아도 설정 항목이 빠졌을 수 있습니다

최신 보안 계층, 흐름 제어, 전송 매개변수가 오래된 가져오기 기능에서 무시될 수 있습니다. 서버 이름과 주소, 포트가 표시되어 목록은 정상처럼 보여도 중요한 항목이 저장되지 않았을 수 있습니다. REALITY 조합은 가져온 뒤 항목 하나를 골라 프로토콜 유형, 보안 계층, 서버 이름, 공개 키 매개변수, 짧은 ID, 흐름 제어가 원래 설정과 일치하는지 확인하세요. WebSocket이나 gRPC에서는 경로, 요청 헤더, 서비스 이름을 중점적으로 확인하면 됩니다. 목록에 몇 개가 표시되는지만 보고 구독 형식이 완전히 호환된다고 판단하지 마세요.

구독 갱신, 중복 항목, 수동 수정의 처리 방식은 클라이언트마다 다를 수 있습니다. 일부 수동 변경 사항은 다음 갱신 때 덮어써지고, 일부 재정의 설정은 새 항목에도 계속 적용될 수 있습니다. 구독 출처별 그룹과 로컬 테스트 설정을 분리해 관리하고, 시험할 항목은 복사한 뒤 한 번에 하나씩 변경하세요. 같은 구독 항목을 장기적인 수동 설정처럼 계속 수정하면 제공자가 서버 매개변수를 바꾼 뒤 기존 재정의 값과 새 데이터가 섞여 각 항목의 출처를 파악하기 어렵습니다.

라우팅 설정은 서버 항목과 자동으로 함께 옮겨지지 않습니다

클라이언트를 바꾸면서 서버 항목을 가져와도 기존 DNS, 라우팅, 앱별 분할 터널링, 프록시 모드까지 함께 이동하는 것은 아닙니다. 기본 연결이 성공한 뒤 기본 아웃바운드와 도메인 처리 방식을 다시 확인해야 합니다. 아래 코드는 일반적인 코어 설정의 라우팅 구조를 보여주는 예로, 루프백 주소만 direct라는 아웃바운드로 보냅니다. 전체 설정이 아니므로 단독으로 실행할 수 없으며 완전한 파일에 해당 아웃바운드 태그가 이미 정의되어 있어야 합니다. 이처럼 짧은 예시는 항목 간 관계를 설명하는 데 적합하지만 클라이언트가 생성한 전체 설정 파일을 대체할 수는 없습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "::1/128"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs는 해당 정책으로 라우팅을 판단할 때 도메인을 IP로 변환하지 않는다는 뜻입니다. 클라이언트 전체에서 DNS 조회를 중단한다거나 요청이 절대 해석되지 않는다는 의미는 아닙니다. 다른 도메인 정책은 서로 다른 조건에서 조회와 IP 규칙 판정에 관여할 수 있으므로 실제 동작은 코어와 DNS 설정을 함께 확인해야 합니다. 마이그레이션 후 라우팅 결과가 달라졌다면 옵션 이름만 보고 경로를 추측하지 말고 요청이 코어에 들어올 때 도메인과 IP 중 무엇을 포함하는지 확인한 뒤 도메인 규칙, IP 규칙, 최종 기본 아웃바운드를 살펴보세요.

구독 갱신 실패와 서버 연결 불가도 구분해야 합니다. 전자는 설정을 가져오고 파싱하는 단계의 문제이고, 후자는 실제 연결 단계에서 발생합니다. 기존 항목을 계속 사용할 수 있다면 갱신 한 번 실패했다고 그룹 전체를 삭제하지 마세요. 먼저 갱신 요청이 성공했는지, 응답이 유효한 구독인지 확인한 뒤 형식을 점검하세요. 빈 목록 등 흔한 문제는 FAQ에서 확인할 수 있습니다. 파싱과 분할 라우팅을 함께 다뤄야 한다면 V2Ray DNS 분할 조회 설정을 참고하세요. 설정 출처 문제를 해결하려고 프로토콜을 무작정 바꾸지 마세요.

사용 환경에 맞게 선택하기: 요구 사항부터 설정까지

데스크톱과 모바일에서 공통으로 지원되는 기능부터 확인하세요

데스크톱에서는 먼저 v2rayN을 선택한 다음 운영체제와 프로세서 아키텍처에 맞는 다운로드 항목을 고르세요. 클라이언트를 설치한 뒤에는 설정 제공자가 명확히 지원하는 프로토콜 조합을 우선 사용하고 ‘기능을 모두 갖추기 위해’ 고급 옵션을 전부 켤 필요는 없습니다. 안정적으로 사용하는 VMess, Trojan, SS 설정이 있다면 그대로 써도 됩니다. VLESS와 REALITY 조합을 받았다면 실제 코어와 가져온 항목을 먼저 확인하세요. 우선 클라이언트, 코어, 서버가 공통으로 지원하는 범위에서 작동하는지 확인하고, 그다음 사용 환경에 맞는 리소스 최적화를 검토하세요.

Android에서 설정에 Xray의 특정 기능이 필요하다면 먼저 v2rayNG를 확인하세요. V2Fly 설정과 유지보수 경로를 명확히 사용한다면 v2flyNG를 고려할 수 있습니다. 두 앱을 동시에 켜서 비교하지 마세요. 시스템 VPN 트래픽 처리가 서로 간섭할 수 있어 앱 전환과 연결 복구가 측정 결과에 섞입니다. 백그라운드 사용을 위해서는 시스템 권한과 배터리 관리가 필요한 실행 방식을 허용하는지 먼저 확인한 뒤 프로토콜을 비교하세요. 앱별 분할 터널링이 필요하다면 대상 앱을 확인하고 브라우저 테스트 트래픽과 해당 앱 트래픽이 실제로 같은 경로를 거치는지도 살펴보세요.

이름이 아니라 실제 부하를 기준으로 테스트하세요

일반 웹과 메신저는 짧은 요청이 많으므로 DNS 조회, 연결 설정, 절전 후 복구를 살펴보세요. 지속적인 다운로드는 안정적인 처리량, 기기 발열, 장시간 연결 유지가 중요합니다. UDP를 사용하는 앱은 해당 경로가 작동하는지 별도로 확인해야 합니다. 각 환경에서 먼저 정상 작동이 확인된 기본 설정으로 기준을 만든 다음 다른 조합과 비교하세요. 두 설정이 서로 다른 서버를 사용한다면 결과는 해당 서비스 조합의 종합 성능만 보여줍니다. 특정 프로토콜 자체가 더 우수하다는 증거는 아닙니다. 서버 조건을 맞출 수 없다면 속도 순위보다 호환성과 유지보수 품질을 우선하세요.

여러 기기에서 설정을 동기화한다는 것은 보통 각 클라이언트가 같은 구독을 사용하는 것이지 데스크톱 설정 전체를 휴대전화에 복사한다는 뜻이 아닙니다. 로컬 포트, 시스템 트래픽 처리 방식, 앱별 분할 터널링, 백그라운드 권한은 기기마다 따로 설정해야 합니다. 서버 출처와 그룹 이름은 통일하되 해당 기기에 맞지 않는 시스템 프록시 항목까지 동기화하지 마세요. 이전을 마치면 각 기기에서 웹 요청, 필요한 UDP 앱, DNS 동작을 확인하세요. 같은 구독을 사용해도 모든 기기의 네트워크 동작이 같아지는 것은 아닙니다.

되돌릴 수 있는 확인 절차를 마련하세요

실제 작업은 네 단계로 진행할 수 있습니다. 첫 번째 단계에서는 설정 출처와 항목을 확인해 링크가 온전한지, 인증 매개변수가 서로 맞는지, 전송 방식과 보안 계층이 일치하는지 살펴봅니다. 두 번째 단계에서는 클라이언트가 올바른 코어를 호출하는지, 코어가 정상적으로 시작하는지, 로컬 연결이 작동하는지 확인합니다. 세 번째 단계에서는 라우팅을 단순하게 유지하고 DNS와 프록시 모드를 동시에 바꾸지 않은 채 기본 접속을 검증합니다. 네 번째 단계에서 앱별 분할 터널링, 사용자 지정 규칙, 선택적 최적화를 적용합니다. 각 단계마다 정상 작동이 확인된 상태를 보관하고 문제가 생기면 직전 단계로 되돌리세요. 이후 최적화에서 생긴 차이를 프로토콜 자체의 문제로 오해하지 않도록 해야 합니다.

실패하면 오류가 로컬에서 발생했는지 원격에서 발생했는지도 구분해야 합니다. 코어 시작 오류, 포트 충돌, 시스템 프록시 설정 잔존은 로컬 실행 환경 문제입니다. 연결 시간 초과, 핸드셰이크 실패, 인증 거부는 네트워크와 서버 방향으로 확인해야 합니다. 웹페이지는 열리지만 예상과 다른 방식으로 조회된다면 프로토콜 인증이 아니라 DNS와 라우팅 문제일 수 있습니다. DNS 누수 검사와 설정 방법에서 조회 경로를 확인할 수 있습니다. 검사 결과는 현재 네트워크와 클라이언트 모드를 고려해 해석해야 하며, 한 페이지에 표시된 내용만으로 전체 상황을 단정할 수 없습니다.

마지막으로 간단한 유지보수 기록을 남기세요. 클라이언트와 코어 이름, 프로토콜·전송 조합, 특수 보안 항목의 누락 여부, 라우팅 모드, 마지막으로 정상 작동이 확인된 환경이면 충분합니다. 문제를 기록할 때 인증 정보는 숨기고 원인을 찾는 데 필요한 구조와 오류 요약만 남기세요. 설정 제공자가 매개변수를 바꾸면 구독을 갱신하고 항목을 확인한 뒤 로컬 재정의를 조정하세요. 이 가이드는 판단 기준을 설명합니다. 가져오기와 연결 절차를 다시 진행하려면 빠른 시작 가이드로 돌아가 기본 순서에 따라 진행하세요. 고급 설정을 하나씩 무작정 바꿀 필요는 없습니다.