VPNStay 문제 해결 가이드

연결이 전혀 안 될 때: 로컬 네트워크부터 확인

먼저 ‘클라이언트가 실행되지 않는 경우’와 ‘실행은 되지만 연결을 설정하지 못하는 경우’를 구분하세요. 전자는 권한 안내가 반복해서 나타나거나 연결 버튼을 눌러도 반응이 없고, 프로그램이 실행 직후 종료되는 식으로 나타날 수 있습니다. 후자는 서버 목록은 보이지만 연결 중 상태에서 멈추거나 로그에 시간 초과 또는 핸드셰이크 실패가 표시되는 경우가 많습니다. 우선 오류 문구를 그대로 기록한 뒤 점검을 이어가세요. ‘네트워크가 안 돼요’라는 설명만으로는 기기, 구독, 원격 경로 중 어디에 문제가 있는지 판단하기 어렵습니다.

현재 상태를 기록한 뒤 기본 연결을 확인하세요

클라이언트 연결을 잠시 끊고 다른 프록시 도구도 종료한 다음, 평소 바로 접속되는 웹페이지를 열어 보세요. 이 페이지들도 열리지 않는다면 현재 네트워크에 웹 인증이 필요한지, 기기에 유효한 주소가 할당됐는지, 공유기가 정상인지 확인하세요. 공용 네트워크의 인증 페이지가 기존 프록시 설정에 막힐 수 있으니 인증을 마친 뒤 다시 연결하세요. 기본 네트워크가 복구되기 전에는 국제 서버를 계속 바꿔도 대개 결과가 달라지지 않습니다.

가능하면 같은 기기에서 같은 웹페이지를 사용하고, 연결 네트워크만 바꿔 테스트하세요. 신뢰할 수 있는 다른 네트워크에서는 연결된다면 계정 오류라고 단정하기보다 기존 네트워크의 접속 환경을 먼저 의심할 수 있습니다. 모든 네트워크에서 실패할 때는 클라이언트와 계정을 확인하세요. 네트워크 변경, 프로그램 재설치, DNS 설정 변경을 한꺼번에 하지 마세요. 연결이 복구되더라도 실제로 어떤 조치가 효과가 있었는지 알 수 없습니다.

구독, 권한, 현재 서버를 확인하세요

사용자 패널에서 요금제 상태와 남은 트래픽을 확인한 뒤, 클라이언트에서 방금 갱신한 구독을 사용 중인지 살펴보세요. 서버 이름이 목록에 남아 있다고 해서 계정이 여전히 유효하거나 설정 갱신이 성공했다는 뜻은 아닙니다. 이름이 같은 설정이 여러 개라면 출처와 갱신 시각을 확인해 올바른 설정을 선택한 뒤 연결하세요. 오래된 파일과 현재 구독을 섞어 하나씩 시도하면 증상만 더 복잡해질 수 있습니다.

시스템에서 처음 연결할 때 네트워크 설정 추가, 백그라운드 서비스 실행, 가상 네트워크 인터페이스 사용을 허용하라는 안내가 표시될 수 있습니다. 이러한 권한은 트래픽을 클라이언트로 전달하기 위한 것이며, 서버 자체의 사용 가능 여부와는 별개의 문제입니다. 권한을 거부했다면 시스템 설정이나 클라이언트 안내에서 다시 허용하세요. 조직에서 관리하는 기기라면 관련 기능 사용이 허용되는지 관리자에게 먼저 확인하세요. 관리 정책을 해제해 연결을 강제로 설정하지 마세요.

지역이나 유형이 다른 서버로 바꿔 오류가 달라지는지 확인하세요. 특정 서버만 실패하고 다른 서버는 작동한다면 사용 가능한 서버는 그대로 두고, 실패한 서버 이름과 발생 시각을 기록하세요. 모든 서버에서 같은 로컬 권한 오류가 나타나면 클라이언트 서비스를, 특정 네트워크에서만 모두 시간 초과가 발생하면 접속 환경을 우선 확인하세요. 오류가 발생하는 범위는 오류 문구에 나온 단일 용어보다 판단에 더 도움이 됩니다.

로그를 확인하고 변경 범위를 무작정 넓히지 마세요

시간 초과는 특정 단계에서 응답을 받지 못했다는 뜻입니다. DNS 조회, 원격 서버 연결, 대상 웹사이트 요청 중 어느 단계에서든 발생할 수 있습니다. 핸드셰이크 실패는 설정 불일치, 시스템 시간 오류, 네트워크 중단과 관련될 수 있고, 인증 실패는 계정과 구독 출처를 확인해야 합니다. 오류 이름만으로 원인을 단정할 수는 없습니다. 오류 전후의 연속된 로그를 살펴보고 문제가 서버 주소와 관련된 것인지, 접속 대상과 관련된 것인지 확인한 다음 점검할 항목을 정하세요.

보안 프로그램을 먼저 끄거나 네트워크 인터페이스를 모두 삭제하거나 시스템 네트워크 설정 전체를 초기화하지 마세요. 되돌릴 수 있는 항목부터 확인하고 변경 전 상태를 기록하세요. 이렇게 하면 연결을 복구한 뒤 원래 작업 환경으로 되돌릴 수 있습니다.

클라이언트를 종료한 뒤 평소 바로 열리던 웹페이지도 접속되지 않는다면 시스템 프록시가 중지된 로컬 서비스 주소를 계속 가리키는지 확인하세요. 먼저 클라이언트에서 시스템 프록시를 끈 다음 시스템 설정에서도 확인하세요. 주소나 포트를 추측해 입력하지 마세요. 기본 네트워크와 요금제가 정상이고 현재 구독 갱신도 성공했는데 여러 네트워크에서 여러 서버가 같은 오류를 보인다면 문의를 접수할 수 있습니다. 민감 정보를 가린 연속 로그를 첨부하면 프로그램을 반복해서 재설치하는 것보다 도움이 됩니다.

연결은 되는데 웹페이지가 열리지 않을 때: DNS와 요청 확인

클라이언트에 연결됨으로 표시되어도 연결 과정의 일부가 완료되었다는 뜻일 뿐, 모든 웹사이트에 정상 접속할 수 있다는 의미는 아닙니다. 브라우저에서 웹페이지를 열 때는 도메인 조회, 연결 설정, 인증서 검증, 콘텐츠 요청도 이루어집니다. 먼저 증상을 구체적으로 확인하세요. 모든 페이지가 빈 화면인지, 특정 도메인만 오류를 내는지, 주소를 찾을 수 없다는 안내가 뜨는지, 기다린 뒤 시간 초과가 되는지 살펴보세요. 인증서 경고인지 사이트의 접속 제한 페이지인지도 구분해야 합니다. 증상에 맞는 항목을 확인하고 모두 서버 연결 문제로 취급하지 마세요.

