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

1. 먼저 프로토콜 선택 기준 세우기

프로토콜·전송 계층·보안 계층은 서로 다른 기준입니다

클라이언트 노드 이름에는 VLESS, TCP, WebSocket, TLS, REALITY 같은 용어가 함께 표시되는 경우가 많아 서로 경쟁하는 여러 프로토콜처럼 보이기 쉽습니다. 하지만 실제로는 각 항목이 서로 다른 계층에 속합니다. VMess, VLESS, Trojan, Shadowsocks는 주로 클라이언트와 서버가 사용자를 식별하고 데이터를 캡슐화하며 프록시 세션을 수립하는 방식을 정의합니다. TCP, WebSocket, gRPC 등은 데이터 전송 방식을 설명하고, TLS와 REALITY는 연결 보안 및 핸드셰이크 특성을 처리합니다. 완전한 노드는 여러 계층의 조합으로 구성되므로 모든 용어 중 하나만 고르는 방식이 아닙니다.

예를 들어 “VLESS + TCP + REALITY”는 애플리케이션 계층에 VLESS를 사용하고, 하위 계층에서는 TCP로 전송하며, 보안 계층은 REALITY 관련 핸드셰이크 매개변수로 처리한다는 뜻입니다. “VMess + WebSocket + TLS”는 또 다른 조합입니다. 노드를 비교할 때는 계층별로 나누어 살펴보세요. 먼저 클라이언트 코어가 해당 프로토콜을 지원하는지 확인하고, 이어서 전송 방식과 보안 방식을 함께 사용할 수 있는지 점검한 다음 주소·포트·사용자 식별자·서버 이름·공개 키 등의 세부 필드를 확인해야 합니다. 노드 이름의 첫 단어만 비교해서는 현재 기기에 적합한 전체 설정인지 판단할 수 없습니다.

이론적 성능보다 호환성이 우선입니다

프로토콜을 선택할 때 첫 번째 원칙은 추상적인 의미에서 가장 빠른 방법을 찾는 것이 아니라, 서버·구독 변환기·클라이언트 코어·그래픽 인터페이스가 동일한 설정을 빠짐없이 표현하도록 하는 것입니다. 어떤 조합이 더 간결하더라도 클라이언트가 핵심 필드 하나를 무시하면 핸드셰이크 실패, 연결 후 데이터 전송 불가, 가져오기 과정에서 노드 정보 유실로 이어질 수 있습니다. 따라서 먼저 프로토콜 지원 매트릭스를 확인한 뒤 연결 속도·처리량·리소스 사용량을 비교해야 합니다.

데스크톱에서는 Windows·macOS·Linux에서 비교적 완전한 그래픽 설정 기능을 제공하고 일반적인 Xray 프로토콜 필드를 처리할 수 있는 v2rayN을 우선 권장합니다. Android에서는 Xray 코어를 사용하는 v2rayNG가 VLESS와 REALITY 등이 필요한 설정에 적합하고, v2fly 코어를 사용하는 v2flyNG는 VMess·Shadowsocks 및 V2Fly 호환 설정이 중심인 환경에 더 알맞습니다. 두 Android 클라이언트의 인터페이스는 비슷하지만, 이를 근거로 하위 프로토콜 기능까지 완전히 같다고 판단해서는 안 됩니다.

노드 품질을 프로토콜 이름으로 대신할 수 없습니다

실제 연결 품질은 서버 부하·회선 품질·출구 대역폭·거리·도메인 해석·시스템 네트워크 스택·서버 매개변수의 영향을 함께 받습니다. 같은 프로토콜을 사용하는 두 노드도 성능 차이가 클 수 있고, 서로 다른 프로토콜도 회선 조건에 따라 정반대의 결과를 보일 수 있습니다. 프로토콜은 캡슐화 방식과 기능 범위를 결정할 뿐 노드의 대역폭·안정성·사용 가능 기간을 직접 보장하지 않습니다.

따라서 먼저 완전히 가져올 수 없는 조합을 호환성 기준으로 제외한 뒤, 동일한 기기·네트워크·비슷한 시간대에서 실제 연결 지연·웹 응답·지속 다운로드 성능을 비교하는 것이 좋습니다. 클라이언트의 ICMP Ping, TCP 실제 연결 지연, 다운로드 속도 측정은 서로 다른 네트워크 구간을 측정하므로 단순히 가장 작은 숫자 순으로 정렬할 수 없습니다. 세 가지 테스트의 차이가 궁금하다면 Ping·실제 연결 지연·다운로드 속도 측정의 차이를 계속 읽어 보세요.

2. VMess와 VLESS: 완전한 세션에서 간결한 인증까지

VMess의 설계 배경과 세션 특성

VMess는 Project V 초기 생태계를 대표하는 프로토콜 중 하나입니다. 사용자 식별자·시간 기반 검증·세션 수립·데이터 캡슐화를 프로토콜 설계 안에 포함해 클라이언트와 서버가 통일된 구조로 인증과 통신을 수행하도록 합니다. 초기 V2Ray 설정에서 VMess는 많은 역할을 담당했기 때문에 오래된 구독, 장기간 운영된 서버, V2Fly 생태계에서 여전히 자주 사용됩니다. 역사적으로 호환 범위가 넓고 많은 구독 생성 시스템과 그래픽 클라이언트가 기본 필드를 인식한다는 점이 장점입니다.

VMess 설정에는 일반적으로 서버 주소·포트·사용자 식별자·암호화 또는 보안 필드·전송 방식·TLS 등의 외부 옵션이 포함됩니다. 사용자 식별자는 서버와 일치해야 하며 클라이언트 기기의 시스템 시간도 정상이어야 합니다. 시간 오차가 인증 과정에 영향을 줄 수 있기 때문입니다. VMess 연결 실패를 점검할 때는 주소와 포트뿐 아니라 기기 시간·사용자 식별자·전송 경로·Host 필드·TLS 서버 이름·구독 만료 여부도 확인해야 합니다. 이 필드들을 점검하지 않고 속도만 다시 측정하면 설정 계층의 오류를 찾기 어렵습니다.

