V2Ray 프로토콜과 코어 선택

01 / 프로토콜·전송·보안 계층

하나의 설정 이름에 세 가지 계층이 들어갈 수 있습니다

클라이언트 목록의 ‘VLESS + TCP + REALITY’는 서로 바꿔 쓸 수 있는 프로토콜 세 가지를 뜻하지 않습니다. VLESS는 프록시 요청에 필요한 인증 정보와 대상 정보를 처리하고, TCP는 연결의 기반이 되는 전송 방식과 관련 설정을 담당하며, REALITY는 보안 핸드셰이크를 제공합니다. VMess도 여러 전송 방식과 함께 사용할 수 있고 Trojan은 일반적으로 TLS를 사용합니다. 계층을 나눠 보면 서버에서 받은 값을 어느 항목에 입력해야 하는지 알 수 있으며, ‘VLESS 지원’을 ‘모든 VLESS 조합 지원’으로 오해하지 않을 수 있습니다.

프록시 프로토콜은 클라이언트가 서버에 어떤 인증 정보를 보내고, 어떤 대상에 접속할지 전달하며, 요청을 어떻게 구성하는지 정합니다. 전송 계층은 TCP를 직접 사용하거나 WebSocket·gRPC 등의 방식으로 데이터를 전달하는 방법을 다룹니다. 보안 계층은 연결 상대를 인증하고 키를 협상하며 전송 데이터를 보호합니다. 각 계층은 서로 연관되어 있지만 임의로 조합할 수 있는 것은 아닙니다. 실제로 사용할 수 있는 조합은 코어 구현과 클라이언트 인터페이스의 제약도 받습니다.

주소·포트·이름을 각각 확인하세요

‘주소’는 일반적으로 실제 연결을 설정할 서버의 도메인이나 IP를 뜻하고, ‘포트’는 연결할 서비스를 지정합니다. TLS 서버 이름은 인증과 핸드셰이크에 사용되며, WebSocket의 Host와 경로는 해당 전송 방식의 요청 처리에 쓰입니다. 이 값들은 주소 입력란의 내용과 다를 수 있습니다. 설정 제공자가 항목을 구분해 안내했다면 받은 값을 그대로 입력하세요. 모든 도메인을 주소란의 값으로 바꾸면 네트워크 연결은 되더라도 인증서 검증이나 전송 요청 단계에서 실패할 수 있습니다.

로컬 수신 포트는 원격 서버의 포트와 다릅니다. v2rayN에서 자주 쓰는 로컬 SOCKS 포트는 브라우저나 다른 프로그램이 연결하는 포트이지, 원격 서비스의 진입점이 아닙니다. 로컬 포트를 바꿔도 서버 프로토콜은 달라지지 않으며, 원격 포트를 변경해도 로컬 수신 포트 충돌은 해결되지 않습니다. 로그를 볼 때는 오류가 로컬 인바운드, 원격 연결, 대상 접속 중 어느 단계에서 발생했는지 구분하세요. 단계마다 관련 설정이 다르므로 여러 항목을 한꺼번에 바꾸며 해결을 시도하지 않는 것이 좋습니다.

라우팅과 DNS는 프로토콜의 우열과 별개입니다

라우팅은 요청을 직접 연결, 프록시 또는 차단 중 어떤 경로로 보낼지 결정합니다. DNS는 도메인을 연결 가능한 주소로 변환하며 라우팅 판단에도 관여할 수 있습니다. 같은 프로토콜을 사용해도 라우팅 설정에 따라 접속 결과는 크게 달라집니다. 웹사이트가 직접 연결에서는 열리지만 프록시에서는 실패한다고 해서 프로토콜 자체에 문제가 있다고 단정할 수는 없습니다. DNS 응답, 대상 주소 유형 또는 규칙 순서가 원인일 수도 있습니다. 프로토콜을 바꾸기 전에 해당 요청이 실제로 어떤 경로를 선택했는지 확인하세요.

인터페이스의 도메인 정책, 트래픽 탐지, 다중화도 서로 다른 기능입니다. 도메인 정책은 도메인을 언제 해석하고 주소 매칭에 어떻게 반영할지 정합니다. 트래픽 탐지는 요청에서 대상 정보를 식별하려고 시도하며, 다중화는 여러 요청이 연결을 사용하는 방식을 바꿉니다. 특정 환경에서는 도움이 될 수 있지만 변수도 늘어날 수 있습니다. 처음 연결을 설정할 때는 클라이언트의 적절한 기본값을 유지하고 서버 필수 항목만 입력하세요. 연결이 안정된 뒤 고급 옵션을 하나씩 확인하는 편이 좋습니다.

02 / VMess와 VLESS의 설계 차이

VMess: 인증과 프로토콜 내부 보호

VMess는 Project V 생태계와 함께 발전했으며 기존 설정에서 자주 볼 수 있는 프록시 프로토콜입니다. 프로토콜 설계에 인증과 데이터 보호 기능이 포함되어 있어 클라이언트에 사용자 ID와 관련 보안 설정이 필요한 경우가 많습니다. 현재는 유지 관리되는 코어에서 지원하는 유효한 설정을 사용해야 합니다. 예전 가이드의 항목을 현재 인터페이스에 그대로 적용하지 마세요. 오래된 링크를 가져올 수 있다는 사실은 파서가 링크 형식을 인식한다는 뜻일 뿐, 인증 방식이 현재 서버에 적합하다는 보장은 아닙니다.

