V2Ray 프로토콜·코어 가이드

1. 설정을 네 가지 계층으로 나누기

클라이언트에 표시되는 서버 설정 하나에는 보통 프록시 프로토콜, 하위 전송 방식, 보안 계층, 로컬 연결 방식이 함께 포함됩니다. 각 항목의 역할은 다르므로 목록에 표시된 프로토콜 이름만으로 전체 기능을 판단할 수 없습니다. 프록시 프로토콜은 클라이언트와 서버 간 인증, 대상 주소 전달, 데이터 중계를 담당합니다. 전송 방식은 데이터를 어떤 연결로 전달할지 정하고, 보안 계층은 연결을 암호화하고 상대방의 신원을 확인합니다. 로컬 연결 방식은 어떤 앱의 요청을 클라이언트로 보낼지 결정합니다. 문제를 해결하려면 먼저 계층을 나눠 어떤 항목을 수정해야 하는지 파악하세요.

프로토콜 이름만으로 연결 방식 전체를 알 수 없습니다

VLESS를 예로 들면, 이름만으로는 프록시 프로토콜만 알 수 있습니다. TLS나 REALITY를 사용하는지, 어떤 전송 방식을 쓰는지, 서버에서 특정 flow를 요구하는지는 알 수 없습니다. 같은 VLESS 설정이라도 필요한 코어 기능이 다를 수 있습니다. VMess도 여러 전송 방식과 함께 사용할 수 있고, Shadowsocks는 암호화 방식을 추가로 확인해야 합니다. 서버를 편집할 때는 먼저 프로토콜 종류를 확인하고 주소, 포트, 인증 정보를 대조한 다음 전송 방식과 보안 설정을 살펴보세요. 프로토콜 선택 메뉴에서 이름을 임의로 바꿔도 원격 서버의 프로토콜이 변환되지는 않습니다.

서버 주소와 서버 이름은 서로 다른 항목입니다. 서버 주소는 연결할 대상이며 보통 도메인이나 IP 주소를 입력합니다. TLS 서버 이름은 핸드셰이크 중 전달되는 이름으로, 인증서의 신원 확인에도 사용됩니다. 배포 방식에 따라 두 값이 같을 수도, 다를 수도 있습니다. 서버 주소를 IP로 바꾼 뒤 서버 이름을 지우면 기존에 정상 작동하던 인증서 검증이 실패할 수 있습니다. 포트는 원격 서버가 연결을 받는 포트입니다. 로컬 수신 포트와 혼동하지 마세요. 클라이언트의 로컬 포트는 이 기기의 앱이 접속하는 포트이며, 값을 바꿔도 원격 서버의 수신 포트는 달라지지 않습니다.

로컬 연결과 원격 프로토콜을 따로 확인하세요

v2rayN의 시스템 프록시는 시스템 프록시 설정을 따르는 앱의 요청을 로컬 클라이언트로 보내는 기능입니다. 원격 프로토콜과는 별개이며 모든 프로그램이 이 설정을 따른다는 보장도 없습니다. TUN 모드는 가상 네트워크 인터페이스와 권한, 라우팅 처리가 필요한 별도의 연결 방식입니다. Android 클라이언트는 시스템 VPN 권한을 받아 연결을 구성하지만, 화면의 VPN 아이콘은 로컬 서비스가 시작됐다는 뜻일 뿐 원격 인증에 성공했다는 증거는 아닙니다. 로그를 확인하고 실제 앱으로 연결을 테스트하세요.

라우팅은 요청이 클라이언트에 들어온 뒤 적용됩니다. 규칙에 따라 특정 도메인, 주소 또는 포트의 트래픽을 프록시로 보내거나 직접 연결하거나 차단할 수 있지만, 서버 비밀번호 오류를 해결하지는 못합니다. DNS 조회는 연결 방식과 설정에 따라 앱, 시스템, 로컬 클라이언트 또는 원격 경로에서 처리될 수 있습니다. 일부 도메인만 열리지 않는다면 먼저 DNS 조회 실패인지, 잘못된 출구로 라우팅됐는지, 원격 연결이 실패했는지 구분하세요. 모든 프로토콜을 차례로 바꾸면 원래 문제를 재현하기 어려워집니다.

다시 확인할 수 있도록 설정 기록 남기기

설정을 점검할 때는 프로토콜, 주소, 포트, 전송 방식, 보안 계층, 서버 이름, 코어 등 민감하지 않은 정보를 기록하고 시스템 프록시나 다른 연결 방식 중 무엇을 사용하는지도 적어 두세요. UUID, 비밀번호, 구독 주소는 별도로 보관하고 공개 스크린샷에 포함하지 마세요. 원본 설정을 먼저 백업한 뒤 한 번에 한 항목만 수정하세요. 로그에 로컬 포트를 바인딩할 수 없다고 나오면 포트 충돌을 해결하세요. 인증서 이름이 일치하지 않는다면 서버 이름과 인증서를 확인하세요. 인증 거부 오류라면 인증 정보와 프로토콜을 점검하세요. 클라이언트 이름으로 원인을 짐작하기보다 오류가 발생한 계층에 맞춰 해결하는 편이 정확합니다.

2. VMess·VLESS·Trojan·SS 비교

프로토콜을 선택하기 전에 서버에서 해당 연결을 실제로 제공하는지 확인해야 합니다. 클라이언트가 특정 프로토콜을 지원한다고 해서 어떤 서버든 연결할 수 있는 것은 아닙니다. 아래에서는 각 프로토콜의 역할과 설정 범위를 비교하며, 기기와 네트워크 조건을 무시한 속도 순위는 제시하지 않습니다. 프로토콜 자체의 처리 부담은 전체 연결 비용 중 일부에 불과하며, 회선 품질과 전송 방식, 서버 구현에 따라 사용 경험은 달라질 수 있습니다. 이미 안정적으로 작동하는 구독이 있다면 이름이 더 새로워 보이는 프로토콜로 모두 바꾸기보다 먼저 정상적으로 가져와 연결을 확인하는 것이 좋습니다.

VMess: 인증과 암호화를 결합한 프로토콜

