V2Ray 프로토콜 및 코어
기술 가이드

프로토콜 계층: 먼저 클라이언트 설정 항목부터 구분하기

클라이언트, 코어, 서버는 서로 다른 계층입니다

클라이언트를 고를 때는 어떤 이름이 더 최신인지 비교하기보다 연결을 구성하는 요소부터 구분해야 합니다. v2rayN은 서버와 구독, 실행 모드를 관리하는 그래픽 클라이언트입니다. 코어는 실제 연결을 만들고 프로토콜을 처리하며 라우팅과 DNS 규칙을 적용합니다. 서버는 클라이언트와 호환되는 접속 방식을 제공해야 합니다. 인터페이스에서 특정 프로토콜을 선택할 수 있다는 것은 해당 항목을 편집할 수 있다는 뜻일 뿐입니다. 현재 실행 중인 코어와 서버 설정, 가져오기 형식까지 모두 지원한다는 의미는 아닙니다.

연결은 로컬 진입점, 프록시 프로토콜, 전송 방식, 보안 계층, 원격 출구로 나눠 이해할 수 있습니다. 로컬 진입점은 시스템 프록시가 지정하는 로컬 프록시 포트나 가상 네트워크 인터페이스처럼 앱의 트래픽이 전달되는 경로를 정합니다. 프록시 프로토콜은 사용자 인증과 요청 형식을 담당하고, 전송 방식은 데이터를 하위 연결에 실어 보내는 방법을 정합니다. 보안 계층은 해당 전송을 보호합니다. 원격 출구는 이후 대상 서비스에 연결합니다. 어느 한 계층이라도 맞지 않으면 브라우저가 계속 대기할 수 있지만, 해결 방법은 원인에 따라 달라집니다.

프로토콜과 전송 방식은 따로 확인해야 합니다

VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜 또는 프록시 방식의 이름입니다. TCP, WebSocket, gRPC는 전송 방식을 가리키므로 두 그룹을 같은 기준으로 놓고 서로 대체할 수 있는지 판단하면 안 됩니다. VLESS는 여러 전송 방식 및 보안 설정과 조합할 수 있지만, 실제 지원 범위는 코어와 서버에 따라 다릅니다. 서버가 WebSocket을 요구하는데 클라이언트에서 프로토콜만 VLESS로 바꾸고 일반 TCP 설정을 그대로 두면 같은 연결이 되지 않습니다. 경로와 호스트 이름, 보안 계층도 함께 맞춰야 합니다.

TLS와 REALITY도 별도의 서버 주소나 구독으로 이해해서는 안 됩니다. 둘 다 연결 보안 설정에 해당합니다. 일반 TLS 연결에서는 서버 인증서와 이름이 일치하는지 확인해야 합니다. REALITY는 별도의 인증 매개변수와 핸드셰이크 방식을 사용합니다. 클라이언트 인터페이스에서 같은 드롭다운에 표시되더라도 설정 구성 방식이 비슷할 뿐, 각 항목을 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. 특히 TLS의 인증서 옵션을 REALITY에 그대로 적용하거나 REALITY의 공개 키를 사용자 ID 입력란에 넣지 마세요.

계층별로 가져오기와 속도 측정 결과 이해하기

구독을 가져오는 데 성공했다면 보통 텍스트를 파싱해 클라이언트 항목으로 만들 수 있었다는 뜻입니다. 원격 포트에 연결할 수 있는지, 인증 정보가 맞는지는 확인되지 않은 상태입니다. 포트에 연결할 수 있어도 프로토콜 핸드셰이크가 성공한다고 볼 수 없습니다. 하위 연결이 만들어진 뒤에도 이름, 경로, 사용자 ID 또는 보안 매개변수가 맞지 않으면 연결이 중단될 수 있습니다. 따라서 가져오기와 파싱, 하위 연결, 프로토콜 인증, 대상 접속 순으로 확인하세요. 한 단계의 성공 메시지만으로 전체 연결이 정상이라고 판단해서는 안 됩니다.

라우팅과 DNS도 결과에 영향을 줍니다. 특정 앱의 트래픽이 클라이언트로 전달되지 않거나 도메인이 직접 연결 경로로 지정되면, 테스트 결과가 선택한 서버를 반영하지 않을 수 있습니다. 먼저 같은 앱과 대상, 명확한 트래픽 처리 모드로 확인한 뒤 분할 라우팅 규칙을 추가하는 것이 좋습니다. 테스트할 때 한 번에 한 계층만 변경해야 결과가 프로토콜, DNS 또는 로컬 진입점 중 어디에서 비롯됐는지 알 수 있습니다. 각 항목의 간단한 설명은 용어집에서 확인해 이름이 비슷한 설정을 같은 매개변수로 착각하지 않도록 하세요.

프록시 프로토콜: 등장 배경과 설계상 고려 사항

VMess와 VLESS: 서로 다른 설계 방향

VMess는 Project V 생태계의 주요 프로토콜로, 사용자 인증과 요청 형식, 데이터 보호를 프로토콜 체계 안에 구성하도록 설계됐습니다. 오랫동안 여러 클라이언트와 구독 형식에서 지원되어 왔으며, 관련 설정이 모두 갖춰진 환경에 적합합니다. 현재 설정에서는 오래된 안내서의 과거 필드를 그대로 복사하기보다 사용 중인 구현이 지원하는 인증 및 암호화 방식을 확인해야 합니다. 오래된 공유 설정을 사용할 때는 해당 필드를 현재 코어가 여전히 처리하는지 살펴보세요. 클라이언트에서 저장에 성공해도 코어가 이전과 같은 방식으로 처리한다는 보장은 없습니다.