웹페이지 증상 범위로 문제 지점을 파악하세요

클라이언트를 켠 상태에서 평소 바로 열리는 웹사이트와 접속하려는 웹사이트를 각각 방문하세요. 전자는 정상이고 후자만 실패하면 대상 요청이 프록시 규칙에 따라 처리되는지 확인하세요. 두 사이트 모두 실패하면 시스템 프록시, 가상 네트워크 연결, DNS 설정을 살펴보세요. 브라우저만 실패하고 다른 앱은 정상이라면 브라우저의 비공개 창으로 테스트해 오래된 캐시와 확장 프로그램의 영향을 확인할 수 있습니다. 비공개 창도 시스템 네트워크 설정을 따를 수 있으므로 이를 근거로 모든 프록시 문제를 배제할 수는 없습니다.

도메인 주소를 찾지 못하면 DNS 조회에서 유효한 결과를 얻지 못했을 가능성이 큽니다. 주소를 받았지만 연결이 시간 초과된다면 라우팅과 서버를 추가로 확인하세요. 인증서 경고가 나타나면 먼저 시스템의 날짜와 시간이 맞는지, 대상 도메인이 올바른지 확인하세요. 계속 이용하려고 인증서 경고를 무시하거나 출처가 불분명한 인증서를 가져오지 마세요. 인증이 필요한 일부 네트워크에서는 요청이 로그인 페이지로 연결될 수 있습니다. 이 경우 대상 사이트 설정을 바꾸기보다 기본 연결을 다시 확인하세요.

DNS 설정이 서로 충돌하는지 확인하세요

시스템, 브라우저, 클라이언트가 각각 DNS 조회에 관여할 수 있습니다. 브라우저에서 별도의 보안 DNS를 사용하면 시스템 명령으로 조회한 결과와 다를 수 있습니다. 클라이언트가 DNS를 처리하는 경우에는 자체 규칙에 따라 요청을 보낼 수도 있습니다. 먼저 각 설정의 기존 상태를 기록하고 클라이언트 안내에 따라 일관된 설정을 사용하세요. 서로 덮어쓰는 DNS 경로를 여러 개 동시에 지정하지 마세요. 시스템 조회는 성공하고 브라우저에서는 실패해도 모순이 아닙니다. 두 요청이 같은 경로를 거치지 않을 수 있습니다.

Windows에서는 터미널에서 현재 네트워크 정보를 확인하고 공개된 예시 도메인을 조회할 수 있습니다. 아래 명령은 상태 확인용이며 계정 정보는 포함하지 않습니다. 조회 결과가 나와도 이번 시스템 DNS 조회가 성공했다는 의미일 뿐, 대상 앱의 트래픽이 프록시를 거쳤다는 뜻은 아닙니다. 결과를 문의에 첨부할 때는 기기 주소와 네트워크 이름처럼 문제 파악에 필요하지 않은 정보를 가리고, 오류 문구와 조회에 사용한 인터페이스 정보는 남겨 두세요.

ipconfig /all
nslookup example.com

DNS 설정을 수정했는데도 시스템이 이전 결과를 계속 사용한다면 Windows에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비운 다음 브라우저를 다시 여세요. 브라우저에 별도 캐시가 있을 수 있으므로 명령이 성공해도 모든 앱의 동작이 바로 바뀌지는 않습니다. Linux에서 systemd-resolved를 사용한다면 resolvectl status로 상태를 확인하세요. 해당 구성요소가 없는 배포판에서는 사용 중인 네트워크 관리 도구를 확인하고, 관련 없는 수정 명령을 그대로 따라 하지 마세요.

DNS가 정상이라면 다음으로 접속 경로를 확인하세요

클라이언트의 연결 로그를 열어 오류가 난 웹페이지를 다시 방문하고, 요청이 어떤 규칙과 서버에 연결되었는지 확인하세요. 직접 연결 규칙에 해당한다면 분할 터널링 설정을 먼저 확인하세요. 프록시에 전달된 뒤 대상 웹사이트의 오류 페이지를 받았다면 요청이 적어도 서버 측까지 도달한 것입니다. 다음으로 서버를 바꾸거나 사이트 계정 상태를 확인하세요. 웹페이지에 표시되는 지역 안내나 로그인 실패를 로컬 DNS 오류와 혼동하지 마세요. 각각 점검할 위치가 다릅니다.

웹사이트 IP 주소를 직접 입력하는 방법으로 전체 연결을 검증하려 하지 마세요. 많은 웹사이트는 인증서 검증과 콘텐츠 전달에 도메인을 사용합니다. IP로 접속되지 않는다는 사실만으로 서버 문제를 판단할 수는 없습니다.

설정 변경 후 모든 웹페이지에 접속할 수 없게 되면 방금 수정한 DNS 항목을 먼저 되돌린 다음 클라이언트 설정을 원래대로 복구하세요. 복구 과정에서는 다른 변수를 그대로 두고 기본 웹페이지와 대상 웹페이지의 동작을 각각 확인하세요. 지원이 필요하다면 대상 도메인, 오류 유형, 시스템 DNS 조회 결과, 클라이언트에서 적용된 규칙, 같은 네트워크의 다른 웹사이트가 정상인지 함께 알려 주세요. ‘웹페이지를 표시할 수 없음’이라는 화면만으로는 DNS 조회 실패와 이후 연결 실패를 구분하기 어렵습니다.

속도 저하와 저녁 시간대 끊김: 혼잡과 앱 문제 구분하기

‘느리다’는 증상을 구체적으로 나누는 것부터 시작하세요. 웹페이지 로딩이 시작되지 않는 경우, 다운로드는 시작되지만 전송이 불안정한 경우, 동영상이 자주 버퍼링되는 경우, 앱 반응이 느린 경우는 서로 다른 단계와 관련될 수 있습니다. 먼저 대상과 사용 방식을 고정한 뒤 서버를 비교하세요. 속도 측정 사이트 결과가 실제 앱의 사용 경험을 대신하지는 않으며, 한 번의 테스트로 저녁 시간대 상태를 단정할 수도 없습니다. 보기 좋은 수치보다 반복해서 확인할 수 있는 차이를 찾는 것이 점검의 목표입니다.

