V2Ray 프로토콜·코어 가이드

01 / CONFIGURATION LAYERS

설정 계층: 프로토콜은 연결의 일부

먼저 네 가지 설정을 구분하세요

노드 이름은 기술 사양이 아닙니다. 목록에 지역이나 용도가 적혀 있어도 어떤 프로토콜을 사용하는지는 알 수 없습니다. v2rayN에서 노드 편집 창을 열고 프로토콜 유형, 전송 방식, 전송 계층 보안 설정 순으로 확인하세요. 이 항목은 각각 요청 형식, 데이터 전달 방식, 암호화 및 서버 인증 방법을 결정합니다. 코어는 이러한 규칙을 실제로 실행합니다. 계층을 구분해야 둘 다 VLESS로 표시된 노드가 왜 서로 다른 설정과 연결 결과를 보이는지 이해할 수 있습니다.

프로토콜은 인증 정보, 대상 주소, 요청 형식을 정합니다. 예를 들어 VMess는 사용자 식별자를 인증에 사용하고, Trojan은 비밀번호로 요청을 인증하며, Shadowsocks는 선택한 암호화 방식과 그에 맞는 키를 사용합니다. 전송 계층은 데이터를 직접 전달하는 TCP일 수도 있고, WebSocket 같은 방식을 추가로 사용할 수도 있습니다. TLS와 REALITY는 연결 보안과 관련된 방식이므로 프로토콜과 같은 항목에 놓고 서로 대체 가능한 선택지로 보면 안 됩니다. 설정 화면에서 함께 표시되는 것은 입력을 편리하게 하기 위해서일 뿐, 같은 계층이라는 뜻은 아닙니다.

서버에서 받은 설정을 기준으로 역순 확인

노드를 점검할 때는 주소와 포트가 같은 설정에 속하는지 확인한 뒤 인증 정보를 살펴보세요. 다음으로 네트워크 유형, 경로, 서비스 이름, 보안 계층을 확인합니다. WebSocket 경로는 서버 설정과 일치해야 하며, gRPC 서비스 이름을 다른 노드에서 그대로 복사해서는 안 됩니다. 도메인은 서버 주소, TLS 서버 이름, 전송 요청 헤더에 각각 들어갈 수 있습니다. 세 값이 같을 수도 있지만 용도가 서로 다를 수도 있습니다. 모든 항목을 연결 주소로 바꾸면 문제가 해결되기는커녕 올바른 설정을 망가뜨릴 수 있습니다.

클라이언트의 서버 이름은 일반적으로 TLS의 SNI에 해당합니다. 핸드셰이크에서 접속할 이름을 알리고 인증서 이름을 확인하는 데도 쓰입니다. WebSocket 요청 헤더의 Host는 애플리케이션 계층의 요청 정보입니다. 연결 주소는 처음 접속할 대상을 정하고, 나머지 두 이름은 그다음 단계에서 서로 다른 역할을 합니다. 제공업체가 전체 공유 링크를 제공했다면 원래 값을 유지하세요. 명확한 설정 안내를 받은 경우에만 개별 항목을 변경하세요. 이름이 서로 다르더라도 용도를 먼저 확인하고, 단지 통일되지 않아 보인다는 이유로 오류라고 판단하지 마세요.

로컬 연결과 원격 연결 구분

시스템 프록시와 Tun은 원격 프로토콜이 아닙니다. 시스템 프록시는 해당 설정을 따르는 앱의 요청을 로컬 프록시 포트로 전달합니다. Tun은 가상 네트워크 인터페이스를 만들어 더 많은 트래픽을 클라이언트 처리 과정으로 보냅니다. 둘 다 트래픽이 코어에 들어오는 방식을 바꿀 뿐, VMess를 VLESS로 바꾸거나 서버에 없는 기능을 보완하지는 않습니다. 웹페이지가 열리지 않을 때 로그에 해당 요청이 전혀 없다면 로컬 연결부터 점검하세요. 요청이 코어에 전달됐지만 핸드셰이크에 실패했다면 원격 프로토콜과 보안 설정을 확인해야 합니다.

라우팅과 DNS도 별도로 이해해야 합니다. 라우팅은 요청이 사용할 출구를 정하고, DNS는 도메인을 주소로 변환합니다. 연결 테스트에 성공해도 테스트 경로의 일부 단계가 정상 작동했다는 뜻일 뿐, 모든 도메인이 같은 출구를 사용한다는 보장은 없습니다. 라우팅 규칙을 바꾸면 노드는 그대로여도 일부 사이트의 접속 결과가 달라질 수 있습니다. 문제를 확인할 때는 변경한 계층을 기록하고 한 번에 한 종류의 설정만 수정하세요. 단계별 점검에는 연결됐지만 인터넷이 안 될 때 점검 목록도 참고할 수 있습니다.

02 / PROTOCOL CHOICES

프로토콜 설계: 네 가지 방식의 차이

VMess: 인증과 암호화를 함께 설계

VMess는 Project V 생태계의 주요 프로토콜입니다. 사용자 인증, 요청 헤더, 데이터 보호를 하나의 규칙으로 다뤄 프록시 연결을 통합적으로 설정해야 하는 경우에 적합합니다. 단순한 비밀번호 항목이 아니라 사용자 식별자, 인증 과정, 암호화 방식도 관련됩니다. 현재 설정은 클라이언트가 해석할 수 있는 인증 방식에 맞추고, 오래된 스크린샷을 따라 과거 항목을 임의로 추가하지 마세요. 일부 인증 과정은 시간에 민감하므로 기기의 시계가 크게 어긋나면 설정이 올바르게 보여도 인증에 실패할 수 있습니다.

