V2Ray 프로토콜 및 커널선택 가이드

01 / MODEL

프로토콜을 선택하기 전에: 프로토콜·전송·보안 계층부터 구분하기

클라이언트의 한 줄 노드는 실제로 여러 계층의 매개변수로 구성됩니다

클라이언트 화면에서 “프로토콜”은 넓은 분류명으로 사용되는 경우가 많지만, 실제로 사용할 수 있는 연결은 프로토콜 이름 하나만으로 결정되지 않습니다. 일반적인 VLESS 노드를 예로 들면 VLESS는 클라이언트와 서버가 인증 정보와 데이터를 교환하고 전달하는 기본 방식을 정의합니다. TCP, WebSocket, gRPC 등의 필드는 하위 데이터 전송 방식을 설명하고, TLS 또는 REALITY는 핸드셰이크와 보안 계층을 담당합니다. XTLS Vision은 데이터 처리에 참여하는 플로우 제어 방식일 수 있습니다. 주소, 포트, 사용자 식별자, 서버 이름은 연결 매개변수에 해당합니다. 어느 한 계층이라도 맞지 않으면 시간 초과, 핸드셰이크 실패, 연결 후 트래픽 없음으로 나타날 수 있습니다.

따라서 선택할 때 “VLESS”와 “VLESS + TCP + REALITY + Vision”을 같은 수준의 이름으로 보면 안 됩니다. 전자는 프로토콜 구조만 나타내고, 후자가 완전한 조합에 더 가깝습니다. 구독을 가져온 뒤 클라이언트에 표시되는 유형 태그는 보통 가장 쉽게 식별할 수 있는 부분만 강조합니다. 전체 매개변수는 노드 편집 화면에서 직접 확인해야 합니다. 특히 텍스트 구독을 다른 클라이언트로 옮길 때 이름이 같다고 해서 모든 확장 필드가 보존되는 것은 아닙니다.

고정된 순위보다 네 가지 판단 기준이 더 신뢰할 만합니다

첫째는 서버 호환성입니다. 클라이언트가 임의로 VMess를 VLESS로 바꿀 수 없으며, REALITY를 선택한다고 해서 일반 TLS 노드에 해당 기능이 생기지도 않습니다. 프로토콜, 전송, 보안 매개변수는 서버 설정과 하나씩 일치해야 합니다. 둘째는 커널 기능입니다. v2rayN은 데스크톱에서 흔히 사용하는 설정을 처리할 수 있고, v2rayNG은 주로 Xray 커널을 사용하며, v2flyNG은 V2Fly 커널을 대상으로 합니다. 동일한 기본 노드라도 이러한 클라이언트에서 지원 범위가 다를 수 있으며, REALITY·Vision·특정 전송 확장을 사용할 때 차이가 더 뚜렷합니다.

셋째는 기기 환경입니다. 데스크톱은 일반적으로 처리 시간과 메모리가 더 여유로우므로 호환성, 라우팅 기능, 관리 편의성을 우선할 수 있습니다. Android 기기는 백그라운드 실행, 무선 네트워크 전환, 지속적인 핸드셰이크와 반복 재연결로 인한 배터리 소모도 고려해야 합니다. 넷째는 설정 출처입니다. 노드가 구독에서 제공된다면 구독에 명시되어 있고 클라이언트가 완전히 인식하는 유형을 우선하세요. 특정 이름을 얻기 위해 누락된 매개변수를 추측해 수동으로 입력하지 않는 것이 좋습니다.

무엇보다 완전성을 확인한 뒤 성능을 비교하세요

연결 속도의 전제는 매개변수가 올바른지 여부입니다. 주소 확인, 포트 접근 가능 여부, 정확한 시스템 시간, 일치하는 사용자 식별자, 동일한 전송 경로가 프로토콜 이름보다 첫 연결 성공률에 직접적인 영향을 줍니다. 가져온 뒤 서버 이름, WebSocket 경로, REALITY 공개 키 또는 짧은 식별자가 빠져 있다면 노드 유형만 바꿔서는 해결되지 않습니다. 노드 정보나 구독 출처로 돌아가 대조해야 하며, 클라이언트에서 값을 하나씩 추측해서는 안 됩니다.

실용적인 순서는 다음과 같습니다. 먼저 클라이언트가 노드 유형을 인식하는지 확인하고, 주소·포트·인증 필드를 대조한 다음 전송 방식과 부가 매개변수를 확인합니다. 마지막으로 보안 계층과 플로우 제어를 점검하세요. 이 과정을 마친 뒤 연결 수립 시간, 지속 처리량, 메모리 사용량, 배터리 소모를 비교해야 합니다. 이렇게 하면 “설정 오류”와 “프로토콜 선택의 차이”를 분리할 수 있어 한 번의 핸드셰이크 실패를 특정 프로토콜의 느린 속도로 오해하지 않게 됩니다.

02 / VMESS

VMess: 기존 설정 호환성과 매개변수 범위

설계 배경과 현재 위치

VMess는 Project V 생태계에서 비교적 이른 시기에 널리 사용되기 시작한 프로토콜입니다. 사용자 식별자, 인증 정보, 데이터 전송 규칙을 하나의 프로토콜 구조로 구성하고 클라이언트와 서버 사이에 시간 기반 인증 절차를 둡니다. 이 설계 때문에 VMess는 단순한 “주소와 비밀번호” 조합이 아니며, 시스템 시간 오차가 연결에 영향을 줄 수 있는 이유도 여기에 있습니다. 오래전에 배포된 많은 서버, 구독 변환 도구, 클라이언트 설정이 VMess를 기반으로 하므로 기존 노드 호환성 측면에서 여전히 실용적인 가치가 있습니다.

VMess를 선택하는 주된 이유는 처리 단계를 최소화하려는 것이 아니라 기존 설정이 안정적으로 작동하고 관련 구독 필드를 클라이언트가 완전히 해석하기 때문인 경우가 많습니다. 서버가 VMess만 제공한다면 클라이언트도 같은 프로토콜을 유지해야 합니다. 노드 유형을 VLESS로 바꾸고 기존 UUID를 그대로 둔다고 동등한 연결이 만들어지지는 않습니다. 두 프로토콜의 인증 방식과 데이터 구조가 다르기 때문입니다. 프로토콜 마이그레이션은 서버와 클라이언트를 함께 조정해야 하며 로컬 태그만 바꿔서는 안 됩니다.

