프록시 프로토콜
및 회선 선택

연결 모델과 사용 경험 지표

프로토콜, 전송 방식, 회선을 구분해서 보기

프록시 프로토콜은 클라이언트와 서버가 서로를 식별하고, 목적지 주소를 지정하며, 데이터를 전달하는 방식을 설명합니다. 전송 계층은 데이터가 네트워크를 통과하는 방법을 담당하고, 회선은 데이터가 실제로 이동하는 경로입니다. 서로 관련은 있지만 같은 개념은 아닙니다. 노드 이름에 특정 프로토콜이 표시되어도 회선 경로나 전용 대역폭 사용 여부를 알 수는 없습니다. 연결 성능을 판단할 때는 프로토콜 이름, 하위 전송 방식, 진입 지역, 출구 지역을 따로 기록해 막연히 ‘빠르다’는 평가에 여러 특성을 섞지 않도록 하세요.

웹페이지에 접속할 때는 보통 이름 확인, 연결 설정, 보안 협상, 요청 전송, 콘텐츠 수신 과정을 거칩니다. 프록시는 이 과정의 일부일 뿐입니다. 대상 웹사이트의 응답이 늦거나, 로컬 무선 네트워크가 혼잡하거나, 클라이언트 규칙이 잘못 적용되어도 페이지가 늦게 표시될 수 있습니다. 프로토콜을 바꾸면 연결 설정과 전송 방식은 달라질 수 있지만, 대상 서버의 처리 속도까지 빨라지는 것은 아닙니다. 연결 전과 후 중 어느 단계에서 문제가 생기는지 먼저 구분하면 점검 방향을 잡기 쉽습니다.

프록시 진입점과 최종 출구도 구분해야 합니다. 클라이언트가 처음 연결하는 서버 주소는 진입점일 뿐, 이후 중계 구간을 거쳐 출구에서 대상 사이트에 접속할 수 있습니다. 진입점이 사용자와 가깝다고 출구까지 가까운 것은 아니며, 출구가 대상 지역에 있다고 중간 경로가 직선인 것도 아닙니다. 애플리케이션에는 대개 출구 주소가 표시되지만, 클라이언트 연결 검사는 진입점이나 프록시 서비스의 일부만 확인할 수 있습니다. 따라서 두 결과를 단순 비교해서는 안 됩니다.

연결 속도, 다운로드 속도, 응답성은 서로 다른 문제입니다

연결 설정 속도는 페이지를 처음 열거나 앱이 네트워크에 다시 연결하거나 짧은 요청을 보낼 때의 대기 시간에 영향을 줍니다. 지속 처리량은 대용량 파일 다운로드와 동영상 버퍼링에 영향을 줍니다. 조작 반응성은 왕복 지연 시간과 지터, 패킷 손실 복구에 더 크게 좌우됩니다. 다운로드 성능이 좋은 회선도 원격 데스크톱에서는 조작 반응이 답답할 수 있습니다. 반대로 전체 처리량은 두드러지지 않아도 문자 대화와 일반 웹 이용이 더 안정적인 회선도 있습니다. 모순이 아니라 서비스마다 네트워크에 요구하는 조건이 다른 것입니다.

연결 재사용도 체감에 영향을 줍니다. 브라우저는 기존 연결을 이어 쓸 수 있고, 클라이언트는 여러 앱의 요청을 하나의 공유 채널에 담을 수도 있습니다. 이때 페이지를 다시 열었을 때 연결이 빨라 보인다고 해서 새 연결도 똑같이 빠르다는 뜻은 아닙니다. 네트워크를 바꾸거나 기기를 깨우거나 출구를 바꾼 직후에는 연결 상태를 새로 설정해야 하므로 대기가 더 길어질 수 있습니다. 비교할 때는 기존 연결을 계속 사용했는지, 연결을 끊은 상태에서 새로 시작했는지 함께 기록하세요.

클라이언트에 표시되는 지연 시간은 먼저 측정 방식을 확인해야 합니다. 노드 주소와의 연결만 확인하는 도구도 있고, 프록시를 통해 지정한 웹페이지에 요청을 보내는 도구도 있으며, 보안 협상과 대상 서버 응답까지 포함하는 도구도 있습니다. 각 도구는 서로 다른 경로를 측정할 수 있으므로 결과만으로 프로토콜 순위를 매길 수 없습니다. 같은 클라이언트와 검사 대상, 비슷한 네트워크 환경을 유지하면서 실제 사용 경험을 함께 살펴보세요. 더 작아 보이는 숫자만 좇는 것보다 신뢰할 만한 방법입니다.

기술 가이드는 현재 판매 중인 설정 목록이 아닙니다

이 페이지에서 다루는 프로토콜은 일반적인 기술 방식을 설명하기 위한 것으로, OEMVPN의 모든 회선에서 이 조합을 제공한다는 의미는 아닙니다. 실제 프로토콜과 전송 방식, 선택 가능한 노드는 로그인 후 패널과 클라이언트에서 가져온 구독 정보를 기준으로 확인하세요. OEMVPN은 110+개 국가 / 210+개 회선을 지원합니다. 이 범위는 제공 지역의 폭을 뜻하며, 모든 지역의 구조와 대역폭 조건 또는 대상 플랫폼 성능이 같다는 뜻은 아닙니다.

구독을 가져온 뒤에는 서비스에서 제공한 설정을 우선 유지하세요. 전송 방식이나 암호화 방식, 핸드셰이크 필드를 직접 바꾸면 클라이언트와 서버 설정이 맞지 않을 수 있습니다. 프로토콜 이름이 같아도 구현 방식과 하위 전송, 서버 설정이 다르면 서로 연결되지 않을 수 있습니다. 명확한 설정 안내가 없다면 온라인에서 찾은 설정의 값을 기존 노드에 옮기지 마세요. 연결할 수 없다는 이유만으로 프로토콜 자체가 불안정하다고 단정해서도 안 됩니다.

비교 대상은 ‘클라이언트, 프로토콜, 전송 방식, 회선’을 모두 포함한 조합이어야 합니다. 프로토콜 이름만 비교하면 경로 품질이나 대상 서비스의 차이를 프로토콜 성능으로 잘못 판단하기 쉽습니다.