v2rayN에서 VMess 노드를 편집할 때는 사용자 식별자, 암호화 방식, 전송 설정, TLS를 확인하세요. 공유 정보에 과거 호환용 매개변수가 포함되어 있어도 모든 구현에서 계속 유효하다는 뜻은 아닙니다. 먼저 현재 코어에서 구독을 사용할 수 있는지 확인한 뒤 설정을 다시 가져올지 결정하세요. VMess의 장점은 오랜 생태계와 널리 쓰이는 기존 배포 환경입니다. 반면 설정 개념이 비교적 한곳에 모여 있어 초보자는 프로토콜 자체의 암호화와 외부 TLS를 혼동하기 쉽습니다. 체크 항목을 중복해서 켜면 무조건 더 안전하다고 생각하지 마세요.

VLESS: 프로토콜 자체의 역할을 간결하게

VLESS는 경량 인증과 요청 형식에 초점을 둡니다. 프로토콜 자체는 일반적인 데이터 암호화 기능을 제공하지 않으므로 보통 TLS나 REALITY 같은 보안 방식과 함께 사용합니다. 여기서 ‘경량’은 프로토콜의 역할을 설명하는 말이지, 어떤 회선이든 빠르다는 보장은 아닙니다. 클라이언트의 암호화 항목이 none으로 표시되어도 연결이 평문이라고 단정할 수는 없습니다. 외부 보안 설정을 확인하세요. 반대로 외부 보안도 꺼져 있다면 프로토콜 이름만으로 암호화가 제공된다고 생각해서는 안 됩니다.

VLESS 설정에는 특정 흐름 제어 동작을 지정하는 flow 항목이 포함될 수 있습니다. 임의로 고르는 속도 향상 옵션이 아닙니다. 서버가 Vision을 요구한다면 클라이언트와 코어 모두 해당 조합을 지원해야 합니다. 비어 있는 flow를 Vision으로 바꾼다고 일반 노드에 기능이 생기지는 않으며, 전송 조건이 맞지 않으면 연결되지 않을 수도 있습니다. 노드를 비교할 때는 프로토콜, 전송, 보안 계층, flow를 하나의 조합으로 살펴보세요. 뒤에서 REALITY와 Vision의 관계 및 두 기능이 서로 다른 이유를 설명합니다.

Trojan: TLS를 기반으로 한 인증 모델

일반적인 Trojan 배포는 TLS로 전송을 보호하고 비밀번호로 프록시 요청을 인증합니다. 설정 화면은 비교적 단순해 보이지만, 연결하려면 서버 이름과 인증서, 서버 접속 지점이 모두 올바라야 합니다. 비밀번호가 맞는다고 인증서 이름 불일치까지 해결되는 것은 아닙니다. 노드를 편집할 때는 제공업체가 지정한 서버 이름과 전송 방식을 유지하세요. 비밀번호 형식이 익숙하다는 이유로 보안 계층을 무시하지 마세요. 아직 원인을 모르는 설정 오류를 가리려고 인증서 검증을 끄는 것도 피해야 합니다.

Shadowsocks: 암호화 방식과 키의 조합이 중요

Shadowsocks는 흔히 SS라고 부르며, 명확한 암호화 프록시 모델을 사용합니다. 설정은 보통 서버, 포트, 암호화 방식, 비밀번호로 구성됩니다. 암호화 방식에 따라 키 형식, 구현 지원, 프로토콜 동작이 달라질 수 있으므로 이름에 비슷한 암호 알고리즘이 포함되어 있다는 이유만으로 서로 바꿔 쓰지 마세요. 최신 방식과 기존 방식도 항목 이름 하나만 바꾼다고 호환되는 것은 아닙니다. 가져온 뒤 비밀번호 형식 오류가 표시되면 해당 방식에서 요구하는 키 인코딩을 확인하세요. 구조화된 키를 짧은 일반 비밀번호로 바꾸지 마세요.

네 가지 방식 모두 일반적인 프록시 연결에 사용할 수 있지만, 서버 배포와 무관하게 항상 우선되는 방식은 없습니다. 기존 VMess 설정이 안정적으로 작동한다면 다른 프로토콜 이름이 더 최신이라는 이유만으로 바꿀 필요는 없습니다. Xray 기능이 필요하다면 VLESS 조합 전체를 확인하고, Trojan이나 Shadowsocks를 사용할 때는 TLS 조건이나 암호화 방식 지원 여부부터 살펴보세요. 실제로 사용할 수 있는 방식은 서버가 정확한 매개변수를 제공하고, 클라이언트가 이를 표현하며, 코어가 실행할 수 있는 범위가 겹치는 경우입니다. 노드 목록에서 가장 눈에 띄는 이름이 기준은 아닙니다.

03 / SECURITY AND FLOW

TLS, REALITY, Vision의 차이

TLS: 서버를 확인한 뒤 전송을 보호

TLS는 전송을 암호화하고 인증서 등의 방식을 통해 접속 중인 서버를 확인하도록 돕습니다. 일반적인 구성에서는 인증서 신뢰 체인, 유효 기간, 이름 일치 여부를 확인해야 합니다. 노드 주소는 IP나 주소일 수 있지만 서버 이름은 인증서에 지정된 도메인일 수 있으므로 두 값을 기계적으로 합치지 마세요. 핸드셰이크에 실패하면 기기 시간과 서버 이름부터 확인하고 서버 인증서 상태를 점검하세요. ‘안전하지 않은 연결 허용’을 켜도 검증 범위만 달라질 뿐, 오류의 실제 원인은 해결되지 않습니다.

TLS 핸드셰이크 매개변수와 브라우저 동작을 흉내 내는 설정도 구분해야 합니다. 일부 클라이언트는 핸드셰이크 지문을 선택하는 옵션을 제공합니다. 이는 사용자 신원을 나타내지 않으며 사용자 식별자나 비밀번호를 대체하지도 않습니다. 모든 코어가 같은 방식으로 지원하는 것도 아닙니다. 다른 노드의 지문, 서버 이름, 애플리케이션 계층 프로토콜 목록을 그대로 복사하면 호환성 문제가 생길 수 있습니다. 서버 안내에서 요구하지 않는다면 구독에 지정된 값이나 클라이언트 기본값을 유지하고, 고급 설정을 모두 채우려고 하지 마세요.

