V2Ray 프로토콜 및 코어 가이드

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

프록시 프로토콜, 전송 방식, 보안 계층을 구분하세요

클라이언트의 서버 설정은 적어도 세 가지를 정해야 합니다. 대상 주소와 인증 정보를 어떤 프로토콜로 표현할지, 데이터를 어떤 전송 방식으로 보낼지, 보안 연결을 어떻게 설정할지입니다. VMess, VLESS, Trojan, Shadowsocks는 주로 첫 번째 항목에 해당합니다. TCP, WebSocket, gRPC 등은 두 번째 항목이며 TLS와 REALITY는 보안 연결과 관련된 선택지입니다. 이 항목들이 한 편집 화면에 함께 표시되더라도 서로 바꿔 쓸 수 있는 같은 종류의 옵션은 아닙니다. 서버가 VLESS를 사용한다는 정보만으로는 연결 설정을 재현할 수 없습니다.

예를 들어 두 설정 모두 VLESS를 사용하더라도 하나는 TCP와 REALITY, 다른 하나는 WebSocket과 TLS를 사용한다면 핸드셰이크 절차, 필수 항목, 서버 연결 방식이 모두 다릅니다. 첫 번째 설정의 공개 키를 두 번째 설정에 복사하거나 두 번째 설정의 경로를 첫 번째 설정에 입력해도 대개 문제가 해결되지 않습니다. 프로토콜, 전송 방식, 보안 계층을 각각 적고 주소, 포트, 인증 정보는 별도로 기록하는 편이 좋습니다. 이렇게 정리하면 클라이언트 화면의 항목 이름이 바뀌어도 의미에 맞춰 확인할 수 있습니다.

서버 주소와 핸드셰이크 이름 구분하기

서버 주소는 연결을 처음 보낼 대상을 지정하며 도메인이나 IP 주소를 사용할 수 있습니다. TLS의 서버 이름은 보통 SNI 필드로 전달되어 핸드셰이크와 인증서 신원 확인에 사용됩니다. 주소 입력란과 문자열이 반드시 같아야 하는 것은 아니지만 서버 구성과 일치해야 합니다. WebSocket의 Host는 HTTP 요청 헤더에 해당하고, 경로는 연결할 엔드포인트를 지정합니다. 이 항목들은 같은 도메인을 입력하는 경우가 있어 중복처럼 보일 수 있습니다. 문제를 해결할 때는 각각 따로 확인하고, 주소만 바꾸면 다른 이름도 자동으로 바뀐다고 가정하지 마세요.

로컬 인바운드, 시스템 프록시, 라우팅은 별도의 설정 항목입니다. 로컬 인바운드는 앱의 연결을 받아들이고, 시스템 프록시는 일부 앱이 해당 인바운드로 요청을 보내도록 합니다. 라우팅은 코어에 들어온 트래픽의 아웃바운드를 결정합니다. 앱이 시스템 프록시를 사용하지 않는다면 프로토콜의 암호화 방식을 바꿔도 해당 앱의 트래픽이 자동으로 코어에 들어오지 않습니다. 라우팅 규칙에 따라 직접 연결되고 있다면 서버를 바꿔도 해당 연결의 아웃바운드는 달라지지 않습니다. 안드로이드의 VPN 트래픽 처리와 PC의 시스템 프록시 방식은 다르므로, 모든 설정을 그대로 복사하기보다 각 기능의 적용 범위를 확인하세요.

진단에 필요한 정보를 남기고 최소한으로 변경하기

가져온 직후에는 원본 설정을 보존하고 로컬 동작을 항목별로 조정하세요. 주소, 인증, 전송, 보안 매개변수는 서버에서 제공한 정보를 기준으로 설정해야 합니다. 로컬 포트, 앱별 적용 범위, 로그 수준은 기기에 맞게 조정할 수 있습니다. 프로토콜, DNS, 라우팅을 한꺼번에 바꾸면 성공하거나 실패해도 원인을 파악하기 어렵습니다. 설정을 복사해 비교용으로 보관하고 한 번에 한 항목만 바꾼 뒤, 오류가 시작·핸드셰이크·접속 중 어느 단계에서 발생했는지 기록하세요. 항목별 간단한 설명은 용어집에서 확인할 수 있으며, 처음 가져오는 절차는 시작 가이드를 참고하세요.

VMess: 인증, 시간, 암호화 방식

설계 배경과 연결 비용

VMess는 Project V 생태계 초기의 주요 프록시 프로토콜로, 인증과 요청 표현, 데이터 보호를 프로토콜 설계에 포함합니다. 일반 TCP 연결에 이름만 붙인 것이 아니라 클라이언트와 서버가 동일한 형식으로 요청을 처리해야 합니다. 선택할 때는 성숙한 생태계 지원과 다양한 전송 조합이 장점이며, 프로토콜 자체의 암호화와 외부 보안 연결이 어떤 관계인지 이해해야 합니다. 오래된 설정을 사용할 때는 과거 인증 방식과 현재 구현을 구분해야 하며, VMess 링크를 모두 같은 형식으로 취급해서는 안 됩니다.