비슷한 조건으로 비교하세요

먼저 기기에서 대용량 파일 동기화, 시스템 업데이트, 다른 다운로드를 잠시 멈추고 가정 내 다른 기기가 네트워크를 사용 중인지 확인하세요. Wi-Fi 신호가 약하거나 기기의 절전 기능이 작동하거나 공유기에 부하가 걸려도 국제 접속 문제가 있는 것처럼 보일 수 있습니다. 가능하다면 기존 무선 연결과 유선 연결을 비교하되 서버와 대상은 그대로 유지하세요. 로컬 네트워크를 바꾸자 문제가 뚜렷하게 개선된다면 원격 서버를 반복해서 바꾸기보다 접속 환경을 먼저 확인하세요.

같은 기기, 앱, 대상 콘텐츠를 사용해 서버를 비교하세요. 지리적으로 가까운 서버가 항상 더 빠른 것은 아닙니다. 실제 경로와 접속 네트워크, 대상 서비스의 위치가 모두 결과에 영향을 줍니다. 한 서버에서는 웹페이지가 원활한데 다른 서버에서는 특정 동영상 사이트만 끊긴다면 대상별 차이를 기록하세요. ‘전부 느림’이라고 뭉뚱그리지 마세요. 서버 이름과 문제가 발생한 시간대를 함께 기록해 두면 확인에 도움이 됩니다.

저녁 시간대 끊김은 반복되는 패턴인지 살펴보세요

저녁에 네트워크가 붐빌 때만 눈에 띄게 느려진다면 비슷한 사용 조건에서 시간대별 대상 성능과 서버 변경 결과를 기록하세요. 속도 측정 작업을 여러 개 동시에 실행하지 마세요. 측정 자체가 대역폭을 사용해 네트워크 경쟁을 심화할 수 있습니다. 기존 네트워크에서 여러 서버가 모두 느리고 신뢰할 수 있는 다른 네트워크에서는 개선된다면 접속 구간이 병목일 수 있습니다. 특정 서버에서만 반복적으로 끊긴다면 결과를 고객 지원팀에 전달하고 같은 서버에 계속 재연결하지 않아도 됩니다.

서버 유형에 따라 적합한 비교 방법은 다르지만 이름만으로 성능을 보장할 수는 없습니다. IEPL 전용 회선, 중계, 직접 연결은 현재 네트워크와 대상 서비스에 맞춰 실제로 테스트하세요. 먼저 글로벌 서버 및 회선 안내에서 선택 방법을 확인한 뒤 실제 작업으로 검증하세요. 회선 이름만 보고 모든 지역과 시간대에서 더 빠르다고 단정하거나, 유형을 바꾸기 위해 모든 클라이언트 설정을 변경하지 마세요.

앱 설정과 요금제 상태도 확인하세요

동영상 앱은 화질을 자동으로 높일 수 있으므로 ‘서버를 바꿔도 끊김’ 현상이 있으면 화질이 바뀌었는지도 확인하세요. 클라우드 동기화 앱은 백그라운드 전송을 제한할 수 있고, 브라우저 다운로드는 대상 서버의 속도 제한을 받을 수 있습니다. 실시간 앱은 응답의 연속성이 중요하고 파일 전송은 지속적인 처리량에 더 크게 좌우됩니다. 서로 다른 작업을 한데 묶어 비교하면 결론이 엇갈리기 쉽습니다. 실제로 하려는 작업을 기준으로 판단하고, 익숙하지 않은 속도 측정 사이트 하나로 모든 사용 경험을 대신하지 마세요.

사용자 패널에서 트래픽과 요금제 상태를 확인해 한도 소진 후의 접속 오류를 저녁 시간대 혼잡으로 오해하지 않도록 하세요. 월간 구독 트래픽은 가입일을 기준으로 매월 초기화됩니다. 이용 도중 요금제를 업그레이드하면 차액은 남은 일수에 따라 계산됩니다. 구체적인 용량과 가격은 요금제 페이지를 확인하세요. 용량 증가는 사용할 수 있는 트래픽 문제를 해결하는 것이지 모든 대상 서비스의 속도를 높여 주는 것은 아닙니다. 네트워크 경로를 확인하기 위해 먼저 요금제를 업그레이드할 필요는 없습니다.

같은 시간대, 같은 대상, 같은 접속 네트워크에서 특정 서버가 사용 가능한 비교 서버보다 계속 눈에 띄게 느리다면 문의에 첨부할 만한 자료가 됩니다. 실제 작업과 발생 시간대, 백그라운드 전송을 멈췄는지, 서버 변경 전후 결과를 구체적으로 적으세요. 속도 측정 화면 하나만 첨부하거나 한 번의 일시적인 개선을 장기적인 결과처럼 표현하지 마세요. 고객 지원팀이 적절한 서버 변경이나 로컬 네트워크 추가 점검 여부를 판단할 수 있도록 재현 조건을 알려 주세요.

잦은 연결 해제와 백그라운드 끊김: 끊기는 시점 확인

연결 해제는 네트워크 전환, 기기 절전, 앱의 백그라운드 전환, 장시간 사용 중에 발생할 수 있습니다. 연결이 끊기기 직전에 무엇을 하고 있었는지, 클라이언트 아이콘이 계속 표시되는지, 앱을 다시 열었을 때 자동으로 복구되는지 아니면 재연결이 필요한지 기록하세요. 화면을 잠근 뒤에만 문제가 생긴다면 시스템의 백그라운드 관리부터 확인하세요. 화면이 켜져 있어도 끊긴다면 서버와 접속 네트워크를 살펴보세요. 복구 후의 ‘연결됨’ 상태만 확인하면 실제로 끊긴 시점을 놓칠 수 있습니다.

VPN 터널 끊김과 대상 서비스 세션 만료를 구분하세요

동영상 재생이 멈추거나 원격 업무 세션이 끊겼다고 해서 프록시 연결 전체가 해제된 것은 아닐 수 있습니다. 먼저 다른 웹페이지에 접속한 뒤 클라이언트 연결 상태와 해당 시점의 로그를 확인하세요. 다른 웹사이트가 정상이라면 대상 앱의 세션이 만료되었거나 서버가 연결을 종료했을 수 있습니다. 모든 접속이 동시에 실패하고 로그에 재연결이 나타난다면 VPN 터널이나 기반 네트워크가 끊겼을 가능성이 높습니다. 이 차이를 확인하면 설정 전체를 불필요하게 다시 만들 필요가 없습니다.

