연결 문제 해결 가이드

1. 점검 전 준비와 판단 흐름

대부분의 '연결 안 됨'은 회선 고장이 아니라 로컬의 특정 단계가 트래픽을 막고 있어서 생깁니다. 헛수고를 하지 않으려면 전체 경로를 세 계층으로 나눠 보세요: 기기와 로컬 네트워크 계층(사용자의 PC, 공유기, 인터넷 회선, 접속한 Wi-Fi), 클라이언트와 설정 계층(클라이언트 로그인 여부, 구독 가져오기 여부, 프록시 모드와 프로토콜 설정), 회선과 서비스 계층(출구 회선 자체에 도달할 수 있는지). 세 계층 중 서버 쪽 문제는 세 번째뿐이고, 앞의 두 계층은 모두 사용자 손에 있으며 문제가 가장 많이 몰리는 곳이기도 합니다.

권장 판단 순서는 아래에서 위로입니다. 먼저 로컬 네트워크 자체가 살아 있는지 확인하고, 다음으로 클라이언트 상태와 설정을 보고, 마지막에 회선을 의심하세요. 반대로 하면—페이지가 안 열린다고 회선만 계속 바꾸면—문제 없는 출구들 사이를 왔다 갔다 하며 시간만 쓰고 진짜 단서를 덮어버리기 쉽습니다.

먼저 준비할 세 가지 정보

시작하기 전에 아래 세 가지를 옆에 적어 두세요: 오류 메시지 원문(스크린샷을 찍거나 그대로 옮겨 적고, '오류가 났다'고만 쓰지 마세요), 문제가 발생한 정확한 시각(분 단위까지, 시간대도 함께), 현재 사용 중인 플랫폼과 네트워크 유형(Windows / macOS / iOS / Android / Linux 중 무엇인지, 가정용 인터넷·회사 네트워크·공용 Wi-Fi·모바일 데이터 중 무엇에 연결되어 있는지). 이 세 가지가 이후 한 번에 원인을 찾을 수 있는지를 좌우하며, 문의를 넣을 때도 필수 항목입니다.

증상별로 먼저 분류

같은 '연결 안 됨'이라도 원인이 있는 계층은 전혀 다릅니다. 아래 표는 가장 흔한 증상을 해당 점검 장에 바로 연결해 줍니다. 먼저 분류하고 나서 움직이면 시행착오를 절반 이상 줄일 수 있습니다.

자주 놓치는 전제가 하나 더 있습니다: 클라이언트가 로그인 상태여야 한다는 점입니다. VPNCZ 가입에는 사용자 이름과 비밀번호만 필요하며 이메일 주소는 필요하지 않습니다. 로그인 정보는 로컬에 저장됩니다. 클라이언트가 로그인되지 않았거나 자격 증명이 만료되었다고 알리면 구독이 정상적으로 새로 고쳐지지 않고, 나타나는 증상은 '회선 고장'과 거의 같습니다. 이상이 느껴지면 클라이언트 오른쪽 위의 계정 상태를 먼저 확인하세요. 2초면 됩니다.

2. 아예 연결이 안 될 때: 내 기기에서 출구까지 다섯 단계 판단

'아예 연결이 안 됨'은 클라이언트에서 연결을 눌러도 통로가 만들어지지 않고 트래픽도 전혀 나가지 않는 상태를 말합니다. 이런 문제는 판단 순서가 명확해서, 순서대로 따라가면 보통 다섯 단계 안에 결론이 납니다.

1단계: 로컬 네트워크 자체가 살아 있는지 확인

먼저 가속기를 끄고 한국 국내 사이트를 하나 열어 보세요. 정상적으로 열리면 인터넷 회선, Wi-Fi, 공유기, DNS 계층에는 문제가 없다는 뜻이므로 2단계로 넘어갑니다. 국내 사이트조차 열리지 않으면 문제는 로컬 네트워크에 있고 가속 서비스와는 무관합니다. 공유기를 재부팅하고 Wi-Fi에 다시 연결하거나, 다른 네트워크 환경(예: 회사 네트워크에서 모바일 데이터 핫스팟으로 전환)에서 다시 시도해 보세요. '연결 안 됨' 문의 중 상당수는 결국 회사 내부망이나 학교 네트워크의 출구 정책 문제로 귀결됩니다.

