V2Ray 프로토콜과
코어 기술 참고

01 / CONFIGURATION LAYERS

프로토콜·전송 방식·보안 계층

노드 이름만으로는 설정을 알 수 없습니다

클라이언트 목록의 노드 하나는 함께 작동하는 여러 설정값의 조합이지, 프로토콜 이름 하나만을 뜻하지 않습니다. 프로토콜은 인증과 프록시 요청의 표현 방식을 정하고, 전송 방식은 데이터를 서버로 전달하며, 보안 계층은 연결을 보호하고 상대의 신원을 확인합니다. 주소, 포트, 사용자 식별자는 연결 조건이고 경로, 요청 헤더, 서버 이름은 서로 다른 계층에 속할 수 있습니다. 어떤 설정을 선택할 때는 약어만 보고 속도나 호환성을 판단하지 말고 전체 매개변수를 확인하세요. 사용 가능한 조합은 서버가 결정하며, 클라이언트는 지원 범위 안에서 설정을 정확히 재현할 뿐입니다.

VLESS를 예로 들면 같은 프로토콜도 서로 다른 전송 방식과 보안 설정을 조합할 수 있습니다. 일반 TCP 전송 설정을 WebSocket으로 바꾸고 그대로 연결할 수는 없습니다. 서버에도 그에 맞는 수신 방식과 경로 처리가 필요하기 때문입니다. TLS도 아무 노드에나 설정 하나를 추가한다고 사용할 수 있는 것은 아닙니다. 서버가 해당 핸드셰이크를 제공해야 하고 인증서 이름이 일치해야 하며, 클라이언트가 인증서 발급 체인을 신뢰해야 합니다. 프로토콜이 같더라도 다른 설정이 달라지면 실제 연결 과정은 완전히 달라질 수 있습니다.

주소, 서버 이름, 요청 대상을 구분하세요

서버 주소는 클라이언트가 연결할 대상을 지정하며 도메인 이름이나 IP 주소를 사용할 수 있습니다. TLS 서버 이름은 일반적으로 SNI 전송과 인증서 이름 검증에 사용됩니다. WebSocket의 Host는 애플리케이션 계층의 요청 헤더입니다. 배포 방식에 따라 셋이 같을 수도, 서로 다르게 지정될 수도 있습니다. 모두 도메인처럼 보인다고 해서 같은 값을 복사하지 마세요. 문제를 확인할 때는 먼저 주소 확인, 포트 연결 여부, 핸드셰이크와 인증 순으로 살펴보고 마지막으로 대상 웹사이트 접속을 확인하세요. 이 순서대로 점검하면 주소 확인 문제를 프로토콜 문제로 오해하는 일을 줄일 수 있습니다.

트래픽 유입 방식과 아웃바운드 프로토콜은 별개입니다

시스템 프록시는 시스템이나 앱에 로컬 프록시 연결 지점을 제공하며, 관련 설정을 따르는 프로그램만 이를 사용합니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아들이므로 일반적으로 더 넓은 범위를 처리하지만, 라우팅·권한·제외 항목에도 영향을 받습니다. 둘 다 원격 서버의 프로토콜을 자동으로 바꾸지는 않습니다. 노드를 가져오는 데 성공했는데 특정 프로그램이 접속하지 못한다면, 먼저 해당 프로그램의 트래픽이 실제로 클라이언트를 거치는지 확인한 다음 아웃바운드 로그를 살펴보세요. VLESS를 VMess로 바꿔도 시스템 프록시를 우회하는 앱 문제는 해결되지 않습니다.

라우팅과 DNS는 또 다른 계층입니다. 라우팅은 트래픽을 직접 연결, 프록시, 차단 등의 아웃바운드로 보냅니다. DNS는 이름을 확인하고 관련 정책을 적용합니다. 웹사이트가 직접 연결된다고 해서 노드 인증에 실패한 것은 아니며, 도메인 이름을 확인할 수 없다고 TLS 설정이 잘못되었다고 단정할 수도 없습니다. 문제를 기록할 때는 클라이언트, 코어, 프로토콜, 전송 방식, 보안 계층, 트래픽 유입 방식을 함께 적어 두세요. 로그를 공유하기 전에는 구독 주소, 사용자 식별자, 인증 정보를 삭제하고 오류 유형과 발생 순서만 남기면 됩니다.

가져오기 화면에서 성공으로 표시되는 것은 대개 텍스트를 파싱해 목록에 추가했다는 의미일 뿐, 서버가 연결을 받아들였다는 뜻은 아닙니다. 실제로 연결하려면 코어 실행, 세션 생성, 대상에 접속하는 단계까지 확인해야 합니다. 전체 설정 방법은 v2rayN 설정 가이드에서 확인하세요. 다음 장에서는 각 계층의 선택 기준을 설명합니다.

02 / VMESS & VLESS

VMess와 VLESS의 설계 차이

VMess: 프로토콜에 인증 및 암호화 기능 포함

VMess는 Project V 생태계에서 비교적 일찍 자리 잡은 프록시 프로토콜로, 사용자 인증, 요청 정보 보호, 데이터 암호화를 프로토콜 자체에 포함하도록 설계되었습니다. 클라이언트에는 올바른 사용자 식별자가 필요하며, 서버 요구에 맞는 보안 설정을 선택해야 합니다. 최신 설정에서는 일반적으로 AEAD 기반 인증 방식을 사용합니다. 오래된 자료에 나오는 추가 식별자 필드는 이전 버전과의 호환성을 위한 내용이므로, 옛 가이드를 따라 임의의 값을 입력하지 마세요. 서버 설정과 클라이언트 설정은 일치해야 합니다. 새 설정은 유지 관리자가 명확히 안내한 최신 매개변수를 우선 사용하세요.