Wi-Fi에서 모바일 네트워크로 전환하거나 무선 액세스 포인트 사이를 이동하면 기기의 출구와 라우팅 경로가 바뀔 수 있습니다. 기존의 장시간 연결이 그대로 이어지지 않을 수 있으며 클라이언트가 다시 연결된 뒤 앱에서도 세션을 새로고침해야 할 수 있습니다. 테스트할 때는 먼저 동일한 네트워크에 고정해 가만히 둔 상태에서도 연결이 끊기는지 확인하세요. 네트워크 전환 때만 발생한다면 전환 방향과 복구 과정을 기록하고, 이동 중 상황과 고정 네트워크 상태를 한데 묶어 판단하지 마세요.

모바일에서는 백그라운드와 절전 설정부터 확인하세요

Android의 배터리 최적화, 백그라운드 활동 제한, 제조사별 작업 관리 기능으로 화면을 잠근 뒤 클라이언트가 종료될 수 있습니다. 시스템의 앱 설정에서 필요한 백그라운드 실행이 허용되어 있는지, 클라이언트에 필요한 알림 권한이 있는지 확인하세요. 시스템마다 메뉴 이름은 다를 수 있으므로 낯선 화면의 명칭을 그대로 찾기보다 기능을 확인하세요. 모든 절전 설정을 한꺼번에 끄지 말고 클라이언트 관련 항목부터 조정한 다음 화면을 잠가 다시 확인하세요. 그래야 변경 효과를 판단할 수 있습니다.

iOS에서는 일반적으로 시스템이 관리하는 네트워크 확장 기능을 통해 연결됩니다. 시스템 설정에서 현재 활성화된 구성이 무엇인지, 다른 네트워크 도구가 해당 구성을 대체하지 않았는지 확인하세요. 연결 아이콘이 표시되어도 대상 앱의 세션이 복구된 것은 아닙니다. 앱으로 돌아온 뒤 대상 콘텐츠를 다시 요청하세요. 구성 권한을 묻는 안내가 반복되면 중복되거나 오래된 구성이 있는지 먼저 확인하세요. 삭제 전에 현재 구성을 다시 가져올 수 있는지 확인하고, 유일하게 유효한 구성까지 함께 지우지 마세요.

앱 전환 화면에서 앱을 직접 종료하는 것은 평소처럼 백그라운드로 보내는 것과 다릅니다. 일부 시스템은 앱을 직접 종료한 것을 백그라운드 작업을 중단하라는 신호로 처리할 수 있습니다. 백그라운드 연결 끊김을 확인할 때는 자연스럽게 화면을 잠근 경우와 앱을 직접 종료한 경우를 따로 기록하세요. 배터리 부족 상태도 영향을 주는지 살펴보세요. 화면을 계속 켜 두는 것은 백그라운드 관리의 영향을 확인하기 위한 임시 비교 방법일 뿐, 최종 해결책은 아닙니다.

데스크톱에서는 절전 복귀, 인터페이스, 서비스를 확인하세요

Windows와 macOS는 절전 모드에서 복귀한 뒤 네트워크 인터페이스가 앱보다 늦게 복구되어 기존 연결이 일시적으로 끊길 수 있습니다. 기본 네트워크가 복구될 때까지 기다린 다음 클라이언트가 다시 연결되는지 확인하세요. 절전 모드에서 깨어난 뒤에만 실패한다면 구독을 바꾸기보다 클라이언트 로그의 인터페이스 변경과 서비스 상태를 확인하세요. Linux에서는 복귀 과정에서 네트워크 관리자가 인터페이스를 다시 만드는지, 백그라운드 서비스가 계속 실행 중인지도 살펴봐야 합니다. 확인 방법은 설치 방식에 따라 다릅니다.

네트워크가 고정되어 있고 기기가 절전 모드에 들어가지 않았는데도 연결이 자주 끊긴다면 다른 서버와 다른 접속 네트워크를 각각 비교하세요. 특정 서버에서만 발생하면 사용 가능한 대체 서버를 유지하고 해당 서버 문제를 문의하세요. 모든 서버에서 발생하지만 특정 네트워크에서만 문제가 생기면 공유기와 로컬 접속 환경을 확인하세요. 여러 프록시나 보안 도구가 네트워크를 제어하고 있다면 필요한 작업 환경을 유지한 채 관리자에게 허용된 방법으로 한 번에 하나씩 비교하세요. 인터페이스를 두고 도구들이 서로 충돌하지 않도록 주의해야 합니다.

군용급 암호화는 연결 보호 수준을 설명하는 표현이지, 기기 화면 잠금이나 네트워크 전환, 대상 서비스 세션이 절대 끊기지 않는다는 뜻은 아닙니다. 원활하게 복구하려면 시스템의 백그라운드 관리와 앱의 재연결 여부를 함께 확인해야 합니다.

연결 해제 문제를 문의할 때는 앱을 사용 중일 때, 화면을 잠갔을 때, 네트워크를 전환한 뒤 중 언제 끊겼는지와 당시 다른 웹페이지도 접속되지 않았는지 적으세요. 실제 시간과 시간대를 표시한 연결 전후의 연속 로그를 첨부하세요. 재연결에 성공한 뒤부터만 기록된 로그에는 원인이 나타나지 않을 수 있습니다. 먼저 사용 가능한 서버와 복구 방법을 확보하세요. 중요한 작업 중에 네트워크 설정을 반복해서 바꾸지 말고 작업을 마친 뒤 추가 테스트를 진행하세요.

구독 갱신 실패: 가져오기·파싱·적용 단계 구분

구독 갱신은 하나의 동작으로 끝나지 않습니다. 클라이언트가 먼저 설정 내용을 가져오고, 이를 사용 가능한 설정으로 파싱한 다음, 현재 사용 항목으로 지정합니다. 가져오기에 실패하면 네트워크나 계정 문제일 수 있습니다. 파싱에 실패하면 가져오기 방식이나 형식이 맞지 않을 수 있습니다. 갱신에 성공했는데도 이전 서버를 사용한다면 새 설정을 현재 항목으로 전환하지 않았을 수 있습니다. 오류가 어느 단계에서 발생하는지 먼저 확인한 뒤 패널에서 다시 가져올지, 클라이언트의 현재 설정을 처리할지 결정하세요.

패널에서 구독 출처와 계정을 확인하세요

