V2Ray 프로토콜과 코어

연결 계층: 클라이언트, 코어, 프로토콜

먼저 각 계층의 역할을 파악하세요

그래픽 클라이언트는 설정 저장, 구독 가져오기, 출구 전환, 로그 표시를 담당합니다. 코어는 연결을 실행하고 프로토콜을 해석하며 라우팅을 처리해 실제 데이터 경로를 만듭니다. 둘은 같은 소프트웨어를 달리 부르는 말이 아닙니다. 클라이언트에 코어가 포함되어 있을 수도 있고 별도의 코어 프로세스를 실행할 수도 있습니다. 따라서 설정을 저장하는 데 성공했다는 사실은 관리 화면이 해당 항목을 받아들였다는 뜻일 뿐, 실행 중인 코어가 모든 옵션을 인식한다는 보장은 아닙니다. 호환성을 판단하려면 클라이언트에서 해당 설정을 입력할 수 있는지와 현재 코어가 이를 실행할 수 있는지를 모두 확인해야 합니다.

연결은 프록시 프로토콜, 전송 방식, 보안 계층으로 나눠 이해할 수 있습니다. 프록시 프로토콜은 인증 정보와 대상 주소, 데이터 형식을 정의합니다. 전송 방식은 스트림 연결을 직접 사용하거나 다른 애플리케이션 전송에 데이터를 담는 등 데이터를 전달하는 방법을 정합니다. 보안 계층은 이에 맞는 암호화와 인증을 담당합니다. VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜이며, 각 프로토콜이 암호화와 결합되는 방식은 서로 다릅니다. REALITY는 보안 메커니즘이지, 가져오기 과정에서 앞서 언급한 프로토콜을 마음대로 대체할 수 있는 범용 프로토콜 이름이 아닙니다.

설정 이름만으로 호환성을 알 수는 없습니다

서비스 제공자가 설정에 ‘고속’, ‘모바일’, ‘백업’ 같은 이름을 붙이는 경우가 있지만, 이는 메모에 불과합니다. 실제 연결을 좌우하는 것은 주소, 포트, 인증 정보, 전송 유형, 보안 설정입니다. 프로토콜 항목에 모두 VLESS라고 표시되어도 보안 방식이나 전송 매개변수가 다르면 필요한 코어 기능도 달라질 수 있습니다. 반대로 화면에 비슷한 이름이 표시된다고 해서 두 프로젝트의 설정 항목이 완전히 같다는 뜻은 아닙니다. 이름으로 내부 구성을 추측하지 말고 실제 설정값을 확인하세요.

설정값을 확인할 때는 먼저 서버에서 요구하는 조합을 기록한 다음 클라이언트 설정과 대조하세요. 주소는 연결 대상을, 포트는 해당 서비스의 수신 지점을 지정합니다. 사용자 ID나 비밀번호는 인증에 사용되며 서버 이름은 보통 보안 핸드셰이크에 쓰입니다. 전송 경로와 호스트 이름은 애플리케이션 계층의 전달 조건일 수 있습니다. 한 설정 화면에 함께 표시되더라도 각 항목의 역할은 다릅니다. 서버 이름을 연결 주소에 넣거나 웹 경로를 호스트 이름으로 입력하면 하위 연결은 성공해도 이후 핸드셰이크가 완료되지 않을 수 있습니다.

앱 트래픽에서 원격 출구까지

앱 트래픽을 클라이언트로 전달할 방법도 필요합니다. 시스템 프록시는 관련 설정을 따르는 앱에 프록시 주소를 제공하지만 모든 프로그램의 트래픽을 가로채지는 않습니다. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 받으며 시스템 라우팅, 권한, 도메인 이름 조회도 관련됩니다. 둘 다 트래픽이 들어오는 경로이지 원격 프로토콜이 아닙니다. TUN을 켜도 VMess가 VLESS로 바뀌지 않으며 서버에 없는 보안 설정이 추가되지도 않습니다. 연결 문제를 살펴볼 때는 먼저 트래픽이 클라이언트에 들어왔는지 확인한 뒤 출구 연결을 점검하세요.

민감한 인증값은 제외한 설정 목록을 만들어 각 계층별로 설정 출처와 용도를 기록하는 것이 좋습니다. 첫 연결에서는 필요한 설정만 남기고, 연결을 확인한 뒤 분할 라우팅, 멀티플렉싱, 가상 인터페이스 기능을 추가하세요. 문제가 생겼을 때 진입 경로, 규칙, 원격 핸드셰이크 중 어디서 발생했는지 구분하기 쉬워집니다. 용어를 빠르게 확인하려면 용어 한눈에 보기를, 증상별 해결 방법은 자주 묻는 질문을 참고하세요. 클라이언트 선택은 언제나 서버에서 제공한 전체 설정 조합을 확인하는 것부터 시작해야 합니다.

VMess: 인증, 암호화, 시간 조건

설계 배경과 사용 목적

VMess는 Project V 생태계에서 일찍 도입된 프록시 프로토콜로, 인증 정보와 요청 정보, 데이터 보호를 프로토콜 설계에 포함하며 오랫동안 클라이언트 설정과 구독에 사용되어 왔습니다. 주된 용도는 이미 구축된 서버에 연결하는 것이며, 사용자가 새로운 보안 조합을 직접 구성하는 데 있는 것은 아닙니다. VMess 자체의 데이터 보호와 외부 보안 계층을 구분해서 이해해야 합니다. VMess를 사용한다고 해서 모든 전송에 같은 보안 방식을 반드시 덧붙여야 하는 것도 아니고, 서버가 명시한 설정을 생략해도 되는 것도 아닙니다.