VLESS는 프록시 프로토콜 자체의 역할을 줄이고 전송 보호를 함께 사용하는 보안 계층이나 별도의 제어 환경에 맡기는 더 간결한 방향을 택했습니다. 설정이 간결하다고 자동으로 안전한 것도, 언제나 VMess보다 빠른 것도 아닙니다. 공용 네트워크에 배포할 때는 명확한 전송 보호 방식을 함께 구성해야 합니다. 일반적인 VLESS 설정에는 사용자 ID, 전송 방식, 보안 계층, 선택적 흐름 제어가 포함됩니다. 이 중 어느 하나라도 달라지면 서버와 호환되지 않을 수 있습니다. 프로토콜 이름만 보고 선택하지 말고 서버가 실제로 제공하는 조합을 사용하세요.

두 프로토콜 모두 클라이언트에 사용자 ID 항목이 표시될 수 있지만, 항목 이름이 비슷하다고 서로 바꿔 쓸 수 있는 것은 아닙니다. VMess 항목의 유형을 VLESS로 바꾸면 로컬에서 설정을 생성하는 방식만 바뀌며, 서버의 인증 프로토콜은 그대로입니다. 프로토콜을 전환하려면 서버에 해당 접속 방식을 설정한 뒤 새 설정을 클라이언트에 배포해야 합니다. 이미 연결이 안정적이고 명확한 기능 요구나 호환성 문제가 없다면 드롭다운 하나만 바꾸기보다 양쪽 설정을 일치시켜 유지하는 편이 합리적입니다.

Trojan과 SS: 보안 의존성과 알고리즘 조건

Trojan은 일반적으로 TLS를 통한 전송 보호와 비밀번호 기반 프록시 인증을 사용합니다. 널리 쓰이는 TLS 기능과 비교적 단순한 프록시 요청 방식을 결합하지만, 비밀번호만 입력하면 되는 것은 아닙니다. 주소, 포트, 서버 이름, 인증서 신뢰 설정, 실제 전송 방식이 모두 일치해야 합니다. 인증서 검증에 실패하면 이름과 시스템 시간, 서버 인증서 체인을 확인하세요. 검증을 끄면 오류가 달라질 수는 있지만 중요한 서버 신원 확인 절차도 비활성화되므로 일반적인 연결 방법으로 권장하지 않습니다.

SS는 Shadowsocks의 일반적인 약칭으로, 미리 공유한 키와 지정된 암호화 방식을 사용해 프록시 연결을 구성합니다. 설정 항목이 적어 보여도 알고리즘 이름은 호환성에 직접 영향을 줍니다. 알고리즘 계열마다 키 형식과 인증 방식, 구현 요구 사항이 다를 수 있으므로 비밀번호만 확인하고 방식 항목을 놓쳐서는 안 됩니다. 클라이언트와 코어도 서버에서 사용하는 구체적인 방식을 지원해야 합니다. 기존 SS 서버에 연결할 때는 막연히 “SS 지원” 여부만 볼 것이 아니라 알고리즘과 키 형식을 먼저 확인하세요.

단독 이름이 아니라 전체 조합을 선택하세요

프로토콜의 등장 배경을 이해하면 각 항목이 필요한 이유를 알 수 있지만, 실제 환경에서 검증하는 일을 대신할 수는 없습니다. 예를 들어 프로토콜 헤더가 짧으면 일부 처리 오버헤드가 줄어들 수 있습니다. 하지만 실제 접속에는 DNS 조회와 핸드셰이크, 원격 출구, 대상의 응답이 모두 포함됩니다. 사용자가 체감하는 차이는 서버 위치와 네트워크 품질에서 비롯될 수도 있습니다. 서버가 다른 상태에서 다운로드 속도를 한 번 비교한 뒤 그 결과를 VMess나 VLESS의 차이로 단정하면 필요한 통제 조건이 부족하며 다른 기기에 그대로 적용하기도 어렵습니다.

클라이언트를 선택할 때는 서버가 전체 설정을 제공하는지, 현재 코어가 해당 매개변수 조합을 지원하는지, 구독에 모든 값이 담기는지, 대상 앱에 특정 트래픽 기능이 필요한지 순서대로 확인하는 것이 좋습니다. 앞의 세 항목 중 하나라도 충족되지 않으면 이론상의 성능 이점도 얻을 수 없습니다. 흐름 제어와 보안 계층, 알고리즘을 임의로 추측해 보완하지 마세요. 설정 제공자에게 원래 매개변수를 확인한 뒤 클라이언트에서 하나씩 대조해야 합니다. 프로토콜 선택은 우선 호환성을 결정하는 일이며, 성능 최적화는 그다음입니다.

REALITY와 XTLS Vision: 보안 계층과 흐름 제어의 차이

REALITY는 VLESS와 나란히 놓이는 프록시 프로토콜이 아닙니다

REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS와 함께 사용되는 경우가 많아 공유 설정 전체를 하나의 이름처럼 부르기도 합니다. 설정할 때는 계층을 구분해야 합니다. VLESS는 프록시 요청과 인증을 담당하고 REALITY는 관련 핸드셰이크와 신원 확인을 처리하며 Vision은 별도의 흐름 제어 옵션입니다. 서로 함께 사용할 수 있지만 언제나 하나로 묶이는 동의어는 아닙니다. 클라이언트에 REALITY 옵션이 있다고 해서 아무 프로토콜이나 전송 방식과 조합할 수 있는 것도 아닙니다.

클라이언트 설정에는 서버 주소, 포트, 사용자 ID, 서버 이름, 지문, 공개 키, 짧은 ID가 자주 포함됩니다. 주소는 실제 접속 지점을 가리키고 서버 이름은 핸드셰이크 설정에 사용되므로 주소 문자열과 다를 수 있습니다. 공개 키는 해당 서버의 신원 확인에 사용되며, 짧은 ID는 서버에서 허용한 값과 일치해야 합니다. 항목 이름만 보고 내용을 추측하거나, 해석 가능한 도메인이라 해서 서버 이름 입력란에 임의로 넣지 마세요. 여러 안내서의 매개변수를 조합하지 말고 유효한 하나의 설정에서 가져와야 합니다.

PublicKey, ShortId, Fingerprint의 역할

