TROUBLESHOOTING REFERENCE

VPN 문제 해결 가이드

증상부터 시작해 로컬 네트워크, 클라이언트, 구독, 회선, DNS, 앱별 라우팅을 차례로 확인합니다. 한 번에 하나의 변수만 바꾸고 재현 기록을 남기세요.

  • 120+개 국가 / 170+개 회선
  • 동시 연결 기기 수 제한 없음
  • 30일 무조건 환불
진단 워크벤치 REFERENCE
증상 범위 확인모든 앱인가요, 특정 앱인가요
START
로컬 네트워크 확인연결을 끊은 뒤 기본 접속 점검
LOCAL
구독과 클라이언트 확인설정, 권한, 시스템 시간과 프록시 모드
CLIENT
지역과 회선 유형 전환단일 회선 문제인지 전체 문제인지 구분
ROUTE
재현 자료 정리시간, 플랫폼, 회선, 오류 문구와 로그
TICKET

DIAGNOSIS METHOD

진단 방법: 먼저 문제 범위를 정의하세요

이 페이지는 설치와 구독 가져오기를 완료했지만 연결 결과가 예상과 다를 때 참고하는 체계적인 매뉴얼입니다. 아직 가입, 요금제 선택, 구독 주소 확인 또는 클라이언트 가져오기를 완료하지 않았다면 먼저 빠른 시작에 따라 기본 절차를 진행하세요. 빠른 시작은 연결을 설정하는 과정이고, 이 페이지는 연결이 실패하는 이유와 범위를 좁히는 방법, 지원 담당자에게 문제를 전달해야 하는 시점을 설명합니다. 두 페이지의 역할은 다르므로 클라이언트에 구독을 제대로 가져오기 전에 회선 최적화로 바로 이동하는 것은 권장하지 않습니다.

막연한 설명을 검증 가능한 증상으로 바꾸기

“안 돼요”만으로는 충분히 정확한 진단 정보가 아닙니다. 먼저 클라이언트에 연결 완료로 표시되는지 확인한 다음, 모든 웹사이트가 열리지 않는지 특정 웹사이트나 앱만 문제인지 확인하세요. 이어서 문제가 특정 네트워크, 기기, 회선 또는 시간대에만 발생하는지도 살펴보세요. 연결을 전혀 만들 수 없다면 권한, 로컬 네트워크, 시스템 시간, 구독 유효성, 프로토콜 호환성부터 점검하는 것이 일반적입니다. 연결 성공으로 표시되지만 웹페이지가 열리지 않는다면 시스템 프록시, DNS, 라우팅 규칙과 브라우저 캐시에 주목해야 합니다. 특정 앱 하나만 문제라면 클라이언트를 반복해서 재설치하지 말고 해당 앱이 시스템 프록시를 우회하는지 바로 확인하세요.

진단할 때는 안정적인 기준 환경을 마련해야 합니다. 먼저 진행 중인 대용량 파일 전송, 클라우드 동기화와 시스템 업데이트를 일시 중지하고, 네트워크 경로를 바꿀 수 있는 보안 프로그램, 디버깅 프록시 또는 이전 클라이언트를 종료하세요. 단, 여러 시스템 설정을 동시에 변경하지는 마세요. 하나의 클라이언트, 하나의 회선, 하나의 일반 웹페이지를 기준으로 정한 뒤 작업을 한 단계씩 실행하고 매번 결과를 기록하세요. 회선 변경, 프록시 모드 변경, DNS 교체, 클라이언트 재설치를 한꺼번에 진행하면 정상으로 돌아와도 실제 원인을 알 수 없습니다. 문제가 다시 발생하면 처음부터 다시 점검해야 합니다.

가까운 단계부터 먼 단계 순서로 확인하기

“기기 기본 네트워크 → 클라이언트 상태 → 구독 내용 → 회선 연결 → DNS 확인 → 대상 앱” 순서로 점검하는 것이 좋습니다. 이 순서의 장점은 기기에 가장 가까우면서 검증하기 쉬운 단계부터 우선 배제할 수 있다는 데 있습니다. 가속 연결을 끊은 뒤에도 일반 웹페이지에 접속할 수 없다면 문제는 우선 로컬 네트워크에 있으므로 원격 회선을 계속 바꿀 필요가 없습니다. 클라이언트가 구독 내용을 읽지 못한다면 회선 이름이 완전하게 표시되어도 설정이 유효하다는 뜻은 아닙니다. 기본 네트워크가 정상이고 구독 업데이트가 가능하며 클라이언트가 연결을 만든 뒤에야 대상 서비스의 지역, 회선 유형과 라우팅 규칙을 추가로 판단해야 합니다.

또한 “설정 문제”와 “환경 변화”를 구분해야 합니다. 구독을 방금 가져온 뒤 계속 실패한다면 가져오기 방식, 권한 또는 클라이언트 모드와 관련된 경우가 많습니다. 원래 정상 작동하다가 네트워크를 바꾼 뒤 갑자기 실패했다면 새 네트워크의 제한과 DNS를 먼저 확인하세요. 시스템 업데이트나 다른 네트워크 도구 설치 후 문제가 생겼다면 가상 네트워크 어댑터, 시스템 프록시와 권한 변경을 우선 점검합니다. 저녁에만 느려진다면 계정을 삭제하고 다시 만들 것이 아니라 같은 지역의 서로 다른 회선 유형을 비교해야 합니다. 사용자가 “VPN 연결 안 됨”을 검색할 때 실제로 마주하는 문제도 대부분 이러한 기본 네트워크, 설정 또는 라우팅 문제이므로 검증 가능한 네트워크 단계에 따라 처리해야 합니다.

최소 재현 기록 준비하기

테스트할 때마다 최소한 플랫폼 이름, 클라이언트 상태, 회선 이름, 발생 시간, 네트워크 유형, 접속 실패 대상, 오류 안내 원문과 이미 실행한 작업을 기록하세요. Windows, macOS, iOS, Android, Linux는 권한 모델과 프록시 처리 방식이 다르므로 “PC”나 “모바일”이라고만 쓰면 중요한 맥락이 사라집니다. 오류 안내는 원문을 복사하거나 스크린샷으로 남기고 “오류가 났다”고만 옮겨 적지 마세요. 회선 이름도 지역명만 쓰지 말고 전체를 기록해야 합니다. 같은 지역에 IEPL, 중계와 직결 등 서로 다른 유형이 동시에 존재할 수 있기 때문입니다.

관찰 결과 우선 확인 잠시 하지 말 것
연결을 끊어도 웹페이지에 정상적으로 접속할 수 없음 로컬 네트워크, 게이트웨이, 시스템 네트워크 상태 원격 회선을 계속 전환하기
연결은 성공했지만 도메인이 열리지 않음 DNS, 시스템 프록시, 규칙 모드 계정을 바로 삭제하기
특정 앱 하나만 문제 앱의 프록시 기능, 라우팅과 프로세스 재시작 모든 네트워크 구성 요소 재설치
네트워크를 바꾼 뒤 문제 발생 새 네트워크 제한, 권한과 DNS 캐시 여러 설정을 동시에 변경하기