VMess는 자체적으로 처리하는 세션 로직이 많아 VLESS보다 프로토콜 처리가 다소 복잡합니다. 다만 일반적인 데스크톱에서는 이러한 차이가 네트워크 품질로 인한 변동보다 작은 경우가 많습니다. 저전력 Android 기기, 고동시성 연결, 지속적인 대용량 트래픽 환경에서야 캡슐화 복잡도가 CPU 깨우기·메모리 할당·배터리 사용량 변화로 나타날 가능성이 높습니다. 그럼에도 전송 방식과 애플리케이션 동작이 프로토콜 자체보다 더 큰 영향을 줄 수 있습니다.

VLESS가 간결한 설계를 채택한 이유

VLESS는 프로토콜 내부가 담당하는 암호화와 상태 관리의 책임을 줄이고, 보안 기능을 TLS·REALITY 같은 외부 계층에 더 많이 맡기는 데 초점을 둡니다. 사용자 식별자와 필요한 프록시 세션 필드는 유지하지만, 완전한 데이터 암호화 계층을 별도로 중복 구현하지 않습니다. 이를 통해 프로토콜 처리 경로를 줄이고 보안 계층과 전송 계층의 역할을 명확히 나눌 수 있습니다. VLESS 자체를 적절한 보안 설정 없이 “자동으로 안전한 프로토콜”로 이해해서는 안 되며, 노드의 보안성은 VLESS라는 이름이 아니라 전체 조합에 달려 있습니다.

이러한 계층화 방식 때문에 VLESS 노드에는 TLS 또는 REALITY가 함께 표시되는 경우가 많습니다. 클라이언트로 가져올 때는 서버 이름·지문 옵션·공개 키·짧은 식별자·흐름 제어 매개변수 등의 조합 필드를 모두 보존해야 합니다. 일부 필드는 특정 전송 방식·보안 방식·코어 구현에서만 유효하므로 다른 조합에 임의로 복사하면 핸드셰이크가 완료되지 않을 수 있습니다. 특히 흐름 제어 필드는 범용 속도 스위치가 아니며, 서버와 클라이언트가 동일한 방식으로 설정된 경우에만 활성화해야 합니다.

사용자 관점에서 VLESS의 주요 가치는 인터페이스 옵션이 적다는 데 있지 않고, 프로토콜의 역할이 명확해 최신 전송 및 보안 메커니즘과 조합하기 쉽다는 데 있습니다. 새 설정에서 서버가 VLESS를 명확히 제공하고 현재 클라이언트가 모든 필드를 완전히 인식한다면 우선 테스트 대상으로 삼을 수 있습니다. 기존 VMess 노드가 안정적이고 구독 업데이트도 정상이라면 프로토콜 이름이 오래되었다는 이유만으로 즉시 이전할 필요는 없습니다. 필드가 누락된 새 조합보다 안정적으로 동작하는 완전한 설정이 더 신뢰할 만합니다.

두 프로토콜의 호환성과 마이그레이션 범위

VMess와 VLESS는 노드 유형 드롭다운을 바꾸는 것만으로 서로 변환되는 형식이 아닙니다. 서버에는 해당 인바운드 프로토콜이 설정되어야 하며, 클라이언트의 사용자 식별자·전송 계층·보안 계층도 이에 맞아야 합니다. VMess 공유 링크의 프로토콜 헤더만 VLESS로 바꾸거나 그래픽 인터페이스에서 프로토콜 유형만 전환해도 사용할 수 있는 노드가 자동으로 생성되지는 않습니다. 마이그레이션은 서버 설정과 구독 내용이 함께 변경되어야 합니다.

구독 변환 과정에서 기존 필드가 새로운 필드로 매핑될 수도 있습니다. 예를 들어 일부 과거 VMess 데이터의 보안 필드·위장 유형·경로 표현은 구독 형식에 따라 이름이 다릅니다. 가져온 뒤에는 노드가 목록에 나타났는지만 보지 말고 노드 편집 화면에서 항목을 하나씩 확인해야 합니다. 노드가 표시된다는 것은 파서가 기본 레코드를 인식했다는 뜻일 뿐, 모든 고급 필드가 보존되었다는 의미는 아닙니다.

3. Trojan·Shadowsocks·REALITY의 경계

Trojan: 간결한 인증, 완전한 TLS 설정이 전제

Trojan은 직관적인 비밀번호 인증 구조를 사용하며 일반적으로 TLS 연결 위에서 동작합니다. 보안 전송은 검증된 TLS 구현에 맡기고, 자체적으로는 프록시 요청과 신원 확인을 담당합니다. 노드 필드는 복잡한 VMess 조합보다 짧아 보이지만 실제 연결 성립 여부는 주소·포트·비밀번호·서버 이름·인증서 관련 설정·전송 옵션에 달려 있습니다. 비밀번호가 맞더라도 서버 이름이 틀리면 TLS 핸드셰이크 단계에서 연결이 중단될 수 있습니다.

Trojan은 서버에 TLS가 올바르게 구성되어 있고 클라이언트가 서버 이름을 정확히 전달할 수 있는 환경에 적합합니다. 기본 모델을 이해하기 쉽고 구독 형식도 널리 사용됩니다. 다만 구현에 따라 WebSocket·gRPC 등의 전송 방식이 추가될 수 있으므로 Trojan을 단순히 “주소·포트·비밀번호” 세 항목으로만 볼 수는 없습니다. 경로·서비스 이름·Host·ALPN 등의 필드가 호환성 조건이 될 수 있습니다. 가져온 뒤 노드가 존재하지만 연결되지 않는다면 원본 구독의 필드와 하나씩 비교하세요.

성능 측면에서 Trojan의 프로토콜 캡슐화는 비교적 직접적이지만 최초 TLS 핸드셰이크에는 연산과 왕복 비용이 발생합니다. 장시간 연결이 수립되면 이후 데이터 전송에 비용이 분산되지만, 짧은 연결을 자주 만들면 핸드셰이크 횟수가 응답 속도와 배터리에 더 큰 영향을 줍니다. 따라서 한 번의 속도 측정만으로 VMess나 VLESS보다 반드시 빠르다고 판단해서는 안 됩니다. 연결 재사용 여부와 네트워크 전환 빈도도 결과를 바꿀 수 있습니다.