계정 개요에서 현재 요금제와 트래픽 상태를 확인한 다음 패널에서 제공하는 경로로 구독을 가져오세요. 채팅 기록에 전달된 오래된 주소를 사용하거나 다른 사람이 보낸 설정을 본인 계정의 설정으로 사용하지 마세요. VPNStay는 이메일 주소 없이 사용자 이름과 비밀번호로 계정을 만들 수 있습니다. 문제를 확인할 때는 실제 사용 중인 계정으로 로그인했는지도 살펴보세요. 여러 계정 사이에서 요금제 상태를 잘못 확인할 수 있습니다.

구독 주소는 인증 정보처럼 취급하세요. 공개 포럼, 검색창, 온라인 형식 검사 사이트, 출처가 불분명한 도구에 붙여 넣지 마세요. 화면을 캡처할 때는 전체 주소와 가져오기 QR 코드를 가리고, 로그에 요청 주소가 포함되어 있으면 민감 정보를 삭제하세요. 고객 지원팀에 필요한 정보는 일반적으로 오류 유형, 클라이언트 환경, 발생 단계이며 전체 구독 인증 정보가 아닙니다. 주소가 노출된 것 같다면 패널에서 제공하는 관리 방법을 사용하고 이후 조치는 고객 지원팀에 문의하세요.

가져오기에 실패하면 네트워크와 복사한 내용을 확인하세요

패널에서 주소를 다시 복사한 뒤 공백, 줄바꿈, 안내 문구가 함께 복사되지는 않았는지 확인하세요. 일부 입력란은 구독 주소만 허용하고 공유 내용 전체를 붙여 넣을 수 없습니다. 반대로 일부 가져오기 메뉴는 로컬 설정 파일만 허용합니다. 현재 메뉴의 안내에 맞는 가져오기 방법을 선택하세요. 주소를 파일 내용으로 저장해 반복해서 가져오지 마세요. 패널은 정상적으로 열리는데 클라이언트에서 가져오지 못한다면 클라이언트의 갱신 요청이 오래된 프록시 설정을 통해 작동하지 않는 서버로 전달되는지 확인하세요.

일부 클라이언트에서는 현재 프록시를 통해 구독을 갱신하거나 직접 가져오도록 설정할 수 있습니다. 설정 이름은 실제 화면에서 확인하세요. 현재 서버가 작동하지 않는데 갱신 요청도 그 서버에 의존하면 스스로 해결할 수 없는 상황이 생깁니다. 먼저 기본 네트워크에서 패널에 접속할 수 있는지 확인한 다음 클라이언트가 지원하는 방식으로 갱신 경로를 조정하세요. 테스트를 위해 구독을 타사 변환 서비스에 맡기지 마세요. 정보 노출 위험이 커지고 설정 출처를 추적하기 어려워집니다.

파싱 오류와 이전 설정 잔존은 따로 확인하세요

설정 내용을 가져왔지만 파싱에 실패했다면 패널에서 안내하는 클라이언트 가져오기 방식을 선택했는지 먼저 확인하세요. 클라이언트마다 설정 형식과 지원 기능이 다를 수 있으며 이름이 비슷하다고 서로 대체할 수 있는 것은 아닙니다. 오류에 알 수 없는 필드나 지원되지 않는 유형이 언급되면 원문을 기록하고 클라이언트 출처를 확인하세요. 파싱을 통과시키려고 이해하지 못한 설정 필드를 바로 삭제하지 마세요. 연결은 되는 것처럼 보여도 필요한 라우팅이나 DNS 규칙이 사라질 수 있습니다.

갱신이 끝나면 새 설정이 현재 사용 중인 설정으로 지정되었는지 확인한 뒤 서버 목록과 연결 기록을 살펴보세요. 일부 클라이언트는 사용자가 직접 선택한 항목, 임시 규칙, 이전 서버 그룹을 유지하므로 갱신 후에도 개인 설정이 모두 초기화되지는 않을 수 있습니다. 현재 선택한 서버가 여전히 있는지, 수동으로 덮어쓴 항목이 있는지 확인하세요. 서버 수가 바뀌었는지만 보고 갱신 성공 여부를 판단하지 마세요. 수가 그대로여도 설정 매개변수만 변경되었을 수 있습니다.

다시 가져오기 전에 현재 설정의 출처 이름과 필요한 사용자 지정 규칙을 기록하세요. 백업은 신뢰할 수 있는 곳에 보관하세요. 구독 인증 정보가 포함된 파일을 일반 스크린샷이나 첨부 파일처럼 함부로 보내지 마세요.

트래픽 및 결제 문제는 재설치로 해결되지 않습니다

월간 구독 트래픽은 가입일을 기준으로 매월 초기화되므로 달력의 매월 첫날에 맞춰 임의로 계산하지 마세요. 트래픽 패키지는 소진할 때까지 유효하며 만료되지 않습니다. 만료되지 않는다는 것은 유효 기간에 관한 설명이지, 트래픽을 모두 사용한 뒤에도 남은 용량이 있다는 뜻은 아닙니다. 패널에 표시된 상태가 예상과 다르면 주문과 현재 계정을 먼저 확인한 다음 문의를 접수하세요. 클라이언트를 다시 설치해도 계정의 트래픽 한도는 바뀌지 않으며, 서로 다른 결제 방식이 자동으로 하나의 새 규칙으로 합쳐지지도 않습니다.

기본 네트워크가 정상이고 패널에 접속할 수 있는데도 다시 가져온 구독이 계속 실패한다면 가져오기 메뉴, 오류 단계, 클라이언트 플랫폼, 민감 정보를 가린 오류 원문을 문의에 적으세요. 이전 설정은 여전히 연결되는지, 가져오기·파싱·활성화 중 어느 단계에서 실패하는지도 알려 주세요. 처음 가져오기 과정을 다시 진행해야 한다면 빠른 시작 가이드를 참고하세요. iOS 클라이언트 다운로드 단계에서 막혔다면 iPhone 처음부터 설정하기도 확인할 수 있습니다. 다운로드 권한 문제와 구독 파싱 문제를 같은 문제로 취급하지 마세요.

특정 앱에서 프록시가 작동하지 않을 때: 트래픽 연결과 분할 터널링 점검

