V2Ray 프로토콜 및 코어선택 가이드

// 01 · DECISION MODEL

프로토콜·전송·보안·라우팅을 먼저 분리하기

클라이언트 설정은 단일 프로토콜이 아닙니다

V2Ray GUI 클라이언트는 복잡한 설정을 몇 가지 입력 항목으로 단순화하므로 VMess 또는 VLESS를 선택하면 모든 기술적 선택이 끝났다고 생각하기 쉽습니다. 실제로 하나의 연결은 최소 다섯 계층으로 나눌 수 있습니다. 애플리케이션이 원본 TCP 또는 UDP 트래픽을 만들고, 클라이언트의 로컬 인바운드가 트래픽을 수신하며, 프록시 프로토콜이 인증과 캡슐화를 담당합니다. 전송 방식은 프록시 데이터를 TCP, WebSocket, gRPC 등의 매체에 담고, TLS 또는 REALITY는 외부 핸드셰이크와 암호화를 처리합니다. 원격 서버에 도착한 데이터는 아웃바운드와 라우팅 규칙에 따라 직접 연결, 프록시 또는 차단으로 다시 분류됩니다. 어느 한 계층의 매개변수라도 맞지 않으면 ‘설정은 가져와지지만 연결되지 않는’ 현상이 나타날 수 있습니다.

프로토콜 계층은 주로 인증 필드, 요청 헤더 구조와 코어 구현을 결정합니다. 예를 들어 VMess는 사용자 식별자를 사용하며 자체 프로토콜 구조를 갖고, VLESS는 더 가벼운 구조로 암호화와 전송 보안을 외부 계층에 맡깁니다. 전송 계층은 데이터를 어떻게 프레이밍하는지, HTTP 의미론이 필요한지, 중간 경로가 올바르게 전달할 수 있는지를 결정합니다. 보안 계층은 인증서 검증, 서버 이름, 키 교환과 대상 신원 확인을 처리합니다. 라우팅 계층은 프로토콜 자체를 바꾸지 않지만 어떤 요청이 프록시 연결로 들어갈지 직접 좌우합니다. 문제를 해결할 때는 먼저 계층을 특정한 뒤 매개변수를 변경해야 하며, 여러 옵션을 연속으로 바꾸면 실제 원인을 가리게 됩니다.

‘최강 프로토콜’ 대신 제약 조건으로 선택하기

환경을 배제한 프로토콜 순위는 존재하지 않습니다. 서버가 무엇을 제공하는지, 현재 클라이언트 코어가 무엇을 해석할 수 있는지, 운영체제에 어떤 기능이 필요한지, 경로에 리버스 프록시나 특정 전송 방식만 허용하는 인프라가 있는지를 함께 확인해야 합니다. 서버가 VMess로 고정되어 있다면 클라이언트만 VLESS로 바꿀 수 없습니다. 구독이 WebSocket만 제공한다면 로컬에서 전송 방식을 gRPC로 바꾸는 것만으로는 해결되지 않습니다. 클라이언트의 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식과 보안 매개변수는 서버와 항목별로 일치해야 합니다.

판단 우선순위는 ‘사용 가능성, 호환성, 리소스 비용, 유지 관리 비용’ 순으로 정할 수 있습니다. 첫째 서버와 코어의 지원 여부를 확인하고, 둘째 구독 필드가 완전히 전달되는지 확인한 뒤, 셋째 연결 수립 속도·처리량·배터리 사용량을 비교합니다. 여러 기기에서 사용할 경우 데스크톱과 Android에서 동일한 구독을 재사용할 수 있는지도 고려해야 합니다. 특정 조합을 한쪽에서만 완전히 인식할 수 있다면 일상적인 유지 관리 비용이 작은 성능 향상보다 커지는 경우가 많습니다.

되돌릴 수 있는 기준 설정 만들기

프로토콜을 비교할 때는 이미 정상 작동을 확인한 기준 설정을 하나 보존하고 바로 덮어쓰지 마세요. 기준 설정은 로컬 포트, 시스템 프록시, DNS와 라우팅 규칙의 영향을 배제하는 데 사용합니다. 새 설정을 테스트하기 전에는 전역 프록시나 가장 단순한 라우팅 모드를 임시로 사용해 기본 연결을 확인한 뒤 분할 라우팅을 복원하세요. 기본 연결은 정상인데 규칙을 복원한 뒤 문제가 발생한다면 원인은 라우팅 또는 DNS에 있으므로 프로토콜 매개변수를 계속 바꿔서는 안 됩니다. GUI 클라이언트는 일반적으로 설정 복제나 구독별 그룹 관리를 지원하므로, 그룹을 적절히 활용하면 반복적인 가져오기로 인한 필드 혼란을 크게 줄일 수 있습니다.

// 02 · PROTOCOL FAMILIES

VMess, VLESS, Trojan, Shadowsocks 및 REALITY

VMess: 완성도 높은 프로토콜 구조와 폭넓은 호환성

VMess는 Project V 생태계에서 초기에 발전한 핵심 프록시 프로토콜로, 사용자 인증·시간 검증·데이터 캡슐화를 하나의 프로토콜 안에서 처리하도록 설계되었습니다. 클라이언트에서 자주 보이는 필드는 서버 주소, 포트, 사용자 ID, alterId, 암호화 방식과 전송 설정입니다. 최신 설정에서 alterId는 일반적으로 0이지만, 오래된 구독에 0이 아닌 값이 남아 있다면 서버의 실제 설정에 맞춰 유지해야 하며 최신 설정 관행만 보고 임의로 바꾸면 안 됩니다. VMess는 시스템 시간에 민감하므로 기기 시간의 오차가 크면 인증을 완료하지 못할 수 있습니다. 따라서 ‘같은 설정이 한 기기에서는 작동하고 다른 기기에서는 작동하지 않는’ 경우 자동 시간 동기화를 확인해야 합니다.

VMess의 장점은 오랜 기간 축적된 도구 호환성과 기존 배포 사례가 많다는 점입니다. 많은 구독 형식이 기본 필드를 안정적으로 표현합니다. 반면 프로토콜 자체의 구조가 VLESS보다 복잡하고 인증과 캡슐화에 추가 처리가 필요합니다. 최신 데스크톱과 모바일 기기에서는 이 비용이 대개 병목이 아니며, 실제 체감에는 네트워크 왕복 시간, 전송 방식, TLS 핸드셰이크와 서버 부하가 더 큰 영향을 줍니다. 기존 VMess 설정이 안정적으로 작동한다면 이론적인 소폭의 비용 차이만을 이유로 이전할 경우 재설정과 여러 기기 검증에 드는 비용을 회수하지 못할 수 있습니다.

