V2Ray 프로토콜 가이드: 프로토콜, 전송 방식 및 코어 선택

1. 프로토콜·전송·보안 계층·코어를 구분해서 이해하기

클라이언트의 ‘프로토콜’은 하나의 단일 옵션이 아닙니다

v2rayN, v2rayNG 또는 v2flyNG의 서버 편집 화면에서 하나의 연결은 보통 프로토콜 유형, 주소, 포트, 사용자 인증 정보, 전송 방식, 보안 계층, 라우팅 출구를 함께 포함합니다. 프로토콜 유형은 클라이언트가 서버와 인증하고 데이터 프레임을 구성하는 방식을 결정합니다. 전송 방식은 TCP, WebSocket, gRPC 중 어떤 운반 수단으로 프레임을 보낼지 정합니다. TLS 또는 REALITY 같은 보안 계층은 핸드셰이크, 서버 신원 확인, 연결 암호화를 담당하며, 코어는 이 필드들을 실행 가능한 설정으로 조합합니다. 개념을 혼동하면 ‘특정 프로토콜이 반드시 더 빠르다’거나 ‘유형만 바꾸면 연결된다’는 잘못된 결론에 이르기 쉽습니다.

예를 들어 VLESS는 일반 TCP, WebSocket 또는 gRPC에서 동작할 수 있고 TLS, REALITY와도 조합할 수 있습니다. VLESS로 표시된 두 노드라도 전송 계층, 혼잡 상태, 인증서 핸드셰이크, 서버 구현이 다르면 실제 성능은 완전히 달라질 수 있습니다. REALITY는 VLESS와 같은 계층의 프록시 프로토콜이 아니라 Xray가 구현하는 전송 보안 방식에 가깝습니다. 흔한 조합은 VLESS, TCP, REALITY, XTLS Vision입니다. 서버를 선택할 때는 공유 링크 앞부분의 vless://만 보지 말고 전체 조합을 하나의 단위로 판단해야 합니다.

선택 전에 네 가지 제약을 먼저 확인하세요

첫째는 서버에 어떤 설정이 제공되는지입니다. 클라이언트만으로 VMess를 VLESS로 바꿀 수 없으며, 서버에 REALITY가 설정되어 있지 않다면 클라이언트에서 REALITY를 선택해도 동작하지 않습니다. 둘째는 코어가 해당 필드를 인식하는지입니다. v2rayNG는 Xray 코어를 주요 실행 환경으로 사용하고, v2flyNG는 V2Fly 코어를 대상으로 합니다. v2rayN은 데스크톱 그래픽 클라이언트이며, 일반적인 설정은 Xray 코어로 실행됩니다. 기본 VMess, VLESS, Trojan, Shadowsocks 필드는 생태계 전반에서 폭넓게 지원되지만 XTLS Vision, REALITY 같은 확장 기능은 이를 지원하는 코어와 일치해야 합니다.

셋째는 설정의 출처입니다. 구독 링크에는 프로토콜, 주소, 포트, 전송 매개변수가 함께 포함되므로 보통 전체를 가져와야 하며, 주소와 포트만 복사해 다시 입력해서는 안 됩니다. 넷째는 사용 환경입니다. 데스크톱은 TUN, 복잡한 라우팅, 다중 프로세스 연결을 처리하기 쉽고, 모바일은 상시 실행 시 배터리 소모, 네트워크 전환 후 재연결, 백그라운드 상태를 더 중요하게 봅니다. 같은 프로토콜이라도 플랫폼별 체감 차이는 프로토콜 이름보다 시스템 네트워크 스택, TUN 구현, 연결 유지 정책에서 발생하는 경우가 많습니다.

하나의 라벨로 전체 판단을 대신하지 마세요

프로토콜 선택 순서는 서버 조합과 클라이언트 코어의 호환 여부를 먼저 확인하고, 공유 링크 또는 구독이 완전한지 점검한 뒤 성능과 리소스 사용량을 비교하는 것이 좋습니다. 연결은 되지만 웹페이지에 접속할 수 없다면 시스템 프록시, TUN, DNS, 라우팅 분할을 계속 확인하세요. 설정을 가져오는 단계에서 필드가 이미 누락됐다면 시스템 프록시를 반복해서 바꾸기보다 먼저 구독 형식을 해결해야 합니다. v2rayN 데스크톱 설치 패키지와 v2rayNG·v2flyNG Android 설치 패키지는 설치 패키지 페이지에서 플랫폼에 맞게 선택할 수 있으며, 설치 후 기본 사용법은 시작 가이드에서 이어서 안내합니다.

2. VMess: 완전한 세션 프로토콜과 호환성 기준

탄생 배경과 설계 핵심

VMess는 Project V 생태계 초기에 형성된 핵심 프로토콜 중 하나입니다. 사용자 신원, 시간 정보, 요청 대상, 데이터 전송을 자체 프로토콜 구조에 포함하며 서버는 사용자 ID로 연결을 식별합니다. 초기 설정에는 alterId가 자주 등장했으며 추가 인증 메커니즘에 사용되었습니다. 현대 구현은 대부분 AEAD 방식을 사용하므로 일반적인 설정에서 alterId는 보통 0입니다. 오래된 구독을 가져왔을 때 클라이언트에 큰 alterId 값이 표시되더라도 새 서버에 그대로 적용하지 말고 실제 서버 설정을 기준으로 판단해야 합니다.

VMess의 장점은 특정 성능 항목이 압도적이라는 데 있지 않습니다. 오랜 생태계 축적, 성숙한 필드 정의, 폭넓은 클라이언트·구독 변환 도구 지원이 강점입니다. 안정적으로 작동하는 VMess 설정이라면 새 프로토콜 이름이 등장했다는 이유만으로 즉시 이전할 필요는 없습니다. 특히 TCP, WebSocket, TLS 같은 일반적인 기능 조합만 사용하는 경우 V2Fly와 Xray 모두 기본 설정을 처리할 수 있어, 클라이언트 간 이전 시 호환성 기준으로 여전히 유용합니다.