프로토콜에 보호 기능이 내장되어 있어도 외부 TLS가 쓸모없다는 뜻은 아닙니다. 외부 연결과 프록시 프로토콜은 서로 다른 문제를 다루며, 배포 방식에 따라 WebSocket 등 다른 전송 방식이 사용될 수도 있습니다. VMess 노드를 평가할 때는 로컬 트래픽 유입, 프로토콜 캡슐화, 외부 전송, 원격 아웃바운드까지 전체 연결 경로를 함께 살펴보세요. 각 단계에서 리소스를 사용합니다. 프로토콜 이름만으로 오버헤드를 추정할 수 없으며, 암호화 계층이 하나 더 있다는 이유만으로 일상적인 사용 속도가 반드시 눈에 띄게 느려진다고 단정해서도 안 됩니다.

VLESS: 프로토콜 자체의 데이터 암호화 역할을 축소

VLESS는 프록시 프로토콜의 구조를 간소화하고, 데이터 보안을 보완 보안 계층에 더 맡기는 방향으로 설계되었습니다. 일반적인 클라이언트 설정에서 암호화 항목은 none입니다. 이는 VLESS 자체가 해당 데이터 암호화를 제공하지 않는다는 뜻이지, 연결 전체가 보호되지 않는다는 뜻은 아닙니다. 안전한 연결인지 확인하려면 TLS 또는 REALITY가 올바르게 활성화되었는지, 서버 신원이 검증되는지, 로컬과 원격의 신뢰 경계가 어떻게 설정되었는지 살펴봐야 합니다. 이 항목을 다른 프로토콜의 암호화 방식으로 바꾸면 대개 설정이 거부됩니다.

VLESS와 Xray 생태계에서는 흐름 제어와 보안 계층 기능이 함께 언급되는 경우가 많지만, 모든 VLESS 구현에 기본으로 포함된 기능은 아닙니다. 예를 들어 Vision 흐름 제어는 코어 지원과 연결 조합이 맞아야 사용할 수 있습니다. 기본 VLESS 항목만 포함한 공유 링크에는 이 기능이 자동으로 추가되지 않습니다. 서버에서 흐름 제어를 요구하지 않는다면 성능을 높인다는 이유로 직접 추가하지 마세요. 설정은 많을수록 좋은 것이 아니라 서버가 제공한 내용을 정확히 재현하는 것이 우선입니다.

시간, 사용자 식별자, 전환 시 주의할 점

VMess는 시간 동기화가 중요합니다. 기기 시간이 크게 어긋나면 인증에 영향을 줄 수 있습니다. 문제를 확인할 때 사용자 식별자를 계속 새로 만들기보다 시스템 날짜와 시간, 자동 동기화 상태를 점검하세요. VLESS가 모든 시간 문제를 해결하는 대안이라고 볼 수는 없습니다. 외부 인증서 검증에도 시스템 시간이 영향을 미칩니다. 두 프로토콜에서 사용자 식별자가 모두 UUID처럼 보일 수 있지만 형식이 같다고 서로 바꿔 쓸 수 있는 것은 아닙니다. 클라이언트의 드롭다운 항목만 바꿔도 서버 설정은 바뀌지 않습니다.

기존 VMess 구성에서 VLESS로 전환하려면 서버에서 새 연결 지점을 제공하거나 변경 사항을 명확히 안내해야 합니다. 전송 방식, 보안 계층, 흐름 제어 조건도 함께 확인하세요. 전환 전에 기존에 작동하던 설정을 보존하고 새 연결 지점은 별도 그룹에서 테스트하세요. 대상 앱과 UDP 사용도 정상인지 확인한 뒤 교체하면 됩니다. 유일하게 사용 가능한 노드의 설정 여러 개를 연달아 덮어쓰면 문제가 생겼을 때 원인을 찾기 어렵습니다. 인증 및 보호 방식의 차이는 VMess와 VLESS의 차이에서 자세히 확인할 수 있습니다.

가져온 뒤에는 노드 메모만 비교하지 말고 프로토콜 종류, 사용자 식별자, 주소, 포트, 전송 방식, 보안 계층, 흐름 제어를 하나씩 확인하세요. 메모는 공유자가 입력하는 설명일 뿐 기술적 조건이 아닙니다. 설정 파싱 오류는 먼저 필드와 코어 호환성을 확인하고, 인증 오류는 서버 계정과 매개변수를 점검하세요. 연결이 안정적으로 이루어진 뒤에야 처리량과 응답 속도를 비교하는 것이 좋습니다.

03 / TROJAN & SHADOWSOCKS

Trojan과 Shadowsocks 설정 시 주의할 점

Trojan: TLS를 일반적인 연결 기반으로 사용

Trojan은 비밀번호 인증과 TLS 연결을 결합한 프로토콜입니다. 클라이언트 설정에는 보통 주소, 포트, 비밀번호, 서버 이름이 포함됩니다. UUID를 사용하는 프로토콜과 인증 정보 표현 방식은 다르지만, 클라이언트와 서버의 설정이 모두 일치해야 한다는 점은 같습니다. 비밀번호가 맞아도 반드시 연결되는 것은 아닙니다. 인증서 이름, 발급 체인, 시스템 시간, 외부 전송에 문제가 있으면 인증 단계에 도달하기 전에 연결이 종료될 수 있습니다. 문제를 확인할 때 TLS 핸드셰이크에서 실패했는지, 프로토콜 인증 단계에서 실패했는지 먼저 구분하세요.