alterId, 암호화 옵션과 기존 설정 확인

기존 자료에는 alterId가 자주 등장합니다. 이는 초기 VMess 설정 체계의 일부로, 최신 설정에서는 일반적으로 0을 사용합니다. 과거 구독을 가져올 때 클라이언트에 이 필드가 표시되더라도 서버의 실제 설정을 기준으로 판단하고, 문서 작성 시기에 따라 임의의 숫자로 바꾸지 마세요. 클라이언트마다 더 이상 자주 사용하지 않는 옵션을 숨기거나 가져오는 과정에서 기본값을 자동으로 입력할 수 있습니다. 이러한 화면 차이가 프로토콜 내용의 변경을 의미하는 것은 아닙니다.

VMess 노드에는 security 또는 “암호화 방식”이 표시되기도 합니다. 이 필드는 VMess 데이터 계층의 처리 방식을 나타내며 외부 TLS와는 다른 옵션입니다. 외부 TLS의 활성화 여부는 전송 보안 필드가 결정합니다. security에 이미 값이 있다는 이유로 TLS도 설정되었다고 생각하는 것이 흔한 오해입니다. 실제로 두 항목은 서로 다른 계층에 있습니다. 문제를 점검할 때는 각각 확인해야 하며 한 항목으로 다른 항목을 대신할 수 없습니다.

{
  "protocol": "vmess",
  "settings": {
    "vnext": [{
      "address": "example.com",
      "port": 443,
      "users": [{
        "id": "11111111-1111-4111-8111-111111111111",
        "alterId": 0,
        "security": "auto"
      }]
    }]
  }
}

위 예시는 VMess 아웃바운드의 핵심 계층만 보여 줍니다. 실제 연결에는 서버와 일치하는 전송 및 보안 설정도 필요합니다. 예시 주소와 사용자 식별자는 필드 구조를 설명하기 위한 것일 뿐 노드로 사용할 수 없습니다. 수동으로 입력할 때는 노드 정보의 각 값을 해당 위치에 넣어야 하며 예시 내용을 그대로 복사해서는 안 됩니다.

전송 조합과 성능 이해

VMess는 TCP, WebSocket 등의 전송 방식과 조합할 수 있고 TLS를 추가할 수도 있습니다. 조합별 차이는 VMess 프로토콜 자체의 차이보다 큰 경우가 많습니다. 예를 들어 직접 TCP를 사용하면 캡슐화 경로가 비교적 짧고, WebSocket은 추가 프레임 처리가 필요하며 경로와 Host 등의 필드가 일치해야 합니다. TLS는 핸드셰이크와 암호화 계산을 추가합니다. “VMess가 빠른가”를 논하려면 양쪽이 같은 전송 방식, 같은 보안 계층, 같은 서버와 네트워크 조건을 사용하는지 밝혀야 합니다.

리소스 사용량 측면에서 VMess의 인증 및 데이터 처리는 구조가 더 간결한 VLESS보다 단계가 많을 수 있지만, 최신 데스크톱에서는 이런 차이가 주요 병목이 아닐 수 있습니다. 실제로 눈에 띄는 지연은 도메인 조회, 서버와의 거리, 무선 네트워크 변동, 반복적인 연결 수립, 전송 계층 재시도에서 발생하는 경우가 많습니다. 모바일 기기에서 계속 사용할 때는 클라이언트 로그에 주기적인 연결 끊김과 재연결이 나타나는지 확인하세요. 반복 핸드셰이크는 대기 시간과 배터리 소모를 함께 늘립니다.

유지하기 좋은 경우와 마이그레이션이 필요한 경우

VMess 노드의 매개변수가 완전하고 연결이 안정적이며 구독 업데이트가 정상이고 현재 클라이언트가 전송 설정을 정확히 인식한다면 계속 사용해도 좋습니다. 새로운 이름이 등장할 때마다 반드시 마이그레이션할 필요는 없습니다. 반대로 새 서버를 구축 중이고 클라이언트와 커널이 필요한 보안 조합을 포함한 VLESS를 명확히 지원한다면 더 간결한 프로토콜 구조부터 검토할 수 있습니다. 마이그레이션할 때는 기존 노드를 비교용으로 남겨 두고 새 설정을 추가해 검증한 뒤 삭제하세요. 매개변수를 확인하기 전에 기존의 사용 가능한 기준점을 없애지 않도록 주의해야 합니다.

v2rayN, v2rayNG, v2flyNG 사이에서 VMess 노드를 옮길 때 기본 필드는 대체로 호환되지만 일부 전송 확장은 커널에 따라 달라집니다. 가져온 뒤에는 최소한 프로토콜, 주소, 포트, UUID, 전송 방식, TLS 활성화 여부, 서버 이름, 경로를 확인하세요. 구독에 vmess:// 항목 하나만 제공되는 경우 클라이언트가 보통 디코딩을 처리합니다. 빈 노드나 어긋난 필드가 표시되면 임의로 값을 보충하기보다 구독 내용이 완전한지 먼저 확인해야 합니다.

03 / VLESS · REALITY

VLESS, REALITY, XTLS Vision: 세 계층의 역할

VLESS는 경량 프로토콜 구조입니다

VLESS는 프로토콜 자체가 맡는 역할을 단순화하는 데 중점을 둡니다. 사용자 식별자로 인증을 수행하지만 VLESS 데이터 계층에서 완전한 암호화 체계를 중복 제공하지 않고 TLS, REALITY 등의 외부 방식에 보안 기능을 맡깁니다. 이러한 분업은 프로토콜 구조를 명확하게 하고 일부 중복 처리를 줄입니다. 다만 “VLESS 자체가 가볍다”는 말이 모든 VLESS 조합이 반드시 빠르다는 뜻은 아닙니다. 실제 비용은 전송 방식, 보안 핸드셰이크, 플로우 제어, 서버 구현, 네트워크 경로가 함께 결정합니다.