VMess를 이해할 때는 프로토콜 내부의 데이터 보호와 외부 TLS를 구분해야 합니다. 내부 보호 기능이 있더라도 배포 환경에 따라 외부에서 TLS를 사용할 수 있습니다. 그렇다고 보호 계층을 더 추가하면 반드시 속도나 안정성이 좋아지는 것은 아닙니다. 각 계층마다 협상과 처리 조건이 늘어납니다. 서버에서 요구하는 조합을 클라이언트에서도 그대로 사용하세요. 단순화를 위해 필요한 보안 계층을 끄거나, 서버에 설정되지 않은 전송 방식을 임의로 추가해서는 안 됩니다.

VMess 인증에는 시간 조건이 관련되므로 시스템 시간이 크게 어긋났는지 우선 확인할 만합니다. 사용자 ID를 바꾸기 전에 기기의 자동 시간 동기화를 켜고 다시 연결해 보세요. 보안 옵션은 현재 클라이언트와 서버가 함께 지원하는 값을 사용해야 하며, 이름만 보고 호환성을 추측해서는 안 됩니다. 오래된 설정에 추가 식별자 같은 과거 항목이 있다면 설정 제공자에게 현재 필요한 값을 확인하세요. 맞지 않는 설정을 임의의 값으로 계속 시험하는 것은 피해야 합니다.

VLESS: 간결한 프로토콜, 외부 조합으로 보안 구성

VLESS는 프록시 프로토콜 자체의 역할을 간소화하고 필요한 인증 및 요청 정보만 유지하는 방식으로 설계되었습니다. 전송 보안은 외부 메커니즘에 맡깁니다. VMess와 같은 프로토콜 내부 암호화 체계를 제공하지 않으므로 ‘VLESS가 가볍다’는 말을 ‘어떤 경우든 보안 계층을 설정할 필요가 없다’는 뜻으로 받아들여서는 안 됩니다. 일반적으로 VLESS는 TLS나 REALITY 같은 메커니즘과 함께 사용됩니다. 실제 보안 범위는 프로토콜 이름이 아니라 전체 설정에 따라 결정됩니다.

VLESS 설정 화면의 사용자 ID, 암호화 항목, 흐름 제어, 보안 유형은 각각 다른 역할을 합니다. 일부 설정에서 암호화 항목이 none으로 표시되는 것은 해당 프로토콜 항목의 값일 뿐, 연결 전체에 보안이 없다는 뜻은 아닙니다. 외부 보안 설정을 함께 확인해야 합니다. 흐름 제어 역시 속도를 무조건 높이는 스위치가 아닙니다. 서버·코어·현재 전송 조합이 모두 지원할 때만 입력하세요. 명확한 값을 받지 않았다면 임의로 추가하지 마세요.

REALITY와 Vision은 같은 설정 안내에 함께 나오는 경우가 많지만 같은 뜻은 아닙니다. REALITY는 보안 메커니즘이고, Vision은 관련 구현에서 사용하는 흐름 제어 방식으로 역할이 다릅니다. VLESS를 지원하는 구현이라고 해서 REALITY나 특정 흐름 제어 조합까지 지원하는 것은 아닙니다. 화면에 해당 옵션이 없다면 먼저 실행 중인 코어와 클라이언트 기능을 확인하세요. 흐름 제어 문자열을 메모, 경로 등 관계없는 입력란에 넣어서는 안 됩니다.

둘 중 어느 쪽을 선택할까요?

기존 서비스를 사용 중이라면 서버에서 실제로 제공하고 현재도 유지 관리되는 방식을 우선 선택하세요. 매개변수가 빠짐없이 설정되어 안정적으로 동작하는 VMess 설정을 VLESS라는 이름이 더 새롭다는 이유만으로 바꿀 필요는 없습니다. 서버에서 VLESS 보안 조합을 제공한다면 오래된 가이드에 맞추려고 VMess로 바꿀 이유도 없습니다. 마이그레이션하려면 서버 진입점, 클라이언트 항목, 호환 코어를 모두 준비하세요. 기존 설정을 비교용으로 남겨 두고 대상 웹사이트, 장시간 연결, UDP 요구 사항을 각각 확인해야 합니다.

새 설정을 비교할 때는 같은 네트워크와 대상, 비슷한 전송 조건을 사용하세요. VMess와 VLESS에 서로 다른 서버나 전송 방식을 사용하면 측정 결과는 주로 배포 환경의 차이를 반영하므로 프로토콜 차이라고 단정할 수 없습니다. 매개변수를 정확히 배포할 수 있는지, 클라이언트가 설정을 빠짐없이 가져오는지, 문제가 생겼을 때 재현하기 쉬운지를 중점적으로 살펴보세요. 이론적인 처리 오버헤드의 작은 차이보다 명확하고 관리하기 쉬운 설정이 더 중요할 때가 많습니다.

03 / Trojan·Shadowsocks·REALITY

Trojan: TLS 기반 프록시 연결

Trojan은 TLS 기반 프록시 연결 방식으로, 일반적인 설정에서는 비밀번호로 프록시 인증을 하고 TLS로 서버를 인증하며 연결을 보호합니다. 여기에는 역할이 다른 두 가지 인증 절차가 있습니다. 비밀번호는 프록시 서비스가 요청을 허용할지 결정하고, 인증서와 서버 이름은 클라이언트가 연결 상대를 확인하는 데 사용됩니다. 비밀번호가 맞아도 인증서 이름이 일치하지 않으면 연결이 실패할 수 있습니다. 인증서 검증에 성공해도 프록시 인증이 통과한다는 보장은 없습니다. 로그를 보고 어느 단계에서 문제가 발생했는지 구분하세요.

