V2Ray 프로토콜 및 코어 기술 가이드

연결 설정: 프로토콜, 전송 방식, 보안 계층

클라이언트의 연결 항목은 단순한 프로토콜 이름이 아닙니다. 원격 주소, 인증 정보, 프록시 프로토콜, 데이터를 전달하는 전송 방식, 연결을 보호하는 보안 계층을 함께 나타냅니다. 목록에 ‘VLESS’라고 표시되어도 이는 여러 계층 중 하나일 뿐입니다. 실제 연결 여부는 나머지 설정이 서버와 일치하는지에 달려 있습니다. 따라서 이름을 비교하기 전에 전체 설정 조합을 이해해야 합니다.

프록시 프로토콜은 연결 요청을 정의합니다

프록시 프로토콜은 클라이언트가 대상 주소를 전달하고, 접속 권한을 인증하며, 이후 데이터를 캡슐화하는 방식을 정합니다. VMess, VLESS, Trojan, Shadowsocks가 이 계층에 속하지만 인증과 암호화의 역할은 서로 다릅니다. 사용자 이름처럼 보이는 항목이라도 실제 자격 증명은 UUID일 수도, 비밀번호일 수도 있습니다. 모두 ‘사용자’ 입력란에 표시된다고 서로 바꿔 쓸 수 있는 것은 아닙니다.

원격 서버 주소는 최종적으로 접속할 웹사이트 주소와 다릅니다. 클라이언트는 먼저 프록시 서버에 연결한 다음, 프로토콜을 통해 서버에 접속 대상 주소를 전달합니다. 문제를 진단할 때는 이 두 구간을 구분해야 합니다. 클라이언트와 서버 사이의 연결이 실패했다면 주소, 포트, 핸드셰이크부터 확인하세요. 특정 대상에만 접속할 수 없다면 라우팅, 이름 확인, 대상 서버 상태도 점검해야 합니다. 두 단계를 혼동하면 프로토콜 전체가 작동하지 않는다고 잘못 판단하기 쉽습니다.

전송 방식은 데이터가 전달되는 경로를 정합니다

TCP, WebSocket, gRPC 같은 전송 방식은 프록시 데이터를 하위 연결을 통해 전달하는 방법을 정합니다. TCP는 비교적 직접 데이터를 전달하고, WebSocket은 업그레이드 핸드셰이크와 메시지 프레임을 추가합니다. gRPC는 HTTP/2 통신 방식을 사용합니다. WebSocket과 gRPC는 기존 리버스 프록시 환경에서 자주 쓰이지만, 경로·서비스 이름·전달 규칙 등 중간 계층과 맞춰야 할 조건이 늘어납니다. 그렇다고 직접 연결보다 항상 빠른 것은 아닙니다.

클라이언트에 표시되는 ‘경로’, ‘Host’, ‘서비스 이름’은 노드 메모가 아니라 전송 계층의 설정인 경우가 많습니다. WebSocket 경로는 서버 및 중간 전달 규칙과 일치해야 하고, gRPC 서비스 이름도 임의로 입력하면 안 됩니다. 일부 입력란을 비워 둘 수 있는 것은 특정 조합에서 기본값이 적용되기 때문이지, 모든 서버가 빈 값을 허용한다는 뜻은 아닙니다. 확실하지 않다면 가져온 값을 유지하고 설정 제공자에게 각 항목의 의미를 확인하세요.

연결 다중화는 별도로 판단해야 합니다. 여러 트래픽이 하위 연결을 공유해 연결을 반복해서 만드는 비용을 줄이는 기능이지만, 혼잡의 영향을 키우거나 특정 전송 방식과 기능이 중복될 수도 있습니다. 다중화를 항상 켜 두는 것을 보편적인 최적화로 여기지 마세요. 먼저 서버에서 권장하는 기본 설정으로 안정성을 확인한 다음, 다중화 적용 전후의 첫 페이지 로딩, 장시간 연결, 동시 요청 결과를 따로 비교해야 의미 있는 결론을 얻을 수 있습니다.

보안 계층과 애플리케이션 자체 암호화는 구분하세요

TLS는 클라이언트와 프록시 서버 사이의 연결을 암호화하고 서버 신원을 확인합니다. REALITY는 양쪽 설정이 맞아야 하는 별도의 보안 계층입니다. 둘 다 VLESS와 나란히 놓고 바꿔 쓸 수 있는 프록시 프로토콜은 아닙니다. 웹사이트에 접속할 때 사용하는 HTTPS는 프록시 연결 안쪽에 있습니다. 바깥쪽 보안 계층은 클라이언트와 프록시 서버의 통신을 보호하고, 안쪽 HTTPS는 브라우저와 웹사이트 사이의 데이터를 보호합니다. 두 계층은 보호 범위가 다릅니다.

시스템 프록시, Tun 모드, 라우팅 규칙은 로컬 연결 방식과 트래픽 경로를 결정합니다. 시스템 프록시가 켜져 있어도 모든 앱이 이를 따르는 것은 아닙니다. Tun은 더 넓은 범위의 트래픽을 처리하지만 라우팅과 권한의 영향을 받습니다. 프로토콜 설정이 맞는데 브라우저가 프록시를 사용하지 않는 문제와 핸드셰이크 매개변수 오류는 서로 다른 문제입니다. 이 페이지의 이후 비교는 트래픽이 이미 클라이언트로 들어오고 서버 설정을 알고 있다는 전제에서 진행합니다. 연결 방식의 차이를 프로토콜 성능으로 혼동하지 않도록 유의하세요.

VMess와 VLESS: 인증과 암호화의 역할

VMess는 Project V 초기 발전 과정에서 인증, 요청 정보 전달, 데이터 보호 등의 역할을 맡았습니다. VLESS는 더 간결한 프로토콜 구조를 택하고 보안은 주로 함께 사용하는 보안 계층에 맡깁니다. 둘 다 사용자 식별에 UUID를 사용하는 경우가 많고 그래픽 클라이언트의 추가 메뉴에도 표시되지만, 설정 항목이 비슷하다고 연결을 서로 호환할 수 있는 것은 아닙니다. 서버가 VMess를 받도록 설정되어 있다면 클라이언트에서 드롭다운만 바꿔 VLESS로 전환할 수 없습니다.