VLESS: 인증 계층과 보안 계층의 분리

VLESS는 사용자 ID 인증 방식을 유지하지만 프로토콜 내부에서 데이터 암호화까지 중복으로 담당하지 않고 TLS, REALITY 등의 외부 계층에 보안 기능을 맡깁니다. 이에 따라 프로토콜 계층의 중복이 줄고 전송 보안의 역할도 명확해집니다. VLESS 설정에는 주소, 포트, 사용자 ID 외에도 flow 필드가 자주 포함됩니다. flow는 모든 VLESS 설정에 필요한 것은 아니며 서버에서 해당 흐름 제어 방식을 활성화한 경우에만 입력해야 합니다. 관련 값으로 가장 흔한 것은 xtls-rprx-vision이며, 비워 두거나 잘못된 값을 입력하면 클라이언트와 서버의 동작이 일치하지 않게 됩니다.

VLESS 자체가 REALITY를 의미하는 것은 아니며 특정 전송 방식을 자동으로 뜻하지도 않습니다. TCP, WebSocket, gRPC 등과 조합할 수 있고 TLS 또는 REALITY를 사용할 수도 있습니다. VLESS를 선택한 뒤에도 network, security, serverName, flow 등의 필드를 계속 확인해야 합니다. 최신 Xray 설정에서는 VLESS와 REALITY, Vision의 조합이 자주 사용되는데, 같은 코어 계열 안에서 이 기능들이 함께 구현되기 때문입니다. V2Fly 기능만 지원하는 클라이언트에 설정을 전달해야 한다면 해당 조합에 동등한 구현이 대상 코어에 있는지 먼저 확인하세요.

Trojan: TLS 기반 비밀번호 인증

Trojan의 핵심 필드는 비교적 간단합니다. 서버 주소, 포트, 비밀번호, TLS 서버 이름과 선택적 전송 매개변수로 구성됩니다. Trojan은 올바른 TLS 배포에 의존하며 클라이언트는 서버 이름을 기준으로 인증서를 검증합니다. 연결 주소에 IP를 사용하고 서버 이름에는 도메인을 입력하는 조합은 정상입니다. 연결 대상과 인증서의 신원은 분리될 수 있기 때문입니다. 다만 서버 이름이 비어 있거나 오타가 있거나 인증서 체인에 문제가 있으면 프록시 데이터 단계에 도달하기 전에 연결이 실패합니다. 인증서 검증을 끄면 오류를 일시적으로 우회할 수 있지만 신원 확인 기능을 잃으므로 장기적인 해결책으로 적합하지 않습니다.

Trojan은 프로토콜 이해에 필요한 부담이 낮아 서버에서 표준 TLS를 안정적으로 제공하는 환경에 적합합니다. VLESS TLS와의 성능 차이는 대개 회선 품질과 전송 방식에 따른 차이보다 작습니다. 비교할 때는 서버 위치, 포트, 전송 방식과 동시 연결 수를 동일하게 유지해야 합니다. 한 설정은 직접 TCP를 사용하고 다른 설정은 WebSocket과 중간 전달을 추가했다면 다운로드 속도만으로 프로토콜의 우열을 판단할 의미가 없습니다.

Shadowsocks: 가벼운 암호화 프록시

Shadowsocks는 흔히 SS로 줄여 부르며, 설정은 주로 주소, 포트, 비밀번호와 암호화 방식으로 구성됩니다. 구조가 간단하고 리소스 사용량이 대체로 낮으며 TCP와 UDP 모두 성숙한 구현을 제공합니다. 암호화 방식은 서버와 완전히 일치해야 하며 이름이 비슷하다고 서로 바꿔 사용할 수 없습니다. 최신 배포에서는 클라이언트와 서버가 함께 지원하는 AEAD 계열 방식을 사용해야 합니다. 오래된 방식이 일부 코어에서 여전히 해석되더라도 호환성, 보안 특성과 유지 관리 상태를 최신 방식과 동일하게 볼 수는 없습니다.

SS는 필드가 단순하고 여러 클라이언트에서 재사용해야 하는 환경에 적합합니다. 구독 링크 표현도 비교적 간결하지만 생성기마다 사용자 정보 인코딩, 플러그인 매개변수와 메모 필드를 다르게 작성할 수 있습니다. 기본 SS 설정은 대체로 쉽게 이전할 수 있지만 추가 플러그인 매개변수가 포함된 설정은 대상 클라이언트가 동일한 기능을 구현했는지 확인해야 합니다. v2rayN, v2rayNG와 v2flyNG는 일반적인 기본 설정을 처리할 수 있지만 복잡한 확장 기능은 각 코어와 가져오기 도구의 제약을 받습니다.

REALITY: 전송 보안 방식이며 독립적인 프록시 프로토콜은 아님

REALITY는 VLESS와 함께 표시되는 경우가 많아 독립적인 프로토콜로 잘못 불리기도 합니다. 더 정확히 말하면 VLESS는 프록시 프로토콜과 사용자 인증을 담당하고 REALITY는 외부 핸드셰이크와 서버 신원 확인을 담당합니다. 클라이언트의 주요 필드는 서버 이름, 공개 키, 짧은 식별자, 브라우저 지문 모방 값과 선택적 SpiderX입니다. 공개 키는 서버 키 쌍에서 가져오고 짧은 식별자는 서버가 허용한 값으로 결정되므로 클라이언트에서 임의로 생성해 교체할 수 없습니다. 서버 이름 역시 서버 설정과 일치해야 합니다.

REALITY는 주로 Xray 코어에서 완전하게 지원됩니다. 설정을 가져올 때 화면에서 VLESS를 인식하더라도 구독 변환 과정에서 REALITY의 publicKey, shortId 또는 fingerprint가 누락되면 연결할 수 없습니다. 문제를 해결할 때는 목록의 프로토콜 태그만 보지 말고 설정 상세를 펼쳐 항목별로 확인해야 합니다. V2Fly 코어가 필요한 기기에는 별도의 호환 설정을 준비해야 하며, V2Fly가 REALITY 필드를 자동으로 무시하고 계속 작동할 것이라고 기대해서는 안 됩니다.

// 03 · PERFORMANCE & RESOURCE

연결 속도·처리량·리소스 사용량 비교 방법

핸드셰이크 속도와 지속 처리량을 먼저 구분하기

