VPNZe 문제 해결 가이드

DIAGNOSIS BASELINE

점검 기준선 세우기

먼저 증상을 판단 가능한 문장으로 작성하기

“네트워크가 불안정하다”만으로는 해결 방법을 정할 수 없습니다. 범위, 시점과 동작을 포함하도록 문제를 다시 작성하세요. 예를 들면 클라이언트가 연결을 완료하지 못함, 클라이언트에는 연결됨으로 표시되지만 모든 웹페이지가 열리지 않음, 특정 앱만 실패함, 낮에는 정상이나 피크 시간대에 끊김, 모바일 네트워크로 전환하면 복구됨, 구독 업데이트에는 오류가 나지만 기존 서버에는 연결됨 등입니다. 설명이 구체적일수록 문제가 진입 네트워크, 서버, 시스템 또는 대상 서비스 중 어디에 있는지 판단하기 쉽습니다.

문제가 계속 발생하는지 간헐적인지도 함께 확인하세요. 지속적인 실패는 설정, 권한, 구독 상태 또는 네트워크 환경과 관련된 경우가 많고, 간헐적인 실패는 서버의 순간적인 변동, 시스템 절전, 네트워크 전환 또는 앱 캐시와 관련될 가능성이 큽니다. 한 번의 실패만으로 결론을 내리지 마세요. 설정을 바꾸지 않고 같은 동작을 반복해 오류 메시지가 일관적인지 확인할 수 있습니다. 매번 메시지가 다르다면 클라이언트를 바로 재설치하기보다 로컬 네트워크의 안정성을 먼저 점검하세요.

문제 계층 나누기

최소 테스트 환경 준비

점검할 때는 방해 요소를 일시적으로 줄이세요. 클라이언트 하나, 브라우저 창 하나와 테스트할 서버 하나만 남기고 네트워크를 계속 사용하는 동기화, 다운로드와 업데이트 작업을 잠시 중지합니다. 시스템에 프록시 클라이언트가 여러 개 설치되어 있다면 다른 클라이언트를 먼저 종료해 시스템 프록시나 가상 네트워크 인터페이스를 서로 차지하지 않도록 하세요. 브라우저 확장 프로그램도 프록시를 임의로 바꿀 수 있으므로 확장 기능을 로드하지 않는 독립 창에서 다시 테스트할 수 있습니다. 다만 처음부터 모든 개인 데이터를 삭제하지는 마세요.

테스트 대상도 계층별로 나누어야 합니다. 먼저 평소 안정적으로 열리는 일반 웹페이지를 방문한 다음 로그인이나 특정 지역에 의존하는 서비스를 테스트하세요. 일반 웹페이지부터 실패한다면 스트리밍 계정이나 앱 지역 설정을 먼저 확인할 필요가 없습니다. 일반 웹페이지는 정상인데 특정 대상만 실패한다면 문제 범위는 대상 서비스, 앱별 라우팅, 계정 지역 또는 서버 출구로 좁혀지며 전체 연결 기능의 문제는 아닐 가능성이 큽니다.

변경 전 상태 기록

모드나 DNS를 변경하기 전에 현재 서버의 전체 이름, 클라이언트 모드, 시스템 네트워크 유형, 오류 원문과 발생 시각을 기록하세요. 스크린샷에는 핵심 상태가 보이게 하되 구독 내용과 접근 인증 정보는 가려야 합니다. 구독 주소를 공개 페이지에 붙여 넣지 말고 문의 내용에 비밀번호를 제출하지도 마세요. VPNZe는 사용자 이름과 비밀번호만으로 이용할 수 있으며 이메일 주소가 필요하지 않습니다. 문의 처리에는 문제를 재현할 수 있는 정보만 필요하고 로그인 인증 정보는 필요하지 않습니다.

클라이언트 업데이트, 네트워크 전환 또는 시스템 절전 이후 문제가 발생했다면 어떤 동작이 계기였는지도 적으세요. 최종 오류보다 유발 동작이 더 중요한 단서가 되는 경우가 많습니다. 예를 들어 절전 모드에서 깨어난 뒤 실패했다가 클라이언트를 재시작하면 복구된다면 가상 인터페이스 재구성을 먼저 확인하고, 네트워크 전환 후 실패한다면 기존 연결과 DNS 캐시를 먼저 확인하며, 구독을 바꾼 뒤 서버 목록이 비었다면 구독 가져오기 과정을 먼저 확인해야 합니다. 기준선을 세우는 것은 번거로운 일이 아니라 간헐적인 문제를 지속적인 장애로 잘못 판단하지 않기 위한 과정입니다.

CONNECTION FAILURE

연결 자체가 안 될 때 점검 방법

“클라이언트가 실행되지 않음”과 “서버 핸드셰이크 실패” 구분하기

연결 자체가 안 되는 문제는 겉보기에는 비슷하지만 보통 두 가지로 나뉩니다. 첫 번째는 클라이언트 핵심 프로세스가 정상적으로 실행되지 않는 경우입니다. 실행 직후 멈추거나, 시스템 프록시 버튼이 적용되지 않거나, 가상 네트워크 모드를 만들 수 없거나, 권한 문제가 계속 표시되는 식으로 나타납니다. 두 번째는 클라이언트는 정상인데 선택한 서버와 세션을 만들 수 없는 경우입니다. 연결 과정이 멈추거나 시간 초과가 발생하거나 서버 오류가 즉시 반환됩니다. 전자는 로컬 권한과 소프트웨어 상태를 확인하고, 후자일 때 서버와 네트워크 환경을 점검해야 합니다.

먼저 클라이언트를 완전히 종료한 뒤 다시 열고, 실행 과정에서 처음 나타나는 이상을 확인하세요. 마지막 오류만 보지 마세요. 뒤에 이어지는 오류는 앞선 실패의 연쇄 결과일 수 있습니다. 클라이언트가 시스템 네트워크 설정을 요청하면 시스템 안내에 따라 권한을 허용하세요. 이미 권한이 있지만 상태가 이상하다면 연결을 끊고 클라이언트를 종료한 뒤 다시 진입하세요. 연결 버튼을 빠르게 반복해서 누르면 이전 세션이 해제되기 전에 새 세션이 생성될 수 있습니다.

기본 네트워크 진입 경로 확인

가속 연결을 끊은 뒤 현재 네트워크로 평소 이용하는 페이지가 열리는지 확인하세요. 기본 네트워크 자체를 사용할 수 없다면 라우터, 무선 접속 또는 유선 연결부터 복구해야 합니다. 웹페이지 확인이 필요한 네트워크라면 클라이언트에 연결하지 않은 상태에서 먼저 인증을 완료하세요. 이러한 진입 페이지는 로컬 리디렉션에 의존하는 경우가 많아 시스템 프록시가 켜져 있으면 제대로 표시되지 않을 수 있습니다. 따라서 진입 절차가 완료되지 않은 것을 서버 문제로 오해해서는 안 됩니다.