사용자 ID는 인증 대상을 식별하는 주요 항목이며 흔히 UUID 형식으로 표시됩니다. 구독 메모도 원격 서버의 기기 번호도 아닙니다. 복사할 때는 내용 전체를 그대로 유지하고 따옴표, 공백, 줄바꿈을 덧붙이지 마세요. 연결 주소는 도메인 이름이나 주소 문자열일 수 있으며, 주소 확인과 사용자 인증은 서로 별도로 점검해야 합니다. 연결에 실패했다면 사용자 ID를 반복해서 바꾸기보다 먼저 도메인 확인과 포트 연결을 점검한 다음 인증 및 보안 핸드셰이크를 확인하는 편이 원인을 좁히기 쉽습니다.

이전 필드와 최신 인증 방식

과거 VMess 설정에는 추가 ID 수를 지정하는 필드가 있었으며, 일부 공유 형식에서는 aid로 표기합니다. 최신 AEAD 방식은 보통 이 추가 ID의 이전 동작 경로를 따르지 않고, 흔히 0으로 설정됩니다. 그러나 이 필드를 수정하는 것이 모든 문제를 해결하는 만능 방법은 아닙니다. 구형 서버, 오래된 가져오기 기능, 현재 코어 사이에는 호환성 차이가 있을 수 있습니다. 설정 출처에 과거 매개변수가 남아 있다면 시대가 다른 화면 캡처를 따라 하나씩 고치기보다 제공자에게 서버의 실제 지원 방식을 확인하세요.

시간 동기화는 VMess 문제 해결 시 별도로 확인할 만한 항목입니다. 인증 방식에 시간 조건이 포함되므로 시스템 시계가 크게 어긋나면 인증에 실패할 수 있습니다. 확인할 대상은 실제 시간과 자동 동기화 상태이며, 시간대 표시만 보고 판단해서는 안 됩니다. 시간대가 다르다고 반드시 시간이 틀린 것은 아니며, 표시되는 시간을 다른 지역에 맞춰 수동으로 바꾸면 올바른 시스템 시계를 오히려 망가뜨릴 수 있습니다. 데스크톱이 절전 모드에서 깨어난 뒤, 가상 머신을 일시 중지했다가 다시 실행한 뒤, 모바일 기기에서 자동 시간 설정을 끈 뒤에는 시간이 정확한지 다시 확인하세요.

암호화 옵션과 전송 설정

클라이언트에서 자동 암호화나 특정 데이터 암호화 방식을 선택할 수 있지만, 사용 가능 여부는 양측 구현과 코어 지원에 따라 달라집니다. 하드웨어 가속, 프로세서 아키텍처, 연결 부하가 알고리즘별 실제 비용에 영향을 주므로 알고리즘 이름만으로 처리 속도 순위를 판단할 수 없습니다. 이미 제공된 설정은 우선 그대로 유지하세요. 알고리즘 차이를 평가해야 한다면 서버, 전송 방식, 테스트 부하를 고정한 뒤 프로세서 사용률과 지속 전송 성능을 비교하고, 여러 항목을 동시에 바꾸지 마세요.

VMess는 여러 전송 방식과 함께 사용할 수 있지만 주소, 경로, 호스트 이름, 보안 이름은 서버 구성에 맞아야 합니다. 리버스 프록시를 거치는 연결에서는 하위 포트로 연결할 수 있다고 해서 애플리케이션 계층의 경로까지 올바르다는 뜻은 아닙니다. 경로의 대소문자, 앞쪽 슬래시, 전달 조건이 맞지 않으면 이후 단계에서 거부될 수 있습니다. 보안 계층의 서버 이름도 메모를 그대로 복사해서는 안 됩니다. 가져온 뒤 클라이언트에 표시된 전송 유형이 원래 설정과 다르면 연결을 시도하기 전에 공유 형식이 온전히 인식되었는지 확인하세요.

VMess를 선택할 만한 이유는 기존 서비스가 명확하게 지원하고 설정값을 확인할 수 있으며, 현재 클라이언트와 코어가 이를 온전히 실행할 수 있다는 점입니다. 오래전에 등장했다는 이유만으로 사용할 수 없는 방식이 되는 것도 아니고, 호환 항목이 많다고 모든 기기에 반드시 적합한 것도 아닙니다. 현재 연결이 안정적이라면 업그레이드나 이전은 새로운 보안 방식이 필요하거나 유지 관리 분기를 줄이는 등 구체적인 요구에 맞춰 진행하세요. 이전할 때는 기존 항목을 보존하고 새 설정을 추가해 별도로 확인하면 비교 기준을 잃지 않습니다. 인증 실패와 로그 확인에 관한 문제 해결 방법은 문제 해결 Q&A에서 이어서 살펴볼 수 있습니다.

VLESS와 REALITY: 프로토콜과 보안 계층의 조합

간결한 프로토콜이라고 보안 설계를 생략하는 것은 아닙니다

VLESS는 프로토콜 계층이 담당하는 기능을 줄이고 적절한 외부 보안 방식에 데이터 보호를 맡기는 것을 설계 방향 중 하나로 삼습니다. 인증과 프록시 요청을 표현하지만 프로토콜 이름만으로 연결 보호가 완료된다고 이해해서는 안 됩니다. 화면에 표시되는 암호화 옵션 none은 대개 VLESS 계층의 설정을 나타내며, 연결 전체에 암호화가 없다는 뜻은 아닙니다. 실제 보안은 TLS 또는 REALITY를 올바르게 사용하는지, 요구된 인증이 완료되는지 등 외부 설정에도 달려 있습니다.