‘속도’에는 최소한 연결 수립 시간, 첫 바이트 도달 시간, 지속 다운로드 처리량, 업로드 처리량과 높은 동시 연결에서의 안정성이 포함됩니다. 프로토콜 계층이 가볍다고 모든 지표가 더 빠른 것은 아닙니다. 새 연결은 DNS 조회, TCP 연결 수립, TLS 또는 REALITY 핸드셰이크, 프록시 프로토콜 인증과 대상 서버 연결을 거쳐야 합니다. 지역 간 경로에서는 네트워크 왕복 시간이 로컬 프로토콜 인코딩 시간보다 훨씬 긴 경우가 많습니다. 짧은 연결이 많은 웹 페이지 접속은 핸드셰이크 횟수의 영향을 크게 받고, 장시간 파일 전송은 회선 대역폭, 패킷 손실, 혼잡 제어와 서버 처리 능력의 영향을 주로 받습니다.

VMess, VLESS, Trojan과 SS를 비교할 때는 가능한 한 같은 서버, 같은 경로, 비슷한 포트와 동일한 전송 계층을 사용하세요. 테스트 전에는 경로를 바꾸는 사용자 지정 라우팅을 끄고 DNS 해석 결과가 같은지 확인합니다. 네트워크 부하는 시간에 따라 달라지므로 한 종류를 모두 측정한 뒤 다른 종류를 측정하지 말고, 각 설정을 여러 차례 번갈아 테스트해야 합니다. 결과에는 중앙값 수준의 성능과 이상 발생 횟수를 기록하고 가장 빠른 한 번의 결과만 남기지 마세요. 차이가 매우 작다면 일반적으로 프로토콜 자체의 우수성을 입증하기에 부족합니다.

전송 캡슐화가 프로토콜 차이보다 더 크게 작용하는 경우

직접 TCP는 추가 프레이밍이 적어 종단 간 안정적인 연결이 가능한 환경에 적합합니다. WebSocket은 데이터 외부에 HTTP 업그레이드와 프레임 구조를 추가하므로 HTTP를 이해하는 인프라에 연결하기 쉽지만 헤더와 프레이밍 비용이 늘어납니다. gRPC는 HTTP/2 기반으로 스트림과 연결 관리 기능을 제공하며 서버와 중간 경로가 모두 HTTP/2를 올바르게 지원하는 배포에 적합합니다. HTTPUpgrade와 WebSocket은 진입 방식이 비슷하지만 서로 다른 전송 유형이며, 지원 여부는 코어와 서버에 따라 달라집니다. 이론적인 비용만 볼 것이 아니라 전체 경로에서 버퍼링, 시간 제한 또는 장기 연결 초기화가 발생하는지도 확인해야 합니다.

다중화는 여러 논리 요청이 더 적은 수의 하위 연결을 공유하도록 합니다. 잦은 연결 수립 비용을 줄일 수 있지만 패킷 손실이 발생하면 여러 논리 스트림이 동시에 대기해 선두 블로킹이 생길 수도 있습니다. 웹의 소규모 요청, 실시간 통신과 대용량 파일 전송은 다중화에 서로 다르게 반응합니다. 다중화를 켠 뒤 다운로드는 안정적이지만 웹 페이지가 간헐적으로 멈추거나, 단일 연결의 패킷 손실로 모든 요청이 함께 멈춘다면 다중화를 끄고 비교해 보세요. 현상을 곧바로 VLESS나 VMess의 문제로 단정해서는 안 됩니다.

CPU·메모리와 암호화 구현

리소스 사용량은 프로토콜 해석, 암호화 알고리즘, TLS 구현, 전송 프레이밍, 로그 수준과 연결 수가 함께 결정합니다. VLESS는 데이터 암호화를 외부 계층에 맡겨 프로토콜 처리가 비교적 직접적이고, Trojan은 TLS에 의존하며, SS는 설정된 암호화 방식을 사용하고, VMess는 자체 프로토콜 구조를 갖습니다. 최신 기기는 일반적으로 효율적인 암호화 구현을 제공하므로 일반적인 웹 브라우징에서는 여러 프로토콜의 CPU 차이를 체감하기 어렵습니다. 성능이 낮은 기기, 고속 전송 또는 다수의 동시 연결에서는 알고리즘 구현과 메모리 복사 횟수가 병목이 되기 쉽습니다.

로그도 리소스 사용량에 영향을 줍니다. 문제를 해결할 때 상세 로그는 핸드셰이크와 라우팅을 파악하는 데 도움이 되지만, 디버그 수준을 장기간 유지하면 디스크 쓰기, 메모리 버퍼와 화면 갱신이 늘어납니다. 안정화된 뒤에는 일반 로그 수준으로 되돌리세요. 라우팅 규칙의 수가 적을수록 항상 빠른 것도 아닙니다. 구조가 합리적인 도메인 집합과 IP 집합은 코어가 효율적으로 매칭하므로, 실제로 피해야 할 것은 중복·충돌·순서가 불명확한 사용자 지정 규칙입니다.

재현 가능한 테스트 순서

먼저 브라우저 하나로 콜드 스타트 테스트를 진행해 처음 열 때와 연속으로 열 때의 차이를 기록하세요. 그다음 지속 전송으로 처리량의 안정성을 관찰하고, 이어서 여러 동시 요청과 UDP 애플리케이션을 테스트합니다. 마지막으로 평소의 라우팅과 DNS 설정을 복원하세요. 매 단계에서는 변수 하나만 변경해야 합니다. VMess WebSocket TLS에서 VLESS TCP REALITY로 한 번에 바꾸면 개선이 프로토콜 때문인지 전송 때문인지 보안 계층 때문인지 확인할 수 없습니다. 더 신뢰할 수 있는 방법은 전송과 TLS를 유지한 채 VMess와 VLESS를 먼저 비교하고, 그다음 전송 방식만 바꾸며, 마지막으로 보안 계층을 비교하는 것입니다.

클라이언트 화면의 연결 테스트는 보통 원격 서버가 응답하는지만 확인하며 완전한 서비스 경로의 안정성을 보장하지는 않습니다. 실제 애플리케이션은 서로 다른 도메인, IPv4 또는 IPv6, UDP, 장기 연결과 동시 요청을 사용할 수 있습니다. 설정을 주 설정으로 사용할 수 있는지 판단하려면 최소한 웹 접속, 지속 전송, 절전 후 복귀와 네트워크 전환을 모두 확인해야 합니다. 특정 애플리케이션에서만 문제가 발생한다면 프로토콜을 무작위로 바꾸기보다 DNS, 라우팅 또는 해당 애플리케이션의 프록시 연결 방식을 살펴봐야 합니다.