VMess의 무결성 및 호환성 범위

최신 VMess 설정은 일반적으로 AEAD 인증 방식을 사용합니다. 오래된 설정에는 alterId 같은 과거 인증 관련 매개변수가 남아 있을 수도 있습니다. 예전 공유 정보를 가져왔다면 서버가 실제로 어떤 인증 방식을 쓰는지 확인하고, 오래된 매개변수를 모든 노드에 공통으로 적용하지 마세요. 현재 흔히 쓰이는 AEAD 설정에서는 사용자가 별도의 사용자 번호를 추가할 필요가 없는 경우가 많습니다. 구체적인 항목은 가져온 설정과 서버 안내를 기준으로 확인하세요.

VMess의 보안 옵션은 프로토콜 자체의 데이터 암호화 방식을 뜻하며, 전송 설정의 TLS 옵션과 혼동하면 안 됩니다. ‘자동’은 보통 코어가 지원되는 방식 중 적절한 방법을 선택한다는 뜻이지, 암호화가 없다는 뜻이 아닙니다. 서버가 특정 방식을 제한한다면 해당 설정을 따라야 합니다. 호환성 문제를 해결할 때는 여러 암호화 옵션을 무작정 바꾸기보다 제공자가 안내한 값을 먼저 복원하세요.

시스템 시간도 확인해야 합니다. VMess의 인증 처리에는 시간 정보가 사용되므로 기기의 시계가 크게 어긋나면 네트워크 시간 초과처럼 보이는 인증 실패가 발생할 수 있습니다. 시스템에서 자동 시간 설정을 켠 뒤 다시 시도하는 편이 UUID를 계속 바꾸는 것보다 효과적입니다. 같은 설정이 다른 기기에서는 작동한다면 양쪽 기기의 시간, 코어 선택, 전송 설정을 하나씩 비교해 차이를 좁히세요. 연결 항목을 전부 새로 만들 필요는 없습니다.

VLESS가 가볍다고 해서 보안이 독립적으로 제공되는 것은 아닙니다

VLESS의 기본 설계는 VMess처럼 일반적인 데이터 암호화를 제공하지 않으므로, 실제 배포에서는 TLS나 REALITY와 함께 사용하는 경우가 많습니다. 클라이언트의 encryption 항목에 흔히 표시되는 none은 해당 프로토콜 필드를 설명할 뿐, 연결 전체가 안전하지 않다는 뜻은 아닙니다. 보안 계층이 활성화되어 있는지, 서버 신원을 어떻게 확인하는지도 살펴봐야 합니다. 한 가지 필드만 보고 연결 보안을 판단하면 중요한 맥락을 놓치게 됩니다.

VLESS 설정의 flow는 속도 단계가 아닙니다. 예를 들어 xtls-rprx-vision은 구체적인 흐름 제어 방식을 뜻하며 서버, 코어, 연결 조합이 모두 지원해야 합니다. 서버에 해당 구성이 없는데 클라이언트에서 임의로 입력하면 통신이 바로 실패할 수 있습니다. 반대로 서버에서 해당 방식을 요구하는데 가져온 설정에서 필드가 빠졌다면 일반 TLS 옵션을 켜는 것으로 해결할 수 없습니다.

VLESS를 선택하는 실질적인 이유는 대개 기존 서버가 TLS 또는 REALITY와의 특정 조합을 사용하고, 클라이언트 코어가 이를 온전히 지원하기 때문입니다. ‘프로토콜 이름이 더 새것이니 무조건 빠르다’는 이유로 선택하는 것은 적절하지 않습니다. 프로토콜 처리 단계가 적으면 일부 오버헤드를 줄일 수 있지만, 실제 경로와 전송 방식, 기기의 암호화 성능, 동시 접속 부하도 영향을 줍니다. 안정적으로 작동하는 VMess 설정을 옮기려면 호환성이나 유지 관리 측면의 분명한 목적이 있어야 합니다.

클라이언트에서 두 프로토콜의 설정 확인하기

v2rayN에서 연결 항목을 가져온 뒤 편집 화면을 열어 프로토콜, 서버, 포트, UUID를 먼저 확인하고 전송 방식, 보안 계층, 고급 설정을 살펴보세요. 노드 메모는 자유롭게 바꿀 수 있지만 인증 식별자를 임의로 수정하면 안 됩니다. v2rayNG에서도 같은 순서로 확인하고, 특히 고급 설정에 접혀 있는 서버 이름과 flow를 살펴보세요. 저장한 다음 연결을 테스트해 목록에 남아 있는 이전 설정을 실제로 사용하고 있지는 않은지 확인하세요.

설정을 가져온 직후 연결이 실패한다면 로그를 확인해 어느 단계에서 문제가 생겼는지 살펴보세요. 서버 연결 자체가 되지 않으면 네트워크와 포트를 먼저 확인하고, 핸드셰이크 단계에서 거부되면 인증, 보안 계층, flow를 점검하세요. 연결은 되었지만 특정 대상에만 문제가 있다면 라우팅과 이름 확인을 살펴봐야 합니다. 추가 설정 차이는 4가지 프로토콜의 사용 환경별 비교에서 확인할 수 있습니다. 첫 진단부터 모든 옵션을 동시에 바꾸지는 마세요.

Trojan과 Shadowsocks: 서로 다른 보안 설계

Trojan과 Shadowsocks는 같은 노드 목록에 함께 표시되는 경우가 많지만 인증과 암호화를 처리하는 방식은 다릅니다. 일반적인 Trojan 사용 방식은 TLS로 보안 채널을 만든 뒤 그 안에서 프록시 요청과 비밀번호 인증을 처리합니다. Shadowsocks는 공유 비밀 정보와 선택한 암호화 방식을 사용해 프록시 통신을 보호합니다. 두 프로토콜 모두 화면에 ‘비밀번호’가 표시된다는 이유만으로 선택하지 말고 전체 배포 방식을 비교하세요.

Trojan은 TLS 설정이 핵심입니다