이러한 계층 분리는 각 설정의 역할을 이해하기 쉽게 해 주지만, 조합을 더욱 꼼꼼히 확인해야 합니다. 사용자 ID는 프로토콜 인증에 속하고, 서버 이름과 관련 공개 키 설정은 보안 핸드셰이크에 쓰이며, 전송 유형은 데이터 전달 방식을 정합니다. 일부 흐름 제어 옵션은 프로토콜, 보안 계층, 코어 구현에 따라 지원 여부가 달라집니다. 화면에서 모든 항목을 입력할 수 있다고 해서 서로 자유롭게 조합할 수 있는 것은 아닙니다. 익숙하지 않은 옵션은 적용 조건을 먼저 확인하고, 다른 설정의 값을 그대로 가져와 빈칸을 채우지 마세요.

REALITY 설정의 범위

REALITY는 특정 구현 기능과 관련된 보안 메커니즘으로, Xray의 VLESS 설정에서 자주 사용됩니다. 클라이언트에는 보통 연결 주소와 포트, 사용자 ID, 서버 이름, 공개 키, 짧은 ID 등의 설정이 필요합니다. 화면마다 필드 이름은 달라질 수 있지만 각 정보의 역할이 바뀌지는 않습니다. 공개 키는 해당 핸드셰이크의 검증에 쓰이며 구독 주소가 아닙니다. 짧은 ID도 사용자 메모가 아닙니다. 설정이 빠졌다면 신뢰할 수 있는 설정 출처에서 전체 내용을 받아야 하며, 임의로 값을 만들어 원격 인증 문제를 해결하려 해서는 안 됩니다.

서버 이름은 서버 설정에서 허용하는 조건에 맞아야 하므로 흔한 웹사이트 도메인으로 임의 변경하지 않는 것이 좋습니다. 연결 주소와 서버 이름은 서로 다를 수 있습니다. 전자는 네트워크 연결에, 후자는 보안 핸드셰이크에 사용됩니다. 두 값을 같게 맞춘다고 반드시 올바른 것은 아닙니다. 공개 키, 짧은 ID, 서버 이름도 서로 바꿔 쓸 수 있는 항목이 아닙니다. 문제를 해결할 때는 프로토콜 항목에 VLESS가 표시되는지만 보지 말고 전체 설정을 대조해 가져오기 기능이 값을 빠뜨리거나 잘못 대응시키지 않았는지 확인하세요.

흐름 제어, 핑거프린트, 전송 호환성

일부 설정은 화면의 Vision 관련 옵션처럼 특정 흐름 제어 방식을 사용합니다. 모든 VLESS 연결에 필요한 범용 가속 설정이 아니며, 서버와 전송 방식, 보안 조합에 따라 적용 여부가 달라집니다. 다른 설정에 해당 항목이 없다면 값을 임의로 가져오지 마세요. 클라이언트 핑거프린트 설정은 보안 핸드셰이크에 영향을 줄 수 있지만, 이를 바꾼다고 대역폭이 늘어나는 것은 아닙니다. 서버가 요구하거나 클라이언트가 명확히 지원하는 조합을 먼저 사용하고, 필요한 경우에만 조정하면 호환성 문제를 성능 문제로 오해하지 않을 수 있습니다.

가져오기는 되지만 실행 직후 보안 유형을 지원하지 않는다거나 알 수 없는 필드라는 오류가 뜨면 우선 실행 중인 코어를 확인하세요. 그래픽 화면에서 REALITY 연결 설정을 인식하더라도 선택한 코어가 해당 기능을 지원한다는 뜻은 아닙니다. 코어를 바꿔도 기존 항목에 필드가 그대로 남을 수 있지만, 실제 실행 설정은 달라질 수 있습니다. 전환 전에 백업하고 전환한 뒤에는 시작 결과와 로그를 살펴 설정이 코어에 제대로 전달되었는지 확인하세요. 항목의 프로토콜 표시만 보고 판단해서는 안 됩니다.

이 조합을 선택하려면 서버가 명확히 지원하고, 클라이언트가 모든 항목을 저장하며, 사용하는 코어가 해당 구현을 실행할 수 있어야 합니다. 다른 조합보다 자동으로 빠른 것도 아니며 인증서 체계 밖의 모든 운영 점검을 대신하지도 않습니다. 모바일 기기에서는 네트워크 전환, 장시간 연결, 백그라운드 실행도 고려해야 합니다. 이미 제공된 구독에 연결하는 것이 목적이라면 옵션을 직접 찾아 조합하기보다 전체 설정을 가져와 값을 유지하는 편이 대체로 안전합니다. 프로토콜과 코어의 역할은 Xray와 V2Fly 코어의 차이에서 더 자세히 확인할 수 있습니다.

Trojan과 Shadowsocks: 보안 경계와 방식 식별

Trojan과 TLS의 조합

Trojan은 프록시 인증과 요청 전달을 TLS 연결 안에서 처리하며, 일반적인 설정에서는 비밀번호를 인증 정보로 사용합니다. 설계상의 선택이 VLESS와 다르므로 항목 수만 비교해 어느 쪽이 더 가볍다고 판단해서는 안 됩니다. 화면에 보이는 주소, 포트, 비밀번호는 연결의 일부일 뿐이며 서버 이름, 인증서 검증, 전송 방식도 서버 요구 사항에 맞아야 합니다. 가져온 뒤 비밀번호가 표시된다고 인증서 체인을 신뢰할 수 있다는 뜻은 아닙니다. 하위 포트에 연결된다고 보안 핸드셰이크와 프록시 인증까지 모두 통과한 것도 아닙니다.