CONNECTION FAILURE

연결 자체가 안 됨: 시작 조건부터 단계별로 배제하기

“연결 자체가 안 됨”은 클라이언트가 연결 설정 단계에서 실패해 연결 중 상태에 멈추거나 곧바로 연결 해제로 돌아가거나, 핸드셰이크·시간 초과·권한·설정 사용 불가 등의 오류를 바로 표시하는 경우를 말합니다. 이때는 트래픽이 유효한 회선으로 들어가지 않았으므로 웹페이지나 스트리밍부터 논의하지 마세요. 목표는 클라이언트가 사용할 수 있는 설정을 확보했는지, 시스템이 네트워크 제어를 허용하는지, 현재 네트워크가 회선 진입점에 도달할 수 있는지, 선택한 회선만의 문제인지 확인하는 것입니다.

가속 기능 없이 기본 네트워크부터 확인하기

클라이언트를 창만 최소화하지 말고 완전히 종료한 다음, 브라우저로 평소 정상적으로 접속하는 일반 웹페이지를 열어 보세요. 일반 웹페이지도 열리지 않는다면 Wi-Fi, 유선 네트워크, 라우터 또는 상위 네트워크를 먼저 복구해야 합니다. 현재 네트워크 연결을 끊었다가 다시 연결하거나, 조건이 허용되면 다른 네트워크 환경으로 바꾸어 비교할 수도 있습니다. 다른 네트워크를 장기적인 해결책으로 삼는 것이 아니라 문제가 현재 네트워크에 묶여 있는지 판단하는 것이 핵심입니다. 네트워크를 바꾼 뒤 클라이언트가 바로 연결된다면 계정과 구독은 대체로 사용 가능하므로 원래 네트워크의 DNS, 게이트웨이 정책 또는 네트워크 권한을 다시 점검하세요.

기본 네트워크가 복구되면 기기의 날짜, 시간과 시간대가 시스템에서 자동으로 관리되는지 확인하세요. 많은 암호화 연결은 인증서 유효 기간에 의존하므로 시스템 시간이 크게 틀리면 핸드셰이크 실패, 인증서 오류 또는 지속적인 시간 초과로 나타날 수 있습니다. 인증서 오류를 무시해 문제를 우회하지 말고 시스템 시간을 먼저 바로잡은 뒤 클라이언트를 재시작하세요. 이어서 다른 VPN, 디버깅 프록시, 패킷 캡처 도구 또는 가상 네트워크 어댑터를 제어하는 소프트웨어가 동시에 실행 중인지 확인합니다. 유사한 도구가 기본 라우팅을 동시에 바꾸면 연결 진입점이 이전 터널로 들어가 순환하거나 바로 시간 초과가 발생할 수 있습니다.

권한, 설정과 클라이언트 상태 확인하기

처음 실행하거나 시스템을 업데이트한 뒤 클라이언트가 VPN 설정, 네트워크 확장, 가상 네트워크 어댑터 또는 백그라운드 실행 권한을 다시 요청할 수 있습니다. Windows와 Linux에서는 가상 네트워크 어댑터가 정상적으로 생성되었는지와 클라이언트에 충분한 권한이 있는지 확인하세요. macOS에서는 네트워크 확장 승인 요청이 있는지 살펴보고, iOS와 Android에서는 시스템에 VPN 설정이 남아 있는지 확인해야 합니다. 권한 팝업을 닫아도 클라이언트 화면에서는 연결 버튼을 누를 수 있지만 시스템이 실제 터널을 만들지는 않습니다. 이때 반복해서 클릭해도 결과는 바뀌지 않으므로 클라이언트를 종료하고 시스템 설정에서 권한을 승인한 뒤 다시 시작하세요.

구독 목록에 선택 가능한 회선이 실제로 존재하고 회선 이름과 유형 태그가 정상적으로 표시되는지 확인하세요. 목록이 비어 있거나 이전 회선만 남아 있거나 업데이트 시간이 이상하다면 먼저 이 페이지의 “구독 업데이트” 섹션으로 이동하세요. 목록이 정상이라면 현재 위치의 네트워크 경로와 가까운 일반 지역 회선을 기준으로 선택하고, 초기 진단 단계에서는 복잡한 수동 규칙이나 사용자 지정 설정을 사용하지 마세요. VPNCF는 120+개 국가 / 170+개 회선을 제공하며 글로벌 노드에서 지역과 회선 유형 설명을 확인할 수 있습니다. 테스트할 때는 먼저 같은 지역의 서로 다른 회선 유형을 비교한 뒤 다른 지역을 비교해야 단일 회선 문제인지 전체 클라이언트 진입점 문제인지 구분할 수 있습니다.

오류가 발생한 단계로 방향 판단하기

연결 버튼을 누른 직후 오류가 나타난다면 설정 해석, 권한 또는 가상 네트워크 어댑터 문제에 가까운 경우가 많습니다. 한동안 기다린 뒤 시간 초과가 발생한다면 네트워크 경로, 회선 진입점 또는 DNS 확인 문제일 가능성이 큽니다. 연결이 잠시 성공했다가 바로 끊기면 다른 네트워크 서비스가 라우팅을 되돌리는지 확인하세요. 오류 문구에 설정 필드 이름이 포함되어 있다면 구독을 다시 가져오고 필드 값을 추측해 수동으로 입력하지 마세요. 인증서나 시간을 가리키는 오류라면 먼저 시스템 시간을 처리하세요. 단일 회선만 시간 초과를 일으킨다면 해당 회선 이름을 기록하고 같은 지역의 다른 유형을 테스트하면 되며 전체 구독을 삭제할 필요는 없습니다.

Windows:
ipconfig /flushdns

macOS:
dscacheutil -flushcache

Linux:
ip route
resolvectl status

이 명령은 각각 기기의 DNS 캐시를 정리하거나 라우팅 및 확인 상태를 확인하는 데 사용되며, 유효하지 않은 구독을 복구하거나 클라이언트 권한 설정을 대신하지 않습니다. 명령을 실행하기 전에 진행 중인 작업을 저장하세요. 실행 후에는 클라이언트를 완전히 종료했다가 다시 열고 동일한 회선으로 테스트를 반복해야 합니다. 명령을 사용할 수 없거나 시스템에서 권한 부족을 알리더라도 출처가 불분명한 복구 도구를 내려받지 말고 시스템이 제공하는 네트워크 진단 기능을 사용하세요.

WEB AND DNS

연결됐지만 웹페이지가 열리지 않음: 시스템 프록시와 DNS 확인

