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

01 / SELECTION MODEL

프로토콜·전송·보안 계층과 코어부터 구분하기

클라이언트의 ‘프로토콜 유형’은 첫 번째 선택일 뿐입니다

그래픽 클라이언트에서는 보통 VMess, VLESS, Trojan, Shadowsocks를 노드 유형으로 표시하지만, 하나의 연결은 이 항목 하나만으로 결정되지 않습니다. 전체 연결 경로는 최소 네 계층으로 나눌 수 있습니다. 애플리케이션 프로토콜은 인증과 요청 형식을 담당하고, 전송 방식은 데이터를 TCP, WebSocket, gRPC 등의 채널에 어떻게 담을지 결정하며, 보안 계층은 암호화와 상대방 신원 확인을 맡고, 코어는 설정을 해석해 실제 연결을 수립합니다. REALITY는 애플리케이션 프로토콜이라기보다 보안 및 핸드셰이크 기능에 가깝습니다. 이 개념들을 하나의 이름으로 섞어 이해하면 ‘프로토콜을 맞게 골랐는데도 연결되지 않는’ 상황을 잘못 판단하기 쉽습니다.

일반적인 VLESS 조합을 예로 들면 노드에 VLESS, TCP, REALITY, XTLS Vision, 서버 이름, 공개 키 등의 필드가 함께 들어갈 수 있습니다. VLESS는 인증과 요청 형식만 설명하고, TCP는 하위 전송을 나타내며, REALITY는 핸드셰이크와 신원 확인을 처리하고, Vision은 데이터 스트림 처리 방식에 영향을 줍니다. 클라이언트는 공유 링크를 가져온 뒤 이 요소들을 하나의 아웃바운드 설정으로 기록합니다. 핵심 필드가 빠지거나 표기가 달라지거나 현재 코어가 인식하지 못하는 위치에 있으면 최종 동작이 노드 이름과 다르게 나타날 수 있습니다.

선택은 서버의 기존 설정에서 시작해야 합니다

프로토콜은 클라이언트의 선호만으로 일방적으로 바꿀 수 없습니다. 클라이언트 노드는 서버와 프로토콜, 포트, 인증 정보, 전송 방식 및 보안 매개변수가 서로 맞아야 합니다. 구독이 이미 설정된 구성을 제공한다면 VLESS를 수동으로 VMess로 바꾸거나 서버 주소와 포트만 남겨 노드를 새로 만드는 대신, 클라이언트가 모든 필드를 정확히 인식하는지 확인해야 합니다. 이름이 비슷하다고 서로 교체할 수 있는 것은 아니며, UUID가 같아도 나머지 매개변수를 대신할 수 없습니다. 노드 편집기의 각 옵션은 본질적으로 서버 설정을 매핑한 값입니다.

양쪽 설정을 직접 결정할 수 있다면 다음 순서를 따르세요. 먼저 양쪽 코어의 지원 범위를 확인하고, 애플리케이션 프로토콜을 정한 다음, 보안 계층과 전송 방식을 결정하고, 마지막으로 클라이언트 가져오기와 유지 관리 편의성을 검토합니다. 대부분의 새 구성에서 VLESS는 가벼운 프로토콜 계층을 제공해 TLS나 REALITY 같은 보안 기능과 조합하기 좋습니다. VMess는 기존 설계 요소가 더 많은 프로토콜 계층으로, 오래된 구성에서 자주 사용됩니다. Trojan은 비밀번호 인증과 TLS 사용 방식을 결합하고, Shadowsocks는 구조가 단순하며 지원 클라이언트가 많습니다. 네트워크 환경, 서버 구현, 유지 관리 목표를 배제한 절대적인 순위는 없습니다.

이름이 아니라 필드의 완전성으로 호환성을 판단하기

클라이언트가 특정 노드를 지원하는지 판단하려면 최소한 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식, 보안 방식, 서버 이름, 지문, 경로 또는 서비스 이름 등의 필드를 확인해야 합니다. 클라이언트 목록에 노드가 표시된다고 해서 모든 필드가 올바르게 전달된 것은 아닙니다. 구독 변환, 오래된 구독 템플릿 또는 코어가 다른 구성에서 가져오기를 수행하면 인식하지 못하는 확장 항목이 버려져, 노드가 완전해 보여도 실제로는 기본값으로 돌아갈 수 있습니다. 이런 경우 노드 편집 화면을 열어 원본 링크나 서버 안내와 항목별로 비교하고, 클라이언트 로그에서 알 수 없는 필드, 핸드셰이크 실패 또는 설정 해석 관련 메시지를 확인하세요.

따라서 프로토콜 선택의 기본 원칙은 특정 이름을 좇는 것이 아니라, 전체 매개변수 묶음이 서버·구독·클라이언트·코어 사이에서 빠짐없이 전달되도록 하는 것입니다. 먼저 이 계층 모델을 세워야 이후 속도, 리소스 사용량 또는 배터리 소모를 의미 있게 비교할 수 있습니다. 기본 가져오기 절차가 아직 끝나지 않았다면 먼저 빠른 설정 튜토리얼에 따라 작동하는 연결을 하나 만든 뒤, 이 페이지로 돌아와 조합을 비교하세요.

02 / VMESS & VLESS

VMess와 VLESS의 설계 차이

VMess의 배경과 설정 특징

VMess는 Project V 초기 생태계를 대표하는 프로토콜입니다. 사용자 식별자, 인증 정보, 프로토콜 계층 암호화를 자체 형식으로 구성하며, 오랫동안 다양한 V2Ray 설정과 구독 형식에서 사용되었습니다. 일반적인 노드 필드에는 서버 주소, 포트, 사용자 UUID, alterId, 전송 방식 및 보안 설정이 포함됩니다. 최신 설정에서는 높은 alterId 값에 의존하지 않는 경우가 많지만, 오래된 구독이나 튜토리얼에는 여전히 해당 필드가 남아 있을 수 있습니다. 가져온 뒤에는 서버가 제공한 값을 기준으로 확인하고, 필드가 오래되어 보인다는 이유만으로 임의로 수정하지 마세요.

