V2Ray 프로토콜 및 코어 비교 가이드

01 / Configuration layers

노드 설정의 네 가지 계층

클라이언트 목록에 표시되는 노드 하나는 실제로 여러 설정이 결합된 것입니다. 서버 주소와 포트는 어디에 연결할지를 정하고, VMess·VLESS·Trojan·Shadowsocks는 프록시 요청과 사용자 인증 방식을 정합니다. TCP·WebSocket 같은 전송 방식은 데이터를 전달하는 방법을 나타내며, TLS나 REALITY는 연결을 보호합니다. 이 모든 것을 하나의 프로토콜로 뭉뚱그리면 선택을 잘못하기 쉽습니다. VLESS로 표시된 두 노드라도 보안 계층과 전송 방식이 다르면 연결 조건이 완전히 달라질 수 있습니다.

프록시 프로토콜과 전송 프로토콜은 다릅니다

프록시 프로토콜은 원격 대상 주소와 사용자 정보, 요청 유형, 데이터 인코딩 방식 등을 전달합니다. 전송 계층은 이 데이터를 원격지까지 보내는 역할을 합니다. 하나의 프록시 프로토콜에 여러 전송 방식을 조합할 수 있지만, 모든 조합을 코어와 서버가 지원하는 것은 아닙니다. 노드 세부 정보를 확인할 때는 유형·전송 방식·보안 유형·추가 필드를 각각 기록하세요. 노드 이름의 약어만 보고 판단해서는 안 됩니다. 이름은 구독 관리자가 붙인 라벨일 뿐 실제 연결 방식을 규정하는 기술 용어가 아닙니다.

예를 들어 WebSocket은 HTTP 업그레이드 절차를 거치며, 보통 경로와 요청 호스트 설정도 필요합니다. 반면 TCP를 직접 사용하면 이런 필드가 자동으로 적용되지 않습니다. WebSocket을 선택해도 프록시 프로토콜의 사용자 인증을 대신할 수 없고, 연결이 암호화된다는 보장도 없습니다. TLS를 켜더라도 일반 프록시 요청이 다른 프록시 프로토콜로 바뀌는 것은 아닙니다. 클라이언트에서 이 설정들이 나란히 표시되는 것은 편집을 쉽게 하기 위해서이지, 같은 기술 계층에 속해서가 아닙니다.

보안 계층과 트래픽 진입점을 따로 확인하세요

로컬 인바운드는 브라우저 같은 앱이 클라이언트에 접속하는 지점이고, 원격 아웃바운드는 이 가이드에서 주로 비교하는 대상입니다. 일반적인 로컬 SOCKS 또는 HTTP 수신 포트는 노드 서버의 포트가 아닙니다. 시스템 프록시는 보통 앱의 연결을 로컬 HTTP 진입점으로 보내며, SOCKS를 지원하는 앱은 해당 진입점을 별도로 지정할 수도 있습니다. 트래픽이 코어에 들어온 뒤에는 라우팅 규칙에 따라 일부 요청이 직접 전송될 수 있습니다. 따라서 시스템 프록시가 켜졌다는 사실만으로 모든 연결이 현재 선택한 노드를 거친다고 볼 수는 없습니다.

사용자 인증과 전송 보호도 구분해야 합니다. 사용자 ID나 비밀번호는 서비스 사용 권한을 확인하는 데 쓰이고, 인증서 검증은 TLS 상대방의 신뢰성을 확인합니다. 두 검증의 실패 원인과 해결 방법은 서로 다릅니다. 인증 정보가 틀렸을 때 인증서 검사를 끄는 방식으로 해결해서는 안 되며, 인증서 이름이 일치하지 않을 때 사용자 ID를 계속 바꾸는 것도 적절하지 않습니다. 먼저 문제가 발생한 계층을 찾아야 여러 설정을 한꺼번에 바꿔 원인을 놓치는 일을 피할 수 있습니다.

다시 확인할 수 있는 설정 목록 만들기

노드를 비교하기 전에 이 네 계층의 정보를 로컬에 기록하고 사용하는 코어와 클라이언트도 함께 적어 두세요. 민감한 필드의 값을 옮겨 적을 필요는 없습니다. 필드가 있는지, 출처가 일치하는지만 확인하면 됩니다. 구독에 완성된 설정이 포함되어 있다면 원래 조합을 그대로 유지하고, 기억에 의존해 전송 방식을 바꾸지 마세요. 클라이언트의 드롭다운을 변경해도 서버 설정이 자동으로 바뀌지는 않습니다. 주소와 인증 정보가 올바르더라도 경로나 보안 계층이 틀리면 핸드셰이크가 실패할 수 있습니다.

이 계층별 접근 방식은 용어와 로그를 확인할 때도 유용합니다. 핸드셰이크, 인증, 경로, 라우팅 규칙 일치 같은 메시지가 보이면 먼저 해당 계층을 파악한 뒤 관련 설정을 확인하세요. 용어집에서 인바운드·아웃바운드·라우팅의 뜻을 확인할 수 있습니다. 다음 섹션에서는 설정이 왜 서로 다른 조합으로 구성되는지, 사용자가 실제로 어떤 차이를 선택해야 하는지 설명합니다.

02 / Proxy protocols

VMess와 VLESS의 설계 차이

VMess는 Project V 생태계에서 비교적 일찍 정립된 프록시 프로토콜로, 사용자 인증과 요청 헤더, 데이터 보호를 위한 기능을 갖추고 있습니다. 반면 VLESS는 프록시 계층의 추가 처리를 간소화하고 연결 보호를 외부 보안 계층에 더 많이 맡기며, 이후 확장을 고려해 설계되었습니다. 이름만 보고 어느 쪽이 더 최신인지 순위를 매기거나 노드 유형을 VMess에서 VLESS로 바꾸는 것만으로 업그레이드가 끝났다고 여겨서는 안 됩니다. 서버에 해당 인바운드가 있어야 하며, 클라이언트도 인증·전송·보안 설정을 맞춰야 합니다.

