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

1. 프로토콜·전송·보안·클라이언트 구분하기

연결에는 어떤 설정이 필요할까

v2rayN의 ‘서버 추가’ 창에서 프로토콜 유형은 설정의 시작점일 뿐입니다. 클라이언트가 연결을 구성하려면 서버 주소, 포트, 사용자 인증 정보, 전송 방식, 전송 계층 보안 설정도 알아야 합니다. 예를 들어 VLESS를 선택했다면 주소에는 your-server.example을 입력하고 포트는 서버 설정에 지정된 값을 사용합니다. 사용자 인증 정보는 보통 UUID이며, 전송 프로토콜은 tcp, ws 또는 grpc일 수 있습니다. 전송 계층 보안은 tls나 reality를 사용할 수 있습니다. 각 필드의 역할은 서로 다르므로 프로토콜 유형이 같다고 서버 매개변수 전체를 서로 바꿔 쓸 수는 없습니다. 주소와 포트는 연결 대상을, 인증 정보는 양쪽이 서로를 확인할 수 있는지를, 전송 및 보안 필드는 연결 방식을 결정합니다.

여기서 ‘프록시 프로토콜’은 주로 클라이언트와 서버 사이에서 요청을 구성하고, 사용자를 식별하며, 대상 주소를 전달하는 방식을 가리킵니다. VMess, VLESS, Trojan, Shadowsocks가 이 계층에 속합니다. ‘전송’은 데이터를 전달하는 방식을 뜻합니다. tcp는 스트림 연결을 직접 사용하고, WebSocket은 자체 핸드셰이크와 메시지 캡슐화를 추가하며, gRPC는 HTTP/2 스트림을 기반으로 합니다. 사용할 전송 방식은 서버에서 실제로 제공하는 방식에 따라야 하며, 클라이언트에서 임의로 바꿀 수 없습니다. 주소와 인증 정보가 맞더라도 경로, 서비스 이름 또는 전송 유형이 다르면 핸드셰이크 단계에서 연결이 끊길 수 있습니다.

REALITY는 프로토콜 유형으로 선택하는 항목이 아닙니다

tls와 reality는 전송 계층 보안과 관련된 옵션입니다. REALITY는 VLESS와 나란히 놓이는 독립적인 프록시 프로토콜이 아닙니다. 흔히 VLESS, tcp, reality를 함께 설정하는데, 이는 VLESS로 프록시 데이터를 구성하고 TCP로 전송하면서 서버 설정에 따라 REALITY 연결을 맺는다는 뜻입니다. 설정을 확인할 때는 먼저 프로토콜 필드, 다음으로 전송 필드, 마지막으로 보안 필드를 살펴보세요. 공유 텍스트에 ‘REALITY 노드’라고만 적혀 있고 프로토콜이 명시되지 않았다면 원본 링크나 제공자의 안내를 확인해야 합니다. 표시 이름만으로 서버 항목을 만들 수는 없습니다.

‘코어’는 앞서 설명한 설정을 해석하고 실행하는 프로그램입니다. v2rayN은 Windows, macOS, Linux용 데스크톱 그래픽 클라이언트이고, v2rayNG와 v2flyNG는 Android용 그래픽 클라이언트입니다. 인터페이스는 항목, 구독, 시스템 설정을 관리하며 실제로 사용할 수 있는 필드는 내장된 코어와 코어 버전에도 영향을 받습니다. 설정을 인터페이스에 저장할 수 있다고 해서 코어가 반드시 실행할 수 있는 것은 아닙니다. 필드를 인식하지 못하는 경우 서버 주소만 확인하지 말고 클라이언트, 현재 코어, 서버에서 요구하는 기능을 함께 점검하세요.

프로토콜을 추측하지 말고 필드 목록을 확인하세요

서버 매개변수를 받았다면 프로토콜, 주소, 포트, 인증 정보, 전송 방식, 보안 유형, 전송 전용 매개변수 순으로 정리할 수 있습니다. WebSocket은 Host와 경로를, gRPC는 serviceName을 확인해야 하는 경우가 많습니다. TLS는 서버 이름을 확인하고, REALITY는 공개 키, 짧은 ID와 서버가 제공한 핸드셰이크 매개변수를 확인해야 합니다. 정보가 빠져 있다면 먼저 설정 제공자에게 원본 내용을 요청하세요. ‘특정 프로토콜은 보통 특정 포트를 사용한다’는 내용을 고정 규칙으로 믿어서는 안 됩니다. 포트는 서버 설정이며 프로토콜 이름만으로 알아낼 수 없습니다.

이 페이지에서는 클라이언트 필드와 서버 설정의 대응 관계를 다룹니다. 알 수 없는 서버 설정을 임의로 변경하라는 뜻은 아닙니다. 구독을 가져오면 그래픽 인터페이스가 복잡한 매개변수를 편집 창에 접어 표시할 수 있습니다. 확인이 필요하면 목록에 보이는 이름만 보지 말고 항목 상세 정보를 열어보세요. 표시 이름은 구독 제공자가 임의로 지정할 수 있으므로 프로토콜을 판단하는 기준이 아니며, 전송 보안 옵션이 일치한다는 증거도 아닙니다. 모드를 반복해서 바꾸기보다 계층별로 점검하는 편이 문제를 찾기 쉽습니다.