2단계: 클라이언트가 어느 상태에서 멈추는지 확인

세 가지 양상을 구분하세요: 연결을 눌러도 아무 반응이 없음(버튼이 연결 중 상태로 넘어가지 않음)—보통 클라이언트 프로세스 이상이나 미로그인 상태이므로 클라이언트를 종료했다가 다시 열고 계정 상태를 확인하면 됩니다. 계속 로딩만 되다가 시간 초과—클라이언트가 핸드셰이크를 시도하고 있지만 출구에 도달하지 못하는 경우로 회선 문제이므로 3단계로 넘어갑니다. 즉시 오류가 뜸—오류 메시지 원문을 기록해 두세요. 이런 메시지는 시스템 시간이 맞지 않음, 설정 파싱 실패, 가상 네트워크 어댑터 생성 불가처럼 원인을 직접 알려주는 경우가 많습니다.

3단계: 다른 지역의 회선으로 교체

현재 지역에서 같은 회선만 반복해서 눌러 보지 마세요. 지리적 위치와 회선 유형이 모두 다른 출구로 바꿔 보세요. 예를 들어 일본에서 싱가포르로, 또는 중계 회선에서 직접 연결 회선으로 바꾸는 식입니다. 서로 다른 지역의 회선을 세 개 이상 바꿔도 모두 실패한다면 문제는 개별 회선이 아니므로 2단계와 4단계로 돌아가 내 기기를 점검하세요.

4단계: 시스템 시간과 보안 프로그램 확인

암호화 핸드셰이크는 정확한 시스템 시간에 의존하므로 시간 오차가 크면 연결이 그대로 거부됩니다. 시스템 시간을 자동 동기화로 설정한 뒤 클라이언트를 재시작하세요. 동시에 로컬 보안 프로그램, 방화벽, 회사 관리 도구가 가상 네트워크 어댑터를 차단하고 있지 않은지 확인하세요. 이런 프로그램은 시스템 업데이트 후 규칙을 초기화하는 일이 잦습니다. 네트워크 보호를 잠시 끄고 다시 연결해 보고, 연결된다면 차단 문제이므로 클라이언트를 허용 목록에 추가하면 됩니다. 보호 기능을 계속 꺼 둘 필요는 없습니다.

5단계: 기존 설정을 지우고 다시 가져오기

여기까지 문제가 없다면 로컬에 이전 버전 설정이 남아 있을 수 있습니다. 클라이언트에서 현재 구독을 삭제하고 프로그램을 종료한 뒤, 다시 로그인해서 구독을 한 번 더 가져오세요. 오래된 설정이 남아 있을 때의 전형적인 증상은 회선 목록에 이미 종료된 지역 이름이 나타나거나, 연결할 때 특정 설정 항목을 찾을 수 없다는 안내가 뜨는 것입니다.

흔한 오해 하나를 짚고 넘어가겠습니다. 연결 실패가 곧 계정 문제는 아닙니다. 클라이언트는 로그인하지 않은 상태에서도 회선 목록을 표시하는데, 그 목록은 마지막으로 동기화에 성공한 캐시에서 오기 때문입니다. 계정이 유효한지는 클라이언트가 회선 이름을 보여주는지가 아니라 패널의 구독 상태로 판단하세요. 패널에서 구독이 정상이고 트래픽도 남아 있다면, 문제는 반드시 로컬 환경이나 출구 도달 가능성 쪽에 있습니다.

3. 연결은 되는데 페이지가 안 열릴 때: DNS와 분할 라우팅 점검

이 유형의 특징은 클라이언트는 연결됨으로 표시되는데 브라우저가 계속 로딩만 되거나 일부 사이트만 열리지 않는다는 점입니다. 2장의 '아예 연결이 안 됨'과는 다른 문제입니다. 통로는 이미 만들어졌고, 도메인 해석이나 트래픽 분할 단계에서 막힌 것입니다.

먼저 세 가지 양상 구분

