프로토콜 및 네트워크 경로 기술 가이드

웹사이트 접속 과정을 단계별로 나눠 보기

웹사이트를 열 때 클라이언트가 페이지를 프로토콜에 바로 넘기는 것은 아닙니다. 먼저 앱이 접속할 주소를 정하고, 기기에서 도메인을 조회한 다음 규칙에 따라 프록시 사용 여부를 결정합니다. 프록시를 거치는 연결은 클라이언트에서 로컬 네트워크를 지나 진입점에 도달하고, 이후 서버를 통해 대상 웹사이트에 접속합니다. 응답은 같은 경로를 따라 돌아옵니다. 페이지에서 이미지와 스크립트, 다른 도메인의 리소스를 추가로 요청할 수도 있으므로 ‘페이지가 열리지 않는다’고 해서 특정 프로토콜이 연결을 수립하지 못했다고 단정할 수는 없습니다. 먼저 도메인 조회, 연결, 전달, 콘텐츠 로딩 중 어느 단계에서 문제가 생겼는지 확인해야 비교가 의미 있습니다.

프로토콜은 주로 클라이언트와 서버가 요청을 식별하고, 인증하고, 데이터를 전송하는 방식을 정합니다. 핸드셰이크 과정이나 데이터 캡슐화, 연결 재사용, 네트워크 변경 대응 방식에 영향을 줄 수 있지만 통신사 경로와 출구 위치, 대상 웹사이트의 응답 속도까지 단독으로 결정하지는 않습니다. 같은 프로토콜도 네트워크 경로가 다르면 체감이 크게 달라질 수 있고, 서로 다른 프로토콜도 같은 출구의 혼잡 영향을 받아 함께 느려질 수 있습니다. 프로토콜 이름만 보고 네트워크 경로의 품질을 판단하면 경로 문제를 구현 문제로 오해할 수 있습니다.

첫 응답, 지속 전송 속도, 안정성을 나눠 살펴보기

연결 수립이 빠르다는 것은 앱이 콘텐츠를 받기 시작하기까지 기다리는 시간이 짧다는 뜻입니다. 웹페이지를 자주 열거나 API를 반복 호출할 때 중요합니다. 지속 전송 속도는 연결이 안정된 뒤 파일을 얼마나 원활하게 전송하는지를 봅니다. 다운로드나 장시간 재생에 적합한 기준입니다. 안정성에는 응답 시간의 변동, 잦은 재연결 여부, 네트워크 전환 후 복구 가능성도 포함됩니다. 어떤 조합은 웹페이지가 빠르게 열려도 지속 전송 중 출구 용량의 한계에 부딪힐 수 있고, 다른 조합은 다운로드가 안정적인 대신 첫 핸드셰이크를 기다리는 시간이 길 수 있습니다. 이 모두를 하나의 ‘속도’로 묶어 판단하지 마세요.

테스트할 때는 기기와 접속 네트워크, 대상 서비스, 규칙 모드를 가능한 한 동일하게 유지하세요. 먼저 같은 네트워크 경로에서 패널이 제공하는 프로토콜을 비교한 뒤, 프로토콜을 고정하고 네트워크 경로를 비교하면 지역과 클라이언트 설정을 동시에 바꾸는 일을 피할 수 있습니다. 평소 사용하는 웹페이지나 회의 앱, 파일을 대상으로 관찰하고 문제가 발생한 시간대도 기록하세요. 대상 사이트마다 출구 경로가 다를 수 있으므로 속도 측정 페이지 하나의 결과는 해당 페이지에 접속한 경로만 보여 줍니다. 모든 앱의 성능을 대변하지는 않습니다.

설정에서 지원하는 기능과 서비스 제공 범위 구분하기

프로토콜 문서에 적힌 기능이 현재 클라이언트와 서버에서 모두 활성화되어 있다는 보장은 없습니다. 예를 들어 데이터그램 전달, 연결 마이그레이션, 다중 연결 사용에는 커널 지원과 서버 설정이 추가로 필요할 수 있습니다. 확인할 때는 패널의 구독 정보와 클라이언트에서 선택할 수 있는 항목, 네트워크 경로 안내를 기준으로 삼으세요. 더 고급으로 보이는 설정을 임의로 추가하거나 일반적인 가이드만 보고 본 서비스가 특정 전용 회선이나 전송 방식을 제공한다고 추정하지 마세요. 확인된 출처의 구독 설정을 가져오는 편이 검증되지 않은 설정을 직접 조합하는 것보다 안전합니다.

VPNQB는 100+개 국가 / 190+개 네트워크 경로를 제공하며, 지역별 진입점은 네트워크 경로 목록에서 확인할 수 있습니다. 이는 선택 가능한 범위를 안내할 뿐, 모든 네트워크 경로와 대상 서비스에서 동일한 성능을 보장하지는 않습니다. 이 문서에서도 프로토콜 순위를 매기지 않습니다. 현재 네트워크에서 연결할 수 있고, 대상 앱을 사용할 수 있으며, 기기 부담도 감당할 수 있는 조합을 선택해야 합니다. 비교 결과는 특정 조건에서 관찰한 내용으로 기록하고, 한 번 원활하게 접속한 경험을 장기적인 결론으로 확대하지 마세요.

비교 전 확인 사항

구독 정보를 최신 상태로 업데이트하고 기기 시간이 정확한지, 대상 서비스가 정상적으로 응답하는지 확인하세요. 클라이언트의 연결 아이콘만 보지 말고 ‘연결 성공’과 ‘대상 앱 정상 작동’을 따로 기록하세요.

Shadowsocks: 단순한 데이터 전달 구조

Shadowsocks는 클라이언트와 서버 사이에서 앱 트래픽을 전달하는 암호화 프록시 프로토콜입니다. 완전한 네트워크 터널처럼 인터페이스와 라우팅을 관리하는 기능을 제공하는 경우가 일반적이지 않으므로, 앱 트래픽을 프록시로 보내는 방식은 클라이언트의 시스템 프록시, 가상 네트워크 인터페이스, 규칙 처리 기능에 따라 달라집니다. 기기에 VPN 표시가 나타나더라도 프로토콜 자체가 네트워크 계층 터널이라는 뜻은 아닙니다. 운영체제에서 클라이언트가 트래픽을 처리하도록 허용한 방식일 수 있습니다. 이 두 계층을 구분하면 어떤 앱은 정상 작동하고 다른 앱은 프록시를 거치지 않는 이유를 이해하기 쉽습니다.

