V2Ray 프로토콜 및 코어 선택

1. 프로토콜·전송 방식·보안 계층 구분하기

클라이언트의 세 가지 설정은 서로 다른 항목입니다

프록시 설정에는 최소한 서버 주소, 포트, 인증 정보, 통신 방식이 포함됩니다. 프로토콜은 요청에서 대상 서버를 지정하고 사용자를 인증하며 데이터를 구성하는 방식을 정합니다. 전송 방식은 데이터가 어떤 연결 형태로 전달되는지 결정하고, 보안 계층은 통신 내용을 보호하고 연결 상대를 확인합니다. VMess, VLESS, Trojan, Shadowsocks는 프로토콜 이름입니다. TCP, WebSocket, gRPC는 주로 전송 설정에 표시되며 TLS와 REALITY는 보안 메커니즘입니다. 서로 다른 계층의 항목을 한데 묶어 속도를 비교해도 의미 있는 결론을 얻기 어렵습니다.

예를 들어 VLESS는 여러 전송 방식 및 보안 계층과 조합할 수 있으므로, 실제 성능을 ‘VLESS’라는 세 글자만으로 설명할 수 없습니다. TCP는 일반적으로 연결을 직접 전달하고, WebSocket은 업그레이드 핸드셰이크와 프레임 처리를 추가하며, gRPC는 HTTP/2 기반으로 데이터를 전달합니다. 조합에 따라 서버, 리버스 프록시, 클라이언트에 필요한 조건도 달라집니다. 클라이언트 화면에서 항목을 선택할 수 있다는 것은 해당 옵션을 제공한다는 뜻일 뿐, 서버에 필요한 접속 지점이 이미 설정되어 있거나 프로토콜과 전송 방식을 자유롭게 조합할 수 있다는 뜻은 아닙니다.

설정 한 개를 빠짐없이 설명하는 방법

두 연결을 비교할 때는 먼저 프로토콜, 전송 방식, 보안 계층, 흐름 제어, 코어를 기록한 다음 속도를 살펴보세요. 서버 위치, 기기 종류, 테스트에 사용한 앱도 함께 남겨야 합니다. 프로토콜 이름만 바꾸고 서버와 네트워크까지 동시에 바꾸면 차이가 어느 계층에서 생겼는지 알 수 없습니다. 구독에 표시된 메모는 보통 서비스 제공자가 입력한 내용이지, 기능을 확인한 결과가 아닙니다. 메모에 REALITY나 Vision이라고 적혀 있어도 실제 설정 항목과 시작 로그를 확인해야 합니다.

서버가 지원하는 기능에 맞춰 선택 범위 좁히기

이미 구독을 사용 중이라면 구독에 온전히 포함된 조합을 우선 사용하세요. VMess 노드를 VLESS로 바꿔 ‘업그레이드’하지 마세요. 프로토콜을 바꾸려면 서버 인바운드와 클라이언트 아웃바운드를 함께 조정해야 합니다. 한쪽만 바꾸면 양쪽에서 요청을 이해하지 못합니다. 서버를 직접 관리하는 경우에도 먼저 현재 설치 환경이 지원하는 프로토콜과 전송 방식을 확인한 다음 클라이언트를 선택하세요. 기존 서비스를 문제없이 사용하는 것이 목적이라면 드롭다운 메뉴에서 새로 추측하기보다 구독이 생성한 설정을 유지하는 편이 안전합니다.

문제 해결도 계층별 순서에 따라 진행하세요. 주소가 확인되지 않으면 도메인과 네트워크를 먼저 살펴보고, 포트 연결에 실패하면 서버의 수신 설정과 접근 가능 여부를 확인하세요. 보안 핸드셰이크가 실패하면 서버 이름, 시간, 인증 매개변수를 점검합니다. 연결은 됐지만 대상에 접근할 수 없다면 라우팅, DNS, 앱 프록시 설정을 확인하세요. 매 단계에서 관련된 항목만 조정하면 정상 설정까지 함께 망가뜨리는 일을 막을 수 있습니다. 구체적인 연결 문제는 연결 문제 해결에서 이어서 확인하세요.

2. VMess: 인증·암호화·이전 설정 이해하기

설계 목표와 기존 설정의 관계

VMess는 Project V 생태계에서 비교적 일찍 만들어진 프록시 프로토콜로, 사용자 인증과 데이터 보호를 주요 설계 요소로 삼습니다. 일반 연결에 비밀번호만 추가하는 방식이 아니라 요청 정보와 데이터 흐름을 구성하는 방법도 정의합니다. 오랫동안 사용되며 여러 클라이언트, 구독, 가이드에 널리 등장한 만큼 과거 설정 항목도 남아 있습니다. 오래된 가이드를 참고할 때는 당시 설정 방법과 현재 코어가 여전히 지원하는 항목을 구분해야 합니다. 화면에 같은 이름이 보인다는 이유만으로 설정을 그대로 적용해서는 안 됩니다.

VMess의 사용자 식별 정보에는 일반적으로 UUID가 사용됩니다. UUID는 서버 주소가 아니며 다른 노드의 사용자 식별 정보와 바꿔 쓸 수 없습니다. 주소, 포트, 인증 정보가 모두 일치해도 전송 방식과 보안 계층까지 맞아야 합니다. ‘UUID만 맞으면 연결돼야 한다’고 생각하기 쉽지만, 서버는 WebSocket을 받도록 설정되어 있고 클라이언트가 직접 TCP 요청을 보내면 정상적으로 통신할 수 없습니다. 프로토콜 인증이 올바르다는 것은 전체 연결 과정 중 한 단계만 통과했다는 뜻입니다.