VMess: 인증 방식과 시간 조건 확인

VMess 설정에는 보통 사용자 ID와 보안 관련 옵션이 포함됩니다. 오래된 자료에는 추가 ID 개수 같은 과거 필드가 자주 등장하지만, 최신 설정은 대체로 AEAD 인증 방식을 사용합니다. 오래된 노드를 가져올 때는 과거 화면에 있던 필드를 모두 채우기보다 서버가 실제로 사용하는 인증 방식과 현재 코어의 지원 여부를 확인하는 것이 중요합니다. 구독에서 생성된 최신 설정에 과거 필드를 임의로 추가하면 호환성 문제가 생길 수 있습니다. 필드가 많다고 설정이 더 완전한 것은 아닙니다.

시간은 VMess 문제 해결에서 놓치기 쉬운 조건입니다. 일부 인증 절차는 시간 허용 범위에 의존하므로 시스템 시각이 크게 어긋나면 인증에 실패할 수 있습니다. 화면에 선택된 시간대뿐 아니라 기기의 실제 날짜와 시각, 자동 동기화 상태도 확인하세요. 정확한 절대 시각이 같다면 시간대만 바꿔도 일반적으로 인증 오차가 생기지 않습니다. 모든 VMess 노드가 동시에 실패하고 다른 프로토콜은 정상이라면 시간 동기화도 점검 항목에 넣되, 프로토콜 이름만으로 결론 내리지 말고 로그를 함께 확인하세요.

VMess의 데이터 보호에는 추가 처리가 필요하지만 실제 리소스 사용량은 알고리즘 구현, 프로세서 성능, 외부 TLS, 연결 수, 트래픽 패턴에도 영향을 받습니다. 노드에 TLS를 추가로 적용하면 보안 보호가 VMess 자체에만 의존하지 않습니다. 이런 조합을 유지할지는 서버 설계와 호환성 요구에 따라 결정해야 합니다. 암호화 처리를 한 번 줄이겠다며 기존 보안 계층을 임의로 끄지 마세요. 연결 가능 여부와 배포 구성이 적절한지는 각각 따로 확인해야 합니다.

VLESS: 간결하다고 자체 암호화를 제공하는 것은 아닙니다

VLESS는 프록시 요청과 사용자 인증을 처리하지만, 기본 구성 자체는 애플리케이션 데이터를 암호화하지 않습니다. 일반적인 설정 화면에서 encryption이 none으로 표시되는 것은 정상적인 필드 값이며, 외부 TLS나 REALITY가 꺼졌다는 뜻은 아닙니다. 연결이 보호되는지 판단할 때는 해당 항목만 보지 말고 보안 유형도 확인하세요. 신뢰할 수 없는 네트워크를 통과하는 연결에는 서버 요구 사항에 맞는 보안 계층을 적용해야 합니다. 보호되지 않은 구성을 일반적인 배포 방식으로 권장해서는 안 됩니다.

VLESS는 flow 필드의 Vision처럼 Xray의 확장 기능과 함께 사용되는 경우가 많습니다. flow는 임의로 입력하는 속도 설정이 아니라 프로토콜 의미와 구현 조건이 있는 구성입니다. 서버에서 해당 흐름을 활성화하지 않았거나 전송 조합이 맞지 않거나 사용 중인 코어에 해당 기능이 구현되지 않았다면 같은 값을 입력해도 같은 결과를 얻을 수 없습니다. 특정 필드 이름을 무작정 따라 하기보다 구독에서 제공한 값을 유지하고 클라이언트가 실제로 어떤 코어를 사용하는지 확인하는 것이 중요합니다.

클라이언트에서 설정 선택하기

기존 VMess 설정이 오랫동안 안정적으로 작동하고 제공업체가 해당 서버를 계속 운영한다면 직접 바꾸기보다 그대로 사용하는 편이 안전합니다. 새 설정에 VLESS와 이에 맞는 TLS 또는 REALITY가 명시되어 있다면 전체 조합을 그대로 사용하세요. 비교할 때는 두 노드의 서버 지역과 네트워크 경로를 비슷하게 맞추고 같은 시간대에 테스트해야 합니다. 그렇지 않으면 프로토콜이 아니라 네트워크 경로 차이를 측정하게 될 수 있습니다. 다운로드 속도뿐 아니라 연결 실패율과 재연결 상태도 함께 고려하세요.

v2rayN에서는 먼저 노드 편집 창에서 프로토콜과 보안 설정을 확인한 다음 해당 설정이 실제로 어떤 코어를 호출하는지 살펴보세요. v2rayNG에서도 가져온 뒤 추가 필드가 유지되었는지 확인해야 합니다. 원하는 조합을 현재 구현에서 지원하지 않는다면 모르는 필드를 지우지 말고 전체 설정을 처리할 수 있는 클라이언트나 코어를 사용하세요. 두 코어의 구체적인 호환 범위는 코어 호환성 섹션에서 확인할 수 있습니다.

03 / Alternative designs

Trojan과 Shadowsocks의 사용 범위

Trojan과 Shadowsocks는 노드 목록에서 함께 표시되는 경우가 많지만, 인증과 데이터 보호 방식은 서로 다릅니다. Trojan은 보통 TLS를 연결 보안의 기반으로 삼아 그 안에서 프록시 요청과 비밀번호 인증을 처리합니다. Shadowsocks는 경량 프록시와 사전 공유 키를 기반으로 자체 데이터 보호 기능을 제공합니다. 선택할 때는 이름만 보지 말고 구체적인 프로토콜 버전·암호화 방식·전송 조합을 확인한 뒤 네트워크 성능을 비교하세요. Trojan이나 SS라는 짧은 표기만으로는 전체 호환성을 판단할 수 없습니다.

