V2Ray 프로토콜 및 코어 가이드

프로토콜 계층과 설정 항목

프록시 프로토콜은 요청을 표현하는 방식

VMess, VLESS, Trojan, Shadowsocks가 공통으로 하는 일은 클라이언트가 서버에 대상 주소를 전달하고, 양쪽이 합의한 방식으로 인증과 데이터를 처리하도록 하는 것입니다. 이 프로토콜들이 네트워크 환경 전체를 의미하는 것은 아닙니다. 하나의 연결에는 도메인 이름 확인, 하위 전송, 보안 핸드셰이크, 라우팅 출구도 관여합니다. v2rayN에서 하나의 서버 항목에 함께 표시되는 옵션도 실제로는 서로 다른 계층에 속할 수 있습니다. 설정이 유효한지 판단할 때는 각 계층을 구분해 특정 항목 하나를 만능 설정처럼 취급하지 않는 것이 중요합니다.

VLESS는 다양한 전송 방식 및 보안 계층과 함께 사용할 수 있으므로, VLESS를 사용한다는 정보만으로는 설정을 완료할 수 없습니다. 최소한 서버 주소, 포트, 사용자 ID를 입력하고 전송 유형, 보안 유형, 해당 조합에 필요한 추가 항목도 확인해야 합니다. Trojan은 일반적으로 TLS를 통해 전송을 보호하며, Shadowsocks에서는 암호화 방식이 주요 설정 항목입니다. 구독을 가져오면 일부 항목을 자동으로 입력할 수 있지만, 설정값끼리 서로 맞아야 한다는 점은 달라지지 않습니다.

전송 방식은 데이터 전달 방법을 결정합니다

TCP, WebSocket, gRPC 등의 이름은 서로 다른 데이터 전달 방식을 가리키며, 계정 종류를 뜻하지 않습니다. WebSocket은 리버스 프록시를 거치는 구성에서 자주 사용되며, 경로와 요청 호스트가 전달 규칙에 관여할 수 있습니다. gRPC를 사용할 때는 서비스 이름 등의 매개변수를 확인해야 합니다. 일반 TCP 설정에는 같은 경로 개념이 적용되지 않습니다. WebSocket 경로를 다른 전송 방식에 복사해도 호환성이 높아지지 않으며, 설정이 완성된 것처럼 오해할 수 있습니다. 클라이언트에 편집 가능한 입력란이 있다고 해서 현재 조합에서 반드시 사용되는 것은 아닙니다.

TLS와 REALITY는 보안 설정 계층에 속하므로 VMess나 VLESS와 같은 계층의 대체 프로토콜로 볼 수 없습니다. 흔히 쓰는 “VLESS + REALITY”는 프록시 프로토콜과 보안 방식의 조합입니다. TCP는 전송 방식이고, Xray는 설정을 실행하는 코어이며, v2rayN은 설정을 관리하는 그래픽 클라이언트입니다. 이 이름들이 한 설정에 함께 등장해도 모순이 아닙니다. 선택 기준을 설명할 때는 특정 조합의 성능을 구성 요소 중 하나의 이름 탓으로 돌리기보다 전체 조합을 명확히 밝혀야 합니다.

트래픽 유입과 원격 프로토콜을 각각 확인

시스템 프록시, TUN, 안드로이드 VPN 모드는 앱 트래픽을 클라이언트로 전달하고, 원격 프로토콜은 전달받은 요청을 서버로 보냅니다. 앞단 설정이 올바르다고 해서 원격 핸드셰이크까지 성공한 것은 아니며, 원격 연결 테스트가 성공해도 모든 앱의 트래픽이 클라이언트에 들어온다고 볼 수 없습니다. v2rayN에서 시스템 프록시만 켜면 시스템 프록시 설정을 따르지 않는 앱은 계속 직접 연결할 수 있습니다. v2rayNG에서 VPN 모드를 켠 경우에도 앱별 우회와 로컬 네트워크 우회 규칙을 확인해야 합니다.

라우팅 규칙은 트래픽이 클라이언트에 들어온 뒤 도메인, 주소 또는 다른 조건에 따라 출구를 선택합니다. DNS는 대상 이름을 주소로 변환하는 방식과 라우팅에서 도메인 정보를 확인할 수 있는지에 영향을 줍니다. 서버 주소를 사용할 때 서버 자체의 이름을 확인하는 과정과 최종 대상의 이름을 확인하는 과정은 별개입니다. 전자에 문제가 생기면 연결이 시작되지 않고, 후자에 문제가 생기면 클라이언트는 실행 중인데 웹사이트가 열리지 않을 수 있습니다. 로그에서 두 상황을 따로 확인하고 모두 프로토콜 비호환으로 분류하지 마세요.

설정은 계층별로 기록하는 것이 좋습니다. 먼저 주소와 인증 정보를 적고, 다음으로 전송 방식, 마지막으로 보안 계층과 라우팅 예외를 기록하세요. 수정할 때는 한 번에 한 계층만 바꾸고 직전의 정상 설정을 보관합니다. 그러면 문제가 발생했을 때 트래픽 유입, 프로토콜 핸드셰이크, 이름 확인 중 어느 단계에서 생겼는지 파악하기 쉽습니다. 클라이언트 간 설정을 옮길 때 놓치기 쉬운 추가 항목도 줄일 수 있습니다.

프록시 프로토콜별 설계와 선택 기준

VMess와 VLESS: 인증과 암호화의 역할 차이

VMess는 Project V 생태계 초기의 주요 프록시 프로토콜로, 사용자 인증과 데이터 보호 기능을 포함하도록 설계되었습니다. 대상 주소를 전달할 뿐 아니라 일부 보안 기능도 담당하므로 사용자 ID, 암호화 옵션, 시간에 관련된 인증 조건을 설정해야 합니다. VMess를 검토할 때는 최신 구현과 과거 설정을 구분하세요. 오래된 안내서의 호환성 매개변수를 새 설정의 권장값으로 그대로 적용하면 안 됩니다. 가져온 설정에서 인증 오류가 발생하면 암호화 옵션을 무작정 바꾸기보다 사용자 ID, 클라이언트 시간, 서버 요구사항을 확인하세요.

