VPN 문제 해결 가이드

전혀 연결되지 않을 때: 문제가 멈춘 단계를 먼저 확인하세요

“연결 실패”는 결과일 뿐 원인이 아닙니다. 클라이언트가 구독 정보를 읽는지, 회선을 선택할 수 있는지, 터널을 만들 수 있는지, 터널이 만들어진 뒤 데이터가 전송되는지를 확인해야 합니다. 먼저 연결 버튼을 누르기 전과 후 중 언제 실패하는지 살펴보세요. 회선 목록이 비어 있거나 구독 이름이 사라졌거나 클라이언트에 구성을 사용할 수 없다는 안내가 표시된다면 문제는 아직 구성 입력 단계에 있습니다. 회선은 보이지만 계속 연결 중이라면 현재 네트워크, 시스템 권한, 선택한 회선을 확인하세요. 연결됨으로 표시되지만 트래픽이 없다면 다음 장으로 이동해 출구와 DNS를 점검하세요.

변경을 최소화하는 것부터 시작하세요. 클라이언트를 완전히 종료한 뒤 다시 엽니다. 여기서 종료란 트레이로 숨기거나 백그라운드로 전환하는 것이 아니라 클라이언트 프로세스를 끝내 가상 네트워크 인터페이스와 시스템 프록시 상태를 다시 초기화하는 것입니다. 이후 네트워크는 그대로 유지하고 같은 지역의 다른 회선으로 바꿔 보세요. 그래도 실패하면 다른 지역으로 변경합니다. 이 순서를 따르면 특정 회선 문제와 로컬 환경 문제를 구분할 수 있습니다. 64VPN은 90+개 국가 / 200+개 회선을 제공하므로 한 지역에만 계속 몰릴 필요는 없지만, 회선은 용도와 네트워크 경로를 기준으로 선택해야 합니다. 지역별 안내는 서버 페이지에서 확인할 수 있습니다.

로컬 네트워크의 기본 연결 상태 확인

VPN 연결을 끊은 뒤 평소 안정적으로 열리는 웹사이트에 먼저 접속하세요. 일반 네트워크도 열리지 않는다면 클라이언트를 계속 조정할 의미가 없으므로 라우터, 무선 네트워크 또는 유선 네트워크부터 복구해야 합니다. 일반 웹페이지가 정상이라면 시스템 날짜와 시간이 자동 동기화로 설정되어 있는지도 확인하세요. 인증서 검증에는 정확한 시간이 필요하므로 시간이 크게 어긋나면 클라이언트가 정상적인 서버 인증서를 유효하지 않은 것으로 판단할 수 있습니다. 오류를 피하려고 인증서 검사를 끄지 마세요. 진단 가능한 시간 또는 네트워크 문제가 더 식별하기 어려운 연결 위험으로 바뀔 수 있습니다.

시스템 프록시, 가상 네트워크 카드 또는 네트워크 필터를 동시에 제어하는 다른 프로그램이 실행 중인지도 확인하세요. 충돌이 항상 명확한 오류로 나타나는 것은 아니며, 연결 버튼이 반복해서 원래 상태로 돌아오는 정도로 보일 수도 있습니다. 클라이언트 하나만 남기고 다른 네트워크 도구, 보안 필터 규칙, 수동 프록시 설정을 잠시 종료한 뒤 다시 연결해 보세요. 정상화되면 기존 프로그램을 하나씩 다시 켜 충돌 원인을 찾습니다. 여러 클라이언트를 부팅 시 네트워크를 제어하도록 설정하지 마세요. 시작 순서에 따라 문제가 다르게 나타날 수 있습니다.

권한·회선·네트워크 제한 구분

Windows와 macOS에서는 가상 네트워크 인터페이스를 만들거나 활성화해야 할 수 있으며, 모바일 운영체제에서는 VPN 구성 생성 권한 안내가 표시됩니다. 이전에 권한을 거부했다면 클라이언트 화면은 정상이어도 터널을 실제로 만들 수 없습니다. 이 경우 시스템 네트워크 설정에서 해당 구성이 존재하는지 확인한 뒤 클라이언트에서 다시 시도하세요. Linux에서는 실행 방식이 네트워크 인터페이스 생성을 허용하는지, 연결 직후 서비스 프로세스가 종료되지 않는지 확인해야 합니다. 시스템 디렉터리 권한을 임의로 바꾸지 말고, 먼저 클라이언트 로그에서 “permission”, “interface”, “route”와 같은 안내를 찾은 뒤 해당 대상만 처리하세요.

네트워크를 바꾼 뒤 연결된다면 기존 네트워크가 중요한 단서입니다. 이때 클라이언트를 반복해서 재설치하기보다 라우터에 오래된 DNS, 수동 프록시 또는 필터 설정이 남아 있는지 확인하고 네트워크 설정을 다시 받도록 하세요. 네트워크와 지역을 바꾸고 클라이언트를 재시작해도 모두 실패한다면 실패 시 전체 안내와 로그의 시간 범위를 저장해 문서 마지막의 문의 목록에 따라 제출하세요. 로그는 연결 버튼을 누른 시점부터 오류가 나타날 때까지의 전체 과정을 포함해야 하며 마지막 한 줄만 남겨서는 안 됩니다.

연결되지만 웹페이지가 열리지 않을 때: 출구·DNS·브라우저 문제 분리

클라이언트에 “연결됨”이라고 표시되는 것은 제어 절차가 완료되었다는 뜻일 뿐, 모든 앱의 트래픽이 예상대로 기기를 빠져나간다는 의미는 아닙니다. 이런 문제는 출구, 도메인 조회, 앱 접속 순서로 확인하세요. 먼저 브라우저 데이터를 삭제하지 마세요. 캐시 때문에 모든 웹사이트가 동시에 작동하지 않는 경우는 드뭅니다. 새 창을 열어 도메인 접속과 기본 네트워크 요청을 각각 테스트하고, 문제가 전체적으로 발생하는지, 특정 유형의 도메인에만 영향을 주는지, 특정 브라우저에서만 나타나는지 확인하는 편이 효과적입니다.