VMess의 속도는 암호화 여부만으로 판단할 수 없습니다. 요청 한 번에도 로컬 DNS 조회, 전송 연결, 인증, 원격 전달이 필요하며 TLS까지 추가하면 핸드셰이크 작업이 늘어납니다. 최신 프로세서는 암호화 알고리즘에 따라 하드웨어 지원 정도가 다릅니다. 짧은 요청은 왕복 시간의 영향을 더 크게 받을 수 있고, 장시간 다운로드에서는 지속 처리량의 한계가 드러나기 쉽습니다. VMess 연결이 다른 연결보다 느리다면 프로토콜 처리 비용을 따지기 전에 두 연결의 회선, 서버 부하, 전송 방식이 같은지 먼저 확인하세요.

UUID, 암호화, alterId의 범위

VMess 설정에서 UUID는 인증 정보이지 노드 이름이나 클라이언트에서 임의로 생성해 바로 쓸 수 있는 문자열이 아닙니다. 암호화 방식은 양측 구현이 지원해야 합니다. 클라이언트의 자동 선택은 실행 환경에 맞는 알고리즘을 선택하는 기능인 경우가 많으며, 인증 오류를 자동으로 해결하지는 않습니다. 처리 비용을 줄이겠다는 이유만으로 데이터 암호화를 제공하지 않는 방식을 임의로 선택하지 마세요. 외부 TLS와 프로토콜 자체 보호는 역할이 다릅니다. 특정 조합을 사용할지는 명확한 서버 구성에 따라 결정해야 하며, 계층을 하나 줄이는 것이 언제나 최적화인 것은 아닙니다.

오래된 가이드에는 alterId가 자주 등장합니다. 과거 호환성 기능과 관련된 항목으로, 최신 VMess AEAD 설정에서는 보통 0을 사용하며 클라이언트에서 해당 필드가 숨겨질 수도 있습니다. 구독에 0이 아닌 값이 남아 있어도 숫자만 0으로 바꾼다고 이전이 완료되는 것은 아닙니다. 서버가 해당 인증 방식을 지원해야 합니다. 먼저 제공자가 요구하는 설정을 확인하고 현재 코어가 해당 형식을 처리할 수 있는지 점검하세요. 오래된 매개변수를 계속 사용하면 가져오기는 성공해도 연결이 실패할 수 있습니다. 화면에 구문 오류가 없다고 해서 양측 인증 방식이 일치한다는 뜻은 아닙니다.

시스템 시간과 전송 항목 확인 순서

VMess 인증에는 시간이 관여하므로 시스템 시간이 크게 어긋나면 요청이 거부될 수 있습니다. 문제를 해결할 때는 시스템 자동 시간 설정을 켜고 날짜와 실제 시각을 확인하세요. 화면에 표시된 시간대만 확인해서는 부족합니다. 시간대 표시가 다르다고 해서 시스템 시계가 반드시 잘못된 것은 아닙니다. 그다음 UUID와 포트, 서버가 현재 설정을 계속 허용하는지 확인합니다. 인증 정보가 정확한 것을 확인한 뒤 WebSocket 경로, Host 등 전송 항목을 점검하세요. 이렇게 하면 인증 문제를 회선 장애로 오해하는 일을 줄일 수 있습니다.

VMess 링크로 가져올 때는 링크 내부 항목이 클라이언트 편집 화면에 어떻게 반영됐는지도 확인해야 합니다. 오래된 링크는 전송 이름, TLS 사용 여부, 호스트 이름을 구식 필드로 표현할 수 있으며, 가져오기 도구가 자체 규칙에 따라 기본값을 채울 수도 있습니다. 목록의 프로토콜 표시만 보지 말고 가져온 뒤 주소, SNI, 경로, 암호화 방식을 확인하세요. 같은 설정이 다른 기기에서 작동한다면 동일한 링크를 계속 삭제하고 다시 붙여넣기보다 설정 항목과 코어 로그를 비교하세요.

VLESS와 REALITY: 경량 프로토콜과 보안 핸드셰이크 구분하기

VLESS는 프로토콜 자체의 역할을 줄입니다

VLESS는 프로토콜 자체의 인증과 요청 처리를 단순화하도록 설계됐으며, VMess처럼 기본 프로토콜에 같은 종류의 데이터 암호화 기능을 제공하지 않습니다. 일반적인 설정에서 encryption 값이 none인 것은 이 계층의 처리 방식을 뜻하며, 전체 연결이 반드시 평문이라는 의미는 아닙니다. 보안 보호 여부는 외부에 TLS 또는 REALITY를 사용하는지, 관련 검증이 올바르게 활성화됐는지 추가로 확인해야 합니다. 계층을 나눠 조합하기 편리하지만, 한 항목의 의미를 전체 연결로 확대 해석하지 않도록 주의해야 합니다.