VLESS는 프로토콜을 간결하게 설계하고 데이터 암호화는 외부 보안 계층에 맡깁니다. 여기서 ‘간결하다’는 것은 프로토콜의 역할을 설명하는 말이지, 모든 네트워크에서 지연 시간이 더 짧다는 뜻은 아닙니다. VLESS는 TLS나 REALITY와 함께 사용하는 경우가 많으며, 전체 조합의 보안성과 연결 비용을 기준으로 판단해야 합니다. 사용자 ID가 맞더라도 보안 계층 설정이 틀리면 연결할 수 없습니다. 외부 보안 계층을 끄더라도 그 설정이 동일한 수준의 보안을 제공하는 것은 아닙니다.

기존 VMess 구성이 정상적으로 유지되고 있다면 계속 사용하는 것이 적절합니다. VLESS는 Xray 기능을 활용하는 새 구성에서 흔히 사용됩니다. 둘 중 무엇을 쓸지는 클라이언트 메뉴에서 더 최신으로 보이는 이름이 아니라 서버가 제공하는 설정에 따라 결정해야 합니다. 서버에 해당 연결을 받을 설정이 없으면 클라이언트에서 프로토콜 유형만 바꿔도 전환되지 않습니다. 마이그레이션에는 서버와 클라이언트 양쪽의 변경이 필요하며, 주소와 포트만 남기는 것이 아니라 인증, 전송, 보안 항목을 다시 확인해야 합니다.

Trojan: TLS 기반 보안 연결

Trojan은 TLS로 보안 연결을 설정한 뒤 그 안에서 프록시 인증과 요청 전달을 수행하도록 설계되었습니다. 일반적으로 비밀번호, 서버 이름, 인증서 검증 관련 옵션을 설정해야 합니다. 인증과 암호화를 프로토콜 내부에 모두 묶어 둔 방식과 달리, 성숙한 TLS 기반 시설을 더 많이 활용합니다. 보안 계층의 역할이 명확하다는 장점이 있지만 인증서, 도메인, 핸드셰이크를 올바르게 설정해야 합니다. 비밀번호가 맞아도 인증서 이름이 틀리면 연결되지 않고, 인증서가 유효해도 프록시 비밀번호가 맞다는 뜻은 아닙니다.

Trojan 설정을 단순히 “비밀번호가 있는 TLS”로만 이해해서는 안 됩니다. 코어마다 전송 확장 기능과 추가 옵션 지원 범위가 다르며, 공유 링크에 배포 환경의 세부 설정이 모두 포함되지 않을 수 있습니다. v2rayN이나 v2rayNG에서 가져온 뒤에는 보안 유형, 서버 이름, 전송 방식, 비밀번호가 유지되었는지 확인하세요. 핸드셰이크 오류가 나면 먼저 TLS 계층을 살펴보고, 핸드셰이크는 성공했지만 인증에 실패한다면 비밀번호와 서버 설정을 확인하는 편이 불필요한 시도를 줄입니다.

Shadowsocks: 간결한 설정, 암호화 방식 일치가 중요

Shadowsocks는 일찍부터 간결한 암호화 프록시 방식으로 사용되었으며, 일반적인 설정에는 주소, 포트, 암호화 방식, 비밀번호가 포함됩니다. 현재 사용하려면 구체적인 암호화 방식과 구현별 지원 범위를 확인해야 합니다. 단순히 “Shadowsocks 지원”이라고 해서 모든 변형이 서로 호환되는 것은 아닙니다. 세대별로 인증 및 키 요구사항이 다를 수 있으며, 일부 방식에서는 정해진 형식의 키가 필요하므로 일반 비밀번호로 임의 대체할 수 없습니다. 클라이언트에 방식 이름을 저장할 수 있다고 해서 현재 코어가 이를 구현했다는 의미도 아닙니다.

Shadowsocks는 설정 항목이 적어 고정된 연결 지점을 직접 관리할 때 편리하지만, 간결하다고 해서 서버 정보가 필요 없는 것은 아닙니다. TCP와 UDP 지원 여부는 서버, 클라이언트, 현재 트래픽 유입 방식 모두를 확인해야 합니다. 플러그인이나 추가 캡슐화 기능도 모든 코어에서 공통으로 지원되는 기능은 아닙니다. 오래된 공유 링크에서 추가 구성 요소를 사용한다면 현재 세 클라이언트의 실제 지원 방식을 먼저 확인하세요. 불분명한 확장 항목은 삭제하고 계속 사용하기보다 설정 제공자에게 문의하는 것이 좋습니다.

프로토콜 선택은 결국 유지 관리 편의성을 기준으로 해야 합니다. 현재 서비스가 안정적인지, 클라이언트가 계속 지원하는지, 설정을 빠짐없이 옮길 수 있는지, 문제가 생겼을 때 로그를 이해할 수 있는지 확인하세요. 이름이 다르다는 이유만으로 정상 작동 중인 조합을 바꿀 필요는 없습니다. 새로운 기능이 필요하다면 프로토콜의 신구만 따지기보다 마이그레이션 비용과 서버 지원 범위를 함께 검토하는 편이 효과적입니다.

TLS, REALITY 및 인증의 경계

TLS에서는 서버 이름과 신뢰 체인을 확인하세요

TLS는 연결을 암호화하고 서버 신원을 확인합니다. 클라이언트에 입력하는 서버 주소는 도메인이나 IP 주소일 수 있지만, 보안 검증에 사용하는 서버 이름은 별도의 의미를 가집니다. 특정 주소에 연결했다고 해서 그 주소에서 제공하는 모든 인증서를 받아들여도 되는 것은 아닙니다. 인증서의 유효 기간, 이름 일치 여부, 신뢰 체인을 모두 확인해야 합니다. 시스템 시간이 크게 어긋나면 유효한 인증서도 아직 유효하지 않거나 만료된 것으로 판정될 수 있으므로, 보안 핸드셰이크 문제를 점검할 때는 먼저 시간을 동기화하세요.

서버 이름은 일반적으로 클라이언트 인터페이스의 SNI 또는 ServerName 항목에 해당하며, 연결에 사용하는 주소와 다를 수 있습니다. 연결 주소는 서버를 찾는 데 쓰이고, 서버 이름은 핸드셰이크와 검증에 관여합니다. WebSocket 요청의 Host는 또 다른 계층의 항목으로, 리버스 프록시에서 사이트를 선택하는 데 사용될 수 있습니다. 배포 설정에 따라 이 이름들이 같을 수는 있지만, 그렇다고 같은 항목은 아닙니다. 수정할 때는 배포 안내에 따라 각각 확인하세요.