Shadowsocks: 가벼운 데이터 전달과 방식 호환성

Shadowsocks는 흔히 SS라고 줄여 부르며, 가벼운 전달을 목표로 설계되었습니다. 기본 설정은 대개 서버·포트·비밀번호·암호화 방식으로 구성됩니다. 여러 계층의 조합 필드를 포함하는 노드보다 다양한 클라이언트와 구독 형식으로 표현하기 쉽고, 리소스가 제한된 기기에도 적합합니다. 그러나 필드가 적다고 해서 호환성을 무시할 수 있는 것은 아닙니다. 클라이언트와 서버가 동일한 암호화 방식을 지원해야 하며, 구형 구현과 최신 구현의 지원 목록이 다를 수 있습니다.

구독을 가져온 뒤 암호화 방식이 바뀌거나 비어 있거나 지원되지 않는 것으로 표시되면 속도를 다시 측정한다고 노드가 복구되지는 않습니다. 현재 코어가 해당 방식을 구현하는지 확인하고, 구독 변환 과정에서 방식 이름이 다른 표기로 변경되지 않았는지 점검해야 합니다. 플러그인 확장을 사용하면 추가 매개변수가 필요하므로 기본 SS 필드만 남겨서는 안 됩니다. v2rayN·v2rayNG·v2flyNG 모두 일반적인 SS 노드를 처리할 수 있지만, 구체적인 방식과 확장 기능은 클라이언트와 함께 실행되는 코어에 따라 달라집니다.

SS는 프로토콜 처리 오버헤드가 대체로 낮아 연결 수가 많지 않고 설정 구조가 명확한 일상적인 사용에 적합합니다. 실제 처리량은 회선·암호화 방식·기기 프로세서·서버 부하가 함께 결정합니다. 저사양 Android 기기에서는 코어가 기본 지원하고 연산 비용도 적절한 방식을 선택하는 편이 노드 이름을 바꾸는 것보다 더 큰 효과를 낼 수 있습니다. 암호화 방식은 서버와의 약속이므로 클라이언트에서 임의로 변경하지 마세요.

REALITY는 보안 계층 조합이며 독립적인 프록시 프로토콜이 아닙니다

REALITY는 VLESS와 함께 표시되는 경우가 많아 VMess나 Trojan과 나란히 놓인 프로토콜로 오해하기 쉽습니다. 더 정확히는 특정 핸드셰이크와 보안 계층 로직을 처리하며, VLESS 같은 프로토콜이 여전히 프록시 세션을 담당합니다. REALITY 노드에는 일반적으로 서버 이름·공개 키·짧은 식별자·지문·필요할 경우 흐름 제어 매개변수도 필요합니다. 이 필드들은 서로 연관되어 있어 하나라도 빠지면 클라이언트가 핸드셰이크를 완료하지 못할 수 있습니다.

REALITY 관련 기능은 주로 Xray 코어에서 제공되므로 v2rayNG와 Xray를 핵심 실행 옵션으로 사용하는 v2rayN이 이러한 노드 처리에 더 적합합니다. v2fly 코어를 사용하는 v2flyNG가 동일한 필드 지원을 제공한다고 가정해서는 안 됩니다. 구독 파서가 노드 제목을 읽더라도 저장 과정에서 코어가 인식하지 못하는 필드를 버릴 수 있습니다. 호환성을 판단할 때는 목록에 “REALITY”라는 글자가 보이는지만 확인하지 말고 노드 편집 화면에 해당 보안 방식과 매개변수가 있는지 살펴봐야 합니다.

서버 이름과 대상 주소의 의미도 혼동해서는 안 됩니다. 노드 연결 주소는 클라이언트가 네트워크 연결을 수립할 위치를 결정하고, 서버 이름은 핸드셰이크 매개변수에 사용되며 서로 다른 필드일 수 있습니다. 공개 키는 사용자 식별자가 아니고, 짧은 식별자는 포트에 붙이는 값이 아닙니다. 설정을 복사할 때는 필드 위치를 유지하고 주소나 메모에 합치지 마세요. 지문 필드는 서버 설정이 지원하는 값을 사용해야 하며, 클라이언트 기본값이 모든 노드에서 서로 호환되는 것은 아닙니다.

4. 연결 속도·처리량·리소스 사용량 비교 방법

연결 속도는 여러 단계로 구성됩니다

사용자가 느끼는 “로딩 속도”에는 일반적으로 도메인 해석, 서버까지의 네트워크 왕복, TCP 연결 수립, 보안 핸드셰이크, 프로토콜 인증, 서버의 대상 연결, 첫 바이트 응답 등이 포함됩니다. VMess·VLESS·Trojan·SS의 프로토콜 처리는 그중 일부에 불과합니다. 노드와의 거리가 멀거나 회선이 혼잡하면 캡슐화 처리 시간을 조금 줄여도 전체 응답이 크게 달라지지 않습니다. 회선 조건이 비슷할 때는 핸드셰이크 방식과 연결 재사용이 차이를 더 뚜렷하게 만들 수 있습니다.

클라이언트의 지연 시간 측정도 모든 단계를 포함하지 않을 수 있습니다. 일반 Ping은 주소까지의 네트워크 왕복만 측정할 수 있고, 실제 연결 지연은 프록시 연결을 실제로 수립하는 경우가 많으며, 다운로드 속도 측정은 출구 대역폭·테스트 대상·지속 전송 능력의 영향을 함께 받습니다. 따라서 “Ping은 낮지만 웹 응답은 보통”이거나 “실제 연결 지연은 높지만 다운로드는 안정적”인 결과도 모순이 아닙니다. 노드를 고를 때는 용도에 맞는 지표를 사용하세요. 웹 탐색은 최초 연결과 응답, 지속 전송은 안정적인 처리량, 실시간 애플리케이션은 지터와 패킷 손실이 더 중요합니다.

