프로토콜 · 전송 · 보안 계층 · 코어

V2Ray 프로토콜과 코어클라이언트 선택 가이드

노드 설정에 맞춰 프로토콜을 선택한 다음, 코어 지원 여부와 구독 형식, 라우팅 동작을 확인하세요.

이 페이지는 설정 항목의 호환 범위를 체계적으로 살펴보는 기술 참고 자료입니다. 처음 설치하거나 연결하는 경우 먼저 입문 가이드를 읽어 보세요. 프로토콜, 보안 계층 또는 코어 선택에 문제가 있다면 해당 절을 확인하면 됩니다. 데스크톱에서는 v2rayN부터 시작하는 것을 권장합니다. 설치 파일은 클라이언트 다운로드 페이지에서 확인하세요.

VMess
VLESS
Trojan
Shadowsocks
REALITY

확인 순서: 설정 계층을 파악한 다음 프로토콜과 실행 조건을 비교하세요.

사용 가능한 노드가 있다면 제공된 설정을 우선 그대로 유지하세요. 프로토콜 이름은 속도 등급이 아니며, 코어를 바꿔도 설정이 변환되는 것은 아닙니다.

설정 계층과 VMess: 프로토콜·전송·암호화를 구분하기

노드 이름을 살펴볼 때는 먼저 각 요소를 계층별로 나눠 보세요. 프록시 프로토콜은 사용자 인증 정보와 목적지 주소를 전달하는 방식을 정하고, 전송 방식은 이 데이터를 어떤 통로로 보낼지 정합니다. 보안 계층은 해당 연결을 인증하고 암호화하며, 클라이언트는 화면의 설정 항목을 코어 설정으로 변환합니다. 하나의 프로토콜도 여러 전송 방식과 조합할 수 있으므로, 두 노드가 모두 VMess라고 해서 모든 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 주소, 포트, 사용자 ID, 전송 및 보안 설정이 함께 연결을 구성합니다. 하나라도 빠지면 연결의 어느 단계에서든 실패할 수 있습니다.

VMess의 설계 배경과 현재 사용 방식

VMess는 Project V 생태계 초기에 만들어진 프록시 프로토콜입니다. 사용자 인증과 프록시 데이터 전달을 결합했으며, 발전 과정에서 인증 암호화 기반의 방식을 채택했습니다. 클라이언트와 서버가 사용자를 어떻게 식별하고 프로토콜 데이터를 보호하며 프록시 요청을 표현할지를 다루지만, 모든 외부 전송 방식을 직접 정하는 것은 아닙니다. 기존 구독에는 여전히 VMess 노드가 포함될 수 있습니다. 선택할 때는 노드 설정이 완전한지, 서버가 해당 연결 방식을 계속 제공하는지 확인하세요. 프로토콜 이름이 오래됐다는 이유만으로 사용 가능한 설정을 다른 유형으로 바꿀 필요는 없습니다.

v2rayN에서 VMess 노드를 편집할 때는 서버 주소, 포트, 사용자 ID를 먼저 확인한 다음 암호화 옵션, 전송 방식, TLS 설정을 살펴보세요. 사용자 ID는 보통 UUID 형식이지만, 길이가 같다고 해서 아무 문자열이나 대신 사용할 수 있는 것은 아닙니다. 화면의 ‘자동’은 일반적으로 코어가 지원하는 규칙에 따라 암호화 방식을 결정한다는 뜻이지, 서버 설정 오류를 자동으로 고친다는 뜻은 아닙니다. 공유 링크를 가져온 뒤에도 편집 창에서 주요 항목을 확인하세요. 특히 오래된 형식에서 변환된 노드는 세심하게 살펴봐야 합니다.

프로토콜 암호화와 외부 TLS 구분하기

VMess 자체의 인증 암호화와 외부 TLS는 서로 다른 기능입니다. 전자는 프록시 프로토콜 계층에서 처리하고, 후자는 해당 외부 연결을 보호하며 인증서와 서버 이름을 확인할 수 있습니다. 한 계층을 켰다고 해서 다른 계층을 끄거나 켜야 하는 것은 아닙니다. 노드에 WebSocket과 TLS가 지정되어 있다면 연결 주소, 요청 Host, 경로, 서버 이름도 구분해야 합니다. 이 값들은 같을 수도 있지만, 진입점 지정, 요청 전달, 인증 등 서로 다른 용도로 쓰일 수 있습니다. 화면을 깔끔하게 보이게 하려고 모두 같은 값으로 입력하지 마세요.

오래된 자료에는 추가 ID, 구식 인증 방식, 과거에 사용된 설정 항목이 자주 등장합니다. 이런 자료는 화면을 한 항목씩 그대로 따라 하기보다 현재 유효한 공유 링크나 구독을 제공자에게 요청하세요. 최신 구현마다 이전 방식의 지원 범위가 다르며, 클라이언트에 입력란이 보인다고 해서 코어가 모든 과거 값을 받아들이는 것은 아닙니다. 기기 시간이 크게 틀어져 있으면 시간에 의존하는 인증이나 TLS 인증서 유효 기간 확인에도 문제가 생길 수 있습니다. 인증에 실패했다면 먼저 시스템 시간을 동기화한 뒤 사용자 ID와 원본 노드 설정을 대조하세요.

설정 계층	주요 항목	확인할 내용
프록시 프로토콜	유형, 사용자 ID, 비밀번호	서버의 인증 설정과 일치하는지
전송 방식	네트워크, 경로, Host	진입점의 전송 방식과 일치하는지
보안 계층	TLS, 서버 이름	서버 보안 설정과 일치하는지
실행 구현	코어, 로그, 설정 생성	앞의 세 계층을 모두 표현할 수 있는지

오류가 발생한 계층부터 찾기