VMess의 장점은 주로 축적된 생태계와 기존 호환성에 있습니다. 많은 구독 생성기, 패널 형식 및 클라이언트가 기본 필드를 안정적으로 인식하므로 기존 설정을 이전할 때 부담이 적습니다. 반면 프로토콜 계층이 담당하는 작업이 상대적으로 많고, 필드 의미가 전송 계층이나 보안 계층과 섞여 이해되기 쉽습니다. 리소스가 제한된 기기에서는 이런 차이가 단독으로 사용 경험을 결정하는 경우가 드물지만, 동시 연결이 많거나 자주 깨어나거나 장시간 실행할 때는 추가 처리가 CPU 시간과 배터리 사용량에 영향을 줄 수 있습니다.

VLESS는 보안 책임을 조합 계층에 맡깁니다

VLESS는 프로토콜 계층을 단순화하는 데 초점을 둡니다. 사용자 식별자로 인증하지만 VLESS 자체에서 완전한 데이터 암호화를 중복 제공하지 않고, TLS·REALITY 같은 외부 보안 계층에 의존해 완전한 연결을 구성합니다. 이러한 계층 분리는 역할을 명확히 하며 Xray 생태계의 확장 기능을 조합할 여지도 남깁니다. 클라이언트에서 VLESS를 선택한 뒤에도 security, flow, transport, serverName 등의 항목을 계속 확인해야 합니다. 주소, 포트, UUID만 입력해서는 원래 노드를 재현하기에 부족한 경우가 많습니다.

‘VLESS가 더 가볍다’고 해서 모든 환경에서 반드시 더 빠르다는 뜻은 아닙니다. 전체 연결 시간에는 도메인 조회, TCP 연결 수립, 보안 핸드셰이크, 인증, 첫 요청 및 지속적인 전송이 포함됩니다. 프로토콜 계층의 처리가 줄어드는 것은 그중 일부에만 영향을 줍니다. 네트워크 왕복 시간이 길다면 적은 로컬 연산보다 핸드셰이크 횟수와 연결 재사용이 더 큰 영향을 줍니다. 대용량 파일을 주로 전송한다면 혼잡 제어, 회선 품질, 서버 출구가 더 중요합니다. 휴대폰에서 짧은 연결을 자주 만들면 핸드셰이크와 애플리케이션 깨우기가 다시 핵심이 됩니다. 따라서 성능은 VLESS와 VMess라는 네 글자만 비교하지 말고 전체 조합 안에서 판단해야 합니다.

Vision·TLS·REALITY는 반드시 함께 확인해야 합니다

일부 VLESS 설정에는 특정 TCP 및 보안 조합과 함께 사용하는 Vision 등의 flow 필드가 포함됩니다. 이 필드는 장식용 태그가 아니라 양쪽의 협상과 데이터 처리에 관여합니다. 구독을 가져온 뒤 flow가 비어 있거나 값이 잘렸거나 현재 코어가 해당 조합을 지원하지 않으면 핸드셰이크 후 연결이 실패할 수 있습니다. TLS 환경에서는 서버 이름, 인증서의 도메인, 애플리케이션 계층 프로토콜 옵션을 확인해야 합니다. REALITY 환경에는 공개 키, 짧은 식별자, 서버 이름, 클라이언트 지문 등의 매개변수도 추가됩니다. 구체적인 의미는 3장에서 설명합니다.

설정 편집기에 있는 ‘인증서 검증 건너뛰기’는 진단용 옵션이며 장기적인 해결책으로 적합하지 않습니다. 인증서 오류는 보통 기기 시간, 서버 이름, 인증서 배포 또는 구독 필드에 문제가 있음을 나타냅니다. 검증을 바로 완화하면 원인을 가려 이후 기기 이전이나 구독 업데이트 때 다시 실패할 수 있습니다. 더 안전한 순서는 시스템 시간을 확인하고, 노드의 서버 이름을 점검한 뒤, 서버의 해당 포트가 실제로 예상한 TLS 설정을 제공하는지 확인하는 것입니다.

두 프로토콜의 실제 선택 기준

기존 VMess 설정이 안정적으로 작동하고 여러 기기에서 모든 필드를 정상적으로 가져올 수 있다면, 이름이 바뀌었다는 이유만으로 즉시 다시 만들 필요는 없습니다. 새로 배포하면서 Xray 생태계를 사용하고 REALITY·Vision 등의 조합이 필요하다면 VLESS가 일반적으로 더 자연스럽습니다. V2Fly와 Xray 사이에서 폭넓은 호환성을 유지해야 한다면 양쪽이 모두 이해하는 기본 필드를 우선 사용하고, 특정 확장을 공통 설정으로 착각하지 않도록 주의해야 합니다. 구독 관리자는 단순히 ‘VLESS 노드’라고 표시하기보다 프로토콜·전송·보안 계층을 명확히 출력하는 것이 중요합니다.

v2rayN에서는 노드 편집 화면에서 전체 조합을 확인할 수 있습니다. Android에서 v2rayNG를 사용할 때도 노드 목록 이름만 보지 말고 전송 및 보안 옵션을 펼쳐 확인해야 합니다. v2flyNG는 V2Fly 코어를 중심으로 하므로 V2Fly가 인식할 수 있는 설정에 적합합니다. 세 클라이언트의 설치 경로와 지원 플랫폼은 다운로드 페이지에서 확인할 수 있습니다.

03 / TROJAN, SHADOWSOCKS & REALITY

Trojan·Shadowsocks·REALITY의 역할 구분

Trojan은 프로토콜이며, 핵심은 올바른 TLS 매개변수입니다

Trojan은 비밀번호 인증을 사용하고 TLS 위에서 연결을 수립합니다. 클라이언트 노드에는 일반적으로 서버 주소, 포트, 비밀번호, 서버 이름 및 인증서 검증 관련 옵션이 필요합니다. 여러 확장 필드를 포함한 VLESS보다 겉보기 설정은 단순하지만 TLS 매개변수는 여전히 연결 성립의 핵심입니다. 서버 주소는 도메인이나 IP일 수 있고, 서버 이름은 보통 TLS 핸드셰이크에서 이름 일치에 사용됩니다. 두 값이 같은 경우도 있고 다른 경우도 있습니다. 구독 변환 과정에서 주소만 남고 서버 이름이 사라지면 인증서 이름 불일치가 발생할 수 있습니다.