REALITY: 핸드셰이크와 인증 방식 변경

REALITY는 일반적인 인증서 배포와 다른 연결 설정 및 인증 방식을 사용합니다. 대상 사이트의 TLS 특성과 자체 인증 설계를 조합해 동작하므로, 실제 도메인을 아무거나 입력하면 연결되는 방식이 아닙니다. 클라이언트에는 서버 이름, 공개 키, 짧은 ID 등 서로 맞는 정보가 필요하고 서버도 이에 맞게 설정되어 있어야 합니다. 공개 키는 인증 관계에 사용하며 사용자 로그인 비밀번호가 아닙니다. 짧은 ID도 서버에서 정한 인증 매개변수이므로 다른 노드의 값을 가져오거나 예시 문구를 실제 연결에 입력해서는 안 됩니다.

클라이언트 화면에서 공개 키를 Public key로 표시할 수도 있고, 구현이 바뀌면서 다른 항목 이름을 사용할 수도 있습니다. 올바르게 입력했는지 확인하려면 현재 클라이언트 안내와 구독 해석 결과를 기준으로 삼으세요. 오래된 스크린샷의 위치만 보고 판단하면 안 됩니다. 공개 키와 개인 키의 역할은 다르며, 일반 사용자는 보통 서버가 제공하는 클라이언트용 매개변수만 필요합니다. 서버 개인 키를 요청하거나 공유하지 마세요. 가져온 뒤 항목이 비어 있다면 링크에 정보가 포함됐는지, 파서가 이를 지원하는지 확인하고 이름이 비슷한 필드를 조합해 임의로 설정하지 마세요.

Vision: 흐름 제어는 암호화 스위치가 아닙니다

XTLS Vision은 특정 연결 조합에 맞춰 사용하는 흐름 제어 방식입니다. 프록시 경로에서 암호화된 트래픽을 다시 감싸는 동작을 처리해 조건에 맞는 데이터 경로의 중복 처리를 줄입니다. 모든 트래픽에 적용되는 만능 최적화도 아니고 REALITY를 켜면 자동으로 활성화되는 기능도 아닙니다. TLS와 REALITY는 연결을 안전하게 설정하는 방식을 설명하고, Vision은 특정 데이터 처리 단계를 설명합니다. 서로 관련은 있지만 역할은 다릅니다. 사용 가능 여부는 프로토콜, 전송, 코어, 서버 설정이 지원되는 조합을 이루는지에 달려 있습니다.

v2rayN이나 v2rayNG에서 이 유형의 노드를 확인할 때는 제공업체가 지정한 프로토콜인지 먼저 보고, 보안 설정을 확인한 뒤 flow를 살펴보세요. 서버에서 해당 흐름 제어를 사용하지 않는다면 클라이언트에서 Vision을 선택해도 기대한 결과를 얻기 어렵습니다. 일부 조합은 전송 방식에 명확한 제한이 있으므로 직접 TCP 전송용 설정을 WebSocket에 그대로 적용하면 안 됩니다. 가져오기는 성공했지만 시작에 실패한다면 DNS나 시스템 프록시를 바꾸기 전에 코어 로그의 매개변수 오류부터 확인하세요.

보안 매개변수를 하나씩 대조했는데도 연결되지 않는다면 주소에 도달할 수 있는지, 포트가 맞는지, 기기 시간이 올바른지, 서버에서 해당 접속 지점을 계속 제공하는지 확인하세요. 화면에 연결 성공을 표시하려고 검증 수준을 낮추지 마세요. 암호화 중복과 흐름 제어에 대해 더 알아보려면 REALITY와 XTLS Vision 원리 해설을 참고하세요. 이 글은 판단 기준을 제공하며, 실제 설정 항목은 제공업체와 현재 코어가 지원하는 조합을 따라야 합니다.

04 / CONNECTION COST

연결 속도와 리소스 사용량 확인 순서

초기 접속, 지속 전송, 상호작용을 구분하세요

‘빠르다’에는 적어도 세 가지 의미가 있습니다. 페이지를 처음 여는 데 걸리는 시간, 다운로드를 계속할 때의 처리량, 요청에 응답하는 속도입니다. 첫 접속 시간은 DNS 조회, 연결 설정, 보안 핸드셰이크의 영향을 받습니다. 지속 전송은 회선 용량과 혼잡, 양쪽 기기의 처리 능력에 더 좌우됩니다. 상호작용은 왕복 시간과 패킷 손실에 민감합니다. 노드 속도 테스트에서 전송량이 많다고 웹페이지가 반드시 더 빨리 열리는 것은 아닙니다. 프로토콜을 비교하기 전에 실제로 줄이고 싶은 대기 시간이 무엇인지 정하세요.

연결은 보통 여러 단계를 거칩니다. 도메인을 조회하고, 하위 연결을 설정하고, 보안 계층 핸드셰이크를 수행하며, 전송 방식에 따라 추가 협상을 할 수도 있습니다. 캡슐화를 추가하면 호환성이나 배포 편의성이 좋아질 수 있지만 처리 단계와 데이터 오버헤드도 늘어납니다. 그렇다고 계층 수만 세어 고정된 속도 순위를 정할 수는 없습니다. 연결 재사용, 서버 위치, 캐시 상태, 네트워크 패킷 손실에 따라 결과가 달라집니다. 왕복 시간이 긴 회선에서는 핸드셰이크 한 번을 줄이는 효과가 클 수 있지만, 다른 환경에서는 주요 요인이 아닐 수도 있습니다.