Trojan의 비밀번호는 접속 자격 증명이며, 서버 이름과 인증서 검증은 서버 신원을 확인합니다. 두 설정이 모두 필요합니다. 비밀번호가 맞더라도 인증서 이름이 일치하지 않으면 연결이 실패해야 합니다. 반대로 인증서가 신뢰할 수 있어도 비밀번호가 틀리면 정상적인 프록시 세션을 만들 수 없습니다. 제공자가 도메인을 안내했다면 해당 이름이 보안 계층 설정에도 반영되어 있는지 확인하세요. 서버 주소를 숫자 주소로 바꿨다고 나머지 설정을 그대로 둬도 되는 것은 아닙니다.

일반적인 Trojan은 TCP와 TLS를 조합하지만 코어나 서버 구현에 따라 다른 전송 방식이 추가될 수도 있습니다. 같은 Trojan 표시가 보인다고 전송 방식까지 같다고 단정할 수 없습니다. 설정에 WebSocket 경로나 다른 확장 항목이 있다면 현재 코어가 해당 구현을 지원하는지 확인해야 합니다. trojan:// 접두사를 인식하는 것만으로 가져오기 도구가 모든 확장 정보를 보존했다고 볼 수는 없습니다.

TLS 핸드셰이크가 실패한다면 시스템 시간, 서버 이름, 인증서 신뢰 체인부터 확인한 다음 중간 전달 계층이 실제로 연결을 대상 서버로 넘기는지 살펴보세요. 테스트를 통과시키려고 인증서 검증을 계속 꺼 두면 안 됩니다. 검증을 끄면 신뢰할 수 있는 서버와 다른 엔드포인트를 구분하는 기능이 약해지므로, 테스트가 성공해도 설정이 올바르다고 할 수 없습니다. 이름과 인증서가 일치하도록 수정하는 것이 안정적인 해결 방법입니다.

Shadowsocks의 암호화 방식 이름은 정확히 일치해야 합니다

Shadowsocks는 다양한 암호화 방식과 함께 발전해 왔습니다. 최신 배포에서는 AEAD 방식이 흔히 쓰이며, 키 요구 사항이 다른 새로운 암호화 방식도 있습니다. 클라이언트는 서버에서 사용하는 방식과 해당 자격 증명 형식을 모두 지원해야 합니다. 방식 이름, 키 인코딩, 비밀번호 문자열은 모두 연결 설정이므로 이름이 비슷해 보인다는 이유로 바꿔 쓸 수 없습니다. 같은 서버 주소에서도 인증 설정은 완전히 다를 수 있습니다.

기존의 비밀번호 기반 키 파생 설정에서는 비밀번호 문자열로 실제 키를 생성합니다. 일부 최신 방식은 정해진 길이로 인코딩된 키를 요구할 수 있습니다. 두 경우 모두 비밀번호 입력란에 표시되지만 의미는 다릅니다. 복사할 때 앞뒤 공백, 줄바꿈, 인코딩 문자를 특히 주의하세요. 형식 오류가 표시되면 클라이언트가 저장을 허용할 때까지 문자를 지우지 말고, 해당 방식의 입력 요건을 먼저 확인해야 합니다.

Shadowsocks에서 UDP를 사용하려면 연결 전체가 이를 지원해야 합니다. 서버의 UDP 활성화 여부, 네트워크 경로의 허용 여부, 클라이언트의 로컬 연결 방식에서 UDP를 전달하는지 모두 실제 사용 결과에 영향을 줍니다. 웹페이지가 열린다고 일부 TCP 통신만 정상임을 확인할 수 있을 뿐, 실시간 통신이나 다른 UDP 서비스도 작동한다고 단정할 수는 없습니다. 특정 앱에서만 문제가 생기면 암호화 방식을 바꾸기보다 먼저 해당 앱의 트래픽 유형과 경로를 확인하세요.

설정의 간결함과 유지 관리 비용을 함께 비교하세요

Shadowsocks는 일반적으로 설정 항목이 적어 익숙한 환경에 배포하기 편하지만 플러그인이나 확장 기능을 추가하면 호환성 범위가 달라집니다. 공유 링크에 확장 매개변수가 있다면 세 클라이언트의 실제 코어와 화면에서 이를 지원하는지 확인하세요. 플러그인 설정을 일반 메모처럼 무시하면 안 됩니다. Trojan은 인증서와 도메인 관련 유지 관리가 더 필요할 수 있지만, 그만큼 널리 쓰이는 TLS 신뢰 체계를 바탕으로 서버 신원을 확인합니다.

선택 표에서 Shadowsocks를 항상 ‘가장 빠름’, Trojan을 항상 ‘느림’으로 표시하는 것은 비교 조건이 갖춰지지 않은 평가입니다. 하드웨어 가속을 지원하는 알고리즘, 연결 다중화 여부, 서버 부하, 실제 네트워크 경로에 따라 결과가 달라집니다. 데스크톱에서 일상적으로 사용한다면 설정이 완전하고 서버 관리가 명확하며 지속적으로 업데이트되는 구성을 우선하세요. 모바일 기기에서는 같은 작업을 수행하면서 백그라운드 연결 유지와 배터리 사용량을 비교하세요.

이미 사용하는 Trojan 또는 Shadowsocks 설정이 안정적으로 작동한다면 목록의 프로토콜 이름을 통일하기 위해 바꿀 필요는 없습니다. 이전 방식의 지원이 중단되거나 서버 설정이 바뀌었거나 현재 조합으로 필요한 기능을 제공할 수 없는 경우에 마이그레이션을 고려하세요. 새 설정을 추가해 검증한 뒤 기존 설정을 비활성화하고 비교용으로 남겨 두세요. 자격 증명 변경과 클라이언트 설정 변경을 동시에 적용하면 문제 원인을 파악하기 어렵습니다.

TLS와 REALITY: 서버 신원 및 핸드셰이크 설정

TLS와 REALITY는 클라이언트의 ‘보안’ 또는 비슷한 메뉴에서 자주 볼 수 있습니다. 최종 접속 대상 웹사이트를 고르는 기능이 아니라, 클라이언트와 프록시 서버 사이에 보호된 연결을 설정하는 방식입니다. 일반적인 VLESS 설정은 둘 중 하나와 조합할 수 있고, Trojan의 일반적인 배포도 TLS를 사용합니다. 보안 계층 설정은 서버와 일치해야 하며 클라이언트에서 임의로 켜는 부가 기능이 아닙니다.

TLS의 이름, 인증서, 주소