Trojan은 성숙한 TLS 조합이 필요하고 설정 의미를 비교적 직접적으로 유지하고 싶은 상황에 적합합니다. 성능은 TLS 핸드셰이크, 연결 재사용, 하위 전송의 영향을 받으며, 필드가 적다고 해서 모든 비용이 자동으로 줄어드는 것은 아닙니다. 장시간 연결에서는 최초 핸드셰이크 비용이 이후 데이터에 분산되지만, 짧은 연결이 많다면 핸드셰이크 횟수를 더 중요하게 봐야 합니다. 클라이언트 로그에 TLS 관련 오류가 표시되면 로컬 프록시 모드를 반복해서 바꾸기보다 이름, 시간, 서버 설정부터 해결하세요.

Shadowsocks의 간결함은 명확한 암호화 방식에서 나옵니다

Shadowsocks 노드의 핵심 필드는 보통 서버, 포트, 비밀번호, 암호화 방식입니다. 구조가 비교적 간결하고 여러 플랫폼과 코어에서 구현되어 있어 기본 호환성과 낮은 설정 복잡도를 중시하는 상황에서 자주 사용됩니다. 암호화 방식은 양쪽이 지원하고 완전히 일치해야 합니다. 클라이언트 드롭다운에 특정 방식이 있다고 해서 서버도 반드시 그것을 사용하는 것은 아닙니다. 구독의 방식 이름이 변환 도구로 바뀌어도 인증이 실패할 수 있습니다.

암호화 방식마다 프로세서 성능과 구현 품질에 요구하는 조건이 다릅니다. 최신 기기는 대칭 암호화를 대체로 잘 처리하지만, 저전력 기기나 구형 프로세서, 높은 동시 연결 환경에서는 차이가 나타날 수 있습니다. 평가할 때는 웹페이지를 한 번 여는 대신 지속적인 처리량에서 CPU 사용량, 온도, 안정성을 확인해야 합니다. 서버나 클라이언트 로그에 unsupported method가 표시되면 구독 원본 값으로 되돌리고 현재 코어에 해당 구현이 포함되어 있는지 확인하세요.

Shadowsocks의 간결함은 일부 고급 동작을 외부 계층이나 클라이언트 정책이 담당한다는 뜻이기도 합니다. 분할 라우팅, DNS, 시스템 프록시, 애플리케이션 연결은 프로토콜 자체의 기능이 아니므로 이런 설정 변화를 Shadowsocks 노드의 특성으로 돌려서는 안 됩니다. 같은 노드가 두 클라이언트에서 다르게 작동하는 흔한 원인은 라우팅 규칙, DNS 조회 경로 또는 시스템 연결 방식의 차이이며, 노드 프로토콜이 바뀐 것이 아닙니다.

REALITY는 다섯 번째 병렬 프록시 프로토콜이 아닙니다

REALITY는 VLESS와 함께 표시되는 경우가 많지만, 담당하는 것은 보안 핸드셰이크와 상대방 확인이며 VLESS의 프록시 요청 형식을 대체하지 않습니다. 이런 노드를 새로 만들 때는 보통 먼저 VLESS를 선택하고, 보안 방식을 REALITY로 설정한 뒤 공개 키, 짧은 식별자, 서버 이름, 지문, flow 등의 매개변수를 입력합니다. 구독 화면에 ‘REALITY 노드’라고 간단히 표시되더라도 VLESS·전송·보안 계층·흐름 제어의 네 부분으로 나누어 이해해야 합니다.

공개 키는 클라이언트가 서버 신원을 확인하는 데 사용되고, 짧은 식별자는 서버 설정에 의해 제한되며, 서버 이름은 핸드셰이크 매개변수에 관여하고, 클라이언트 지문은 핸드셰이크 특성을 설명합니다. 이 필드들은 서로 임의로 대체할 수 없습니다. 특히 일반 TLS 인증서 필드를 REALITY에 그대로 적용하거나 노드 표시 이름만으로 공개 키와 짧은 식별자를 추측해서는 안 됩니다. 서버 설정이 바뀌면 구독도 함께 업데이트해야 하며, 여러 기기를 수동으로 편집하면 일부 기기에 오래된 값이 남기 쉽습니다.

REALITY 관련 확장은 주로 Xray 코어 기능과 연결됩니다. V2Fly 코어를 사용하는 클라이언트에서는 ‘VLESS 지원’만으로 같은 REALITY 확장도 지원한다고 추론할 수 없습니다. 기본 프로토콜 호환성과 확장 기능 호환성은 따로 판단해야 합니다. 서로 다른 코어에 같은 구독을 제공한다면 코어별 그룹을 만들거나, 최소한 필요한 조건을 노드 이름에 명확히 표시해 가져온 뒤 필드가 무시되는 일을 피하세요.

세 항목을 선택할 때는 먼저 ‘이 항목이 연결 스택에서 어떤 역할을 하는가’를 확인한 다음, 클라이언트와 코어가 모든 필드를 지원하는지 확인하세요. 이 순서가 노드 이름만 보고 판단하는 것보다 신뢰할 만합니다. 가져온 뒤 노드가 사라지거나 필드가 비어 있거나 업데이트가 실패하는 문제는 자주 묻는 질문과 구독 업데이트 실패 해결에서 집중적으로 확인할 수 있습니다.

04 / PERFORMANCE & POWER

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

연결 수립·첫 응답·처리량·안정성을 먼저 구분하세요

‘속도’에는 적어도 네 가지 지표가 있습니다. 연결 수립 시간은 연결 시작부터 프로토콜 및 보안 핸드셰이크가 끝날 때까지의 시간이고, 첫 응답 시간은 요청 후 첫 유효 데이터가 도착할 때까지의 대기 시간입니다. 지속 처리량은 장시간 전송의 실제 속도를, 안정성은 네트워크 전환·유휴·지속 부하에서 연결이 유지되는지를 나타냅니다. 연결 수립 단계에서 한 번의 처리가 줄었다고 장시간 전송 처리량이 반드시 높아지는 것은 아닙니다. 반대로 처리량이 비슷해도 짧은 연결의 사용감은 같지 않을 수 있습니다.

