V2Ray 프로토콜 안내

설정 계층: 프로토콜·전송·보안

프로토콜 이름만으로 연결 구성이 완성되지는 않습니다

클라이언트에서 말하는 ‘프로토콜’은 보통 프록시 프로토콜을 뜻하며, 인증 방식과 대상 주소, 데이터 전달 규칙을 정합니다. VMess, VLESS, Trojan, Shadowsocks가 여기에 속합니다. 이 프로토콜은 클라이언트와 서버가 프록시 요청을 어떻게 해석할지 정할 뿐, 네트워크의 모든 세부 사항을 결정하지는 않습니다. 두 설정 모두 VLESS를 사용하더라도 전송 방식, 보안 계층, 서버 접속 지점이 다르면 연결 경로는 완전히 달라질 수 있습니다. 따라서 프로토콜 이름만으로 호환성이나 성능을 판단해서는 안 됩니다.

전송 계층은 TCP를 직접 사용하거나 WebSocket, gRPC 등을 이용하는 등 프록시 데이터를 전달하는 방식을 정합니다. 전송 옵션은 서버 접속 지점과 일치해야 합니다. WebSocket을 TCP로 바꾼다고 클라이언트가 다른 접속 지점을 자동으로 찾는 것은 아닙니다. 경로, 서비스 이름, 요청 호스트 등의 항목도 각자 용도가 있습니다. 선택 사항처럼 보여도 실제로는 서버의 요청 분배에 쓰이는 경우가 많습니다. 구독 설정에 전송 매개변수가 이미 입력되어 있다면 그대로 유지하고, 대체 설정이 완비된 것을 확인한 뒤에 변경하세요.

보안 계층은 연결을 암호화하고 상대방의 신원을 확인합니다. TLS가 널리 쓰이며, REALITY는 특정 코어에서 지원하는 보안 계층 방식입니다. REALITY는 VLESS와 나란히 놓이는 독립적인 프록시 프로토콜이 아닙니다. 클라이언트에서는 흔히 두 가지를 조합해 사용합니다. 편집 화면에서 여러 옵션을 한 카드에 표시한다고 해서 기술적으로 같은 계층에 속하는 것은 아닙니다. 설정을 확인할 때는 항목을 위에서부터 추측하기보다 프록시 프로토콜, 전송 방식, 보안 계층을 구분해 적은 다음 인증 정보를 살펴보세요.

클라이언트, 코어, 트래픽 처리 방식은 각각 역할이 다릅니다

GUI 클라이언트는 설정 편집과 저장, 가져오기를 담당하고 코어를 실행하거나 시스템 연동 기능을 제공하기도 합니다. 프로토콜 핸드셰이크, 라우팅 규칙 적용, 데이터 전달은 실제로 코어가 처리합니다. 드롭다운에 옵션이 표시된다는 것은 클라이언트가 해당 항목을 알고 있다는 뜻일 뿐, 현재 실행 중인 코어가 이를 지원한다는 의미는 아닙니다. 설정을 가져오는 데 성공했지만 실행에 실패했다면 클라이언트에 저장된 설정, 선택한 코어, 로그에 기록된 실제 기능 실행 여부를 함께 확인하세요. 가져오기 성공을 연결 성공으로 간주해서는 안 됩니다.

시스템 프록시, TUN, Android VPN 모드는 트래픽을 처리하는 방식이지 원격 프로토콜이 아닙니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용되는 경우가 많습니다. TUN은 더 많은 네트워크 트래픽을 처리할 수 있지만 권한, 라우팅, DNS도 고려해야 합니다. Android에서 VPN 연결 상태가 표시되는 것은 시스템이 로컬 가상 네트워크 인터페이스를 허용했다는 뜻이지, 원격 연결에서 어떤 프로토콜을 사용하는지 알려주는 것은 아닙니다. 따라서 트래픽 처리 방식을 바꾸면 프록시를 거치지 않던 앱 문제는 해결할 수 있어도 잘못된 사용자 ID나 서버 포트까지 고쳐지지는 않습니다.

계층별 순서에 따라 문제 찾기

연결은 최소한 로컬 트래픽 처리, 주소 확인, 전송 연결 수립, 보안 핸드셰이크, 프록시 인증 단계를 거칩니다. 로그의 ‘연결 시간 초과’와 ‘인증 실패’는 서로 다른 단계를 가리킵니다. 인증 실패는 보통 요청에 응답할 수 있는 상대방에 도달했다는 뜻입니다. 먼저 어느 계층에서 멈췄는지 파악한 다음 해당 계층의 항목을 수정하세요. DNS, 프로토콜, 라우팅을 매번 한꺼번에 바꾸면 연결이 복구되어도 실제 원인을 알기 어렵고, 다음 구독 업데이트 후 같은 문제가 반복될 수 있습니다.

프로토콜을 선택할 때도 같은 순서를 따르세요. 먼저 서버가 제공하는 완전한 조합을 확인하고, 다음으로 로컬 코어의 지원 범위를 확인한 뒤 기기 부담과 앱 요구 사항을 비교합니다. 클라이언트는 프로토콜 변환기가 아닙니다. 드롭다운을 바꾼다고 기존 계정이 다른 유형의 서비스로 바뀌지 않습니다. 정상 작동하는 원본 설정을 보관하고 별도의 테스트 항목을 만들어 비교하면 수동 수정으로 구독 원본을 덮어쓰는 일을 막을 수 있습니다. 분할 라우팅 규칙을 알아보려면 라우팅 규칙 실전 가이드를 참고하세요.

VMess와 VLESS: 인증과 암호화의 차이

VMess의 설계 배경과 기존 설정

VMess는 Project V 생태계 초기의 주요 프록시 프로토콜로, 사용자 인증과 요청 정보, 데이터 보호를 하나의 프로토콜 설계에 담았습니다. 널리 사용된 덕분에 기존 서비스와 구독에는 여전히 VMess 설정이 많이 남아 있습니다. 기존 서버가 완전하게 지원하고 설정 출처를 신뢰할 수 있으며 현재 클라이언트에서 제대로 실행된다면 선택할 이유가 충분합니다. 이름에 특정 프로젝트가 포함되어 있다는 이유만으로 모든 환경에 적합하다고 판단해서는 안 됩니다. 안정적으로 작동하는 설정이라면 프로토콜 이름을 바꾸려고 굳이 이전할 필요가 없습니다.