모든 사이트가 안 열림: 통로는 만들어졌지만 트래픽이 실제로 나가지 않는 경우로, 보통 분할 라우팅 규칙이나 가상 네트워크 어댑터가 작동하지 않은 것입니다. 일부 사이트만 안 열림: 전형적인 도메인 해석 문제로, 도달할 수 없는 주소로 해석된 상태입니다. 브라우저는 안 되는데 메신저는 정상: 브라우저 자체의 암호화 DNS 설정이나 확장 프로그램이 해석을 가로채는 것으로, 통로와는 무관합니다.

출구가 실제로 바뀌었는지 확인

가장 직접적인 확인 방법은 현재 출구 주소를 조회해 보는 것입니다. 연결 전후로 각각 한 번씩 조회해서 두 결과가 완전히 같다면 트래픽이 회선을 타지 않은 것이므로, 문제는 DNS가 아니라 클라이언트의 프록시 모드나 시스템 계층에 있습니다. 이 단계만으로 '해석 문제'와 '아예 회선을 타지 않음'을 즉시 구분할 수 있어 DNS에서 헛수고하는 일을 막아 줍니다. 출구 확인의 전체 방법은 가속 서비스가 실제로 작동하는지 확인하는 방법 글에서 볼 수 있습니다.

로컬 DNS 캐시 정리

오래된 해석 결과는 시스템에 일정 시간 캐시로 남아, 회선을 바꾼 뒤에도 예전 기록을 그대로 사용합니다. '연결은 되는데 페이지가 안 열리는' 가장 흔한 원인 중 하나입니다. 캐시를 한 번 정리하고 다시 시도해 보세요:

# Windows(명령 프롬프트)
ipconfig /flushdns

# macOS(터미널)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo resolvectl flush-caches

브라우저 자체 암호화 DNS 확인

일부 브라우저는 '보안 DNS / DNS over HTTPS'를 기본으로 켜 두고, 시스템 설정을 우회해 직접 도메인을 해석합니다. 이 해석 서비스가 현재 네트워크에서 도달할 수 없으면 '메신저는 되는데 브라우저만 안 되는' 현상이 나타납니다. 브라우저의 보안 DNS를 끄거나 시스템 설정을 따르도록 바꾸면 보통 즉시 해결됩니다. 마찬가지로 브라우저에 설치된 광고 차단이나 프록시 관련 확장 프로그램도 요청을 가로챌 수 있으므로, 점검할 때는 확장 프로그램이 하나도 없는 깨끗한 브라우저 프로필로 한 번 시도해 보세요.

캐시 정리, 브라우저 암호화 DNS 끄기, 전역 모드 전환까지 세 단계를 모두 해 봤는데도 일부 도메인만 해석에 실패한다면, 열리지 않는 구체적인 도메인과 당시의 오류 메시지를 기록해 문의를 넣으세요. 도메인 단위의 해석 이상은 서버 쪽에서 함께 확인해야 하며, 혼자 더 시도해도 보통 새로운 결과는 나오지 않습니다.

4. 속도 저하와 저녁 피크 버벅임: '항상 느린지' '특정 시간대만 느린지' 먼저 구분

속도 문제에서 가장 좋지 않은 것은 '그냥 느리다'고 뭉뚱그려 말하는 것입니다. 먼저 한 가지 질문에 답하세요: 하루 종일 느린가, 아니면 저녁 특정 시간대에만 느린가? 이 두 경우는 원인이 완전히 다르고 대응 방식도 다릅니다.

항상 느릴 때: 병목은 대개 로컬

언제든, 어떤 회선에서든 느리다면 로컬 구간을 먼저 의심하세요. 현재 인터넷 요금제의 실제 다운로드 속도, 2.4GHz 대역을 쓰고 있지는 않은지(2.4GHz는 주택 밀집 지역에서 간섭이 심하며 5GHz로 바꾸면 대개 효과가 즉시 나타납니다), 공유기를 오랫동안 재부팅하지 않았는지, 같은 네트워크의 다른 기기가 다운로드나 고화질 영상을 보고 있지는 않은지 차례로 확인하세요. 랜선으로 공유기에 직접 연결해 다시 측정했을 때 속도가 뚜렷하게 회복된다면 문제는 무선 구간에 있고 출구 회선과는 무관합니다.

저녁 피크에 느릴 때: 국제 구간 혼잡