브라우저에서는 대상 웹페이지가 열리는데 특정 앱만 계속 실패한다면, 먼저 해당 앱의 요청이 클라이언트로 전달되는지 확인하세요. 시스템 프록시, 가상 네트워크 연결, 앱 자체 프록시는 서로 다른 방식입니다. 하나를 켰다고 모든 프로그램의 트래픽이 자동으로 처리되는 것은 아닙니다. 연결 로그를 살펴본 뒤 규칙을 확인할지 앱 설정을 확인할지 결정하세요. 요청 기록이 없다면 트래픽 연결을, 요청은 기록되지만 잘못된 서버로 전달된다면 분할 터널링을, 올바른 서버를 거쳤는데도 오류가 난다면 대상 서비스를 확인하세요.

시스템 프록시는 모든 앱을 제어하는 단일 스위치가 아닙니다

시스템 프록시는 일반적으로 시스템 설정을 따르는 앱에 프록시 연결 정보를 제공합니다. 일부 데스크톱 프로그램은 자체 네트워크 라이브러리를 사용하고, 일부 터미널 도구는 환경 변수만 읽으며, 또 다른 앱은 별도의 프록시 설정을 제공합니다. 따라서 브라우저가 정상이라고 모든 앱의 트래픽이 처리되고 있다고 볼 수는 없습니다. 앱의 공식 네트워크 설정 안내에서 지원하는 연결 방식을 확인하세요. 낯선 안내에서 고정 주소와 포트를 복사하지 마세요. 실제 값은 기기에 설치된 클라이언트 화면에서 확인해야 합니다.

클라이언트에 가상 네트워크 연결 기능이 있다면 가상 인터페이스를 통해 더 많은 트래픽을 처리할 수 있지만, 일반적으로 시스템 권한, 라우팅, DNS 설정도 관련됩니다. 기능을 켠 뒤에는 기본 네트워크와 대상 앱이 실제로 작동하는지 확인하세요. 스위치가 켜졌다는 이유만으로 성공했다고 판단하지 마세요. 조직에서 관리하는 기기이거나 업무용 터널을 함께 사용한다면 먼저 호환성 요건을 확인하세요. 특정 앱을 사용하려고 조직 네트워크의 접속 경로를 임의로 변경하지 마세요.

연결 로그에서 적용된 규칙을 확인하세요

대상 앱을 완전히 종료한 뒤 다시 실행하고, 페이지 새로고침이나 콘텐츠 불러오기처럼 명확한 동작을 한 번 실행하면서 연결 로그를 확인하세요. 대상 도메인, 프로세스 정보, 적용된 규칙, 실제 출구 서버를 살펴보세요. 기록이 바뀌지 않더라도 앱이 캐시나 기존 장시간 연결을 계속 사용할 수 있으므로 곧바로 클라이언트를 우회한다고 단정할 수는 없습니다. 새 요청이 실제로 발생했는지 확인한 뒤 브라우저에서 같은 서비스에 접속했을 때의 기록과 비교하세요.

직접 연결 규칙이 적용되었다면 사용자가 추가한 도메인 규칙, 프로세스 규칙, 지역 규칙이 있는지 확인하세요. 규칙에는 우선순위가 있어 먼저 적용된 항목이 뒤의 선택을 덮어쓸 수 있습니다. 사용자 지정 항목을 먼저 백업한 뒤 현재 대상과 관련된 규칙만 수정하고 앱 세션을 다시 설정하세요. 도메인 하나 때문에 전체 규칙 목록을 삭제하거나 모든 낯선 도메인을 프록시에 추가하지 마세요. 영향 범위가 커지고 이후 관리도 어려워집니다.

진단을 위해 잠시 더 넓은 범위의 프록시 모드로 전환하면 분할 터널링 문제인지 확인하는 데 도움이 됩니다. 다만 이는 진단용 비교일 뿐입니다. 전환 후 대상 앱이 작동한다면 규칙 모드로 돌아와 차이가 무엇인지 확인하세요. 계속 실패한다면 앱 자체의 프록시 설정, 연결 방식, 서버 측 제한을 추가로 점검하세요. 테스트가 끝나면 일상 사용에 적합한 모드로 되돌리세요. 로컬 기기, 업무 리소스, 로컬 네트워크 서비스에 함께 접속한다면 불필요한 전체 적용 설정이 남지 않도록 특히 주의하세요.

AI 도구, 동영상, 게임은 각각 따로 확인하세요

AI 도구는 로그인, 콘텐츠 요청, 실시간 응답 단계에서 서로 다른 도메인을 사용할 수 있습니다. 따라서 첫 화면이 열린다고 모든 기능이 작동하는 것은 아닙니다. 스트리밍 서비스는 계정 지역, 콘텐츠 권리, 접속 서버 판정의 영향을 받을 수 있으므로 서버를 바꾼 뒤 재생 세션을 다시 설정하세요. 게임이나 실시간 통신은 일반 웹페이지와 다른 전송 방식을 사용할 수 있습니다. 웹사이트 접속이 정상이라고 앱 호환성까지 확인된 것은 아닙니다. 제품 이름만 적기보다 구체적으로 어떤 동작에서 실패했는지 기록하세요.

앱 요청이 프록시를 거쳤는데 서버에서 계정이나 지역에 관한 명확한 안내를 반환했다면 원문을 보존하고 계정 상태와 대상 서비스 정책을 확인하세요. 로컬 네트워크 설정을 반복해서 지워도 서버의 판단은 달라지지 않을 수 있습니다. 스트리밍 문제라면 동영상 시청 및 지역별 접속 안내를 참고해 실제 콘텐츠로 확인하세요. 서버에 연결되었다고 모든 콘텐츠를 재생할 수 있는 것은 아닙니다. 웹사이트에서 반환한 안내 페이지를 연결 시간 초과로 오해하지 마세요.

Windows 데스크톱 앱의 전체 프록시 적용과 분할 터널링 차이는 Windows 클라이언트 점검 목록에서 확인할 수 있습니다. 판단 기준은 모드 이름이 아니라 기기에서 기록된 실제 연결 내역입니다.

고객 지원팀의 도움이 필요하면 앱 이름, 플랫폼, 수행한 동작, 오류 문구, 적용된 규칙을 알려 주세요. 브라우저에서 같은 서비스에 접속할 때는 정상인지도 함께 설명하세요. 로그에 비공개 세션 제목, 접속 경로, 계정 식별 정보가 있다면 먼저 가리세요. 비밀번호, 로그인 인증 정보, 전체 검색 기록은 보내지 마세요. ‘요청이 들어오지 않음’, ‘요청은 들어왔지만 잘못된 규칙이 적용됨’, ‘올바른 서버를 거쳤지만 대상에서 거부됨’ 중 어디에 해당하는지 설명하면 문제 범위를 좁히는 데 도움이 됩니다.