VMess의 기존 설정에는 다양한 핸드셰이크와 보안 옵션이 있습니다. 현재 사용에서는 AEAD 관련 지원을 확인하고, 오래된 안내서의 매개변수를 새 설정에 그대로 복사하지 마세요. 오래된 공유 설정에는 추가 식별자나 다른 보안 알고리즘 이름이 포함될 수 있습니다. 클라이언트가 호환성을 위해 이를 파싱하더라도 코어에서 허용하는지는 따로 확인해야 합니다. 오래된 구독을 가져온 뒤 실행되지 않는다면 임의의 숫자를 계속 시도해 클라이언트가 서버 요구 사항을 알아서 채우기를 기대하기보다 현재 형식의 설정을 요청하고 로그에 적힌 항목 설명을 확인하세요.

시스템 시간도 VMess 문제를 확인할 때 중요합니다. 인증 과정에는 시간 조건이 있으므로 기기 시간이 크게 어긋나면 올바른 사용자 ID와 포트를 사용해도 연결에 실패할 수 있습니다. 운영체제의 날짜와 시간이 정상적으로 동기화되도록 하고, 실제 시각이 틀린 경우와 표시 시간대만 다른 경우를 구분하세요. 시간대 표시가 다르다고 반드시 인증에 실패하는 것은 아닙니다. 실제 시스템 시계를 확인하지 않고 시간대만 반복해서 바꿔도 대개 문제는 해결되지 않습니다. 보안 계층에 TLS를 사용한다면 인증서 유효 기간에 대한 시간 확인도 통과해야 합니다.

VLESS의 간소화된 부분

VLESS는 간결한 인증과 요청 캡슐화에 중점을 두며, 프로토콜 자체에는 VMess와 같은 데이터 암호화 방식이 없습니다. 연결 보호는 보통 TLS나 REALITY 같은 외부 보안 계층이 담당합니다. 클라이언트에 ‘암호화: none’이 표시되더라도 조합 전체가 암호화되지 않는다고 단정할 수는 없습니다. 보안 계층이 제대로 활성화되어 있는지 더 확인해야 합니다. 반대로 적절한 보안 계층이 전혀 없다면 프로토콜 이름이 새롭다는 이유만으로 인증 정보와 데이터가 완전하게 보호된다고 여겨서는 안 됩니다.

VLESS의 사용자 식별자는 UUID 형식이 흔하지만, 겉모양이 같다고 VMess 계정과 서로 바꿔 쓸 수 있는 것은 아닙니다. 서버가 수신하는 프로토콜 유형, 사용자 설정, 전송 접속 지점이 모두 서로 맞아야 합니다. 일부 조합에는 Vision처럼 특정 처리 흐름을 지정하는 flow 항목도 포함됩니다. 이 항목은 범용 속도 향상 스위치가 아니므로 아무 VLESS 노드에나 임의로 추가하면 안 됩니다. 서버, 전송 방식, 보안 계층이 모두 요구 조건을 충족할 때만 해당 흐름을 사용할 수 있습니다.

두 프로토콜을 올바르게 비교하는 방법

캡슐화 설계만 놓고 보면 VLESS는 자체 프로토콜 계층에서 일부 암호화 작업을 반복하지 않아 특정 조합에서 처리 오버헤드가 줄어들 수 있습니다. 하지만 실제 연결에는 보안 핸드셰이크, 네트워크 왕복 시간, 서버 대기열, 앱 요청도 영향을 줍니다. 이런 요소가 프로토콜 헤더 차이보다 더 크게 작용하는 경우가 많습니다. 서로 다른 지역과 서비스 제공자의 접속 지점을 비교하면 전체 경로 차이를 측정하는 것이지 VMess와 VLESS의 순수한 프로토콜 차이를 측정하는 것이 아닙니다. 따라서 환경과 무관한 고정 속도 순위는 제시하지 않습니다.

클라이언트에서 선택을 비교할 때는 서버가 제공한 완전한 설정을 우선 사용하세요. 두 프로토콜을 모두 사용할 수 있다면 서비스 대상, 전송 경로, 테스트 앱을 최대한 동일하게 유지하면서 첫 실행, 연속 전송, 잠시 유휴 상태였다가 복구하는 상황을 확인하세요. 클라이언트 목록에 표시되는 한 번의 연결 테스트만 보지 마세요. 실제 웹 요청을 포함하지 않을 수 있고 앱의 DNS 처리나 연결 재사용 방식이 재현되지 않을 수도 있습니다. 테스트는 단일 결과를 비교하는 데 그치지 않고 일상적인 작업이 개선되는지 판단할 수 있어야 합니다.

기존 설정을 많이 관리하는 데스크톱 사용자는 프로토콜 이전보다 호환성과 변경 이력 추적이 더 중요할 수 있습니다. 새 연결을 만들 때 서버가 현재 코어에 맞는 VLESS 보안 조합을 제공한다면 후보로 검토한 뒤 모바일 네트워크 전환, UDP 앱, 라우팅 요구 사항을 확인하세요. VMess만 제공된다면 현재 지원되는 최신 설정을 사용하고 시간을 동기화하세요. 어느 쪽이든 실제 배포 조건을 따라야 합니다. 클라이언트만 바꿔 서버 기능을 변경할 수는 없습니다.

Trojan과 Shadowsocks: 배포 방식과 매개변수 확인

Trojan은 TLS를 기본으로 사용합니다