신뢰할 수 있는 네트워크 환경에서 올바른 검증을 거치면 TLS는 연결을 암호화하고 서버 신원을 확인합니다. Trojan을 선택할 때 인증서 검증 건너뛰기를 기본 설정으로 사용하거나, 알 수 없는 인증서 오류를 단순히 클라이언트 제한으로 돌려서는 안 됩니다. 도메인 인증서와 직접 연결하는 서버 주소는 다를 수 있지만 서버 이름은 배포 조건에 맞아야 합니다. IP 주소로 직접 연결할 때는 특히 이름 항목을 확인하세요. 클라이언트가 인증서에 맞는 도메인을 자동으로 알아낼 것이라고 기대해서는 안 됩니다.

Shadowsocks: 암호화 방식도 프로토콜 호환 조건입니다

Shadowsocks는 클라이언트에서 SS로 줄여 표시되기도 하며, 주요 설정은 서버, 포트, 비밀번호, 암호화 방식입니다. 비교적 간결한 암호화 프록시 연결을 지향하지만, ‘SS 지원’이라는 표시만으로 완전한 호환성을 뜻하지는 않습니다. 기존 AEAD 방식과 후속 확장 방식은 키 요구 사항, 구현 지원, 링크 파싱 방식이 다를 수 있습니다. 설정에 적힌 방식 이름을 정확히 일치시켜야 하며, 클라이언트의 다른 옵션이 더 최신처럼 보인다는 이유로 임의로 바꾸지 마세요.

비밀번호를 일반적인 짧은 암호처럼 취급할 수 없는 구성도 있습니다. 특정 방식은 정해진 길이와 인코딩 형식의 키를 요구합니다. 끝 문자를 실수로 지우거나 대소문자를 바꾸고, 다시 디코딩하면 인증 조건이 깨집니다. 공유 링크를 복사할 때는 전체 내용을 그대로 유지하세요. 직접 입력해야 한다면 서버 안내에 따르세요. 다른 프로토콜의 UUID를 SS 비밀번호 칸에 넣어 자동 변환을 기대해서는 안 됩니다. 링크에 인코딩된 인증 정보를 최종 비밀번호로 그대로 사용해서도 안 됩니다.

플러그인, UDP, 전송 확장 기능도 확인하세요

일부 SS 공유 정보에는 플러그인 매개변수가 포함됩니다. 그래픽 클라이언트에서 링크를 인식했다고 해서 실행 환경에 필요한 플러그인이 설치되어 있거나 코어가 같은 기능을 기본으로 지원한다는 뜻은 아닙니다. 지원 클라이언트 목록은 다운로드 페이지의 안내를 확인하세요. 플러그인이 필요한 서비스를 이용할 때는 현재 클라이언트가 지원하는 대체 연결 지점이 있는지 먼저 확인해야 합니다. 플러그인 누락 오류를 비밀번호 오류로 오해하지 말고, 출처가 불분명한 안내에 따라 추가 구성 요소를 설치하지 마세요. 먼저 서비스 관리자에게 연결 방식을 확인하세요.

UDP 사용 가능 여부는 프로토콜 구현, 서버 전달 기능, 클라이언트의 트래픽 유입 방식, 대상 앱을 모두 확인해야 합니다. 웹 페이지가 열려도 음성 통화나 실시간 통신까지 정상이라고 볼 수는 없습니다. 이런 서비스는 다른 유형의 트래픽을 사용할 수 있습니다. 시스템 프록시는 일반적으로 모든 프로그램의 UDP 트래픽을 자동으로 처리하지 않습니다. TUN으로 연결해도 서버가 제공하지 않는 기능을 보완할 수는 없습니다. Trojan과 SS를 비교하려면 같은 네트워크와 작업 조건에서 각각 검증하세요. 웹 페이지를 한 번 불러온 결과로 전체 호환성을 판단해서는 안 됩니다.

표준 Trojan 또는 SS 설정만 제공하는 기존 서비스를 이용한다면 해당 매개변수를 모두 표현할 수 있는 클라이언트 설정을 우선 사용하세요. 필요하지 않은 전송 옵션을 더할 이유는 없습니다. 데스크톱에서는 v2rayN에 별도의 테스트 항목을 만들고, Android에서는 v2rayNG에서 암호화 방식과 보안 옵션을 확인할 수 있습니다. v2flyNG를 사용하려면 포함된 코어가 해당 방식과 확장 기능을 지원하는지도 확인하세요. 화면에 같은 프로토콜 이름이 보인다고 검증을 생략해서는 안 됩니다.

두 프로토콜 중 어느 하나가 본질적으로 특정 속도 등급에 해당하는 것은 아닙니다. 서버 부하, 네트워크 경로, 암호화 구현, 연결 재사용 방식이 프로토콜 이름보다 체감 차이를 더 잘 설명하는 경우가 많습니다. 설정은 먼저 인증, 기능 요구, 유지 관리 조건을 충족하도록 선택한 뒤 실제 작업으로 리소스 사용량을 비교하세요. 가져온 설정이 작동하지 않으면 도움말 센터의 설치·설정 및 문제 해결 항목을 참고하세요.

04 / TLS & REALITY

TLS, REALITY와 Vision 흐름 제어

REALITY는 VLESS와 같은 계층의 노드 프로토콜이 아닙니다

클라이언트에서는 VLESS, REALITY, Vision이 한 노드 설명에 함께 표시되어 세 가지를 같은 계층으로 오해하기 쉽습니다. 실제 설정에서 VLESS는 프록시 프로토콜, REALITY는 Xray 생태계의 보안 메커니즘, Vision은 특정 연결 조합에서 사용하는 흐름 제어입니다. 서로 협력하지만 역할은 다릅니다. REALITY를 선택해도 프로토콜 인증은 필요하며, Vision을 선택해도 보안 계층을 대신할 수 없습니다. 화면의 각 항목은 서버에서 제공한 조합에 맞춰 설정해야 합니다.