캡슐화, 재사용, 혼잡은 많을수록 좋은 게 아닙니다

WebSocket은 자체 프레임 구조로 데이터를 전달하며 이에 맞는 서버 접속 방식에 적합합니다. gRPC는 자체 프로토콜 스택을 사용하고 스트림 관리 방식도 다릅니다. 둘 다 우선 전송 및 배포 방식이지, 범용 속도 향상 버튼은 아닙니다. 연결 재사용은 연결을 반복해서 설정하는 비용을 줄일 수 있지만, 여러 요청이 하나의 하위 연결을 공유하면 같은 구간의 혼잡이나 전송 차단의 영향을 받을 수 있습니다. 서버 안내에서 특정 재사용 방식을 지원하지 않는다면 클라이언트에서 단독으로 켜도 최적화되지 않으며 요청 오류가 생길 수 있습니다.

리소스 사용량도 프로토콜 이름만으로 판단할 수 없습니다. 암호화 알고리즘의 하드웨어 지원 여부, 코어의 버퍼 할당 방식, 동시에 활성화된 연결 수, 로그의 상세 수준 등이 CPU와 메모리 사용량에 영향을 줍니다. 한 종류의 기기에서 빠른 알고리즘이 다른 기기에서도 유리하다고 볼 수는 없습니다. 화면에 표시되는 클라이언트 메모리에는 그래픽 인터페이스, 캐시, 백그라운드 작업이 포함될 수 있으므로 프로토콜 자체의 오버헤드와 같지 않습니다. 판단할 때는 실행 순간의 숫자 하나가 아니라 코어 활동과 실제 작업을 함께 관찰하세요.

프로토콜 순위 대신 통제된 조건에서 비교하세요

의미 있는 비교를 하려면 서버 지역, 접속 대상, 기기, 연결 네트워크, 테스트 시간을 최대한 비슷하게 맞추세요. 두 노드가 서로 다른 회선을 사용한다면 결과는 프로토콜 차이보다 회선 차이를 더 크게 반영할 수 있습니다. 같은 페이지를 처음 열어 보고, 다시 방문한 뒤 지속 전송과 상호작용도 확인하세요. 한 번에 한 요소만 바꾸고 연결을 다시 설정했는지도 기록하세요. 연결을 미리 예열한 결과와 캐시를 비우고 클라이언트를 막 시작한 결과를 그대로 비교하지 마세요.

‘연결 테스트는 빠른데 웹페이지는 느리다’면 테스트 대상과 웹페이지가 같은 라우팅을 사용하는지 확인한 다음 DNS, 인증서, 실제 요청 로그를 살펴보세요. 일부 테스트는 하위 연결이나 특정 탐색 요청만 확인하므로 웹페이지에 포함된 여러 리소스 도메인까지 검사하지 않습니다. 라우팅에 따라 기본 페이지와 정적 리소스가 서로 다른 출구를 사용하면 체감 결과가 달라질 수도 있습니다. 구체적으로 어느 단계에서 실패하는지 찾은 뒤 프로토콜 변경이 필요한지 판단하세요. 원인을 모른 채 노드를 자주 바꾸면 변수만 늘어납니다.

실시간 앱은 UDP도 별도로 확인해야 합니다. 노드 프로토콜이 UDP 요청을 표현할 수 있어도 클라이언트 연결 방식, 서버 전달, 원격 네트워크가 이를 허용한다는 보장은 없습니다. 앱이 시스템 프록시를 따르지 않으면 노드가 관련 기능을 지원해도 프록시 경로에 들어오지 않을 수 있습니다. Tun을 켰다면 라우팅, 권한, DNS가 모두 올바른지도 확인하세요. 동영상을 계속 시청할 때는 노드 이름보다 안정성과 혼잡 제어가 중요할 때가 많고, 웹 브라우징은 DNS와 연결 설정을 먼저 살펴야 합니다.

모든 지표에서 최고인 방식을 찾을 필요는 없습니다. 일반적인 웹 브라우징은 정확한 설정과 안정적인 연결을 우선하고, 장시간 전송은 지속 성능과 기기 부하를 살펴보세요. 실시간 상호작용은 왕복 시간과 패킷 손실을 확인하고 앱 트래픽이 실제로 프록시를 통과하는지 점검해야 합니다. 프로토콜은 연결 경로의 일부만 결정합니다. 노드 목록의 지역과 배율 정보를 해석하려면 노드 선택 요소 비교를 참고하세요. 상업적 표시를 기술 매개변수로 오해하지 마세요.

05 / MOBILE POWER

모바일 배터리와 백그라운드 실행

배터리는 전체 처리 과정에서 소모됩니다

Android 기기의 배터리 소모는 암호화 연산만으로 결정되지 않습니다. 무선 연결 유지, 앱의 지속적인 요청, 백그라운드 재연결, DNS 조회, 로그 기록도 영향을 줄 수 있습니다. 신호가 불안정하면 네트워크 전환과 반복 핸드셰이크로 소모가 커집니다. 따라서 ‘특정 프로토콜이 배터리를 덜 쓴다’는 말은 기기, 트래픽 유형, 네트워크 조건과 함께 제시해야 합니다. 이런 조건을 빼고 순위를 매겨도 신뢰할 만한 판단 기준이 되지 않습니다. 먼저 클라이언트가 의도한 대로 작동하는지 확인한 뒤 프로토콜 차이를 살펴보세요.

모바일에서는 v2rayNG를 권장합니다. V2Fly 코어가 필요하고 설정이 지원되는 경우 v2flyNG도 고려할 수 있습니다. 화면이 비슷하다는 이유만으로 두 앱이 모든 노드를 똑같이 지원한다고 볼 수는 없습니다. 가져온 뒤 프로토콜, 보안 계층, 고급 설정이 유지됐는지 확인하고 실제 연결도 테스트하세요. 설치 파일은 Android 클라이언트 다운로드에서 받을 수 있습니다. 패키지를 선택할 때는 기기 아키텍처를 확인하세요. 설치 파일 크기 차이는 배터리 소모의 기준이 아닙니다. 지원 명령어와 실제 실행 방식이 기기 호환성에 더 중요합니다.