시간과 오래된 설정 항목이 문제를 일으키는 이유

VMess 인증에는 시간이 관여하므로 기기의 시스템 시간이 크게 어긋나면 인증에 실패할 수 있습니다. 가져오기는 됐지만 계속 인증 오류가 발생한다면 사용자 식별 정보를 반복해서 바꾸기보다 시스템의 자동 시간 설정을 켜고 시간대 표시와 실제 시간이 맞는지 확인하세요. 시간대는 주로 표시 방식에 영향을 주며, 실제로 중요한 것은 시스템 시계의 정확성입니다. 서버 시간도 정상이어야 합니다. 클라이언트 시간만 맞춰도 서버 시간이 틀리면 문제가 해결되지 않습니다.

오래된 자료에는 alterId, 즉 추가 식별자와 관련된 과거 설정이 자주 등장합니다. 최신 설정에서는 일반적으로 값이 0이며 이에 맞는 AEAD 인증 방식을 사용합니다. 오래된 가이드와 호환하려고 값을 임의로 높이거나, 구독에 포함된 과거 설정을 다른 코어에 그대로 옮기지 마세요. 가져오기 도구에서 지원되지 않는다고 표시되면 설정 제공자에게 현재 유효한 VMess 매개변수를 먼저 확인한 뒤 클라이언트와 코어의 파싱 결과를 살펴보세요. 오래된 항목을 인식하지 못한다고 해서 서버를 반드시 사용할 수 없는 것은 아닙니다.

프로토콜 암호화와 외부 TLS는 별도로 확인하세요

VMess의 암호화 옵션과 외부 TLS는 서로 다른 계층입니다. 화면의 자동 선택은 일반적으로 코어가 지원 여부에 따라 구체적인 알고리즘을 선택한다는 뜻이지, ‘노드 전체를 자동으로 설정’한다는 뜻이 아닙니다. 알고리즘을 직접 지정하려면 양쪽에서 해당 구현을 지원해야 합니다. 프로세서마다 하드웨어 가속 지원이 달라 처리 비용에도 차이가 생길 수 있습니다. 특정 알고리즘 하나가 모든 기기에서 가장 빠르다고 단정할 수 없습니다. 외부 TLS에는 자체 핸드셰이크, 서버 인증, 인증서 체인 요건이 있으므로 내부 암호화만으로 이를 대체할 수 없습니다.

WebSocket은 경로와 Host를, gRPC는 서비스 이름 등의 전송 매개변수를 확인해야 합니다. 이런 항목은 전송 설정에 속하며 UUID나 암호화 옵션에 입력하면 안 됩니다. 경로는 보통 대소문자를 구분하므로 앞에 붙는 슬래시, 대소문자, 추가 문자가 모두 일치해야 할 수 있습니다. 리버스 프록시가 특정 경로만 전달하도록 설정되어 있다면 주소와 포트에 연결되더라도 요청이 일반 웹페이지로 전달될 수 있습니다. 이 경우 핸드셰이크 오류가 발생하거나 연결이 즉시 끊어질 수 있습니다.

VMess를 계속 사용해도 되는 경우

기존 VMess 서비스가 안정적으로 작동하고 클라이언트가 필요한 기능을 모두 지원하며 새 기능이 필요한 이유도 없다면 계속 사용해도 됩니다. 프로토콜을 옮기려면 인바운드, 구독 생성, 클라이언트 호환성을 다시 확인해야 합니다. 드롭다운 옵션 하나만 바꾸는 작업이 아닙니다. 이름의 신구보다 현재 조합의 안정성, 유지 관리 비용, 기기 부하를 비교하는 것이 중요합니다. 서비스 제공자가 새 설정을 완전히 제공했다면 기존 설정을 비교 기준으로 남겨 두고 두 설정을 따로 테스트하세요. 웹 탐색, 파일 전송, UDP 사용이 모두 만족스러운지 확인한 뒤 전환하면 됩니다.

3. VLESS: 경량 프로토콜이라고 보안 설정이 완성되는 것은 아닙니다

프로토콜 역할을 줄인 설계의 장단점

VLESS는 프록시 요청 표현과 외부 보안 메커니즘을 분리해 경량화를 강조하는 프로토콜입니다. VMess와 달리 자체 데이터 암호화 설계를 사용하지 않으며, 기본 설정에서는 일반적으로 TLS나 REALITY 같은 외부 보안 계층으로 통신을 보호합니다. 따라서 ‘프로토콜 자체의 오버헤드가 적다’는 말과 ‘연결 전체가 암호화되지 않는다’는 말은 같은 뜻이 아닙니다. 실제 보호 방식은 노드 유형만 볼 것이 아니라 전체 조합을 확인해야 합니다. 이름에 경량이라는 의미가 있다고 해서 외부 보안 설정을 생략해서도 안 됩니다.