TLS의 애플리케이션 계층 프로토콜 협상은 연결에서 사용할 애플리케이션 프로토콜을 결정하며, HTTP 기반 전송 설정에서 흔히 사용됩니다. 성능을 높이는 옵션처럼 임의로 선택할 수 있는 항목이 아니며, 클라이언트와 서버가 호환되는 결과로 협상해야 합니다. 사용자 지정 옵션을 켜기 전에 현재 전송 방식에 실제로 무엇이 필요한지 확인하세요. 확인 없이 서버 이름, 협상 목록, 전송 방식을 함께 바꾸면 로그에 표시된 단일 핸드셰이크 오류의 원인이 여러 가지로 늘어나 문제를 찾기 어려워집니다.

REALITY는 독립 프록시 유형이 아닌 보안 방식

REALITY는 Xray가 지원하는 전송 보안 방식으로, VLESS와 함께 사용하는 경우가 많습니다. 별도의 인증 및 핸드셰이크 조건이 있으며, 일반적으로 서버에서 받은 공개 키 정보, 허용된 서버 이름, 짧은 ID 등을 클라이언트에 설정해야 합니다. 공개 키 정보는 서버 신원과 핸드셰이크 설정에 사용되며 VLESS 사용자 ID를 대신하지 않습니다. 사용자 ID, 짧은 ID, 공개 키는 각각 역할이 다르므로 하나를 올바르게 입력해도 다른 항목이 맞지 않으면 연결되지 않습니다.

REALITY 설정의 클라이언트 지문 옵션은 핸드셰이크 특성을 구성하는 데 영향을 주지만, 인증 조건을 대체하지 않습니다. 목록에서 익숙한 이름을 선택해도 공개 키 오류나 짧은 ID 불일치를 자동으로 해결할 수는 없습니다. 지문 옵션은 현재 코어의 구현에도 좌우되므로 마이그레이션할 때 설정에 텍스트가 표시되는지만 보지 말고 실제로 인식되는지 확인해야 합니다. 일부 인터페이스는 알 수 없는 항목을 그대로 표시할 수 있지만 실행 시 지원하지 않는 값으로 오류가 날 수 있으므로 런타임 로그를 기준으로 판단하세요.

VLESS의 흐름 제어 항목도 전송 방식 및 보안 조합과 함께 확인해야 합니다. 흔히 쓰이는 Vision 옵션은 특정 구현에서 제공하는 트래픽 처리 기능이며, 모든 VLESS 연결에 필요한 것은 아닙니다. 서버에서 특정 흐름 제어 설정을 요구하면 클라이언트에서도 같은 설정을 사용해야 하며, 해당 설정이 지원되는지도 확인해야 합니다. 서버에 관련 설정이 없으면 속도를 높이려는 목적으로 임의로 추가하지 마세요. 가져온 설정에서 흐름 제어 항목이 비어 있더라도 바로 링크가 불완전하다고 단정하지 말고, 해당 배포에서 필요한지 먼저 확인하세요.

핸드셰이크 오류를 단계별로 확인

v2rayN에서 보안 연결 문제를 살펴볼 때는 먼저 서버 주소가 확인되는지 점검하고, 연결이 대상 포트에 도달하는지 확인한 다음, 보안 핸드셰이크와 프록시 인증이 각각 완료되는지 살펴보세요. 포트에 연결할 수 있다는 것은 전송 연결이 가능할 수 있다는 뜻일 뿐, 인증이 통과했다는 뜻은 아닙니다. 반대로 연결 시간 초과가 반드시 보안 계층 문제인 것도 아닙니다. 주소 확인 실패, 경로 문제, 서버 미수신 상태는 핸드셰이크 전에 발생할 수 있습니다. 막연한 “연결할 수 없음” 메시지보다 로그에 기록된 단계별 정보가 더 유용합니다.

v2rayNG에서 REALITY 설정을 옮길 때는 가져오기 도구가 서버 이름, 지문, 짧은 ID, 공개 키 정보, 흐름 제어를 보존했는지 확인하세요. 클라이언트 업데이트에 따라 인터페이스의 항목 이름이 달라질 수 있지만, 매개변수의 의미는 서버 안내와 일치해야 합니다. 기존 설정은 작동했는데 이전 후 실패한다면 네트워크 차이를 살피기 전에 해당 항목부터 비교하세요. 사용자 ID와 인증 정보가 포함될 수 있으므로 문제를 확인하기 위해 전체 공유 링크를 공개하지 마세요.

TLS와 REALITY는 최종 사용 애플리케이션 자체의 보안 대책을 대신하지 않습니다. 클라이언트와 서버 사이의 연결 보안은 웹사이트에서 사용하는 HTTPS와 서로 다른 계층이며, 그 이후의 접속 경로도 별도로 고려해야 합니다. 방식을 선택할 때는 신뢰 대상, 인증 정보 보관 방법, 갱신 절차를 함께 파악하세요. 모르는 옵션을 많이 추가하는 것보다 매개변수가 적고 설정이 명확한 조합이 장기간 관리하기 쉽습니다.

연결 속도와 리소스 사용량

첫 요청과 연속 다운로드를 구분해 측정

VMess, VLESS, Trojan, Shadowsocks의 성능은 전체 연결 경로를 빼고 비교할 수 없습니다. 웹페이지를 처음 열 때 느끼는 시간에는 DNS 조회, 연결 설정, 보안 핸드셰이크, 프록시 인증, 대상 사이트의 응답이 모두 포함됩니다. 연속 다운로드 속도는 대역폭, 혼잡, 서버 부하, 대상 리소스 제한의 영향을 더 많이 받습니다. 같은 조합이라도 첫 접속은 다소 느리지만 안정적인 전송 속도를 유지할 수 있고, 다른 조합은 핸드셰이크는 빠르지만 패킷 손실이나 속도 제한으로 장시간 연결에서 성능이 떨어질 수 있습니다.

v2rayN의 연결 테스트는 테스트 요청이 지나가는 경로만 확인하며 모든 앱의 성능을 대표하지 않습니다. 테스트 대상, 연결 재사용 여부, 캐시가 결과에 영향을 줍니다. 특정 연결 지점이 테스트 주소에 빠르게 응답해도 동영상, 소프트웨어 저장소, 업무 시스템이 더 빨라진다고 볼 수 없습니다. 비교할 때는 클라이언트, 네트워크, 대상 리소스, 트래픽 유입 방식을 동일하게 유지하고 첫 요청, 연속 접속, 대용량 파일 전송 결과를 각각 기록하세요. 여러 변수가 바뀐 결과를 프로토콜 차이로 오해하지 않도록 주의해야 합니다.