다음 장을 읽을 때는 일정한 순서로 점검해 보세요. 먼저 클라이언트가 구독 설정을 올바르게 해석하는지 확인하고, 현재 네트워크에서 전송 방식에 연결할 수 있는지 살펴본 다음, 진입점에서 출구까지의 경로를 확인하고 마지막으로 대상 서비스를 검증합니다. 이 순서로 진행하면 불필요한 설정 변경을 줄일 수 있습니다. 현재 지역의 노드 목록은 회선 페이지에서 확인하세요. 설치와 가져오기 방법이 필요하다면 초보자 가이드로 돌아가면 됩니다. 프로토콜 원리에서 클라이언트 버튼 위치를 찾을 필요는 없습니다.

Shadowsocks와 VMess의 설계 차이

Shadowsocks: 기본 프로토콜과 추가 계층 이해하기

Shadowsocks는 앱 트래픽을 암호화된 프록시를 거쳐 목적지 주소로 전달하는 데 사용됩니다. 프록시 전송을 중심으로 설계되어 있어 모든 사용 방식에 웹 전송과 같은 외형을 덧붙일 필요는 없습니다. 최신 인증 암호화 방식을 사용하면 해당 메커니즘이 데이터의 기밀성과 무결성을 함께 보호합니다. 실제 설정의 암호화 방식은 서버 설정과 일치해야 합니다. 이름이 더 강력해 보인다는 이유만으로 클라이언트 설정만 바꾸면 안 됩니다.

구조가 비교적 단순해 보일 수 있지만, ‘단순하다’고 해서 리소스 사용량이 반드시 가장 적은 것은 아닙니다. 암호화 구현이 기기 명령어를 활용하는지, 클라이언트가 버퍼를 어떻게 처리하는지, 플러그인이나 외부 전송 계층을 추가했는지에 따라 실제 부하가 달라집니다. 저전력 기기는 프로세서 성능에 영향을 받을 수 있고, 데스크톱 기기는 회선 상태가 주요 제한 요인일 수 있습니다. 추가 전송 구성요소를 사용한다면 해당 구성요소의 핸드셰이크와 캡슐화, 유지 관리 비용도 함께 고려해야 합니다.

UDP 지원 여부도 프로토콜 이름만 보고 판단할 수 없습니다. 프로토콜 기능과 서버의 전달 설정, 클라이언트 구현, 앱의 연결 방식이 모두 맞아야 합니다. 클라이언트가 시스템 프록시를 통해 웹 트래픽을 처리한다고 해서 시스템의 모든 UDP 트래픽도 자동으로 프록시를 통과하는 것은 아닙니다. 웹은 정상인데 실시간 음성 통화가 이상하다면 암호화 방식을 먼저 바꾸기보다 트래픽 처리 방식과 규칙을 확인한 뒤 서버가 해당 전달을 허용하는지 점검하세요.

VMess: 인증 정보와 전송 방식을 함께 이해하기

VMess에는 사용자 인증과 데이터 전송을 위한 설계가 포함되어 있으며, 다양한 라우팅 기능을 지원하는 프록시 클라이언트에서 흔히 사용됩니다. 여러 외부 전송 방식과 조합할 수 있어 VMess라고 표시된 노드라도 연결 동작은 서로 다를 수 있습니다. 직접 전송, 웹 관련 전송 방식 사용, TLS 추가 적용은 핸드셰이크 경로와 연결 재사용, 중간 장비 호환성에서 차이가 있습니다. 하나의 성능 결론으로 묶을 수 없습니다.

인증 필드와 시간 설정, 보안 옵션이 서로 맞아야 합니다. 일부 인증 절차는 시스템 시간이 크게 어긋나면 영향을 받을 수 있으므로 인증 실패가 반복된다면 기기 시간이 자동으로 동기화되는지 확인하세요. 서버 주소를 확인할 수 있고 포트에 연결할 수 있어도 인증이 완료된 것은 아닙니다. 클라이언트 로그에 인증 관련 메시지가 있다면 연결 검사 결과를 새로 고치기보다 구독 정보와 시스템 상태를 먼저 확인하세요.

추가 캡슐화는 특정 배포 환경과의 호환성을 높일 수 있지만 구조를 복잡하게 만들기도 합니다. 리버스 프록시나 다른 전달 구성요소를 거친다면 경로와 호스트 필드, 전달 규칙도 서로 맞아야 합니다. 설정 오류는 실제 프록시 인증이 시작되기 전에 발생할 수도 있습니다. 일반 사용자라면 항목을 하나씩 이해한 뒤 직접 조합하기보다 서비스에서 제공한 전체 설정을 정확히 가져오는 편이 안전합니다. 원리를 이해하면 문제 발생 지점을 구분하는 데 도움이 됩니다.

리소스 사용량은 같은 조건에서 비교하세요

이 프로토콜들을 비교할 때는 가능한 한 같은 기기와 비슷한 출구 경로를 사용하세요. 프로토콜과 지역, 클라이언트 코어를 동시에 바꾸면 경험이 달라진 이유를 알기 어렵습니다. 대상 웹사이트를 고정한 뒤 연결이 안정적으로 설정되는지, 계속 이용하는 동안 멈춤이 생기는지 확인하고, 마지막으로 클라이언트의 프로세서 사용량과 기기 온도를 살펴보세요. 한 번 연결에 성공했다는 사실은 그 시점에 사용할 수 있었다는 뜻일 뿐, 지속적인 사용 경험을 대신하지 않습니다.

메모리 사용량도 연결 수와 버퍼 정책의 영향을 받습니다. 브라우저에서 많은 페이지를 열거나 동기화 도구가 계속 업로드하거나 다운로드 작업이 장시간 연결을 유지하면 클라이언트 부하가 커집니다. 복잡한 작업 중에만 메모리 사용량이 늘어난다면 프로토콜 탓으로 단정할 수 없습니다. 불필요한 작업을 종료한 뒤 다시 확인하고, 연결이 해제되지 않거나 로그가 계속 증가하는지도 살펴보세요. 기본 설정을 유지하면 서로 다른 시점의 결과를 비교하기 쉽습니다.

이미 안정적으로 설정되어 있고 주로 일상적인 웹 이용에 쓴다면 프로토콜 이름이 새롭다는 이유만으로 옮길 필요는 없습니다. 클라이언트 호환성이나 UDP 전달, 인증에 실제 문제가 생겼을 때 해당 문제 단계에 맞는 대안을 찾아보세요. 기술은 이름이 복잡한지가 아니라 현재 기기와 네트워크에 적합한지가 중요합니다. 설정을 바꿀 때는 기존에 작동하던 설정을 복구용으로 남겨 두고, 필요한 서비스가 정상 작동하는지 확인한 뒤 장기적으로 사용할지 결정하세요.