TLS 연결에서는 실제 접속 주소, 핸드셰이크에 사용하는 서버 이름, 인증서에 명시된 이름을 혼동하기 쉽습니다. 접속 주소는 데이터가 전송될 곳을 결정합니다. 서버 이름은 보통 SNI에 사용되어 핸드셰이크에 참여하고 서버 신원을 확인하는 데 쓰입니다. 세 이름이 달라도 서버 배포 설계에 따른 합리적인 차이라면 문제가 없습니다. 하지만 주소만 다른 서버로 바꾸고 기존 이름을 유지한다고 연결이 자동으로 작동하지는 않습니다.

인증서 검증에는 신뢰 관계, 유효 기간, 이름 일치 여부 등이 포함됩니다. 시스템 시간이 잘못되면 유효 기간 판단에 문제가 생길 수 있고, 인증서 체인이 불완전하면 일부 기기에서만 오류가 드러날 수 있습니다. 설정을 복사하거나 주소를 직접 수정한 뒤에는 이름 불일치가 흔히 발생합니다. 이런 문제를 검증 해제로 감추면 안 됩니다. 먼저 제공된 도메인과 기기 시간을 확인한 뒤 클라이언트가 실제로 사용하는 서버 이름을 점검하면 문제를 더 명확히 진단할 수 있습니다.

ALPN은 애플리케이션 계층 프로토콜을 협상합니다. 입력 여부와 값은 전송 방식 및 서버 설계에 따라 달라집니다. gRPC 같은 조합은 HTTP/2가 필요하지만 일반 연결에서는 직접 지정할 필요가 없을 수 있습니다. 다른 노드의 ALPN 목록을 복사하면 정상 핸드셰이크가 설정 불일치로 실패할 수 있습니다. 클라이언트에서 수정할 수 있는 항목이 많다고 해서 모든 항목을 직접 설정해야 하는 것은 아닙니다.

REALITY에는 서로 맞춰야 하는 설정이 있습니다

REALITY는 일반적인 인증서 배포와 다른 검증 방식을 사용하며, Xray를 사용하는 연결 조합에서 자주 볼 수 있습니다. 클라이언트에는 보통 서버 이름, 서버가 제공한 검증 정보, short ID 등이 필요합니다. 클라이언트와 코어에 따라 항목 이름은 다를 수 있습니다. 서버의 개인 키는 서버에만 보관해야 합니다. 클라이언트에 가져오는 것은 검증에 필요한 정보이며, 서버 설정의 모든 키를 클라이언트에 복사해서는 안 됩니다.

short ID는 노드 번호도, 임의로 만들어 넣는 메모도 아닙니다. 서버에서 허용하는 값과 일치해야 하며 형식은 설정 제공자에게 확인해야 합니다. 서버 이름도 서버 설정에 맞아야 하므로 흔히 쓰이는 도메인을 아무거나 입력해도 작동하는 것은 아닙니다. 지문 설정은 핸드셰이크 특성을 흉내 내는 방식을 뜻하며 대상 웹사이트의 신원을 나타내지 않습니다. 지문, 서버 이름, 주소는 각각 다른 역할을 합니다.

VLESS, REALITY, Vision의 일반적인 조합에서는 flow와 보안 계층 설정을 함께 확인해야 합니다. 그렇다고 모든 REALITY 연결에 같은 flow를 무조건 입력해야 하는 것은 아닙니다. 클라이언트가 지원하는지, 전송 방식이 적합한지, 서버가 해당 항목을 요구하는지 각각 확인해야 합니다. 가져오기 도구가 프로토콜은 인식했지만 보안 계층 설정을 누락하면 목록은 완전해 보여도 실제 핸드셰이크는 실패합니다. 노드 메모만 보는 것보다 편집 화면에서 설정을 확인하는 편이 정확합니다.

핸드셰이크 단계에서 문제 원인 찾기

로그에서 하위 연결이 성립한 직후 연결이 종료된 것으로 나타난다면 일반 TLS의 인증서 검증 실패인지, REALITY 매개변수 검증 실패인지 구분하세요. 전자는 서버 이름, 시간, 신뢰 체인을 확인하고 후자는 검증 정보, short ID, 서버 이름, 코어 지원 여부를 확인해야 합니다. 두 문제 모두 화면에는 단순한 연결 실패로 표시될 수 있으므로 로그의 구체적인 오류를 펼쳐 봐야 어느 계층을 수정할지 알 수 있습니다.

REALITY가 로컬 DNS, 시스템 프록시, 앱 자체의 인증서 문제를 자동으로 해결해 주는 것은 아닙니다. 특정 웹사이트에서만 앱 계층 인증서 오류가 발생한다면 브라우저와 웹사이트 사이의 안쪽 TLS 문제인지, 클라이언트와 서버 사이의 바깥쪽 핸드셰이크 문제인지 먼저 구분하세요. REALITY를 사용한다는 이유만으로 모든 인증서 오류나 이름 확인 문제를 같은 원인으로 취급해서는 안 됩니다. 연결 단계를 나눠 살펴봐야 올바른 보안 계층의 설정을 반복해서 바꾸지 않을 수 있습니다.

Project V, V2Fly, Xray: 코어와 인터페이스의 역할

V2Ray는 기술 생태계를 가리키는 말로 쓰이기도 하고, 구체적인 프로그램이나 설정 이름에 등장하기도 합니다. Project V는 이 생태계를 이해하는 배경을 제공하고, V2Fly는 V2Ray 커뮤니티의 발전을 이어 왔으며, Xray는 별도의 코어 분기로 발전했습니다. 공통된 역사와 설정 개념이 일부 있지만 기능은 각자 다른 방향으로 발전했습니다. 설정의 실행 가능 여부는 이름에 V2Ray가 포함되어 있는지가 아니라 실제 코어의 지원 여부로 판단해야 합니다.

클라이언트가 설정을 관리하고 코어가 연결을 처리합니다

그래픽 클라이언트는 구독 관리, 노드 편집, 시스템 프록시 설정, 로그 표시 등을 담당하고 코어에 설정을 전달해 실행합니다. 코어는 실제 프로토콜 해석, 연결, 보안 계층, 라우팅 등을 처리합니다. 화면에서 저장이 완료된 것은 입력값이 로컬 검사를 통과했다는 뜻일 뿐, 코어가 모든 매개변수를 받아들였다는 의미는 아닙니다. 특정 링크를 가져올 수 있다고 해서 현재 선택한 코어가 링크의 모든 확장 항목을 지원한다는 뜻도 아닙니다.