먼저 연결 전후 출구가 바뀌었는지 확인하세요. 출구 IP와 DNS 확인 방법에 따라 검증할 수 있습니다. 연결 상태는 바뀌었지만 출구가 그대로라면 시스템 트래픽이 터널로 들어가지 않은 것이므로 전체 모드, 시스템 프록시 스위치, 라우팅 규칙을 확인하세요. 출구는 바뀌었는데 도메인만 열리지 않는다면 DNS를 우선 의심할 수 있습니다. 도메인은 조회되지만 브라우저에 연결 재설정 또는 인증서 오류가 표시된다면 브라우저 확장 프로그램, 시스템 시간, 대상 서비스 자체를 계속 확인해야 합니다.

최소한의 명령으로 문제 위치 확인

명령줄은 “모든 것을 고치는” 도구가 아니라 추측을 줄이는 도구입니다. 아래 예시는 공개된 예시 도메인에만 접속하며 실제 구독 정보는 포함하지 않습니다. 실행 후 주소를 얻는지, 요청 연결이 성립하는지, VPN 연결을 끊었을 때 결과가 달라지는지 확인하세요. 운영체제마다 출력 형식이 다르므로 각 줄을 비교할 필요는 없고 성공 여부, 실패 여부, 오류 유형만 기록하면 됩니다.

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

도메인 조회가 실패하고 이미 정상임을 아는 도메인에 직접 접속해도 실패한다면 공용 DNS를 바로 수동 입력하지 마세요. 먼저 클라이언트를 종료하고 시스템 네트워크 설정의 DNS가 자동으로 설정되어 있는지, 과거에 수동 변경된 적이 있는지 확인하세요. 오래된 수동 설정은 회사 네트워크, 가정용 라우터 또는 다른 네트워크 도구에서 남았을 수 있으며 새 주소를 바로 추가하면 원인 구분이 더 어려워집니다. 자동으로 받도록 복원한 뒤 다시 연결하고 클라이언트가 DNS 조회를 제어하는지 확인하세요. 특정 무선 네트워크에서만 문제가 발생한다면 해당 네트워크를 삭제한 뒤 다시 연결하는 것이 여러 단계에 DNS 설정을 계속 추가하는 것보다 깨끗한 상태를 얻기 쉽습니다.

브라우저가 시스템 전체를 대변할 수 있을까요

그렇지 않습니다. 브라우저는 자체 보안 DNS, 프록시 확장 프로그램, 별도의 네트워크 캐시를 사용할 수 있지만 다른 앱은 시스템 DNS를 사용할 수 있습니다. 한 브라우저만 열리지 않고 다른 브라우저가 정상이라면 터널 자체는 대체로 작동하므로 문제가 있는 브라우저의 확장 프로그램과 네트워크 설정을 확인하세요. 먼저 확장 프로그램이 없는 환경에서 테스트한 뒤 브라우저 내부에 별도로 설정된 프록시를 끄세요. 모든 브라우저가 실패하지만 명령줄 요청이 성공한다면 브라우저 계층 문제일 가능성이 높고, 명령줄과 브라우저가 함께 실패하면 시스템 라우팅과 DNS를 계속 확인하세요.

“일부 웹사이트는 열리지만 일부는 열리지 않는” 경우도 주의해야 합니다. 이것이 자동으로 DNS 오류를 뜻하지는 않습니다. 대상 웹사이트가 지역, 계정 상태, 브라우저 세션 또는 캐시에 남은 이전 지역 정보를 확인할 수 있습니다. 점검할 때는 먼저 같은 대상 지역의 다른 회선으로 바꾸고 새 브라우저 세션에서 테스트하세요. 여러 지역을 자주 오간 뒤 같은 로그인 세션을 계속 사용하면 사이트에 저장된 지역 정보가 판단을 방해할 수 있습니다. 스트리밍 이용 시에는 시청 차단 해제 페이지에서 지역과 회선 선택을 확인하고, 연결 버튼 색상만 보지 마세요.

네트워크 설정을 새로 받은 뒤에도 조회 오류가 계속되면 실패한 도메인, 모든 앱에 영향을 주는지 여부, 연결 전후 출구 변화, 한 번의 조회 결과를 기록하세요. 문의할 때 “웹페이지가 열리지 않는다”라고만 쓰면 출구 미전환, DNS 실패, 대상 서비스 제한, 브라우저 확장 프로그램 충돌을 구분할 수 없습니다. “출구는 바뀌었고 명령줄 조회는 실패했으며 네트워크를 바꾸자 복구됐다”처럼 관찰 결과를 정확히 적으면 추가 확인을 크게 줄일 수 있습니다.

속도 저하와 피크 시간대 끊김: 변수를 통제한 뒤 회선 판단

속도 문제는 한 번의 속도 측정으로 가장 쉽게 잘못 판단할 수 있습니다. 측정 결과는 로컬 인터넷, 무선 신호, 기기 부하, 대상 서버, 국제 경로, 선택한 회선의 영향을 동시에 받습니다. 목표는 보기 좋은 숫자가 아니라 병목이 연결 전인지, 로컬 무선인지, 특정 회선인지, 특정 대상 서비스인지 확인하는 것입니다. 먼저 VPN을 끊었을 때 일반 네트워크가 안정적인지 확인한 뒤, 같은 기기·같은 네트워크·같은 측정 대상을 사용해 연결 후와 비교하세요. 테스트 대상까지 매번 바뀌면 결과를 비교할 수 없습니다.