사용자 식별 정보에는 보통 UUID를 사용하지만 VMess와 VLESS는 요청 형식이 다릅니다. 두 프로토콜에 모두 사용자 식별 정보가 있다고 해서 서로 바꿔 쓸 수 있는 것은 아닙니다. 일반적인 기본 설정에서 VLESS 공유 링크의 encryption 매개변수는 none이며, 이는 프로토콜 자체 암호화가 활성화되지 않았다는 뜻입니다. TLS나 REALITY를 끄라는 의미가 아닙니다. 클라이언트에서 다른 확장 기능을 제공하더라도 구체적인 코어와 서버 구현에서 지원되는지 확인해야 합니다. 기본 항목만으로 지원 여부를 판단할 수 없습니다.

보안 계층과 흐름 제어를 각각 확인하기

TLS를 사용한다면 서버 이름이 인증서의 신원과 일치하고 기기가 인증서 체인을 신뢰하는지 확인하세요. 연결 주소는 도메인이나 IP일 수 있지만, 인증에 사용하는 이름은 서버 설정 안내에 따라야 합니다. ‘이 IP에 연결할 수 있다’고 해서 ‘이 IP가 올바른 인증서 이름이다’라는 뜻은 아닙니다. 일부 서버는 서버 이름을 별도 항목에 입력해야 합니다. 클라이언트가 주소에서 이름을 자동으로 추론하더라도 해당 서버 설정에 맞지 않을 수 있습니다. 입력할 때는 연결 대상과 인증할 신원을 구분하세요.

flow는 별도로 이해해야 하는 매개변수입니다. 흔히 쓰이는 xtls-rprx-vision은 전송 유형도 아니고 모든 VLESS 연결에 적용되는 속도 옵션도 아닙니다. 호환되는 코어 기능, 서버 설정, 지원되는 전송 방식이 필요합니다. 해당 기능을 사용하지 않는 노드에 flow를 억지로 추가하면 인증이나 데이터 처리에 실패할 수 있습니다. 반대로 서버에서 특정 흐름 제어를 요구하는데 가져오기 과정에서 누락되면 노드가 제대로 작동하지 않을 수도 있습니다.

클라이언트 화면에서 항목 확인하기

v2rayN에서 노드 편집 창을 확인할 때는 ‘주소와 인증 정보, 전송 방식, 보안 계층, 흐름 제어’ 순서로 살펴보세요. v2rayNG에서도 같은 순서를 따르면 여러 설정 화면을 오가며 추측하지 않아도 됩니다. 먼저 원본 설정을 저장한 뒤 한 항목씩 변경하세요. 구독에서 가져온 노드는 다음 업데이트 때 수동 변경 내용이 덮어써질 수 있습니다. 테스트용 사본을 별도 위치에 두고 변경 이유를 기록하세요. 구독에서 생성된 기준 설정을 바로 덮어쓰지 않는 것이 좋습니다.

가져온 뒤 화면에 표시되는 항목이 코어에 전달되는 최종 설정과 일치하지 않을 수도 있습니다. 클라이언트가 기본값을 채우거나 화면 항목을 다른 내부 구조로 변환할 수 있습니다. 설정이 올바른지 판단하려면 설정 생성 안내와 시작 로그를 함께 확인하세요. 알 수 없는 항목이나 지원되지 않는 흐름 제어 오류가 나오면 즉시 항목을 삭제하지 말고 먼저 코어와 설정 조합을 살펴보세요. 오류 메시지는 현재 파싱 단계의 문제를 가리킵니다. 원인은 매개변수 오타가 아니라 코어 불일치일 수 있습니다.

적용 범위와 전환 여부 판단

VLESS는 해당 서버가 이미 준비되어 있고 외부 보안 및 흐름 제어 조합을 직접 관리하려는 경우에 적합합니다. 다른 프로토콜보다 지연 시간이 짧다고 보장하지는 않습니다. 특히 노드마다 서버 경로가 다르면 네트워크 경로 차이가 더 크게 작용할 수 있습니다. 앱이 짧은 연결을 많이 만들면 외부 핸드셰이크와 연결 재사용이 체감 성능에 큰 영향을 줍니다. 대용량 파일을 오래 전송한다면 지속 처리량, 프로세서 사용량, 서버 부하를 더 주의 깊게 살펴보세요. 두 사용 환경은 각각 검증해야 합니다.

VMess에서 VLESS로 바꿀 때는 먼저 완전한 새 설정을 받은 다음 이름 확인, 일반 웹페이지, 장시간 연결, 필요한 UDP 앱을 테스트하세요. 웹페이지가 한 번 열린 것만 확인하고 기존 그룹을 삭제하지 마세요. 새 설정에 REALITY나 Vision이 포함되어 있다면 구독 형식에서 관련 항목이 모두 유지되는지도 확인해야 합니다. 두 프로토콜의 배경과 장단점은 프록시 프로토콜 비교에서 살펴볼 수 있지만 실제 연결에는 서버가 제공한 설정을 사용해야 합니다.

4. REALITY와 Vision: 핸드셰이크와 데이터 흐름의 역할

REALITY는 독립된 프록시 프로토콜이 아닙니다

REALITY는 보안 메커니즘이며 VLESS와 함께 사용하는 경우가 많습니다. Vision은 관련 데이터 흐름을 처리하는 메커니즘입니다. 노드 메모에 ‘REALITY 프로토콜’이라고 함께 적는 경우가 흔하지만 설정할 때는 각각의 역할을 구분해야 합니다. 프록시 요청은 VLESS 같은 프로토콜로 표현하고, REALITY는 관련 보안 핸드셰이크와 인증을 담당하며, Vision은 지원 조건에 맞는 데이터 흐름을 처리합니다. 세 기능의 역할은 서로 다릅니다. 프록시 프로토콜 유형에 REALITY를 입력한다고 나머지 항목을 자동으로 알 수 있는 것은 아닙니다.

