재현 가능한 점검 기준선 세우기
원인을 추측하기 전에 증상을 설명합니다
연결 문제를 오래 끄는 가장 흔한 원인은 처음부터 회선, 클라이언트 또는 계정 문제라고 단정한 뒤 여러 설정을 연달아 바꾸는 것입니다. 변경 항목이 많아지면 연결이 복구되어도 실제로 효과가 있었던 단계를 알기 어렵습니다. 먼저 현상을 구체적으로 적어 두는 편이 안전합니다. 클라이언트에 연결됨으로 표시되는지, 브라우저에서 일반 웹페이지가 열리는지, 국제 서비스만 실패하는지 아니면 모든 웹사이트가 실패하는지, 다른 기기에서도 동시에 발생하는지, 회선을 바꾸면 결과가 달라지는지를 확인하세요. 증상을 구체적으로 설명할수록 다음에 확인할 분기가 줄어듭니다.
점검할 때는 추가 확장 기능이나 복잡한 라우팅 규칙이 없는 테스트 환경을 하나 유지해야 합니다. 브라우저는 새 임시 창을 사용하고, 클라이언트는 기본 규칙으로 설정하며, 시스템에서는 네트워크 경로를 바꾸는 다른 도구를 잠시 종료합니다. 목적은 사용 습관을 영구적으로 바꾸는 것이 아니라 단순한 기준선을 세우는 데 있습니다. 기준선 환경에서 접속된다면 문제는 대개 브라우저 확장 기능, 사용자 지정 규칙, 앱 프록시 또는 여러 네트워크 도구 간 충돌에 있습니다. 기준선에서도 실패한다면 네트워크와 구독 계층을 계속 점검합니다.
문제 범위를 하나의 계층으로 좁힙니다
하나의 연결에는 여러 단계가 포함됩니다. 로컬 네트워크가 요청을 클라이언트로 전달하면 클라이언트가 규칙에 따라 직접 연결할지 프록시를 사용할지 결정하고, 구독에 포함된 회선을 통해 세션을 만든 뒤 DNS가 도메인을 해석하고 대상 서비스가 콘텐츠를 반환합니다. 어느 한 단계에 문제가 생겨도 ‘열리지 않음’으로 나타날 수 있습니다. 따라서 클라이언트의 연결 아이콘만 확인해서는 안 됩니다. 아이콘은 세션이 만들어졌다는 뜻일 뿐, 브라우저·시스템 프록시·DNS·개별 앱이 같은 경로로 작동한다는 의미는 아닙니다.
| 관찰된 현상 | 우선 확인할 계층 | 확인에 사용할 조치 |
|---|---|---|
| 모든 회선에서 연결을 만들 수 없음 | 로컬 네트워크, 클라이언트 권한, 구독 상태 | 네트워크를 바꾸고 구독을 다시 불러옵니다 |
| 연결됨으로 표시되지만 모든 웹페이지가 실패함 | 시스템 프록시, DNS, 가상 네트워크 인터페이스 | 도메인 해석과 직접 요청을 각각 확인합니다 |
| 특정 앱 하나만 접속할 수 없음 | 앱의 프록시 지원, 라우팅 규칙, 캐시 | 전체 적용으로 전환해 테스트한 뒤 앱을 재시작합니다 |
| 특정 시간대에만 눈에 띄게 느려짐 | 로컬 접속과 회선 혼잡 | 테스트 조건을 동일하게 유지한 뒤 회선을 바꿔 비교합니다 |
한 번에 변수 하나만 바꿉니다
비교는 ‘네트워크, 회선, 모드, 앱’ 순서로 진행하는 것이 좋습니다. 먼저 클라이언트와 회선을 그대로 두고 로컬 네트워크만 바꿉니다. 다음에는 네트워크를 유지한 채 회선만 전환하고, 그 후에야 규칙 모드를 조정합니다. 마지막으로 개별 앱을 확인합니다. 매번 같은 접속 동작을 반복하고 결과를 기록하세요. 클라이언트 재설치, DNS 변경, 회선 전환과 라우터 재시작을 동시에 하지 마세요. 이렇게 하면 유효한 결론을 남길 수 없습니다.
테스트 대상도 일정하게 유지해야 합니다. 일반 웹페이지 하나, 국제 회선이 필요한 웹페이지 하나, 자주 사용하는 앱 하나를 고정 샘플로 선택할 수 있습니다. 점검 중인 서비스, 다시 로그인이 필요한 서비스 또는 지역에 따라 다른 페이지를 반환하는 서비스를 유일한 판단 기준으로 삼지 마세요. 일반 웹페이지는 정상이고 국제 웹페이지만 실패한다면 규칙과 회선을 우선 확인합니다. 둘 다 실패하면 시스템 프록시와 DNS를 먼저 봅니다. 웹페이지는 정상인데 앱만 실패한다면 문제는 대체로 앱 계층에 있습니다.
먼저 계정과 서비스 정보를 확인합니다
ZVVPN은 사용자 이름과 비밀번호만으로 가입할 수 있으며 이메일 주소가 필요하지 않습니다. 사용자 패널에 로그인한 뒤 요금제 또는 데이터 패키지를 아직 사용할 수 있는지 먼저 확인하고 최신 구독을 다시 받아야 합니다. 월간 구독은 여러 데이터 용량으로 제공되며 활성화한 날을 기준으로 매월 데이터가 초기화됩니다. 데이터 패키지는 소진될 때까지 사용할 수 있고 영구적으로 만료되지 않습니다. 페이지에 표시된 구독 상태와 클라이언트 캐시가 다르면 사용자 패널의 정보를 기준으로 다시 가져오세요. 오래된 캐시로 반복해서 연결하지 마세요.
120개 이상의 국가 / 170개 이상의 회선을 지원하며 Windows, macOS, iOS, Android와 Linux에서 사용할 수 있고 기기 수 제한이 없습니다. 기기 수에 제한이 없더라도 한 기기에서 여러 프록시 클라이언트를 동시에 실행해야 한다는 뜻은 아닙니다. 여러 클라이언트가 시스템 프록시나 가상 네트워크 인터페이스를 함께 사용하면 오히려 흔한 충돌 원인이 됩니다. 요금제 내용을 비교하려면 요금제 및 데이터 규칙을 확인하고, 지역과 회선 유형을 확인하려면 글로벌 회선 안내를 확인하세요.
완전히 연결되지 않을 때의 판단 절차
‘클라이언트가 열리지 않음’과 ‘회선에 연결되지 않음’을 구분합니다
클라이언트가 시작되지 않거나 시작 후 화면이 비어 있거나 시스템에서 네트워크 권한이 없다고 알리는 문제는 연결을 눌렀을 때 회선이 시간 초과되는 문제와 다릅니다. 전자는 설치 상태, 시스템 권한과 보안 정책을 먼저 확인해야 하고, 후자만 네트워크와 회선 진단으로 넘어갑니다. 클라이언트에 구독 지역이 정상적으로 표시되지만 어떤 회선도 연결되지 않는다면 구독을 적어도 한 번은 읽은 상태입니다. 이때는 현재 네트워크가 연결 방식을 제한하는지, 시스템에서 다른 클라이언트가 네트워크 인터페이스를 사용 중인지 우선 확인하세요.
다른 프록시, 네트워크 필터, 기업용 접속 또는 트래픽 분석 도구를 완전히 종료한 뒤 ZVVPN 클라이언트를 다시 시작하세요. 창만 닫아서는 백그라운드 서비스가 종료되지 않을 수 있으므로 시스템 트레이, 메뉴 막대 또는 프로세스 관리 화면에서 관련 프로그램이 실제로 종료됐는지 확인합니다. 이후 기본 규칙을 유지하고 추가 설정은 가져오지 않은 상태에서 다른 지역의 회선을 선택해 테스트하세요. 한 회선은 실패하고 다른 회선은 성공한다면 클라이언트의 기본 기능은 정상이며 회선 접근성에 문제가 집중된 것입니다. 모두 실패하면 로컬 접속 네트워크를 바꿔 보세요.
네트워크를 바꿔 로컬 접속 문제를 판단합니다
가정용 인터넷, 사무실 네트워크, 공용 네트워크와 모바일 네트워크는 서로 다른 출구 정책을 사용할 수 있습니다. 연결에 실패했을 때는 많은 회선을 연달아 바꾸기보다 클라이언트와 구독을 그대로 둔 채 네트워크를 바꿔 비교하는 것이 효과적입니다. 네트워크를 바꾼 뒤 연결된다면 기존 네트워크의 라우팅 오류, 게이트웨이 캐시, 기업 정책 또는 로컬 기기 설정에 문제가 있을 수 있습니다. 이 경우 클라이언트를 재설치하기보다 현재 네트워크 장비를 재시작하고 네트워크 설정을 다시 받은 뒤 시스템 시간을 확인하는 편이 더 의미 있습니다.
시스템 시간 오차는 보안 세션 설정에 영향을 줄 수 있습니다. 날짜, 시간과 시간대를 자동 동기화로 설정한 다음 클라이언트를 완전히 종료하고 다시 여세요. 기기가 기업 관리 환경에 있다면 조직에서 배포한 네트워크 프로파일이나 인증서 정책이 설치되어 있는지도 확인해야 합니다. 업무용 기기의 관리 설정을 임의로 삭제하지 말고 네트워크 관리자에게 허용된 사용 범위를 먼저 확인하세요. 개인 기기에 이전 클라이언트를 설치한 적이 있다면 오래된 가상 네트워크 인터페이스가 계속 활성화되어 있는지도 확인합니다.
권한과 가상 네트워크 인터페이스를 확인합니다
Windows와 Linux에서는 클라이언트가 네트워크 인터페이스를 만들고 라우팅을 변경하는 데 필요한 권한을 갖고 있는지 확인해야 합니다. macOS, iOS와 Android에서는 일반적으로 처음 연결할 때 네트워크 설정 추가를 요청합니다. 한 번 거부하면 클라이언트 화면에서는 연결을 누를 수 있어도 시스템이 실제 인터페이스를 만들지 않습니다. 시스템 네트워크 또는 개인정보 보호 설정에서 ZVVPN 관련 네트워크 구성이 존재하고 활성화되어 있는지 확인하세요. 구성이 중복되어 있다면 클라이언트를 종료한 뒤 이전 설치에 속한 것이 확실한 중복 항목만 삭제하고 현재 클라이언트에서 다시 권한을 요청합니다.
| 플랫폼 | 집중적으로 확인할 위치 | 자주 나타나는 현상 |
|---|---|---|
| Windows | 네트워크 어댑터, 시스템 프록시, 백그라운드 서비스 | 연결이 초기화 단계에서 멈추거나 인터페이스가 나타나지 않음 |
| macOS | 네트워크 확장 기능, 네트워크 구성, 시스템 권한 | 권한을 반복해서 요청하거나 연결 직후 복구됨 |
| iOS | 시스템 네트워크 구성과 현재 네트워크 상태 | 연결 스위치가 되돌아가거나 구성이 적용되지 않음 |
| Android | 네트워크 구성, 백그라운드 제한, 다른 클라이언트 | 이미 실행 중인 네트워크 서비스가 있다는 알림 |
| Linux | 인터페이스 권한, 라우팅 테이블, 데스크톱 네트워크 관리 | 명령을 실행해도 라우팅이 바뀌지 않음 |
구독과 회선을 분리해 확인합니다
구독을 업데이트할 수 있다고 해서 모든 회선이 현재 네트워크에서 연결된다는 뜻은 아닙니다. 특정 회선 연결에 실패했다고 구독이 만료된 것도 아닙니다. 먼저 클라이언트에 회선 이름이 표시되는지 확인하고, 업데이트 시간이나 결과를 확인한 뒤 서로 다른 지역을 선택해 각각 테스트하세요. 구독 목록이 비어 있거나 업데이트 오류가 발생하면 이 페이지의 구독 장으로 이동합니다. 목록은 정상인데 모든 연결이 실패하면 네트워크와 권한을 계속 확인합니다. 일부 회선만 실패한다면 다른 회선을 우선 사용하고 문의 진단을 위해 실패한 회선 이름을 기록해 두세요.
채팅 기록이나 이전 기기에서 오래된 구독 텍스트를 복사해 현재 설정을 덮어쓰지 마세요. 사용자 패널의 다운로드 또는 구독 메뉴에서 다시 받아 클라이언트의 가져오기 기능으로 불러와야 합니다. 다음 예시 주소는 형식을 이해하기 위한 것일 뿐 실제 구독에 사용할 수 없습니다:
https://example.com/sub?token=YOUR_TOKEN
가져온 뒤에는 클라이언트가 생성한 기본 그룹을 먼저 사용하고 복잡한 규칙을 바로 추가하지 마세요. 기본 설정으로 연결된다면 개인 규칙을 단계적으로 복원합니다. 이렇게 하면 문제가 서비스 설정에서 발생했는지 로컬 사용자 설정에서 발생했는지 구분할 수 있습니다. 구독 링크는 비밀번호와 같은 민감 정보로 관리하고 스크린샷, 공개 문서 또는 여러 사람이 공유하는 설정 저장소에 넣지 마세요.
연결됐지만 웹페이지가 열리지 않음
연결 상태가 트래픽이 회선으로 들어갔다는 뜻은 아닙니다
클라이언트에 연결됨으로 표시되는 것은 보통 클라이언트와 특정 회선 사이에 세션이 만들어졌다는 의미입니다. 브라우저 요청이 이 세션으로 들어가는지는 시스템 프록시, 가상 네트워크 모드, 브라우저 자체 설정과 라우팅 규칙에 따라 달라집니다. 먼저 클라이언트의 연결 로그나 상태 페이지를 열어 둔 뒤 일반 웹페이지에 접속하세요. 접속 동작 후 새 기록이 전혀 생기지 않는다면 브라우저 트래픽이 클라이언트로 들어가지 않는 것일 수 있습니다. 요청은 기록되지만 직접 연결 또는 거부로 표시된다면 규칙을 확인해야 합니다. 요청이 회선을 통해 전달됐는데 응답이 없다면 DNS와 회선을 확인합니다.
일부 브라우저는 별도로 프록시를 설정할 수 있고 확장 기능이 네트워크를 대신 제어할 수도 있습니다. 점검할 때는 확장 기능을 로드하지 않은 임시 브라우저 환경을 만들고 브라우저가 시스템 네트워크 설정을 따르게 하세요. 임시 환경에서 정상이라면 확장 기능을 하나씩 복원하고 한 번에 모두 활성화하지 마세요. 프록시 주소를 수동으로 입력했던 브라우저는 오래된 설정도 삭제해야 합니다. 브라우저가 더 이상 존재하지 않는 로컬 포트로 요청을 보내는 일을 막을 수 있습니다.
도메인 해석과 웹 요청을 나눠 확인합니다
웹 접속에는 ‘도메인을 주소로 해석하는 단계’와 ‘대상 주소로 요청을 보내는 단계’가 포함됩니다. 해석에 실패하면 브라우저에 서버를 찾을 수 없다는 메시지가 표시되는 경우가 많고, 요청 단계에서 실패하면 계속 대기하거나 연결이 재설정되거나 인증서 페이지가 비정상적으로 나타나는 경우가 많습니다. 시스템 터미널에서 다음과 같은 일반 점검을 실행할 수 있으며, 예시 도메인에는 계정 정보가 포함되지 않습니다:
nslookup example.com
curl -I https://example.com
도메인 조회에 실패하지만 클라이언트의 회선 연결이 안정적으로 유지된다면 DNS를 우선 처리합니다. 도메인은 해석되지만 요청이 실패한다면 시스템 프록시, 회선과 브라우저를 확인하세요. 명령줄 요청은 정상인데 브라우저만 실패한다면 브라우저 확장 기능, 캐시, 독립 프록시 또는 보안 정책에 문제가 있을 가능성이 큽니다. 명령줄 도구의 사용 가능 여부는 운영체제마다 다르므로 도구가 없다고 별도로 설치할 필요는 없습니다. 서로 다른 브라우저 두 개로 같은 비교를 수행해도 됩니다.
규칙 모드와 대상 도메인을 확인합니다
규칙 모드는 도메인, 주소 또는 앱에 따라 요청 경로를 결정합니다. 오래된 규칙, 잘못된 규칙 순서 또는 기본 규칙을 덮어쓰는 사용자 지정 항목 때문에 대상 웹사이트가 잘못 직접 연결될 수 있습니다. 테스트 트래픽이 모두 회선을 통과하도록 하는 모드로 잠시 전환한 뒤 웹페이지를 다시 여세요. 이때 복구된다면 회선과 웹페이지 자체는 접근 가능하고 규칙 매칭에 문제가 집중된 것입니다. 확인이 끝난 뒤 테스트 모드를 장기간 유지하지 말고 해당 도메인이 속한 규칙을 찾아 수정한 다음 평소 모드로 돌아가세요.
웹페이지는 주 도메인, 정적 리소스 도메인, 인증 도메인과 미디어 도메인을 함께 로드하는 경우가 많습니다. 주 도메인에만 규칙을 추가하면 페이지 골격은 열리지만 이미지, 로그인 버튼 또는 콘텐츠 영역이 비어 있을 수 있습니다. 브라우저 개발자 도구의 네트워크 목록으로 실패한 요청의 도메인을 확인할 수 있지만, 로그인 매개변수·세션 식별자·구독 내용이 포함된 전체 요청 주소를 공개 채널에 보내지 마세요. 문의할 때는 도메인만 남기고 쿼리 매개변수는 가리세요.
연결 전환 후 남은 캐시 상태를 정리합니다
직접 연결과 프록시 사이를 자주 전환하면 브라우저에 이전 연결, DNS 캐시 또는 사이트 세션이 남을 수 있습니다. 먼저 대상 웹사이트의 탭을 완전히 닫고 브라우저를 종료한 뒤 다시 여세요. 그래도 문제가 계속되면 모든 방문 기록을 처음부터 삭제하기보다 해당 웹사이트의 캐시와 사이트 데이터를 정리하세요. 사이트 데이터를 삭제하면 다시 로그인해야 할 수 있으므로 계정 인증 정보가 안전하게 보관되어 있는지 먼저 확인합니다.
시스템이 절전 모드에서 복구되거나 네트워크가 유선에서 무선으로 바뀌거나 기기가 다른 접속 지점으로 이동하면 이전 연결이 더 이상 유효하지 않은 경로를 계속 사용할 수 있습니다. 이때는 먼저 클라이언트를 연결 해제하고 시스템 네트워크가 일반 접속을 회복할 때까지 기다린 뒤 다시 연결하세요. 시스템이 유효한 네트워크를 아직 얻지 못한 상태에서 연결 버튼을 연속으로 누르지 마세요. 완료되지 않은 세션이 반복 생성되어 로그를 해석하기 어려워질 수 있습니다.
단일 페이지에 의존하지 않고 출구 변화를 확인합니다
회선이 적용됐는지 확인할 때는 클라이언트 아이콘만 보거나 지역 정보를 캐시할 수 있는 웹사이트 하나에만 의존해서는 안 됩니다. 연결 전후의 출구 정보를 비교하고 DNS 요청이 예상한 경로를 따르는지 확인할 수 있습니다. 자세한 확인 방법은 출구 IP와 DNS를 확인하는 전체 방법에서 볼 수 있습니다. 출구가 이미 바뀌었는데 웹페이지가 열리지 않는다면 ‘회선을 전혀 거치지 않은 것’이 아니므로 규칙, 대상 서비스 상태와 브라우저 계층으로 돌아가 판단해야 합니다.
대상 웹사이트는 계정 지역, 브라우저 저장 데이터 또는 콘텐츠 이용 권한에 따라 다른 결과를 반환할 수 있습니다. 회선 지역이 올바르다고 해서 이전 세션이 즉시 바뀌는 것은 아닙니다. 대상 계정에서 로그아웃하고 사이트 데이터를 정리한 뒤 다시 접속할 수 있지만, 점검을 위해 계정 정보를 자주 바꾸지는 마세요. 같은 회선에서 여러 기기의 결과가 동일하고 회선을 바꾸면 복구된다면 대상 도메인과 회선 지역을 기록해 회선 측에 추가 분석을 요청하세요.
속도 저하와 피크 시간대 끊김
먼저 로컬 접속과 국제 경로 중 어디에서 느려지는지 판단합니다
속도 문제는 비교 조건이 있어야 판단할 수 있습니다. 먼저 클라이언트를 연결 해제하고 현재 네트워크에서 일반 웹페이지와 평범한 콘텐츠 다운로드가 정상인지 확인한 다음, 같은 기기·같은 네트워크·같은 대상을 사용해 회선 연결 상태를 반복 테스트하세요. 직접 연결 자체가 불안정하다면 무선 신호, 라우터, 인터넷 출구 또는 시스템 백그라운드 사용량을 우선 처리합니다. 국제 회선은 로컬 접속 계층의 패킷 손실과 간섭을 해결할 수 없으므로 무작정 회선을 바꾸면 실제 원인을 가릴 뿐입니다.
무선 네트워크는 거리, 장애물, 동일 주파수 간섭과 절전 설정의 영향을 특히 많이 받습니다. 점검할 때는 접속 장치 가까이 이동하고 클라우드 동기화, 시스템 업데이트, 동영상 업로드와 지속적으로 대역폭을 사용하는 작업을 일시 중지하세요. 가능하다면 유선 네트워크로도 비교해 보세요. 특정 속도 수치를 목표로 하기보다 웹페이지 최초 표시, 지속 다운로드와 동영상 버퍼링이 함께 개선되는지 관찰하면 됩니다. 로컬 기준선이 안정된 뒤에야 회선 간 비교가 의미 있습니다.
회선을 비교할 때 작업을 동일하게 유지합니다
회선을 선택할 때 지리적 거리만 봐서는 안 됩니다. 사용자와 입구, 입구와 출구, 출구와 대상 서비스 사이의 라우팅이 모두 결과에 영향을 줍니다. 먼저 지리적으로 가까운 지역을 선택한 다음 대상 서비스 지역과 일치하는 회선을 고르고 같은 작업으로 테스트하세요. 회선을 바꾼 뒤에는 기존 다운로드나 재생 세션을 종료하고 대상 콘텐츠를 다시 열어 이전 연결이 이전 경로를 계속 사용하지 않도록 합니다.
어떤 회선은 웹 응답이 빠르지만 대용량 파일의 지속 전송이 느릴 수 있습니다. 경로는 안정적이지만 사용 가능한 대역폭이 제한된 경우일 수 있습니다. 다운로드 속도는 괜찮은데 웹페이지가 자주 멈춘다면 패킷 손실, DNS 대기 또는 연결 재사용 이상을 의심할 수 있습니다. 동영상 화질만 낮아진다면 대상 플랫폼의 비트레이트, 적응형 정책과 지역 판단도 고려해야 합니다. 스트리밍 화질 점검 방법은 화질 저하 원인과 회선 선택 기준에서 확인할 수 있습니다.
| 증상 | 가능성이 높은 원인 | 권장 비교 방법 |
|---|---|---|
| 모든 네트워크 작업이 느림 | 로컬 접속 또는 시스템 백그라운드 사용량 | 회선을 끊고 백그라운드 작업을 일시 중지합니다 |
| 웹페이지 최초 표시만 느리고 이후 로딩은 정상 | DNS, 핸드셰이크 또는 연결 재사용 | 브라우저를 바꾸고 해석을 확인합니다 |
| 지속 전송 속도가 점차 떨어짐 | 경로 혼잡 또는 무선 품질 변동 | 네트워크와 회선을 각각 바꿔 테스트합니다 |
| 특정 서비스만 느림 | 대상 서비스, 지역 또는 라우팅 규칙 | 같은 지역의 다른 회선과 비교합니다 |
피크 시간대에는 단일 결과보다 지속성을 봅니다
피크 시간대의 끊김은 뚜렷한 시간대 특성을 보이는 경우가 많습니다. 문제가 발생한 시점의 회선을 유지한 채 다른 지역 회선을 선택해 비교하고, 같은 시간대에 로컬 일반 네트워크도 느려지는지 확인하세요. 모든 회선과 직접 연결 작업이 함께 느려진다면 로컬 통신사의 출구나 가정용 네트워크를 우선 처리하는 편이 좋습니다. 특정 회선만 정해진 시간대에 느려진다면 다른 회선으로 바꾸고 반복되는 시간대와 회선 이름을 기록하세요.
짧은 시간에 계속 새로 고침하며 안정성을 판단하지 마세요. 웹페이지 새로 고침은 캐시를 사용할 수 있고 속도 측정 페이지도 매번 다른 대상을 선택할 수 있습니다. 완전한 동영상 재생, 지속 다운로드, 원격 회의 또는 AI 도구의 연속 대화에서 규칙적인 멈춤이 나타나는지 관찰하는 편이 더 유용합니다. 테스트 작업은 평소 사용 목적에 가까워야 하지만 여러 고용량 작업을 동시에 진행하지 마세요. 그래야 어느 작업이 다른 연결에 영향을 줬는지 판단할 수 있습니다.
프로토콜, 모드와 기기 성능을 확인합니다
연결 방식마다 시스템 자원, 네트워크 환경과 라우팅 정책에 대한 적응성이 다릅니다. 클라이언트에서 연결 방식을 선택할 수 있다면 기본 설정이 실패한 뒤 하나씩 비교할 수 있지만 기록 없이 자주 전환하지 마세요. 성능이 낮은 기기, 오랫동안 재시작하지 않은 시스템, 백그라운드에서 많은 네트워크 필터가 실행되는 환경도 암호화와 전달의 병목이 될 수 있습니다. 이때는 회선을 반복해서 바꾸기보다 불필요한 프로그램을 종료하고 클라이언트를 재시작하는 편이 효과적입니다.
라우터가 집 전체의 트래픽을 전달한다면 처리 성능, 펌웨어 네트워크 스택과 규칙 복잡도가 속도에 직접 영향을 줍니다. 단일 기기의 클라이언트는 정상인데 집 전체 구성이 눈에 띄게 느리다면 문제를 회선 자체가 아니라 라우터로 좁혀야 합니다. 집 전체 네트워크 가속 구성 실측 비교를 참고해 펌웨어 요구 사항, 라우팅 관리와 기기 부하 사이의 균형을 확인할 수 있습니다.
데이터 상태도 판단에 영향을 줍니다
월간 구독 데이터는 활성화한 날을 기준으로 매월 초기화되며, 요금제는 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB입니다. 이용 중 업그레이드하면 차액이 남은 일수에 따라 계산됩니다. 데이터 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 소진될 때까지 사용할 수 있고 영구적으로 만료되지 않습니다. 연결이 갑자기 중단되거나 작업을 계속할 수 없다면 먼저 사용자 패널에서 현재 사용 가능 상태를 확인하세요. 요금제 상태를 회선 속도 변동으로 오해하지 마세요.
요금제를 변경해야 한다면 요금제 페이지에서 원래 규칙을 확인하세요. 결제 수단은 Alipay, WeChat Pay와 USDT이며 7일 이내 무조건 환불이 가능합니다. 속도 문제를 점검할 때 단 한 번의 테스트만으로 요금제를 바꾸지는 않는 것이 좋습니다. 먼저 로컬 네트워크, 대상 서비스와 회선 차이를 확인하고 실제 데이터 사용량이 달라졌을 때 요금제 조정을 고려하세요.
잦은 연결 끊김과 자동 재연결
먼저 어떤 동작 뒤에 연결이 끊기는지 관찰합니다
잦은 연결 끊김은 회선 변동만으로 발생하지 않습니다. 기기 절전 모드, 화면 꺼짐, 무선 네트워크 전환, 시스템 업데이트, 라우터 재접속과 클라이언트 백그라운드 종료도 세션을 끊을 수 있습니다. 점검할 때 ‘또 끊겼다’고만 기록하지 말고 끊기기 직전에 무엇이 있었는지 적으세요. 기기가 절전 모드에서 막 복구됐는지, 다른 접속 지점으로 이동했는지, 유선과 무선을 전환했는지, 특정 앱이 대량 전송을 시작했는지를 확인합니다.
절전 모드에서 복구할 때마다 실패하지만 평소 사용 중에는 안정적이라면 시스템이 네트워크를 복구하는 순서와 클라이언트 자동 재연결을 우선 확인합니다. 가만히 있어도 일정하게 끊긴다면 절전 설정, 백그라운드 제한과 회선을 확인하세요. 이동 중에만 끊긴다면 네트워크 전환이 주원인일 가능성이 큽니다. 발생 조건을 명확히 하면 우연한 문제를 오래 기다리지 않고 같은 동작으로 재현할 수 있습니다.
네트워크 전환 후 세션을 다시 만듭니다
기기가 가정용 네트워크에서 다른 네트워크로 전환되면 로컬 주소, 기본 게이트웨이와 출구 경로가 모두 바뀝니다. 기존 세션은 대개 새 경로로 그대로 이동할 수 없으며 클라이언트가 변화를 감지해 다시 연결해야 합니다. 클라이언트에는 연결됨으로 표시되지만 실제로 접속할 수 없다면 먼저 수동으로 연결을 끊고 일반 네트워크가 복구됐는지 확인한 뒤 다시 연결하세요. 네트워크가 바뀌는 동안 클라이언트를 연속해서 켰다 끄지 마세요. 시스템에 여러 개의 일시적인 인터페이스 상태가 남을 수 있습니다.
여러 무선 접속 지점을 사용하는 환경에서는 신호가 비슷할 때 기기가 반복해서 로밍할 수 있습니다. 겉으로는 무선 아이콘이 바뀌지 않아도 하위 연결은 전환될 수 있습니다. 잠시 한 접속 지점 근처에 고정해 테스트하거나 다른 네트워크와 비교하세요. 고정된 환경에서 안정적이고 이동할 때만 끊긴다면 원격 회선을 계속 바꾸기보다 로컬 무선 범위와 로밍을 먼저 개선해야 합니다.
네트워크 인터페이스를 선점하는 프로그램을 종료합니다
여러 프록시 클라이언트, 기업용 접속 소프트웨어, 보호 필터 도구와 가상 머신 네트워크 구성 요소가 동시에 라우팅을 변경할 수 있습니다. 이런 프로그램은 화면에 표시되지 않아도 백그라운드 서비스가 네트워크 변화 때 시스템 설정을 다시 쓸 수 있습니다. 점검 중에는 클라이언트 하나만 남기고 관련 프로세스가 모두 종료됐는지 확인하세요. 충돌 프로그램을 종료한 뒤 안정된다면 평소 사용할 도구를 하나 정해야 하며, 여러 도구가 시작 순서에 따라 서로의 설정을 덮어쓰게 두지 않는 것이 좋습니다.
브라우저 확장 기능은 일반적으로 하위 세션을 직접 끊지는 않지만 ‘웹페이지가 갑자기 모두 실패하는’ 것처럼 보이게 할 수 있습니다. 실제로 연결이 끊겼는지 판단하려면 클라이언트 상태와 다른 앱도 함께 확인하세요. 클라이언트에 정상 요청이 계속되고 브라우저만 실패한다면 브라우저 설정으로 돌아갑니다. 모든 앱이 동시에 중단되고 클라이언트 상태도 바뀌었다면 연결 계층의 끊김입니다.
절전과 백그라운드 정책이 연결을 종료할 수 있습니다
노트북과 모바일 기기는 배터리를 절약하기 위해 화면이 꺼진 뒤 네트워크 활동을 제한할 수 있습니다. 클라이언트가 백그라운드에서 실행되도록 허용하고 백그라운드 앱을 자동으로 중지하는 모드는 피하세요. 시스템 업데이트 후에는 기존 권한을 다시 확인해야 할 수도 있습니다. 화면을 잠근 뒤 항상 끊긴다면 먼저 백그라운드 권한을 확인하고, 그다음 클라이언트에 자동 재연결 기능이 있는지 확인하세요. 연결을 유지하기 위해 시스템 보안 잠금 전체를 끄지 말고 클라이언트의 백그라운드 네트워크와 관련된 항목만 조정합니다.
데스크톱 시스템도 유휴 상태의 무선 어댑터나 가상 네트워크 인터페이스를 끌 수 있습니다. 전원과 네트워크 설정에서 절전 옵션을 확인하고 전원 연결 상태와 배터리 상태를 각각 비교하세요. 배터리 상태에서만 자주 끊긴다면 절전 정책에 가까운 문제입니다. 두 상태가 같다면 회선과 네트워크를 확인합니다.
로그로 능동 종료와 시간 초과를 구분합니다
클라이언트 로그의 오류 원문은 화면에 표시되는 ‘연결 실패’보다 더 유용합니다. 능동 종료에는 시스템 절전, 인터페이스 종료, 권한 철회 또는 사용자 동작이 함께 기록되는 경우가 많습니다. 시간 초과는 네트워크 접근 불가나 회선 응답 중단과 관련된 경우가 많고, 인증 또는 구독 오류는 구독 장에서 처리해야 합니다. 로그를 복사할 때는 장애 전후의 관련 구간만 남기고 구독 링크, 토큰과 계정 정보는 가리세요.
로그가 너무 많다면 안전하게 삭제할 수 있는 오래된 로그를 먼저 정리한 뒤 한 번 장애를 재현하고 즉시 내보내세요. 재현 과정은 최대한 단순하게 유지합니다. 예를 들어 고정된 웹페이지 하나를 계속 열어 둔 상태에서 화면 잠금, 네트워크 전환 또는 절전처럼 연결을 끊는 동작을 실행합니다. 이렇게 하면 로그의 시간 흐름이 분명해져 고객 지원 담당자가 시스템 이벤트와 연결 끊김의 선후 관계를 판단하기 쉽습니다.
| 발생 상황 | 우선 처리할 항목 | 확인 방법 |
|---|---|---|
| 화면 잠금 또는 화면 꺼짐 후 연결 끊김 | 백그라운드 권한과 절전 정책 | 전면 실행과 백그라운드 실행을 각각 테스트합니다 |
| 네트워크 전환 후 연결 끊김 | 로컬 네트워크가 복구된 뒤 다시 연결합니다 | 고정 네트워크와 이동 상황을 비교합니다 |
| 다른 네트워크 도구를 실행한 뒤 연결 끊김 | 인터페이스와 라우팅 충돌 | 클라이언트 하나만 실행합니다 |
| 가만히 사용하는 중에도 연결 끊김 | 회선, 로컬 네트워크와 시스템 서비스 | 네트워크와 회선을 각각 바꿔 재현합니다 |
구독 업데이트 실패와 구성 오류
다운로드할 수 없는 문제인지 해석할 수 없는 문제인지 먼저 판단합니다
구독 업데이트 실패는 보통 두 단계로 나뉩니다. 클라이언트가 구독 내용을 받지 못했거나, 내용을 받았지만 해석하지 못한 경우입니다. 전자는 네트워크 요청 실패, 잘못된 주소 또는 접속 시간 초과로 나타나는 경우가 많고, 후자는 구성 형식 오류, 빈 콘텐츠 또는 지원되지 않는 필드로 나타나는 경우가 많습니다. 두 문제는 처리 순서가 다릅니다. 다운로드할 수 없다면 먼저 사용자 패널의 현재 구독 메뉴와 로컬 네트워크를 확인하고, 해석할 수 없다면 가져오기 방식, 클라이언트 유형과 이전 구성의 잔여 항목을 확인하세요.
구독 링크의 문자를 직접 편집하거나 스크린샷에서 링크를 인식하지 마세요. 복사하는 과정에서 공백, 줄바꿈 또는 문장 부호가 섞이기 쉽고, 특히 메신저를 거치면 더 그렇습니다. 사용자 패널에서 직접 복사 또는 가져오기 메뉴를 사용하고 클라이언트에 새 구독 항목을 만들어야 합니다. 새 항목이 정상 작동하면 이전 항목을 삭제하세요. 유일하게 작동하는 구성을 먼저 삭제하지 말아야 비교 기준을 잃지 않습니다.
현재 계정 상태와 구독 출처를 확인합니다
ZVVPN 가입에는 사용자 이름과 비밀번호만 필요하며 이메일 주소가 필요하지 않습니다. 기기에 여러 사용자 이름이 저장되어 있다면 먼저 활성화된 요금제 또는 데이터 패키지가 있는 계정으로 로그인했는지 확인하세요. 비슷한 사용자 이름, 브라우저에 저장된 이전 세션 또는 다른 계정의 구독을 계속 사용하는 클라이언트 때문에 패널과 클라이언트 상태가 달라질 수 있습니다. 사용자 패널에서 로그아웃한 뒤 다시 로그인하고 현재 페이지에서 구독을 받아 계정 혼동을 줄이세요.
구독 주소는 민감한 자격 증명이므로 공개 스크린샷, 포럼 첨부 파일 또는 공유 문서로 전달해서는 안 됩니다. 주소가 유출됐다고 의심되면 사용자 패널에서 제공하는 보안 관리 기능을 사용해 처리한 뒤 다시 가져오세요. 문의할 때 전체 구독 주소를 보낼 필요는 없습니다. 업데이트 오류, 클라이언트 플랫폼과 오류 원문만 설명하면 됩니다. 계정 확인이 필요하면 고객 지원이 문의 내 계정 정보로 처리해야 하며 공개 자격 증명을 요구해서는 안 됩니다.
이전 캐시를 덧붙여 가져오지 말고 정리합니다
같은 구독을 반복해서 가져오면 같은 이름의 그룹이 여러 개 생길 수 있고, 클라이언트가 계속 이전 그룹을 사용해 업데이트가 적용되지 않았다고 생각하게 됩니다. 먼저 현재 선택된 그룹의 출처를 기록한 뒤 수동으로 업데이트를 실행하고 회선 목록이 바뀌는지 확인하세요. 중복 구독이 명확하게 표시된다면 패널에서 방금 가져온 항목을 남기고 이전 항목을 비활성화한 뒤 테스트합니다. 새 항목이 작동하는 것을 확인한 다음 이전 항목을 정리하세요.
일부 클라이언트는 마지막으로 성공한 업데이트 내용을 캐시합니다. 이번 다운로드가 실패해도 목록은 남아 있지만 업데이트 시간은 바뀌지 않을 수 있습니다. ‘회선이 아직 보인다’는 이유만으로 업데이트가 성공했다고 판단하지 말고 업데이트 결과나 로그를 확인하세요. 캐시된 회선으로 연결할 수 있다면 일단 사용하면서 업데이트 요청을 점검합니다. 캐시도 사용할 수 없다면 계정 상태와 네트워크를 함께 확인해야 합니다.
기본 네트워크로 구독 요청을 확인합니다
구독 업데이트 자체도 하나의 네트워크 요청입니다. 현재 시스템 프록시가 손상되어 있으면 클라이언트가 잘못된 프록시를 통해 자신의 구독을 업데이트하려 하면서 문제가 반복될 수 있습니다. 먼저 연결을 끊어 시스템이 일반 네트워크를 회복하도록 한 뒤 구독을 업데이트하거나, 다른 사용 가능한 네트워크에서 시도하세요. 연결을 끊은 뒤 업데이트된다면 구독 주소는 정상이고 현재 프록시 또는 규칙에 문제가 있는 것입니다. 네트워크를 바꿔도 실패하면 패널 메뉴와 클라이언트 가져오기 방식을 다시 확인합니다.
브라우저에서 사용자 패널이 열린다고 해서 클라이언트가 구독을 반드시 다운로드할 수 있는 것은 아닙니다. 두 프로그램이 서로 다른 네트워크 경로와 인증서 환경을 사용할 수 있기 때문입니다. 반대로 클라이언트 업데이트가 성공해도 브라우저 프록시가 정상이라는 뜻은 아닙니다. 따라서 업데이트 테스트는 별도로 기록하고 웹 접속 결과와 섞어 판단하지 마세요.
사용자 지정 구성은 최소 내용부터 복원합니다
기본 구독은 정상적으로 해석되지만 개인 규칙을 추가한 뒤 오류가 발생한다면 사용자 지정 내용을 최소화하고 한 구간씩 복원하세요. 흔한 문제로는 들여쓰기 수준 불일치, 같은 이름의 필드 중복, 존재하지 않는 그룹을 참조하는 규칙과 텍스트에 섞인 보이지 않는 문자가 있습니다. 설정 파일이 공백과 계층에 민감하다면 서식 있는 편집기에서 수정하지 말고 일반 텍스트 편집기를 사용하며 수정 전 사본을 보관하세요.
subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
test-domain: example.com
위 내용은 구조를 보여 주기 위한 예시일 뿐 어떤 클라이언트의 완전한 구성도 아니며 실제 자격 증명도 포함하지 않습니다. 실제로 사용할 때는 클라이언트의 내장 가져오기 절차를 우선 사용하고 본 서비스의 구독 내용을 직접 조합하지 마세요. 클라이언트에서 지원되지 않는 필드라고 표시하면 해당 클라이언트에 맞는 가져오기 메뉴로 돌아가야 하며 서비스 측 구독을 반복해서 수정해서는 안 됩니다.
요금제 상태와 클라이언트 오류를 구분합니다
월간 구독 데이터는 활성화한 날을 기준으로 매월 초기화되고, 데이터 패키지는 소진될 때까지 사용할 수 있으며 영구적으로 만료되지 않습니다. 이용 중 요금제를 업그레이드하면 차액이 남은 일수에 따라 계산됩니다. 패널의 상태가 예상과 다르면 먼저 요금제 규칙과 주문 기록을 확인한 뒤 결제 문의를 제출할지 결정하세요. 클라이언트 해석 오류는 결제를 반복한다고 해결되지 않으며, 결제 상태가 정상이어도 로컬 형식 오류를 고칠 수 없습니다. 두 문제는 분리해 처리해야 합니다.
본 서비스는 기기 수 제한 없이 사용할 수 있지만 각 기기는 현재 계정에서 받은 유효한 구독을 사용해야 하며 여러 사람에게 공개적으로 공유해서는 안 됩니다. 기기 수 제한이 없다는 사실이 구독 관리 의무를 없애지는 않습니다. 새 기기에서 가져오기에 실패하면 먼저 정상 작동하는 기기에서 패널 메뉴가 여전히 사용 가능한지 확인한 뒤 두 기기의 클라이언트와 가져오기 방식을 비교하세요.
특정 앱이 프록시를 사용하지 않음과 모바일 백그라운드 연결 끊김
웹페이지는 정상인데 앱이 실패하면 앱의 네트워크 모델을 먼저 확인합니다
브라우저는 접속되지만 특정 앱에 접속할 수 없다면 하위 회선이 완전히 중단된 것은 아닐 가능성이 큽니다. 앱이 별도 프록시 설정, 고정 네트워크 인터페이스, 특수 도메인, 지속 연결 또는 시스템 프록시를 따르지 않는 요청 방식을 사용할 수 있습니다. 먼저 해당 앱을 실행할 때 클라이언트에 요청 기록이 나타나는지 확인하세요. 기록이 전혀 없다면 앱 트래픽이 현재 프록시 모드를 우회하는 것일 수 있습니다. 기록은 있지만 직접 연결로 판정된다면 라우팅 규칙을 확인하고, 요청이 회선을 거쳤는데 응답이 이상하다면 지역, 캐시와 계정 상태를 확인하세요.
테스트 전에 앱을 데스크톱으로 보내기만 하지 말고 프로세스를 완전히 종료해야 합니다. 많은 앱이 이전 연결을 유지해 회선을 바꾼 뒤에도 기존 경로를 사용할 수 있습니다. 앱을 종료한 뒤 다시 열고 같은 동작을 실행하세요. 웹 버전이 있다면 브라우저에서 같은 서비스를 열어 비교할 수 있습니다. 웹 버전은 정상인데 클라이언트만 실패한다면 앱 자체를 집중적으로 확인하고, 둘 다 실패한다면 회선·DNS와 대상 서비스를 다시 확인합니다.
임시 전체 적용 테스트로 라우팅 오류를 찾습니다
규칙 모드에서는 앱이 여러 보조 도메인에 접속하면서 일부 요청만 올바르게 매칭될 수 있습니다. 테스트 트래픽이 모두 회선을 통과하도록 잠시 설정하고 앱을 다시 시작하세요. 복구된다면 회선과 앱 서비스는 통신 가능하고 규칙 적용 범위에 문제가 있는 것입니다. 이후 클라이언트 로그의 도메인과 규칙 적중 결과를 확인해 필요한 도메인을 올바른 그룹에 넣고 평소 모드로 돌아갑니다. 임시 테스트는 위치를 찾기 위한 것이며 장기적으로 명확한 라우팅 설정을 대신해서는 안 됩니다.
앱 이름만 보고 모든 도메인을 추측하지 마세요. 로그인, 콘텐츠, 이미지, 업데이트와 푸시는 서로 다른 도메인을 사용할 수 있고 앱 업데이트 후 바뀔 수도 있습니다. 실패 동작이 발생할 때 새로 생긴 요청을 기록하는 편이 인터넷에서 출처가 불분명한 규칙 전체를 복사하는 것보다 안전합니다. 규칙을 추가한 뒤 로그인, 콘텐츠 로드와 업로드 기능을 하나씩 확인하여 홈 화면만 열리는 상태를 정상으로 판단하지 마세요.
앱 내부 프록시 설정이 시스템 경로를 덮어쓸 수 있습니다
일부 데스크톱 앱은 ‘시스템 설정 따르기’, ‘프록시 사용 안 함’ 또는 수동 프록시 옵션을 제공합니다. 이전에 로컬 주소를 입력한 적이 있다면 시스템 프록시를 ZVVPN이 관리하더라도 앱이 오래된 주소에 계속 연결하려 할 수 있습니다. 점검할 때는 시스템 설정 따르기 또는 자동 모드를 우선 선택하고 더 이상 사용하지 않는 수동 설정을 삭제하세요. 변경 후에는 앱을 완전히 재시작하여 네트워크 설정을 다시 읽게 합니다.
명령줄 도구와 개발 환경도 환경 변수를 읽는 경우가 많습니다. 오래된 변수 때문에 요청이 다른 로컬 포트로 계속 전달될 수 있습니다. 현재 터미널에서 프록시 관련 환경을 확인할 수 있지만 자격 증명이 포함된 전체 환경을 문의에 붙여 넣지는 마세요. 확인이 필요하면 사용자 지정 시작 스크립트가 없는 새 터미널을 열어 일반 요청을 실행하세요. 개발 도구의 프로젝트별 설정도 시스템과 터미널 설정을 덮어쓸 수 있으므로 별도로 확인해야 합니다.
모바일 백그라운드 연결 끊김은 시스템 스케줄링부터 확인합니다
모바일 기기는 화면이 꺼진 뒤 백그라운드 활동을 제한하며, 절전 모드나 배터리 부족 상태 또는 앱을 오래 열지 않은 경우에는 더 심할 수 있습니다. ZVVPN 클라이언트의 백그라운드 실행을 허용하고 시스템이 자동으로 일시 중지하지 않도록 하세요. 기기마다 설정 이름은 다를 수 있지만 판단 방법은 같습니다. 클라이언트를 전면에 둔 상태에서 테스트한 뒤 화면을 잠그고 다시 테스트하세요. 전면에서는 안정적이고 백그라운드에서 끊긴다면 시스템 스케줄링에 문제가 집중된 것입니다. 전면과 백그라운드 모두 끊긴다면 회선과 네트워크 전환을 확인하세요.
시스템 네트워크 구성을 사용하는 앱을 여러 개 동시에 활성화하지 마세요. 모바일 운영체제는 보통 이런 연결 하나만 활성 상태로 둘 수 있으며 다른 클라이언트를 시작하면 현재 연결을 대체할 수 있습니다. 상태 표시줄 아이콘이 사라지거나 다른 서비스가 연결을 인계했다는 알림이 나오면 충돌하는 앱을 종료한 뒤 다시 연결하세요. 기기를 재시작해도 문제가 계속되면 이전 클라이언트에 속한 것이 확실한 네트워크 구성만 삭제하되 현재 사용하는 항목은 이름을 확인해 남겨 두세요.
푸시, 음성과 실시간 연결에는 지속적인 경로가 필요합니다
메신저, 음성 통화, 원격 데스크톱과 온라인 협업은 장시간 연결에 의존합니다. 네트워크 전환, 백그라운드 정지 또는 회선 변화가 세션을 다시 만들게 할 수 있습니다. 문자 메시지는 정상인데 통화만 자주 끊긴다면 고정 네트워크에서 테스트하고 자동 회선 전환을 유발하는 정책은 잠시 끄세요. 푸시 알림만 늦다면 회선 오류로 단정하지 말고 앱 알림과 백그라운드 권한을 먼저 확인합니다.
AI 도구도 웹 요청과 지속 출력 연결을 동시에 사용할 수 있습니다. 페이지는 열리지만 답변이 중간에 멈춘다면 로컬 네트워크가 전환됐는지, 브라우저가 절전 상태가 됐는지, 회선이 안정적인지 먼저 확인한 뒤 같은 지역의 다른 회선과 비교하세요. 같은 테스트에서 페이지 새로 고침, 회선 전환과 재로그인을 동시에 하지 마세요. 그래야 세션 만료와 네트워크 중단을 구분할 수 있습니다.
| 앱에서 나타나는 현상 | 권장 관찰 항목 | 다음 단계 |
|---|---|---|
| 클라이언트에 요청 기록이 전혀 없음 | 앱이 시스템 네트워크를 따르는지 여부 | 앱 프록시와 네트워크 모드를 확인합니다 |
| 요청이 직접 연결로 판정됨 | 적중한 규칙과 그룹 | 임시로 모두 회선을 통과시킨 뒤 규칙을 수정합니다 |
| 화면을 잠근 뒤에만 중단됨 | 백그라운드 권한과 절전 상태 | 백그라운드 실행을 허용한 뒤 재현합니다 |
| 네트워크 전환 후 중단됨 | 이전 세션이 계속 유지되는지 여부 | 로컬 네트워크가 복구된 뒤 다시 연결합니다 |
DNS 오류·기기 충돌과 문의 제출
DNS 오류의 대표적인 증상을 파악합니다
DNS 오류는 도메인 해석 실패, 첫 접속의 긴 대기, 같은 웹사이트가 때로는 정상이고 때로는 서버를 찾을 수 없다고 표시되는 현상 또는 회선에 연결한 뒤에도 로컬 네트워크의 해석 결과가 반환되는 현상으로 나타날 수 있습니다. 회선에 전혀 접근할 수 없는 경우와 다른 점은 클라이언트 연결이 유지될 수 있고 캐시된 주소를 사용하는 일부 앱은 작동하지만 새로 여는 도메인은 실패한다는 것입니다. 도메인 조회와 웹 요청을 분리해 테스트하면 문제가 어느 단계에서 멈추는지 확인할 수 있습니다.
먼저 클라이언트 연결을 끊고 일반 네트워크에서 도메인 해석이 정상인지 확인한 뒤 다시 연결해 같은 조회를 반복하세요. 연결을 끊었을 때는 정상이고 연결한 뒤 실패한다면 클라이언트 DNS 모드, 시스템 네트워크 구성과 사용자 지정 규칙을 확인합니다. 두 상태에서 모두 실패한다면 먼저 로컬 네트워크를 복구해야 합니다. 시스템, 브라우저, 클라이언트와 라우터에 서로 다른 DNS를 동시에 여러 세트 지정하지 마세요. 요청 경로를 판단하기 어려워집니다.
이전 해석 상태를 지우고 네트워크를 다시 만듭니다
네트워크나 회선을 바꾼 뒤에도 시스템과 브라우저가 이전 캐시를 계속 사용할 수 있습니다. 먼저 대상 앱을 종료하고 클라이언트 연결을 끊은 뒤 일반 네트워크가 복구될 때까지 기다렸다가 다시 연결하세요. 시스템에 DNS 캐시 삭제 기능이 있다면 운영체제에서 제공하는 방식을 사용합니다. 명령어가 익숙하지 않다면 네트워크 연결과 앱을 재시작해 깨끗한 비교 환경을 만들 수도 있습니다. 출처를 알 수 없는 스크립트에서 시스템 변경 권한이 필요한 명령을 복사하지 마세요.
브라우저에서 별도의 보안 DNS를 활성화하면 시스템이나 클라이언트 설정을 따르지 않을 수 있습니다. 점검 중에는 브라우저가 시스템 설정을 따르도록 잠시 바꿔 문제가 사라지는지 확인하세요. 복구된다면 클라이언트가 지원하는 방식에 따라 장기 설정을 결정합니다. 기업 기기의 DNS는 조직 정책으로 관리될 수 있으므로 임의로 변경하지 말고 조회 실패 현상을 네트워크 관리자에게 확인받으세요.
기기 수에는 제한이 없지만 구성은 서로 충돌할 수 있습니다
ZVVPN은 기기 수 제한 없이 사용할 수 있으므로 Windows, macOS, iOS, Android와 Linux에서 현재 계정을 이용할 수 있습니다. 하지만 각 기기에는 독립적인 클라이언트, 시스템 권한, 캐시와 네트워크 환경이 있습니다. 한 기기는 정상이고 다른 기기는 실패할 때 계정의 기기 제한을 먼저 의심하지 말고 두 기기의 구독 업데이트 시간, 클라이언트 모드, 로컬 네트워크와 시스템 프록시를 비교하세요.
한 기기에서 여러 클라이언트를 실행하는 것과 여러 기기에서 서비스를 사용하는 것은 다릅니다. 전자는 시스템 프록시와 가상 네트워크 인터페이스를 두고 경쟁할 수 있지만 후자는 로컬 구성을 공유하지 않습니다. 기기 간 차이가 발생하면 문제가 있는 기기를 정상 기기가 사용하는 같은 네트워크에 연결하고 같은 지역 회선으로 테스트하세요. 결과가 여전히 다르면 기기 쪽 문제일 가능성이 크고, 네트워크에 따라 결과가 달라지면 접속 환경을 확인해야 합니다.
로컬에서 더 이상 시행착오를 반복하지 않아도 되는 시점
기본 네트워크, 다른 회선, 시스템 권한, 구독 업데이트와 DNS를 확인한 뒤에도 문제가 안정적으로 재현된다면 문의를 제출해야 합니다. 특히 여러 기기, 서로 다른 네트워크와 여러 지역 회선에서 같은 오류가 발생한다면 계속 재설치하고 캐시를 지워도 유효한 정보가 늘어나지 않는 경우가 많습니다. 문의의 목적은 ‘많은 방법을 시도했다’는 것을 증명하는 것이 아니라 고객 지원 담당자가 재현하고 판단할 수 있는 경로를 제공하는 데 있습니다.
결제와 환불 문제도 문의를 통해 직접 처리해야 합니다. 서비스 안내에는 7일 이내 무조건 환불이 가능하다고 명시되어 있으며, 구체적인 신청은 환불 정책을 기준으로 합니다. 결제 수단은 Alipay, WeChat Pay와 USDT입니다. 주문과 관련된 문의에는 주문 페이지에 표시된 상태와 결제 수단을 첨부하고 결제 자격 증명, 전체 거래 키 또는 문제와 관계없는 계정 자료는 제출하지 마세요.
유효한 문의에는 무엇이 포함되어야 하나요
제목에는 ‘구독은 업데이트되지만 모든 회선 연결 실패’ 또는 ‘화면을 잠그면 시스템이 연결을 종료함’처럼 증상을 직접 적으세요. 본문에는 플랫폼, 사용한 네트워크 유형, 클라이언트에 표시된 오류 원문, 문제가 발생한 회선 이름, 대상 웹사이트나 앱, 처음 발생했을 때의 동작과 완료한 비교 테스트를 순서대로 설명합니다. 네트워크나 회선을 바꾼 뒤 결과가 달라졌다면 그 차이도 적어야 합니다.
로그는 장애 전후의 관련 부분만 잘라내세요. 스크린샷에는 클라이언트 상태와 오류 정보가 포함되어야 하지만 사용자 이름, 전체 구독 주소, 토큰, 주문의 민감한 내용과 기타 개인정보는 반드시 가려야 합니다. 맥락이 보이지 않는 빨간색 알림 하나만 잘라 보내거나 장애와 무관한 전체 채팅 기록을 업로드하지 마세요. 텍스트로 된 오류 원문이 이미지보다 검색하기 쉬우므로 스크린샷과 별도로 복사해 두는 것이 좋습니다.
제출 전 확인 목록
- 명확한 동작으로 증상을 다시 재현할 수 있음
- 모든 회선인지 특정 회선 하나인지 설명함
- 로컬 네트워크를 바꾼 뒤의 결과를 설명함
- 플랫폼, 오류 원문과 회선 이름을 첨부함
- 로그와 스크린샷에서 구독 주소와 토큰을 삭제함
- 결제 문제에 주문 상태와 결제 수단을 첨부함
복구 후 최소한의 기록을 남깁니다
문제가 복구된 뒤 최종적으로 효과가 있었던 동작과 복구 전의 핵심 현상을 기록해 두는 것이 좋습니다. 예를 들어 ‘중복 클라이언트를 종료한 뒤 복구됨’, ‘구독을 다시 가져온 뒤 회선 목록이 업데이트됨’ 또는 ‘백그라운드 실행을 허용한 뒤 화면을 잠가도 끊기지 않음’처럼 적을 수 있습니다. 민감한 로그 전체를 보관할 필요는 없지만 문제 유형과 해결 방향은 남겨 두세요. 나중에 비슷한 현상이 발생했을 때 모든 설정을 처음부터 바꾸지 않고 같은 분기를 먼저 확인할 수 있습니다.
복구 원인이 분명하지 않다면 관계없는 변경을 단계적으로 되돌려 실제로 유지해야 하는 설정을 확인하세요. 임시 규칙, 수동 DNS와 중복 구독을 장기간 쌓아 두면 다음 문제를 판단하기 더 어려워집니다. 안정적인 구성은 선택 항목이 가장 많은 구성이 아니라 네트워크 경로가 명확하고 구독 출처가 분명하며 시스템에서 연결을 담당하는 클라이언트가 하나뿐이고 각 사용자 지정 설정의 목적을 설명할 수 있는 구성입니다.