국경을 넘는 트래픽은 저녁 시간대에 몰리기 때문에 공용 출구의 혼잡은 객관적으로 존재합니다. 완화 방법은 두 가지입니다: 회선 유형 교체—일반 직접 연결을 전용선이나 중계 유형 출구로 바꾸면 이런 회선의 대역폭은 상대적으로 독립적으로 확보됩니다. 지역 교체—해당 시간대에 가장 붐비는 출구 지역을 피해 상대적으로 덜 붐비지만 물리적 거리가 가까운 노드를 고르세요. 두 가지를 함께 하면 같은 회선을 반복해서 다시 연결하는 것보다 효과가 훨씬 좋습니다.

프로토콜과 전송 방식의 영향

같은 기기, 같은 회선이라도 전송 프로토콜을 바꾸면 속도가 달라집니다. UDP 기반 전송은 패킷 손실 환경에서 복구가 빨라 실시간성이 중요한 상황에 적합하고, TCP 기반 전송은 제한된 네트워크에서 연결이 더 쉽게 맺어지지만 패킷 손실을 만나면 속도 하락이 더 뚜렷합니다. 클라이언트에서 보통 전환이 가능하니 같은 시간대에 각각 한 번씩 측정해 더 나은 쪽을 남겨 두세요.

백그라운드 트래픽 간섭

시스템 업데이트, 클라우드 동기화, 드라이브 클라이언트, 게임 플랫폼의 백그라운드 다운로드는 대역폭을 계속 차지하면서도 보통 아무 알림도 띄우지 않습니다. 점검 전에 시스템의 네트워크 사용량 패널을 열어 보고, 불필요한 대용량 프로세스를 잠시 멈춘 뒤 다시 측정하세요. 이 단계만으로 '어젯밤에 갑자기 느려졌다가 오늘은 괜찮아졌다' 같은, 겉보기엔 무작위인 문제가 설명되는 경우가 많습니다.

회선 유형을 바꿔 보고, 지역도 바꿔 보고, 로컬에 대용량 트래픽이 없다는 것까지 확인했는데도 속도가 계속 기대에 못 미친다면, 문의에 거주 지역, 주로 사용하는 시간대, 사용 중인 회선 유형, 그리고 세 번 측정한 결과 스크린샷을 첨부하세요. 이 정보가 있으면 회선 용량 문제인지 로컬 구간 문제인지 가려낼 수 있습니다. 회선 유형 선택에 대한 자세한 설명은 회선 목록 페이지에 있습니다.

5. 잦은 끊김: 간격 패턴으로 원인 역추적

끊김 자체는 단서가 아닙니다. 끊기는 간격의 패턴이 단서입니다. 먼저 20분 정도 관찰하면서 '일정한 간격으로 끊김', '불규칙하게 끊김', '네트워크를 바꿀 때 끊김' 중 어느 쪽인지 적어 두고, 아래 해당 갈래를 따라가세요.

일정한 간격으로 끊김

매번 비슷한 시점에 끊긴다면(예: 5분마다, 30분마다) 예약된 메커니즘을 가리킵니다. 시스템 절전 정책이 백그라운드에서 클라이언트를 동결시키거나, 공유기의 주소 임대 기간이 만료되거나, 특정 예약 작업이 네트워크 인터페이스를 재설정하는 경우입니다. 대응은 클라이언트의 백그라운드 제한을 풀어 주는 것입니다. 시스템의 배터리 또는 절전 설정에서 클라이언트를 제한 없음 목록에 추가하고, 이 앱을 대상으로 한 '스마트 절전'류 옵션을 끄세요. 공유기 쪽 임대 기간 문제는 공유기 재부팅으로 검증할 수 있습니다. 재부팅 후 끊기는 간격이 뚜렷하게 달라졌다면 공유기에서 임대 기간을 늘리세요.

불규칙한 끊김

규칙성 없는 끊김은 대개 무선 신호와 관련이 있습니다. 기기가 여러 액세스 포인트 사이를 로밍하거나, 신호 강도가 임계값 근처에서 계속 흔들리거나, 2.4GHz 대역이 이웃 공유기의 간섭을 받는 경우입니다. 기기를 5GHz 대역에 고정하고 공유기에 가까이 두거나, 아예 랜선으로 바꿔 보세요. 끊김이 사라지면 무선 구간 문제로 확인됩니다. 사무실이나 공공장소에서는 액세스 포인트 간 전환이 일상적이므로, 이런 환경이라면 모바일 데이터로 비교 테스트를 해 보는 것을 권합니다.