사용 경험은 암호화 방식과 구현 품질, 전송 경로의 영향을 함께 받습니다. 캡슐화가 단순하면 추가 처리량을 줄이는 데 도움이 될 수 있지만, 모든 기기에서 배터리를 덜 쓴다고 단정할 수는 없습니다. 기기가 암호화 가속을 지원하는지, 클라이언트가 트래픽을 계속 검사하는지, 규칙이 복잡한지에 따라 리소스 사용량이 달라집니다. 설정의 암호화 방식과 인증 정보는 서버 설정과 일치해야 합니다. 인증 정보가 맞더라도 암호화 방식이 일치하지 않으면 클라이언트에서 설정을 저장할 수는 있어도 실제 요청은 완료되지 않을 수 있습니다.

TCP 트래픽과 UDP 데이터그램은 각각 확인해야 합니다. TCP 웹페이지가 정상적으로 열려도 UDP에 의존하는 앱까지 작동한다는 보장은 없습니다. 서버의 전달 기능과 클라이언트 모드, 접속 네트워크가 데이터그램 경로를 제한할 수 있습니다. 회의 앱에 접속한 뒤 음성에 문제가 생기고 웹페이지는 정상이라면, 모든 네트워크 경로를 바로 바꾸기보다 앱에서 실제로 사용하는 전송 방식과 클라이언트의 데이터그램 지원 여부부터 확인하세요. 사용자 패널에 없는 기능은 로컬 설정을 수정한다고 지원되는 것으로 간주할 수 없습니다.

VMess: 인증과 캡슐화는 구현 방식에 따라 달라짐

VMess는 요청 인증과 데이터 캡슐화에 자체적인 프로토콜 구조를 사용하며 여러 전송 방식과 조합할 수 있습니다. 비교할 때는 ‘VMess’와 이를 운반하는 전송 방식을 구분해야 합니다. 같은 프로토콜 이름이라도 바깥 계층은 직접적인 스트림 연결일 수도 있고, 추가 캡슐화를 거칠 수도 있습니다. 외부 보안 전송을 사용하는지, 중계 진입점을 거치는지, 협상 과정이 추가되는지에 따라 연결 대기 시간과 호환성이 달라집니다. 따라서 특정 조합의 장단점을 모든 VMess 설정에 일반화해서는 안 됩니다.

인증 관련 오류는 구독 설정이나 클라이언트 지원 범위, 기기 시간과 관련된 경우가 많습니다. 기기 시간이 크게 어긋나면 시간 정보를 사용하는 인증과 보안 검증에 영향을 줄 수 있지만, 모든 오류가 시간 문제인 것은 아닙니다. 먼저 시스템의 자동 시간 설정을 켜고 구독 정보를 업데이트한 다음 현재 클라이언트가 패널에서 받은 설정을 인식하는지 확인하세요. 이전 설정에 남은 필드를 경험에 의존해 새 설정으로 옮기지 마세요. 한 클라이언트에서 가져올 수 있는 설정도 다른 클라이언트에서는 필드 해석이 다를 수 있습니다.

추가 캡슐화는 진입점 구성과 전송 환경에 맞추기 위해 사용되기도 하지만 중간 처리 단계가 늘어납니다. 연결은 되는데 웹페이지 응답이 느리다면 같은 지역에서 사용할 수 있는 다른 조합을 비교해 진입점 협상과 이후 전송 중 어느 단계에서 지연되는지 확인해 보세요. 첫 접속만 느리고 그다음부터 안정적이라면 연결 재사용과 도메인 조회를 먼저 살펴보세요. 세션 내내 느리다면 인증 방식만 보기보다 경로 용량과 대상 서버 응답, 기기 리소스를 확인하는 편이 좋습니다.

적합한 사용 환경과 흔한 오해

일상적인 웹 브라우징과 일반 앱 이용에 기존 설정이 안정적으로 작동한다면 프로토콜 이름을 바꾸기 위해 굳이 설정을 변경할 필요는 없습니다. Shadowsocks의 단순한 구조와 VMess의 다양한 캡슐화 방식은 각기 다른 환경에 적합할 수 있습니다. 중요한 것은 현재 클라이언트가 설정을 제대로 가져올 수 있는지, 대상 앱에 필요한 트래픽이 프록시를 거치는지, 출구 경로가 대상 지역에 적합한지입니다. 기기를 자주 바꾸는 사용자라면 한 번 연결했을 때의 체감뿐 아니라 호환성과 구독 관리 부담도 비교해야 합니다.

문제 상황을 ‘클라이언트가 연결되지 않음’, ‘연결은 됐지만 페이지가 열리지 않음’, ‘전송 중 연결이 끊김’처럼 구분해 보세요. 첫 번째는 설정값이나 진입점, 인증에 가까운 문제일 수 있습니다. 두 번째는 규칙이나 도메인 조회, 대상 서비스와 관련될 수 있습니다. 세 번째는 네트워크 변동과 세션 유지, 출구 혼잡을 확인해야 합니다. 이 현상을 모두 ‘프로토콜이 불안정하다’고 표현하면 설정을 바꾼 뒤 일시적으로 복구되어도 어느 단계가 해결됐는지 판단하기 어렵습니다.

설정 관리 시 유의 사항

구독 정보는 사용자 패널에서 가져오고 업데이트해야 합니다. 링크를 확인하고 가져오거나 재설정하는 방법은 VPN 구독 링크 안내를 참고하세요. 공개된 게시물이나 스크린샷에 구독 정보를 전체 공개하지 마세요.

Trojan에서 안전한 연결을 위한 조건

Trojan은 일반적으로 프록시 요청을 TLS 보안 연결을 통해 전송합니다. 클라이언트는 먼저 설정에 맞는 보안 세션을 서버와 수립한 뒤 프록시 인증과 데이터 전달을 진행합니다. TLS는 전송 보호와 인증서 신원 확인을 담당하고, Trojan 인증 정보는 서버가 프록시 요청을 받아들일지 결정합니다. 두 기능은 서로 다릅니다. 인증서 검증이 성공해도 프록시 인증 정보가 올바르다는 뜻은 아니며, 인증 정보가 맞아도 인증서 이름 불일치나 시스템의 신뢰 설정 오류를 해결할 수는 없습니다.