REALITY는 TLS 관련 메커니즘을 활용하고 자체 인증 매개변수를 사용합니다. 일반적인 배포에서는 프록시 서버에 일반 웹사이트 TLS와 같은 공개 인증서 절차를 그대로 적용할 필요가 없지만, 그렇다고 클라이언트에서 신원 확인을 생략해도 된다는 뜻은 아닙니다. 클라이언트에 올바른 공개 키, 서버 이름, 짧은 ID 등의 정보가 필요합니다. 서버 측에서 선택한 대상과 동작에도 제약이 있습니다. 접속 가능한 웹사이트를 아무거나 고르면 안정적인 설정이 되는 것은 아닙니다. 클라이언트를 설정할 때는 이미 구성된 전체 매개변수를 사용하세요.

혼동하기 쉬운 인증 항목

서버 이름은 보통 serverName 또는 공유 링크의 sni로 표시되며 서버가 허용하는 이름과 일치해야 합니다. 공개 키는 서버가 보유한 개인 키와 짝을 이루는 키입니다. 클라이언트에서 서버 개인 키를 요청하거나 입력해서는 안 됩니다. 짧은 ID인 shortId는 서버에서 허용한 ID와 일치해야 하며, 보통 16진수 문자열로 표시됩니다. 길이와 내용은 코어 제약을 따라야 합니다. 임의의 메모가 아니며 UUID 일부를 잘라 대신 쓸 수도 없습니다. 일부 설정에서는 특정한 빈 값을 허용하지만, 서버에서 그렇게 설정했다고 명시한 경우에만 사용할 수 있습니다.

핑거프린트 설정은 관련 핸드셰이크에서 클라이언트가 보이는 방식을 지정하므로 현재 코어가 지원하는 항목을 선택해야 합니다. 임의로 바꿀 수 있는 기기 이름도 아니며, 덜 흔한 항목이 더 효과적인 것도 아닙니다. 일부 공유 링크에서는 fp, pbk, sid 같은 약어를 사용하고 클라이언트 화면에는 한국어 항목명으로 표시될 수 있습니다. 가져온 뒤에는 이름이 같은지보다 의미에 따라 각각 대응하는지 확인하세요. 코어가 업데이트되면서 항목 이름이 달라질 수도 있으므로 오래된 가이드가 현재 코어 설명을 대신할 수는 없습니다.

Vision이 줄이는 오버헤드

일반 HTTPS 앱 데이터는 이미 TLS로 보호되어 있습니다. 여기에 프록시 보안 계층까지 적용하면 중첩 처리가 발생합니다. Vision은 지원되는 데이터 흐름을 식별하고 처리하는 과정을 최적화해 조건이 맞을 때 일부 중복 캡슐화와 복사 비용을 줄입니다. 앱 자체의 HTTPS를 제거하는 기능은 아니며 모든 트래픽이 같은 최적화 경로를 사용하는 것도 아닙니다. 요청 유형, 연결 단계, 코어 구현, 서버 구성에 따라 실제 효과가 달라지므로 이론상의 이점을 고정된 속도 배수로 환산할 수 없습니다.

요청량이 적다면 DNS 조회, 연결 설정, 네트워크 왕복에 대부분의 시간이 들 수 있어 데이터 처리량을 줄여도 페이지 첫 로딩이 크게 달라지지 않을 수 있습니다. 대용량 데이터를 지속해서 전송할 때 프로세서가 병목이라면 최적화 효과가 더 잘 나타날 수 있습니다. 기기 부하가 낮은데 서버 경로가 혼잡하다면 흐름 제어를 바꿔도 대역폭 제한을 우회할 수 없습니다. 앱 작업 완료 시간, 프로세서 부하, 연결 안정성을 함께 확인하고 클라이언트에 표시되는 지연 시간 하나만 보지 마세요.

핸드셰이크 실패 시 확인 순서

먼저 해당 조합을 지원하는 Xray 코어를 사용 중인지 확인한 다음 주소, 포트, UUID, 보안 유형, 공개 키, 짧은 ID, 서버 이름, flow를 점검하세요. 한 번에 한 항목만 수정하거나 복원하고 로그에 기록된 원래 오류 유형을 보존하세요. 시간 초과는 먼저 연결 가능 여부를 확인하고, 인증 실패는 관련 매개변수 전체를 점검합니다. 지원되지 않는 항목 오류라면 코어와 가져오기 형식을 확인하세요. 자세한 원리는 REALITY 및 XTLS Vision 안내에서 확인할 수 있습니다. 서버에 해당 접속 지점이 없다면 클라이언트만으로 이 조합을 활성화할 수 없습니다.

5. Trojan과 Shadowsocks: 서로 다른 두 가지 간소화 방식

Trojan은 TLS를 기반으로 연결을 보호합니다