Trojan은 TLS로 클라이언트와 서버 간 연결을 보호한 뒤 그 안에서 프록시 인증과 데이터 전달을 수행합니다. UUID를 사용하는 프로토콜과 달리 일반적인 클라이언트 설정에는 비밀번호 항목이 있습니다. 비밀번호는 인증의 일부일 뿐이며 서버 주소, 포트, 인증서 검증 이름, 전송 설정도 정확히 일치해야 합니다. 해당 TLS 서버 설정이 이미 있고 인증서 관리 체계를 그대로 활용하려는 환경에 적합하지만, 그렇다고 인증서 검증을 생략하거나 비밀번호 하나만 입력하면 신뢰할 수 있는 연결이 완성된다고 생각해서는 안 됩니다.

도메인으로 연결하면 클라이언트는 보통 설정된 서버 이름을 전송하고 인증서를 검증합니다. 접속 주소와 인증서 이름은 같을 수도 있고 서버 배포 방식에 따라 다를 수도 있으므로 서로 바꿔 써도 된다고 단정할 수 없습니다. 서버가 별도의 서버 이름 항목을 제공한다면 원본 설정대로 입력하세요. 안내가 없다면 다른 노드의 도메인을 가져다 쓰지 마세요. 연결에 실패하면 시스템 시간, 도메인 철자, 인증서 유효성을 먼저 확인하세요. 자세한 내용은 TLS 핸드셰이크 및 인증서 오류 안내를 참고하세요.

Trojan의 전송 조합과 확장 구현은 서로 바꿔 쓸 수 있는 같은 형식으로 취급해서는 안 됩니다. 클라이언트가 Trojan 유형을 인식하더라도 이를 기반으로 한 모든 확장을 실행할 수 있는 것은 아닙니다. 공유 링크를 가져온 뒤 전송 방식, 보안 계층, 추가 항목이 모두 유지되었는지 확인하세요. 서버가 요구하는 기능을 현재 코어에서 지원하지 않는다면 비밀번호를 바꿔도 도움이 되지 않습니다. 호환되는 완전한 접속 설정으로 바꾸거나 해당 조합을 명시적으로 지원하는 클라이언트와 코어를 사용하세요.

Shadowsocks의 간결한 설정과 암호화 방식

Shadowsocks는 SS로 줄여 부르기도 하며, 사전 공유 비밀값과 지정된 암호화 방식으로 프록시 통신을 처리합니다. 설정 구조는 대체로 간결하고 서버, 포트, 비밀번호, 암호화 방식이 핵심 항목입니다. 초기 설계와 최신 AEAD 계열은 보안 특성과 호환 조건이 다르므로 ‘SS’라는 이름만 보고 설정이 서로 같다고 판단할 수 없습니다. 새 설정에는 서버와 코어가 모두 지원하는 최신 방식을 사용하세요. 오래된 안내서와의 호환을 위해 더 이상 사용하기에 적절하지 않은 구형 방식으로 되돌리지 마세요.

암호화 방식 이름은 정확히 일치해야 하며 비밀번호 인코딩 조건도 해당 방식과 맞아야 합니다. 특히 일부 최신 방식은 정해진 길이의 키 재료가 필요해 임의로 짧은 비밀번호를 대신 사용할 수 없습니다. 공유 링크에 방식과 비밀번호가 함께 인코딩되어 있을 때도 있고 별도 항목으로 분리되어 있을 때도 있으므로 링크 모양만 보고 일부를 잘라 비밀번호로 사용하지 마세요. 먼저 클라이언트에서 전체 링크를 파싱한 뒤 제공자의 안내와 대조하세요. 파싱에 실패하면 낯선 문자를 하나씩 지워 보기보다 링크 형식부터 확인하세요.

Shadowsocks 2022 같은 방식은 별도의 호환 범위가 적용됩니다. ‘코어가 Shadowsocks를 지원한다’는 이유만으로 모든 방식을 지원한다고 볼 수 없습니다. 또한 일부 설정은 추가 전송 확장이나 외부 구성 요소에 의존하며, 이 사이트의 세 클라이언트가 모든 플랫폼에서 동일한 기능을 제공한다고 보장할 수 없습니다. 접속 설정은 현재 클라이언트에서 바로 실행할 수 있는지 먼저 확인하세요. 별도 구성 요소가 필요하다면 클라이언트 문서와 서버 요구 사항을 확인하고, 다른 소프트웨어 생태계의 설정 파일을 그대로 구독으로 가져오지 마세요.

UDP 지원과 유지 관리 부담도 고려하세요

Trojan과 Shadowsocks의 UDP 지원 여부는 프로토콜 구현, 클라이언트의 트래픽 처리 방식, 서버 설정, 네트워크 경로를 함께 확인해야 합니다. 일반 웹페이지가 열린다고 해서 통화, 게임, 기타 데이터그램 기반 서비스도 정상이라고 볼 수는 없습니다. 시스템 프록시가 이러한 앱의 트래픽까지 처리하지 않을 수도 있습니다. 테스트할 때는 앱 트래픽이 먼저 클라이언트로 들어가는지 확인한 뒤 관련 전달 기록이 로그에 남는지 살펴보세요. 그렇지 않으면 트래픽 처리 범위 문제를 프로토콜 자체의 한계로 오해하기 쉽습니다.

유지 관리 측면에서 Trojan은 TLS 인증서와 이름의 일치 여부를, Shadowsocks는 암호화 방식과 비밀값의 일치 여부를 중점적으로 확인해야 합니다. 두 프로토콜은 문제를 점검할 기준이 서로 다릅니다. 서버에서 한 가지 방식을 안정적으로 제공하고 모든 대상 기기에서 제대로 실행된다면, 유형을 자주 바꾸기보다 설정을 단순하게 유지하고 출처를 보존하는 편이 더 유용할 수 있습니다. 프로토콜 선택의 목적은 인증, 호환성, 업무 요구를 충족하는 것이지 목록에 유형을 많이 추가하거나 이름의 신구를 따지는 것이 아닙니다.

TLS와 REALITY: 보안 계층 매개변수 확인

TLS에서는 연결 대상 검증이 중요합니다