Trojan과 VLESS의 보안 경계

Trojan: TLS 보호와 인증서 검증

Trojan은 일반적으로 TLS로 보안 채널을 설정한 뒤, 그 안에서 프록시 인증과 데이터 전달을 수행합니다. 이해할 때는 프록시 프로토콜과 TLS라는 두 계층을 함께 살펴봐야 합니다. TLS는 전송을 보호하고 서버 신원을 확인하며, 프록시 인증은 접속 정보가 유효한지 판단합니다. 한 단계가 완료되어도 다른 단계까지 완료된 것은 아닙니다. 연결에 실패했다면 인증서 오류와 핸드셰이크 오류, 인증 오류를 구분하세요.

인증서 검증은 임의로 건너뛰어도 되는 번거로운 절차가 아닙니다. 클라이언트는 보통 서버 이름이 인증서와 일치하는지 확인하고, 인증서 체인을 신뢰할 수 있는지 검사해야 합니다. 오류를 잠시 없애려고 검증을 끄면 원래의 신원 확인 기능이 약해집니다. 문제가 생기면 구독 정보를 업데이트하고 시스템 시간과 서버 이름을 확인한 뒤 서비스 지원 채널을 통해 설정을 확인하세요. 낯선 안내에서 말하는 ‘검증 건너뛰기’를 일반적인 최적화 방법으로 받아들이지 마세요.

TLS 협상에도 비용이 들지만, 그렇다고 모든 환경에서 Trojan이 더 느리다고 볼 수는 없습니다. 연결 재사용 여부와 세션 복구 여부, 기기의 암호화 처리 성능, 요청 크기에 따라 추가 비용의 비중이 달라집니다. 지속적인 다운로드나 장시간 세션에서는 최초 협상이 주요 병목이 아닐 수 있습니다. 반면 자주 깨어나는 앱이 짧은 연결을 반복해서 설정한다면 핸드셰이크와 복구 동작을 살펴볼 필요가 있습니다.

VLESS: 가벼운 인증 계층이 별도의 암호화 계층을 뜻하지는 않습니다

VLESS는 가벼운 프록시 인증 계층과 데이터 전송을 분리해 설계되었습니다. VLESS 자체는 전통적인 의미의 데이터 암호화를 제공하지 않으며, 실제 보안은 함께 사용하는 보안 전송 방식에 달려 있습니다. VLESS라는 이름만 보고 설정에 사용자 식별 정보가 있으니 데이터도 완전히 암호화되었다고 생각해서는 안 됩니다. 사용자 식별 정보는 접속 주체를 확인하고, 전송 보호는 네트워크를 지나는 데이터를 안전하게 다룹니다. 두 기능의 역할은 다릅니다.

VLESS는 여러 전송 및 보안 방식과 조합해 배포할 수 있습니다. 외부 계층에 따라 연결 설정 경로와 호환성이 달라질 수 있습니다. 따라서 리소스 사용량을 논할 때는 외부 계층을 무시하고 프록시 프로토콜만 봐서는 안 됩니다. 가벼운 인증 계층에 복잡한 캡슐화를 조합하면 전체 구조가 다른 방식보다 단순하지 않을 수 있습니다. 반대로 서로 잘 맞는 구현은 불필요한 중복 처리를 줄일 수도 있습니다. 이름만이 아니라 전체 설정을 비교하세요.

일부 조합에는 특정 흐름 제어나 핸드셰이크 관련 매개변수가 포함됩니다. 일반적으로 이러한 매개변수는 클라이언트와 서버가 모두 지원해야 하며, 마음대로 바꿔 쓸 수 있는 속도 조절 옵션이 아닙니다. 가져온 뒤 ‘지원하지 않음’ 또는 해석 불가 메시지가 나타나면 클라이언트가 구독에 포함된 조합을 지원하는지 확인한 다음 서비스 지원 채널에 호환 설정을 문의하세요. 이해하지 못한 항목을 삭제해 억지로 가져오면 설정이 적용된 것처럼 보여도 실제로는 작동하지 않을 수 있습니다.

암호화가 끝나는 지점과 앱 자체 보호를 구분하기

프록시 채널은 클라이언트와 프록시 서비스 관련 종단 사이의 데이터 전송을 보호합니다. 앱에서 HTTPS를 사용한다면 브라우저나 앱과 대상 서비스 사이에도 별도의 암호화가 적용됩니다. 두 보호 계층은 종단이 서로 다르므로 프록시 암호화가 모든 보안 문제를 해결한다고 볼 수 없습니다. 계정 비밀번호는 대상 서비스의 올바른 페이지에만 입력해야 합니다. 낯선 웹사이트와 위조된 로그인 화면, 악성 파일은 특정 프록시 프로토콜을 사용한다고 해서 위험이 사라지지 않습니다.

인증서 검증을 유지하고 구독에서 제공한 설정을 사용하세요. 문제를 해결할 때는 실패한 단계를 찾아야 합니다. 겉으로 연결되는 것처럼 보이게 하려고 보안 검사를 먼저 끄지 마세요.

DNS도 별도로 점검해야 합니다. 클라이언트가 DNS 요청을 프록시로 보내는지, 앱이 자체 암호화 DNS를 사용하는지, 시스템이 캐시를 사용하는지에 따라 도메인 요청 경로가 달라질 수 있습니다. 웹페이지 하나가 열린다고 모든 DNS 요청이 예상대로 처리된다는 뜻은 아닙니다. DNS 검사 결과가 다르다고 해서 프록시 채널이 고장 난 것도 아닐 수 있습니다. 클라이언트의 DNS 정책과 실제 적용 규칙을 함께 확인하고, 인증서나 인증, 회선 품질과 관련 없는 문제를 한데 묶지 마세요.

프로토콜을 선택할 때는 인증서 관리와 클라이언트 지원 범위, 기존 설정의 안정성을 주요 기준으로 삼을 수 있습니다. TLS 방식이 이미 안정적으로 작동한다면 이름이 다른 방식으로 옮긴다고 개인정보 보호가 강화되거나 지연 시간이 줄어드는 것은 아닙니다. OEMVPN의 주요 보안 정책은 로그 미보관 정책입니다. 프로토콜 암호화와 서비스 정책은 별도로 이해해야 합니다. 계정과 구독 링크를 안전하게 관리하는 방법은 VPN 보안 기초에서 확인하세요. 전송 계층 보호를 계정 관리의 대안으로 여겨서는 안 됩니다.