2. VMess와 VLESS: 서로 다른 필드 구성

VMess의 설계 배경과 실제 설정

VMess는 Project V 생태계에서 일찍부터 널리 사용된 프록시 프로토콜입니다. 프로토콜 계층에서 사용자 인증과 데이터 캡슐화를 처리하므로 고유한 연결 형식을 갖습니다. 그래픽 클라이언트에서는 보통 주소, 포트, 사용자 ID와 서버 설정에 따른 보안 또는 암호화 옵션을 입력합니다. 오래된 가이드에 나오는 필드 이름이 현재 인터페이스와 완전히 같지는 않을 수 있습니다. 일부 옵션은 구형 설정 형식에 속하고, 다른 옵션은 전송 또는 TLS 설정으로 이동했을 수 있습니다. 입력할 때는 현재 서버 매개변수와 클라이언트 필드의 의미를 기준으로 삼고, 오래된 가이드를 그대로 재현하려고 제공되지 않은 값을 기존 설정에 추가하지 마세요.

VMess는 여러 전송 방식과 조합할 수 있습니다. ‘VMess’가 ‘WebSocket’을 뜻하는 것은 아니며, TLS가 반드시 활성화된다는 의미도 아닙니다. 연결이 실패하면 프로토콜 인증 필드가 맞지 않는 경우와 전송 핸드셰이크가 실패한 경우를 구분해야 합니다. 서버에서 ws 경로를 제공하는데 클라이언트를 tcp로 설정하면 사용자 ID가 맞더라도 동일한 연결을 만들 수 없습니다. 서버에서 TLS를 요구한다면 입력한 서버 이름과 관련 보안 설정도 확인해야 합니다. 프로토콜 유형을 바꾸려면 보통 서버 측에서도 해당 유형에 맞는 설정을 제공해야 합니다. 클라이언트에서 VMess를 VLESS로 바꾸기만 해서는 해결되지 않습니다.

VLESS는 왜 보안 설정을 다른 계층에 맡길까

VLESS는 사용자 ID로 연결을 식별하는 방식은 유지하면서 프로토콜 계층을 간소화했습니다. 일반적으로 프록시 프로토콜 자체에서 데이터 암호화까지 중복 처리하지 않습니다. 전송 보안이 필요하면 서버와 동일한 TLS나 REALITY 등의 옵션을 사용합니다. 계층을 분리하면 프로토콜 필드와 전송 보안 필드를 각각 살펴보기 쉽고, VLESS를 여러 전송 방식과 조합할 수도 있습니다. 대신 보안 계층을 반드시 확인해야 합니다. ‘VLESS’라는 이름만 보고 연결에 특정 보안 설정이 적용됐다고 판단하거나 서버가 제공한 공개 키 또는 서버 이름 확인을 생략해서는 안 됩니다.

VLESS에서 흔히 사용하는 인증 정보는 UUID입니다. 일부 설정에는 flow도 나타나는데, 이는 특정 동작 방식에 대한 약속이지 임의로 설정하는 성능 옵션이 아닙니다. 서버가 동일한 flow를 명시적으로 제공하고 클라이언트 코어도 해당 조합을 지원할 때만 사용해야 합니다. 비워 두는 것과 값을 입력하는 것은 서로 다른 서버 설정을 가리킬 수 있습니다. 링크를 가져온 뒤 flow가 빠졌다면 모든 항목에 같은 값을 추가하지 말고 구독 출력 형식과 파싱 결과부터 확인하세요. 직접 입력할 때는 일반적인 스크린샷을 따라 하기보다 원본 매개변수와 편집 화면을 항목별로 대조하는 것이 더 정확합니다.

VMess와 VLESS 중 무엇을 선택할까

이미 안정적으로 사용하는 VMess 서버가 있고 구독에 인증 정보, 전송, 보안 필드가 모두 포함되어 있다면 새로운 이름을 좇아 프로토콜을 바꿀 필요는 없습니다. 새 설정을 만들 때는 서버에서 실제로 제공하는 유형과 필요한 전송 보안을 대상 코어가 지원하는지 확인하세요. VLESS는 프로토콜 계층이 비교적 간결하지만, 연결 전체에는 TCP, TLS 핸드셰이크, 선택한 전송 방식과 애플리케이션 트래픽에 따른 비용이 포함됩니다. ‘프로토콜 계층이 더 가볍다’는 이유만으로 모든 네트워크 환경에서 더 빠르다고 볼 수는 없습니다. 사용자에게는 세부적인 캡슐화 차이보다 설정의 일치와 안정적인 연결이 더 중요합니다.

기존 서버를 이전할 때는 비교를 위해 기존 항목을 남겨두고 새 항목을 가져와 필드를 각각 확인하는 것이 좋습니다. 두 항목의 주소와 포트가 같아도 같은 인증 방식을 사용한다고 볼 수는 없습니다. 테스트할 때는 기기, 네트워크, 애플리케이션을 동일하게 유지한 채 연결이 성립하는지 확인하세요. 프로토콜, 전송, 시스템 프록시를 동시에 변경하면 무엇이 결과를 바꿨는지 알기 어렵습니다. 클라이언트 인터페이스에서 가져오는 구체적인 방법은 시작 가이드에서 확인할 수 있습니다.