네트워크를 바꿀 때 끊김

스마트폰을 들고 Wi-Fi에서 밖으로 나가 모바일 데이터로 전환하거나, 노트북을 유선에서 무선으로 바꾸면 이런 네트워크 인터페이스 변화로 이미 만들어진 통로가 무효화됩니다. 대부분의 클라이언트는 인터페이스가 바뀐 뒤 자동으로 다시 연결합니다. 자동 복구가 되지 않는다면 클라이언트에 자동 재연결 옵션이 켜져 있는지 확인하고, 그래도 복구되지 않으면 수동으로 끊고 다시 연결하면 됩니다. 이는 고장이 아니라 네트워크 환경 전환의 정상적인 결과입니다.

클라이언트 로그 읽는 법

클라이언트는 보통 로그를 볼 수 있는 메뉴를 제공합니다. 로그를 읽을 때 모든 줄을 볼 필요는 없고 두 종류만 찾으면 됩니다: 타임스탬프(끊김이 발생한 정확한 시각이 관찰과 일치하는지 확인)와 연결 끊김, 시간 초과, 재설정 같은 단어가 들어간 줄(이 줄들이 보통 원인을 직접 알려줍니다). 이 두 종류의 줄을 타임스탬프와 함께 스크린샷으로 남기면 문의할 때 가장 가치 있는 정보가 됩니다. '자꾸 끊긴다'고 설명하는 것보다 훨씬 유용합니다.

장시간 연결에 대해 한 가지 덧붙이겠습니다. 메신저, 원격 데스크톱, 온라인 게임 같은 장시간 연결은 끊김에 매우 민감해서, 단 2초만 끊겨도 '메시지가 한참 뒤에 도착'하거나 '게임이 그대로 종료'되는 식으로 나타날 수 있습니다. 이런 앱을 주로 쓴다면 IEPL 전용선 유형의 출구를 우선 선택하고, 가능하면 같은 회선을 고정해서 사용해 전환에 따른 재연결 비용을 줄이세요.

6. 구독 업데이트 실패: 링크, 상태, DNS 세 곳 확인

구독은 계정 권한을 클라이언트로 동기화하는 통로입니다. 이 업데이트가 실패하면 클라이언트의 회선 목록이 예전 상태에 머물러, '새 회선이 있는데 보이지 않는다'거나 '연결 후 설정이 유효하지 않다고 나온다'는 식으로 나타납니다.

먼저 확인할 세 가지

업데이트 실패 원인 중 절반 이상은 기술 문제가 아니라 상태 문제입니다: 계정이 로그인 상태인지(로그인이 만료되면 구독을 가져올 수 없습니다), 요금제가 유효 기간 내인지(월 구독이 만료되면 구독 업데이트가 멈춥니다), 트래픽을 모두 사용하지 않았는지(트래픽은 개통일 기준으로 매월 초기화되며, 소진되면 초기화를 기다리거나 요금제를 업그레이드해야 합니다). 이 세 가지는 패널에서 한눈에 확인할 수 있으니 먼저 확인하고 나서 점검에 들어가세요. 도중에 요금제를 업그레이드하면 차액이 남은 일수로 환산되며, 업그레이드 후 구독 내용은 새 요금제에 따라 바뀝니다.

그다음 링크와 DNS 확인

상태가 정상임을 확인했다면 구독 링크가 온전히 복사되었는지 확인하세요. 링크가 보통 길어서 채팅 창이나 스크린샷에서 복사할 때 끝부분 문자가 빠지기 쉽습니다. 수동으로 한 번 업데이트해 보세요. 클라이언트의 구독 관리에서 업데이트를 선택하고 안내 메시지를 확인합니다. 네트워크 오류가 뜬다면 클라이언트가 구독을 가져올 때 연결을 맺지 못한 것이므로, 현재 회선에 연결되어 있는지 먼저 확인하거나 프록시를 잠시 끄고 다시 업데이트해 보세요.