암호화 오버헤드보다 재연결부터 확인하세요

대기 중 배터리가 빠르게 줄어든다면 클라이언트 로그에 연결 해제와 재연결이 반복되는지 확인하세요. 원인으로는 서버 접속 불가, 이름 조회 실패, 인증 매개변수 불일치, 시스템의 백그라운드 네트워크 제한 등이 있습니다. 연결이 계속 실패하면 클라이언트가 재시도하고, 매번 DNS 조회와 핸드셰이크가 발생할 수 있습니다. 이때 암호화 알고리즘을 바꾸면 핵심을 놓칠 수 있습니다. 먼저 안정적으로 연결되는 노드를 복구한 뒤 대기 중 배터리 사용량을 관찰해야 이전 소모가 반복 오류 때문인지 판단할 수 있습니다.

백그라운드 연결이 시스템에 의해 종료되고 화면 잠금을 해제한 뒤 다시 연결되는 경우도 있습니다. 장시간 연결을 유지해야 한다면 시스템의 앱 배터리 관리에서 v2rayNG 또는 v2flyNG의 백그라운드 제한을 확인하세요. 기기마다 메뉴 이름이 다르므로 앱 정보에서 배터리 및 백그라운드 활동 관련 설정을 찾으면 됩니다. 제한을 완화하면 연결 유지에 도움이 될 수 있지만 대기 중 배터리 소모가 늘 수도 있어 두 가지가 동시에 개선된다고 장담할 수는 없습니다. 앱을 사용할 때만 연결하면 된다면 이론적인 안정성을 위해 백그라운드 실행을 계속 유지할 필요는 없습니다.

처리 대상 트래픽 범위가 작업량을 결정합니다

Android 클라이언트는 보통 시스템 가상 네트워크 인터페이스를 통해 트래픽을 받습니다. 시스템에 연결 표시가 나타나면 로컬 인터페이스가 설정된 것이지 원격 노드까지 사용할 수 있다는 뜻은 아닙니다. 앱별 분할 설정으로 프록시 경로에 들어갈 앱을 바꿀 수 있지만, 앱을 제외하기 전에 실제로 프록시가 필요 없는지와 관련 서비스에 미치는 영향을 확인하세요. 불필요한 처리를 줄이면 부담이 낮아질 수 있지만 규칙을 잘못 설정하면 일부 요청이 의도한 출구를 우회할 수 있습니다. 먼저 기능이 올바르게 작동하는지 확인한 다음 처리 범위를 점차 줄이세요.

자동 속도 테스트를 자주 실행하거나, 너무 짧은 간격으로 연결을 유지하거나, 연결 정보를 계속 새로 고치는 설정도 점검하세요. 연결 유지는 특정 상태를 유지하는 데 쓰이지만 간격이 짧을수록 사용 경험이 좋아지는 것은 아닙니다. 무선 네트워크가 작은 패킷을 처리하느라 계속 깨어날 수 있습니다. 관련 설정이 있다면 우선 적절한 기본값을 사용하고, 유휴 상태에서 연결이 끊기는 문제가 확인된 경우에만 조정하세요. 문제를 확인할 때는 불필요한 일괄 테스트를 잠시 중지하고, 설정 변경 직후의 순간적인 배터리 변화가 아니라 동일한 사용 조건으로 충분히 관찰하세요.

기기 온도와 배터리를 관찰할 때는 화면 밝기, 시스템 업데이트, 앱 다운로드, 동영상 디코딩 등 다른 요인도 고려하세요. 비슷한 네트워크와 같은 앱 작업을 유지하며 전면 사용과 대기 상태를 따로 기록하는 것이 좋습니다. 트래픽은 별로 늘지 않았는데 CPU 부하가 커졌다면 오류 재시도나 상세 로그가 원인일 수 있습니다. 트래픽이 계속 증가한다면 실제로 네트워크를 사용하는 앱을 확인하세요. 배터리 화면의 수치는 시스템이 추정한 결과로, 인터페이스와 코어, 가상 인터페이스의 사용량을 완전히 구분하지 못할 수 있습니다. 항목별 비율을 프로토콜 비용으로 단정하지 마세요.

절전 설정은 다음 순서로 확인하세요. 설정 호환성을 확보하고 반복 연결을 해결한 뒤 백그라운드 정책을 확인하고, 필요한 트래픽만 처리하도록 범위를 조정하세요. 마지막으로 프로토콜 구현의 오버헤드를 비교합니다. 안정적으로 연결되는 기존 노드를 다른 프로토콜로 무작정 바꿔도 배터리 사용량이 줄어든다는 보장은 없으며 새로운 핸드셰이크 조건이 생길 수 있습니다. Wi-Fi와 모바일 네트워크의 차이가 크다면 각각 기록하고 네트워크 전환 후 DNS와 연결을 다시 확인하세요. 모바일에서 중요한 최적화는 설정 화면을 복잡하게 만드는 것이 아니라 클라이언트가 제대로 작동하도록 하는 것입니다.

06 / CORE COMPATIBILITY

V2Fly와 Xray: 프로젝트 관계와 호환성 범위

클라이언트 화면과 코어의 역할은 다릅니다