서버 주소와 TLS에 사용할 서버 이름, 인증서에 포함된 이름은 설정에 맞게 서로 연결되어 있어야 합니다. 구독 설정에서 접속 주소와 서버 이름을 각각 지정하는 경우도 있으므로, 둘이 달라 보인다고 임의로 같게 바꾸지 마세요. 패널에 설정이 모두 제공되어 있다면 원래 상태 그대로 가져오는 것이 좋습니다. 인증서 오류가 발생하면 먼저 시스템 날짜와 구독 만료 여부, 수동 변경 여부를 확인한 뒤 클라이언트 지원 범위를 살펴보세요. 인증서 검증을 끄는 것은 일반적인 해결 방법이 아닙니다.

TLS 연결 과정에는 협상 비용이 들지만 앱에서 요청할 때마다 처음부터 다시 진행되는 것은 아닙니다. 클라이언트가 기존 연결을 재사용하거나 보안 세션 복구 기능을 사용할 수 있으며 실제 효과는 구현과 서버 정책에 따라 달라집니다. 짧은 연결을 자주 사용하는 앱은 초기 협상 영향을 더 많이 받을 수 있고, 장시간 전송은 경로와 출구 용량의 영향을 더 크게 받는 경우가 많습니다. 한 번의 새 연결만 테스트하면 기존 세션에서의 사용성을 과소평가할 수 있습니다. 반대로 이미 연결이 준비된 상태만 살피면 첫 접속의 대기 시간을 놓칠 수 있습니다.

VLESS의 가벼운 구조가 완전한 보안을 뜻하지는 않습니다

VLESS는 비교적 단순한 요청 구조와 인증 방식을 지향합니다. 일부 암호화 프록시 프로토콜과 같은 데이터 암호화 계층을 자체적으로 제공하지 않으므로, 실제 보안 수준은 이를 운반하는 전송 설정과 함께 판단해야 합니다. VLESS를 설명할 때는 외부 보안 전송과 클라이언트 구현도 함께 고려해야 합니다. ‘가볍다’는 이유만으로 더 빠르거나 안전하고 배터리를 덜 쓴다고 단정할 근거는 없습니다. 전송 보호를 고려하지 않으면 적합한 사용 환경도 잘못 이해할 수 있습니다.

VLESS 조합에 따라 전송 방식과 협상 설정이 다를 수 있으므로 클라이언트가 관련 필드를 인식하는지가 중요합니다. 설정을 가져오는 데 성공해도 모든 매개변수가 의도한 대로 적용된다는 뜻은 아닙니다. 구독 업데이트 후 일부 네트워크 경로가 사라지거나 가져오기 과정에서 지원되지 않는 필드가 표시되면 먼저 클라이언트 출처와 지원 범위를 확인한 뒤 패널 안내를 살펴보세요. 다른 서비스의 가이드에서 필드를 가져와 조합하지 마세요. 이름이 같은 설정도 특정 조합에 의존할 수 있어 서로 다른 설정 간에 임의로 옮길 수 없습니다.

프로토콜 계층의 처리가 적으면 일부 작업량을 줄일 수 있지만 외부 보안 연결과 규칙 매칭, 데이터 복사 작업은 여전히 필요합니다. 복잡한 전송 방식과 조합한 VLESS가 완성도 높은 구현의 Trojan보다 가볍다고 볼 수도 없습니다. 기기에서 관찰되는 메모리 사용량이나 발열은 클라이언트 로그, 연결 수, 앱 부하 때문일 수도 있습니다. 공정하게 비교하려면 진입점과 대상, 테스트 절차를 동일하게 유지하고 프로토콜 이름만이 아니라 전체 조합을 기록하세요.

인증서 문제를 네트워크 경로 변경으로 덮으면 안 되는 이유

오류가 인증서 체인이나 서버 이름, 시스템 시간을 가리킨다면 지역을 무작위로 바꾸는 것만으로 증상이 잠시 사라질 수는 있어도 원인이 해결됐다는 뜻은 아닙니다. 오류 종류를 기록하고 구독의 원래 설정을 복원한 뒤 정상적인 검증 상태에서 다시 시도해야 특정 설정 하나에 문제가 있는지 확인할 수 있습니다. 여러 보안 연결에서 동시에 오류가 발생하면 기기의 신뢰 저장소와 로컬 보안 소프트웨어, 네트워크 로그인 상태도 확인하세요. 공유 Wi-Fi의 로그인 페이지를 완료하지 않은 상태에서도 정상적인 연결 과정에 문제가 생길 수 있습니다.

프로토콜의 암호화와 서비스의 개인정보 처리 방침은 따로 살펴봐야 합니다. TLS는 특정 전송 구간을 보호할 수 있지만 계정 보안이나 대상 웹사이트의 보안 연결, 서비스 정책을 대신하지는 않습니다. VPNQB는 개인정보 보호 관련 안내에서 “익명 무로그”를 표방합니다. 자세한 내용은 개인정보 처리방침을 확인하세요. 기술 선택 시 특정 프로토콜 이름만으로 모든 이용 행위가 완벽하게 보호된다고 생각하지 마세요. 연결 대기 시간을 줄이려고 정상적인 신원 검증을 포기해서도 안 됩니다.

UDP를 사용해도 앱 데이터가 불안정해지는 것은 아닙니다

Hysteria2와 TUIC는 모두 QUIC 전송과 관련이 있습니다. QUIC는 UDP를 기반으로 하지만 상위 계층에서 보안 세션과 신뢰성 있는 스트림, 혼잡 제어를 제공할 수 있습니다. 따라서 ‘UDP를 사용한다’고 해서 웹페이지 내용이 임의로 누락되거나 패킷 손실을 처리하지 않아도 된다는 뜻은 아닙니다. 기존 연결의 일부 기능을 다른 계층에서 구현해 스트림과 연결 상태를 더 유연하게 관리할 수 있지만, 이점이 있는지는 클라이언트와 서버, 접속 네트워크의 조합에 달려 있습니다.

기존 TCP 연결에서는 데이터 세그먼트 하나가 손실되면 같은 바이트 스트림의 뒤쪽 데이터 전달까지 막힐 수 있습니다. QUIC는 서로 다른 스트림 사이에서 전달 단계의 상호 차단을 줄일 수 있지만, 신뢰성 있는 동일 스트림에서는 누락된 데이터를 기다려야 하며 여러 스트림이 네트워크 용량을 공유합니다. 혼잡 제어는 전체 전송 속도에 계속 영향을 미칩니다. 따라서 ‘HOL 블로킹 감소’를 패킷 손실 환경에서도 전혀 영향을 받지 않는다는 뜻으로 이해해서는 안 됩니다. 앱 내부의 요청 간 의존성 때문에 리소스 하나가 늦게 도착해 전체 페이지가 기다릴 수도 있습니다.

