VPN 문제 해결 가이드

재현 가능한 문제 진단 방법 만들기

네트워크 문제는 여러 단계에서 비슷한 증상으로 나타나기 때문에 오판하기 쉽습니다. 클라이언트에 연결 실패가 표시되어도 일시적인 로컬 네트워크 장애, 잘못된 시스템 시간, 미갱신 구독, 접근할 수 없는 라우팅 또는 이전 네트워크 확장이 인터페이스를 점유한 것이 원인일 수 있습니다. 연결됨으로 표시되는데 웹페이지가 열리지 않는 경우에도 라우팅 자체가 고장 났다고 단정할 수 없습니다. 브라우저 프록시, DNS 캐시, 라우팅 규칙과 앱의 연결 재사용이 이전 경로를 계속 사용할 수 있기 때문입니다. 효과적인 점검은 연결 버튼을 반복해서 누르는 것이 아니라 전체 경로를 나누어 입력, 처리 과정과 결과를 차례로 확인하는 것입니다.

시작하기 전에 현재 상태를 기록하세요. 사용 중인 플랫폼, 클라이언트 이름, 현재 네트워크 유형, 선택한 라우팅, 문제가 시작된 대략적인 시각, 화면에 표시된 전체 오류와 서비스 연결을 끊었을 때 일반 웹사이트에 접속할 수 있는지를 적어 둡니다. 먼저 설정을 초기화하거나 즉시 재설치하지 마세요. 원래 상태가 덮어쓰이면 구독 내용, 시스템 권한 또는 라우팅 선택 중 무엇이 문제였는지 판단하기 어려워집니다. 화면에서 로그를 복사할 수 있다면 먼저 텍스트로 저장하세요. 오류만 확인할 수 있다면 문맥이 보이는 스크린샷을 보관하되, 제출 전 사용자 이름, 비밀번호와 구독 내용을 가리세요.

비교 테스트로 범위 좁히기

비교 테스트의 핵심은 한 번에 변수 하나만 바꾸는 것입니다. 같은 기기와 클라이언트를 유지한 채 먼저 라우팅을 변경하면 문제가 라우팅 측에 집중되어 있는지 확인할 수 있습니다. 라우팅을 유지하고 다른 로컬 네트워크로 바꾸면 현재 접속 네트워크가 연결에 영향을 주는지 알 수 있습니다. 네트워크와 라우팅을 유지한 채 브라우저와 다른 앱을 각각 테스트하면 특정 앱의 라우팅 문제인지 판단할 수 있습니다. 클라이언트, 네트워크와 라우팅을 동시에 바꾸면 복구되더라도 어떤 변경이 효과가 있었는지 알 수 없어 다음에 같은 문제가 발생했을 때 처음부터 다시 시험해야 합니다.

또한 ‘연결을 만들 수 없음’, ‘연결은 되었지만 데이터 없음’, ‘일부 대상에 접근할 수 없음’, ‘접속은 되지만 사용이 불안정함’을 구분해야 합니다. 각 상태는 확인할 지점이 다릅니다. 첫 번째는 권한, 시간, 구독과 프로토콜을 우선 확인하고, 데이터가 없으면 기본 라우팅, DNS와 시스템 프록시를 확인하세요. 일부 대상만 이상하면 규칙, 지역과 앱 캐시를 살펴보고, 사용이 불안정하면 패킷 손실, 경로 혼잡, 로컬 무선 환경과 백그라운드 제한을 확인합니다. ‘안 된다’를 구체적인 증상으로 바꾸는 것만으로도 진단에서 가장 중요한 단계를 마친 셈입니다.

먼저 계정과 설정 보호하기

ZJVPN은 이메일 주소 없이 사용자 이름과 비밀번호만으로 계정을 만들 수 있으므로, 사용자 이름과 비밀번호는 접근 복구에 중요한 자격 증명입니다. 점검 중에는 자격 증명, 구독 전문 또는 토큰이 포함된 링크를 공개 게시판에 올리지 마세요. 구독 주소는 접근 자격 증명과 비슷한 역할을 하므로 스크린샷을 찍을 때 주소 표시줄, QR 코드와 로그에 전체 내용이 노출되지 않았는지 확인하세요. 예시 설정에는 항상 다음과 같이 명확한 가짜 값을 사용하세요:

subscription: "https://example.com/sub?token=YOUR_TOKEN"
profile: "diagnostic-copy"
dns-mode: "system"

설정을 복사해 테스트할 때는 수정하지 않은 원본을 한 부 보관하고, 테스트용 복사본에는 알아보기 쉬운 이름을 붙이세요. 복구할 때는 먼저 클라이언트를 종료한 다음 원본을 가져와 여러 네트워크 확장이 동시에 활성화되지 않도록 합니다. 시스템 업데이트, 클라이언트 교체 또는 네트워크 환경 변경 후 문제가 시작되었다면 해당 변경도 기록하세요. 변경의 발생 순서는 단일 오류 코드보다 더 유용한 단서가 되는 경우가 많습니다.

기본 기록을 마쳤다면 해당 증상에 맞는 장으로 이동하세요. 여러 증상이 동시에 나타나면 가장 먼저 실패한 지점을 기준으로 합니다. 먼저 연결 자체를 해결하고, 그다음 연결 후 웹페이지와 DNS를 처리한 뒤 마지막으로 속도와 특정 앱을 분석하세요. 하위 연결이 안정되지 않은 상태에서는 상위 앱 테스트 결과에 진단 가치가 거의 없습니다.

연결 자체가 안 될 때: 권한부터 라우팅까지 단계별 확인

‘연결 자체가 안 됨’은 클라이언트가 연결됨 상태로 전환되지 않거나, 연결을 시작하자마자 다시 연결 끊김 상태로 돌아가는 경우를 말합니다. 먼저 실패 지점이 클라이언트 내부인지, 라우팅과 세션을 설정하는 과정인지 구분해야 합니다. 연결을 눌렀을 때 시스템에 네트워크 권한 요청이 전혀 나타나지 않거나 클라이언트에 권한 부족이 명확히 표시된다면 대개 기기 측 문제입니다. 반대로 연결 과정이 일정 시간 지속된 뒤 시간 초과가 발생한다면 로컬 네트워크와 라우팅 사이의 경로 이상일 가능성이 더 큽니다. 두 문제의 처리 순서는 다르므로 운에 맡겨 라우팅만 계속 바꿔서는 안 됩니다.

로컬 네트워크와 시스템 기본 상태 확인

먼저 ZJVPN 연결을 끊고 평소에 열리는 일반 웹페이지에 접속하세요. 일반 웹페이지도 열리지 않는다면 기존 접속 네트워크를 먼저 복구해야 합니다. 네트워크 가속 연결은 현재 접속 경로에 의존하기 때문입니다. 접속 페이지에서 약관 동의나 웹 로그인이 필요하다면 연결을 끊은 상태에서 인증을 완료한 뒤 클라이언트로 돌아와 연결하세요. 사무실, 학교와 호텔 네트워크는 연결 방식별로 자체 규칙을 적용할 수 있습니다. 허용된 환경에서 다른 접속 네트워크로 바꿔 비교할 수 있지만, 문제가 있는 네트워크에서 구독을 계속 삭제해도 기본 접속 문제는 해결되지 않습니다.