데스크톱에서는 Windows, macOS, Linux에서 사용할 수 있는 v2rayN을 우선 추천합니다. 실제 사용할 수 있는 코어와 기능은 설치한 배포 패키지와 클라이언트 지원 여부에 따라 달라지므로 다른 플랫폼의 화면에 같은 메뉴가 있다고 단정하지 마세요. Windows의 데스크톱 버전과 클래식 WPF 버전은 주로 인터페이스 기술과 조작 방식이 다릅니다. ‘클래식’이 오래된 프로토콜만 지원한다거나 ‘데스크톱 버전’에서 모든 기능을 자동으로 사용할 수 있다는 뜻은 아닙니다.

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 추천하며, V2Fly 코어를 사용하는 v2flyNG를 대안으로 고려할 수 있습니다. 두 클라이언트에서 사용할 수 있는 설정 출처가 겹칠 수는 있지만 앱 이름만 바꾼다고 모든 설정을 지원하는 것은 아닙니다. 특히 REALITY, 특정 flow, 코어 확장 기능을 사용하는 경우 지원하는 코어를 먼저 확인하세요. 설정이 Xray의 특정 구현에 의존한다면 비슷한 입력 화면이 있다는 이유만으로 다른 코어에서도 작동하리라 기대할 수 없습니다.

호환된다고 해서 설정 전체를 그대로 바꿔 쓸 수 있는 것은 아닙니다

V2Fly와 Xray는 일반적인 인바운드, 아웃바운드, 라우팅 등에서 비슷한 개념을 사용하며 일부 간단한 설정은 이전할 수 있습니다. 하지만 보안 계층, 전송 구현, 필드 값, 확장 기능은 다를 수 있습니다. 두 프로그램 모두 JSON을 읽는다고 해도 파일 문법이 같다는 뜻일 뿐, 설정의 의미까지 같은 것은 아닙니다. 그래픽 클라이언트가 생성한 실행 설정에는 로컬 경로나 내부 태그가 포함될 수 있으므로 다른 클라이언트에서 가져오기 파일로 바로 사용하지 않는 것이 좋습니다.

마이그레이션이 필요하다면 먼저 프로토콜, 전송 방식, 보안 계층, 흐름 제어, 이름 확인에 필요한 기능을 정리하고 대상 코어가 각 기능을 지원하는지 확인하세요. 서버 주소와 사용자 식별 정보는 비교적 옮기기 쉽지만 코어 전용 필드에는 새 설정 안내가 필요합니다. 실행 로그에서 매개변수를 다시 조합하기보다 원본 공유 정보를 보관하고 기준으로 삼는 편이 안전합니다. 서버도 변경해야 한다면 클라이언트만 따로 바꾸지 말고 양쪽 설정을 함께 갱신해야 합니다.

업데이트 후 기능 변경 및 회귀 여부 확인

클라이언트 업데이트와 코어 업데이트는 관련이 있지만 같은 작업은 아닙니다. 새 인터페이스에서 구독 해석 문제가 해결될 수도 있고, 코어 업데이트로 필드 검증이나 프로토콜 구현이 달라질 수도 있습니다. 둘 다 기존 설정에 영향을 줄 수 있습니다. 업데이트 전에 현재 사용 중인 항목, 연결 모드, 주요 라우팅 설정을 기록하고 업데이트 후 기존 기본 설정을 먼저 검증하세요. 코어, 전송 방식, 라우팅을 한 번에 바꾸면 문제가 생겼을 때 원인을 찾기 어렵습니다.

로그에 알 수 없는 필드, 잘못된 flow, 지원하지 않는 보안 유형이 표시된다면 고급 설정을 전부 지우기 전에 코어를 잘못 선택했는지, 설정 출처가 현재 클라이언트와 맞는지 먼저 확인하세요. 필드를 지우면 프로그램은 실행될 수 있어도 연결 설정의 의미가 달라질 수 있습니다. 생태계에 관한 자세한 내용은 Project V와 클라이언트 계열 안내를 참고하세요. 설치 파일 형식은 다운로드 페이지에서 확인할 수 있습니다. 이 프로토콜 가이드에서 별도의 클라이언트 종류를 추가로 다루지는 않습니다.

속도, 리소스 사용량, 모바일 배터리

프로토콜 성능은 빠른 순서대로 고정된 순위를 매길 수 없습니다. 같은 프로토콜도 전송 방식, 보안 계층, 서버 배포 방식에 따라 달라지며, 그 차이가 프로토콜 간 평균 오버헤드보다 클 수 있습니다. 비교하기 전에 사용 목적부터 정하세요. 웹페이지 첫 로딩은 연결 수립과 이름 확인이 중요하고, 지속 다운로드는 안정적인 처리량이 중요하며, 실시간 통신은 지연 변동과 패킷 손실이 중요합니다. 이 경험들을 하나의 테스트 수치로 합치면 서로 모순되는 결론을 얻기 쉽습니다.

첫 연결 시간과 지속 전송 속도는 따로 측정하세요

웹페이지를 한 번 열 때 로컬 연결, 이름 확인, 프록시 서버 연결, 보안 핸드셰이크를 거친 다음 대상 웹사이트 연결과 앱 응답이 이어질 수 있습니다. WebSocket, gRPC 또는 다른 중간 전달 방식을 추가하면 관련 협상과 처리 과정도 늘어납니다. 프로토콜 자체의 처리 부담이 적어도 불안정한 연결이나 바쁜 원격 서버의 영향을 상쇄하지는 못합니다. 반대로 이미 연결이 성립되어 재사용되는 경우만으로 초기 연결 비용을 모두 설명할 수도 없습니다.