연결 시간 초과가 발생하면 먼저 주소, 포트, 전송 진입점을 확인하세요. 인증서 오류는 보안 계층과 기기 시간을 먼저 살펴보세요. 연결된 직후 끊긴다면 인증 정보, 경로, 서버 로그를 확인하세요. 이 순서는 오류 유형을 일대일로 분류하는 표가 아니라 여러 설정을 동시에 바꾸지 않고 문제를 좁혀 가는 방법입니다. 원래 노드가 연결된다면 복사본을 만들어 테스트하고, 근거가 명확한 항목 하나씩만 바꿔 보세요. 전체 메뉴 경로는 구독 가져오기 안내에서 확인하세요. 원본 그룹을 반복해서 시험하는 임시 설정 공간으로 사용하지 마세요.

VLESS와 REALITY: 프로토콜과 보안 계층을 따로 확인하기

VLESS는 프록시 프로토콜 자체의 처리를 간소화하고 데이터 보호는 선택한 외부 보안 방식에 맡기는 설계입니다. 사용자 인증은 여전히 필요하지만, ‘이름이 짧은 VMess’로 이해해서는 안 됩니다. VMess의 프로토콜 유형만 VLESS로 바꾸고 나머지 설정을 그대로 써서도 안 됩니다. 두 프로토콜은 요청을 표현하고 처리하는 방식이 다르므로 서버에 해당 진입점이 마련되어 있어야 합니다. VLESS는 TLS나 REALITY 같은 보안 설정과 함께 쓰이는 경우가 많습니다. 전송 방식과 흐름 제어 설정은 노드에 제공된 전체 설정에 따라 선택하세요.

VLESS의 사용자 ID, 암호화, 흐름 제어

클라이언트에서 VLESS 노드를 편집할 때는 주소, 포트, 사용자 ID를 입력한 다음 전송 방식, 보안 유형, 흐름 제어 항목을 확인하세요. 암호화 값은 흔히 none으로 표시됩니다. 이는 VLESS 계층의 설정을 뜻하며, 연결 전체가 암호화되지 않는다는 의미는 아닙니다. 노드에 외부 TLS 또는 REALITY가 지정되어 있다면 해당 보안 계층도 빠짐없이 설정해야 합니다. 이 값만 보고 합의되지 않은 암호화 옵션을 추가하거나 외부 보호를 끄지 마세요. 계층을 임의로 더해도 서버와 호환되는 것은 아닙니다.

흐름 제어는 특정 설정 조합에서 요구되는 기능이지, 마음대로 켤 수 있는 가속 옵션이 아닙니다. 예를 들어 노드에 Vision에 해당하는 흐름 제어 값이 명시되어 있다면 클라이언트, 코어, 서버가 해당 조합을 지원해야 하며 전송 조건도 일치해야 합니다. 흐름 제어 설정이 없는 노드에 다른 노드의 화면을 참고해 같은 옵션을 추가해서는 안 됩니다. 설정 생성 오류가 나거나 핸드셰이크 직후 연결이 끊긴다면 구독 변환 도구가 흐름 제어를 누락했는지, 지원되지 않는 전송 조합에 설정이 잘못 들어갔는지 확인한 뒤 제공자에게 새 설정을 요청하세요.

REALITY는 독립적인 프록시 프로토콜 유형이 아닙니다

REALITY는 Xray 생태계의 보안 방식입니다. 보통 클라이언트에서 프록시 프로토콜이 아니라 보안 유형으로 선택합니다. 일반적인 노드의 프로토콜은 VLESS이고, 보안 계층이 REALITY입니다. REALITY는 자체 도메인 인증서를 배포하는 일반적인 방식과 다른 검증 절차를 사용하므로, 클라이언트에서 서버에 맞는 공개 키와 기타 합의된 설정을 사용해야 합니다. TLS 노드를 REALITY로 바꾸거나, 반대로 공개 키를 지우고 TLS를 선택해도 연결이 자동으로 구성되지는 않습니다. 서버에도 해당 설정이 있어야 합니다.

REALITY 클라이언트의 주요 항목에는 서버 이름, 공개 키, 짧은 ID, 지문이 있습니다. 서버 이름은 제공자가 허용한 값 중에서 선택해야 합니다. 공개 키는 서버 키와 짝이 맞아야 하며, 짧은 ID는 제공된 원본 값을 그대로 사용해야 합니다. 임의로 0을 붙이거나 값을 이어 붙이지 마세요. 설정에 따라 짧은 ID를 비워 둘 수 있지만, 허용 여부는 서버가 결정합니다. 지문은 클라이언트 핸드셰이크 특성에 영향을 주며 코어의 지원도 필요합니다. 가져온 뒤 공개 키만 남고 서버 이름이나 짧은 ID가 사라졌다면 연결에 실패할 수 있습니다. 링크가 인식됐다는 사실만으로 설정이 완전하다고 볼 수는 없습니다.

클라이언트가 설정 조합을 지원하는지 확인하기

데스크톱에서는 v2rayN에서 해당 노드에 실제로 할당된 코어를 확인하세요. 설치 폴더에 Xray가 있는지만 봐서는 안 됩니다. Android에서 REALITY 노드를 사용할 때는 v2rayNG에 포함된 Xray의 기능이 노드 요구 사항과 맞는지 먼저 확인하세요. V2Fly를 코어로 사용하는 v2flyNG에 같은 설정을 전달해도 똑같이 작동한다고 가정하지 마세요. 클라이언트 화면의 선택 항목, 링크 파서, 코어의 실행 능력은 서로 다른 세 단계입니다. 어느 한 단계에서든 항목이 누락되면 가져오기는 성공해도 연결되지 않을 수 있습니다.

필요한 배포 조건을 고려해 선택하세요. VLESS와 REALITY의 전체 설정이 있고 현재 클라이언트가 모든 항목을 표현할 수 있다면 제공된 설정대로 사용할 수 있습니다. 일반 TLS 설정만 있다면 일반 TLS 노드로 다루세요. REALITY가 모든 연결을 업그레이드하는 보편적인 방법인 것은 아니며 지연 시간을 줄여 준다고 보장하지도 않습니다. 실제 성능을 비교할 때는 서버 위치, 진입 경로, 테스트 대상, 네트워크 환경을 동일하게 맞춰야 합니다. 코어 계열 간 차이는 Xray와 V2Fly 코어의 차이를 참고하세요. 성능을 논하기 전에 호환 범위를 먼저 확인하세요.