일반적인 TLS 신뢰 경로는 인증서, 이름, 발급 체인에 의존합니다. 클라이언트는 이 조건으로 원격 서버의 신원을 확인하며, 시스템 시간도 인증서 유효기간을 판단하는 데 사용됩니다. REALITY는 별도의 인증 및 핸드셰이크 방식을 사용하며 클라이언트에서 공개 키, 짧은 ID, 서버 이름 등의 관련 매개변수를 설정합니다. 두 방식의 항목을 서로 바꿔 적용할 수는 없습니다. 일반 TLS 인증서 설정이 REALITY 공개 키를 대신할 수 없으며, 일반 TLS 노드에 짧은 ID를 입력한다고 REALITY 노드가 되는 것도 아닙니다.

공개 키, 짧은 ID, 핑거프린트를 각각 확인하세요

REALITY 공개 키는 서비스 관리자가 제공한 클라이언트 설정에서 가져와야 합니다. 임의로 생성한 값을 사용하거나 서버 개인 키를 클라이언트에 입력해서는 안 됩니다. 짧은 ID도 서버에서 허용한 설정과 일치해야 합니다. 문제를 확인할 때는 먼저 복사한 값이 완전한지, 불필요한 공백이나 줄바꿈이 없는지 살펴본 다음 현재 코어가 실제로 지원하는 항목 형식을 확인하세요. 코어 버전에 따라 필드 이름이나 파싱 방식이 달라질 수 있으므로, 실행 중인 코어 문서와 클라이언트 내보내기 결과를 기준으로 삼고 오래된 설정을 무작정 복사하지 마세요.

서버 이름은 서버에서 명확히 허용한 값을 사용해야 하며, 흔한 웹사이트 도메인 중 하나를 임의로 골라서는 안 됩니다. 핑거프린트는 특정 보안 조합에서 클라이언트 핸드셰이크 특성을 지정하는 데 필요할 수 있지만 속도 설정은 아닙니다. 핑거프린트를 바꿔도 주소 연결 불가, 키 불일치, 사용자 인증 오류는 해결되지 않습니다. 서버가 권장 값을 제공했다면 우선 그대로 사용하세요. 호환성을 확인해야 한다면 한 번에 한 항목만 바꾸고 코어 로그에서 실패 단계를 기록하세요.

Vision은 연결 조합이 일치해야 합니다

xtls-rprx-vision은 흔히 사용되는 흐름 제어 식별자이며, 모든 전송 방식에 적용할 수 있는 범용 최적화 옵션이 아닙니다. 서버에 해당 사용자 흐름 제어가 설정되어 있어야 하고 클라이언트 코어도 그 조합을 지원해야 합니다. 특정 경로 설정이 필요한 전송 방식을 TCP로 바꾸거나 기존 WebSocket 설정에 Vision을 추가하면 호환되지 않을 수 있습니다. 흐름 제어 관련 오류가 발생하면 전체 구성을 먼저 확인하세요. 모든 보안 옵션을 차례로 켜 보며 해결하려고 하지 마세요.

같은 서비스에서 일반 TLS와 REALITY 연결 지점을 모두 제공한다면 각각 별도 노드로 만들어 테스트하세요. 각 방식의 인증 및 전송 조건을 그대로 유지해야 합니다. 선택 기준은 클라이언트 지원 여부, 서비스 유지 관리 방식, 인증서 관리 조건, 실제 네트워크 성능이며, 어느 한쪽을 모든 상황의 대체재로 여겨서는 안 됩니다. 일상적으로 핸드셰이크 세부 사항을 외울 필요는 없지만, 어떤 항목이 한 세트로 유지되어야 하는지, 검증을 건너뛰어도 해결되지 않는 오류가 무엇인지는 알아야 합니다.

로그에 핸드셰이크 실패가 나타나면 이름 불일치, 신뢰할 수 없는 인증서, 상대 측 연결 종료, 인증 불일치 등을 구분하세요. 먼저 클라이언트가 예상한 주소와 포트에 연결하는지 확인한 뒤 보안 계층 설정을 점검합니다. 라우팅 규칙을 계속 바꿔도 핸드셰이크 자체는 해결되지 않는 경우가 많습니다. 자세한 점검 순서는 TLS 핸드셰이크 실패 문제 해결에서 확인하세요. 시스템 시간과 서버 이름에서 자주 발생하는 오해도 설명합니다.

도움을 요청할 때는 REALITY 사용 여부, Vision 사용 여부, 클라이언트와 코어 종류, 오류 발생 단계를 알려 주면 됩니다. 전체 공유 링크, 공개 키 외의 비밀 정보, 서버 설정은 공개하지 마세요. 공개 가능한 매개변수도 모두 올릴 필요는 없습니다. 전체 설정을 붙여 넣는 것보다 문제 파악에 필요한 기술 정보를 간결하게 정리하는 편이 유용합니다.

05 / PERFORMANCE & BATTERY

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

연결 시작과 지속 전송을 나눠 측정하세요

‘속도가 빠르다’는 말은 웹페이지를 처음 열 때까지 기다리는 시간이 짧다는 뜻일 수도 있고, 대용량 파일의 지속 전송 처리량이 높다는 뜻일 수도 있습니다. 두 결과에 영향을 미치는 요인은 다릅니다. 연결을 시작하려면 이름 확인, 네트워크 연결, 보안 핸드셰이크, 프록시 인증이 필요합니다. 지속 전송 성능은 주로 가용 대역폭, 혼잡, 서버 전달 및 처리 능력에 좌우됩니다. 어떤 프로토콜이 캡슐화 일부를 줄여도 먼 거리의 네트워크에서 첫 응답이 반드시 빨라지는 것은 아닙니다. 대용량 파일을 한 번 내려받은 결과만으로 대화형 앱의 사용 경험을 판단할 수도 없습니다.