Trojan 설정에 필요한 항목은 보통 서버 주소, 포트, 비밀번호, TLS 서버 이름이며 나머지는 전송 방식과 구현에 따라 달라집니다. 인증서 검증에 실패하면 서버 이름, 기기 시간, 인증서 체인, 서버 설정을 먼저 확인하세요. 검증을 건너뛰는 설정을 장기간 사용해서는 안 됩니다. 검증을 건너뛰면 인증 경계가 달라지는 것이지, 일반적인 호환성 문제가 최적화되는 것이 아닙니다. 이 설정으로 일시적으로 연결되더라도 원래 문제가 해결됐다고 볼 수 없습니다.

Shadowsocks: 암호화 방식이 호환성을 좌우합니다

Shadowsocks는 간결한 암호화 프록시 설계에서 출발했으며 보통 SS라고 줄여 부릅니다. 암호화 방식과 비밀번호 등의 매개변수로 연결을 설정합니다. VMess의 전송 모드가 아니므로 가져올 때 해당 프로토콜을 선택해야 합니다. 세대별로 암호화 방식의 키 요구사항과 구현 지원 범위가 다르므로 SS라는 이름이 붙은 모든 설정이 서로 호환되는 것은 아닙니다. 특히 새로운 방식을 사용할 때는 클라이언트 화면에 옵션이 표시되는지뿐 아니라 실행 중인 코어에 실제 구현이 있는지도 확인해야 합니다.

AEAD 방식을 사용할 때는 클라이언트와 서버의 방식 이름 및 비밀번호가 일치해야 합니다. 특정 최신 방식은 키 형식에도 명확한 제약이 있을 수 있습니다. 오래된 가이드에 나온 구식 방식은 새로 설정할 때 기본값으로 선택하지 마세요. 공유 링크에 플러그인 매개변수가 포함되어 있다면 현재 클라이언트와 코어에서 처리할 수 있는지 별도로 확인해야 합니다. 기본 주소와 비밀번호를 가져오는 데 성공했다고 해서 추가 조건을 무시해도 되는 것은 아닙니다. 전송 구성 요소가 없으면 프로토콜 항목이 맞아도 연결할 수 없습니다.

REALITY: 독립 프록시 유형이 아닌 보안 메커니즘

REALITY는 Xray 생태계의 보안 메커니즘으로, VLESS 조합에서 자주 사용됩니다. VMess나 Trojan처럼 독립적으로 전체 프록시 프로토콜 역할을 하지는 않습니다. 따라서 클라이언트에 ‘REALITY’ 보안 옵션이 있더라도 상위 프로토콜과 주소, 인증 항목이 필요합니다. 선택 항목에 REALITY를 별도로 표시하는 이유는 흔한 조합의 경계를 비교하기 위해서이지, 모든 이름을 같은 계층으로 분류하기 위해서가 아닙니다. 서버 설정을 읽을 때도 계층을 구분해야 합니다.

REALITY 클라이언트 설정에는 서버 공개 키, 서버 이름, 짧은 ID, 클라이언트 지문 등이 포함되는 경우가 많습니다. 구체적인 이름과 표시 방식은 구현에 따라 달라질 수 있습니다. 공개 키는 서버의 해당 키 설정에서 가져와야 하며, 임의로 새 값을 만들어 대신 입력해서는 안 됩니다. 짧은 ID도 서버에서 허용하는 값 중 하나여야 합니다. 지문 옵션은 관련 핸드셰이크 동작에 사용되므로 임의로 바꾼다고 성능이 좋아지는 것은 아닙니다. 각 값이 따로는 그럴듯해 보여도 전체 설정이 서로 맞는다는 보장은 없습니다.

약칭 순위가 아니라 전체 조합으로 비교하세요

Trojan, SS, VLESS와 REALITY 조합의 연결 비용은 항목 수만으로 판단할 수 없습니다. TLS 세션 재개, 서버 구현, 프로세서 가속, 네트워크 왕복 시간, 실제 전송량이 모두 결과에 영향을 줍니다. 매개변수가 적으면 직접 확인하기는 쉽지만 모든 작업에 적합하다는 보장은 없습니다. UDP가 필요한 앱이라면 클라이언트 인바운드, 프로토콜 아웃바운드, 서버 전달 경로가 모두 원하는 동작을 지원하는지 확인하세요. 프로토콜 설명에 ‘UDP 지원’이라고 적혀 있다는 이유만으로 충분하다고 볼 수 없습니다.

선택할 때는 기존 서비스가 지원하는 범위를 먼저 고려하고, 설정 배포 과정에서 오류가 날 가능성도 살펴보세요. 여러 기기에서 같은 방식을 사용하려면 모든 기기에서 전체 매개변수를 입력할 수 있는지 확인해야 합니다. 한 기기에서 항목을 버려야만 가져올 수 있다면 진정한 호환이라고 할 수 없습니다. 검증된 기본 설정을 남겨 두고 같은 앱으로 새 조합을 시험하면 인증, 보안 계층, 앱 연결 중 어디서 문제가 생겼는지 쉽게 판단할 수 있습니다. 모든 실패를 프로토콜 불안정으로 돌리지 마세요.

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