프로토콜을 비교할 때는 변수를 통제해야 합니다. 동일한 클라이언트·기기·네트워크·비슷한 지역 및 서버 부하에서 짧은 시간 동안 여러 번 테스트해야 우연한 변동을 줄일 수 있습니다. 두 노드에서 프로토콜·서버 지역·전송 방식을 동시에 바꾸면 결과를 프로토콜 탓으로 돌릴 수 없습니다. 실험실 수준의 정밀도는 필요 없지만 회선 차이를 VLESS나 Trojan의 고유한 장점으로 오인하지 않도록 해야 합니다.

애플리케이션 프로토콜보다 전송 캡슐화가 처리량에 더 큰 영향을 줄 수 있습니다

TCP 직접 전송은 구조가 대체로 간단합니다. WebSocket은 프레임 캡슐화가 추가되고 HTTP 업그레이드 과정에 의존합니다. gRPC는 HTTP/2를 기반으로 자체적인 스트림 및 연결 관리 방식을 사용합니다. 전송 방식마다 서버 배포·연결 재사용·헤더 오버헤드·중간 네트워크 장비 호환성에서 서로 다른 장단점이 있습니다. 대용량 파일을 지속 전송할 때는 적은 헤더 오버헤드가 유일한 병목이 아니며, 짧은 요청이 많을 때는 핸드셰이크와 재사용 전략이 더 중요할 수 있습니다.

전송 방식은 메모리와 프로세서 부하에도 영향을 줍니다. 연결 수가 늘어나면 각 연결의 버퍼·프로토콜 상태·암호화 컨텍스트가 리소스를 사용합니다. WebSocket이나 gRPC가 반드시 더 느린 것은 아니지만 단순 TCP보다 구현 경로가 길어 클라이언트와 서버의 구현 품질에 따라 성능 차이가 커질 수 있습니다. 리소스가 제한된 기기에서는 불필요한 다중 캡슐화를 줄이는 편이 안정적인 성능을 얻기 쉽습니다.

UDP 기반 서비스는 별도로 관찰해야 합니다. 일부 프로토콜과 전송 조합은 UDP를 전달할 수 있지만, 원본 데이터그램으로 처리하는지 다른 연결을 통해 전달하는지는 구현에 따라 다릅니다. 게임·음성·DNS 요청은 패킷 손실·지터·헤드 오브 라인 블로킹에 민감하므로 TCP 다운로드 속도만으로 UDP 체감을 예측할 수 없습니다. 클라이언트에서 TUN 모드를 켜면 시스템 트래픽의 유입 방식도 달라져 라우팅 규칙·DNS 정책·코어 처리 경로가 측정 결과에 함께 반영됩니다.

리소스 사용량은 시작 순간이 아니라 안정 구간을 봐야 합니다

코어가 시작될 때는 설정을 읽고 라우팅 규칙을 만들며 DNS·로그·연결 관리 모듈을 초기화하므로, 이때의 일시적인 프로세서 사용량은 대표성이 없습니다. 설정과 애플리케이션 활동을 비슷하게 유지한 채 일정한 안정 구간을 관찰하고 유휴·웹 탐색·지속 전송 상태를 각각 기록하는 것이 더 의미 있습니다. 메모리 사용량도 상주 메모리·연결 버퍼·시스템 캐시를 구분해야 하며, 한순간의 숫자만으로 프로토콜 효율을 판단하기는 어렵습니다.

로그 수준은 리소스 사용량에 영향을 줍니다. 문제를 해결할 때 상세 로그를 켜면 핸드셰이크·DNS·라우팅 문제를 찾는 데 도움이 되지만, 높은 상세도를 계속 유지하면 쓰기와 포맷팅 작업이 늘어납니다. 일상 사용에서는 warning이나 error처럼 절제된 수준을 선택하고, 점검할 때만 일시적으로 높인 뒤 문제가 확인되면 되돌리는 것이 좋습니다. 노드가 많을 때 대량 속도 측정과 구독 업데이트가 만드는 일시적인 피크는 현재 연결 프로토콜의 안정적인 사용량과 구분해야 합니다.

5. Android 배터리 사용량과 백그라운드 연결

배터리 소모는 암호화 연산만이 아니라 지속적인 깨우기에서 발생합니다

Android에서 v2rayNG 또는 v2flyNG를 실행하면 배터리 소모는 여러 요소가 함께 만듭니다. 코어의 데이터 처리, 가상 네트워크 인터페이스의 트래픽 전달, 포그라운드 서비스 유지, 시스템 네트워크 전환, DNS 요청, 로그 기록, 다른 앱의 백그라운드 요청이 모두 프로세서와 무선 모듈을 깨울 수 있습니다. 프로토콜 암호화는 그중 하나일 뿐입니다. 노드가 “연결됨” 상태여도 애플리케이션 트래픽이 없다면 지속적인 동영상 재생·파일 동기화·대량 알림이 발생하는 상태와 배터리 소모 양상이 다릅니다.

셀룰러 네트워크와 무선 LAN은 전력 소비 특성도 다릅니다. 신호가 약하면 무선 모듈이 더 높은 송신 전력을 사용하고, 네트워크 상태가 바뀐 뒤 연결을 반복해서 다시 수립할 수 있습니다. 이동 중에는 네트워크 주소 변경·절전 해제·연결 만료로 클라이언트가 채널을 다시 만들 수 있습니다. 고정된 무선 네트워크에서 안정적인 프로토콜 조합이 네트워크를 자주 전환하는 환경에서도 같은 배터리 사용량을 보인다고 할 수는 없습니다.

장시간 연결은 반복적인 핸드셰이크를 줄이는 데 도움이 되지만, 연결을 유지하려면 하트비트나 시스템 유지 메커니즘이 필요합니다. 하트비트가 너무 잦으면 깨우기 횟수가 늘고, 간격이 너무 길면 네트워크 장비가 연결을 정리해 재연결이 발생할 수 있습니다. 사용자가 하위 하트비트를 직접 조정할 필요는 거의 없습니다. 안정적인 노드를 선택하고 잦은 전환과 백그라운드 대량 속도 측정을 피하며 클라이언트가 코어와 시스템이 권장하는 기본 연결 매개변수를 사용하게 하는 편이 현실적입니다.