TLS는 전송을 암호화할 뿐 아니라 인증서와 이름을 검증해 클라이언트가 연결 대상을 확인하도록 돕습니다. 서버 인증서는 유효 기간 내에 있어야 하고 인증서 체인은 기기에서 신뢰할 수 있어야 하며 검증 이름도 인증서의 적용 범위와 일치해야 합니다. 암호화 연결이 실패하면 이 중 어느 단계에서든 원인이 생길 수 있습니다. 인증서 관련 문제를 모두 ‘프로토콜 비호환’으로 돌리면 기기 시간 오류, 잘못된 접속 주소, 불완전한 서버 인증서 갱신처럼 더 직접적인 원인을 놓칠 수 있습니다.

SNI는 핸드셰이크 중 전송되는 서버 이름으로, 서버가 인증서와 접속 지점을 선택하는 데 주로 사용됩니다. 클라이언트가 실제로 검증에 사용하는 이름은 구현과 설정에 따라 정해집니다. 두 이름은 같은 경우가 많지만 용도를 혼동해서는 안 됩니다. 연결할 수 있는 일반 웹사이트 도메인으로 직접 바꿔도 기존 서비스에 해당 인증서가 자동으로 생기지는 않습니다. 주소에 IP를 사용하더라도 설정에 서버 이름이 별도로 지정되어 있다면 그 구분을 유지하고, IP를 모든 이름 항목에 기계적으로 복사하지 마세요.

ALPN은 애플리케이션 계층 프로토콜을 협상하고, 핑거프린트 옵션은 클라이언트 핸드셰이크 특성과 관련됩니다. 둘 다 비밀번호가 아니며 마음대로 바꿔 쓰는 성능 설정도 아닙니다. 서버나 중간 접속 지점이 특정 매개변수를 요구하면 조합이 잘못될 경우 핸드셰이크가 성공한 뒤에도 사용할 수 없을 수 있습니다. 원본 공유 설정을 그대로 유지하세요. 배포 환경에서 지원하는 항목을 명확히 아는 경우에만 고급 옵션을 변경해야 합니다. 이름이 비슷해도 동작이 다른 항목은 한국어 레이블만 보고 추측하지 말고 현재 클라이언트에서 실제로 어떻게 매핑되는지 확인하세요.

REALITY는 매개변수 전체의 조합이 중요합니다

REALITY는 Xray 생태계의 VLESS 조합에서 자주 사용됩니다. 보안 핸드셰이크와 서버 인증 방식을 바꾸는 기능이지 독립적인 계정 유형이 아닙니다. 클라이언트에는 공개 검증 정보와 연결 매개변수를 설정하며 서버의 비밀 정보는 클라이언트 구독에 넣지 않아야 합니다. 이 점을 알면 공유 설정도 올바르게 확인할 수 있습니다. 클라이언트는 서버를 검증할 수 있어야 하지만 서버의 모든 비밀 정보를 보유할 필요는 없습니다. 사용자에게 서버 설정 전체를 복사하라고 요구해서도 안 됩니다.

일반적으로 서버 이름, 공개 검증 정보, 짧은 ID, 클라이언트 핑거프린트가 주요 항목이며 일부 조합에는 해당 flow도 필요합니다. 항목 이름은 클라이언트와 코어가 발전하면서 달라질 수 있으므로 오래된 화면 캡처에서 같은 이름의 입력란만 찾지 말고 현재 화면 안내를 공유 설정의 항목과 대응시키세요. 공개 검증 정보와 짧은 ID는 같은 서비스 설정에서 가져와야 합니다. 사용할 수 있는 노드 두 개에서 각각 하나씩 가져와 조합하면 안 됩니다. 둘 다 문자열처럼 보여도 인코딩과 용도는 완전히 다를 수 있습니다.

REALITY를 사용해도 시간, 네트워크 연결 가능 여부, 전송 방식의 일치를 확인해야 합니다. 클라이언트는 올바른 주소와 포트에 연결할 수 있어야 하며 보안 핸드셰이크도 구현 요구 사항을 충족해야 합니다. 업데이트 후 연결이 끊겼다면 먼저 해당 조합을 지원하는 코어가 실제로 실행되는지 확인하고, 구독 파싱 과정에서 매개변수가 빠지지 않았는지, 서버 설정이 함께 변경되었는지 살펴보세요. 보안 계층을 일반 TLS로 바꾸는 것만으로는 보통 해결되지 않습니다. 서버가 같은 접속 지점에서 다른 핸드셰이크까지 받아들여야 할 의무는 없기 때문입니다.

암호화의 보호 범위와 앱 자체의 보안

프록시 연결의 보안 계층은 클라이언트와 프록시 서버 사이의 구간을 보호할 뿐 앱 자체의 HTTPS나 기타 종단 간 보호를 대신하지 않습니다. 데이터가 서버에 도착한 뒤 대상에 어떻게 접속하는지는 대상 프로토콜과 서버 동작에 따라 달라집니다. 따라서 프록시 접속 지점에 TLS가 표시된다는 이유로 웹사이트 인증서 경고를 무시해서는 안 됩니다. 코어의 연결 성공 상태가 모든 앱 데이터에 동일한 보안이 적용되었다는 뜻도 아닙니다. 설정을 선택할 때 각 계층이 어디서부터 어디까지 보호하며 어떤 대상을 신뢰하는지 확인하세요.

일반 TLS와 REALITY 중에서 고를 때는 먼저 서버가 제공하는 완전한 설정과 기기 지원 여부를 확인한 뒤 관리 요구를 고려하세요. 인증서를 체계적으로 관리하는 환경이라면 호환되는 TLS 접속 지점을 계속 사용할 수 있습니다. REALITY를 명시적으로 사용하는 서비스라면 매개변수를 빠짐없이 유지해야 합니다. 두 방식은 스위치 하나로 ‘업그레이드’할 수 있는 관계가 아닙니다. 여러 기기에서 같은 구독을 사용해야 한다면 각 기기의 파서와 코어가 관련 항목을 모두 보존할 수 있는지 확인하세요. 그렇지 않다면 호환 범위에 따라 접속 설정을 나누어 제공해야 합니다.