Trojan은 TLS로 연결을 보호하고 그 안에서 프록시 인증과 요청 전달을 처리합니다. 일반적으로 VMess나 VLESS에서 자주 쓰는 UUID가 아니라 비밀번호를 입력합니다. 이 비밀번호는 프록시 서비스 인증 정보이며 시스템 로그인 비밀번호나 웹사이트 계정 비밀번호와는 다릅니다. 클라이언트와 서버는 전송 방식과 보안 매개변수도 동일하게 설정해야 합니다. 노드가 비밀번호 인증을 사용하더라도 비밀번호만 맞으면 서버 이름이나 인증서 검증을 무시해도 된다는 뜻은 아닙니다.

Trojan의 실제 연결 성능은 TLS 설정 품질과 밀접한 관련이 있습니다. 인증서 만료, 이름 불일치, 잘못된 시스템 시간, 불완전한 인증서 체인이 연결을 막을 수 있습니다. 이런 문제가 생기면 먼저 서버 정보와 기기 시간을 확인하세요. 안전하지 않은 연결 허용을 계속 켜 두면 서버 신원 확인이 약해지고 설정 오류가 가려집니다. 인증서 문제를 찾는 데 임시 테스트가 도움이 되더라도 마지막에는 서버 이름이나 인증서 체인을 수정해야 합니다. 테스트 상태를 정상 설정으로 남겨 두지 마세요.

Shadowsocks의 핵심은 암호화된 트래픽 전달입니다

Shadowsocks는 보통 SS라고 줄여 부르며, 암호화 프록시 전달에 필요한 설정을 비교적 간단하게 구성합니다. 일반적인 항목은 서버, 포트, 비밀번호, 암호화 방식입니다. TLS 기반 조합과 캡슐화 및 인증 방식이 다르므로 TLS의 서버 이름 항목을 그대로 가져와 입력해서는 안 됩니다. 추가 전송 확장이 필요하지 않은 서버라면 설정 항목이 적어 입력 오류를 줄일 수 있습니다. 다만 사용 목적에 맞는지는 클라이언트, 코어, 서버가 구체적인 암호화 방식을 모두 지원하는지에 달려 있습니다.

구형 방식, AEAD 방식, 최신 프로토콜 변형은 서로 호환되지 않을 수 있습니다. 특히 일부 최신 방식은 키의 형식과 길이를 엄격히 요구하므로 임의의 문자열 비밀번호를 입력한다고 사용할 수 있는 것은 아닙니다. ‘SS’라는 이름만 보고 모든 구현이 완전히 호환된다고 가정하지 마세요. 가져오기 과정에서 암호화 방식이 지원되지 않는다고 나오면 전체 방식 이름과 현재 코어의 지원 여부를 확인하세요. 이름이 비슷한 항목을 임의로 대체해서는 안 됩니다. 양쪽에서 서로 다른 방식을 사용하면 통신을 복호화할 수 없습니다.

비밀번호·인코딩·확장 매개변수의 주의점

공유 링크는 구분 기호나 특수 문자로 값이 잘못 나뉘지 않도록 비밀번호와 다른 항목을 인코딩할 수 있습니다. 직접 복사할 때 인코딩된 문자열이 잘리거나 공백이 추가되거나 이미 디코딩된 값을 다시 디코딩하면 실제 인증 정보가 달라질 수 있습니다. 우선 클라이언트의 기본 가져오기 기능을 사용한 다음 화면에 표시된 항목을 확인하세요. 서버에 추가 전송 확장이 필요하다면 서버 주소와 비밀번호만으로는 부족할 수 있습니다. 현재 코어가 해당 확장을 구현하는지도 확인해야 합니다. 노드 메모에 적힌 이름만으로 지원 여부를 추측할 수 없습니다.

Trojan과 Shadowsocks는 UDP를 지원할 수 있지만, 프로토콜이 UDP를 지원한다고 해서 앱의 UDP 트래픽이 클라이언트로 전달되는 것은 아닙니다. 로컬 인바운드, TUN 또는 시스템 네트워크 가로채기 방식과 서버 측 전달 허용 여부도 확인해야 합니다. 웹페이지는 정상인데 실시간 음성이 작동하지 않는다면 비밀번호부터 바꾸지 마세요. 앱이 어떤 전송 방식을 사용하는지, 클라이언트가 해당 트래픽을 처리하는지, 라우팅이 예상한 아웃바운드로 전달하는지 먼저 살펴본 뒤 서버와 응답 경로를 확인하세요.

이름 순위가 아니라 현재 서버 설정에 맞춰 선택하기

이미 운영 중인 TLS 서비스와 완전한 Trojan 설정이 있다면 Trojan으로 기존의 명확한 인증서 관리 절차를 이어갈 수 있습니다. 기기 리소스가 제한적이고 서버가 호환되는 Shadowsocks 방식을 제공한다면 실제 성능을 먼저 확인해 볼 수 있습니다. 서버 경로, 암호화 구현, 앱 사용 목적을 함께 보지 않고 둘 중 하나가 더 낫다고 판단할 수는 없습니다. 일반 사용자에게는 더 고급스러워 보이는 이름보다 설정이 완전하고 코어가 지원하며 필요한 작업을 안정적으로 수행하는 것이 중요합니다.

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

연결 설정과 지속 전송을 구분하세요