프로토콜과 전송 방식이 배터리에 미치는 상대적 영향

동일한 회선 조건이라면 처리 경로가 짧고 연결 재수립이 적은 조합이 일반적으로 배터리 관리에 유리합니다. VLESS는 보안 역할을 외부 메커니즘에 맡기고 SS의 기본 구조도 가볍지만, 실제 배터리 소모는 TLS 또는 REALITY 핸드셰이크·전송 캡슐화·애플리케이션 연결 수·네트워크 안정성에 좌우됩니다. VMess의 세션 처리가 더 완전하다고 해서 모든 기기에서 배터리를 확실히 더 많이 쓰는 것은 아닙니다. VMess 노드가 안정적인 반면 가벼운 프로토콜 노드가 계속 재연결된다면 오히려 전자가 배터리를 덜 사용할 수 있습니다.

WebSocket과 gRPC는 각각 별도의 프로토콜 처리와 연결 관리를 추가합니다. 최신 기기에서는 정상적인 트래픽에서 차이가 작을 수 있지만, 저성능 기기·많은 동시 단기 연결·장시간 백그라운드 실행에서는 추가 캡슐화가 눈에 띄는 변화로 나타날 수 있습니다. TUN 모드를 사용하면 수동 프록시 포트를 거치지 않던 애플리케이션 요청을 포함해 더 많은 시스템 트래픽이 클라이언트로 들어옵니다. TUN으로 전환한 뒤 배터리 소모가 늘었다면 먼저 백그라운드 앱이 계속 네트워크를 사용하는지 확인한 다음 프로토콜과의 관련성을 판단하세요.

DNS 설정도 중요합니다. 해석 실패·접속할 수 없는 결과·중복 조회를 만드는 규칙 때문에 클라이언트와 애플리케이션이 연결을 반복 시도할 수 있습니다. 겉으로는 프록시 클라이언트가 계속 활동하는 것처럼 보여도 원인은 DNS나 라우팅 규칙일 수 있습니다. 점검할 때는 복잡한 규칙을 잠시 줄이고 안정적인 노드를 사용하면서 시스템 배터리 화면에서 어떤 앱이 계속 트래픽을 만드는지 관찰하세요. 가상 네트워크 서비스는 전달 활동이 더 많이 집계될 수 있으므로 클라이언트가 배터리 목록에서 차지하는 비율만으로 결론 내리지 마세요.

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

v2rayNG와 v2flyNG 또는 두 프로토콜을 비교할 때는 화면 밝기·네트워크 유형·백그라운드 앱·사용 시간을 최대한 동일하게 유지해야 합니다. 먼저 기기의 충전 상태를 안정시키고 대량 업데이트와 속도 측정을 끈 뒤 대기·가벼운 웹 탐색·지속 전송을 각각 관찰하세요. 몇 분 동안의 배터리 백분율 변화는 정밀도가 낮으므로 시스템 배터리 곡선·포그라운드 활동·발열을 함께 고려하는 것이 좋습니다.

화면을 잠근 뒤 특정 노드가 자주 끊긴다면 먼저 Android의 앱 백그라운드 실행 제한·포그라운드 서비스 상태·네트워크 전환을 확인하세요. 이어서 클라이언트 로그에 연결 시간 초과·DNS 오류·핸드셰이크 실패가 반복되는지 살펴봅니다. 네트워크 복구 직후 실패가 집중된다면 연결 재수립 문제일 수 있고, 고정된 네트워크에서도 계속 발생한다면 노드 필드와 서버 가용성을 확인해야 합니다. 일반적인 점검 절차는 자주 묻는 질문에서 더 확인할 수 있습니다.

일상적인 최적화는 불필요한 작업을 줄이는 것부터 시작할 수 있습니다. 필요한 경우에만 구독을 업데이트하고 클라이언트가 계속 속도를 측정하지 않도록 하세요. 노드 목록이 지나치게 많다면 그룹화나 필터를 사용하고, 점검이 끝나면 일반 로그 수준으로 되돌리며, 전역 트래픽 가로채기가 꼭 필요할 때만 TUN을 켜세요. 재연결이 적고 실제 연결 테스트가 안정적인 노드를 선택하는 것도 중요합니다. 프로토콜 이름 자체가 배터리 스위치는 아니며, 안정적인 연결과 적절한 트래픽량이 대체로 더 큰 영향을 줍니다.

6. V2Fly와 Xray 코어 계열 및 설정 호환성

Project V 생태계와 두 코어의 방향

Project V는 프록시 프로토콜·핵심 프로그램·설정 체계·클라이언트 도구가 함께 이루는 오픈 소스 생태계입니다. V2Ray라는 말은 전체 기술 체계를 가리키기도 하고 특정 코어 구현을 뜻하기도 하므로 호환성을 논할 때는 프로토콜·설정 형식·구체적인 코어 중 무엇을 말하는지 명확히 해야 합니다. V2Fly는 V2Ray의 커뮤니티 유지 관리 방향을 이어받아 기존 프로토콜과 설정 생태계를 중시하고, Xray는 유사한 설정 모델 위에서 기능을 확장하며 VLESS·REALITY 관련 기능을 제공합니다.

두 코어는 공통된 역사와 유사한 개념을 많이 공유하지만, 이름만 다른 동일한 기능의 프로그램으로 볼 수는 없습니다. 기본적인 인바운드·아웃바운드·라우팅·DNS·로그 구조는 상당 부분 유사하지만, 구체적인 프로토콜 필드·전송 옵션·보안 설정·기본 동작은 다를 수 있습니다. 설정 파일을 다른 코어가 파싱할 수 있다고 해서 모든 항목이 같은 방식으로 작동하는 것은 아닙니다. 반대로 파싱에 실패했다고 해서 전체 설정 체계가 호환되지 않는 것도 아니며, 다른 코어 전용 필드가 포함된 경우일 수 있습니다.