먼저 로컬 연결을 확인하세요. 무선 신호가 약하거나 라우터가 바쁘거나 기기에서 파일을 동기화 중이면 어떤 회선도 느리게 느껴집니다. 대용량 동기화, 시스템 업데이트, 네트워크를 계속 사용하는 작업을 일시 중지한 뒤 무선 액세스 포인트 가까이 이동하거나 안정적인 유선 네트워크를 사용하세요. VPN을 끊어도 속도가 같은 방식으로 흔들리면 로컬 네트워크를 먼저 처리해야 합니다. 기본 네트워크가 안정적인데 연결 후 특정 지역만 눈에 띄게 느리다면 같은 지역의 다른 회선을 비교하세요. 완전히 다른 지역으로 바로 바꾸면 물리적 경로와 대상 지역이 함께 달라져 개선 원인을 알기 어렵습니다.

피크 시간대 문제의 핵심은 동일한 조건으로 반복하는 것입니다

“낮에는 빠르고 밤에는 느린” 현상은 로컬 통신사의 국제 출구 혼잡, 가정 네트워크의 동시 사용, 특정 시간대에 특정 국제 경로가 과부하된 결과일 수 있습니다. 문제가 발생한 시점에 VPN을 끊은 기본 네트워크를 먼저 측정한 다음 현재 회선, 같은 지역의 다른 회선을 차례로 테스트하세요. 기본 네트워크도 함께 느려졌다면 로컬 접속이 중요한 요인입니다. 기본 네트워크는 안정적인데 현재 회선만 느려지고 같은 지역의 다른 회선은 정상이라면 해당 회선을 잠시 피하세요. 여러 지역이 동시에 느려진다면 측정 시간, 네트워크 유형, 대상 서비스를 기록해 상위 경로를 추가로 판단할 수 있게 하세요.

지연 시간과 다운로드 속도를 같은 개념으로 보지 마세요. 지연 시간은 요청 왕복의 대기감을 나타내며 웹페이지 열기, 소용량 파일 요청, 인터랙티브 앱에 더 민감합니다. 지속적인 다운로드와 동영상 버퍼링은 안정적인 처리량이 더 중요합니다. 먼 지역은 대역폭이 충분해도 상호작용이 느리게 느껴질 수 있습니다. 회선을 선택할 때는 지역 이름이나 한 번의 최고 수치만 보지 말고 대상 서비스가 있는 지역에 가깝고 경로가 비교적 직접적인 회선을 우선하세요. 서버 페이지에서 지역과 회선 정보를 제공하므로 회선 목록에서 용도에 맞게 필터링할 수 있습니다.

앱 유형별로 관찰하고 하나의 결과로 전체를 판단하지 마세요

웹페이지가 느리다면 첫 화면 대기 시간과 이후 리소스가 계속 로드되는지를 확인하세요. 동영상 끊김은 재생 시작이 느린지, 화질이 낮아지는지, 일정 시간 후 버퍼링하는지를 구분해야 합니다. 파일 전송은 속도가 지속적으로 안정적인지 보고, 인터랙티브 앱은 반응 속도가 갑자기 빨라지거나 느려지는지 확인하세요. 같은 회선도 대상 서비스에 따라 결과가 다를 수 있습니다. 출구와 대상 서비스 사이에는 별도의 경로가 있기 때문입니다. 한 웹사이트만 느리면 브라우저와 같은 지역의 회선을 바꿔 확인하고, 모든 앱이 느리면 로컬 네트워크, 클라이언트 모드, 기기 부하를 점검하세요.

문제가 계속되면 속도 측정 화면 한 장만 기록해서는 부족합니다. 더 유용한 정보는 연결을 끊었을 때 정상인지, 영향을 받은 앱, 선택한 지역, 특정 시간대에 집중되는지, 같은 지역 회선으로 바꾼 뒤의 변화, 무선 또는 유선 네트워크 사용 여부입니다. 짧은 순간의 최고 수치를 장기 상태로 보지 말고, 여러 네트워크를 연속으로 바꾼 뒤 결과를 섞지도 마세요. 지원이 필요할 때는 같은 조건의 비교 과정을 첨부해야 다른 회선을 추천할지, 계정 트래픽 상태를 확인할지, 로컬 네트워크를 계속 진단할지 판단할 수 있습니다.

요금제 트래픽도 점검 대상에 포함하세요. 월간 구독은 ¥9.9/월 60GB 포함, ¥18/월 250GB 포함, ¥28/월 500GB 포함이며, 트래픽은 개통일을 기준으로 매월 초기화되고 중도 업그레이드 차액은 남은 일수로 환산됩니다. 클라이언트가 연결된 상태에서도 전송 문제가 계속되면 사용자 패널에서 현재 요금제와 트래픽 상태를 확인하세요. 트래픽 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 소진 시까지 사용하고 영구적으로 만료되지 않습니다. 전체 규칙은 요금제 페이지에서 확인하세요. 속도 변화만으로 트래픽 상태를 추정하지 마세요.

잦은 연결 끊김과 모바일 백그라운드 연결 종료: 세션 중단과 시스템 종료 구분

잦은 연결 끊김은 먼저 두 현상을 구분해야 합니다. 클라이언트가 직접 연결 해제를 표시하는지, 앱을 백그라운드에서 다시 열었을 때 트래픽이 더 이상 터널을 통과하지 않는지 확인하세요. 전자는 네트워크 전환, 회선 세션, 가상 인터페이스, 클라이언트 프로세스와 관련된 경우가 많고, 후자는 모바일 운영체제에서 더 흔하며 절전 정책, 백그라운드 활동 제한, 무선 네트워크 절전으로 발생할 수 있습니다. 두 문제의 해결 경로는 다르므로 연결 버튼을 반복해서 누르는 것만으로는 해결되지 않습니다.