그다음 시스템 날짜, 시간과 시간대가 시스템에 의해 정상적으로 관리되는지 확인하세요. 보안 연결은 인증서 유효 기간을 검증하므로 시간이 크게 어긋나면 핸드셰이크 실패, 인증서 오류 또는 연결 직후 끊김으로 나타날 수 있습니다. 시간을 수정한 뒤에는 클라이언트를 완전히 종료했다가 다시 열어 네트워크 구성 요소가 상태를 새로 읽게 하세요. 기기가 절전 모드에서 막 깨어났다면 시스템 네트워크가 안정될 때까지 기다린 후 연결하세요. 절전 전에 남은 가상 인터페이스가 잠시 사용할 수 없는 상태일 수 있습니다.

시스템 권한과 충돌 구성 요소 확인

Windows와 macOS에서는 클라이언트가 가상 네트워크 인터페이스를 만들거나 사용할 수 있도록 허용해야 합니다. iOS와 Android는 처음 사용할 때 VPN 구성을 생성할 권한을 요청합니다. Linux에서는 네트워크 인터페이스와 라우팅을 조작하는 데 필요한 권한이 클라이언트에 있는지 확인하세요. 권한을 거부한 뒤 클라이언트가 요청을 다시 자동으로 표시하지 않을 수 있으므로 시스템 설정에서 해당 권한을 확인해야 합니다. 권한을 허용한 뒤에는 다른 유사 네트워크 도구를 먼저 종료하고 ZJVPN을 테스트하세요. 여러 도구가 기본 라우팅, 시스템 프록시 또는 DNS를 동시에 변경하면 화면은 정상인데 데이터가 잘못된 인터페이스로 흐르는 충돌이 발생할 수 있습니다.

시스템에서 이전 클라이언트, 기업용 보안 접속 도구, 패킷 캡처 도구 또는 가상 머신 네트워크 구성 요소가 여전히 실행 중인지 확인하세요. 이런 소프트웨어를 영구적으로 삭제할 필요는 없습니다. 진단하는 동안 완전히 종료하고 관련 네트워크 확장이 더 이상 작동하지 않는지만 확인하면 됩니다. 종료 후 연결된다면 하나씩 다시 활성화해 충돌 원인을 찾으세요. 방화벽이나 보안 정책에서 접근 요청이 표시되면 프로그램 이름과 출처를 확인한 뒤 조직의 규칙에 따라 처리하세요. 테스트를 위해 보안 기능 전체를 끄면 안 됩니다. 관리되는 기기의 정책은 기기 관리자에게 확인해야 합니다.

구독, 라우팅과 프로토콜 확인

클라이언트에 선택할 수 있는 라우팅이 실제로 존재하는지 확인하세요. 비어 있는 설정 이름 하나만 있는 것은 아닌지 살펴봐야 합니다. 라우팅 목록이 비어 있거나 업데이트 시간이 바뀌지 않거나 모든 항목이 동시에 사라졌다면 먼저 구독 업데이트 장으로 이동하세요. 라우팅이 있다면 서로 다른 지역의 라우팅을 선택해 비교합니다. ZJVPN은 90+개 국가 / 200+개 라우팅을 제공하므로 테스트 목적은 계속 클릭하는 것이 아니라 ‘모든 라우팅이 같은 단계에서 실패하는지’ 또는 ‘특정 그룹만 실패하는지’를 확인하는 데 있습니다. 전자는 권한, 구독 또는 로컬 네트워크 문제일 가능성이 높고, 후자는 특정 경로 문제일 가능성이 높습니다. 노드 페이지에서 라우팅 유형과 지역 선택 원칙을 확인할 수 있습니다.

클라이언트에서 여러 연결 모드를 제공하더라도 먼저 구독 기본값을 사용하세요. 의미를 모르는 상태에서 포트, 전송 방식, 암호화 매개변수 또는 서버 이름을 직접 바꾸지 마세요. 어느 한 필드라도 구독과 다르면 핸드셰이크가 실패할 수 있습니다. 설정을 수동으로 편집한 적이 있다면 새로 깨끗한 설정을 만들고 구독을 다시 가져와 이전 설정과 비교하세요. 깨끗한 설정에서 연결된다면 문제는 로컬 수정에서 비롯된 것이므로 계정이나 모든 라우팅을 계속 의심할 필요가 없습니다.

한 네트워크에서는 모든 연결이 시간 초과되지만 다른 네트워크에서는 정상이라면 두 네트워크의 유형과 실패 시각을 기록하세요. 단순히 ‘라우팅이 작동하지 않음’이라고만 적지 마세요. 같은 네트워크에서 다른 기기는 연결되는데 현재 기기만 안 된다면 권한, 충돌 구성 요소와 클라이언트 설정으로 다시 범위를 좁힙니다. 현재 기기의 모든 라우팅이 실패하고 다른 기기도 같은 네트워크에서 실패한다면 로컬 출구나 네트워크 정책을 우선 확인할 가치가 있습니다. 이러한 교차 검증은 문의 처리 범위를 크게 줄여 줍니다.

연결됐지만 웹페이지가 열리지 않을 때: DNS 오류 확인

클라이언트에 연결됨이 표시된다는 것은 세션이 만들어졌다는 뜻일 뿐, 모든 트래픽이 해당 세션으로 정상 진입한다는 의미는 아닙니다. 웹페이지가 열리지 않을 때는 도메인 확인 실패, 기본 라우팅 미전환, 브라우저의 이전 프록시 사용, 대상 웹사이트의 현재 지역 거부 또는 전환 중 로컬 네트워크 연결 손실을 구분해야 합니다. 곧바로 ‘노드가 고장 났다’고 단정하면 확인할 수 있는 단계를 많이 건너뛰게 됩니다. 도메인, 주소, 여러 앱과 여러 라우팅을 나누어 테스트하는 것이 가장 효과적입니다.

모든 대상인지 일부 대상인지 먼저 확인

성격이 다른 일반 웹페이지를 여러 개 열면서 다른 앱도 인터넷에 연결되는지 함께 확인하세요. 모든 웹페이지와 앱에 데이터가 없다면 기본 라우팅, 시스템 프록시와 DNS를 우선 살펴봅니다. 브라우저만 이상하고 다른 앱은 정상이라면 브라우저 프록시, 확장 프로그램과 보안 DNS를 먼저 확인하세요. 특정 웹사이트 하나만 열리지 않는다면 대상 지역, 사이트 자체 상태, 캐시와 라우팅 규칙을 고려해야 합니다. 단일 웹사이트의 결과로 전체 네트워크 경로를 판단하지 마세요. 대상 서비스의 점검도 같은 증상을 만들 수 있습니다.