클라이언트의 TCPing은 주로 서버 포트에 연결할 수 있는지 확인하는 데 쓰입니다. 실제 연결 테스트는 보통 프록시 경로를 통해 테스트 대상에 요청하지만, 결과는 테스트 주소와 구현 방식에 영향을 받습니다. 둘 다 지속적인 다운로드 속도를 측정하는 것은 아닙니다. 노드의 TCPing은 정상이지만 실제 연결이 실패한다면 인증, 보안 계층, 대상 접속 단계에 문제가 있을 수 있습니다. 이를 근거로 ‘프로토콜이 느리다’고 판단하지 말고 먼저 연결이 가능한지 확인하세요.

공정하게 비교하려면 같은 기기, 네트워크, 대상, 연결 방식을 사용하고 테스트 순서를 바꿔 가며 여러 시간대에 반복하세요. 서버 지역과 프로토콜을 동시에 바꾸면 결과 차이가 프로토콜 때문인지 알 수 없습니다. 최저 수치 하나를 찾기보다 웹페이지 첫 방문, 재방문, 장시간 전송의 결과를 각각 기록하는 편이 유용합니다. 자세한 확인 절차는 첫 연결 및 프록시 적용 확인을 참고하세요.

CPU, 메모리, 연결 수가 함께 영향을 줍니다

암호화 처리 부담은 알고리즘과 프로세서 성능에 따라 달라집니다. 일부 기기는 특정 알고리즘의 하드웨어 가속을 지원하므로 다른 아키텍처에서는 결과가 달라질 수 있습니다. TLS, 프로토콜 자체 암호화, 데이터 복사, 전송 캡슐화 모두 처리 자원을 쓸 수 있지만 특정 계층이 항상 병목이라고 단정할 수는 없습니다. 부하가 적은 웹 서핑에서는 차이가 잘 드러나지 않다가 동시 연결이 많거나 장시간 데이터를 전송할 때 CPU 사용량 증가가 보일 수 있습니다.

메모리 사용량은 연결 수, 버퍼, 규칙 목록, DNS 캐시, 로그 양에도 영향을 받습니다. 대규모 라우팅 규칙으로 늘어난 리소스 사용량을 VMess나 VLESS 탓으로만 돌릴 수는 없습니다. 클라이언트 리소스 사용량을 확인하려면 같은 규칙과 로그 설정을 유지한 채 유휴 상태, 일상적인 웹 서핑, 지속 전송 상태를 비교하세요. 같은 작업 부하에서 재현되는 결과여야 의미를 해석할 수 있습니다.

다중화는 일부 연결 수립 비용을 줄이지만 모든 작업의 처리량을 높이는 것은 아닙니다. 공유 연결에서 패킷 손실이나 혼잡이 발생하면 여러 작업이 동시에 영향을 받을 수 있습니다. 일부 전송 방식은 이미 다중 연결 기능을 제공하므로 다중화를 추가하면 복잡성만 커질 수도 있습니다. 기본 설정이 안정적으로 작동한다면 그대로 유지하세요. 시험해 보고 싶다면 한 번에 옵션 하나만 변경하고 웹페이지 한 번 열어 보는 데 그치지 말고 짧은 연결과 긴 연결을 모두 확인하세요.

모바일 배터리 소모는 연결 자체만의 문제가 아닙니다

모바일 기기의 무선 신호, 화면, 백그라운드 앱, 시스템 스케줄링은 모두 배터리 사용량에 영향을 줍니다. 연결이 자주 끊겨 재연결하거나 짧은 주기로 연결을 유지하거나 네트워크를 전환하면 무선 모듈이 오랫동안 활성 상태로 남을 수 있습니다. 프로토콜 처리 부담이 적더라도 재연결이 잦으면 배터리를 절약하지 못할 수 있습니다. 따라서 프로토콜 이름만 보고 ‘절전 모드’라고 판단하지 마세요. 연결이 안정적인지, 시스템이 백그라운드 앱을 반복해서 종료하는지, 재시도가 계속 발생하는지 확인해야 합니다.

v2rayNG 또는 v2flyNG에서 배터리 사용량을 비교할 때는 연결 범위, 규칙, 화면 밝기, 백그라운드 앱을 가능한 한 동일하게 유지하세요. 대기 상태와 실제 사용 상태를 따로 관찰하고 지속 다운로드와 유휴 대기를 함께 비교하지 마세요. 백그라운드 실행이 필요한 정도에 맞춰 시스템의 배터리 최적화 설정을 조정해야 합니다. 지속 실행을 허용하면 연결 유지에는 도움이 되지만 클라이언트가 더 오래 트래픽을 처리할 수 있으므로 실제 사용 환경을 고려해 선택하세요.

모바일 네트워크에서만 배터리 소모가 두드러지면 신호 품질과 네트워크 전환을 먼저 확인하세요. 특정 노드에서만 재연결이 잦다면 경로와 서버를 살펴보고, 모든 항목이 백그라운드에서 끊기면 시스템 제한을 확인하세요. 문제 해결의 목표는 불필요한 깨우기와 재시도를 줄이는 것이지 배터리를 아끼려고 보안 계층을 제거하는 것이 아닙니다. 재현되지 않는 짧은 배터리 변화는 관찰을 이어 가고, 이를 근거로 프로토콜 전반에 대한 결론을 내리지 마세요.

공유 링크와 구독: 형식 호환성이 연결 호환성을 보장하지는 않습니다

공유 링크는 보통 연결 하나의 설정을 나타내고, 구독 주소는 여러 설정을 가져오거나 업데이트하는 데 사용됩니다. 클립보드에서 가져올 수 있다는 점은 같지만 클라이언트가 수행하는 작업은 다릅니다. 공유 링크는 매개변수를 해석하고, 구독은 먼저 콘텐츠를 요청한 다음 응답 형식을 인식합니다. 가져오기는 요청, 디코딩, 필드 매핑, 코어 실행 등 어느 단계에서든 실패할 수 있습니다. 실패 지점을 먼저 파악해야 주소, 형식, 프로토콜 지원 중 무엇을 확인할지 알 수 있습니다.

접두사가 같아도 필드가 다를 수 있습니다

일반적인 VMess 공유 링크는 인코딩된 구조화 데이터를 사용합니다. VLESS와 Trojan은 쿼리 매개변수가 있는 URI를 주로 사용하고, Shadowsocks는 별도의 사용자 정보 인코딩 규칙이 있습니다. 링크 생성 도구마다 확장 필드와 기본값을 처리하는 방식이 다를 수 있습니다. 클라이언트가 접두사를 인식했다는 것은 입력 형식을 알아봤다는 뜻일 뿐입니다. flow, 보안 계층, 지문 등의 값이 제대로 매핑됐는지는 편집 화면에서 확인해야 합니다.