// 04 · MOBILE POWER

Android 연결의 배터리·백그라운드·네트워크 전환

배터리 소모는 프로토콜 이름만으로 결정되지 않습니다

Android의 프록시 클라이언트는 일반적으로 시스템 VPN 서비스를 통해 트래픽을 처리합니다. 배터리 소모에는 계속 실행되는 로컬 인바운드, 암복호화, DNS 처리, 라우팅 매칭, 연결 유지, 로그 기록과 잦은 네트워크 재연결이 모두 영향을 줍니다. 화면이 꺼지면 시스템 스케줄링과 백그라운드 제한이 연결 상태를 바꾸고, Wi-Fi에서 모바일 네트워크로 전환하면 기존 TCP 연결을 다시 수립해야 하는 경우가 많습니다. 따라서 VMess, VLESS 또는 SS의 이론적인 캡슐화 비용만으로 기기 전체의 배터리 사용량을 정확히 예측할 수 없습니다.

v2rayNG는 Xray 코어를 사용하므로 VLESS, REALITY와 Xray 라우팅 기능이 필요한 설정에 적합합니다. v2flyNG는 v2fly 코어를 사용하며 V2Fly 생태계 설정을 위한 Android 선택지가 될 수 있습니다. 두 클라이언트의 배터리 차이는 동일한 설정, 동일한 라우팅 모드와 비슷한 일상 사용 패턴에서 비교해야 합니다. 한쪽만 전체 로그, 복잡한 DNS 분할과 지속적인 탐색을 활성화하고 다른 쪽은 단순 프록시만 실행한다면 결과를 코어 계열의 차이로 볼 수 없습니다.

연결 유지와 잦은 깨우기

연결 유지는 연결을 유지하고 장애를 빠르게 감지하는 데 필요하지만, 간격이 너무 짧으면 네트워크와 프로세서를 자주 깨우게 됩니다. 실시간 통신에는 안정적인 장기 연결이 필요하지만 일반적인 웹 접속은 필요할 때 다시 연결하는 방식을 허용할 수 있습니다. 클라이언트나 서버의 유휴 시간 제한, 중간 네트워크 장비의 연결 회수 정책도 적절한 간격에 영향을 줍니다. 대기 중 배터리 소모가 눈에 띄게 늘었다면 먼저 지속 전송, 상세 로그 또는 비정상적인 재연결이 있는지 확인하세요. 간격을 무작정 매우 짧게 설정하는 것은 권장하지 않습니다.

다중화는 하위 연결 수를 줄일 수 있지만 하나의 장기 연결이 시스템이나 네트워크에 의해 회수될 수도 있습니다. 다중화를 끄면 연결 수와 핸드셰이크 횟수가 늘어날 수 있고, 켜면 주 연결이 자주 끊어질 때 여러 연결이 함께 다시 수립될 수 있습니다. 실제 선택은 전면 사용과 대기 상태를 포함한 완전한 주기를 관찰한 뒤 결정해야 합니다. 시스템 배터리 화면은 애플리케이션 활동 추세를 보여 주지만 프로토콜 비용을 직접 구분하지는 못하므로, 클라이언트 로그의 반복 연결, DNS 시간 초과와 네트워크 전환 기록을 함께 확인해야 합니다.

라우팅 범위와 DNS가 배터리에 미치는 영향

전체 트래픽을 가로채면 더 많은 애플리케이션 트래픽이 코어로 들어가므로 백그라운드 동기화, 미디어 전송과 시스템 서비스의 처리량이 증가합니다. 애플리케이션별 프록시 또는 합리적인 도메인·IP 분할을 사용하면 불필요한 전달을 줄일 수 있지만, 규칙이 지나치게 복잡하거나 원격 DNS 조회가 자주 발생하면 비용이 늘어납니다. 배터리 최적화의 핵심은 규칙을 최소화하는 것이 아니라 로컬 트래픽, LAN 접근과 명확한 직접 연결 대상을 우회시키지 않는 동시에 도메인 해석 경로와 최종 아웃바운드를 일치시키는 것입니다.

DNS 설정이 잘못되면 중복 조회, 시간 초과 후 폴백과 연결 재시도가 발생하며 이러한 배터리 소모를 프로토콜 문제로 오해하기 쉽습니다. 로그에 해석 시간 초과가 반복된다면 현재 네트워크가 설정된 DNS에 접근할 수 있는지, 조회가 올바른 아웃바운드로 라우팅되는지, IPv6 결과가 실제 네트워크 능력과 맞는지 먼저 확인하세요. IPv6를 끄는 것이 항상 정답은 아닙니다. 안정적인 IPv6를 제공하는 네트워크에서는 폴백이 한 번 더 발생할 수 있고, 완전한 IPv6 경로가 없는 네트워크에서는 유효하지 않은 주소를 먼저 시도해 지연이 생길 수 있습니다. 현재 네트워크에서 직접 측정한 결과에 따라 판단해야 합니다.

프로토콜과 전송 방식의 실제 선택

서버가 여러 방식을 동시에 제공한다면 모바일에서는 필드가 완전하고 코어가 기본 지원하며 연결 복구가 안정적인 조합을 먼저 선택하세요. VLESS REALITY에는 v2rayNG가 사용하는 Xray 기능이 필요합니다. 기본 VMess, Trojan 또는 SS는 설정 선택의 폭이 더 넓습니다. 전송 방식은 직접 TCP가 대체로 단순하지만 WebSocket과 gRPC의 적합성은 서버 배포 방식에 따라 달라집니다. 데스크톱 광대역에서 안정적인 전송이 모바일 네트워크 전환에서도 안정적이라는 보장은 없으므로, 특히 백그라운드에서 복귀한 뒤 수동 재연결이 필요한지 확인해야 합니다.

배터리 소모가 높다고 바로 구독을 삭제하지 마세요. 먼저 설정을 복사해 비교 환경을 만드세요. 상세 로그를 끄고 불필요한 탐색을 줄인 상태에서 프로토콜과 서버는 유지하고 다중화만 바꿉니다. 그다음 다중화는 유지한 채 전송 방식만 비교하고, 마지막으로 다른 프로토콜을 비교하세요. 각 테스트에서는 비슷한 화면 사용 시간과 트래픽 유형을 유지해야 합니다. 배터리 소모가 많은 업무 트래픽과 함께 발생한다면 정상적인 데이터 처리 비용일 수 있습니다. 트래픽이 거의 없는데도 계속 활성 상태라면 반복 재연결, DNS 재시도와 백그라운드 애플리케이션의 지속적인 요청을 중점적으로 점검해야 합니다.