프로토콜을 비교할 때는 서버 위치, 네트워크 연결 지점, 테스트 대상, 트래픽 유입 방식을 가능한 한 동일하게 유지하세요. 서버 간 차이가 프로토콜 자체의 차이보다 큰 경우가 많습니다. 프로토콜, DNS, 라우팅, 전송 방식을 한꺼번에 바꾸고 결과를 특정 항목의 영향으로 돌리지 마세요. 같은 앱으로 짧은 요청과 지속 전송을 여러 차례 수행해 결과가 재현되는지 확인한 다음 로그와 시스템 리소스를 살펴보세요. 클라이언트의 연결 테스트는 초기에 문제를 가려내는 데 유용하지만, 테스트 대상이 실제 서비스 경로와 다를 수 있습니다.

캡슐화, 연결 재사용, 기기 성능이 오버헤드를 좌우합니다

암호화 연산은 프로세서 리소스를 사용하지만 실제 비용은 알고리즘 구현과 하드웨어 성능에 따라 달라집니다. VMess, VLESS, Trojan, SS에 정해진 순위를 매길 수는 없습니다. 외부 전송 방식, 연결 수, 로그 수준, 트래픽 복제도 사용량에 영향을 줍니다. 전송 계층에서 요청과 캡슐화가 늘어날 수 있지만 배포 편의성이나 호환성을 얻기도 합니다. 서버 요구사항을 먼저 충족한 뒤 현재 기기에서 이 비용이 체감되는 병목인지 판단하세요.

연결을 재사용하면 연결을 반복해서 수립하는 비용을 줄일 수 있지만, 여러 동시 트래픽이 서로 영향을 주는 방식도 달라질 수 있습니다. 서버와 코어가 지원하는지 확인한 뒤 실제 앱으로 테스트하세요. 모든 트래픽을 더 적은 연결에 모은다고 항상 원활해지는 것은 아닙니다. 짧은 요청이 자주 발생하는 작업과 대량 데이터를 오래 전송하는 작업은 요구가 다릅니다. 지연이나 끊김이 생기면 프로토콜 성능이 부족하다고 단정하기 전에 공유 연결의 혼잡 여부를 확인하세요.

Android 배터리는 먼저 기기 깨우기와 트래픽 범위를 확인하세요

모바일 배터리 사용량은 암호화만으로 결정되지 않습니다. 무선 네트워크를 자주 깨우는 동작, 백그라운드 앱의 지속적인 요청, 네트워크 전환 후 재연결, 지나치게 잦은 연결 확인도 배터리를 더 사용하게 만듭니다. VPN 연결 범위가 넓어져 더 많은 앱을 처리하면 시스템에서 일부 네트워크 활동을 프록시 클라이언트의 사용량으로 집계할 수 있습니다. 따라서 배터리 통계의 비율을 프로토콜 계산 비용으로 바로 해석해서는 안 됩니다. 먼저 비슷한 사용 시간대와 네트워크 조건, 동일한 백그라운드 앱으로 비교하세요.

v2rayNG의 앱별 프록시를 사용하면 연결할 앱을 제한할 수 있습니다. 현재 목록이 허용 모드인지 우회 모드인지, 설정을 저장한 뒤 연결을 다시 시작해야 하는지 확인하세요. 시스템 배터리 최적화와 제조사의 백그라운드 제한도 구분해야 합니다. 제한이 지나치게 강하면 프로세스가 종료되어 반복 재시작하거나 연결이 끊길 수 있습니다. 반대로 제한을 모두 해제하면 필요하지 않은 백그라운드 작업까지 계속 실행될 수 있습니다. 목표는 필요한 서비스를 안정적으로 실행하는 것이지 모든 앱과 시스템 제한을 무조건 해제하는 것이 아닙니다.

TUN 모드에는 가상 인터페이스, 라우팅 처리, DNS 가로채기도 포함되므로 배터리 사용량이 시스템 프록시 사용량에 단순히 더해지는 관계는 아닙니다. 앱 자체가 프록시를 지원한다면 시스템 프록시만으로 충분할 수 있습니다. 프록시 설정을 따르지 않는 프로그램까지 연결해야 한다면 TUN의 추가 작업이 필요한 비용일 수 있습니다. 데스크톱에서 비교할 때는 다른 가상 네트워크 소프트웨어가 함께 실행 중인지도 살펴보세요. 그래야 라우팅 충돌이나 중복 트래픽 처리를 코어 성능 문제로 오해하지 않습니다.

테스트가 끝나면 로그 수준을 평소 설정으로 되돌려 연결 정보가 대량으로 계속 기록되지 않도록 하세요. 성능은 한 번의 최고 기록보다 작업이 안정적으로 완료되는지를 기준으로 평가해야 합니다. 특정 도메인만 눈에 띄게 느리다면 DNS, 분할 라우팅, 원격 경로를 점검하세요. 모든 앱이 영향을 받는다면 로컬 부하, 네트워크 상태, 서버 상태를 확인합니다. 프로토콜 선택은 최적화의 한 부분일 뿐 모든 병목의 공통 원인은 아닙니다.

06 / CORE COMPATIBILITY

V2Fly, Xray와 클라이언트의 관계

그래픽 인터페이스는 관리하고 코어는 연결을 실행합니다

Project V는 V2Ray 생태계를 이해하는 배경이며, V2Fly와 Xray는 관련 발전 과정에서 나온 코어 계열입니다. 그래픽 클라이언트는 노드 관리, 매개변수 편집, 프로세스 실행, 시스템 연결을 담당합니다. v2rayN, v2rayNG, v2flyNG는 특정 프로토콜을 뜻하지 않습니다. 실제 연결은 클라이언트가 실행하는 코어가 처리합니다. 따라서 화면에 특정 항목이 있다는 사실은 인터페이스가 그 매개변수를 입력할 수 있다는 뜻일 뿐, 현재 코어에서 실제로 실행할 수 있음을 보장하지 않습니다.