Xray와 V2Fly: 코어 계열 및 설정 호환성

공통된 배경이 기능까지 같다는 뜻은 아닙니다

Project V는 V2Ray 생태계를 이해하는 데 필요한 배경입니다. V2Fly는 V2Ray 관련 코어 개발을 이어 왔으며 Xray는 관련 코드 기반에서 출발해 독자적인 발전 경로를 갖춘 코어로 자리 잡았습니다. 인바운드, 아웃바운드, 라우팅, DNS 등 여러 개념은 비슷하지만 기능 확장, 항목의 의미, 기본 동작이 항상 일치한다고 보장할 수는 없습니다. 두 코어를 같은 프로그램의 서로 다른 이름으로 보기보다 배경을 공유하는 별개의 구현 경로로 이해하는 편이 정확하며 설정 이전 위험을 판단하는 데도 도움이 됩니다.

프로토콜 지원 여부는 프로토콜, 보안 계층, 전송 방식, 확장 흐름을 구체적으로 따져야 합니다. Xray 생태계의 REALITY, Vision 기능이 V2Fly로 전환한 뒤에도 그대로 작동한다고 가정할 수 없습니다. V2Fly에서 발전한 기능도 항목 모양이 비슷하다는 이유만으로 Xray에서 같은 방식으로 동작한다고 단정해서는 안 됩니다. 두 코어가 모두 최상위 프로토콜 이름을 인식하는 것은 호환성 확인의 첫 단계일 뿐입니다. 실제 지원 범위는 실행 중인 코어의 문서, 클라이언트 통합 상태, 시작 로그를 기준으로 판단하세요.

코어에 따라 도메인 정책, DNS 처리, 연결 재사용, 라우팅 규칙의 세부 동작이 다를 수도 있습니다. 이전 후 원격 연결을 수립할 수 있더라도 로컬 트래픽이 기존 의도대로 분기되는지 확인해야 합니다. 일부 항목은 오류 없이 무시될 수 있지만 DNS 조회 위치나 아웃바운드 선택이 달라질 수 있습니다. 오랫동안 사용한 복잡한 설정은 ‘실행 가능’, ‘대상에 접속 가능’, ‘규칙이 의도대로 작동’하는지를 별도의 검증 단계로 보고 하나씩 확인한 뒤 일상 설정을 교체하세요.

세 클라이언트의 선택 범위

v2rayN은 이 사이트에서 우선 추천하는 데스크톱 클라이언트로 Windows, macOS, Linux를 지원합니다. GUI로 설정을 관리할 수 있지만 플랫폼, 배포 형태, 통합 버전에 따라 사용할 수 있는 시스템 기능은 다를 수 있습니다. 클라이언트에서 코어를 선택할 수 있다면 메뉴에 다른 코어 이름을 표시하려고 전환하지 말고 현재 설정의 의존 기능부터 확인하세요. GUI에서 특정 항목을 편집할 수 있는지와 설치 폴더의 실제 코어 파일이 해당 기능을 지원하는지도 각각 확인해야 합니다.

Android에서는 주로 v2rayNG를 사용합니다. 이 클라이언트는 Xray 중심의 코어 기능을 활용합니다. v2flyNG는 V2Fly 계열을 위한 대안입니다. 이름이 비슷해도 고급 매개변수와 네이티브 설정을 그대로 바꿔 쓸 수는 없습니다. 서버에서 특정 Xray 확장을 사용한다면 먼저 v2rayNG의 현재 지원 여부를 확인하세요. 기존 설정이 V2Fly 동작에 명시적으로 의존하는 경우에는 v2flyNG를 고려할 수 있습니다. 두 클라이언트에서 VPN 트래픽 처리를 동시에 켠 채 프로토콜을 비교하면 실제 트래픽 경로가 달라져 결과가 왜곡될 수 있으므로 피하세요.

전환 전후 확인 순서

JSON 문법을 공유한다고 해서 설정 의미까지 모두 같은 것은 아닙니다. 네이티브 설정을 다른 코어로 넘기기 전에 프로토콜 이름, 전송 항목, 보안 설정, 라우팅 참조, 리소스 파일을 모두 인식할 수 있는지 확인하세요. 아래는 해당 라우팅 규칙 목록에 넣을 수 있는 간단한 규칙 객체입니다. 사설 주소 범위의 트래픽을 direct라는 아웃바운드로 보내는 예시입니다. 완전한 설정이 아니므로 사용하기 전에 해당 아웃바운드를 정의하고 사용할 수 있는 GeoIP 리소스를 제공해야 합니다.

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

이처럼 짧은 객체도 실행 환경에 따라 달라집니다. 아웃바운드 태그가 존재해야 하고 규칙 파일을 읽을 수 있어야 하며 앞선 규칙이 동일한 트래픽을 먼저 가져가지 않아야 합니다. 복잡한 설정을 이전할 때는 복사본을 만들고 최소한의 아웃바운드 설정만 유지한 뒤 DNS, 규칙, 연결 재사용 옵션을 단계별로 추가하세요. 시작에 실패하면 모든 매개변수를 한꺼번에 다시 작성하지 말고 로그에서 미지원 항목, 누락된 참조, 로컬 포트 충돌을 먼저 찾으세요. 자세한 절차는 v2rayN 코어 시작 실패 해결 방법을 참고하세요.

연결 성능, 리소스 사용량, 모바일 배터리

첫 연결과 연속 전송은 따로 비교하세요

사용자가 느끼는 ‘속도’는 페이지를 처음 여는 시간일 수도 있고 대용량 파일의 연속 전송 속도일 수도 있습니다. 두 경우에 영향을 주는 요소는 다릅니다. 첫 접속에는 DNS, 기본 연결 수립, 보안 핸드셰이크, 프록시 인증, 대상 서버 응답이 관여합니다. 연속 전송은 회선 용량, 혼잡, 패킷 손실, 서버 부하, 기기 처리 성능의 영향을 더 많이 받습니다. 프로토콜 캡슐화에도 오버헤드가 있지만 이러한 조건을 무시하고 단독으로 결론을 내릴 수는 없습니다. 핸드셰이크가 원활한 접속 지점도 지속 부하가 걸리면 성능이 크게 흔들릴 수 있습니다.