// 05 · CORE FAMILIES

V2Fly와 Xray 코어 계열의 관계

공통 기반과 서로 다른 발전 방향

V2Fly와 Xray는 모두 Project V 설정 체계의 여러 핵심 개념을 이어받았습니다. 여기에는 인바운드, 아웃바운드, 라우팅, DNS, 전송과 정책 객체가 포함됩니다. 두 코어는 VMess, 기본 VLESS, Shadowsocks, SOCKS, HTTP 등 일반적인 기능에서 상당 부분 겹치므로 기본 설정이 비슷하게 보이는 경우가 많습니다. 하지만 서로 독립적으로 발전하는 코어 계열이므로 새로운 기능, 필드 이름, 기본 동작과 출시 일정이 완전히 같을 필요는 없습니다. 설정 구조가 비슷하다고 해서 모든 설정을 바로 서로 바꿔 사용할 수 있는 것은 아닙니다.

Xray는 VLESS, XTLS Vision, REALITY 등의 기능에서 명확한 조합 경로를 형성했습니다. V2Fly는 자체 코어를 중심으로 프로토콜, 전송, 라우팅과 플랫폼 기능을 계속 유지 관리합니다. 코어를 선택할 때는 어느 쪽이 ‘더 최신인가’만 묻지 말고, 구독에 사용된 기능이 어느 계열에 속하는지, 클라이언트가 해당 설정을 노출하는지, 서버가 동일한 구현을 사용하는지를 확인해야 합니다. 프로토콜이 기본적일수록 코어 간 호환이 쉽고, 전용 보안 계층·흐름 제어·실험적 필드를 사용할수록 호환 범위가 좁아집니다.

세 가지 GUI 클라이언트의 대응 관계

데스크톱에서는 v2rayN을 우선 고려할 수 있습니다. Windows, macOS와 Linux를 지원하며 구독 관리, 시스템 프록시, 라우팅 규칙과 다양한 코어 설정 진입점을 제공합니다. Android에서는 v2rayNG가 Xray 코어를 중심으로 동작하므로 VLESS, REALITY, Vision 등 Xray 기능이 필요한 설정에 적합합니다. v2flyNG는 V2Fly 코어에 대응하며 서버와 구독이 V2Fly 호환 기능을 명확히 사용하는 환경에 사용할 수 있습니다. 구체적인 설치 경로와 플랫폼 요구 사항은 클라이언트 받기 페이지에서 운영체제별로 확인하세요.

클라이언트 이름과 코어 이름을 혼동해서는 안 됩니다. v2rayN은 구독, 설정 편집, 코어 실행과 시스템 프록시를 담당하는 GUI 관리 계층이고, 실제로 프로토콜·전송·라우팅을 실행하는 것은 선택한 코어입니다. 동일한 v2rayN 화면에서도 코어를 바꾸면 사용할 수 있는 필드와 실행 결과가 달라질 수 있습니다. 문제를 해결할 때는 클라이언트 이름뿐 아니라 현재 코어 유형도 기록해야 합니다. ‘v2rayN이 연결되지 않는다’는 정보만으로는 부족하며 같은 설정도 코어에 따라 다른 결과가 나올 수 있습니다.

설정 호환성의 세 가지 계층

첫째는 문법 호환성입니다. JSON을 해석할 수 있는지, 필드 유형과 객체 위치가 코어 요구 사항에 맞는지를 확인합니다. 둘째는 기능 호환성입니다. 필드를 읽을 수 있더라도 해당 프로토콜이나 전송 방식이 실제로 구현되어 있는지 확인해야 합니다. 셋째는 동작 호환성입니다. 양쪽이 같은 이름의 기능을 구현하더라도 기본값, 폴백 규칙이나 경계 처리가 같은지 살펴봐야 합니다. 구독 가져오기에 성공했다는 것은 GUI 클라이언트가 입력을 받아들였다는 뜻일 뿐, 코어가 반드시 실행할 수 있거나 서버 매개변수와 일치한다는 의미는 아닙니다.

예를 들어 VLESS REALITY 설정을 일반 링크 형식으로 v2flyNG에 가져오면 목록에 주소와 사용자 ID가 표시될 수 있습니다. 그러나 대상 코어가 REALITY를 지원하지 않는다면 연결이 일반 TLS로 자동 전환되지는 않습니다. 서버가 기대하는 핸드셰이크가 완전히 다르므로 보안 계층을 조용히 바꿀 수 없습니다. 올바른 방법은 서버가 별도로 제공하는 호환 설정을 사용하거나, 해당 기능을 지원하는 v2rayNG·v2rayN과 Xray 코어에서 사용하는 것입니다.

코어 이전 전 검증 방법

이전하기 전에 원래 설정의 프로토콜, 전송, 보안, 라우팅과 DNS를 내보내거나 기록하세요. 공유 링크만 보관해서는 안 됩니다. 그런 다음 대상 코어가 각 핵심 필드를 지원하는지 확인하며, 특히 flow, REALITY 공개 키, 짧은 식별자, 전송 서비스 이름과 사용자 지정 아웃바운드를 살펴보세요. 이전 후에는 먼저 복잡한 라우팅을 끄고 단일 설정으로 기본 연결을 확인한 다음 DNS를 복원하고 마지막으로 분할 라우팅을 복원하세요. 이렇게 하면 프로토콜 호환성 문제인지, DNS 동작 차이인지, 규칙 태그 변경인지 구분할 수 있습니다.

코어를 전환한 뒤에는 로컬 수신 포트와 시스템 프록시도 확인해야 합니다. GUI 클라이언트는 설정 모드마다 다른 진입점을 사용할 수 있으므로, 기존 브라우저나 애플리케이션의 프록시 설정이 여전히 이전 포트를 가리키면 ‘코어는 성공적으로 시작되었지만 트래픽이 없다’는 현상이 나타납니다. 로그에 인바운드 연결 기록이 없다면 먼저 애플리케이션이 로컬 인바운드로 들어오는지 확인하세요. 인바운드 기록은 있지만 원격 핸드셰이크가 실패한다면 프로토콜과 보안 필드를 확인해야 합니다. 포트 충돌은 로컬 수신 포트 문제 해결을 참고하세요.

// 06 · TRANSPORT & SECURITY

전송 방식·TLS·REALITY와 핵심 매개변수

TCP·WebSocket·gRPC 및 HTTPUpgrade