클라이언트 화면이 실행 코어를 뜻하지는 않습니다

이 생태계를 이해하려면 Project V를 배경으로 알아 둘 필요가 있습니다. V2Fly와 Xray는 각각 구분해야 하는 코어 프로젝트입니다. 그래픽 클라이언트는 구독 관리, 설정 편집, 시스템 연결, 프로세스 실행을 담당하고 코어는 실제 프로토콜·전송·라우팅·연결 처리를 담당합니다. v2rayN 화면이 보인다는 이유만으로 제품 이름만 보고 이번 연결에서 어떤 코어가 실행됐는지 판단할 수는 없습니다. 기능 차이가 의심되면 클라이언트 관련 설정과 시작 로그에서 실제 실행 정보를 확인하세요.

V2Fly는 V2Ray 관련 구현과 생태계의 발전을 이어가고 있으며, Xray는 관련 코드 기반에서 분기해 독자적인 기능을 발전시켜 왔습니다. 두 프로젝트는 일부 개념과 설정 관례를 공유하지만 같은 프로그램의 다른 이름은 아닙니다. REALITY·Vision 등 관련 기능은 일반적으로 Xray 지원 여부를 확인해야 합니다. V2Fly 자체의 전송 방식과 설정 변화도 별도로 살펴보세요. 기능 사용 가능 여부는 실제 코어 구현과 클라이언트 연동에 따라 결정됩니다.

세 클라이언트의 역할

데스크톱에서는 v2rayN을 우선 사용하세요. Windows·macOS·Linux 설치 파일은 다운로드 페이지에서 받을 수 있지만, 인터페이스와 시스템 연동 기능은 플랫폼마다 다를 수 있습니다. v2rayN에서 코어 관련 설정을 관리할 수 있다고 해서 모든 프로토콜을 원하는 코어로 바꿔 실행할 수 있는 것은 아닙니다. Android에서는 v2rayNG가 Xray 코어를 사용하고, v2flyNG는 V2Fly 코어 기반 대안입니다. 클라이언트 이름을 속도 등급처럼 여기지 말고 서버 매개변수에 맞게 선택하세요.

코어를 바꾸기 전에 현재 정상적으로 동작하는 설정을 복사하고 라우팅, DNS, 수신 포트, 시작 옵션을 기록하세요. 그런 다음 코어나 관련 설정 조합만 바꾸고 로그에서 정상적으로 시작되는지 확인한 뒤 접속을 시험합니다. 다른 코어가 고급 항목을 거부하면 오류가 사라질 때까지 해당 줄을 삭제하지 말고, 그 코어에서 지원하는 설정 방식을 확인하세요. 삭제한 항목이 중요한 라우팅이나 보안 역할을 할 수 있으므로 프로그램이 시작된다고 설정의 의미까지 같아지는 것은 아닙니다.

JSON 구조가 비슷해도 그대로 바꿔 쓸 수 있는 것은 아닙니다

두 설정에 인바운드, 아웃바운드, 라우팅, DNS 영역이 모두 있다고 해서 구성 방식이 비슷하다는 점만 알 수 있습니다. 필드 값, 전송 이름, 기본 동작, 확장 기능은 다를 수 있습니다. 그래픽 클라이언트가 실행 설정을 생성할 때 로컬 수신 항목, 태그, 플랫폼 관련 매개변수를 추가할 수도 있으므로 직접 저장한 조각과 실제 실행 파일도 다를 수 있습니다. 문제를 해결할 때는 클라이언트의 설정 보기나 로그 기능으로 코어에 실제 전달된 내용을 먼저 확인하세요.

아래는 지원되는 코어의 라우팅 설정에서 사용할 수 있는 규칙 객체 예시입니다. 사설 IP 주소를 direct라는 아웃바운드로 보내도록 지정합니다. 전체 실행 설정은 아니므로 해당 아웃바운드 태그와 규칙 데이터가 이미 있어야 동작합니다. 이 예시는 필드 간 관계를 이해하기 위한 것이며 클라이언트가 생성한 전체 설정을 그대로 덮어쓰면 안 됩니다. 그래픽 인터페이스를 사용한다면 라우팅 편집 영역에서 같은 규칙을 설정하고 생성된 결과를 확인하는 편이 안전합니다.

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

규칙 파일도 호환성을 좌우합니다. 설정에 geosite:나 geoip: 접두사가 있다고 해서 관련 데이터가 반드시 존재하는 것은 아니며, 데이터에 참조한 태그가 포함되어 있다는 보장도 없습니다. 코어를 바꾸거나 디렉터리를 옮기거나 백업을 복원한 뒤에는 클라이언트가 사용하는 데이터 경로와 업데이트 결과를 확인하세요. 자세한 내용은 GeoIP·GeoSite 규칙 파일 업데이트 안내를 참고하세요. 규칙을 불러오지 못한 문제를 프록시 프로토콜 인증 실패로 오해하지 마세요.

05 / 연결 속도와 리소스 사용량 비교하기

속도를 관찰 가능한 단계로 나누세요

‘연결이 빠르다’는 말은 클라이언트 시작이 빠르다는 뜻일 수도 있고, 첫 핸드셰이크나 웹페이지의 첫 응답이 빠르다는 뜻일 수도 있으며, 지속 다운로드 처리량이 높다는 뜻일 수도 있습니다. 각 지표는 서로 다릅니다. 코어 시작 시간은 설정 규모, 규칙 로딩, 기기 성능에 영향을 받습니다. 첫 연결은 이름 해석, 네트워크 왕복 시간, 보안 핸드셰이크에 영향을 받으며, 지속 전송은 대역폭, 혼잡도, 대상 서비스, 서버 부하에도 좌우됩니다. 어느 단계를 측정했는지 먼저 정해야 프로토콜 비교 결과를 해석할 수 있습니다.

