V2Ray 프로토콜
및 코어 가이드

VMess의 인증과 전송 방식 선택

VMess는 Project V 생태계에서 비교적 일찍 자리 잡은 프록시 프로토콜로, 사용자 식별, 요청 포장, 데이터 보호와 관련된 메커니즘을 포함합니다. 오랫동안 널리 사용되어 오래된 구독과 배포 문서에도 여전히 많이 등장합니다. VMess를 이해할 때는 현재도 사용할 수 있다는 사실과 오래된 안내가 지금도 유효하다는 사실을 구분해야 합니다. 이전 설정의 인증 방식이나 보조 항목은 최신 코어에 적합하지 않을 수 있습니다. 프로토콜 선택은 튜토리얼의 작성 시기나 노드 이름이 아니라 서버의 실제 구현을 기준으로 해야 합니다.

사용자 ID, 암호화 방식과 시간

‘사용자 ID’에는 보통 UUID를 입력합니다. 인증에 쓰이는 값이며 임의로 정하는 메모 이름이 아닙니다. 클라이언트에서 새 UUID를 생성해도 서버 권한이 자동으로 부여되지 않으므로 서버에 등록된 사용자 값과 일치해야 합니다. ‘암호화 방식’도 프로토콜 설정의 일부로, TLS 사용 여부와 혼동하면 안 됩니다. 자동 선택은 구현체가 적절한 방식을 결정하는 경우가 많습니다. 알고리즘을 직접 지정하기 전에는 양쪽에서 지원하는지 확인하세요. 프로세서의 하드웨어 가속 지원 여부에 따라 실제 처리 부담이 달라지므로, 이름만 보고 일관된 속도 순위를 정할 수는 없습니다.

VMess 인증에는 시간 관련 검사가 포함되므로 시스템 시각이 크게 어긋나면 인증에 실패할 수 있습니다. 문제를 해결할 때는 먼저 시스템 시간 동기화를 켜고 날짜, 시간, 시간대가 올바르게 표시되는지 확인하세요. 시간대는 표시 방식에 영향을 줄 뿐이며, 실제로 정확해야 하는 것은 시스템 시간입니다. 화면에 보이는 시간만 바꾸고 실제 시각을 바로잡지 않으면 문제가 계속됩니다. 시계를 확인하기도 전에 구독을 다시 만들거나 암호화 방식을 바꾸면 변수가 늘어나 오류를 재현하기 어려워질 수 있습니다.

오래된 공유 정보에는 alterId가 자주 포함됩니다. 현재 흔히 쓰이는 VMess AEAD 설정은 보통 0을 사용하거나 클라이언트가 해당 방식에 따라 처리합니다. 값을 크게 설정한다고 더 안전해지는 항목이 아닙니다. 이전 필드가 남아 있는 구독을 사용한다면 서버가 해당 인증 방식으로 설정되어 있는지, 클라이언트가 그 필드를 어떻게 해석하는지 확인하세요. 수년 전의 0이 아닌 값을 그대로 복사하지 마세요. 서버 안내와 가져온 설정이 서로 다르면 양쪽을 임의로 바꾸기보다 서버의 실제 배포 방식과 사용 중인 코어 문서를 기준으로 판단해야 합니다.

WebSocket과 TLS를 함께 사용하는 이유

VMess는 여러 전송 방식으로 전달할 수 있습니다. 역방향 프록시가 필요한 배포에서는 WebSocket과 TLS 조합이 흔합니다. 클라이언트가 먼저 TLS 핸드셰이크를 완료하고 올바른 HTTP 업그레이드 요청을 보낸 뒤 VMess 세션을 시작합니다. 따라서 포트에 연결할 수 있다고 경로까지 맞는 것은 아닙니다. WebSocket의 path와 Host는 배포 설정과 일치해야 하고, 역방향 프록시는 요청을 해당 백엔드로 전달해야 합니다. 경로 철자나 끝의 슬래시가 다르거나 잘못된 대상 사이트를 선택하면 핸드셰이크가 실패하거나 일반 웹페이지가 표시될 수 있습니다.