기본 네트워크가 정상이라면 같은 클라이언트로 다른 서버를 테스트하세요. 지역은 같고 서버 유형은 다른 노드를 우선 선택하면 지역 차이가 결과에 미치는 영향을 줄일 수 있습니다. VPNZe는 100+개 국가와 250+개 서버를 제공하며, 서버 페이지에서 IEPL 전용 회선, 중계와 직결 유형을 확인할 수 있습니다. 비교가 필요하다면 글로벌 서버 페이지에서 유형 설명을 확인하세요. 같은 지역의 다른 유형에 연결된다면 클라이언트와 구독은 대체로 정상이며, 원래 서버 또는 현재 네트워크에서 해당 서버로 이어지는 경로에 문제가 집중됩니다.

구독에 유효한 내용이 남아 있는지 확인

클라이언트에 기존 서버 이름이 남아 있다고 해서 구독 내용이 최신이라는 뜻은 아닙니다. 먼저 구독이 정상적으로 업데이트되었는지 확인하고, 서버 목록이 이전 캐시에서 복원된 것이 아닌지 살펴보세요. 업데이트에 실패해도 기존 설정을 바로 삭제하지 마세요. 기존 설정을 남겨 두면 “구독을 가져오지 못함”과 “서버에 연결하지 못함”이 별개의 문제인지 판단하는 데 도움이 됩니다. 구독 업데이트 절차는 뒤에서 별도로 설명합니다. 패널에서 요금제 상태를 확인해야 한다면 같은 기존 링크를 반복해서 가져오기보다 계정 개요로 이동해 확인하세요.

구독은 업데이트되고 서버 목록도 완전하지만 모든 서버에 연결할 수 없다면 서로 다른 접속 네트워크의 결과를 비교하세요. 목적은 네트워크를 계속 바꾸는 것이 아니라 현재 진입 경로에서만 문제가 발생하는지 확인하는 것입니다. 다른 네트워크에서 연결된다면 클라이언트와 계정에 근본적인 문제가 없을 가능성이 높으므로 원래 네트워크의 프록시 제한, DNS 변조, 게이트웨이 규칙 또는 남은 세션을 확인하세요. 모든 접속 환경에서 같은 오류가 발생한다면 클라이언트 핵심 프로세스, 시스템 시간, 구독 내용과 로그에 기록된 첫 번째 이상을 중점적으로 살펴보세요.

무작정 재설치하지 말고 남은 상태 정리

연결이 강제로 끊긴 뒤 시스템 프록시, 가상 네트워크 인터페이스와 클라이언트 프로세스의 상태가 서로 맞지 않을 수 있습니다. 안전한 순서는 클라이언트에서 먼저 연결을 끊고, 클라이언트를 종료한 뒤 시스템 프록시가 복구되었는지 확인하고 다시 시작하는 것입니다. 가상 네트워크 모드에 문제가 있다면 일반 시스템 프록시 모드로 잠시 전환해 비교하세요. 일반 모드에서 연결된다면 서버 자체는 사용 가능하고, 문제는 가상 인터페이스, 권한 또는 시스템 네트워크 스택에 집중됩니다. 이때 서버를 계속 바꾸지 마세요.

재설치는 클라이언트 파일이 손상되었거나 핵심 프로세스를 시작할 수 있다는 사실을 확인한 뒤에 고려하세요. 재설치 전에는 필요한 비민감 설정을 저장하고 사용자 패널에서 클라이언트와 구독을 다시 가져올 수 있는지 확인하세요. 출처가 불분명한 페이지에서 같은 이름의 프로그램을 다운로드하거나 정체를 알 수 없는 설정을 가져오지 마세요. VPNZe는 Windows, macOS, iOS, Android와 Linux를 지원하며 클라이언트 진입점은 사용자 패널 다운로드 영역에 통합되어 있습니다.

자체 점검을 중단해야 할 때

서로 다른 네트워크와 서버 유형에서도 연결되지 않고 로그에 같은 핸드셰이크 또는 인증 오류가 계속 나타난다면 문의를 접수하세요. 클라이언트 플랫폼, 연결 모드, 서버 전체 이름, 발생 시각, 오류 원문과 함께 “기본 네트워크 정상, 서버 변경 완료, 클라이언트 재시작 완료” 결과를 첨부하세요. “연결되지 않음”이라고만 쓰거나 맥락 없는 스크린샷을 여러 장 한꺼번에 보내지 마세요. 각 스크린샷이 어느 단계에 해당하는지 알아야 지원팀이 서버 측 이상인지 로컬 설정 문제인지 판단할 수 있습니다.

WEB AND DNS

연결됨에도 웹페이지가 열리지 않거나 DNS 오류가 발생할 때

브라우저 문제인지 시스템 전체 문제인지 먼저 판단

클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않는다면 다른 브라우저나 시스템 기본 네트워크 도구로 비교하세요. 한 브라우저만 실패한다면 독립 프록시, 보안 DNS, 확장 프로그램 규칙 또는 오래된 캐시를 확인합니다. 모든 브라우저가 실패하면 시스템 프록시가 실제로 적용되었는지 확인하세요. 브라우저는 정상인데 다른 앱이 실패한다면 DNS에 시간을 더 쓰지 말고 “앱별 라우팅” 장으로 이동하세요.

브라우저 오류 페이지의 문구는 중요한 단서입니다. 도메인 확인 실패, 연결 시간 초과, 인증서 이상과 연결 재설정은 각각 확인 방향이 다릅니다. 도메인을 확인할 수 없다면 DNS 경로부터 점검하고, 연결 시간 초과는 서버, 대상 주소 또는 라우팅과 관련될 가능성이 큽니다. 인증서 오류가 나면 시스템 시간과 대상 도메인이 올바른지 먼저 확인하세요. 연결이 재설정되면 서버와 네트워크 진입 경로를 비교해야 합니다. 모든 오류를 “서버 문제”로 통칭하지 마세요.

명령어로 도메인 확인과 접속 구분

공개 테스트 도메인에 대해 도메인 확인과 응답 검사를 실행할 수 있습니다. 아래 명령어에는 구독 정보가 포함되지 않으며 시스템 설정도 변경하지 않습니다. 플랫폼마다 명령어 이름은 다를 수 있지만 판단 목표는 같습니다. 먼저 도메인이 확인 결과를 반환하는지 보고, 그다음 HTTPS 요청으로 응답을 설정할 수 있는지 확인하세요. 명령 출력은 원인 파악에만 사용하고 대상 서비스의 계정 상태를 추론하는 근거로 삼지 마세요.