클라이언트에 “연결됨”으로 표시된다는 것은 터널 또는 프록시 프로세스가 만들어졌다는 뜻일 뿐, 브라우저 요청이 반드시 올바른 경로로 들어간다는 의미는 아닙니다. 웹페이지가 열리지 않을 때는 요청이 브라우저 밖으로 나가는지, 도메인 확인이 성공하는지, 시스템 프록시가 적용되는지, 규칙 모드가 대상 트래픽을 잘못된 출구로 보내는지를 계속 확인해야 합니다. 이 증상은 “연결 자체가 안 됨”과 다릅니다. 이 경우 구독을 반복해서 다시 가져와도 효과가 제한적일 수 있으므로 연결 후 트래픽 처리에 초점을 맞춰야 합니다.

모든 웹페이지인지 특정 도메인인지 먼저 구분하기

평소 접속 가능한 일반 웹페이지와 대상 웹페이지를 각각 테스트하세요. 모든 웹페이지가 열리지 않는다면 시스템 프록시가 이미 종료된 이전 클라이언트를 가리키는지, 현재 클라이언트가 시스템 프록시 제어를 활성화했는지, 브라우저에 별도 프록시가 설정되어 있는지 먼저 확인합니다. 일부 브라우저 확장 프로그램은 시스템 설정을 덮어쓸 수 있으므로 관련 확장을 잠시 끄고 브라우저를 다시 시작하세요. 특정 도메인 하나만 열리지 않는다면 먼저 다른 브라우저나 시크릿 창을 사용해 캐시, 쿠키, 오래된 서비스 워커와 확장 프로그램의 영향을 배제하세요. 단일 사이트 문제를 전체 회선 장애로 바로 단정하지 마세요.

이어서 클라이언트의 전역 모드와 규칙 모드를 한 번 비교하세요. 전역 모드는 정상이고 규칙 모드만 이상하다면 연결 자체는 대체로 사용할 수 있으며, 문제는 규칙 일치, 도메인 분류 또는 앱 우회에 있을 가능성이 큽니다. 규칙 모드는 정상이고 전역 모드만 이상하다면 대상 회선이 모든 트래픽을 처리하기에 적합한지, 로컬 서비스가 직결을 유지해야 하는지 확인하세요. 비교가 끝나면 원래 모드로 되돌려 진단 상태를 최종 설정으로 장기간 사용하지 않도록 합니다. 구체적인 회선 용도는 VPN 회선 선택법: 지역·회선 유형·용도를 한 번에 정리에서 확인할 수 있습니다.

DNS 확인 이상 여부 판단하기

DNS의 역할은 도메인 이름을 네트워크 주소로 변환하는 것입니다. 연결은 설정됐지만 브라우저에 서버를 찾을 수 없거나 이름을 확인할 수 없거나 도메인이 존재하지 않는다는 메시지가 표시되면 먼저 확인 경로를 점검해야 합니다. 터미널에서 시스템 기본 조회 도구를 사용해 도메인이 결과를 반환하는지 확인할 수 있습니다. 조회 명령은 실패하지만 이미 알고 있는 서비스에 직접 접속할 수 있다면 DNS 문제일 가능성이 큽니다. 도메인은 확인되지만 연결이 시간 초과된다면 회선, 라우팅 또는 대상 서비스 측 문제일 가능성이 더 높습니다. 출처가 불분명한 공용 DNS 주소를 함부로 복사하지 마세요. 네트워크와 라우팅 모드에 따라 확인 경로가 다르며, 무작정 교체하면 도메인은 로컬에서 확인하고 트래픽은 원격으로 나가는 경로 불일치가 생길 수 있습니다.

Windows:
nslookup example.com

macOS / Linux:
dig example.com
nslookup example.com

예시 도메인은 조회 과정을 확인하기 위한 것으로 실제 구독 정보가 포함되어 있지 않습니다. 출력 결과에서는 명령이 확인 결과를 정상적으로 반환했는지, 오랫동안 멈춰 있는지, 시스템이 실제로 어떤 확인 진입점을 사용하는지를 중점적으로 살펴보세요. 클라이언트에 “클라이언트 DNS 사용”, “시스템 설정 따르기” 또는 유사한 옵션이 있다면 먼저 기본 권장 방식으로 기준을 마련한 뒤 하나씩 비교하세요. 전환 후에는 브라우저와 시스템 캐시를 지우고 대상 앱을 재시작해야 합니다. 그렇지 않으면 이전 확인 결과가 재사용되어 설정이 적용되지 않은 것처럼 보일 수 있습니다.

남은 프록시와 잘못된 라우팅 정리하기

클라이언트가 비정상적으로 종료된 뒤 시스템 프록시가 더 이상 존재하지 않는 로컬 포트를 계속 가리킬 수 있습니다. 클라이언트를 종료하면 모든 웹페이지에 접속할 수 없고 다시 실행하면 복구되는 것이 전형적인 사례입니다. 이때 시스템 네트워크 설정에서 남아 있는 수동 프록시를 끄거나 현재 클라이언트의 “시스템 프록시 복원” 기능을 사용하세요. 기기에 여러 네트워크 도구를 설치한 적이 있다면 가상 네트워크 어댑터와 자동 프록시 스크립트가 남아 있는지도 확인해야 합니다. 구성 요소를 삭제하기 전에는 소속을 확인하고 회사 네트워크, 개발 환경 또는 보안 프로그램에 필요한 설정까지 함께 제거하지 않도록 주의하세요.

Linux 환경에서는 명령줄 프로그램이 데스크톱 시스템 프록시를 반드시 읽는 것은 아닙니다. 브라우저는 정상인데 터미널 도구만 실패한다면 오래된 값이 환경 변수에 남아 있는지, 현재 명령이 HTTP·HTTPS 또는 SOCKS 프록시를 지원하는지 확인하세요. 반대로 터미널은 작동하지만 브라우저가 실패한다면 브라우저 확장, 별도 DNS, 보안 DNS와 프록시 설정을 우선 점검합니다. Windows와 macOS에서도 브라우저가 별도 암호화 DNS를 활성화해 클라이언트의 확인을 우회할 수 있으므로 진단할 때는 브라우저를 기본 설정으로 잠시 되돌려 비교하세요.

증상 가능한 계층 확인 방법
모든 웹페이지가 열리지 않음 시스템 프록시, 기본 라우팅, 클라이언트 프로세스 이전 클라이언트를 종료하고 시스템 프록시 확인
도메인을 확인할 수 없다는 메시지 DNS와 캐시 조회 명령 실행 후 캐시 정리
전역 모드는 사용 가능하지만 규칙 모드는 실패 규칙 일치와 라우팅 대상 도메인을 기록하고 규칙 일치 확인
브라우저만 실패 확장 프로그램, 별도 프록시 또는 보안 DNS 시크릿 창과 기본 설정으로 비교

SPEED AND PEAK HOURS

느린 속도피크 시간대 지연: 경로를 나누어 관찰하기