공용 인터넷 경로, 서버 부하, 도메인 조회, TCP 혼잡 제어, 애플리케이션 자체 캐시는 프로토콜 계층의 차이보다 더 큰 영향을 주는 경우가 많습니다. 의미 있는 비교를 하려면 서버, 출구, 클라이언트, 라우팅 규칙, 테스트 시간을 고정하고 프로토콜 조합 하나만 바꿔야 합니다. 한 번 가장 빠른 결과를 고르는 것보다 여러 차례 연속 테스트를 진행해 중앙값을 기록하는 편이 평상시 성능을 더 잘 보여 줍니다. 테스트 중에는 백그라운드 동기화와 시스템 업데이트도 꺼서 추가 트래픽의 영향을 줄이세요.

프로토콜과 전송 방식이 함께 비용을 결정합니다

VMess는 프로토콜 계층에서 더 많은 처리를 담당하고, VLESS는 프로토콜 계층이 가벼우며, Trojan은 TLS에 의존하고, Shadowsocks는 선택한 암호화 방식에 따라 처리 부담이 달라집니다. 이는 계산 비용의 일부일 뿐입니다. WebSocket은 추가 프레이밍과 헤더 처리가 필요하고, gRPC는 HTTP/2 연결 관리에 의존하며, TCP 직접 연결 조합은 중간 캡슐화를 줄입니다. 구현마다 버퍼, 연결 재사용, 동시 작업 스케줄링을 처리하는 방식도 실제 리소스 사용량을 바꿀 수 있습니다.

메모리 사용량은 보통 연결 수, DNS 캐시, 라우팅 규칙 규모, 로그 수준, 그래픽 클라이언트 화면의 영향을 더 많이 받습니다. 유휴 노드 하나의 메모리 값만 비교해서는 프로토콜 비용을 대표하기 어렵습니다. 같은 수의 연결을 만들고 같은 시간 동안 같은 작업을 실행한 뒤, 코어 프로세스의 안정 구간을 관찰하는 편이 합리적입니다. 로그를 상세 수준으로 설정하면 디스크 쓰기와 텍스트 포맷팅 비용도 늘어나므로 진단이 끝나면 일반 수준으로 되돌리세요.

CPU 사용량은 기기 하드웨어와 함께 봐야 합니다. 데스크톱 프로세서는 일상적인 연결을 대체로 쉽게 처리하지만, 저전력 기기는 높은 처리량, 복잡한 암호화, 많은 규칙, 다수의 동시 연결에서 부하가 눈에 띄게 높아질 수 있습니다. CPU 사용량이 처리량에 따라 선형적으로 증가한다면 먼저 암호화와 전송 조합을 비교하세요. 유휴 상태에서도 계속 사용량이 높다면 프로토콜을 바로 바꾸기보다 재연결 반복, 구독 업데이트 작업, 비정상적인 DNS 요청, 로그 순환을 확인해야 합니다.

모바일 배터리 소모는 주로 깨우기와 네트워크 활동에서 발생합니다

모바일 기기의 배터리 효율은 암호화 알고리즘만으로 순위를 매길 수 없습니다. 지속적인 연결 유지, 잦은 재연결, Wi‑Fi와 셀룰러 네트워크 전환, 백그라운드 깨우기, DNS 조회, 다수의 짧은 연결은 무선 모듈과 프로세서를 반복해서 활성 상태로 만듭니다. 계산량이 조금 적더라도 자주 끊겨 재연결하는 조합은 계산량이 조금 더 많아도 안정적인 조합보다 배터리를 더 사용할 수 있습니다. 따라서 안정성, 연결 유지 간격, 애플리케이션 트래픽 패턴은 프로토콜 자체만큼 중요합니다.

배터리를 테스트할 때는 같은 기기, 비슷한 신호 세기, 같은 애플리케이션 작업을 사용하고, 전면 연속 사용과 백그라운드 대기 두 단계를 최소한 포함해야 합니다. 시스템 배터리 통계는 추세를 보는 데 적합하지만, 짧은 시간의 작은 변화를 결론으로 삼기에는 부족합니다. v2rayNG 또는 v2flyNG가 백그라운드에서 배터리를 많이 사용한다면 먼저 지속적인 재연결 여부, 지나치게 잦은 자동 구독 업데이트, 모든 애플리케이션 트래픽을 프록시로 보내는 라우팅, 시스템이 연결 서비스를 반복 종료하고 다시 시작하는지를 확인하세요.

메시지, 웹페이지, 가벼운 동기화가 중심이라면 최고 처리량보다 안정적인 연결과 합리적인 분할 라우팅이 중요합니다. 지속적인 다운로드나 동영상 스트리밍에서는 서버 출구와 회선 품질의 비중이 더 큽니다. 개발 도구 요청이 많다면 연결 재사용과 DNS 동작을 더 유심히 봐야 합니다. 작업을 먼저 정의해야 프로토콜 성능 비교가 상황과 동떨어진 숫자 경쟁이 되지 않습니다.

종합하면 VLESS의 단순한 프로토콜 계층은 일부 처리를 줄이는 데 유리하고, Shadowsocks도 구조가 비교적 간결하며, VMess는 기존 호환성에 강하고, Trojan은 TLS 연결 관리와 밀접한 성능 특성을 보입니다. 그러나 이런 방향성만으로 전송 방식, 구현, 네트워크 조건의 영향을 덮을 수는 없습니다. 일반 사용자는 프로토콜 이름만 보고 이론적 비용을 좇기보다 필드가 완전하고 연결이 안정적이며 코어가 명확한 노드를 우선 선택하는 편이 효과적입니다.

05 / CORE FAMILY

V2Fly와 Xray 코어 계열의 관계

공통 설정 전통이 기능의 완전한 동일성을 뜻하지는 않습니다

V2Fly와 Xray는 모두 Project V 생태계의 설정 구성 방식을 계승했으며, 일반적인 구조에는 inbounds, outbounds, routing, dns, log가 포함됩니다. 기본 VMess, VLESS, Shadowsocks, Trojan 및 라우팅 설정은 개념적으로 유사한 경우가 많아 비슷한 JSON 계층과 클라이언트 필드를 자주 보게 됩니다. 이런 구조적 유사성은 이전에 도움이 되지만 모든 확장을 직접 교환할 수 있다는 뜻은 아닙니다. 두 코어 계열은 각자 기능·필드·구현을 관리하므로 구체적인 지원 범위는 대상 코어별로 확인해야 합니다.