브라우저의 독립 프록시 확장 프로그램을 끄고 새 시크릿 창에서 테스트하세요. 일부 브라우저는 이전 연결 풀을 보관하므로 시스템 라우팅이 바뀌어도 기존 탭이 연결이 끊기기 전에 만든 연결을 재사용할 수 있습니다. 같은 페이지를 반복해서 새로 고치는 것보다 브라우저를 완전히 종료한 뒤 다시 여는 편이 더 확실합니다. 시크릿 창은 열리는데 일반 창이 열리지 않는다면 라우팅을 계속 바꾸지 말고 확장 프로그램, 캐시, 사이트 데이터와 브라우저 사용자 지정 DNS를 확인하세요.

DNS와 라우팅 장애 구분

DNS는 도메인 이름을 네트워크 주소로 변환합니다. 확인에 실패하면 브라우저에 서버를 찾을 수 없음, 존재하지 않는 도메인 또는 확인 시간 초과가 표시되는 경우가 많습니다. 라우팅 장애는 확인이 완료된 뒤 연결 시간 초과로 나타나는 경우가 많습니다. 시스템에 기본으로 포함된 명령을 사용해 확인 결과를 볼 수 있습니다. 다음 명령에는 자격 증명이 포함되지 않으므로 해당 플랫폼의 터미널에서 실행할 수 있습니다:

nslookup example.com

ping example.com

traceroute example.com

일부 시스템에서는 경로 추적 명령의 이름이 다릅니다. 명령을 사용할 수 없더라도 별도 도구를 설치할 필요는 없습니다. 브라우저 오류와 클라이언트 로그를 보관하면 됩니다. 또한 ‘대상이 ping에 응답하지 않는다’고 해서 바로 라우팅 장애로 판단하지 마세요. 대상 서버가 이러한 요청에 응답하지 않을 수 있습니다. 여기서 확인할 것은 도메인이 확인되는지, 요청이 로컬에서 즉시 실패하는지, 연결을 끊었을 때와 연결했을 때 결과가 달라지는지이지 특정 수치를 얻는 것이 아닙니다.

도메인을 확인할 수 없지만 알고 있는 주소로 직접 접속하면 연결된다면 DNS 문제에 가까울 수 있습니다. 먼저 클라이언트를 종료한 뒤 시스템 DNS 캐시를 정리하고 다시 연결해 테스트하세요. Windows에서는 터미널에서 다음을 사용할 수 있습니다:

ipconfig /flushdns

macOS, iOS, Android와 Linux의 DNS 관리는 시스템 버전, 네트워크 관리 서비스와 클라이언트 구현에 따라 달라지므로 적용되지 않는 명령을 그대로 따라 하면 안 됩니다. 일반적인 방법은 연결을 끊고 클라이언트를 종료한 뒤 네트워크를 한 번 바꾸고 다시 연결하는 것입니다. Linux 사용자는 현재 확인 상태와 기본 라우팅을 먼저 확인한 다음 어떤 서비스가 관리하는지 판단할 수 있습니다:

resolvectl status

ip route

여러 DNS 설정이 서로 덮어쓰지 않도록 확인

클라이언트, 운영체제, 브라우저와 로컬 네트워크가 각각 DNS를 제공할 수 있습니다. 브라우저에서 독립 보안 DNS를 활성화하면 시스템이 할당한 확인 경로를 우회할 수 있습니다. 클라이언트가 가상 DNS를 사용하면서 시스템 네트워크 관리 서비스가 연결 변경 시 설정을 덮어쓰면 처음에는 정상이다가 잠시 후 확인에 실패할 수 있습니다. 진단할 때는 먼저 변수를 줄이세요. 브라우저는 시스템 설정을 따르도록 되돌리고, 클라이언트는 구독 기본 설정을 사용하며, 시스템 네트워크 카드에는 이전에 수동 입력했지만 더 이상 유효하지 않은 주소가 남지 않게 합니다. 기본 경로가 정상임을 확인한 뒤 개인 설정을 하나씩 복원하세요.

특정 도메인만 비정상 주소로 확인된다면 브라우저 캐시와 시스템 캐시를 정리한 뒤 라우팅을 바꾸어 다시 확인하세요. 같은 접속 네트워크에 있는 여러 기기에서 동일한 비정상 결과가 나오고 네트워크를 바꾸면 복구된다면 로컬 확인 소스를 중점적으로 살펴볼 필요가 있습니다. 한 기기에서 어떤 네트워크를 사용해도 이상하지만 다른 기기는 정상이라면 현재 기기의 브라우저, hosts 파일, 보안 소프트웨어 또는 DNS 설정 문제일 가능성이 큽니다.

시스템 프록시와 기본 라우팅 확인

일부 클라이언트는 시스템 프록시로 브라우저 트래픽을 전달하고, 다른 클라이언트는 가상 인터페이스로 시스템 라우팅을 제어합니다. 클라이언트가 비정상 종료되면 시스템 프록시에 더 이상 존재하지 않는 로컬 포트가 남아 연결을 끊은 뒤에도 웹페이지가 열리지 않을 수 있습니다. 이때는 시스템 네트워크 설정에서 프록시가 수동으로 활성화되어 있는지 확인하세요. 네트워크 안내 글에 나온 공용 프록시 주소를 임의로 입력하지 마세요. 정상적인 경우 현재 클라이언트가 자동으로 관리합니다. 클라이언트를 다시 열고 정상적으로 연결을 끊는 것이 프로세스를 강제 종료하는 것보다 원래 설정을 복구하기 쉽습니다.

연결 후 로컬 네트워크 기기에만 접근할 수 없고 인터넷은 정상이라면 전체 라우팅이 로컬 주소를 제어하고 있을 수 있습니다. 클라이언트에서 로컬 네트워크 우회나 앱별 라우팅 옵션을 제공하는지 확인하고 기본 규칙으로 테스트하세요. 인터넷과 로컬 네트워크 모두 데이터가 없다면 기본 라우팅과 가상 인터페이스로 돌아가 확인해야 합니다. 관리되는 네트워크의 내부 도메인은 조직 내부 DNS로만 확인될 수 있습니다. 외부 라우팅에 연결한 뒤 확인되지 않는 것은 네트워크 경계 문제일 수 있으므로 관리자에게 사용 가능한 방식을 문의하세요.

느린 속도와 혼잡 시간대 끊김을 단계별로 판단하기

속도 문제는 한 번의 속도 측정 결과만으로 판단할 수 없습니다. 국제 접속은 로컬 접속, 통신사 출구, 라우팅 진입점, 지역 간 경로, 대상 서비스와 콘텐츠 전송 네트워크를 거치며 어느 한 단계의 변화도 사용 경험에 영향을 줄 수 있습니다. 저녁 혼잡 시간대의 끊김은 가정 내 무선 네트워크 경쟁, 대상 플랫폼의 혼잡 또는 선택한 지역과의 거리에서 비롯될 수도 있습니다. 진단의 목표는 보기 좋은 숫자를 얻는 것이 아니라 병목이 안정적으로 재현되는지, 어떤 대상에서 집중되는지와 어떤 조건을 바꾸면 개선되는지를 찾는 것입니다.

먼저 비교 가능한 테스트 조건 만들기