클라이언트 설정에서 TCP는 일반적으로 프로토콜 데이터를 TCP로 직접 전달한다는 뜻이며 TLS가 없다는 의미는 아닙니다. network는 전송을, security는 외부 보안을 결정하므로 서로 독립적인 필드입니다. WebSocket에는 경로가 필요하고 일부 배포에서는 Host도 필요합니다. 경로는 일반적으로 슬래시로 시작하며 서버와 중간 전달 규칙이 사용하는 값과 일치해야 합니다. gRPC는 serviceName으로 서비스를 식별하므로 WebSocket의 path를 그대로 입력해서는 안 됩니다. HTTPUpgrade도 경로와 Host를 사용하지만 WebSocket과는 다른 전송 유형이며 서버가 명시적으로 지원해야 합니다.

구독을 가져온 뒤 주소, 포트와 사용자 ID가 올바른데 로그에 HTTP 상태 오류, 서비스 없음 또는 즉시 연결 종료가 나타난다면 먼저 전송 방식을 확인하세요. 흔한 문제로는 경로 끝의 불필요한 슬래시, 변환기가 serviceName을 path로 처리한 경우, Host와 서버 이름을 혼동한 경우, 중간 전달이 HTTP/1.1 또는 HTTP/2 중 하나만 활성화된 경우가 있습니다. 클라이언트는 자동 시도로 서버의 실제 배포 방식을 추측할 수 없으므로 입력 필드가 정확해야 합니다.

TLS의 서버 이름과 인증서 검증

TLS 설정의 serverName은 핸드셰이크에서 신원을 검증하는 데 사용되며 인증서의 도메인과 대응하는 경우가 많습니다. 연결 주소는 도메인이나 IP일 수 있지만 serverName은 서버 요구 사항에 맞춰 입력해야 합니다. allowInsecure 계열 옵션은 인증서 검증 여부를 제어하며 정상적인 설정에서는 엄격한 검증을 유지해야 합니다. 인증서 오류가 발생하면 검증을 장기간 끄기보다 기기 시간, 서버 이름, 인증서 유효 범위와 인증서 체인을 확인하세요. 인증서 오류는 프록시 인증보다 먼저 발생하므로 사용자 ID나 비밀번호를 바꿔도 해결되지 않습니다.

ALPN은 상위 프로토콜을 협상하는 데 사용하며 HTTP/2 또는 HTTP/1.1과 관련된 값이 흔합니다. 서버나 중간 인프라에서 명확히 요구할 때만 직접 지정하세요. ALPN을 무작정 추가하면 클라이언트가 서버에서 올바르게 처리하지 못하는 프로토콜을 협상할 수 있습니다. 지문 모방 필드는 TLS 클라이언트 핸드셰이크 특성에 영향을 주며 선택 가능한 값은 코어 구현에 따라 달라집니다. 구독에 이 필드가 포함되어 있다면 대개 그대로 유지해야 하며, 직접 편집하기 전 현재 코어가 허용하는 이름인지 확인하세요.

REALITY의 핵심 필드 네 가지

REALITY 설정에서 가장 먼저 확인할 항목은 serverName, publicKey, shortId와 fingerprint입니다. serverName은 핸드셰이크에 사용되는 서버 이름이고 publicKey는 서버 키 쌍의 공개 키에 해당합니다. shortId는 서버가 허용한 값이어야 하며 fingerprint는 클라이언트 핸드셰이크 지문을 지정합니다. 어느 하나라도 누락되거나 문자가 틀리면 초기 단계에서 연결이 실패할 수 있습니다. 공유 링크에서는 이 필드가 sni, pbk, sid, fp 등의 매개변수로 표시되는 경우가 많으므로 가져온 뒤 설정 상세에서 값이 잘리지 않았는지 확인해야 합니다.

VLESS REALITY는 Vision 흐름 제어와 함께 사용하는 경우가 많습니다. 이때 클라이언트의 flow는 서버와 일치해야 하며 다른 VLESS 설정이 비어 있다는 이유로 삭제해서는 안 됩니다. 반대로 서버에서 Vision을 활성화하지 않았다면 임의로 추가하지 마세요. REALITY 매개변수는 ‘고급 설정’처럼 보이지만 실제로는 연결에 필요한 정보입니다. 구독 변환, QR 코드 인식 또는 수동 복사 후 문제가 발생했다면 라우팅 모드를 반복해서 바꾸기보다 먼저 이 필드를 문자 단위로 대조하는 편이 효과적입니다.

라우팅 설정 예시와 프로토콜 설정의 경계

라우팅 규칙은 원격 프로토콜 연결을 수립하지 않고 코어에 들어온 요청을 여러 아웃바운드로 분배할 뿐입니다. 아래 예시는 일반적인 우선순위를 보여 줍니다. 먼저 광고 범주를 차단하고, 사설 주소와 국내 지역 도메인은 직접 연결하며, 나머지 요청은 기본 프록시 아웃바운드로 보냅니다. 예시는 해석 가능한 Xray/V2Ray 라우팅 객체 조각이며, 실제로 사용할 때는 전체 설정에 block, direct, proxy라는 아웃바운드 태그가 존재하는지 확인해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

규칙은 코어 설정의 의미에 따라 매칭되며 충돌하는 규칙의 순서가 결과에 영향을 줍니다. 사용자 지정 규칙을 추가하기 전에 클라이언트가 최종 설정을 생성할 때 기본 규칙을 뒤에 추가하는지 확인하세요. 화면에 보이는 순서가 최종 JSON 순서와 다를 수 있습니다. domainStrategy는 도메인을 IP로 해석해 IP 규칙을 계속 매칭할 시점을 결정하며 DNS 조회 횟수와 분할 라우팅 결과에 영향을 줍니다. domain, ip, geosite의 구체적인 작성법과 우선순위는 사용자 지정 라우팅 규칙 문법 완벽 가이드에서 계속 확인할 수 있습니다.

// 07 · SUBSCRIPTION COMPATIBILITY

구독 형식·공유 링크와 필드 호환성

구독은 설정을 전달하는 방식입니다

구독 자체는 프록시 프로토콜이 아닙니다. 제공 서버의 설정을 클라이언트로 전달하는 역할을 하며, Base64로 인코딩된 여러 줄의 공유 링크일 수도 있고 클라이언트가 인식할 수 있는 구조화된 설정일 수도 있습니다. 일반적인 공유 링크는 vmess://, vless://, trojan:// 또는 ss://로 시작합니다. 링크 스킴은 프로토콜 유형을 나타내고, 쿼리 매개변수는 전송, 보안, 서버 이름, 경로, 공개 키 등의 필드를 추가로 표현합니다. 클라이언트는 가져오는 과정에서 디코딩, 필드 매핑과 내부 설정 생성을 수행해야 합니다.