그래픽 클라이언트는 코어 위에서 동작합니다. v2rayN은 노드 관리, 구독, 라우팅 템플릿, 시스템 프록시, 코어 실행을 담당하며 데스크톱에서는 보통 사용자의 선택을 코어 설정으로 변환합니다. v2rayNG는 Android에서 유사한 관리 계층을 제공하고 Xray 코어 기능을 주요 기준으로 삼습니다. v2flyNG는 V2Fly 코어를 대상으로 합니다. 클라이언트 화면에 특정 옵션이 있다는 것은 해당 필드를 표현할 수 있다는 뜻일 뿐이며, 실제 적용 여부는 현재 코어와 필드 조합에 따라 결정됩니다.

Xray 확장과 V2Fly 공통 필드는 나누어 봐야 합니다

REALITY, 특정 flow 값, 일부 확장 조합은 Xray 기능과 더욱 밀접하게 연결됩니다. 이런 필드를 포함한 구독을 V2Fly를 실행 코어로 사용하는 클라이언트에 가져오면 인식하지 못하거나 무시하거나 실행에 실패할 수 있습니다. 반대로 이전할 때도 주의해야 합니다. Xray가 받아들이는 설정이라고 해서 양쪽에 모두 권장되는 공통 형식이라는 뜻은 아닙니다. 여러 코어에서 사용할 구독을 만들 때는 기본 프로토콜 노드와 특정 코어가 필요한 노드를 명확히 구분해야 합니다.

호환성은 세 계층으로 나누어 판단할 수 있습니다. 첫째는 문법으로, JSON을 해석할 수 있고 필드 유형이 올바른지 확인합니다. 둘째는 구조로, 필드가 대상 코어가 인식하는 위치에 있는지 확인합니다. 셋째는 의미로, 해당 프로토콜·전송·보안 조합이 실제로 구현되어 있는지 확인합니다. 형식 검사만 통과했다고 노드 연결이 보장되는 것은 아닙니다. 로그의 unknown field, failed to build config, unsupported security는 각각 구조 또는 의미 문제를 가리킵니다.

최소 라우팅 구조로 설정의 경계를 이해하기

아래 예시는 공통적인 라우팅 구조만 보여 줍니다. 사설 주소는 direct라는 이름의 아웃바운드로 보내고, 나머지 트래픽은 이후 규칙과 기본 아웃바운드로 처리합니다. 이 조각에는 노드 인증 정보가 포함되어 있지 않으며 routing, rule, outboundTag의 관계를 이해하는 데 사용할 수 있습니다. 실제 클라이언트는 보통 더 완전한 설정을 생성하므로 수동 수정 전에 먼저 백업을 내보내야 합니다.

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

outboundTag는 설정에 실제로 존재하는 아웃바운드 태그를 가리켜야 합니다. 클라이언트 템플릿이 직접 연결 아웃바운드에 다른 이름을 사용한다면 이 규칙만 복사할 경우 존재하지 않는 대상을 참조하게 됩니다. domainStrategy는 라우팅 단계에서 도메인과 IP 일치를 처리하는 방식을 제어합니다. DNS 설정과 관련되지만 시스템이나 코어의 전체 DNS 결정을 대신하지는 않습니다. 그래픽 클라이언트가 사전 설정 라우팅을 제공한다면 먼저 그 효과를 이해한 뒤 사용자 지정 JSON을 편집하세요.

코어를 이전할 때는 기능 목록을 항목별로 검증해야 합니다

이전은 실행 파일을 교체한 뒤 실행 여부만 확인하는 작업이 아닙니다. 먼저 현재 노드가 사용하는 프로토콜, 전송, 보안 방식, flow, 라우팅 규칙, DNS 정책, 로컬 인바운드를 나열한 다음 대상 코어에서 하나씩 확인해야 합니다. 이후 필드가 가장 단순한 노드로 기본 연결을 검증하고, 확장 노드와 분할 라우팅을 테스트하세요. 이렇게 하면 문제를 기본 실행, 프로토콜 확장, 라우팅 설정 중 하나로 좁힐 수 있어 모든 내용을 한 번에 가져온 뒤 복합 오류를 마주하는 일을 피할 수 있습니다.

설정 파일을 서로 다른 클라이언트 사이에서 장기간 양방향으로 덮어쓰는 것도 피해야 합니다. v2rayN, v2rayNG, v2flyNG는 각자 화면 모델에 따라 설정을 생성하므로 추가 필드, 태그 이름, 기본 인바운드가 다를 수 있습니다. 구독 링크는 노드 정보 전달에 적합하고, 클라이언트 백업은 같은 종류의 클라이언트 설정 복원에 적합하며, 완전한 코어 JSON은 필드 의미를 정확히 알고 있을 때 사용하는 편이 좋습니다. 세 가지의 용도는 다르므로 섞어 사용하면 클라이언트 생성 계층과 코어 실행 계층이 뒤엉키기 쉽습니다.

데스크톱에서 Windows·macOS·Linux를 지원해야 한다면 v2rayN을 이 사이트의 우선 추천 클라이언트로 사용할 수 있습니다. Android에서 Xray 설정을 중심으로 사용한다면 v2rayNG를, V2Fly 코어 방향이 필요하다면 v2flyNG를 선택하세요. 설치 패키지 종류와 시스템 아키텍처 설명은 클라이언트 다운로드 페이지에 모아 두었으며, 이 장에서는 코어와 설정의 호환 관계만 다룹니다.

06 / SUBSCRIPTION COMPATIBILITY

구독 형식과 필드 호환성

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

구독 링크는 여러 노드 정보를 일괄 전달하지만, 노드 내부에는 여전히 VMess, VLESS, Trojan, Shadowsocks 등의 프로토콜이 들어 있습니다. 일반적인 형식으로는 base64로 묶은 공유 링크 목록, 클라이언트가 인식하는 네이티브 설정, 개별 공유 링크가 있습니다. base64는 단순한 텍스트 인코딩 방식으로 프로토콜 기능을 추가하지 않으며 누락된 필드를 복구하지도 않습니다. 클라이언트는 구독을 가져온 뒤 먼저 컨테이너 형식을 인식하고 각 노드를 해석한 다음 현재 코어 설정으로 변환합니다.