Trojan과 Shadowsocks: TLS 의존성과 암호화 방식 비교

Trojan과 Shadowsocks는 서로 다른 설계 방향을 보여 줍니다. 일반적인 Trojan은 TLS 연결 안에서 인증과 프록시 요청을 처리하므로 보안 핸드셰이크와 인증서 검증이 올바르게 이뤄져야 합니다. Shadowsocks는 가벼운 암호화 프록시 전송에 초점을 두며, 미리 공유한 인증 정보와 합의된 암호화 방식으로 통신을 구성합니다. 둘 다 서버 주소 하나만으로 전체 설정을 복원할 수는 없습니다. 선택할 때는 서버가 어떤 진입 방식을 제공하는지 먼저 확인하고, 암호화 방식과 확장 기능을 클라이언트가 지원하는지 살펴보세요. 비밀번호 형식이 비슷하다고 프로토콜까지 호환되는 것은 아닙니다.

Trojan: 먼저 TLS 검증을 통과하는지 확인하기

Trojan 노드를 편집할 때는 주소, 포트, 비밀번호, 서버 이름을 차례로 확인하세요. 연결 주소는 진입점을 찾는 데 쓰이고 서버 이름은 보통 TLS 핸드셰이크와 인증서 검증에 사용되므로 두 값이 항상 같을 필요는 없습니다. 제공자가 서버 이름으로 특정 도메인을 지정했다면 주소란에 IP를 입력하더라도 해당 이름을 유지해야 합니다. 비밀번호는 프록시 계층의 인증 정보이지 웹사이트 로그인 비밀번호가 아닙니다. 복사할 때 앞뒤 공백, 줄바꿈, 입력기에서 바뀐 문자가 들어가지 않도록 주의하세요. 클라이언트에 표시된 비밀번호 길이가 정상이어도 원본과 일치한다는 보장은 없습니다.

인증서 오류가 발생하면 기기 시간, 서버 이름, 서버 인증서 설정부터 확인하세요. ‘안전하지 않은 연결 허용’을 일반적인 해결책으로 사용하지 마세요. 인증서 검증을 건너뛰면 연결 대상의 신원을 확인하는 보안이 약해집니다. 신뢰할 수 있는 인증서로 작동하던 노드라면 이름이나 인증서 문제를 해결하세요. 자체 신뢰 체계를 사용하는 배포 환경이라면 명시된 안내에 따라 신뢰 조건을 설정해야 합니다. 통제된 테스트에서 원인을 좁히기 위해서만 검증 설정을 임시로 조정하고, 테스트가 끝나면 원래대로 되돌린 뒤 실제 실패 원인을 기록하세요.

Shadowsocks: 암호화 방식 이름을 정확히 일치시키기

Shadowsocks 노드는 주소, 포트, 암호화 방식, 인증 정보가 하나의 핵심 조합을 이룹니다. 최신 설정에는 인증 암호화 방식이 흔히 사용되지만, 방식마다 키와 구현, 데이터 포장에 대한 구체적인 요구 사항이 있습니다. 암호화 방식 이름을 ‘자동 암호화’로 줄여 쓰거나 기기 성능을 이유로 다른 방식으로 바꾸면 안 됩니다. 최신 Shadowsocks 2022 방식은 키 표현과 처리 면에서 기존 방식과 다르므로 클라이언트와 코어가 해당 형식을 지원해야 합니다. 가져오기 과정에서 변환 도구가 비밀번호를 일반 문자열처럼 다시 인코딩하면 원래 의미가 손상될 수 있습니다.

공유 링크의 ss:// 형식은 한 가지로만 쓰이지 않습니다. 암호화 방식과 인증 정보 부분을 인코딩하는 형식도 있고, URI 구조가 다른 형식도 있으며, 확장 설정이 추가될 수도 있습니다. 파서는 링크 바깥 형식과 내부 항목을 모두 이해해야 합니다. 노드가 추가 확장에 의존한다면 이 페이지의 클라이언트가 기본 Shadowsocks 링크를 인식한다는 이유만으로 확장까지 실행할 수 있다고 판단하지 마세요. 제공자에게 필요한 확장과 구체적인 조건을 확인한 다음 현재 코어의 지원 여부를 살펴보세요. 안내와 무관한 구성 요소를 설치해 무작정 시험하지 마세요.

항목	Trojan	Shadowsocks
인증 정보	비밀번호	암호화 방식과 해당 인증 정보 또는 키
보안 확인 항목	TLS 서버 이름과 인증서 검증	암호화 방식과 키 형식
주요 호환 범위	전송 확장과 TLS 옵션	암호화 방식 세대와 확장 지원
UDP 동작	구현과 서버 기능에 따라 다름	암호화 방식, 구현, 배포 환경에 따라 다름

‘가볍다’고 모든 환경에서 더 빠른 것은 아닙니다

Shadowsocks의 가벼운 설계가 모든 휴대폰과 네트워크에서 배터리를 덜 쓴다는 뜻은 아닙니다. Trojan이 TLS를 사용한다고 해서 매 요청마다 전체 핸드셰이크를 다시 수행하는 것도 아닙니다. 연결 재사용, 세션 복구, 프로세서 가속, 서버 부하, 앱의 요청 패턴에 따라 결과가 달라집니다. 짧은 연결이 많다면 연결 설정 비용을 살펴보는 편이 중요하고, 장시간 전송에서는 처리량과 패킷 손실, 지속적인 암호화 부담이 더 중요합니다. 같은 기기와 네트워크에서 비교하고 프로토콜 이름만으로 성능을 판단하지 마세요.

기존 Trojan 설정이 있고 인증서 검증도 정상이라면 우선 그대로 사용하는 편이 좋습니다. 최신 Shadowsocks 암호화 방식을 사용하고 클라이언트가 모두 지원한다면 가벼운 프록시 진입점으로 활용할 수 있습니다. 음성 통화, 게임 등 UDP에 의존하는 앱을 쓸 때는 서버, 중간 진입점, 클라이언트의 트래픽 처리 방식을 모두 확인하세요. 노드가 TCP를 지원한다고 모든 앱이 작동하는 것은 아닙니다. 웹은 열리지만 특정 앱이 실패한다면 노드 유형을 바꾸기 전에 해당 트래픽이 프록시로 전달되는지, 프로토콜이 필요한 데이터를 운반하는지 구분하세요.