따라서 VLESS를 ‘암호화를 빼서 무조건 빠른 프로토콜’이라고 단순화할 수 없습니다. 일부 프로토콜 처리 비용이 줄어도 TLS나 REALITY에는 핸드셰이크와 데이터 보호 작업이 남아 있으며, 전송 방식의 오버헤드가 주요 비용일 수도 있습니다. 현재 기기에 VLESS가 적합한지는 서버가 제공하는 조합, 코어 구현, 네트워크 환경에 따라 달라집니다. PC에서는 v2rayN이 사용하는 코어가 필요한 매개변수를 모두 지원하는지 확인하세요. 안드로이드에서는 클라이언트 코어와 설정 형식이 맞는지 점검해야 합니다. UUID를 인식한다고 해서 모든 기능을 사용할 수 있는 것은 아닙니다.

REALITY는 독립된 프록시 프로토콜이 아닙니다

REALITY는 Xray 생태계의 보안 연결 방식이며 VLESS와 함께 사용하는 경우가 많습니다. 클라이언트에는 보통 서버 공개 키, 서버 이름, shortId, 지문 설정이 필요합니다. 이 정보들은 핸드셰이크에 함께 사용되므로 일반 TLS 설정만으로 유추할 수 없습니다. 인증서 도메인 검증과 설정 방식은 다르지만, 그렇다고 신원 확인을 무시해도 된다는 뜻은 아닙니다. 클라이언트에는 연결에 필요한 공개 매개변수만 설정해야 하며, 서버 개인 키를 구독, 스크린샷, 클라이언트 입력란에 노출해서는 안 됩니다.

공개 키는 복사 가능한 문자열처럼 보여도 서버 키와 짝이 맞아야 합니다. shortId도 서버에서 허용하는 값과 형식에 맞아야 합니다. 서버 이름은 배포 설정에 따라야 하며 접속 가능한 도메인을 임의로 입력해서는 안 됩니다. 지문 옵션은 관련 핸드셰이크 동작을 위한 호환성 매개변수이지 지역 선택이나 속도 설정이 아닙니다. 가져오기 도구가 이 중 하나를 빠뜨리면 설정이 목록에 표시되더라도 핸드셰이크 단계에서 실패할 수 있습니다. 검증을 끄고 오류를 우회하지 말고 원본 매개변수와 하나씩 대조하세요.

flow와 전송 방식은 임의로 조합할 수 없습니다

VLESS의 flow는 XTLS Vision 관련 값처럼 특정 흐름 제어 방식을 나타냅니다. 범용 가속 버튼이 아니며 모든 전송 조합에서 사용할 수 있는 것도 아닙니다. 서버에서 Vision을 요구한다면 클라이언트가 해당 방식을 지원해야 하며 호환되는 전송 방식과 보안 계층을 사용해야 합니다. 서버에 해당 flow가 설정되지 않은 상태에서 임의로 추가하면 오히려 연결이 실패할 수 있습니다. 웹 가이드에서 발췌한 매개변수는 해당 전체 조합에만 적용됩니다. 문맥을 벗어나 WebSocket이나 다른 연결 방식에 그대로 복사하지 마세요.

실제 설정은 ‘프로토콜 및 UUID → 전송 방식 → 보안 계층 → 공개 키 및 서버 이름 → shortId → flow’ 순서로 확인할 수 있습니다. 편집 화면에서 기본값이 항목을 덮어쓰지 않았는지 확인한 뒤 코어 로그를 살펴 매개변수 파싱 오류와 원격 핸드셰이크 실패를 구분하세요. 전자는 지원되지 않는 구현이나 잘못된 필드 형식이 원인일 수 있고, 후자는 서버 요구 사항과 네트워크 연결 가능성을 추가로 확인해야 합니다. 구독 업데이트 후 갑자기 실패했다면 이전 기록을 보존해 항목별 차이를 비교하세요. 모든 오류를 공개 키 변경 탓으로 돌리지 마세요.

Trojan과 Shadowsocks: TLS 의존성과 암호화 방식

Trojan은 TLS를 기반으로 보안 연결을 구성합니다

일반적인 Trojan 연결은 먼저 TLS를 맺은 뒤 프로토콜 인증과 데이터 전달을 수행합니다. 클라이언트에서 중요한 항목은 서버 주소, 포트, 비밀번호, 서버 이름입니다. 다른 조합보다 설정이 간단해 보여도 TLS에는 명확한 신원 확인 절차가 있습니다. 인증서 이름 불일치, 인증서 체인 오류, 시스템 시간 문제는 비밀번호를 확인하기 전에 연결을 끊을 수 있습니다. Trojan 연결이 실패해도 비밀번호를 반복해서 바꾸기보다 로그에서 어느 단계에서 멈췄는지 먼저 확인하세요.