공유 링크는 보통 URI scheme에 프로토콜 유형을 넣고, 본문과 쿼리 매개변수로 인증·전송·보안 정보를 표현합니다. 기본 필드는 여러 클라이언트 사이에서 전달되기 쉽지만 확장 필드는 링크 규격과 파서 구현에 의존합니다. REALITY 공개 키, 짧은 식별자, 지문, flow, gRPC 서비스 이름 등은 구독 생성기가 비표준 매개변수 이름을 사용하면 수신 측에서 무시될 수 있습니다. 노드가 목록에 표시된다는 것은 외부 형식 해석에 성공했다는 뜻일 뿐, 모든 쿼리 매개변수가 설정에 반영되었다는 의미는 아닙니다.

네이티브 JSON과 공유 링크의 용도는 다릅니다

네이티브 JSON은 완전한 인바운드, 아웃바운드, DNS, 라우팅, 로그 설정을 표현할 수 있어 단일 코어 인스턴스를 정밀하게 제어하는 데 적합합니다. 하지만 그래픽 클라이언트의 노드 데이터베이스와 완전히 같은 것은 아닙니다. 완전한 JSON을 그래픽 클라이언트로 가져오면 일부 클라이언트는 사용자 지정 설정으로 실행하고, 일부는 아웃바운드 노드만 추출하며, 일부 화면 설정은 원본 파일에 다시 기록하지 않습니다. 사용하기 전에 가져오기 메뉴가 ‘노드’, ‘구독’, ‘사용자 지정 설정’ 중 무엇을 의미하는지 확인하세요.

공유 링크는 단일 노드 전달에 더 적합해 QR 코드, 클립보드, 구독 집계에 편리하지만 복잡한 라우팅과 DNS 정책을 하나의 노드 링크에 넣어서는 안 됩니다. 구독은 노드를, 클라이언트는 로컬 라우팅을 담당하는 편이 역할이 명확합니다. 여러 기기에서 같은 분할 라우팅을 유지해야 한다면 노드 구독과 라우팅 템플릿을 따로 관리하고, 각 클라이언트에서 알맞은 형식을 사용하세요. 하나의 지나치게 복잡한 구독에 모든 설정을 맡기는 일은 피해야 합니다.

업데이트 실패와 업데이트 후 사용 불가는 서로 다른 문제입니다

업데이트 실패는 클라이언트가 구독 내용을 가져오지 못했거나 해석하지 못했다는 뜻입니다. 흔한 단서로는 접근할 수 없는 링크, 잘못된 기기 시간, 예상과 다른 응답 형식, 인증서 오류, 로컬 네트워크 출구 문제가 있습니다. 업데이트는 성공했지만 노드를 사용할 수 없다면 필드 완전성, 코어 지원, 서버 상태를 확인해야 합니다. 두 문제는 로그 위치와 처리 순서가 다릅니다. 먼저 구독 요청이 성공했는지 확인하고, 다음으로 해석된 노드 수를 확인한 뒤, 마지막으로 단일 노드 연결을 점검하면 모든 오류를 구독 링크 탓으로 돌리는 일을 피할 수 있습니다.

자동 업데이트 간격을 지나치게 짧게 설정하지 마세요. 자주 가져오면 백그라운드 깨우기가 늘고, 서버가 임시로 콘텐츠를 생성하는 동안 로컬 목록을 반복해서 덮어쓸 수도 있습니다. 노드 변경 빈도에 맞춰 주기를 정하고, 대규모 변경 전에는 클라이언트 백업을 보관하는 것이 좋습니다. 그룹 이름, 활성화 상태, 정렬, 로컬 메모는 클라이언트 자체 데이터일 수 있으며 구독 업데이트 때 유지되는지는 구현에 따라 다릅니다. 따라서 중요한 설명을 덮어쓰기 쉬운 노드 이름에만 기록해서는 안 됩니다.

여러 구독을 관리할 때는 모든 노드를 한 목록에 넣기보다 출처나 코어 요구 사항별로 그룹을 만드는 편이 문제를 찾기 쉽습니다. 기본 호환 노드, Xray 확장 노드, V2Fly 노드를 나눈 뒤 포함 또는 제외 키워드로 목록의 잡음을 줄일 수 있습니다. 구체적인 그룹 방법은 구독 그룹과 서버 키워드 필터링을, 형식 차이는 base64·네이티브 JSON·공유 링크의 차이를 참고하세요.

구독에 v2rayN은 인식하지만 다른 클라이언트는 인식하지 못하는 확장이 포함되어 있다면 원본 구독을 완전히 범용적인 형식으로 취급해서는 안 됩니다. 대상 클라이언트에 맞춰 명확하고 필드가 완전한 구독을 출력하거나 양쪽이 지원하는 기본 조합을 선택하는 편이 유지 관리 비용이 낮습니다. 설정 JSON에서 inbounds·outbounds·routing의 역할은 설정 파일 구조 단계별 해설에서 확인할 수 있습니다.

07 / CLIENT WORKFLOW

클라이언트에서 프로토콜을 선택하고 확인하기

데스크톱에서는 먼저 v2rayN으로 기준 설정을 만드세요

데스크톱 환경에서는 v2rayN을 우선 사용하세요. 설치 후 구독을 가져와 한 번 업데이트하되, 바로 노드 필드를 수정하지는 마세요. 출처가 명확한 노드를 하나 선택해 편집 화면에서 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식, 보안 방식, 서버 이름, flow 및 확장 매개변수를 기록합니다. 저장하고 연결한 뒤 클라이언트 로그에서 설정 생성, 코어 실행, 아웃바운드 연결이 정상인지 확인하세요. 이 과정에서 기준 설정이 만들어지며, 이후 성능 테스트나 프로토콜 이전은 이를 기준으로 진행해야 합니다.

노드 연결이 확인된 후 시스템 프록시와 라우팅 모드를 설정하세요. 시스템 프록시는 해당 방식을 지원하는 애플리케이션이 요청을 클라이언트로 보낼지 결정하고, 라우팅 모드는 코어에 들어온 트래픽을 프록시·직접 연결·차단 중 어디로 보낼지 결정합니다. 둘 다 프로토콜 필드가 아닙니다. VMess를 VLESS로 바꾼다고 시스템 프록시가 자동으로 켜지는 것도 아니고, 라우팅 규칙을 수정한다고 REALITY 공개 키가 채워지는 것도 아닙니다. 문제를 찾을 때 계층을 분리하면 불필요한 수정을 줄일 수 있습니다.