인증·시간·암호화 필드

VMess 요청에는 시간과 관련된 인증 정보가 포함됩니다. 따라서 클라이언트와 서버의 시스템 시간이 크게 다르면 주소, 포트, 사용자 ID가 모두 정확해도 인증에 실패할 수 있습니다. 문제를 확인할 때는 먼저 기기에서 자동 시간 설정과 올바른 시간대가 활성화되어 있는지 확인한 다음 서버 시계를 점검하세요. 여기서 중요한 것은 네트워크 지연이 아니라 시스템 시간 오차입니다. 같은 링크를 반복해서 가져오거나 전체 프록시를 전환하거나 클라이언트를 다시 설치해도 뚜렷한 시계 오차는 해결되지 않습니다.

클라이언트 화면에서는 VMess 보안 옵션이 auto, aes-128-gcm, chacha20-poly1305, none으로 표시되는 경우가 많습니다. 이 필드들은 VMess 데이터 계층의 처리 방식을 설명할 뿐 외부 TLS를 대신하지 않습니다. auto를 선택하면 코어가 구현과 기기 성능에 따라 적절한 방식을 정합니다. 알고리즘을 수동으로 고정하는 것은 서버가 명시적으로 요구하거나 호환성 문제를 진단할 때만 의미가 있습니다. 외부 TLS를 활성화한 뒤에도 서버 이름, 인증서의 도메인, 전송 경로는 각각 일치해야 합니다.

VMess에서 자주 발생하는 설정 오류

첫 번째 오류는 사용자 ID를 일반 비밀번호처럼 수정하는 것입니다. VMess ID는 보통 UUID 형식이며, 문자가 빠지거나 앞뒤에 공백이 붙거나 잘못된 사용자 항목에 입력되면 인증에 실패합니다. 두 번째는 WebSocket 경로와 Host를 혼동하는 것입니다. 경로는 HTTP 요청 경로이고 Host는 요청 헤더 또는 TLS 서버 이름과 관련된 필드입니다. 둘은 같을 수도 다를 수도 있으므로 원본 설정에 따라 입력해야 합니다. 세 번째는 공유 링크의 주요 필드만 남기고 전송 계층 매개변수를 누락하는 것입니다. 클라이언트가 vmess:// 링크를 인식한다고 해서 현재 변환 도구가 모든 필드를 올바르게 해석했다는 뜻은 아닙니다.

네 번째 오류는 TLS 스위치에서 발생합니다. 서버가 TLS를 요구하는데 클라이언트에서 TLS를 끄면 올바른 핸드셰이크를 완료하기 어렵습니다. 반대로 서버에 TLS가 설정되지 않았는데 클라이언트에서 켜도 안전한 연결이 자동으로 만들어지지는 않습니다. 다섯 번째는 코어를 업그레이드한 뒤 오래된 필드를 계속 사용하는 경우입니다. 코어는 폐기된 필드에 경고를 표시하거나 설정 로드를 거부할 수 있으며, 그래픽 클라이언트에는 ‘시작 실패’만 표시되기도 합니다. 이때는 트레이 상태만 보지 말고 outbound, streamSettings, security 같은 로그의 필드 경로를 확인해야 합니다.

유지할 때와 이전할 때

기존 VMess 연결이 안정적이고 서버 관리가 명확하며 구독 업데이트가 정상이라면 목적 없이 이전하기보다 그대로 유지하는 편이 수월합니다. 이전을 고려할 신호는 서버 설정 변경, 코어 기능 요구, 구독 제공자의 명시적인 프로토콜 전환입니다. REALITY 또는 XTLS Vision을 사용하려면 새로운 VLESS 설정 전체를 가져와야 하며, VMess 노드의 주소와 ID를 복사한 뒤 프로토콜 드롭다운만 바꿔서는 안 됩니다. 이전 후에도 원래 노드를 일정 기간 유지하면 문제가 프로토콜 설정 때문인지 로컬 DNS·라우팅 규칙 때문인지 비교하기 쉽습니다.

3. VLESS와 REALITY: 경량 인증과 현대적인 보안 계층 조합

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

VLESS는 경량 신원 인증과 요청 전달에 초점을 두며, 프로토콜 자체에 별도의 콘텐츠 암호화 계층을 중복해서 제공하지 않습니다. 클라이언트에서 흔히 보이는 encryption 값이 none인 것은 전체 연결에 암호화가 없다는 뜻이 아니라 TLS, REALITY 같은 외부 계층이 보안 기능을 담당한다는 의미입니다. 이 방식은 프로토콜 계층과 전송 보안 계층의 중복 처리를 줄이고 VLESS를 XTLS 계열 흐름 제어와 쉽게 조합할 수 있게 합니다. 설정 시에는 VLESS와 TCP만 사용하고 보안 계층을 활성화하지 않은 경우와 VLESS에 TLS 또는 REALITY를 조합한 경우의 연결 특성이 완전히 다르다는 점을 분명히 해야 합니다.

VLESS 사용자 인증 정보도 보통 UUID입니다. VMess와 달리 VMess의 시간 인증 구조에 의존하지 않으며 alterId도 없습니다. 서버는 사용자별로 flow 같은 확장 필드를 설정할 수 있고 클라이언트는 이를 항목별로 일치시켜야 합니다. 흔히 쓰이는 xtls-rprx-vision은 XTLS Vision 흐름 제어 값으로, Xray 생태계의 구현 기능이며 VLESS라는 이름을 사용하는 모든 코어가 지원하는 것은 아닙니다. 구독을 가져온 뒤 flow가 비어 있는데 원본 링크에 Vision이 명시되어 있다면 먼저 클라이언트 코어와 구독 파싱 과정을 확인해야 합니다.

REALITY가 해결하는 설정 계층 문제