Xray와 V2Fly: 클라이언트와 실제 코어 구분하기

Project V는 관련 프록시 도구와 설정 방식의 중요한 기반입니다. V2Fly는 V2Ray 생태계의 커뮤니티 유지보수를 이어 가고, Xray는 이 기술 기반에서 별도의 발전을 거친 코어 계열입니다. 공통된 역사와 함께 각자의 프로토콜 확장, 전송 기능, 설정 변경도 있습니다. 이름만 다른 동일한 프로그램으로 이해해서는 안 되며, 특정 시기의 기능 목록으로 이후 모든 구현을 추정해서도 안 됩니다. 호환성을 판단하려면 현재 실행되는 코어가 해당 항목과 설정 조합을 지원하는지, 생성된 설정이 검사를 통과하는지 확인해야 합니다.

세 클라이언트의 역할

v2rayN은 노드 관리, 구독 업데이트, 라우팅 설정, 코어 실행을 담당하는 데스크톱 그래픽 클라이언트입니다. Windows의 Desktop과 WPF 버전은 주로 화면 기술과 상호작용 방식이 다르며, 프록시 프로토콜 표준이 두 종류라는 뜻은 아닙니다. macOS와 Linux 사용자도 별도의 클라이언트 이름을 찾기보다 해당 운영체제에 맞는 v2rayN 설치 항목에서 아키텍처와 패키지 형식을 선택해야 합니다. 화면은 설정을 실행 설정으로 변환하고, 실제 네트워크 연결 처리는 호출된 코어가 담당합니다. 문제를 해결할 때는 두 계층을 모두 확인해야 합니다.

Android의 v2rayNG는 주로 Xray 코어를 사용하며, v2flyNG는 V2Fly 코어를 사용하는 선택지를 제공합니다. 화면 조작이 비슷해도 모든 공유 링크, 흐름 제어 값, 보안 방식의 지원 범위가 같은 것은 아닙니다. 특히 REALITY와 Xray 전용 기능을 사용할 때는 해당 설정을 표현할 수 있는 클라이언트를 먼저 선택해야 합니다. 기존 노드가 양쪽에서 지원하는 기본 기능만 사용한다면 실제 호환 여부를 확인해 선택하세요. 클라이언트 이름에 비슷한 글자가 있다는 이유만으로 판단하지 마세요.

설정 호환은 그대로 복사하는 것과 다릅니다

공통된 설정 구조와 프로토콜 이름은 일부 이전을 가능하게 하지만, 항목의 의미와 기본값, 지원 조합은 다를 수 있습니다. 오래된 항목이 삭제되거나 실험 기능이 바뀌고 DNS 또는 라우팅 구조가 조정되면, 동일해 보이는 JSON도 다른 코어에서 실행되지 않을 수 있습니다. 그래픽 클라이언트는 보통 자체 실행 설정을 생성하며, 수동으로 넣은 사용자 설정은 같은 방식으로 변환되지 않을 수 있습니다. 코어를 바꾸기 전 일반 노드 모드인지 전체 사용자 설정 모드인지 확인하세요. 두 모드는 설정의 출처와 적용 순서가 다르므로 혼동해서는 안 됩니다.

v2rayN에서는 노드의 프로토콜과 코어 할당 옵션을 먼저 확인한 뒤 실행 로그에서 실제로 시작된 프로그램을 확인하세요. 화면 구성에 따라 메뉴 이름은 조금 다를 수 있으므로 코어 설정, 프로토콜별 코어, 노드 편집 항목을 찾아보세요. 전역 드롭다운 하나를 바꾸면 모든 노드에 적용된다고 가정하지 마세요. 로그에 알 수 없는 항목이나 지원되지 않는 보안 유형이 표시되면 먼저 코어 선택과 설정의 출처를 확인하세요. 설정 검사를 통과했는데 연결되지 않는다면 서버 설정을 점검하세요. 두 종류의 오류를 모두 네트워크 문제로 돌리지 마세요.

업데이트와 롤백을 위해 기존 설정 기록하기

업데이트 전에는 현재 작동하는 노드, 라우팅 모드, DNS 설정, 코어 할당을 기록해 구독과 트래픽 처리 방식을 동시에 바꾸지 않도록 하세요. 업데이트 후에는 같은 노드와 같은 대상을 먼저 검증한 다음 새 기능을 시도하세요. 클라이언트 업데이트에는 코어 변경이 포함될 수도 있고 화면이나 설정 생성만 바뀔 수도 있습니다. 시스템에 별도 코어 파일을 넣었다고 해서 클라이언트가 이를 사용한다는 뜻은 아닙니다. 롤백할 때는 출처와 호환성 안내가 명확한 설치 방식을 이용하고 관련 설정도 함께 복구하세요. 여러 디렉터리의 파일을 섞으면 실행 상태를 추적하기 어려워집니다.

오픈 소스라고 해서 모든 서드파티 설정이 검토되었거나 특정 코어가 모든 환경에서 자원을 덜 사용한다는 뜻은 아닙니다. 이 사이트는 세 클라이언트의 다운로드 경로와 설정 참고 자료를 제공하며, 별도의 코어 다운로드 영역은 운영하지 않습니다. 설치 항목은 클라이언트 다운로드 페이지에서 확인하세요. 클라이언트가 메인 화면에 들어가기 전에 종료된다면 시작 시 강제 종료 문제 해결 안내에 따라 실행 조건부터 확인하세요. 시작도 되지 않은 상태에서 노드 프로토콜을 반복해서 바꾸지 마세요.

구독 형식과 가져오기: 주소·내용·항목 누락 확인