먼저 연결이 끊기는 조건을 관찰하세요. 기기가 무선 네트워크에서 다른 네트워크로 전환한 직후 끊긴다면 기존 세션이 새 네트워크로 바로 이전되지 않아 클라이언트가 연결을 다시 만들어야 하는 것입니다. 이것이 회선이 계속 비정상이라는 뜻은 아닙니다. 네트워크 변화가 없고 기기를 전면에서 사용 중인데 일정한 작업 후 끊긴다면 클라이언트 로그에서 연결 끊김 직전의 첫 오류를 확인하세요. 화면을 잠근 뒤에만 끊긴다면 잠금 해제 후 다시 연결하고, 모든 회선을 먼저 바꾸기보다 시스템 백그라운드 권한과 절전 정책을 우선 확인하세요.

데스크톱 시스템의 지속적인 연결 끊김 점검

데스크톱에서는 먼저 절전과 네트워크 어댑터 절전 설정의 영향을 끄고, 기기를 깨어 있는 상태로 유지해 비교하세요. 깨어 있는 동안 안정적이라면 시스템 전원 상태와 관련된 문제입니다. 전면에서 계속 사용해도 끊긴다면 여러 네트워크 제어 프로그램이 동시에 실행 중인지 확인하세요. 시스템이 절전에서 복귀하면 가상 인터페이스가 계속 존재하는 것처럼 보여도 하위 네트워크 주소는 바뀌었을 수 있습니다. 이때는 웹페이지를 새로 고치는 것보다 완전히 연결을 끊었다가 다시 연결하는 편이 효과적입니다. 매번 깨어난 뒤 수동으로 처리해야 한다면 네트워크 복구 후 클라이언트 자동 재연결을 허용하는지 확인하세요.

라우터가 주기적으로 네트워크 설정을 다시 할당하는 경우도 배제해야 합니다. 같은 네트워크의 다른 기기도 비슷한 시각에 잠시 끊긴다면 로컬 네트워크 문제일 가능성이 높습니다. 잠시 다른 네트워크로 바꾸고 같은 회선으로 테스트하세요. 네트워크를 바꾼 뒤 안정된다면 클라이언트를 재설치할 필요가 없습니다. 두 네트워크 모두 전면 사용 중 끊길 때에만 다른 회선과 클라이언트 로그를 비교하세요. 점검 중 라우터 재부팅, 회선 변경, 클라이언트 재설치를 동시에 하지 마세요. 복구되더라도 어떤 단계가 효과를 냈는지 알 수 없습니다.

모바일 백그라운드 유지 점검 순서

모바일 운영체제는 배터리, 메모리, 백그라운드 정책에 따라 앱을 관리합니다. 먼저 클라이언트의 백그라운드 활동을 허용하고, 엄격한 절전 제한 대상이 아니며, 시스템이 VPN 구성을 유지하도록 설정되어 있는지 확인하세요. 그런 다음 회선에 연결하고 앱을 전면에 둔 채 기본 안정성을 확인한 뒤 화면을 잠갔다가 돌아와 테스트합니다. 전면에서는 안정적이고 잠근 뒤 끊긴다면 백그라운드 관리가 원인입니다. 전면에서도 끊긴다면 회선 또는 네트워크 단계로 돌아가세요. 시스템마다 메뉴 이름은 다를 수 있으므로 “배터리”, “백그라운드 활동”, “VPN”, “항상 연결 유지”와 같은 분류로 찾고 특정 메뉴 경로에 의존하지 마세요.

끊긴 뒤 클라이언트에는 계속 연결 중으로 표시되지만 출구가 로컬 네트워크로 돌아왔다면 먼저 수동으로 연결을 끊고 시스템이 기존 인터페이스를 해제할 때까지 기다린 뒤 다시 연결하세요. 실패한 세션을 여러 개 겹치게 두지 마세요. 다시 연결한 뒤 짧은 시간 안에 같은 상태가 나타나면 출구 확인 결과와 로그를 저장하세요. 로그에 회선 이름이나 로컬 인터페이스 정보가 포함될 수 있으므로 제출 전에 진단과 무관한 개인 파일 경로는 가려도 되지만 오류 전후의 맥락은 잘라내지 마세요.

모바일에서는 클라이언트가 시스템에 의해 종료된 것인지, 화면을 잠근 뒤 무선 네트워크 자체가 절전 상태가 된 것인지도 구분해야 합니다. 같은 기기에서 네트워크를 바꿔 재테스트하거나, 같은 네트워크에서 다른 기기를 사용해 관찰할 수 있습니다. 64VPN은 Windows / macOS / iOS / Android / Linux를 지원하며 기기 수 제한이 없으므로 교차 검증을 위해 다른 기기를 먼저 삭제할 필요가 없습니다. 교차 검증의 목적은 여러 기기에서 장기간 동시에 테스트하는 것이 아니라 문제가 기기, 네트워크, 특정 회선을 따라가는지 확인하는 것입니다. 특정 기기에서만 문제가 발생한다면 문의에 운영체제 유형과 백그라운드 설정 상태를 명시하세요.

구독 업데이트 실패: 주소·인증·캐시·구성 파싱 확인

구독 업데이트 실패와 회선 연결 실패는 같은 단계의 문제가 아닙니다. 구독은 사용 가능한 구성을 클라이언트에 전달하며, 구독이 아직 정상적으로 불러와지지 않았다면 회선을 반복해서 바꿔도 의미가 없습니다. 먼저 클라이언트 안내가 네트워크 요청 실패, 인증 실패, 내용 없음, 구성 파싱 실패 중 어디에 해당하는지 확인하세요. 네트워크 요청 실패는 현재 네트워크와 주소 접근성을 확인해야 하고, 인증 실패는 올바른 계정으로 로그인했는지와 구독이 유효한지 확인해야 합니다. 내용이 비어 있으면 계정 상태를 확인하고, 파싱 실패라면 복사 누락, 클라이언트 유형, 오래된 캐시가 원인일 가능성이 높습니다.