Hysteria2와 TUIC의 전송 특성

QUIC 기반의 안정적인 데이터 전송

Hysteria2와 TUIC는 모두 QUIC 기술과 관련이 있으며, 일반적으로 UDP 위에서 암호화와 연결 상태, 안정적인 스트림 전송을 구성합니다. 여기서 UDP는 하위 전송 방식일 뿐, 앱이 받은 데이터에 누락이 생겨도 된다는 뜻은 아닙니다. 안정적인 바이트 스트림을 제공하려면 확인 응답과 재전송, 혼잡 제어가 필요합니다. 다만 이러한 기능이 기존 TCP 스택과 같은 방식으로 제공되지는 않습니다. 이 점을 이해하면 ‘UDP를 사용하니 패킷 손실을 기다릴 필요가 없다’고 오해하지 않을 수 있습니다.

QUIC은 하나의 연결에서 서로 비교적 독립적인 데이터 스트림을 관리해 스트림 간 순서 보장으로 발생하는 대기를 줄일 수 있습니다. 그렇다고 스트림이 서로 완전히 영향을 주지 않는 것은 아닙니다. 이들은 출구 대역폭과 혼잡 상태, 기기 리소스를 공유할 수 있습니다. 경로가 심하게 혼잡하면 앱은 여전히 느려집니다. 대용량 다운로드가 웹 이용에 영향을 주는지는 클라이언트의 연결 재사용 방식과 스케줄링, 회선이 부하 한계에 얼마나 가까운지에 따라 달라집니다.

암호화와 연결 협상에도 전제 조건이 있습니다. 클라이언트가 서버의 UDP 경로에 올바르게 접속할 수 있어야 하고, 관련 네트워크 장비가 세션을 계속 유지할 수 있어야 합니다. 일부 네트워크에서는 TCP 기반 서비스에 접속할 수 있어도 UDP 전달이나 속도 제한 정책은 다를 수 있습니다. 이런 경우 프로토콜 매개변수만 조정해서 해결하기는 어렵습니다. 먼저 현재 네트워크와 다른 접속 방식의 성능을 비교한 뒤 전송 방식을 바꿔야 할지 판단하세요.

Hysteria2: 대역폭 판단에 유의하세요

Hysteria2는 특정 경로 조건을 고려한 전송 설계를 제공하며, 혼잡 제어 동작과 설정 방식은 구현에 맞춰 이해해야 합니다. 설정에 업로드·다운로드 대역폭 안내값이 포함되어 있다면 실제 접속 환경에 맞춰야 합니다. 값을 크게 적을수록 좋은 것은 아닙니다. 전송 예상치를 너무 높게 잡으면 로컬 대기열이 길어져 상호작용 요청이 더 느려질 수 있고, 너무 낮게 잡으면 사용 가능한 처리량이 제한될 수 있습니다. 서비스에서 매개변수를 제공했다면 먼저 기존 값을 유지하고, 문제가 어디서 발생하는지 확인한 뒤 조정을 검토하세요.

패킷 손실 환경에서의 처리량은 이런 방식이 주목받는 이유 중 하나지만, 패킷 손실의 원인은 여러 가지입니다. 무선 간섭으로 발생하는 무작위 손실과 출구 혼잡으로 계속 버려지는 패킷은 같은 방식으로 설명할 수 없습니다. 무작위 손실은 적절한 전송 복구로 개선될 수 있지만, 혼잡이 발생하면 송신 측은 다른 트래픽과 제한된 용량을 나눠 써야 합니다. 프로토콜이 물리적 대역폭을 늘리거나 로컬 네트워크와 상위 경로 점검을 대신해 줄 수는 없습니다.

업로드와 다운로드도 따로 살펴보세요. 가정용 인터넷은 방향별 성능이 다를 수 있습니다. 클라우드 드라이브에 파일을 업로드하면 확인 응답과 다른 요청이 지나는 경로가 혼잡해져 다운로드나 웹 응답도 느려질 수 있습니다. 업로드 중에만 문제가 생긴다면 프로토콜을 바꾸기 전에 백그라운드 업로드를 제한하고 라우터의 대기열을 확인하세요. 다운로드 최고 속도만 보면 일상 사용에 실제로 영향을 주는 업로드 혼잡을 놓치기 쉽습니다.

TUIC: 연결 재사용, 복구, 네트워크 전환

TUIC도 QUIC의 연결 및 다중 스트림 전송 기능을 활용하며, 실제 사용 경험은 인증과 트래픽 전달 방식, 클라이언트 구현에 따라 달라집니다. 연결을 재사용하는지, 유휴 연결을 어떻게 처리하는지, 데이터그램을 어떻게 전달하는지에 따라 리소스 사용과 앱 호환성이 달라질 수 있습니다. Hysteria2와 이름만 다른 대체 방식으로 보면 안 됩니다. 관련 기술 경로를 공유하더라도 매개변수의 의미와 혼잡 동작, 오류 메시지까지 그대로 바꿔 쓸 수 있는 것은 아닙니다.

모바일 네트워크가 바뀔 때 QUIC의 연결 식별 메커니즘은 경로 변경을 지원하는 기술적 기반이 됩니다. 하지만 앱이 실제로 끊김 없이 이어지는지는 클라이언트와 서버, 접속 네트워크의 영향을 받습니다. 무선 네트워크에서 모바일 네트워크로 전환하면 기존 경로가 끊기고 새 경로를 확인하는 과정, 시스템의 백그라운드 제한 때문에 대기가 생길 수 있습니다. 하위 계층이 연결 이전을 지원한다고 전환 중 모든 서비스가 끊김 없이 작동한다고 보장할 수는 없습니다. 실제로 확인하려면 기기 화면을 잠그고 다시 켜는 과정과 네트워크 전환 후 복구를 시험해야 합니다.

이런 방식을 선택할 때는 먼저 현재 네트워크에서 안정적으로 작동하는지 확인하고, 지속적인 작업과 상호작용 작업을 함께 수행할 수 있는지 살펴본 다음 기기 온도와 백그라운드 활동을 점검하세요. 호환성 차이가 뚜렷하다면 낯선 매개변수를 반복해서 적용하기보다 TCP 기반의 사용 가능한 설정을 복구용으로 남겨 두는 편이 효과적입니다. 프로토콜 적합성은 조건에 따라 판단해야 하며, 특정 기술 경로를 영구적인 순위로 매길 수는 없습니다.