속도 문제는 한 번의 속도 측정 결과만으로 판단할 수 없습니다. 웹페이지 첫 화면 지연, 동영상 버퍼링, 다운로드 변동, 회의 끊김과 API 시간 초과는 네트워크에 요구하는 조건이 서로 다릅니다. 한 번 측정한 최고 속도가 높아도 지속 전송이 안정적이라는 뜻은 아니며, 웹페이지가 순간적으로 정상적으로 열려도 장시간 연결이 흔들리지 않는다는 의미는 아닙니다. 점검할 때는 먼저 구체적인 사용 상황을 정하세요. 모든 트래픽이 느린지, 동영상·파일 전송·실시간 통화 또는 특정 대상 지역만 느린지, 하루 종일 지속되는지 네트워크가 붐비는 시간대에 집중되는지를 확인해야 합니다. 용도와 시간 범위를 명확히 해야 회선 비교가 의미를 갖습니다.

로컬 대역폭 경쟁과 무선 간섭 배제하기

먼저 가속 연결을 끊고 동일한 기기와 장소에서 기본 네트워크를 테스트하세요. 기본 네트워크 자체에서 패킷 손실이나 변동이 발생한다면 원격 회선으로 로컬 접속 문제를 해결할 수 없습니다. 클라우드 동기화, 시스템 업데이트, 게임 플랫폼 다운로드, 가정용 미디어 기기와 다른 단말이 업로드 또는 다운로드 대역폭을 사용하고 있는지 확인하세요. 실시간 회의는 특히 안정적인 업로드에 의존하므로 백그라운드 업로드가 있으면 웹페이지는 열려도 음성과 영상이 크게 끊길 수 있습니다. 무선 네트워크는 거리, 장애물과 같은 주파수 간섭의 영향도 받습니다. 가능하다면 유선 연결이나 액세스 포인트 가까운 위치에서 비교하되 다른 테스트 조건은 그대로 유지하세요.

클라이언트에서 중복 프록시 체인과 불필요한 트래픽 분석 기능을 끄세요. 브라우저 확장 프로그램이 트래픽을 다른 로컬 프록시로 먼저 보낸 뒤 클라이언트가 다시 전달하면 장애 지점이 늘고 경로 순환이 생길 수 있습니다. 보안 프로그램의 HTTPS 검사, 개발 도구의 패킷 캡처 프록시와 컨테이너 네트워크도 연결 동작을 바꿀 수 있습니다. 진단 단계에서는 명확한 네트워크 제어 방식 하나만 유지하고 안정성을 확인한 뒤 다른 도구를 하나씩 되돌리세요. 하나를 복원할 때마다 동일한 사용 상황을 다시 테스트해야 실제 영향을 준 구성 요소를 찾을 수 있습니다.

지역만 바꾸지 말고 회선 유형 비교하기

회선을 선택할 때는 먼저 대상 지역을 고정한 뒤 IEPL, 중계와 직결을 비교하세요. IEPL은 회선 안정성이 중요한 지속 접속에 더 적합하고, 중계 회선은 진입점과 출구 사이의 경로를 최적화해 일반적인 국제 접속에 적합합니다. 직결 경로는 단순하지만 현재 통신사와 국제 회선 상태의 영향을 더 크게 받습니다. 여기서 중요한 점은 어떤 유형이 모든 네트워크에서 더 빠르다고 단정하는 것이 아니라 테스트 변수를 명확하게 유지하는 것입니다. 같은 지역에서 유형을 먼저 비교한 뒤 인접 지역으로 바꾸면 지역 거리와 회선 구조를 동시에 변경하는 일을 피할 수 있습니다.

특정 콘텐츠 서비스만 느리다면 대상 서비스의 지역 진입점과 콘텐츠 전송 정책도 고려해야 합니다. 가까운 지역을 선택해도 가장 적합한 콘텐츠 노드에 연결된다는 보장은 없으며, 너무 먼 지역은 경로 길이를 늘릴 수 있습니다. 스트리밍 환경은 4K 스트리밍 VPN 추천: 화질이 480p로 계속 떨어지는 원인과 확인할 지표를 참고할 수 있지만, 진단할 때 화질 표시만 보지는 마세요. 버퍼링이 지속되는지, 재생 위치를 옮긴 뒤 회복되는지, 같은 회선에서 일반 웹페이지는 정상인지, 같은 지역의 다른 회선 유형으로 바꿨을 때 결과가 달라지는지를 관찰해야 합니다.

피크 시간대에 올바르게 비교하는 방법

피크 시간대 지연은 문제가 실제로 발생하는 시간대에 재현해야 합니다. 낮에 회선을 바꾼 뒤 복구되었다고 해서 밤에도 같은 성능이 유지된다는 뜻은 아닙니다. 고정된 테스트 대상을 정하고 평상시와 지연 시간대에 페이지 로딩, 지속 재생, 파일 전송 또는 서비스 요청이 안정적인지 각각 기록하세요. 서로 다른 웹사이트, 기기와 네트워크에서 얻은 결과를 직접 비교하지 마세요. 같은 회선이 특정 네트워크의 혼잡 시간대에만 이상하고 다른 접속 네트워크에서는 정상이라면 로컬 통신사와 진입점 사이의 문제일 가능성이 큽니다. 여러 접속 네트워크에서 동일한 회선이 동시에 이상하다면 회선 이름을 기록하고 같은 지역의 대체 회선으로 전환하세요.

동시 속도 측정을 자주 실행하면 그 자체로 회선을 모두 사용해 다른 앱이 더 느려 보일 수 있습니다. 진단은 실제 사용 상황을 중심으로 하고 속도 측정은 보조 수단으로만 사용하세요. 동영상은 지속 전송과 버퍼링을, 개발자 API는 연결 설정·시간 초과와 장시간 연결 안정성을, 웹페이지는 첫 바이트와 리소스가 완전히 로드되는지를 확인해야 합니다. AI API 환경은 웹 버전과 요구 사항이 다르므로 ChatGPT/Claude API 가속 회선 추천: 개발자 선택 가이드를 참고해 고정 출구, 동시 연결과 시간 초과 제어를 확인하고 최고 속도만 비교하지 마세요.

회선 유형 우선 확인하기 좋은 상황 집중해서 점검할 항목
IEPL 지속 접속, 회의, 개발 도구 같은 지역의 대체 회선과 로컬 진입점
중계 일상적인 웹 사용, 동영상과 종합적인 사용 진입 경로, 대상 지역과 혼잡 시간대
직결 경로 비교와 특정 네트워크 환경 통신사의 국제 회선과 대상 접근성

DISCONNECTION AND MOBILE

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