클라이언트와 구독 정보는 사용자 패널에서 받아야 하며 채팅 기록, 스크린샷, 전달받은 오래된 주소를 사용하지 마세요. 패널에 로그인한 뒤 전체 내용을 다시 복사하고, 처음과 끝에 공백, 줄바꿈, 추가 문장 부호가 없는지 확인하세요. 클라이언트가 클립보드 가져오기를 지원한다면 실패한 가져오기 항목을 먼저 삭제한 뒤 다시 붙여 넣습니다. 같은 이름의 구독을 여러 개 남겨 두면 새로 고칠 때 오래된 항목을 잘못 조작하기 쉽습니다. 현재 구독에 구분하기 쉬운 이름을 지정해 패널에서 방금 받은 항목을 업데이트하는지 확인하세요.

명확한 가짜 값으로 구독 주소 구조 이해하기

아래 내용은 주소를 완전한 형태로 유지해야 한다는 점을 설명하기 위한 것이며 실제 구독 주소가 아니고 연결에도 사용할 수 없습니다. 쿼리 매개변수의 값은 인증 정보에 해당하므로 문자가 빠지거나 채팅 앱에서 잘리거나 공백이 섞이면 업데이트가 실패합니다. 실제 주소는 사용자 패널에서만 받아야 하며 공개 문서, 공유 메모, 스크린샷에 적지 마세요.

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

브라우저에서 다른 웹사이트는 열리는데 클라이언트가 구독을 업데이트할 때 요청 실패를 표시한다면 먼저 클라이언트를 종료한 뒤 다시 시도하고 네트워크를 바꿔 확인하세요. 일부 시스템에서는 클라이언트의 업데이트 요청이 오래된 프록시를 사용하고 브라우저는 현재 네트워크를 사용할 수 있으므로 “브라우저 정상”만으로 클라이언트 요청까지 정상이라고 단정할 수 없습니다. 네트워크를 바꾼 뒤 업데이트된다면 기존 네트워크의 수동 프록시와 DNS를 정리하세요. 여러 네트워크에서 모두 실패한다면 패널에서 구독을 다시 복사하고 계정에 요금제와 구독 메뉴가 정상적으로 표시되는지 확인하세요.

오래된 캐시와 파싱 실패 구분

클라이언트는 업데이트가 실패해도 마지막으로 성공한 구성을 보존할 수 있어 이전 회선이 목록에 계속 표시됩니다. 이것만으로 구독 업데이트가 성공했다고 판단하지 마세요. 클라이언트에 표시된 업데이트 시간, 새로 고침 결과, 오류 안내를 확인해 새 내용이 실제로 이전 내용을 대체했는지 검증하세요. 업데이트 후 회선 목록이 바뀌지 않으면 필요한 로컬 규칙을 먼저 내보낸 뒤 기존 구독을 제거하고 다시 가져오세요. 로컬 규칙을 백업했는지 확인하기 전에는 앱 데이터를 모두 삭제하지 마세요. 초기화하면 문제와 무관한 개인 설정도 함께 삭제됩니다.

파싱 실패는 보통 클라이언트가 내용을 받았지만 구성으로 변환하지 못했다는 뜻입니다. 먼저 패널에서 제공하는 해당 클라이언트용 진입점을 사용했는지 확인하고, 한 클라이언트 형식을 다른 클라이언트에 강제로 가져오지 마세요. 이후 클라이언트가 현재 사이트 패널에서 제공하는 출처의 버전인지 확인하세요. 본 프로젝트는 마케팅 페이지에 정적 설치 패키지를 제공하지 않으며, 클라이언트는 로그인 후 패널에서 다운로드해야 합니다. 출처가 불분명하거나 오랫동안 관리되지 않은 클라이언트라면 패널에서 호환 클라이언트를 다시 받아 구독을 가져오세요. 자세한 방법은 빠른 시작을 참고하세요.

계정 페이지가 정상적으로 열리지 않는다면 구독 주소를 타사 도구에 넘겨 테스트하기 전에 기본 네트워크를 먼저 확인하세요. 계정에 접속되고 요금제 상태도 정상인데 다시 복사한 뒤에도 파싱에 실패한다면 문의 시 클라이언트 이름, 운영체제 플랫폼, 오류 원문, 업데이트 동작, 인증 정보가 제거된 주소 구조를 첨부하세요. 지원팀은 보통 전체 인증 매개변수 없이도 요청 단계와 파싱 단계를 판단할 수 있습니다. 계정 확인이 필요하면 사용자 패널의 문의 메뉴를 이용하고 공개 채널에 인증 정보를 보내지 마세요.

가입에는 이메일 주소가 필요하지 않으며 사용자 이름과 비밀번호만으로 가입할 수 있습니다. 따라서 계정을 찾거나 확인할 때는 먼저 올바른 사용자 이름을 사용 중인지 확인하고 비밀번호를 안전하게 보관하세요. 구독 문제를 점검하려고 비슷한 사용자 이름을 여러 개 만들지 마세요. 요금제와 구독의 귀속을 확인하기 어려워집니다. 어느 계정에 요금제가 연결됐는지 알 수 없다면 문의에 결제 방식과 주문 페이지에 표시되는 정보를 제공하세요. 64VPN은 Alipay / WeChat Pay / USDT를 지원하며, 결제 비밀번호나 전체 거래 인증 정보를 첨부해서는 안 됩니다.

특정 앱만 프록시를 사용하지 못할 때: 분할 라우팅부터 앱 자체 네트워크 스택까지