보안 핸드셰이크가 첫 연결 과정에 추가 작업을 더할 수는 있지만, ‘TLS를 쓰는 방식은 무조건 느리다’고 단정할 수는 없습니다. 세션 재개, 연결 재사용, 앱의 장시간 연결 방식에 따라 반복 오버헤드가 줄어들 수 있습니다. 반대로 클라이언트 연결 테스트가 빠르다고 해서 복잡한 웹페이지도 빠르게 열리는 것은 아닙니다. 웹페이지는 여러 도메인에 접속하고 다양한 주소를 해석하며 여러 연결을 설정할 수 있습니다. 테스트 버튼의 결과는 일부 상황을 보여주는 지표로만 활용하세요.

처리기 사용량은 전송량과 유휴 상태를 함께 살펴보세요

암호화 방식, 프로세서 명령어 지원, 메모리 복사, 캡슐화 단계 수는 모두 CPU 사용량에 영향을 줍니다. 같은 프로토콜이라도 기기에 따라 상대적인 결과가 다를 수 있으므로 모든 기기에 적용되는 리소스 순위를 정할 수는 없습니다. 사용량을 살필 때는 유휴 상태와 지속 전송 상태를 구분하고 가능한 한 비슷한 전송량으로 비교하세요. 실제 데이터 전송량이 많아 사용량이 높아진 것만으로 효율이 낮다고 볼 수는 없습니다. 유휴 상태에서도 계속 비정상적으로 바쁘다면 원인을 살펴봐야 합니다.

메모리 사용량도 연결 수, 라우팅 데이터, DNS 캐시, 로그 버퍼의 영향을 받습니다. 시작 직후의 수치와 한동안 실행한 뒤의 수치는 직접 비교할 수 없으며, 운영체제 작업 관리 도구마다 집계 기준도 다를 수 있습니다. 메모리가 늘어나는 것을 발견하면 연결이 계속 쌓이는지, 앱이 재시도를 반복하는지, 로그 수준이 지나치게 자세한지 먼저 확인하세요. 한 번 찍은 화면만으로 특정 코어가 ‘메모리를 덜 쓴다’고 결론 내리기에는 근거가 부족합니다.

한 번의 속도 측정보다 조건을 통제한 비교를 하세요

비교할 때는 같은 기기와 네트워크, 같은 대상 리소스, 비슷한 시간대를 사용하세요. 전체 프로토콜 조합을 기록하고 서로 다른 지역의 서버를 같은 프로토콜 순위에 넣지 마세요. 먼저 고정된 페이지 열기, 같은 파일 동기화, 같은 업무 연결 유지처럼 앱에서 실제로 하는 작업을 비교한 뒤 클라이언트 연결 테스트를 참고하세요. 여러 차례 반복하고 테스트 순서를 번갈아 적용하면 캐시, 백그라운드 업데이트, 순간적인 네트워크 변화의 영향을 줄일 수 있습니다.

다중화는 별도 변수로 시험하세요. 특정 환경에서는 연결 설정 비용을 줄일 수 있지만 연결 간 영향이 달라질 수도 있습니다. 일부 전송 방식이나 흐름 제어 조합에는 별도 제약도 있습니다. 다중화, 지문, DNS, 도메인 정책을 동시에 바꾼 뒤 결과를 한 항목의 효과라고 판단하지 마세요. 변경할 때마다 기록을 남기고 처음 접속인지 장시간 연결 업무인지 어떤 상황에서 개선됐는지 적어야 설정을 계속 사용할 가치가 있는지 판단할 수 있습니다.

데스크톱에서는 시스템 프록시와 TUN의 연결 방식 차이도 살펴봐야 합니다. 두 번의 테스트에서 연결 방식이 다르면 실제로 코어에 전달되는 트래픽 범위, DNS 동작, 백그라운드 부하가 달라질 수 있습니다. 성능 결론은 특정 기기와 연결 방식, 서버 설정의 전체 조합에 한정해야 하며 특정 프로토콜이 항상 우세하다고 일반화해서는 안 됩니다. 먼저 정확한 동작과 장기적인 안정성을 확보한 다음 실제 사용 경험에 영향을 주는 부분만 소규모로 최적화하세요.

06 / Android 배터리 및 백그라운드 연결

배터리 소모는 프로토콜만으로 결정되지 않습니다

Android 기기에서 v2rayNG나 v2flyNG는 시스템 VPN 인터페이스를 통해 트래픽을 처리하는 경우가 많습니다. 시스템 통계에서는 해당 인터페이스를 거친 일부 작업이 클라이언트 사용량으로 집계될 수 있으므로 클라이언트의 배터리 사용 비율이 높다고 해서 코어가 아무 작업 없이 돌아간다고 단정할 수는 없습니다. 화면 사용 시간, 실제 전송량, 백그라운드 앱, 기기 대기 시간을 함께 살펴보세요. 대용량 파일 동기화, 동영상 재생, 장시간 유휴 상태는 서로 다른 부하이므로 배터리 화면의 비율 하나만 비교해서는 안 됩니다.