Xray는 발전 과정에서 REALITY, Vision 등의 기능을 제공해 왔으며, V2Fly에도 별도의 유지 관리 방향과 설정 확장이 있습니다. 두 코어는 역사적으로 일부 개념을 공유하지만 모든 항목이 늘 똑같은 것은 아닙니다. 지원 기능, 기본 동작, 전송 방식 구현은 코어 버전에 따라 달라질 수 있습니다. 특정 기능을 사용할 때는 현재 포함된 코어의 안내를 확인하세요. 한 계열의 매개변수 목록을 다른 계열에서도 계속 호환되는 목록으로 간주해서는 안 됩니다.

세 클라이언트의 용도는 서로 다릅니다

데스크톱에서는 v2rayN을 우선 사용하고, 다운로드 페이지에서 제공하는 운영체제 아키텍처와 형식에 맞춰 Windows, macOS, Linux에 설치하세요. 데스크톱 인터페이스에 따라 메뉴 위치는 달라질 수 있지만 프로토콜 매개변수는 선택한 코어가 실행해야 합니다. Android에서는 Xray를 코어로 사용하는 v2rayNG를 우선 고려하세요. V2Fly 구성과 맞춰야 한다면 v2flyNG를 검토할 수 있습니다. 두 모바일 클라이언트의 이름이 비슷해도 지원하는 설정 기능과 코어 확장이 완전히 같지는 않습니다.

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

기본 설정에서 외부 구조가 같아 보여도 내부 항목은 다를 수 있습니다. 특히 전송 방식 이름, DNS 옵션, 흐름 제어, 보안 계층 매개변수를 확인해야 합니다. Xray 설정을 V2Fly에서 실행하거나 반대로 적용하려면 먼저 기능 지원 범위를 점검하세요. 파싱 단계에서 알 수 없는 항목이 나타나면 설정 모델이 맞지 않을 가능성이 큽니다. 실행은 성공했지만 연결에 실패한다면 해당 항목이 무시되었는지, 기본값이 달라졌는지, 서버가 연결을 허용하는지도 확인해야 합니다.

코어를 전환하기 전에 노드, 구독 그룹, 사용자 지정 규칙을 백업하세요. 클라이언트가 생성할 수 있는 표준 설정을 우선 사용하고, 정상 작동이 확인된 노드 하나로 검증한 뒤 사용자 지정 항목을 단계적으로 복원하세요. 기존의 복잡한 설정을 한 번에 옮기면 오래된 경로, 규칙 파일 참조, 이전 코어에서만 사용할 수 있는 옵션까지 함께 가져올 수 있습니다. 실행에 실패하면 불필요한 확장을 먼저 제거하고 최소한의 연결 설정부터 복구하세요. 호환 옵션을 계속 추가하는 방식으로 해결하려고 하지 마세요.

v2rayN에서 선택한 코어 종류는 노드 구성에 맞아야 합니다. 정확한 메뉴 위치는 현재 인터페이스에서 확인하세요. 특정 기능의 코어 선택을 클라이언트가 자동으로 처리한다면 목록에 표시된 메모만 보지 말고 시작 로그에서 실제 실행 프로세스를 확인하세요. 클라이언트를 업데이트하면 인터페이스와 코어 간 연동 방식도 달라질 수 있습니다. 정상 작동하는 설정의 백업과 테스트 기록을 보관하면 업데이트로 바뀐 동작과 서버 설정 변경을 구분하는 데 도움이 됩니다.

연결 문제가 생겼다고 두 코어를 반복해서 바꾸지 마세요. 오류가 파싱, 실행, 핸드셰이크, 인증, 대상 접속 중 어느 단계에서 발생했는지 먼저 찾고 구현 지원 여부를 판단하세요. 일반적인 주소 확인 오류, 시스템 시간 차이, 로컬 프록시 포트 충돌은 대개 코어를 바꿀 이유가 아닙니다. 클라이언트를 설치하거나 교체해야 한다면 클라이언트 다운로드 페이지에서 해당 플랫폼에 맞는 항목을 선택하세요. 그래야 운영체제 아키텍처 문제와 프로토콜 문제를 혼동하지 않습니다.

07 / SUBSCRIPTION FORMATS

공유 링크, 구독, 기본 JSON

세 가지 형식에는 서로 다른 정보가 저장됩니다

공유 링크에는 보통 하나의 연결 정보가 담기고, 구독 주소는 업데이트 가능한 연결 정보 목록을 가져오는 데 사용됩니다. 기본 JSON은 코어 실행 설정을 표현할 수 있습니다. 같은 내용을 파일 확장자만 바꿔 저장한 형식이 아닙니다. 공유 링크는 노드를 전달하기 편하지만 라우팅, DNS, 사용자 지정 아웃바운드 설정을 모두 담지 못할 수 있습니다. 기본 JSON은 더 많은 설정을 표현할 수 있지만 특정 코어나 로컬 파일에 의존할 수 있습니다. 가져오기 방식을 선택하기 전에 제공된 형식부터 확인하세요.

일반적인 텍스트 구독은 줄마다 나열된 공유 링크를 Base64로 인코딩하지만, 이는 흔한 형식일 뿐 모든 구독에 적용되는 표준은 아닙니다. 일부 주소는 설정 문서나 다른 클라이언트용 형식을 반환하므로 반복해서 디코딩해도 이 사이트의 클라이언트 형식으로 바뀌지 않습니다. 구독을 내려받는 데 성공해도 파싱까지 성공한 것은 아닙니다. 서버가 로그인 페이지, 오류 페이지, 빈 응답을 반환할 수도 있습니다. 먼저 클라이언트 오류 유형을 확인한 뒤 가져오기 실패, 형식 불일치, 특정 노드 매개변수 미지원 중 어디에 해당하는지 판단하세요.