3. Trojan과 Shadowsocks: 비밀번호 필드의 차이

Trojan에서 TLS가 중요한 이유

Trojan은 비밀번호로 인증하며 일반적으로 TLS 연결을 사용합니다. 클라이언트에 입력하는 주요 필드는 주소, 포트, 비밀번호, 서버 이름입니다. 인증서는 서버 설정 및 도메인과 일치해야 합니다. VMess나 VLESS의 UUID 필드와는 다릅니다. 그래픽 인터페이스에서 모두 ‘사용자 정보’ 근처에 표시되더라도 의미를 서로 바꿔 쓸 수 없습니다. Trojan 공유 링크를 받았다면 서버 이름이 링크에 온전히 포함되어 있는지 특히 확인하세요. 주소는 도메인일 수도, 숫자 주소일 수도 있지만 TLS 핸드셰이크에는 서버가 예상하는 이름이 필요합니다. 대상 주소만으로 모든 핸드셰이크 매개변수를 추측할 수는 없습니다.

Trojan은 추가 전송 설정과 조합할 수도 있으며, 구체적인 지원 여부는 코어와 서버에 따라 다릅니다. 속도를 비교할 때 프록시 프로토콜의 캡슐화 크기만 따져서는 안 됩니다. TLS 연결 수립, 네트워크 왕복 시간, 연결 재사용 방식은 모두 첫 요청에 영향을 줍니다. 연결 수립 후의 지속 전송은 네트워크 품질, 서버 부하, 애플리케이션 데이터 양의 영향을 받습니다. 이미 설정된 항목에서는 비밀번호, 서버 이름, TLS 설정이 일치하는지 확인한 뒤 애플리케이션이 실제로 클라이언트의 로컬 프록시를 통해 요청을 보내는지 점검하는 편이 유용합니다.

Shadowsocks의 method 필드

Shadowsocks는 흔히 SS라고 줄여 부르며, 비밀번호와 암호화 방식이 핵심 매개변수입니다. 비교적 오래된 생태계로, 클라이언트 인터페이스에서는 보통 서버 주소, 포트, 비밀번호, method를 입력합니다. 암호화 방식마다 실제 호환성의 경계가 있으므로 서버와 클라이언트의 방식이 일치해야 합니다. 비밀번호만 맞춰서는 충분하지 않습니다. 일부 방식은 클라이언트와 서버 구현에 별도의 요구 사항이 있습니다. 따라서 ‘Shadowsocks 지원’이 모든 방식을 지원한다는 뜻은 아닙니다. 구독을 가져온 뒤 항목은 보이지만 연결할 수 없다면 라우팅 규칙을 바꾸기 전에 편집 창에서 method가 올바르게 인식됐는지 확인하세요.

Shadowsocks와 Trojan 모두 인터페이스에 ‘비밀번호’가 표시될 수 있지만, 비밀번호 필드만으로 프로토콜을 구분할 수는 없습니다. 두 프로토콜은 연결 구성과 서버 구현이 다르므로 SS 매개변수를 Trojan 편집 창에 붙여 넣어도 동일한 설정이 되지 않습니다. Shadowsocks의 선택형 플러그인이나 추가 전송 계층도 프로토콜 자체로 간주해서는 안 됩니다. 자료에 method, 플러그인 매개변수, 서버 이름이 함께 있다면 먼저 원본 형식을 확인한 뒤 항목 유형에 맞게 계층별로 입력하세요. 플러그인 옵션을 전송 계층 보안 필드에 잘못 넣지 않도록 주의해야 합니다.

선택할 때는 기존 서버 설정을 기준으로 삼으세요

기존 서버가 Trojan을 사용한다면 클라이언트에서도 Trojan을 선택하고 TLS 매개변수를 유지하세요. 서버가 Shadowsocks를 사용한다면 Shadowsocks를 선택하고 암호화 방식을 확인해야 합니다. 직접 서버를 관리한다면 먼저 대상 클라이언트와 코어가 선택한 방식을 지원하는지 확인한 뒤 서버 설정과 구독 출력 형식을 정하세요. SS는 필드가 적어 직접 입력하기 쉽지만, 실수할 수 있는 부분이 비밀번호뿐이라는 뜻은 아닙니다. method, 포트, 플러그인 매개변수도 정확히 일치해야 합니다. Trojan 설정 항목은 단순해 보여도 TLS 서버 이름과 인증서 검증을 빼놓을 수 없습니다.

두 프로토콜을 비교할 때는 유지 관리 비용도 고려해야 합니다. 여러 사람이 같은 안내를 참고한다면 ‘주소+비밀번호’만 보내기보다 프로토콜 유형, method, TLS 이름을 명확하게 표시하는 편이 입력 오류를 줄이는 데 도움이 됩니다. 구독 제공자가 매개변수를 변경했다면 편집 상세 정보를 다시 열어 핵심 필드가 예상대로 바뀌었는지 확인하세요. 구독 그룹을 구분하고 용도별 항목을 필터링하려면 구독 그룹과 노드 필터링을 참고하세요. 목록을 정리하려고 프로토콜 이름을 바꾸지는 마세요.