REALITY는 Xray의 전송 보안 구현으로, 보통 대상 사이트와 관련된 정보를 핸드셰이크에 활용하고 서버의 개인 키와 클라이언트의 공개 키를 연결해 대응 관계를 구성합니다. 클라이언트에서 흔히 사용하는 필드는 서버 이름, 지문, 공개 키, Short ID, SpiderX입니다. 서버에는 대응하는 개인 키와 허용된 서버 이름 등의 설정이 저장됩니다. 클라이언트에는 공개 키만 필요하며 서버 개인 키를 구독이나 공유 링크에 넣어서는 안 됩니다. 공개 키, Short ID, 서버 이름 중 하나라도 일치하지 않으면 연결이 빠르게 종료되는 현상으로 나타날 수 있습니다.

서버 이름은 클라이언트에서 SNI 또는 serverName으로 표시되며 핸드셰이크의 선택과 검증에 사용됩니다. 지문 필드에는 chrome 같은 브라우저 지문 식별자가 흔히 사용되어 핸드셰이크 특성 구현을 정합니다. 이는 기기의 브라우저 버전을 뜻하지 않으며 실제로 해당 브라우저를 실행할 필요도 없습니다. Short ID는 서버가 허용한 값 중 하나로, 길이와 내용이 서버 설정을 만족해야 합니다. SpiderX의 기본값은 흔히 슬래시이며 REALITY 관련 동작을 설정합니다. 서버가 별도로 지정하지 않았다면 경험만으로 복잡한 경로를 추가하지 마세요.

XTLS Vision과 전달 경로

XTLS Vision의 목표 중 하나는 직접 전달하기에 적합한 데이터 경로를 식별해 불필요한 재캡슐화와 메모리 복사를 줄이는 것입니다. 전송 콘텐츠 자체에 이미 보안 계층이 있다면 적절한 흐름 제어로 추가 처리 비용을 낮출 수 있으며, 지속적인 처리량이 필요한 연결에서 특히 의미가 있습니다. 다만 Vision의 효과는 코어, 서버, 전송 조합, 실제 데이터 유형에 따라 달라집니다. 짧은 연결의 페이지 로딩은 주로 핸드셰이크, DNS, 왕복 시간의 영향을 받으므로 flow를 선택하는 것만으로 모든 대기 시간이 사라지지는 않습니다.

Vision은 보통 TCP와 조합합니다. 지원되지 않는 전송 방식과 임의로 결합하면 설정을 불러오지 못하거나 서버가 거부할 수 있습니다. 클라이언트 편집기에 프로토콜, 전송, 보안, flow 네 가지 옵션 그룹이 있다면 서버가 제공한 전체 조합에 맞춰 입력해야 합니다. 올바른 순서는 먼저 protocol = vless인지 확인하고, 전송 방식을 확인한 다음 security = reality인지 확인하고, 마지막으로 flow, 공개 키, 서버 이름, 지문, Short ID를 점검하는 것입니다.

{
  "protocol": "vless",
  "user": {
    "id": "00000000-0000-4000-8000-000000000000",
    "encryption": "none",
    "flow": "xtls-rprx-vision"
  },
  "transport": {
    "network": "tcp",
    "security": "reality",
    "serverName": "www.example.com",
    "fingerprint": "chrome"
  }
}

위 예시는 필드 계층을 설명하기 위한 것으로, 예시 도메인과 예시 사용자 ID를 사용하므로 실제 서버에 직접 연결할 수 없습니다. 실제 설정에는 서버 주소, 포트, REALITY 공개 키, Short ID가 반드시 포함되어야 합니다. 핵심은 구독 변환 후 필드가 올바른 위치에 들어갔는지 확인하는 데 있습니다. VLESS 사용자 필드, TCP 전송 필드, REALITY 보안 필드는 서로 대체할 수 없습니다.

가져오기에 실패했을 때의 확인 순서

먼저 현재 클라이언트가 REALITY와 Vision을 지원하는 Xray 코어를 실제로 사용하는지 확인하세요. 그런 다음 링크의 security=reality와 flow=xtls-rprx-vision이 구독 변환 과정에서 누락되지 않았는지 점검합니다. 이어서 pbk 또는 publicKey, sid 또는 shortId, sni, fp 등의 필드를 확인하세요. 공유 링크 규격에 따라 약칭이 사용될 수 있지만, 가져온 뒤 화면에는 대응하는 설정 항목이 복원되어야 합니다. 노드를 저장할 수 있지만 시작할 때 알 수 없는 필드 오류가 난다면 코어 기능이 맞지 않을 가능성이 큽니다. 코어는 정상적으로 시작되지만 핸드셰이크에 실패한다면 공개 키, 서버 이름, Short ID를 먼저 확인하세요.

4. Trojan과 Shadowsocks: 서로 다른 두 가지 간결한 방식

Trojan에서 TLS가 중요한 이유

Trojan은 비밀번호로 사용자를 인증하며 표준 TLS를 연결 설계의 중요한 기반으로 사용합니다. 클라이언트 설정에는 보통 서버 주소, 포트, 비밀번호, 서버 이름, 인증서 확인 관련 옵션이 포함됩니다. 필드 수는 비교적 적고 직관적이지만 ‘필드가 적다’고 TLS를 무시할 수 있는 것은 아닙니다. 서버 이름은 서버 배포 설정과 일치해야 하며 인증서 이름 확인도 이 필드에 의존합니다. 서버 이름을 IP로 바꾸면 인증서 호스트 이름이 일치하지 않을 수 있습니다. 명확한 진단 환경이 아니라면 인증서 검증을 끄는 것을 장기적인 해결책으로 삼지 마세요.

Trojan과 VLESS의 차이는 인증 정보에만 있지 않습니다. Trojan은 비밀번호를 사용하고 VLESS는 UUID를 주로 사용합니다. Trojan의 일반적인 연결은 TLS에 밀접하게 의존하며 VLESS는 여러 보안 계층과 조합할 수 있습니다. 두 프로토콜 모두 일부 전송 방식과 함께 사용할 수 있지만 구체적인 지원 범위는 서버와 코어가 결정합니다. trojan:// 공유 링크를 받았다면 비밀번호, SNI, 전송 유형, Host, 경로를 모두 유지해야 하며 가장 눈에 띄는 서버 주소만 추출해서는 안 됩니다.