# 구독 주소 형식(예시는 자리 표시자이며, 패널에서 실제로 생성된 주소를 기준으로 하세요)
https://example.com/sub?token=YOUR_TOKEN

# 업데이트 실패 시 연결 확인을 먼저 한 번 해볼 수 있습니다(주소를 패널의 실제 주소로 바꾸세요)
curl -I "https://example.com/sub?token=YOUR_TOKEN"

시스템 시간 오차도 업데이트 실패를 일으킵니다. 구독을 가져올 때 검증이 필요하고, 시간이 맞지 않으면 거부됩니다. 시스템 시간을 자동 동기화로 설정하고 클라이언트를 재시작한 뒤 다시 업데이트하세요.

그래도 실패하면

클라이언트에서 예전 구독을 삭제하고 프로그램을 종료한 뒤, 다시 로그인해서 새로 가져오세요. 예전 구독 삭제가 중요합니다. 같은 클라이언트에 같은 계정을 가리키는 구독이 여러 개 남아 있으면 서로 덮어쓰거나 회선 목록이 중복되는 문제가 생기기 쉽습니다. 다시 가져온 뒤 회선 목록이 복구되고 정상적으로 연결된다면 문제는 해결된 것입니다.

다시 가져와도 실패한다면 문의에 오류 메시지 원문, 발생 시각, 현재 사용 중인 플랫폼, 패널에 표시된 요금제 상태를 첨부하세요. 구독 링크 전체를 문의에 붙이지 마세요. '구독 업데이트 실패'라고만 알려주면 됩니다. 고객 지원은 계정으로 상태를 직접 확인할 수 있습니다.

7. 특정 앱만 프록시를 타지 않을 때: 모드, 프로토콜, 권한

'다른 앱은 다 정상인데 그것만 안 된다'는 앱별 프록시에서 가장 전형적인 문제입니다. 원인은 보통 회선이 아니라 트래픽을 가로채는 방식에 있습니다.

먼저 클라이언트의 프록시 모드 확인

클라이언트는 보통 세 가지 모드를 제공합니다: 전역(모든 트래픽이 회선을 탐), 규칙(규칙 목록에 따라 결정), 직접 연결(아무것도 타지 않음). 특정 앱이 적용되지 않는다면 먼저 전역 모드로 바꿔 한 번 시도해 보세요. 전역에서는 정상이고 규칙에서는 이상하다면 규칙 목록이 그 앱을 포함하지 않은 것이므로 설정 문제입니다. 전역에서도 여전히 이상하다면 그 앱의 트래픽이 애초에 클라이언트에 의해 처리되지 않는 것입니다.

가상 네트워크 어댑터 처리와 시스템 프록시의 차이

가상 네트워크 어댑터 기반 방식은 네트워크 계층에서 동작하므로 시스템 프록시 설정을 읽지 않는 프로그램까지 대부분 커버합니다. 시스템 프록시 방식은 프록시 설정을 직접 읽는 앱에만 영향을 주므로 브라우저는 보통 문제가 없지만, 일부 데스크톱 클라이언트, 게임, 명령줄 도구는 이를 그냥 무시합니다. 대상 앱이 후자에 속한다면 클라이언트에서 가상 네트워크 어댑터 처리 모드를 켜야 합니다.

앱 자체의 제약

일부 앱은 자체적인 네트워크 동작을 고정합니다. 어떤 앱은 별도의 프록시 설정 항목을 내장하고 있어(따로 입력하거나 꺼야 합니다) 중간 처리를 거부하거나, 인증서 검증을 해서 중간 개입을 받아들이지 않습니다. 또 어떤 앱은 UDP로 통신하는데 현재 회선이나 모드가 TCP만 처리하기도 합니다. 이런 경우 '로그인은 되지만 콘텐츠가 로드되지 않음' 또는 '연결이 계속 수립 중'으로 나타나는 일이 많습니다. 클라이언트에서 전송 프로토콜을 바꿔 다시 시도하거나, 전역 모드로 잠시 확인해 분할 라우팅과 관련이 있는지 판단해 보세요. 게임 앱의 지연과 패킷 손실 문제는 게임 가속기 추천 글에 더 자세히 정리되어 있습니다.