인증서 검증은 상대방의 신원을 확인하는 절차입니다. 이름 불일치, 인증서 만료, 신뢰 체인 문제 등이 발생하면 먼저 설정의 서버 이름과 시스템 시간, 서버 인증서 구성을 점검하세요. 검증을 끄면 연결의 보안 경계가 달라지므로 장기적인 해결책으로 삼아서는 안 됩니다. 기업 네트워크에서 자체 신뢰 환경을 사용하는 경우에도 모든 설정에서 검증을 일괄 건너뛰지 말고 실제 관리 정책에 따라 처리해야 합니다. 오류 메시지를 없애는 데 그치지 말고 인증할 수 없는 원인을 찾아야 합니다.

Shadowsocks에서는 암호화 방식이 호환 조건입니다

Shadowsocks는 보통 간결한 프록시 및 암호화 조합으로 연결을 제공하며, 주요 설정에는 주소, 포트, 암호화 방식, 비밀번호가 포함됩니다. 암호화 방식은 임의로 바꿀 수 있는 개인 설정이 아니라 양측이 미리 일치시켜야 하는 핵심 조건입니다. 세대가 다른 방식은 키 요구 사항, 세션 처리, 구현 지원에서 차이가 클 수 있습니다. 클라이언트에 서버가 지원하는 것보다 더 많은 방식이 표시되더라도 원하는 항목을 임의로 선택할 수 있다는 뜻은 아닙니다.

최신 방식은 키 형식에 엄격한 요구 사항이 있을 수 있으므로 사람이 읽을 수 있는 짧은 비밀번호를 모두 유효한 키로 간주해서는 안 됩니다. 오래된 공유 링크는 서로 다른 인코딩 형식을 사용할 수 있습니다. 어떤 링크는 방식과 비밀번호를 함께 인코딩하고, 어떤 링크는 인증 정보와 주소를 따로 표시합니다. 해석에 성공한 뒤에도 방식 이름과 비밀번호가 온전히 유지되었는지, 특히 특수 문자가 링크 인코딩 과정에서 제대로 복원되었는지 확인하세요. 출처가 분명한 구독은 클라이언트로 가져오는 것이 좋으며, 직접 여러 차례 디코딩하고 다시 조합해 인코딩하지 마세요.

확장 필드 및 데이터그램 지원

일부 Shadowsocks 설정은 추가 확장 기능에 의존하지만 그래픽 클라이언트나 현재 코어가 이를 구현하지 않을 수 있습니다. 기본 프로토콜만 인식되고 연결은 실패할 수도 있습니다. 프로토콜 이름이 같다는 이유만으로 설정 전체가 호환된다고 판단하지 마세요. 확장이 필요한지, 어느 구성 요소가 확장 매개변수를 처리하는지, 현재 소프트웨어가 실제로 지원하는지 확인해야 합니다. 이 가이드는 사이트에서 다루는 세 가지 클라이언트의 선택만 설명하며, 특정 공유 링크를 따라 출처가 불분명한 추가 프로그램을 설치하라고 권하지 않습니다.

음성 통화, 게임 등 데이터그램을 사용하는 서비스라면 전체 연결 경로의 UDP 지원도 확인해야 합니다. 클라이언트 진입점이 데이터그램을 받을 수 있는지, 프로토콜 구현이 전달할 수 있는지, 서버가 중계를 허용하는지, 앱 트래픽이 실제로 해당 진입점으로 들어오는지 모두 중요합니다. 하나라도 빠지면 웹은 정상인데 특정 앱만 작동하지 않을 수 있습니다. 이를 곧바로 프로토콜이 ‘느리다’고 판단하지 마세요. 로그와 앱 동작으로 트래픽 유형을 확인한 뒤 클라이언트 진입 모드와 서버 지원 여부를 살펴보세요.

두 프로토콜 모두 기존 서비스의 서버 구성 조건에 맞춰 사용해야 합니다. 인증서를 적절히 관리하는 기존 Trojan 서비스는 해당 설정에 따라 사용할 수 있으며, 지원되는 방식과 명확한 설정을 갖춘 Shadowsocks 서비스도 적절한 사용처가 있습니다. 인증을 끄거나 암호화 방식을 바꾸거나 확장 필드를 삭제해 호환되지 않는 설정을 억지로 ‘가져올 수 있는’ 설정으로 만들어서는 안 됩니다. 이전하려면 서버에서 새 연결 정보를 온전히 제공받고 별도 항목으로 검증하세요. 기존 항목은 되돌릴 수 있도록 보존해야 합니다.

코어 종류: Xray, V2Fly와 클라이언트 호환

공통된 뿌리가 계속되는 호환성을 보장하지는 않습니다

Project V는 이 생태계를 이해하는 배경이며 V2Fly는 V2Ray 관련 구현을 유지하고 Xray는 분기되어 자체 기능을 발전시켜 왔습니다. 공통된 기반 때문에 개념과 설정 구조가 비슷한 부분은 있지만, 두 프로젝트는 같은 프로그램의 스킨이 아닙니다. 분기된 뒤 기능, 보안 방식, 전송 구현, 필드 정의가 각자 발전할 수 있습니다. 어떤 프로토콜을 지원한다고 해서 그 프로토콜의 모든 확장 조합까지 지원하는 것도 아닙니다. 코어를 비교할 때는 프로젝트 이름을 성능 등급처럼 보지 말고 구체적인 설정 요구 사항을 기준으로 삼으세요.