직결·중계·전용 회선 구조

직결: 중계 단계가 적다고 경로가 짧은 것은 아닙니다

직결은 보통 클라이언트가 대상 지역이나 해외에 있는 프록시 진입점에 직접 연결하고, 서비스 제공자가 별도의 중계 구간을 추가하지 않은 구조를 뜻합니다. 하지만 인터넷 자체는 여러 네트워크가 서로 연결된 구조라 데이터가 다양한 통신망과 교환 지점을 거칠 수 있습니다. 지도상 거리가 가까워도 라우팅 정책에 따라 경로가 돌아갈 수 있습니다. 직결은 서비스 배포 구조의 복잡성을 일부 줄여 주지만, 이름만으로 실제 왕복 경로가 가장 짧거나 모든 시간대에 안정적이라고 단정할 수는 없습니다.

실제 경로는 송신과 수신 방향이 다를 수도 있습니다. 요청이 나가는 경로와 응답이 돌아오는 경로가 같지 않을 수 있으므로 한쪽 경로의 상태만으로 전체 세션을 판단해서는 안 됩니다. 웹페이지 로딩이 느리다면 요청을 보내는 경로가 아니라 콘텐츠가 돌아오는 경로에 문제가 있을 수 있습니다. 로컬에서 확인한 일부 라우트 추적 결과만으로 전체 경로 품질을 단정하면 출구에서 대상 서비스까지의 구간을 놓치기 쉽습니다.

직결이 적합한지는 로컬 통신망과 대상 지역의 실제 연결 상태, 자주 사용하는 서비스의 응답을 확인해야 알 수 있습니다. 접속 품질이 좋은 경로라면 구조가 비교적 직접적이어서 관리 단계를 줄일 수 있습니다. 저녁 시간대에 다른 네트워크와의 연결이 혼잡한 경로라면 프로토콜 자체의 오버헤드가 작아도 사용 경험이 나빠질 수 있습니다. ‘중계 단계가 적을수록 좋다’가 아니라 ‘실제 경로가 현재 사용 환경에 적합한가’를 기준으로 판단하세요.

중계: 추가 경로를 활용해 제어 가능성을 높이기

중계는 클라이언트와 최종 출구 사이에 전달 진입점이나 중계 구간을 추가하는 방식입니다. 사용자는 먼저 더 쉽게 연결할 수 있는 진입점에 접속하고, 진입점이 트래픽을 출구로 전달합니다. 한 구간이 추가되면 전파와 처리 비용이 늘어날 수 있지만, 기존에 우회하거나 혼잡했던 경로를 대체하면 최종 사용 경험이 개선될 수도 있습니다. 따라서 중계가 본질적으로 더 빠르거나 느린 것은 아닙니다. 기존 경로를 어떻게 대체하는지, 중계 구간의 용량과 관리 상태가 어떤지에 따라 가치가 달라집니다.

중계 구조에서는 조율해야 할 구성요소가 늘어납니다. 진입점이 정상이어도 진입점과 출구 사이가 정상이라는 뜻은 아니며, 출구에 연결할 수 있어도 진입점에서 대기열이 생기지 않는다는 보장은 없습니다. 연결은 되지만 전송이 멈춘다면 중계 구간이 병목인지 확인해야 합니다. 같은 진입점을 사용하는 여러 출구에서 동시에 문제가 생기면 진입점이나 공유 중계 구간을 먼저 점검하세요. 특정 출구에서만 문제가 생긴다면 해당 출구나 이후 대상 경로가 원인일 가능성이 높습니다.

지역 이름만으로 여러 회선이 어떤 기반 시설을 공유하는지 모두 알기는 어렵습니다. 국가 이름이 다른 여러 노드가 같은 진입점이나 상위 네트워크를 거칠 수 있고, 같은 지역에서도 경로가 다를 수 있습니다. 회선을 바꾼 뒤에도 사용 경험이 달라지지 않았다고 해서 변경이 무효였다는 뜻은 아닙니다. 같은 병목 구간을 계속 사용했을 수도 있습니다. 전체 노드 이름과 발생 시간을 기록하면 서비스 지원 채널에서 공유 구간을 확인하는 데 도움이 됩니다.

전용 회선: 전용 구간의 시작과 끝을 확인하기

전용 회선은 특정 구간의 리소스와 연결 방식에 대한 설명이지, 클라이언트에서 대상 웹사이트까지의 전체 경로를 자동으로 전용으로 만든다는 뜻은 아닙니다. 중간에 전용 전송 구간을 사용하더라도 사용자의 무선 네트워크와 접속망, 출구에서 대상 서비스까지는 일반 인터넷을 거칠 수 있습니다. 전용 회선이라는 표시를 보면 전체 앱 연결이 완전히 독점적인 통로라고 생각하기보다 전용 구간이 어디에서 시작해 어디에서 끝나는지 확인하세요.

안정성은 용량 계획과 장애 대응에도 좌우됩니다. 전용 구간은 일부 불확실성을 줄일 수 있지만 양 끝의 장비와 출구 대역폭, 대상 서비스 응답에는 여전히 한계가 있습니다. 특정 회선 유형을 가용성 보장으로 여겨서는 안 되며, 표시만 보고 공개되지 않은 대역폭을 추론해서도 안 됩니다. 회선을 선택할 때는 구조를 사용 경험을 이해하기 위한 단서로 보고, 실제 자주 쓰는 서비스로 검증하세요. 표시 자체를 최종 결과로 간주하지 마세요.

OEMVPN에서 제공하는 구체적인 도시와 회선 유형, 할당 정보는 패널의 목록을 기준으로 확인하세요. 이 페이지에서는 확인되지 않은 지역에 전용 회선이나 중계 속성을 표시하지 않습니다. 먼저 회선 목록에서 필요한 지역을 확인한 뒤, 대상 서비스에 적합한 출구인지 살펴보세요. 집 전체에 적용하는 구성은 라우터가 한 단계 더 추가됩니다. 트래픽 분기와 기기 성능의 장단점은 라우터 VPN 구성 안내에서 확인하세요. 라우터 처리 성능의 병목을 국제 회선 문제로 오해하지 않도록 주의하세요.

패킷 손실, 지터, 저녁 시간대 혼잡

패킷 손실은 하나의 원인으로 설명할 수 없습니다