nslookup example.com
curl -I https://example.com

도메인 확인 명령이 실패했지만 클라이언트의 서버 테스트나 주소 기반 연결에는 응답이 있다면 DNS에 가까운 문제입니다. 도메인 확인은 성공했지만 HTTPS 요청이 시간 초과되면 시스템 프록시, 라우팅 규칙과 대상 경로를 계속 점검하세요. 명령줄은 정상인데 브라우저만 실패한다면 브라우저의 프록시와 DNS 설정을 먼저 확인합니다. 명령줄과 브라우저가 모두 실패하면 다른 서버로 바꿔 같은 테스트를 수행하고 문제가 서버를 따라 움직이는지 관찰하세요.

연결됨에도 실패하는 DNS 문제의 원리

도메인 확인은 시스템 기본 DNS, 클라이언트 내장 DNS, 가상 네트워크 인터페이스 또는 브라우저 독립 DNS를 통해 이루어질 수 있습니다. 여러 경로가 동시에 존재할 때 흔한 문제는 DNS가 없는 것이 아니라 조회가 트래픽과 다른 출구를 사용하거나 오래된 캐시가 현재 서버에 맞지 않는 결과를 계속 사용하는 것입니다. 네트워크 전환, 절전 해제 또는 클라이언트 모드 변경 후에는 이전 DNS 캐시가 특히 쉽게 남습니다.

영향이 적은 조치부터 순서대로 처리하세요. 문제가 발생한 브라우저 창을 닫고 다시 열고, 클라이언트에서 연결을 끊었다가 다시 연결하며, 브라우저가 현재 환경과 충돌하는 독립 DNS를 강제로 사용하지 않는지 확인합니다. 필요한 경우에만 시스템 DNS 캐시를 정리하세요. 캐시 정리는 시스템에 다시 조회하도록 요청할 뿐 잘못된 프록시 규칙을 고치지는 않습니다. 정리 직후 잠시 복구되었다가 다시 실패한다면 반복해서 캐시를 지우지 말고 DNS 경로를 계속 확인하세요.

시스템 프록시와 가상 네트워크 모드 확인

일반 시스템 프록시 모드는 앱이 시스템 프록시 설정을 적극적으로 읽어야 작동합니다. 일부 명령줄 도구나 독립 앱은 이 설정을 상속하지 않아 브라우저는 정상인데 명령줄만 실패할 수 있습니다. 가상 네트워크 모드는 더 낮은 계층에서 트래픽을 인계하지만 시스템 권한과 인터페이스 상태에 의존합니다. 모드를 바꾼 뒤 문제가 사라졌다면 서버 자체는 대체로 사용 가능하고 트래픽 인계 방식에서 차이가 발생한 것입니다. 이때 정상 작동하는 모드를 유지하면서 기존 모드의 프록시 상속 또는 권한을 점검하세요. 국가나 지역을 계속 바꿀 필요는 없습니다.

시스템에 수동 프록시 주소가 남아 있는지도 확인하세요. 클라이언트를 종료한 뒤에도 수동 프록시가 중지된 로컬 포트를 가리키면 모든 웹페이지가 실패할 수 있습니다. 자동 설정 또는 클라이언트 관리로 되돌린 뒤 다시 시도하세요. 네트워크 가이드에 나오는 포트와 주소를 임의로 복사하지 마세요. 클라이언트마다 로컬 수신 방식이 다를 수 있으므로 확인할 때는 현재 클라이언트에 실제로 표시된 설정을 기준으로 삼아야 합니다.

특정 도메인만 실패할 때

대부분의 웹페이지는 정상인데 특정 도메인만 실패한다면 같은 서버에서 웹 버전과 앱 버전을 먼저 비교한 뒤 같은 지역의 다른 서버로 다시 테스트하세요. 특정 서비스는 출구 지역, 계정 지역, 로그인 상태 또는 캐시에 따라 다른 결과를 반환할 수 있습니다. 이때 DNS는 여러 가능성 중 하나일 뿐입니다. 브라우저 전체를 초기화하기보다 해당 사이트의 부분 캐시를 지우는 편이 안전하며, 입력한 주소가 공식 도메인인지도 확인하세요. 리디렉션 도메인이나 오래된 즐겨찾기를 메인 사이트로 착각하지 않도록 주의해야 합니다.

특정 서버에서만 문제가 발생한다면 문의 내용에 서버 전체 이름, 실패한 도메인, 브라우저 오류 원문과 비교한 서버를 적으세요. 여러 도메인에서 동시에 확인에 실패한다면 도메인 확인 명령 결과도 첨부합니다. 출력에 로컬 사용자 이름이나 디렉터리 경로가 포함되어 있다면 해당 부분을 가려도 됩니다. 구독 주소는 제출하지 마세요. DNS 경로를 판단하는 데 구독 인증 정보는 필요하지 않습니다.

SPEED AND PEAK HOURS

속도 저하와 피크 시간대 끊김

어떤 동작에서 “느림”이 발생하는지 먼저 정의

웹페이지 첫 화면 로딩 지연, 동영상 버퍼링, 파일 전송 속도 저하, 화상회의 끊김과 AI 도구 응답 중단은 같은 기준으로 판단하면 안 됩니다. 웹페이지는 연결 수립과 짧은 요청 응답을, 동영상은 지속적인 처리량과 지역별 사용 가능 여부를, 회의는 지연 변동과 패킷 손실을 더 중요하게 봅니다. 파일 전송은 단일 연결 제한과 대상 서버의 영향을 받기 쉽습니다. 실제 용도에 맞는 테스트 동작을 먼저 선택하고, 하나의 속도 측정 페이지만으로 전체 사용 경험을 대신하지 마세요.

테스트할 때 백그라운드 동기화와 업데이트를 일시 중지하고 로컬 네트워크, 클라이언트 모드, 대상 서비스와 작업 순서를 고정한 채 서버만 바꾸세요. 페이지가 막 열린 순간 전환하지 말고 안정적인 추세를 확인할 만큼 테스트를 유지합니다. 로컬 무선 네트워크 자체가 불안정하면 서버 차이도 과장되어 보일 수 있습니다. 접속 지점 가까이 이동하거나 안정적인 연결로 비교할 수 있지만, 임시 조건의 결과를 서비스 속도 보장으로 해석하지는 마세요.

지역과 서버 유형으로 범위 좁히기