PublicKey는 클라이언트가 사용하는 공개 검증 정보로, 서버의 해당 개인 키와 짝을 이룹니다. 사용자 ID가 아니며 임의로 바꿔도 되는 메모도 아닙니다. 클라이언트에는 연결에 필요한 공개 매개변수만 제공하면 됩니다. 서버 개인 키를 전달할 필요도, 전달해서도 안 됩니다. ShortId는 서버가 설정을 구분하는 데 사용하며 허용 값과 길이, 형식은 구현에 따라 달라집니다. 일부 설정에서는 빈 값을 허용할 수 있지만 다른 서버도 비워 둘 수 있다고 단정하지 마세요. 가져온 설정에서 이 항목이 빠져 있다면 먼저 제공자의 원본 설정을 확인하세요.

Fingerprint는 클라이언트 핸드셰이크에서 사용할 지문 동작을 선택하는 항목입니다. 기기의 운영체제를 나타내는 것도 아니며, 특이한 값일수록 좋은 것도 아닙니다. 현재 구현에서 지원하고 배포 환경에도 적합한 값을 선택해야 합니다. 원하는 옵션이 보이지 않으면 임의로 그럴듯한 이름을 입력하지 말고 실행 중인 코어와 클라이언트의 지원 여부를 먼저 확인하세요. 서버 이름은 WebSocket의 Host 필드와도 다릅니다. 특정 배포에서 두 값이 같더라도 서로 다른 계층의 항목이므로 오류를 확인할 때 각각 살펴봐야 합니다.

전송 보안 계층으로 REALITY를 선택했다면 서버 설정에 맞춰 PublicKey와 ShortId를 확인하세요. 핸드셰이크 오류를 해결하려고 신원 확인을 끄거나 이름을 임의로 입력하거나 다른 서버의 매개변수를 섞어 쓰지 마세요.

Vision은 특정 데이터 경로를 최적화합니다

XTLS Vision은 클라이언트의 흐름 제어 항목에서 보통 xtls-rprx-vision으로 표시됩니다. 특정 트래픽과 전송 조합에 맞춰 처리 경로를 최적화하며 일부 중복 처리 가능성을 줄입니다. 범용 다운로드 가속 스위치도 아니고 암호화를 간단히 해제하는 옵션도 아닙니다. 실제 효과는 트래픽 특성과 코어 구현, 보안 및 전송 방식에 따라 달라집니다. 서버 설정과 현재 구현에서 허용하는 경우에만 해당 흐름 제어를 선택해야 합니다. 모든 VLESS 항목에 일괄 적용하지 마세요.

일반적인 배포에서는 TCP 계열의 하위 전송과 해당 보안 계층을 조합하지만, Vision을 사용할 수 있는지는 실제 코어 지원과 서버 요구 사항을 기준으로 판단해야 합니다. WebSocket과 gRPC 등은 데이터 구성과 연결 관리 방식이 다릅니다. VLESS를 전달할 수 있다는 이유만으로 같은 흐름 제어를 그대로 적용할 수는 없습니다. 가져온 설정에서 흐름 제어 미지원이나 조합 오류가 발생하면 오류 필드를 먼저 삭제하기보다 원본 설정에서 조합을 확인하세요.

확인 순서와 기대할 수 있는 효과

수동으로 추가할 때는 먼저 실행 코어를 확인하고, VLESS와 올바른 전송 방식을 선택한 뒤 보안 계층과 흐름 제어를 설정하세요. 마지막으로 서버 이름과 지문, 공개 키, 짧은 ID를 입력합니다. 저장 후 항목을 다시 열어 설정값이 유지됐는지 확인하세요. 다시 열었을 때 값이 사라졌다면 편집 화면의 조합 제한, 가져오기 도구의 인식 여부, 버전별 지원 차이일 수 있습니다. 클라이언트 로그를 확인해야 하며 서버 목록에 항목이 남아 있다는 이유만으로 정상이라고 판단해서는 안 됩니다.

이 조합을 평가할 때는 먼저 핸드셰이크가 제대로 되는지, 다음으로 안정적으로 접속할 수 있는지 확인하고 장시간 연결에서의 리소스 사용량을 살펴보세요. 짧은 속도 측정 결과는 주로 서버 대역폭을 반영할 수 있어 흐름 제어의 효과를 입증하기 어렵습니다. 처음 연결할 때 잠시 대기하는 현상도 DNS나 모바일 네트워크 복구에서 비롯될 수 있습니다. 원리를 더 알아보려면 REALITY와 XTLS Vision 해설을 참고하세요. 실제 사용에서는 양쪽 설정이 일치해야 합니다. 특정 기술 이름을 적용하려고 명확히 정해진 서버 설정을 바꾸지 마세요.

V2Fly와 Xray: 프로젝트 관계와 설정 호환성

공통된 배경이 있어도 지원 기능이 항상 같은 것은 아닙니다

Project V는 프록시 기능을 모듈형으로 구성하는 생태계의 기반을 제공했습니다. V2Fly는 V2Ray 관련 구현을 계속 관리하고 있으며 Xray는 관련 코드와 설정 관례를 바탕으로 독자적인 발전을 이어가고 있습니다. 인바운드와 아웃바운드, 라우팅, DNS 모듈처럼 공유하는 개념과 설정 관례가 있어 비슷해 보이는 필드가 많습니다. 하지만 두 프로젝트는 각각 발전하고 있으므로 지원하는 프로토콜 확장과 전송 세부 사항, 기본 동작, 설정 검사 방식이 다를 수 있습니다. 프로젝트 관계가 모든 설정의 영구적인 양방향 호환을 보장하지는 않습니다.