패킷 손실은 무선 간섭과 장비 버퍼 부족, 혼잡으로 인한 폐기, 경로 변경에서 발생할 수 있습니다. 진단용 패킷에 응답이 오지 않은 것일 수도 있습니다. 실제 데이터가 손실되면 안정적인 전송을 위해 누락된 부분을 복구해야 하므로 앱에서 대기가 발생합니다. 실시간 서비스는 재생을 계속하거나 품질을 낮추거나 오래된 데이터를 건너뛸 수 있습니다. 같은 네트워크 문제라도 웹과 음성 통화, 다운로드에서 증상이 다르게 나타나므로 ‘연결이 끊겼다’는 말만으로 설명하기 어렵습니다.

라우트 추적에서 중간 노드가 응답하지 않는다고 해서 그 노드를 지나는 데이터가 모두 손실된 것은 아닙니다. 네트워크 장비는 진단 패킷의 처리 우선순위를 낮추면서도 실제 트래픽은 정상적으로 전달할 수 있습니다. 이후 노드와 최종 대상, 실제 앱 동작을 함께 확인해야 의미 있는 문제가 있는지 판단할 수 있습니다. 중간 지점 하나가 응답하지 않는다는 이유만으로 네트워크 장애라고 결론 내리면 정상적인 관리 정책을 성능 문제로 오해할 수 있습니다.

지터는 대기 시간의 변화를 나타냅니다. 평균 왕복 시간이 안정적으로 보여도 간헐적으로 지연이 크게 발생하면 원격 조작이나 실시간 음성 통화를 사용하기 어려울 수 있습니다. 지속 처리량이 높아도 이런 문제를 놓칠 수 있습니다. 동영상 플레이어는 버퍼로 변동을 흡수할 수 있지만, 상호작용 서비스는 사용자가 아직 보내지 않은 조작을 미리 저장할 수 없습니다. 연결 여부뿐 아니라 어떤 서비스에서 멈춤이 발생하는지, 한꺼번에 반복되는지, 다른 작업과 동시에 나타나는지도 기록하세요.

저녁 시간대 혼잡은 공유 리소스 경쟁인 경우가 많습니다

저녁 시간대 속도가 느려지는 현상은 공유 회선이나 장비의 트래픽 증가와 관련이 있는 경우가 많습니다. 병목은 가정용 무선 네트워크와 접속망 집선 구간, 국제 네트워크 연결, 중계 구간, 출구에서 발생할 수 있습니다. 혼잡 지점에 따라 해결 방법도 달라집니다. 로컬 업로드로 대기열이 생긴다면 가정의 트래픽을 먼저 조절해야 하고, 공유 출구가 혼잡하다면 다른 경로를 이용하는 편이 효과적일 수 있습니다. 대상 플랫폼의 응답 자체가 느리다면 로컬 프록시 설정에서 만능 옵션을 찾으려 해서는 안 됩니다.

대기열이 길어지면 데이터가 바로 손실되지는 않아도 전송되기까지 기다려야 합니다. 다운로드는 계속되지만 웹과 음성 통화가 눈에 띄게 느려질 수 있습니다. 이런 현상을 버퍼블로트라고 합니다. 혼잡 제어는 전송 동작을 조정하지만 로컬 장비의 대기열 관리도 중요합니다. 대용량 업로드와 다운로드를 잠시 멈추고 상호작용이 회복되는지 확인하는 방법은 프로토콜을 무작정 바꾸는 것보다 원인을 찾기 쉽고, 새로운 설정 변수도 늘리지 않습니다.

특정 시간대에만 문제가 생긴다면 같은 서비스와 접속 환경을 유지한 채 다른 시간대에도 확인하세요. 여러 출구에서 같은 대상이 느리다면 대상 서비스와 로컬 접속을 점검하세요. 특정 회선 그룹에서만 동시에 문제가 생긴다면 공유 경로를 살펴보세요. 유선 연결은 정상인데 무선 연결에서만 이상하다면 먼저 무선 환경을 확인하세요. 각 단계에서는 검증 가능한 가설 하나에 집중해 노드와 DNS 설정, 전송 옵션을 한꺼번에 바꾸지 마세요.

조건을 명확히 한 비교 기록 만들기

유용한 기록에는 접속 방식과 클라이언트 상태, 전체 회선 이름, 대상 서비스, 증상이 포함되어야 합니다. 증상은 ‘인증 완료 후 페이지가 계속 대기함’, ‘동영상은 정상 재생되지만 재생 위치를 이동하면 멈춤’, ‘업로드 중 문자 요청이 느려짐’처럼 관찰 가능한 말로 적으세요. 이런 설명은 핸드셰이크와 처리량, 대기열 문제를 구분하는 데 도움이 됩니다. 막연히 ‘속도가 느리다’고 하는 것보다 다음 점검 단계로 연결하기 쉽습니다.

먼저 환경을 고정한 뒤 변수를 하나씩 바꾸세요. 속도 측정과 연결 검사, 실제 서비스 이용은 서로 다른 질문에 답하므로 결과를 서로 대신해서는 안 됩니다.

비교 테스트에는 일반 공개 페이지와 민감하지 않은 테스트 콘텐츠를 사용하면 됩니다. 문제 해결을 위해 구독 링크를 낯선 진단 사이트에 붙여 넣거나 클라이언트 설정 전체를 업로드할 필요는 없습니다. 로그를 제출해야 한다면 접속 정보와 구독 주소, 개인 계정 내용을 삭제하고 오류 유형과 필요한 맥락만 남기세요. 기술 진단의 목적은 문제 범위를 좁히는 것이지, 문제와 무관한 개인정보를 수집하는 것이 아닙니다.

게임에서는 회선 프록시와 게임 경로 최적화를 구분해야 합니다. 게임은 서비스 서버와 매칭 지역, 데이터 전송 방식이 서로 다를 수 있어 웹 연결이 정상이라고 게임 경로도 적합한 것은 아닙니다. 지연 시간과 패킷 손실이 조작에 미치는 영향은 게임 가속기와 VPN의 차이에서 확인하세요. 로컬 무선 설정을 조정해 해결할 수 있는 문제라면 모든 개선을 국제 프로토콜 변경의 효과로 돌리지 마세요. 정확한 원인을 파악해야 실제로 유용한 설정을 유지할 수 있습니다.

플랫폼별 트래픽 처리 방식과 모바일 배터리

시스템 프록시와 가상 네트워크 인터페이스의 차이