잦은 연결 끊김은 먼저 사용자가 직접 연결을 끊은 경우, 네트워크 전환과 시스템 정리를 구분해야 합니다. 직접 연결을 끊은 경우는 보통 클라이언트 로그에 명확한 이벤트가 남습니다. 네트워크 전환은 Wi-Fi와 이동통신 네트워크, 서로 다른 액세스 포인트 사이 또는 절전 모드 진입과 복귀 중에 발생합니다. 시스템 정리는 모바일 기기가 백그라운드로 전환된 뒤 클라이언트 프로세스나 VPN 확장이 절전 정책으로 일시 중지될 때 흔합니다. 세 경우 모두 화면에는 “다시 연결 중”으로 표시될 수 있지만 해결 방향은 완전히 다릅니다. 점검할 때는 끊긴 뒤의 오류만 기록하지 말고 끊기기 직전에 기기에서 어떤 일이 있었는지도 적어야 합니다.

네트워크 전환과 절전 모드 복귀 확인하기

기기를 움직이지 않고 사용할 때는 안정적이지만 위치를 옮기거나 화면을 잠그거나 덮개를 닫거나 절전 모드에서 복귀한 뒤 끊긴다면 네트워크 전환을 우선 확인하세요. 노트북이 유선에서 무선으로 바뀌거나 모바일 기기가 Wi-Fi에서 이동통신 네트워크로 바뀌면 기존 연결이 사용하던 로컬 주소와 출구 경로가 변하므로 이전 세션을 그대로 재사용하기 어렵습니다. 클라이언트가 연결을 다시 만들어야 하며 자동 재연결이 실패하면 구독을 바로 삭제하지 말고 먼저 연결을 끊었다가 다시 연결하세요. 반복된다면 전환 전후의 네트워크 유형과 클라이언트 상태를 기록해 특정 전환 방향에서만 발생하는지 확인하세요.

데스크톱 시스템이 절전 모드에서 복귀한 뒤 가상 네트워크 어댑터가 일반 네트워크 어댑터보다 늦게 복구되어 클라이언트가 너무 일찍 재연결을 시도하다 실패할 수 있습니다. 기본 네트워크가 완전히 복구될 때까지 기다린 후 수동으로 연결하거나 클라이언트 설정에서 시스템이 허용하는 자동 재연결 옵션을 활성화할 수 있습니다. 깨어날 때마다 클라이언트를 재시작해야 한다면 시스템 업데이트 후 네트워크 확장 또는 가상 네트워크 어댑터 권한을 다시 요청했는지 확인하세요. 모든 절전과 전원 절약 기능을 비활성화해 문제를 장기적으로 가리지 마세요. 전력 소모가 늘고 진단 정보도 사라집니다. 먼저 시스템 복구 순서, 클라이언트 권한 또는 특정 회선 세션이 해제되지 않는 문제인지 확인해야 합니다.

모바일 백그라운드 끊김의 권한 경로

iOS와 Android 모두 백그라운드 활동을 관리하지만 구체적인 동작은 다릅니다. iOS에서는 시스템 VPN 설정이 계속 허용되어 있는지 확인하세요. 저전력 상태, 네트워크 전환과 시스템 정리가 재연결을 일으킬 수 있습니다. Android에서는 배터리 최적화, 백그라운드 활동, 데이터 절약과 제조사가 제공하는 앱 절전 정책을 확인해야 합니다. 클라이언트에 알림 권한만 부여했다고 지속적인 백그라운드 실행 조건이 갖춰지는 것은 아닙니다. 시스템 설정에서 해당 앱을 찾아 필요한 백그라운드 네트워크 활동을 허용하고 자동 동결이나 깊은 절전 목록에 넣지 않도록 하세요.

모바일에서 점검할 때는 명확한 흐름을 사용하세요. 먼저 화면을 켜 둔 상태에서 연결과 웹페이지 접속이 정상인지 확인합니다. 화면을 잠근 뒤 시스템이 백그라운드 상태로 들어갈 때까지 기다렸다가 잠금을 해제해 연결을 확인하세요. 이어서 Wi-Fi 안에서 이동하는 경우, Wi-Fi와 이동통신 네트워크 사이 전환, 저전력 상태를 각각 테스트합니다. 매번 한 가지 변화만 확인하세요. 전면 사용 중에도 끊긴다면 단순한 백그라운드 정리 문제가 아니므로 회선과 기본 네트워크로 돌아가 점검해야 합니다. 화면을 잠근 뒤에만 끊기고 클라이언트를 다시 열면 즉시 복구된다면 백그라운드 권한과 절전 정책을 우선 확인하세요.

회선 연결 해제와 앱의 장시간 연결 해제 구분하기

클라이언트에는 계속 연결됨으로 표시되지만 회의, 메신저 또는 개발 도구에서 다시 로그인해야 하는 경우가 있습니다. 이는 앱의 장시간 연결이 끊긴 것일 수 있으며 VPN 터널 전체가 끊겼다는 뜻은 아닙니다. 문제가 발생했을 때 바로 일반 웹페이지를 열고 다른 앱도 네트워크에 연결되는지 확인하세요. 웹페이지는 정상이고 특정 앱만 다시 연결된다면 해당 앱의 연결 유지, 프록시 지원과 백그라운드 권한을 점검합니다. 모든 요청이 멈췄다면 클라이언트 로그로 돌아가 연결이 재구성되었는지 확인하세요. 앱이 백그라운드에서 복귀하면서 네트워크 세션을 새로 만들 수도 있으며, 이전 세션이 만료되는 것은 앱 계층의 동작입니다.

라우터나 상위 네트워크가 장시간 유휴 상태인 세션을 처리하는 방식 때문에 주기적으로 연결이 끊길 수도 있습니다. “잠시 지나면”이라는 느낌만으로 고정 주기를 추측하지 말고 정확한 발생 시간, 당시 트래픽이 있었는지, 기기가 잠금 상태였는지와 네트워크가 전환되었는지를 기록하세요. 지속적인 사용 중에는 안정적이고 유휴 상태 뒤에 끊긴다면 클라이언트에서 제공하는 연결 유지 또는 필요 시 연결 설정을 시도할 수 있습니다. 지속 전송 중에도 끊긴다면 서로 다른 회선 유형과 접속 네트워크를 비교하는 것이 더 중요합니다.

플랫폼 우선 확인 대표적인 비교 방법
Windows 가상 네트워크 어댑터, 절전 복귀, 이전 프록시 프로세스 전면 사용과 절전 복귀를 나누어 테스트
macOS 네트워크 확장 권한, 덮개를 닫은 뒤 복귀, 네트워크 서비스 순서 기본 네트워크 복구 후 다시 연결
iOS VPN 설정, 저전력 상태, 네트워크 전환 전면 사용, 화면 잠금과 네트워크 전환을 각각 확인
Android 배터리 최적화, 백그라운드 활동, 데이터 절약 깊은 절전을 끈 상태로 비교
Linux 네트워크 관리 서비스, 절전 복귀, 라우팅 재구성 복귀 전후 라우팅과 확인 상태 확인