일반 사용자에게 코어 차이는 특정 매개변수 조합을 실제로 실행할 수 있는지에 가장 직접적인 영향을 줍니다. REALITY와 XTLS Vision은 Xray를 선택할 때 중요한 기능입니다. 특정 구현을 대상으로 작성된 설정도 해당 코어를 우선 사용하는 것이 좋습니다. V2Fly는 지원 범위에 맞는 기존 배포에 적합합니다. 프로젝트 이름만으로 어느 쪽이 보편적으로 더 낫다고 판단할 수는 없습니다. 어떤 기능을 서버에서 제공하는지, 클라이언트가 설정 전체를 생성할 수 있는지가 어느 코어가 더 “앞선지” 따지는 것보다 중요합니다.

클라이언트별 코어 지원 방식

데스크톱에서는 Windows, macOS, Linux를 지원하고 서버 항목과 구독 그룹, 라우팅 설정을 한곳에서 관리하기 쉬운 v2rayN을 우선 고려하세요. 전환 가능한 코어 범위는 설치 환경과 클라이언트의 현재 지원 상태에 따라 달라집니다. Android에서는 보통 Xray를 사용하는 v2rayNG를 우선 선택하며, V2Fly와 함께 배포해야 한다면 v2flyNG를 고려할 수 있습니다. 클라이언트를 고를 때는 플랫폼과 서버 요구 사항을 먼저 확인한 다음 구독 형식을 살펴보세요. 인터페이스가 비슷해도 두 모바일 클라이언트의 기능이 완전히 같다고 가정하면 안 됩니다.

그래픽 클라이언트는 서버 항목을 코어가 읽을 수 있는 설정으로 변환합니다. 이 과정에서 기본값을 추가하거나 구조를 재정렬하고 지원하지 않는 필드를 제외할 수 있습니다. 따라서 서버 편집 창은 코어 설정을 그대로 보여 주는 화면이 아닙니다. 옵션을 저장했는데도 실행되지 않는다면 시작 로그에서 클라이언트가 어떤 코어를 호출했는지, 생성된 설정이 받아들여졌는지, 오류가 시작 단계와 연결 단계 중 어디에서 발생했는지 확인하세요. 코어 단계의 오류 해결과 구독 단계의 오류 해결은 서로 다른 문제입니다.

이름만 바꾸지 말고 항목별로 확인하세요

설정 호환성은 문법과 필드, 동작의 세 계층으로 나눠 확인해야 합니다. 문법 호환성은 파일을 파싱할 수 있다는 뜻입니다. 필드 호환성은 해당 모듈이 설정 옵션을 인식한다는 뜻입니다. 동작 호환성이 있어야 설정이 예상대로 실제 작동합니다. 예를 들어 같은 라우팅 설정도 기본 DNS 처리 정책의 영향을 받을 수 있고, 같은 출구 식별자라도 규칙에서 올바르게 참조해야 합니다. 코어가 시작되는 것은 필수 조건이지만 모든 라우팅과 DNS, 전송 조합이 검증됐다는 뜻은 아닙니다.

마이그레이션 전에 기존 클라이언트에서 내보낸 설정을 보관하고 필요한 화면을 캡처하세요. 구독 주소와 비밀번호, 사용자 정보는 캡처에서 가려야 합니다. 우선 서버 항목 하나만 옮기고 복잡한 규칙을 추가로 끈 상태에서 명확한 로컬 프록시 진입점으로 테스트하세요. 그런 다음 도메인 규칙과 DNS 정책, TUN 처리를 하나씩 복원합니다. 코어와 프로토콜, DNS, 실행 모드를 한꺼번에 바꾸면 문제가 발생했을 때 원인을 찾기 어렵고 로컬 라우팅 문제를 코어 비호환으로 오해할 수도 있습니다.

코어를 업데이트할 때는 이전 버전으로 되돌릴 방법도 마련해 두세요. 새 구현은 지원 기능을 추가할 수도 있지만 이전에 무시하던 필드를 엄격하게 검사할 수도 있습니다. 이전 설정에서 오류가 나면 서버가 고장 났다고 바로 판단하지 말고 해당 필드의 오류 설명부터 확인하세요. 반대로 오랫동안 업데이트하지 않으면 새 구독 매개변수를 인식하지 못할 수 있습니다. 설치 경로와 플랫폼 아키텍처는 클라이언트 다운로드 센터에서, 세 클라이언트의 용도는 선택 가이드에서 확인하세요. 이 페이지에서는 기능 지원 범위를 다루며, 특정 업데이트가 모든 환경에서 성능을 높인다고 보장하지 않습니다.

연결 속도와 리소스: 의미 있는 비교 방법

첫 응답 대기 시간, 처리량, 연결 안정성 구분하기

연결 속도는 적어도 세 가지 지표로 나눠 봐야 합니다. 첫째는 요청을 보내고 응답을 받을 때까지의 시간으로, DNS와 하위 연결, 핸드셰이크 왕복에 영향을 받기 쉽습니다. 둘째는 지속 전송 처리량으로, 회선 용량과 혼잡, 서버 부하, 출구 제한의 영향을 더 크게 받습니다. 셋째는 연결이 계속 유지되는지, 끊긴 뒤 얼마나 빨리 복구되는지입니다. 처음 응답은 빠르지만 다운로드가 평범한 조합도 있고 장시간 연결은 안정적이지만 첫 접속이 조금 느린 조합도 있습니다. 속도 측정 숫자 하나로 모든 특성을 설명할 수는 없습니다.

프로토콜 오버헤드는 존재하지만 전체 연결 경로를 함께 살펴야 영향을 판단할 수 있습니다. 사용자와 서버 사이의 경로, 서버와 대상 사이의 경로, 대상 서비스 자체가 모두 병목이 될 수 있습니다. 서버가 다른 결과를 비교하면 프로토콜 차이만 분리할 수 없고, 테스트 시간대가 다르면 부하 변화가 섞일 수 있습니다. 전송 조합의 영향을 확인하려면 가능한 한 기기와 진입 위치, 대상 파일, 테스트 도구, 트래픽 처리 방식을 고정하고 여러 번 번갈아 테스트하세요. 일시적인 한 번의 변화를 지속적인 차이라고 단정하지 마세요.

핸드셰이크 단계와 연결 재사용에는 각각 비용이 있습니다