주소에 IP를 사용하고 인증서가 도메인에 발급된 경우에는 서버 안내에 따라 올바른 서버 이름을 입력해야 할 수 있습니다. SNI는 핸드셰이크에서 서버 이름을 전달하며, 인증서 검증은 상대방의 신원을 확인합니다. 서로 관련은 있지만 같은 설정은 아닙니다. 인증서 검증을 건너뛰면 신원 확인이 약해지므로 일반적인 해결책으로 사용해서는 안 됩니다. 서버가 별도의 신뢰 방식을 사용하는 경우 명시된 설정을 따르세요. 일반적인 공개 인증서를 사용하는 서버라면 시간, 이름, 인증서 체인을 바로잡고 정상적인 검증을 유지하세요.

Shadowsocks의 암호화 방식은 프로토콜 조건입니다

Shadowsocks는 보통 SS로 줄여 부르며 간결한 프록시 전달과 암호화 처리를 중시합니다. 클라이언트에는 서버 주소, 포트, 비밀번호, 암호화 방식이 필요합니다. 암호화 방식은 클라이언트만 따로 정하는 성능 옵션이 아니라 양측이 일치해야 하는 프로토콜 조건입니다. 비밀번호가 맞아도 방식이 다르면 연결에 실패합니다. 과거 설정과 최신 프로토콜 변형은 키 요구 사항이 다를 수 있으므로, SS로 표시된 모든 설정이 비밀번호만 바꾸면 서로 호환된다고 볼 수 없습니다.

기존 AEAD 방식과 Shadowsocks 2022 계열은 키 처리 등에서 차이가 있습니다. 후자의 암호화 방식 이름과 인코딩된 키 요구 사항은 서버나 구독 제공자가 안내한 값을 사용해야 하며, 임의의 짧은 비밀번호를 입력하는 것은 적절하지 않습니다. 특정 방식을 지원하는지는 클라이언트 화면에 Shadowsocks가 표시되는지만이 아니라 실행 중인 코어에 달려 있습니다. 가져오는 중 알 수 없는 방식이라는 오류가 나오면 먼저 이름의 철자와 코어 지원 여부를 확인하세요. 익숙한 다른 이름으로 바꿔도 서버가 새 알고리즘을 자동으로 사용하는 것은 아닙니다.

전송 조합과 UDP 요구 사항

Trojan이나 SS는 배포 방식에 따라 추가 전송 매개변수를 사용할 수 있지만, 범용 공유 링크 하나가 모든 확장 항목을 완벽하게 표현한다고 가정해서는 안 됩니다. 특히 SS 링크의 추가 매개변수는 가져오기 도구가 모두 지원하지 않을 수 있습니다. 제공자가 요구하는 조합을 현재 클라이언트 세 종류와 각 코어에서 표현할 수 있는지 확인한 뒤 사용 여부를 결정하세요. 가져온 뒤 확장 매개변수가 사라졌다면 호환성 문제로 보아야 합니다. 필요한 항목이 빠진 설정으로 회선 속도를 계속 측정하지 마세요.

음성 통화, 게임 등 데이터그램이 필요한 경우에는 UDP 경로도 별도로 확인해야 합니다. 프로토콜에서 UDP를 지원하더라도 로컬 인바운드, 클라이언트의 트래픽 처리 방식, 서버 전달, 대상 네트워크가 모두 데이터그램을 허용한다는 뜻은 아닙니다. TCP 웹 접속이 성공한 것은 해당 요청 경로가 작동한다는 사실만 보여 줍니다. 실제로 UDP가 필요한 앱을 사용하고 로그를 확인해 앱이 코어에 들어오지 않는지, 서버가 전달하지 않는지, 대상이 응답하지 않는지 구분하세요. 웹페이지가 열린다는 이유만으로 UDP 문제를 앱 자체의 문제라고 단정하지 마세요.

속도, 리소스, 배터리: 핸드셰이크와 지속 전송 구분하기

빠른 연결과 빠른 다운로드는 다릅니다

짧은 웹페이지를 여는 데는 DNS 조회, 연결 설정, 핸드셰이크, 첫 응답 대기 시간이 주로 영향을 줍니다. 장시간 다운로드는 회선 용량, 혼잡 제어, 서버 출구 대역폭, 기기 처리 능력의 영향을 더 크게 받습니다. 특정 프로토콜이 핸드셰이크 작업을 줄여 짧은 연결 경험을 개선하더라도 장시간 연결의 처리량까지 높이는 것은 아닙니다. 반대로 다운로드가 잘되는 회선도 DNS 조회나 핸드셰이크 대기 때문에 웹페이지가 늦게 열릴 수 있습니다. 프로토콜을 비교할 때는 연결 성공률, 첫 응답 시간, 안정적인 전송 성능을 나눠 기록하세요. 지연 시간 하나로 전체 사용 경험을 설명할 수는 없습니다.