VMess는 Project V의 초기 프로토콜 설계에서 비롯됐으며 인증과 데이터 보호 등의 기능을 담당합니다. 현재 사용 시에는 오래된 가이드의 과거 설정을 그대로 따르기보다 클라이언트와 서버가 최신 인증 방식을 지원하는지 확인하세요. 일부 구형 설정에는 추가 ID 같은 항목이 포함되는데, 의미가 구현과 시기에 따라 다를 수 있습니다. 가져온 설정에서 인증에 실패한다면 먼저 서버 안내, UUID, 양쪽 기기의 시간을 확인하세요. 오래된 문서의 값을 일반적인 해결책으로 취급해서는 안 됩니다. 시스템 시간이 크게 어긋나도 인증이나 보안 핸드셰이크에 문제가 생길 수 있습니다.

VMess는 기존 배포 환경과 구독 도구에서 폭넓게 지원되므로 현재 잘 작동하고 유지 관리되는 설정을 계속 사용하는 데 적합합니다. 이름이 바뀌었다는 이유만으로 코어를 변경할 필요는 없지만, 전송 방식은 양쪽에서 지원해야 합니다. 편집할 때 프로토콜 내부의 암호화 설정과 외부 TLS를 구분하세요. 이름이 비슷해도 서로 다른 설정입니다. 설정 제공자가 암호화 방식을 지정했다면 그대로 확인하고, TLS가 켜져 있다는 이유로 내부 항목을 임의로 바꾸지 마세요. 과거 호환 항목이 많을수록 가져온 원본을 비교 자료로 보관하는 것이 중요합니다.

VLESS: 간결한 프록시 계층, 외부 보호 기능 필요

VLESS는 프록시 계층의 복잡성을 줄인 프로토콜입니다. 기본 설계에는 VMess와 같은 데이터 암호화 기능이 없으므로 보통 TLS나 REALITY 같은 보안 계층과 함께 사용합니다. 구조가 간결하다고 해서 인증을 생략해도 되는 것은 아니며, 신뢰할 수 없는 경로에서 평문으로 전송해도 된다는 뜻도 아닙니다. 클라이언트의 암호화 항목이 none으로 표시된다면 외부 보안 설정과 함께 해석해야 합니다. 프로토콜 요구 사항에 따른 값일 수 있으며 연결 전체의 보호를 끄라는 뜻은 아닙니다. 사용하기 전에 서버에서 제공하는 전체 조합을 확인하세요.

VLESS 설정에는 flow 항목이 자주 포함됩니다. flow는 임의로 켜고 끄는 성능 옵션이 아니라 특정 구현 및 전송 조합에 연결된 프로토콜 동작입니다. 서버에서 요구하지 않으면 추가하지 말고, 요구한다면 누락하지 마세요. 구독으로 서버 항목은 만들어졌지만 시작할 때 flow를 지원하지 않는다는 오류가 나오면 UUID를 바꾸기 전에 선택한 코어와 해당 기능의 지원 여부를 확인하세요. 기존 구독에서는 설정을 통일하는 것보다 서버에서 지정한 항목을 모두 보존하는 것이 중요합니다.

Trojan·Shadowsocks: 서로 다른 인증 항목

Trojan은 비밀번호 인증과 TLS 보호를 함께 사용하는 경우가 많습니다. 비밀번호와 인증서 확인 설정을 모두 살펴보세요. 비밀번호가 맞더라도 서버 이름이 틀리면 인증 전에 핸드셰이크가 실패할 수 있습니다. 설정 항목이 짧아 보여도 보안 계층을 생략할 수 있는 것은 아닙니다. 서버에서 추가 전송 캡슐화를 사용한다면 클라이언트에도 해당 항목을 설정해야 합니다. Trojan 비밀번호를 UUID 칸에 붙여 넣거나 다른 프로토콜의 공유 링크에서 접두어만 바꿔서는 유효한 설정을 만들 수 없습니다.

Shadowsocks는 보통 SS로 줄여 부르며 서버 주소, 포트, 비밀번호, 암호화 방식이 핵심 설정입니다. 암호화 방식은 서로 바꿔 쓸 수 있는 옵션이 아닙니다. 특히 최신 방식 계열을 사용할 때는 양쪽 구현에서 지원하는지 확인해야 합니다. 일부 설정에는 추가 캡슐화 매개변수도 필요하므로 주소와 비밀번호만 남겨서는 안 됩니다. 구조는 대체로 간결하지만 리소스 사용량은 암호화 알고리즘, 프로세서 지원, 데이터 전달 경로에 따라 달라집니다. 오래된 방식이 어떤 가이드에서 ‘호환성이 가장 좋다’고 소개됐다는 이유만으로 우선 사용하지 말고, 현재 서버와 코어의 지원 범위에 맞춰 설정하세요.

실제 설정을 점검할 때는 기존 VMess 설정의 최신 구현 호환성과 시간을 확인하고, VLESS는 보안 계층과 flow를 중점적으로 살펴보세요. Trojan은 비밀번호와 TLS 신원 확인을 함께 점검하고, SS는 암호화 방식의 정확한 이름을 확인해야 합니다. 서버에서 비교 가능한 여러 연결을 제공할 때만 성능을 비교하세요. 가능한 한 같은 지역, 같은 연결 방식, 비슷한 시간대에 테스트해야 서로 다른 서버의 차이를 프로토콜 차이로 착각하지 않습니다.

3. 전송 방식·TLS·REALITY 설정 범위

프록시 프로토콜 외에도 전송 방식과 보안 계층이 연결 성립 여부를 좌우하는 경우가 많습니다. 전송 설정은 데이터의 구성과 전달 방식을, 보안 설정은 연결 상대를 확인하고 내용을 보호하는 방식을 나타냅니다. 서로 조합할 수는 있지만 임의로 섞어 쓸 수는 없습니다. 서버가 특정 전송 방식과 보안 구성을 사용한다면 클라이언트도 이에 맞춰야 합니다. 클라이언트 메뉴에 더 많은 선택지가 있다는 것은 설정할 수 있다는 뜻일 뿐입니다. 구독 안내를 확인할 때는 프로토콜, 전송 방식, 보안 계층을 하나의 조합으로 기록하세요. 한 항목의 이름만 따로 떼어 전체 설정인 것처럼 판단하지 마세요.