클라이언트 편집 화면에서 VLESS의 일반적인 필드는 주소, 포트, UUID, 암호화 값, 전송 방식, 보안 유형, 플로우 제어입니다. 일부 화면에서는 암호화 필드에 none을 입력하도록 요구합니다. 이는 프로토콜 구조의 일부이며 전체 연결에 보안 계층이 없다는 뜻이 아닙니다. 노드가 TLS 또는 REALITY를 함께 사용한다면 보안 처리는 외부 계층에 위치합니다. 보안 조합을 판단할 때는 “전송 계층 보안” 또는 유사한 옵션을 확인해야 하며 VLESS의 암호화 필드만 봐서는 안 됩니다.

REALITY는 보안 핸드셰이크 방식이며 VLESS의 대체 이름이 아닙니다

REALITY는 VLESS와 함께 제공되는 경우가 많아 여러 클라이언트에서 조합명이 붙어서 표시됩니다. 엄밀히 구분하면 VLESS는 애플리케이션 프로토콜이고 REALITY는 보안 및 핸드셰이크 기능을 담당합니다. REALITY 설정에는 일반적으로 서버 이름, 공개 키, 짧은 식별자, 클라이언트 지문 등의 매개변수가 포함되며 이 값들은 한 세트로 일치해야 합니다. 주소, 포트, UUID만으로는 완전한 연결을 만들 수 없습니다. 구독 변환 과정에서 확장 필드 중 하나라도 빠지면 클라이언트에 VLESS로 표시되더라도 핸드셰이크 단계에서 실패할 수 있습니다.

공개 키는 클라이언트가 검증하고 핸드셰이크에 사용할 중요한 필드이며, 짧은 식별자는 서버 설정과의 일치에 사용되고 서버 이름은 핸드셰이크 의미에 참여합니다. 클라이언트의 “지문” 옵션은 핸드셰이크 표현에 사용할 사전 설정을 나타냅니다. 버전에 따라 “Public Key”, “공개 키”, 약어 등 필드 이름이 조금 다를 수 있지만 역할은 바뀌지 않습니다. 노드를 옮길 때는 화면 위치가 아니라 의미를 기준으로 매핑해야 합니다.

XTLS Vision은 플로우 제어 및 데이터 처리 방식입니다

XTLS Vision은 VLESS + REALITY 조합에 자주 포함됩니다. 새로운 인증 프로토콜이나 서버 주소의 부가 형식이 아니라 플로우 제어 방식입니다. Vision은 특정 상황에서 중복 처리를 줄이고 이미 보안 의미를 가진 데이터를 더 적합한 경로로 처리하는 것을 목표로 합니다. 클라이언트와 서버 모두 이를 지원하고 동일하게 설정해야 합니다. 서버에서 해당 플로우 제어를 활성화하지 않았다면 클라이언트만 Vision을 선택할 경우 연결 이상이 발생할 수 있습니다.

화면에서 흔히 볼 수 있는 값은 xtls-rprx-vision입니다. 선택할 때는 노드 정보를 기준으로 판단하세요. 비워 두는 것과 이 값을 입력하는 것은 임의로 바꿀 수 있는 성능 단계가 아니라 서버 설정의 일부입니다. 일부 구독 형식은 flow 매개변수를 직접 포함하지만, 오래된 변환 과정에서는 이 값이 빠질 수 있습니다. 가져온 뒤 REALITY 공개 키와 짧은 식별자가 모두 있는데도 전송되지 않는다면 서버 이름만 반복해서 바꾸지 말고 flow도 확인하세요.

이러한 조합이 응답 성능이 좋은 경우가 많은 이유

VLESS 프로토콜 구조는 간결하고, REALITY는 일반 TLS 인증서 설정을 직접 준비하는 일부 과정을 줄이며, Vision은 데이터 처리 경로를 최적화합니다. 세 가지를 조합하면 중복 캡슐화가 줄고 적절한 플로우 제어를 사용해 처리 비용이 낮아질 수 있습니다. 그러나 실제 체감 성능은 왕복 지연 시간, 서버 부하, 혼잡, 도메인 조회, 기기 성능의 영향도 받습니다. 프로토콜은 그중 일부만 결정하므로 한 번의 속도 측정으로 일반적인 결론을 내려서는 안 됩니다.

모바일 기기에서는 지속 연결이 안정적이고 반복 계산이 적을 때 장점이 나타나는 경우가 많습니다. 네트워크가 무선 LAN과 모바일 데이터 사이에서 자주 전환되면 어떤 프로토콜이든 연결을 다시 수립해야 합니다. 이때는 프로토콜 차이보다 백그라운드 정책과 네트워크 품질이 배터리에 더 큰 영향을 줄 수 있습니다. 핸드셰이크와 데이터 경로를 더 이해하려면 REALITY와 XTLS Vision 기술 해설을 참고하세요. 실제 설정 전에는 사용하는 클라이언트와 커널이 전체 필드를 지원하는지도 확인해야 하며, v2rayNG은 Xray 관련 확장을 처리하는 데 더 적합합니다.

04 / TROJAN · SS

Trojan과 Shadowsocks: 구조는 간결하지만 선택 기준은 다릅니다

Trojan: 인증과 TLS 조합이 명확합니다

Trojan은 일반적으로 비밀번호를 인증 정보로 사용하며 TLS와 함께 구성됩니다. 이해하기 쉬운 구조로, 클라이언트가 지정한 주소와 포트에 연결해 비밀번호로 프로토콜 인증을 수행하고 TLS가 보안 계층을 제공합니다. 일반적인 노드 정보에는 서버 이름과 인증서 검증 관련 옵션도 포함됩니다. 서버 이름은 서버의 인증서 설정과 일치해야 하며 주소 필드만 보고 추측해서는 안 됩니다.