Trojan에서 자주 발생하는 문제 범위

TLS 핸드셰이크 단계에서 실패한다면 먼저 기기 시간, 서버 이름, 인증서 유효 상태, 대상 포트에 네트워크가 도달할 수 있는지를 확인하세요. TLS 연결 후 인증에 실패한다면 비밀번호를 다시 확인합니다. 비밀번호는 대소문자를 구분하며 링크의 특수 문자는 올바르게 URL 인코딩되어야 합니다. 수동 복사 과정에서 더하기 기호, 퍼센트 기호, 해시 기호가 링크 구조 문자로 잘못 처리되면 가져온 결과가 원래 비밀번호와 달라질 수 있습니다. 가장 안전한 방법은 클라이언트에서 전체 공유 링크를 직접 가져온 뒤 편집 화면에서 필드를 확인하는 것입니다.

WebSocket이나 gRPC 같은 전송을 사용하면 경로, 서비스 이름, Host 등의 매개변수도 추가됩니다. 이때 ‘Trojan으로 연결된다’는 것은 Trojan 인증, TLS 핸드셰이크, 전송 계층 매개변수가 모두 올바르다는 뜻입니다. 로그에 HTTP 상태 오류가 나오면 전송 경로를, 인증서 이름 오류가 나오면 서버 이름을 확인하세요. 인증 거부가 표시될 때 비밀번호를 점검하면 됩니다. 여러 스위치를 반복해서 바꾸는 것보다 단계별로 확인하는 편이 원인을 찾기 쉽습니다.

Shadowsocks의 암호화 방식과 비밀번호

Shadowsocks는 간결한 암호화 프록시 구조를 사용하며 클라이언트와 서버가 완전히 동일한 암호화 방식과 비밀번호를 사용해야 합니다. 흔한 AEAD 방식에는 aes-128-gcm, aes-256-gcm, chacha20-poly1305가 있습니다. 하드웨어 가속을 지원하는 데스크톱 프로세서와 모바일 프로세서에서는 방식별 성능이 달라질 수 있지만, 최신 기기에서는 네트워크 품질, 연결 수, 서버 부하가 그 차이를 덮는 경우가 많습니다. 선택할 때는 서버 설정을 우선하며 클라이언트에서 일방적으로 알고리즘을 바꾸지 마세요.

Shadowsocks 2022 계열 방식은 키와 세션 처리를 개선했지만 비밀번호 또는 키 형식이 기존 AEAD 방식과 다르고, 모든 코어와 구독 파서가 완전히 지원하는 것도 아닙니다. 방식 이름에 2022가 포함되어 있다면 먼저 클라이언트 코어가 해당 방식을 지원하는지 확인하고, 가져온 뒤 키가 온전히 보존되었는지 점검하세요. 2022 방식을 기존 AEAD 이름으로 바꿔도 서버가 사용하는 프로토콜 세부 사항이 다르기 때문에 호환 연결이 만들어지지 않습니다.

이 두 프로토콜은 언제 선택할까

서버가 표준 Trojan 설정을 제공하고 인증서와 서버 이름을 명확하게 관리한다면 Trojan의 설정 모델은 이해하기 쉽고 TLS와 인증 단계로 나누어 문제를 확인하기도 편합니다. 서버가 간결한 Shadowsocks 설정을 제공하고 클라이언트가 해당 암호화 방식을 명확히 지원한다면 Shadowsocks는 필드가 적어 복잡한 흐름 제어 확장이 필요하지 않은 환경에 적합합니다. 두 프로토콜 사이에 환경을 초월한 절대적인 우선순위는 없습니다. 실제 선택에서는 서버 관리 방식, 클라이언트 코어, 구독의 필드 표현 완전성, 기기의 TUN·복잡한 라우팅 필요 여부를 함께 고려해야 합니다.

v2rayN, v2rayNG, v2flyNG 모두 화면에 이러한 프로토콜 옵션을 표시할 수 있지만, 표시되는 옵션이 현재 코어에서 모든 확장 조합을 지원한다는 뜻은 아닙니다. 특히 Shadowsocks 플러그인 매개변수, 2022 방식, Trojan의 특수 전송 조합은 실행 코어가 생성한 설정 결과를 기준으로 확인해야 합니다. 노드가 구독에서 제공된 것이라면 구독 업데이트 후 원래 프로토콜 유형을 먼저 확인하고, 이름이 비슷한 노드를 필드 템플릿으로 삼아 덮어쓰지 마세요.

5. 연결 속도·리소스 사용량·모바일 배터리

속도는 여러 구간의 연결이 함께 결정합니다

사용자가 체감하는 ‘속도’에는 최소한 DNS 조회, 클라이언트에서 서버까지 연결 설정, TLS 또는 REALITY 핸드셰이크, 서버에서 대상 사이트까지의 연결, 첫 바이트 대기 시간, 지속 전송 처리량이 포함됩니다. 프로토콜은 이 중 일부에만 영향을 줍니다. 짧은 웹 요청은 DNS, 핸드셰이크 왕복, 연결 재사용의 영향을 크게 받고, 대용량 파일 전송은 암호화 구현, 메모리 복사, 혼잡 제어, 서버 출구 성능이 더 잘 드러납니다. 한 번의 노드 속도 측정만으로 VMess, VLESS, Trojan 간 차이를 정확히 프로토콜 탓으로 돌릴 수는 없습니다.

프로토콜을 비교할 때는 같은 기기와 네트워크 진입점, 비슷한 시간대, 같은 서버와 대상 콘텐츠를 사용하고 전송 계층도 가능한 한 동일하게 유지해야 합니다. 한 노드가 WebSocket과 TLS를 사용하고 다른 노드가 TCP와 REALITY를 사용한다면 결과는 전체 조합의 차이를 반영합니다. 테스트에서는 새 연결과 이미 연결된 상태도 구분해야 합니다. 새 연결에는 DNS와 핸드셰이크 비용이 포함되고, 반복 요청은 연결을 재사용할 수 있으므로 두 방식은 서로 다른 질문에 답합니다.