시스템 프록시는 시스템 설정을 따르는 앱에 프록시 진입점을 제공하지만 모든 프로그램의 트래픽을 반드시 처리하는 것은 아닙니다. 일부 앱은 자체적으로 연결을 설정하거나 시스템 프록시가 처리할 수 없는 전송 방식을 사용해 브라우저는 정상이어도 다른 프로그램은 기존 경로를 이용할 수 있습니다. 가상 네트워크 인터페이스는 네트워크 계층에 더 가까운 곳에서 트래픽을 처리하므로 더 많은 범위를 지원할 수 있지만, 라우팅 규칙과 권한, DNS 설정, 클라이언트 구현에 더 크게 의존합니다.

더 넓은 범위를 지원한다고 항상 가장 광범위한 트래픽 처리를 켜야 하는 것은 아닙니다. 로컬 공유와 기업 네트워크, 로컬 네트워크 기기는 기존 경로를 유지해야 할 수 있습니다. 전체 트래픽을 처리했을 때 프린터나 원격 업무, 사내 사이트에 문제가 생기면 해외 노드를 계속 바꾸기보다 로컬 네트워크 우회 설정과 적용 규칙을 먼저 확인하세요. 트래픽 처리 방식은 어떤 데이터가 클라이언트로 들어오는지를 결정하고, 프로토콜은 들어온 데이터를 어떻게 전달할지를 결정합니다. 두 문제를 분리해 조정하세요.

Windows와 macOS에는 다른 네트워크 필터 구성요소가 함께 설치되어 있을 수 있습니다. 보안 프로그램과 기업용 접속 도구, 여러 프록시 클라이언트가 시스템 프록시와 가상 인터페이스, DNS 설정을 변경할 수 있습니다. 문제가 반복되거나 간헐적으로 나타나면 현재 어떤 프로그램이 트래픽을 처리하는지 확인하고, 불필요하게 중복된 구성요소를 종료한 뒤 클라이언트를 닫았을 때 시스템 설정이 복원되는지도 점검하세요. 단일 프로토콜의 성능 차이보다 여러 구성요소가 동시에 트래픽을 처리하는 문제가 더 우선일 수 있습니다.

배터리 소모는 작업량과 기기 활성화 방식에 따라 달라집니다

모바일 배터리는 암호화 처리뿐 아니라 무선 모듈의 활성 상태 유지와 백그라운드 연결 유지, 잦은 재연결, 앱의 지속적인 데이터 전송 때문에 소모됩니다. 유휴 상태에서도 계속 재연결하는 설정이 안정적으로 작동하는 설정을 계속 사용하는 것보다 배터리를 더 많이 소모할 수 있습니다. 프로토콜별 배터리 사용량을 비교하려면 두 설정이 비슷한 작업을 처리하는지 먼저 확인해야 합니다. 동영상 재생과 백그라운드 대기를 비교해 프로토콜의 차이라고 결론 내리면 안 됩니다.

신호 품질은 무선 전송에 필요한 작업량을 바꿉니다. 신호가 약하면 재전송이 반복되고 기기가 접속망을 전환하면서 활성 시간이 늘어날 수 있습니다. 특정 장소나 접속 환경에서만 기기가 뜨거워진다면 네트워크 신호와 재연결 상태를 먼저 확인하세요. 클라이언트가 실행 중이라는 이유만으로 배터리 소모 전체를 암호화 탓으로 돌려서는 안 됩니다. 시스템 배터리 화면의 앱별 사용량은 단서일 뿐이며 화면 사용과 실행 중인 작업, 무선 활동도 함께 고려해야 합니다.

연결 유지 간격을 더 짧게 설정한다고 항상 좋은 것은 아닙니다. 너무 잦은 연결 유지는 백그라운드 활성화를 늘릴 수 있고, 너무 드물면 네트워크 장비가 유휴 세션을 정리해 다음 요청 때 다시 연결해야 할 수 있습니다. 적절한 설정은 시스템의 백그라운드 동작과 접속망, 서버 동작에 따라 달라집니다. 일반 사용자는 구독과 클라이언트 기본값을 우선 사용하세요. 유휴 연결이 끊기는 문제를 확인한 뒤에만 서비스 안내에 따라 조정하고, 불필요한 백그라운드 활동이 늘지 않도록 주의하세요.

플랫폼별 차이를 실제 점검 방법으로 확인하기

Linux에서는 모든 앱이 같은 프록시 설정을 공유하지 않을 수 있습니다. 데스크톱 환경과 터미널 프로세스, 백그라운드 서비스는 서로 다른 환경 변수와 권한을 사용할 수 있으므로 특정 터미널 도구가 작동해도 모든 프로세스가 트래픽 처리 대상이라는 뜻은 아닙니다. 문제를 일으키는 실제 프로세스부터 확인하고, 브라우저 검사에만 의존하지 말고 해당 프로세스가 프록시 설정을 가져오는 방식을 점검하세요. 환경 변수를 바꿔도 실행 중인 프로세스가 새 설정을 바로 읽지 못할 수 있으므로 앱 동작에 맞춰 다시 시작해야 합니다.

OEMVPN은 Windows / macOS / iOS / Android / Linux를 지원하며 동시 접속 기기 수에 제한이 없습니다. 클라이언트와 구독 정보는 사용자 패널에서 받을 수 있습니다. iOS 이외의 플랫폼은 로그인 후 다운로드할 수 있으며, iOS는 유효한 요금제가 있어야 실제 다운로드 링크를 이용할 수 있습니다. 플랫폼 지원은 해당 기기에서 사용할 방법을 제공한다는 의미이며, 시스템 권한과 앱 동작, 백그라운드 기능이 모두 같다는 뜻은 아닙니다. 기기별로 따로 확인해야 합니다.

데스크톱에서 트래픽 분기와 자동 실행을 설정할 때 고려할 점은 Windows VPN 사용 비교에서 확인하세요. iOS 가져오기 절차는 iPhone VPN 설정 가이드를 참고하세요. 처음 사용할 때는 기본 연결을 먼저 완료한 다음 필요한 트래픽 처리 방식을 설정하세요. 그러면 복구 경로를 명확하게 유지하면서 이후 문제가 프로토콜과 규칙, 플랫폼 권한 중 어디에서 비롯되었는지 확인하기 쉽습니다. 변경 사항을 한꺼번에 적용하지 마세요.

사용 환경에 맞는 선택

먼저 업무에 필요한 조건을 정하고 프로토콜 이름은 나중에 고르세요