Trojan: TLS 설정과 비밀번호를 모두 확인

일반적인 Trojan 설정에는 서버 주소, 포트, 비밀번호와 TLS 관련 서버 이름이 필요합니다. 비밀번호가 맞아도 인증서 검증 실패를 해결할 수는 없습니다. TCP 연결에 성공했다고 TLS와 이후 인증까지 끝난 것도 아닙니다. 로그가 인증서 단계에서 멈췄다면 서버 이름, 인증서 체인, 기기 시각을 확인하세요. TLS가 완료된 뒤 원격 서버가 요청을 거부한다면 비밀번호와 서버 인바운드를 확인하면 됩니다. 단계별로 점검하는 편이 포트를 계속 바꾸는 것보다 효과적입니다.

설정에서 서버 주소와 서버 이름은 서로 다른 역할을 할 수 있습니다. 전자는 네트워크 연결 대상이고, 후자는 TLS 핸드셰이크와 인증서 이름 검증에 사용됩니다. 주소 필드에 IP를 입력했다고 해서 서버 이름에도 같은 IP를 입력해야 하는 것은 아닙니다. 구독에 지정된 이름은 그대로 유지하세요. 인증서 검증을 건너뛰도록 설정하면 신뢰 범위가 달라지므로 일반적인 해결 방법으로 사용해서는 안 됩니다. 이름 설정, 시스템 시각, 서버 인증서 설정부터 확인하세요.

일부 구현은 Trojan에 여러 전송 방식을 조합합니다. 이때 경로·호스트 이름·전송 매개변수도 연결에 영향을 줍니다. 한 클라이언트에서 내보낸 확장 조합이 Trojan을 지원하는 모든 구현에서 그대로 작동한다고 볼 수는 없습니다. 호환성을 확인할 때는 유형 선택 목록에 Trojan이 있는지만 볼 것이 아니라 대상 코어가 구체적인 조합을 지원하는지 확인해야 합니다. 가져온 뒤 전송 방식이 기본값으로 바뀌었다면 연결 전에 확인하세요. 파싱 과정에서 정보가 사라진 문제를 노드 장애로 오해할 수 있습니다.

Shadowsocks: 암호화 방식은 필수 설정입니다

Shadowsocks의 주요 설정에는 보통 주소·포트·암호화 방식·비밀번호가 포함됩니다. 기존 AEAD 방식과 이후의 2022 계열 방식은 규격이 다르며, 키 요구 사항과 구현 지원도 완전히 같지 않습니다. 이름이 비슷하다고 서로 바꿔 쓸 수 있는 것은 아닙니다. 양쪽에서 같은 규격을 사용해야 합니다. 특히 임의 길이의 일반 비밀번호를 키 길이나 인코딩 조건이 정해진 설정에 그대로 넣고 연결 실패를 네트워크 문제로 돌려서는 안 됩니다.

오래된 문서에 등장하는 기존 스트림 암호화 방식은 새 설정의 기본 선택지가 되어서는 안 됩니다. 실제 사용 시에는 제공업체가 명확히 유지 관리하고 양쪽 코어가 지원하는 방식을 선택하세요. 오래된 화면과 맞추기 위해 구식 설정으로 되돌릴 필요는 없습니다. 일부 구독에는 추가 전송 확장 정보가 포함되지만, 이는 Shadowsocks 기본 프로토콜의 일부가 아닙니다. 대상 클라이언트가 주소와 비밀번호를 이해하더라도 확장 필드를 처리하지 못할 수 있으므로 가져온 뒤 세부 정보를 확인하세요.

‘경량’이라는 이유만으로 사용 경험을 단정하지 마세요

Shadowsocks의 기본 처리 과정은 비교적 간결할 수 있지만, 실제 노드마다 속도가 더 빠르거나 배터리를 덜 소모하는 것은 아닙니다. 암호화 방식의 하드웨어 가속 지원, 패킷 손실, 서버 부하, 클라이언트의 연결 유지 정책에 따라 결과가 달라질 수 있습니다. Trojan은 TLS를 사용하더라도 매 요청마다 전체 핸드셰이크 비용을 다시 부담하는 것은 아닙니다. 연결 재사용과 세션 복구가 실제 오버헤드에 영향을 줍니다. 설계상의 특징은 분석을 위한 단서로 삼고, 측정을 대신하는 고정 순위로 받아들이지 마세요.

제공업체가 두 유형의 노드를 모두 제공한다면 클라이언트가 설정을 빠짐없이 해석하고 일상적으로 안정적으로 사용할 수 있는 조합을 우선하세요. UDP가 필요한 앱은 클라이언트·코어·서버·현재 모드가 모두 지원하는지 별도로 확인해야 합니다. 웹페이지가 열린다고 해서 UDP도 작동한다고 볼 수는 없습니다. 응답 시간과 지역 거리, 트래픽 배율을 함께 판단하는 방법은 노드 선택 및 테스트 방법을 참고하고, 프로토콜을 전체 네트워크 조건의 일부로 살펴보세요.

04 / Security layers

TLS, REALITY 및 전송 방식

REALITY는 홍보 문구나 노드 이름에서 VMess·VLESS·Trojan과 나란히 표시되기도 하지만, 설정 계층상 프록시 요청을 표현하는 독립 프로토콜은 아닙니다. 흔히 VLESS와 REALITY를 조합해 프록시 계층에서 대상 요청을 처리하고, 보안 메커니즘으로 연결 보호와 상대방 인증을 수행합니다. TLS는 보다 범용적인 보안 프로토콜입니다. 비교할 때는 전체 조합을 명시하고 서로 다른 계층을 놓고 ‘VLESS와 REALITY 중 하나’를 선택하는 식으로 생각하지 마세요.

TLS: 연결 이름, 인증서, 애플리케이션 협상