TCP, WebSocket, gRPC는 각기 다른 캡슐화와 연결 관리 방식을 사용하지만 실제 영향은 구현과 배포 환경에 따라 달라집니다. WebSocket에는 HTTP 업그레이드와 프레임 처리가 추가되고, gRPC는 HTTP/2 동작과 서버 지원에 의존합니다. 이러한 방식은 대개 연결 아키텍처에 필요한 것이지 모든 회선의 지연 시간을 줄이기 위한 것은 아닙니다. 패킷 손실, 혼잡, 중간 장비의 처리 방식도 결과를 바꿉니다. 회선과 서버 조건을 통제하지 않은 비교 테스트는 해당 연결 조합만 평가할 수 있습니다. 이를 근거로 프로토콜에 고정된 속도 순위를 매길 수는 없습니다.

CPU·메모리 사용량과 연결 재사용의 한계

암호화 알고리즘이 프로세서 명령어를 활용할 수 있는지, 코어의 버퍼 처리 방식, 활성 연결 수, 로그 출력량에 따라 리소스 사용량이 달라집니다. PC 부하가 낮을 때는 브라우저와 시스템 작업이 프로토콜 간 차이를 가릴 수 있습니다. 소형 기기는 장시간 높은 처리량을 유지할 때 발열 제한에 걸리기 쉽습니다. 리소스를 관찰할 때는 실제 처리량과 지속 시간을 함께 확인하세요. 같은 CPU 사용률이어도 처리한 데이터 양은 크게 다를 수 있습니다. 클라이언트 화면을 표시하는 프로세스의 사용량이 코어 전체 사용량을 뜻하는 것은 아닙니다. 두 프로세스가 분리돼 있을 수도 있습니다.

연결 재사용은 여러 논리 요청이 더 적은 수의 하위 연결을 공유하게 해 반복 연결을 줄일 수 있습니다. 반면 혼잡, 길이가 다른 요청의 혼합, 구현 불일치 때문에 대기 시간이 늘어날 수도 있습니다. 모든 프로토콜에 적용되는 전역 최적화 기능은 아닙니다. 기본 설정을 유지하고 짧은 연결이 많으며 서버도 지원하는 경우에만 비교 테스트를 하세요. 활성화 후 간헐적인 멈춤이 생기면 독립 연결을 기준으로 되돌리세요. 라우팅, DNS, 전송 방식을 동시에 바꾸면 결과를 연결 재사용 설정 덕분이라고 단정할 수 없습니다.

안드로이드 배터리는 깨우기와 재연결이 주요 변수입니다

모바일 배터리 사용량은 암호화 작업뿐 아니라 무선 연결 유지, 백그라운드 깨우기, 연결 유지 간격, 실패 후 재연결의 영향을 받습니다. 계산량이 적은 프로토콜처럼 보여도 자주 끊겨 보안 연결을 다시 맺으면 결과적으로 배터리를 더 많이 쓸 수 있습니다. 모바일 네트워크와 Wi-Fi를 전환할 때도 연결을 다시 맺는 비용이 발생합니다. v2rayNG 또는 v2flyNG를 비교할 때는 비슷한 신호 세기, 화면 사용 시간, 앱 부하를 유지하며 관찰하세요. 한 번 측정한 백그라운드 배터리 순위를 특정 프로토콜의 고정적인 특성으로 해석해서는 안 됩니다.

VpnService는 안드로이드 트래픽을 가로채는 기능이지 코어가 연결에 성공했다는 뜻은 아닙니다. 배터리 최적화 제한으로 화면을 잠근 뒤 백그라운드 처리가 중단되면 화면을 켰을 때 다시 연결되는 것처럼 보일 수 있습니다. 앱별 설정 때문에 일부 앱이 코어를 완전히 거치지 않을 수도 있습니다. 먼저 시스템의 백그라운드 제한과 트래픽 처리 범위를 확인한 뒤 프로토콜 변경을 고려하세요. 관련 설정은 v2rayNG 권한, 배터리 최적화, 앱별 설정을 참고하세요. 속도 측정 대상의 차이는 지연 시간 테스트 원리에서 확인할 수 있습니다. ICMP 결과를 실제 프록시 요청의 결과로 대신하지 마세요.

V2Fly와 Xray: 프로젝트 계보와 설정 호환성

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