일반적으로 대상 서비스 지역에 가깝고 로컬 진입 경로도 합리적인 서버부터 선택하는 것이 좋습니다. 거리가 유일한 기준은 아니지만 네트워크 경로가 많아질수록 불확실성이 커질 수 있습니다. 특정 지역 콘텐츠 이용이 목적이라면 해당 지역을 우선 선택하고, 지역이 중요하지 않다면 인접 지역을 비교하세요. 서버 유형도 판단에 포함해야 합니다. IEPL 전용 회선, 중계와 직결은 경로 구조가 다르므로 접속 환경에 따라 성능이 달라질 수 있습니다.

효과적인 비교는 여러 국가를 무작위로 전환하는 것이 아니라 가까운 지역에서 유형을 비교하거나 같은 유형에서 인접 지역을 비교하는 것입니다. 그래야 지역 출구, 서버 유형 또는 대상 서비스 중 무엇이 영향을 주는지 판단할 수 있습니다. 서버 페이지에는 지역, 도시, 서버 유형과 스트리밍 태그가 표시되므로 글로벌 서버에서 먼저 필터링한 뒤 클라이언트에서 테스트하세요. 서버 이름에 “전용 회선”이나 “직결”이 포함되어 있다고 절대적으로 판단하지 말고, 최종 기준은 현재 접속 환경과 실제 용도입니다.

피크 시간대에만 발생하는 끊김 처리

낮에는 안정적이지만 피크 시간대에 뚜렷하게 끊긴다면 같은 시간대에 로컬 접속 네트워크도 느려지는지 먼저 확인하세요. 클라이언트를 끊고 평소 이용하는 콘텐츠에 접속해 기본 네트워크에서도 지연이나 패킷 손실이 발생하는지 관찰합니다. 기본 네트워크도 영향을 받는다면 서버 변경만으로는 일부만 개선됩니다. 기본 네트워크는 정상인데 특정 서버만 느려진다면 같은 지역의 다른 유형 서버로 비교하고 발생 시간대를 기록하세요.

피크 시간대 문제는 지속적인 처리량 저하나 간헐적인 멈춤으로 나타나는 경우가 많습니다. 전자는 동영상 화질을 높이거나 파일을 계속 전송할 때 더 뚜렷하고, 후자는 회의, 게임 또는 짧은 요청에서 더 쉽게 느낄 수 있습니다. 문의할 때도 두 현상을 구분해 설명해야 합니다. “피크 시간대에 안 된다”라고만 쓰면 지속적인 처리량 부족인지, 순간적인 지연 변동인지, 대상 서비스 혼잡인지 판단할 수 없습니다. 어떤 동작이 영향을 받았는지, 모든 서버에서 발생했는지, 어떤 유형의 서버로 바꾸자 달라졌는지 적어 주세요.

속도 측정 방식이 결론을 방해하지 않도록 하기

속도 측정 대상마다 다른 네트워크에 있으므로 결과가 모든 웹사이트를 직접 대표하지는 않습니다. 브라우저 속도 측정은 페이지 스크립트, 브라우저 확장 프로그램, 기기 성능과 동시 연결의 영향도 받습니다. 더 실용적인 방법은 실제 작업을 중심으로 비교하는 것입니다. 같은 동영상이 같은 화질로 계속 재생되는지, 같은 파일 출처에서 안정적으로 전송되는지, 같은 회의 환경에서 반복적으로 재연결되는지 확인하세요. 속도 측정은 보조 자료일 뿐 유일한 증거가 되어서는 안 됩니다.

여러 속도 측정 작업을 동시에 실행하지도 마세요. 동시 작업이 대역폭을 서로 나누어 사용하면 서버가 실제보다 더 나빠 보일 수 있습니다. 테스트가 끝나면 페이지를 닫아 백그라운드 전송을 중지하세요. 클라이언트에서 연결 로그를 제공한다면 끊김 시점에 재연결이나 서버 전환이 발생했는지 확인할 수 있지만, 순간적인 단일 정보만으로 결론을 내리지는 마세요. 안정성 문제는 시간대와 반복되는 현상을 함께 봐야 합니다.

기기 리소스와 모드 확인

기기의 절전 상태, 바쁜 백그라운드 작업, 가상 네트워크 인터페이스 이상 또는 보안 소프트웨어의 심층 트래픽 검사가 속도를 낮출 수 있습니다. 불필요한 작업을 먼저 종료한 뒤 일반 시스템 프록시와 가상 네트워크 모드를 비교하세요. 한 모드는 안정적인데 다른 모드에서 계속 끊긴다면 차이는 로컬 트래픽 처리 경로에 있을 가능성이 큽니다. 이때 작동하는 모드를 유지하고 문의 내용에 모드별 차이를 적는 편이 단순히 “더 빠른 서버로 바꿔 달라”고 요청하는 것보다 도움이 됩니다.

특정 앱만 느리고 브라우저와 다른 앱은 정상이라면 앱별 라우팅 장으로 이동하세요. 모든 앱이 모든 서버에서 느리고 기본 네트워크는 정상이라면 서버와 환경 정보를 제출할 수 있습니다. VPNZe 월간 구독의 트래픽은 개통일을 기준으로 매월 초기화되므로 요금제 상태를 확인하려면 패널을 이용하세요. 반복적인 속도 측정으로 많은 트래픽을 소모하지 말고, 요금제 잔여 상태와 특정 서버의 성능을 혼동하지도 마세요.

DISCONNECTION AND SLEEP

잦은 연결 해제와 모바일 백그라운드 연결 끊김

연결이 끊기는 시점 판단

잦은 연결 해제는 먼저 유발 조건을 찾아야 합니다. 대표적인 계기는 기기 절전, 화면 꺼짐, 무선 네트워크와 모바일 네트워크 전환, 신호가 약한 지역에서 복귀, 클라이언트의 백그라운드 전환과 시스템 절전 정책입니다. 매번 같은 동작 뒤에 발생한다면 무작위 연결 해제보다 원인을 찾기 쉽습니다. 앱을 다시 열었을 때의 상태만 기록하지 말고 연결이 끊기기 직전의 마지막 동작을 기록하세요.

기기를 사용하지 않을 때 끊기고 계속 사용하는 동안 안정적이라면 백그라운드 실행 권한과 절전 정책을 먼저 확인하세요. 네트워크 전환 후에만 끊긴다면 클라이언트가 세션을 다시 만들 수 있는지, 기존 가상 인터페이스가 해제되었는지 확인합니다. 사용 중 뚜렷한 계기 없이 자주 끊긴다면 같은 지역의 다른 서버와 비교해 문제가 서버를 따라가는지 확인하세요. 세 경우의 처리 순서는 서로 다릅니다.

모바일 백그라운드 정책