이 조합에는 포장과 핸드셰이크 단계가 더해지지만, 접속할 때마다 전체 비용을 다시 부담한다는 뜻은 아닙니다. 장기 연결 재사용, 연결 풀, 앱의 접속 방식, 중간 프록시의 시간 제한에 따라 결과가 달라집니다. 반대로 직접 TCP를 사용하면 포장 단계는 줄지만 모든 환경에서 페이지가 더 빨리 로드되는 것도 아닙니다. 서버 위치, 연결 품질, DNS가 다르다면 배포 방식이 서로 다른 두 연결만 비교해서 VMess 자체의 속도를 판단할 수 없습니다.

기존 배포를 유지할지 마이그레이션할지

기존 VMess 설정이 유지 관리 중인 클라이언트와 서버에서 정상 작동한다면, 프로토콜 이름이 오래되었다는 이유만으로 마이그레이션할 필요는 없습니다. 오래된 인증 방식을 아직 사용하는지, 설정이 안정적으로 가져와지는지, 전송 매개변수가 명확한지, 서버가 계속 관리되는지를 확인하는 편이 중요합니다. VLESS로 옮기려면 서버에 해당 인바운드를 만들고 새 설정값을 받아야 합니다. 클라이언트 드롭다운에서 VLESS만 선택하면 되는 것이 아닙니다. 두 프로토콜은 인증과 요청 형식이 달라 한쪽에서 이름만 바꿔 호환할 방법은 없습니다.

새로 배포하면서 Xray의 VLESS와 REALITY 조합이 필요하다면 해당 방식에 맞춰 설정하세요. 기존 VMess 서버에 계속 연결해야 한다면 프로토콜과 전송 방식을 그대로 유지하는 것이 우선입니다. ‘가져오기는 성공했지만 연결되지 않음’ 문제가 발생하면 원본 공유 정보와 편집 창의 암호화 방식, 전송 방식, 보안 계층, 경로를 비교한 다음 로그를 확인하세요. 일반적인 문제 해결 방법은 자주 묻는 질문에서 확인할 수 있습니다. 로컬 시스템 프록시 문제를 VMess 프로토콜 비호환으로 잘못 판단하지 마세요.

Trojan과 Shadowsocks의 차이

Trojan과 Shadowsocks는 또 다른 흔한 선택지지만 설계의 중점은 서로 다릅니다. Trojan은 일반적으로 TLS 연결과 비밀번호 인증을 중심으로 배포되므로 인증서와 서버 이름이 중요한 설정입니다. Shadowsocks는 간결한 프록시 전달 및 인증 암호화 메커니즘을 바탕으로 폭넓게 구현되어 있으며, 암호화 방식에 따라 세대가 나뉩니다. 비교할 때 ‘비밀번호만 필요하다’는 사실을 보안 계층까지 같다는 뜻으로 이해하면 안 됩니다. SS라고 적힌 노드가 모두 동일한 알고리즘과 기능을 제공하는 것도 아닙니다.

Trojan: 비밀번호뿐 아니라 인증서와 이름도 필요합니다

v2rayN 또는 v2rayNG에서 Trojan을 추가할 때는 보통 주소, 포트, 비밀번호, TLS 관련 설정이 필요합니다. 비밀번호는 입력기에서 기호가 바뀌지 않도록 원본 그대로 입력하세요. 메모 이름은 인증에 사용되지 않습니다. 서버 이름은 배포 설정 및 인증서 검증 방식과 일치해야 합니다. 서버가 그렇게 구성되어 있다면 주소는 IP를 사용하고 검증에는 도메인을 사용할 수도 있습니다. 인증서 이름이 일치하지 않는다면 비밀번호 길이를 의심하기 전에 SNI와 서버 인증서를 확인하세요.

Trojan에 처음 연결할 때는 보통 TCP 연결과 TLS 핸드셰이크가 이루어집니다. 짧은 요청을 많이 보내는 경우 연결 재사용 여부가 체감에 영향을 줍니다. 오랫동안 데이터를 전송하는 경우에는 연결 처리량과 서버 자원이 더 중요합니다. TLS는 범용으로 널리 쓰이는 성숙한 보안 기반이지만 실제 성능은 구현, 인증서 배포, 중간 프록시, 핸드셰이크 재개 기능에 따라 달라집니다. TLS를 사용한다는 이유만으로 반드시 느리다고 단정하거나, 설정 항목이 적다는 이유로 문제 해결 때 비밀번호 하나만 확인해서는 안 됩니다.

Shadowsocks: 암호화 방식을 정확히 맞춰야 합니다