4. REALITY: 프로토콜 옆에 표시되지만 보안 계층에 속하는 항목

자주 쓰이는 조합부터 이해하기

REALITY는 Xray 생태계의 전송 계층 보안 메커니즘으로, VLESS 설정에서 자주 사용됩니다. 제공자는 항목을 ‘VLESS · REALITY’라고 줄여 부를 수 있지만, 실제로는 두 가지 정보를 나타냅니다. 프록시 프로토콜은 VLESS이고 보안 유형은 reality입니다. 전송 방식도 별도로 확인해야 하며, tcp가 흔한 예입니다. 클라이언트에서 VLESS 항목만 선택할 수 있고 해당 보안 옵션이 없거나 선택한 코어가 REALITY 매개변수를 인식하지 못한다면 주소와 UUID를 입력하는 것만으로 연결할 수 없습니다. 새 보안 필드가 보이면 먼저 코어 지원 여부를 확인하고 클라이언트 편집 창에 필드가 올바르게 표시되는지 살펴보세요.

REALITY 설정에는 보통 서버에서 지정한 서버 이름, 공개 키, 짧은 ID가 포함됩니다. 일부 조합에는 flow와 다른 핸드셰이크 매개변수도 들어갑니다. 이 값들은 클라이언트가 도메인으로 자동 계산하는 값이 아닙니다. 공개 키는 해당 서버 설정에 연결된 공개 매개변수이므로 다른 서버의 값을 대신 사용해서는 안 됩니다. 짧은 ID는 서버가 제공한 내용을 따라야 하며 빈 값에도 특별한 의미가 있을 수 있습니다. 그래픽 인터페이스에서는 이런 필드가 ‘전송 계층 보안’ 펼침 영역에 표시되기도 합니다. 가져온 뒤 직접 열어 확인하고, 특히 비어 있는 필드와 파싱되지 않은 필드를 살펴보세요.

보안 계층 문제와 프록시 계층 문제를 구분하세요

REALITY 핸드셰이크 매개변수가 맞지 않으면 프록시 프로토콜 인증이 시작되기도 전에 연결이 끊길 수 있습니다. 이때 VLESS UUID를 계속 바꿔도 대개 도움이 되지 않습니다. 다음 순서로 확인하세요. 서버 주소와 포트가 맞는지, 전송 방식이 서버와 일치하는지, 보안 유형으로 reality를 선택했는지, 서버 이름·공개 키·짧은 ID가 하나씩 일치하는지, 마지막으로 UUID와 flow가 맞는지 확인합니다. 이 순서는 연결 대상, 핸드셰이크, 사용자 필드 문제를 구분하는 데 유용합니다. 구체적인 오류는 현재 코어 로그를 기준으로 판단하세요.

코어 로그는 목록 상태보다 장애가 발생한 위치를 파악하는 데 유용하지만, 하나의 오류도 앞선 여러 필드 때문에 나타날 수 있습니다. 예를 들어 ‘핸드셰이크 실패’가 곧 공개 키 오류를 뜻하지는 않습니다. 네트워크 연결이 끊기거나 서버 설정이 바뀌어도 비슷한 증상이 생길 수 있습니다. 점검 중에는 어떤 필드를 변경했는지 기록하고, 매번 변경 후 연결을 다시 시도하세요. 여러 항목을 구독에서 가져왔다면 원본 매개변수가 완전한 항목 하나를 비교 대상으로 삼으세요. 구독 형식 변환으로 필드가 빠진 것을 서버 장애로 오해하지 않는 데 도움이 됩니다.

적용 범위와 호환성 확인

REALITY를 모든 프로토콜에 공통으로 적용하는 체크박스로 생각해서는 안 됩니다. 서버가 해당 메커니즘을 명확히 사용하고 클라이언트 코어가 조합을 지원할 때만 선택하세요. 기존 TLS 설정에서 보안 유형을 reality로 바꾼다고 자동으로 전환되지 않습니다. 필요한 매개변수가 서로 다릅니다. 같은 구독에 일반 TLS 항목과 REALITY 항목이 섞여 있다면 각 항목의 원래 보안 유형을 유지해야 하며 일괄 변경해서는 안 됩니다. v2rayN은 선택한 코어로 해당 설정을 실행합니다. Android에서도 v2rayNG 또는 v2flyNG가 사용하는 코어와 실제 지원 범위를 확인해야 합니다.

직접 입력하기 전에 원본 링크의 프로토콜, 전송, 보안 필드를 간단히 목록으로 정리한 뒤 입력 후 하나씩 대조하세요. 클라이언트에 ‘저장됨’이라고 표시되어도 입력을 폼에서 받아들였다는 뜻일 뿐, 서버가 해당 조합을 처리할 수 있다는 보장은 없습니다. 코어 시작 단계에서 설정 오류가 발생하면 코어와 필드 지원을 먼저 확인하세요. 코어는 정상적으로 시작하지만 연결이 실패하면 서버 매개변수와 네트워크 경로를 살펴보세요. 시작 단계 오류에 대한 내용은 Xray 코어 시작 실패 문제 해결에서 이어서 확인할 수 있습니다.

5. V2Fly, Xray, 그래픽 클라이언트의 역할