TCP·WebSocket·gRPC

TCP로 데이터를 직접 전달하면 연결 구조가 비교적 단순하지만, 새 연결을 만들 때 TCP 연결 설정과 보안 핸드셰이크, 프록시 인증이 필요할 수 있습니다. WebSocket은 HTTP 핸드셰이크 후 양방향 데이터를 전달하므로 경로와 요청 헤더의 호스트 정보를 확인해야 하는 경우가 많습니다. 경로의 대소문자와 맨 앞 슬래시, 서버의 리버스 프록시 규칙도 일치 여부에 영향을 줄 수 있습니다. 핸드셰이크가 거부되면 프로토콜 비밀번호뿐 아니라 요청이 올바른 서버에 도달했는지도 확인하세요. 일반 웹페이지가 반환됐다고 해서 프록시 인증까지 성공한 것은 아닙니다.

gRPC는 HTTP/2를 기반으로 하며 설정에 서비스 이름 같은 항목이 포함되는 경우가 많습니다. WebSocket 경로를 그대로 복사해서는 안 됩니다. 앞단의 서비스가 해당 연결 방식을 제대로 지원해야 하며, 중간 구간의 유휴 시간 제한도 장시간 연결에 영향을 줄 수 있습니다. 다른 회선에서 안정적이었던 전송 방식이 현재 서버에서도 적합하다는 보장은 없습니다. 기존 서비스를 이용한다면 명시적으로 제공된 전송 방식을 먼저 사용하세요. 직접 서버를 운영한다면 중간 프록시 기능, 연결 관리, 앱 종류를 고려해 선택하세요. 추가 캡슐화는 처리 단계를 늘릴 수 있지만 실제로 체감할 만큼 부담이 되는지는 직접 확인해야 합니다.

TLS: ‘사용 설정’보다 인증서 이름이 중요합니다

TLS는 단순히 켜고 끄는 설정이 아닙니다. 클라이언트는 인증서 신뢰 체인과 유효 기간, 대상 이름을 확인해야 하며, 일부 설정에는 애플리케이션 계층 프로토콜 협상 매개변수도 포함됩니다. 서버 이름은 보통 핸드셰이크의 이름 표시와 인증서 신원 확인에 사용됩니다. 전송 요청 헤더의 호스트 이름은 별도의 요청 처리에 쓰입니다. 배포 환경에서 우연히 같은 문자열을 사용하더라도 두 항목이 항상 같은 의미인 것은 아닙니다. 주소를 변경하거나 도메인을 이전하거나 리버스 프록시를 조정한 뒤에는 각각 다시 확인하세요. 모든 이름 항목을 한꺼번에 비우지 마세요.

인증서 오류가 발생하면 먼저 시스템 시간을 확인한 뒤 구독의 서버 이름이 유지됐는지, 서버 인증서가 유효한지 살펴보세요. 인증서 검증을 건너뛰면 연결의 신뢰 조건이 달라지므로 일상적인 문제 해결 방법으로 사용해서는 안 됩니다. 서버가 사설 신뢰 체계를 사용한다면 서비스 관리자가 올바른 신뢰 설정을 안내해야 합니다. 각 기기에서 검증을 계속 무시하도록 설정하지 마세요. 애플리케이션 계층 프로토콜 협상도 양쪽 설정이 일치해야 합니다. 관련 핸드셰이크 오류가 나오면 다른 설정에서 흔히 보이는 값을 복사하기보다 서버 요구 사항을 확인하세요.

REALITY: 서버에서 공개한 매개변수에 맞춰 설정

REALITY는 Xray 생태계의 보안 계층 방식입니다. 클라이언트 설정에는 보통 서버 이름, 서버가 제공한 공개 키, short ID, 클라이언트 지문이 포함됩니다. 클라이언트에는 공개 매개변수를 사용하며 서버 개인 키를 배포해서는 안 됩니다. 서버 이름도 임의로 선택할 수 있는 웹사이트 이름이 아닙니다. 서버 설정에서 허용한 값이어야 합니다. short ID를 비워도 되는지, 어떤 값을 입력해야 하는지는 서버 설정에 따라 다릅니다. 가져오는 과정에서 프로토콜과 UUID만 남고 나머지 매개변수가 사라지면 목록에 항목이 표시되더라도 연결되지 않을 수 있습니다.

클라이언트 지문은 지정된 핸드셰이크 동작을 선택하는 값이며 브라우저 신원이나 계정 신원, 속도 등급을 뜻하지 않습니다. 선택 가능한 값과 관련 기능은 코어마다 다를 수 있으므로 설정 출처에서 지정하고 현재 코어가 지원하는 값을 사용하세요. flow와 REALITY도 서로 다른 설정입니다. flow는 프로토콜 동작이고 REALITY는 보안 계층입니다. 함께 쓰이는 경우가 많더라도 각각 확인해야 합니다. 로그에 보안 유형을 지원하지 않는다고 나오면 먼저 코어를 확인하세요. 핸드셰이크 단계까지 진행된 뒤 실패한다면 서버 이름, 공개 키, short ID, 네트워크 연결을 점검하세요.

최종 점검은 서버 주소와 포트 확인, 프록시 프로토콜과 인증 정보 확인, 전송 항목 점검, 보안 계층 매개변수 대조 순으로 진행하세요. 각 계층을 확인할 때마다 로그의 구체적인 오류를 기록해 두세요. 그러면 연결 대상에 도달하지 못한 경우, 전송 설정이 맞지 않는 경우, 신원 인증이 실패한 경우를 구분할 수 있습니다. 경로와 서버 이름, flow를 한꺼번에 바꾸면 연결이 복구되더라도 원인을 알기 어렵고, 다음 구독 업데이트 후 같은 문제가 반복될 수 있습니다.

4. Project V·V2Fly·Xray 코어 계열