클라이언트가 이미 가상 네트워크 어댑터 모드이고 전역 모드에서도 해당 앱이 적용되지 않는다면, 문의에 앱 이름, 플랫폼, 그리고 특정 작업(예: 음성 통화, 파일 업로드)에서만 실패하는지 여부를 적어 주세요. 이런 정보가 있으면 처리 방식 문제인지 앱 자체의 네트워크 정책 문제인지 빠르게 구분할 수 있습니다.

8. 모바일 백그라운드 종료와 기기 수 초과

스마트폰과 태블릿에서 생기는 끊김은 대부분 회선 문제가 아니라 시스템의 백그라운드 관리 정책 때문입니다. 모바일 시스템은 전력 절약을 위해 앱이 백그라운드로 들어가면 네트워크 활동을 제한하고, 그 결과 '잠깐 나갔다 돌아오면 연결이 이미 끊겨 있는' 현상이 나타납니다.

모바일의 백그라운드 정책

해결 방향은 클라이언트를 절전 제한에서 풀어 주는 것입니다. 시스템의 배터리 설정에서 클라이언트를 찾아 제한 없음으로 설정하고, 이 앱을 대상으로 한 '스마트 절전', '백그라운드 제한'류 옵션을 끄세요. 시스템의 연결 설정에서 이 앱이 네트워크 구성으로 활성화되어 있는지도 확인하세요. iOS와 Android는 설정 메뉴 이름이 다르지만 방향은 같습니다. 시스템이 이 앱은 백그라운드에서 네트워크 활동을 유지해야 한다는 점을 알게 하는 것입니다.

'기기 수 초과'에 대하여

VPNCZ는 기기 수를 제한하지 않습니다. 같은 계정으로 Windows / macOS / iOS / Android / Linux에서 동시에 사용할 수 있으며, 기기 수에 따라 요금을 받거나 제한하는 규칙은 없습니다. 따라서 '기기 수가 한도에 도달했습니다' 같은 안내가 보인다면 그것은 거의 계정 차원의 제한이 아니며, 흔한 원인은 세 가지입니다: 같은 기기에 설정이 여러 개 남아 있음(예전 구독을 삭제하지 않아 클라이언트가 여러 연결 인스턴스로 인식), 시스템 네트워크 설정에 예전 구성 프로필이 남아 있음(특히 iOS는 구성 프로필을 여러 번 설치하면 여러 개가 남을 수 있음), 패널에 로그아웃되지 않은 로그인 세션이 여러 개 있음—일부 클라이언트는 이를 합쳐서 표시합니다.

처리 순서

먼저 클라이언트에서 불필요한 구독을 삭제하고 하나만 남기세요. 다음으로 시스템 설정에 같은 이름의 네트워크 구성이 여러 개 있는지 확인해 가장 최신 하나만 남기고 나머지는 삭제하세요. 그런 다음 기기를 재부팅하세요. 그래도 안내가 계속 나오면 패널에 로그인해 현재 로그인 세션을 확인하고, 더 이상 쓰지 않는 기기를 로그아웃한 뒤 다시 로그인하세요. 이 세 단계를 마치면 보통 안내가 다시 나타나지 않습니다.

한 가지 더 알려 둘 점이 있습니다. 모바일은 신호가 약한 환경에서 기지국 사이를 자주 전환하므로 통로가 다시 만들어지는 횟수가 Wi-Fi 환경보다 훨씬 많습니다. 출퇴근길에 사용한다면 가끔 한 번씩 재연결되는 것은 정상이며, 클라이언트를 반복해서 재시작할 필요가 없습니다. 정말 주의해야 할 것은 '백그라운드로 보냈다가 돌아올 때마다 반드시 수동으로 다시 연결해야 하는' 안정적으로 재현되는 상황이며, 그때가 백그라운드 정책이 허용하지 않은 경우입니다.

9. 언제 고객 지원에 문의해야 하고, 문의에 무엇을 첨부해야 할까

앞의 여덟 장에서 스스로 해결할 수 있는 대부분의 문제를 다뤘습니다. 나머지 일부는 서버 쪽에서 함께 확인해야 하므로, 이때는 반복해서 시도하는 것보다 문의를 넣는 편이 효율적입니다. 핵심은 어떤 것을 넣어야 하고 어떤 것은 넣지 않아도 되는지, 그리고 넣을 때 무엇을 첨부할지 구분하는 것입니다.