TLS 등의 보안 핸드셰이크에는 통신 왕복과 암호화 연산이 필요하므로 왕복 지연 시간이 긴 네트워크에서는 연결 설정 비용이 더 크게 느껴질 수 있습니다. 이미 연결을 수립해 앱에서 재사용하는 경우에는 요청마다 전체 비용을 다시 부담하지 않습니다. 브라우저 연결 풀, 코어의 연결 재사용, 서버의 유휴 시간 제한이 실제 결과를 좌우합니다. 비교할 때는 새 연결 상태와 기존 연결 상태를 구분해야 합니다. 그렇지 않으면 먼저 측정한 조합과 나중에 측정한 조합이 서로 다른 핸드셰이크 과정을 거쳤을 수 있습니다.

암호화·캡슐화·다중화에는 각각 비용이 있습니다

암호화 연산 비용은 프로세서, 운영체제 구현, 하드웨어 가속의 영향을 받습니다. 같은 방식도 데스크톱과 저전력 기기에서 다르게 작동할 수 있으므로 데스크톱 측정 결과만으로 모바일 배터리 사용량을 판단할 수 없습니다. VLESS가 암호화를 외부 보안 계층에 맡긴다고 해서 전체 연결에 암호화 비용이 없는 것은 아닙니다. Trojan도 TLS를 이용하므로 TLS 처리 비용을 고려해야 합니다. 평가할 때는 프록시 계층에서 처리한 데이터만 보지 말고 전체 연결을 살펴보세요.

WebSocket과 gRPC 등의 전송 방식은 각각 프레임 구조, 상태 유지, 배포 경로를 추가합니다. 캡슐화 계층이 늘면 처리 부담이 커질 수 있지만, 리버스 프록시 기반 시설, 연결 재사용, 네트워크 경로가 실제 이점을 제공할 수도 있습니다. 특정 배포 환경에서 한 전송 방식이 더 안정적이라고 해서 본질적으로 더 빠른 것은 아닙니다. 먼저 서버 배포 요구사항을 충족한 다음 추가 캡슐화가 필요한지 검토하고, 이름이 다양해 보인다는 이유로 현재 앱에 필요 없는 계층을 더하지 마세요.

다중화는 여러 논리 요청이 기존 연결을 공유하게 해 연결 수립을 반복하는 비용을 줄일 수 있지만, 하위 연결의 혼잡과 장애도 함께 영향을 받습니다. 하위 연결에서 패킷 손실이 발생하면 다른 논리 요청도 함께 대기할 수 있으며, 서버나 중간 장비의 시간 초과 정책도 다중화 효과에 영향을 줍니다. 브라우저가 이미 애플리케이션 계층에서 연결을 재사용한다면 별도의 다중화 계층을 추가해도 뚜렷한 이점이 없을 수 있습니다. 무조건 많이 켜는 대신 같은 환경에서 반복 측정한 결과를 기준으로 판단하세요.

리소스 비교는 테스트 조건을 통일하세요

v2rayN의 리소스 사용량을 비교할 때는 두 설정에서 같은 작업을 수행하고 유휴 상태, 연속 전송, 짧은 요청이 많은 상태를 각각 관찰하세요. 메모리에 상주하는 데이터에는 설정 캐시, 규칙 데이터, 런타임 관리 정보가 포함되며, 이것이 현재 연결에서 같은 규모의 네트워크 리소스를 사용한다는 뜻은 아닙니다. 그래픽 인터페이스 프로세스와 코어 프로세스도 구분해 통계를 내야 인터페이스 갱신 비용을 프로토콜 처리 비용으로 잘못 계산하지 않습니다. 로그 상세도를 지나치게 높이면 디스크와 프로세서 부담이 늘 수 있습니다.

UDP를 사용하는 앱은 별도로 검증해야 합니다. 실시간 음성 통화, 게임 및 기타 데이터그램 서비스는 지터, 패킷 손실, 지속적인 연결 가능성을 중요하게 보므로 웹페이지 테스트로 대신할 수 없습니다. 일부 조합은 UDP 전달에 특정 캡슐화 방식이나 구현이 필요하며 서버와 클라이언트 양쪽에서 지원해야 합니다. 테스트에 실패하면 지연 시간을 논하기 전에 해당 데이터 경로가 실제로 활성화되어 있는지 확인하세요. 현재 TCP 트래픽만 처리하는 연결이 된다고 해서 모든 종류의 트래픽이 올바르게 전달되는 것은 아닙니다.

성능을 조정할 때는 기준 설정을 하나 보관하고, 매번 옵션 하나만 바꿔 여러 시간대에 같은 작업을 반복하세요. 한 번의 테스트에서만 차이가 났다면 이를 근거로 장기간 설정을 바꾸지 않는 편이 좋습니다. 우연한 최고 속도보다 재현 가능한 안정성 향상이 더 유용한 판단 자료입니다. 트래픽 유입 방식과 라우팅 영향을 더 구분해 확인하려면 시스템 프록시와 라우팅 모드의 차이를 참조하세요.

안드로이드 배터리와 백그라운드 실행

VPN이 계속 켜져 있다고 계속 높은 부하가 걸리는 것은 아닙니다

v2rayNG와 v2flyNG는 안드로이드 시스템 VPN 인터페이스를 통해 앱 트래픽을 받을 수 있습니다. 시스템에 VPN 상태가 표시된다는 것은 트래픽 처리 서비스가 실행 중이라는 의미이지, 프로세서가 항상 높은 부하로 작동한다는 뜻은 아닙니다. 실제 배터리 소모에는 데이터 사용량, 연결이 깨어나는 빈도, 무선 네트워크 상태, 암호화 처리, DNS 요청, 다른 앱의 백그라운드 활동이 영향을 줍니다. 알림 아이콘이 계속 표시된다는 이유만으로 클라이언트가 배터리를 비정상적으로 많이 소모한다고 단정하면 실제 트래픽을 발생시키는 앱을 놓칠 수 있습니다.