플랫폼 및 여러 기기: 기기 충돌과 제한 안내 구분

VPNStay는 Windows / macOS / iOS / Android / Linux를 지원하며 동시 접속 기기 수에 제한이 없습니다. ‘기기 수 초과’와 같은 안내가 표시되어도 VPNStay에 별도로 공개되지 않은 기기 제한이 있다고 바로 해석하지 마세요. 해당 안내는 클라이언트 자체, 시스템 네트워크 설정, 타사 앱, 대상 웹사이트에서 나타날 수 있습니다. 안내가 어느 창에 표시되었는지, 어떤 동작을 했는지 확인해 출처를 파악하세요. 안내를 없애려고 다른 기기를 함부로 삭제하지 마세요.

기기 수 안내가 어디서 왔는지 먼저 확인하세요

사용자 패널, 클라이언트, 대상 앱을 각각 확인해 실제로 어느 쪽에서 제한 안내를 반환했는지 파악하세요. 동영상 서비스나 업무 서비스에는 자체 세션 정책이 있을 수 있으며 이를 VPNStay의 동시 접속 정책과 혼동하면 안 됩니다. VPNStay 관련 동작에서 나타난 안내임을 확인했다면 전체 문구와 표시된 화면, 당시 계정 상태를 보존해 고객 지원팀에 문의하세요. 연결 기기를 늘리려면 요금제를 업그레이드해야 한다고 임의로 해석하거나 관련 없는 요금제를 변경하지 마세요.

여러 기기에서 동시에 문제가 생기면 유용한 비교 자료가 됩니다. 같은 공유기와 서버를 사용하던 여러 기기에서 비슷한 시간에 실패했다면 공통 네트워크와 서버를 먼저 확인하세요. 같은 조건에서 다른 기기는 정상인데 한 기기만 실패한다면 해당 기기의 권한, 설정, 백그라운드 상태를 우선 점검하세요. 비교할 때는 대상과 서버를 최대한 동일하게 맞추세요. 한 기기의 동영상 재생과 다른 기기의 웹페이지 로딩을 바로 비교하지 마세요.

플랫폼별 점검에서 놓치기 쉬운 항목

Windows에서는 클라이언트 창이 보인다고 백그라운드 서비스까지 정상이라는 뜻은 아닙니다. 프로그램을 종료해도 시스템 프록시가 자동으로 복구되지 않을 수 있습니다. 먼저 클라이언트 화면의 서비스 안내를 확인한 뒤 시스템의 현재 프록시 설정을 살펴보세요. macOS의 네트워크 확장 권한은 일반 앱의 실행 권한과 다릅니다. 시스템 업데이트나 이전 후에는 권한을 다시 확인해야 할 수 있습니다. 시스템 권한 안내가 명확히 표시되면 먼저 해당 권한을 처리하세요. 원격 서버를 사용할 수 없는 문제로 단정하지 마세요.

모바일에서는 시스템이 관리하는 네트워크 설정과 앱 화면에 표시된 상태를 구분해야 합니다. 다른 네트워크 도구를 활성화하면 기존 설정이 더 이상 실제 연결에 사용되지 않을 수 있으며, 백그라운드 연결이 끊기는 문제는 배터리 관리 설정과 함께 확인해야 합니다. Linux에서는 데스크톱 프록시 설정, 터미널 환경 변수, 백그라운드 서비스가 각각 독립적으로 작동할 수 있습니다. 브라우저는 정상인데 명령줄에서 실패하는 경우도 드물지 않습니다. 단순히 ‘Linux는 지원되지 않는다’고 적기보다 데스크톱 환경과 설치 방식을 기록하면 원인을 찾는 데 도움이 됩니다.

중복 클라이언트와 남아 있는 설정을 하나씩 정리하세요

네트워크를 제어하는 도구를 여러 개 동시에 실행하면 시스템 프록시가 반복해서 덮어써지거나 가상 인터페이스가 충돌하고 DNS 경로가 일치하지 않을 수 있습니다. 불필요한 도구를 먼저 종료하고 백그라운드 구성요소까지 실행 중인지 확인한 다음 현재 클라이언트를 테스트하세요. 업무에 필요한 소프트웨어라면 관리자에게 먼저 문의하세요. 무작정 제거하지 마세요. 도구 하나를 종료한 뒤 문제가 해결되면 충돌한 조합과 실행 순서를 기록해 향후 호환 설정에 활용하세요.

클라이언트를 다시 받아야 한다면 사용자 패널 다운로드를 이용하세요. Android, Windows, macOS, Linux는 로그인 후 다운로드할 수 있으며 iOS 링크는 유효한 요금제가 있어야 사용할 수 있습니다. 다운로드 권한과 네트워크 문제는 서로 다른 사안입니다. 다운로드 화면에 안내가 표시되면 먼저 필요한 조건을 확인하세요. 정적 설치 파일을 찾아 링크를 대체하거나, 오래된 클라이언트가 실행된다는 이유로 현재 패널의 가져오기 방식과 설정 방법이 일치하는지 확인하지 않은 채 사용하지 마세요.

재설치는 프로그램 파일이나 기기 상태에 문제가 있다고 확인된 경우에만 고려하세요. 일반적인 첫 단계가 아닙니다. 재설치 전에 구독 출처, 현재 규칙, 기존 시스템 프록시 설정을 기록하고 설정을 다시 가져올 수 있는지 확인하세요. 프로그램을 제거한 뒤에는 기본 네트워크를 먼저 확인한 다음 현재 구독을 가져오세요. 같은 설정이 다른 기기에서는 정상이고 이 기기에서 권한을 다시 허용한 뒤에도 실패한다면 플랫폼, 오류 문구, 이미 확인한 충돌 도구를 문의에 적어 주세요. 고객 지원팀이 처음부터 원인을 추측하지 않아도 됩니다.

문의 및 복구: 재현 조건을 명확히 전달하세요

문제 해결을 무한정 계속할 필요는 없습니다. 기본 네트워크와 계정 상태가 정상이고, 반복 가능한 서버 또는 기기 비교까지 마쳤다면 사용자 패널 문의로 도움을 요청할 수 있습니다. 계정 상태와 주문 내용이 일치하지 않거나, 현재 구독이 계속 파싱되지 않거나, 명확한 서버 오류 또는 비정상적인 인증서 안내가 나타나면 광범위한 설정 변경을 멈추고 문의하세요. 방향 없이 매개변수를 계속 바꾸면 원래 재현하기 쉬웠던 문제도 확인하기 어려워질 수 있습니다.

