Diagnostic baseline
전혀 연결되지 않을 때: 문제가 어느 단계에서 멈추는지 먼저 확인
“전혀 연결되지 않는다”는 여러 현상을 포함합니다. 클라이언트가 실행되지 않거나, 구독을 가져왔지만 회선이 보이지 않거나, 연결을 누르자마자 연결 안 됨 상태로 돌아가거나, 연결 과정이 오래 멈추거나, 시스템에는 연결된 것으로 표시되지만 트래픽이 전혀 흐르지 않는 경우입니다. 겉보기에는 비슷하지만 해결 경로는 다릅니다. 먼저 클라이언트에서 설정 화면이 정상적으로 열리는지, 구독에 포함된 회선 이름이 보이는지, 연결 버튼을 누르기 전과 후 중 언제 실패하는지 확인하세요. 클라이언트 자체가 열리지 않거나 권한 요청이 완료되지 않았다면 설치와 시스템 권한부터 처리하고, 회선 목록이 비어 있다면 구독 항목으로 이동합니다. 회선이 존재하는데 연결 동작만 실패할 때 네트워크와 회선을 점검하세요.
최소 테스트 환경 만들기
먼저 라우팅을 바꿀 수 있는 다른 도구를 모두 종료하세요. 시스템에 남아 있는 프록시 설정, 브라우저에 별도로 설정된 프록시, 기업 네트워크 클라이언트와 과거에 활성화했던 가상 네트워크 어댑터가 포함됩니다. 시스템 프록시나 터널 기능을 담당하는 프로그램을 동시에 두 개 실행하지 마세요. 나중에 실행한 프로그램이 기본 경로를 덮어쓰는 동안 먼저 실행한 프로그램이 도메인 해석을 계속 가로챌 수 있어, 화면은 모두 정상인데 트래픽의 출구가 불분명해질 수 있습니다. 이 프로그램들을 종료한 뒤 46VPN 클라이언트를 창에서 연결만 반복하지 말고 완전히 종료한 다음 다시 실행하세요.
그다음 테스트할 네트워크 진입점을 하나로 고정합니다. 현재 무선 네트워크를 사용 중이라면 테스트 중 계속 유지하고 다른 접속 방식으로 자주 바꾸지 마세요. 원래 접속할 수 있던 일반 웹페이지를 열어 기본 네트워크가 작동하는지 확인합니다. 46VPN에 연결하지 않은 상태에서 모든 웹페이지가 열리지 않는다면 문제는 로컬 네트워크 진입점에 있으므로, 회선을 바꿔도 유효한 결론을 얻을 수 없습니다. 기본 네트워크가 정상이라면 다른 사용 가능한 회선으로 다시 연결하세요. 이름만 보고 회선을 연속으로 모두 시도하지 말고, 먼저 다른 지역 또는 다른 회선 유형으로 바꿔 단일 회선 문제인지 연결 방식 전체의 문제인지 확인합니다. 전체 회선 범위는 글로벌 노드 페이지에서 확인할 수 있습니다.
시스템 권한 및 가상 네트워크 어댑터 확인
데스크톱 클라이언트는 일반적으로 가상 네트워크 인터페이스를 만들거나 사용해야 합니다. 처음 실행할 때 시스템 권한 확인 창에서 취소를 누르면 클라이언트와 회선 목록은 열리지만 터널이 설정되지 않을 수 있습니다. Windows에서는 네트워크 어댑터 목록에서 관련 가상 인터페이스가 존재하고 비활성화되지 않았는지 확인하세요. macOS에서는 시스템 네트워크 설정과 개인정보 및 보안 알림에서 네트워크 확장이 허용되었는지 확인합니다. Linux에서는 현재 계정에 클라이언트 실행에 필요한 네트워크 권한이 있는지 확인하세요. 잘 모르는 시스템 인터페이스를 함부로 삭제하지 말고, 먼저 클라이언트를 완전히 종료한 뒤 클라이언트 자체의 복구 또는 권한 재승인 절차를 이용하세요.
모바일 시스템에서는 VPN 구성을 확인하라는 메시지도 표시됩니다. 이전에 거부했거나 삭제했거나 시스템 네트워크 설정을 초기화했다면 클라이언트에서 다시 연결을 시작해 시스템의 구성 확인 창을 다시 띄워야 합니다. 연결 버튼을 누르자마자 원래 상태로 돌아가는 경우에는 시스템 구성이 허용되지 않았거나, 기존 구성이 비정상 상태이거나, 운영체제의 네트워크 보호 정책이 새 터널을 차단했을 가능성이 있습니다. 현재 클라이언트가 만들었지만 이미 유효하지 않은 구성만 먼저 삭제한 뒤 클라이언트에서 다시 생성하세요. 기업 또는 업무 환경에서 관리자가 설정한 항목은 삭제하지 마세요.
교차 테스트로 결론 좁히기
교차 테스트는 기기, 네트워크, 회선 세 가지 축으로 진행합니다. 기기와 네트워크를 고정하고 회선만 바꾸면 단일 회선 문제를 확인할 수 있습니다. 기기와 회선을 고정하고 네트워크를 바꾸면 진입 네트워크 문제를 확인할 수 있습니다. 네트워크와 구독을 고정하고 지원되는 다른 플랫폼의 기기로 바꾸면 로컬 환경 문제를 확인할 수 있습니다. 46VPN은 Windows, macOS, iOS, Android, Linux를 지원하며 기기 동시 접속 수가 제한되지 않으므로, 다른 기기를 먼저 삭제하지 않고 기존 기기를 비교에 활용할 수 있습니다.
같은 네트워크에서 모든 회선이 실패하지만 네트워크를 바꾸면 복구된다면 실패한 네트워크 유형, 웹 로그인 인증 필요 여부, 기업 또는 학교 네트워크 정책 유무를 기록하세요. 한 회선만 실패한다면 다른 회선으로 임시 전환하고 회선 이름과 실패 시간을 지원 담당자에게 전달합니다. 모든 기기·네트워크·회선에서 실패한다면 사용자 패널에서 계정과 구독을 정상적으로 읽을 수 있는지 확인한 뒤 구독 점검으로 이동하세요. 문제 해결 과정에서 처음부터 클라이언트를 반복 설치하지 마세요. 재설치는 로그, 설정과 재현 상태를 지우므로 권한이나 설정이 실제로 손상되었다는 근거가 있을 때 적합하며 진단을 대신할 수 없습니다.
Reachability and DNS
연결되지만 웹페이지가 열리지 않을 때: 라우팅·해석·브라우저 상태 구분
클라이언트에 연결 성공이라고 표시되는 것은 터널 또는 시스템 프록시가 작동 상태에 들어갔다는 의미일 뿐, 도메인 해석·기본 경로·브라우저 요청이 모두 올바르게 회선을 통과한다는 뜻은 아닙니다. 점검할 때는 모든 웹페이지가 열리지 않는지, 도메인만 열리지 않고 알고 있는 서비스에 직접 접속하면 응답하는지, 특정 웹사이트만 열리지 않는지, 브라우저만 열리지 않고 다른 앱은 작동하는지를 먼저 구분하세요. 이 범위에 따라 시스템 네트워크, DNS, 사이트 자체 또는 브라우저 확장을 확인해야 합니다. 특정 웹사이트의 점검, 계정 지역 제한 또는 로그인 상태 문제를 곧바로 회선 문제로 단정하지 마세요.
기본 요청을 먼저 확인한 뒤 도메인 해석 점검
연결한 뒤 용도가 다른 웹사이트 여러 곳을 열어 보세요. 모두 실패한다면 브라우저를 완전히 종료했다가 다시 열어, 연결 전 네트워크 세션을 계속 재사용하지 않도록 합니다. 그래도 실패하면 클라이언트를 통해 트래픽이 흐르는지, 시스템 프록시가 올바르게 활성화되었는지, 연결 모드가 특정 규칙만 프록시하는지 확인하세요. 이어서 터미널에서 도메인 해석을 점검합니다. 다음 예시는 공개 테스트 도메인을 사용하며 실제 구독 정보는 포함하지 않습니다.
nslookup example.com
ping example.com
nslookup 결과가 반환되면 시스템이 최소한 도메인 레코드를 가져올 수 있다는 뜻입니다. 서버를 찾을 수 없거나 요청 시간이 초과되거나 결과가 없다는 메시지가 나오면 DNS 경로 문제일 가능성이 큽니다. ping은 대상 서비스가 이런 탐색에 응답하지 않을 수 있어 응답을 받지 못할 수 있으므로 웹사이트 사용 가능성을 판단하는 유일한 기준으로 삼아서는 안 됩니다. 더 중요한 것은 명령이 도메인을 주소로 변환하는지 여부입니다. 도메인이 해석되는데도 브라우저가 실패한다면 DNS를 계속 바꾸기보다 프록시 라우팅, 브라우저 보안 DNS, 확장 프로그램과 캐시를 점검하세요.
캐시 정리 및 DNS 문제 처리
운영체제, 브라우저와 클라이언트 모두 도메인 결과를 캐시할 수 있습니다. 회선을 바꾼 뒤에도 이전 결과가 기존 접속 경로를 가리키면 연결은 갱신되었지만 페이지가 계속 실패할 수 있습니다. 먼저 브라우저를 완전히 종료한 다음 플랫폼에 맞게 시스템 캐시를 정리하세요. Windows에서는 다음을 사용할 수 있습니다.
ipconfig /flushdns
macOS에서는 터미널에서 시스템 캐시 갱신 명령을 실행할 수 있습니다.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
systemd-resolved를 사용하는 Linux 환경에서는 다음을 사용할 수 있습니다.
sudo resolvectl flush-caches
명령을 실행한 뒤 브라우저를 다시 열고 재현 테스트를 진행하세요. 브라우저에서 별도의 보안 DNS를 사용하면 시스템의 해석 경로를 우회해 시스템 테스트는 정상인데 브라우저만 이상해질 수 있습니다. 이 옵션을 잠시 꺼서 비교하고, 원인을 확인한 뒤 시스템 해석과 브라우저 지정 해석 중 어떤 방식을 사용할지 결정하세요. 여기서 “잠시 끄기”는 진단 변수일 뿐 장기 설정을 권장하는 의미가 아닙니다. 점검이 끝나면 자신에게 필요한 보안 수준에 맞는 설정으로 되돌리세요.
일부 웹사이트에만 영향을 줄 때 문제 범위를 넓히지 않기
단일 웹사이트가 열리지 않으면 먼저 시크릿 창에서 테스트해 기존 쿠키, 사이트 저장 데이터와 확장 프로그램의 영향을 제외하세요. 그다음 같은 지역의 다른 회선으로 전환해 출구 변화와 관련 있는지 확인합니다. 홈페이지는 열리지만 로그인·동영상 또는 API 요청이 실패한다면 실패한 구체적인 페이지와 동작을 기록하고 단순히 “웹사이트가 열리지 않는다”고만 쓰지 마세요. 서로 다른 하위 리소스가 다른 도메인을 사용할 수 있으므로 페이지의 기본 구조가 정상적으로 로드되었다고 후속 요청도 같은 경로를 사용한다는 뜻은 아닙니다. 개발자는 브라우저 네트워크 패널에서 실패 요청의 도메인, 상태와 장시간 대기 여부를 확인할 수 있지만, 문의할 때는 요청에서 계정 정보, 인증 필드와 개인 내용을 삭제해야 합니다.
모든 도메인이 실패하지만 46VPN을 종료하면 즉시 복구된다면 클라이언트가 시스템 트래픽을 완전히 처리하는 현재 모드인지, 시스템에 수동 프록시가 남아 있는지 확인하세요. Windows와 macOS에서는 시스템 네트워크 프록시 페이지에서 주소와 포트를 현재 클라이언트가 관리하는지 확인할 수 있습니다. 클라이언트를 종료한 뒤에도 프록시가 남아 있다면 잔여 설정을 먼저 끄고 클라이언트를 다시 실행하세요. 모바일에서는 연결을 끄고 네트워크 인터페이스를 잠시 껐다 켠 뒤 다시 연결해 시스템이 기본 경로를 새로 만들도록 합니다. 네트워크를 바꾼 뒤 증상이 나타났다면 이전 네트워크의 DNS와 새 터널이 동시에 남지 않도록 완전히 연결을 끊었다가 다시 연결하세요.
회선이 작동하는 것을 확인한 뒤 출구 IP 및 DNS 확인 방법에 따라 요청이 실제로 예상한 출구를 통과하는지 확인할 수 있습니다. 확인할 때는 클라이언트 버튼 색상에만 의존하지 말고 출구, DNS와 실제 앱을 함께 살펴보세요. 출구가 바뀌고 DNS도 해석되는데 특정 서비스가 계속 접속을 거부한다면 해당 서비스의 계정, 지역 정책 또는 사이트 상태 문제일 가능성이 크므로 별도로 처리해야 합니다.
Performance isolation
속도 저하와 피크 시간대 끊김: 진입점·회선·앱을 나눠 테스트
속도 문제는 “노드가 느리다”는 말로 쉽게 정리되지만 실제 경로에는 로컬 접속, 통신사 출구, 회선 진입점, 해외 구간, 대상 서비스와 단말 성능이 모두 포함됩니다. 어느 한 구간이 혼잡해도 로딩이 느려집니다. 먼저 연결하지 않은 상태에서 로컬 네트워크 기준선을 만든 뒤, 서로 다른 회선·시간대·앱을 비교해야 하며 한 번의 속도 측정 결과만 보아서는 안 됩니다. 속도 측정 도구는 자체적으로 대상 서버를 선택하므로 실제 사용하는 웹사이트와 완전히 다른 경로를 사용할 수 있습니다. 따라서 측정 페이지가 빠르다고 스트리밍, AI 도구 또는 코드 저장소도 반드시 빠른 것은 아니며 반대의 경우도 마찬가지입니다.
로컬 무선 네트워크와 백그라운드 트래픽부터 제외
연결 전후에 일반 웹페이지가 안정적으로 열리는지 확인하고 클라우드 드라이브 동기화, 시스템 업데이트, 대용량 다운로드와 로컬 네트워크 백업을 일시 중지하세요. 무선 신호가 흔들리면 VPN 터널은 기존 패킷 손실을 재전송과 멈춤으로 확대할 뿐입니다. 접속 지점 가까이 이동하고 여러 무선 접속점 사이를 오가지 않도록 하거나, 가능하다면 더 안정적인 로컬 연결로 비교하세요. 연결하지 않은 상태에서도 영상 화질이 낮아지거나 웹페이지가 간헐적으로 시간 초과되거나 원격 세션이 멈춘다면 먼저 진입 네트워크를 복구해야 합니다. 불안정한 기준선에서 회선을 아무리 바꿔도 신뢰할 수 있는 결론을 얻기 어렵습니다.
단말 성능도 암호화와 전달 속도에 영향을 줍니다. 한 기기에서만 느리고 같은 네트워크의 다른 기기는 정상이라면 절전 모드, 부족한 저장 공간, 바쁜 백그라운드 작업 또는 모든 네트워크 트래픽을 검사하는 보안 소프트웨어를 확인하세요. 브라우저에서 많은 페이지를 열었거나 개발자 도구가 요청을 계속 수집하거나 컨테이너·가상 머신이 네트워크를 사용 중이어도 체감 속도가 달라집니다. 테스트와 무관한 작업을 먼저 종료한 뒤 같은 대상 페이지로 다시 확인해 기기 부하를 회선 문제로 오인하지 않도록 하세요.
지명만 보지 말고 용도에 맞는 회선 선택
물리적 거리는 왕복 시간에 영향을 주지만 유일한 요소는 아닙니다. 대상 서비스의 배치 위치, 진입 통신사, 회선 유형과 당시 혼잡도도 중요합니다. 일본 지역 서비스를 이용할 때는 일본 및 인접 지역 회선을 먼저 비교할 수 있습니다. 미국 대상 개발 서비스를 이용할 때는 목표 지역에 가까운 곳이 라우팅이 더 안정적인 진입점보다 반드시 우수한 것은 아닙니다. 실제 용도를 기준으로 판단하세요. 웹 브라우징은 첫 응답과 연속 요청, 동영상은 지속 전송, 터미널 세션과 AI 코딩 도구는 장시간 연결의 안정성, 파일 전송은 지속 처리량을 중점적으로 봅니다.
| 사용 시나리오 | 우선 확인할 항목 | 흔한 오판 | 권장 조치 |
|---|---|---|---|
| 웹페이지 및 검색 | 첫 화면 응답, 연속 이동 | 최대 다운로드 속도만 확인 | 서로 다른 지역 회선에서 실제 페이지 비교 |
| 동영상 재생 | 지속 로딩, 이동 후 복구 | 홈페이지가 열리는지만 테스트 | 화질을 고정하고 연속 재생 확인 |
| 개발 및 터미널 | 장시간 연결, 요청 재시도 | 속도 측정이 빠르면 세션도 안정적이라고 판단 | 실제 저장소 또는 도구 작업으로 검증 |
| 파일 전송 | 지속 처리량, 중단 여부 | 순간 최대치로 전체 구간을 판단 | 다른 다운로드를 멈추고 단독 재측정 |
피크 시간대 끊김을 판단하는 근거
같은 기기·네트워크·대상 서비스가 다른 시간대에는 안정적이지만 피크 시간대마다 느려진다면 발생 시간대, 사용 회선, 대상 서비스와 증상 유형을 기록하세요. “로딩 시작이 느림”, “재생 중 멈춤”, “터미널 세션 끊김”처럼 적는 것이 단순히 “속도가 느림”이라고 쓰는 것보다 유용합니다. 그런 다음 다른 지역 또는 다른 회선 유형으로 비교하세요. 한 그룹의 회선만 전반적으로 영향을 받고 다른 그룹은 정상이라면 후자를 임시로 사용할 수 있습니다. 모든 회선이 동시에 느려진다면 로컬 통신사, 가정 네트워크 공유와 대상 서비스 자체의 부하도 확인해야 합니다.
46VPN은 90+개 국가와 200+개 회선을 지원하므로 일부 구간의 혼잡을 피할 선택지가 있지만, 모든 지역이 모든 목적지에 적합하다는 뜻은 아닙니다. 사용 중에는 자신의 네트워크에서 안정적인 후보 회선을 몇 개 저장하고 단일 출구에 장기간 의존하지 마세요. 회선이 복구된 뒤 기존 회선으로 다시 테스트하면 문제가 시간대와 관련 있는지도 확인할 수 있습니다. 특정 회선에서 같은 문제가 반복되면 회선 이름, 발생 시간대, 진입 네트워크와 대상 서비스를 지원 담당자에게 전달하는 것이 단독 속도 측정 화면 하나를 보내는 것보다 원인 파악에 도움이 됩니다.
트래픽 잔량도 확인해야 합니다. 월간 구독은 ¥9.9/월에 60GB, ¥18/월에 250GB, ¥28/월에 500GB가 포함되며 트래픽은 개통일을 기준으로 매월 초기화됩니다. 트래픽 패키지는 ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 소진될 때까지 사용하고 영구적으로 만료되지 않습니다. 계정의 트래픽 상태가 이상하다면 전송 불가를 회선 혼잡으로 오인하지 말고 사용자 패널에서 요금제를 먼저 확인하세요. 중간에 업그레이드하면 차액은 남은 일수에 따라 계산됩니다. 자세한 선택은 요금제 및 트래픽 패키지에서 확인할 수 있습니다.
Session continuity
잦은 연결 끊김과 모바일 백그라운드 끊김: 세션 수명 확인
잦은 연결 끊김은 먼저 터널이 실제로 끊긴 것인지, 앱의 장시간 연결이 재설정된 것인지, 기기의 네트워크 진입점이 바뀐 것인지 구분해야 합니다. 클라이언트에는 계속 연결됨으로 표시되지만 특정 메신저·터미널·동영상 앱이 다시 로드된다면 해당 앱의 세션만 만료된 것일 수 있습니다. 클라이언트 상태도 동시에 연결 안 됨으로 바뀌어야 터널 중단에 더 가깝습니다. 끊김이 화면 잠금, 절전, 무선 네트워크 전환, 특정 접속점 이탈 또는 절전 상태 진입 직후에 반복되는지도 관찰하세요. 명확한 트리거가 있는 문제는 시스템 설정으로 해결할 수 있는 경우가 많고, 무작위로 나타나는 문제는 로그와 여러 회선 비교가 더 필요합니다.
데스크톱에서는 절전과 네트워크 전환부터 확인
데스크톱 기기가 절전에서 복귀할 때 기존 네트워크 인터페이스가 이미 새 주소를 받았지만 클라이언트는 절전 전 터널 상태를 유지할 수 있습니다. 이때 화면에는 잠시 연결됨으로 표시되어도 요청이 올바르게 라우팅되지 않을 수 있습니다. 복귀 후 웹페이지가 열리지 않으면 바로 시스템을 재시작하지 말고 먼저 연결을 끊었다가 다시 연결하세요. 절전 후 매번 재현된다면 클라이언트가 시스템 시작 후 실행되도록 허용되어 있는지, 네트워크 복구 후 자동 재연결이 가능한지, 운영체제가 절전 중 네트워크 어댑터를 끄는지 확인하세요.
무선 네트워크가 여러 접속점 사이를 전환해도 하위 연결이 바뀔 수 있습니다. 네트워크 이름이 같아도 기기가 다른 경로로 이동할 수 있어 기존 터널을 다시 만들어야 합니다. 점검할 때는 한 위치에 고정하고 다른 네트워크에 자동으로 연결되는 옵션을 끈 뒤 끊김이 사라지는지 관찰하세요. 유선과 무선을 동시에 연결한 기기에서는 운영체제가 두 연결의 우선순위를 자동으로 바꾸지 않도록 합니다. 특정 진입점에서만 끊기면 진입 네트워크나 라우터 문제일 수 있고, 모든 진입점에서 발생하면 클라이언트·시스템 권한·회선을 점검하세요.
모바일 백그라운드 정책이 주요 변수
모바일 운영체제는 배터리 절약을 위해 백그라운드 활동을 제한합니다. 화면이 꺼진 뒤 시스템이 클라이언트를 정지하거나 네트워크 작업을 지연하거나 세션을 회수하면 화면을 다시 켰을 때 잠시 사용할 수 없게 됩니다. Android에서는 앱 배터리 정책, 백그라운드 실행 권한, 데이터 절약 모드와 시스템의 앱 절전 기능을 확인하고 클라이언트가 필요한 백그라운드 실행을 허용받도록 설정하세요. 제조사마다 메뉴 이름이 다를 수 있으므로 특정 경로보다 “배터리”, “백그라운드”, “자동 시작”, “데이터 사용량”을 기준으로 찾으세요. 조정한 뒤 화면을 잠그고 기다렸다가 실제로 사용하는 앱을 다시 열어 확인합니다.
iOS에서는 시스템에 VPN 구성이 남아 있는지 확인하고 저전력 모드, 네트워크 전환과 주문형 연결 동작을 점검하세요. 무선 네트워크와 모바일 네트워크를 전환한 뒤에만 문제가 나타난다면 완전히 연결을 끊고 새 네트워크가 안정된 후 다시 연결합니다. 신호가 계속 바뀌는 동안 연결을 연속해서 누르지 마세요. 시스템이 이전 세션 정리와 새 세션 생성을 동시에 처리해 화면 상태와 실제 라우팅이 잠시 어긋날 수 있습니다. 백그라운드 복귀 후 한 앱만 실패한다면 해당 앱을 종료하고 다시 여세요. 모든 앱이 실패할 때는 터널을 다시 연결합니다.
| 플랫폼 | 중점 확인 사항 | 재현 방법 | 우선 처리 |
|---|---|---|---|
| Windows | 어댑터 절전, 절전 복귀, 잔여 프록시 | 절전 복귀 후 같은 웹페이지 열기 | 재연결 후 네트워크 어댑터 상태 확인 |
| macOS | 네트워크 확장 권한, 무선 전환, 시스템 프록시 | 화면 잠금 또는 접속 네트워크 전환 후 재현 테스트 | 확장 권한 확인 및 연결 재설정 |
| Android | 배터리 최적화, 백그라운드 제한, 데이터 절약 | 화면 잠금 후 대상 앱 다시 열기 | 필요한 백그라운드 실행 허용 |
| iOS | 시스템 구성, 저전력 모드, 네트워크 전환 | 네트워크 전환 후 모든 앱 확인 | 네트워크가 안정된 뒤 다시 연결 |
| Linux | 네트워크 관리자, 절전 훅, 해석 서비스 | 세션 복구 후 라우팅과 DNS 확인 | 연결을 재시작하고 기본 경로 확인 |
회선 중단과 앱 재연결 구분
일반 웹페이지 하나와 장시간 연결 앱 하나를 동시에 관찰하세요. 웹페이지는 계속 사용할 수 있는데 장시간 연결 앱만 끊긴다면 앱 세션, 하트비트 또는 대상 서비스 문제일 가능성이 큽니다. 둘 다 동시에 실패하고 클라이언트가 다시 연결된다면 회선이나 진입 네트워크 변동에 더 가깝습니다. 같은 동작을 유지한 채 다른 회선으로 바꿔 보세요. 증상이 회선을 따라 사라지면 기존 회선을 기록하고, 같은 네트워크에서 모든 회선이 끊기지만 네트워크를 바꾸면 정상이라면 진입 네트워크를 기록합니다. 이런 결과가 “자주 끊긴다”는 표현보다 훨씬 구체적으로 활용할 수 있습니다.
끊김이 계정의 동시 접속 기기와 관련 없다면 기기를 삭제하며 시행착오를 겪을 필요도 없습니다. 46VPN은 동시 접속 기기 수가 제한되지 않으므로 여러 개인 기기가 정상적으로 연결된다고 기기 수를 초과하는 것은 아닙니다. 실제로 확인할 항목은 여러 기기가 동시에 대량 전송을 하는지, 가정의 진입 네트워크가 혼잡한지, 특정 기기가 계속 재연결하며 국지적인 간섭을 만드는지입니다. 기기 비교는 장애 범위를 확인하기 위한 것이며 비워야 하는 제한 항목이 아닙니다.
Subscription state
구독 업데이트 실패와 기기 이상 알림: 출처부터 로컬 캐시까지 확인
구독 업데이트 실패는 보통 “사용자 패널에서 구독 정보 생성”, “클라이언트의 구독 접근”, “클라이언트의 내용 해석”, “새 설정의 로컬 저장” 중 한 단계에서 발생합니다. 먼저 계정에 정상적으로 로그인할 수 있고 패널에서 요금제 상태와 트래픽 정보를 읽을 수 있는지 확인하세요. 46VPN은 이메일 주소 없이 사용자 이름과 비밀번호만으로 가입할 수 있으므로 계정 문제를 점검할 때는 실제 사용자 이름을 기준으로 확인해야 합니다. 인증 정보를 잊었거나 로그인 상태가 이상하다면 패널의 계정 절차를 이용하고 새 계정을 반복해서 만들지 마세요. 요금제와 구독이 서로 다른 계정에 흩어질 수 있습니다.
구독 출처와 접근 경로 확인
클라이언트와 구독 정보는 모두 사용자 패널에서 받아야 합니다. 다른 사람이 전달한 주소, 스크린샷 속 텍스트 또는 오래전에 저장한 제3자 기록을 사용하지 마세요. 홍보 페이지에는 정적 설치 패키지 직접 링크나 공개 구독 주소가 제공되지 않습니다. 패널에 들어가야 계정에 맞는 클라이언트와 구독 정보를 받을 수 있습니다. 구독이 예전에는 갱신되다가 갑자기 실패했다면 패널로 돌아가 현재 접속 경로를 다시 복사하세요. 이미 만료되었거나 잘렸거나 불필요한 공백이 포함된 이전 내용을 계속 사용하지 마세요.
복사할 때 텍스트가 처음부터 끝까지 완전한지 확인하고, 쿼리 매개변수를 직접 수정하지 마세요. 메신저가 자동으로 만든 미리보기 문구를 주소로 사용해서도 안 됩니다. 형식을 설명하기 위해 아래에는 명확한 예시 값만 사용하며 실제 연결에는 사용할 수 없습니다.
https://example.com/sub?token=YOUR_TOKEN
브라우저에서는 구독 진입점에 접근할 수 있지만 클라이언트만 업데이트되지 않는다면 클라이언트 가져오기 방식, 형식 호환성 또는 로컬 캐시 문제일 가능성이 큽니다. 브라우저와 클라이언트 모두 접근할 수 없다면 계정 상태, 현재 네트워크와 진입점의 유효성을 확인하세요. 실제 구독 내용을 공개 포럼이나 공개 문의 스크린샷에 붙여 넣지 마세요. 구독 진입점은 계정 인증 정보의 일부이므로 유출되었다면 문제 해결을 위해 계속 공유하지 말고 사용자 패널에서 제공되는 절차에 따라 갱신하세요.
캐시, 중복 설정과 해석 실패 처리
업데이트 전에 현재 사용할 수 있는 회선을 기록해 정리 후 되돌아갈 경로를 남기세요. 먼저 클라이언트 내부에서 구독 업데이트를 실행하고 설정을 직접 삭제하지 마세요. 형식 오류가 표시되면 웹페이지 주소, 따옴표가 포함된 텍스트 또는 불완전한 내용을 가져오지 않았는지 확인합니다. 네트워크 오류라면 기본 네트워크가 정상인 환경으로 바꿔 재시도하세요. 저장 실패라면 클라이언트에 설정 저장에 필요한 시스템 권한이 있는지 확인합니다. 로컬 설정이 손상되었다는 사실을 확인했을 때만 해당 이전 구독을 삭제하고 다시 가져오세요.
클라이언트에 같은 이름의 구독이 여러 개 있으면 이전 항목을 업데이트하고도 다른 항목의 회선에 연결할 수 있습니다. 구독 업데이트 시간, 회선 이름과 출처를 비교해 현재 유효한 항목을 남기고 명확하게 중복되거나 만료된 사본을 삭제하세요. 작업 전에 계정 인증 정보가 포함되지 않은 설정 설명을 내보내거나 회선 이름을 기록하는 것이 좋습니다. 다시 가져온 뒤에도 회선이 비어 있다면 클라이언트 오류 원문과 구독 업데이트 시간을 보존해 지원 담당자에게 전달하고, 서버 응답과 클라이언트 해석이 일치하는지 확인을 요청하세요.
기기 수 초과 알림 판단 방법
46VPN의 동시 접속 기기 수는 제한되지 않으므로 개인 기기를 정상적으로 사용할 때 “기기 수 초과”를 요금제 규칙으로 보아서는 안 됩니다. 클라이언트, 시스템 또는 다른 소프트웨어에서 비슷한 알림이 표시되면 먼저 알림의 출처를 확인하세요. 46VPN 사용자 패널인지, 현재 클라이언트인지, 운영체제인지, 동시에 실행 중인 다른 네트워크 도구인지 구분해야 합니다. 스크린샷에는 창 제목과 전체 알림 영역이 포함되어야 출처를 판단할 수 있습니다. 46VPN에서 보낸 알림이 아니라면 해당 소프트웨어나 시스템 환경에서 처리하세요.
사용자 패널에 동시 접속 기기 수 제한과 맞지 않는 상태가 실제로 표시된다면 기기를 삭제하거나 요금제를 반복 구매하지 말고 바로 문의를 제출하세요. 문의에는 계정 사용자 이름, 요금제 이름, 알림이 나타난 플랫폼, 조작 경로와 전체 스크린샷을 첨부하되 비밀번호나 구독 진입점은 포함하지 마세요. 지원 담당자는 클라이언트를 재설치해 문제를 가리는 대신 계정 측 상태를 확인해야 합니다. 여러 플랫폼에서 같은 알림이 나타났다면 Windows, macOS, iOS, Android 또는 Linux 중 영향을 받은 플랫폼을 명시하세요. 한 플랫폼에서만 나타났다면 해당 클라이언트의 로컬 캐시와 로그인 계정이 올바른지도 함께 확인합니다.
결제 상태를 확인해야 한다면 사용자 패널의 주문 기록을 기준으로 삼으세요. 46VPN은 Alipay, WeChat Pay, USDT를 지원합니다. 결제 관련 문의를 제출할 때 주문 상태, 결제 방식과 패널에 표시된 주문 식별자를 제공할 수 있지만 결제 비밀번호, 전체 계정 인증 정보 또는 확인과 무관한 개인 정보는 보내지 마세요. 요금제 선택이 확실하지 않다면 먼저 가격 및 요금제 안내를 읽으세요. 본 서비스는 60일 무조건 환불을 제공하며 환불 문제는 사이트 약관에 따라 패널 문의로 처리해야 합니다. 확인을 위해 주문을 반복해서 생성하지 마세요.
Application routing
특정 앱만 프록시를 통과하지 않을 때: 모드·프로세스·독립 네트워크 스택 확인
브라우저는 접속되고 출구도 바뀌었지만 특정 앱만 기존 네트워크를 계속 사용하거나 전혀 연결되지 않는다면 전체 회선보다 앱 라우팅에 문제가 있을 가능성이 큽니다. 앱이 시스템 프록시를 읽지 않거나, 독립 DNS를 사용하거나, 특정 유형의 연결을 직접 만들거나, 보조 프로세스를 실행하거나, 연결 전에 이미 세션을 만든 것일 수 있습니다. 먼저 “이 앱만 이상한지”를 증명하세요. 같은 기기의 브라우저와 다른 앱을 비교해 시스템 전체가 정상인지 확인한 뒤 해당 앱의 네트워크 동작을 점검합니다. 모든 앱이 동시에 실패한다면 웹페이지 및 DNS 항목으로 돌아가세요.
앱 세션부터 다시 만들기
많은 앱은 실행 시 시스템 프록시를 읽고 기존 연결을 계속 재사용합니다. 46VPN에 연결하기 전에 앱을 열었다면 새 경로로 자동 전환되지 않을 수 있습니다. 트레이 프로세스, 메뉴 막대 프로세스와 백그라운드 보조 서비스를 포함해 앱을 완전히 종료한 뒤 46VPN에 연결하고 다시 실행하세요. 창만 닫으면 백그라운드 프로세스가 종료되지 않는 경우가 많습니다. 개발 도구, 게임 플랫폼, 메신저와 동기화 소프트웨어는 특히 백그라운드에 계속 남으므로 시스템 작업 관리 화면에서 프로세스가 종료되었는지 확인하세요.
다시 시작한 뒤 앱 자체의 계정 새로 고침, 콘텐츠 로딩 또는 네트워크 진단 기능으로 재확인하세요. 복구되었다면 원인은 이전 세션이므로 전역 설정을 바꿀 필요가 없습니다. 그래도 실패한다면 앱에 “시스템 프록시 사용”, “프록시 자동 감지”, “직접 연결” 또는 사용자 지정 네트워크 설정이 있는지 확인하세요. 보통은 앱이 시스템 설정을 따르도록 하는 것이 우선입니다. 이전 프록시 주소가 저장되어 있다면 삭제하세요. 의미를 모르는 상태에서 시스템 프록시와 앱 프록시를 동시에 설정하지 마세요. 중복 전달이 발생하거나 이미 닫힌 로컬 포트로 요청이 전송될 수 있습니다.
규칙 모드와 전체 모드 비교
클라이언트가 규칙 모드를 사용하면 해당 규칙과 일치하는 요청만 회선을 통과합니다. 앱이 사용하는 도메인, 주소 또는 프로토콜이 규칙에 포함되지 않으면 기존 네트워크로 나갑니다. 진단할 때는 일시적으로 더 넓은 범위를 포함하는 연결 모드로 바꿔 비교할 수 있습니다. 앱이 바로 복구되면 규칙 매칭 문제이고, 여전히 복구되지 않으면 앱 네트워크 스택과 시스템 권한을 계속 확인하세요. 비교가 끝나면 원래 모드로 되돌린 뒤 앱 도메인이나 프로세스에 맞게 규칙을 조정해 다른 앱의 경로를 장기간 바꾸지 않도록 합니다.
클라이언트가 앱별 선택을 지원한다면 대상 앱 본체와 보조 프로세스가 모두 포함되어 있는지 확인하세요. 브라우저는 보통 주요 프로세스 이름 하나만 사용하지만 개발 도구는 실행기, 백그라운드 서비스와 런타임이 함께 요청을 만들 수 있습니다. 보이는 주 프로그램만 선택하면 다운로드·로그인·업데이트 모듈이 직접 연결될 수 있습니다. 시스템 작업 관리 도구에서 앱 실행 후 추가된 관련 프로세스를 확인하고, 클라이언트의 앱별 기능에 맞춰 설정하세요. 출처가 불분명한 규칙 전체를 복사하지 말고 실제 앱과 도메인을 중심으로 규칙을 구성해 유지 관리하기 쉽게 하세요.
| 증상 | 가능한 범위 | 확인 방법 | 처리 방향 |
|---|---|---|---|
| 브라우저는 정상인데 앱에 로그인할 수 없음 | 앱이 시스템 프록시를 읽지 않음 | 연결 후 앱을 완전히 종료하고 다시 열기 | 시스템 프록시 따르기 활성화 또는 앱별 설정 확인 |
| 앱 홈페이지는 정상인데 다운로드 실패 | 보조 프로세스 또는 리소스 도메인이 규칙과 일치하지 않음 | 실패 동작에 해당하는 프로세스와 요청 관찰 | 프로세스 또는 도메인 규칙 추가 |
| 전체 모드로 전환하면 복구됨 | 규칙 매칭 범위 부족 | 원래 모드로 복구한 뒤 다시 재현 | 대상 서비스에 맞게 규칙 수정 |
| 업데이트 모듈만 실패 | 업데이트 프로그램이 독립적으로 실행됨 | 백그라운드에 추가된 프로세스 확인 | 업데이트 프로그램도 같은 네트워크 경로 사용 |
개발 도구와 명령줄의 특수한 경우
터미널 프로그램은 그래픽 인터페이스의 브라우저 프록시 설정을 자동으로 읽지 않는 경우가 많습니다. 일부 명령은 환경 변수를 읽고, 다른 도구는 자체 설정 파일을 사용하며, 시스템 라우팅을 그대로 따르는 도구도 있습니다. 브라우저는 정상인데 명령줄만 실패한다면 먼저 클라이언트가 제공하는 것이 시스템 프록시인지 가상 네트워크 어댑터를 통한 처리인지 확인하세요. 환경 변수를 설정해야 한다면 클라이언트 화면에 명확히 표시된 로컬 주소와 포트만 사용하고, 다른 안내에서 고정값을 복사하지 마세요. 다음 예시는 변수 형식만 보여 주며 임의의 포트는 제공하지 않습니다.
export HTTP_PROXY="http://LOCAL_PROXY"
export HTTPS_PROXY="http://LOCAL_PROXY"
unset HTTP_PROXY
unset HTTPS_PROXY
진단이 끝나면 unset을 사용해 임시 변수를 삭제하고, 클라이언트가 종료된 뒤에도 터미널이 유효하지 않은 주소를 계속 가리키지 않도록 하세요. Git, 패키지 관리자, 컨테이너 환경과 통합 개발 도구도 각자 프록시 설정을 저장할 수 있으므로 단계별로 확인해야 합니다. 컨테이너의 네트워크 환경은 호스트와 다르므로 호스트에서 접속된다고 컨테이너도 자동으로 상속되는 것은 아닙니다. 원격 개발 환경에서는 요청이 로컬에서 실행되는지 원격 호스트에서 실행되는지도 확인하세요. 요청 실행 위치를 먼저 정한 뒤 어느 쪽에 네트워크를 설정할지 결정하면 로컬에서 반복 수정해도 계속 실패하는 상황을 피할 수 있습니다.
AI 코딩 도구는 장시간 연결, 터미널 세션과 보조 프로세스의 영향을 크게 받을 수 있으므로 AI 코딩 도구용 VPN 선택 및 안정성 안내를 추가로 확인하세요. 브라우저에서 로그인한 뒤 클라이언트로 돌아오는 방식이라면 브라우저 콜백, 클라이언트 주 프로세스와 백그라운드 서비스가 일관된 네트워크 경로를 사용하는지도 함께 점검하세요. 특정 계정만 실패하고 다른 계정은 정상이라면 계정 지역, 서비스 정책과 네트워크 장애를 분리해 판단하고 프록시 범위를 계속 넓히지 마세요.
Escalation and recovery
고객 지원에 문의할 때: 장애를 재현 가능한 문의로 정리하기
문제 해결은 무한 반복이 아닙니다. 기본 네트워크 확인, 단일 변수 전환과 교차 테스트를 마친 뒤 문제가 안정적으로 재현된다면 설정을 무작위로 더 바꾸는 것은 현장 상태만 훼손합니다. 문의에 적합한 경우는 여러 네트워크에서 여러 회선이 같은 연결 실패를 보일 때, 특정 회선만 계속 이상하고 다른 회선은 정상일 때, 사용자 패널의 동시 접속 기기 수·트래픽 또는 주문 상태가 실제 규칙과 다르게 표시될 때, 구독 진입점은 접근되지만 클라이언트가 계속 해석에 실패할 때, 시스템 권한을 확인했는데도 클라이언트가 연결을 만들지 못할 때, 전체 라우팅 모드에서도 같은 앱이 안정적으로 실패할 때입니다.
문의에 반드시 포함할 상황 정보
처리 가능한 문의는 결론보다 증상을 먼저 명확히 적어야 합니다. “연결을 누르면 클라이언트가 연결 안 됨 상태로 돌아감”, “연결 후 모든 도메인을 해석할 수 없음”, “화면 잠금에서 복귀하면 모든 앱의 네트워크가 끊김” 또는 “특정 앱의 로그인 요청만 실패함”처럼 작성하세요. 이어서 영향을 받은 플랫폼을 Windows, macOS, iOS, Android, Linux 중 실제 항목으로 밝히고, 현재 네트워크 유형, 회선 이름, 발생 시간대, 매번 재현되는지, 마지막 정상 사용 이후 어떤 변경을 했는지 설명합니다.
그다음 이미 완료한 비교를 나열하세요. 회선을 바꿨는지, 네트워크를 바꿨는지, 다른 기기는 정상인지, 다른 앱은 정상인지, 종료 후 다시 열면 복구되는지, DNS 캐시를 정리했을 때 결과가 달라졌는지 적습니다. 문의를 완전하게 보이게 하려고 확인하지 않은 결론을 넣지 말고 실제로 수행한 동작만 작성하세요. 웹사이트나 앱 문제라면 서비스 이름, 실패한 동작과 오류 원문을 제공하고, 구독 문제라면 클라이언트에 표시된 오류 유형과 업데이트 시간을 제공하되 실제 구독 진입점은 붙여 넣지 마세요.
복사해 사용할 수 있는 문의 양식
문제 증상:
영향받은 플랫폼:
현재 네트워크:
선택한 회선:
영향받은 앱 또는 웹사이트:
안정적으로 재현되는가:
완료한 비교:
오류 원문:
제공 가능한 비식별화 스크린샷 또는 로그:
스크린샷·로그와 개인정보 경계
스크린샷에는 클라이언트 상태, 회선 이름, 오류 알림과 필요한 시스템 시간 정보가 포함되어야 하지만 사용자 이름 이외의 민감한 계정 정보는 가려야 합니다. 비밀번호, 구독 진입점, 결제 정보, Cookie, 인증 토큰과 개인 통신 내용은 첨부하지 마세요. 로그를 제출하기 전에 전체 요청 주소나 계정 필드가 포함되어 있는지 검색하세요. 클라이언트가 비식별화 내보내기를 제공한다면 해당 방식을 우선 사용합니다. 로그 내용을 확인할 수 없다면 문의에 로그를 제공할 수 있다고 먼저 적고 지원 담당자에게 필요한 범위를 안내받으세요.
네트워크 진단 스크린샷에는 테스트 조건이 드러나야 합니다. 특정 웹사이트 실패 화면을 제출할 때 다른 웹사이트가 정상인지, 현재 연결 중인지, 어떤 회선을 사용하는지도 함께 적으세요. 오류 페이지 한 장만으로는 대상 서비스, DNS, 회선과 브라우저 중 무엇이 문제인지 구분할 수 없습니다. 속도 문제도 속도 측정 페이지만 첨부하지 말고 실제 앱에서의 상태, 연결하지 않았을 때 정상인지, 회선을 바꾼 뒤 어떤 차이가 있는지 설명하세요. 잦은 연결 끊김은 화면 잠금, 절전 또는 네트워크 전환과 관련 있는지도 작성해야 합니다.
처리 대기 중 되돌릴 수 있는 상태 유지
문의 제출 후에는 이미 사용 가능하다고 확인한 예비 회선을 우선 사용하고 모든 설정을 계속 삭제하지 마세요. 장애를 재현할 수 있는 회선 이름과 조작 경로는 보존하면서 일상적인 사용은 안정적인 후보로 전환하세요. 특정 앱에서만 문제가 발생한다면 전체 시스템을 바꾸지 말고 원래 규칙으로 잠시 되돌린 뒤 다른 사용 가능한 방식으로 작업을 진행합니다. 구독 업데이트 문제인데 기존 회선은 여전히 사용할 수 있다면 새 구독이 정상적으로 가져와졌는지 확인할 때까지 이전 설정을 보존하세요.
큰 변경을 하기 전에 클라이언트 연결 모드, 시스템 프록시 활성화 여부, DNS를 시스템이 관리하는지, 구독 항목 이름과 사용 가능한 회선을 기록하세요. 시도에 효과가 없어도 알려진 상태로 돌아갈 수 있습니다. 네트워크 초기화, 클라이언트 데이터 삭제와 재설치는 영향 범위가 큰 작업이므로 권한·캐시·설정 문제에 명확한 근거가 생긴 뒤로 미루세요. 실행 전에 계정 인증 정보가 작동하는지 확인하고 사용자 패널에서 클라이언트와 구독 정보를 다시 받는 경로를 확인하세요.
복구 후 한 번 더 전체 흐름 확인
문제가 복구된 것처럼 보여도 클라이언트의 연결 표시만 보지 말고 원래 실패했던 동작을 다시 실행하세요. 연결 문제는 일반 웹페이지와 대상 앱이 모두 작동하는지 확인하고, DNS 문제는 도메인 해석과 출구 경로가 복구되었는지 확인합니다. 속도 문제는 실제 용도에서 지속 성능을 관찰하고, 모바일 문제는 화면 잠금과 네트워크 전환이라는 원래 트리거를 거쳐 확인하세요. 구독 문제는 회선 목록이 업데이트되었고 연결 가능한지 확인하며, 앱 라우팅 문제는 주 프로세스와 보조 기능이 모두 작동하는지 확인합니다.
마지막으로 실제로 효과가 있었던 변경만 기록하고, 진단 중 사용한 임시 프록시 환경 변수, 브라우저 테스트 옵션 또는 전체 라우팅 모드처럼 효과가 없었던 설정은 되돌리세요. 증상, 원인 범위, 효과가 있었던 처리와 되돌리는 방법을 짧게 남깁니다. 다음에 비슷한 현상이 발생하면 모든 설정을 처음부터 시험하지 않고 같은 범위를 먼저 확인할 수 있습니다. 문제가 회선의 국지적 이상으로 발생했다면 글로벌 노드를 확인해 대체 출구를 준비하세요. 구독과 예산이 관련되었다면 요금제 페이지에서 트래픽과 기간을 확인할 수 있습니다.
46VPN은 60일 무조건 환불을 제공합니다. 지원 절차를 거친 뒤에도 실제 사용 요구를 충족하지 못한다면 서비스 약관에 따라 처리할 수 있습니다. 문제 해결과 환불은 서로 다른 절차입니다. 기술 문의는 연결·회선·클라이언트와 계정 상태를 확인하는 데 사용하고, 환불 신청은 약관과 주문 상태에 따라 처리합니다. 두 요청을 구분해 작성하면 기술 정보와 주문 정보가 하나의 설명에 섞이는 것을 피할 수 있습니다.
Resolution checklist
장애 해결 전체 흐름 점검
- 먼저 범위 확정: 한 기기, 한 네트워크, 한 회선, 한 앱의 문제인지 모든 환경의 문제인지 확인합니다.
- 그다음 변수 변경: 한 번에 회선·네트워크·기기 중 하나의 조건만 바꾸고 같은 동작을 다시 확인합니다.
- 근거 보존: 플랫폼, 회선, 시간대, 오류 원문, 트리거 동작과 완료한 비교를 기록합니다.
- 신중한 초기화: 재설치, 데이터 삭제와 네트워크 초기화는 진단 후반에 진행하고 실행 전에 되돌릴 상태를 보존합니다.
- 신속한 문의 전환: 문제가 안정적으로 재현되면 비식별화 문의를 제출하고 현장에서 무작위로 더 수정하지 않습니다.