v2rayN이 여러 데스크톱 설치 형태를 제공한다면 다운로드 페이지 안내에 따라 적합한 인터페이스 버전을 선택하세요. 노드와 코어를 선택하는 원칙은 같습니다. Windows·macOS·Linux는 시스템 프록시 메뉴와 권한 동작이 다를 수 있지만, 클라이언트가 생성하는 아웃바운드 설정은 동일한 계층 구조를 따릅니다. 로컬 네트워크 공유가 필요하다면 수신 주소, 방화벽, 포트를 별도로 설정해야 하며, 구체적인 범위는 로컬 네트워크 연결 허용 설정 가이드에서 확인하세요.

Android에서는 코어 방향에 따라 클라이언트를 선택하세요

Xray 확장 노드를 사용할 때는 v2rayNG가 해당 필드 모델에 더 잘 맞고, V2Fly 코어가 필요하다면 v2flyNG를 사용할 수 있습니다. 구독을 가져온 뒤 먼저 노드 상세 정보를 확인하고, 특히 VLESS의 보안 방식, flow, 서버 이름, 공개 키, 짧은 식별자를 점검하세요. 모바일 화면은 공간이 제한되어 일부 필드가 고급 설정이나 전송 설정 안에 있을 수 있습니다. 목록 화면에 표시되지 않는다고 필드가 없다고 단정해서는 안 됩니다.

연결을 수립하면 시스템에 로컬 연결 서비스 상태가 표시됩니다. 애플리케이션에 트래픽이 없다면 먼저 해당 애플리케이션이 현재 분할 라우팅 규칙에 포함되는지 확인하고, 다음으로 라우팅과 DNS를 점검하세요. 연결 서비스가 반복해서 종료되면 클라이언트 로그에서 설정 해석이나 코어 시작 메시지를 확인합니다. 네트워크 전환 후에만 문제가 생긴다면 수동으로 연결을 끊었다가 다시 연결해 비교하고, 회선 전환·시스템 백그라운드 제한·노드 핸드셰이크 중 원인을 구분하세요. 프로토콜을 이전하는 동안에는 한 번에 한 항목만 바꿔야 결과를 비교할 수 있습니다.

수동 노드는 검증에 적합하지만 장기 구독을 대신할 수는 없습니다

수동 노드 생성은 특정 매개변수 묶음이 작동하는지 확인하는 데 적합합니다. 만들 때는 프로토콜부터 시작해 서버, 포트, 인증 정보, 전송 및 보안 계층을 순서대로 입력하고, 저장 직후 편집 화면으로 돌아가 다시 확인하세요. 일부 클라이언트는 빈 필드에 기본값을 기록할 수 있으므로, 재확인을 통해 그 기본값이 서버 요구 사항과 다른지 발견할 수 있습니다. 테스트가 성공했더라도 노드가 구독으로 관리된다면 각 기기에 수동 복사본을 장기간 남기지 말고 구독 출력을 수정해야 합니다.

구독 노드를 로컬에서 수정하면 다음 업데이트 때 변경 사항이 덮어써지거나 중복 노드가 생길 수 있습니다. 임시로 문제를 확인해야 한다면 노드를 로컬 그룹에 복사해 복사본을 수정하고 원본은 보존하세요. 문제가 확인되면 올바른 필드를 구독 소스나 서버 설정에 반영한 뒤 임시 복사본을 삭제합니다. 이렇게 하면 원본 설정·진단 설정·최종 설정을 구분할 수 있어 몇 주 뒤 어떤 항목이 현재 기준인지 헷갈리지 않습니다.

로그는 단계별로 읽어야 합니다

설정 해석 단계에서는 필드 유형, 알 수 없는 필드, 아웃바운드 생성 오류를 확인합니다. 코어 시작 단계에서는 포트 사용 중, 권한, 로컬 수신을 확인합니다. 연결 단계에서는 도메인 조회, TCP 연결, 보안 핸드셰이크, 인증을 확인합니다. 라우팅 단계에서는 요청이 최종적으로 어떤 아웃바운드 태그에 매칭되었는지 확인합니다. 로그의 마지막 줄이 반드시 원인은 아니므로 같은 연결 시도의 시작부터 뒤로 읽어야 합니다. 진단이 끝나면 일반 로그 수준으로 되돌려 불필요한 기록이 장기간 쌓이지 않게 하세요.

처음 설정할 때는 V2Ray 사용 튜토리얼에 따라 구독 가져오기, 노드 연결, 검증을 진행하면 됩니다. 이 페이지의 확인 목록은 노드가 연결되지 않거나, 클라이언트 간 이전을 하거나, 프로토콜을 바꾸려 할 때 유용합니다. 오류 메시지를 분류하기 어렵다면 자주 묻는 질문 페이지에서 설치·설정 및 문제 해결 항목을 기준으로 계속 찾아보세요.

08 / SCENARIO GUIDE

사용 상황에 따른 선택 결정

기존 설정이 안정적이라면 유지하면서 대체 노드를 만드세요

기존 VMess, Trojan 또는 Shadowsocks 노드가 오랫동안 안정적으로 작동한다면 가장 안전한 전략은 현재 상태를 유지하면서 별도의 새 조합을 테스트하는 것입니다. 새 노드에는 다른 이름과 그룹을 사용해 구독 업데이트 때 기존 노드와 혼동하지 않도록 하세요. 테스트는 웹페이지의 짧은 연결, 지속 전송, 기기 대기 후 복귀, 네트워크 전환을 포함해야 하며 연결 성공을 한 번 확인하는 것으로 끝내서는 안 됩니다. 일정 기간 비교한 뒤 새 노드를 기본값으로 사용할지 결정하세요.

이 방법은 VMess에서 VLESS로 이전하거나 일반 TLS 조합에서 REALITY 조합으로 이전할 때 특히 적합합니다. 이전에는 서버·구독·클라이언트 세 곳이 관련되므로 단계적으로 전환하면 되돌릴 경로를 남길 수 있습니다. 여러 기기에서 서로 다른 클라이언트를 사용한다면 먼저 필드가 가장 완전하게 표시되는 클라이언트에서 검증한 뒤 다른 클라이언트의 구독 해석을 테스트하세요. 어느 한쪽에서 확장 필드가 빠진다면 정식 전환 전에 해결해야 합니다.