Project V는 이 도구 생태계를 이해하는 배경입니다. V2Fly는 V2Ray 관련 개발을 이어 왔고, Xray는 관련 코드 기반에서 분기해 고유한 기능을 발전시켰습니다. 일부 개념과 설정 방식은 공유하지만 단순히 이름만 다른 관계는 아닙니다. 그래픽 클라이언트는 설정, 구독, 로컬 트래픽 처리, 로그 표시를 관리하고 코어는 실제 연결, 라우팅, 프로토콜 처리를 담당합니다. 화면에서 특정 서버 유형을 설정할 수 있다는 사실은 편집 기능을 제공한다는 뜻일 뿐입니다. 실제 동작은 실행 중인 코어가 처리해야 합니다.

PC에서는 설정 관리와 여러 플랫폼에서의 사용 방식이 한곳에서 관리하기에 적합해 v2rayN을 우선 추천합니다. 다만 실제 프로토콜 지원 여부는 선택한 코어를 확인해야 합니다. 안드로이드의 v2rayNG는 주로 Xray 기능을 지원하고, v2flyNG는 V2Fly 계열을 사용하는 대안입니다. 두 앱 중 하나를 고를 때는 먼저 서버가 요구하는 프로토콜과 확장 기능을 확인한 뒤 화면 사용 방식을 고려하세요. 같은 구독이 두 앱에 표시된다고 해서 모든 설정이 똑같이 실행된다는 뜻은 아닙니다.

공통 필드가 있다고 완전히 호환되는 것은 아닙니다

두 코어 계열 모두 인바운드, 아웃바운드, 라우팅, DNS 같은 상위 개념을 사용하고 같은 이름의 프로토콜을 지원할 수 있습니다. 하지만 확장 필드, 기본 동작, 전송 방식 지원에는 차이가 있습니다. Xray 계열의 REALITY, XTLS Vision 관련 기능이 JSON 형식과 비슷하다는 이유만으로 V2Fly에서 그대로 실행된다고 볼 수 없습니다. 반대 방향으로 이전할 때도 V2Fly 고유 설정과 클라이언트가 생성하는 형식을 확인해야 합니다. 가장 안전한 이전 방법은 설정 파일 전체를 복사하는 것이 아니라 각 필드의 의미를 확인하는 것입니다.

사용자 지정 설정과 그래픽 편집 화면은 적용되는 과정이 다를 수 있습니다. 클라이언트는 보통 화면에서 저장한 정보를 실행 설정으로 생성하며, 시작할 때 임시 파일을 덮어쓸 수도 있습니다. 생성된 파일을 직접 수정해도 다음 연결에서 변경 사항이 유지되지 않을 수 있습니다. 사용자 지정 설정을 계속 사용하려면 클라이언트가 공식적으로 제공하는 사용자 지정 설정 기능을 이용하고 시스템 프록시, 라우팅, DNS 중 어떤 기능을 여전히 화면에서 제어하는지 확인하세요. 그렇지 않으면 파일에 작성한 규칙과 실제로 불러온 규칙이 달라져 문제 해결 방향을 잘못 잡을 수 있습니다.

최소 설정 예시 읽기

아래는 Xray 형식의 라우팅 객체 일부로, 필드 계층을 보여 주기 위한 예시이며 실행 가능한 전체 설정은 아닙니다. domainStrategy는 라우팅 판단 과정에서 도메인을 처리하는 방식을 나타냅니다. 규칙은 순서대로 적용되며 outboundTag는 이미 정의된 아웃바운드 태그와 일치해야 합니다. 이 객체만으로 서버가 생성되거나 시스템 프록시가 자동으로 설정되지는 않습니다. 기존 설정에 적용하기 전 현재 코어가 해당 필드를 지원하는지, 클라이언트가 라우팅 설정을 다시 생성하는지 확인하세요. 유효한 규칙을 잘못된 위치에 붙여넣지 않도록 주의해야 합니다.

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

코어 업데이트는 클라이언트의 설정 생성 기능과 함께 살펴봐야 합니다. 업데이트로 프로토콜 필드가 추가되거나 호환성 처리가 바뀔 수 있지만, 서버에 없는 매개변수가 자동으로 채워지지는 않습니다. 시작 오류가 발생하면 가장 먼저 나타난 파싱 오류를 확인하고 예상한 코어가 실행 중인지 점검한 뒤 생성된 설정의 필드를 살펴보세요. 업데이트 전에는 작동했지만 이후 실패한다면 되돌릴 설정 사본을 보관하고 최소 설정으로 재현하세요. 오픈 소스는 코드 검토와 유지 관리의 기반이지 서로 다른 구현의 자동 호환성을 의미하지 않습니다. 클라이언트별 차이는 클라이언트 비교에서 확인하세요.

구독 및 공유 링크: 가져오기에 성공해도 모든 설정이 보존되는 것은 아닙니다

주소, 콘텐츠 형식, 연결 설정은 서로 다른 항목입니다