URI의 특수 문자는 올바르게 인코딩해야 합니다. 메모의 공백, 비밀번호의 기호, 매개변수 값의 구분 문자는 복사하거나 전달하는 과정에서 바뀔 수 있습니다. 브라우저가 자동으로 디코딩해 표시한 텍스트를 그대로 다시 조합하는 것은 적절하지 않을 수 있습니다. 원본 전체 링크를 복사하고 불필요해 보이는 퍼센트 기호나 등호를 임의로 삭제하지 마세요. QR 코드로 가져온 경우에도 주요 필드를 확인해야 합니다. 인식에 성공했다고 설정이 완전한 것은 아닙니다.

공유 정보의 remarks나 조각 부분에 있는 메모는 주로 화면 표시용이므로 이름을 바꿔도 되는 경우가 많습니다. 반면 쿼리 매개변수는 실제 연결에 쓰일 수 있습니다. 알 수 없는 매개변수가 있으면 모두 메모로 보고 지우지 말고, 클라이언트가 지원하는지 서버에서 필요한지 먼저 확인하세요. 일부 가져오기 도구는 알 수 없는 매개변수를 오류 없이 무시할 수 있습니다. 이 경우 항목은 목록에 나타나지만 고급 기능은 빠질 수 있으므로 원본 공유 정보와 하나씩 대조해야 합니다.

구독 업데이트는 별도의 데이터 연결입니다

구독 응답은 링크 목록, 인코딩된 목록, 구조화된 설정 등 여러 형식일 수 있으며 세 클라이언트가 모두 직접 읽을 수 있는 것은 아닙니다. 파일 확장자로 콘텐츠 형식을 정확히 알 수도 없습니다. 일반 웹페이지처럼 보이는 주소가 구독 데이터를 반환할 수 있고, 반대로 다른 주소는 로그인 페이지를 반환할 수 있습니다. 업데이트 후 항목이 비어 있다면 프로토콜 호환성을 따지기 전에 요청이 성공했는지, 응답이 실제 설정 데이터인지 확인하세요.

구독 요청은 직접 연결하거나 기존 프록시를 통해 보낼 수 있습니다. 이는 가져온 노드를 어떤 방식으로 연결할지와는 별개의 문제입니다. 현재 프록시를 사용할 수 없으면 프록시를 통해 보내는 업데이트 요청도 실패할 수 있어 ‘연결하려면 업데이트해야 하는데 업데이트하려면 연결해야 하는’ 상황이 생깁니다. 제공자 안내에 따라 사용할 수 있는 업데이트 경로를 선택하고 이미 작동하는 항목은 보관하세요. 구독을 가져오는 문제를 해결하려고 로컬 설정을 전부 삭제하지 마세요.

구독 주소에는 접속 자격 증명이 포함될 수 있으며 주소 자체가 접근 권한을 가질 수도 있습니다. 문제를 설명하는 화면에 전체 주소를 공개하지 말고 쿼리 매개변수를 공개 댓글에 붙여 넣지도 마세요. 형식을 설명해야 한다면 응답 유형, 오류 종류, 필드 이름만 공유하세요. 구독 만료, 인증 실패, 서버 오류 페이지는 설정 제공자가 해결해야 합니다. 로컬 프로토콜을 바꿔도 구독 요청 단계의 접근 권한 문제는 해결되지 않습니다.

업데이트 후 현재 항목과 직접 수정한 설정을 확인하세요

구독 업데이트는 항목을 바꾸거나 이름을 조정하고 기존 서버를 제거할 수 있습니다. 현재 선택 항목과 직접 수정한 내용이 유지되는지는 클라이언트 구현에 따라 다릅니다. 중요한 로컬 설정은 먼저 기록하고 필요한 경우 알아보기 쉬운 이름을 붙인 별도 항목으로 복사하세요. 단, 업데이트되지 않는 오래된 자격 증명을 계속 사용하지 않도록 주의해야 합니다. 업데이트 후에는 현재 선택 항목, 프로토콜, 보안 계층, 라우팅 설정을 확인하고 실제 접속도 테스트하세요.

클라이언트를 옮길 때는 제공자가 명시적으로 지원하는 구독 형식을 우선 사용하세요. 항목이 적다면 하나씩 가져와 확인하고, 여러 항목에서 같은 확장 기능을 사용한다면 전체를 옮기기 전에 하나를 먼저 시험하세요. 변환 도구는 필드를 누락하거나 로컬 라우팅 의미를 바꿀 수 있으므로 변환 성공이 실제 작동을 보장하지는 않습니다. 접속 자격 증명이 포함된 정보를 처리할 때는 데이터가 어떤 과정을 거치는지도 확인해야 합니다.

업데이트 전에는 정상적으로 작동했는데 이후 문제가 생겼다면 클라이언트를 바로 다시 설치하지 말고 새로 바뀐 내용을 먼저 비교하세요. 서버 주소, 프로토콜, 보안 계층, flow가 달라지면 필요한 코어도 달라질 수 있습니다. 자격 증명을 제외한 오류 요약을 남기면 제공자에게 문제를 더 정확하게 설명할 수 있으며, 도움말 센터에서 가져오기, 인증, 연결 문제에 해당하는 해결 절차를 찾을 수도 있습니다.

사용 환경에 맞게 선택하기: 설정을 먼저 확인하고 실제 사용으로 검증하세요

클라이언트의 프로토콜 목록은 자유롭게 업그레이드하는 메뉴가 아닙니다. 사용할 수 있는 프로토콜은 먼저 서버에서 제공하는 유효한 설정으로 결정되고, 다음으로 로컬 코어의 지원 여부, 마지막으로 성능과 유지 관리 선호도가 영향을 줍니다. 먼저 사용 목적을 정하고 전체 설정 조합을 확인한 뒤 안정적인 기본 설정을 만들고 대안을 비교하세요. 최종적으로 필요한 것은 서버 조건과 무관한 프로토콜 순위가 아니라 실제로 검증할 수 있는 연결 설정입니다.