모바일 운영체제는 배터리, 메모리와 백그라운드 활동에 따라 앱을 일시 중지합니다. 클라이언트가 백그라운드로 이동한 뒤 화면에는 “연결됨”이 남아 있어도 실제 세션은 시스템에 의해 종료되었을 수 있습니다. 다시 전면으로 가져왔을 때 클라이언트가 자동으로 재연결되는지, 시스템 상태 표시줄의 네트워크 표시가 복구되는지, 대상 앱이 요청을 다시 보내야 하는지 확인하세요. 작업 목록에 앱 카드가 남아 있다는 이유만으로 계속 실행 중이라고 판단하지 마세요.

시스템 설정에서 클라이언트가 필요한 백그라운드 활동을 유지하도록 허용하고 과도하게 제한된 절전 정책에서 제외할 수 있습니다. 시스템마다 메뉴 이름이 다르므로 고정된 경로보다 “백그라운드 실행, 네트워크 연결, 절전 제한”을 중심으로 찾아보세요. 변경 후 화면을 잠갔다가 다시 켜 원래 연결 해제를 일으킨 동작을 반복합니다. 문제가 사라지면 유발 조건이 확인된 것입니다. 계속 끊긴다면 서버와 네트워크 전환을 추가로 확인하세요.

네트워크 전환 후 남은 세션 처리

기기가 한 접속 네트워크에서 다른 네트워크로 전환되면 로컬 주소, 게이트웨이와 DNS 경로가 모두 바뀝니다. 기존 세션을 그대로 재사용하지 못할 수 있어 클라이언트가 연결을 새로 만들어야 합니다. 전환 후 모든 페이지가 멈춘다면 설정을 바로 삭제하지 말고 클라이언트에서 먼저 연결을 끊었다가 다시 연결하세요. 재연결 후 복구된다면 구독과 서버는 여전히 유효하고, 문제는 네트워크 전환 후 세션 복구에 집중됩니다.

네트워크를 바꿀 때마다 기기를 재시작해야 복구된다면 가상 네트워크 모드를 확인하세요. 일반 시스템 프록시 모드로 잠시 바꿔 비교할 수 있습니다. 일반 모드에서 정상적으로 복구된다면 가상 인터페이스 상태를 중점적으로 살펴볼 만합니다. 반대로 일반 모드에서만 일부 앱이 전환 후 작동하지 않는다면 앱이 시스템 프록시를 다시 읽지 않았을 가능성이 있습니다. 이 모드 차이를 문의 내용에 적으면 지원팀의 반복 질문을 줄일 수 있습니다.

서버 연결 해제와 앱 멈춤 구분

특정 앱이 전면으로 돌아온 뒤 로드되지 않는다고 서버 연결이 끊겼다는 뜻은 아닙니다. 먼저 브라우저로 일반 페이지를 열어 보세요. 브라우저가 정상이라면 시스템 연결은 유지되고 있으며, 앱이 기존 연결, 오래된 DNS 결과 또는 이전 세션을 유지하고 있을 가능성이 큽니다. 서버를 바꾸기보다 해당 앱을 완전히 종료하고 다시 여는 것이 더 직접적인 방법입니다. 모든 앱이 실패할 때는 클라이언트 연결 상태와 로그로 돌아가세요.

동영상이나 회의 앱은 특히 장시간 연결을 유지하기 쉽습니다. 네트워크가 바뀐 뒤 기존 연결이 제때 재생성되지 않으면 화면이 멈추거나 메시지가 갱신되지 않지만 새로 연 웹페이지는 정상일 수 있습니다. 이때 대상 앱을 재시작해 확인하세요. 앱을 재시작해도 효과가 없고 서버를 바꾸면 복구된다면 기존 서버와 대상 서비스를 기록하고, 클라이언트를 재시작해야 복구된다면 클라이언트 모드와 유발 동작을 기록하세요.

데스크톱 시스템의 절전 및 복귀

데스크톱 기기가 절전 모드에 들어가면 네트워크 인터페이스와 클라이언트 핵심 프로세스가 서로 다른 순서로 복구될 수 있습니다. 복귀 직후 서버를 연달아 바꾸지 말고 기본 네트워크가 복구될 때까지 기다린 뒤 클라이언트 상태를 확인하세요. 시스템 프록시는 켜져 있지만 클라이언트 핵심 프로세스가 아직 복구되지 않았다면 웹페이지가 잠시 모두 실패할 수 있습니다. 이때 클라이언트에서 다시 연결하고, 그래도 되지 않으면 클라이언트를 종료해 시스템 프록시가 복구되었는지 확인한 뒤 다시 여세요.

절전 후 장기간 문제가 반복된다면 일반 프록시 모드와 가상 네트워크 모드를 비교하고, 로그에서 복귀 후 처음 나타난 이상을 확인하세요. 장애 주변의 로그만 잘라내면 충분하며 전체 기록 파일을 제출할 필요는 없습니다. 로그에 로컬 디렉터리나 계정 식별자가 포함되어 있다면 가리세요. 지원팀에는 “계속 사용할 때는 안정적이나 절전 복귀 후 실패”라고 설명하는 편이 “가끔 끊김”보다 정확합니다.

무작위 연결 해제의 비교 경로

뚜렷한 유발 동작이 없다면 서버 하나를 고정해 관찰한 뒤 연결이 끊기면 같은 지역의 다른 유형으로 바꿔 보세요. 기존 서버를 따라 연결이 끊긴다면 서버 정보를 제출하고, 모든 서버에서 끊긴다면 접속 네트워크와 클라이언트 모드를 비교합니다. 한 기기에서만 발생한다면 해당 기기의 권한, 절전과 시스템 네트워크 상태를 확인하세요. VPNZe는 동시 접속 기기 수에 제한이 없으므로 고정된 기기 수를 추측하기보다 비정상 세션이나 클라이언트 상태를 확인하는 데 집중해야 합니다.

SUBSCRIPTION UPDATE

구독 업데이트 실패 및 서버 목록 이상

현재 사용 가능한 설정 먼저 보호

구독 업데이트에 실패해도 기존 설정을 먼저 삭제하지 마세요. 기존 설정으로 계속 연결할 수 있다면 비교에 사용할 수 있고 클라이언트 핵심 프로세스와 로컬 권한이 대체로 정상임을 보여 주기도 합니다. 삭제 후 다시 가져오면 “업데이트 실패”가 “사용 가능한 서버가 전혀 없음”으로 확대될 수 있습니다. 현재 설정 이름과 마지막으로 정상 작동한 상태를 기록한 뒤 별도로 업데이트를 실행하는 것이 안전합니다.