REALITY나 특정 흐름 제어 기능이 필요하다면 사용하는 Xray 구현과 클라이언트 호환성을 확인해야 합니다. 기존 V2Fly 서버와 설정을 사용한다면 해당 코어의 실제 지원 여부를 점검하세요. 일반적인 기본 프로토콜은 양쪽에서 모두 사용할 수 있는 경우가 있지만, 같은 이름의 설정이라도 매개변수, 기본값, 제약 조건을 확인해야 합니다. 특히 새 전송 방식은 오래된 튜토리얼만 보고 다른 코어의 지원 여부를 판단해서는 안 됩니다. ‘어느 코어가 더 발전했나’라는 막연한 질문보다 ‘현재 환경에서 이 설정의 필드를 모두 실행할 수 있는가’를 확인하는 편이 정확합니다.

세 가지 클라이언트의 역할

데스크톱에서는 Windows, macOS, Linux의 설정 관리에 사용할 수 있는 v2rayN을 우선 고려하세요. 다만 화면 구성, 시스템 연동, 배포 패키지별 기능은 실제 인터페이스를 기준으로 확인해야 합니다. Android에서는 Xray 코어를 사용하는 v2rayNG를 먼저 고려하고, V2Fly 계열이 필요하다면 v2flyNG를 검토하세요. 세 클라이언트는 하나의 앱을 플랫폼별로 부르는 이름이 아니므로 가져오기 기능, 라우팅 편집 방식, 설정 메뉴가 다를 수 있습니다. 이전할 때는 똑같은 메뉴 이름을 찾기보다 설정의 의미를 옮기세요.

클라이언트에 표시된 코어 전환 기능에도 한계가 있습니다. 코어를 선택할 수 있다고 해서 모든 설정이 의미상 동일한 형태로 자동 변환되는 것은 아닙니다. 일부 필드는 한쪽에서만 작동하고, 클라이언트가 코어별로 서로 다른 구조의 설정을 생성할 수도 있습니다. 사용자 지정 설정에서는 차이가 더욱 분명합니다. 특정 코어가 읽을 수 있는 전체 설정 파일을 다른 코어에 그대로 넘겨도 같은 결과가 나온다고 가정해서는 안 됩니다. 이전하기 전에 원본 파일과 실행 로그를 보관하세요.

코어 전환 시 확인 순서

구독 출처, 수동으로 추가한 항목, 사용자 지정 라우팅을 먼저 백업한 뒤 매개변수가 분명한 설정 하나를 기준으로 정하세요. 멀티플렉싱이나 복잡한 분할 라우팅처럼 확인과 무관한 기능은 잠시 끄고 새 코어를 실행해 오류를 확인하세요. 시작 단계에서 알 수 없는 필드 오류가 발생하면 설정 구조를 살펴보고, 핸드셰이크 단계에서 인증이나 보안 오류가 나면 원격 설정값을 확인하세요. 웹은 되지만 앱에 문제가 있다면 트래픽 진입점, 도메인 이름 조회, 데이터그램 지원을 점검하세요. 단계별 오류는 서로 다른 계층을 가리키므로 모두 ‘코어 바꾸기’로 해결하려 해서는 안 됩니다.

라우팅 규칙도 별도로 확인해야 합니다. 도메인 목록, 주소 목록, 리소스 파일의 형식과 로드 위치는 클라이언트와 코어의 영향을 함께 받을 수 있습니다. 전환 후 연결 자체는 정상인데 직접 연결해야 할 트래픽이 프록시로 들어간다면 프로토콜 인증을 바꾸기보다 실제 생성된 규칙 순서와 기본 출구를 확인하세요. 규칙 파일 누락, 분류 이름 차이, 도메인 조회 정책 변경도 매칭 결과를 바꿀 수 있습니다. 코어 이전은 연결 계층뿐 아니라 라우팅 동작도 다시 확인해야 합니다.

장기적으로 관리할 때는 특정 코어에 의존하는 설정, 클라이언트가 생성한 규칙, 직접 수정한 설정을 기록해 두는 것이 좋습니다. 업데이트 전에 복구할 수 있는 설정 사본을 보관하고, 업데이트 후에는 일상적인 분할 라우팅을 복원하기 전에 소규모 연결 테스트를 진행하세요. 다운로드는 클라이언트 다운로드 페이지에서 확인할 수 있습니다. 코어 종류에 관한 설명은 별도의 프로그램을 추가로 받아야 한다는 안내가 아닙니다. 생태계 관계는 Project V 생태계 개요에서, 플랫폼 및 인터페이스 선택은 세 클라이언트 비교에서 확인하세요.

성능과 배터리: 핸드셰이크, 처리량, 백그라운드 부하 구분

‘속도’에는 적어도 세 가지 의미가 있습니다

프로토콜을 비교할 때 연결 수립 시간, 요청 응답 시간, 지속 처리량을 혼동하기 쉽습니다. 연결 수립에는 도메인 이름 조회, 하위 연결, 보안 핸드셰이크, 인증이 관련됩니다. 응답 시간은 원격 대상과 네트워크 왕복 시간에도 영향을 받습니다. 지속 처리량은 대역폭, 혼잡, 서버 부하, 기기의 처리 능력에 따라 달라집니다. 첫 페이지를 더 빨리 여는 조합이 장시간 전송에서도 반드시 더 높은 처리량을 보장하지는 않습니다. 프로토콜 이름만으로는 구조상 비용 일부만 알 수 있으며, 실제 연결 상태를 관찰하는 일을 대신할 수 없습니다.