브라우저는 정상인데 특정 앱만 접속하지 못한다면 터널은 대체로 이미 만들어진 상태이며, 앱 분할 라우팅, 시스템 프록시 지원 방식, 앱 캐시, 독립 DNS가 원인일 가능성이 높습니다. 먼저 해당 앱이 완전히 인터넷에 연결되지 않는지, 연결은 되지만 출구가 바뀌지 않는지 확인하세요. 전자는 잘못된 규칙으로 차단되었는지 확인해야 하고, 후자는 시스템 프록시를 우회하거나 독립 네트워크 인터페이스를 사용하거나 현재 모드의 제어 대상이 아닐 수 있습니다.

먼저 시스템 트래픽을 제어할 수 있는 연결 모드로 바꿔 비교하되 불필요한 전체 설정을 장기간 유지하지 마세요. 전체 제어 후 앱이 복구되면 문제는 분할 라우팅 규칙에 있으므로 해당 앱의 도메인, 프로세스, 대상 주소가 잘못 직접 연결로 분류되지 않았는지 확인하세요. 전체 제어 후에도 변화가 없다면 앱 자체 프록시 설정을 확인합니다. 일부 개발 도구, 다운로드 도구, 브라우저는 앱 내부에 프록시 주소를 저장하며 시스템 설정을 바꿔도 이전 값을 계속 사용할 수 있습니다. 먼저 앱을 시스템 설정을 따르도록 복원한 뒤 다시 시작하세요.

프로세스·도메인·연결 시점별로 단계적으로 확인

분할 라우팅 규칙은 도메인, 대상 주소, 프로세스를 기준으로 식별할 수 있습니다. 앱이 시작될 때 이미 장시간 연결을 만들었다면 이후 VPN을 전환해도 기존 연결이 이전 경로를 계속 사용할 수 있습니다. 테스트할 때는 앱을 완전히 종료하고 VPN 연결을 만든 뒤 다시 시작하세요. 창만 닫았다가 여는 것으로는 부족합니다. 백그라운드 서비스가 있는 앱이라면 백그라운드 프로세스도 종료됐는지 확인하세요. 새로 만들어진 연결만 현재 라우팅을 정확하게 반영합니다.

앱이 여러 도메인에 의존한다면 기본 화면이 열린다고 해서 모든 리소스가 같은 경로를 사용한다는 뜻은 아닙니다. 로그인, 이미지, 파일 다운로드, 실시간 연결이 서로 다른 주소를 사용할 수 있습니다. 이때는 앱을 사용할 수 없다고만 하지 말고 구체적으로 어느 단계에서 실패하는지 기록하세요. 예를 들어 “로그인 페이지는 열리지만 제출 후 시간 초과”와 “시작 후 빈 화면”은 점검 방향이 다릅니다. 전자는 인증 도메인이나 지역 세션, 후자는 리소스 도메인이나 앱 캐시와 관련될 수 있습니다. 네트워크 로그에서 세션 인증 정보가 포함된 전체 요청을 복사하지 말고 도메인, 오류 유형, 시간 범위만 남기세요.

시스템 프록시와 가상 인터페이스의 차이

일부 앱은 시스템 프록시를 읽고, 일부 앱은 직접 네트워크 연결을 만듭니다. 시스템 프록시만 켜면 후자의 트래픽은 터널에 들어가지 않을 수 있으며, 가상 인터페이스로 제어할 때는 적용 범위가 달라집니다. 점검의 목적은 항상 특정 모드를 사용하라는 것이 아니라 모드별 비교로 앱이 현재 연결 방식을 지원하는지 판단하는 것입니다. 시스템 프록시 모드에서 실패하고 가상 인터페이스 모드에서 복구된다면 이 결론을 기록하고 클라이언트 분할 라우팅을 확인하세요. 두 모드 모두 실패하지만 브라우저가 정상이라면 앱 내부 네트워크 설정, 인증서 저장소, 계정 지역을 계속 확인해야 합니다.

AI 도구에서도 브라우저는 되지만 데스크톱 클라이언트는 작동하지 않는 차이가 나타날 수 있습니다. 이때는 먼저 계정과 대상 지역을 확인한 뒤 데스크톱 클라이언트가 시스템 프록시를 따르는지 점검하세요. 웹페이지가 정상이라는 이유만으로 네트워크 계층이 완전히 같다고 판단하지 마세요. AI 가속 페이지에서 지역과 안정적인 연결을 선택하는 원칙을 확인할 수 있습니다. 사용자가 “검열 우회 소프트웨어”를 검색한 뒤 출처가 불분명한 네트워크 도구를 여러 개 설치했다면 시스템 프록시와 가상 인터페이스가 서로 덮어쓰는 일이 흔합니다. 점검할 때는 출처가 명확한 클라이언트 하나만 실행하고 사용자 패널에서 사이트 클라이언트를 받으세요.

앱에 디버그 로그가 있다면 실행부터 오류 발생까지 관련 부분을 추출하세요. 로그에는 대상 도메인, 연결 방식, 오류 유형을 남기고 계정 토큰, Cookie, 로컬 개인 경로는 숨기세요. 문의에는 브라우저가 정상인지, 다른 앱은 정상인지, 전체 제어로 복구되는지, 앱을 재시작하면 결과가 바뀌는지도 함께 적으세요. 이 비교 정보만으로도 분할 라우팅 규칙, 앱 자체 프록시, 대상 서비스 중 어디가 원인인지 빠르게 판단할 수 있어 반복적인 재설치를 요구하지 않아도 됩니다.

계정·트래픽·기기 수 안내: 패널의 사실부터 확인

클라이언트에 요금제를 사용할 수 없음, 트래픽 부족, 인증 이상, 기기 수 초과가 표시되면 사용자 패널의 계정 및 요금제 상태를 기준으로 판단하세요. 타사 클라이언트의 한 줄 안내만으로 서비스 규칙을 추정하지 마세요. 64VPN은 기기 수 제한이 없습니다. 어떤 클라이언트에 “기기 수 초과” 또는 유사한 문구가 표시된다면 사이트의 사실과 맞지 않으므로 클라이언트 로컬 상태, 오래된 구성, 잘못된 계정, 캐시 안내, 인증 오류에서 원인을 찾아야 합니다. 다른 기기를 삭제하며 추측하지 말고 패널과 문의를 통해 확인하세요.