CPU·메모리·연결 재사용

암호화 알고리즘의 하드웨어 가속 여부, 데이터 캡슐화 계층 수, 동시 연결 수, 로그 수준은 모두 CPU 사용량에 영향을 줍니다. AES-GCM은 AES 하드웨어 명령을 지원하는 데스크톱 프로세서에서 대체로 효율적입니다. 이에 비해 해당 AES 가속이 없는 기기에서는 ChaCha20-Poly1305가 더 적합할 수 있지만, 기기 종류만으로 단정해서는 안 됩니다. VLESS가 적절한 흐름 제어와 결합되면 일부 중복 처리를 줄일 수 있으나, 실제 효과는 서버와 전송 조합의 지원 여부에 달려 있습니다.

Mux 다중화는 여러 논리 연결을 더 적은 수의 하위 연결로 모아 잦은 핸드셰이크 비용을 줄일 수 있지만, 하나의 하위 연결에서 혼잡이나 패킷 손실이 발생하면 여러 요청이 서로 영향을 받을 수도 있습니다. 짧은 요청이 많은 웹페이지에서는 Mux가 연결 설정 비용을 줄이는 데 도움이 될 수 있습니다. 반면 지속적인 다운로드, 실시간 연결, 네트워크 품질 변동이 큰 환경에서는 Mux를 끄는 편이 더 안정적일 수 있습니다. 클라이언트 기본값을 출발점으로 삼되 ‘연결 수가 적을수록 빠르다’고 단순하게 해석하지 마세요.

메모리 사용량은 라우팅 규칙, 도메인 데이터베이스, DNS 캐시, TUN 버퍼, 동시 연결 수도 영향을 받습니다. 프로토콜 자체의 프레임 헤더 차이가 그래픽 클라이언트 전체 메모리 사용량의 유일한 주요 원인인 경우는 드뭅니다. 사용량이 높다면 먼저 상세 로그를 끄고, 지나치게 큰 규칙 집합을 줄이고, 반복 속도 측정을 중지하고, 불필요한 동시 작업을 끈 뒤 변화를 비교하세요. 그 다음에야 프로토콜 변경을 검토하는 것이 좋습니다.

TUN 모드가 리소스를 더 많이 사용하는 이유

시스템 프록시는 시스템 프록시 설정을 따르는 애플리케이션의 트래픽을 주로 처리하므로 경로가 비교적 단순합니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 시스템 프록시를 읽지 않는 프로그램까지 더 폭넓게 적용할 수 있지만, IP 패킷, DNS, 라우팅 매칭, 프로토콜 스택 변환을 처리해야 합니다. 모바일에서 TUN을 장시간 켜 두면 깨우기 빈도, 백그라운드 연결 유지, DNS 요청, 네트워크 전환에 따른 연결 재구성이 배터리에 영향을 줍니다. 주요 비용은 시스템 수준의 트래픽 가로채기에서 발생하며 선택한 프록시 프로토콜에 단순히 귀속할 수 없습니다.

브라우저와 시스템 프록시를 따르는 데스크톱 프로그램만 사용한다면 시스템 프록시가 보통 더 적은 리소스를 사용합니다. 프로세스별 제어 또는 애플리케이션 트래픽 전체를 가로채야 할 때 TUN을 검토하세요. TUN을 켠 뒤에는 가상 네트워크 인터페이스를 점유하는 다른 도구를 동시에 실행하지 말고, 로컬 네트워크 우회, DNS 모드, 라우팅 규칙을 확인해야 합니다. TUN은 적용 범위를 넓혀 주지만 ‘더 강력한 프로토콜’은 아니며 잘못된 사용자 ID, 공개 키, 서버 이름도 해결하지 못합니다.

모바일 배터리 사용량을 좌우하는 실제 항목

모바일 배터리 사용량은 네트워크 상태와 백그라운드 동작의 영향을 더 크게 받습니다. 신호가 약하면 무선 연결을 유지하는 것만으로도 더 많은 전력이 필요합니다. 노드가 자주 끊기면 재연결, DNS 재시도, 연결 재구성이 반복됩니다. 자동 속도 측정과 지나치게 짧은 구독 업데이트 주기도 네트워크를 깨웁니다. 안정적인 노드를 선택하고 지속적인 일괄 속도 측정을 피하며, 필요한 주기로 구독을 업데이트하고, 전체 트래픽 가로채기가 필요하지 않을 때는 TUN 사용 시간을 줄이는 것이 좋습니다.

프로토콜 계층에서는 클라이언트 코어가 기본 지원하고 필드가 완전하며 연결이 안정적인 조합을 우선 선택하세요. 이론적인 처리 비용은 낮지만 핸드셰이크에 자주 실패하는 노드는 안정적인 기존 설정보다 실제 배터리를 더 많이 소모할 수 있습니다. v2rayNG는 Xray 코어를 사용하므로 REALITY, Vision 등 Xray 기능이 필요한 설정에 적합합니다. v2flyNG는 V2Fly 계열을 사용하므로 해당 코어 설정과 일치해야 하는 환경에 적합합니다. 앱을 선택할 때는 프로토콜 기능과 백그라운드 안정성을 함께 고려해야 하며 설치 패키지 이름만 비교해서는 안 됩니다.

6. V2Fly·Xray 코어 계열과 설정 호환 범위

공통 기반과 발전 방향

V2Fly와 Xray는 모두 Project V 생태계의 모듈식 설정 방식을 이어받았습니다. 인바운드는 로컬 트래픽을 받고, 아웃바운드는 대상 또는 프록시 서버에 연결하며, 라우팅은 트래픽을 어느 아웃바운드로 보낼지 결정합니다. DNS 모듈은 도메인 해석 정책을 제공하고 전송 설정은 TCP, WebSocket, gRPC 같은 운반 방식을 설명합니다. 두 코어는 VMess, 일부 VLESS, Trojan, Shadowsocks, 기본 라우팅 구조에서 유사한 개념을 많이 공유하므로 여러 구독을 서로 다른 클라이언트에서 인식할 수 있습니다.