SUBSCRIPTION UPDATE

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

구독 업데이트는 사용 가능한 회선과 관련 설정을 클라이언트에 전달하는 과정입니다. 업데이트 실패가 반드시 회선 자체의 문제를 뜻하지는 않습니다. 클라이언트가 구독 진입점에 접속하지 못했거나, 로그인 상태가 만료되었거나, 이전 캐시가 손상되었거나, 시스템 시간이 잘못되었거나, 가져오기 방식이 현재 클라이언트에서 지원되지 않을 수도 있습니다. 먼저 실패가 “구독 가져오기” 단계인지 “설정 해석” 단계인지 확인하세요. 전자는 네트워크 오류, 인증 실패 또는 접속 불가로 나타나는 경우가 많고, 후자는 형식·필드·설정 해석 오류로 나타나는 경우가 많습니다.

사용자 패널에서 구독 다시 받기

구독과 클라이언트는 사용자 패널에서 받아야 하며 정적 설치 파일의 직접 링크나 다른 사람이 전달한 구독 텍스트를 사용하지 마세요. 로그인 후 클라이언트 및 구독 페이지로 이동해 현재 계정 상태를 확인한 다음 플랫폼 안내에 따라 복사하거나 가져오세요. VPNCF는 이메일 주소 없이 사용자 이름과 비밀번호만으로 가입할 수 있습니다. 로그인 문제를 점검할 때는 다른 정보를 사용자 이름 필드에 입력하지 말고 계정 생성 시 사용한 사용자 이름인지 확인하세요. 구독은 계정 접근 자격 정보이므로 공개 채팅, 포럼이나 스크린샷에 공유해서는 안 됩니다.

클라이언트에 이전 구독 항목이 남아 있다면 기존 항목에 계속 붙여 넣지 마세요. 먼저 기존 설정을 기록한 다음 별도의 새 항목을 만들어 가져오면 이전 캐시 손상인지 새 내용 자체의 해석 실패인지 구분할 수 있습니다. 새 항목이 정상적으로 업데이트되면 회선이 완전한지 확인한 뒤 이전 항목을 삭제하세요. 새 항목과 이전 항목 모두 실패한다면 시스템 시간, 기본 네트워크와 클라이언트 지원 방식을 확인합니다. 해석을 “복구”하려고 구독 본문 속 프로토콜 필드를 직접 편집하지 마세요. 문자 하나만 잘못되어도 모든 회선이 작동하지 않을 수 있고 이후 업데이트에서 수동 수정 내용이 덮어써집니다.

네트워크 접속과 시스템 시간 확인하기

구독 업데이트는 보통 회선 연결을 만들기 전에 이루어지므로 현재 기본 네트워크에 의존합니다. 먼저 클라이언트를 연결 해제하고 사용자 패널이 정상적으로 열리는지 확인하세요. 패널에도 접속할 수 없다면 로컬 네트워크를 먼저 처리해야 합니다. 패널은 열리지만 클라이언트 업데이트가 실패한다면 아직 연결되지 않은 프록시를 통해 업데이트하도록 클라이언트가 잘못 강제 설정되어 있는지 확인하세요. 일부 클라이언트에는 “프록시를 통한 업데이트” 또는 유사한 옵션이 있습니다. 처음 가져올 때는 구독 진입점에 접속할 수 있는 경로를 사용해 노드가 있어야 노드를 받을 수 있는 순환을 피하세요.

시스템 시간이 이상해도 구독 진입점의 보안 연결 검증이 실패할 수 있습니다. 날짜, 시간과 시간대를 시스템 자동 관리로 되돌린 다음 클라이언트를 완전히 종료하고 다시 테스트하세요. 브라우저에서는 패널에 접속되지만 클라이언트가 인증서, 핸드셰이크 또는 보안 연결 오류를 표시한다면 시간과 클라이언트 실행 환경을 우선 점검해야 합니다. 인증서 검사를 끄지 말고 구독 내용을 신뢰할 수 없는 온라인 변환 사이트에 붙여 넣지도 마세요. 변환 과정에서 완전한 구독 자격 정보가 노출될 수 있으며 변환된 설정은 업데이트 기능을 잃을 수 있습니다.

캐시·형식·가져오기 방식 문제 확인하기

클라이언트가 내용을 내려받았지만 해석 실패를 표시한다면 먼저 해당 플랫폼에 대해 패널이 제공하는 가져오기 방식을 사용했는지 확인하세요. 클라이언트마다 허용하는 형식이 다르므로 동일한 내용을 모든 프로그램이 바로 읽을 수 있다고 가정할 수 없습니다. 구독 주소를 브라우저, 텍스트 편집기나 채팅 도구에 붙여 넣은 적이 있다면 복사 과정에서 공백, 줄바꿈 또는 일부 문자가 추가되거나 잘렸을 수 있습니다. 패널에서 복사 버튼이나 가져오기 진입점을 다시 사용하고 직접 조합하지 마세요. 구독 예시는 다음과 같이 명백한 가짜 값만 사용해야 합니다:

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

이 주소는 구조를 설명하기 위한 것일 뿐 연결에 사용할 수 없습니다. 실제 구독 주소는 문의 본문, 공개 스크린샷이나 공유 문서에 포함해서는 안 됩니다. 지원 담당자의 확인이 필요하다면 “구독 업데이트 실패”라고만 설명하고 오류 문구를 첨부하세요. 지원 담당자는 계정 내 문의 맥락을 바탕으로 확인할 수 있으므로 전체 자격 정보를 붙여 넣을 필요가 없습니다. 스크린샷에 QR 코드, 긴 링크 또는 토큰이 포함되어 있다면 민감한 부분을 먼저 가리세요.

업데이트는 성공했지만 회선 목록이 바뀌지 않는다면 클라이언트가 여전히 이전 설정 그룹을 표시하는지, 새 구독을 수동으로 선택해야 하는지, 업데이트 후 설정 다시 불러오기가 완료되었는지 확인하세요. 일부 클라이언트는 여러 구독을 동시에 유지할 수 있어 현재 선택된 항목이 여전히 이전 항목일 수 있습니다. 구독 이름과 업데이트 시간을 확인한 뒤 회선 목록이 일치하는지 살펴보세요. 일부 회선만 사라졌다면 직접 회선을 추가하지 말고 누락된 지역, 클라이언트 플랫폼과 구독 항목 이름을 기록해 문의로 전달하세요.

APPLICATION ROUTING

특정 앱이 프록시를 사용하지 않음: 라우팅 경로 확인