안드로이드 배터리 사용량 통계에는 일부 네트워크 처리 비용이 VPN 클라이언트에 포함될 수 있지만, 실제 요청은 다른 앱에서 발생했을 수 있습니다. 따라서 사용 시간, 포그라운드와 백그라운드 트래픽, 같은 작업을 수행한 비교 결과를 함께 확인하고 하나의 비율만 보고 판단하지 마세요. 동영상 연속 재생, 대량 클라우드 동기화, 짧은 푸시 알림은 부하 특성이 다르며 전송량, 연결 횟수, 기기 깨우는 빈도에 각각 영향을 줍니다. 같은 프로토콜이라도 작업에 따른 배터리 차이가 프로토콜 교체로 인한 차이보다 훨씬 클 수 있습니다.

모바일 네트워크의 무선 모듈은 절전 상태에서 활성 상태로 전환될 때도 전력을 사용합니다. 짧은 연결을 자주 만들거나, 지나치게 자주 연결을 유지하거나, 실패 후 계속 재시도하면 활성 상태가 오래 지속될 수 있습니다. 설정 오류로 핸드셰이크가 반복되면 배터리 소모가 늘어나는 원인은 정상 작동 중인 프로토콜의 높은 비용이 아니라 실패가 반복되는 상황일 수 있습니다. 먼저 로그에서 시간 초과, 인증 실패, 연결 재설정이 반복되는지 확인한 뒤 설정을 간소화하거나 백그라운드 정책을 조정하세요.

배터리 절약 설정은 안정성과 함께 평가하세요

v2rayNG가 시스템의 백그라운드 실행 제한을 받으면 화면을 잠근 뒤 연결이 끊길 수 있으며, 앱이 네트워크에 다시 연결될 때 연결을 새로 설정할 수 있습니다. 배터리 제한을 해제하면 계속 실행하는 데 도움이 되지만 클라이언트가 정상적으로 작동하는 시간도 늘어나므로 단순한 배터리 절약 설정으로 볼 수는 없습니다. 먼저 사용 목적을 정하세요. 하루 종일 안정적으로 연결해야 한다면 필요한 백그라운드 실행을 허용하고, 특정 작업에만 사용하는 경우에는 작업이 끝난 뒤 연결을 끊어 불필요한 상주를 줄일 수 있습니다.

v2flyNG의 백그라운드 동작도 시스템 스케줄링과 기기 제조사의 정책에 영향을 받습니다. 코어 계열을 바꿔도 시스템 제한을 자동으로 우회하거나 배터리 소모를 줄일 수 있는 것은 아닙니다. 두 클라이언트를 비교할 때는 한 번에 하나만 실행하고 네트워크, 앱 작업, 관찰 시간을 비슷하게 맞추세요. 한 클라이언트는 VPN 서비스를 유지하고 다른 클라이언트는 시스템에 의해 종료된 상태라면 배터리 사용량을 비교할 수 없습니다. 백그라운드 실행 시간의 총소모량이 아니라 같은 작업을 수행하는 데 드는 비용을 비교해야 합니다.

VPN 모드와 프록시만 사용하는 모드는 트래픽 처리 범위가 다릅니다. 프록시 모드에서는 일반적으로 앱이 로컬 프록시를 직접 사용해야 하므로 기기 전체 트래픽이 처리된다고 볼 수 없습니다. 이 모드가 배터리를 덜 쓰는 것처럼 보이는 이유는 처리하는 트래픽이 적기 때문일 수 있습니다. 앱별 프록시와 로컬 네트워크 우회 규칙은 불필요한 전달을 줄일 수 있지만 트래픽 경로도 바꿉니다. 설정을 수정하기 전에 프록시를 거쳐야 하는 앱을 확인해 예상한 연결 방식이 손상되지 않도록 하세요.

모바일 네트워크 전환과 DNS를 별도로 확인하세요

Wi-Fi와 모바일 데이터 사이를 전환하면 주소, 경로, 시스템 네트워크 상태가 바뀌므로 기존 연결이 그대로 유지되지 않을 수 있습니다. v2rayNG가 원격 연결을 다시 설정해야 할 수 있고, 앱이 이미 유효하지 않은 연결 풀을 계속 사용할 수도 있습니다. 전환 직후 잠시 연결이 복구되지 않았다고 바로 프로토콜 문제로 판단하지 마세요. 복구되지 않는 상태가 이어진다면 클라이언트가 다시 연결할 수 있는지, DNS가 더 이상 유효하지 않은 경로를 사용하는지, 앱이 새 연결을 만든 뒤 정상 작동하는지 확인하세요.

DNS 요청이 실패 후 재시도를 반복하거나 잘못 라우팅되면 백그라운드 활동이 늘어날 수 있습니다. 원격 DNS와 직접 연결 DNS는 각각 도달 가능한 출구가 필요하며, 프록시가 아직 연결되지 않았는데 서버 주소 확인에 프록시를 요구하는 순환 구조도 피해야 합니다. FakeDNS는 도메인과 주소의 연결 방식을 바꾸지만 배터리 절약 기능은 아닙니다. 사용하기 전에 라우팅, 앱 캐시, VPN 트래픽 유입과 어떻게 연동되는지 확인하세요. 관련 내용은 FakeDNS 원리와 사용 사례를 참조하세요.

배터리 문제는 세 단계로 점검할 수 있습니다. 먼저 일반 설정으로 정해진 작업을 완료하고, 다음으로 화면이 잠긴 유휴 상태에서 이상 트래픽이 계속 발생하는지 확인한 뒤, 마지막으로 네트워크 전환을 재현하세요. 배터리 비율만 기록하기보다 각 단계의 클라이언트 상태, 작업 시간, 오류 유형을 기록하는 편이 효과적입니다. 특정 단계에서 인증 오류가 반복된다면 설정을 먼저 수정한 뒤 비교를 계속하세요. 그렇지 않으면 잘못된 설정에서 재시도하는 데 든 전력만 관찰하게 됩니다.

v2rayNG의 백그라운드 설정은 안드로이드 배터리 소모 및 백그라운드 실행 문제 해결을 참조하세요. 장기간 사용의 목표는 작업을 안정적으로 완료하면서 비정상적인 기기 깨우기를 줄이는 것입니다. 시스템 통계에서 클라이언트의 배터리 사용량을 0에 가깝게 만드는 것이 목표는 아닙니다. 프로토콜 선택도 한 요소일 뿐이며, 백그라운드 정책, 트래픽 발생 앱, 네트워크 품질도 중요합니다.

Xray와 V2Fly 코어 계열