짧은 요청마다 연결을 반복해서 만들면 핸드셰이크 비용이 더 두드러지고, 장시간 대량 데이터를 전송할 때는 안정적인 처리량과 암호화 처리 비용이 더 중요합니다. 추가 캡슐화는 처리 단계와 데이터 오버헤드를 늘릴 수 있지만 서버 구성, 중계 경로, 연결 재사용 방식도 결과에 영향을 줍니다. 이러한 조건을 무시한 채 VMess, VLESS, Trojan, Shadowsocks의 속도를 고정된 순서로 매길 수는 없습니다. 같은 프로토콜이라도 기기, 전송 방식, 서버가 다르면 프로토콜 간 차이보다 성능 차이가 더 클 수 있습니다.

부하 구성에 따라 리소스 사용량이 달라집니다

프로세서 부하는 암호화 알고리즘, 하드웨어 가속, 데이터 복사, 동시 연결 수에 따라 달라집니다. 메모리 사용량은 규칙 데이터, 캐시, 버퍼, 클라이언트 화면의 영향도 받습니다. 그래픽 인터페이스를 모두 켰을 때 보이는 전체 사용량을 프로토콜 탓으로만 돌릴 수는 없습니다. 비교할 때는 두 설정에서 규칙과 트래픽 진입점을 비슷하게 맞추고 유휴 상태와 부하 상태의 차이를 관찰하세요. 한쪽은 복잡한 규칙과 가상 인터페이스를 켜고 다른 쪽은 단순한 시스템 프록시만 사용한다면 프로토콜 성능만 비교한 결과가 아닙니다.

멀티플렉싱은 일부 연결 수립 비용을 줄일 수 있지만 모든 환경에서 이점이 있는 것은 아닙니다. 패킷 손실이 있거나 서버 제한이 있거나 서로 다른 작업이 영향을 주는 경우 연결을 한곳에 집중하면 대기 시간이나 복구 문제가 생길 수 있습니다. 일부 흐름 제어와 멀티플렉싱 조합에는 구현상 제약도 있으므로 양측 지원이 전제되어야 합니다. 스레드 수나 연결 수를 계속 늘리는 것을 범용 속도 향상 방법으로 삼지 마세요. 기본 설정이나 출처가 명확한 설정을 먼저 유지하고, 재현 가능한 문제가 확인되면 한 번에 하나의 변수만 바꾸세요.

모바일 배터리는 주로 실행 방식에 영향을 받습니다

모바일 기기의 배터리 소모는 암호화 연산뿐 아니라 무선 네트워크 깨우기, 백그라운드 연결 유지, 잦은 재접속, 도메인 조회, 데이터 전달에도 영향을 받습니다. 유휴 상태에서도 계속 통신하는 설정은 연산이 조금 더 무겁더라도 연결이 안정적인 설정보다 배터리를 더 많이 소모할 수 있습니다. Wi-Fi와 모바일 데이터 사이를 오갈 때 기존 연결을 복구하는 방식도 사용 경험에 영향을 줍니다. 화면 밝기, 신호 세기, 다른 백그라운드 앱이 프로토콜 차이를 가릴 수 있으므로 한 번의 배터리 감소만으로 특정 코어가 더 절전된다고 단정하지 마세요.

v2rayNG 또는 v2flyNG를 테스트할 때는 비슷한 네트워크와 앱 부하를 사용해 화면을 켠 상태, 화면을 끈 유휴 상태, 네트워크 전환 후의 동작을 각각 살펴보세요. 시스템 배터리 관리가 백그라운드 활동을 제한하면 화면을 끈 뒤 연결이 끊기거나 복구가 느려질 수 있습니다. 제한을 완화할지는 실제 필요와 배터리 소모를 고려해 결정하고, 절전 기능을 무조건 모두 끄지는 마세요. 구독을 자주 업데이트하거나 자동 테스트 또는 비정상적인 재시도가 발생하는지도 확인해야 합니다. 이러한 백그라운드 작업은 프로토콜 간의 작은 차이보다 배터리 소모를 더 크게 늘릴 수 있습니다.

실제 선택에서는 먼저 명백한 호환성 문제와 비정상적인 재접속을 해결한 다음 성능을 비교하세요. 단독 지연 시간 하나를 저장하는 것보다 테스트 조건, 설정 조합, 문제가 발생한 단계를 기록하는 편이 유용합니다. 결과는 해당 기기와 네트워크에만 적용되며 프로토콜의 영구적인 순위로 일반화해서는 안 됩니다. 일반 웹과 지속 전송은 안정적인데 특정 앱만 이상하다면 진입점과 라우팅을 먼저 확인하세요. 모든 설정에서 동시에 느려진다면 프로토콜 매개변수를 계속 바꾸기보다 공통 네트워크 조건을 살펴보세요.

구독 호환성: 공유 링크, 인코딩, 필드 유지

링크 모양만으로 데이터 형식을 알 수는 없습니다