구독은 여러 노드 설정을 가져오는 통로이지 특정 프록시 프로토콜이 아닙니다. 구독 주소에서 여러 공유 링크, 인코딩된 텍스트, 특정 클라이언트 전용 구조가 반환될 수 있습니다. 클라이언트는 먼저 데이터를 가져오고 외부 형식을 파싱한 다음 각 노드를 내부 모델로 변환합니다. 따라서 브라우저에서 구독 주소가 열린다는 사실은 가져오기 단계가 정상일 가능성만 보여 줍니다. 실제로 가져올 수 있는지, 모든 설정이 보존되는지, 실행 가능한지는 각각 따로 확인해야 합니다. 단계를 구분하면 무작정 프로토콜을 바꾸는 일을 막을 수 있습니다.

구독 주소와 단일 공유 링크의 차이

단일 공유 링크는 보통 프로토콜별 URI 접두사로 시작하며 한 노드의 주소, 인증 정보, 추가 설정을 담습니다. 구독 주소는 대개 접속 인증 정보가 포함된 웹 주소이며, 클라이언트가 접속하면 여러 노드가 반환됩니다. 각각 알맞은 입력란에 넣어야 합니다. 단일 링크를 구독 그룹의 URL 입력란에 넣으면 업데이트가 실패할 수 있고, 구독 주소를 일반 서버 주소로 입력해도 프록시 연결은 되지 않습니다. 처음 설정할 때는 링크 형식을 확인한 뒤 ‘클립보드에서 공유 링크 가져오기’ 또는 구독 그룹 설정을 선택하세요.

v2rayN에서 구독 그룹 설정을 열고 그룹을 추가한 다음 설명을 입력하세요. 전체 주소를 ‘주소 (URL) (선택 사항)’에 넣고, 필요하면 업데이트를 켠 뒤 해당 그룹을 업데이트합니다. 예시 주소 https://example.com/sub?token=xxxx는 입력란 위치를 보여 주기 위한 것으로, 실제 노드가 들어 있지 않습니다. 본인 주소를 복사할 때는 쿼리 매개변수를 유지하고 물음표 뒤의 내용을 삭제하지 마세요. 메신저에서 붙은 줄바꿈이나 끝의 문장 부호도 함께 입력하지 않도록 주의하세요. 구독 주소에는 접근 권한 정보가 포함되므로 공개 화면, 로그 공유, 확인되지 않은 변환 서비스에 노출하지 마세요.

디코딩에 성공해도 모든 설정이 보존되는 것은 아닙니다

VMess 공유 형식은 인코딩된 구조를 사용하는 경우가 많고, VLESS·Trojan·Shadowsocks 링크는 보통 URI에 각각의 설정을 담습니다. 공유 규격마다 경로, 서버 이름, 지문, 흐름 제어의 이름이 항상 같지는 않으며 확장 항목은 변환 과정에서 특히 쉽게 누락됩니다. 가져온 뒤 노드 하나를 선택해 편집 화면을 열고 원본과 프로토콜, 전송 방식, 보안 유형, 인증 항목을 대조하세요. 이름, 주소, 포트가 표시되더라도 REALITY 공개 키나 WebSocket 경로가 비어 있다면 가져오기가 완전하지 않은 것입니다.

일부 구독 응답은 다른 설정 체계를 대상으로 하며 내부 노드 항목이나 규칙 구조가 다릅니다. 파일 확장자만 바꿔 현재 클라이언트의 기본 구독 형식으로 만들 수 없으며, 모든 클라이언트가 자동 변환한다고 가정해서도 안 됩니다. 먼저 제공자에게 v2rayN 또는 해당 Android 클라이언트용 형식을 요청하세요. 변환이 꼭 필요하다면 변환 도구가 어떤 항목을 이해하고 어떤 구조를 출력하는지, 인증 정보가 기기 밖으로 전송되는지 확인해야 합니다. 변환된 노드는 다시 항목별로 검토하세요. 특히 보안 계층과 전송 확장을 확인하고 노드 수만 비교해서는 안 됩니다.

업데이트 후 노드와 수동 설정 관리하기

구독을 업데이트하면 노드 목록이 다시 만들어질 수 있습니다. 수동으로 바꾼 이름, 경로, 코어 연결 설정이 유지되는지는 클라이언트의 관리 방식에 따라 다릅니다. 임시 비교가 필요하면 노드를 별도 그룹에 복사하고 메모에 변경 내용을 기록하세요. 구독 그룹을 장기간 수동 설정을 보관하는 곳으로 사용하지 마세요. 업데이트 후에는 선택한 노드가 여전히 있는지 확인하고 필터 조건이 대상 노드를 제외하지 않았는지 살펴보세요. 목록이 비어 있다고 서버에 노드가 없다는 뜻은 아닙니다. 반환 형식, 권한, 필터, 파싱 단계의 문제일 수도 있습니다.

자동 업데이트 간격은 제공자의 제한과 실제 사용 빈도에 맞춰 설정하세요. 자주 가져온다고 노드 지연 시간이 줄어들지는 않으며 백그라운드 실행, 요청 실패, 접속 부담이 늘 수 있습니다. 업데이트가 실패하면 로그를 읽고 연결 오류, 권한 오류, 형식 오류 중 무엇인지 확인하세요. 로그를 공개하기 전에는 전체 URL, 사용자 ID, 비밀번호를 가리세요. 구독과 노드의 기본 관계는 초보자를 위한 자주 묻는 질문 10가지를 참고하고, 실제 조작 단계는 입문 가이드의 가져오기 절에서 확인하세요.

성능과 모바일 배터리: 연결 수명 주기에 따라 비교하기

프로토콜 성능에는 환경과 관계없이 적용되는 고정 순위가 없습니다. 한 번의 접속에도 도메인 조회, 프록시 진입점 연결, 외부 보안 핸드셰이크, 프록시 인증, 대상까지의 전달이 포함될 수 있으며, 그 뒤에야 지속 전송이 시작됩니다. 테스트마다 이 가운데 일부만 측정합니다. TCP 포트 테스트는 진입점이 연결을 받아들이는지 보여 줄 뿐, 인증 정보가 맞고 목적지에 접근할 수 있다는 뜻은 아닙니다. 실제 연결 테스트가 실제 요청에 더 가깝더라도 결과는 테스트 대상의 영향을 받습니다. 어떤 구간을 측정했는지 먼저 파악한 뒤 프로토콜의 속도를 비교하세요.