같은 생태계의 서로 다른 코어 계열

Project V는 프로토콜, 설정 형식, 클라이언트 도구가 함께 발전하는 생태계를 이루었습니다. V2Fly는 V2Ray 프로젝트의 코어 계보를 이어가며, Xray는 독자적으로 발전한 코어 계열로 일부 프로토콜 확장, 전송, 보안 기능에서 자체 구현을 갖추고 있습니다. 공통된 역사와 유사한 설정 개념이 있지만, 이름만 다르고 기능은 완전히 같은 프로그램으로 볼 수는 없습니다. ‘VLESS 지원’이 VLESS의 모든 flow, 보안 유형, 확장 필드를 지원한다는 뜻도 아닙니다. 특히 새로운 보안 메커니즘과 전송 옵션은 구체적인 필드 조합을 기준으로 호환성을 판단해야 합니다.

그래픽 클라이언트는 서버 항목, 구독, 라우팅 설정을 코어에서 사용할 수 있는 설정으로 구성합니다. v2rayN은 Windows, macOS, Linux용으로 데스크톱에서 서버 편집, 구독 관리, 라우팅, 시스템 프록시 기능을 제공합니다. v2rayNG는 Xray 코어를 사용하는 Android 클라이언트이며, v2flyNG는 V2Fly 코어를 사용하는 Android 대안입니다. Android 클라이언트를 선택할 때 서버 설정이 Xray 전용 기능에 의존한다면 먼저 v2rayNG에서 해당 기능을 지원하는지 확인하세요. 기존 설정이 V2Fly 생태계에 맞춰져 있다면 v2flyNG와의 호환성을 살펴보세요. 클라이언트 이름은 프로토콜 이름이 아니며 서버 매개변수를 대신할 수 없습니다.

설정 호환성은 세 가지 계층으로 나뉩니다

첫째는 개념 호환성입니다. 두 코어가 ‘아웃바운드’, ‘라우팅 규칙’, ‘사용자 ID’ 같은 개념을 모두 알 수 있습니다. 둘째는 문법 호환성입니다. 같은 개념이라도 설정 파일의 필드, 허용 값, 기본 동작이 다를 수 있습니다. 셋째는 기능 호환성입니다. 코어가 특정 프로토콜을 파싱할 수 있어도 관련 확장을 모두 구현했다는 뜻은 아닙니다. 그래픽 클라이언트는 여기에 가져오기 파싱과 설정 변환을 추가합니다. 따라서 기본 코어 JSON, 공유 링크, 구독 텍스트는 포장 방식만 다른 완전히 동등한 형식이 아닙니다.

한 기기에서는 서버가 작동하지만 다른 기기에서는 그렇지 않다면 표시 이름만 비교하지 말고 양쪽 편집 상세 정보를 대조하세요. 프로토콜, 전송, 보안 유형, flow, 서버 이름, 인증 정보가 일치하는지 확인한 뒤 Android 클라이언트의 코어가 해당 값을 지원하는지 살펴보세요. 가져오는 과정에서 일부 필드가 무시되어도 인터페이스에 항목이 표시될 수 있고, 어떤 필드는 코어가 시작될 때 오류를 일으킵니다. ‘가져오기 성공’, ‘코어 시작 성공’, ‘애플리케이션 요청 성공’의 세 단계를 구분하면 문제 범위를 크게 줄일 수 있습니다.

라우팅 예시는 코어 설정이지 구독 링크가 아닙니다

아래 조각은 도메인에 따라 요청을 direct라는 이름의 아웃바운드 처리로 전달하는 라우팅 규칙을 보여줍니다. JSON 객체 조각이므로 같은 이름의 아웃바운드가 포함된 전체 코어 설정에 넣어야 의미가 있습니다. 클라이언트의 구독 주소 입력란에 붙여 넣으면 안 됩니다. 예시 도메인은 필드 위치를 설명하기 위한 것입니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy는 라우팅 판단에서 도메인을 처리하는 방식을 정합니다. type은 규칙 유형을 지정하고, outboundTag는 전체 설정에 존재하는 아웃바운드를 참조해야 합니다. 라우팅은 요청을 어느 아웃바운드로 보낼지 결정할 뿐 해당 아웃바운드에서 사용하는 서버 프로토콜은 바꾸지 않습니다. 도메인과 DNS 조회 결과를 함께 고려하는 규칙을 만들려면 DNS와 라우팅의 관계를 별도로 확인하세요. 자세한 내용은 V2Ray DNS 분할 라우팅 설정을 참고하세요. 라우팅을 바꾸기 전에 기본 연결을 정상화해 DNS 문제와 프로토콜 문제를 혼동하지 않도록 하세요.

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

첫 연결과 지속적인 데이터 전송은 다릅니다