Base64는 인코딩일 뿐 암호화를 의미하지 않으며 프로토콜 기능을 결정하지도 않습니다. 같은 구독 주소도 업데이트에 따라 다른 노드, 메모 또는 매개변수를 반환할 수 있습니다. 클라이언트가 구독을 갱신하면 일반적으로 그룹 단위로 기존 설정을 교체하거나 병합하므로, 구독에서 생성된 항목을 수동으로 수정해도 다음 갱신 때 덮어쓰일 수 있습니다. 로컬 수정을 장기간 유지해야 한다면 독립 설정으로 복사하거나 클라이언트가 제공하는 구독 전처리·후처리 기능을 사용하고 수정 이유를 기록하세요.

공유 링크의 필드가 누락되는 이유

필드 누락은 생성 단계, 변환 과정과 클라이언트 가져오기 도구가 같은 매개변수에 서로 다른 이름을 사용할 때 자주 발생합니다. VLESS REALITY를 예로 들면 공개 키는 pbk, 짧은 식별자는 sid, 서버 이름은 sni, 지문은 fp로 표시될 수 있습니다. 가져오기 도구가 한 가지 명명 방식만 인식하면 목록에는 주소와 사용자 ID가 생성되지만 핵심 보안 필드는 비어 있게 됩니다. VMess JSON 공유 내용도 오래된 필드, 문자 인코딩 또는 메모에 포함된 특수 문자 때문에 해석에 실패할 수 있습니다.

구독 문제를 판단할 때는 ‘구독 가져오기’와 ‘개별 설정 실행’을 분리해서 보세요. 구독 주소를 갱신할 수 없다면 주소가 완전한지, 인증이 필요한지, 시스템 시간과 네트워크가 제공 서버에 접근할 수 있는지 먼저 확인합니다. 구독 갱신은 성공했지만 특정 설정만 실행되지 않는다면 해당 항목의 프로토콜 필드를 점검하세요. 원본 공유 링크를 수동으로 가져오면 작동하지만 구독으로 가져온 뒤 작동하지 않는다면 문제는 코어보다 구독 내용이나 변환 과정에 있을 가능성이 큽니다.

세 클라이언트의 호환성 판단

v2rayN은 데스크톱에서 VMess, VLESS, Trojan, SS 등 일반적인 유형을 통합 관리하고 선택한 코어로 실행하는 데 적합합니다. v2rayNG는 Android와 Xray 설정을 대상으로 하며 VLESS REALITY 같은 Xray 기능에 더 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 구독이 V2Fly에서 실행 가능한 설정을 명확히 제공하는 환경에 적합합니다. 세 클라이언트 모두 기본 공유 링크를 인식할 수 있지만 ‘링크를 인식한다’는 것과 ‘링크의 모든 기능을 지원한다’는 것은 구분해서 판단해야 합니다.

여러 기기에서 하나의 구독을 공유할 때 가장 안정적인 방법은 구독에 기본 호환 설정과 전용 코어가 필요한 설정을 함께 제공하고 읽기 쉬운 메모로 구분하는 것입니다. 모든 항목이 REALITY에 의존한다면 v2flyNG가 자동으로 사용할 수 있는 대체 설정을 얻지는 못합니다. 반대로 기본 VMess 또는 SS만 사용하면 코어 간 이전이 대체로 간단하지만 전송 확장, UDP와 암호화 방식은 여전히 확인해야 합니다. 전체 가져오기 절차는 v2rayN 및 v2rayNG 구독 링크 가져오기 가이드를 참고하세요.

구독 갱신을 위한 안전한 순서

갱신 전에 현재 사용 중인 항목과 라우팅 모드를 기록하고, 중요한 수동 설정은 먼저 구독과 무관한 그룹으로 복사하세요. 갱신 후에는 이전 그룹을 바로 삭제하지 말고 항목 수가 적절한지, 메모가 바뀌었는지, 현재 설정이 계속 선택되어 있는지 확인한 뒤 연결을 테스트하세요. 갱신 후 모든 항목에서 문제가 발생했다면 이전 설정으로 돌아가 구독 내용의 변화인지 로컬 네트워크 문제인지 판단할 수 있습니다. 단일 항목에서만 문제가 발생한 경우에는 갱신 전후의 주소, 포트, 프로토콜, 보안과 전송 필드를 비교하세요.

QR 코드 가져오기도 공유 링크 해석의 한 방식입니다. QR 코드 화면이 선명하더라도 내용이 완전하다는 보장은 없습니다. 스크린샷 잘림, 확대·축소와 긴 링크의 용량이 인식에 영향을 줄 수 있습니다. 인식 후에는 설정 상세를 확인하고 ‘가져오기 성공’ 알림만으로 최종 검증을 끝내지 마세요. 구독이나 공유 링크에 민감한 연결 정보가 포함되어 있다면 접근 자격 증명처럼 관리하고 공개 페이지나 로그 화면에 전체 내용을 표시하지 않아야 합니다. 문제를 제출할 때는 프로토콜 유형과 필드 이름만 남기고 주소, 사용자 ID, 비밀번호와 키 매개변수는 가리세요.

// 08 · SCENARIO CHOICE

사용 환경별 프로토콜 및 클라이언트 선택

기존 서버: 일치 여부를 우선하기

설정이 기존 서버나 구독에서 제공된 것이라면 선택의 범위는 서버가 결정합니다. 클라이언트는 프로토콜, 전송과 보안 매개변수를 그대로 사용해야 하며 VLESS를 VMess로 바꾸거나 WebSocket을 TCP로 바꿔서는 안 됩니다. 데스크톱에서는 v2rayN을 우선 사용하고, 설정의 모든 필드를 지원하는 코어를 선택하세요. Android에서 VLESS REALITY, Vision 등 Xray 기능이 필요하면 v2rayNG를 사용하고, V2Fly 호환 설정을 명확히 사용하는 경우에는 v2flyNG를 선택할 수 있습니다. 프로토콜 이름의 최신성보다 안정적인 실행이 중요합니다.

하나의 구독에 서로 다른 프로토콜이 여러 개 있다면 먼저 필드가 불완전하거나 코어가 맞지 않는 항목을 제외한 뒤 실제 경로를 비교하세요. VMess는 성숙한 배포를 이어 가는 데 적합하고, VLESS는 최신 TLS 또는 REALITY 조합에 적합합니다. Trojan은 표준 TLS 매개변수가 명확한 배포에 적합하며, SS는 기본 필드가 간단하고 UDP 지원이 필요한 환경에 적합합니다. 최종 선택은 목록 순서나 이름의 인상이 아니라 안정성, 복구 속도와 일상 애플리케이션의 동작을 기준으로 해야 합니다.