첫 요청, 지속 처리량, 자원 사용량

첫 요청은 DNS, 연결 왕복 시간, 보안 핸드셰이크의 영향을 더 많이 받습니다. 지속 다운로드에서는 회선 대역폭, 패킷 손실, 혼잡 제어, 서버 부하, 암호화 처리 능력이 더 중요합니다. 짧은 테스트에서 지연 시간이 낮았다고 대용량 파일도 더 빨리 내려받을 수 있는 것은 아닙니다. 프로세서에 하드웨어 가속이 있으면 일부 암호화 연산의 부담이 줄 수 있지만, 기기 부하가 높거나 절전 상태라면 같은 설정도 다르게 작동할 수 있습니다. 암호화 방식은 이론적 처리량을 높이려고 바꾸는 것이 아니라 서버가 지정한 값을 따라야 합니다.

연결 재사용은 반복적인 연결 설정 비용을 줄일 수 있지만 여러 요청을 하나의 공유 통로에 모으므로 장애 영향과 혼잡 양상은 구현마다 달라집니다. 재사용, 전송 프로토콜, 앱 자체의 연결 풀이 겹쳐 작동할 수 있습니다. 화면의 재사용 스위치를 언제나 효과적인 속도 향상 옵션으로 이해해서는 안 됩니다. 연결이 안정적이라면 기본값이나 제공자 권장 설정을 유지하고, 특정 앱에서 문제가 생기면 해당 옵션만 따로 시험하세요. 매번 설정 하나씩 바꾸고 짧은 요청, 장시간 연결, 동시 요청을 살펴보세요. 지연 시간 테스트만 반복해서는 안 됩니다.

모바일 배터리는 백그라운드 동작의 영향을 함께 받습니다

Android 기기의 배터리 소모는 암호화만으로 결정되지 않습니다. 지속적인 VPN 서비스, 무선 네트워크 깨우기, 상태 확인 요청, DNS 요청, 백그라운드 동기화, 반복적인 재연결도 배터리에 영향을 줍니다. 신호가 약하거나 Wi-Fi와 모바일 네트워크를 자주 오가면 무선 모듈의 전력 소모가 프로토콜 차이보다 더 커질 수 있습니다. 노드가 계속 끊겼다 연결되면 한 번의 암호화 비용이 적어도 전체 전력은 줄지 않을 수 있습니다. v2rayNG와 v2flyNG를 비교할 때는 양쪽에서 완전히 지원되는 동등한 설정을 사용해야 합니다. 그렇지 않으면 호환성 오류를 측정하게 될 수 있습니다.

먼저 백그라운드 배터리 제한 때문에 VPN 서비스가 자주 중단되는지 확인한 다음 클라이언트 로그에서 재연결 횟수를 살펴보세요. 계속 연결해야 하는 앱은 시스템 설정에서 해당 앱의 백그라운드 실행을 허용할 수 있지만, 이 경우 기기 전체의 전력 조건이 달라지므로 실제 필요에 맞춰 판단해야 합니다. VPN 기능이 있는 앱을 여러 개 동시에 켜 놓고 서로 트래픽을 선점하는 현상을 프로토콜 전력 소모로 오인하지 마세요. 화면을 잠근 뒤에만 연결이 끊긴다면 노드 보안 계층을 바꾸기 전에 시스템 백그라운드 정책, 네트워크 전환, 연결 유지 동작부터 살펴보세요.

측정 항목	주요 의미	바로 단정할 수 없는 내용
포트 연결 시간	진입점까지 연결되는 조건	전체 프록시 경로의 정상 동작
실제 연결 지연 시간	지정한 대상에 보낸 단일 프록시 요청	모든 앱에서 속도가 동일함
지속 처리량	특정 시간 동안의 전송 성능	첫 요청이 반드시 더 빠름
백그라운드 배터리	전체 실행 조건에서 소비되는 전력	프로토콜 이름만으로 결정됨

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

같은 기기와 네트워크, 비슷한 시간대에 동일한 테스트 대상을 선택하고 노드, 코어, 트래픽 처리 방식, 라우팅 모드를 기록하세요. 테스트 요청이 실제로 해당 노드를 거치는지 먼저 확인한 다음 첫 접속, 재방문, 지속 전송을 각각 살펴보세요. 모바일 배터리를 비교할 때는 화면 켜짐 시간, 신호 품질, 백그라운드 작업을 비슷하게 맞춰야 합니다. 짧은 시간 동안 배터리 잔량이 변한 것만으로 차이를 판단할 수는 없습니다. 획일적인 성능 향상 비율을 지어내거나 지역이 다른 서버의 결과를 프로토콜 설계 탓으로 돌리지 마세요.

안정적인 일상 사용이 목적이라면 모든 설정이 호환되고 재연결이 적으며 앱이 정상 작동하는 구성을 먼저 선택한 뒤 체감 응답 시간을 비교하세요. 클라이언트의 여러 속도 측정 메뉴가 무엇을 의미하는지 알고 싶다면 노드 지연 시간 테스트 안내를 참고하세요. 테스트 결과는 사용 가능한 설정 중에서 선택할 때 활용해야 합니다. 인증을 우회하거나 인증서 문제를 무시하고 누락된 설정을 가리는 데 쓰면 안 됩니다. 성능 비교 전에 이런 문제부터 해결해야 합니다.

라우팅 분할과 DNS: 트래픽이 선택한 노드로 가는지 확인하기

프로토콜 설정은 프록시 연결을 수립하는 방법을 정할 뿐, 어떤 요청이 해당 연결을 사용할지는 라우팅이 결정합니다. 시스템 프록시는 시스템 설정을 따르는 앱에 프록시 진입점을 제공하지만 모든 앱에 사용을 강제하지는 않습니다. TUN은 가상 네트워크 인터페이스로 더 많은 트래픽을 처리하지만 적절한 권한, 라우팅, DNS 설정이 필요합니다. 노드 연결 테스트는 통과했는데 특정 앱이 직접 연결된다면 트래픽 처리 범위나 규칙의 문제일 수 있으며 프로토콜이 작동하지 않는다고 단정할 수 없습니다. 문제를 살펴보기 전에 현재 어떤 트래픽 처리 방식을 쓰는지, 대상 앱이 이를 따르는지 확인하세요.