브라우저는 정상인데 특정 앱에 연결할 수 없다면 터널과 구독은 기본적으로 사용 가능하고, 문제는 앱이 네트워크 요청을 시작하는 방식에 집중되어 있을 가능성이 큽니다. 앱은 시스템 프록시를 읽거나 별도 프록시 설정을 사용하거나 직접 네트워크 연결을 만들거나 내장 DNS를 사용하거나 브라우저와 다른 프로세스와 통신할 수 있습니다. 이때 계정을 먼저 바꾸거나 클라이언트를 반복해서 재설치하지 말고 트래픽이 프록시에 들어가는지, 규칙이 어디로 보내는지, 새 설정을 읽으려면 앱을 재시작해야 하는지를 확인하세요.

앱이 시스템 프록시를 지원하는지 확인하기

많은 데스크톱 앱은 시스템 프록시를 읽지만 시스템 설정을 완전히 무시하는 앱도 있습니다. 클라이언트가 시스템 프록시 모드만 켠 경우 이를 무시하는 프로그램은 계속 직결될 수 있습니다. 클라이언트에 가상 네트워크 어댑터 또는 전역 제어 모드가 있다면 한 번 비교해 보세요. 전환 후 앱이 복구되면 회선은 사용할 수 있고 기존 모드에서 앱이 프록시에 들어가지 않았다는 뜻입니다. 전환 후에도 실패하면 대상 지역, DNS와 앱 계정 상태를 계속 확인하세요. 테스트가 끝나면 실제 필요에 따라 모드를 선택하고 모든 앱이 장기간 전역 제어를 사용해야 한다고 가정하지 마세요.

앱에 별도 프록시 설정이 있다면 이전 주소, 이전 포트 또는 잘못된 프로토콜이 남아 있는지 확인하세요. 로컬 포트는 현재 클라이언트 설정에 따라 달라지고 재설치나 모드 전환 후 바뀔 수 있으므로 인터넷에서 포트 정보를 임의로 복사하지 마세요. 클라이언트가 제공하는 시스템 제어 또는 연결 정보 복사 기능을 우선 사용하세요. 별도 프록시 설정을 변경한 뒤에는 앱을 완전히 종료하고 다시 시작해야 합니다. 창만 닫으면 백그라운드 프로세스가 끝나지 않아 이전 연결 풀이 기존 경로를 계속 사용할 수 있습니다.

규칙 일치와 프로세스 범위 확인하기

규칙 모드는 보통 도메인, 주소, 프로세스 또는 앱 패키지 이름에 따라 프록시를 사용할지 직결할지를 결정합니다. 대상 앱은 로그인, 콘텐츠, 업데이트와 원격 측정 등 여러 도메인에 동시에 접속할 수 있으므로 주 도메인 하나만 규칙에 추가해도 전체 과정이 적용되지 않을 수 있습니다. 진단할 때는 먼저 전역 모드로 현재 회선에서 앱을 사용할 수 있는지 확인한 다음 규칙 모드로 돌아가 로그나 연결 목록에서 실패한 요청이 어느 출구로 분류되었는지 살펴보세요. 전역 모드는 정상이고 규칙 모드만 실패한다면 규칙 범위를 수정해야 합니다. 전역 모드도 실패한다면 라우팅만이 유일한 원인은 아닙니다.

데스크톱 앱은 여러 프로세스가 협력하는 경우가 많습니다. 기본 창 프로세스는 화면만 담당하고 실제 네트워크 요청은 업데이트 프로그램, 백그라운드 서비스, 런타임 또는 하위 프로세스가 보낼 수 있습니다. 주 프로그램 이름만으로 규칙을 설정하면 백그라운드 요청은 계속 직결될 수 있습니다. 파일명을 추측하지 말고 클라이언트 연결 로그에서 실제 요청을 보낸 프로세스와 도메인을 확인하세요. 모바일 앱은 시스템 네트워크 서비스나 내장 브라우저 구성 요소를 사용할 수 있으므로 앱 패키지와 도메인을 함께 기준으로 규칙을 검증해야 합니다.

앱 캐시·프로토콜·지역 문제 배제하기

앱은 시작할 때 DNS, 지역 정보와 연결 풀을 캐시합니다. 회선을 바꾼 뒤 브라우저는 바로 달라져도 실행 중인 앱은 이전 연결을 계속 재사용할 수 있습니다. 앱의 백그라운드 프로세스를 종료하고 클라이언트 연결이 안정적인지 확인한 뒤 다시 여세요. 앱 계정이나 콘텐츠 자체에 지역 요건이 있다면 회선 지역도 대상 서비스와 맞아야 합니다. 웹페이지가 열린다는 이유만으로 어떤 지역이든 앱의 모든 기능에 적합하다고 판단할 수는 없습니다. 스트리밍 환경은 스트리밍 지역 접속에서 지역 선택 방법을 확인하고, AI 도구는 AI 가속 주제를 참고하세요.

일부 앱은 UDP, 장시간 연결 또는 사용자 지정 전송 방식을 사용하지만 현재 프록시 모드는 트래픽 일부만 제어할 수 있습니다. 로그인 페이지는 열리지만 음성, 게임 매칭, 동기화 또는 실시간 업데이트가 실패하는 식으로 나타날 수 있습니다. 클라이언트가 지원하는 전체 제어 모드로 비교하고 앱의 각 기능이 따로 복구되는지 관찰하세요. 로그인 페이지만 테스트하지 마세요. 로그인 성공은 요청 일부만 도달했다는 뜻일 수 있습니다. 클라이언트 로그에 대상 트래픽이 회선으로 들어간 것으로 표시되는데도 앱이 서버 오류를 반환한다면 오류 원문을 보존하고 대상 서비스 상태나 계정 제한을 확인하세요.

비교 결과 판단 방향 다음 단계
브라우저는 정상, 앱은 실패 앱이 시스템 프록시를 무시하거나 별도 설정이 있음 앱 설정과 전체 제어 모드 확인
전역 모드는 정상, 규칙 모드는 실패 도메인·프로세스·패키지 이름 규칙이 불완전함 연결 로그와 실제 요청 프로세스 확인
앱 재시작 후 복구 이전 연결 풀 또는 DNS 캐시 회선 전환 후 앱 연결 재구성
로그인은 성공하지만 실시간 기능은 실패 일부 프로토콜 또는 트래픽이 제어되지 않음 앱의 네트워크 기능을 각각 확인

DEVICE AND SUPPORT

기기 안내, 계정 상태와 문의 자료

VPNCF 요금제는 연결 기기 수에 제한이 없습니다. 클라이언트나 타사 가져오기 도구에 “기기 수 초과”, “연결 수 이상” 또는 유사한 안내가 표시되어도 이를 곧바로 요금제 제한으로 이해해서는 안 됩니다. 먼저 안내가 VPNCF 사용자 패널, 현재 클라이언트, 운영체제 또는 별도 앱 중 어디에서 나온 것인지 확인하세요. 출처에 따라 “기기”는 로그인 세션, 설정 인스턴스, 시스템 VPN 슬롯, 앱 자체의 인증 또는 아직 해제되지 않은 이전 연결을 의미할 수 있으며 본 서비스의 기기 수 정책과 같지 않습니다.