그래픽 클라이언트는 여기에 또 하나의 매핑 계층을 추가합니다. v2rayN은 인터페이스·구독·시스템 프록시 동작을 코어 설정으로 변환하고, v2rayNG는 Xray 코어 기능을 주요 기반으로 하며, v2flyNG는 v2fly 코어에 대응합니다. 사용자가 인터페이스에서 보는 것은 노드와 스위치지만 실제 연결 동작은 생성된 설정과 하위 코어가 함께 결정합니다. 문제를 점검할 때는 “구독에서 필드를 파싱하지 못한 경우”, “인터페이스에 옵션이 없는 경우”, “코어가 기능을 지원하지 않는 경우”를 구분해야 합니다.

공통 설정 뼈대와 전용 필드

두 코어 유형은 대체로 JSON 설정을 사용하며 로그·인바운드·아웃바운드·DNS·라우팅 등의 부분으로 구성됩니다. 다음 최소 예시는 로컬 SOCKS 인바운드를 만들고 자유 아웃바운드를 통해 직접 접속하며, 설정 파일 구조·수신 포트·코어 시작 과정을 확인하는 데 사용합니다. 원격 노드는 포함하지 않으므로 클라이언트가 생성한 일상적인 설정을 대신할 수 없습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

Xray를 올바르게 설치하고 위 내용을 config.json으로 저장했다면 터미널에서 다음 명령을 실행해 설정이 시작되는지 확인할 수 있습니다. 포트가 다른 프로그램에서 사용 중이면 충돌하는 프로그램을 먼저 종료하거나 수신 포트를 변경하세요. 그래픽 클라이언트를 정상적으로 사용할 때는 일반적으로 이 명령을 직접 실행할 필요가 없습니다.

xray run -config config.json
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

실제 VLESS·VMess·Trojan 또는 SS 아웃바운드에는 서버 목록·사용자 식별자·비밀번호·암호화 방식·흐름 설정이 추가됩니다. REALITY 관련 필드는 특히 주의해서 확인해야 하는 확장 기능입니다. 이러한 필드가 포함된 Xray 설정을 지원하지 않는 코어에 그대로 넘기면 시작 시 알 수 없는 필드 오류가 발생하거나, 상위 변환 도구가 미리 삭제할 수도 있습니다. 코어 간 설정을 사용할 때는 JSON 문법뿐 아니라 프로토콜 의미도 항목별로 확인해야 합니다.

설정 호환성이 곧 구독 호환성은 아닙니다

코어 설정 파일과 구독 파일은 서로 다른 문제를 해결합니다. 코어 설정은 프로그램이 어떻게 수신·라우팅·연결할지를 정의하고, 구독은 노드 레코드를 전달한 뒤 클라이언트가 완전한 코어 설정을 생성하도록 합니다. 어떤 클라이언트는 특정 공유 링크를 지원하면서도 전체 코어 JSON 가져오기는 제공하지 않을 수 있습니다. 반대로 코어 설정 가져오기를 허용하더라도 모든 필드를 편집 가능한 노드로 변환하지 못할 수 있습니다. 따라서 “Xray가 실행된다”는 사실만으로 “모든 구독 클라이언트에서 가져올 수 있다”고 결론 내릴 수 없습니다.

v2rayN은 데스크톱에서 노드 관리·구독 업데이트·라우팅 선택·시스템 프록시 전환에 적합합니다. v2rayNG는 Android에서 Xray 관련 프로토콜을 사용하는 데 알맞고, v2flyNG는 V2Fly 계열의 대안입니다. 세 클라이언트는 구독 링크나 단일 노드 공유 정보로 일반적인 설정을 동기화할 수 있지만, 복잡한 라우팅·DNS 규칙·코어 전용 필드·클라이언트 인터페이스 설정은 완전히 호환되지 않는 경우가 많습니다. 여러 기기에서 동기화하는 방법은 구독 링크·설정 내보내기·QR 코드 공유를 참고하세요.

코어 차이가 있을 때의 점검 순서

먼저 노드의 원래 프로토콜과 모든 보안·전송 필드를 기록합니다. 다음으로 현재 클라이언트가 실제로 사용하는 코어 계열을 확인하고, 노드 편집 화면에서 해당 필드가 존재하는지 살펴본 뒤, 실행 로그에서 오류가 파싱·시작·핸드셰이크·전송 중 어느 단계에서 발생했는지 판단합니다. 가져온 뒤 특정 필드에 대응하는 입력란이 아예 없다면 대개 클라이언트나 코어의 기능 범위 문제이지 네트워크 지연 문제가 아닙니다. 이때는 해당 설정을 지원하는 클라이언트로 바꾸고, 추측으로 핵심 필드를 삭제해서는 안 됩니다.

7. 구독 형식·공유 링크·필드 호환성

구독은 노드 컨테이너이지 통합 설정 표준이 아닙니다

“구독 링크”는 클라이언트가 여러 노드 데이터를 가져오는 진입점을 뜻하지만, 반환되는 내용의 구성 방식은 서로 다를 수 있습니다. 여러 줄의 공유 링크, 인코딩된 텍스트, 구조화된 노드 목록, 클라이언트 전용 형식 등이 대표적입니다. 클라이언트는 먼저 외부 형식을 식별한 뒤 각 노드 레코드를 파싱하고, 마지막으로 필드를 코어 설정에 매핑합니다. 어느 한 단계라도 호환되지 않으면 구독 업데이트 실패·노드 수 이상·고급 매개변수 유실이 발생할 수 있습니다.

VMess 공유 데이터에는 구조화된 필드가 많이 포함되는 경우가 많습니다. VLESS·Trojan·SS는 URI 형식으로 제공되고 쿼리 매개변수로 전송 및 보안 옵션을 표현하는 경우가 흔합니다. URI를 인식한다고 해서 현재 클라이언트가 모든 매개변수 이름을 지원하는 것은 아닙니다. 특히 REALITY 공개 키·짧은 식별자·지문·흐름 제어, gRPC 서비스 이름, WebSocket 경로와 Host 등은 오래된 파서나 형식 변환 과정에서 누락되기 쉽습니다.