Shadowsocks의 일반적인 설정에는 서버, 포트, 비밀번호, 암호화 방식이 포함됩니다. 최신 AEAD 방식과 이전 세대의 스트림 방식은 설계가 다릅니다. AEAD는 암호화뿐 아니라 데이터 인증도 처리합니다. 서버에서 지정한 방식은 클라이언트와 실행 중인 코어가 모두 지원해야 하며, 드롭다운에 비슷한 이름이 있다고 서로 대체할 수 있는 것은 아닙니다. 방식을 잘못 선택하면 비밀번호가 맞아도 통신할 수 없습니다. 이전 설정을 가져올 수 있다는 것은 클라이언트가 공유 형식을 인식했다는 뜻일 뿐, 현재 코어가 해당 알고리즘을 지원한다는 뜻은 아닙니다.

AEAD 2022 같은 방식은 키 형식에 명확한 조건을 둘 수 있으므로 일반 텍스트 비밀번호처럼 생각해 임의로 입력하면 안 됩니다. 일부 배포는 다중 사용자 키 등의 확장 형식을 사용하므로 공유 정보 전체를 그대로 보존해야 합니다. 이러한 설정을 사용한다면 먼저 서버의 암호화 방식과 클라이언트 지원 범위를 확인한 뒤 키를 정확히 복사하세요. 구분자가 있는 내용을 일부만 잘라내거나 구독 변환 도구가 기존 비밀번호 방식으로 다시 해석하게 두면 의미가 달라질 수 있습니다. 키 형식은 프로토콜 조건이지 자유롭게 선택할 수 있는 표시 방식이 아닙니다.

기본 Shadowsocks 설정에서 TCP와 UDP를 지원하는지도 클라이언트의 트래픽 연결 방식과 함께 확인해야 합니다. 서버에서 UDP를 허용하더라도 시스템 HTTP 프록시를 통해 클라이언트에 연결된 프로그램이 UDP를 투명하게 전달받는 것은 아닙니다. 공유 링크에 플러그인 매개변수가 포함될 수도 있습니다. 이 사이트에서 안내하는 클라이언트와 코어가 해당 확장을 구현하지 않았다면 서버 주소와 비밀번호만 남겨서는 동등한 설정이 되지 않습니다. 이 경우 인식할 수 없는 필드를 지우고 계속 사용하기보다 양쪽이 지원하는 전체 설정을 요청하세요.

설정 항목 수가 아니라 기존 배포 방식에 맞춰 선택하기

서버에서 올바르게 관리되는 Trojan 설정을 제공하고 클라이언트가 해당 전송 및 TLS 설정을 모두 지원한다면, 매개변수를 몇 개 줄이려고 다른 프로토콜로 바꿀 이유는 없습니다. 서버가 Shadowsocks를 사용한다면 특히 세대별 차이를 고려해 암호화 방식과 키 형식을 정확히 확인해야 합니다. 호환성을 높이겠다며 보안 검사를 끄거나 알 수 없는 매개변수를 삭제해서는 안 됩니다. 의미가 바뀌어 오류가 사라진 설정을 사용하는 것보다 원래 오류를 보존하는 편이 문제 해결에 도움이 됩니다.

실제 선택에서는 관리 부담도 고려해야 합니다. 인증서를 안정적으로 갱신할 수 있는지, 키 변경 사항이 구독에 반영되는지, 대상 코어가 필요한 확장을 지원하는지 확인하세요. 기존 서비스에 연결하려는 초보자라면 프로토콜을 새로 정하기보다 현재 배포 방식에 맞추는 것이 가장 중요합니다. 비밀번호나 구독 내용이 노출되었을 가능성이 있다면 서버에서 해당 정보를 폐기하고 다시 배포해야 합니다. 로컬 메모만 바꾸는 것으로는 해결되지 않습니다. 클라이언트 로그와 공유 링크에도 민감한 설정값이 포함될 수 있으므로 문의 내용을 보내기 전에 인증 정보와 전체 구독 주소를 삭제하세요.

연결 오버헤드, 시스템 자원과 모바일 배터리

‘어떤 프로토콜이 가장 빠른가’를 비교하려면 먼저 측정 대상을 정해야 합니다. 첫 연결은 DNS 조회, 연결 수립, 보안 핸드셰이크가 중요합니다. 웹페이지 사용 경험에는 대상 사이트, 연결 재사용, 리소스 개수도 영향을 줍니다. 지속 다운로드에서는 처리량, 패킷 손실, 서버 용량이 더 중요하고, 음성이나 실시간 앱에서는 지터와 UDP 경로를 살펴야 합니다. 지표마다 결과가 다를 수 있습니다. 클라이언트의 지연 시간 측정 하나로 모든 앱의 성능을 판단할 수 없으며, 서버가 서로 다른 두 수치를 비교해 프로토콜 자체의 속도 차이를 도출해서도 안 됩니다.