인코딩 변환으로 누락된 매개변수가 생기지는 않습니다

Base64는 인코딩 방식이지 비밀을 보호하는 수단이 아닙니다. 디코딩한 사용자 식별자, 비밀번호, 서버 정보도 계속 비밀로 관리해야 합니다. 링크의 퍼센트 인코딩에도 고유한 규칙이 있으므로 문자열 전체를 반복해서 디코딩하지 마세요. 특히 비밀번호, 메모, 경로에 특수 문자가 포함되면 변환을 한 번 더 하는 것만으로도 원래 의미가 바뀔 수 있습니다. 복사할 때는 클라이언트의 공유 또는 내보내기 기능을 우선 사용하고, 서식 있는 텍스트 편집기를 거치며 줄바꿈, 전각 문자, 보이지 않는 공백이 삽입되지 않도록 주의하세요.

공유 링크를 기본 설정으로 변환하려면 해당 프로토콜, 전송 방식, 보안 계층의 항목이 어떻게 대응되는지 알아야 합니다. 원본 링크에 확장 매개변수가 없다면 변환 도구가 실제 값을 정확히 추론할 수 없습니다. 반대로 복잡한 기본 설정을 단일 공유 링크로 줄이면 사용자 지정 DNS, 여러 아웃바운드, 라우팅 규칙이 손실될 수도 있습니다. 변환 후에는 주요 항목을 확인하고 실제 연결을 검증하세요. ‘변환 성공’만으로 두 설정이 완전히 같다고 볼 수는 없습니다.

작은 예시로 이해하는 기본 JSON의 범위

아래는 코어 설정의 라우팅 조각이며 독립적으로 실행할 수 있는 전체 설정은 아닙니다. 광고 도메인 분류에 해당하는 항목을 찾으면 이름이 block인 아웃바운드를 사용하라는 뜻입니다. 전체 설정에서 해당 아웃바운드를 정의해야 하며 실행 환경에서 관련 규칙 데이터도 읽을 수 있어야 합니다. 이 예시는 필드 간 참조 관계를 설명하기 위한 것이므로 클라이언트의 공유 링크 가져오기 창에 그대로 붙여 넣지 마세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  }
}

여기서 도메인 정책은 라우팅 조건을 확인할 때 이름 확인을 시도하는 상황을 정합니다. DNS 서버 주소를 지정하는 항목은 아니며 모든 DNS 요청이 프록시를 통과하도록 보장하지도 않습니다. 규칙의 아웃바운드 이름은 전체 설정과 일치해야 합니다. 그렇지 않으면 JSON 문법은 올바르더라도 예상과 다르게 동작할 수 있습니다. 규칙 데이터의 존재 여부, 분류 이름 사용 가능 여부, 코어의 관련 항목 지원 여부도 실행 조건입니다. 필드의 의미는 용어집에서 더 확인할 수 있습니다.

구독 업데이트와 직접 편집은 따로 관리하세요

구독 그룹의 노드는 업데이트할 때 교체되거나 다시 생성될 수 있습니다. 이런 노드를 직접 편집하면 다음 업데이트에서 변경 사항이 사라질 수 있습니다. 계속 유지해야 하는 로컬 설정은 클라이언트가 지원하는 별도 설정이나 관리 방법으로 적용하고, 구독 원본과 달라진 부분을 기록하세요. 업데이트 전에 기존 그룹을 서둘러 삭제하지 마세요. 새 노드가 연결되는지 먼저 확인한 뒤 중복 항목과 만료된 항목을 정리하면 문제가 생겼을 때 되돌리기 쉽습니다.

구독 주소에는 접근 토큰이 포함되는 경우가 많으므로 계정 인증 정보처럼 관리해야 합니다. 출처가 불분명한 온라인 변환 서비스에 전달하거나 토큰이 포함된 전체 주소를 공개된 문의에 올리지 마세요. 이전할 때는 클라이언트 내장 기능을 우선 사용하고 대상 클라이언트가 해당 형식을 지원하는지 확인한 뒤 가져오세요. 형식 간 차이와 실패 원인은 구독 형식과 변환 방법에서 확인할 수 있습니다. 호환 여부는 매개변수가 유지되는지, 코어가 받아들이는지, 실제 연결이 정상인지로 판단해야 합니다.

08 / SCENARIO SELECTION

사용 환경에 맞춰 선택하고 검증하기

기존 서비스: 전체 호환성을 먼저 확인한 뒤 프로토콜 비교

이미 사용할 수 있는 구독이 있다면 클라이언트 선택 시 서버에서 제공하는 프로토콜 조합과 기기 플랫폼을 먼저 살펴보세요. 데스크톱에서는 v2rayN을, Android에서는 v2rayNG를 우선 고려하고 V2Fly에 대응하는 기능이 필요할 때 v2flyNG를 검토하세요. 다른 프로토콜이 소개 글에서 더 간단해 보인다고 노드를 임의로 바꾸지 마세요. 구독 원본을 보존하고 필요한 매개변수를 모두 가져올 수 있는지 확인한 다음 노드 하나로 연결을 검증하세요. 그 후 구독 그룹, 라우팅, 여러 앱 사용으로 범위를 넓히면 됩니다.