Project V는 이 도구 생태계를 이해하는 출발점이며, V2Ray는 널리 사용된 핵심 프로젝트입니다. V2Fly 커뮤니티는 관련 개발과 유지 관리를 이어가고 있고, Xray는 비슷한 코드와 설계 배경에서 출발해 독자적으로 발전한 코어 계열입니다. 두 계열은 공통 개념을 공유하면서도 각각 기능을 추가하고 구현을 변경해 왔습니다. 단순히 새 버전과 구버전의 관계가 아니므로 이름만 보고 어느 한쪽이 모든 설정에 적합하다고 판단할 수 없습니다. 선택할 때는 실제 프로토콜, 전송 방식, 보안 계층, 확장 항목을 지원하는지 확인하세요.

그래픽 클라이언트와 코어의 역할

v2rayN, v2rayNG, v2flyNG는 사용자가 설정을 저장하고 구독을 가져오며 라우팅을 구성하고 코어를 실행하는 그래픽 클라이언트입니다. 프록시 연결을 실제로 처리하는 것은 주로 코어입니다. 화면에 특정 항목이 표시된다고 해서 현재 실행 중인 코어가 그 항목을 지원하는 것은 아닙니다. 링크를 가져올 수 있어도 전체 호환성이 확인된 것은 아닙니다. 시작 오류가 발생하면 클라이언트 이름과 실제 코어 종류, 오류 내용을 함께 기록하세요. 판단에 필요한 정보 없이 ‘가져오기는 성공했지만 작동하지 않는다’고만 보고하지 마세요.

데스크톱에서는 v2rayN을 우선 사용하고, 지원되는 설정과 옵션에서 실제 사용 중인 코어를 확인할 수 있습니다. Android의 v2rayNG는 주로 Xray 코어를 기반으로 하며, v2flyNG는 v2fly 코어를 사용하는 대안입니다. 실제 기능은 설치 패키지에 포함된 코어와 클라이언트 구현에 따라 달라집니다. 클라이언트를 바꾸기 전에 문제가 프로토콜 기능 미지원인지, 로컬 권한이나 구독 변환 또는 서버 설정 오류인지 확인하세요. 화면만 바꾼다고 잘못된 인증 정보가 자동으로 수정되지는 않습니다.

구조가 비슷해도 확장 항목은 호환되지 않을 수 있습니다

두 코어 계열은 인바운드, 아웃바운드, 라우팅, DNS 같은 개념을 공유하고 일부 설정 구조도 비슷해 기본 설정은 옮길 수 있습니다. 하지만 확장 프로토콜, 보안 계층, flow 옵션, DNS 동작, 일부 항목 이름은 다를 수 있습니다. REALITY와 일반적인 Vision flow 조합은 Xray의 명시적인 지원 범위에 맞춰 확인해야 하며, v2fly 코어에서도 바로 작동한다고 가정해서는 안 됩니다. 반대로 특정 코어용으로 만든 설정 파일도 이름만 바꿔 다른 코어에서 사용할 수는 없습니다.

설정을 옮길 때는 공유 링크와 네이티브 설정 파일을 구분해야 합니다. 공유 링크에는 단일 서버의 연결 매개변수가 담깁니다. 클라이언트는 이를 바탕으로 로컬 연결, 라우팅, DNS 설정을 새로 만들 수 있습니다. 네이티브 JSON 설정에는 해당 항목이 이미 포함되어 있을 수 있으며 사용자 지정 태그나 파일 경로에 의존할 수도 있습니다. 아래는 두 코어에서 흔히 쓰이는 라우팅 규칙 구조의 예시입니다. 기존 설정에 병합하고 해당 아웃바운드 태그가 정의되어 있는지 확인하세요. 단독으로 실행할 수 있는 완전한 설정이 아니며 서버 인증 매개변수도 바꾸지 않습니다.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "0-65535",
        "outboundTag": "proxy"
      }
    ]
  }
}

이 규칙은 사설 주소를 직접 연결하고 나머지 포트는 프록시 아웃바운드로 보냅니다. 주소 데이터베이스를 사용해 일치시키려면 실행 환경에 해당 리소스가 있어야 합니다. 기존 설정에 direct 또는 proxy라는 아웃바운드가 없다면 존재하지 않는 참조를 추가하지 말고 실제 태그로 바꾸세요. 규칙은 순서대로 적용되므로 범위가 넓은 조건을 앞에 놓으면 뒤의 구체적인 조건이 가려집니다. 그래픽 클라이언트가 설정을 자동 생성한다면 사용자 지정 규칙이 다시 생성되는 과정에서 덮어써지지 않는지도 확인하세요.

코어를 바꾸기 전에 되돌릴 수 있도록 준비하세요

v2rayN에서 코어 관련 설정을 변경하기 전에 현재 설정을 백업하고 시스템 프록시, 라우팅 모드, DNS의 기존 상태를 기록하세요. 변경 후에는 먼저 코어가 정상적으로 시작되는지 확인한 다음 같은 서버 설정으로 연결을 테스트하세요. 알 수 없는 항목이나 지원하지 않는 보안 유형이라는 오류가 로그에 명확히 표시되면 원래 설정을 복원하고 지원 범위를 확인하세요. 프로그램이 시작될 때까지 항목을 계속 삭제하지 마세요. 설정이 불러와지는 것은 첫 단계일 뿐이며 인증, 도메인 조회, 앱 접속도 각각 검증해야 합니다.

클라이언트 업데이트와 코어 업데이트가 항상 함께 이루어지는 것은 아닙니다. 화면 변경은 설정 관리에만 영향을 줄 수 있지만 코어 변경은 프로토콜 지원이나 기본 동작을 바꿀 수 있습니다. 업데이트 안내에서는 버전 숫자만 좇지 말고 현재 설정과 관련된 기능을 확인하세요. 이 페이지에서는 특정 버전을 모든 사용자에게 필요한 기준으로 제시하지 않습니다. 다운로드할 때는 플랫폼별 다운로드 페이지에서 올바른 설치 파일을 선택하세요. 이전하기 전에 기존 설정을 보관하고, 완료한 뒤 실제 기능으로 호환성을 확인하세요.

5. 구독 형식과 공유 링크 호환성