QUIC의 연결 식별 및 마이그레이션 기능은 네트워크가 바뀌어도 연결을 이어 갈 수 있는 기술적 기반을 제공하지만, 이 기능만으로 앱 사용이 계속된다고 보장할 수는 없습니다. 클라이언트에서 마이그레이션을 허용하는지, 서버가 새 경로를 어떻게 검증하는지, 기기의 백그라운드 권한과 NAT 매핑 상태가 어떤지에 따라 결과가 달라집니다. 네트워크를 바꾼 뒤 앱에서 세션을 다시 만드는 경우도 있습니다. 비교할 때는 클라이언트에 연결이 유지된다고 표시되는지만 보지 말고 실제 대상 앱이 계속 응답하는지 확인하세요. 회의나 다운로드가 반드시 이어진다고 단정할 수는 없습니다.

Hysteria2: 실제 경로에 맞는 전송 전략

Hysteria2 구현은 특정 네트워크 경로에 적합한 전송 전략을 사용할 수 있으며, 설정에서 예상 대역폭과 혼잡 제어 방식을 지정할 수도 있습니다. 관련 값은 높을수록 좋은 것이 아닙니다. 실제 경로의 가용 용량보다 전송 능력을 크게 설정하면 대기열과 패킷 손실, 재전송이 늘어나 같은 접속 네트워크의 다른 앱에도 영향을 줄 수 있습니다. 자동 감지와 직접 설정은 각각 전제 조건이 있으므로 패널에서 제공한 설정을 우선 사용하세요. 네트워크 경로와 무관한 대역폭 수치는 신뢰할 수 있는 기준이 될 수 없으므로 여기서는 제시하지 않습니다.

변동이 있는 네트워크 경로에서는 적극적인 전송 전략이 일부 지속 전송 성능을 개선할 수 있지만, 원래 없던 출구 용량을 만들어 내지는 못합니다. 로컬 무선 신호가 약할 때 전송량을 늘리면 상호작용 지연이 더 커질 수도 있습니다. 평가할 때는 다운로드 속도뿐 아니라 페이지 응답과 회의 음성, 기기 부담도 함께 확인하세요. 대용량 파일 전송은 개선됐지만 다른 앱이 눈에 띄게 느려졌다면 성능 향상의 당연한 대가로 여기지 말고 네트워크 대기열이 가득 찬 것은 아닌지 살펴보세요.

TUIC: 스트림과 데이터그램은 앱에 따라 다르게 처리

TUIC 역시 QUIC 전송을 이용해 프록시 트래픽을 전달하며, 구체적인 구현에 따라 스트림과 데이터그램을 다르게 처리할 수 있습니다. 스트림 요청은 데이터의 순서와 완전성을 중시하는 반면 실시간 음성·영상은 새 데이터가 제때 도착하는 편이 중요할 수 있습니다. 이미 시점을 놓친 데이터는 재전송해도 쓸모가 없을 수 있습니다. 데이터그램을 전달하는 방식이나 특정 데이터를 신뢰성 있는 스트림으로 처리하는지에 따라 대기 시간과 손실 사이의 균형이 달라집니다. 클라이언트에 표시된 이름만으로 동작을 완전히 알 수는 없으므로 설정 안내와 앱에서 나타나는 현상을 함께 확인하세요.

UDP를 정상적으로 사용할 수 있는 네트워크라면 QUIC 조합도 비교해 볼 만합니다. UDP를 제한하거나 방해하는 접속 환경에서는 TCP 조합보다 연결 수립이 더 어려울 수도 있습니다. TCP 기반 설정은 작동하지만 QUIC 설정은 연결 단계에서 오래 멈춰 있는 것이 대표적인 증상입니다. 이때는 인증 필드를 계속 수정하기보다 먼저 패널에서 제공하는 다른 전송 방식으로 사용을 복구하고, 로컬 네트워크에서 해당 트래픽을 허용하는지 확인하세요.

전송 방식만으로 성능을 보장한다고 단정하지 마세요

QUIC와 TCP는 각각 적합한 환경이 있습니다. 한 번 전환에 성공했다고 모든 네트워크에서 더 낫다는 뜻은 아니며, 연결 실패가 프로토콜 설계에 문제가 있다는 뜻도 아닙니다.

모바일 기기에서는 UDP 세션을 유지하기 위한 백그라운드 활동도 고려해야 합니다. 연결과 매핑 상태를 유지하려고 클라이언트가 연결 유지 신호를 보낼 수 있고, 기기는 이를 처리하기 위해 네트워크를 활성화해야 합니다. 대기 중 배터리 소모가 눈에 띄게 늘어난다면 백그라운드 규칙과 연결 유지 동작, 네트워크 신호를 함께 비교하세요. 똑같이 자주 활동하는 다른 QUIC 조합으로 바꾸는 것만으로는 해결되지 않을 수 있습니다. 안정적인 네트워크에서의 결과를 이동과 네트워크 전환이 잦은 통근 환경에 그대로 적용할 수도 없습니다.

연결 대기에는 여러 협상 단계가 포함됩니다

새 프록시 연결에는 도메인 조회와 하위 연결 수립, 보안 협상, 프록시 인증, 대상 연결 수립이 포함될 수 있습니다. 어느 한 단계의 응답이 느려도 앱이 진행되지 않는 것처럼 보일 수 있습니다. 클라이언트가 기록하는 연결 시간은 모든 단계를 포함하지 않을 수 있으며 앱에서 표시하는 페이지 로딩 시간에는 렌더링도 포함될 수 있습니다. 연결 속도를 비교할 때는 새 연결을 시작한 상태와 기존 프록시 세션, 대상 웹사이트의 리소스가 캐시된 상태를 구분하세요. 조건이 다른 결과를 한데 놓고 순위를 매기지 않는 편이 좋습니다.

연결을 재사용하면 후속 요청에서 반복 협상 단계를 줄일 수 있지만 공유 리소스와 관련된 장단점도 있습니다. 여러 요청이 기존 연결을 함께 사용하면 연결 수와 핸드셰이크 활동을 줄일 수 있습니다. 반면 하위 연결에 문제가 생기면 더 많은 요청이 동시에 영향을 받을 수도 있습니다. 연결 재사용이 적합한지는 프로토콜 구현과 대상 앱의 동작, 네트워크 상태에 따라 다릅니다. 첫 연결은 조금 느려도 이후 접속이 안정적이라면 계속 관찰하세요. 연결 재사용 후 모든 요청이 함께 멈춘다면 하위 세션이 정상인지 먼저 살펴보세요.