규칙 순서와 일치 정보

라우팅 규칙은 보통 정해진 순서대로 평가되며 앞에서 일치한 규칙이 이후 판단에 영향을 줍니다. 도메인 규칙에는 사용 가능한 도메인 정보가 필요하고, IP 규칙은 목적지 주소나 DNS 조회 결과를 사용합니다. geosite와 geoip는 흔히 사용하는 분류 데이터 참조이며 프록시 프로토콜이 아닙니다. 클라이언트 기본 템플릿은 서로 다른 데이터 파일이나 기본 아웃바운드 설정과 함께 동작할 수 있으므로, 규칙을 복사할 때 관련 데이터와 태그가 유효한지 확인해야 합니다. 템플릿 이름이 같아도 코어나 클라이언트가 다르면 생성되는 규칙 전체가 같다고 볼 수 없습니다.

라우팅을 직접 설정하려면 현재 구성을 먼저 복사한 뒤 필요한 최소 범위의 규칙을 추가하세요. 대상이 도메인 하나인지, 서브넷인지, 특정 앱 유형인지 명확히 하고 기존 설정을 덮어 버리는 광범위한 규칙은 피해야 합니다. 규칙이 적용되지 않는다면 앱이 도메인 이름과 IP 중 무엇을 프록시에 전달하는지, 규칙 순서와 아웃바운드 태그가 맞는지 확인하세요. 스니핑 기능은 조건에 따라 대상 정보를 보완할 수 있지만 모든 프로토콜과 요청에서 도메인을 복원할 수 있는 것은 아닙니다. 올바른 DNS와 트래픽 처리 설계를 대신하지도 않습니다. 변경 후에는 로그를 통해 실제 적용 경로를 확인하세요.

DNS 설정과 이름 조회 위치

DNS는 이름을 주소로 변환하지만, 이름을 앱이 로컬에서 조회할 수도 있고 프록시 측에 맡길 수도 있습니다. 시스템 프록시, TUN, 앱별 DNS 설정에 따라 조회 경로가 달라집니다. 시스템 DNS만 바꿔도 클라이언트 내부 조회가 바뀌지 않을 수 있고, 클라이언트 DNS만 바꿔도 앱 자체의 암호화된 조회 요청을 처리하지 못할 수 있습니다. 서버 주소를 조회하는 과정과 대상 사이트를 조회하는 과정을 구분하세요. 전자가 실패하면 프록시 진입점에 연결할 수 없고, 후자가 실패하면 노드는 연결되지만 일부 도메인만 열리지 않을 수 있습니다.

DNS 조회 방식을 고를 때는 어느 계층에서 도메인이 필요하고 어느 계층에서 IP가 필요한지 먼저 확인하세요. 도메인 이름을 원격에서 조회하게 하면 일부 로컬 DNS 차이를 피할 수 있지만, 로컬 IP 분류 규칙은 같은 방식으로 판단하지 못할 수 있습니다. 로컬에서 조회하면 IP 기반 규칙에 필요한 정보를 얻을 수 있지만 로컬 조회 결과와 원격 접속 위치가 달라질 가능성도 있습니다. 모든 배포 환경에 맞는 단일 해답은 없습니다. 클라이언트에 이미 마련된 전체 설정을 우선 사용하고 로그를 살펴 항목별로 조정하세요. 여러 안내서에서 일부씩 가져와 새로운 DNS 경로를 임의로 조합하지 마세요.

아래는 Xray 형식의 라우팅 예시로, 사설 주소를 직접 연결하는 항목의 관계를 보여 줍니다. 완성된 설정이 아니므로 기존 설정의 routing 위치에 병합해야 하며, 기존 아웃바운드 태그가 실제로 direct인지, 분류 데이터를 사용할 수 있는지 확인해야 합니다. 그래픽 클라이언트를 사용하는 일반 사용자는 라우팅 설정에서 같은 동작을 지정하는 것이 좋습니다.

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

실제로 관찰할 수 있는 경로를 따라 문제 해결하기

먼저 노드 연결을 테스트하고, 시스템 프록시 또는 TUN 상태를 확인한 다음 대상 앱을 검증하고 규칙과 DNS를 살펴보세요. LAN 기기 접속에 문제가 있다면 사설 주소 규칙, 가상 인터페이스 라우팅, 로컬 이름 조회를 확인하세요. 도메인 하나만 실패한다면 조회 결과와 규칙 적용 여부를 비교하세요. 프로토콜의 우열을 확인한다며 모든 규칙을 반복해서 지우지 마세요. 한 번에 너무 많은 조건이 달라집니다. 로그를 공개할 때는 내부 주소 계획과 접속 인증 정보를 숨기고, 문제 파악에 필요한 오류 유형과 항목 이름만 남기세요.

데스크톱과 Android는 트래픽 처리 설정이 다릅니다. 한쪽의 시스템 프록시 스위치를 다른 쪽의 VPN 권한과 같은 뜻으로 보면 안 됩니다. 라우터나 우회 라우터에 중앙 배포하는 경우 게이트웨이, 반환 경로, DNS 전달 관계까지 설계해야 하므로 데스크톱 템플릿을 그대로 복사하지 마세요. 관련 내용은 라우터와 우회 라우터 배포 개요를 참고하세요. 첫 연결은 입문 가이드의 모드 선택 절차에 따라 설정한 다음 이 장으로 돌아와 규칙을 구체화하세요.

사용 사례별 선택과 검증: 전체 설정부터 재현 가능한 연결까지