데스크톱 일상 사용과 모바일 백그라운드의 차이

데스크톱에서 일상적으로 웹을 사용할 때는 v2rayN으로 제공자가 안내한 설정을 관리하고, 시스템 프록시가 필요한 앱을 대상으로 작동하는지 먼저 확인하세요. VMess, Trojan, Shadowsocks 연결이 안정적으로 작동한다면 VLESS를 봤다는 이유만으로 옮길 필요는 없습니다. 서버에서 Xray가 필요한 REALITY 설정을 제공했다면 해당 코어와 필드가 맞는지 확인하세요. 데스크톱에서는 기기 성능보다 연결 안정성과 명확한 라우팅이 사용 경험에 더 직접적인 영향을 주는 경우가 많습니다.

모바일에서는 v2rayNG와 설정의 호환성을 우선 확인하고 백그라운드 연결 유지, 네트워크 전환, 실제 사용 작업을 함께 살펴보세요. V2Fly 기능이 필요할 때 v2flyNG를 검토하면 됩니다. 웹페이지 하나만 열어 보고 끝내지 말고 대기 후 연결 복구, 무선 네트워크 전환, 필요한 UDP 작업도 확인하세요. 프로토콜 핸드셰이크가 성공해도 시스템의 백그라운드 제한이나 로컬 연결 범위 때문에 특정 앱이 계속 작동하지 않을 수 있습니다.

여러 기기에서 함께 사용할 때는 한 기기에서 복잡한 확장 기능을 추구하기보다 모든 기기에서 완전히 설정할 수 있는 조합을 선택하는 편이 관리하기 쉽습니다. 기기마다 이름과 설정 출처를 명확히 기록해 업데이트할 때 혼동하지 않도록 하세요. 서버가 기기별 자격 증명을 지원한다면 별도로 관리하면 취소와 문제 해결이 쉬워집니다. 모든 기기의 문제를 같은 노드 메모 탓으로 돌리지 마세요. 실제로 사용 중인 설정은 이미 달라졌을 수 있습니다.

로컬 라우팅과 프로토콜 선택은 별도로 확인하세요

분할 라우팅 규칙은 트래픽을 어느 아웃바운드로 보낼지 결정하며 원격 프로토콜을 바꾸지는 않습니다. 특정 웹사이트가 열리지 않는다면 테스트 중인 프록시 항목을 전혀 거치지 않는 상황일 수도 있습니다. 문제를 진단하기 전에 적용되는 라우팅 규칙, 선택된 아웃바운드, 이름 확인 경로를 확인하세요. 아래 예시는 광고 분류를 차단하는 코어 라우팅 규칙의 단일 객체입니다. 전체 설정 파일이 아니며 block이라는 차단 아웃바운드와 해당 geosite 데이터가 이미 있어야 합니다.

{
  "type": "field",
  "domain": ["geosite:category-ads-all"],
  "outboundTag": "block"
}

이 예시는 규칙에서 참조하는 태그와 데이터 파일도 실행 조건에 포함된다는 점을 보여줍니다. 프로토콜 핸드셰이크가 정상이어도 아웃바운드나 규칙 리소스가 빠져 있으면 보완되지 않습니다. 일상적인 문제 해결에서는 클라이언트가 제공하는 단순한 기본 규칙부터 사용한 뒤 사용자 지정 규칙을 단계적으로 복원하세요. 단일 노드의 작동 여부를 확인하려고 실행 설정 전체를 덮어쓰지 마세요. 특정 유형의 도메인만 실패한다면 프로토콜을 바꾸기 전에 규칙과 이름 확인부터 점검하세요.

시스템 프록시와 Tun 모드도 따로 확인해야 합니다. 앱이 시스템 프록시를 따르지 않는다면 프로토콜을 바꿔도 트래픽이 자동으로 클라이언트에 들어오지 않습니다. Tun 모드에서 권한이나 라우팅 문제가 발생해도 노드 테스트 성공만으로 연결 방식이 정상이라고 판단할 수 없습니다. 먼저 프록시를 따르는 것이 확실한 앱에서 확인한 다음 적용 범위를 넓히세요. 처음 설정하는 경우 빠른 시작 가이드로 돌아가 가져오기, 선택, 연결, 접속 확인 순서대로 진행하세요.

점검 순서로 선택을 마무리하세요

첫 번째로 주소, 포트, 프로토콜, 자격 증명을 확인해 연결 대상과 신원을 검증하세요. 두 번째로 전송 방식, 경로, 서버 이름, 보안 계층, flow를 확인해 핸드셰이크 설정을 점검하세요. 세 번째로 코어 지원 여부, 로컬 연결 방식, 라우팅을 확인해 실제 트래픽이 의도한 아웃바운드를 거치는지 살펴보세요. 근거가 있는 불일치 항목만 한 번에 하나씩 수정하고 저장한 뒤 다시 시도하세요. 이렇게 하면 원인과 결과를 추적하고 원본 설정과 비교하기 쉽습니다.

로그는 문제 범위를 좁히는 데 도움이 되지만 마지막 한 줄만 캡처해서는 안 됩니다. 하위 연결 시간 초과, 인증 거부, 인증서 이름 불일치, 대상 이름 확인 실패는 서로 다른 단계의 문제입니다. 오류 유형, 발생 상황, 최근 변경 사항을 기록하고 자격 증명은 가린 뒤 도움을 요청하세요. 같은 설정이 한 기기에서만 실패하면 해당 기기의 코어, 시간, 연결 설정을 먼저 비교하세요. 여러 기기에서 동시에 실패한다면 서버 상태와 설정 변경을 확인해야 합니다.

최종적으로 사용할 설정은 매개변수 출처가 명확하고 필요한 작업에서 검증을 마쳤으며 업데이트와 문제 해결 방법이 분명해야 합니다. 이 조건이 갖춰진 다음에 성능을 비교하세요. 운영체제와 프로세서 아키텍처에 맞는 설치 파일은 다운로드 센터에서 선택하고, 개념이 헷갈리면 용어 안내를 참고하세요. 같은 문제가 반복되면 도움말 센터의 항목별 안내를 확인하세요. 프로토콜 이름은 출발점일 뿐이며, 전체 설정과 반복 가능한 검증 결과가 선택 기준입니다.