단일 공유 링크는 하나의 연결 설정을 나타내고, 구독 주소는 업데이트될 수 있는 여러 설정을 가져오는 데 사용됩니다. 둘 다 클립보드에 복사할 수 있지만 관리 방식은 다릅니다. 공유 링크에는 보통 프로토콜 접두사가 붙고, 구독 주소는 대개 요청 가능한 네트워크 주소이며 응답으로 링크 목록, 인코딩된 텍스트, 그 밖의 구조를 반환할 수 있습니다. 주소가 보안 웹 프로토콜로 시작한다는 사실만으로 응답을 현재 클라이언트가 인식한다고 볼 수는 없습니다. 가져오기 전에 제공자가 안내한 용도를 확인하세요.

VMess 공유 형식은 인코딩된 구조화 데이터를 사용하는 경우가 많고, VLESS와 Trojan은 인증 정보, 주소, 쿼리 매개변수를 링크에 함께 담는 경우가 흔합니다. Shadowsocks에는 인증 정보를 인코딩하는 방식이 여러 가지 있습니다. 이러한 형식은 널리 사용되지만 모든 가져오기 기능이 모든 변형을 지원하는 것은 아닙니다. 해석에 실패했다면 링크가 잘렸거나 인코딩이 손상되었을 수도 있고, 클라이언트가 아직 지원하지 않는 필드를 출처에서 사용했을 수도 있습니다. 오류가 형식 계층인지 실행 계층인지 먼저 구분하면 불필요한 수정을 줄일 수 있습니다.

가져온 뒤에도 확인해야 합니다

클라이언트는 보통 링크를 내부 항목으로 변환한 다음 해당 항목을 바탕으로 코어 실행 설정을 생성합니다. 이 과정에서 알 수 없는 필드가 사라지거나 빠진 필드에 기본값이 채워질 수 있습니다. 따라서 ‘가져오기 성공’은 첫 단계일 뿐입니다. 프로토콜, 주소, 포트, 인증 정보, 전송 방식, 보안 계층, 관련 추가 설정을 확인하고 특히 REALITY 매개변수, 흐름 제어, 서버 이름, 전송 경로를 살펴보세요. 원본 링크에 있던 설정이 화면에 전혀 보이지 않는다면 원격 서버를 바꾸기 전에 해당 설정이 유지되었는지 확인해야 합니다.

특수 문자는 흔한 문제 원인입니다. 비밀번호의 구분자, 경로의 쿼리 내용, 메모의 비라틴 문자는 올바른 퍼센트 인코딩이 필요할 수 있습니다. 채팅 창에서 여러 번 전달하거나 전체 문자열을 일반 웹 주소처럼 처리하면 링크가 잘리거나 잘못 복원될 수 있습니다. 인코딩 단계를 모른다면 링크 전체를 반복해서 디코딩하지 마세요. 원본을 다시 복사해 클라이언트의 해당 가져오기 기능을 사용하고, 붙여넣은 내용에 설명, 공백, 줄바꿈이 포함되지 않았는지 확인하는 것이 좋습니다.

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

구독 업데이트는 보통 서버에서 반환된 내용을 기준으로 합니다. 중복 항목 인식, 메모 유지, 설정 덮어쓰기 방식은 클라이언트마다 다릅니다. 구독 항목을 직접 수정하면 업데이트 후 원래 값으로 복구되거나 다른 값으로 대체될 수 있습니다. 테스트 설정을 장기간 보존하려면 클라이언트가 지원하는 경우 별도 항목으로 복사하고 용도를 명확히 표시하세요. 다만 별도 복사본에는 원격 주소나 인증 정보가 자동으로 갱신되지 않으므로 주기적으로 확인해야 합니다. 구독 관리와 수동 설정에는 각각 비용이 있으므로 출처를 추적할 수 없는 하나의 항목으로 섞지 않는 것이 좋습니다.

구독 주소에는 접근 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 화면 캡처, 로그, 문제 설명을 공유할 때는 전체 주소, 사용자 ID, 비밀번호, 관련 비공개 매개변수를 가리세요. 다운로드 문제를 진단할 때는 연결 오류, 응답 유형, 해석 메시지만으로도 충분한 경우가 많으며 구독 전체를 공개할 필요는 없습니다. 응답이 로그인 페이지, 오류 페이지, 빈 텍스트로 바뀌면 클라이언트가 해석 실패를 보고할 수 있습니다. 이는 프로토콜이 지원되지 않는다는 뜻이 아니라 예상했던 설정 목록이 아닌 다른 내용을 가져왔다는 의미일 수 있습니다.

클라이언트를 이전할 때는 제공자가 명확히 지원하는 구독 형식을 우선 사용하고 대표 설정 하나를 골라 교차 확인하세요. 항목 수만 비교해서는 이전이 완전하다고 볼 수 없습니다. 개수가 같아도 중요한 필드가 빠져 있을 수 있습니다. 여러 항목을 가져온 뒤에는 하나를 먼저 검증하고, 프로토콜과 전송 방식별 대표 항목도 확인하세요. 복사, 구독 추가, 업데이트 방법은 입문 가이드에서 확인할 수 있습니다. 형식 차이와 가져오기 경로는 공유 링크와 구독 주소의 차이를 참고하세요. 설정 필드가 올바르게 유지되어야 이후 성능과 안정성을 비교할 수 있습니다.

사용 환경별 선택: 최소 설정과 검증 순서

제약 조건에 따라 조합을 고르세요