구독 주소는 보통 여러 서버 설정을 가져오는 데 사용하고, 단일 공유 링크는 특정 서버 설정 하나를 표현합니다. 구독은 나중에 업데이트할 수 있지만 공유 링크는 대개 생성 당시 매개변수의 스냅샷입니다. 구독 주소가 일반 웹 주소라고 해서 반환되는 콘텐츠가 웹페이지라는 뜻은 아니며, 모든 클라이언트가 해당 형식을 해석할 수 있다는 보장도 없습니다. 서버는 링크 목록, 인코딩된 텍스트, 특정 설정 형식으로 응답할 수 있습니다. 클라이언트가 해당 콘텐츠를 가져와 편집 가능한 서버 항목으로 변환하는 기능을 지원해야 합니다.

구독 다운로드가 성공했다는 것은 응답을 받았다는 뜻일 뿐입니다. 로그인 페이지, 오류 메시지, 호환되지 않는 콘텐츠가 반환되면 목록이 비어 있을 수 있습니다. 네트워크 요청 실패와 콘텐츠 파싱 실패를 먼저 구분한 뒤 네트워크 경로를 바꿀지 결정하세요. 일부 클라이언트에서는 구독 업데이트를 직접 연결로 보낼지 기존 프록시로 보낼지 선택할 수 있습니다. 현재 설정이 작동하지 않을 때 업데이트를 프록시로 강제하면 의존성 순환이 생길 수 있습니다. 설정을 바꾸기 전에 업데이트 방식과 사용 가능한 연결을 확인하고, 오류를 살펴보지 않은 채 라우팅을 바꾸며 같은 주소를 반복 요청하지 마세요.

링크 형식별로 누락될 수 있는 항목

VMess 공유 링크에는 인코딩된 구조화 데이터가 자주 사용됩니다. VLESS와 Trojan 링크는 일반적으로 주소 부분과 쿼리 매개변수로 설정을 표현하고, SS는 여러 인코딩 형식이 있습니다. 서버 이름, 경로, 서비스 이름에 특수 문자가 포함되면 형식에 맞는 이스케이프 처리가 필요합니다. 메신저가 줄바꿈을 넣거나 복사 과정에서 끝부분이 빠지거나 이중 인코딩이 발생하면 매개변수가 달라질 수 있습니다. 가져오기 도구가 일부 오류를 허용하더라도 결과 설정이 원래 의미와 같다는 보장은 없습니다. 가져온 뒤 핵심 항목을 확인하세요.

VLESS의 flow, REALITY의 공개 키와 shortId, TLS의 서버 이름, WebSocket의 Host와 경로는 특히 주의해서 확인해야 합니다. 변환 과정에서 프로토콜, 주소, 인증 정보만 보존하면 핸드셰이크를 결정하는 확장 항목이 빠질 수 있습니다. 노드 이름이 같은지만 비교하지 마세요. 노드 이름은 연결에 사용되지 않는 표시용 태그입니다. 가져오기 방식에 대한 자세한 내용은 공유 링크와 구독 주소의 차이를 참고하세요. 안내된 절차와 이 페이지의 설정 설명을 함께 활용할 수 있습니다.

구독 업데이트와 로컬 변경 사항은 따로 관리하세요

구독 관리는 보통 그룹 단위로 서버 항목을 업데이트하며, 어떤 로컬 변경 사항을 유지하는지는 클라이언트 동작에 따라 다릅니다. 구독에서 생성된 서버의 포트, 이름, 전송 매개변수를 직접 바꾸면 다음 업데이트 때 덮어써질 수 있습니다. 장기간 비교해야 한다면 항목을 로컬 설정으로 복사하고 용도를 표시하세요. 다만 서버 변경 사항을 직접 동기화해야 합니다. 라우팅 규칙과 앱별 적용 범위는 대개 로컬 정책이므로 구독 업데이트가 이를 수정해 줄 것이라고 가정해서는 안 됩니다. 변경할 때마다 어느 계층의 설정을 바꾸는지 확인하세요.

다른 클라이언트로 옮길 때는 원본 구독을 다시 가져온 뒤 확장 항목을 확인하세요. 특정 클라이언트의 전체 설정 파일을 범용 구독처럼 사용해서는 안 됩니다. PC의 시스템 프록시 포트, 안드로이드의 앱별 목록, 로컬 DNS 선택에는 기기별 설정이 포함되므로 이전 후 다시 설정해야 합니다. 실제 웹 요청과 필요한 UDP 앱을 각각 한 번 이상 테스트하고, 구독 업데이트를 반복해서 실행할 수 있는지도 확인하세요. 처음 한 번 연결에 성공했다고 해서 다음 구독 업데이트에서도 설정이 올바르게 변환된다는 뜻은 아닙니다.

사용 상황에 맞는 조합과 문제 해결: 조건을 먼저 확인하고 성능을 비교하세요

서버와 기기에 맞춰 사용할 조합을 정하세요