Trojan의 장점은 매개변수 계층을 이해하기 쉽고 많은 클라이언트가 표준 공유 링크를 안정적으로 해석한다는 점입니다. 그렇다고 “비밀번호와 포트만 있으면 된다”는 뜻은 아닙니다. TLS 핸드셰이크, 서버 이름, 전송 방식도 일치해야 합니다. WebSocket 또는 gRPC를 사용한다면 경로와 서비스 이름 같은 부가 필드도 연결에 참여합니다. 문제를 점검할 때는 TLS 핸드셰이크 단계와 Trojan 인증 단계를 나누어 보세요. 전자는 시스템 시간, 서버 이름, 보안 설정을 확인하고 후자는 비밀번호와 서버 프로토콜 설정을 확인합니다.

Shadowsocks: 간결한 암호화 전달 구조

Shadowsocks는 흔히 SS로 줄여 부릅니다. 핵심 매개변수는 보통 서버 주소, 포트, 암호화 방식, 비밀번호이며 VMess나 여러 확장 계층을 포함한 VLESS 조합보다 구조가 짧습니다. 간결한 설정은 수동 입력과 클라이언트 간 전달에 유리합니다. 다만 암호화 방식은 클라이언트와 서버가 함께 지원해야 하며 이름도 정확히 일치해야 합니다. 비슷해 보이는 방식을 임의로 바꾼다고 자동으로 사용 가능한 값으로 협상되지는 않습니다.

커널마다 Shadowsocks 암호화 방식의 지원 범위가 다를 수 있습니다. 최신 방식은 그에 맞는 커널 기능이 필요하며, 구형 클라이언트는 ss:// 링크를 읽더라도 연결 단계에서 지원되지 않는다고 표시할 수 있습니다. 이런 경우 먼저 클라이언트 커널을 확인하고 비밀번호를 바꾸지 마세요. v2rayN은 데스크톱에서 여러 프로토콜을 통합 관리하는 데 적합하고, v2rayNG과 v2flyNG은 각각 사용하는 커널의 지원 범위에 영향을 받습니다. 클라이언트를 선택할 때 실제 암호화 방식도 호환성 점검 대상에 포함해야 합니다.

{
  "protocol": "shadowsocks",
  "settings": {
    "servers": [{
      "address": "example.com",
      "port": 8388,
      "method": "aes-128-gcm",
      "password": "your-password"
    }]
  }
}

이 예시는 표준 아웃바운드 필드의 관계를 보여 줍니다. 주소, 포트, 방식, 비밀번호는 서버가 제공한 실제 값으로 바꿔야 합니다. 암호화 방식은 로컬에서 선호하는 옵션이 아니므로 리소스 사용량을 줄이기 위해 일방적으로 변경할 수 없습니다. 가져온 뒤 방식이 비어 있다면 공유 링크 또는 구독 변환 결과를 다시 확인하세요.

두 프로토콜의 성능 차이는 필드 수만으로 판단할 수 없습니다

Shadowsocks의 매개변수가 적다고 해서 모든 네트워크 환경에서 Trojan보다 빠른 것은 아닙니다. Trojan은 일반적으로 TLS 핸드셰이크 비용을 부담하지만, 장시간 연결이 수립되면 이후의 지속적인 전송 과정에서 그 비용이 분산됩니다. Shadowsocks의 실제 비용은 선택한 암호화 방식, 기기 하드웨어 가속, 패킷 크기, 커널 구현에 따라 달라집니다. 짧은 연결이 많을 때는 연결 재사용과 클라이언트 동작이 체감 성능을 좌우할 수 있고, 지속 다운로드에서는 서버 대역폭과 경로 품질이 더 중요할 때가 많습니다.

모바일 기기에서는 지속적인 암호화 계산과 잦은 재연결이 배터리에 영향을 줍니다. 최신 프로세서는 일반적인 암호화 연산을 잘 지원하므로 알고리즘 이름만 보고 배터리 소모를 정확히 예측하기 어렵습니다. 같은 네트워크, 같은 서버 지역, 비슷한 부하를 유지하면서 일정 시간 동안 연결 안정성, 깨우기 횟수, 클라이언트 백그라운드 상태를 기록하는 방식이 더 유용합니다. 몇 초간의 한 번의 속도 측정만으로 장기적인 배터리 성능을 판단할 수는 없습니다.

적용 범위와 선택 방법

노드 정보가 표준 Trojan 매개변수만 제공하고 클라이언트가 TLS 관련 필드를 정확히 인식한다면 Trojan을 유지하는 것이 가장 안전합니다. Shadowsocks 노드라면 암호화 방식이 현재 커널에서 지원되는지 우선 확인하세요. 두 프로토콜 모두 다른 노드와 “유형을 통일”하려고 변환할 필요는 없습니다. 구독에 여러 프로토콜이 함께 포함되어 있다면 유형별로 유지하고 클라이언트에서 노드 단위로 관리하면 됩니다. 시스템 프록시와 라우팅 규칙이 모든 아웃바운드에 같은 프로토콜을 요구하는 것은 아닙니다.

관리 측면에서 매개변수가 적으면 수동 확인이 쉽지만 이후 업데이트를 생략해도 된다는 뜻은 아닙니다. 서버 주소, 비밀번호, 인증서 이름, 암호화 방식이 바뀌면 기존 노드는 작동하지 않습니다. 구독을 사용한다면 클라이언트의 구독 업데이트 기능으로 변경 사항을 반영하고, 여러 수동 복사본을 장기간 관리하지 않도록 하세요. 데스크톱과 Android의 구독 메뉴는 V2Ray 구독 링크 가져오기 방법에서 확인할 수 있습니다.

05 / PERFORMANCE

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

“빠르다”를 네 가지 관찰 가능한 단계로 나누기

프로토콜 비교에서 말하는 “속도”에는 최소 네 가지 지표가 포함됩니다. 첫째는 클라이언트가 연결을 시작한 뒤 핸드셰이크를 완료할 때까지의 연결 수립 시간입니다. 둘째는 요청을 보낸 후 첫 유효 데이터가 도착할 때까지의 첫 패킷 시간입니다. 셋째는 장시간 전송에서 안정적인 속도를 보여 주는 지속 처리량입니다. 넷째는 웹페이지 연속 로딩, 오디오·비디오 재생, 백그라운드 작업의 안정성을 좌우하는 지터와 재연결입니다. 어떤 조합이 연결 수립은 조금 느려도 지속 처리량이 반드시 낮은 것은 아니며, 첫 연결이 빠르다고 약한 네트워크에서 더 안정적인 것도 아닙니다.