‘속도’에는 연결 수립 시간, 첫 요청 응답 시간, 지속 전송 처리량이 포함됩니다. 프로토콜 계층의 캡슐화와 인증은 처리 비용에 영향을 줄 수 있지만, 첫 연결에는 DNS 조회, TCP 연결, TLS 또는 기타 보안 핸드셰이크, 전송 핸드셰이크, 네트워크 왕복 시간도 영향을 줍니다. WebSocket, gRPC 같은 전송 방식은 각각의 처리 단계를 추가합니다. 사용할지는 기존 서버 구조와 애플리케이션 요구 사항에 따라야 합니다. 연결이 수립된 뒤 대용량 파일을 전송할 때는 회선 대역폭, 혼잡, 서버 부하, 기기 성능이 주요 제한 요소일 수 있습니다. VMess, VLESS, Trojan이라는 이름만으로 절대적인 속도 순위를 매길 근거는 없습니다.

설정을 비교할 때는 조건을 동일하게 유지하세요. 같은 네트워크, 비슷한 시간대, 같은 서버 리소스, 같은 보안 계층과 전송 방식을 사용하고, 콜드 스타트와 이미 연결된 상태를 구분해야 합니다. 한 서버의 VLESS＋tcp 설정과 다른 서버의 Trojan＋TLS를 비교하면 관찰된 차이에는 서버 및 네트워크 차이도 포함되므로 프로토콜 탓으로 돌릴 수 없습니다. 클라이언트 인터페이스의 연결 상태는 해당 단계가 완료됐는지만 보여줍니다. 애플리케이션의 실제 요청 결과로 애플리케이션이 예상한 경로를 사용하는지 판단할 수 있습니다. 데스크톱 문제를 확인할 때는 시스템 프록시가 켜져 있는지, 애플리케이션이 시스템 프록시를 사용하는지도 점검하세요.

CPU와 메모리 사용량은 전체 처리 과정의 영향을 받습니다

코어는 연결을 처리하면서 암복호화, 프로토콜 캡슐화, 라우팅 규칙 비교, DNS 처리, 로그 기록을 수행합니다. 짧은 연결이 많으면 핸드셰이크와 DNS 비용이 두드러질 수 있고, 대량 데이터를 계속 전송하면 암호화와 데이터 복사의 비중이 커질 수 있습니다. 복잡한 라우팅 규칙, 상세한 로그 수준, 동시 연결 수 역시 리소스 사용량을 바꿉니다. VLESS의 프로토콜 계층이 비교적 간결하더라도 전체 설정에서 항상 CPU를 덜 사용하는 것은 아닙니다. 보안 유형과 전송 방식까지 함께 바꾸면 전체 처리 경로도 달라집니다. 리소스 사용량을 관찰할 때는 클라이언트가 실행 중인지 여부만 보지 말고 사용 중인 애플리케이션과 트래픽 유형을 기록하세요.

Android 배터리 사용량을 판단하는 방법

Android에서 v2rayNG와 v2flyNG를 실행하면 시스템 네트워크 인터페이스, 백그라운드 유지, 무선 네트워크 상태, 잦은 기기 깨우기가 배터리 사용량에 영향을 줄 수 있습니다. 프로토콜은 여러 요인 중 하나일 뿐입니다. 스트리밍이나 동기화를 계속하면 네트워크와 프로세서가 작동 상태를 유지합니다. 애플리케이션이 짧은 연결을 반복해서 만들면 기기를 깨우고 핸드셰이크하는 횟수가 늘 수 있습니다. 모바일 신호가 불안정해도 무선 모듈의 전력 소비가 증가할 수 있습니다. 따라서 특정 프로토콜이 반드시 배터리를 가장 적게 사용한다고 단정할 수 없습니다. 비교할 때는 같은 네트워크 환경과 비슷한 애플리케이션 부하를 유지하고 시스템 배터리 통계에서 실제 활동 시간을 확인하세요.

대기 중 배터리가 비정상적으로 빨리 줄어든다면 클라이언트가 트래픽을 계속 처리하는 경우와 시스템이 반복적으로 재연결하는 경우를 먼저 구분하세요. 구독 자동 업데이트 간격이 지나치게 짧게 설정되어 있는지, 백그라운드 애플리케이션이 계속 요청을 보내는지 확인한 다음 네트워크가 전환될 때 연결이 반복해서 수립되는지 살펴보세요. 사용량을 줄이려면 불필요한 상시 작업을 줄이고 시스템 백그라운드 실행 설정을 확인하며 서버 설정과 클라이언트 코어를 일치시키는 것부터 시작할 수 있습니다. 이런 조건은 그대로 둔 채 프로토콜만 바꾸면 원인을 분리하기 어려운 경우가 많습니다. 짧은 테스트 한 번으로 하루 전체의 배터리 사용량을 추정하지 마세요.

7. 구독과 공유 링크: 가져오기 성공이 필드 완전성을 뜻하지는 않습니다

자주 사용하는 입력 형식 세 가지 구분하기

클라이언트는 단일 공유 링크, 여러 링크를 모은 구독 텍스트, 서비스 제공자가 정의한 구조화 구독 콘텐츠를 받을 수 있습니다. 단일 링크는 대개 프로토콜 식별자로 시작하고 서버 필드를 포함합니다. 구독 주소는 콘텐츠를 가져오는 위치이며 그 안의 특정 서버와 같은 것이 아닙니다. 특정 클라이언트에서 읽도록 만든 설정 파일 형식도 있습니다. 웹 주소를 열 수 있다고 해서 v2rayN, v2rayNG, v2flyNG가 모두 같은 방식으로 파싱할 수 있는 것은 아닙니다. 가져오기 전에 제공자가 표시한 형식을 확인하고 클라이언트에서 해당 형식에 맞는 가져오기 메뉴를 선택하세요.