노드 메모는 일반적으로 표시용이며 연결에는 사용되지 않습니다. 메모를 바꿔도 프로토콜은 달라지지 않지만 메모를 기준으로 자동 그룹화하는 규칙에는 영향을 줄 수 있습니다. 반면 주소·포트·사용자 식별자·비밀번호·암호화 방식·서버 이름·보안 매개변수는 연결 필드이므로 화면을 정리하려고 삭제해서는 안 됩니다. 가져오기 이상이 발생하면 원본 구독을 비교 자료로 보존하고 여러 필드를 연속해서 수동 변경하지 마세요. 어떤 변경이 결과를 바꿨는지 알기 어려워집니다.

가져오기 성공과 연결 성공은 서로 다른 점검 단계입니다

구독을 업데이트한 뒤 노드가 나타났다는 것은 클라이언트가 기본 파싱을 완료했다는 뜻일 뿐입니다. 다음으로 노드 유형이 올바른지, 전송 및 보안 방식이 일치하는지, 핵심 입력란에 값이 있는지 확인한 뒤 실제 연결 테스트를 진행해야 합니다. 모든 노드가 가져와지지 않았다면 먼저 구독 주소 접속 가능 여부·반환 내용의 공백 여부·구독 유형 선택 오류를 확인하세요. 특정 프로토콜만 누락되었다면 형식이나 코어 기능 문제일 가능성이 더 큽니다.

노드는 존재하지만 모두 연결에 실패한다면 먼저 동일한 서버 이름·전송 방식·코어 전용 설정 등 공통 필드가 있는지 확인하세요. 일부 노드만 실패한다면 주소·포트·사용자 정보를 점검해야 합니다. 모든 실패를 구독 주소 탓으로 돌리면 노드 수준의 오류를 놓칠 수 있습니다. 반대로 구독 업데이트 자체가 오류를 내는 동안 노드를 계속 바꿔도 소용이 없습니다. 업데이트 과정이 아직 노드 연결 단계에 도달하지 않았기 때문입니다.

구독 업데이트에는 덮어쓰기 규칙도 관련됩니다. 일부 클라이언트는 구독 그룹에 따라 기존 노드를 교체하므로 수동으로 수정한 구독 노드가 다음 업데이트에서 원래대로 돌아갈 수 있습니다. 다른 경우에는 로컬 노드를 유지하면서 새 레코드를 추가해 중복 항목이 생길 수 있습니다. 장기간 사용자 지정 매개변수를 유지해야 한다면 먼저 클라이언트의 업데이트 동작을 확인한 뒤 독립적인 수동 노드를 유지할지 구독 원본을 수정할지 결정하세요. v2rayN 구독 가져오기의 기본 절차는 빠른 시작 안내를 참고하세요.

클라이언트 간 동기화에서는 공통으로 지원되는 범위를 받아들여야 합니다

v2rayN에서 v2rayNG로 동기화할 때 일반적인 노드 프로토콜과 기본 필드는 동일한 구독으로 유지할 수 있습니다. 그러나 데스크톱의 시스템 프록시 설정·라우팅 규칙 그룹·프로세스 매칭·인터페이스 설정은 Android에 자동으로 나타나지 않습니다. 반대 방향도 마찬가지입니다. Android의 앱별 선택과 백그라운드 서비스 설정은 노드 구독에 포함되지 않습니다. 구독은 서버 연결 정보를 관리하는 데 적합하지만 모든 기기 설정을 백업하는 용도는 아닙니다.

v2rayNG와 v2flyNG의 차이는 주로 코어 기능에서 비롯됩니다. REALITY가 포함된 구독은 v2rayNG에서 완전히 인식되더라도 v2flyNG에서는 동일한 설정으로 만들 수 없을 수 있습니다. 이때 REALITY 필드를 일반 TLS로 낮춰 바꾸려고 해서는 안 됩니다. 두 기능은 임의로 교체할 수 있는 스위치가 아니기 때문입니다. 더 나은 방법은 각 코어가 지원하는 노드 유형을 제공하거나 Android에서 구독 기능에 맞는 클라이언트를 선택하는 것입니다.

QR 코드 공유는 본질적으로 단일 노드 URI를 시각적으로 인코딩한 방식이며, 한 레코드의 길이와 클라이언트 파싱 능력에 제한됩니다. 소수의 노드를 임시로 전달하는 데는 적합하지만 장기적인 구독 업데이트를 대신할 수는 없습니다. 설정 파일 내보내기에는 더 완전한 라우팅 및 DNS 정보가 포함될 수 있지만 클라이언트 전용 구조 때문에 다른 클라이언트에서 호환되지 않을 가능성이 더 큽니다. 동기화 방식을 선택할 때는 먼저 목적을 정하세요. 노드만 동기화하려면 구독, 단일 노드를 임시 공유하려면 QR 코드, 고급 설정까지 보존하려면 클라이언트가 지원하는 내보내기 방식을 사용하고 대상 기기에서 항목별로 다시 확인하세요.

8. 사용 시나리오별 프로토콜 및 클라이언트 선택

데스크톱 일상 사용: 클라이언트를 먼저 고르고 완전한 노드를 선택하세요

Windows·macOS·Linux 데스크톱에서는 v2rayN을 우선 사용하세요. 구독 관리·시스템 프록시 전환·노드 편집·연결 로그 확인에 적합합니다. 구독에 VLESS·VMess·Trojan·SS가 함께 제공된다면 필드가 불완전하거나 코어가 지원하지 않는 노드를 먼저 제외한 뒤 남은 노드에서 실제 연결과 접속 테스트를 진행하세요. 새 설정은 명확한 보안 계층을 갖춘 VLESS를 우선 테스트할 수 있고, 이미 안정적인 VMess나 Trojan 노드는 계속 사용해도 됩니다.

데스크톱 기기는 일반적으로 프로세서와 메모리가 충분하므로 프로토콜 간 작은 처리 오버헤드는 가장 큰 문제가 아닙니다. 연결 안정성·서버 부하·전송 방식·라우팅 설정에 더 주목하세요. 프로세스별 분할 라우팅이나 전역 가로채기가 필요하다면 TUN 모드가 트래픽 진입 경로를 바꾸므로 현재 시스템 프록시와 라우팅 옵션을 기록한 뒤 단계적으로 켜는 것이 좋습니다. TUN 전환 후 일부 앱만 이상하다면 먼저 DNS와 라우팅을 확인하고 바로 프로토콜을 바꾸지는 마세요.