기기 수 초과 안내 처리하기

먼저 사용자 패널에서 현재 계정과 요금제 상태를 확인한 다음 기기에 동일한 구독을 중복으로 가져왔는지, 여러 클라이언트를 동시에 실행 중인지, 자동 연결 설정을 여러 개 유지하고 있는지 확인하세요. 사용하지 않는 클라이언트를 완전히 종료하고 시스템에서 중복 VPN 설정을 끈 뒤 다시 연결합니다. 별도 클라이언트의 로컬 화면에 안내가 나타났다면 클라이언트 이름과 전체 문구를 기록하고 “초과”라는 두 글자만 잘라 보내지 마세요. 운영체제에서 나온 안내라면 이전 네트워크 확장, 가상 네트워크 어댑터 또는 기업 관리 설정이 같은 연결 진입점을 점유하고 있는지 확인하세요.

기기를 바꾸거나 시스템을 재설치하거나 클라이언트가 비정상적으로 종료된 뒤 이전 세션이 잠시 남아 있을 수 있습니다. 먼저 다른 기기의 연결을 종료하고 클라이언트가 정상적으로 연결 해제를 완료할 때까지 기다린 다음 현재 기기에서 다시 로그인하거나 다시 가져오세요. 식별할 수 없는 기기에 계정 자격 정보를 공유하지 말고 출처가 불분명한 통합 클라이언트도 사용하지 마세요. 세션 관리 방식이 연결을 제대로 해제하지 못할 수 있습니다. 계정 페이지 상태가 정상이고 다른 클라이언트를 종료한 뒤에도 안내가 계속되면 문의를 제출해 지원 담당자가 계정 맥락에 따라 세션 상태를 확인하도록 하세요.

고객 지원이 정말 필요한지 먼저 판단하기

단일 회선만 이상하고 같은 지역의 다른 회선은 정상이라면 대체 회선을 먼저 사용하면서 문제가 발생한 회선 이름을 기록하세요. 모든 회선이 특정 기기에서 실패하고 다른 기기에서는 정상이라면 해당 기기의 권한, 프록시와 네트워크 구성 요소를 우선 점검합니다. 모든 기기가 같은 네트워크에서 실패하고 다른 네트워크에서는 정상이라면 원래 네트워크를 우선 확인하세요. 서로 다른 기기, 네트워크와 회선에서 동일한 오류가 발생할 때 문의를 바로 제출하는 것이 적합합니다. 이렇게 계층별로 나누면 반복적인 질문을 줄이고 로컬 환경 문제를 서비스 측 장애로 잘못 판단하는 일도 피할 수 있습니다.

결제와 계정 문제는 사용자 패널의 문의 접수에서 처리하세요. VPNCF 월간 구독은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며 트래픽은 개통일을 기준으로 매월 초기화되고 중간 업그레이드 차액은 남은 일수에 따라 계산됩니다. 데이터 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 소진될 때까지 사용할 수 있고 영구적으로 만료되지 않습니다. 요금제 표시, 트래픽 초기화 또는 업그레이드 결과와 관련된 문제라면 선택한 요금제 이름, 작업 시간과 패널에 현재 표시된 내용을 적으세요. 받을 트래픽이나 남은 기간을 직접 계산하지 마세요.

결제 문제도 사실만 설명하세요. VPNCF는 Alipay / WeChat / USDT를 지원하며 30일 무조건 환불을 제공합니다. 문의에는 사용한 결제 방식, 패널에 표시된 주문 상태와 오류 안내를 적을 수 있지만 결제 비밀번호, 전체 결제 정보, 계정 비밀번호 또는 구독 주소를 제출하지 마세요. 스크린샷에는 주문 상태와 시간이 보이도록 하되 지원 담당자가 볼 필요가 없는 민감한 정보는 가리세요. 요금제 상세 내용은 가격 페이지와 사용자 패널에 현재 표시된 내용을 기준으로 합니다.

바로 사용할 수 있는 문의 체크리스트

품질 높은 문의에는 문제 제목, 발생 시간, 플랫폼, 클라이언트, 네트워크 유형, 회선 이름, 재현 단계, 예상 결과, 실제 결과, 오류 원문, 이미 시도한 작업과 다른 기기나 네트워크에서 재현되는지 여부가 포함되어야 합니다. 제목을 “안 돼요”라고만 쓰지 말고 “macOS 연결 후 모든 웹페이지에서 DNS 확인 불가” 또는 “Android 화면 잠금 후 시스템이 연결을 일시 중지함”처럼 작성하세요. 본문은 발생 순서대로 설명하고 서로 다른 여러 문제를 한 문단에 섞지 마세요.

문제 현상:
사용 플랫폼:
클라이언트 상태:
현재 회선:
네트워크 유형:
발생 시간:
재현 단계:
오류 원문:
실행한 작업:
다른 기기 결과:
다른 네트워크 결과:

로그는 장애 시간과 가까운 구간만 제출하고, 그 안에 구독 주소, 토큰, 계정 비밀번호 또는 기타 비공개 정보가 포함되어 있는지 먼저 확인하세요. 스크린샷에는 전체 오류 창과 클라이언트 상태 표시줄이 포함되어야 하며 한 줄만 잘라 맥락이 사라지지 않도록 하세요. 특정 앱 문제라면 브라우저나 다른 앱이 정상인지 적어야 합니다. 속도 문제라면 최고 속도 스크린샷만 첨부하지 말고 구체적인 사용 상황, 시간대, 회선 유형과 로컬 기본 네트워크의 정상 여부를 함께 작성하세요.

지원 담당자가 작업 방법을 안내하면 같은 테스트 조건에서 다시 재현하고 결과를 알려야 합니다. 답변을 기다리는 동안 시스템 재설치, 여러 클라이언트 전환과 전체 네트워크 설정 변경을 동시에 진행하지 마세요. 전후 환경을 비교할 수 없게 됩니다. 대체 회선으로 문제가 완화되었더라도 원래 회선과 발생 시간을 남겨 이후 확인에 활용하세요. 문제가 해결된 뒤에는 문의에 최종적으로 효과가 있었던 작업을 추가해 문제 해결을 완결하고 “됐어요”라고만 답하지 않는 것이 좋습니다.

제출 전 자체 점검

  • 연결을 끊었을 때 기본 네트워크가 정상인지 확인했습니다.
  • 플랫폼, 클라이언트 상태와 전체 회선 이름을 기록했습니다.
  • 모든 앱의 문제인지 특정 앱 하나의 문제인지 구분했습니다.
  • 다른 조건을 바꾸지 않고 대체 회선이나 네트워크를 테스트했습니다.
  • 오류 원문을 복사하고 문제가 발생한 시간을 표시했습니다.
  • 스크린샷과 로그에서 비밀번호, 전체 구독 주소와 토큰을 삭제했습니다.
무료 체험