호환성에는 최소 두 가지가 포함됩니다. 클라이언트가 구독 텍스트를 인식하는지, 파서가 각 서버에 필요한 필드를 모두 보존하는지 확인해야 합니다. 목록에 항목이 보인다는 사실은 파서가 표시 가능한 정보를 일부 추출했다는 뜻일 뿐입니다. VLESS＋REALITY는 UUID, 전송, 보안 유형, 공개 키, 짧은 ID, 서버 이름, 필요한 경우 flow를 확인하세요. Shadowsocks는 method, 비밀번호, 플러그인 매개변수를 확인하고 Trojan은 비밀번호와 TLS 이름을 확인해야 합니다. 일괄 가져온 뒤에는 목록 첫 항목만 시험하지 말고 서로 다른 프로토콜의 대표 항목을 몇 개 골라 확인하세요. 형식 변환에서 누락된 필드를 더 잘 찾을 수 있습니다.

업데이트, 그룹, 수동 수정의 관계

구독 그룹은 출처별로 항목을 정리하고 업데이트 정책과 필터 규칙을 설정하는 데 사용됩니다. 업데이트하면 원격 콘텐츠를 다시 읽기 때문에 항목의 표시 이름과 매개변수가 모두 출처에 따라 바뀔 수 있습니다. 구독 항목을 직접 수정했을 때 다음 업데이트에서도 변경 사항이 유지되는지는 클라이언트의 처리 방식에 달려 있습니다. 따라서 구독 원본을 수정하거나 장기간 따로 관리할 항목을 구독에서 생성된 항목과 분리하는 편이 안전합니다. 필터 키워드는 목록 정리에만 영향을 줍니다. 프로토콜 매개변수를 수정하는 용도로 사용해서는 안 됩니다.

구독 주소를 받았지만 목록이 비어 있다면 먼저 주소에서 대상 클라이언트가 읽을 수 있는 콘텐츠가 반환되는지 확인하세요. 브라우저에서 열리는 안내 페이지만 반환될 수도 있습니다. 이어서 그룹 필터가 모든 항목을 제외하지 않았는지, 단일 공유 링크를 구독 주소로 잘못 입력하지 않았는지, 구독 콘텐츠가 다른 형식만 포함하지는 않는지 살펴보세요. 서버 주소를 추측해 항목을 만들어서는 안 됩니다. 원본 형식에 핵심 필드가 없다면 클라이언트가 표시 이름만으로 복원할 수 없습니다. 여러 출처를 섞어 사용한다면 그룹에 알아보기 쉬운 별칭을 지정해 항목의 출처를 추적하세요.

클라이언트를 옮길 때 공통 필드부터 확인하세요

데스크톱 v2rayN의 서버를 Android로 옮길 때는 대상 클라이언트가 명확히 지원하는 공유 링크나 구독 형식을 사용하고 가져온 뒤 편집 상세 정보를 확인하세요. 데스크톱 클라이언트의 라우팅 그룹, 시스템 프록시 설정과 Android의 앱별 프록시 설정은 각 클라이언트의 로컬 동작이므로 서버 공유 링크와 함께 옮겨지지 않습니다. 서버 매개변수가 같아도 기기에서 프록시를 적용할 범위는 각각 설정해야 합니다. v2flyNG를 사용할 경우 항목이 Xray 전용 기능을 요구하는지도 확인하세요. 현재 코어가 필요한 기능을 지원하지 않는다면 구독 텍스트 인코딩을 바꿔도 코어 기능을 추가할 수 없습니다.

안정적으로 이전하려면 두 단계로 진행하세요. 먼저 대상 기기에서 필드가 완전한 대표 항목 하나를 가져와 연결한 뒤 전체 그룹을 옮깁니다. 첫 항목이 실패하면 원본 링크와 가져온 뒤의 필드를 대조해 텍스트 파싱, 코어 시작, 애플리케이션 요청 중 어느 단계에서 문제가 생겼는지 확인하세요. 그룹이 많다면 구독 그룹과 노드 필터링 안내를 참고해 용도별 그룹을 명확히 정리한 뒤 업데이트 간격을 정하세요. 모든 항목을 반복해서 삭제하고 다시 가져오는 것보다 문제를 추적하기 쉽습니다.

8. 사용 환경에 맞게 선택하고 단계별로 검증하기

설정 출처를 먼저 확인하고 기기에 맞추세요

이미 서버나 구독을 사용 중이라면 먼저 출처에서 제공한 프로토콜과 전체 매개변수를 그대로 따라야 합니다. 선호하는 프로토콜 이름을 먼저 정한 다음 항목을 바꾸지 마세요. 데스크톱에서는 Windows, macOS, Linux 중 실제 운영체제에 맞는 설치 항목을 v2rayN에서 선택하세요. Android에서는 필요한 Xray 기능을 v2rayNG가 지원하는지 우선 확인하고, 기존 설정이 V2Fly 코어용이라면 v2flyNG가 적합한지 살펴보세요. 설치 링크는 클라이언트 다운로드 페이지에서 확인할 수 있습니다. 클라이언트를 선택한 뒤 서버가 요구하는 프로토콜, 전송, 보안 조합을 실제 코어에서 실행할 수 있는지 확인하세요.