TLS는 연결 암호화와 무결성 보호, 상대방 인증을 제공합니다. 클라이언트는 설정된 서버 이름으로 상대방 인증서를 확인하고 인증서 체인과 유효 기간도 검증해야 합니다. 네트워크 연결 주소, TLS 서버 이름, WebSocket 요청의 호스트 필드는 서로 같을 수도 있고 각각 다르게 설정할 수도 있습니다. 모두 도메인처럼 보인다는 이유로 세 필드를 같은 값으로 바꾸지 마세요. 어떤 필드를 일치시켜야 하는지는 서버의 인증서 할당 방식과 전송 수신 및 요청 처리 설정에 따라 결정됩니다.

ALPN은 애플리케이션 계층 프로토콜을 협상하는 기능이지 지역 선택이나 가속 설정이 아닙니다. 특정 애플리케이션 프로토콜을 사용하는 전송 방식이라면 클라이언트와 서버의 협상 결과가 요구 사항에 맞아야 합니다. 지문 설정은 TLS 핸드셰이크의 표현 방식과 구현 호환성에 영향을 줄 수 있지만, 특별할수록 좋은 것은 아닙니다. 구독에 해당 필드가 있다면 먼저 원래 값으로 테스트하고, 값이 없다면 다른 노드의 설정을 그대로 가져오지 마세요. 서버 인바운드마다 요구 조건이 다를 수 있으므로 일부 설정만 복사하면 정상적으로 작동하던 조합이 깨질 수 있습니다.

REALITY: 관련 매개변수로 인증 이해하기

REALITY는 Xray 생태계에서 구현되며, 일반적인 인증서 체인 검증과는 다른 관련 인증 메커니즘을 사용합니다. 클라이언트에는 보통 서버 이름, 공개 키 관련 매개변수, 짧은 ID, 지문 등의 정보가 필요합니다. 구체적인 항목 이름은 구현에 따라 바뀔 수 있습니다. 모든 값은 같은 유효 설정에서 가져와야 하며 서로 다른 노드의 값을 섞어서는 안 됩니다. 공개 키는 짝이 맞는 서버를 검증하는 데 쓰이고 짧은 ID도 서버에서 허용한 값과 일치해야 합니다. 둘 다 임의로 생략해도 되는 장식용 필드가 아닙니다.

일반적인 VLESS·REALITY·Vision 조합은 코어 구현과 전송 조건도 서로 맞아야 합니다. 클라이언트가 VLESS를 지원한다고 해서 REALITY도 지원하는 것은 아닙니다. REALITY 지원이 있더라도 모든 flow와 전송 방식을 임의로 조합할 수 있는 것은 아닙니다. 서버가 명시적으로 지원하는 조합을 하나의 전체 설정으로 취급하세요. 연결에 문제가 생기면 코어·서버 이름·인증 매개변수·flow를 먼저 확인한 다음 네트워크 연결 가능성을 살펴보세요. 한 필드만 반복해서 바꾸며 시험하지 마세요.

REALITY는 잘못된 서버 주소를 보완하는 도구가 아니며 특정 원격 서버의 품질을 보장하지도 않습니다. 보안 협상이 성공해도 이후 프록시 인증·대상 연결·라우팅 단계에서 실패할 수 있습니다. 제공업체의 전체 매개변수를 보관하고 해당 조합을 지원하는 코어를 사용하며 업데이트 후 파싱 결과를 다시 확인하세요. 시간을 무시하거나 인증을 생략하거나 모든 인증서 개념을 우회하는 범용 스위치로 이해해서는 안 됩니다.

직접 연결과 WebSocket의 비용

TCP를 직접 전송에 사용하면 중간 처리 계층이 대체로 적습니다. WebSocket은 HTTP 업그레이드와 메시지 캡슐화를 통해 다른 접속 방식을 제공하며, 기존 리버스 프록시나 애플리케이션 서비스 구조에서 자주 사용됩니다. 추가 캡슐화에 비용이 들 수 있지만 실제 체감 성능은 배포 경로가 적절한지에도 달려 있습니다. 계층 수만 보고 처리량을 예측하거나 계층을 줄이려고 서버에서 WebSocket만 제공하는 설정을 TCP로 임의 변경하지 마세요. 이는 클라이언트 내부 최적화가 아니라 연결 진입점을 바꾸는 것입니다.

다중화가 모든 전송 방식에 적합한 기본 개선 설정이라고 생각하는 것도 흔한 오해입니다. 다중화는 여러 논리 연결이 하위 리소스를 공유하도록 하지만, 패킷 손실이나 장시간 이어지는 트래픽, 특정 프로토콜 흐름에 따라 서로 영향을 줄 수 있으며 일부 조합에는 명확한 제한도 있습니다. 현재 코어 문서와 서버 조합을 기준으로 사용 여부를 결정하고 실제 앱으로 검증하세요. 설정 화면에 스위치가 있다는 것은 편집 기능이 제공된다는 뜻일 뿐 모든 노드에 적합하다는 뜻은 아닙니다.

05 / Performance and battery

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

프로토콜 비교는 테스트 조건을 생략한 속도 순위표로 축약되기 쉽지만, 조건이 빠진 순위는 다시 활용할 수 없습니다. 앱 사용 경험에는 최초 연결 시간, 요청 응답, 지속 처리량, 재시도 동작, 장시간 안정성이 포함됩니다. 프록시 프로토콜은 여러 변수 중 하나일 뿐입니다. 네트워크 왕복 거리, 이름 해석 과정, 혼잡, 서버 부하, 대상 사이트의 응답 속도도 큰 영향을 줄 수 있습니다. 합리적으로 비교하려면 먼저 이런 조건을 고정한 다음 프로토콜 조합과 클라이언트 설정에 따른 차이를 확인해야 합니다.

지연 시간·핸드셰이크·처리량을 따로 측정하세요