핸드셰이크 비용과 지속 전송은 따로 살펴보기

DNS 조회, TCP 연결 수립, TLS 또는 다른 보안 핸드셰이크에는 연결 전 대기 시간이 들어갑니다. WebSocket과 gRPC 등의 전송 방식도 연결을 만드는 과정이 있습니다. 하지만 연결 재사용과 핸드셰이크 재개로 반복 비용을 줄일 수 있고, 네트워크 재전송은 한 번의 실패로 드는 비용을 늘릴 수 있습니다. 연결을 자주 새로 만드는 앱에서는 불필요한 왕복을 줄이는 것이 도움이 될 수 있습니다. 이미 연결을 유지하며 데이터를 전송한다면 초기 핸드셰이크가 전체 시간에서 차지하는 비중은 줄어듭니다. 성능을 시험할 때 이 차이를 유지하고, 장시간 다운로드 한 번으로 짧은 연결의 사용 경험을 대신 판단하지 마세요.

CPU 사용량은 암호화 알고리즘, 하드웨어 명령어, 데이터 복사, 구현 최적화에 따라 달라집니다. 데스크톱 프로세서에서 부담이 적은 알고리즘도 다른 아키텍처의 휴대전화에서는 그렇지 않을 수 있습니다. 메모리 사용량은 연결 수, 버퍼, 라우팅 데이터, DNS 캐시, 로그 규모의 영향도 받으므로 프로토콜 하나로 결정되지 않습니다. 클라이언트 점유율이 늘어났다면 프로토콜을 바꾸기 전에 규칙 다운로드 중인지, 연결이 많이 유지되고 있는지, 상세 로그를 출력하는지 확인하세요.

모바일에서는 암호화 비용만 비교할 수 없는 이유

휴대전화 배터리를 많이 소모하는 요인에는 무선 모듈 깨우기, 약한 신호에서의 재전송, 백그라운드 연결, 잦은 재연결, 다른 앱의 활동이 있습니다. 프로토콜 암호화에도 연산 자원이 필요하지만 항상 주요 원인인 것은 아닙니다. 안정적으로 연결되어 깨우는 횟수가 적은 조합은 이론상 처리 단계가 가벼워도 계속 재시도하는 조합보다 전력을 덜 쓸 수 있습니다. 셀룰러 네트워크와 Wi-Fi의 전력 사용 조건도 다르므로 네트워크나 화면 밝기가 다른 상황에서 배터리 감소를 Xray 또는 V2Fly 탓으로 돌릴 수 없습니다.

Android에서 VPN 인터페이스로 트래픽을 연결하면 클라이언트가 패킷을 읽고 전달하는 작업도 맡습니다. 데스크톱 TUN 역시 가상 네트워크 인터페이스, 라우팅, DNS 처리와 연동됩니다. 이 기능은 트래픽이 연결되는 범위와 처리 경로를 바꾸는 것이지 서버 프로토콜을 업그레이드하지는 않습니다. 시스템 프록시가 대상 프로그램을 이미 처리하고 있다면 TUN을 켜도 속도가 나아지지 않을 수 있습니다. 대상 프로그램이 시스템 프록시를 따르지 않는다면 TUN으로 연결 범위를 넓힐 수 있습니다. 구체적인 설정 방법은 v2rayN TUN 모드 설정을 참고하세요.

Mux, 연결 유지와 UDP의 실제 제약

다중화는 여러 논리 요청을 더 적은 수의 하위 연결에 실어 보내는 방식으로, 특정 짧은 연결 상황에서는 연결 수립을 반복하는 비용을 줄일 수 있습니다. 하지만 공유 연결에서 혼잡이나 패킷 손실이 발생하면 여러 요청에 영향을 줄 수 있습니다. 일부 프로토콜과 흐름 제어 조합은 Mux 사용에 제약이 있으므로 기본으로 켜두면 안 됩니다. 연결 유지에도 절충점이 있습니다. 간격이 너무 짧으면 백그라운드 활동이 늘고, 너무 길면 일부 네트워크의 유휴 연결 상태가 유지되지 않을 수 있습니다. 호환되는 기본값을 우선 사용하고 구체적인 문제가 확인된 뒤에만 조정하세요.