연결을 끊은 상태와 연결한 상태에서 동일한 안정적 대상에 각각 접속하고, 기기 위치, 접속 네트워크와 테스트 콘텐츠를 동일하게 유지하세요. 여러 속도 측정 사이트를 한꺼번에 사용하거나 서로 다른 지역, 파일과 시간대의 결과를 직접 비교하지 마세요. 브라우저 다운로드, 클라우드 동기화, 시스템 업데이트, 온라인 동영상과 다른 기기의 대용량 작업은 로컬 대역폭을 차지합니다. 테스트 전에 이런 활동을 일시 중지하세요. 무선 환경에서는 접속 장치 가까이에서 테스트해 신호 차단과 잦은 로밍을 배제하세요.

연결을 끊은 상태 자체가 느리다면 먼저 로컬 네트워크를 처리하세요. 연결을 끊으면 정상인데 모든 라우팅이 느리고 다른 접속 네트워크로 바꾸면 복구된다면 원래 로컬 출구에 문제가 있을 가능성이 높습니다. 특정 지역 라우팅만 느리고 인접 지역으로 바꾸면 복구된다면 사용 목적에 맞는 라우팅을 선택하세요. 특정 콘텐츠 플랫폼만 끊기고 일반 웹페이지, 파일 다운로드와 다른 동영상 서비스는 정상이라면 대상 플랫폼의 지역 구분, 캐시 노드와 계정 지역을 고려해야 합니다. 이를 전체 네트워크 속도 저하로 일반화하지 마세요.

지연 시간, 처리량과 안정성의 차이 이해하기

지연 시간은 상호작용 응답에 영향을 주고, 처리량은 지속적인 전송 속도에 영향을 주며, 안정성은 연결에 흔들림, 재전송과 멈춤이 발생하는지를 결정합니다. 웹페이지가 느리게 열리는 것은 확인 과정이나 첫 연결의 지연 때문일 수 있습니다. 동영상 재생을 시작한 뒤 반복해서 버퍼링된다면 지속 처리량이나 패킷 손실에 더 가깝습니다. 원격 회의 음성이 끊기는 경우에는 순간적인 최대 대역폭보다 안정성이 중요합니다. 한 번의 다운로드가 빠르다고 해서 실시간 앱도 안정적이라고 할 수 없습니다. 실제 사용 상황에 맞춰 증상을 기록하고 속도 측정 스크린샷 한 장만 제출하지 마세요.

라우팅 거리는 일반적으로 왕복 경로에 영향을 줍니다. 일본 지역의 대상을 이용할 때는 거리가 가깝고 대상에 접근할 수 있는 지역을 선택하는 편이 합리적입니다. 유럽 대상에 접속할 때는 가까운 진입점이 대상까지 가장 짧은 경로를 의미하지 않을 수 있습니다. ZJVPN은 90+개 국가 / 200+개 라우팅을 제공하므로 선택할 때 먼저 노드 안내의 지역과 라우팅 유형을 참고한 뒤 실제 대상과 비교하세요. 너무 자주 바꾸면 연결 풀과 콘텐츠 캐시가 끊기므로 변경 후에는 앱이 세션을 다시 만든 뒤 충분한 사용 과정을 관찰하세요.

혼잡 시간대 문제 증거 수집

혼잡 시간대 문제는 시간과 연관되어 있으므로 낮에 제출한 정상 결과만으로는 재현할 수 없습니다. 정상 시간대와 이상 시간대에 동일한 작업을 수행하고 라우팅 이름, 접속 네트워크, 대상 서비스와 대략적인 시각을 기록하세요. 이상 시간대에 다른 라우팅으로 바꾸자마자 개선되고 로컬 일반 네트워크는 여전히 정상이라면 두 라우팅을 명확한 비교 자료로 고객센터에 제공할 수 있습니다. 모든 라우팅과 일반 네트워크가 동시에 느려진다면 로컬 접속 혼잡일 가능성이 더 높습니다.

대용량 다운로드를 계속 새로 고치거나 여러 속도 측정을 동시에 실행해 라우팅을 ‘부하 테스트’하지 마세요. 로컬 환경 자체가 변수가 되고 요금제 트래픽을 소모할 수 있습니다. 월간 구독 트래픽은 개통일을 기준으로 매월 초기화됩니다. 트래픽 패키지는 소진될 때까지 사용할 수 있으며 영구적으로 만료되지 않습니다. 점검 전 계정 개요에서 현재 사용량을 확인해 트래픽 상태와 속도 문제를 혼동하지 않도록 하세요. 요금제 상세 내용은 요금제 페이지에서 확인할 수 있습니다.

스트리밍과 대용량 파일 환경

스트리밍 앱은 이전 세션의 지역과 콘텐츠 전송 노드를 캐시하는 경우가 많습니다. 라우팅을 바꾼 뒤에도 화질이나 지역 콘텐츠가 달라지지 않는다면 재생 중에 계속 라우팅을 전환하지 말고 앱을 완전히 종료한 뒤 적절한 캐시를 정리하고 다시 여세요. 플랫폼 선택과 지역별 콘텐츠 판단은 스트리밍 콘텐츠 이용 안내에서 계속 확인할 수 있습니다. Mac에서 네트워크 확장, 시스템 권한 또는 Apple 서비스와의 공존이 주요 문제라면 Mac VPN 추천과 선택 기준의 확인 방법을 참고하세요.

대용량 파일은 시작 순간의 속도가 아니라 지속적인 안정성을 관찰해야 합니다. 다운로드 소스가 계정, 지역 또는 서버에 따라 속도를 제한할 수 있으므로 서로 다른 출처로 비교할 수 있지만, 출처가 불분명한 테스트 파일은 사용하지 마세요. 웹페이지는 정상이고 특정 다운로드 소스만 느리다면 대상 서버를 우선 확인하세요. 신뢰할 수 있는 여러 대상이 같은 경로에서 계속 느려질 때 라우팅, 시간과 대상 유형을 정리해 문의하세요.

잦은 연결 끊김과 모바일 백그라운드 연결 끊김

잦은 연결 끊김은 먼저 능동적인 연결 해제와 수동적인 중단을 구분해야 합니다. 능동적인 연결 해제는 시스템 절전, 네트워크 전환, 배터리 절약 정책, 클라이언트 자동 규칙 또는 사용자 조작에서 비롯되는 경우가 많습니다. 수동적인 중단은 무선 신호 변화, 로컬 출구 재연결, 라우팅 세션 이상 또는 클라이언트 네트워크 확장 충돌 때문일 수 있습니다. 화면에는 둘 다 ‘연결 끊김’으로만 표시될 수 있지만 로그의 시간 순서는 다릅니다. 진단할 때는 끊긴 뒤의 오류만이 아니라 끊기기 전에 기기에서 무슨 일이 있었는지도 기록하세요.

연결 끊김을 유발한 조건 관찰