전송 방식도 성능에 영향을 줍니다. 추가 캡슐화 계층은 처리 단계를 늘릴 수 있지만 기존 서버 접속 지점에 맞추기 위해 필요할 수도 있습니다. 연결 재사용은 일부 반복 연결을 줄여 주지만 여러 서비스가 같은 연결을 공유하면 서로 영향을 줄 수 있습니다. 일부 서비스는 짧은 패킷 손실, 대기열, 복구 방식에 민감하므로 평균 전송량만 보고 연결 재사용 여부를 정해서는 안 됩니다. 서버에서 요구하거나 명시적으로 지원하지 않는다면 Mux를 기본 활성화해야 하는 최적화 항목으로 여기지 마세요.

테스트에서는 변수를 통제해야 합니다. 기기, 네트워크, 대상 콘텐츠, 테스트 시간대를 최대한 비슷하게 맞추고 콜드 스타트, 연속 접속, 유휴 상태 후 복구, 네트워크 전환을 각각 확인하세요. 클라이언트의 연결 테스트는 참고 자료일 뿐 앱에서 실제로 느끼는 사용성을 대신하지 않습니다. 테스트 요청은 특정 대상을 사용하거나 동일한 라우팅을 거치지 않을 수 있습니다. 두 접속 지점의 위치와 리소스가 다르다면 결과는 ‘이 두 접속 지점의 성능’으로 기록해야 합니다. 특정 프로토콜의 보편적인 순위로 확대 해석하지 마세요.

CPU와 메모리 사용량은 암호화만으로 결정되지 않습니다

암복호화에는 프로세서 자원이 필요합니다. 기기에서 관련 명령어 최적화를 지원하는지, 코어가 어떻게 구현되었는지, 패킷 크기가 어떤지에 따라 실제 오버헤드가 달라집니다. 프로토콜이나 알고리즘 이름이 최신이라고 모든 기기에서 자원을 덜 사용하는 것은 아닙니다. 간결한 캡슐화도 추가 전송 계층이 오히려 이점을 상쇄할 수 있습니다. 저전력 기기에서는 다른 아키텍처 기기의 경험을 그대로 따라 하기보다 실제 작업 중 CPU 사용률이 계속 높은지, 기기가 눈에 띄게 뜨거워지는지, 앱이 원활하게 작동하는지 확인하세요.

메모리 사용량에는 동시 연결 수, 버퍼, DNS 캐시, 규칙 수, 로그 양도 영향을 줍니다. 상세 디버그 로그를 오래 켜 두면 저장 장치 쓰기와 처리 작업이 늘어날 수 있으므로 평소에는 적절한 로그 수준으로 되돌리세요. 대규모 속도 테스트나 자동 검사는 백그라운드에서 계속 연결을 만들어 프로토콜 비교를 방해할 수 있습니다. 리소스 사용량을 비교하기 전에 불필요한 테스트 작업을 종료하고 두 설정의 규칙과 트래픽 처리 방식을 비슷하게 맞추세요. 그렇지 않으면 관측된 차이를 해석하기 어렵습니다.

모바일 배터리는 깨우기와 재연결부터 확인하세요

Android 배터리 사용량은 무선 네트워크 상태의 영향을 많이 받습니다. 잦은 소규모 요청, 지나치게 적극적인 연결 유지, 네트워크 품질 저하로 인한 재전송, 연결 실패 후 반복되는 재시도는 무선 모듈이 더 오래 활성 상태를 유지하게 할 수 있습니다. 프로토콜 자체의 처리 오버헤드가 낮더라도 이런 동작은 배터리 소모를 늘립니다. 대기 상태에서 배터리가 비정상적으로 줄어든다면 먼저 로그에 재연결이 계속 기록되는지 확인하고, 백그라운드 앱에서 요청을 반복하는지 살펴본 다음 프로토콜 조합 변경을 고려하세요.

VPN 모드에서는 더 많은 트래픽이 로컬 처리 경로를 거칩니다. 따라서 배터리 통계에서 클라이언트 사용 비중이 늘어도 추가 소모가 전부 클라이언트에서 발생했다고 단정할 수 없습니다. 시스템이 일부 전달 작업을 클라이언트 사용량으로 집계할 수도 있습니다. 앱별 프록시를 사용하면 처리 범위를 줄일 수 있지만 프록시가 필요한 앱이 선택되었는지, 포함 목록과 제외 목록이 어떻게 다른지 알아야 합니다. 시스템 배터리 최적화로 백그라운드 연결이 반복 종료되면 복구와 재연결이 발생해 사용성이 떨어질 뿐 아니라 배터리 소모 측정도 왜곡될 수 있습니다.

실제 설정에서는 최고 성능보다 연결 복구의 안정성을 우선할 수 있습니다. Wi-Fi와 모바일 네트워크 사이를 자주 전환한다면 전환 후 연결이 정상적으로 다시 설정되는지, 통화·메시지·백그라운드 작업에 영향이 있는지 확인하세요. 네트워크 전환으로 기존 연결이 끊기는 것 자체가 프로토콜 결함은 아닙니다. 중요한 것은 클라이언트와 앱이 빠르게 복구할 수 있는지입니다. 일상 작업을 안정적으로 처리하는 조합을 우선 사용한 뒤 반복 가능한 테스트로 전송 방식, 연결 재사용, 보안 설정을 바꿀 가치가 있는지 판단하세요.

구독 및 공유 형식: 가져오기가 가능해도 실행된다는 뜻은 아닙니다

공유 링크, 구독, 네이티브 JSON의 차이