클라이언트의 TCP 연결 테스트는 보통 노드 진입점까지의 연결만 확인하며 프록시 인증이나 대상 요청 성공을 보장하지 않습니다. 실제 요청 테스트는 앱 사용에 더 가깝지만 테스트 주소의 지역·캐시·서비스 상태에도 영향을 받습니다. 장시간 다운로드는 주로 처리량을 나타내며 짧은 요청의 응답 속도와는 다릅니다. 테스트 이름이 어떤 과정을 측정하는지 확인하고, 같은 조건에서 같은 지표끼리 비교하세요. 서로 다른 테스트 결과를 직접 빼서 비교해서는 안 됩니다.

최초 연결에는 보통 도메인 조회와 전송 연결, 보안 핸드셰이크가 필요합니다. 이후 같은 대상에 보내는 요청은 연결 재사용의 이점을 얻을 수 있습니다. 테스트할 때는 처음 열리는 시점과 연속 사용을 모두 살펴보고 한쪽 연결만 미리 준비된 상태로 비교하지 마세요. 첫 접속은 느리지만 이후 정상이라면 핸드셰이크와 이름 해석을 먼저 살펴보세요. 처음에는 정상인데 전송 중 점점 나빠진다면 혼잡·패킷 손실·서버 제한·기기 온도를 확인하세요. 증상마다 해결 방향이 다릅니다.

리소스 사용량은 구현과 작업 부하에 따라 달라집니다

데이터 암호화는 프로세서 리소스를 사용하고, 추가 캡슐화는 처리와 메모리 복사를 늘릴 수 있습니다. 연결 재사용과 버퍼링 방식도 메모리 사용량을 바꿉니다. 하드웨어 가속을 지원하는 암호화 방식은 일부 프로세서에서 효율적일 수 있지만 다른 기기에서는 이점이 없을 수도 있습니다. 클라이언트 화면 프로세스와 프록시 코어가 별도로 실행될 수 있으므로 시스템 리소스를 볼 때 두 항목을 구분하세요. 화면 프로세스의 사용량이 낮다는 이유만으로 전체 프록시 경로의 리소스 소비가 적다고 단정할 수 없습니다.

메모리 사용량이 높더라도 활성 연결·캐시·버퍼 때문일 수 있어 곧바로 오류라고 볼 수는 없습니다. 비슷한 부하에서 계속 증가하는지, 트래픽을 멈춘 뒤 안정되는지, 시스템 메모리 회수나 프로세스 종료가 동반되는지를 살펴보는 편이 더 유용합니다. 자주 연결을 끊고 다시 연결하면 소수의 안정적인 연결을 유지할 때보다 핸드셰이크 작업이 늘 수 있습니다. 지나치게 적극적인 연결 재사용은 여러 요청을 막힌 통로 하나에 몰아넣을 수도 있습니다. 특정 리소스 수치를 최소화하기보다 실제 작업 부하에 맞춰 설정하세요.

모바일에서는 무선 통신과 백그라운드 동작도 확인하세요

Android에서는 프로토콜 연산뿐 아니라 무선 네트워크 활동, 앱의 백그라운드 요청, 기기 깨우기도 배터리를 소모합니다. 짧은 간격의 연결 유지 신호, 잦은 자동 속도 측정, 실패 후 계속되는 재시도는 기기가 저전력 상태로 진입하지 못하게 할 수 있습니다. 신호가 약한 환경에서는 셀룰러 데이터 전송으로 배터리 소모가 더 커질 수도 있습니다. v2rayNG와 v2flyNG의 배터리 사용량을 비교할 때는 네트워크 유형·화면 상태·앱 부하를 동일하게 맞추고 자동 업데이트나 테스트 작업이 실행 중인지 확인하세요.

시스템의 백그라운드 제한은 장시간 연결에 영향을 줍니다. 제한을 완화하면 앱이 오래 실행될 수 있지만 배터리 조건도 달라집니다. 따라서 한쪽은 백그라운드 실행을 허용하고 다른 쪽은 엄격히 제한한 테스트를 비교한 뒤 차이를 모두 코어 탓으로 돌려서는 안 됩니다. 앱을 사용하는 동안, 화면이 꺼진 대기 상태, 무선 네트워크 전환의 세 상황을 각각 살펴보세요. 연결이 복구되는지, 다시 연결하는지, 앱이 실제로 데이터를 전송하는지도 기록해야 합니다. 화면이 켜진 상태에서 한 번 다운로드하는 것만으로는 일상적인 모바일 사용을 평가하기 어렵습니다.

비교할 때는 한 번에 변수 하나만 바꾸고 비슷한 시간대에 반복 테스트한 뒤 기존의 정상 설정을 복구용으로 보관하세요. 계속 최대 속도로 다운로드하는 것만을 기준으로 삼지 마세요. 기기 온도·데이터 사용량·시스템 스케줄링이 모두 함께 달라집니다. 일상적인 웹 탐색에서는 최고 처리량보다 짧은 요청을 안정적으로 완료하는지가 더 유용한 지표입니다. 결론은 특정 기기·네트워크·설정 조합에서 관찰한 결과로 제시하고 모든 사용자에게 적용되는 프로토콜 순위처럼 표현하지 마세요.

06 / Core compatibility

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

V2Ray는 처음에 Project V 생태계의 일부였습니다. V2Fly는 관련 프로젝트를 커뮤니티에서 이어서 관리하고, Xray는 이 기술 기반에서 분기해 발전하며 VLESS·XTLS·REALITY 등의 방향으로 자체 구현을 구축했습니다. 일부 개념과 과거 설정 방식은 공유하지만, 이제 서로 임의로 바꿔 쓸 수 있는 동일한 프로그램은 아닙니다. 코어를 선택할 때는 먼저 필요한 설정을 구현할 수 있는지 확인하고, 그다음 특정 기기에서의 리소스 사용량과 관리 편의성을 비교하세요.

그래픽 클라이언트와 코어의 역할은 다릅니다