새 Xray 설정: 전체 조합 지원을 우선 고려하세요

새 설정을 만들고 양쪽에서 Xray 기능을 사용할 수 있다면 VLESS를 프로토콜 계층 후보로 삼고, 서버 설계에 따라 TLS 또는 REALITY를 선택한 뒤 특정 flow가 필요한지 확인할 수 있습니다. 선택 기준은 유행이 아니라 서버에서 안정적으로 관리할 수 있는지, 구독이 완전하게 출력되는지, 클라이언트가 안정적으로 해석하는지입니다. 데스크톱에서 v2rayN, Android에서 v2rayNG를 사용하면 필드 모델을 일관되게 유지하기 쉬운 편이지만, 여전히 항목별 확인이 필요합니다.

같은 구독을 V2Fly를 실행 코어로 사용하는 클라이언트에도 제공해야 한다면 기본 호환 노드를 준비하거나 코어별 노드를 명확한 그룹에 넣으세요. ‘VLESS 기본 프로토콜을 인식한다’고 해서 ‘모든 VLESS 확장 조합을 실행할 수 있다’고 오해해서는 안 됩니다. 코어 간 호환성의 핵심은 클라이언트가 알 수 없는 필드를 무시하길 기대하는 것이 아니라 공통으로 지원되는 필드 집합으로 범위를 좁히는 것입니다.

저전력 및 모바일 환경: 안정적인 연결을 우선하세요

모바일에서는 재연결이 적고 필드가 명확하며 구독 업데이트가 안정적인 노드를 우선 선택해야 합니다. VLESS와 Shadowsocks는 프로토콜 구조가 가벼운 편이지만 실제 배터리 사용량은 보안 핸드셰이크, 신호, 분할 라우팅, 애플리케이션 트래픽에도 영향을 받습니다. 테스트할 때 백그라운드 대기 후 복구되는지, 네트워크 전환 뒤 반복해서 재연결하는지, 시스템 배터리 통계에서 연결 서비스가 계속 활성 상태인지 관찰하세요. 문제가 백그라운드 제한이나 신호 변화에서 비롯되었다면 프로토콜을 바꿔도 바로 해결되지 않습니다.

자동 업데이트 빈도, 로그 수준, 전역 프록시 범위도 배터리에 영향을 줍니다. 노드 변경이 잦지 않다면 업데이트를 촘촘하게 설정할 필요가 없습니다. 진단이 끝나면 상세 로그를 끄고 필요한 트래픽만 프록시로 보내 불필요한 연결 활동을 줄이세요. v2rayNG와 v2flyNG 중 무엇을 선택할지는 먼저 노드의 코어 요구 사항으로 결정하고, 그다음 화면 선호를 비교해야 합니다.

여러 클라이언트와 팀 설정: 설명 가능한 최소 집합을 선택하세요

여러 기기, 서로 다른 데스크톱 시스템, Android 클라이언트 사이에 설정을 배포해야 한다면 필드 정의가 명확하고 대상 코어가 모두 지원한다고 확인한 조합을 우선 선택하세요. 구독 그룹에 프로토콜, 코어 요구 사항, 용도를 표시하면 ‘고속’, ‘백업’ 같은 모호한 이름보다 유지 관리가 쉽습니다. 라우팅과 DNS 정책은 각 플랫폼의 클라이언트 템플릿으로 관리하고, 노드 구독은 아웃바운드 정보만 전달하면 플랫폼 간 변환 복잡도를 낮출 수 있습니다.

설정 문서에는 프로토콜, 전송, 보안 계층, 코어 요구 사항, 핵심 확장 필드를 기록하되 전체 인증 정보를 그대로 복사할 필요는 없습니다. 변경할 때 어떤 필드가 바뀌었는지 기록하고 검증이 끝날 때까지 이전 노드를 보존하세요. 그러면 특정 클라이언트가 해석 방식을 바꾸더라도 구조를 기준으로 차이를 찾을 수 있어 노드 의미를 다시 추측할 필요가 없습니다.

문제가 생기면 의사 결정 트리에 따라 되돌리기

첫 번째로 구독 콘텐츠를 정상적으로 가져왔는지 판단합니다. 실패하면 링크, 기기 시간, 응답 형식을 확인하세요. 두 번째로 노드 필드가 완전한지 판단하고, 누락되었다면 구독 생성과 변환을 점검합니다. 세 번째로 코어가 설정을 생성할 수 있는지 판단하고, 실패하면 알 수 없는 필드·유형·지원되지 않는 조합을 처리합니다. 네 번째로 보안 핸드셰이크가 완료되었는지 판단하고, 실패하면 서버 이름·공개 키·짧은 식별자·비밀번호·기기 시간을 확인합니다. 다섯 번째로 요청이 올바르게 라우팅되는지 판단합니다. 연결은 성공했지만 애플리케이션을 사용할 수 없다면 시스템 프록시, 애플리케이션별 규칙, DNS, 아웃바운드 태그를 확인하세요.

각 단계에서는 관련 계층의 설정 하나만 변경하고 로그와 원래 설정을 비교할 수 있도록 보관하세요. 프로토콜·전송·보안 계층·라우팅을 동시에 계속 바꾸면 한 번 성공해도 재현하기 어렵습니다. 구독 업데이트로 문제가 생겼다면 먼저 기존 노드를 복사해 비교하고, 코어 교체로 문제가 생겼다면 가장 기본적인 노드로 코어 실행을 먼저 검증하세요. 특정 플랫폼에서만 문제가 발생한다면 서버 이상으로 단정하지 말고 클라이언트가 생성한 필드와 시스템 연결 방식을 비교해야 합니다.

선택을 마친 뒤 v2rayN·v2rayNG·v2flyNG 다운로드 페이지에서 해당 플랫폼의 설치 패키지를 선택하고, 설정 튜토리얼에 따라 연결을 구성하세요. 구독, 코어 시작, 시스템 프록시 또는 라우팅 문제가 발생하면 이 장의 의사 결정 트리와 문제 해결 분류를 함께 사용해 계층별로 원인을 찾는 편이 노드 유형을 계속 바꾸는 것보다 효과적입니다.