구독 주소는 여러 설정을 가져오는 경로이지 프록시 프로토콜의 한 종류가 아닙니다. 서버가 반환하는 데이터는 공유 링크 목록, 인코딩된 텍스트, 구조화된 설정 형식일 수 있습니다. 클라이언트는 먼저 응답 형식을 인식한 뒤 각 항목을 편집하고 실행할 수 있는 설정으로 변환해야 합니다. 따라서 ‘구독 업데이트 성공’, ‘서버 항목 표시’, ‘연결 성공’은 서로 다른 단계입니다. 호환성을 점검할 때 각 단계를 따로 확인하세요. 데이터 일부를 받았다는 이유만으로 모든 항목이 올바르게 해석됐다고 판단하지 마세요.

링크 형식이 비슷해도 인코딩된 항목은 다를 수 있습니다

VMess 공유 링크는 인코딩된 구조화 데이터를 사용하는 경우가 많습니다. VLESS와 Trojan은 주소와 비슷한 형식으로 인증 정보를 사용자 이름 위치에 넣고, 쿼리 매개변수로 전송 및 보안 항목을 추가하는 경우가 많습니다. SS 공유 링크에는 암호화 방식과 비밀번호의 인코딩도 포함됩니다. 이는 일반적인 형식일 뿐 모든 생성기가 동일하게 동작한다는 뜻은 아닙니다. 메모에 들어간 한글, 공백, 특수문자는 올바르게 인코딩해야 하며 인증 정보에 포함된 특수문자를 링크 정리를 위해 수동으로 지워서는 안 됩니다.

같은 항목도 형식에 따라 이름이 다를 수 있습니다. 예를 들어 한 공유 형식에서는 서버 이름을 짧은 매개변수로 나타내지만 네이티브 설정에서는 별도의 보안 설정 객체에 넣을 수 있습니다. 가져오기 도구가 항목을 변환하지만 모든 신규 확장을 지원하는 것은 아닙니다. 가져온 뒤 메모 이름만 보지 말고 편집 화면에서 프로토콜, 전송 방식, 서버 이름, flow, REALITY 관련 항목을 확인하세요. 이름이 같은 항목이 여러 개라면 새 구독에서 갱신된 설정을 선택했는지도 확인하세요. 예전 설정으로 새 구독을 테스트하는 일을 막을 수 있습니다.

구독을 업데이트하면 로컬 수정 사항이 유지되지 않을 수 있습니다

많은 클라이언트는 구독 설정과 수동 서버 설정을 별도로 관리하며, 업데이트할 때 구독에 속한 항목을 새로 만들 수 있습니다. 구독 항목의 경로나 flow, 메모를 직접 수정하면 다음 업데이트에서 덮어써질 수 있습니다. 임시로 비교해야 한다면 독립된 수동 설정으로 복사하고 용도를 적어 두세요. 문제를 확인한 뒤 구독 원본을 수정해 서로 다른 설정을 여러 개 관리하지 않도록 하세요. 한 번 수정한 내용을 보존하려고 업데이트를 계속 중단하면 서버 주소나 인증 정보가 바뀌었을 때 로컬 설정이 오래되어 작동하지 않을 수 있습니다.

v2rayN에서는 ‘구독 그룹 설정’에서 주소와 그룹을 확인한 뒤 구독을 업데이트할 수 있습니다. Android 클라이언트에서는 구독 관리 및 업데이트 메뉴에서 같은 정보를 확인하세요. 메뉴 이름은 화면에 따라 다를 수 있지만 확인할 사항은 같습니다. 그룹이 저장됐는지, 요청이 성공했는지, 응답 형식을 인식했는지, 대상 항목이 현재 그룹에 속하는지 확인하세요. 업데이트 후 항목 수가 갑자기 줄었다면 모든 설정을 바로 지우지 말고 업데이트 로그와 형식을 먼저 살펴보세요. 작업 전에 백업하면 유효한 비교 자료를 보존할 수 있습니다.

구독 변환으로 지원되지 않는 기능을 추가할 수는 없습니다

형식 변환은 한 형식의 항목을 다른 형식의 이에 해당하는 항목으로 바꿀 수는 있지만, REALITY를 지원하지 않는 코어에 해당 구현을 추가하거나 누락된 비밀번호의 올바른 값을 알아낼 수는 없습니다. 가져온 뒤 항목이 사라졌다면 먼저 원본 데이터에 해당 항목이 실제로 포함되어 있었는지 확인하고, 그다음 가져오기 도구가 이를 인식했는지 살펴보세요. 전체 구독 주소를 출처가 불분명한 변환 사이트에 입력하지 마세요. 구독 주소에는 접근 인증 정보가 들어 있어 노출되면 다른 사람이 같은 설정 모음에 접근할 수 있습니다. 문제를 공유할 때는 민감한 정보를 가린 항목과 오류 내용만 제공하세요.

여러 기기에서 같은 구독을 사용하면 서버 설정을 일치시킬 수 있지만 시스템 프록시, VPN 권한, 앱 필터, DNS는 보통 기기마다 따로 설정해야 합니다. 백업 파일에 기기별 경로나 로컬 포트가 저장될 수도 있으므로 다른 플랫폼에서 복원하면 바로 실행된다고 가정하지 마세요. 자세한 이전 방법은 여러 기기 간 설정 동기화를 참고하세요. 처음 가져오는 기본 절차는 빠른 시작 가이드를 따르세요. 이 절에서는 형식과 항목의 차이를 다룹니다.

6. 연결 속도와 리소스 사용량 비교

‘빠르다’는 말에는 첫 페이지가 빨리 열리는지, 전송 속도가 안정적인지, 유휴 상태 후 빠르게 복구되는지 등 여러 의미가 있습니다. 각각 영향을 받는 요인이 다릅니다. 처음 접속할 때는 DNS 조회와 연결 설정, 보안 핸드셰이크, 프록시 인증을 거칩니다. 지속적인 전송 속도는 회선 대역폭, 혼잡, 패킷 손실, 서버 부하, 기기 처리 성능의 영향을 더 많이 받습니다. 유휴 상태에서 복구할 때는 연결이 정리됐는지, 모바일 기기가 절전 상태인지도 관련될 수 있습니다. 한 가지 테스트 결과만으로 프로토콜 전체의 성능을 판단하면 서로 모순되는 결론에 도달하기 쉽습니다.