문의하지 않아도 되는 경우

개별 회선 하나가 연결되지 않음(다른 회선으로 바꾸면 됩니다), 특정 사이트가 열리지 않음(3장에 따라 캐시를 정리하고 브라우저 암호화 DNS를 끄세요), 저녁 피크에 속도 저하(4장에 따라 회선 유형 교체), 스마트폰이 백그라운드로 간 뒤 끊김(8장에 따라 절전 설정 조정). 이런 것들은 설정이나 환경 차원의 문제이며, 고객 지원이 줄 수 있는 답도 직접 가이드를 따라 하는 것과 같습니다.

문의를 넣어야 하는 경우

서로 다른 지역과 회선 유형의 출구를 세 개 이상 바꿔도 여전히 전혀 연결되지 않을 때, 여러 기기와 여러 네트워크 환경에서 같은 실패가 나타날 때, 구독 업데이트가 반복해서 실패하는데 패널에는 상태가 정상으로 표시될 때, 로그에 서버 쪽을 가리키는 시간 초과 기록이 반복될 때, 기기 수 제한 안내가 뜨지만 실제로는 한 대에서만 사용할 때, 그리고 계정 보안과 관련되거나 낯선 로그인 기록이 보이는 모든 의문입니다. 이런 경우는 서버에서 계정 상태와 회선 도달 가능성을 확인해야 하며, 혼자 계속 시도해도 새로운 결과는 나오지 않습니다.

문의에 반드시 첨부할 정보

정보를 정확히 쓰면 한 번에 원인을 찾고, 두루뭉술하게 쓰면 몇 번을 주고받아도 기본 상황부터 확인하게 됩니다. 아래 목록을 항목별로 채워 넣는 것을 권합니다:

• 계정 사용자 이름(사용자 이름만, 비밀번호는 쓰지 마세요);
• 사용 플랫폼: Windows / macOS / iOS / Android / Linux 중 무엇인지, 그리고 기기 모델;
• 오류 메시지 원문: 그대로 옮겨 적거나 스크린샷을 찍고, '오류가 났다'고 요약하지 마세요;
• 발생 시각: 분 단위까지, 시간대도 함께;
• 네트워크 환경: 가정용 인터넷, 회사 네트워크, 공용 Wi-Fi, 모바일 데이터 중 무엇인지;
• 이미 시도한 단계: 가이드에 따라 어떤 단계를 했고 각 단계의 결과는 어땠는지;
• 문제가 안정적으로 재현되는지: 매번 나타나는지, 간헐적으로 나타나는지.

문의 외의 세 가지 경로

첫째, 사용 가이드는 가입부터 연결 확인까지의 기본 흐름을 다루므로 처음 설치하면서 문제가 생기면 그 페이지를 먼저 보세요. 둘째, 도움말 센터는 계정과 구독, 연결과 문제 해결, 속도와 회선, 결제와 환불 네 가지로 나눠 자주 묻는 질문을 정리해 두었으니 세부적인 문제는 거기서 바로 답을 찾을 수 있습니다. 셋째, 환불과 결제에 관한 의문은 요금제 페이지와 환불 정책에 규칙이 명시되어 있습니다. 첫 결제 후 30일 이내에는 이유를 묻지 않고 전액 환불을 신청할 수 있습니다. 환불 신청도 같은 문의 창구로 접수하며, 주문 시각만 적으면 됩니다.

마지막으로 서버 쪽 점검 속도를 설명하겠습니다. 문의는 접수 순서대로 처리되며, 정보를 모두 갖춘 문의는 보통 한 번에 결론이 나오고, 정보가 부족한 문의는 먼저 보완을 요청받습니다. 그러니 '연결이 안 되는데 어떻게 하나요'라고 급하게 한 줄 넣기보다, 2분을 들여 위 목록의 일곱 항목을 채우는 편이 낫습니다. 이것이 이 가이드가 처음부터 끝까지 전하려는 한 가지이기도 합니다. 증상을 정확히 설명하면 문제는 이미 절반이 해결된 것입니다.