TCP와 TLS, 애플리케이션 계층 전송 방식에 따라 연결을 설정하는 과정이 달라질 수 있습니다. WebSocket과 gRPC는 각각의 프로토콜 캡슐화가 필요하며 배포 유연성과 연결 관리 방식도 다릅니다. 캡슐화가 추가되면 일반적으로 처리 과정도 늘어나지만 실제 병목인지는 서버 구성과 연결 재사용, 트래픽 특성에 따라 달라집니다. 프로토콜 이름이 많다는 이유만으로 특정 조합이 반드시 느리다고 판단할 수 없습니다. 같은 포트를 사용한다고 해서 연결 조합별 핸드셰이크 비용이 같아지는 것도 아닙니다.

연결 재사용은 적합한 환경에서 반복적인 연결 설정을 줄일 수 있지만, 여러 요청이 하위 연결을 공유하는 방식도 달라집니다. 공유 연결에서 혼잡이나 문제가 생기면 여러 요청이 함께 영향을 받을 수 있습니다. 일부 앱은 이미 자체적으로 장시간 연결을 유지하므로 연결 재사용을 추가해도 효과가 크지 않을 수 있습니다. 사용하는 코어와 프로토콜, 트래픽 요구 사항을 고려해 조정하세요. 모든 서버에 적용하는 기본 속도 향상 옵션으로 취급하면 안 됩니다. 변경 후에는 짧은 요청의 응답과 지속 연결의 상태를 함께 살펴보세요.

CPU와 메모리는 실제 작업량을 고려해 비교해야 합니다

암호화 알고리즘과 하드웨어 명령어 지원, 프로토콜 캡슐화, 데이터 복사 등이 CPU 사용량에 영향을 줍니다. 구형 프로세서는 높은 처리량에서 먼저 연산 한계에 도달할 수 있고, 최신 기기는 네트워크가 주된 병목일 수 있습니다. 같은 프로토콜을 사용해도 두 기기의 결과가 다른 이유입니다. 확인할 때는 클라이언트와 코어 프로세스의 지속적인 사용량을 기록하고 코어 하나가 포화 상태에 가까운지 살펴보세요. 시스템 전체 사용량이 낮다는 이유만으로 연산 병목을 배제해서는 안 됩니다. 짧은 순간의 최고 사용량이 장기적인 부담을 뜻하는 것도 아닙니다.

메모리 사용량은 동시 연결 수와 버퍼, 라우팅 데이터, DNS 캐시, 로그의 영향을 받습니다. 클라이언트 그래픽 인터페이스와 코어의 메모리 사용량은 따로 확인해야 하며 TUN 같은 트래픽 처리 구성 요소도 별도의 부하를 더할 수 있습니다. 전체 데스크톱 클라이언트와 단독 백그라운드 코어를 비교하면 기능 범위가 같지 않습니다. 리소스가 부족한 기기라면 불필요한 동시 속도 측정과 상세 로그를 줄인 뒤 일반 작업 중 기준 사용량을 확인하세요. 테스트 자체의 사용량을 평상시 소모로 오해하지 않도록 해야 합니다.

재현 가능한 테스트 기록 남기기

테스트 기록에는 실행 모드와 코어, 전체 프로토콜 조합, 네트워크 유형, 대상 작업을 적어 두세요. 먼저 같은 서버에서 반복 테스트한 뒤 옵션을 하나만 변경합니다. 옵션 변경에 서버 측 설정도 필요하다면 양쪽 설정이 실제로 일치하는지 확인하세요. 연결 실패 후 자동 재시도와 백그라운드 구독 업데이트, 반복 속도 측정이 평상시 접속 데이터에 섞이지 않도록 합니다. 결과는 현재 테스트 조건에만 해당하며, 특정 프로토콜이 모든 지역과 기기, 앱에서 항상 더 낫다는 순위로 일반화할 수 없습니다.

대부분의 사용자에게는 이론상 처리 단계를 몇 개 줄이는 것보다 연결 안정성과 관리하기 쉬운 설정, 명확한 매개변수 출처가 중요합니다. 필요한 작업이 잘 된다면 전송 조합을 자주 변경할 이유는 없습니다. 병목이 회선이나 대상 서비스가 아닌 로컬 연산과 핸드셰이크, 연결 관리에 있다고 확인된 뒤에 프로토콜 관련 옵션을 조정해야 효과를 기대할 수 있습니다. 기능이 정상적으로 작동한 다음 성능을 최적화해야 재현하기 어려운 차이를 좇다가 새로운 문제를 만드는 일을 줄일 수 있습니다.

모바일 배터리: 프로토콜 외에 지속적으로 발생하는 부하

배터리 소모는 전체 연결 경로에서 발생합니다

모바일 배터리 소모를 프로토콜 이름만으로 판단할 수는 없습니다. CPU 암호화와 가상 네트워크 인터페이스, 데이터 전달, 무선 네트워크 활동, 앱의 백그라운드 요청이 모두 리소스를 사용합니다. 프록시를 통해 대량의 데이터를 주고받지 않더라도 잦은 연결 유지 신호와 재연결, 백그라운드 속도 측정 때문에 기기가 깊은 절전 상태에 들어가지 못할 수 있습니다. 설정의 전력 효율을 평가할 때는 실제 전송량과 연결 재설정 빈도, 화면이 꺼진 뒤의 백그라운드 동작을 함께 살펴보세요. 클라이언트의 배터리 화면에 표시되는 백분율 하나만 비교해서는 안 됩니다.

무선 네트워크의 동작 상태도 중요합니다. 모바일 데이터와 Wi-Fi는 연결 유지 및 절전 방식이 다르며, 전송량이 적어도 요청이 자주 발생하면 기기가 계속 깨어날 수 있습니다. 일부 장시간 연결은 기기나 라우터, 네트워크 중간 장비에서 연결을 유지하기 위해 정기적으로 신호를 보냅니다. 유지 간격을 짧게 하면 특정 환경에서 연결 상태가 나아질 수 있지만 활동 빈도가 높아집니다. 반대로 간격을 늘리면 연결이 끊기기 쉬워질 수 있으므로 앱의 요구 사항에 맞춰 조정해야 합니다.