조건을 맞춘 다음 프로토콜을 비교하세요

서버에서 여러 프로토콜 연결을 제공한다면 같은 기기와 연결 방식, 비슷한 시간대에 테스트하세요. 같은 앱에서 같은 작업을 수행하고 라우팅 모드와 DNS 설정도 유지해야 합니다. 프로토콜마다 다른 지역의 서버에 연결한다면 결과는 프로토콜보다 회선 차이를 주로 반영합니다. 새 연결과 기존 연결을 재사용한 접속도 구분하세요. 브라우저에서 같은 페이지를 두 번째 열 때 빨라졌다면 프로토콜 변경이 아니라 캐시나 연결 재사용 때문일 수 있습니다.

프로토콜의 처리 부담은 핸드셰이크 횟수, 캡슐화 단계, 인증 처리, 암호화 연산, 연결 관리 측면에서 살펴볼 수 있습니다. 간결한 프로토콜 계층은 일부 작업을 줄일 수 있지만 외부 전송 방식이 복잡하거나 기기에서 관련 하드웨어 가속을 지원하지 않으면 실제 차이가 예상과 다를 수 있습니다. TLS 연결 재개로 다음 연결에 필요한 비용이 줄어들 수도 있지만, 구체적인 구현과 연결 조건에 따라 달라집니다. 통제된 테스트 없이 특정 프로토콜이 항상 빠르다거나 특정 암호화 방식이 무조건 리소스를 덜 쓴다고 단정하지 마세요.

CPU·메모리 사용량은 전체 처리 경로를 반영합니다

CPU 사용량에는 암호화뿐 아니라 데이터 복사, DNS 조회, 규칙 매칭, 로그 기록, 로컬 연결 처리도 포함됩니다. TUN 모드와 시스템 프록시 모드는 처리 경로가 다르므로 두 프로토콜을 각각 다른 방식으로 테스트하면 연결 방식 차이가 함께 반영됩니다. 메모리는 규칙 데이터베이스, 활성 연결, DNS 캐시, 그래픽 인터페이스에서 사용될 수 있습니다. 작업 관리자에서 클라이언트 전체의 메모리 사용량이 높게 보여도 프로토콜 자체의 사용량이 높다고 단정할 수 없습니다. 유휴 상태와 같은 부하를 가한 상태의 변화를 함께 살펴보세요.

다중화는 기존 연결 하나에서 여러 논리 스트림을 전달해 반복적인 연결 설정을 줄일 수 있지만, 혼잡과 장애의 영향 범위도 바꿉니다. 전송 연결에서 패킷 손실이 발생하면 여러 요청이 동시에 영향을 받을 수 있습니다. 전송 방식 자체에 스트림 관리 기능이 있다면 다중화를 추가해도 이득이 크지 않을 수 있습니다. 특정 flow에 의존하는 조합은 코어 안내를 따라야 합니다. ‘최적화’를 위해 모든 다중화 옵션을 켜지 말고 기본 동작을 유지한 뒤 짧은 연결이 많은 환경이나 특정 앱에서 효과를 확인하세요.

UDP·DNS·연결 복구를 각각 테스트하세요

웹페이지가 열린다고 앱에서 필요한 UDP가 제대로 전달된다는 뜻은 아닙니다. 실시간 음성·영상, 일부 대화형 앱, 특정 전송 경로는 UDP를 사용할 수 있습니다. UDP 지원 여부는 로컬 연결 방식, 프록시 프로토콜, 코어, 서버가 함께 결정합니다. 설정을 선택할 때 앱에서 실제로 필요한 트래픽 유형을 확인하고 프로토콜 이름만으로 전체 경로를 판단하지 마세요. 특정 앱에서만 문제가 발생한다면 앱 요청이 프록시에 들어오는지, UDP가 올바른 아웃바운드로 라우팅되는지, 서버에서 해당 전달을 허용하는지 확인하세요.

DNS 사용 경험도 한 번의 조회 결과만으로 판단할 수 없습니다. 캐시 적중 여부, 동시 조회, DNS 처리 위치, 라우팅 정책이 이후 연결에 영향을 줍니다. 브라우저에서 자체 DNS 기능을 사용하면 클라이언트의 DNS 설정이 모든 조회를 제어하지 않을 수 있습니다. 문제를 확인할 때는 먼저 조회가 실제로 어디에서 처리되는지 파악하고, 반환된 주소와 출구 경로가 일치하는지 살펴보세요. 프로토콜을 바꾼 직후 캐시가 비워져 잠시 나아진 것처럼 보일 수도 있습니다. 변경 전후 조건을 기록해야 원인과 현상을 구분할 수 있습니다.

같은 시간대에 모든 프로토콜이 느리다면 로컬 네트워크와 공통 서버 환경부터 확인하세요. 첫 접속만 느리다면 DNS와 핸드셰이크를 살펴보세요. 전송이 계속 끊기면 패킷 손실, 유휴 시간 제한, 리소스 사용량을 확인하세요. 특정 앱만 영향을 받는다면 연결 방식과 라우팅으로 돌아가세요. 단계별 진단 방법은 느린 연결 단계별 점검에서 확인할 수 있습니다. 문제를 진단하기도 전에 프로토콜을 바꾸기보다 원인을 먼저 찾으세요.

7. Android 배터리 소모와 백그라운드 연결

Android 배터리 소모를 VMess, VLESS 또는 특정 코어 이름 탓으로만 돌릴 수는 없습니다. 시스템 VPN으로 연결한 클라이언트가 선택된 앱의 네트워크 요청을 계속 처리하면서 CPU 깨우기, 무선 네트워크 활성화, DNS 조회, 재연결, 로그 기록에 전력을 사용합니다. 같은 설정이라도 Wi-Fi와 모바일 데이터에서 결과가 달라질 수 있고 신호가 약하면 소모량이 크게 늘 수도 있습니다. 비교하기 전에 네트워크 환경과 화면 상태, 포그라운드 앱을 맞춰 프록시 프로토콜 외의 사용 차이가 결과에 섞이지 않도록 하세요.

VpnService 권한과 백그라운드 제한