비교할 때는 서버, 네트워크, 대상 주소, 라우팅 규칙, 테스트 시간을 고정해야 합니다. 두 노드가 서로 다른 지역에 있다면 차이는 프로토콜이 아니라 네트워크 경로를 주로 반영합니다. 도메인 조회와 최초 연결 캐시의 영향을 줄이기 위해 한 번 예열한 뒤 측정하는 것도 좋습니다. 클라이언트의 일반적인 “지연 시간 테스트”는 TCP 연결 수립이나 특정 탐색 주소만 측정할 수 있어 실제 프로토콜 핸드셰이크를 완료하지 않을 수 있습니다. 노드가 작동하는지 판단하려면 실제 연결 테스트를 수행하고 연결 후 실제 대상에 접속해 확인해야 합니다.

프로토콜 처리가 항상 유일한 병목은 아닙니다

VMess에는 자체 인증 및 데이터 처리 과정이 있고, VLESS는 보안 기능을 외부 계층에 더 많이 맡기며, Trojan은 TLS와 함께 사용되는 경우가 많고, Shadowsocks의 비용은 암호화 방식과 관련됩니다. VLESS + REALITY + Vision에는 핸드셰이크와 플로우 제어의 협력이 추가됩니다. 이론적인 처리 단계는 차이를 설명하는 데 도움이 되지만 일반적인 클라이언트 사용에서는 네트워크 왕복, 서버 처리 능력, 패킷 손실, 혼잡이 더 큰 비중을 차지하는 경우가 많습니다. 서버와 경로 조건이 비슷할 때에만 프로토콜 계층의 차이를 더 쉽게 관찰할 수 있습니다.

전송 방식도 결과를 바꿉니다. TCP 조합은 일반적으로 경로가 직접적이고, WebSocket은 프레임 캡슐화를 추가하며, gRPC는 HTTP/2 의미 체계를 기반으로 다중화를 활용할 수 있습니다. 다중화는 연결이 많을수록 좋은 것이 아니며, 지나치게 묶으면 하나의 하위 연결에서 발생한 지터가 여러 요청에 영향을 줄 수 있습니다. 클라이언트의 동시성, 연결 재사용, mux 옵션은 보수적으로 조정하고 한 번에 하나만 변경하면서 기본값을 비교 기준으로 남겨 두세요.

메모리, 프로세서, 백그라운드 깨우기

리소스 사용량은 클라이언트 화면, 커널, 규칙 집합, 연결 수, 로그 수준이 함께 결정합니다. 프로토콜은 그중 일부일 뿐입니다. 큰 라우팅 규칙, 계속 기록되는 상세 로그, 많은 동시 연결은 단일 프로토콜 필드보다 메모리와 프로세서 사용량을 더 크게 늘리는 경우가 많습니다. 데스크톱의 v2rayN은 시스템 프록시, 트레이 상태, 설정 목록도 관리해야 하며 Android 클라이언트는 시스템 네트워크 인터페이스로 트래픽을 넘겨받고 백그라운드 정책의 영향을 받습니다. 리소스를 비교할 때는 두 테스트가 같은 규칙과 로그 수준을 사용하는지 확인해야 합니다.

로그 수준은 장기간 관찰을 방해하기 쉽습니다. 문제를 해결할 때 상세 로그는 유용하지만 점검이 끝나면 일반 수준으로 되돌려 지속적인 기록과 포맷팅 비용을 줄일 수 있습니다. 노드가 많아도 일반적으로 프로세서를 계속 많이 사용하지는 않지만, 전체 테스트를 자주 실행하면 많은 연결이 동시에 만들어집니다. 모바일 기기에서는 자동 테스트 간격을 지나치게 짧게 설정하지 마세요. 필요할 때 현재 후보 노드만 테스트하는 편이 결과를 해석하기 쉽습니다.

모바일 배터리는 안정성과 재연결 빈도가 함께 좌우합니다

모바일 기기의 배터리 소모를 VMess, VLESS, Trojan 순서로 단순하게 나눌 수는 없습니다. 무선 모듈 깨우기, 화면 사용, 신호 세기, 백그라운드 유지, 연결 수, 재시도 정책이 모두 결과에 영향을 줍니다. 이론상 처리가 가벼워도 수십 초마다 연결이 끊겼다 다시 연결되는 노드는 안정적으로 장시간 연결을 유지하는 노드보다 배터리를 더 많이 사용할 수 있습니다. 먼저 안정적인 경로를 선택한 뒤 프로토콜 처리 차이를 비교해야 합니다.

v2rayNG 또는 v2flyNG에서 노드를 비교할 때는 같은 라우팅 모드와 앱 범위를 유지하고 불필요한 연속 속도 측정을 끈 뒤 정상 사용 시간 동안 시스템 배터리 통계를 관찰하세요. 테스트 중에는 네트워크를 자주 전환하거나 대규모 시스템 업데이트를 동시에 진행하지 않는 것이 좋습니다. 기기가 절전 모드에 들어간 뒤 연결이 계속 시스템에 의해 종료된다면 클라이언트의 백그라운드 실행 설정을 확인하세요. 이는 기기 스케줄링 문제이므로 프로토콜을 바꿔도 해결되지 않을 수 있습니다.

06 / CORES

V2Fly와 Xray: 커널 계열, 기능 범위, 설정 호환성

클라이언트 화면과 프록시 커널은 서로 다른 구성 요소입니다

v2rayN, v2rayNG, v2flyNG은 모두 그래픽 인터페이스를 제공하지만 실제 프로토콜 해석, 연결 수립, 라우팅 처리는 일반적으로 커널이 담당합니다. 화면은 구독 관리, 노드 편집, 시스템 프록시, 로그 표시, 시작 제어를 담당하고 커널은 설정을 읽어 네트워크 로직을 실행합니다. 이 구분을 이해하면 많은 호환성 문제를 더 쉽게 찾을 수 있습니다. 화면에 특정 필드가 표시된다는 것은 데이터가 저장되었다는 뜻일 뿐이며, 커널이 실행할 수 있는지는 해당 기능의 지원 여부에 달려 있습니다.