먼저 연결 끊김이 화면 잠금, 절전, 무선 네트워크 전환, 앱 이탈, 외부 네트워크 연결 또는 시스템 복구와 관련 있는지 확인하세요. 화면을 잠글 때마다 발생한다면 백그라운드 실행과 배터리 절약 제한을 우선 확인합니다. 무선에서 다른 네트워크로 전환할 때 발생한다면 하위 인터페이스 변화이므로 클라이언트가 자동으로 다시 연결되는지 관찰하세요. 화면과 네트워크를 그대로 유지해도 주기적으로 끊긴다면 그때 라우팅, 클라이언트 로그와 시스템 네트워크 구성 요소를 확인합니다. 유발 동작을 구체적으로 적는 것이 끊긴 횟수를 기록하는 것보다 재현에 도움이 되는 경우가 많습니다.

데스크톱 플랫폼에서는 시스템 절전이 네트워크 인터페이스를 일시 중지합니다. 깨어난 뒤 이전 세션이 이미 만료되어 클라이언트가 연결을 다시 만들어야 할 수 있습니다. 화면에는 연결됨으로 표시되지만 데이터가 없다면 먼저 수동으로 연결을 끊었다가 다시 연결하세요. 즉시 기기를 재시작하지 마세요. 깨어날 때마다 복구되지 않는다면 다른 네트워크 확장이 동시에 실행 중인지, 클라이언트가 복구되기 전에 다른 프로그램이 시스템 프록시를 덮어쓰는지 확인하세요. 기업용 기기는 깨어난 뒤 보안 정책을 다시 적용할 수 있으므로 조직 환경을 함께 고려해야 합니다.

모바일 백그라운드 정책

iOS와 Android는 배터리, 메모리, 네트워크 상태와 앱 활성도에 따라 백그라운드 프로세스를 관리합니다. 클라이언트가 시스템에 의해 일시 중지되면 화면에는 이전 상태가 남아 있어도 연결을 다시 만들어야 할 수 있습니다. 시스템 설정에서 클라이언트가 정상적으로 백그라운드에서 실행되도록 허용하고, 강제 종료 목록에 넣지 마세요. Android 기기는 제조사별 배터리 절약 정책 차이가 크므로 시스템 설정의 배터리와 백그라운드 관리 항목을 기준으로 확인하세요. 관련 기본 조작은 Android VPN 설치부터 확인까지에서도 볼 수 있습니다.

여러 자동 연결 규칙을 동시에 활성화하지 마세요. 시스템 주문형 연결, 클라이언트 시작 시 자동 연결과 네트워크 전환 시 자동 연결이 모두 작동하면 인터페이스가 바뀔 때 서로를 호출해 연결과 끊김이 반복될 수 있습니다. 진단 중에는 하나의 자동 정책만 남기고 나머지는 잠시 끄세요. 수동 연결이 안정적인 것을 확인한 뒤 자동 설정을 하나씩 복원합니다. 특정 무선 네트워크에서만 문제가 나타난다면 해당 네트워크에 재인증이 필요한지, 유휴 상태에서 연결을 회수하는지 확인하세요.

라우팅 끊김과 로컬 인터페이스 초기화 구분

라우팅이 끊길 때 로그에는 원격 연결 종료, 핸드셰이크 시간 초과 또는 재연결 과정이 나타나는 경우가 많습니다. 로컬 인터페이스 초기화는 네트워크 변경, 라우팅 소실, 주소 갱신 또는 시스템 네트워크 서비스 재시작과 함께 나타날 가능성이 큽니다. 일반 사용자가 모든 로그를 해석할 필요는 없으며, 끊기기 전후의 연속 구간만 보관하면 됩니다. 마지막 한 줄만 캡처하지 마세요. 마지막 줄은 재시도 실패일 뿐 실제 원인은 앞부분에 있을 수 있습니다.

같은 네트워크에서 라우팅을 바꾸어 관찰할 수 있습니다. 모든 라우팅이 화면 잠금, 절전 또는 네트워크 전환 후 끊긴다면 시스템 정책을 우선 처리하세요. 기기를 계속 사용 중인데 특정 라우팅만 중단되고 다른 라우팅은 안정적이라면 라우팅 이름을 기록하고 잠시 다른 라우팅을 사용하세요. 접속 네트워크를 바꾼 뒤 문제가 사라진다면 원래 네트워크의 신호, 인증과 출구 변화를 중점적으로 확인합니다. 같은 접속 네트워크의 여러 기기에서 동시에 끊긴다면 로컬 네트워크나 상위 경로를 의심할 만합니다.

복구할 때 연결 반복 방지

연속 재연결이 발생하면 먼저 자동 연결을 끄고 수동으로 연결을 끊은 뒤 시스템 네트워크가 정상으로 돌아올 때까지 기다렸다가 한 번만 다시 연결하세요. 스위치를 빠르게 반복해서 누르지 마세요. 연결과 해제 요청이 동시에 처리되면 화면 상태가 시스템 상태를 따라가지 못할 수 있습니다. 클라이언트가 멈추지 않는다면 먼저 앱을 정상적으로 종료한 뒤 시스템 VPN 설정에서 구성이 연결 해제되었는지 확인하세요. 네트워크 인터페이스가 명확히 남아 있고 일반 웹페이지에도 영향을 줄 때만 기기 재시작을 고려합니다.

재시작 후 잠시 복구되지만 특정 앱을 실행하거나 특정 네트워크 환경에 들어갈 때마다 재발한다면 유발 조건을 계속 비교하세요. 재시작은 현장 상태를 지웠을 뿐 근본 원인을 해결했다는 뜻이 아닙니다. ‘재시작하면 복구됨’과 ‘특정 조건 후 재발함’을 함께 문의에 적으면 리소스 잔류, 클라이언트 충돌과 라우팅 문제를 구분하는 데 도움이 됩니다. 시스템이 방금 업데이트되었다면 업데이트 전후의 차이도 적되, 구체적인 버그라고 추측하지는 마세요.

구독 업데이트 실패와 기기 상태 확인

구독 업데이트 실패는 설정을 다운로드할 수 없거나, 라우팅 목록이 비어 있거나, 업데이트 시간이 바뀌지 않거나, 가져온 직후 형식 오류가 발생하거나, 이전 라우팅은 남아 있지만 새 내용이 나타나지 않는 형태로 나타납니다. 계정 접근, 구독 주소, 클라이언트 파싱, 로컬 캐시와 요금제 상태를 구분해야 합니다. 구독은 설정을 가져오는 입구이지 라우팅 연결 자체가 아닙니다. 구독 내용조차 정상적으로 가져오지 못했다면 라우팅을 계속 테스트해도 의미가 없습니다.

접속 경로와 계정 상태 확인

먼저 사용자 패널에서 구독을 가져오고 채팅 기록, 예전 스크린샷 또는 공개 페이지에 저장된 이전 주소를 사용하지 마세요. ZJVPN은 이메일 주소 없이 사용자 이름과 비밀번호로 계정을 만들 수 있습니다. 로그인 정보를 잊었다면 패널에서 제공하는 계정 절차를 따르고, 중복 계정을 여러 개 만들지 마세요. 로그인 후 개요와 요금제 상태를 확인한 다음 클라이언트 다운로드에서 현재 플랫폼에 맞는 설정 방법을 선택하세요.