서버를 직접 관리하면서 새 설정 유형을 결정해야 한다면 팀에서 이미 운영 중인 서버 기능, 기존 구독 출력 형식, 적용할 기기 범위를 고려하세요. REALITY가 필요하다면 먼저 선택한 코어와 클라이언트가 필드를 지원하는지 확인한 뒤 VLESS 설정을 계획하세요. 이미 안정적인 VMess나 Trojan 설정이 있다면 이름을 통일하려고 옮기기보다 각 필드를 명확히 문서화하는 편이 안전합니다. Shadowsocks를 선택할 때는 대상 클라이언트가 공통으로 지원하는 method를 미리 확인하세요. 어떤 방식을 선택하든 대표 항목 하나로 먼저 연결한 뒤 구독을 일괄 생성해야 합니다. 서버와 기기를 고려하지 않은 단독 ‘최고’ 프로토콜은 없습니다.

세 단계로 실패 원인 찾기

첫 번째는 가져오기 단계입니다. 항목이 표시되는지, 편집 상세 정보에 원본 설정의 핵심 필드가 포함되어 있는지 확인하세요. 두 번째는 코어 시작 단계입니다. 클라이언트 로그에 알 수 없는 필드, 잘못된 매개변수, 로컬 포트 사용 중 오류가 나타나는지 살펴보세요. 세 번째는 애플리케이션 요청 단계입니다. 코어가 시작된 뒤 대상 앱이 올바른 로컬 프록시 또는 시스템 프록시 설정을 사용하는지, 라우팅 규칙이 요청을 예상한 아웃바운드로 보내는지 확인하세요. 첫 단계에서 실패하면 구독 형식을, 두 번째 단계에서 실패하면 코어와 필드 조합을 점검하세요. 세 번째 단계에서 실패하면 시스템 설정, DNS, 라우팅, 애플리케이션 동작을 확인하면 됩니다. 모든 실패를 ‘프로토콜을 사용할 수 없음’으로 묶지 마세요.

데스크톱 브라우저와 터미널 명령줄은 서로 다른 프록시 설정을 사용할 수 있습니다. v2rayN 트레이 메뉴의 ‘시스템 프록시 자동 설정’은 주로 시스템 프록시를 따르는 애플리케이션에 영향을 줍니다. 터미널 도구에는 별도의 환경 변수나 애플리케이션별 설정이 필요할 수 있습니다. 브라우저에서는 되는데 터미널에서는 안 된다면 서버 프로토콜을 바로 바꾸기보다 각각 어떤 프록시 설정을 사용하는지 확인하세요. 자세한 순서는 macOS 시스템 프록시가 적용되지 않을 때를 참고하세요. 자주 묻는 설정은 자주 묻는 질문에서 항목별로 확인할 수 있습니다.

다시 확인할 수 있도록 설정을 기록하세요

대표 항목별로 프로토콜, 전송, 보안 유형, 코어 계열, 설정 출처를 기록하고 로그인에 사용할 수 있는 민감한 정보는 남기지 마세요. 구독을 업데이트하거나 코어를 바꾸거나 서버 설정을 변경한 뒤에는 이 항목들을 다시 대조하고 연결 동작을 확인하세요. 문제가 발생하면 관련 로그의 오류 유형과 변경 순서를 기록하고, 로그를 공유하기 전 주소, 인증 정보, 비밀번호 등을 삭제하세요. 이런 기록은 ‘어느 계층이 바뀌었는가’를 확인하는 데 도움이 됩니다. ‘전에는 됐는데 지금은 안 된다’고만 적는 것보다 문제를 찾기 쉽습니다.

라우팅 모드는 기본 연결을 확인한 다음 설정하세요. 먼저 올바른 서버 설정으로 클라이언트가 연결되는지 확인한 뒤 필요에 따라 로컬 네트워크 우회, 라우팅 규칙, DNS 조회를 설정하세요. 다른 기기가 컴퓨터의 로컬 프록시 포트를 공유하게 하려면 수신 주소와 시스템 방화벽도 설정해야 합니다. 서버 프로토콜만으로 공유 여부가 결정되지는 않습니다. 자세한 방법은 LAN 연결 허용 설정을 참고하세요. 한 번에 한 계층만 바꾸고 같은 애플리케이션으로 다시 테스트해야 결과를 해석할 수 있습니다.

이 순서는 직접 입력한 항목을 구독 관리로 옮길 때도 적용할 수 있습니다. 먼저 단일 연결을 확인하고, 다음으로 일괄 가져오기를 검증한 뒤 라우팅과 기기별 프록시 범위를 설정하세요. 처음 설정한다면 시작 가이드로 돌아가 인터페이스 안내를 따라 진행하세요. 연결은 이미 되지만 필드를 확인하고 싶다면 이 페이지의 해당 항목을 참고하면 됩니다. 프로토콜 선택, 코어 호환성, 애플리케이션 프록시를 나누어 점검하면 여러 설정을 한 번에 바꿔 원인을 놓치는 일을 줄일 수 있습니다.