클라이언트가 여러 설정을 지원한다면 기존 설정을 보존하고 테스트 설정을 새로 만드세요. 지원하지 않더라도 사용자 패널에 로그인해 구독을 다시 가져올 수 있는지 먼저 확인해야 합니다. 구독 내용은 계정 제공 정보이므로 공개 도구, 검색창이나 타사 검사 페이지에 붙여 넣지 마세요. 예시 형식은 구조를 이해하기 위한 것일 뿐 패널에서 생성한 실제 내용을 대신할 수 없습니다.

https://example.com/sub?token=YOUR_TOKEN

“가져오지 못함”과 “해석하지 못함” 구분

업데이트 실패는 보통 요청 단계와 해석 단계로 나뉩니다. 요청 단계에서 실패하면 클라이언트가 구독 응답을 가져오지 못하며 시간 초과, 네트워크 오류 또는 접근 거부로 나타나는 경우가 많습니다. 해석 단계에서 실패하면 요청은 반환되었지만 현재 클라이언트가 해당 형식을 받아들이지 못해 설정 무효, 서버 목록 없음 또는 필드 오류로 표시될 수 있습니다. 두 경우에 필요한 증거가 다릅니다. 전자는 네트워크 오류 원문을, 후자는 해석 안내와 클라이언트 유형을 남기세요.

먼저 기본 네트워크가 정상인지 확인한 뒤 클라이언트에서 업데이트를 시도하세요. 클라이언트가 현재 서버를 통해 구독에 접근해야 하는데 그 서버가 이미 작동하지 않는다면 의존성 문제가 생길 수 있습니다. 이때는 연결을 끊고 기본 네트워크에서 업데이트해 보세요. 기본 네트워크에서도 되지 않으면 사용자 패널에서 다시 가져옵니다. 여러 네트워크에서 업데이트 버튼을 연속으로 누르면 어떤 요청이 결과를 반환했는지 확인하기 어려워집니다.

구독 주소를 직접 수정하지 말고 다시 가져오기

구독 주소에는 계정 식별 정보가 포함될 수 있습니다. 주소의 문자를 직접 삭제하거나 수정하지 말고 다른 사이트의 형식을 적용하지도 마세요. 계정 개요에 로그인해 서비스 상태를 확인한 뒤 패널의 다운로드 또는 구독 메뉴에서 현재 내용을 가져오세요. VPNZe는 이메일 주소 없이 사용자 이름과 비밀번호로 이용할 수 있습니다. 사용자 이름을 잊었거나 혼동한 경우 패널의 기존 절차를 이용하고, 같은 구독을 확인하려고 여러 계정을 새로 만들지 마세요.

복사할 때 앞뒤 공백, 줄바꿈, 따옴표 또는 메신저가 추가한 텍스트가 함께 들어가지 않도록 주의하세요. 클라이언트가 QR 코드와 붙여넣기를 모두 지원한다면 내용을 손상시킬 가능성이 낮은 방법을 선택할 수 있습니다. 붙여넣은 뒤 먼저 설정 이름이 표시되는지 확인하고 업데이트를 실행하세요. 가져오기는 성공했지만 서버 목록이 비었다면 클라이언트 안내 메시지를 기록하고 구독 주소에 임의로 매개변수를 추가하지 마세요.

업데이트는 성공했지만 내용이 바뀌지 않을 때

클라이언트에는 업데이트 완료로 표시되지만 기존 서버가 계속 보일 수 있습니다. 캐시, 설정 미전환, 화면 미갱신 또는 같은 이름의 다른 설정으로 업데이트된 경우가 원인일 수 있습니다. 현재 활성화된 설정 이름을 먼저 확인한 뒤 설정 화면을 닫고 다시 들어가세요. 비슷한 이름이 여러 개라면 테스트 설정의 이름을 잠시 바꿔 구분할 수 있지만 서버 필드는 수정하지 마세요.

서버 목록에 내용은 있지만 선택 후에도 기존 서버로 연결된다면 현재 세션을 끊은 뒤 설정과 서버를 바꾸세요. 일부 클라이언트는 기존 세션이 끝날 때까지 이전 연결을 유지하므로 목록에서 선택만 바꾼다고 실제 출구가 즉시 변경되지는 않습니다. 연결 해제, 선택, 재연결의 전체 절차로 다시 테스트하면 화면 선택과 실제 세션이 어긋나는 문제를 피할 수 있습니다.

플랫폼별 차이

구독 문제 문의 접수

문의에는 플랫폼, 클라이언트 유형, 업데이트 방식, 오류 원문, 발생 시각과 기존 설정의 연결 가능 여부를 포함하세요. 업데이트는 성공했지만 서버 목록이 비었다면 설정 이름과 화면에 나타난 현상을 설명합니다. 민감한 내용을 가린 스크린샷은 제공할 수 있지만 구독 주소, 비밀번호 또는 전체 설정 파일은 첨부하지 마세요. 지원팀은 제공 상태와 호환성을 판단하면 되며 계정을 직접 조작할 필요가 없습니다.

요금제 상태가 관련된 문제라면 패널에서 확인한 상태도 함께 적으세요. 월간 구독은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며 트래픽은 개통일을 기준으로 매월 초기화됩니다. 이용 중 업그레이드하면 차액은 남은 일수에 따라 계산됩니다. 트래픽 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 모두 소진될 때까지 사용하고 영구적으로 만료되지 않습니다. 패널에 표시된 실제 요금제만 기준으로 점검하고 남은 기간을 임의로 환산하지 마세요.

APPLICATION ROUTING

특정 앱이 프록시를 사용하지 않을 때

먼저 시스템 연결이 정상인지 확인

특정 앱에 접속할 수 없다면 같은 기기와 같은 서버에서 브라우저로 일반 웹페이지를 먼저 열어 보세요. 브라우저도 실패한다면 웹페이지 및 DNS 장으로 돌아가고, 브라우저가 정상이라면 서버와 기본 프록시가 적어도 일부 작동하는 것입니다. 이때 점검 범위를 대상 앱, 라우팅 규칙, 프록시 상속과 앱 캐시로 좁힐 수 있습니다. 앱 하나가 실패했다고 전체 구독을 삭제하지 마세요.

그다음 해당 서비스의 웹 버전과 앱 버전을 비교하세요. 웹 버전은 정상인데 앱만 실패한다면 앱이 시스템 프록시를 읽지 않거나, 연결 전에 만들어진 기존 세션을 유지하거나, 독립 네트워크 인터페이스를 사용하거나, 라우팅 규칙에 의해 직결로 처리되었을 가능성이 있습니다. 웹 버전과 앱 버전 모두 특정 서비스에서만 실패한다면 서버 지역, 대상 서비스 상태와 계정 지역을 확인해야 합니다.