CPU, 메모리, 로그는 각각 다른 리소스 비용입니다

암·복호화에는 프로세서가 사용되고 트래픽 버퍼와 연결 상태에는 메모리가 필요합니다. 규칙 확인과 도메인 조회, 로그 기록에도 리소스가 소모됩니다. 하드웨어와 운영체제의 작업 배분 방식, 클라이언트 구현에 따라 비용이 달라집니다. 전송량이 많을 때 잠시 기기가 뜨거워지는 것만으로 프로토콜에 문제가 있다고 볼 수는 없습니다. 대기 중에도 계속 발열한다면 반복적인 재연결이나 상세 로그, 백그라운드 앱 요청을 확인하는 편이 좋습니다. 프로세스의 메모리 사용량만 비교해서 어느 프로토콜이 배터리를 덜 쓴다고 결론 내릴 수는 없습니다. 메모리는 지속적인 연산이 아니라 캐시에 사용될 수도 있습니다.

리소스 사용량을 테스트할 때는 앱 동작을 동일하게 유지해야 합니다. 브라우저 탭과 클라우드 동기화, 앱 업데이트, 동영상 재생은 추가 부하를 발생시켜 관찰 결과에 영향을 줍니다. 테스트와 무관한 대용량 전송을 먼저 중단한 뒤 클라이언트 연결 상태와 시스템 배터리 사용량을 기록하세요. 클라이언트에서 같은 오류가 계속 발생한다면 오류 원인을 먼저 해결하세요. 연결을 반복해서 시도하는 행위는 정상적인 세션을 유지하는 것보다 리소스를 더 많이 쓸 수 있습니다. 문제 해결이 끝나면 로그 수준을 평소 상태로 되돌리고 상세 로그를 계속 켜 둘 필요는 없습니다.

모바일 네트워크의 배터리 소모는 암호화만으로 결정되지 않습니다

모바일 기기의 무선 통신은 그 자체로 배터리를 사용합니다. 신호가 약한 곳에서 연결을 유지하거나 네트워크를 자주 전환하고, 통신 모듈을 짧은 간격으로 깨우면 배터리 소모가 늘어날 수 있습니다. 프록시 클라이언트가 연결 유지 신호를 자주 보내거나 재연결하고 백그라운드 앱 요청을 처리하면 이 부담이 더 커질 수 있습니다. 데스크톱에서 가볍게 작동하는 프로토콜이라고 해서 모바일 기기의 장시간 대기에도 적합하다는 뜻은 아닙니다. 한곳에 머무르는 Wi-Fi 환경과 이동 중 네트워크 환경은 따로 평가해야 합니다.

배터리 소모를 줄이려면 불필요한 활동부터 줄인 다음 프로토콜 조합을 비교하세요. 사용할 수 없는 네트워크 경로가 반복해서 재연결되는지, 상세 로그를 계속 켜 둔 것은 아닌지, 앱이 백그라운드에서 계속 다운로드하는지 확인하세요. 시스템 절전 제한으로 클라이언트가 일시 중지되면 화면에 다시 표시될 때 재연결이 필요할 수도 있습니다. 연결을 유지하려고 시스템 절전 기능을 무작정 모두 끄지 마세요. 백그라운드 권한 때문에 연결이 끊기는지, 네트워크 경로 세션 자체에 문제가 있는지 확인한 뒤 클라이언트 안내에 따라 필요한 권한만 조정하세요.

iOS의 네트워크 확장 기능과 Android의 백그라운드 관리 방식은 서로 다르므로 데스크톱의 상시 실행 프로세스 방식을 그대로 적용할 수 없습니다. 설치와 설정 가져오기 절차는 빠른 시작 가이드를 참고하세요. iPhone 사용자는 iOS 처음 시작하기 가이드도 확인할 수 있습니다. 플랫폼별 설정 메뉴는 달라질 수 있으므로 이 페이지에서는 판단 방법만 설명하며, 존재하지 않는 메뉴 위치나 클라이언트 버전을 임의로 안내하지 않습니다.

검증 가능한 배터리 소모 판단 기준 만들기

기기가 대기 상태였는지, 네트워크 신호가 안정적이었는지, 콘텐츠를 재생하고 있었는지, 클라이언트가 재연결했는지를 기록하세요. 평소 사용 환경을 먼저 관찰한 뒤 비슷한 조건에서 패널이 제공하는 다른 조합을 시험하세요. 백그라운드 동기화를 꺼서 개선된 것이라면 프로토콜의 효과로 볼 수 없습니다. 신호가 약할 때만 문제가 발생한다면 접속 환경을 먼저 살펴보세요. 최종 선택에서는 연결 복구와 배터리 소모를 함께 고려하세요. 리소스 목록에서 가장 작은 수치를 찾거나 일시적인 발열만으로 장기적인 결론을 내릴 필요는 없습니다.

지역 표시는 일반적으로 전체 경로가 아니라 출구를 나타냅니다

‘도쿄’나 ‘싱가포르’ 같은 네트워크 경로 이름은 보통 출구 지역이나 노드 위치를 가리키지만, 기기가 해당 도시와 직접 연결된다는 뜻은 아닙니다. 클라이언트는 먼저 진입점에 연결하고, 진입점에서 출구로 요청을 중계한 뒤 대상 서비스에 접속할 수 있습니다. 진입점과 출구가 서로 다른 네트워크에 있을 수 있고 이름에 모든 중간 단계가 표시되지 않을 수도 있습니다. 지역을 비교할 때는 대상 앱에 필요한 출구 위치와 기기에서 진입점까지의 연결 가능성을 따로 확인하세요. 출구가 적합해도 현재 접속 네트워크에서 진입점에 연결하기 어렵다면 사용 경험은 좋지 않을 수 있습니다.

직접 연결은 일반적으로 서비스 측에서 별도의 중계 계층을 두지 않고 기기가 대상 프록시 서버에 바로 연결하는 방식입니다. 경로를 이해하기 쉽고 처리 단계가 비교적 명확하지만 로컬 접속 네트워크와 원격 네트워크 간의 상호 연결 품질에 영향을 받습니다. 지리적으로 가깝다고 네트워크 경로까지 짧은 것은 아닙니다. 통신사 간 라우팅과 상호 연결 용량, 출구 정책에 따라 가까워 보이는 지역도 더 긴 경로를 거칠 수 있습니다.