v2rayN은 Windows, macOS, Linux에 적합한 데스크톱용 기본 선택지로 여러 노드와 라우팅 설정을 관리할 수 있습니다. v2rayNG은 Android에서 널리 사용하는 클라이언트로 주로 Xray 커널 기능을 활용합니다. v2flyNG도 Android용이지만 V2Fly 커널을 사용하는 경로를 따르므로 해당 커널의 호환 범위가 필요할 때 선택할 수 있습니다. 세 클라이언트의 설치 메뉴는 다운로드 센터에 모아 두었으니 기기 플랫폼과 노드 유형에 따라 선택하세요. 이름이 비슷하다는 이유만으로 판단해서는 안 됩니다.

V2Fly는 Project V 설정 체계를 계승합니다

V2Fly는 V2Ray 관련 핵심 기능을 유지하며 inbounds, outbounds, routing, dns 등의 계층 구조를 이어 갑니다. VMess, Shadowsocks, Trojan과 해당 전송 기능을 지원 범위 안에서 구성할 수 있습니다. 기존 V2Fly 설정에 의존하거나 같은 커널 체계를 유지하려는 사용자에게 v2flyNG은 Android에서 바로 사용할 수 있는 그래픽 인터페이스를 제공합니다.

“설정 구조가 비슷하다”는 것이 모든 확장 필드가 완전히 통용된다는 뜻은 아닙니다. 일부 필드는 특정 커널에만 존재할 수 있고, 이름이 같아도 지원 값의 범위가 다를 수 있습니다. 한 커널의 전체 JSON을 다른 커널로 복사하기 전 프로토콜과 전송 지원을 확인한 뒤 라우팅 규칙과 DNS 구조를 점검하세요. 기본 아웃바운드는 비교적 쉽게 옮길 수 있지만 실험적 기능, 전용 플로우 제어, 확장 전송이 포함되면 항목별 검증이 필요합니다.

Xray는 VLESS, REALITY, Vision 등의 기능을 확장합니다

Xray는 V2Ray 설정 체계와 구조적으로 깊은 연관이 있어 많은 기본 설정이 비슷해 보입니다. Xray는 VLESS, XTLS Vision, REALITY 등의 기능을 제공하므로 이러한 노드는 대체로 v2rayNG 또는 데스크톱의 해당 커널 환경에서 사용하는 편이 적합합니다. 노드 정보에 REALITY 공개 키, 짧은 식별자, Vision 플로우 제어가 명시되어 있다면 화면에 VLESS 유형이 있다는 것만 확인하지 말고 현재 클라이언트가 실제로 호출하는 커널이 이를 지원하는지 먼저 확인하세요.

커널 선택은 공유 링크를 해석한 뒤 어떤 필드가 보존되는지에도 영향을 줍니다. 클라이언트가 가져오기 단계에서 URI 매개변수를 인식하더라도 커널을 시작할 때 설정 변환이나 검사가 다시 수행될 수 있습니다. 로그에 알 수 없는 필드, 잘못된 값, 지원되지 않는 플로우 제어가 표시된다면 문제는 주소 접근성보다 기능 범위에 있을 가능성이 큽니다. 이때는 노드 유형과 커널의 호환 관계를 다시 확인해야 하며, 설정을 억지로 통과시키려고 무작위로 필드를 삭제해서는 안 됩니다. 삭제한 필드가 연결에 필수일 수 있기 때문입니다.

일반적으로 쉽게 호환되는 설정과 주의가 필요한 설정

주소, 포트, 기본 사용자 식별자, 표준 VMess 필드, 일부 일반 전송 방식, 기본 라우팅 규칙은 유사한 설정 체계 사이에서 비교적 쉽게 매핑됩니다. DNS와 routing의 기본 계층에도 공통 개념이 있습니다. 하지만 REALITY, XTLS Vision, 특정 전송 확장, 프로토콜 전용 설정, 각 커널에서 새로 추가된 필드는 별도로 확인해야 합니다. 클라이언트가 생성한 전체 설정에는 로컬 수신 포트, 로그 경로, 플랫폼별 설정이 포함될 수 있으므로 다른 기기에 그대로 복사하기에 적합하지 않습니다.

더 안전한 마이그레이션 방법은 노드 공유 정보를 입력으로 사용해 대상 클라이언트가 자체 로컬 설정을 생성하도록 하는 것입니다. 이렇게 하면 원본 클라이언트의 로컬 포트, 캐시 경로, 플랫폼 옵션이 함께 옮겨지는 것을 막을 수 있습니다. 이후 라우팅 규칙을 옮기고 항목별로 검증하세요. JSON을 직접 처리해야 한다면 최소 아웃바운드와 필수 전송 필드만 먼저 남겨 연결을 확인한 뒤 DNS, 라우팅, 고급 옵션을 추가하세요. 계층을 하나 추가할 때마다 테스트하면 오류가 발생한 최근 변경을 찾을 수 있습니다.

v2ray test -c config.json
xray run -test -c config.json

위 명령은 해당 커널 실행 파일이 올바르게 설치되어 현재 명령 환경에서 실행될 수 있을 때 설정 문법을 확인하는 용도입니다. 명령 테스트를 통과했다는 것은 설정을 해석할 수 있다는 뜻일 뿐 서버에 반드시 접근할 수 있다는 의미는 아닙니다. 그래픽 클라이언트 사용자는 클라이언트를 나가지 않고 시작 로그를 바로 확인할 수 있습니다.

07 / SUBSCRIPTION

구독, 공유 링크, 클라이언트 호환성: 도구 간 필드 전달 방식

구독 링크는 설정 모음에 접근하는 수단이지 프로토콜 자체가 아닙니다

구독 링크는 보통 여러 노드 데이터를 반환하며, 클라이언트는 이를 가져온 뒤 로컬 설정으로 해석합니다. VMess, VLESS, Trojan, Shadowsocks 등 여러 유형이 포함될 수 있고 Base64로 인코딩된 여러 줄의 공유 링크를 반환할 수도 있습니다. 구독 주소만으로 내부 노드의 프로토콜을 알 수는 없으며 업데이트와 해석을 거쳐야 구체적인 유형을 확인할 수 있습니다. 구독 주소를 단일 노드 편집창에 직접 붙여 넣으면 일반적으로 올바르게 처리되지 않습니다.