공유 링크에는 보통 프로토콜, 주소, 인증 정보, 일부 전송 매개변수 등 하나의 연결 설정이 담깁니다. 구독은 클라이언트가 설정 목록을 주기적으로 가져오는 주소입니다. 응답에는 여러 공유 링크가 텍스트로 들어 있거나 Base64로 인코딩된 내용, 또는 특정 구조의 데이터가 포함될 수 있습니다. 네이티브 JSON은 코어의 실행 설정을 표현하며 로컬 인바운드, 여러 아웃바운드, DNS, 라우팅까지 포함할 수 있습니다. 세 형식은 서로 다른 문제를 해결합니다. 모두 텍스트로 복사할 수 있다고 해서 같은 가져오기 메뉴에서 서로 바꿔 사용할 수 있는 것은 아닙니다.

Base64는 인코딩 방식일 뿐 내용을 보호하지 않으며 내부에서 어떤 프로토콜을 사용하는지도 결정하지 않습니다. 인코딩된 구독에 여러 공유 링크가 들어 있을 수 있고, 공유 링크 일부만 인코딩되어 있을 수도 있습니다. 따라서 형식은 끝부분에 특정 문자가 있는지만 보지 말고 디코딩된 구조와 클라이언트 요구 사항을 확인해야 합니다. 구독 주소와 공유 설정에는 실제 서비스에 접속할 수 있는 인증 정보가 포함되는 경우가 많으므로 계정 정보처럼 보관하세요. 형식을 확인하려고 잘 모르는 온라인 도구에 제출하지 마세요.

네이티브 JSON과 GUI 클라이언트가 생성한 설정은 관리 범위도 다를 수 있습니다. 네이티브 설정을 가져오면 목록에 서버 하나를 추가하는 데 그치지 않고 코어가 전체 규칙 세트를 실행할 수 있습니다. 로컬 수신 포트, 로그 출력, 라우팅 동작이 바뀔 수도 있습니다. 가져오기 전에 클라이언트가 이 설정을 전체 설정으로 사용하는지, 일부 항목만 추출하는지 확인하세요. 용도를 모르는 외부 전체 설정으로 정상 작동 중인 로컬 관리 구성을 덮어쓰지 마세요.

파서와 코어는 별도의 호환성 관문입니다

구독을 가져오면 먼저 클라이언트 파서가 처리합니다. 파서는 공유 형식을 해석해 매개변수를 내부 항목으로 변환하고, 이후 클라이언트가 코어에서 실행할 수 있는 설정을 생성합니다. 따라서 가져오기 호환성과 실행 호환성은 별도의 관문입니다. 파서는 링크를 받아들이면서도 알지 못하는 새 항목을 누락할 수 있습니다. 코어가 기능을 지원하더라도 현재 GUI에서 해당 설정을 완전히 생성하지 못할 수도 있습니다. 목록에 항목이 표시되는 것은 중간 결과일 뿐입니다. 편집 화면을 확인하고 실제로 실행해 보는 과정도 필요합니다.

서버 이름, 전송 서비스 이름, 핑거프린트, 보안 계층의 추가 항목은 이름이나 인코딩 방식이 서로 다를 수 있습니다. 클라이언트 간에 내보내고 다시 가져올 때 이런 항목이 빠지거나 의미가 달라지기 쉽습니다. 확인할 때 양쪽 레이블이 완전히 같은지 따질 필요는 없지만 용도에 따라 비교해 값이 기본값이나 빈칸으로 바뀌지 않았는지 확인해야 합니다. 원래 클라이언트에서는 작동했지만 내보낸 뒤 연결되지 않는다면 계정을 다시 발급받거나 서버를 변경하기 전에 고급 항목부터 비교하세요.

구독 변환은 원본 형식을 파싱한 뒤 대상 형식에 맞게 다시 구성하는 과정입니다. 대상 형식에 대응하는 항목이 없으면 원본의 의미를 완전히 표현하지 못할 수 있습니다. 변환 결과를 가져올 수 있어도 중요한 정보가 빠졌을 가능성이 있습니다. 특정 보안 계층이나 확장 흐름을 사용하는 연결은 제공자가 직접 제공하는 호환 형식을 우선 사용하세요. 구조 차이에 대한 자세한 설명은 Base64 구독, 네이티브 JSON, 공유 링크 비교를 참고하세요. 형식 변환만으로 새로운 코어 기능이 생기는 것은 아닙니다.

구독 업데이트와 수동 수정 함께 관리하기

구독을 관리하면 원본에서 연결 설정을 일괄 업데이트할 수 있지만 목록이 다시 만들어질 수도 있습니다. 중복 항목, 메모, 수동 변경을 처리하는 방식은 클라이언트마다 다르므로 로컬 수정이 계속 유지된다고 가정해서는 안 됩니다. 프로토콜을 시험하기 전에 원본 항목은 구독 그룹에 그대로 보관하고, 테스트용 사본은 별도의 수동 그룹에 두세요. 메모에 변경 내용을 기록해 두면 구독 업데이트를 계속 받으면서 테스트 설정이 최신 접속 정보와 여전히 일치하는지도 확인할 수 있습니다.

업데이트 실패는 ‘응답을 받지 못함’과 ‘응답은 받았지만 파싱할 수 없음’을 구분해야 합니다. 전자는 구독 주소의 유효성, 연결 방식, DNS 문제와 관련될 수 있습니다. 후자는 웹페이지, 계정 안내, 지원되지 않는 형식이 반환된 경우일 수 있습니다. 오류 응답을 구독처럼 계속 변환하지 말고 인증 정보가 포함된 전체 주소를 공개하지 마세요. 여러 출처를 관리하는 방법은 여러 구독 그룹과 필터 활용법을 참고하세요. 기본적인 문제 해결은 자주 묻는 질문의 설치·설정 및 문제 해결 항목에서 확인할 수 있습니다.

사용 환경에 맞는 선택: 호환되는 조합에서 안정적인 설정까지

먼저 호환성을 확인하고 사용 경험을 비교하세요