증상을 먼저 설명하고 확인한 항목을 이어서 적으세요

문의 첫머리에는 실제로 겪는 문제를 자연스럽게 설명하세요. 예: ‘클라이언트에는 연결 성공으로 표시되지만 대상 웹페이지가 계속 로딩 중이고 다른 페이지는 정상입니다.’ 이어서 대략적인 발생 시각과 시간대, 사용 플랫폼, 접속 네트워크 유형, 현재 서버 이름, 구체적인 오류를 적으세요. ‘너무 느림’, ‘사용 불가’라고만 쓰거나 원인을 서버 문제로 단정하지 마세요. 관찰한 증상과 추측을 나누어 적어야 고객 지원팀이 잘못된 전제를 바탕으로 되묻지 않고 근거에 따라 판단할 수 있습니다.

다음으로 비교 결과를 적으세요. 서버를 바꿨을 때 달라졌는지, 접속 네트워크를 바꿨을 때 달라졌는지, 같은 계정의 다른 기기는 정상인지, 클라이언트를 종료한 뒤 기본 웹페이지에 접속할 수 있었는지 알려 주세요. 각 항목에는 실제로 수행한 동작만 기록하고 테스트하지 않은 것은 아직 확인하지 않았다고 분명히 적으세요. 기기가 조직에서 관리된다면 그 사실도 알려 주세요. 실행하기 어려운 네트워크 초기화 조치를 권하지 않도록 하는 데 도움이 됩니다. 점검 기록은 조치 수가 아니라 조건의 명확성에 가치가 있습니다.

로그와 스크린샷에는 원인 파악에 필요한 내용만 남기세요

로그에는 실패 동작 전후의 기록이 포함되어야 하며 어느 부분이 문제 발생 시점인지 표시하세요. 마지막 오류 문장만 캡처하면 앞서 발생한 DNS 조회나 인터페이스 변경을 놓칠 수 있고, 장기간의 전체 로그에는 불필요한 정보가 들어갈 수 있습니다. 먼저 원본을 기기에 보관한 뒤 민감 정보를 가린 사본을 만드세요. 구독 주소, 가져오기 QR 코드, 계정 인증 정보, 비공개 대상 경로, 불필요한 로컬 네트워크 식별 정보는 가리되 오류 유형, 서버 이름, 시각은 남겨야 합니다. 이를 가리면 핵심 단서도 사라집니다.

고객 지원팀이 추가 진단 정보를 요청하면 사용 목적을 먼저 확인한 다음 현재 문제와 관련된 부분만 제공하세요. 비밀번호, 전체 구독 인증 정보, 계정에 직접 로그인할 수 있는 내용을 보내지 마세요. 출처가 불분명한 원격 스크립트도 실행하지 마세요. 시스템 프록시, 라우팅, DNS 변경 안내를 받으면 먼저 기존 값을 기록하고 되돌리는 방법을 확인하세요. 업무용 기기를 변경할 때는 소속 조직의 기기 관리 정책을 따라야 합니다.

문의 전 확인하세요. 같은 동작을 다시 했을 때 문제가 재현되나요? 실패한 순간 다른 웹페이지는 어떻게 작동했나요? 어떤 변경이 효과가 있었고 어떤 변경에는 차이가 없었나요? 이런 정보가 스크린샷을 더 많이 보내는 것보다 도움이 되는 경우가 많습니다.

복구 후 전체 이용 경로를 확인하세요

연결이 복구된 뒤에는 상태 표시등만 확인하지 마세요. 먼저 기본 웹페이지에 접속하고, 그다음 이전에 실패했던 대상을 확인한 뒤, 실제 앱에서 원래 하려던 작업을 완료해 보세요. 동영상 문제였다면 해당 콘텐츠를 다시 재생하고, 업무 연결 문제였다면 세션을 다시 설정하고, 백그라운드 문제가 있었다면 다시 화면을 잠가 확인하세요. 서버 변경으로 일시적으로 복구된 경우 기존 서버의 문제 기록을 남겨 두세요. 특정 설정을 되돌려 복구되었다면 효과가 있었던 변경을 기록하고 다른 최적화 설정을 곧바로 추가하지 마세요.

임시 진단 모드를 일상 사용에 적합한 상태로 되돌리고 시스템 프록시, DNS, 가상 네트워크 연결 설정이 서로 덮어쓰는 상태로 남지 않았는지 확인하세요. 터미널 환경 변수와 브라우저의 별도 DNS 설정도 실제 필요에 따라 다시 점검해야 합니다. 테스트 설정을 삭제하기 전에 현재 사용 중인 설정을 다시 가져올 수 있는지 확인하고 필요한 사용자 지정 규칙 설명은 보존하세요. 다음에 같은 문제가 생기면 모든 설정을 다시 하나씩 바꾸기보다 최근 변경 사항부터 확인할 수 있습니다.

결제·환불 문제와 이용 문제는 따로 확인하세요

문제가 요금제 상태나 트래픽과 관련된 것으로 확인되면 네트워크 매개변수를 계속 살펴보기보다 요금제 안내를 확인하세요. VPNStay는 Alipay / WeChat Pay / USDT 결제를 지원하며 60일 무조건 환불을 제공합니다. 구체적인 신청 방법은 환불 정책에서 확인하세요. 문제 해결 문의와 환불 신청은 각각 필요한 내용을 나누어 적을 수 있습니다. 네트워크 문제를 입증하려고 비공개 접속 내용을 제출할 필요는 없으며, 환불 안내를 모든 대상 서비스의 이용 가능성을 보장한다는 뜻으로 해석해서도 안 됩니다.

일상적인 관리는 간단하게 유지할 수 있습니다. 패널에서 최신 구독을 가져오고 신뢰할 수 있는 클라이언트 출처를 이용하며 네트워크를 중복해서 제어하는 도구를 줄이세요. 설정을 변경하기 전에는 기존 상태를 기록해 두세요. 처음 이용할 때는 빠른 시작 가이드를 참고하고, 간단한 질문은 도움말 센터에서 확인할 수 있습니다. 이 안내서의 목적은 복잡한 증상을 확인 가능한 작은 문제로 나누는 것입니다. 확인할 근거가 충분해지면 고객 지원팀에 자료를 전달하고 방향 없는 테스트를 계속할 필요는 없습니다.