Project V는 오픈소스 프록시 생태계를 이해하는 데 필요한 배경입니다. V2Fly는 V2Ray의 커뮤니티 개발을 이어 가고 있으며, Xray는 공통된 기술적 기반을 바탕으로 자체 기능을 발전시켜 왔습니다. 두 프로젝트는 비슷한 개념과 설정 형식을 공유하지만 같은 프로그램처럼 항목을 그대로 바꿔 쓸 수는 없습니다. 오픈소스 라이선스를 살펴볼 때는 프로젝트 자체와 포함된 구성 요소의 라이선스를 구분해야 합니다. 클라이언트 사용자도 관련 약관을 따라야 합니다. 오픈소스는 공개적인 검토와 논의의 기반을 제공하지만 모든 설정 조합의 호환성을 보장하지는 않습니다.

v2rayN, v2rayNG, v2flyNG는 사용자가 다루는 그래픽 클라이언트로 노드 표시, 구독 관리, 실행 설정 생성을 담당합니다. 코어는 연결을 설정하고 라우팅을 처리하며 프로토콜을 실행합니다. 화면에서 항목을 저장할 수 있다는 것은 입력을 받았다는 뜻일 뿐, 현재 사용하는 코어가 이를 실행할 수 있다는 뜻은 아닙니다. 반대로 코어가 기능을 지원하더라도 클라이언트에서 설정할 수 없다면 그래픽 화면에서도 사용할 수 있다고 단정할 수 없습니다. 클라이언트의 설정 표현 능력과 코어의 실행 능력을 함께 확인하세요.

비슷한 JSON이라고 의미까지 같지는 않습니다

두 코어에서 인바운드, 아웃바운드, 라우팅, DNS 같은 설정 개념을 흔히 볼 수 있습니다. 기본 구조가 비슷해도 지원 항목, 기본값, 조합 제한은 다를 수 있습니다. 특히 REALITY나 Vision 같은 기능은 ‘둘 다 V2Ray 생태계에 속한다’는 이유만으로 V2Fly에서 바로 쓸 수 있다고 판단하면 안 됩니다. 코어가 알 수 없는 항목을 발견하면 명확한 오류와 함께 시작을 거부하는 구현도 있고, 일부 정보를 무시하는 구현도 있습니다. 오류가 없다고 해당 기능이 작동하는 것은 아니므로 실제 생성된 설정과 실행 결과를 확인하세요.

코어를 전환하기 전에 현재 작동하는 노드를 별도로 복사해 두고 클라이언트의 코어 설정 및 노드 유형 매핑을 확인하세요. 화면 구성에 따라 코어 선택이 설정 페이지나 관련 노드 메뉴에 있을 수 있으므로 트레이 메뉴의 모드 이름만으로 판단하면 안 됩니다. 코어를 선택한 뒤 영향을 받는 연결을 다시 시작하고 로그에서 실제 실행된 코어와 오류를 확인하세요. 라우팅, DNS, 보안 설정을 동시에 바꾸면 실패 원인이 코어 차이인지 다른 설정인지 구분하기 어렵습니다.

전환 후에는 시작 여부뿐 아니라 동작도 확인하세요

아래 예시는 흔히 쓰이는 라우팅 표현으로, 사설 주소 범위와 일치하는 요청을 direct 태그가 붙은 출구로 전달합니다. 설정 항목 간 관계를 이해하는 데 도움이 되지만 전체 연결 설정은 아닙니다. 사용하기 전에 전체 설정에 해당 출구가 정의되어 있고 코어가 관련 항목을 지원하는지 확인하세요. 또한 모든 로컬 네트워크 도메인이 자동으로 직접 연결된다는 뜻도 아닙니다. 도메인이 DNS 조회에 포함되는지와 규칙에서 주소를 언제 가져오는지는 전체 DNS 및 라우팅 정책에 달려 있습니다.

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

전환 후에는 최소 세 가지를 확인하세요. 코어가 시작되는지, 대상 요청이 예상한 출구를 사용하는지, 클라이언트를 종료한 뒤 시스템 네트워크 상태가 복구되는지 확인합니다. 앞의 두 항목은 설정 의미를 검증하고 마지막 항목은 로컬 연결 동작을 검증합니다. Tun과 시스템 프록시는 권한과 정리 과정이 다르므로 노드 연결에 성공했다고 종료 후 테스트를 생략하면 안 됩니다. 시스템이 종료된 로컬 프록시 포트를 계속 가리킨다면 원격 프로토콜을 탓하지 말고 시스템 프록시 상태부터 복구하세요.

안정적으로 작동하는 설정의 코어를 바꾼다면 지원되는 프로토콜 조합이 필요하거나 재현 가능한 구현 문제를 해결해야 하는 등 분명한 목적이 있어야 합니다. 정기 점검처럼 코어를 바꾸거나 신구 이름을 품질 순위로 여기지 마세요. 데스크톱에서 처음 실행할 때 권한이나 시작 문제가 생기면 v2rayN 첫 설치 및 초기 설정을 참고하세요. 필요한 클라이언트와 코어를 선택한 뒤 설정을 꼭 필요한 만큼만 유지하면 호환성 매개변수를 계속 추가하는 것보다 관리하기 쉽습니다.

07 / SUBSCRIPTION FORMATS

구독 형식: 가져오기 성공이 설정 완성을 뜻하지 않습니다

공유 링크, 구독 주소, 실행 설정

공유 링크는 보통 하나의 노드를 나타내고 구독 주소는 업데이트할 수 있는 노드 목록을 가져오는 데 사용합니다. 실행 설정은 코어가 최종적으로 읽는 구조화된 데이터입니다. 서로 용도가 다릅니다. 단일 노드 편집 창에 구독 주소를 넣으면 해석되지 않을 수 있고, 특정 코어의 전체 JSON을 범용 구독처럼 사용해도 다른 클라이언트가 이해하지 못할 수 있습니다. 구독 본문은 인코딩된 형태일 수 있으므로 브라우저에서 깨진 문자처럼 보인다고 해서 바로 사용할 수 없다고 단정하지 마세요. 해당 형식을 지원하는 클라이언트로 해석하고 구체적인 오류를 확인해야 합니다.