이미 제공되는 서비스를 사용할 때는 어떤 프로토콜이 더 좋은지 따지기보다 서버가 제공하는 조합, 기기 플랫폼, 실제 사용 목적부터 정리해야 합니다. 데스크톱에서는 v2rayN을 우선 사용하고 설정에 필요한 코어와 전송 방식을 확인하세요. Android에서는 v2rayNG부터 고려하고 V2Fly 계열이 필요할 때 v2flyNG를 검토할 수 있습니다. 서버가 지원되는 완전한 조합 하나만 제공한다면 다른 이름을 좇아 인증이나 보안 설정을 바꾸지 말고 해당 조합에 맞춰 클라이언트를 설정하세요. 서버 구성을 직접 선택할 수 있다면 유지 관리 역량과 업데이트 비용도 결정에 포함해야 합니다.

네트워크를 자주 바꾸는 모바일 환경에서는 재접속과 백그라운드 동작을, 데스크톱에서 장시간 전송할 때는 처리량 안정성과 프로세서 부하를 살펴보세요. 여러 앱을 서로 다른 출구로 보내야 한다면 라우팅 표현과 트래픽 진입점을, 데이터그램을 사용하는 서비스라면 전체 경로 지원 여부를 먼저 확인해야 합니다. 프로토콜이 담당하는 것은 이 중 일부뿐입니다. 모든 요구를 ‘어떤 프로토콜이 가장 빠른가’라는 질문으로 좁히면 앱이 시스템 프록시 설정을 읽지 않거나 도메인 조회가 예상한 분할 라우팅 경로로 들어가지 않는 등 실제 제약을 놓치기 쉽습니다.

먼저 검증 가능한 최소 경로 하나를 구성하세요

처음 연결을 확인할 때는 매개변수가 분명한 원격 설정 하나만 켜고 간단한 라우팅 모드를 유지한 뒤, 동작을 확인할 수 있는 앱 하나를 클라이언트 진입점에 연결하세요. 코어가 정상적으로 시작되는지 확인하고 자주 사용하는 일반 웹페이지에 접속한 다음 로그에서 연결과 출구를 확인하세요. 웹페이지가 열렸다고 해서 모든 앱, 모든 도메인, 모든 데이터 유형이 정상이라고 할 수는 없습니다. 이후 규칙, 가상 인터페이스, 다른 기능을 하나씩 복원하면서 각 단계에서 결과를 비교할 수 있도록 하세요.

라우팅 문제는 범위가 좁은 규칙부터 검증하면 의미를 파악하기 쉽습니다. 아래는 Xray 또는 V2Ray 형식의 설정에서 사용하는 라우팅 일부이며, 전체 설정에 direct 태그가 붙은 직접 연결 출구가 이미 있어야 합니다. 이 조각만으로 실행할 수 있는 전체 파일은 아닙니다. 예시에서는 예약된 예시 도메인과 정확히 일치하는 요청만 해당 출구로 보내며, 나머지 요청은 전체 설정의 다른 규칙이나 기본 출구를 따릅니다. 클라이언트의 그래픽 라우팅 편집기는 다른 방식으로 표현할 수 있으므로 이 내용을 공유 링크 입력란에 그대로 붙여넣지 마세요.

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

오류가 발생한 단계에 따라 점검하세요

코어를 시작할 수 없다면 원격 대역폭을 테스트할 필요 없이 필드, 설정 구조, 코어 지원 여부부터 확인하세요. 도메인을 확인할 수 없다면 주소 입력과 조회 경로를 점검하세요. 연결 시간 초과가 발생하면 네트워크 연결 가능 여부, 포트, 서버 수신 상태를 확인하세요. 보안 핸드셰이크에 실패하면 시스템 시간, 서버 이름, 인증서 또는 공개 키 설정을 점검하세요. 인증이 실패하면 사용자 ID, 비밀번호, 양측 프로토콜을 확인하세요. 연결은 되지만 일부 앱만 이상하면 진입 모드, 라우팅, 데이터그램 지원을 살펴보세요. 이러한 순서로 확인하면 매번 분명한 목적을 가지고 설정을 바꿀 수 있습니다.

복잡한 분할 라우팅을 복원할 때는 규칙이 보통 순서대로 적용되며 앞쪽의 넓은 규칙이 뒤쪽의 세부 규칙을 가릴 수 있다는 점을 유의하세요. 도메인 규칙과 주소 규칙의 적용 여부는 조회 정책과 데이터 세트에도 영향을 받습니다. 지역 분류가 언제나 정확한 서비스 분류라고 가정하지 마세요. 하나의 앱도 여러 도메인과 주소 대역에 접속할 수 있습니다. 원하는 출구를 먼저 정하고 실제 적용된 조건을 확인하세요. 관련 원리와 규칙 충돌 확인 방법은 geosite 및 geoip 분할 라우팅 설정 가이드를 참고하세요.

되돌릴 지점을 남기고 장기 설정을 조정하세요

한 번에 하나의 계층만 조정하세요. 원격 항목을 바꾸거나 진입점을 바꾸거나 코어를 바꾸되 프로토콜, 라우팅, 조회 설정을 동시에 변경하지 마세요. 원본 설정 출처, 변경 목적, 관찰 결과를 기록하고 공개될 경우 문제가 될 인증값은 기록하지 마세요. 새 조합이 안정적인지 확인한 뒤 일상적으로 사용할 항목을 교체하고, 새 경로 검증이 끝날 때까지 기존 설정을 보존하세요. 업데이트 후 문제가 생기면 구독을 모두 다시 가져오기보다 먼저 변경 범위를 되짚어 보세요. 일상적인 설정은 빠른 시작 안내에서, 구체적인 문제는 자주 묻는 질문에서 확인할 수 있습니다. 이 안내서는 판단 기준을 제공할 뿐 모든 서버에 같은 설정을 요구하지 않습니다.