중계는 단계를 추가하지만 경로를 개선할 수도 있습니다

중계는 별도의 진입점을 통해 요청을 출구로 전달하며, 접속과 후속 전송에 더 적합한 경로를 활용하는 것이 목적입니다. 처리와 전달 단계가 추가되지만 진입점에 연결하기 쉽고 이후 네트워크 연결이 안정적이라면 전체 사용 경험이 직접 연결보다 나을 수 있습니다. 반대로 중계 진입점이 혼잡하거나 후속 구간의 용량이 부족하면 전달 단계가 늘어난 만큼 대기 시간이 길어질 수 있습니다. ‘경유 횟수가 많다’는 이유만으로 더 느리다고 단정할 수 없으며 ‘중계’라는 말만으로 더 안정적이라고 볼 수도 없습니다.

중계 경로에서는 진입점과 후속 구간, 출구를 모두 확인해야 합니다. 기기에서 진입점까지 정상적으로 연결된다고 해서 이후 구간도 정상이라는 뜻은 아닙니다. 클라이언트 연결은 되지만 대상 웹사이트가 계속 대기한다면 후속 구간이나 출구에 문제가 있을 수 있습니다. 같은 진입점을 사용하는 여러 출구에서 동시에 문제가 생기면 공통 구간을 확인하세요. 대상 서비스 하나에서만 문제가 발생한다면 해당 서비스의 응답과 지역 조건, 도메인 조회 결과를 더 살펴봐야 합니다.

전용 회선은 경로의 특성이지 프로토콜의 종류가 아닙니다

전용 회선은 일반적으로 서비스 제공자가 특정 자원 구성을 적용한 전송 경로를 뜻합니다. 구체적인 접속 방식과 자원 공유 여부, 서비스 범위는 네트워크 경로 안내에서 확인해야 합니다. 전용 회선은 Trojan, VLESS, QUIC와 서로 배타적인 개념이 아닙니다. 전자는 경로 자원을 설명하고, 후자는 클라이언트와 서버가 데이터를 주고받는 방식을 설명합니다. 프로토콜 이름만으로 전용 회선 사용 여부를 알 수 없고, 지역 이름만으로 네트워크 등급을 판단할 수도 없습니다. VPNQB에서 제공하는 구체적인 경로 유형은 패널 안내를 기준으로 확인하세요. 일반적인 개념을 근거로 제공 범위를 확대해 설명하지 않습니다.

후속 구간에 별도로 마련된 회선을 사용하더라도 로컬 Wi-Fi와 진입점 접속, 출구에서 대상 웹사이트까지의 연결에는 변동이 생길 수 있습니다. 전용 회선이 로컬 신호 품질을 대신하거나 모든 앱에서 동일한 성능을 보장하는 것은 아닙니다. 경로를 선택할 때는 어느 구간을 개선하는지 확인한 뒤 실제 앱 사용에 도움이 되는지 살펴보세요. 회의처럼 상호작용이 필요한 앱에서는 안정적인 왕복 시간과 지터가 더 중요할 수 있고, 파일 전송에서는 지속적으로 사용할 수 있는 용량과 출구 경로를 더 살펴봐야 합니다.

왕복 경로를 모두 고려해야 합니다

네트워크 경로에는 방향성이 있습니다. 요청이 나가는 경로와 응답이 돌아오는 경로가 서로 다른 상호 연결을 거칠 수 있습니다. 업로드는 원활하지만 다운로드가 불안정하다고 해서 반드시 클라이언트 설정이 잘못된 것은 아닙니다. 반대로 다운로드는 정상인데 회의 중 음성 전송에 문제가 생긴다면 업로드 경로나 로컬 대기열이 원인일 수 있습니다. 클라이언트에서 진입점에 연결된다는 사실만으로 응답 경로와 출구 연결까지 정상이라고 증명할 수는 없습니다. 문제를 해결할 때는 데이터 전송 방향과 수신, 상호작용 응답을 나눠 살펴보고 모든 문제를 하나의 막연한 네트워크 상태로 뭉뚱그리지 마세요.

네트워크 경로 목록에서 먼저 대상 지역을 확인한 다음 실제 앱을 기준으로 진입점 조합을 선택하세요. 자주 사용하는 지역은 이용 가능한 대체 경로를 저장해 둘 수 있지만 이름만 다르고 동일한 공유 진입점을 거치는 선택지는 가급적 피하세요. 출장 중에는 접속 환경이 자주 바뀔 수 있습니다. 출장 중 네트워크 선택 안내를 참고해 호텔 Wi-Fi와 해외 업무 환경의 차이를 살펴보세요. 경로는 접속 환경이 달라질 때마다 다시 확인해야 하며, 한 번 선택한 뒤 계속 점검하지 않는 방식은 적절하지 않습니다.

패킷 손실의 원인은 여러 가지입니다

패킷 손실은 무선 접속과 라우터 대기열, 네트워크 간 상호 연결, 대상 서비스 측에서 발생할 수 있습니다. 무선 신호에 간섭이 있으면 기기가 데이터를 재전송하거나 전송량을 조절할 수 있어 앱에서는 명확한 오류보다 지연 시간의 변동으로 나타날 수 있습니다. 대기열 용량이 부족하면 혼잡을 줄이기 위해 일부 데이터가 폐기되고 신뢰성 있는 전송은 이후 복구를 시도합니다. 모든 패킷 손실을 네트워크 경로 문제로만 보면 흔한 원인인 로컬 네트워크를 놓칠 수 있습니다. 무작위로 바뀐 무선 신호 때문에 프로토콜 변경 효과를 잘못 판단할 수도 있습니다.

경로 진단에서 중간 장비가 응답하지 않아도 트래픽을 정상적으로 전달하지 않는다는 뜻은 아닙니다. 일부 장비는 진단 요청에 대한 응답 우선순위를 낮추거나 해당 탐색 요청에 응답하지 않습니다. 중간 구간에 이상이 표시되더라도 이후의 대상과 실제 앱이 정상 응답한다면 그 장비를 패킷 손실 지점으로 단정할 수 없습니다. 진단 도구는 단서를 제공할 뿐이며 실제 서비스에 미치는 영향을 판단할 때는 앱 동작과 최종 대상의 상태가 중요합니다. 중간 노드 표시만으로 결론을 내리지 마세요.

연결은 유지되는데 반응이 느리다면 대기열을 확인하세요