공유 형식에는 VMess, VLESS, Trojan, Shadowsocks 프로토콜 표시가 자주 들어갑니다. 같은 접두어라도 매개변수 인코딩 방식은 다를 수 있습니다. 이름 메모, 특수 문자, 요청 헤더, 보안 설정의 이스케이프 처리가 해석 결과에 영향을 줍니다. 복사할 때 문자 하나를 빠뜨리거나 링크 끝의 문장 부호까지 함께 선택해도 결과가 달라질 수 있습니다. 가져온 뒤 노드 이름만 나타나는지 확인하지 말고 편집 창을 열어 프로토콜, 주소, 포트, 고급 보안 항목을 확인하세요. 이름이 보인다는 것은 일부 내용이 읽혔다는 뜻일 뿐입니다.

형식 변환 과정에서 기능이 누락될 수 있습니다

클라이언트 파서는 구독 내용을 내부 노드 모델로 변환한 다음 코어 실행 설정을 생성합니다. 내부 모델에 해당 항목이 없으면 변환 과정에서 새로운 기능이 온전히 보존되지 않을 수 있습니다. 보안 계층이 기본값으로 돌아가거나 flow가 사라지고, 서비스 이름이 비거나 매개변수가 일반 메모로 처리될 수 있습니다. 따라서 같은 구독을 두 클라이언트에서 가져온 결과가 다르더라도 서버 설정이 바뀌었다고 단정할 수 없습니다. 먼저 가져온 뒤의 항목을 비교하고 생성된 설정을 확인한 다음 코어가 실제로 호환되지 않는지 판단하세요.

형식 변환 서비스를 단순한 중계 단계로 여기지 마세요. 변환 서비스가 구독 내용을 읽을 수 있고 변환 규칙에 따라 항목을 다시 해석할 수도 있습니다. 구독 주소에는 개인 인증 정보가 포함되는 경우가 많아 주소를 가진 사람이 노드를 이용하거나 해당 리소스를 소모할 수 있습니다. 화면을 공유하거나 로그를 제출하거나 도움을 요청하기 전에 전체 주소, 사용자 식별자, 비밀번호 같은 민감 정보를 가리세요. 주소가 유출됐다면 기기에서 그룹을 삭제하는 데 그치지 말고 제공업체 관리 페이지에서 인증 정보를 갱신하세요.

구독 업데이트와 노드 연결은 별개입니다

v2rayN에서 구독 그룹 설정을 열어 주소가 저장됐는지 확인한 다음 ‘구독 업데이트(프록시 사용 안 함)’를 실행하세요. 이 옵션은 직접 업데이트 경로와 현재 프록시 경로의 문제를 구분하는 데 사용합니다. 모든 구독이 항상 직접 가져와야 한다는 뜻은 아닙니다. 구독 주소가 작동 중인 프록시를 통해서만 접속 가능하다면 기존 연결이 정상인지 확인한 뒤 적절한 업데이트 방식을 선택하세요. 업데이트 경로만 한 번에 하나씩 바꾸고 기존 그룹은 비교를 위해 유지하세요. 모든 노드를 한꺼번에 지우지 마세요.

구독 업데이트는 실패했지만 기존 노드가 연결된다면 구독 주소, 인증, 가져오기 경로를 먼저 확인하세요. 구독은 업데이트되지만 모든 노드가 연결되지 않는다면 노드 설정, 서버 상태, 코어 지원 여부를 점검해야 합니다. 두 작업이 모두 실패하더라도 구독 가져오기 오류와 노드 연결 오류를 각각 기록하세요. HTTP 요청이 성공해도 응답 본문이 구독이라는 보장은 없습니다. 로그인 화면이나 오류 메시지, 다른 웹페이지가 반환될 수 있습니다. 파서에서 형식 오류가 나면 노드 비밀번호를 반복해서 바꾸지 말고 응답 내용의 유형을 확인하세요.

구독을 업데이트하면 수동 변경 사항이 덮어써질 수 있습니다. 서버 이름이나 전송 매개변수를 임시로 바꾸려면 별도 노드로 복사하고 변경 목적을 적어 두세요. 다음 업데이트에서 테스트 결과가 사라지는 것을 방지할 수 있습니다. 그룹 이름은 관리용 표시일 뿐 서버 프로토콜을 바꾸지 않으며, 같은 주소를 여러 이름의 그룹에 넣어도 회선이 달라지지 않습니다. 중복 노드를 삭제하기 전에 보안 계층과 전송 설정이 실제로 같은지 확인하세요. 표시 이름만으로 중복 여부를 판단하면 안 됩니다.

기기 간 동기화는 전체 클라이언트 데이터 폴더를 덮어쓰기보다 각 기기에서 지원되는 구독을 따로 가져온 뒤 설정 항목을 비교하는 편이 좋습니다. 데스크톱 시스템 프록시, Android 앱별 분할, 로컬 파일 경로는 기기마다 다르므로 전체 설정을 옮기면 맞지 않는 항목이 따라올 수 있습니다. 파싱 오류가 발생하면 구독 업데이트 실패 및 파싱 오류 해결을 따라 항목별로 확인하세요. 구독 관리는 노드 목록을 길게 만드는 것이 아니라 정확한 출처와 업데이트 관계를 유지하는 것이 목적입니다.

08 / SELECTION AND VALIDATION

사용 상황별 선택과 연결 확인

프로토콜 이름보다 필요한 작업을 기준으로 선택하세요