먼저 클라이언트 계정에서 로그아웃한 뒤 요금제를 구매할 때 사용한 사용자 이름으로 로그인했는지 확인하세요. 이메일 주소가 필요하지 않으므로 사용자 이름과 비밀번호만으로 가입할 수 있어 비슷한 사용자 이름이 혼동을 일으키기 쉽습니다. 패널에서 해당 주문, 요금제, 구독 메뉴가 보이는지 확인하세요. 패널에 요금제가 없는데 결제가 완료됐다면 주문 페이지와 결제 채널에 표시되는 거래 정보를 보관하고 문의로 확인하세요. 문의에 결제 비밀번호, 계정 비밀번호, 전체 인증 매개변수를 보내지 마세요.

월간 구독과 트래픽 패키지는 확인 방법이 다릅니다

월간 구독은 ¥9.9/월 60GB 포함, ¥18/월 250GB 포함, ¥28/월 500GB 포함이며, 트래픽은 개통일을 기준으로 매월 초기화되고 중도 업그레이드 차액은 남은 일수로 환산됩니다. 패널에 월간 트래픽을 모두 사용한 것으로 표시되면 개통일 초기화를 기다리거나 현재 요금제를 업그레이드하거나 필요에 따라 트래픽 패키지를 선택하세요. 트래픽을 복구하려고 구독을 반복해서 가져오지 마세요. 업그레이드 후 남은 일수는 차액으로 환산되며 구체적인 결과는 패널 주문 확인 페이지를 기준으로 합니다.

트래픽 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 소진 시까지 사용하고 영구적으로 만료되지 않습니다. 트래픽 패키지는 매월 초기화되지 않으므로 현재 월간 구독을 사용하는지 트래픽 패키지를 사용하는지 확인하세요. 두 상품의 상태 의미는 다르므로 “초기화되지 않음”만으로 오류라고 판단할 수 없습니다. 전체 가격과 적용 상황은 요금제 페이지에서 확인할 수 있으며 결제는 Alipay / WeChat Pay / USDT를 지원합니다.

기기 교차 검증 방법

기기 수 제한이 없으므로 Windows / macOS / iOS / Android / Linux에서 같은 계정을 사용할 수 있지만, 점검 중 여러 기기에서 대용량 작업을 동시에 실행하지는 마세요. 한 기기만 이상하고 다른 기기는 정상이라면 해당 기기의 클라이언트, 시스템 설정, 네트워크 환경을 따라가는 문제일 가능성이 높습니다. 같은 네트워크에서 모든 기기가 이상하면 라우터와 현재 네트워크를 우선 확인하고, 서로 다른 네트워크와 기기에서 같은 계정 안내가 나타나면 계정 및 구독 상태로 범위를 좁히세요.

교차 검증에서는 계정과 회선 지역을 동일하게 유지하고 기기 또는 네트워크 중 하나만 바꾸세요. 먼저 다른 기기를 같은 네트워크에 연결합니다. 원래 기기만 실패하면 원래 기기의 시간, 권한, 오래된 프록시, 구독 캐시를 확인하세요. 두 기기 모두 실패하면 그중 한 기기만 네트워크를 바꿔 보세요. 이렇게 해야 기기와 네트워크를 명확히 비교할 수 있습니다. 기기, 네트워크, 계정, 회선을 동시에 바꾸면 복구되더라도 원인을 찾을 수 없습니다.

새로 결제한 뒤 요금제 상태가 갱신되지 않아도 연속으로 다시 결제하지 마세요. 먼저 패널을 새로 고치고 다시 로그인해 주문 상태를 확인한 뒤 사용자 이름, 결제 방식, 주문 페이지 상태, 인증 정보가 제거된 거래 정보를 문의로 제출하세요. 64VPN은 14일 무조건 환불을 제공하지만 문제 해결과 환불 신청은 별도 절차입니다. 기술 문제는 재현 정보를 먼저 제출하고, 요금제 규칙과 환불 메뉴는 패널 및 약관 페이지를 기준으로 확인하세요.

계정 이상은 브라우저에 오래된 로그인 상태가 저장되어 발생할 수도 있습니다. 먼저 패널에서 로그아웃하고 관련 페이지를 닫은 뒤 올바른 사용자 이름으로 다시 로그인하세요. 여러 브라우저의 표시가 다르면 새 브라우저 세션으로 확인하고, 여러 계정 사이를 오간 뒤 오래된 탭을 계속 사용하지 마세요. 최종 문의에는 “패널에 무엇이 표시되는지, 클라이언트에 무엇이 표시되는지, 다른 기기에서도 같은지”를 명확히 적고 팝업 한 줄만 전달하지 마세요.

지원팀에 문의할 시점: 재현 가능한 문의와 복구 기록 제출

기본 네트워크가 정상이고 같은 지역의 다른 회선으로 바꿔도 해결되지 않으며, 네트워크와 기기를 바꾼 뒤에도 문제가 재현되거나 계정과 주문 상태가 서로 맞지 않는다면 무의미한 재설치를 멈추고 문의를 제출하세요. 좋은 문의의 목표는 스크린샷을 쌓는 것이 아니라 지원팀이 판단 경로를 재현할 수 있도록 하는 것입니다. 가장 중요한 정보는 문제가 어느 단계에서 발생했는지, 어떤 비교를 했는지, 각 비교 결과가 어땠는지, 오류가 발생한 시간 범위입니다.