월간 구독은 ¥9.9/월에 60GB, ¥18/월에 250GB, ¥28/월에 500GB를 포함하며, 트래픽은 개통일을 기준으로 매월 초기화되고 중도 업그레이드 차액은 남은 일수에 따라 계산됩니다. 트래픽 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며, 소진될 때까지 사용할 수 있고 영구적으로 만료되지 않습니다. 점검할 때는 현재 요금제가 사용 가능한 상태인지 확인하면 되며, 남은 기간을 직접 계산하거나 트래픽 상태를 추측하지 마세요. 요금제 정보가 예상과 다르면 먼저 요금제 안내와 비교한 뒤 주문 관련 정보를 제출하세요.

안전하게 구독 다시 가져오기

현재 설정의 이름을 바꾸거나 백업을 내보낸 뒤, 새 빈 설정을 만들어 최신 구독을 가져오세요. 이렇게 하면 문제가 이전 캐시에서 비롯되었는지 구독 내용에서 비롯되었는지 구분할 수 있습니다. 이전 설정에서 서버 주소와 프로토콜 필드를 직접 덮어쓰지 말고, 서로 다른 서비스의 노드를 하나의 설정에 합친 뒤 고객센터에 판단을 요청하지도 마세요. 혼합 설정에서는 로그만으로 요청이 어느 항목에서 발생했는지 확인하기 어렵습니다.

구독 주소를 복사할 때 불필요한 공백, 줄바꿈 또는 채팅 앱에서 잘린 부분이 없는지 확인하세요. 주소는 브라우저 검색창이 아니라 클라이언트의 구독 가져오기 위치에 직접 붙여넣어야 합니다. 공개 페이지에 게시하지도 마세요. 클라이언트가 QR 코드 가져오기를 지원하더라도 QR 코드가 로그인한 사용자 패널에서 제공된 것인지 확인하세요. 가져오기에 실패하면 전체 안내 문구를 저장하고, 특히 네트워크 요청 실패, 인증 실패, 내용 없음과 형식 파싱 실패를 구분하세요. 각각의 안내는 처리 방향이 다릅니다.

브라우저에서는 사용자 패널에 접속되지만 클라이언트에서 구독 업데이트가 실패한다면 클라이언트에만 시스템 프록시, DNS 또는 방화벽 문제가 적용되는지 확인하세요. 현재 연결을 끊고 일반 네트워크에서 업데이트해 볼 수 있습니다. 연결 후에만 업데이트할 수 있다면 현재 사용 가능한 라우팅을 선택해 다시 시도하세요. 업데이트가 성공한 뒤에는 ‘완료’ 표시만 보지 말고 라우팅 목록이 실제로 갱신되었는지 확인하세요. 클라이언트가 이전 설정 사본을 보관할 수 있으므로 이름이 같아도 내용이 같다는 뜻은 아닙니다.

캐시, 시간과 형식 문제

시스템 시간이 어긋나면 구독 요청의 보안 연결이 실패할 수 있으며, 라우팅 핸드셰이크 문제와 비슷하게 나타납니다. 시간을 수정한 뒤 클라이언트를 완전히 종료하고 다시 시도하세요. 클라이언트가 설정 대신 웹페이지 텍스트를 다운로드했다면 로그인 상태가 만료되었거나 주소가 완전히 복사되지 않았거나 요청이 리디렉션되었을 수 있습니다. 웹페이지 소스를 설정으로 가져오지 마세요. 로그에 형식 오류가 표시되면 사용자 패널에서 원본 구독을 다시 가져와 인코딩, 따옴표나 들여쓰기를 수동으로 편집하지 않도록 합니다.

캐시 정리는 범위를 제한해야 합니다. 먼저 특정 구독의 캐시만 삭제하고 전체 클라이언트 데이터를 먼저 지우지 마세요. 다른 유효한 설정과 규칙이 포함되어 있을 수 있습니다. 재설치가 필요하다면 먼저 사용자 이름과 비밀번호가 유효한지 확인하고 보관할 비민감 설정을 내보내세요. 재설치 후에는 깨끗한 구독 하나만 가져와 확인하고 정상 작동을 확인한 뒤 사용자 지정 규칙을 하나씩 복원합니다.

기기 수 제한 없음이 하나의 설정을 무제한 복제해도 된다는 뜻은 아닙니다

ZJVPN은 동시 접속 기기 수를 제한하지 않지만, 각 기기는 올바른 플랫폼용 클라이언트와 현재 유효한 구독을 사용해야 합니다. ‘기기 수 초과’와 같은 안내가 나타나도 사실 표에 기기 수 제한 없음이 명시되어 있으므로 요금제 제한이라고 추측하지 마세요. 먼저 안내가 ZJVPN 사용자 패널, 현재 클라이언트 또는 다른 혼합 설정에서 나온 것인지 확인하세요. 이전 클라이언트, 다른 서비스 설정 또는 로컬 규칙에도 자체 제한 문구가 표시될 수 있습니다. 안내가 표시된 화면과 설정 이름을 보관해야 고객센터가 출처를 판단할 수 있습니다.

여러 기기에서 동시에 구독이 무효화되었다면 계정과 구독 접속 경로를 우선 확인하세요. 한 기기에서만 실패한다면 해당 기기의 캐시, 권한과 클라이언트를 먼저 확인합니다. 플랫폼 간에 설정을 가져올 때 한 플랫폼에서 내보낸 전체 로컬 설정을 그대로 복사하지 마세요. 해당 플랫폼에서만 인식되는 경로, 인터페이스 이름 또는 규칙이 포함될 수 있습니다. 사용자 패널에서 Windows, macOS, iOS, Android 또는 Linux에 맞는 가져오기 방법을 각각 선택하세요.

특정 앱만 프록시를 사용하지 않을 때: 앱별 라우팅 확인

특정 앱만 접속할 수 없고 브라우저와 다른 앱은 정상이라면 전체 라우팅이 고장 난 경우가 보통 아닙니다. 흔한 원인으로는 앱이 시스템 프록시를 우회하거나, 라우팅 규칙이 도메인을 직접 연결 경로로 보내거나, 앱이 독립 DNS를 사용하거나, 기존 연결이 다시 만들어지지 않았거나, 대상 서비스가 계정과 지역을 기준으로 추가 판단을 하는 경우가 있습니다. 계속 계정이나 라우팅을 바꾸기보다 해당 앱이 실제로 어떤 경로를 사용하는지 확인하는 것이 핵심입니다.

먼저 브라우저로 비교하기

해당 앱의 공식 웹사이트나 같은 서비스의 웹 접속 경로를 찾아 현재 라우팅에서 브라우저로 접속하세요. 웹은 정상인데 앱만 이상하다면 기본 라우팅과 대상 도메인에 최소한 일부 접근이 가능하다는 뜻이므로 앱 자체를 확인해야 합니다. 웹과 앱 모두 이상하면 대상 지역, 라우팅, DNS 또는 서비스 상태가 관련되었을 가능성이 큽니다. 앱에 웹 접속 경로가 없다면 유사한 네트워크 요청을 비교 대상으로 사용할 수 있지만, 전혀 무관한 웹사이트로 결론을 내리지는 마세요.