v2rayN에서는 구독 그룹 또는 구독 관리 메뉴에 주소를 저장한 뒤 구독 업데이트를 실행해야 합니다. v2rayNG과 v2flyNG에도 해당 구독 설정 및 업데이트 기능이 있습니다. 업데이트 후 먼저 노드 수와 유형을 확인하고 노드를 선택해 테스트하세요. 목록이 비어 있다면 주소가 완전한지, 네트워크 요청이 성공했는지, 반환 형식이 클라이언트에서 지원되는지 확인해야 합니다. 전체 과정은 v2rayN·v2rayNG 구독 가져오기 안내에서 확인할 수 있습니다.

일반적인 URI 형식에 포함되는 정보

vmess://의 일반적인 형식은 JSON 정보를 인코딩해 링크에 넣으며, 주소, 포트, UUID, 전송 방식, Host, 경로, TLS 등의 필드를 포함할 수 있습니다. 생성 도구마다 필드 이름이 조금씩 달랐던 시기가 있으므로 오래된 링크를 새 클라이언트에서 해석한 결과는 직접 확인해야 합니다. vless://, trojan://, 일부 ss:// 링크는 표준 URI에 더 가깝습니다. 인증 정보는 사용자 정보 부분에, 주소와 포트는 호스트 부분에, 나머지 매개변수는 쿼리 문자열에 들어갑니다.

URI의 매개변수 이름에는 명확한 의미가 있습니다. 예를 들어 security는 TLS 또는 REALITY를 나타낼 수 있고, type은 전송 방식을, flow는 플로우 제어를 나타냅니다. sni 또는 동의어 매개변수는 서버 이름을 의미하며 pbk와 sid는 REALITY 공개 키와 짧은 식별자에 자주 사용됩니다. 클라이언트는 이러한 매개변수를 인식해 커널 설정에 올바르게 매핑해야 합니다. 공유 링크가 길다고 해서 정보가 완전한 것은 아닙니다. 생성 도구가 필요한 필드를 기록하지 않았다면 아무리 긴 링크라도 누락된 내용을 복원할 수 없습니다.

Base64는 표현 방식일 뿐 특정 프로토콜을 뜻하지 않습니다

많은 구독은 여러 줄의 공유 링크 전체를 Base64로 인코딩해 하나의 텍스트로 전송합니다. 디코딩한 결과는 여러 vmess://, vless://, trojan://, ss:// 항목입니다. Base64는 노드 정보를 암호화하지 않으며 클라이언트 호환성을 결정하지도 않습니다. 호환성은 디코딩된 프로토콜 링크, 확장 매개변수, 대상 클라이언트의 해석 능력에 따라 결정됩니다.

한 클라이언트에서는 가져와지지만 다른 클라이언트에서는 비어 있다면 먼저 구독이 만료되었다고 판단하지 마세요. 대상 클라이언트가 구독 반환 유형을 지원하는지, 포함된 프로토콜을 인식하는지, 링크의 확장 매개변수를 지원하는지 순서대로 확인할 수 있습니다. v2flyNG과 v2rayNG은 서로 다른 커널 경로를 사용하므로 REALITY 또는 Vision 노드에서는 차이에 특히 주의해야 합니다. 구독에 여러 노드 유형이 함께 있다면 일부만 성공하고 일부가 실패하는 현상은 전체 구독 요청보다 프로토콜 또는 매개변수 지원 범위의 차이를 의미하는 경우가 많습니다.

업데이트, 중복 제거, 로컬 수정의 범위

구독을 업데이트하면 구독으로 관리되는 노드가 덮어써질 수 있습니다. 클라이언트에서 구독 노드를 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 장기간 보관할 로컬 실험 설정은 독립 노드로 복사해 이름을 바꾸고 구독 항목과 혼동하지 않도록 하세요. 노드 이름이 같다고 반드시 중복은 아니므로 주소, 포트, 프로토콜, 인증 필드, 전송, 보안 매개변수를 비교한 뒤 삭제 여부를 결정해야 합니다.

구독 업데이트 후 갑자기 연결되지 않는다면 먼저 노드 매개변수가 바뀌었는지 확인한 뒤 로컬 프록시 설정을 판단하세요. 서버가 주소, 포트, 보안 필드를 변경했거나 클라이언트의 해석 규칙 변화로 표시 방식이 달라졌을 수 있습니다. 업데이트 전 독립적인 비교용 설정을 하나 보관하면 변경이 어느 계층에서 발생했는지 파악하는 데 도움이 됩니다. 모든 구독 노드가 동시에 시간 초과된다면 노드 시간 초과 문제 해결 순서에 따라 시스템 시간, 로컬 포트, 노드 매개변수, 구독 상태를 점검하세요.

08 / DECISION

사용 상황에 맞는 프로토콜 선택과 안전한 마이그레이션

이미 안정적인 노드가 있다면: 이름보다 호환성을 우선하세요

현재 사용 중인 VMess, Trojan, Shadowsocks 노드가 안정적으로 작동하고 구독 업데이트도 정상이며 클라이언트가 매개변수를 완전히 인식한다면 새로운 프로토콜 이름이 보인다는 이유만으로 즉시 마이그레이션할 필요는 없습니다. 프로토콜 선택은 먼저 서버 기능의 제약을 받고, 그다음 로컬 선호를 반영합니다. 안정적인 연결에는 검증된 서버 설정, 네트워크 경로, 클라이언트 조합이 포함되어 있어 이론적인 비교보다 가치가 큽니다.

클라이언트를 바꿔야 한다면 데스크톱에서는 v2rayN을 우선 선택하세요. Android에서는 Xray 확장을 포함한 설정에 v2rayNG을, V2Fly 커널이 필요한 경우 v2flyNG을 고려할 수 있습니다. 마이그레이션 전 기존 클라이언트의 프로토콜, 전송, 보안, 서버 이름, 경로, 플로우 제어, 인증 필드를 기록하세요. 공유 링크 또는 구독으로 가져온 뒤 항목별로 대조해야 합니다. 이름과 주소만 일치해서는 충분하지 않으며 확장 필드가 빠지면 핸드셰이크 단계에서 노드가 실패할 수 있습니다.