같은 계보라고 설정이 항상 호환되는 것은 아닙니다

V2Fly는 Project V의 관련 구현과 커뮤니티 유지 관리를 이어가며, Xray는 같은 기술 생태계에서 독자적인 기능 방향으로 발전했습니다. 공통된 개념과 비슷한 설정 구조도 있지만, 기능과 항목, 동작 방식은 각 프로젝트에서 따로 관리됩니다. 코어 계열을 이해하면 프로토콜 이름과 설정 용어를 파악하는 데 도움이 됩니다. 반면 “설정 파일을 자유롭게 서로 바꿔 쓸 수 있다”고 생각하면 실제 마이그레이션 과정에서 문제가 생길 수 있습니다. 호환성은 프로젝트의 출처가 아니라 구체적인 기능과 설정 항목을 기준으로 확인해야 합니다.

REALITY 및 관련 VLESS 흐름 제어 조합을 지원하는 Xray의 기능은 코어 선택에서 자주 고려됩니다. V2Fly는 자체적인 프로토콜, 전송, 라우팅 구현 범위를 갖고 있습니다. 지원 여부는 오래된 글이나 클라이언트의 과거 화면이 아니라 현재 설치된 코어의 기능을 기준으로 판단하세요. 기능과 설정 항목은 바뀔 수 있으므로 이 페이지가 특정 시점의 기능 전체를 영구적으로 보장하지는 않습니다. 이전하기 전에 클라이언트 로그와 해당 설정 안내를 함께 확인하세요.

v2rayN은 서버 관리, 구독 해석, 시스템 프록시, 코어 실행을 담당하는 데스크톱 그래픽 클라이언트입니다. 인터페이스에 특정 설정 항목이 보인다는 것은 이를 입력할 수 있는 기능이 있다는 뜻일 뿐이며, 실제 설정은 선택한 코어가 실행합니다. 코어를 바꾸면 이전에 작동하던 항목이 지원되지 않을 수 있고 일부 서버 설정은 새 코어에 적합하지 않을 수도 있습니다. 코어 이름만 비교하지 말고 바꾸기 전에 현재 연결에 필요한 프로토콜, 보안 계층, 흐름 제어 기능을 확인하세요.

필요한 기능에 따라 안드로이드 클라이언트 선택

v2rayNG는 주로 Xray 코어 기능을 기준으로 선택하며, 관련 프로토콜 조합이 필요한 안드로이드 환경에 적합합니다. v2flyNG는 V2Fly 계열의 안드로이드 대안으로, 해당 구현 범위에 맞는 설정에 사용할 수 있습니다. 두 클라이언트의 화면과 설정 가져오기 방식이 비슷해도 같은 공유 링크를 가져온 뒤 동일하게 작동한다고 보장할 수는 없습니다. 특히 특정 보안 방식이나 확장 항목이 포함된 링크는 화면 표시를 확인하기 전에 코어 지원 여부부터 확인해야 합니다.

클라이언트 업데이트와 코어 업데이트는 서로 다른 작업입니다. 그래픽 인터페이스는 구독을 해석해 실행 설정을 만들고, 코어는 실제 통신을 담당합니다. 어느 한쪽이 오래되어도 새 설정 항목을 사용하지 못할 수 있습니다. 코어만 교체해도 오래된 인터페이스가 올바른 매개변수를 생성한다는 보장은 없고, 인터페이스만 업데이트해도 실행 파일이 필요한 기능을 지원한다는 보장은 없습니다. “설정 항목은 있지만 작동하지 않는” 문제가 생기면 설정 생성 과정과 실제로 실행된 코어를 모두 확인하세요.

설정 항목을 기준으로 마이그레이션

Xray와 V2Fly 사이에서 설정을 옮길 때는 최소한의 연결부터 시작하세요. 원격 출구 하나만 있는 기본 설정을 만들고 인증과 보안 핸드셰이크를 확인한 뒤 라우팅, DNS, 기타 옵션을 차례로 옮깁니다. 규칙이 많은 설정 전체를 한 번에 복사하면 실행에 성공하더라도 어떤 항목이 무시되었거나 기본 동작이 달라졌는지 파악하기 어렵습니다. 프로그램이 바로 종료되지 않았다는 사실은 일부 시작 검사에 통과했다는 뜻일 뿐, 모든 트래픽 경로가 예상대로 작동한다는 의미는 아닙니다.

라우팅 데이터와 코어 설정도 구분해야 합니다. 일부 규칙은 도메인 분류나 주소 분류 데이터를 참조하므로 해당 파일의 존재 여부, 분류 이름의 유효성, 로드 경로가 결과에 영향을 줍니다. 원래 클라이언트의 라우팅 설정을 복사했더라도 필요한 데이터가 없으면 로드에 실패하거나 예상과 다르게 규칙이 일치할 수 있습니다. 이런 문제는 대개 원격 프록시 프로토콜 장애와 별개이므로 시작 로그와 규칙 일치 동작을 따로 확인하세요.

사용자 지정 설정은 누가 관리하는지 명확히 해야 합니다. 그래픽 클라이언트는 다시 불러오기, 구독 업데이트, 설정 변경 후 실행 파일을 다시 생성할 수 있으므로 생성된 결과를 직접 수정해도 오래 유지되지 않을 수 있습니다. 사용자 지정 항목이 필요하면 클라이언트에서 제공하는 입력 기능을 우선 사용하고 저장 위치와 덮어쓰기 규칙을 확인하세요. 설정을 비교하려고 내보낼 때는 인증 정보가 포함될 수 있다는 점에 유의하세요. 문제를 공유하기 전 주소, 사용자 ID, 비밀번호 등 민감한 정보를 삭제해야 합니다.

코어 선택은 필요한 기능을 먼저 충족한 뒤 안정성과 유지 관리 비용을 따져야 합니다. 기존 V2Fly 설정이 정상 작동하고 추가 기능이 필요하지 않다면 호환되는 클라이언트를 계속 사용할 수 있습니다. REALITY 등의 특정 조합이 필요하다면 해당 설정을 빠짐없이 표현하고 실행할 수 있는 Xray 구성을 선택하세요. 운영체제와 칩셋에 맞는 설치 파일은 클라이언트 다운로드 페이지에서 선택하면 됩니다. 프로토콜 이름마다 별도의 클라이언트를 찾을 필요는 없습니다.

공유 링크와 구독 형식 호환성