데이터 전송 요구량이 네트워크의 가용 용량을 초과하면 데이터가 대기열에 쌓입니다. 다운로드는 계속되는데 회의 음성이 늦게 도착하는 현상은 대용량 전송이 공유 대기열을 가득 채울 때 흔히 발생합니다. 연결 자체가 끊긴 것은 아니므로 클라이언트에는 계속 연결된 것으로 표시될 수 있습니다. 로컬 백그라운드 전송을 제한하거나 클라우드 동기화를 일시 중지한 뒤 상호작용 앱이 정상화되는지 확인하면 로컬 대기열 문제와 원격 혼잡을 구분하는 데 도움이 됩니다. 더 적극적으로 데이터를 전송하는 프로토콜로 바꾸면 오히려 대기 시간이 늘어날 수 있습니다.

지속 전송 속도와 상호작용 응답은 서로 다른 우선순위를 가집니다. 파일 전송은 최종적으로 온전하게 도착한다면 어느 정도 기다릴 수 있지만, 회의에서는 현재 내용을 제때 전달해야 합니다. 시간이 지난 데이터를 다시 받아도 사용 경험을 완전히 되돌릴 수는 없습니다. 신뢰성 있는 스트림은 데이터 완전성을 위해 재전송하는 반면 실시간 앱은 진행을 유지하기 위해 일부 손실을 허용할 수 있습니다. 프로토콜의 전달 방식과 앱의 전략이 함께 작용하므로 다운로드 속도로 통화 품질을 대신 판단하거나, 음성이 간혹 끊겼다는 이유만으로 전체 경로가 전혀 작동하지 않는다고 결론 내리지 마세요.

혼잡 시간대에는 공유 자원을 다시 확인해야 합니다

특정 시간대에 여러 네트워크 경로가 함께 느려지면 접속 네트워크나 공유 진입점, 네트워크 간 연결 용량에서 경쟁이 심해졌을 수 있습니다. 특정 출구만 느려진다면 출구나 대상까지의 경로에 더 가까운 문제일 수 있습니다. 같은 접속 네트워크에서 여러 진입점을 비교한 뒤 같은 대상 서비스에 대해 출구별 성능을 관찰하면 원인을 단계적으로 좁힐 수 있습니다. 저녁 시간에 한 번 접속이 실패했다고 서비스의 장기적인 성능을 단정할 수 없으며, 낮에 원활했던 기록이 모든 시간대의 성능을 설명하지도 않습니다. 관찰할 때 시간 조건을 함께 기록하세요.

혼잡 제어는 네트워크가 보내는 신호에 맞춰 전송량을 조정해 네트워크를 계속 가득 채우지 않도록 합니다. 구현 방식에 따라 변동이 있을 때 적용하는 전략이 다르므로 같은 경로에서도 프로토콜별 체감이 다를 수 있습니다. 하지만 프로토콜이 실제 용량 한계를 없애지는 못하며 더 적극적인 전송이 공유 네트워크에 적합하지 않을 수도 있습니다. 특정 조합에서 다운로드가 빨라진 대신 다른 앱이 모두 느려졌다면 이 부작용도 선택 기준에 포함하세요. 안정적인 사용을 위해서는 한 번의 전송이 리소스를 독점하게 하기보다 여러 앱의 동시 사용도 고려해야 합니다.

캡슐화와 경로 MTU가 미치는 영향

추가 캡슐화는 데이터 패킷에서 사용할 수 있는 공간을 차지하며 네트워크에 따라 경로가 전달할 수 있는 실제 데이터 크기도 달라질 수 있습니다. 작은 요청은 정상인데 큰 페이지를 열거나 파일을 업로드할 때 멈춘다면 경로 MTU와 분할 처리를 점검할 수 있습니다. 다만 온라인에서 흔히 볼 수 있는 고정값을 곧바로 입력하지 마세요. 클라이언트마다 트래픽 처리 방식이 다르고 설정을 바꿔야 하는 위치도 다릅니다. 먼저 패널과 클라이언트의 기본 설정을 사용한 뒤 접속 네트워크를 바꾸거나 원래 설정으로 되돌려 캡슐화 경로와 관련이 있는지 확인하세요.

보안 전송과 가상 인터페이스, 데이터그램 캡슐화가 함께 적용되면 특정 앱이나 큰 요청에서만 문제가 나타날 수 있습니다. 대상 서버가 업로드를 거부한 경우와 앱 요청 시간 초과, 네트워크 전송 정지를 구분하세요. 첫 번째는 보통 앱에서 안내를 표시하고, 나머지는 클라이언트 로그와 다른 대상의 동작을 함께 확인해야 합니다. 웹사이트 하나에서만 업로드가 실패하는 경우 전체 MTU를 바로 바꾸지 마세요. 여러 대상에서 비슷한 전송이 실패하고 접속 네트워크를 바꾸면 해결되는 경우라면 경로 조건을 더 살펴볼 필요가 있습니다.

범위를 좁혀 문제 원인 찾기

같은 기기에서 접속 네트워크 바꾸기, 같은 네트워크에서 진입점 바꾸기, 같은 진입점에서 대상 바꾸기는 각각 다른 질문에 답합니다. 매번 조건을 하나씩만 바꾸고 기존에 작동하던 설정은 보관하세요. 일시적으로 복구된 것을 근본 원인이 해결된 것으로 오해하지 않도록 합니다.

지원 요청을 제출할 때는 ‘속도가 느리다’고만 쓰기보다 접속 네트워크와 이용 지역, 문제가 발생한 시간대, 대상 앱, 오류 종류를 함께 적어 주세요. 필요한 경우 확인한 로그 일부를 첨부하되 구독 링크와 인증 정보, 계정 정보는 삭제해야 합니다. 지원은 사용자 패널의 문의 티켓에서 받을 수 있습니다. 로그는 연결 단계 문제를 찾기 위한 자료이며 설정 전체를 공개해도 된다는 뜻은 아닙니다.

웹 브라우징, AI 도구, API 요청

일반적인 웹 브라우징에서는 첫 응답과 도메인 조회, 여러 리소스의 병렬 로딩이 중요합니다. 현재 접속 네트워크에서 안정적으로 연결되는 조합을 우선 선택하고, 페이지 열기와 페이지 간 이동이 원활한지 확인한 뒤 프로토콜 변경을 고려하세요. AI 도구와 응답 시간이 긴 API는 대상 지역과 계정 권한, 서버 세션의 영향도 받습니다. 페이지는 열리지만 요청이 중간에 끝난다고 해서 반드시 프록시 인증 문제는 아닙니다. 먼저 대상 서비스에서 현재 계정과 지역을 사용할 수 있는지 확인한 뒤 대기 중에 클라이언트나 네트워크가 연결을 종료하는지 살펴보세요.