사용자가 체감하는 ‘속도’에는 DNS 조회, 연결 설정, 첫 데이터 수신 대기 시간, 지속 처리량 등이 포함됩니다. 클라이언트의 지연 시간 테스트는 방식에 따라 이 중 일부만 측정할 수 있습니다. 특정 포트에 빠르게 응답한다고 대상 웹페이지도 빠른 것은 아니며, 웹페이지가 빨리 열려도 대용량 파일을 계속 빠르게 전송할 수 있다는 뜻은 아닙니다. 프로토콜을 비교하기 전에 목적을 정하세요. 페이지 로딩 대기를 줄일지, 지속 전송 효율을 높일지, 백그라운드 연결 유지에 따른 배터리 소모를 줄일지 구분해야 합니다.

TCP, TLS, 추가 전송 핸드셰이크는 연결 설정 단계에서 주고받는 횟수를 늘릴 수 있습니다. 연결 재사용과 세션 재개는 반복되는 비용을 줄이는 데 도움이 될 수 있지만, 실제 효과는 구현 방식과 연결 수명에 따라 달라집니다. WebSocket과 gRPC도 단순히 느리거나 빠르다고 단정해서는 안 됩니다. 추가 구조를 도입하는 대신 특정 서버 구성 및 연결 관리 요구를 충족할 수도 있습니다. 왕복 시간이 긴 네트워크에서는 한 번 더 통신하는 비용이 암호화 알고리즘의 작은 차이보다 크게 느껴질 수 있습니다. 지연 시간이 낮은 네트워크에서는 병목이 프로세서나 서버 대역폭으로 옮겨갈 수 있습니다.

전체 처리 경로에서 발생하는 리소스 사용량

프로세서 부하는 암호화 알고리즘, 하드웨어 가속, 캡슐화 계층 수, 연결 수, 트래픽 규모의 영향을 받습니다. 메모리 사용량에는 클라이언트 화면, 구독 기록, DNS 캐시, 연결 버퍼, 로그도 포함되므로 모두 프로토콜 헤더 탓으로 돌릴 수 없습니다. 한 연결에서 오버헤드가 적은 조합이라고 해도 동시 연결을 많이 열었을 때 계속 리소스를 덜 사용하는 것은 아닙니다. 비교할 때는 같은 클라이언트와 비슷한 백그라운드 작업, 동일한 테스트 내용을 사용하세요. 화면 렌더링이나 다른 앱 때문에 측정 결과가 달라질 수 있습니다.

멀티플렉싱은 여러 논리 연결이 하나의 하위 연결을 공유하도록 하지만 혼잡, 오류 복구, 연결 수명에 영향을 줍니다. 적절한 환경에서는 연결을 반복해서 만드는 비용을 줄일 수 있지만, 네트워크 패킷 손실이나 연결 중단이 발생하면 여러 요청이 한꺼번에 영향을 받을 수도 있습니다. 멀티플렉싱 옵션을 만능 가속기로 취급하거나 특정 설정을 Vision 조합에 그대로 적용하지 마세요. 먼저 기본 설정을 유지하고 현재 코어의 지원 여부와 앱 사용 목적을 확인한 뒤 비교 테스트를 진행하세요.

휴대폰 배터리는 프로토콜만으로 예측할 수 없습니다

모바일 기기의 전력 소모는 무선 네트워크 깨우기, 신호가 약할 때의 재전송, 잦은 연결 확인, 백그라운드 업데이트, 앱 활동에 영향을 받습니다. 작은 트래픽을 계속 보내도 무선 모듈이 저전력 상태로 전환되지 못할 수 있습니다. 반대로 시스템에서 연결을 계속 종료해 반복적으로 다시 연결하면 추가 작업이 늘어납니다. 따라서 ‘백그라운드에서 계속 연결 유지’와 ‘최소 전력 사용’ 사이에는 절충이 필요합니다. 시스템 배터리 정책, 사용 빈도, 앱의 상시 연결 필요 여부를 함께 고려하세요.

v2rayNG에서는 시스템 VPN 인터페이스가 앱 트래픽을 받아오지만 모든 앱에서 같은 양의 트래픽이 발생하는 것은 아닙니다. 전체 트래픽 가로채기, 앱별 제외 설정, 백그라운드 앱 동작에 따라 배터리 소모가 달라집니다. 배터리가 비정상적으로 빨리 닳으면 먼저 시스템 배터리 사용량을 확인하고 잦은 재연결, 자동 테스트, 과도한 로그가 있는지 살펴보세요. 절전을 위해 모든 백그라운드 권한을 한 번에 끄면 화면이 꺼진 뒤 연결이 끊길 수 있습니다. 화면을 끄고 대기할 때, 앱을 사용하며 탐색할 때, 네트워크를 전환할 때를 나누어 테스트하세요.

반복 가능한 방식으로 비교하기

두 가지 완전한 설정을 준비하고 같은 기기와 네트워크에서 같은 작업을 번갈아 테스트하세요. 콜드 스타트 여부, 연결 재사용 여부, 테스트 당시 네트워크 상태를 기록합니다. 먼저 짧은 웹 요청을 시험하고 이어서 지속 다운로드를 진행한 뒤 평소 사용하는 앱의 백그라운드 동작을 관찰하세요. 각 테스트를 여러 번 반복하고 업데이트, 클라우드 동기화, 다른 대용량 작업은 제외하세요. 두 TUN 설정을 동시에 실행해 비교하지 마세요. 라우팅 경합이 결과에 영향을 주고 한 클라이언트의 트래픽이 다른 클라이언트를 거칠 수도 있습니다.

7. V2Fly와 Xray: 설정이 비슷해도 바로 바꿔 쓸 수는 없습니다

클라이언트 화면과 실행 코어의 역할