서비스에서 여러 연결 방식을 제공한다면 별도 테스트 그룹에 각각 추가하고 웹 접속, 지속 전송, 실제 앱으로 결과를 비교하세요. 트래픽 유입 방식, DNS, 대상 주소를 고정하고 한 번에 변수 하나만 비교해야 합니다. 기존 구성이 안정적으로 작동하고 요구사항을 충족한다면 명확한 호환성 요구, 유지 관리 편의성, 재현 가능한 사용 개선이 있을 때 전환을 고려하세요. 프로토콜 이름이 더 최신이라는 이유만으로 바꿀 필요는 없습니다. 결과가 일정하지 않으면 성급하게 결론 내리지 말고 서버 경로와 네트워크 변동을 먼저 확인하세요.

데스크톱 작업과 모바일 백그라운드는 확인할 점이 다릅니다

데스크톱 브라우저나 시스템 프록시를 따르는 도구는 먼저 시스템 프록시로 연결해 로컬 수신 포트와 프로그램 설정이 일치하는지 확인하세요. 다른 트래픽까지 처리해야 할 때 TUN과 권한 조건을 검토하면 됩니다. TUN을 활성화한 뒤에는 로컬 네트워크, 도메인 확인, 다른 가상 네트워크 소프트웨어가 정상인지 확인하세요. 연결 범위를 넓힌 뒤 앱 동작이 달라졌다고 해서 모두 원격 프로토콜 탓으로 돌리지 마세요. 어떤 앱은 그제야 처음으로 클라이언트를 거치기 시작했을 수 있습니다.

모바일에서는 네트워크 전환, 백그라운드 유지, 트래픽 범위가 더 중요합니다. 안정적인 노드 하나로 시작해 화면을 잠근 뒤 필요한 작업이 계속되는지 확인하고, Wi-Fi에서 모바일 네트워크로 바뀐 뒤 연결이 복구되는지도 살펴보세요. 앱별 프록시로 필요 없는 백그라운드 트래픽을 줄이고 실제 동작에 따라 배터리 제한을 조정하세요. 특정 앱을 실행한 뒤에만 배터리 사용량이 비정상적으로 늘어난다면 전체 프로토콜 구성을 바꾸기 전에 해당 앱의 연결 동작을 확인하세요.

DNS와 분할 라우팅도 검증해야 합니다

연결에 성공한 뒤에는 앱의 트래픽이 예상한 아웃바운드로 나가는지 확인해야 합니다. 도메인 정책, 라우팅 규칙 순서, 직접 연결 범위, DNS 경로에 따라 웹사이트마다 결과가 크게 달라질 수 있습니다. 외부 IP 확인만으로 모든 트래픽을 점검할 수 없으며, 웹페이지 하나를 테스트해도 다른 앱의 동작을 알 수 없습니다. DNS 동작을 확인할 때는 클라이언트 로그, 앱 자체의 이름 확인 기능 사용 여부, 시스템 연결 범위를 함께 살펴보세요. 특정 테스트 페이지에서 나온 결과를 모든 환경에 적용하지 마세요.

예를 들어 라우팅 규칙이 직접 연결을 선택하는데 사용자는 프록시를 기대한다면 프로토콜을 바꿔도 규칙 우선순위는 달라지지 않습니다. 앱에서 암호화된 DNS를 직접 사용하면 클라이언트의 일반 DNS 설정이 해당 요청을 처리하지 못할 수도 있습니다. 관련 절차는 DNS 검사와 설정 방법에서 확인하세요. 변경하기 전에 현재 설정을 보존하고 어떤 트래픽을 어떤 경로로 보낼지 정한 다음 결과를 검증하세요. DNS와 관련 있어 보이는 옵션을 전부 동시에 켜서는 안 됩니다.

실패 단계에 따라 다음 조치를 결정하세요

가져오기에 실패했다면 형식과 인코딩을 확인하세요. 코어 실행에 실패했다면 설정 구조와 지원 범위를 점검하고, 핸드셰이크 오류라면 보안 계층을 확인하세요. 인증 실패는 사용자 정보를 점검하고, 연결된 뒤 대상에 접속하지 못하면 라우팅, DNS, 원격 아웃바운드를 살펴봐야 합니다. 이 순서를 따르면 반복적인 시행착오를 줄일 수 있습니다. 한 번에 한 항목만 바꾸고 필요한 프로세스를 다시 시작한 뒤 재검사하며 간단한 기록을 남기세요. 오류 유형이 달라졌다면 연결이 다음 단계로 진행된 것이므로 점검 방향도 그에 맞게 조정하면 됩니다.

새 서비스를 구성할 때도 먼저 클라이언트 지원 범위, 전송 환경, 인증 방식, 유지 관리 조건을 정한 뒤 프로토콜 조합을 선택하세요. 인증서를 관리해야 하는 구성이라면 이름과 인증서 갱신 계획을 세우고, REALITY를 사용하는 구성이라면 키와 허용 매개변수의 관리 방법을 정해야 합니다. 어떤 구성이든 설정을 지속적으로 일치시켜 관리해야 하며 한 번 설치한 뒤 계속 확인하지 않아도 되는 것은 아닙니다. 클라이언트나 코어를 업데이트한 뒤에는 시작 성공 여부만 보는 것보다 기존 테스트 작업을 다시 수행하는 편이 확실합니다.

마지막으로 검증을 마친 구성을 기준 설정으로 보관하고 실험용 매개변수는 별도 항목에서 관리하세요. 처음부터 설정하려면 빠른 시작 가이드를, 구체적인 오류를 찾으려면 도움말 센터를 참고하세요. 플랫폼을 바꾸거나 클라이언트를 설치할 때는 다운로드 페이지로 이동하면 됩니다. 프로토콜과 코어 선택은 설정을 더 이해하기 쉽고 문제를 더 정확히 찾을 수 있도록 해야지, 설명할 수 없는 항목을 늘려서는 안 됩니다.