v2rayNG 또는 v2flyNG가 로컬 VPN 서비스를 처음 설정할 때 Android 시스템 권한이 필요합니다. 권한을 허용한 뒤 앱 상태와 로그를 확인하고 대상 앱에서 인터넷이 되는지 테스트하세요. 시스템 VPN 아이콘만으로 원격 연결이 된다고 판단할 수는 없습니다. 같은 연결 경로를 사용하는 다른 앱이 이미 실행 중이면 현재 연결을 함께 만들지 못할 수 있습니다. 프로토콜을 계속 바꾸기 전에 시스템에서 실제로 어떤 서비스가 유지되는지 확인하세요. 일부 제조사 기기는 백그라운드 서비스에 추가 제한을 적용하기도 합니다.

화면을 잠근 뒤 연결이 끊기고 클라이언트에 다시 들어가면 복구되는 경우에는 배터리 최적화, 백그라운드 활동 권한, 자동 시작 설정을 확인해야 합니다. 설정 경로는 제조사마다 다르므로 시스템 앱 정보에서 배터리 또는 백그라운드 관련 항목을 찾아 필요한 클라이언트만 조정하세요. 백그라운드 제한을 완화하면 연결 유지에는 도움이 될 수 있지만 백그라운드 활동 시간도 늘어날 수 있으므로 일괄적인 절전 방법으로 사용하지 마세요. 조정한 뒤 동일한 시간 동안 화면을 잠가 프로세스가 시스템에 의해 일시 중지되거나 종료된 것이 원인인지 확인하세요.

암호화를 무작정 줄이기보다 불필요한 재연결을 줄이세요

연결이 반복해서 실패하면 DNS 조회와 핸드셰이크, 인증을 거듭 수행합니다. 모바일 네트워크에서는 무선 모듈이 반복해서 깨어날 수도 있습니다. 같은 핸드셰이크 오류가 로그에 계속 나오면 재시도를 계속하기보다 서버 이름, 보안 매개변수, 시스템 시간을 먼저 수정하세요. Wi-Fi와 모바일 데이터 사이에서 네트워크가 전환되면 기존 연결이 끊겨 새 경로를 만들어야 할 수 있습니다. 이런 복구 동작만으로 프로토콜이 불안정하다고 판단할 수는 없습니다. 네트워크 전환 때만 문제가 생기는지 기록하면 연결 중 발생하는 끊김과 구분하는 데 도움이 됩니다.

절전을 위해 보안 계층을 끄면 연결 보호 조건이 달라지므로 일반적인 최적화 방법으로 적절하지 않습니다. 먼저 불필요한 백그라운드 앱 요청, 반복적인 연결 테스트, 장시간의 상세 로그, 지나치게 잦은 구독 업데이트를 점검하세요. 문제를 해결할 때 필요한 수준으로 로그를 켜고 정보를 충분히 모은 뒤 평소 설정으로 되돌리세요. 네트워크 사용량은 적은데 기기가 뜨거워진다면 선택한 프로토콜의 암호화 연산이 과도하다고 단정하지 말고 실패가 반복되는지, 비정상적인 앱이 있는지 살펴보세요.

앱별 프록시가 바꾸는 연결 대상

앱별 프록시를 사용하면 지정한 앱만 프록시를 거치게 하거나 지정한 앱을 프록시에서 제외할 수 있습니다. 구체적인 옵션 이름은 클라이언트 화면에서 확인하세요. 두 모드의 의미는 반대이므로 어떤 앱에 체크했는지만 봐서는 안 됩니다. 설정 후 대상 앱을 다시 테스트하세요. 일부 앱은 별도 구성 요소를 통해 로그인, 다운로드, 시스템 서비스 요청을 처리하므로 기본 앱만 선택하면 전체 과정에 적용되지 않을 수 있습니다. 앱별 설정 때문에 로그인 페이지와 메인 화면이 서로 다른 경로를 사용하면 일부 기능만 작동할 수 있습니다.

앱별 프록시는 도메인별 라우팅과 다른 기능입니다. 앱별 프록시는 어떤 앱의 트래픽을 로컬 연결로 보낼지 정하고, 라우팅은 클라이언트에 들어온 요청을 어떤 아웃바운드로 보낼지 정합니다. 앱이 제외되면 클라이언트의 도메인 규칙을 바꿔도 영향을 주지 않는 경우가 많습니다. 반대로 앱이 연결 경로에 들어와도 라우팅 규칙에 따라 직접 연결될 수 있습니다. 문제를 해결할 때 먼저 앱 필터를 확인하고 그다음 라우팅을 살펴보세요. 두 설정을 동시에 바꾸면 어느 계층에서 달라졌는지 알기 어렵습니다.

배터리 소모는 연결 직후의 순간적인 수치가 아니라 평소 사용 과정을 기준으로 비교해야 합니다. 시스템 배터리 기록을 볼 때는 앱 사용 시간과 실제 작업도 함께 고려하고 짧은 변화를 고정적인 결과로 해석하지 마세요. 자세한 조작 방법은 v2rayNG 권한·절전·앱별 설정을 참고하세요. 설정을 선택할 때는 먼저 프로토콜 호환성과 연결 안정성을 확보한 뒤 불필요한 작업을 줄이세요. 모바일 기기에서는 프로토콜 이름을 따지기보다 반복되는 연결 실패를 해결하는 편이 더 실용적입니다.

8. 사용 환경에 맞는 선택과 호환성 확인

최종 선택은 네 가지 질문으로 정리할 수 있습니다. 어떤 기기와 클라이언트를 사용하는지, 서버에서 어떤 조합을 제공하는지, 앱에 어떤 연결 방식과 트래픽 유형이 필요한지, 문제가 발생했을 때 안정적으로 재현할 수 있는지 확인하세요. 호환성을 먼저 해결하고 성능을 평가한 뒤 선택적인 최적화 항목을 조정해야 합니다. 서버와 코어에서 분리된 최적의 프로토콜은 없습니다. 출처가 불분명하지만 이름이 최신인 조합보다 안정적이고 관리하기 쉬우며 설정이 명확한 구성이 일상적인 사용에 더 적합합니다.

데스크톱 일상 사용: v2rayN부터 시작