앱을 완전히 종료한 뒤 다시 여세요. 많은 앱은 시작할 때 만든 연결을 오래 재사용하므로 라우팅을 바꿔도 즉시 새 연결을 만들지 않습니다. 모바일에서는 홈 화면으로 돌아가는 것만으로 프로세스가 종료되지 않고 백그라운드 세션이 남을 수 있습니다. 다시 연 뒤 로그인 상태와 콘텐츠가 갱신될 때까지 기다리고 오류를 관찰하세요. 앱 재시작 후 복구된다면 연결 캐시 문제이므로 라우팅 규칙을 계속 바꿀 필요가 없습니다.

시스템 프록시, 가상 인터페이스와 앱 우회

시스템 프록시 모드에서는 시스템 프록시 설정을 따르는 앱만 프록시 경로로 들어갑니다. 일부 앱은 네트워크 연결을 직접 만들기 때문에 브라우저는 정상인데 앱은 직접 연결될 수 있습니다. 가상 인터페이스 모드는 일반적으로 더 많은 시스템 트래픽을 포함하지만 제외 규칙, 로컬 네트워크 우회와 앱 허용 목록의 영향을 받을 수 있습니다. 클라이언트에서 전체, 규칙 또는 직접 연결 모드를 제공한다면 진단 중에는 범위가 더 명확한 모드로 잠시 비교한 뒤, 확인이 끝나면 일상 사용에 적합한 규칙 모드로 되돌리세요.

잘못된 규칙을 가리기 위해 전체 모드를 계속 사용하지 마세요. 전체 모드에서는 정상이고 규칙 모드에서만 이상하다면 로그에서 대상 도메인에 어떤 규칙이 적용되었는지 확인하세요. 규칙 세트가 캐시되었거나 업데이트 시간이 달라 새 도메인을 포함하지 않을 수 있고, 콘텐츠 도메인과 로그인 도메인이 서로 다른 라우팅으로 분류되었을 수도 있습니다. 앱은 하나의 주 도메인뿐 아니라 인증, API, 이미지와 미디어 도메인에도 연결하는 경우가 많습니다. 주 도메인만 처리하면 로그인은 되지만 콘텐츠가 로드되지 않을 수 있습니다.

로그로 앱별 라우팅 결과 확인

클라이언트 로그를 연 뒤 이전 내용을 지우고 대상 앱을 실행해 한 번 재현하세요. 재현 시각 전후의 도메인, 연결 결과와 규칙 이름을 찾습니다. 로그가 매우 많다면 하루치 전체를 복사하지 말고 앱 실행 전후의 연속 구간만 보관하세요. 로그에 해당 앱의 요청이 전혀 없다면 앱이 현재 프록시 방식을 우회했거나 로그 수준에서 트래픽을 기록하지 않는 것일 수 있습니다. 요청이 있지만 직접 연결로 표시되면 규칙을 확인하고, 라우팅에 진입한 뒤 시간 초과가 발생한다면 다른 라우팅과 대상 지역을 비교하세요.

time: "REPRODUCE_TIME"
application: "TARGET_APP"
route: "RULE_OR_DIRECT"
result: "COPY_THE_VISIBLE_ERROR"

위 텍스트는 기록을 정리하기 위한 템플릿일 뿐 클라이언트에 가져올 설정이 아닙니다. 인터넷에 흩어진 규칙을 보고 범위가 넓은 일치 규칙을 바로 추가하지 마세요. 지나치게 넓은 도메인 접미사나 프로세스 규칙은 관련 없는 앱까지 다른 경로로 보낼 수 있습니다. 수정 전에는 기존 규칙을 저장하고, 수정 후에는 대상 앱만 테스트하면서 일반 웹페이지, 로컬 네트워크 서비스와 다른 주요 앱에 영향이 없는지 확인하세요.

계정 지역, 캐시와 대상 제한

일부 콘텐츠 서비스는 현재 네트워크 지역뿐 아니라 계정 지역, 결제 지역, 앱 스토어 지역과 과거 캐시도 참고합니다. 라우팅을 바꾼 뒤에도 기존 콘텐츠가 표시된다고 해서 반드시 앱별 라우팅이 실패한 것은 아닙니다. 먼저 계정과 앱을 완전히 종료하고 적절한 캐시를 정리한 뒤 대상 지역과 일치하는 라우팅으로 테스트하세요. 스트리밍과 관련된 경우 스트리밍 페이지에서 지역과 화질 판단 방법을 확인할 수 있습니다. AI 도구와 관련된 경우 AI 도구 접속 안내를 참고하세요.

앱에 내장된 웹페이지는 열리지만 미디어, 업로드 또는 실시간 기능이 실패한다면 기능마다 다른 도메인이나 전송 방식을 사용할 수 있습니다. 로그인, 목록 로드, 이미지, 재생, 업로드 또는 실시간 연결 중 어느 단계에서 실패하는지 각각 기록하세요. 앱 이름만 적지 마세요. 고객센터는 구체적인 단계를 확인해야 라우팅 로그와 규칙을 기준으로 원인을 찾을 수 있으며, 단순히 캐시를 지우라는 안내를 반복하지 않게 됩니다.

플랫폼 권한과 로컬 네트워크 예외

Android의 앱별 프록시, iOS의 시스템 네트워크 확장, macOS의 네트워크 필터와 Windows의 방화벽 규칙은 특정 프로그램에만 영향을 줄 수 있습니다. 대상 앱이 제외되어 있는지, 특정 유형의 네트워크에서만 접근하도록 허용되어 있는지, 보안 소프트웨어에 별도 규칙이 설정되어 있는지 확인하세요. Linux 사용자는 컨테이너, 샌드박스와 네임스페이스도 살펴봐야 합니다. 격리 환경에서 실행되는 앱은 호스트 시스템의 기본 프록시를 사용하지 않을 수 있습니다.

로컬 네트워크 앱은 일반적으로 직접 연결을 유지해야 합니다. 예를 들어 로컬 저장 장치나 프린터에 접근할 때가 그렇습니다. 특정 인터넷 앱을 해결하려고 모든 로컬 트래픽을 라우팅으로 강제하면 로컬 네트워크 서비스가 작동하지 않을 수 있습니다. 규칙을 수정할 때는 대상 도메인과 로컬 주소를 명확히 구분하세요. 복구 후에는 대상 앱과 로컬 네트워크를 함께 확인해 하나의 문제를 해결하면서 새로운 경로 충돌을 만들지 않았는지 검증합니다.

고객센터에 문의할 시점과 접수 내용

자가 점검의 목적은 사용자가 모든 문제를 혼자 해결하게 하는 것이 아니라, 빠르게 확인할 수 있는 로컬 요인을 배제하고 고객센터에 재현 조건을 제공하는 것입니다. 계정, 주문 또는 구독 접속 경로에 문제가 있거나 기본 비교를 마친 뒤에도 문제가 안정적으로 재현된다면 문의를 접수하세요. 유효한 문의는 기술 원인을 추측하지 않고 사실, 시간 순서와 비교 결과를 설명해야 합니다. ‘서버가 고장 났다’고만 적으면 원인을 찾기 어렵습니다. 특정 플랫폼, 라우팅, 접속 네트워크와 대상에서 어떤 동작 후 어떤 오류가 발생했는지 적으면 처리 효율이 크게 높아집니다.