선택을 시작할 때는 선호하는 프로토콜 이름부터 정하지 말고 서버가 실제로 제공하는 완전한 조합을 먼저 정리하세요. 각 조합에는 최소한 프록시 프로토콜, 전송 방식, 보안 계층, 필요한 확장 기능이 포함되어야 합니다. 그런 다음 로컬 클라이언트와 코어에서 해당 설정을 모두 표현할 수 있는지 확인하세요. 항목이 누락되었거나 구현에서 지원하지 않거나 필요한 조건이 불분명한 조합을 제외하고 나서야 남은 후보를 테스트할 가치가 있습니다. 이 순서로 진행하면 서버 협조가 없는 로컬 설정을 바꾸느라 시간을 낭비하지 않고 여러 기기의 설정을 맞출 때 생기는 오해도 줄일 수 있습니다.

데스크톱에서 웹 검색과 업무를 할 때는 v2rayN을 사용하고 구독에서 제공한 기본 보안 조합을 유지해 보세요. 앱이 시스템 프록시 설정을 따른다면 먼저 시스템 프록시로 확인하고, 프록시 설정을 읽지 않는 앱이 있을 때 TUN을 검토하세요. 트래픽을 더 많이 처리하려고 프로토콜, DNS, 라우팅을 한꺼번에 바꾸지 마세요. 연결이 되면 평소 사용하는 웹사이트, 파일 전송, 업무 앱을 테스트하고 절전 모드에서 복구한 뒤에도 정상인지 확인하세요. 한 번의 연결 테스트보다 일상 작업이 안정적으로 완료되는지가 더 중요한 기준입니다.

Android 일상 사용에는 v2rayNG를 우선 선택하세요. 확인할 항목은 VPN 권한, 앱별 처리 범위, 백그라운드 실행 정책, 네트워크 전환 후 복구 여부입니다. 휴대폰 화면에 표시되는 프로토콜 이름만 비교해서는 안 됩니다. 기존 설정이 V2Fly 동작에 명시적으로 의존한다면 v2flyNG에서 별도로 확인할 수 있지만, 두 클라이언트가 번갈아 트래픽을 처리하게 두면 결과가 혼란스러워질 수 있습니다. 테스트 중에는 실제 트래픽을 처리하는 클라이언트를 하나만 유지하고 매번 설정 출처와 코어 계열을 기록하세요.

업무 요구에 따라 테스트 항목을 정하세요

통화, 게임 등 실시간 서비스는 UDP 전달, 트래픽 처리 경로, 연결 안정성을 중점적으로 확인해야 합니다. 일반 웹페이지는 열리지만 실시간 서비스가 실패한다면 먼저 앱 트래픽이 클라이언트로 들어오는지, 서버가 해당 전달을 허용하는지, 중간 네트워크에 필요한 조건이 갖춰져 있는지 확인하세요. TCP 접속이 된다고 모든 데이터그램 기반 서비스도 된다고 단정하지 마세요. 전송 조합에 따라 데이터 처리 방식이 다를 수 있으므로 앱 요구를 만족하는지 직접 확인해야 합니다. 프로토콜 이름만으로 보장할 수는 없습니다.

여러 기기에서 같은 구독을 사용할 때는 모든 기기가 공통으로 지원하는 기능 범위를 우선 고려하세요. 데스크톱은 특정 확장 기능을 사용할 수 있지만 모바일 파서가 해당 매개변수를 보존하지 못한다면 데스크톱 전용 그룹에 넣고 모바일에는 호환성이 명확한 접속 설정을 남기세요. 모든 기기의 목록을 똑같이 보이게 하려고 서로 동등하지 않은 설정을 억지로 복사하지 마세요. 장기간 관리해야 하는 환경에서는 그룹 구분, 출처 기록, 업데이트 절차도 설정 선택의 일부이며 이후 문제 해결에 드는 비용을 크게 줄여 줍니다.

자원이 제한된 기기에서는 추가 처리를 줄이는 것부터 시작하세요. 필요한 라우팅 규칙과 적절한 로그 수준, 명확한 트래픽 처리 범위를 유지하고 불필요한 백그라운드 검사는 일시 중지하세요. 그래도 리소스 사용량이 높다면 프로토콜과 전송 조합을 비교할 수 있습니다. 기기가 오래되었다는 이유로 인증이나 보안 계층을 끄지 마세요. 보안 요구를 낮추는 것은 성능 최적화가 아닙니다. 동일한 작업을 반복했을 때 개선 효과가 확인되고 앱 요구 사항과 연결 대상 검증을 해치지 않는 변경만 유지하세요.

이전 설정으로 되돌릴 방법과 최소 변경 기록 보관

설정 최적화는 복사본에서 진행하고 매번 한 종류의 매개변수만 바꾸며 기대하는 개선 효과를 기록하세요. 예를 들어 연결 재사용 옵션만 비교할 때는 프로토콜, 접속 지점, 라우팅, 테스트 앱을 그대로 유지하세요. 보안 핸드셰이크를 확인할 때 DNS 규칙을 동시에 바꾸지 마세요. 결과가 나빠지면 직전의 정상 설정으로 즉시 돌아갈 수 있어야 합니다. 문제가 발생하면 ‘로컬 트래픽 처리, 이름 확인, 기본 연결, 보안 핸드셰이크, 프록시 인증, 대상 접속’ 순서로 로그를 확인해 잘못된 계층에서 같은 작업을 반복하지 마세요.

최종 선택에서 모든 프로토콜을 지원하거나 모든 기기에서 고급 기능을 똑같이 사용할 필요는 없습니다. 서버가 명시적으로 지원하고, 클라이언트에서 설정을 완전하게 표현할 수 있으며, 코어가 올바르게 실행하고, 실제 앱에서 안정적으로 작동하는 네 가지 조건이 모두 충족되어야 현재 환경에 맞는 설정입니다. 처음 설정한다면 빠른 시작 안내를, 플랫폼별 설치 방법은 다운로드 페이지를 확인하세요. 문제가 계속되면 자주 묻는 질문 분류를 참고해 범위를 좁히세요. 이 프로토콜 안내는 선택 기준을 설명하기 위한 자료이며 실제 환경에서의 검증을 대신하지 않습니다.