실시간 앱에서 UDP를 사용한다면 로컬 연결, 코어 전달, 서버, 대상 네트워크를 포함한 전체 경로가 지원되는지 확인해야 합니다. UDP를 프록시로 전달한다고 지터가 줄어드는 것은 아니며, 서버 경로가 우회하거나 연결이 혼잡하면 사용 경험이 나빠질 수 있습니다. DNS 조회 방식도 대상 주소와 라우팅 선택에 영향을 주므로 테스트할 때 동일하게 유지해야 합니다. FakeDNS는 도메인 매핑과 캐시 동작을 포함하며 범용 속도 향상 옵션이 아닙니다. 관련 원리는 FakeDNS 사용 사례 노트를 참고하세요.

비교할 때마다 변수 하나만 바꾸고 시작, 첫 요청, 지속 전송, 대기 상태를 각각 기록하세요. 가장 좋았던 한 번의 결과만 남기지 말고 여러 번 확인해야 합니다. 같은 서버에서 조건을 통제할 수 없다면 결과를 ‘현재 두 설정의 사용 경험 차이’라고 설명하고 프로토콜 순위로 일반화하지 마세요. 일상적인 사용에서는 미세한 측정 차이보다 안정적인 연결, 완전한 기능 지원, 쉬운 복구가 더 중요합니다. 따라서 선택할 때는 성능 비교에 앞서 호환성을 확인해야 합니다.

사용 환경에 맞는 프로토콜과 코어 선택

선택은 프로토콜 순위가 아니라 사용 조건을 기준으로 해야 합니다. 먼저 기기 플랫폼, 서버에서 실제로 제공하는 조합, 프록시가 필요한 앱 종류, UDP 사용 여부를 확인하세요. 그런 다음 필요한 매개변수를 빠짐없이 표현할 수 있는 클라이언트와 코어를 선택하고 관리 부담과 실행 성능을 비교하면 됩니다. 서버의 협조가 없다면 사용자가 프로토콜을 마음대로 바꿀 수 없으며 이미 제공된 설정 중에서 선택해야 합니다. 클라이언트의 프로토콜 드롭다운은 설정을 입력하는 곳이지 원격 서버를 자동으로 다른 프로토콜로 바꾸는 도구가 아닙니다.

데스크톱과 Android 시작하기

데스크톱에는 v2rayN을 우선 추천합니다. 설치 파일 페이지에서 운영체제와 CPU 아키텍처에 맞는 파일을 선택한 다음 필요한 프로토콜을 처리할 코어를 확인하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스 및 실행 환경의 선택일 뿐 원격 프로토콜이 다른 것은 아닙니다. macOS와 Linux에서도 아키텍처와 시스템 조건을 확인해야 합니다. 일반 브라우저의 트래픽이 이미 시스템 프록시를 사용한다면, TUN은 우선 끄고 변수를 줄여 기준을 만든 다음 트래픽 연결 범위를 넓힐지 결정하세요.

Android에서는 서버가 지원하는 기능에 맞춰 v2rayNG를 우선 선택하세요. 특히 Xray 관련 기능이 필요한 경우에 적합합니다. 배포 환경에서 V2Fly 경로를 명확히 요구하고 설정도 지원 범위에 있다면 v2flyNG를 고려할 수 있습니다. 처음 실행할 때 Android VPN 권한을 허용하고 다른 VPN 연결이 같은 접속 자리를 사용 중인지 확인하세요. 이후 백그라운드 제한과 네트워크 전환 시 동작을 살펴보면 됩니다. 앱을 백그라운드로 보낼 때 연결이 끊긴다고 바로 프로토콜 문제로 판단하지 마세요. 시스템 배터리 관리, 백그라운드 권한, 신호 변화도 각각 확인해야 합니다.

기존 서비스, 새 배포, 실시간 앱

기존 서비스에 연결할 때는 원래 프로토콜과 전송 방식을 유지한 채 전체 설정을 가져왔는지 확인하는 것이 가장 안전합니다. VMess + WebSocket + TLS가 정상 작동한다면 이름을 바꾸기 위해 마이그레이션할 필요는 없습니다. 기존 Trojan은 인증서, 서버 이름, 비밀번호를 정확히 관리하고, 기존 Shadowsocks는 암호화 방식과 키 형식을 맞추세요. VLESS + REALITY가 필요하다면 전체 조합을 지원하는 Xray 경로를 선택하고 서버에서 제공한 흐름 제어와 핸드셰이크 매개변수를 입력하세요. 다른 기록의 필드를 가져다 쓰면 안 됩니다.