가져오기에 성공해도 일부 정보만 읽었을 수 있습니다

구독은 설정을 배포하는 방식이지 새로운 프록시 프로토콜이 아닙니다. 구독 주소에서 공유 링크 목록이 반환될 수도 있고, 특정 구조화 형식의 설정이 반환될 수도 있습니다. 클라이언트는 먼저 형식을 인식한 다음 내부 항목으로 변환해야 합니다. 가져온 뒤 서버 이름이 표시된다는 것은 파서가 일부 내용을 읽었다는 뜻일 뿐입니다. 인증, 보안 계층, 전송 항목이 모두 보존되었는지는 편집 화면에서 확인해야 합니다. 이름 표시, 항목 수 정상, 연결 성공은 서로 다른 결과입니다.

VMess 공유 링크는 인코딩된 구조화 정보를 담는 경우가 많고, VLESS와 Trojan 링크는 주소와 쿼리 매개변수로 옵션을 표현하는 경우가 흔합니다. Shadowsocks 링크는 인증 정보의 인코딩 방식과 확장 매개변수도 확인해야 합니다. 링크 생성 도구마다 항목 이름과 인코딩 세부 사항을 다르게 처리할 수 있으므로 접두사만 보고 호환성을 판단하지 마세요. 새 항목을 오래된 파서가 오류를 내지 않고 무시할 수도 있으므로 “오류 메시지가 없음”이 완전한 호환성을 증명하지는 않습니다.

구독 응답의 Base64 인코딩은 내용을 포장하는 방식이지 보안 암호화가 아닙니다. 구독 주소를 가진 사람은 대개 서버와 인증 정보를 볼 수 있으므로 주소 자체를 민감한 자격 증명으로 관리해야 합니다. 전체 구독 링크를 공개 화면 캡처, 로그, 문의 내용에 넣지 말고, 정체를 알 수 없는 변환 서비스에 구독 응답을 제공하지 마세요. 형식을 비교해야 한다면 필요한 항목을 로컬에서 확인하고 민감 정보를 가린 복사본으로 문제를 설명하세요.

다시 가져오기보다 설정 항목을 비교하세요

v2rayN과 v2rayNG에서 같은 연결 지점을 비교할 때는 주소, 포트, 인증, 전송, 보안 계층, 서버 이름, 추가 매개변수를 차례로 확인하세요. REALITY 조합에서는 공개 키 정보, 짧은 ID, 지문, 흐름 제어도 확인해야 합니다. WebSocket은 경로와 요청 호스트를, gRPC는 서비스 이름을 확인하세요. 항목이 비어 있다면 다른 연결의 값을 복사해 채우기 전에 적법한 기본값인지 가져오기 과정에서 누락된 것인지부터 확인해야 합니다.

특수 문자가 포함되면 가져오기 결과가 달라질 수 있습니다. 비밀번호, 메모, 경로에 예약 문자가 있으면 공유 형식에 맞게 인코딩해야 합니다. 중복으로 인코딩하면 클라이언트가 원래 값이 아니라 인코딩된 문자열을 읽을 수 있습니다. 수동으로 복사할 때는 줄바꿈, 앞뒤 공백, 메신저에서 잘린 내용도 확인하세요. 같은 링크가 한 클라이언트에서는 작동하고 다른 클라이언트에서 실패한다면 구독을 반복해서 갱신하기보다 먼저 파싱된 설정 항목을 비교하세요.

구조화된 설정과 공유 링크는 같은 정보를 담는 형식이 아닙니다. 전체 설정에는 여러 출구, 라우팅 규칙, DNS, 인바운드, 정책이 포함될 수 있지만, 단일 공유 링크는 일반적으로 원격 연결 하나와 제한된 추가 정보만 표현합니다. 전체 설정을 링크 목록으로 변환하면 서버는 남아도 앱별 라우팅과 이름 확인 동작이 사라질 수 있습니다. 반대로 링크를 가져온다고 해서 기존의 전역 동작이 자동으로 복원되는 것도 아닙니다. 이전할 때는 서버 항목과 클라이언트의 전역 설정을 따로 처리해야 합니다.

짧은 설정 예시: 규칙 참조에도 의존 항목이 있습니다

다음은 Xray 또는 V2Fly 설정에서 자주 사용하는 라우팅 조각으로, 규칙이 출구 태그를 참조하는 방식을 보여 줍니다. 실행에 필요한 파일 전체가 아니므로 기존 설정에 합쳐야 하며, direct라는 이름의 직접 연결 출구가 정의되어 있어야 합니다. 규칙은 사설 주소 범위를 사용하며 추가 분류 데이터가 필요하지 않습니다. 이 규칙은 해당 주소 범위만 처리하므로 도메인별 라우팅, DNS, 모든 로컬 네트워크 검색 트래픽을 포함하지는 않습니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

이 설정은 JSON 문법 검사만으로 충분하지 않은 이유도 보여 줍니다. 괄호와 따옴표가 모두 올바르더라도 출구 태그가 없거나 그래픽 클라이언트가 다른 라우팅 구조를 생성하면 조각은 예상대로 작동하지 않습니다. 규칙의 순서도 중요합니다. 앞에서 일치한 규칙이 출구를 결정할 수 있습니다. 그래픽 클라이언트를 사용할 때는 라우팅 설정에서 원하는 동작을 표현하고, 예시를 클라이언트가 생성한 전체 설정 파일에 덮어쓰지 마세요.

구독 업데이트 후 일부 연결 항목이 사라졌다면 서비스에서 제거되었다고 판단하기 전에 응답 형식, 그룹 필터, 파싱 알림을 확인하세요. 업데이트 실패는 구독 주소 접속, 인증 응답, 콘텐츠 파싱 단계로 나눠 확인해야 합니다. 검증된 연결 하나를 기준 설정으로 보관하면 배포 형식과 연결 자체 중 어느 쪽에서 문제가 생겼는지 판단하는 데 도움이 됩니다. 일반적인 사용 방법은 도움말 센터에서 확인하세요.

사용 환경별 선택과 테스트

요구사항을 정리한 뒤 조합을 선택하세요