시스템 프록시와 가상 네트워크 모드의 차이 이해

시스템 프록시 모드는 시스템 설정을 따르는 앱에서만 작동합니다. 브라우저는 보통 설정을 읽지만 일부 앱, 명령줄 도구, 게임 또는 독립 네트워크 스택을 사용하는 소프트웨어는 이를 무시할 수 있습니다. 가상 네트워크 모드는 더 낮은 계층에서 트래픽을 인계해 적용 범위가 더 넓은 편이지만 시스템 권한이 필요하며 보안 소프트웨어, 라우팅 테이블과 절전 복귀의 영향을 더 쉽게 받을 수 있습니다.

가장 직접적인 비교 방법은 서버를 그대로 유지하고 트래픽 인계 모드만 바꾸는 것입니다. 전환 전 연결을 끊고 전환 후 다시 연결한 다음 대상 앱을 완전히 종료하고 다시 여세요. 가상 네트워크 모드에서 앱이 복구된다면 기존 문제는 프록시 상속에 가까울 수 있습니다. 두 모드 모두 실패한다면 라우팅 규칙, DNS와 대상 서비스를 계속 확인하세요. 모드를 바꿀 때 서버까지 동시에 변경하면 어떤 변화가 효과를 냈는지 알 수 없습니다.

라우팅 규칙이 무엇을 적용했는지 확인

규칙 모드는 도메인, 주소, 앱 또는 규칙 모음에 따라 트래픽을 프록시로 보낼지 직결할지 결정합니다. 대상 서비스가 메인 도메인, 로그인 도메인, 정적 리소스 도메인과 API 도메인을 함께 사용할 수 있는데 이 중 일부만 프록시를 적용받으면 페이지는 열리지만 로그인되지 않거나 이미지가 로드되지 않고 메시지가 전송되지 않는 불완전한 장애가 발생합니다. 이때 클라이언트 연결 기록에서 대상 앱이 어떤 도메인에 접속했는지와 각 도메인이 어떤 경로로 처리되었는지 확인하세요.

규칙 문제인지 확인하려면 잠시 전역 프록시 모드로 다시 테스트할 수 있습니다. 전역 모드는 원인 파악용이며 장기 설정으로 적합하지 않을 수 있습니다. 전역 모드에서는 정상이고 규칙 모드에서 실패한다면 규칙 적용 내용을 확인해야 합니다. 두 모드 모두 실패한다면 단순한 라우팅 문제는 아닙니다. 테스트가 끝나면 원래 모드로 되돌리고 결과를 기록하세요. 의미를 모른 채 규칙을 일괄 삭제하지 마세요.

앱 캐시와 기존 연결 처리

가속 서비스에 연결하기 전에 앱이 이미 만든 세션은 기존 경로를 계속 사용할 수 있습니다. 데스크톱으로 돌아갔다가 다시 여는 것만으로는 연결이 재생성되지 않을 수 있으므로 앱을 완전히 종료한 뒤 다시 시작하세요. 앱에 로그아웃이나 캐시 삭제 기능이 있다면 영향이 적은 재시작부터 시도하고, 계정 세션에 문제가 확실할 때만 다시 로그인하세요. 처음부터 모든 로컬 데이터를 삭제하면 새로운 로그인과 동기화 문제가 생길 수 있습니다.

네트워크 전환 후 오래된 DNS 결과가 남을 수도 있습니다. 브라우저는 정상인데 앱만 계속 실패한다면 클라이언트를 끊은 뒤 앱을 닫고 다시 연결한 다음 앱을 시작하세요. 이 순서에서는 앱이 새 네트워크 경로에서 최초 연결을 만들게 됩니다. 그래도 실패하면 같은 지역의 다른 서버와 비교하세요. 서버를 바꾸자 복구되면 기존 서버와 대상 앱을 기록하고, 앱을 재설치해야 복구된다면 앱의 로컬 상태일 가능성이 큽니다.

지역과 대상 서비스의 관계

일부 스트리밍과 온라인 서비스는 출구 지역, 계정 지역, 콘텐츠 라이선스와 로그인 상태에 따라 다른 결과를 반환합니다. 서버에서 일반 웹페이지가 열린다고 모든 지역 콘텐츠를 이용할 수 있다는 뜻은 아닙니다. 대상 서비스에 맞는 지역을 선택하고 서버 페이지의 스트리밍 태그를 참고하세요. Netflix, Disney+, YouTube 등의 태그는 서버 필터링에 사용되지만 대상 서비스는 계정과 콘텐츠 자체를 기준으로 추가 판단할 수 있습니다.

앱에 지역 또는 콘텐츠 이용 불가 안내가 표시된다면 연결 시간 초과와 같은 유형으로 취급하지 마세요. 지역 안내는 앱이 어떤 응답을 받았다는 뜻이므로 서버 지역, 계정 상태와 캐시를 확인해야 합니다. 연결 시간 초과라면 라우팅과 네트워크를 먼저 점검하세요. 오류 원문은 정확하게 작성하고 단순히 “접속 실패”라고만 적지 마세요. 정확한 오류 유형은 대상 서비스 제한, 서버 태그 변경 또는 로컬 규칙 문제를 판단하는 데 도움이 됩니다.

명령줄 도구와 개발 환경

명령줄 도구는 데스크톱 앱의 프록시 설정을 자동으로 상속하지 않는 경우가 많습니다. 현재 클라이언트가 제공하는 로컬 프록시 정보를 확인한 뒤 도구 자체의 문서에 따라 환경 변수나 매개변수를 설정하세요. 다른 클라이언트의 수신 주소를 그대로 복사하거나 구독 주소를 프록시 주소로 사용하지 마세요. 임시 테스트라면 먼저 시스템 프록시를 지원하는 브라우저로 서버를 확인한 뒤 도구 설정을 처리할 수 있습니다.

개발 도구는 시작할 때 프록시 환경을 읽는 경우가 있어 실행 중 시스템 설정을 바꿔도 즉시 적용되지 않을 수 있습니다. 터미널이나 개발 도구를 닫았다가 다시 열고 테스트 명령을 실행하세요. 브라우저는 정상이고 명령줄만 실패했다가 다시 연 뒤 복구된다면 프로세스가 이전 환경을 상속한 것이 원인입니다. 그래도 실패한다면 도구가 프록시를 우회하는지, 인증서 체인을 사용자 지정했는지, DNS 조회를 어느 구성 요소가 수행하는지 확인하세요.

ACCOUNT AND SUPPORT

기기 상태, 요금제 확인과 문의 접수