모바일 네트워크의 무선 모듈은 여러 활성 상태 사이를 오갑니다. 짧은 요청이 자주 발생하거나 연결을 반복해서 재시도하거나 연결 유지를 지나치게 자주 확인하면 저전력 상태에 진입하기 어려울 수 있습니다. 이때 프로토콜 암호화에 필요한 처리기 작업은 전체 비용 중 일부일 뿐입니다. 신호가 약하거나 연결이 자주 끊기면 링크를 다시 설정하는 데 드는 비용도 커질 수 있습니다. 프로토콜 영향을 살펴보기 전에 네트워크가 안정적인지 확인하고 백그라운드 앱이 계속 요청을 보내는 상황을 배제하세요.

연결 유지와 백그라운드 제한의 균형

연결 유지는 필요한 연결을 유지하거나 끊어진 상태를 빠르게 감지하는 데 사용되지만 네트워크마다 시간 초과 동작이 다릅니다. 모든 연결 유지 간격을 짧게 설정하면 기기가 더 자주 깨어날 수 있고, 모두 끄면 일부 장시간 연결이 더 쉽게 끊길 수 있습니다. 명확한 문제가 없다면 클라이언트와 서버 설정의 적절한 기본값을 우선 사용하세요. 값을 바꿔야 한다면 관련 항목을 한 번에 하나씩 수정하고, 대기 중과 잠금 해제 후, 네트워크 전환 후 연결이 복구되는지 확인하세요. 화면을 켠 상태에서 접속하는 것만으로 판단하지 마세요.

시스템 배터리 최적화나 제조사별 백그라운드 관리 기능이 클라이언트 프로세스를 종료하면 화면을 잠근 뒤 연결이 끊기거나, 잠금 해제 후 다시 연결되거나, 서비스 상태와 알림이 서로 다르게 표시될 수 있습니다. 클라이언트의 백그라운드 실행이 허용되어 있는지와 관련 시스템 안내를 처리했는지 확인하세요. 백그라운드 권한을 허용했다고 해서 모든 앱이 계속 인터넷에 연결되어야 하는 것은 아닙니다. 업무상 필요를 확인한 뒤 앱별 프록시를 사용할 수 있지만, 특정 앱을 제외하면 클라이언트 처리 비용만 줄어드는 것이 아니라 해당 앱의 트래픽 경로도 달라진다는 점을 이해해야 합니다.

유휴·사용 중·네트워크 전환 상황을 나눠 확인하세요

정상 동작이 확인된 설정 하나를 사용해 화면을 끈 유휴 상태, 특정 앱을 앞에 둔 상태, Wi-Fi와 모바일 네트워크를 전환한 뒤 연결을 복구하는 상태를 각각 살펴보세요. 각 단계의 시간과 사용 방식은 가능한 한 비슷하게 유지하고 재연결 알림이나 오류 로그가 있었는지 기록하세요. 테스트 중에 업데이트를 설치하거나 사진을 동기화하거나 연속으로 속도를 측정하지 마세요. 이런 추가 부하는 배터리 비교의 신뢰도를 떨어뜨리고 실제 백그라운드 동작을 가릴 수 있습니다.

화면을 켠 상태에서는 정상인데 유휴 상태의 배터리 소모가 눈에 띄게 높다면 인증 반복 실패, 이름 해석 오류, 대상 서버 연결 실패, 연결 유지 재시도를 확인하세요. 실패가 반복되면 기기가 같은 작업을 계속 수행할 수 있으므로 프로토콜 매개변수를 바꾸기 전에 근본 원인을 해결해야 합니다. 재현에 필요한 짧은 시간만 로그를 기록하고 문제를 확인한 뒤에는 평소 로그 수준으로 되돌리세요. 자세한 로그를 계속 남기면 처리량과 쓰기 작업이 늘어나며 공유에 적합하지 않은 연결 정보가 기록될 수도 있습니다.

특정 앱을 사용할 때만 배터리 소모가 높다면 그 앱의 실제 트래픽과 연결 동작을 비교하고 프록시 경로가 달라져 재시도를 반복하는지 확인하세요. 앱별 프록시를 설정할 때는 브라우저가 외부 앱을 호출하는 경우, 계정 로그인, 시스템 구성 요소 간의 연동도 고려해야 합니다. 일부만 프록시로 보내면 앱의 작업 경로가 일관되지 않을 수 있습니다. 앱을 제외한 뒤 배터리 비율이 낮아졌다고 해서 클라이언트가 더 효율적으로 바뀌었다고 단정하지 마세요. 다른 통계 항목으로 작업이 옮겨갔을 수도 있습니다.

v2rayNG와 v2flyNG를 비교해야 한다면 두 클라이언트가 모두 완전하게 지원하는 서버 조합을 사용하고 VPN 연결 서비스를 여러 개 동시에 실행하지 마세요. 한쪽은 REALITY를 사용하고 다른 쪽은 다른 서버를 사용한다면 코어의 전력 효율만 비교한 결과가 아닙니다. 자세한 확인 순서는 v2rayNG 배터리 소모 및 백그라운드 실행 문제 해결을 참고하세요. 모바일에서는 사용량과 무관하게 배터리 비율을 최소화하기보다 필요한 작업을 안정적으로 완료하는 것이 합리적인 목표입니다.

07 / 공유 링크·구독·설정 호환성

구독은 설정을 배포하는 형식이지 별도의 프로토콜이 아닙니다