전체 기기 적용과 앱별 적용의 차이

Android 클라이언트는 시스템 VPN 인터페이스를 통해 로컬 트래픽을 처리할 수 있어 일반 프록시 설정을 따르지 않는 앱에도 적용할 수 있습니다. 적용 범위가 넓어지면 더 많은 백그라운드 작업이 같은 데이터 경로를 사용할 수 있습니다. 원래 로컬 네트워크에서만 통신하던 앱이 잘못된 라우팅으로 외부 주소에 계속 재시도할 수도 있고, 동기화 앱의 요청이 실패하면서 연결을 반복해서 만들 수도 있습니다. 이런 활동은 사용량 통계에서 클라이언트와 관련된 것으로 표시될 수 있지만, 실제 원인이 암호화나 프록시 프로토콜이 아닐 수도 있습니다.

클라이언트가 앱별 적용이나 제외를 지원한다면 실제 요구 사항에 맞춰 범위를 줄일 수 있습니다. 단, 어떤 앱이 프록시를 우회하는지 명확히 파악해야 합니다. 분할 라우팅 규칙은 DNS 처리 방식과도 일치해야 합니다. 앱의 트래픽은 직접 연결로 보내더라도 이름 조회가 다른 경로를 거치면 대기나 중복 요청이 발생할 수 있습니다. 로컬 네트워크 검색과 인쇄, 가정용 기기 제어에 의존하는 앱은 규칙을 넓게 바꿔 가며 시도하기보다 해당 앱의 동작을 따로 확인하세요. 불필요한 요청을 줄이는 편이 프로토콜을 바꾸는 것보다 효과적일 때가 많습니다.

백그라운드 제한과 지속 연결의 균형

시스템의 배터리 최적화 기능이 백그라운드 프로세스를 제한하면 클라이언트가 중지된 뒤 앱 요청이 시간 초과되거나 자주 재연결될 수 있습니다. 지속 연결을 위해 백그라운드 제한을 완화해야 할 수도 있지만, 배터리 소모가 자동으로 줄어드는 것은 아닙니다. 먼저 프로세스 일시 중지나 시스템 정리, 네트워크 전환으로 인한 기존 연결 무효화 중 무엇이 문제인지 확인하세요. 연결이 끊긴다는 이유만으로 모든 절전 제한을 해제하면 백그라운드 실행 범위만 넓어지고 실제 핸드셰이크나 DNS 오류는 해결되지 않을 수 있습니다.

v2rayNG는 보통 Android에서 Xray 설정을 사용할 때 우선 고려하며, v2flyNG는 V2Fly와 함께 사용하는 환경에 적합합니다. 인터페이스와 구현 차이에 따라 사용 가능한 기능은 달라질 수 있지만 특정 배터리 사용 시간 순위를 보장할 수는 없습니다. 비교하려면 같은 기기와 네트워크, 비슷한 신호 상태, 동일한 앱 작업과 트래픽 적용 범위를 유지하세요. 화면 밝기와 다른 백그라운드 앱도 최대한 같게 맞춰야 합니다. 이 요인으로 인한 배터리 변화가 프록시 경로 차이보다 클 수 있습니다.

지속적인 속도 측정과 상세 로그, 끊어진 연결의 재시도, 불필요한 앱 적용을 먼저 줄인 뒤 프로토콜을 비교하세요. 설명 가능한 백그라운드 동작이 배터리 잔량 수치 한 번보다 문제 진단에 더 유용합니다.

조건을 나눠 관찰해 이상 원인 찾기

먼저 클라이언트를 종료한 상태의 대기 전력을 확인하고, 다음으로 클라이언트를 켜되 직접 데이터를 전송하지 않는 상태를 살펴보세요. 마지막으로 같은 탐색이나 다운로드 작업을 수행합니다. 각 단계에서 네트워크가 전환됐는지, 연결이 다시 설정됐는지, 오류가 계속 발생하는지 기록하세요. 배터리 통계에는 반영 지연이 있고 시스템의 사용량 산정 방식에도 영향을 받으므로 아주 짧은 시간만 보고 결론을 내려서는 안 됩니다. 기기가 뜨거워지면 성능이 낮아져 속도가 느려질 수 있습니다. 프로토콜이 느려진 것처럼 보여도 실제로는 발열과 부하가 함께 작용했을 수 있습니다.

백그라운드 로그에 시간 초과가 계속 나타나면 설정값과 DNS, 라우팅부터 바로잡으세요. 네트워크를 바꾼 뒤에만 연결이 끊기면 클라이언트가 연결을 다시 만들고 주소를 재조회하는지 살펴보세요. 특정 앱에서만 문제가 발생하면 해당 앱의 접속 동작을 좁혀 확인하세요. 가상 네트워크 인터페이스의 적용 범위를 이해하려면 TUN 모드 원리와 설정 방법을 참고할 수 있습니다. 다만 모바일의 권한과 백그라운드 정책은 기기 시스템과 클라이언트 화면의 안내를 따르세요. 프로토콜은 안정적인 작업을 위해 선택해야 하며, 시스템 차원의 배터리 진단을 대신하지 않습니다.

구독 및 설정: 형식 호환성이 모든 매개변수를 보장하지는 않습니다

구독은 설정을 배포하는 방식이지 연결 프로토콜이 아닙니다

구독 주소는 서버 항목을 가져오는 데 사용됩니다. 내용은 공유 링크 모음이나 인코딩된 텍스트, 클라이언트 전용 구조화 설정일 수 있습니다. 구독을 가져오는 과정과 프록시 서버에 연결하는 과정은 별개입니다. 구독 업데이트 실패가 기존 서버의 연결 불가를 뜻하지는 않으며, 기존 서버에 연결할 수 있어도 구독 주소가 여전히 유효하다는 보장은 없습니다. 오류를 해결할 때는 가져오기 실패와 콘텐츠 파싱 실패, 필드 변환 실패, 연결 실패를 구분하세요. 모든 문제를 구독 자체의 오류로 뭉뚱그리지 않는 것이 좋습니다.