여러 플랫폼에서 사용: 호환 범위를 우선하기

Windows, macOS, Android와 Linux에서 설정을 공유해야 한다면 모든 플랫폼의 클라이언트가 완전히 가져올 수 있는지 먼저 확인하세요. 기본 VMess, Trojan과 SS는 대체로 여러 환경에서 표현하기 쉽고 기본 VLESS TLS도 폭넓게 지원됩니다. REALITY, Vision 또는 특정 전송 확장을 추가하면 각 플랫폼의 코어를 개별적으로 확인해야 합니다. 여러 플랫폼용 구성에서는 기능이 최신인 주 설정과 필드가 단순한 호환 설정을 함께 준비해 특정 기기가 코어 차이로 완전히 연결할 수 없게 되는 상황을 피할 수 있습니다.

구독 메모에는 Xray 전용과 기본 호환 설정을 구분하는 등 읽기 쉬운 프로토콜과 용도 정보를 포함하세요. 클라이언트가 자동으로 인식한 뒤 추측하게 두지 않는 것이 좋습니다. 구독을 갱신할 때는 먼저 한 기기에서 검증하고 필드와 그룹이 정상인지 확인한 뒤 다른 기기를 갱신하세요. 이렇게 하면 구독 생성 측의 필드 변화가 모든 기기에 동시에 영향을 주는 위험을 줄일 수 있습니다. 기기마다 같은 클라이언트를 사용할 필요는 없지만 각 플랫폼의 코어와 설정 관계는 기록해야 합니다.

저사양 기기와 모바일 사용: 추가 작업 줄이기

성능이 낮은 기기에서 사용하거나 대기 중 배터리를 중시한다면 코어가 기본 지원하고 전송 계층이 단순하며 복잡한 변환이 필요 없는 설정을 우선 선택하세요. SS는 구조가 간단하고 VLESS는 프로토콜 계층의 오버헤드가 낮지만, 실제 리소스 사용량은 외부 보안, 연결 수, DNS와 라우팅에 따라 달라집니다. 직접 TCP가 여러 겹의 HTTP 의미론을 추가하는 방식보다 간단한 경우가 많지만 서버 배포 조건이 허용해야 합니다. 소량의 프로토콜 처리 비용을 줄이려고 필요한 인증이나 인증서 검사를 끄면 안 됩니다.

Android에서는 먼저 디버그 로그, 불필요한 DNS 재시도와 지나치게 짧은 연결 유지를 줄인 뒤 프로토콜을 비교하세요. 대기 후 연결이 자주 끊긴다면 암호화 방식만 바꾸지 말고 백그라운드 제한과 네트워크 전환을 확인해야 합니다. UDP가 필요한 애플리케이션은 서버, 프로토콜, 전송과 클라이언트 인바운드가 모두 UDP를 지원하는지도 확인하세요. 어느 한 계층이라도 빠지면 일부 기능에 문제가 생깁니다. TCP 웹 접속이 정상이라고 UDP 경로까지 정상이라는 뜻은 아닙니다.

복잡한 라우팅: 코어와 규칙 기능을 우선하기

도메인, IP, 애플리케이션 또는 프로토콜 유형에 따라 세밀하게 분할 라우팅해야 한다면 프록시 프로토콜보다 클라이언트의 규칙 생성 방식과 코어 기능이 더 중요합니다. v2rayN은 데스크톱에서 비교적 복잡한 라우팅을 관리하기에 적합하고, v2rayNG는 Android에서 Xray 규칙과 함께 사용할 수 있습니다. 규칙을 설계할 때는 먼저 direct, proxy, block 세 가지 아웃바운드를 정한 다음 높은 우선순위의 예외, 사설 네트워크, 지역 집합과 기본 경로 순으로 구성하세요. 규칙이 많을수록 순서와 DNS 정책을 명확히 해야 합니다.

라우팅 이상은 일부 도메인만 접속되지 않거나, LAN 기기에 접근할 수 없거나, 해석 결과와 연결 아웃바운드가 일치하지 않는 형태로 나타나는 경우가 많습니다. 이때 VMess와 VLESS를 바꿔도 해결되지 않는 경우가 일반적입니다. 일시적으로 단순한 라우팅을 사용해 기본 프로토콜을 확인한 뒤 규칙을 그룹별로 복원하세요. DNS 누출, 원격 해석과 로컬 해석은 DNS와 라우팅 설계의 문제이므로 DNS 점검 및 클라이언트 설정 실전 가이드를 참고해 계속 확인할 수 있습니다.

최종 선택 체크리스트

1. 서버 확인: 프로토콜, 주소, 포트, 전송, 보안 계층과 모든 인증 필드를 기록하고 클라이언트에서 임의로 변경하지 않습니다.
2. 코어 확인: REALITY와 Vision은 Xray 지원 여부를 우선 확인하고, V2Fly 설정은 v2flyNG 또는 해당 데스크톱 코어에서 검증합니다.
3. 구독 확인: 가져온 뒤 flow, sni, publicKey, shortId, fingerprint, path와 serviceName이 모두 완전한지 확인합니다.
4. 기준 설정 마련: 먼저 단순한 라우팅과 일반적인 DNS로 연결을 확인한 뒤 분할 라우팅, 다중화와 고급 옵션을 복원합니다.
5. 환경별 테스트: 짧은 연결, 지속 전송, UDP, 절전 후 복귀, 네트워크 전환과 여러 기기에서의 가져오기를 각각 확인합니다.
6. 대체 경로 보존: 검증된 설정을 복사해 두고 프로토콜 이전, 코어 전환과 구독 갱신을 동시에 진행하지 않습니다.

계속 판단하기 어렵다면 데스크톱에서는 v2rayN과 서버의 원본 설정부터 확인하고, Android에서는 코어 기능에 따라 v2rayNG와 v2flyNG 중에서 선택하세요. 오류가 발생하면 먼저 계층을 특정합니다. 로컬 인바운드에 트래픽이 없으면 시스템 프록시와 포트를 확인하고, 원격 핸드셰이크가 실패하면 프로토콜과 보안 필드를 확인하며, 일부 도메인만 이상하면 라우팅과 DNS를 확인합니다. 구독 갱신 후 문제가 발생했다면 갱신 전후 필드를 비교하세요. 이 순서로 처리하면 프로토콜을 계속 바꾸는 것보다 원인을 더 빠르게 찾을 수 있습니다.