그래픽 클라이언트는 구독 관리·노드 편집·시스템 프록시·시작 제어를 담당하고, 코어는 실행 설정을 해석해 연결·라우팅·전송을 수행합니다. v2rayN은 데스크톱에서 주로 사용하는 설정 관리 도구로, 플랫폼과 소프트웨어 패키지에 따라 관련 코어 설정을 관리할 수 있습니다. v2rayNG는 Android용으로 Xray를 주요 코어 방향으로 삼고, v2flyNG는 V2Fly 기반 대안을 제공합니다. 클라이언트 이름은 프록시 프로토콜이 아닙니다. 같은 프로토콜 노드가 실행되는지는 결국 생성된 설정과 실제 호출되는 코어에 달려 있습니다.

클라이언트 화면에서 필드를 지원한다고 해서 현재 실행 중인 코어도 그 필드를 지원한다고 단정할 수는 없습니다. 반대로 코어에 기능이 있더라도 화면에서 편집 기능을 제공하지 않을 수 있습니다. 문제를 확인할 때는 가져오기 결과와 실행 로그, 현재 선택된 코어를 모두 살펴보세요. 특히 오래된 설정을 옮기거나 코어를 전환한 뒤에는 이전 기본값이 계속 적용되는지 확인해야 합니다. 화면에 ‘실행 중’이라고 표시되어도 실행 동작이 완료된 것일 뿐 실제 대상 요청이 성공했는지는 별도로 확인해야 합니다.

공통 프로토콜도 설정 호환 범위는 다를 수 있습니다

두 코어 모두 VMess·VLESS·Trojan 또는 일부 Shadowsocks 방식을 지원하더라도 구체적인 전송 방식·보안 확장·필드 이름·기본 동작은 다를 수 있습니다. REALITY와 XTLS Vision은 Xray 계열의 주요 기능이므로 V2Fly가 원본 설정을 그대로 해석한다고 가정해서는 안 됩니다. 설정에 이런 기능이 필요하면 그에 맞는 구현을 선택하세요. 파싱을 통과시키려고 핵심 필드를 지우면 연결 동작이 달라집니다. 호환 설정을 얻는 방법이 아닙니다.

JSON 구조가 비슷하다는 점도 자주 혼동을 일으킵니다. 두 코어 모두 인바운드·아웃바운드·라우팅 같은 구조를 사용할 수 있지만 같은 이름의 필드라도 허용 값과 확장 필드, DNS 처리 방식이 구현에 따라 달라질 수 있습니다. 마이그레이션할 때는 기능 요구 사항을 기준으로 해당 설정을 하나씩 확인하고 완성된 파일을 다른 코어에 그대로 넘기지 마세요. 특히 라우팅 태그가 존재하는지, 아웃바운드 참조가 올바른지, 필요한 데이터 리소스를 불러올 수 있는지 다시 확인하세요.

아래는 라우팅 의미를 설명하기 위한 일부 설정 조각이며, 단독으로 실행할 수 있는 완성된 설정이 아닙니다. 지정한 도메인 집합에 일치하면 direct라는 이름의 아웃바운드를 선택한다는 의미입니다. 실제 실행을 위해서는 같은 이름의 아웃바운드가 존재하고 관련 도메인 데이터를 불러올 수 있어야 합니다. 이 예시는 호환성이 프록시 프로토콜뿐 아니라 관련 리소스와 태그 연결에도 달려 있음을 보여 줍니다. 규칙 객체만 복사하고 해당 아웃바운드를 만들지 않으면 기대한 직접 연결을 얻을 수 없습니다.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

코어 전환은 범위를 좁혀 검증하세요

전환하기 전에 기존에 작동하던 설정을 보관하고 대상 코어가 지원한다고 명시된 노드 하나로 먼저 테스트하세요. 이어서 도메인 조회, 자주 사용하는 사이트, UDP가 필요한 앱, 시스템 프록시 복구를 확인합니다. 특정 유형의 노드만 실패하면 해당 프로토콜의 확장 필드를 먼저 점검하세요. 모든 노드가 실패하면 코어 시작 오류와 수신 포트, 설정 생성 과정을 확인하세요. 이렇게 하면 ‘코어가 실행되지 않음’과 ‘특정 프로토콜 비호환’을 구분해 오판을 줄일 수 있습니다.

코어 업데이트와 클라이언트 업데이트는 서로 별도로 진행될 수 있습니다. 업데이트 후 문제가 생기면 변경된 프로토콜·설정 파싱·기본 동작을 먼저 확인하고 기존에 작동하던 설정과 비교하세요. 모든 구독을 곧바로 새로 만들 필요는 없습니다. 사이트의 설치 파일 페이지에는 플랫폼별 클라이언트 세 가지의 다운로드 항목이 정리되어 있습니다. 코어 계열의 차이는 Xray-core와 V2Fly-core 비교 글도 참고하세요. 선택 기준은 실제 설정 요구 사항이어야 하며, 분기 관계를 품질 순위로 받아들여서는 안 됩니다.

07 / Subscription formats

구독 형식·공유 링크·마이그레이션 점검

구독은 설정을 배포하는 방식이지 새로운 프록시 프로토콜이 아닙니다. 구독 주소는 보통 여러 노드 정보를 반환하고 클라이언트가 이를 내부 레코드로 파싱합니다. 공유 링크는 대개 노드 하나의 정보를 담습니다. 둘 다 인코딩된 형태를 사용할 수 있지만 인코딩이 곧 기밀성을 뜻하지는 않습니다. 구독 주소와 노드의 인증 정보는 민감한 정보로 취급하고 공개 스크린샷이나 게시물, 전체 로그에 올리지 마세요. 문제를 확인할 때는 필드의 존재 여부만 설명하면 되며 실제 값은 공개할 필요가 없습니다.

가져오기에 성공해도 파싱이 완전한 것은 아닙니다