공유 링크는 매개변수를 주소 부분이나 쿼리 필드, 인코딩된 구조 등 서로 다른 위치에 넣습니다. 프로토콜마다 사용자 ID와 비밀번호, 알고리즘, 전송 필드가 다르므로 모든 값이 통일된 방식으로 변환되는 것은 아닙니다. 같은 공유 형식을 지원하는 두 클라이언트라도 확장 필드와 기본값, 이름 인코딩을 다르게 처리할 수 있습니다. 단순한 설정은 서로 호환되기 쉽지만 REALITY나 흐름 제어, 최신 전송 옵션을 포함하면 가져오기 도구가 중요한 필드를 모두 유지하는지 추가 확인해야 합니다.

가져온 뒤 항목을 다시 열어 확인하기

최소 확인 목록에는 주소와 포트, 프로토콜, 인증 정보, 전송 방식, 보안 계층이 포함됩니다. WebSocket은 경로와 관련 호스트 설정을, gRPC는 서비스 이름과 배포 요구 사항을 추가로 확인하세요. REALITY는 서버 이름과 지문, 공개 키, 짧은 ID, 흐름 제어를 점검해야 합니다. 별칭은 로컬에서 항목을 구분하기 위한 이름일 뿐, 이름이 같다고 설정도 같지는 않습니다. 구독을 업데이트한 뒤에는 선택한 항목이 그대로 있는지, 클라이언트가 같은 이름의 다른 항목으로 전환하지 않았는지도 확인하세요.

구독 제공자가 매개변수를 변경하거나 서버를 교체할 수 있으므로 구독 항목을 직접 수정하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 테스트가 필요하다면 먼저 항목을 로컬 설정으로 복사하고 용도를 적어 원래 그룹에 추적할 수 없는 변경이 섞이지 않도록 하세요. 테스트에 성공한 뒤에도 설정값이 서버 요구 사항에서 나온 것인지, 특정 라우팅 구간을 우연히 우회한 것인지 확인해야 합니다. 그룹 관리는 출처와 업데이트 범위를 명확히 하기 위한 기능이지 모든 링크를 긴 목록 하나로 합치는 기능이 아닙니다.

클라이언트가 생성하는 코어 설정 이해하기

아래 예시는 인바운드와 아웃바운드 관계를 로컬에서 파악하기 위한 최소 설정입니다. 루프백 주소에서 SOCKS 포트를 수신하고 들어온 요청을 시스템 네트워크로 직접 전달합니다. 이 구조는 두 유형의 코어에서 공통적으로 사용하는 모듈을 포함하지만, 실행 환경에서 해당 기능을 지원해야 하고 포트도 사용 중이 아니어야 합니다. 원격 프록시는 포함하지 않으므로 구독 설정을 대신하는 용도로 사용하면 안 됩니다. 그래픽 클라이언트로 연결을 관리한다면 이 페이지를 읽기 위해 코어를 따로 실행할 필요도 없습니다.

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "auth": "noauth", "udp": false }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

이 예시에서 인바운드 식별자는 로컬 접속 항목을 구분하고, 수신 주소는 연결할 수 있는 범위를 제한하며, 포트는 앱이 진입점을 찾도록 합니다. 아웃바운드는 데이터가 코어를 빠져나가는 방식을 정합니다. 실제 클라이언트 설정에는 프록시 아웃바운드와 라우팅, DNS 등이 추가됩니다. 다른 기기에서 연결할 수 있도록 수신 주소를 모든 인터페이스로 임의 변경하지 마세요. 노출 범위가 달라지므로 인증과 방화벽, 사용 범위를 별도로 고려해야 합니다. 설정 구조를 이해하는 목적은 데이터 경로를 파악하는 것이지 진입 권한을 확대하는 것이 아닙니다.

안전한 설정 공유와 파싱 오류 해결

구독 주소 자체에 접속 권한 정보가 포함될 수 있으며 내보낸 설정에도 비밀번호와 사용자 ID, 기타 연결 정보가 들어갈 수 있습니다. 도움을 요청할 때는 프로토콜 유형과 전송 방식, 코어 이름, 민감 정보를 가린 오류 요약만 남기세요. 구독 전체를 공개하거나 정체가 불분명한 온라인 변환 도구에 설정 전체를 붙여넣지 마세요. 공개 검증 정보인 필드가 있더라도 같은 항목의 다른 값은 민감할 수 있으므로 공유 전에 하나씩 확인해야 합니다.

구독 업데이트에 실패했다면 먼저 주소가 유효한지와 시스템 시간이 정확한지 확인하고, 가져오기 과정에서 연결 오류나 인증서 오류가 발생했는지 살펴보세요. 응답 내용이 구독 데이터가 아니라 안내 페이지인지도 확인해야 합니다. 업데이트는 성공했지만 필드가 빠졌다면 형식과 가져오기 도구의 호환성을 점검하세요. 설정 모듈에 대한 자세한 설명은 JSON 설정 구조 해설을 참고할 수 있습니다. 처음 가져올 때는 설정 가이드의 절차를 따르세요. 기본 연결을 확인하기도 전에 복잡한 사용자 설정을 동시에 추가하지 마세요.

사용 환경별 선택과 오류 해결: 설정 확인부터 안정적인 연결까지

플랫폼과 서버 지원 범위부터 선택지를 좁히세요