사용 중인 유효한 노드와 기기 조건에서 출발해야 하며 프로토콜 순위부터 매길 필요는 없습니다. 사용할 수 있는 구독이 있다면 해당 설정을 완전히 파싱하고 실행할 수 있는 클라이언트를 먼저 선택하세요. 직접 구축하거나 배포 방식을 협의한다면 유지보수 조건, 보안 방식, 앱 요구 사항을 비교하세요. 데스크톱에서는 v2rayN으로 노드를 관리하고 Android에서는 코어 지원 여부에 따라 v2rayNG와 v2flyNG를 선택하세요. 다운로드 패키지의 프로세서 아키텍처는 설치와 실행 가능 여부를 좌우하고, 프로토콜 유형은 연결 동작에 영향을 줍니다. 둘은 서로 대신할 수 없습니다.

일상적인 데스크톱과 모바일 기기의 선택 기준

데스크톱에서 일상적으로 사용할 때는 안정적인 설정 출처, 명확한 라우팅 방식, 확인하기 쉬운 로그를 우선하세요. VMess, Trojan, Shadowsocks 노드가 정상 작동한다면 이름을 바꾸려고 다시 설정할 필요는 없습니다. VLESS와 REALITY 조합을 받았다면 Xray 지원 여부와 보안 항목 전체를 확인한 뒤 테스트하세요. 여러 기기에서 같은 구독을 쓸 때는 각 기기의 파싱 결과를 확인해야 합니다. 데스크톱에서 성공했다고 Android에서도 모든 확장 항목이 유지된다고 볼 수는 없습니다. 기기마다 시스템 시간, 권한, 트래픽 처리 범위도 따로 확인하세요.

모바일에서 네트워크를 자주 바꾸는 경우 재연결 후 복구와 백그라운드 서비스의 안정성을 먼저 살펴보세요. 장시간 전송에서는 처리량과 발열을 확인하세요. 음성 통화 등 UDP 기반 앱은 클라이언트의 트래픽 처리부터 프로토콜 전송, 서버 전달, 목적지 접속까지 전체 경로를 검증해야 합니다. 웹페이지가 열린다는 사실만으로는 이 조건을 모두 확인할 수 없습니다. 두 노드가 서로 다른 지역이나 회선에 있다면 결과는 우선 전체 배포 환경의 차이를 반영합니다. 이를 VLESS, Trojan, Shadowsocks 중 특정 프로토콜 이름의 성능으로 단정할 수 없습니다.

설정을 한꺼번에 바꾸지 말고 단계별로 오류 확인하기

첫 번째 단계는 클라이언트 실행입니다. 화면이 열리지 않는다면 운영체제 실행 조건, 권한, 설치 아키텍처를 확인하세요. 코어가 시작되지 않는다면 설정 파싱 오류와 기능 지원 여부를 살펴보세요. 두 번째 단계는 진입점 연결로 주소, 포트, 도메인 조회, 전송 진입점을 확인합니다. 세 번째 단계는 보안 핸드셰이크와 인증입니다. 기기 시간, 서버 이름, 인증서, 사용자 ID, 비밀번호, REALITY 설정을 점검하세요. 네 번째 단계에서 목적지 접속과 라우팅을 확인합니다. 단계를 구분해야 다른 계층의 문제를 잘못된 방법으로 고치지 않을 수 있습니다.

예를 들어 ‘연결 시간 초과’는 어떤 단계가 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 비밀번호가 틀렸다는 증거는 아닙니다. ‘알 수 없는 항목’은 설정이나 코어 호환성 문제에 가까우므로 DNS를 먼저 바꿀 필요가 없습니다. ‘인증서 이름 불일치’는 암호화 방식이 아니라 서버 이름과 인증서 설정을 확인해야 합니다. 오류 문구는 구현마다 다를 수 있으므로 앞뒤 로그를 읽고 구독 가져오기, 코어 시작, 프록시 요청 중 어느 단계에서 발생했는지 파악하세요. 서로 다른 단계의 같은 ‘실패’ 메시지를 같은 문제로 취급하지 마세요.

재현 가능한 연결 테스트 완료하기

구독 업데이트가 완료됐고 설정 항목이 누락되지 않았는지 확인한 다음 노드를 실행해 코어 로그에 설정 오류가 없는지 살펴보세요. 이어서 명확한 테스트 대상을 확인하고 요청이 의도한 아웃바운드를 거치는지 검증하세요. 노드를 그대로 둔 채 대상 앱과 화면 잠금 후 복구를 테스트하세요. 비교가 필요하면 설정을 복사해 근거가 있는 항목 하나만 바꾸세요. 검증 중에 구독 업데이트, 코어 변경, TUN 활성화, DNS 교체를 동시에 하지 마세요. 결과가 나아져도 무엇이 효과가 있었는지 알 수 없고 다른 기기에서 재현하기도 어려워집니다.

장기적으로 관리할 때는 원인을 추적할 수 없는 설정 차이를 줄이는 것이 중요합니다. 그룹마다 용도를 기록하고 구독에서 생성된 노드와 수동 테스트 노드를 구분하세요. 업데이트 후에는 보안 항목과 실제 코어를 표본으로 확인하세요. 외부에 도움을 요청할 때는 클라이언트 이름, 운영체제, 실패 단계, 민감 정보를 가린 로그를 설명하고 구독 주소와 인증 정보는 공개하지 마세요. 제공자가 서버 프로토콜이나 보안 설정을 변경했다면 새 전체 설정을 요청하세요. 기존 노드에 새 항목을 추측해 추가하지 마세요. 각 변경의 이유를 설명할 수 있는 편이 옵션을 쌓는 것보다 안정적인 사용에 도움이 됩니다.

최종 선택은 세 가지 조건으로 요약할 수 있습니다. 서버가 해당 프로토콜 조합을 실제로 제공하고, 클라이언트와 코어가 필요한 설정 항목을 모두 지원하며, 대상 앱이 실제 네트워크에서 정상 작동해야 합니다. 이 조건을 충족한 뒤 응답 시간, 지속 전송, 백그라운드 배터리 사용량을 비교하세요. 설치 파일과 패키지 형식은 클라이언트 다운로드 페이지에서 확인하고, 기본 조작은 입문 가이드를 참고하세요. 개념별 내용은 이 페이지의 목차에서 찾아볼 수 있습니다. 프로토콜은 설정 조건 중 하나일 뿐, 측정과 문제 해결을 대신하는 결론이 아닙니다.