Project V는 이 생태계를 이해하는 배경이며, V2Fly와 Xray는 관련 코어 계열에서 각기 다른 방향으로 발전해 왔습니다. 클라이언트는 구독 관리, 그래픽 설정, 시스템 프록시, 실행을 담당하고 코어는 설정을 읽어 실제 연결을 처리합니다. 두 역할을 혼동해서는 안 됩니다. v2rayN이라는 화면 이름만으로 특정 코어만 실행한다고 볼 수 없습니다. 화면에 프로토콜 목록이 있다고 해서 현재 선택된 코어가 모든 옵션을 구현했다는 뜻도 아닙니다. 실제 기능은 실행 중인 코어와 생성된 설정에 따라 결정됩니다.

두 코어 계열은 인바운드, 아웃바운드, 라우팅 등 비슷한 설정 개념을 일부 공유하지만 기능 발전 방향과 항목 제약은 완전히 같지 않습니다. Xray 생태계의 REALITY와 Vision 기능은 설정 파일이 모두 JSON이라는 이유만으로 V2Fly에 그대로 전달할 수 없습니다. 반대로 일부 V2Fly 설정 방식도 Xray에서 같은 의미로 작동하는지 확인해야 합니다. 호환성을 판단할 때는 ‘둘 다 V2Ray 생태계에 속한다’는 점에 그치지 말고 프로토콜, 전송 방식, 보안 계층, 세부 항목을 확인하세요.

클라이언트 세 가지 중 선택하기

Windows, macOS, Linux 데스크톱에서는 구독 관리, 로그 확인, 라우팅 조정에 적합한 v2rayN을 우선 선택하세요. Android에서는 일반적으로 Xray 계열 기반의 v2rayNG를 먼저 사용합니다. 기존 설정이 V2Fly 동작에 명확히 의존한다면 대안으로 v2flyNG를 고려할 수 있습니다. 이름이 비슷한 두 모바일 클라이언트는 화면만 다른 동일한 실행 환경이 아닙니다. 다운로드 전 플랫폼별 다운로드를 확인하고, 기능 비교는 세 클라이언트 비교에서 살펴보세요.

코어를 전환하는 작업은 실행 파일 하나만 바꾸는 것이 아닙니다. 클라이언트는 코어별로 서로 다른 설정 항목을 생성하거나 특정 프로토콜 옵션을 제한할 수 있습니다. 시작에 실패하면 현재 코어 이름과 오류 로그를 먼저 확인한 다음 노드에 필요한 기능을 점검하세요. 화면은 업데이트됐는데 실행 코어가 다른 환경에 남아 있으면 가져오기와 설정 생성은 성공하고 시작 단계에서만 오류가 발생할 수 있습니다. 클라이언트에서 지원하는 관리 방법으로 조정하고 경로와 실행 관계를 파악하지 못한 채 파일을 임의로 섞어 두지 마세요.

공통 구조로 설정 구성 이해하기

아래 예시는 로컬 기기에서만 접속할 수 있는 SOCKS 인바운드와 직접 연결 아웃바운드로 구성되어 있으며, 인바운드와 아웃바운드의 기본 관계를 보여줍니다. 원격 프록시 서버에 연결하지 않으며 노드 인증 정보도 포함하지 않습니다. 설정 파일로 저장하기 전에 대상 코어에서 이 항목을 지원하는지 확인해야 합니다. 이 최소 구조를 보면 인바운드는 앱 요청을 받고 아웃바운드는 외부로 보내는 방법을 결정한다는 점을 알 수 있습니다. 원격 프록시를 사용하려면 해당 아웃바운드를 서버 설정과 일치하는 완전한 구성으로 바꿔야 합니다.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

이 예시는 루프백 주소로 수신 범위를 제한합니다. LAN에 연결된 주소로 바꾸려면 접근 제어와 시스템 방화벽도 함께 고려해야 합니다. 인증 없이 접근 범위를 넓히면 안 됩니다. 포트는 실행 중인 다른 클라이언트와 겹치지 않아야 합니다. 겹치면 주소가 이미 사용 중이라는 오류가 발생합니다. 설정 파일 구조와 클라이언트 화면 항목의 관계는 inbounds, outbounds, routing 해설에서 이어서 확인하세요.

두 단계로 나누어 전환 확인하기

첫 번째 단계에서는 노드 하나와 가장 단순한 라우팅만 사용해 코어가 시작되고 앱에 접근할 수 있는지 확인하세요. 두 번째 단계에서 DNS, 분할 라우팅, 멀티플렉싱, 기타 사용자 지정 설정을 복원합니다. 이렇게 하면 프로토콜 지원 문제와 추가 규칙 문제를 구분할 수 있습니다. 알 수 없는 항목이 나오더라도 시작될 때까지 여러 항목을 연달아 삭제하지 마세요. 삭제한 항목이 필수 보안이나 라우팅 기능을 담당할 수 있습니다. 먼저 해당 항목이 어떤 코어와 기능에 속하는지 확인한 뒤 대상 코어에서 지원하는 방식으로 변환하세요. 동등한 방식으로 바꿀 수 없는 기능은 기존 환경에서 사용해야 합니다.

8. 구독 형식 호환성과 사용 환경에 맞는 선택

공유 링크·구독 데이터·실행 설정