일상적인 웹 브라우징에는 설정이 완전하고 안정적으로 업데이트되며 클라이언트에서 명확히 지원되는 노드를 우선하세요. 기존 VMess, Trojan, Shadowsocks 설정이 정상 작동한다면 이름이 다르다는 이유만으로 옮길 필요는 없습니다. REALITY나 Vision을 사용하려면 Xray 지원 여부와 서버에서 제공한 전체 조합부터 확인하세요. 데스크톱에서는 구독, 시스템 프록시, 라우팅을 그래픽 화면에서 관리할 수 있어 v2rayN을 권장합니다. 프로토콜 선택은 서버 기능을 기준으로 판단해야 하며 두 문제를 혼동하면 안 됩니다.

동영상을 오래 보거나 대용량 파일을 전송할 때는 프로토콜 캡슐화를 비교하기 전에 회선 안정성, 지속적인 혼잡, 기기 온도를 확인하세요. 실시간 상호작용은 왕복 시간, 패킷 손실, UDP의 전체 경로를 살펴봐야 합니다. 불안정한 네트워크에서 모바일 기기를 사용할 때는 한 번의 핸드셰이크 비용보다 재연결 동작과 백그라운드 정책이 더 중요할 수 있습니다. 후보 노드의 회선 조건이 비슷해야 프로토콜과 전송 방식의 차이를 의미 있게 비교할 수 있습니다. 설정이 불완전하거나 기능이 맞지 않는 후보를 먼저 제외하면 불필요한 테스트를 줄일 수 있습니다.

데스크톱에서 계층별로 확인

v2rayN으로 노드를 가져온 뒤 편집 창을 열어 프로토콜, 전송 방식, 보안 계층을 확인하고 저장한 다음 사용할 노드로 선택하세요. 이어서 시스템 프록시 메뉴에서 ‘시스템 프록시 자동 구성’을 선택하고 시스템 프록시를 따르는 앱으로 대상에 접속하면서 로그에 해당 요청이 나타나는지 확인합니다. 앱의 요청이 로컬 프록시에 들어오지 않는다면 시스템 연결부터 점검하세요. 요청은 들어왔지만 인증에 실패한다면 원격 매개변수를 확인해야 합니다. 시작부터 Tun을 켜고 DNS를 바꾸거나 코어를 전환하지 마세요.

Tun이 필요하다면 현재 클라이언트와 시스템에서 지원되는지 확인하고 안내에 따라 권한을 처리하세요. 활성화한 뒤 라우팅과 DNS를 다시 확인해야 합니다. 시스템 프록시를 사용할 때와 동작이 완전히 같다고 가정하지 마세요. 로컬 네트워크 기기에 접속하려면 사설 주소 규칙, 도메인 조회, 실제 출구를 별도로 확인해야 합니다. 종료할 때는 시스템 프록시와 가상 인터페이스 상태가 복구됐는지 점검하세요. 클라이언트를 닫은 뒤 모든 웹페이지가 열리지 않으면 원격 노드를 계속 바꾸기보다 남아 있는 로컬 설정부터 확인하세요.

모바일 연결 확인과 문제별 점검

v2rayNG에서 노드를 가져온 뒤 고급 항목을 확인하고 연결을 시작한 다음 시스템에서 요청하는 가상 네트워크 인터페이스 권한을 허용하세요. 이후 상태 표시줄의 연결 아이콘만 보지 말고 실제 앱으로 접속을 확인합니다. 특정 앱 하나만 실패하면 앱별 분할과 해당 앱에서 필요한 트래픽 유형을 확인하세요. 모든 앱에서 실패하면 노드와 DNS를 살펴봐야 합니다. v2flyNG로 바꾸기 전에는 해당 코어가 구현하지 않은 기능에 노드가 의존하지 않는지 확인하세요. 그렇지 않으면 클라이언트만 바꿔도 같은 호환성 문제가 반복됩니다.

코어가 시작되지 않으면 설정 항목, 기능 지원, 구성 문법을 확인하세요. 시작은 되지만 핸드셰이크에 실패하면 주소, 포트, 시간, 인증을 점검합니다. 핸드셰이크는 성공했지만 일부 도메인만 실패하면 DNS와 라우팅을 확인하세요. 특정 앱만 실패한다면 처리 범위와 앱 자체 설정을 살펴보세요. 이 순서는 모든 오류를 하나의 원인으로 몰아가는 것이 아니라 관찰 결과를 해당 계층과 연결하는 방법입니다. 로그에 찍힌 오류는 뒤따라 발생한 결과일 수도 있으므로 마지막 메시지만 검색하지 말고 관련된 첫 실패부터 읽으세요.

확인이 끝나면 클라이언트 이름, 실제 코어, 프로토콜 조합, 시스템 연결 방식, 남아 있는 문제를 간단히 기록하세요. 인증 정보를 적거나 전체 로그를 복사할 필요는 없습니다. 다음에 구독을 업데이트하거나 코어를 바꿀 때 같은 순서로 다시 확인할 수 있습니다. 새 설정에 문제가 생기면 정상 작동이 확인된 조합으로 되돌린 뒤 차이를 하나씩 비교하세요. 해결 옵션을 계속 덧붙이는 것보다 이 방법이 신뢰할 만합니다. 재현 가능한 현상과 변경 기록이 ‘모든 프로토콜을 시험했다’는 말보다 도움이 됩니다.

최종 선택 기준은 설정을 설명할 수 있고, 필요한 기능을 제공하며, 실행 결과를 확인할 수 있는지입니다. 회선과 기기 조건을 무시하고 항상 최고인 프로토콜은 없으며, 스위치 하나로 모든 호환성 문제가 해결되지도 않습니다. 처음 설정한다면 빠른 시작 가이드의 기본 단계를 따라 하세요. 구독이나 연결에 문제가 생기면 이 페이지에서 해당 장을 확인하면 됩니다. 클라이언트를 바꿔야 한다면 다운로드 페이지에서 운영체제와 아키텍처에 맞는 파일을 선택하고, 안정적으로 작동하는 기본 설정을 만든 뒤 필요한 고급 기능만 조정하세요.