데스크톱에서는 v2rayN을 우선 고려하고 Windows, macOS, Linux에 맞는 설치 경로와 아키텍처를 선택하세요. Android에서 Xray 설정을 사용할 때는 v2rayNG를 우선 고려하고, V2Fly 배포와 함께 사용한다면 v2flyNG를 검토하세요. 다음으로 서버에서 제공하는 프로토콜과 보안 계층, 전송 조합을 확인해야 합니다. 클라이언트 선택은 이론상 가장 강력한 프로토콜을 빈 목록에서 고르는 일이 아닙니다. 지원되는 플랫폼과 코어, 완전한 구독 설정, 서버 호환성의 교집합에서 선택하는 과정입니다.

VMess 또는 Trojan 서버가 안정적으로 작동하고 있다면 직접 VLESS로 바꾸기보다 기존 설정을 올바르게 유지하는 편이 대체로 낫습니다. 서버가 VLESS와 REALITY, Vision 설정을 명확하게 제공한다면 해당 매개변수 조합을 모두 지원하는 코어와 클라이언트를 선택하세요. SS 설정만 있다면 비슷한 이름의 프로토콜을 선택하지 말고 알고리즘과 키 요구 사항을 확인해야 합니다. 프로토콜을 전환하려면 서버에 새 진입점과 전체 설정을 마련해야 합니다. 로컬 인터페이스에서 유형만 바꿔서는 전환할 수 없습니다.

작업에 맞춰 트래픽 처리 방식 선택하기

브라우저와 시스템 프록시를 따르는 앱은 먼저 시스템 프록시를 사용해 기본 접속을 확인할 수 있습니다. 다른 앱까지 처리해야 한다면 TUN을 검토하세요. TUN은 로컬 트래픽 적용 범위를 바꾸지만 원격 서버의 인증이나 보안 계층 오류를 자동으로 해결하지는 않습니다. 사용하기 전에 일반 프록시 진입점에서 서버에 연결할 수 있는지 먼저 확인하고 권한과 가상 네트워크 인터페이스, 라우팅, DNS를 설정하세요. 이렇게 하면 전체 기기의 접속에 문제가 생기더라도 원인이 원격 설정이 아니라 로컬 트래픽 처리 계층에 있음을 파악하기 쉽습니다.

개발 작업과 로컬 네트워크 협업에서는 로컬 서비스와 내부 도메인, 사설 주소의 트래픽을 어떤 경로로 보낼지도 확인해야 합니다. 규칙 순서에 따라 어느 출구가 먼저 선택될 수 있고 DNS 정책은 도메인 또는 주소 기반 판단에 영향을 줍니다. 범위가 넓은 규칙 하나를 추가한 뒤 테스트를 끝내지 마세요. 공용 네트워크 접속과 내부 서비스, 이름 조회를 각각 확인해야 합니다. 필드 관계는 DNS 분할 라우팅 해설에서 더 알아볼 수 있습니다. 설정을 변경할 때마다 테스트 결과를 명확히 기록하세요.

반복 재설치 대신 오류 단계별로 확인하기

코어가 시작되지 않는다면 먼저 설정 문법과 알 수 없는 필드, 지원 기능 누락, 로컬 포트 사용 여부를 확인하세요. 이 단계에서는 원격 서버가 작동하는지가 우선 사항이 아닙니다. 하위 연결이 시간 초과되면 주소와 포트, 현재 네트워크를 먼저 확인하세요. 연결이 거부되면 대상 서버의 수신 상태와 접속 조건을 점검해야 합니다. 핸드셰이크 실패 단계에서 사용자 정보와 보안 계층, 서버 이름, 관련 매개변수를 확인하세요. 오류가 발생한 단계는 범위를 좁히는 데 도움이 되지만 로그 한 줄만 보고 원인을 하나로 단정하지 말고 전후 상황도 함께 살펴봐야 합니다.

특정 웹사이트나 앱에서만 문제가 발생한다면 먼저 해당 트래픽이 클라이언트로 전달되는지, 어떤 규칙을 거쳐 어느 출구로 가는지 확인하세요. 잘못된 DNS 조회와 대상 서비스 제한, 앱 자체의 프록시 동작도 일부 접속 오류를 일으킬 수 있습니다. 이때 프로토콜을 바꿔도 문제가 해결되지 않을 수 있으며 기존 비교 조건만 사라질 수 있습니다. 사용자 규칙을 임시로 끄고 테스트하기 전에 원래 설정을 보관하세요. 기본 경로가 정상임을 확인한 뒤 규칙을 하나씩 복원해 실제로 접속에 영향을 주는 항목을 찾으세요.

권장 확인 순서: 설정 로드 → 원격 연결 → 핸드셰이크 및 인증 → 대상 접속 → 분할 라우팅 확인 → 속도와 배터리 최적화

관리하기 쉬운 최종 설정 유지하기

검증이 끝나면 클라이언트와 실행 코어, 서버 출처, 프로토콜 조합, 필요한 로컬 규칙을 기록하되 공개해서는 안 되는 인증 정보는 남기지 마세요. 정상 작동을 확인한 기준 설정을 하나 보관하고 이후 업데이트나 조정은 한 번에 한 요소만 변경하세요. 문제가 생기면 이 기준 설정과 비교해 원인을 찾을 수 있습니다. 클라이언트 재설치와 코어 전환, 프로토콜 변경, 라우팅 초기화를 한 번에 진행하지 마세요. 되돌릴 수 있고 이유를 설명할 수 있는 설정이 매개변수가 많은 설정보다 장기적으로 관리하기 쉽습니다.

처음 사용하는 경우 빠른 설정 가이드를 따라 가져오기와 연결 확인을 진행하거나 V2Ray 초보자 질문 10가지에서 흔한 연결 문제를 살펴보세요. 플랫폼에 맞는 설치 파일은 다운로드 센터에서 받을 수 있습니다. 구독 항목에서 클라이언트 설치 파일을 찾지 마세요. 이 가이드의 선택 원칙은 플랫폼과 코어, 프로토콜, 전송 방식, 보안 계층, 매개변수 출처를 서로 일치시킨 뒤 실제 작업으로 안정성을 확인하는 것입니다. 이름만 보고 연결 품질을 판단하지 마세요.