단일 노드 공유 링크는 연결 하나를 설명합니다. 구독 주소는 지속적으로 업데이트될 수 있는 여러 연결 정보를 가져오는 데 사용하며, 코어 실행 설정에는 인바운드, 라우팅, DNS 등의 실행 옵션도 포함됩니다. 이 세 가지는 서로 다른 형식입니다. 구독 주소를 단일 노드 가져오기 창에 붙여 넣거나 전체 실행 설정을 공유 링크로 가져오면 실패할 수 있습니다. 문제를 해결하기 전에 보유한 데이터의 종류부터 파악하고 클라이언트에서 해당하는 가져오기 메뉴를 선택하세요. 기본 절차는 구독 가져오기 안내를 확인하세요.

흔히 사용하는 공유 링크 형식으로 vmess://, vless://, trojan://, ss://가 있습니다. 형식마다 인코딩, 매개변수 이름, 확장 항목을 표현하는 방식이 다릅니다. 같은 프로토콜에도 과거 방식의 공유 링크가 여럿 있을 수 있으므로 브라우저에서 열린다거나 텍스트가 완전해 보인다는 이유만으로 클라이언트가 파싱할 수 있다고 단정할 수 없습니다. 구독은 요청한 클라이언트에 따라 다른 데이터를 반환할 수도 있습니다. 주소는 유효하지만 현재 클라이언트와 형식이 맞지 않으면 파일 확장자를 바꾸지 말고 제공자에게 호환되는 형식을 요청하세요.

변환 과정에서 누락될 수 있는 정보

구독 변환은 일반적으로 알려진 항목을 다른 형식으로 매핑할 뿐 서버가 실제로 작동하는지 확인하지 않습니다. 변환기가 알지 못하는 전송 방식, 보안 메커니즘, 흐름 제어, 확장 매개변수는 무시되거나 기본값으로 대체될 수 있습니다. 노드가 목록에 남아 있다는 사실은 기본 정보가 보존됐다는 뜻일 뿐 모든 기능이 유지됐다는 의미는 아닙니다. 변환 후에는 REALITY 인증 매개변수, Vision의 flow, WebSocket 경로, gRPC 서비스 이름 등 주요 항목을 특히 확인하세요.

불필요한 중간 변환을 줄이려면 제공자가 직접 생성한 대상 클라이언트 형식을 우선 사용하세요. 변환이 꼭 필요하다면 원본 구독을 비교 기준으로 남기고 노드 하나의 전체 항목을 먼저 점검하세요. 구독 주소는 접속 인증 정보와 같은 성격이 있으므로 출처가 불분명한 온라인 도구에 함부로 입력해서는 안 됩니다. 업데이트 후 노드 수가 달라진 것은 요금제, 그룹 필터, 서버 설정 변경 때문일 수 있습니다. 프로토콜 비호환 문제라고 바로 단정하지 마세요. 공유 링크와 구독의 차이는 링크 가져오기 안내에서 확인할 수 있습니다.

작업 목적에 따라 선택 순서 정하기

일상적인 웹 탐색에서는 기존 서비스의 안정성과 연결 설정 시간을 우선 고려하고 클라이언트가 완전히 파싱할 수 있는 설정을 선택하세요. 대용량 파일 전송에서는 지속 처리량, 프로세서 사용량, 전송 도중 복구 여부를 살펴보세요. 데이터 처리에 병목이 있다고 확인된 경우에만 흐름 제어와 암호화 구현을 비교하는 것이 좋습니다. 모바일에서 오래 사용한다면 네트워크 전환, 화면이 꺼진 뒤 연결 복구, 배터리 정책을 함께 테스트하세요. 저사양 기기라면 불필요한 캡슐화와 백그라운드 확인을 줄이되 서버가 요구하는 보안 메커니즘을 생략해서는 안 됩니다.

실시간 음성이나 다른 UDP 앱을 사용하려면 프로토콜을 비교하기 전에 로컬 트래픽 처리와 서버 전달 경로를 확인하세요. 여러 기기에서 같은 구독을 쓴다면 모든 기기의 코어가 지원하는 조합을 선택하거나 제공자에게 클라이언트별 구독 형식을 요청하세요. 같은 구독 주소를 사용한다고 설정 폴더 전체를 그대로 동기화할 수 있는 것은 아닙니다. 데스크톱 포트, 모바일 앱별 규칙, 시스템 프록시 설정은 플랫폼마다 다르므로 기기별로 관리하세요. 한 기기의 설정으로 다른 기기의 설정을 덮어쓰지 마세요.

문제를 재현할 수 있는 기준 설정 유지하기

설정을 최종 확정할 때는 클라이언트, 실제 코어, 프로토콜 조합, 테스트한 작업을 기록하세요. 판단과 관계없는 홍보용 이름은 기록할 필요가 없습니다. 구독을 업데이트하거나 코어를 전환하기 전에 복구할 수 있는 설정을 보관하고, 변경 후에는 노드 하나부터 확인한 다음 전체 규칙을 복원하세요. 문제가 생기면 마지막으로 작동한 기준 설정으로 돌아가 주소, 인증, 보안 계층, 전송 방식, 라우팅 순서로 점검합니다. 적절한 프로토콜을 선택했다는 것은 메뉴에 이름이 많이 표시된다는 뜻이 아닙니다. 현재 기기에서 설정을 온전히 실행하고 실제로 필요한 작업을 안정적으로 수행할 수 있어야 합니다.