데스크톱에서 v2rayN을 사용할 때는 먼저 서버가 제공하는 조합과 기기의 트래픽 유입 요구사항을 확인하세요. 일반 웹 탐색에 시스템 프록시만 필요하다면 간단한 연결 경로를 유지하고, 시스템 프록시를 사용하지 않는 앱까지 처리해야 할 때 TUN을 검토할 수 있습니다. 프로토콜은 현재 사용할 수 있는 연결을 기준으로 선택하세요. 기존 VMess 배포가 정상적으로 유지된다면 계속 사용할 수 있습니다. Trojan에는 올바른 TLS 설정이 필요하고, VLESS에는 적절한 보안 계층이 필요하며, Shadowsocks에는 구체적인 암호화 방식과 키 요구사항을 확인해야 합니다. 클라이언트에 기능이 많다고 해서 모두 켤 필요는 없습니다.

모바일에서 v2rayNG를 사용할 때는 안정적인 복구와 백그라운드 비용을 함께 평가해야 합니다. REALITY 등 Xray 기능이 필요하면 관련 매개변수를 빠짐없이 가져올 수 있는 설정을 선택하세요. V2Fly 구현에 맞는 연결이 필요하다면 v2flyNG도 검토할 수 있습니다. 두 클라이언트가 같은 시스템 VPN 연결을 동시에 담당하게 해서는 안 됩니다. 비교하기 전에 다른 클라이언트의 서비스를 중지하세요. 그러지 않으면 시스템 트래픽 유입을 전환할 때 생긴 중단을 원격 프로토콜 문제로 오해할 수 있습니다.

개발 및 업무 환경에서는 브라우저, 명령줄 도구, 내부 주소, 의존성 저장소를 함께 사용하는 경우가 많습니다. 시스템 프록시가 모든 도구에 적용되는 것은 아니며 일부 프로그램은 자체 프록시 설정을 사용합니다. 이때는 원격 프로토콜을 바로 바꾸기보다 트래픽 유입 범위와 라우팅 예외를 먼저 확인하세요. 내부 주소에는 명확한 직접 연결 경로가 필요한 경우가 많고 DNS도 관련 이름을 확인할 수 있어야 합니다. 특정 도구 하나만 실패한다면 그 도구가 실제로 사용하는 프록시 설정부터 점검하세요.

한 번에 판단하지 말고 단계별로 확인하세요

1단계에서는 클라이언트와 코어가 정상적으로 실행되는지 확인합니다. 시작에 실패하면 시스템 프록시를 조정하기 전에 항목 형식, 기능 지원, 파일 의존성을 살펴보세요. 2단계에서는 원격 연결 하나를 테스트하고 주소 확인, 보안 핸드셰이크, 인증이 완료되는지 확인합니다. 3단계에서는 실제 앱의 트래픽이 클라이언트로 들어오는지 확인합니다. 4단계에서 라우팅, DNS, 특수 트래픽 유형을 검증합니다. 각 단계에서 결과를 명확히 확인해야 다음 수정이 필요한 계층을 알 수 있습니다.

연결은 성공했는데 웹사이트가 열리지 않는다면 대상 이름 확인 실패, 잘못된 출구 선택, 대상 서비스 장애를 구분해야 합니다. 테스트 주소에 연결된다는 사실은 해당 경로가 성공했다는 것만 보여 줍니다. 브라우저가 이름 확인 결과를 캐시할 수 있고 앱이 오래된 연결을 유지할 수도 있으므로 설정을 바꾼 뒤에는 요청을 새로 보내고 필요한 경우 문제가 있는 앱을 재시작하세요. 모든 설정을 한꺼번에 초기화하면 일시적으로 복구되더라도 무엇이 문제였는지 파악하기 어려워집니다.

DNS는 주소를 받았는지만 확인할 것이 아니라 요청이 예상한 경로를 지나는지도 확인해야 합니다. 직접 연결 DNS, 원격 DNS, 서버 주소 확인은 각각 용도가 다르며 라우팅 규칙이 DNS 요청 자체에 영향을 줄 수도 있습니다. 브라우저의 보안 DNS와 캐시도 검사 결과에 영향을 주므로 한 페이지에서 한 번 확인한 결과만으로 결론을 내리지 마세요. 구체적인 확인 절차는 v2rayN 및 v2rayNG DNS 경로 확인을 참조하세요. 먼저 목표를 정한 뒤 요청이 실제로 지나가는 경로를 확인해야 합니다.

기준 설정을 보관하고 필요한 기능부터 이전하세요

설정을 이전할 때는 기존에 작동하는 연결을 보관하고 새 조합을 먼저 가져와 따로 테스트한 뒤 그룹과 기본 선택을 옮기세요. 새 설정에 다른 코어가 필요하다면 다른 주요 연결이 호환되는지도 먼저 확인해야 합니다. 하나의 연결을 고치다가 전체 설정에 영향을 줄 수 있습니다. 구독 업데이트 후에도 주요 항목, 특히 보안 계층, 흐름 제어, 전송 매개변수를 확인하세요. 장기간 사용할 설정은 구분하기 어려운 복사본을 많이 저장하기보다 변경 이유를 기록하는 것이 유용합니다.

문제 해결 기록은 간단하게 작성하세요. 클라이언트, 코어 계열, 프로토콜 조합, 트래픽 유입 방식, 실패 단계, 최근 변경 사항을 적으면 됩니다. 전체 비밀번호, 사용자 ID, 구독 주소를 기록하거나 공개하지 마세요. 재현한 시점을 중심으로 로그를 확인해 무관한 출력이 실제 오류를 가리지 않도록 하세요. 설정 제공자에게 문의할 때는 “속도가 느림”이라고만 설명하기보다 “보안 핸드셰이크 실패” 또는 “가져온 뒤 흐름 제어 항목이 누락됨”처럼 구체적으로 알려야 해결에 도움이 됩니다.

선택 기준은 필요한 기능을 충족하고, 일상적인 작업을 반복해서 완료할 수 있으며, 문제가 생겼을 때 원인을 특정 계층에서 찾을 수 있는지입니다. 기기와 네트워크 조건에 관계없이 적용되는 영구적인 속도 순위는 없으며, 프로토콜 이름을 바꾸는 것만으로 모든 문제가 해결되는 것도 아닙니다. 서버와 호환되는 설정을 사용한 다음 변수를 통제해 안정성, 리소스 사용량, 배터리 소모를 비교해야 신뢰할 만한 결과를 얻을 수 있습니다. 설정을 시작하려면 입문 가이드로 돌아가고, 설치 파일은 클라이언트 다운로드 페이지에서 확인하세요. 매개변수의 의미는 이 페이지에서 항목별로 살펴볼 수 있습니다.