새로 배포할 때는 유지 관리 역량을 기준으로 선택하는 것이 좋습니다. 인증서와 서버 이름을 관리할 수 있는지, 역방향 프록시를 전송에 사용해야 하는지, 대상 기기가 모두 같은 보안 방식을 지원하는지, 구독 도구가 매개변수를 빠짐없이 출력할 수 있는지 확인하세요. 이런 항목을 목록으로 정리하는 편이 이론적인 오버헤드만 따지는 것보다 유용합니다. 실시간 음성이나 다른 UDP 앱을 사용한다면 웹페이지가 열리는지만 확인하지 말고 전체 UDP 경로와 라우팅을 먼저 테스트하세요. 앱의 지역 설정, 대상 경로, 서버 위치도 사용 경험에 영향을 줍니다.

되돌릴 수 있는 최소 설정으로 기준 만들기

처음 확인할 때는 서버 하나, 명확한 라우팅 방식, 호환 가능한 기본 설정을 사용하세요. 먼저 코어가 실행되는지, 요청이 로컬 포트로 들어오는지, 서버 핸드셰이크와 대상 사이트 접속이 되는지 순서대로 확인합니다. 아래 JSON은 네이티브 설정에서 routing 객체가 사용하는 최소 규칙 구조만 보여 줍니다. 사설 주소를 direct라는 이름의 아웃바운드로 보냅니다. 완전한 연결 설정이 아니므로 사용하기 전에 해당 태그의 직접 연결 아웃바운드가 있어야 하며 기존 규칙의 순서도 확인해야 합니다. 그래픽 클라이언트 사용자는 라우팅 설정에서 같은 작업을 하는 것이 좋습니다.

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

이 규칙은 프로토콜과 별개인 또 하나의 경계를 보여 줍니다. 노드 설정이 바뀌지 않아도 라우팅에 따라 요청이 노드를 통과할지 달라질 수 있습니다. 규칙은 구현체의 일치 처리 방식에 따라 적용되므로, 앞쪽의 넓은 조건이 먼저 일치하면 뒤쪽의 세부 규칙은 적용되지 않을 수 있습니다. 실제로 사용할 때는 지리 데이터 파일을 사용할 수 있는지도 확인해야 합니다. 예시를 적용하려고 routing 객체 전체를 덮어쓰지 말고 기존 규칙을 먼저 파악한 뒤 조건을 명확히 추가하세요. 로컬 네트워크와 대상 네트워크 접속도 각각 확인해야 합니다.

문제가 생기면 확인된 근거에 따라 되돌리기

코어가 실행되지 않으면 설정 생성과 포트 점유를 확인하세요. 핸드셰이크가 실패하면 인증 정보, 보안 계층, 시간을 확인합니다. 연결은 되었지만 앱이 응답하지 않는다면 로컬 트래픽 연결, DNS, 라우팅을 살펴보세요. 로컬 포트 충돌은 포트 점유와 수신 포트 변경 노트에서 확인할 수 있습니다. 한 번에 하나만 바꾸고 이전에 작동하던 상태를 보존하세요. 되돌릴 때는 설정 필드를 전부 다시 입력하기보다 새로 추가한 고급 기능부터 끄세요.

최종 선택 결과는 클라이언트, 코어, 프록시 프로토콜, 전송 방식, 보안 계층, 트래픽 연결 방식, 라우팅 방식을 한 줄로 정리해 둘 수 있습니다. 이렇게 기록하면 기기를 바꿀 때 항목별로 확인할 수 있고 문제가 생겨도 차이를 정확히 설명할 수 있습니다. 프로토콜 선택의 목적은 이름을 복잡하게 만드는 것이 아니라 서버 기능, 클라이언트 구현, 실제 앱의 요구 사항을 일치시키는 것입니다. 기준 설정을 완성한 다음 성능 절차에 따라 조건을 통제해 비교하세요. 일상적인 사용 방법은 빠른 시작 가이드에서, 구체적인 문의는 자주 묻는 질문에서 확인할 수 있습니다.