유사하다고 해서 설정 파일을 완전히 서로 바꿔 쓸 수 있는 것은 아닙니다. Xray는 VLESS, XTLS Vision, REALITY 등의 방향으로 자체 기능을 확장했으며 전송과 라우팅에 특정 필드를 추가하기도 합니다. V2Fly는 자체 버전과 모듈 체계에 따라 기능을 유지합니다. 하나의 JSON을 한 코어가 읽을 수 있다고 해서 다른 코어가 모든 필드를 받아들인다는 뜻은 아닙니다. 그래픽 클라이언트에서 ‘가져오기 성공’이 표시되어도 링크가 서버 기록으로 변환되었다는 의미일 뿐이며, 실제 호환성은 코어 시작 결과와 연결 로그를 기준으로 확인해야 합니다.

세 클라이언트와 코어의 역할

v2rayN은 이 사이트가 데스크톱용으로 우선 권장하는 클라이언트로 Windows, macOS, Linux를 지원하며 서버 목록, 구독 그룹, 시스템 프록시, TUN, 라우팅 설정, 코어 관리 기능을 그래픽 화면에서 제공합니다. 데스크톱에서 여러 구독과 복잡한 라우팅을 처리하거나 프로토콜을 테스트해야 하는 사용자에게 적합합니다. 일반적인 설정은 Xray 기능을 중심으로 동작하므로 REALITY와 XTLS Vision을 가져올 때는 클라이언트 이름만 보지 말고 실제로 해당 코어가 활성화되어 있는지 확인해야 합니다.

v2rayNG는 Android용이며 주로 Xray 코어를 사용해 VLESS, REALITY, Vision과 일반적인 VMess, Trojan, Shadowsocks 설정에 적합합니다. v2flyNG 역시 Android용이지만 코어 계열이 다르며 V2Fly 설정 문법을 사용해야 하는 환경에 적합합니다. 두 앱의 화면 필드는 비슷할 수 있지만 실행 결과는 코어 기능이 결정합니다. 서버가 Xray 확장 필드를 명시적으로 요구한다면 v2rayNG를 우선 선택하고, 설정이 V2Fly를 대상으로 한다면 v2flyNG를 선택할 수 있습니다.

설정 호환성의 세 가지 계층

첫 번째 계층은 문법 호환성으로, JSON 필드 이름과 데이터 유형을 파싱할 수 있는지 확인합니다. 두 번째는 기능 호환성으로, 코어가 해당 프로토콜·전송·보안 계층을 구현했는지 봅니다. 세 번째는 동작 호환성으로, 양쪽이 필드를 받아들이더라도 기본값, DNS 정책, 라우팅 매칭 세부 사항이 같은지 확인합니다. 이전할 때는 ‘설정 로드 성공’만으로 충분하지 않으며 도메인 해석, 직접 연결 규칙, 프록시 규칙, UDP 트래픽이 예상대로 동작하는지 계속 검증해야 합니다.

공유 링크 호환성도 여러 계층으로 나뉩니다. 클라이언트가 vless://는 인식하지만 링크의 새로운 쿼리 매개변수는 인식하지 못할 수 있고, 노드의 기본 정보는 유지하면서 flow, fingerprint, Short ID를 잃을 수도 있습니다. 구독 변환 서비스가 코어 전용 필드를 자체 중간 형식으로 바꾸는 경우도 있습니다. 이때는 원본 공유 링크와 가져온 뒤의 편집 화면을 비교하고 클라이언트가 내보낸 전체 설정을 확인해야 하며, 문제를 막연히 ‘프로토콜 미지원’으로 분류해서는 안 됩니다.

코어 전환 전후 확인 사항

v2rayN에서 실행 코어를 전환하기 전에 현재 노드의 프로토콜, 전송 방식, 보안 계층, 라우팅 설정을 기록하세요. 전환 후 클라이언트를 다시 시작해 설정을 완전히 불러오고, 시작 로그에 알 수 없는 필드, 잘못된 열거형 값, 리소스 파일 누락이 표시되는지 확인합니다. 기본 VMess, TCP, TLS만 사용하는 설정은 이전이 비교적 순조로운 편입니다. REALITY, Vision, 특수 DNS, 코어 전용 라우팅 기능을 사용한다면 필드를 하나씩 검증해야 합니다.

모바일에서는 테스트를 위해 복잡한 노드를 여러 클라이언트에서 반복해서 수동 재구성하지 않는 것이 좋습니다. 더 안정적인 방법은 원래 구독을 유지한 채 대상 클라이언트에서 다시 가져온 다음 노드 유형과 핵심 필드를 확인하는 것입니다. 구독 자체가 특정 코어를 대상으로 생성되었다면 해당 클라이언트를 선택하세요. 설치 경로는 Android 클라이언트 목록에서 확인할 수 있습니다. 두 앱의 연결을 동시에 활성 상태로 유지하면 가상 네트워크 인터페이스와 시스템 라우팅이 서로 덮어쓸 수 있으므로 피해야 합니다.

7. 구독·공유 링크·기본 JSON의 호환성

자주 사용하는 세 가지 설정 형식

단일 공유 링크는 보통 vmess://, vless://, trojan://, ss://로 시작하며 하나의 서버를 설명합니다. 구독 링크는 업데이트 가능한 노드 모음을 가리키고, 클라이언트가 구독을 요청하면 여러 기록을 파싱합니다. 기본 JSON 설정에는 인바운드, 아웃바운드, DNS, 라우팅, 정책 등의 전체 구조가 포함되어 표현력이 가장 강하지만, 서버 기록만 받는 구독 화면에 바로 가져오기에 적합하지 않을 수 있습니다. 세 형식은 용도가 다르므로 모두 텍스트처럼 보인다는 이유만으로 서로 대체할 수 없습니다.