“기기 수 초과”는 어떻게 판단해야 하나

VPNZe는 동시 접속 기기 수에 제한이 없으므로 정상 사용에 고정된 기기 수 제한이 적용되지 않습니다. 클라이언트에 세션 이상, 인증 만료 또는 중복 로그인과 비슷한 안내가 표시되어도 고정된 기기 수 초과라고 추측하지 마세요. 먼저 같은 계정의 유효한 구독을 사용하고 있는지, 기기 시간이 정확한지, 구독이 업데이트되었는지 확인하고 기존 설정이나 다른 계정의 내용을 가져오지 않았는지도 살펴보세요.

여러 기기에서 동시에 문제가 발생하면 “같은 구독 제공 문제”와 “같은 네트워크 환경 문제”를 구분해야 합니다. 모든 기기가 하나의 접속 네트워크를 사용하며 동시에 실패한다면 먼저 다른 네트워크와 비교하세요. 서로 다른 네트워크에 있는 기기에서도 같은 구독 오류가 발생한다면 계정과 설정을 확인하고, 한 기기에서만 실패한다면 해당 기기의 클라이언트, 권한과 시스템 네트워크를 먼저 점검하세요. 기기 수 제한이 없다고 각 기기의 로컬 설정 차이를 무시해도 되는 것은 아닙니다.

요금제 및 트래픽 상태 확인

연결 실패가 요금제 상태와 뒤섞이는 경우도 있습니다. 사용자 패널에서 현재 서비스 상태, 트래픽과 기간을 확인하고 클라이언트에 남아 있는 서버 목록만으로 추측하지 마세요. 월간 구독은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며 트래픽은 개통일 기준으로 매월 초기화되고 이용 중 업그레이드 차액은 남은 일수에 따라 계산됩니다. 트래픽 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 모두 소진될 때까지 사용하고 영구적으로 만료되지 않습니다.

패널 상태는 정상인데 클라이언트에서 구독 만료로 표시된다면 구독을 다시 가져와 설정을 업데이트하세요. 패널 상태에서 이용 연장이 필요하다면 요금제 페이지에서 선택 내용을 확인한 뒤 사용자 패널에서 처리합니다. 결제 수단은 Alipay, WeChat Pay와 USDT를 지원합니다. 요금제 문제와 서버 장애는 나누어 설명하세요. 전자는 패널 상태와 주문을, 후자는 서버, 네트워크와 오류 로그를 중심으로 다룹니다. 두 문제를 모호한 설명 하나로 섞으면 확인에 더 오래 걸립니다.

최소한의 자체 점검을 마친 뒤 제출

문의하기 전에 적어도 다음 질문에 답할 수 있어야 합니다. 연결하지 않은 상태에서 기본 네트워크가 정상인지, 모든 앱에 영향을 주는지 특정 앱 하나만 영향을 받는지, 같은 지역의 다른 서버로 바꿔 보았는지, 시스템 프록시와 가상 네트워크 모드를 비교했는지, 구독이 업데이트되는지, 절전, 네트워크 전환 또는 피크 시간대가 원인인지 확인하세요. 모든 설정을 바꿀 필요는 없으며 증상과 관련된 비교만 완료하면 됩니다.

연결 자체가 안 된다면 클라이언트 실행 상태, 서버 이름과 첫 번째 오류를 중심으로 첨부하세요. 웹페이지가 열리지 않는다면 브라우저 오류와 DNS 점검 결과를 첨부하고, 속도가 느리다면 실제 용도, 시간대와 비교한 서버를 적습니다. 자주 끊긴다면 유발 동작과 복구 방법을, 구독 업데이트에 실패했다면 요청 또는 해석 오류를, 특정 앱만 실패했다면 브라우저와 앱 버전의 비교 결과를 첨부하세요.

처리 가능한 문의에 포함할 내용

비밀번호, 구독 주소, 전체 설정 파일 또는 접근 인증 정보가 포함된 스크린샷은 제출하지 마세요. 로그는 장애 주변의 내용만 잘라내고 각 부분에 해당 동작을 표시하세요. 하나의 문의에 관련 없는 문제가 여러 개 포함된다면 증상별로 나누어 어떤 문제가 독립적으로 재현되는지 설명합니다. 지원팀은 재현 경로를 기준으로 판단하며 원격으로 기기를 조작하거나 계정 비밀번호를 요구하지 않습니다.

신속히 지원팀에 문의해야 하는 경우

여러 접속 네트워크, 플랫폼과 서버에서 같은 오류가 발생하거나, 패널 상태와 클라이언트 상태가 뚜렷하게 다르거나, 구독을 계속 가져오지 못하고 기존 설정도 작동하지 않거나, 특정 서버가 여러 기기에서 동일하게 비정상적이거나, 권한을 확인한 뒤에도 클라이언트 핵심 프로세스가 시작되지 않는 경우에는 설정을 무작위로 계속 바꿔도 얻는 것이 적습니다. 바로 문의를 접수하세요.

브라우저 하나의 캐시, 앱 하나의 오래된 세션 또는 절전 후 인터페이스가 복구되지 않은 문제라면 해당 장의 방법을 먼저 적용하세요. 특정 시간대에만 장애가 발생한다면 정상 시간에는 재현되지 않을 수 있으므로 시간대를 기록한 뒤 문의하세요. 문의 진입점은 사용자 패널에 있습니다. 이메일 주소 없이 사용자 이름과 비밀번호로 계정 절차를 이용할 수 있습니다.

점검을 마친 뒤 정리하기

문제가 복구되면 임시로 변경한 항목을 하나씩 원래대로 되돌리고 효과가 확인된 설정만 유지하세요. 전역 모드를 임시로 사용했다면 일상적으로 필요한 모드로 되돌리고, 테스트 설정을 만들었다면 기본 설정이 안정적인지 확인한 뒤 정리합니다. 다른 네트워크 도구를 종료했다면 하나씩 다시 켜면서 문제가 재발하는지 관찰하세요. 이렇게 해야 여러 임시 변경을 영구적으로 겹쳐 놓는 대신 실제 원인을 확인할 수 있습니다.

간단한 기록도 남겨 두는 것이 좋습니다. 원래 증상, 확인된 원인, 효과가 있었던 조치와 현재 서버 유형을 적어 두세요. 다음에 비슷한 문제가 생기면 유발 조건이 같은지 먼저 확인하고 모든 단계를 기계적으로 반복하지 마세요. 네트워크 장애는 겉모습이 비슷해도 근본 원인은 다를 수 있습니다. 신뢰할 수 있는 방법은 언제나 먼저 계층을 나눈 뒤 최소한의 변경으로 비교하는 것입니다.