이 페이지를 쓸 때 지킬 원칙은 세 가지입니다. 한 번에 변수 하나만 바꾸고, 바꾼 즉시 다시 테스트하세요. 먼저 계층을 좁힌 뒤 손을 대고, 처음부터 클라이언트를 재설치하지 마세요. 현상과 시각을 그때그때 기록해 두면 문의할 때 여러 번 주고받을 일을 줄일 수 있습니다. 검색을 통해 이 서비스를 알게 된 사용자도 많지만, 실제로 막히는 지점은 대개 특정 설정 한 곳입니다.
점검 전 공통 준비: 계층을 나눈 뒤 움직이기
문제가 생겼다고 바로 클라이언트를 바꾸지 마세요. 기기에서 국제 회선까지 이어지는 경로에서 어느 한 구간만 문제가 생겨도 증상은 '페이지가 안 열린다'로 나타납니다. 처음부터 재설치, 초기화, 프로그램 교체를 하면 세 곳을 바꾸고도 어디가 효과를 냈는지 알 수 없습니다. 더 효율적인 방법은 경로를 네 계층으로 나누고, 증상이 어느 계층에 속하는지 판단한 뒤 해당 챕터로 들어가는 것입니다.
기기 자체가 인터넷에 연결되는지, Wi-Fi나 핫스팟이 정상인지, 시스템 시간이 정확한지 확인합니다.
클라이언트 상태가 정상인지, 시스템 프록시가 적용되었는지, 다른 프록시 프로그램이 함께 실행 중인지 확인합니다.
구독을 갱신한 적이 있는지, 로그인 상태가 유효한지, 요금제가 만료되지 않았는지, 트래픽을 다 쓰지 않았는지 확인합니다.
해당 회선을 쓸 수 있는지, 회선 유형이 사용 환경에 맞는지, 피크 시간대에 혼잡하지 않은지 확인합니다.
네 계층 활용법
점검 방향은 위에서 아래로입니다. L1에 문제가 있으면 — 기기가 로컬 네트워크에도 접속하지 못하면 — 나머지 세 계층은 볼 필요가 없습니다. 클라이언트가 아예 연결되지 않으면 L2와 L4를 집중적으로 보세요. 특정 사이트나 특정 앱만 안 열린다면 문제는 대개 L2의 분할 규칙이나 L4의 회선 선택에 있습니다. 계층을 판단했다면 이 페이지의 해당 챕터가 처리 목록이 됩니다.
5분 공통 자가 점검 체크리스트
- 클라이언트를 끄고 기기 자체에서 자주 쓰는 사이트에 정상 접속되는지 확인합니다. 꺼도 안 되면 로컬 네트워크부터 고치세요.
- 클라이언트 상태를 보세요. '연결 안 됨', '연결 중', '연결됨' 중 어느 것인지에 따라 해당 챕터가 달라집니다.
- 구독을 최근에 갱신했는지 확인합니다. 오래 갱신하지 않은 구독은 회선이 이미 조정되었을 수 있습니다.
- 최근에 네트워크를 바꾼 적이 있는지 떠올려 보세요. 집 Wi-Fi, 회사 네트워크, 공용 핫스팟, 셀룰러 데이터는 포트와 프로토콜 제한이 각각 다릅니다.
- 시스템 시간이 자동 동기화되는지 확인합니다. 시간 오차가 크면 암호화 핸드셰이크가 바로 실패해서 '아무리 해도 연결이 안 되는' 증상이 나타납니다.
- 다른 프록시나 가속 프로그램이 동시에 실행 중이 아닌지 확인합니다. 두 프로그램이 시스템 프록시를 두고 다투면 보통 둘 다 정상 동작하지 않습니다.
- 사용자 패널에 로그인해 요금제가 유효 기간 내인지, 트래픽을 다 쓰지 않았는지 확인합니다.
- 문제가 특정 사이트, 특정 앱, 특정 시간대에만 나타나는지 기록하세요. 이 세 가지 정보만으로 범위가 크게 좁혀집니다.
문의 전 준비해야 할 정보
문제가 결국 어느 챕터에 속하든 다음 항목을 먼저 준비하세요. 사용 중인 플랫폼과 클라이언트 이름, 문제가 시작된 시각과 발생 빈도, 오류 메시지 원문이나 스크린샷, 이미 시도한 단계와 결과(어떤 회선을 바꿨는지, 어떤 네트워크로 바꿨는지), 관련 회선의 지역명, 과금이 걸린 경우 주문 번호. 마지막 챕터에서 이 정보들을 그대로 옮겨 적을 수 있는 목록으로 정리합니다.
점검 과정에서 변경한 내용을 메모에 한 줄씩 기록하세요. 무엇을 바꿨고, 결과가 어땠고, 몇 시에 테스트했는지. 번거로워 보여도 '세 곳을 바꾸고 어디가 효과를 냈는지 모르는' 상황을 막아 줍니다.
완전히 연결 불가: 기기에서 출구까지 계층별 진단
클라이언트가 오래 로딩만 돌거나 연결 실패를 표시하거나, 연결됨으로 표시되지만 트래픽이 전혀 없습니다.
로컬 네트워크 → 클라이언트 → 계정과 요금제 → 개별 회선.
대부분 10분 안에 어느 계층의 문제인지 특정할 수 있습니다.
먼저 세 가지 '연결 불가'를 구분하기
- 연결을 누르자마자 실패하거나 버튼이 반응하지 않으면 클라이언트 계층이나 로컬 네트워크 계층일 가능성이 큽니다.
- 계속 로딩만 돌다가 결국 시간 초과가 나면 회선에 도달하지 못하거나 현재 네트워크가 해당 포트를 제한하는 경우가 많습니다.
- 연결됨으로 표시되는데 모든 사이트가 안 열리면 연결 문제가 아니므로 다음 챕터 '연결은 되지만 페이지가 열리지 않을 때'를 바로 보세요.
기기와 로컬 네트워크 계층
먼저 클라이언트를 완전히 종료하고 기기 자체가 인터넷에 되는지 확인합니다. 가장 빠른 판별법은 네트워크를 바꿔 보는 것입니다. Wi-Fi에서 셀룰러 핫스팟으로, 또는 그 반대로 바꿔 보세요. 네트워크를 바꾸니 해결된다면 문제는 계정이나 회선이 아니라 기존 네트워크의 제한에 있습니다. 회사 네트워크, 학교 네트워크, 일부 공용 핫스팟은 비표준 포트를 제한하며, 이런 제한은 클라이언트 쪽에서 풀 수 없고 네트워크를 바꾸는 것이 유일하게 확실한 방법입니다.
공유기가 오래 켜져 있으면 연결 테이블이 고갈되어 '갑자기 전부 안 되는' 증상이 나타날 수 있습니다. 공유기를 재부팅하면 그중 일부는 해결됩니다. 또한 시스템 시간이 자동 동기화되는지 확인하세요. 시간 오차가 크면 암호화 핸드셰이크가 바로 실패하는데, 시간을 수동으로 바꿨거나 시간대 설정이 비정상인 기기에서 드물지 않은 문제입니다.
클라이언트 계층
먼저 클라이언트를 완전히 종료한 뒤 다시 실행하세요. 창을 최소화하는 것이 아니라 프로세스를 종료하는 것입니다. 그다음 클라이언트에서 회선을 하나씩 바꿔 가며 테스트하세요. 권장 순서는 같은 지역의 다른 회선 → 다른 지역 → 회선 유형(전용선, 중계, 직결) 순입니다. 클라이언트가 전송 프로토콜 옵션을 제공한다면 두 회선 사이에서 프로토콜을 바꿔 다시 테스트해 보세요. 이 단계로 '현재 네트워크가 특정 전송 방식에 불리한' 경우를 배제할 수 있습니다.
이어서 방화벽과 보안 프로그램이 클라이언트 프로세스를 차단하지 않는지 확인합니다. Windows에서 가장 흔한 경우는 첫 실행 때 뜬 팝업에서 무심코 '차단'을 눌러, 이후 클라이언트가 아무 안내도 없이 계속 연결되지 않는 것입니다. 클라이언트 재설치는 마지막에 하세요. 재설치 전에 기억할 점: 구독은 사용자 패널에 로그인해 다시 받는 것이며 로컬 캐시에 의존하면 안 됩니다. 재설치 후 다시 가져오면 됩니다.
계정과 요금제 계층
로그인 상태가 만료되었을 수 있으니 로그아웃 후 다시 로그인해 보세요. 사용자 패널에서 요금제가 유효 기간 내인지, 트래픽을 다 쓰지 않았는지 확인합니다. 월 구독은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB 세 가지이며, 트래픽은 개통일 기준으로 매월 초기화됩니다. 월 트래픽을 일찍 다 썼다면 트래픽 패키지(¥158/300GB, ¥358/1000GB, ¥658/3000GB, 소진 시까지, 영구 만료 없음)를 선택할 수 있습니다.
동시 접속 기기 수는 제한이 없으므로 '기기가 너무 많아 접속이 끊기는' 상황은 이 서비스에서 발생하지 않습니다. 반대로 여러 기기가 같은 시각에 함께 실패한다면 문제는 계정, 경로 또는 로컬 네트워크에 있지 특정 기기에 있지 않습니다. 이 판단 하나로 기기별 점검에 드는 시간을 크게 줄일 수 있습니다.
언제 고객 지원에 문의해야 할까
- 서로 다른 지역의 회선을 세 개 이상 바꿔도 여전히 전혀 연결되지 않습니다.
- 네트워크를 바꿔도 마찬가지로 실패하고, 다른 기기에서도 증상이 완전히 동일합니다.
- 클라이언트 로그에 명확한 오류 코드가 나오거나 재시도 기록이 반복됩니다.
- 구독을 재설정해도 여전히 연결되지 않고, 패널의 요금제 상태는 정상입니다.
이런 결과를 정리해 문의하면 '연결이 안 됩니다' 한마디보다 훨씬 빠릅니다. 고객 지원이 이미 배제된 방향을 건너뛰고 바로 확인할 수 있습니다.
회선을 바꾸는 올바른 순서: 같은 지역의 다른 회선 → 다른 지역 → 회선 유형 변경. 한 번에 하나만 바꾸고, 클라이언트가 다시 연결을 마친 뒤에 판단하세요. 그렇지 않으면 결과를 특정할 수 없습니다.
연결은 되지만 페이지 안 열림: 프록시 모드와 애플리케이션 계층 점검
클라이언트는 연결됨으로 표시되는데 브라우저는 시간 초과, 계속 로딩, 또는 접속 불가를 표시합니다.
프록시 모드(전역 / 분할) → 시스템 프록시 적용 여부 → 브라우저 자체 설정.
전역 모드로 한 번 바꿔 테스트하면 범위를 절반으로 줄일 수 있습니다.
먼저 세 가지 증상을 구분하기
'안 열린다'는 하나의 장애가 아닙니다. 먼저 어느 유형인지 확인하세요. 모든 사이트가 안 열리는지, 일부 사이트만 안 열리는지(로컬 사이트는 정상), 아니면 특정 브라우저에서만 안 열리는지. 세 증상은 대응 방향이 완전히 다르며, 아래 대조표를 그대로 따라가면 됩니다.
| 증상 | 가장 가능성 높은 원인 | 먼저 할 일 |
|---|---|---|
| 모든 사이트가 안 열림 | 시스템 프록시가 적용되지 않았거나 트래픽이 실제로 터널을 타지 않음 | 전역 모드로 바꿔 테스트하고 시스템 프록시 스위치와 주소 확인 |
| 일부 사이트만 안 열리고 로컬 사이트는 정상 | 분할 규칙이 해당 도메인을 포함하지 않거나 해당 사이트 자체에 접속 불가 | 전역 모드로 바꿔 테스트하고, 되면 분할 규칙을 다시 확인 |
| 특정 브라우저에서만 안 열림 | 브라우저 확장 프로그램 또는 내장 보안 DNS 간섭 | 다른 브라우저나 시크릿 창으로 테스트하고 보안 DNS 끄기 |
전역과 분할: 한 번의 테스트로 방향 정하기
클라이언트는 보통 두 가지 모드를 제공합니다. 전역 모드는 모든 트래픽을 터널로 보내고, 분할 모드는 규칙에 따라 어떤 트래픽이 터널을 타고 어떤 트래픽이 직결되는지 결정합니다. 점검할 때는 먼저 모드를 전역으로 바꾸고 이전에 안 열리던 사이트에 접속해 보세요. 열리면 문제는 분할 규칙에 있으니 7장으로 넘어가고, 여전히 안 열리면 문제는 프록시 적용, DNS 또는 회선에 있으니 계속 읽어 보세요. 이 단계의 가치는 한 번의 조작으로 한 방향을 배제할 수 있다는 점입니다.
시스템 프록시가 적용되었는지
클라이언트가 '연결됨'으로 표시된다고 해서 시스템 프록시가 이미 적용된 것은 아닙니다. Windows에서는 '설정 → 네트워크 및 인터넷 → 프록시'에서 현재 프록시 스위치와 주소를 볼 수 있고, macOS에서는 '시스템 설정 → 네트워크 → 현재 네트워크 → 세부사항 → 프록시'에서 확인합니다. 브라우저 확장 프로그램, 다른 가속 프로그램, 일부 다운로드 도구가 시스템 프록시를 몰래 자기 포트로 바꿔 놓을 수 있습니다. 프록시 주소가 클라이언트에 표시된 것과 다르다면 그 프로그램들을 먼저 종료하고 다시 테스트하세요.
단편화와 MTU: 연결은 되는데 로딩이 안 될 때
핸드셰이크가 성공하고 연결도 정상인데 웹페이지가 계속 로딩되지 않거나 일부 사이트만 시간 초과가 난다면 패킷 단편화와 관련이 있을 수 있습니다. 터널 캡슐화는 헤더 길이를 늘리는데, 일부 네트워크 환경에서는 경로 MTU를 넘는 단편이 그대로 폐기됩니다. 클라이언트는 보통 '자동' 또는 수동 MTU 옵션을 제공합니다. 우선 자동으로 두고, 이상이 오래 지속될 때만 합리적인 범위에서 미세 조정하세요. 한 번에 값 하나만 바꾸고 바꾼 즉시 다시 테스트해야 합니다. 이 단계에서 가장 피해야 할 것은 여러 파라미터를 한꺼번에 바꾸는 것입니다.
브라우저 자체 DNS
최신 브라우저는 대부분 '보안 DNS'를 내장해 시스템 DNS를 건너뛰고 도메인을 직접 해석합니다. 현재 회선에 맞지 않는 주소로 해석하면 '클라이언트는 정상, 다른 앱도 정상, 이 브라우저만 안 열리는' 증상이 나타납니다. 해결 방법: 브라우저의 보안 DNS를 끄거나 '시스템 설정 따르기'로 바꾸고, 브라우저 캐시를 한 번 지운 뒤 다시 테스트하세요.
처리 순서 정리
- 전역 모드로 바꿔 테스트해 규칙 문제인지 적용 문제인지 판단합니다.
- 시스템 프록시 스위치를 확인하고 주소가 클라이언트와 일치하는지 봅니다.
- 브라우저 보안 DNS를 끄고 시크릿 창으로 다시 테스트합니다.
- 다른 회선으로 바꾸고, 다시 다른 네트워크로 바꿔 봅니다.
- 다른 기기와 비교해 단일 기기 문제인지 확인합니다.
각 단계에서 한 가지만 하고, 끝나면 즉시 다시 테스트해 결과를 기록하세요. 이 다섯 단계를 거쳐도 안 열린다면 8장에서 DNS 해석 경로를 다루세요.
속도 저하와 야간 혼잡: 먼저 수치화하고 회선 교체
접속은 되지만 로딩이 느리고 영상이 자주 버퍼링되며, 밤 8시부터 11시 사이에 가장 심합니다.
로컬 대역폭과 Wi-Fi → 회선 유형 → 시간대와 대상 사이트.
사용 환경에 맞는 회선으로 바꾸면 보통 즉시 효과가 나타납니다.
먼저 '느림'을 수치화하기
느림은 주관적인 느낌이므로 먼저 비교 가능한 현상으로 바꾸세요. 같은 기기, 같은 사이트, 같은 시간대에서 '클라이언트를 끄고 로컬 사이트 접속'과 '클라이언트를 켜고 대상 사이트 접속'을 각각 측정합니다. 클라이언트를 끄고 로컬 사이트에 접속해도 느리면 로컬 대역폭이나 Wi-Fi 문제이고, 해외 접속만 느리면 계속 읽어 보세요. 속도 측정은 한 번의 최고값이 아니라 여러 번 측정한 중앙값을 보세요. 단일 측정은 순간 변동의 영향을 크게 받아 회선 품질을 판단하기에 부족합니다.
회선 유형과 적합한 용도
이 사이트의 회선은 세 가지 유형이며 각각 적합한 용도가 다릅니다. 유형을 잘못 고르는 것이 '속도 저하'에서 가장 흔한 원인 중 하나입니다.
| 회선 유형 | 특징 | 적합한 용도 |
|---|---|---|
| IEPL 전용선 | 독립 채널, 안정적인 경로, 장시간 연결에 유리 | 야간 피크, 화상 회의, 장시간 대용량 작업 |
| 중계 | 중계 노드를 거쳐 접속, 가성비 우수 | 일상 웹 서핑, 소셜 미디어, 일반 영상 |
| 직결 | 근거리 접속, 짧은 경로 | 인접 지역, 지연에 민감한 작업 |
야간 피크에 왜 느려질까
야간 피크의 병목은 보통 서버 쪽이 아니라 국제 구간 자체에 있습니다. 이 시간대에는 국제 회선 전체가 혼잡하고 가정용 회선의 업로드도 많이 점유됩니다. 쓸 수 있는 방법은 세 가지입니다. 전용선 회선으로 바꿔 독립 채널로 공용 경로의 대기를 피하고, 인접 지역(홍콩, 일본, 싱가포르)으로 바꿔 국제 구간 길이를 줄이고, 대용량 작업(시스템 업데이트, 클라우드 동기화, 게임 업데이트)을 비피크 시간대로 옮겨 스스로 대역폭을 다 쓰지 않게 하는 것입니다.
로컬 요인도 무시하지 말기
- Wi-Fi 신호가 약하거나 혼잡한 대역에서 동작 중입니다. 유선 연결이 가능하면 유선을 쓰세요. 가장 간단한 일회성 개선입니다.
- 공유기가 오래되었거나 오랫동안 재부팅하지 않으면 연결 테이블과 포워딩 성능이 떨어집니다.
- 백그라운드에서 시스템 업데이트, 클라우드 동기화, 웹하드 다운로드가 돌면 업로드가 꽉 차서 어떤 회선이든 느리게 느껴집니다.
- 브라우저에 탭과 확장 프로그램이 잔뜩 열려 있으면 페이지 자체 로딩도 느려집니다.
- 보안 프로그램이 전체 검사를 돌리면 디스크와 네트워크가 동시에 점유됩니다.
어떻게 측정해야 신뢰할 수 있을까
도구를 고정하고, 시간대를 고정하고, 여러 차례 측정하세요. 구체적인 방법 — 어떤 도구를 고를지, 야간 피크와 한가한 시간대에 각각 몇 번 측정할지, 지연과 지터, 패킷 손실, 처리량이 각각 무엇을 의미하는지 — 는 블로그 VPN 속도 실측 가이드: 직접 객관적으로 측정하는 방법, 도구와 시간대에 전체 절차가 있으니 그대로 따라 하면 비교 가능한 기록을 얻을 수 있습니다.
흔한 오해 두 가지
첫째, 스트리밍의 자동 화질 저하를 회선 장애로 착각하는 경우입니다. 플랫폼은 실시간 대역폭에 따라 화질을 자동 조정하므로 화면이 흐려지는 것은 플랫폼 정책이지 회선 문제가 아닐 수 있습니다. 관련 메커니즘은 4K 스트리밍에 좋은 VPN: 화질이 480p로 떨어지는 이유와 확인해야 할 회선 지표를 참고하세요. 둘째, 단일 최고값을 결론으로 삼는 경우입니다. 한 번 빨랐다거나 느렸다는 결과만으로는 회선의 장기 성능을 알 수 없고, 여러 차례 측정한 중앙값이 더 신뢰할 만합니다.
두 개의 가속 프로그램을 겹쳐 쓰지 말고, 속도 측정 중에 다운로드 작업을 함께 돌리지 마세요. 두 경우 모두 결과의 참고 가치를 떨어뜨립니다.
잦은 끊김과 모바일 백그라운드 종료: 규칙성으로 원인 찾기
연결이 자꾸 끊기거나, 화면 잠금 후 끊기거나, 네트워크를 바꾸면 수동으로 다시 연결해야 합니다.
끊김 패턴 → 시스템 절전 정책 → 네트워크 전환과 네트워크 어댑터 설정.
주기적으로 끊기는 것과 무작위로 끊기는 것은 대응 방향이 완전히 다르니 먼저 분류하세요.
먼저 끊김의 규칙성을 기록하기
끊김 문제에서 가장 피해야 할 것은 '계속 끊기는 것 같다'는 막연한 느낌입니다. 2분만 투자해 규칙성을 기록하면 방향이 바로 잡힙니다.
- 일정한 간격으로 끊긴다면(예: 5분 또는 30분): 대개 연결 유지(keep-alive) 설정이나 시스템 정책과 관련이 있습니다.
- 무작위로 끊기고 규칙이 없다면: 대개 네트워크 변동이나 회선 자체의 조정입니다.
- 네트워크를 바꿀 때만 끊긴다면(예: Wi-Fi와 셀룰러 데이터 전환): 시스템 재연결 정책 문제입니다.
- 화면 잠금이나 절전 후에만 끊긴다면: 시스템 절전과 백그라운드 제한입니다.
- 특정 시간대에만 끊긴다면: 구간 혼잡 시간대와 관련이 있습니다.
데스크톱: 절전, 전원 관리, 네트워크 어댑터
시스템이 절전 모드에 들어가면 네트워크 연결이 일시 중단되고, 깨어난 뒤 일부 클라이언트가 자동으로 복구되지 않아 '갑자기 끊긴' 것처럼 보입니다. 해결 방법: 클라이언트에서 자동 재연결을켜고, 시스템 전원 계획을 '절전'에서 '균형 조정' 또는 '고성능'으로 바꿔 다시 테스트하세요. 네트워크 어댑터 드라이버 설정의 '전원을 절약하기 위해 컴퓨터가 이 장치를 끌 수 있음' 옵션도 확인해서 꺼 두세요. 또한 클라이언트가 비정상 종료되면 시스템 프록시 스위치가 원래대로 돌아오지 않아 '끊긴 뒤 다시 연결이 안 되는' 증상이 나타날 수 있습니다. 시스템 프록시 설정에서 수동으로 끈 뒤 다시 연결하면 됩니다.
모바일: 백그라운드 정책이 주원인
iOS와 Android 모두 화면 잠금이나 저전력 상태에서 백그라운드 네트워크 활동을 제한합니다. iOS에서 저전력 모드를 켜면 백그라운드 새로 고침과 네트워크 활동이 강화되어 화면 잠금 후 연결이 시스템에 의해 중단되기 쉽습니다. Android는 제조사별 배터리 최적화 정책 차이가 더 크므로 클라이언트를 '제한 없음' 허용 목록에 추가하고 백그라운드 활동을 허용해야 합니다. 또한 시스템 대버전 업데이트 후 VPN 구성 권한을 다시 확인해야 하는 경우가 있는데, 증상은 '시스템 업데이트 후 연결이 안 됨'으로 나타나며 다시 권한을 허용하면 됩니다.
공유기와 다중 기기 환경
공유기에서 전역 프록시를 돌리면 공유기의 메모리와 연결 수 상한이 병목이 되고, 대용량 다운로드를 함께 돌리면 서로 대역폭을 잡아먹어 '사용자가 많으면 끊기는' 증상이 나타납니다. 이 서비스는 동시 접속 기기 수 제한이 없으므로 기기가 많다고 서로 접속이 끊기지는 않습니다. 여러 기기가 같은 시각에 함께 끊긴다면 기기 수가 아니라 출구 경로나 로컬 네트워크를 먼저 의심하세요.
회선 문제인지 로컬 문제인지 판단하기
- 같은 계정의 다른 기기도 동시에 끊기는지 확인합니다. 동시에 끊기면 경로 문제, 한 대만 끊기면 해당 기기 문제입니다.
- 다른 회선으로 바꿔도 끊기는지 확인합니다. 회선을 바꾸니 괜찮아지면 기존 회선이 해당 시간대에 변동이 있는 것입니다.
- 다른 네트워크로 바꿔도 끊기는지 확인합니다. 네트워크를 바꾸니 괜찮아지면 기존 네트워크 쪽에 문제가 있습니다.
- 끊길 때 로컬 사이트는 정상인지 확인합니다. 로컬도 안 되면 국제 구간과는 무관한 문제입니다.
네 가지 중 하나라도 재현되면 범위가 절반으로 줄어듭니다. 끊긴 시각을 기록해 로컬 네트워크 이벤트(공유기 재부팅, 시스템 업데이트, 통신사 변동)와 대조하면 원인을 바로 찾는 경우가 많습니다.
모바일 끊김의 첫 번째 처리 순서: 클라이언트를 절전 허용 목록에 추가 → 저전력 모드 끄기 → 백그라운드 활동 허용 → 그다음에 회선 교체를 고려하세요.
구독 갱신 실패: 링크, 클라이언트, 재설정
갱신 버튼이 로딩만 돌다 실패하거나 오류 코드가 뜨거나, 갱신은 성공했는데 회선이 그대로입니다.
구독 링크가 유효한지 → 갱신 시점에 연결되어 있었는지 → 클라이언트 형식과 캐시.
대부분 사용자 패널에서 링크를 다시 복사하면 해결됩니다.
구독 링크의 작동 방식
구독 링크는 토큰이 포함된 주소로, 클라이언트가 이를 사용해 서버에서 최신 회선 목록을 가져옵니다. 이는 자격 증명과 같아서 링크를 가진 사람은 회선을 가져올 수 있습니다. 같은 링크를 여러 기기에 가져올 수 있으며, 이 서비스는 동시 접속 기기 수 제한이 없으므로 기기마다 따로 신청할 필요가 없습니다. 이 점을 이해하면 이후의 모든 '갱신 실패' 처리가 자연스러워집니다. 링크 자체가 만료되었거나, 클라이언트가 요청을 보내지 못한 것입니다.
흔한 실패 증상과 처리
| 증상 | 가능한 원인 | 처리 |
|---|---|---|
| 갱신 시 403 또는 404 표시 | 링크가 만료되었거나 재설정됨 | 사용자 패널에 로그인해 구독 링크를 다시 복사하고, 기존 구독을 삭제한 뒤 다시 가져오기 |
| 갱신이 계속 시간 초과 | 갱신 채널 자체에 연결성이 필요함 | 사용 가능한 회선에 먼저 연결한 뒤 갱신 실행 |
| 갱신은 성공했는데 회선이 그대로 | 클라이언트 � 또는 실제로 가져오지 않음 | 수동으로 한 번 새로 고치거나 구독을 삭제한 뒤 다시 가져오기 |
| 가져올 때 형식 미지원 표시 | 클라이언트와 구독 형식이 맞지 않음 | 클라이언트가 지원하는 가져오기 방식을 선택하고 해당 형식으로 변경 |
| 갱신 후 회선이 줄어듦 | 회선 목록이 운영에 따라 조정됨 | 정상적인 현상이며, 같은 지역의 다른 회선을 선택하면 됨 |
플랫폼별 가져오기와 갱신 경로
- Windows / macOS: 클라이언트 실행 → 구독 관리 → 구독 추가 → 링크 붙여넣기 → 갱신.
- iOS / Android: 클라이언트에서 구독을 추가한 뒤 수동으로 아래로 당겨 한 번 새로 고치세요.
- Linux: 사용 중인 클라이언트 설명에 따라 구독을 가져오고, 명령줄 클라이언트는 설정 파일 경로와 권한에 주의하세요.
모든 플랫폼의 구독은 사용자 패널에서 받습니다. 로그인 후 다운로드 및 구독 영역에서 복사하세요. 이 사이트는 정적 구독 주소를 제공하지 않습니다. 플랫폼별 단계별 조작은 사용 가이드를, 구독 링크의 전체 개념과 가져오기, 유출 처리 방법은 블로그 구독 링크란 무엇인가? 초보자 완전 가이드를 참고하세요.
링크 유출과 재설정
구독 링크는 자격 증명과 같으므로 공개 그룹이나 포럼에 올리지 말고 스크린샷에 포함하지 마세요. 유출이 의심되면 사용자 패널에서 구독 링크를 재설정한 뒤 기기마다 다시 가져오세요. 기존 링크는 재설정 즉시 만료되며, 이 단계로 '링크가 속도 제한을 받거나 비정상적으로 사용되는' 문제도 함께 해결됩니다.
글과 가이드에 나오는 예시 링크는 모두 가짜 값입니다. 예를 들어 https://example.com/sub?token=YOUR_TOKEN 같은 것이며, 실제 토큰처럼 보이는 주소는 공개된 곳에 붙여넣지 마세요.
갱신 후 회선 이름이 바뀜
회선 이름과 그룹은 운영에 따라 조정되며 이름이 바뀌어도 사용에는 영향이 없습니다. 특정 회선이 사라졌다면 클라이언트에서 같은 지역의 다른 회선을 선택하면 됩니다. 회선 이름이 바뀌었다고 클라이언트를 반복 재설치하지 마세요. 재설치로는 회선 조정이 해결되지 않고 시간만 더 듭니다.
구독 링크가 유출되면 즉시 사용자 패널에서 재설정하고 기기마다 다시 가져오세요. 재설정은 기존 링크를 즉시 무효화하는 유일한 방법입니다.
특정 앱이 프록시를 타지 않을 때: 분할 규칙과 적용 방식
브라우저는 정상인데 특정 프로그램, 게임, 명령줄 도구가 대상 서비스에 연결되지 않습니다.
전역 모드 재테스트 → 적용 방식(시스템 프록시 / TUN) → 사용자 지정 규칙.
전역 모드에서 연결되면 규칙 문제이므로 방향이 명확합니다.
분할 규칙의 기본 논리
분할 모드에서 클라이언트는 도메인, IP 대역, 프로세스에 따라 트래픽을 터널로 보낼지 직결할지 결정합니다. 규칙이 포함하지 않은 대상은 직결되며, 해외 접속이 필요한 상황에서는 '이 앱이 프록시를 타지 않는' 증상으로 나타납니다. 이 점을 먼저 이해한 뒤 어떤 종류의 앱인지 보세요. 종류별로 처리 방식이 크게 다릅니다.
전역 모드로 빠르게 판단하기
모드를 전역으로 바꿔 다시 테스트하세요. 앱이 정상으로 돌아오면 문제는 규칙에 있으니 규칙을 보�면 되고, 여전히 비정상이면 앱의 적용 방식(예: 시스템 프록시를 아예 읽지 않음)이나 자체 UDP, 자체 DNS 구현 방식에 문제가 있습니다. 이 단계를 마치면 이후 처리 경로는 하나만 남습니다.
몇 가지 흔한 경우
- 데스크톱 프로그램과 동기화 드라이브: 일부는 시스템 프록시를 읽지 않으므로 클라이언트의 TUN / 가상 네트워크 어댑터 모드로 모든 트래픽을 적용해야 합니다.
- Windows 스토어 앱: 시스템 네트워크 격리 영향을 받으므로 클라이언트에서 해당 적용 옵션을 켜야 합니다.
- 브라우저: 확장 프로그램 프록시가 시스템 프록시를 덮어쓰므로 먼저 확장을 비활성화해 테스트한 뒤 확장에서 설정할지 결정하세요.
- 명령줄 도구: 프록시 환경 변수를 수동으로 설정해야 하며, 아래 예시를 참고하세요.
- 게임: 대부분 UDP를 사용하므로 UDP 포워딩을 지원하는 모드가 필요합니다. 또한 게임은 지연에 민감하므로 인접 지역 회선을 우선 선택하세요.
명령줄 프록시 예시
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
curl -I https://example.com
포트는 클라이언트에 실제 표시되는 값을 기준으로 하며, 위는 예시일 뿐입니다. Windows PowerShell에서는 $env:HTTPS_PROXY="http://127.0.0.1:7890"로 씁니다. 설정 후 명령줄은 되는데 앱은 여전히 안 된다면 문제는 회선이나 규칙이 아니라 앱 자체에 있습니다.
플랫폼별 적용 방식 대조
| 플랫폼 | 주로 쓰는 적용 방식 | 주의점 |
|---|---|---|
| Windows | 시스템 프록시 + TUN 모드 | 스토어 앱과 보안 프로그램의 차단 알림에 주의 |
| macOS | 시스템 프록시 + 네트워크 확장 | 첫 실행 시 '개인정보 보호 및 보안'에서 네트워크 확장을 허용해야 함 |
| iOS | 시스템 수준 VPN 구성 | 클라이언트가 일괄 적용하며 규칙은 앱 안에서 조정 |
| Android | 시스템 수준 VPN 구성 | 배터리 최적화가 백그라운드 연결에 미치는 영향에 주의 |
| Linux | 시스템 프록시 또는 TUN | 명령줄 도구는 환경 변수를 따로 설정해야 함 |
처리 순서
- 전역 모드로 다시 테스트해 규칙 문제인지 적용 문제인지 확인합니다.
- 적용 방식을 바꿔 봅니다. 시스템 프록시가 안 되면 TUN / 가상 네트워크 어댑터 모드로 전환하세요.
- 이 앱의 대상 도메인이나 프로세스에 사용자 지정 규칙을 추가합니다.
- 그래도 안 되면 단일 프로세스 프록시를 시도해 범위를 한 프로그램으로 좁힙니다.
- 위 방법이 모두 안 되면 문의할 때 앱 이름과 대상 서비스를 함께 적어 주세요. 추가 판단에 도움이 됩니다.
DNS 이상과 유출 자가 점검: 해석 경로 점검
연결은 되지만 도메인 해석이 느리거나 실패하거나, 일부 사이트를 IP로만 열 수 있습니다.
해석 결과 비교 → 클라이언트 DNS 설정 → 시스템과 브라우저 DNS.
DNS 문제의 특징은 '도메인을 바꾸면 결과도 바뀐다'는 점입니다.
DNS 이상은 어떻게 나타날까
- 웹페이지를 열기 전에 몇 초간 '해석 중' 멈춤이 있다가 그제야 정상 로딩됩니다.
- 같은 사이트가 한 기기에서는 열리고 다른 기기에서는 안 열리는데, 두 기기가 같은 회선을 씁니다.
- 도메인을 입력하면 안 열리는데 IP로 직접 접속하면 열립니다.
- 다른 네트워크로 바꾸면 증상이 사라집니다.
이 항목들의 공통점은 문제가 '연결이 되느냐'가 아니라 '도메인이 무엇으로 해석되느냐'에 있다는 것입니다.
점검 명령
# Windows
nslookup example.com
ipconfig /flushdns
# macOS
dig example.com
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux
dig example.com
resolvectl flush-caches
'클라이언트 켜기'와 '클라이언트 끄기' 상태에서 같은 도메인의 해석 결과를 각각 기록하세요. 두 결과가 같으면 해석 요청이 터널을 타지 않은 전형적인 유출입니다. 켠 뒤 해석이 느려지거나 실패하면 터널 내부 해석 서비스가 현재 회선에서 도달 불가능한 것이므로 다른 회선으로 바꿔 다시 테스트하면 됩니다.
DNS 유출이 의미하는 것
DNS 요청이 터널을 타지 않으면 로컬 네트워크나 통신사의 해석 서비스가 처리합니다. 영향은 두 가지입니다. 첫째, 해석 결과가 근거리 주소일 수 있어 해외 접속 시 오히려 우회하게 되어 '연결은 되지만 느린' 증상이 나타납니다. 둘째, 접속 의도가 터널 밖에 노출됩니다. 암호화 자체에는 영향이 없지만 함께 고쳐 두는 것이 좋습니다.
해결 방법
- 클라이언트 DNS 옵션을 '터널 내 DNS 사용' 또는 '시스템 설정 따르기'로 설정하고 둘 다 한 번씩 시도해 해석이 더 안정적인 쪽을 고르세요.
- 시스템 DNS를 안정적인 공용 해석 서비스로 바꾸고, 바꾼 뒤 캐시를 한 번 지우세요.
- 브라우저의 보안 DNS를 끄고 시스템 설정을 따르게 하세요.
- 공유기 수준의 DNS도 한 번 확인하세요. 특히 프록시를 공유기에 올린 환경에서 중요합니다.
이 사이트의 '내 IP' 페이지에서 현재 출구 IP와 소속 지역을 확인해 트래픽이 실제로 터널을 타는지 볼 수 있습니다. DNS를 점검하기 전에 출구를 먼저 확인하면 잘못된 방향에 시간을 쓰는 일을 피할 수 있습니다.
'연결은 되지만 안 열림'과의 관계
DNS 이상은 3장 '연결은 되지만 페이지가 열리지 않을 때'와 자주 함께 나타납니다. 권장 판단 순서는 먼저 3장에서 프록시 적용과 브라우저 설정을 훑고, 다시 이 장으로 돌아와 해석 경로를 처리하는 것입니다. 두 장을 모두 거쳐도 이상이 계속되면 회선 교체나 기기 비교를 고려하세요.
DNS 설정은 한 번에 한 곳만 바꾸고, 바꾼 뒤에는 캐시를 지우는 것을 잊지 마세요. 여러 곳을 함께 바꾸면 나중에 어디가 효과를 냈는지 판단할 수 없습니다.
기기 수, 계정 이상과 문의 시 첨부할 정보
로그인 이상, 구독을 받을 수 없음, 과금 관련, 또는 앞선 챕터에서도 원인을 찾지 못한 경우입니다.
계정 상태 → 요금제와 트래픽 → 지금까지의 점검 기록.
정보가 충분한 문의는 보통 한 번에 처리 방안을 받습니다.
동시 접속 기기 수 무제한
이 서비스의 요금제는 동시 접속 기기 수를 제한하지 않으므로 여러 기기를 동시에 사용해도 제한이 걸리지 않고 '기기 자리'를 따로 구매할 필요도 없습니다. 오히려 주의할 점은 계정 공유입니다. 하나의 계정을 여러 사람이 함께 쓰면 문제가 생겼을 때 어느 기기, 어느 네트워크의 문제인지 판단하기 어려워 점검 비용이 몇 배로 늘고, 구독 링크가 퍼져 나가 불필요한 위험도 생깁니다. 여러 기기가 모두 본인 것이라면 안심하고 동시에 로그인하세요.
계정과 구독 관련 이상
- 로그인 실패: 먼저 아이디와 비밀번호를 확인하고, 비밀번호를 잊었다면 사용자 패널의 재설정 절차를 이용하세요. 가입에 이메일 주소가 필요 없고 아이디와 비밀번호만 있으면 되므로 인증 메일을 기다리는 단계가 없습니다.
- 구독을 받을 수 없음: 구독은 사용자 패널에 로그인한 뒤 받을 수 있으며, 로그인하지 않았거나 로그인 상태가 만료되면 받을 수 없습니다. 다시 로그인한 뒤 다운로드 및 구독 영역에서 복사하세요.
- 요금제 만료 또는 트래픽 소진: 월 구독은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB 세 가지이며, 트래픽은 개통일 기준으로 매월 초기화됩니다. 월 트래픽을 일찍 다 썼다면 트래픽 패키지(¥158/300GB, ¥358/1000GB, ¥658/3000GB, 소진 시까지, 영구 만료 없음)를 선택할 수 있습니다. 도중에 요금제를 업그레이드하면 차액이 남은 일수로 환산됩니다.
- 과금 문의: 주문과 관련된 문의는 문의에 주문 번호를 함께 적으면 훨씬 빠르게 처리됩니다.
요금제와 트래픽 패키지의 전체 설명은 요금제 페이지에, 회선 지역과 유형의 전체 목록은 서버 페이지에 있습니다. 회선을 고르기 전에 한번 대조해 보세요.
고객 지원에 문의해야 할 여섯 가지 경우
- 해당 챕터대로 점검해도 계속 재현되고 스스로 더 판단하기 어렵습니다.
- 네트워크 교체, 회선 교체, 기기 교체 세 가지가 모두 실패했습니다.
- 여러 기기가 같은 시각에 함께 실패합니다.
- 클라이언트 로그에 명확한 오류 코드나 반복 재시도 기록이 있습니다.
- 구독 링크를 재설정해도 여전히 갱신되지 않습니다.
- 주문, 환불, 과금과 관련된 경우입니다. 환불 약속은 60일 무조건 환불이며, 조건에 해당하면 문의에 주문 정보를 적어 주세요.
문의 시 첨부할 정보
- 계정 아이디(비밀번호는 첨부하지 마세요).
- 플랫폼과 클라이언트 이름.
- 문제가 시작된 시각과 발생 빈도.
- 구체적인 증상과 오류 메시지 원문, 스크린샷이면 더 좋습니다.
- 이미 시도한 단계와 결과. 예를 들어 어떤 회선을 바꿨는지, 어떤 네트워크로 바꿨는지.
- 관련 회선의 지역명.
- 과금이 걸린 경우 주문 번호.
문의 접수 경로와 처리 속도
문의 접수는 사용자 패널의 문의 영역에서 로그인 후 제출할 수 있습니다. 같은 문제로 여러 건을 중복 제출하지 마세요. 중복 제출은 처리 순서를 흐트러뜨려 오히려 느려집니다. 추가 정보가 필요하면 기존 문의에 덧붙이면 됩니다. 가장 흔한 주고받기는 '증상 설명 부족'이므로 위 목록을 그대로 채워 넣으면 대부분 한 번에 설명이 끝납니다.
앞선 여덟 챕터의 자가 점검 기록은 문의할 때 가장 유용한 자료입니다. '무엇을 바꿨고 결과가 어땠는지'를 시간순으로 정리하면 보통 한 번에 원인을 찾습니다.
VPNDT: 110+개 국가 / 150+개 회선
동시 접속 기기 수 무제한, 60일 무조건 환불, 이메일 주소 없이 가입할 수 있습니다. 요금제와 트래픽 패키지는 언제든 사용자 패널에서 확인하고 업그레이드할 수 있습니다.
이 페이지 최종 업데이트: 2026-09. 본문에 나온 요금제 가격, 환불 약속, 기기 설명은 사용자 패널과 요금제 페이지의 현재 표시를 기준으로 합니다. 이 페이지의 처리 단계가 클라이언트 실제 화면과 다르면 클라이언트 안내를 우선하며, 문의로 알려 주시면 감사하겠습니다.