새 설정 만들기: 먼저 커널을 정한 뒤 조합을 선택하세요

새 노드를 만들 때는 대상 기기와 클라이언트에서 필요한 커널 기능을 먼저 역산할 수 있습니다. 데스크톱과 Android에서 모두 사용하고 설정에 REALITY와 Vision이 포함된다면 양쪽 모두 적합한 Xray 실행 환경을 제공하는지 확인한 후 VLESS + REALITY + Vision 조합을 선택하세요. 대상 환경에서 V2Fly 설정의 일관성을 중시한다면 V2Fly 지원 범위 안에서 프로토콜과 전송 방식을 선택해야 합니다. 커널을 먼저 정하면 서버 배포가 끝난 뒤 한쪽에서 핵심 필드를 해석하지 못하는 상황을 피할 수 있습니다.

매개변수가 간결하고 수동 입력이 쉬워야 하며 서버와 클라이언트가 같은 암호화 방식을 지원한다면 Shadowsocks를 명확한 선택지로 고려할 수 있습니다. 표준 TLS 설정 체계를 이미 사용하고 비밀번호 인증과 명확한 TLS 계층을 원한다면 Trojan은 이해하고 관리하기 쉽습니다. VMess는 기존 설정과 오래된 구독의 호환을 계속 유지하는 데 적합합니다. 어떤 조합도 환경과 무관한 절대 순위는 없으므로 호환성, 관리, 안정성, 리소스 네 가지를 하나의 점검표에서 함께 판단해야 합니다.

불안정한 네트워크와 모바일 기기: 재연결을 우선 줄이세요

네트워크 변동이 클 때는 이론적으로 캡슐화가 가장 적은 방식을 추구하기보다 안정적인 서버와 적절한 전송 방식을 선택하는 것이 중요합니다. 로그에서 연결 재설정, 핸드셰이크 시간 초과, 반복적인 도메인 조회를 확인하세요. 특정 노드가 자주 끊긴다면 무선 신호, 서버 부하, 전송 설정, 프로토콜 매개변수 중 무엇이 원인인지 먼저 판단해야 합니다. 프로토콜을 바로 바꾸면 서버와 경로도 함께 바뀔 수 있어 비교 기준을 잃게 됩니다.

Android 기기에서는 지속적인 일괄 속도 측정과 지나치게 잦은 구독 업데이트를 줄이고, 라우팅 규칙 규모를 적절히 유지하며 시스템이 클라이언트를 필요할 때 백그라운드에서 실행하도록 허용하세요. VLESS + REALITY + Vision은 완전한 지원과 올바른 매개변수 조합을 전제로 좋은 처리 경로를 제공할 수 있습니다. 하지만 안정적인 Trojan 또는 Shadowsocks 노드가 실제 기기에서 더 나은 결과를 낼 수도 있습니다. 전체 사용 주기의 안정성, 배터리, 실제 연결 결과를 기준으로 판단해야 합니다.

여러 기기 동기화: 구독은 출처로, 클라이언트 설정은 로컬 계층으로 사용하세요

데스크톱과 Android를 함께 사용할 때는 노드 구독을 공유 출처로 두고 시스템 프록시, 앱 범위, 라우팅 모드, 로컬 수신 포트는 각 기기에서 관리하는 것이 좋습니다. 플랫폼별 필드가 포함되므로 전체 클라이언트 설정 파일을 그대로 복사하지 마세요. 구독을 업데이트한 뒤 양쪽에서 노드 유형과 확장 매개변수를 각각 확인해야 합니다. 한쪽에만 특정 유형이 표시된다면 구독 내용을 바로 삭제하지 말고 해당 기기의 해석 및 커널 지원을 점검하세요.

라우팅 규칙도 프로토콜 선택과 혼동해서는 안 됩니다. 같은 VLESS 또는 VMess 아웃바운드를 서로 다른 규칙에서 참조할 수 있으며 라우팅 모드를 바꿔도 노드 프로토콜은 바뀌지 않습니다. “일부 웹사이트는 열리지만 일부는 열리지 않는” 문제라면 먼저 요청이 예상한 라우팅 규칙에 적용되었는지 확인한 뒤 노드를 점검하세요. 모든 요청이 실패할 때 프로토콜과 연결 매개변수로 돌아가면 됩니다. 두 계층을 구분하면 불필요한 수정을 줄일 수 있습니다.

마이그레이션 절차: 추가, 대조, 검증, 정리

안전한 마이그레이션은 네 단계로 나눌 수 있습니다. 첫째, 기존 노드를 보존하고 대상 프로토콜 설정을 추가해 현재 사용 가능한 항목을 덮어쓰지 않습니다. 둘째, 주소, 포트, 인증, 전송, 보안, 플로우 제어를 하나씩 대조해 서버에서도 동일하게 지원하는지 확인합니다. 셋째, 실제 연결 테스트를 실행하고 로그를 확인한 뒤 실제 대상에 접속해 연결 수립과 시스템 프록시 작동을 각각 검증합니다. 넷째, 일정 기간 안정적으로 사용한 후 더 이상 필요 없는 기존 설정을 삭제합니다.

새 설정이 실패하면 가장 최근의 사용 가능한 상태로 되돌린 뒤 계층별로 점검하세요. 인증 오류는 UUID 또는 비밀번호를 확인하고, 핸드셰이크 오류는 시스템 시간, 서버 이름, 공개 키, 짧은 식별자를 확인합니다. 시간 초과는 주소, 포트, 전송 방식을 확인하고 시작 단계에서 알 수 없는 필드가 표시되면 커널 호환성을 점검하세요. 프로토콜, 전송, 라우팅, DNS를 동시에 바꾸지 마세요. 그러면 로그만으로 원인을 찾기 어렵습니다. 첫 연결 검증의 자세한 과정은 v2rayNG 첫 연결 전체 과정을 참고하세요.