대용량 파일을 다운로드하거나 지속적으로 전송할 때는 한 번의 최저 지연 시간보다 처리량이 안정적이고 지터가 작은 노드를 선택하세요. 업무용 웹과 대화형 애플리케이션은 최초 응답이 더 중요하므로 실제 연결 지연과 실제 페이지 로딩 속도를 우선 비교할 수 있습니다. 같은 프로토콜을 사용하는 노드도 서버 지역과 회선 차이가 캡슐화 차이보다 큰 경우가 많으므로 각각 테스트해야 합니다.

Android 일상 연결: 백그라운드 안정성과 코어 호환성을 확인하세요

Android에서 VLESS·REALITY 또는 다른 Xray 기능이 필요하면 v2rayNG를 사용하세요. VMess·SS 등 V2Fly 호환 설정을 주로 처리한다면 v2flyNG를 선택할 수 있습니다. 기기 리소스가 제한되어 있거나 장시간 백그라운드로 실행할 때는 재연결이 적고 필드가 단순하며 코어가 기본 지원하는 조합을 우선하세요. 이론적으로 가벼운 프로토콜이라도 핸드셰이크에 계속 실패하면 배터리 이점이 없습니다.

모바일 네트워크를 자주 전환한다면 네트워크가 복구된 뒤 노드가 정상적으로 재연결되는지 관찰하세요. 특정 노드가 무선 LAN에서만 작동하거나 셀룰러 네트워크 전환 후 계속 실패한다면 주소 해석·전송 방식·서버 접속 가능 여부를 각각 확인해야 합니다. 프로토콜·보안 계층·DNS 설정을 한 번에 모두 바꾸지 말고, 매번 하나의 변수만 변경하며 로그의 오류 단계를 기록하세요.

기기가 뜨겁거나 대기 중 배터리 소모가 눈에 띄면 대량 속도 측정과 잦은 구독 업데이트를 중지하고 백그라운드 앱의 트래픽을 확인한 뒤 프로토콜을 비교하세요. TUN은 가로채는 범위를 넓혀 더 많은 앱 요청이 코어를 거치게 할 수 있습니다. 소수의 앱만 연결하면 클라이언트 기능에 따라 더 좁은 앱 범위를 선택해 불필요한 전달을 처음부터 줄일 수 있습니다.

기존 구독과 장기 설정: 안정성을 우선하고 마이그레이션은 일괄적으로 진행하세요

기존 구독에서는 VMess와 SS를 자주 볼 수 있습니다. 노드가 완전히 가져와지고 연결도 계속 안정적이라면 수동으로 VLESS로 바꾸는 것보다 그대로 사용하는 편이 더 신뢰할 수 있습니다. 프로토콜 마이그레이션은 서버·구독·클라이언트가 함께 변경되어야 하며 로컬 노드 유형만 바꿔서는 안 됩니다. 이전을 계획한다면 원래 노드를 비교용으로 보존하고 서버가 제공한 새 노드를 가져와 각각 테스트한 뒤 그룹을 조정하세요.

구독 변환 도구가 기본 필드만 출력할 수 있다면 복잡한 WebSocket·gRPC·TLS·REALITY 매개변수가 유실될 수 있습니다. 이때는 중간 변환 단계를 줄이고 대상 형식을 지원하는 클라이언트가 구독을 직접 읽도록 하세요. 노드 메모·그룹 이름·정렬은 나중에 정리할 수 있지만 연결 필드는 원본 그대로 유지해야 합니다. 구독 업데이트 실패에 대한 추가 점검은 FAQ 분류 안내를 참고하세요.

저사양 기기와 고동시성 환경

저사양 Android 기기에서는 구조가 비교적 직접적이고 코어가 성숙하게 지원하는 SS·VLESS 또는 현재 안정적인 프로토콜을 우선 테스트할 수 있지만, 서버 조건을 배제하고 하나의 정답을 정할 수는 없습니다. 전체 노드 수를 줄이고 상세 로그를 계속 기록하지 않도록 하며 대량 속도 측정과 대용량 전송을 동시에 실행하지 마세요. 연결 수에 따라 메모리 사용량이 크게 늘면 앱이 짧은 연결을 대량으로 만들고 있는지, TUN이 불필요한 백그라운드 트래픽까지 가로채는지 확인하세요.

고동시성 환경에서는 연결 재사용·서버 파일 디스크립터·버퍼·라우팅 규칙의 복잡도가 프로토콜 캡슐화보다 더 중요할 수 있습니다. WebSocket·gRPC·일반 TCP는 연결 관리 방식이 다르므로 서버 배포 환경과 함께 테스트해야 합니다. 단일 사용자의 일상적인 웹 탐색 결과를 많은 동시 연결에 그대로 적용할 수는 없습니다. 장시간 실행되는 기기에서는 순간 최고 속도보다 안정 구간·오류율·재연결 횟수를 기록하는 편이 더 유용합니다.

최종 결정표와 검증 절차

선택을 마친 뒤에는 간단한 검증 절차를 만드세요. 클라이언트와 코어 계열을 기록하고 노드의 프로토콜·전송·보안 방식을 저장한 다음 여러 번 실제 연결을 테스트합니다. 실제 애플리케이션으로 응답과 지속 전송을 확인하고, 일정한 안정 구간 동안 로그와 리소스 사용량을 관찰한 뒤 기본 노드로 지정할지 결정하세요. 문제가 생기면 가장 최근 변경부터 되돌리고 프로토콜·클라이언트·네트워크 환경을 동시에 바꾸지 마세요.

여러 노드의 성능이 비슷하다면 설정이 명확하고 구독 업데이트가 안정적이며 현재 클라이언트가 완전히 지원하는 항목을 선택하면 됩니다. 모든 플랫폼·네트워크·서버 조건에서 항상 우수한 프로토콜은 없습니다. 프로토콜 선택의 목표는 호환성 위험을 줄이고 연결 동작을 설명 가능하고 재현 가능하게 만드는 것이지, 환경과 무관한 이론 순위를 좇는 것이 아닙니다.