공유 링크는 보통 연결 설정 하나를 설명하고, 구독은 여러 설정을 한곳에서 배포하고 업데이트하는 데 사용됩니다. 구독 주소 자체가 최종 프록시 프로토콜을 결정하지 않으며 모든 클라이언트에서 내용을 읽을 수 있다는 보장도 없습니다. 구독 내용에는 링크 목록, 인코딩된 목록, 특정 구조의 설정 문서 등이 포함될 수 있습니다. 바깥 형식을 읽는 것은 가져오기 과정의 첫 단계일 뿐입니다. 각 설정의 프로토콜, 보안 계층, 전송 항목도 따로 확인해야 합니다.

VMess 공유 링크는 인코딩된 구조화 데이터로 매개변수를 표현하는 경우가 많고, VLESS와 Trojan 등은 주소와 쿼리 매개변수를 조합해 표현하는 경우가 많습니다. SS 링크는 사용자 정보를 자체 규칙에 따라 인코딩합니다. 클라이언트마다 확장 매개변수 지원 범위가 다르고 이름이 같은 항목도 서로 다른 방식으로 매핑해야 할 수 있습니다. 직접 복사할 때는 도메인과 포트만 남기지 말고 전체 링크를 보존하세요. QR 코드에 전체 설정이 들어 있다면 스캔 결과가 앱에서 잘리지 않았는지도 확인해야 합니다.

가져오기에 성공한 뒤에도 주요 항목을 확인하세요

가져온 뒤 먼저 편집 화면을 열어 프로토콜 유형, 주소, 포트, 인증 항목을 확인하고 보안 유형, 서버 이름, 전송 방식, 경로, 서비스 이름도 살펴보세요. REALITY를 사용하는 경우 공개 키, 짧은 ID, 지문, 흐름 제어까지 유지됐는지 확인해야 합니다. 설정에 표시된 이름이 맞다는 것은 이름을 읽었다는 뜻일 뿐, 내부 매개변수가 모두 보존됐다는 뜻은 아닙니다. 다른 기기에서 처음 설정을 옮길 때는 특히 이 과정을 확인하세요.

URL의 특수 문자는 퍼센트 인코딩이 필요할 수 있습니다. 비밀번호, 경로, 이름에 포함된 기호가 잘못 분리되면 파싱 결과가 달라집니다. 인코딩 문자를 임의로 바꿔 링크를 ‘수정’하려 하지 말고 원본 전체를 다시 복사하거나 클라이언트에서 지원하는 파일 가져오기 방식을 사용하세요. 메신저로 전달할 때 줄바꿈, 자동으로 붙는 문장부호, 링크 잘림도 확인해야 합니다. 직접 다시 입력하는 방법은 매개변수가 명확하고 항목별로 검증할 수 있을 때만 사용하세요.

형식을 변환하면 설정의 의미가 달라질 수 있습니다

구독 형식을 다른 형식으로 바꾸는 일은 파일 확장자만 바꾸는 작업이 아닙니다. 대상 형식에서 특정 흐름 제어, 지문, DNS 동작, 라우팅 규칙을 표현하지 못할 수 있고 변환 도구가 다른 기본값을 적용할 수도 있습니다. 변환된 설정이 실행되더라도 원래의 접속 경로와 보안 조건이 유지된다는 보장은 없습니다. 변환이 필요하다면 먼저 대상 클라이언트가 지원하는 기능을 확인하고 변환 전후의 주요 항목을 하나씩 비교하세요. 설정 개수만 확인해서는 안 됩니다.

전체 실행 설정과 공유 링크 하나는 서로 같지 않습니다. 실행 설정에는 로컬 인바운드, 여러 아웃바운드, 라우팅, DNS가 포함될 수 있지만 공유 링크는 보통 원격 연결 하나만 담습니다. 전체 설정을 다른 기기로 옮기면 맞지 않는 수신 주소나 플랫폼 옵션까지 가져올 수 있습니다. 연결 하나만 공유하면 기존에 사용하던 라우팅 규칙이 빠질 수도 있습니다. 이전 목적에 맞는 내보내기 방식을 선택하고 새 기기에서 다시 설정해야 하는 항목을 분명히 하세요.

구독을 업데이트하기 전에 원격 내용과 로컬 수정을 구분하세요

구독 업데이트는 일반적으로 원격 내용을 기준으로 하며, 구독 항목을 로컬에서 편집한 내용은 다음 업데이트 때 덮어써질 수 있습니다. 실제 동작은 클라이언트마다 다릅니다. 장기간 유지할 수정은 클라이언트에서 지원하는 방식에 따라 별도 설정이나 그룹으로 복사하고 용도를 기록하세요. 테스트 항목과 일상적으로 사용하는 구독을 한데 섞지 마세요. 업데이트 뒤 어떤 항목이 서버와 계속 동기화되는지 파악하기 어려워집니다. 변경 전에 복원 가능한 백업을 남기는 편이 기억에 의존해 항목을 다시 만드는 것보다 안전합니다.

구독 주소와 내보낸 인증 매개변수는 서비스에 접근할 권한을 줄 수 있으므로 민감한 정보로 취급하세요. 문제 해결 화면을 공유할 때는 전체 구독 주소, 사용자 ID, 비밀번호 등을 가려야 합니다. 공개 키는 개인 키와 다르지만 다른 설정 세부 정보와 함께 공개할 이유는 없습니다. 업데이트 실패 시에는 주소 접속 실패, 내용 파싱 실패, 가져온 뒤 연결 실패를 구분하세요. 각 단계의 원인이 다릅니다. 기본 작업 순서가 필요하면 구독 가져오기 및 연결 가이드에서 흐름에 따라 확인하세요.