Base64 통합 구독은 여러 공유 링크를 줄바꿈으로 나열한 뒤 인코딩하는 방식이 일반적입니다. Base64는 인코딩일 뿐 프로토콜 변환 기능을 제공하지 않습니다. VLESS 링크에 REALITY 필드가 포함되어 있다면 클라이언트가 해당 쿼리 매개변수를 인식해야 합니다. 기본 JSON 구독은 클라이언트별 사용자 정의 구조를 사용할 수 있어 코어 설정과 필드 이름이 완전히 같지 않을 수 있습니다. 구독 호환성을 판단하려면 응답이 공유 링크 모음인지, 클라이언트 전용 JSON인지, 완전한 코어 설정인지 먼저 확인해야 합니다.

프로토콜별 링크의 핵심 필드

VMess 링크는 주소, 포트, 사용자 ID, 네트워크 유형, Host, 경로, TLS, 서버 이름 등을 포함하는 인코딩된 JSON 객체 형태로 자주 사용됩니다. 과거 형식에는 여러 필드 규약이 존재했기 때문에 변환 도구마다 host, sni, 경로를 다르게 처리할 수 있습니다. VLESS 링크는 보통 UUID를 사용자 정보 위치에 넣고 쿼리 매개변수로 encryption, security, type, flow, sni, fp, pbk, sid 등을 표현합니다. REALITY 설정은 특히 쿼리 매개변수가 완전하게 보존되어야 합니다.

Trojan 링크는 비밀번호를 사용자 정보로 사용하며 쿼리 매개변수에 SNI, 전송 유형, Host, 경로가 포함될 수 있습니다. 비밀번호의 특수 문자는 URL 인코딩해야 합니다. 그렇지 않으면 해시 기호 뒤의 내용이 노드 메모로, 물음표 뒤의 내용이 쿼리 매개변수로 해석될 수 있습니다. Shadowsocks 링크에는 암호화 방식과 비밀번호를 함께 인코딩하는 형식과 사용자 정보를 별도로 표현하는 형식이 모두 있으며, 일부 링크에는 플러그인 매개변수도 포함됩니다. 클라이언트가 ss:// 접두사를 인식한다고 해서 지정된 모든 플러그인이나 2022 방식을 지원한다는 뜻은 아닙니다.

구독을 가져온 뒤 노드가 비어 있을 때

첫 단계로 클라이언트에서 구독 그룹을 수동 업데이트하고, 업데이트 메시지가 요청 실패인지, 콘텐츠 없음인지, 파싱 결과가 0건인지 확인하세요. 요청 실패는 구독 주소, 네트워크 경로, 주소 유효 상태와 관련된 경우가 많습니다. 응답에는 콘텐츠가 있지만 노드가 0개라면 지원되지 않는 형식일 가능성이 큽니다. 두 번째로 웹페이지 주소나 단일 노드 메모가 아니라 구독 주소를 복사했는지 확인하세요. 세 번째로 주소 앞뒤에 공백, 줄바꿈, 한국어 문장부호가 섞이지 않았는지 점검합니다.

일부 노드만 누락되었다면 프로토콜별로 확인하세요. 기존 VMess는 가져와지는데 REALITY 노드가 사라진다면 파서가 새 필드를 보존하지 못했거나 코어 기능이 부족할 가능성이 큽니다. 일반 Shadowsocks는 가져와지는데 2022 방식이 빠진다면 지원 범위가 다를 수 있습니다. Trojan 노드는 있지만 연결되지 않는다면 비밀번호, SNI, 전송 매개변수를 계속 확인하세요. 더 자세한 형식 구조와 변환 방법은 Base64·기본 JSON·공유 링크 설명을 참고하세요.

구독 업데이트와 로컬 수정의 충돌

구독 노드는 보통 원격 기록으로 관리됩니다. 클라이언트에서 구독 노드를 수동으로 수정하면 다음 업데이트 때 로컬 필드가 덮어써질 수 있습니다. 라우팅, DNS, 시스템 프록시를 장기간 조정해야 한다면 구독 노드를 하나씩 수정하기보다 클라이언트의 전역 설정이나 라우팅 설정을 우선 변경하세요. 노드 사본을 장기간 보관해야 한다면 로컬 그룹으로 복사하고 업데이트 가능한 구독과의 관계를 명확히 구분하는 것이 좋습니다.

구독 그룹은 서로 다른 설정 출처를 구분하고 업데이트 주기를 따로 지정하는 데도 사용할 수 있습니다. 서버 목록은 보통 분 단위로 갱신할 필요가 없으므로 업데이트를 지나치게 자주 실행하지 마세요. 모바일에서는 잦은 업데이트가 백그라운드 네트워크 활동을 늘릴 수 있습니다. 노드 메모는 용도를 식별하는 데 도움이 되지만 프로토콜 인증에는 관여하지 않습니다. 노드 이름을 바꿔도 서버 주소, 공개 키, 비밀번호는 바뀌지 않으며 하위 필드 누락도 해결되지 않습니다.

QR 코드·클립보드·수동 입력

QR 코드는 공유 링크를 그래픽으로 표현한 형식일 뿐입니다. 스캔에 성공해도 클라이언트가 원본 URI를 파싱하므로 QR 코드의 선명도는 읽기 여부만 좌우하며 필드 호환성 문제를 해결하지는 못합니다. 클립보드 가져오기는 하나 또는 여러 개의 완전한 링크를 한 번에 처리할 때 적합하고, 수동 입력은 소수의 필드를 확인할 때 유용합니다. REALITY, WebSocket, gRPC 설정은 필드가 많으므로 전체를 먼저 가져온 뒤 편집 화면에서 확인하는 편이 처음부터 수동 입력하는 것보다 안정적입니다.

v2rayN과 v2rayNG에서 구독을 가져오는 구체적인 메뉴, 수동 업데이트 시점, 노드 목록 확인 순서는 구독 링크 가져오기 튜토리얼에서 이어서 확인할 수 있습니다. vmess:// 또는 vless:// 링크 하나만 받은 경우에는 공유 링크와 구독의 차이를 참고해 단일 링크를 구독 주소 입력란에 잘못 넣지 않도록 하세요.

8. 사용 시나리오별 프로토콜 선택과 이전 검증