다음과 같은 경우에는 바로 문의를 제출하는 것이 좋습니다. 여러 네트워크에서 모든 회선이 연결을 만들지 못하는 경우, 패널에서 구독을 다시 받아도 인증 또는 파싱 실패가 계속되는 경우, 패널의 요금제와 완료된 주문이 일치하지 않는 경우, 클라이언트에 “기기 수 제한 없음”이라는 사실과 반대되는 안내가 표시되는 경우, 연결 후 출구가 바뀌지 않고 시스템 프록시·권한·충돌 프로그램을 모두 확인한 경우, 전체 제어와 앱 재시작 후에도 특정 앱의 연결이 만들어지지 않는 경우입니다. 특정 회선 하나가 잠시 실패한 정도라면 같은 지역의 다른 회선으로 바꾸어 관찰하면 되며, 한 번의 우연한 현상을 전체 장애로 설명할 필요는 없습니다.

문의 내용에 포함해야 할 정보

먼저 “Windows 클라이언트가 가정용 무선 네트워크에서 모든 지역에 대해 계속 연결 중으로 표시되지만 다른 네트워크에서는 연결된다”처럼 검증 가능한 증상을 한 문장으로 작성하세요. “사용할 수 없다”라고만 쓰지 마세요. 이어서 운영체제 플랫폼, 클라이언트 출처, 현재 네트워크 유형, 선택한 지역, 문제가 시작되기 전에 시스템 업데이트나 네트워크 전환이 있었는지를 적습니다. 그다음 충돌 프로그램 종료 후 변화 없음, 같은 지역 회선 변경 후 변화 없음, 네트워크 변경 후 복구처럼 이미 수행한 작업과 결과를 나열하세요. 이 정보는 바로 판단 트리를 구성할 수 있습니다.

오류 안내는 원문을 복사하거나 전체 화면을 제공하세요. 스크린샷에는 클라이언트 상태와 오류 맥락이 포함되어야 하지만 사용자 이름 이외의 민감한 계정 정보, 전체 구독 인증 매개변수, 결제 정보, 개인 파일 경로는 가려야 합니다. 로그는 한 번 재현한 시점 전후의 내용만 추출하고 오류 앞뒤의 맥락을 남기세요. 마지막 한 줄만 보내지 마세요. 실제 원인은 뒤따르는 연쇄 오류보다 앞에 나타나는 경우가 많습니다.

증상별로 첨부할 증거

문의에는 아래 구조를 사용할 수 있습니다. 예시 내용은 형식 설명을 위한 것이며 실제 장애를 의미하지 않습니다. 복사한 뒤 자신의 관찰 내용으로 바꾸고 관련 없는 항목은 남기지 마세요.

문제 현상:
사용 플랫폼:
클라이언트 출처: 사용자 패널
현재 네트워크:
선택한 지역:
영향 범위:
완료한 비교 테스트:
오류 원문:
문제 발생 시간 범위:
첨부 파일: 인증 정보가 제거된 스크린샷 또는 관련 로그

복구 후에도 최종 원인을 기록하세요

문제가 복구되면 마지막으로 유효했던 변경과 복구 조건을 기록하세요. 예를 들어 “시스템 DNS를 자동으로 받도록 복원하자 정상화”, “다른 프록시 프로그램을 끄자 정상화”, “같은 지역 회선으로 바꾸자 안정화”, “백그라운드 활동을 허용하자 화면을 잠가도 끊기지 않음”처럼 적습니다. 지금까지 수행한 모든 작업을 해결책으로 묶지 마세요. 되돌리거나 반복 검증한 뒤에도 효과가 확인된 마지막 변경만 참고 가치가 있습니다. 복구 직후 모든 설정을 다시 바꾸면 검증 기회를 잃게 됩니다.

간헐적인 문제라면 짧은 시간 기록을 남길 수 있습니다. 연결 전 네트워크가 정상인지, 문제가 언제 시작됐는지, 절전이나 네트워크 전환이 동반됐는지, 어떤 유형의 앱을 사용했는지, 네트워크와 회선을 바꾼 뒤 결과가 어땠는지를 기록하세요. 이후 다시 발생하면 새 시간 기록을 기존 문의에 추가하는 편이 “또 끊겼다”만 적은 새 문의를 만드는 것보다 비교하기 쉽습니다. 지원팀도 문제가 시간대, 지역, 기기, 계정을 따라가는지 판단할 수 있습니다.

처음 설정을 빠뜨린 문제라면 빠른 시작으로 돌아가 기본 절차를 다시 확인하세요. 지역과 회선 유형을 비교하려면 서버 페이지를 확인하고, 요금제·트래픽 패키지·결제 방식·환불 약정을 확인하려면 요금제 페이지를 확인하세요. 세 페이지와 이 매뉴얼의 역할은 명확합니다. 빠른 시작은 설정 완료, 회선 페이지는 경로 선택, 요금제 페이지는 결제 정보, 이 페이지는 문제를 검증 가능한 단계로 나누는 역할을 합니다.

전체 점검이 조작을 많이 해야 한다는 뜻은 아닙니다. 신뢰할 수 있는 방법은 항상 조건을 유지하고, 한 번에 변수 하나만 바꾸고, 결과를 기록하고, 결과에 따라 다음 단계로 이동하는 것입니다. 전혀 연결되지 않으면 입력 단계와 권한을 먼저 확인하고, 연결 후 웹페이지가 열리지 않으면 출구와 DNS를 확인하세요. 속도 문제는 기본 네트워크 비교부터 하고, 잦은 끊김은 발생 조건을 찾고, 구독 실패는 요청과 파싱을 구분하세요. 특정 앱 문제는 분할 라우팅과 기존 연결을 확인하고, 계정 안내는 패널의 사실을 기준으로 판단하세요. 이렇게 하면 문의가 모호한 설명에서 실행 가능한 진단 자료로 바뀝니다.