08 / 사용 환경별 선택 및 단계별 문제 해결

먼저 호환 범위를 확인하고 사용 경험을 비교하세요

세 가지 질문으로 선택 범위를 좁힐 수 있습니다. 서버에서 어떤 전체 조합을 제공하는지, 사용 중인 기기에서 해당 조합을 지원하는지, 실제 업무에 어떤 연결 기능이 필요한지 확인하세요. 데스크톱에서는 v2rayN을 우선 사용하고 실제 실행 코어를 확인하세요. Android에서 서버에 Xray 전용 기능이 필요하다면 해당 매개변수를 입력할 수 있는 v2rayNG를 선택하세요. V2Fly 관련 설정을 사용하는 서비스라면 v2flyNG의 호환 범위를 확인하세요. 클라이언트 선택은 기능 호환의 문제이지 이름을 등급별로 매기는 일이 아닙니다.

일상적인 웹 검색과 사무 작업에는 설정 배포가 명확하고 인증서나 키를 관리하기 쉬우며 업데이트 후 복구할 수 있는 방식을 우선 고려하세요. 기존 설정이 안정적으로 동작한다면 기준으로 남겨 두고 새 설정은 별도로 시험하세요. 여러 기기에서 같은 서비스를 사용한다면 모든 기기에서 전체 조합을 빠짐없이 설정할 수 있어야 합니다. 특정 기기에서 핵심 항목을 생략해야만 가져올 수 있다면 누락을 정상적인 호환으로 여기지 말고 모두가 지원하는 설정을 다시 선택하세요.

실시간 통신, 게임, 기타 UDP 작업에는 전체 연결 경로의 지원 여부를 확인해야 합니다. 앱 트래픽이 클라이언트에 들어오는지, 로컬 연결 방식이 해당 요청을 전달하는지, 프로토콜 아웃바운드가 지원하는지, 서버가 허용하고 올바르게 전달하는지 모두 살펴보세요. 브라우저에서 웹페이지가 열린다고 UDP 경로까지 사용할 수 있다는 뜻은 아닙니다. TUN도 모든 작업을 해결하는 만능 스위치가 아닙니다. 연결 범위를 바꾸는 기능이며 라우팅, 이름 해석, 원격 서버의 기능에 여전히 영향을 받습니다.

연결 실패는 데이터 경로를 따라 확인하세요

첫 번째로 코어가 시작되는지 확인합니다. 로그에 알 수 없는 필드나 프로토콜, 규칙 로딩 실패가 표시되면 원격 비밀번호를 바꾸기 전에 설정 문법, 구현 기능, 규칙 데이터를 먼저 확인하세요. 두 번째로 원격 연결이 설정되는지 확인합니다. 주소 해석 실패, 연결 시간 초과, 연결 거부는 각각 다른 원인을 가리킵니다. 세 번째로 보안 핸드셰이크와 프록시 인증을 확인합니다. 서버 이름, 시간, 인증서, 공개 키, 짧은 ID, 인증 매개변수를 구체적인 로그에 따라 하나씩 점검하세요.

네 번째로 요청이 예상한 경로로 나가는지 확인합니다. 클라이언트가 실행 중으로 표시되어도 앱이 시스템 프록시를 사용하지 않거나 요청이 직접 연결로 라우팅되면 예상과 다른 결과가 나올 수 있습니다. 로컬 수신 주소와 포트를 확인하고 앱에 별도 프록시 설정이 있는지 살펴본 다음 대상 도메인에 어떤 규칙이 적용되는지 확인하세요. 도메인 접속만 실패하고 IP 주소 접속 조건은 다르다면 DNS와 도메인 정책을 더 살펴봐야 합니다. 관계없는 문제를 해결하려고 인증서 검증을 끄지 마세요.

문제에 맞는 안내 문서를 확인하세요

로컬 포트가 사용 중이라 시작에 실패하면 로컬 포트 충돌 문제 해결에서 충돌을 확인하세요. 포트를 바꾼 뒤에는 해당 포트에 의존하는 프로그램도 함께 수정해야 합니다. 처음 설치하거나 설치 경로에 문제가 있다면 첫 설치 점검 목록을 참고하세요. 이런 문제는 로컬 실행 환경에서 발생하므로 프로토콜을 바꿔도 대개 해결되지 않습니다. 오류가 도메인 해석이나 분기에 집중된다면 DNS 분할 해석 안내를 확인하고 같은 연결 항목을 반복해서 다시 만들지 마세요.

문제를 기록할 때는 기기 운영체제, 클라이언트 이름, 실제 코어, 프로토콜 조합, 연결 방식, 민감한 정보를 가린 오류 요약을 남기세요. 화면 잠금 후에만 발생하는지, 특정 앱에서만 생기는지, 특정 유형의 대상에서만 나타나는지 등 발생 조건도 적어야 합니다. 한 번에 변수 하나만 바꾸고 원래 상태로 되돌릴 수 있는지도 기록하세요. 이렇게 하면 일시적인 네트워크 변화와 재현 가능한 설정 오류를 구분하고 이미 제외한 원인을 반복해서 확인하거나 불필요하게 재설치하고 이전하는 일을 줄일 수 있습니다.