데스크톱 일반 사용

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 사용하세요. 이미 안정적인 구독이 있다면 먼저 전체를 가져오고 구독이 제공한 프로토콜 조합을 사용하면 됩니다. 모든 노드를 미리 같은 유형으로 바꿀 필요는 없습니다. 일반적인 웹 탐색과 시스템 프록시를 따르는 앱은 먼저 시스템 프록시를 활성화하고, 시스템 프록시를 읽지 않는 프로그램까지 제어해야 할 때 TUN을 검토하세요. 노드는 한 번의 속도 측정 결과로 순위를 정하기보다 안정적으로 연결되는지 먼저 확인한 뒤 지속적인 접속 성능을 비교해야 합니다.

구독에 VMess, VLESS REALITY, Trojan, Shadowsocks가 모두 있다면 여러 유형을 비교용으로 유지할 수 있습니다. Xray 코어를 사용할 때 서버가 제공하는 VLESS, REALITY, Vision 조합은 기능 호환성이 대체로 뛰어납니다. 이미 안정적으로 연결되는 VMess나 Trojan도 계속 사용할 수 있으며, Shadowsocks는 암호화 방식을 중점적으로 확인해야 합니다. 프로토콜 이름은 품질 등급이 아니며, 이름의 신구보다 서버 관리와 완전한 설정이 중요합니다.

모바일 상시 연결

Android에서 Xray 확장이 필요하면 v2rayNG를, V2Fly 코어 문법이 필요하면 v2flyNG를 선택하세요. 모바일에서는 가능한 많은 기능을 켜기보다 안정성, 백그라운드 재연결, 배터리를 먼저 고려해야 합니다. 안정적인 노드를 선택하고 불필요한 일괄 속도 측정을 끄며 구독 업데이트를 적절히 예약하세요. 앱 트래픽이 시스템 프록시 경로로 처리될 수 있다면 더 무거운 TUN을 항상 사용할 필요는 없습니다. TUN이 반드시 필요하다면 라우팅 규칙을 단순화하고 DNS가 중복 처리되지 않는지 확인하세요.

모바일 네트워크와 무선 LAN을 전환하면 기존 TCP 연결을 다시 설정해야 하는 경우가 많습니다. 잠시 연결이 끊겼다고 해서 반드시 프로토콜 오류인 것은 아닙니다. 전환할 때마다 장시간 복구되지 않는다면 클라이언트의 백그라운드 권한, 시스템 네트워크 상태, 노드 재연결 로그를 확인하세요. 프로토콜 변경은 프로토콜 또는 핸드셰이크 계층 문제만 해결할 수 있으며, 시스템의 백그라운드 네트워크 중지, 구독 필드 누락, 서버 접근 불가 문제는 고치지 못합니다.

기존 설정을 최신 조합으로 이전하기

VMess에서 VLESS REALITY로 이전할 때는 서버에서 새로운 전체 설정을 생성하고 클라이언트에서 새 노드로 가져와야 합니다. 기존 VMess 노드의 프로토콜 드롭다운만 바꾼 뒤 TLS, WebSocket, 사용자 필드를 계속 사용하지 마세요. UUID, 전송 유형, REALITY 공개 키, Short ID, 서버 이름, 지문, flow를 모두 확인해야 합니다. 원래 노드는 잠시 유지해 같은 네트워크에서 비교할 수 있도록 하세요.

기존 Shadowsocks 방식에서 2022 방식으로 이전할 때도 서버와 클라이언트가 함께 변경되어야 하며 기존 비밀번호 형식을 그대로 사용할 수 없습니다. Trojan에서 인증서나 도메인을 바꾸면 서버 이름과 관련된 전송 Host도 업데이트해야 할 수 있습니다. 어떤 이전이든 먼저 기본 연결을 확인한 다음 복잡한 라우팅, TUN, 사용자 지정 DNS를 복원하세요. 한 번에 너무 많이 바꾸면 로그만으로 구체적인 원인을 찾기 어렵습니다.

장애 증상별 우선 확인 항목

반복 가능한 검증 절차

첫째, 원래 설정의 프로토콜, 전송 방식, 보안 계층, 실행 코어를 기록합니다. 둘째, 새 설정을 가져오되 기존 노드는 아직 삭제하지 않습니다. 셋째, 복잡한 라우팅과 추가 DNS 재작성을 끄고 코어가 시작되는지, 서버에 연결되는지, 기본 도메인에 접속되는지만 확인합니다. 넷째, 시스템 프록시, 라우팅 분할, DNS, TUN을 순서대로 다시 활성화하고 항목을 하나 복원할 때마다 간단한 접속 테스트를 진행합니다. 다섯째, 네트워크 전환과 기기 절전 후 복구 상태를 관찰합니다. 여섯째, 실제 사용 환경에서 새 연결, 연속 접속, 지속 전송을 비교합니다.

로그도 계층에 따라 읽어야 합니다. 설정 파싱 오류가 시작 단계에 나타나면 필드와 코어를 확인하고, 핸드셰이크 오류가 연결 단계에 나타나면 인증 정보와 보안 계층을 확인합니다. 도메인 해석 오류는 DNS를 점검해야 하며, 특정 앱만 접속하지 못할 때는 시스템 프록시, TUN, 라우팅을 확인합니다. 로그 단계와 설정 계층을 대응시키면 모든 문제를 ‘노드 사용 불가’로 단정하는 일을 피할 수 있습니다.

첫 연결을 빠르게 완료하려면 시작 가이드의 기본 순서를 따르면 됩니다. 아직 플랫폼에 맞는 클라이언트를 설치하지 않았다면 설치 패키지 페이지에서 v2rayN, v2rayNG, v2flyNG를 선택하세요. Windows 설치 과정과 데스크톱 버전·WPF 버전의 차이는 v2rayN Windows 설치 및 설정 전체 가이드에서 확인할 수 있습니다. 연결을 완료한 뒤 이 가이드로 돌아와 프로토콜 필드를 점검하는 편이 처음부터 코어, 라우팅, 전송 매개변수를 동시에 바꾸는 것보다 원인을 파악하기 쉽습니다.