이미 사용할 수 있는 서버가 있다면 새 프로토콜로 바꾸기 위해 변경하기보다 서버에서 명시적으로 지원하고 검증된 조합을 유지하는 것이 우선입니다. PC에서 v2rayN을 사용할 때는 시스템 아키텍처와 설치 방법을 확인한 뒤 선택한 코어를 점검하세요. 안드로이드에서 REALITY나 Vision 같은 Xray 관련 기능이 필요하다면 v2rayNG의 해당 설정을 먼저 확인하세요. 기존에 V2Fly 설정을 사용 중이고 필요한 기능이 일치한다면 v2flyNG를 대안으로 고려할 수 있습니다. 설치 파일은 다운로드 센터에서 확인하세요. 프로토콜 가이드는 운영체제와 아키텍처 선택을 대신하지 않습니다.

짧은 페이지를 자주 열어야 한다면 연결 설정, DNS 조회, 첫 응답 대기 시간을 확인하세요. 장시간 전송에서는 지속 처리량, 패킷 손실, 기기 온도를 살펴보세요. 백그라운드 메시지 앱은 트래픽 처리 범위, 연결 복구, 시스템 백그라운드 제한이 더 중요할 수 있습니다. 여러 요구 사항을 설정 하나로 해결하려고 할 필요는 없습니다. 먼저 안정적인 기준 환경을 마련한 뒤 특정 앱에 맞춰 라우팅이나 앱별 적용 범위를 조정하면, 프로토콜과 전송 방식을 동시에 바꾸는 것보다 결과를 이해하기 쉽습니다.

연결 단계별로 실패 원인 찾기

코어가 시작되지 않으면 먼저 설정 파싱, 포트 충돌, 기능 지원 여부를 확인하세요. 이 단계에서는 원격 속도를 측정해도 의미가 없습니다. 코어는 시작되지만 연결을 맺지 못한다면 주소, 포트, 시스템 시간, 전송 매개변수를 점검하세요. 연결은 되지만 보안 핸드셰이크가 실패하면 서버 이름, 인증서, 공개 키, shortId, 인증 정보를 확인합니다. 로그에 요청을 전달한 뒤 대상이 응답하지 않는 것으로 나타난다면 서버 출구, 대상의 연결 가능성, DNS 결과를 살펴봐야 합니다. 모든 문제를 클라이언트의 가져오기 단계 탓으로 돌리지 마세요.

웹은 정상인데 일부 앱에서 문제가 생기면 먼저 해당 앱의 트래픽이 프록시로 들어오는지 확인한 뒤 라우팅과 UDP 요구 사항을 살펴보세요. PC 앱 중에는 시스템 프록시를 사용하지 않는 앱이 있고, 안드로이드에서는 앱별 제외 설정으로 직접 연결될 수도 있습니다. 코어에 들어온 뒤에도 규칙에 따라 direct 또는 block으로 처리될 수 있으므로 규칙 순서와 아웃바운드 태그를 함께 확인해야 합니다. DNS 응답 결과는 IP 기반 규칙의 판단에도 영향을 줄 수 있습니다. 도메인 처리 방식을 바꾸기 전에 적용 범위를 이해하고 DNS 선택과 프로토콜 인증을 혼동하지 마세요.

속도 저하와 연결 시간 초과는 서로 다른 기준으로 점검하세요

연결 시간 초과가 발생하면 우선 연결 자체를 맺을 수 있는지 확인하고 시스템 시간, 구독 유효성, 포트, 전송 방식, 코어 로그 순서로 살펴보세요. 속도가 느리다면 연결이 정상인 상태에서 서버 부하, 회선, 로컬 설정을 비교해야 합니다. 관련 점검 목록은 노드 연결 시간 초과 점검과 속도 저하 단계별 진단을 참고하세요. 두 문제가 함께 발생할 수 있지만 인증 실패를 반복적인 속도 테스트로 진단해서는 안 되며, 한 번 연결에 성공했다고 지속적인 혼잡이 없다고 단정해서도 안 됩니다.

나중에 확인할 수 있도록 클라이언트 이름, 실제 코어, 프로토콜 및 전송 조합, 오류 단계, 가장 최근에 바꾼 설정을 기록해 두세요. 접속 정보는 기록에 포함할 필요가 없습니다. 안정적인 상태로 복구되면 임시로 높였던 상세 로그 수준을 평소 설정으로 되돌리고 중복된 테스트 기록을 정리해 다음에 실수로 선택하지 않도록 하세요. 비슷한 문제가 다시 발생하면 기준 설정과 비교한 뒤 항목 하나만 바꾸세요. 일반적인 질문은 FAQ에서 확인하고 가져오기와 연결 확인을 다시 진행해야 한다면 시작 가이드를 참고하세요. 선택 기준은 언제나 프로토콜 이름이 아니라 전체 조합과 실제 요구 사항입니다.