구독 업데이트에는 네트워크 요청·콘텐츠 식별·필드 파싱·레코드 저장 단계가 있습니다. 요청이 응답을 반환했다고 해서 그 내용이 클라이언트가 이해할 수 있는 노드 목록이라는 보장은 없습니다. 로그인 페이지나 오류 메시지, 다른 설정 형식이 반환될 수 있습니다. 업데이트 뒤 노드가 보이지 않으면 요청 실패와 파싱 실패부터 구분하세요. 요청이 실패했다면 주소와 요청에 사용된 네트워크 경로를 확인하고, 파싱 실패라면 제공업체의 출력 형식이 대상 클라이언트와 호환되는지 살펴보세요. 업데이트 버튼을 계속 누르는 것은 해결책이 아닙니다.

공유 형식에는 VMess·VLESS·Trojan·Shadowsocks별 링크 규칙이 자주 사용되지만 접두사가 같더라도 확장 필드 표현 방식은 다를 수 있습니다. 전송 경로·서버 이름·flow·지문·REALITY 인증 매개변수가 한 파서에서는 모두 인식되지만 다른 파서에서는 무시될 수 있습니다. 따라서 가져온 노드 수가 맞더라도 일부 노드의 세부 정보를 확인해야 합니다. 모든 가져오기가 실패하는 경우보다 중요한 필드가 누락된 채 정상처럼 보이는 노드가 만들어지는 경우가 더 위험합니다.

노드 목록과 전체 실행 설정을 혼동하지 마세요

노드 목록에는 보통 아웃바운드 연결 정보만 들어 있습니다. 전체 설정에는 인바운드·DNS·라우팅·정책도 포함될 수 있습니다. 클라이언트의 일반 구독 메뉴가 전체 설정을 지원하지 않을 수 있으며, 전체 설정 메뉴가 화면의 모든 설정을 적용하는 것도 아닙니다. 먼저 가져올 대상이 무엇인지 확인한 뒤 알맞은 기능을 선택하세요. 전체 설정이 라우팅을 담당하는데 화면의 프리셋을 계속 바꾸면 설정이 바뀌어 보이더라도 실제 동작은 그대로일 수 있습니다. 이는 프로토콜 자체의 문제가 아닙니다.

v2rayN에서 v2rayNG나 v2flyNG로 옮길 때는 제공업체가 명시적으로 제공한 호환 구독이나 공유 형식을 우선 사용하세요. 데스크톱용으로 생성된 실행 설정을 복사해도 모바일에 필요한 진입점과 실행 환경이 유지된다고 보장할 수 없습니다. 모바일에서 앱 트래픽을 연결하는 방식과 파일 경로, 백그라운드 제한은 데스크톱과 다릅니다. 아웃바운드 프로토콜이 같더라도 전체 설정이 그대로 적용된다고 볼 수 없습니다. 마이그레이션에서는 플랫폼별 필드를 모두 억지로 유지하기보다 노드의 의미를 보존해야 합니다.

업데이트 정책은 덮어쓰기와 네트워크 경로를 고려해야 합니다

구독 그룹은 보통 클라이언트가 같은 출처에서 온 노드를 식별하도록 도와줍니다. 업데이트할 때 해당 레코드가 교체·삭제되거나 다시 생성될 수 있습니다. 구독 노드에 직접 적용한 수동 수정은 다음 업데이트 후 유지되지 않을 수 있습니다. 매개변수를 임시로 비교해야 한다면 클라이언트의 복사 기능이나 별도 레코드 기능을 사용하고 복사본이 원래 구독과 계속 연결되어 있는지도 확인하세요. 원래 그룹을 보관하면 제공업체의 변경과 로컬 수정 중 어디서 문제가 생겼는지 파악하기 쉽습니다.

업데이트 요청을 직접 연결할지 프록시를 거칠지에 따라 접근성이 달라집니다. 다만 ‘프록시로 업데이트’하면 현재 노드가 이미 작동하지 않을 때 새 설정을 가져올 수 없는 의존성이 생길 수 있습니다. 이 경우 계속 재시도하지 말고 사용할 수 있는 네트워크 경로나 별도로 작동하는 노드로 업데이트하세요. 자동 업데이트 간격도 지나치게 짧게 설정하지 마세요. 업데이트 주기는 제공업체의 변경 빈도와 기기의 백그라운드 조건에 맞춰야 합니다. 요청을 자주 보낸다고 노드 성능이 높아지지는 않습니다.

마이그레이션이 끝나면 노드 하나를 먼저 확인한 뒤 그룹·라우팅·일상 앱을 점검하세요. 모든 설정을 한꺼번에 바꿀 필요는 없습니다. 업데이트는 정상인데 필드가 누락되었다면 전체 인증 정보를 보내지 말고 대상 클라이언트와 프로토콜 유형, 누락된 필드 이름을 제공업체에 알려주세요. 업데이트 실패 유형은 구독 업데이트 문제 해결 글을 참고하세요. 일반적인 사용법은 사용 설명서의 가져오기 절차에서 확인하고 가져오기·파싱·실행의 세 단계를 구분하세요.

08 / Selection workflow

사용 환경에 맞는 프로토콜 선택 및 설정 검증

실제 사용 환경에 맞는 프로토콜을 선택할 때 모든 프로토콜 중 영원히 가장 좋은 하나를 찾을 필요는 없습니다. 먼저 기기와 클라이언트, 서버가 제공하는 유효한 조합을 확인하고 그중 요구 사항을 안정적으로 충족하는 것을 선택하세요. 데스크톱에서는 보통 v2rayN으로 설정을 관리하고, Android에서는 대개 v2rayNG를 먼저 사용합니다. V2Fly 동작이 필요한 경우 v2flyNG를 고려하세요. 클라이언트는 설정을 다루는 진입점일 뿐이며 연결 기능은 코어와 전체 매개변수에 따라 결정됩니다. 노드 이름이 같다고 두 기기의 실행 조건도 같다고 볼 수 없습니다.