Windows, macOS, Linux 데스크톱에서는 기기 아키텍처와 운영체제에 맞는 v2rayN 설치 파일부터 확인하세요. Windows 데스크톱 버전과 클래식 WPF 버전의 차이는 주로 인터페이스 기술과 사용 방식에 있으므로 원격 프로토콜 성능 차이로 바로 이어지지는 않습니다. 설치 및 실행 방법은 Windows 설치·설정 안내를 참고하세요. macOS에서 시스템 권한 안내가 표시되면 설치 및 권한 문제 해결을 확인하세요. 먼저 클라이언트를 정상적으로 실행한 다음 설정을 가져오세요.

브라우저와 시스템 프록시를 따르는 데스크톱 앱은 시스템 프록시로 최소한의 연결 테스트부터 진행하세요. 필요한 경우에만 TUN 같은 연결 방식을 검토하세요. 처음 설정을 가져올 때 사용자 지정 DNS, 복잡한 라우팅, 코어 변경을 한꺼번에 적용하지 마세요. 설정이 완전한 서버 하나를 선택해 코어 시작과 실제 접속을 확인한 다음 필요한 규칙을 하나씩 추가하세요. 규칙을 추가한 뒤 기존 설정이 작동하지 않으면 먼저 규칙을 되돌리고 프로토콜 종류는 함께 변경하지 마세요.

Android: 코어 요구 사항과 대상 앱에 맞춰 선택

서버에서 Xray 기능이 필요한 VLESS·REALITY 조합을 제공한다면 v2rayNG의 실제 지원 여부와 전체 매개변수를 먼저 확인하세요. v2fly 코어용 설정이 필요한 경우에는 v2flyNG를 대안으로 고려하고, 전송 방식과 각 항목이 지원 범위에 들어가는지 확인하세요. 두 클라이언트 사이에서 이전할 때는 설정 하나만 옮겨 테스트하고 모든 데이터를 바로 덮어쓰지 마세요. 시스템 VPN 권한, 백그라운드 권한, 앱별 선택도 새 클라이언트에서 다시 확인해야 합니다.

일부 앱만 프록시가 필요하다면 앱별 모드를 사용해 불필요한 연결 범위를 줄일 수 있습니다. 여러 앱이 서로 연동된다면 먼저 관련 구성 요소를 파악해 로그인 연결이 끊기도록 지나치게 나누지 마세요. 실시간 통신이나 다른 UDP 트래픽이 필요하면 웹페이지가 열리는지만 보지 말고 전체 경로를 검증하세요. 네트워크를 자주 바꾸는 기기라면 화면 잠금 후 복구와 네트워크 전환 후 재연결도 확인해 실제 사용 환경에서 작동하는지 점검하세요.

기존 구독과 자체 운영 서버는 선택 순서가 다릅니다

기존 구독을 사용한다면 프로토콜은 보통 서비스 제공자가 정합니다. 사용자는 올바른 클라이언트를 선택하고 모든 항목을 보존하며 적절한 서버 연결을 고르고 로컬 연결 방식을 확인할 수 있습니다. 클라이언트가 서버 프로토콜을 다른 종류로 변환할 수 있다고 기대하지 마세요. 직접 서버를 운영한다면 먼저 클라이언트와 앱의 요구 사항을 정한 다음 양쪽에서 지원하는 프로토콜, 전송 방식, 보안 계층을 선택하고 인증서나 키 관리 방법도 마련하세요. 불필요한 캡슐화를 줄이면 문제 해결 범위를 좁힐 수 있지만 인증을 생략해서는 안 됩니다.

여러 플랫폼에서 설정을 함께 사용하려면 한 기기에서 성공하는 것만 기준으로 삼지 말고 대상 클라이언트 전체가 실제로 지원하는 기능의 공통 범위를 선택하세요. 용도가 다른 설정을 별도로 보관할 수 있지만 메모와 지원 기기를 명확히 구분해야 합니다. 서버의 프로토콜이나 보안 설정을 변경한 뒤에는 각 기기에서 하나씩 확인하세요. 오래된 항목과 구독 캐시, 수동 복사본을 특히 주의해서 살펴보세요. 사용자 지정 네이티브 설정은 로컬 경로와 규칙 리소스, 아웃바운드 태그도 확인해야 합니다. 이런 항목을 여러 기기에 그대로 복사할 수 있는 서버 매개변수로 착각하지 마세요.

마지막으로 점검 순서에 따라 확인하세요

1. 클라이언트와 기기 아키텍처가 올바른지, 코어가 시작되는지, 로컬 포트가 충돌하지 않는지 확인하세요.
2. 프로토콜, 주소, 포트, 인증 항목과 전송 및 보안 계층에 필요한 모든 매개변수를 대조하세요.
3. 시스템 프록시 또는 VPN 연결이 활성화됐는지 확인한 뒤 상태 아이콘만 보지 말고 실제 앱으로 테스트하세요.
4. DNS 조회와 라우팅 결과, 필요한 트래픽 종류를 각각 확인하고 재현 가능한 오류 내용을 기록하세요.
5. 마지막으로 화면 잠금, 네트워크 전환, 장시간 사용을 테스트해 구독을 업데이트한 뒤에도 설정이 예상대로 유지되는지 확인하세요.

원인을 계속 찾기 어렵다면 먼저 정상 작동이 확인된 설정 하나로 복원하고 차이를 비교한 뒤 이 페이지의 계층별 방법으로 문제를 좁혀 보세요. 요청 오류가 로컬 연결, 원격 연결 설정, 핸드셰이크 인증, 라우팅 또는 DNS 중 어디에서 발생했는지에 따라 다음에 확인할 항목이 달라집니다. 문제를 공유할 때는 운영체제, 클라이언트, 코어 종류, 프로토콜 조합, 민감한 정보를 가린 로그만 제공하세요. 비밀번호, UUID, 구독 주소는 공개하지 마세요. 처음부터 설정 과정을 다시 진행하려면 빠른 시작 가이드로 돌아가세요. 다른 플랫폼용 설치 파일이 필요하면 클라이언트 다운로드 페이지를 이용하세요. 문제를 해결하는 동안 검증되지 않은 설정을 여러 개 추가하지 마세요.