AI 페이지에 로그인했지만 일부 콘텐츠가 표시되지 않는다면 주요 요청이 실패했는지 부가 도메인 요청이 실패했는지 살펴보고 관련 요청이 규칙에 따라 서로 다른 경로로 분리됐는지 확인하세요. 규칙 모드 변경은 임시 진단 방법으로 사용할 수 있지만 원인을 모르는 상태에서 전체 트래픽의 경로를 장기간 바꾸는 것은 바람직하지 않습니다. 같은 요청 오류가 반복되면 대상 서비스가 표시한 안내와 클라이언트 오류가 동시에 나타났는지 기록하세요. 앱에서 접근을 거부했다고 명시한다면 프로토콜을 바꿔도 대상 서비스의 이용 조건을 대신 충족할 수 없습니다.

스트리밍, 다운로드, 회의는 각각 따로 확인하세요

스트리밍을 이용하려면 지역과 계정, 콘텐츠 목록, 지속 전송 조건이 모두 맞아야 합니다. 출구 지역이 올바르더라도 대상 플랫폼이 현재 출구를 허용한다는 보장은 없으며 프로토콜 이름만으로 콘텐츠 이용을 보장할 수도 없습니다. 재생을 시작한 뒤 버퍼링이 계속되는지와 화질이 안정적인지, 재생 위치를 이동한 뒤 정상적으로 이어지는지 확인하세요. 콘텐츠 목록과 화질에 관한 배경 정보는 스트리밍 이용 안내와 Netflix 지역별 콘텐츠 및 화질 안내에서 확인할 수 있습니다. 이 문서는 전송 상태를 판단하는 방법만 다루며 검증되지 않은 이용 가능 여부를 보장하지 않습니다.

다운로드는 시작 순간이 아니라 진행 중의 상태를 확인하고, 회의는 음성 송수신과 상호작용 대기 시간을 함께 살펴보세요. 회의에 문제가 있지만 웹페이지는 정상이라면 데이터그램 지원과 로컬 업로드 대기열을 먼저 확인하세요. 모든 앱이 느리다면 진입점과 접속 네트워크를 비교하세요. 출장 중에는 네트워크 환경이 바뀔 때마다 자주 사용하는 앱을 다시 확인해야 합니다. 특히 공유 Wi-Fi의 네트워크 로그인을 완료하기 전에는 클라이언트 연결 실패를 구독 정보가 만료된 것으로 판단하지 마세요.

복구 가능한 문제 해결 순서 세우기

먼저 문제와 관계없는 백그라운드 전송을 중지하고 기기 시간과 접속 네트워크가 정상인지 확인한 뒤 사용자 패널에서 구독 정보를 업데이트하세요. 기본 설정을 그대로 유지하면서 기존에 작동했던 네트워크 경로에서 다시 시도합니다. 실패하면 패널에서 제공하는 대체 진입점을 선택하세요. 이후 클라이언트에서 연결을 수립하지 못한 경우와 연결 후 대상 서비스가 실패한 경우, 전송 중 문제가 생긴 경우를 구분합니다. 사용을 복구할 수 있는 설정은 보관하고 이후에 비교하세요. 매번 실패할 때마다 프로토콜과 지역, 규칙, 보안 검증을 한꺼번에 바꾸지 마세요.

구독을 업데이트한 뒤에도 특정 네트워크 경로만 실패하고 다른 경로는 정상이라면 해당 설정과 진입점으로 문제 범위를 좁힐 수 있습니다. 모든 경로에서 연결할 수 없다면 네트워크 로그인 상태와 클라이언트 권한, 구독 정보가 제대로 가져와졌는지 먼저 확인하세요. 클라이언트 연결은 정상이지만 대상 서비스가 요청을 거부한다면 서비스 안내와 지역 조건을 살펴보세요. 대기 모드에서 돌아온 뒤에만 문제가 발생한다면 백그라운드 권한과 연결 유지 항목을 확인하세요. 이 단계는 다음에 할 일을 정하기 위한 안내이며 사용자가 모든 프로토콜 용어를 먼저 익혀야 한다는 뜻은 아닙니다.

데이터 사용량은 요금제로, 경로 문제는 네트워크 경로로 해결하세요

요금제 데이터 용량과 프로토콜 성능은 서로 다른 기준입니다. 네트워크 경로에 문제가 있다고 해서 요금제를 업그레이드해야 한다고 단정하지 마세요. VPNQB 월간 요금제는 ¥9.9/월에 60GB, ¥18/월에 250GB, ¥28/월에 500GB를 제공합니다. 데이터는 가입일 기준으로 매월 초기화되며 중간에 요금제를 업그레이드하면 차액은 남은 일수에 따라 계산됩니다. 데이터 추가 구매분은 모두 사용할 때까지 유효하며 만료되지 않습니다. 가격은 ¥158/300GB, ¥358/1000GB, ¥658/3000GB입니다. 결제 방식은 요금제 페이지에서 확인한 뒤 평소 사용량에 맞춰 선택하세요. 짧은 시간의 속도 측정만으로 전체 사용량을 추정하지 마세요.

VPNQB는 Windows / macOS / iOS / Android / Linux를 지원하며 기기 수에 제한이 없습니다. 계정 생성 시 이메일 주소가 필요하지 않으며 사용자 이름과 비밀번호만 있으면 됩니다. Alipay / WeChat / USDT로 결제할 수 있고 14일 무조건 환불을 제공합니다. 기술 비교의 목적은 명확히 안내된 사실과 현재 사용할 수 있는 설정 안에서 적합한 이용 방식을 찾는 것이지, 최신 프로토콜 이름을 좇는 것이 아닙니다. 문제가 계속 해결되지 않는다면 접속 환경과 오류가 발생한 단계, 이미 시도한 방법을 정리해 지원 페이지로 문의하면 같은 점검을 반복하는 일을 줄일 수 있습니다.

관련 안내

설치와 설정 가져오기는 빠른 시작 가이드를, 지역 선택은 네트워크 경로 목록을, 사용량과 결제는 요금제 안내를 참고하세요. 이 페이지는 차이를 이해하고 판단 기준을 세우기 위한 안내이며 패널에 표시된 최신 설정과 네트워크 경로 안내를 대신하지 않습니다.