일상적인 웹 탐색과 장시간 안정적인 사용

웹 탐색·문서·메신저가 주된 용도라면 최대 다운로드 속도만 보지 말고 짧은 요청의 성공률과 최초 응답, 백그라운드 복구를 우선 확인하세요. 기존 프로토콜 조합이 안정적이고 서버가 계속 유지 관리되며 클라이언트가 설정을 빠짐없이 처리한다면 이름을 최신으로 바꾸려고 자주 이전할 필요는 없습니다. 변경이 필요하다면 같은 네트워크 조건에서 새 조합을 먼저 테스트하고 자주 사용하는 사이트와 이름 해석, 재연결이 정상인지 확인한 다음 일상 설정으로 지정하세요. 기존에 작동하던 설정도 보관해야 합니다.

연결을 자주 만드는 짧은 요청이 많은 환경에서는 핸드셰이크와 연결 재사용을 특히 살펴보세요. 하지만 응답이 느린 원인을 모두 핸드셰이크 탓으로 돌려서는 안 됩니다. 대상 사이트의 응답이 느리거나 라우팅이 잘못되어 직접 연결되거나 DNS가 부적절한 주소를 반환해도 비슷한 증상이 생길 수 있습니다. 먼저 요청이 예상한 아웃바운드를 실제로 통과하는지 확인한 뒤 프로토콜 차이를 비교하세요. 그렇지 않으면 같은 작업에서 두 프로토콜을 비교하는 것이 아니라 서로 다른 네트워크 경로를 비교하게 됩니다.

모바일 네트워크·지속 전송·특수 앱

Wi-Fi와 셀룰러 네트워크를 자주 오가는 환경에서는 한 번의 테스트에서 낮은 지연 시간을 얻는 것보다 연결 복구 능력이 중요합니다. 네트워크 전환 후 기존 연결이 해제되는지, 새 요청이 자동으로 복구되는지, 백그라운드 제한 때문에 클라이언트 실행이 중단되는지 확인하세요. 전환 후에만 문제가 생긴다면 먼저 연결을 다시 수립하고 이름 해석과 현재 네트워크를 점검한 뒤 프로토콜 변경 여부를 결정하세요. 보안 매개변수를 계속 바꿔도 이전 연결이 복구되지 않는 문제는 해결되지 않으며 변수만 늘어납니다.

대용량 파일 전송이나 장시간 영상 시청에서는 안정적인 처리량과 기기 온도가 중요합니다. 서버 지역과 테스트 시간을 일정하게 맞추고 전송이 자주 끊기는지 관찰하세요. 한 번 측정한 최고 속도만으로 판단해서는 안 됩니다. UDP가 필요한 앱은 로컬 연결 방식·코어 아웃바운드·서버·원격 대상까지 전체 경로가 지원하는지 확인하세요. 웹 요청 성공은 이 기능 중 일부만 검증한 것이므로 앱 자체 테스트를 대신할 수 없습니다.

리소스가 제한된 기기에서는 구현이 안정적이고 불필요한 계층이 적으며 양쪽에서 명확히 지원하는 조합을 우선할 수 있습니다. 그렇다고 필요한 보안 보호까지 삭제하라는 뜻은 아닙니다. 지나치게 잦은 자동 속도 측정을 줄이고 적절한 로그 양을 유지하며 반복 백그라운드 작업을 피하고 비정상적인 재연결을 확인하는 편이 더 효과적일 수 있습니다. 기기가 계속 뜨거워지면 프로토콜 연산을 비교하기 전에 실제 트래픽·백그라운드 업데이트·연결 실패 재시도를 구분하세요. 앱 부하 변화를 코어 탓으로 오해하지 않도록 주의해야 합니다.

정해진 순서에 따라 연결 문제를 확인하세요

첫째, 앱이 클라이언트에 연결되는지 확인합니다. 시스템 프록시가 올바른 진입점을 가리키는지, 로컬 수신이 시작되었는지, 앱이 해당 프록시 설정을 따르는지 살펴보세요. 둘째, 라우팅이 예상한 아웃바운드를 선택하는지 확인합니다. 직접 연결 실패를 노드 장애로 오인하지 마세요. 셋째, 원격 주소에 연결할 수 있는지 확인하고 로그를 기준으로 보안 핸드셰이크·프록시 인증·대상 연결을 점검합니다. 로컬에서 원격지까지 범위를 단계별로 좁히면 노드 설정 전체를 먼저 바꾸는 것보다 정확한 원인을 찾기 쉽습니다.

로그에 설정 파싱 실패가 표시되면 먼저 코어 호환성과 필드 문제를 해결하세요. 보안 핸드셰이크가 실패했다면 서버 이름·시각·관련 인증 매개변수를 확인합니다. 인증에 실패하면 사용자 정보와 인바운드 유형을 확인하세요. 인증은 성공했지만 대상에 연결할 수 없다면 DNS·라우팅·서버의 대상 접근 조건을 살펴보세요. 테스트할 때는 한 번에 하나만 바꾸고 결과를 기록한 뒤 원래 값으로 되돌리고 다음 항목을 확인하세요. 즉시 해결되지 않더라도 무엇을 제외했는지 분명해져 여러 설정을 동시에 바꾸는 악순환을 피할 수 있습니다.

라우팅 규칙의 우선순위와 도메인 처리 방식은 사용자 지정 라우팅 규칙 문법에서 확인할 수 있습니다. 클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않는다면 시스템 프록시·라우팅·DNS 점검 목록을 따라 확인하세요. 재설치하거나 플랫폼을 바꿔야 한다면 설치 파일 페이지에서 해당 항목을 선택하면 됩니다. 프로토콜 선택의 결과는 기기와 네트워크 조건을 설명에서 배제한 이름 순위가 아니라, 이해·검증·복구할 수 있는 설정이어야 합니다.