일상적인 웹 이용과 텍스트 기반 AI 도구는 보통 연결 설정과 요청 응답, 세션 안정성이 중요합니다. 현재 접속 환경에서 계속 작동하는 경로를 우선 선택한 뒤 인증을 반복하거나 응답이 끊기거나 페이지가 오래 기다리는지 살펴보세요. 대상 서비스는 계정 지역과 출구 특성, 자체 정책에 따라 접속 결과를 다르게 처리할 수도 있습니다. 홈페이지가 열린다고 모든 기능을 이용할 수 있다는 뜻은 아닙니다. 공개 페이지 하나만 확인하지 말고 실제 사용할 기능으로 회선을 검증하세요.

스트리밍은 지속 처리량과 속도 변동, 대상 플랫폼이 출구를 식별하는 방식이 중요합니다. 지역 표시는 회선 목록에서 어느 지역에 해당하는지를 나타낼 뿐 모든 플랫폼이 같은 방식으로 인식하거나 콘텐츠를 계속 이용할 수 있다는 보장은 아닙니다. 테스트할 때는 실제 재생과 재생 위치 이동, 연속 시청 상태를 확인하세요. 다른 서비스는 정상인데 특정 플랫폼에서만 문제가 생기면 전체 프로토콜 설정을 바로 문제로 보기보다 대상 플랫폼과 출구의 조합을 먼저 살펴보세요.

원격 업무와 실시간 소통에서는 안정적인 왕복 지연 시간과 로컬 네트워크 호환성, 세션 지속성이 중요합니다. 회의와 원격 데스크톱, 사내 사이트, 파일 공유를 함께 확인하고 국제 웹페이지만 테스트한 채 전체 트래픽을 처리하지 마세요. 대용량 작업이 다른 서비스에 미치는 영향도 살펴봐야 합니다. 다운로드 속도는 빠르지만 회의가 끊긴다면 동시에 업무를 처리하기에 적합한 방식이 아닙니다. 백그라운드 작업을 적절히 조절하는 편이 프로토콜을 바꾸는 것보다 직접적인 해결책일 수 있습니다.

작동하는 기준 설정에서 시작해 단계별로 비교하기

먼저 주요 업무를 안정적으로 처리할 수 있는 설정을 저장해 기준으로 삼으세요. 구독을 업데이트하고 클라이언트 지원 여부를 확인한 다음, 접속 네트워크와 대상 서비스는 그대로 둔 채 후보 회선으로 바꿉니다. 연결 상태와 지속 이용, 유휴 상태에서의 복구, 네트워크 전환 후 동작을 확인하고 차이를 기록하세요. 후보 설정에 문제가 생기면 기준 설정으로 돌아가 다시 확인합니다. 기준 설정도 함께 나빠졌다면 후보 설정 자체보다 환경 변화가 원인일 가능성이 높습니다.

비슷한 경로끼리 비교할 수 있을 때 프로토콜 차이를 더 정확하게 판단할 수 있습니다. 실제 구독에서는 같은 경로에 서로 다른 프로토콜을 제공하지 않을 수 있습니다. 따라서 비교 결과로 ‘이 조합이 현재 환경에 더 잘 맞는다’고 말할 수는 있어도 ‘어떤 프로토콜이 다른 프로토콜보다 항상 우수하다’고 결론 내릴 수는 없습니다. 비교의 한계를 인정해도 사용 결정을 내리는 데는 문제가 없습니다. 사용자에게 필요한 것은 기기와 경로, 사용 조건과 무관한 순위가 아니라 반복해서 확인할 수 있는 사용 경험입니다.

문제가 생기면 단계별로 되돌아가 확인하세요. 가져올 수 없다면 클라이언트 지원 여부를, 인증할 수 없다면 구독 정보와 시간을 확인합니다. 연결은 되지만 서비스에 문제가 있다면 규칙과 DNS, 대상 서비스를 살펴보세요. 대용량 트래픽을 사용할 때만 느려진다면 용량과 대기열을 확인하고, 화면을 잠그거나 네트워크를 바꾼 뒤에만 이상이 생긴다면 백그라운드 동작과 복구 상태를 점검하세요. 한 번에 한 가지 문제만 다루고 변경 전 상태를 보존하면 해결 방향을 잡기 쉽고 서비스 지원 채널에서도 재현하기 편합니다.

기술 선택과 요금제 선택은 별도로 판단하기

프로토콜 선택은 데이터 전송 방식을 정하고, 요금제 선택은 트래픽 요금을 정합니다. OEMVPN 월간 요금제는 ¥9.9/월(60GB 포함), ¥18/월(250GB 포함), ¥28/월(500GB 포함)입니다. 트래픽은 가입한 날짜를 기준으로 매월 초기화되며, 이용 도중 요금제를 상향하면 차액을 남은 날짜에 따라 계산합니다. 가격만 보고 공개되지 않은 프로토콜 권한과 전용 회선 등급, 속도 보장을 추론하지 마세요. 자세한 요금제와 선택 가능한 항목은 요금제 페이지와 패널에서 확인하세요.

데이터 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며, 모두 사용할 때까지 유효하고 만료되지 않습니다. 월간 요금제와 데이터 패키지의 주요 차이는 요금 부과 방식과 데이터 유효 기간입니다. 데이터 패키지를 특정 전송 기술로 오해해서는 안 됩니다. 선택하기 전에 사용이 꾸준한지와 데이터 소비가 일정한지 확인한 다음 기기와 사용 환경을 고려하세요. 결제 수단은 Alipay / WeChat / USDT이며, 서비스는 7일 무조건 환불을 제공합니다.

계정 생성에는 이메일 주소가 필요하지 않으며 사용자 이름과 비밀번호만 있으면 됩니다. 구독을 받은 뒤에는 비밀번호처럼 안전하게 보관하고, 다른 사람에게 테스트를 맡기려고 전체 링크를 공개하지 마세요. 지원이 필요하면 패널 문의 티켓에 접속 방식과 클라이언트, 회선, 오류 단계 등을 작성하고 접속 정보는 삭제하세요. 기본 가져오기 절차에 관한 문제라면 초보자 가이드를 확인하세요. 일반적인 계정과 결제 질문은 지원 센터에서 찾아볼 수 있습니다.

최종적으로 사용할 설정은 자주 쓰는 기기와 접속 네트워크, 대상 서비스에서 반복해서 정상 작동해야 합니다. 프로토콜 이름은 원인을 이해하는 데 쓰고, 실제 서비스를 이용해 선택을 검증하며, 복구용 설정을 남겨 변경 비용을 줄이세요.