바로 문의를 접수해도 되는 경우

사용자 패널에 정상적으로 적용된 요금제가 표시되지 않거나, 주문 상태와 결제 기록이 일치하지 않거나, 구독 접속 경로에서 명확한 인증 오류가 반환되거나, 사용자 이름과 비밀번호가 정확한데도 계정 절차에 문제가 있다면 바로 문의를 접수하세요. 결제 수단은 Alipay, WeChat Pay와 USDT만 지원합니다. 결제 관련 문의에는 패널의 주문 정보와 상태 스크린샷을 제공하되, 결제 비밀번호, 개인 키, 시드 문구 또는 전체 결제 자격 증명은 보내지 마세요. 요금제를 확인해야 한다면 먼저 요금제 페이지의 월간 구독과 트래픽 패키지 안내를 참고하세요.

연결 문제의 경우 연결을 끊은 상태에서는 일반 웹페이지에 접속되고, 시스템 시간과 권한이 정상이며, 깨끗한 구독을 다시 가져온 뒤에도 라우팅과 접속 네트워크를 바꾸면 같은 오류가 발생한다면 문의하기에 적합합니다. 특정 라우팅 그룹에서 여러 네트워크를 사용해도 같은 이상이 안정적으로 재현되고 다른 라우팅은 정상이라면 정상 라우팅을 비교 대상으로 적으세요. 속도 문제라면 최소한 정상과 이상 시간대, 대상 유형과 선택한 라우팅을 제공해야 하며 재현할 수 없는 스크린샷 한 장만 보내지 마세요.

특정 앱과 관련된 경우 먼저 브라우저 비교와 앱 재시작을 완료하세요. 로그에 요청이 라우팅으로 들어간 것으로 표시되고 라우팅을 바꿔도 같은 단계에서 실패한다면 대상 앱, 실패한 기능, 대상 지역과 비식별화한 로그를 제출할 수 있습니다. 로그에 요청이 전혀 없다면 로컬 앱별 라우팅이나 프록시 적용 범위 문제일 가능성이 높으므로 클라이언트 모드와 앱 제외 여부도 함께 설명하세요.

문의 정보 체크리스트

다음 템플릿으로 문의 본문을 작성할 수 있습니다. 템플릿의 대문자 부분은 자신의 설명으로 바꾸되, 사용자 이름과 비밀번호, 전체 구독 주소 또는 기타 민감한 자격 증명은 입력하지 마세요:

문제 유형: CONNECT / DNS / SPEED / SUBSCRIPTION / APP
사용 플랫폼: PLATFORM
클라이언트: CLIENT_NAME
선택한 라우팅: ROUTE_NAME
발생 시간: REPRODUCE_TIME
문제 증상: VISIBLE_ERROR_AND_FAILED_STEP
연결 해제 상태: NORMAL_OR_ABNORMAL
라우팅 변경 결과: CONTROL_RESULT
네트워크 변경 결과: CONTROL_RESULT
이미 시도한 조치: ACTIONS_ALREADY_TAKEN
첨부 파일: REDACTED_SCREENSHOT_AND_LOG

로그 비식별화 방법

제출 전에 로그에서 구독 주소, token, 사용자 이름, 비밀번호, QR 코드 내용과 로컬 파일 경로를 검색하세요. 구독 주소는 전체를 삭제하거나 ‘숨김 처리됨’으로 바꾸고 끝부분만 가리지 마세요. 앞부분에도 계정 정보가 포함될 수 있습니다. 공인 주소를 가릴지는 문제 유형에 따라 판단하면 됩니다. 확실하지 않다면 문의에 비식별화했음을 적고, 고객센터가 필요한 최소 정보를 안내하도록 하세요. 스크린샷에서는 브라우저 탭, 알림 영역, 클립보드 팝업과 다른 앱 창도 확인해야 합니다.

로그에는 문맥이 남아 있어야 합니다. ‘연결 실패’ 한 줄만 복사하면 원인을 판단하기 어려우므로 연결 시작, 라우팅 선택, 핸드셰이크, 라우팅 또는 DNS 설정부터 실패까지의 연속 과정을 포함하세요. 문제와 무관한 장기간 로그도 업로드하지 마세요. 내용이 너무 많으면 핵심 이벤트가 묻힙니다. 재현하기 전에 로그를 지우고 한 번의 전체 작업을 수행한 뒤 실패 즉시 멈추고 내보내는 것이 가장 좋습니다.

고객센터 답변 후 검증 방법

처리 안내를 받은 뒤에도 한 번에 한 가지 조치만 실행하세요. 구독을 다시 가져오라는 안내라면 기존 설정을 보관한 뒤 깨끗한 설정을 새로 만들어 테스트합니다. 라우팅을 바꾸라는 안내라면 네트워크와 대상을 유지하세요. 앱별 라우팅을 조정하라는 안내라면 현재 규칙을 먼저 저장하세요. 복구한 뒤에는 원래 실패 조건을 반대로 검증해 문제가 실제로 사라졌는지, 단순히 대상 서비스가 잠시 정상화된 것인지 확인합니다. 검증 결과는 기존 문의에 답변으로 남겨 내용이 같은 문의를 여러 개 만들어 문맥이 분산되지 않도록 하세요.

안내가 효과가 없었다면 실행 결과, 시각과 새 로그를 바로 추가하세요. 전체 배경 설명을 반복해 제출할 필요는 없습니다. 문제가 완전히 연결되지 않는 상태에서 연결은 되지만 DNS에 이상이 있는 상태로 바뀌는 등 조건이 변했다면 증상이 달라졌음을 명확히 적고 해당 장으로 이동해 기본 비교를 다시 진행하세요. 장애가 변화한 과정 자체가 중요한 단서입니다.

점검 종료 후 설정 정리

문제가 해결되면 테스트 중 만든 무효 설정을 삭제하고 필요한 자동 연결과 앱별 라우팅 규칙을 복원한 뒤 시스템 프록시, DNS와 로컬 네트워크 접근이 예상한 상태인지 확인하세요. 깨끗한 구독 설정을 기준선으로 한 부 보관하되 구독 본문을 공개 클라우드 문서나 채팅방에 저장하지 마세요. 여러 기기에서 사용할 때는 Windows, macOS, iOS, Android와 Linux에 충돌 구성 요소가 남아 있지 않은지 각각 확인하세요.

이번 문제가 잘못된 설정과 관련 있었다면 최종적으로 유효했던 설정 이름, 처리 단계와 유발 조건을 개인 유지 관리 기록에 적어 둘 수 있습니다. 다음에 비슷한 증상이 나타나면 모든 단계를 기계적으로 반복하지 말고 같은 유발 조건인지 먼저 확인하세요. 장기 사용자에게는 출처가 불분명한 온라인 안내를 많이 저장하는 것보다 짧고 정확하며 검증된 개인 기록이 더 신뢰할 만합니다.