VPN 문제 해결 가이드

01

시작하기 전에: 점검의 큰 흐름과 준비물

빠른 시작 페이지는 처음 설치부터 연결 성공까지를 다룹니다. 경로가 직선적이죠. 가입, 구독 가져오기, 클라이언트로 불러오기, 연결 확인 순서입니다. 반면 문제 해결은 직선적이지 않습니다. 같은 '페이지가 열리지 않음'도 DNS 해석 실패일 수 있고, 분할 규칙이 해당 대상을 직결로 돌려보냈을 수도 있고, 시스템 프록시가 실제로 적용되지 않았을 수도 있고, 아니면 회선 자체에 문제가 있을 수도 있습니다. 매번 설치 단계부터 다시 밟으면 대부분의 시간을 이미 정상인 부분에 낭비하게 됩니다.

이 가이드는 증상 기준으로 구성했습니다. 각 장은 실제로 눈에 보이는 현상 하나에 대응하며, 장 안에서 먼저 판단 흐름을 제시해 손을 대기 전에 원인을 한두 가지로 좁힌 다음 구체적인 자가 점검 단계와 해결책을 설명합니다. 아홉 개 장에는 순서가 없으니 위 목차에서 해당 장으로 바로 이동하면 됩니다.

• 02전혀 연결되지 않음클라이언트에 트래픽이 전혀 없음
• 03연결은 되는데 페이지가 안 열림터널은 열렸는데 화면만 로딩
• 04속도 저하와 저녁 시간대 지연영상 버퍼링, 다운로드 속도 저하
• 05잦은 끊김연결 후 얼마 지나지 않아 끊김
• 06구독 갱신 실패회선 목록이 비었거나 불러오지 못함
• 07앱 프록시 미적용브라우저는 되는데 앱은 안 됨
• 08모바일 백그라운드 끊김화면 잠금 후 연결이 사라짐
• 09문의 시 첨부할 정보필수 정보 6가지

빠른 시작 페이지와의 역할 분담

아직 클라이언트를 설치하지 않았거나 구독을 가져오지 않았다면 빠른 시작의 기본 흐름부터 보세요. 가입, 구독 가져오기, 불러오기, 연결 확인까지 네 단계입니다. 그 흐름을 마쳤는데도 문제가 남아 있다면 다시 이 페이지로 돌아오면 됩니다. 반대로 이미 정상적으로 사용 중인데 특정 사이트만 가끔 열리지 않는다면 설치 과정을 다시 밟을 필요 없이 해당 증상 장을 보면 됩니다.

공통 점검 흐름: 현상부터 정하고, 계층을 정한다

어떤 증상이든 점검 순서는 세 단계입니다. 첫째, 현상을 재현 가능한 수준으로 서술합니다. '가끔 느리다'는 현상이 아닙니다. '저녁 8시부터 10시까지 특정 영상 사이트만 버퍼링이 걸리고 다른 사이트는 정상'이라야 현상입니다. 재현되는 현상이라야 원인을 짚을 수 있습니다.

둘째, 문제가 어느 계층에 있는지 판단합니다. 해외 접속 경로는 대략 다섯 계층으로 나눌 수 있습니다. 앱 자체, 운영체제 프록시 설정, 클라이언트와 분할 규칙, 로컬 네트워크 구간, 국제 회선입니다. 계층마다 확인 방법이 다르며, 3장부터 8장까지가 대체로 이 계층 구분을 따라 전개됩니다.

셋째, 한 번에 변수 하나만 바꿉니다. 바꾼 즉시 같은 항목을 다시 측정해 효과를 확인한 뒤 다음으로 넘어갑니다. 설정 세 개를 동시에 바꾸면 무엇이 효과를 냈는지 알 수 없고, 다음에 같은 문제를 만나도 또 헤매게 됩니다.

손대기 전에 모아둘 것들

• 클라이언트 이름과 화면에 표시된 버전 정보
• 현재 사용 중인 회선 이름과 회선 유형
• 오류 메시지 원문(직접 요약한 표현이 아니라)
• 운영체제 버전과 네트워크 환경(가정용 인터넷, 회사 네트워크, 공용 Wi-Fi, 셀룰러)
• 문제가 발생한 특정 앱과 특정 주소
• 문제가 시작된 시점, 그리고 그 전에 설정을 바꾼 적이 있는지

이 정보는 9장에서 한 번 더 쓰입니다. 문의할 때 필수 항목이므로 미리 정리해 두면 한 번의 주고받기를 줄일 수 있습니다.

세 가지 원칙

첫째, 클라이언트를 반복해서 재설치하지 마세요. 대부분의 연결 문제는 설치 파일과 무관하며, 재설치하면 구독과 설정만 지워져 변수가 하나 더 늘어납니다.

둘째, 기록 없이 프로토콜이나 포트를 바꾸지 마세요. 바꾸는 것 자체는 유효한 점검 수단이지만 원래 값이 무엇이었는지 기억해야 되돌릴 수 있습니다.

셋째, 실제 업무 환경에서 시험하지 마세요. 업무용 기기와 계정은 다른 기기에서 먼저 변경 사항을 검증하고 문제가 없음을 확인한 뒤 적용하세요.

이 가이드에서 쓰는 몇 가지 용어

회선 유형: IEPL 전용선, 중계, 직결로 나뉘며 차이는 데이터가 입구에서 출구까지 어떻게 이동하느냐에 있습니다. 4장에 전체 비교표가 있습니다. 분할: 어떤 트래픽은 회선으로, 어떤 트래픽은 로컬 직결로 보낼지 클라이언트가 판단하는 규칙 집합입니다. 출구: 목적 사이트에 접속할 때 상대가 보는 주소의 소속 지역입니다. 구독: 계정에 연결된 회선 목록과 설정으로, 클라이언트가 주기적으로 가져와 갱신합니다. 6장에서 따로 다룹니다. 세션: 클라이언트와 회선 사이에 유지되는 연결로, 끊기면 다시 만들어야 합니다.

용어를 먼저 정리해 두면 이후 장의 판단 흐름이 훨씬 수월해집니다. 모르는 단어가 나오면 이 절로 돌아와 확인하면 됩니다.

02

전혀 연결되지 않음: 클라이언트부터 회선까지 4계층 진단

전혀 연결되지 않는 경우는 두 가지입니다. 클라이언트가 미연결로 표시되거나, 연결됨으로 표시되지만 트래픽이 전혀 없는 경우입니다. 둘은 나눠서 봐야 합니다. 전자는 터널 생성 전에 막힌 것이고, 후자는 터널이 만들어진 뒤에 막힌 것입니다.

1계층: 클라이언트가 실제로 실행 중인가

먼저 프로세스가 살아 있는지, 화면이 시작 화면에서 멈춰 있지 않은지 확인합니다. Windows에서는 작업 표시줄 트레이 아이콘이 클릭에 반응하는지, macOS에서는 메뉴 막대 아이콘을 봅니다. 눌렀을 때 화면이 비어 있거나 로딩만 돈다면 바로 재설치하지 말고 완전히 종료한 뒤 한 번 다시 실행해 보세요.

다음은 권한입니다. macOS는 첫 실행 시 VPN 구성 추가 권한을 요청하는데, 이를 거부하면 클라이언트 화면은 멀쩡해 보이지만 연결 버튼을 눌러도 반응이 없습니다. 시스템 설정의 네트워크 항목에서 구성이 존재하는지 확인하세요. Windows에서는 설치 시 가상 네트워크 어댑터 드라이버 설치에 동의했는지 확인해야 합니다. 보안 프로그램이 이를 차단했다면 클라이언트는 열리지만 터널이 만들어지지 않습니다. 이 계층의 문제는 공통점이 하나 있습니다. 어떤 회선, 어떤 프로토콜로 바꿔도 결과가 같다는 점입니다.

2계층: 로컬 네트워크가 외부로 나갈 수 있는가

먼저 클라이언트를 끄고 평소처럼 국내 사이트 하나를 열어 봅니다. 열리지 않는다면 문제는 회선이 아니라 로컬 네트워크에 있으므로 뒤 계층은 볼 필요가 없습니다.

공용 Wi-Fi에서 흔한 경우는 두 가지입니다. 웹 인증이 필요한데 인증 페이지가 클라이언트에 넘어가 버린 경우, 또는 네트워크 자체가 일부 포트만 허용하는 경우입니다. 전자는 클라이언트를 끄고 인증을 마친 뒤 연결하고, 후자는 다른 네트워크에서 확인하세요.

회사 네트워크와 학교 네트워크는 비표준 포트를 제한할 수 있습니다. 클라이언트가 포트 변경을 지원한다면 443으로 바꿔 다시 시도해 보세요. 통과율이 가장 높은 포트입니다.

3계층: 구독과 노드 목록이 로드되는가

클라이언트의 회선 목록을 엽니다. 목록이 비어 있다면 문제는 회선이 아니라 구독에 있습니다. 흔한 원인은 구독 주소 만료, 계정 트래픽 소진, 또는 클라이언트가 설정을 한 번도 정상적으로 가져오지 못한 경우입니다.

구독 가져오기 점검은 6장에서 다룹니다. 여기서는 한 가지만 확인하면 됩니다. 목록에 회선이 있는지 여부입니다. 회선은 있는데 하나도 연결되지 않는다면 4계층으로 넘어가고, 목록이 비어 있다면 6장으로 가세요.

4계층: 회선과 프로토콜

다른 지역의 회선으로 바꾸고, 회선 유형도 바꿔 보고(예: 중계에서 IEPL 전용선으로), 프로토콜도 바꿔 봅니다. 세 번의 전환 중 하나라도 성공한다면 계정이나 네트워크가 아니라 특정 회선 또는 특정 프로토콜의 문제이므로, 실패한 항목을 기록해 전달하면 됩니다.

모든 회선, 모든 프로토콜이 안 된다면 2계층으로 돌아가 로컬 네트워크를 다시 확인하고, 시스템 시간이 정확한지도 확인하세요. 시간 오차가 크면 암호화 핸드셰이크가 그대로 실패하는데, 화면에는 보통 '연결 실패' 네 글자만 보여서 실제 원인을 알 수 없습니다.

네 계층을 모두 확인해도 연결되지 않는다면 9장의 형식에 맞춰 현상을 기록해 문의하세요. 기록에는 '연결이 안 된다'만 쓰지 말고 각 계층에서 무엇을 보았는지 구체적으로 적어야 합니다.

03

연결은 되는데 페이지가 안 열림: DNS 해석, 분할, 시스템 프록시

클라이언트가 연결됨으로 표시되는 것은 터널이 만들어졌다는 뜻일 뿐입니다. 데이터가 목적 사이트까지 도달하려면 DNS 해석, 분할 판단, 시스템 프록시 전달이라는 세 단계를 거쳐야 합니다. 어느 하나만 끊겨도 결과는 '연결은 됐는데 안 열린다'로 같습니다.

'연결됨'은 정확히 무엇을 뜻하나

터널 생성 성공은 클라이언트와 회선 사이가 뚫렸다는 의미입니다. 하지만 이는 사용자에서 회선까지의 구간만 덮습니다. 회선에서 목적 사이트까지의 구간, 그리고 기기가 요청을 클라이언트에 넘기는 방식은 별개의 단계입니다. 그래서 점검할 때는 연결 상태 표시등만 보지 말고 요청이 지나가는 경로를 구간별로 따라가야 합니다.

DNS 해석 이상의 세 가지 양상

첫째, 모든 사이트가 열리지 않는데 클라이언트에는 트래픽이 흐르는 것이 보입니다. 대개 해석 요청이 회선을 타지 않고 로컬 네트워크에서 잘못된 결과를 받은 경우입니다.

둘째, 일부 사이트는 열리고 일부는 열리지 않는데, 열리지 않는 쪽이 해외 사이트인 경우입니다. 전형적인 해석 결과 간섭 현상입니다.

셋째, 열리기는 하는데 매우 느려 매번 십여 초를 기다려야 결과가 나옵니다. 해석 타임아웃 후 예비 서버로 넘어가는 경우입니다.

자가 점검 방법: 명령줄에서 공용 DNS 서비스에 같은 도메인을 직접 질의하고 두 결과를 비교합니다.

nslookup example.com 1.1.1.1
nslookup example.com

두 명령의 응답 주소가 완전히 다르다면 기본 해석이 실제 결과를 돌려주지 않는 것입니다. macOS와 Linux에서는 dig를 쓰면 출력이 더 깔끔합니다:

dig @1.1.1.1 example.com +short
dig example.com +short

해결책은 클라이언트에서 해석이 회선을 타도록 설정하거나, 신뢰할 수 있는 해석 서비스를 직접 지정하는 것입니다. 변경 후에는 반드시 클라이언트를 완전히 종료했다가 다시 실행해야 합니다. 해석 설정은 이미 맺어진 연결에는 적용되지 않습니다.

분할 규칙이 대상을 직결로 돌려보낸 경우

분할 규칙은 어떤 도메인이 회선을 타고 어떤 도메인이 로컬로 갈지 결정합니다. 규칙 목록이 오래되었거나, 규칙 모드를 잘못 골랐거나, 직결 규칙을 직접 추가한 경우 특정 사이트가 직결로 되돌아갑니다.

판단 방법은 단순합니다. 클라이언트를 전역 모드로 바꾸고 같은 사이트를 다시 열어 봅니다. 열리면 분할 문제, 열리지 않으면 분할 문제가 아닙니다. 분할 문제로 확인되면 먼저 규칙 목록을 갱신하고, 사용자 정의 규칙 목록에 관련 항목이 있는지 확인하세요. 전역 모드는 점검 수단일 뿐이므로 평소에는 규칙 모드를 쓰는 편이 좋습니다. 그렇지 않으면 국내 사이트도 한 바퀴 돌아 지연만 늘어납니다.

시스템 프록시와 브라우저 프록시 불일치

클라이언트가 시스템 프록시를 넘겨받은 뒤 브라우저에 프록시 확장 프로그램이 설치되어 있으면 확장이 시스템 설정을 덮어씁니다. 그러면 클라이언트는 연결됨으로 표시되는데 브라우저는 여전히 로컬 네트워크로 나갑니다.

확인 방법: 브라우저에서 현재 출구 지역을 보여주는 페이지를 열고 클라이언트에 표시된 회선 지역과 비교합니다. 다르다면 프록시가 실제로 적용되지 않은 것입니다. 또 하나 흔한 지점은 자동 구성 스크립트로, 스크립트의 판단 오류로 대상 도메인이 제외되기도 합니다. 임시로 전역 프록시로 바꿔 한 번 테스트하면 확인됩니다.

판단 흐름

04

속도 저하와 저녁 시간대 지연: 회선 유형, 혼잡, 로컬 병목

'느리다'는 오판하기 가장 쉬운 현상입니다. 최소 세 가지 전혀 다른 원인이 있고, 대응 방법도 세 가지로 완전히 다르기 때문입니다.

먼저 세 가지 '느림'을 구분하기

핸드셰이크 지연: 연결을 누른 뒤 한참 지나야 연결됨으로 표시됩니다. 터널 생성 과정이 느린 것으로 대역폭과 무관하며, 대개 회선 입구의 응답 문제입니다.

첫 바이트 지연: 연결은 빠른데 페이지가 오래 로딩되고, 내용이 나오기 시작하면 이후 로딩은 빠릅니다. 지연과 해석의 문제이지 대역폭 문제가 아닙니다.

지속 처리량 저하: 페이지는 열리지만 영상이 계속 버퍼링되고 다운로드 속도가 오르지 않습니다. 이것이 진짜 대역폭 문제입니다.

세 가지 느림의 원인은 완전히 다릅니다. 먼저 자기 상황이 어디에 해당하는지 정하고 손대면 헛된 시도를 크게 줄일 수 있습니다.

회선 유형과 적합한 용도

IEPL 전용선: 입구에서 출구까지 독립 통로를 쓰므로 다른 사용자와 경쟁하지 않고 지연이 안정적입니다. 실시간 회의, 원격 데스크톱, API 호출처럼 지터에 민감한 용도에 적합합니다.

중계: 중계 노드를 거쳐 해외로 나가므로 경로가 직결보다 짧고, 저녁 시간대 성능이 대체로 직결보다 좋습니다. 영상과 일상 브라우징에 적합합니다.

직결: 로컬에서 해외 노드로 바로 연결하므로 경로가 가장 길고 국제 구간 혼잡의 영향을 가장 크게 받습니다. 지연에 민감하지 않은 대용량 다운로드에 적합합니다.

저녁 시간대 지연의 원인

저녁 8시부터 11시는 국제 구간이 가장 혼잡한 시간대입니다. 이 시간에는 직결 회선의 지터가 눈에 띄게 커지고, 중계와 전용선은 상대적으로 안정적입니다. 이 시간대에만 느리고 다른 시간에는 정상이라면 회선 혼잡으로 판단할 수 있으며, 사용자의 네트워크나 기기 문제가 아닙니다.

대응 방법은 세 가지입니다. 중계나 전용선으로 바꾸기, 대용량 작업을 비혼잡 시간대로 옮기기, 클라이언트에서 프로토콜을 바꿔 보기입니다. 세 가지 모두 계정 설정을 건드릴 필요가 없고, 이미 구매한 요금제의 트래픽 한도에도 영향을 주지 않습니다. 120+ 국가 / 180+ 회선 규모라면 같은 지역에 보통 여러 회선이 있으므로, 하나를 고집하기보다 바꾸는 편이 빠릅니다.

로컬 병목 점검

먼저 무선 네트워크를 봅니다. 같은 기기를 랜선으로 공유기에 직결해 한 번 측정하고, 차이가 크다면 무선 문제입니다. 2.4GHz 대역은 저녁에 이웃 공유기와 겹치고, 5GHz 대역은 도달 거리가 짧아 벽 하나만 있어도 속도가 떨어질 수 있습니다.

다음은 공유기입니다. 오래된 공유기는 포워딩 성능이 제한적이라 기기 십여 대를 동시에 물리면 대역폭보다 포워딩 능력이 먼저 병목이 됩니다.

마지막으로 백그라운드입니다. 시스템 업데이트, 클라우드 동기화, 백업이 사용자 모르는 사이 업로드 대역을 가득 채웁니다. 업로드가 꽉 차면 다운로드도 느려 보입니다. 요청마다 확인 응답 패킷이 나가지 못하기 때문입니다.

언제 회선 문제가 아니라고 단정할 수 있나

세 가지 신호입니다. 기기를 바꿔도 속도가 같고, 네트워크를 바꿔도 속도가 같고, 비혼잡 시간대에도 속도가 같다면. 세 가지가 동시에 성립하면 문제는 회선이 아니라 목적 사이트 자체나 로컬 기기에 있을 가능성이 큽니다.

반대로 특정 기기에서만 느리거나, 특정 네트워크에서만 느리거나, 혼잡 시간대에만 느리다면 위 절들을 따라 점검한 뒤 회선 교체를 고려하세요. 방향을 제대로 잡으면 대개 몇 분 안에 해결됩니다.

05

잦은 끊김: 세션 유지, 네트워크 전환, 절전 정책

끊김은 연결 실패보다 성가십니다. 좋았다 나빴다 하고 재현이 어렵기 때문입니다. 하지만 끊김의 형태 자체가 정보를 담고 있으므로 형태로 분류하면 범위가 절반으로 줄어듭니다.

세 가지 끊김 형태

즉시 끊김: 연결 후 몇 초 안에 끊깁니다. 대개 프로토콜이나 포트가 중간 장비에 식별되어 리셋된 경우입니다.

주기적 끊김: 몇 분마다 끊기고 간격이 비교적 일정합니다. 대개 하트비트 타임아웃이거나 클라이언트와 회선 사이의 세션 유지 실패입니다.

장시간 후 끊김: 수십 분에서 몇 시간 사용한 뒤 끊깁니다. 대개 네트워크 전환, 시스템 절전, 또는 회선 측 세션 회수입니다.

세션 유지와 하트비트

클라이언트는 세션을 유지하기 위해 회선으로 주기적으로 하트비트를 보냅니다. 간격이 너무 길면 중간 장비가 먼저 세션을 회수하고, 너무 짧으면 비정상 트래픽으로 판정됩니다. 대부분의 클라이언트에는 기본값이 있으므로 임의로 바꾸지 않는 것이 좋습니다.

클라이언트에 하트비트 관련 설정이 보인다면 먼저 기본값으로 되돌리고 계속 끊기는지 관찰하세요. 기본값 복원 자체가 유효한 변수 통제입니다. 바꾼 것을 먼저 원위치해야 남은 것이 진짜 문제입니다.

네트워크 전환으로 인한 재연결

노트북을 들고 거실에서 침실로 이동하면 무선 네트워크가 한 액세스 포인트에서 다른 곳으로 넘어가며 터널이 다시 만들어집니다. 재생성 중에는 모든 연결이 끊기므로 '갑자기 끊겼다가 다시 됐다'로 보입니다.

2.4GHz와 5GHz를 하나의 SSID로 묶은 네트워크에서는 기기가 두 대역을 오가며, 전환이 잦으면 끊김도 잦아집니다. 두 대역을 다른 네트워크 이름으로 분리하고 기기를 하나에 고정하면 확실히 개선됩니다.

실내에서 실외로 나가며 Wi-Fi에서 셀룰러로 넘어가는 것도 같은 종류의 문제입니다. 이런 끊김은 고장이 아니라 네트워크 환경이 바뀐 것이며, 클라이언트가 다시 연결하는 것은 정상 동작입니다.

절전 정책과 백그라운드 제한

이 항목은 모바일에서 가장 흔하며 8장에서 자세히 다룹니다. 데스크톱에도 비슷한 메커니즘이 있습니다. 시스템이 절전에 들어가면 네트워크 어댑터 전원이 꺼지고, 깨어난 뒤 터널을 다시 만들어야 합니다. 클라이언트가 깨어남 이벤트를 제대로 처리하지 못하면 연결됨으로 표시되지만 실제로는 통하지 않습니다. 이럴 때는 연결을 끊었다가 다시 연결하면 복구됩니다.

능동적 끊김과 수동적 끊김 구분

클라이언트 로그에는 보통 끊긴 이유가 남습니다. 능동적 끊김은 명확한 조작 기록이 있고, 수동적 끊김은 타임아웃, 리셋, 또는 아무 표시 없이 사라지는 형태로 나타납니다. 로그에 같은 종류의 타임아웃이 반복된다면 로컬 네트워크 불안정이 아니라 세션 유지 문제로 좁힐 수 있습니다. 이 단계만으로 '네트워크가 안 좋다'는 모호한 판단이 구체적인 방향으로 바뀝니다.

끊긴 시점 기록하기

종이 한 장이나 메모장을 준비해 끊긴 시각, 그때 하던 일, 사용 중이던 회선을 적습니다. 사흘만 기록해도 패턴이 드러납니다. 일정 간격이면 하트비트, 위치 변화를 따라가면 네트워크 전환, 시간대를 따라가면 회선 혼잡일 가능성이 큽니다.

이 기록은 문의할 때 매우 유용합니다. '자주 끊긴다'는 세 글자보다 훨씬 도움이 됩니다. 문제가 해결되었는지 스스로 판단하는 근거로도 가장 좋습니다.

06

구독 갱신 실패: 링크, 시간, 클라이언트 캐시

구독 갱신 실패는 두 가지로 나타납니다. 회선 목록이 그대로 비어 버리거나, 회선은 남아 있는데 전부 연결되지 않는 경우입니다. 둘 다 클라이언트가 가진 목록이 최신이 아니라는 같은 사실을 가리킵니다.

구독 갱신이 하는 일

구독은 계정 정보로 생성되는 회선 목록입니다. 클라이언트가 이 주소로 주기적으로 요청을 보내 최신 노드 목록, 분할 규칙, 설정 값을 받아갑니다. 갱신에 실패했다는 것은 클라이언트가 아직 예전 목록을 쓰고 있고, 그 목록의 회선은 이미 조정되었을 수 있다는 뜻입니다.

링크 만료와 권한

구독 주소에는 계정과 연결된 자격 증명이 포함됩니다. 비밀번호를 재설정했거나, 패널에서 구독을 다시 생성했거나, 계정 상태가 바뀌면 예전 주소는 효력을 잃습니다.

판단 방법: 구독 주소를 브라우저에 붙여 열어 봅니다. 내용이 반환되면 주소가 유효하고, 오류 페이지가 나오면 주소 자체에 문제가 있습니다. 주의할 점은 구독 주소가 계정 자격 증명과 같다는 것입니다. 단체 채팅방에 올리거나, 스크린샷에 담거나, 공개 코드 저장소에 커밋하지 마세요. 예시의 주소는 모두 가짜 값이며, 예를 들어 https://example.com/sub?token=YOUR_TOKEN 같은 형태입니다. 실제 주소는 본인 기기에만 두세요.

갱신 시의 네트워크 조건

구독 갱신 자체도 네트워크를 씁니다. 이때 클라이언트가 '전역으로 회선 사용' 상태이고 그 회선이 막혀 있다면 갱신이 실패합니다. 연결이 안 되니 갱신해야 하고, 갱신해야 하는데 연결이 안 되는 순환입니다.

올바른 방법은 먼저 클라이언트를 직결로 바꾸거나 완전히 종료한 상태에서 로컬 네트워크로 한 번 갱신하고, 그다음 회선에 연결하는 것입니다.

클라이언트 캐시와 가져오기 방식

일부 클라이언트는 가져오기에 실패해도 예전 설정을 유지하며 화면에는 아무 이상도 표시하지 않습니다. 이럴 때는 예전 설정에서 갱신을 누르지 말고 기존 설정을 삭제한 뒤 다시 가져오세요.

가져오기 방식도 맞아야 합니다. 구독 주소는 '링크에서 가져오기'로 불러와야 하며, 노드 정보를 손으로 복사해 하나씩 추가하면 안 됩니다. 직접 추가한 노드는 구독 갱신을 따라가지 않으므로 시간이 지나면 전부 만료됩니다.

시스템 시간 불일치

구독 요청에는 타임스탬프가 붙습니다. 시스템 시간이 실제 시간과 몇 분 이상 차이 나면 서버가 요청을 거부합니다. 노트북을 오래 재부팅하지 않았거나 시간대를 잘못 설정한 경우에 생깁니다. 시스템 시간을 자동 동기화로 설정하고 클라이언트를 재시작한 뒤 다시 시도하세요.

구독 링크의 보안 경계

구독 주소가 유출되면 다른 사람이 내 트래픽을 쓸 수 있습니다. 사용량이 비정상적으로 늘었다면 가장 먼저 패널에서 구독 주소를 재생성하세요. 예전 주소는 즉시 무효가 됩니다.

또한 구독 주소를 브라우저 즐겨찾기에 넣어 기기 간에 동기화하거나, 메신저 파일 전송으로 자신에게 보내는 것도 피해야 합니다. 편해 보이지만 실제로는 자격 증명을 더 많은 곳에 복제하는 일입니다. 계정 가입에는 아이디와 비밀번호만 필요하며 이메일 주소는 필요하지 않습니다. 자격 증명 관리의 책임은 전적으로 본인에게 있으니 이 점은 특히 주의하세요.

07

특정 앱만 프록시를 타지 못함: 앱별 모드와 규칙 우선순위

브라우저에서는 페이지가 열리는데 특정 앱만 네트워크 오류를 띄우는 경우, 가장 흔한 '부분 장애' 유형입니다. 거의 항상 회선이 아니라 규칙이나 프록시 처리 방식의 문제입니다.

전역 모드와 규칙 모드

전역 모드에서는 모든 트래픽이 회선을 타고, 규칙 모드에서는 규칙표에 따라 판단합니다. 특정 앱만 프록시를 못 타는 일은 대개 규칙 모드에서 발생합니다. 규칙표에 그 앱의 도메인이 없거나, 직결 규칙에 걸렸기 때문입니다.

앱별 프록시의 두 가지 구현

하나는 클라이언트에서 처리합니다. 클라이언트가 설치된 앱 목록을 보여주고 어떤 앱을 회선으로, 어떤 앱을 직결로 보낼지 선택합니다. 이 방식은 클라이언트 권한 요구가 크며 Windows와 Android에서 지원이 비교적 좋습니다.

다른 하나는 시스템 계층에서 처리합니다. 가상 네트워크 어댑터와 라우팅 테이블을 이용해 모든 앱이 기본적으로 회선을 타고, 일부 앱만 규칙으로 제외합니다. macOS와 iOS가 여기에 해당합니다. 시스템 계층 처리의 장점은 앱이 프록시를 인식할 필요가 없다는 것이고, 단점은 점검할 때 '어떤 앱이 어느 경로로 갔는지' 같은 세부 정보를 볼 수 없다는 것입니다.

규칙 우선순위와 흔한 오판

규칙표는 보통 순서대로 매칭되며 첫 번째로 걸린 규칙에서 멈춥니다. 직결 규칙을 맨 앞에 두면 같은 도메인에 대한 뒤쪽의 회선 사용 규칙은 모두 무효가 됩니다.

흔한 오판은 세 가지입니다. 도메인 접미사를 너무 넓게 적어 최상위 도메인 전체를 직결로 보낸 경우, 주소 대역 규칙과 도메인 규칙이 충돌하는 경우, 규칙 목록 버전이 오래되어 대상 사이트가 도메인을 바꿨는데 규칙이 따라가지 못한 경우입니다.

점검 방법: 클라이언트의 연결 로그에서 이 앱이 보낸 요청을 찾아 어떤 규칙에 걸렸는지 봅니다. 로그에는 보통 매칭된 규칙 이름이 적혀 있으므로 규칙표에서 거꾸로 찾으면 됩니다.

앱 자체의 네트워크 검사

일부 앱은 시작할 때 네트워크 환경 검사를 하고, 통과하지 못하면 시스템 프록시가 적용되어 있어도 네트워크 사용을 거부합니다. 이런 앱은 별도로 허용하거나 앱별 목록에서 회선 사용으로 지정해야 합니다.

또 다른 경우는 앱이 독자적인 해석 서비스나 하드코딩된 주소를 사용해 시스템 프록시를 우회하는 것입니다. 이때는 클라이언트의 전역 모드나 시스템 계층 가상 어댑터로 처리하는 수밖에 없습니다.

브라우저는 되고 앱은 안 되는 흔한 이유

브라우저는 시스템 프록시를 따르지만 앱은 그렇지 않을 수 있습니다. 일부 앱은 하위 네트워크 인터페이스를 직접 사용해 시스템 프록시 설정을 읽지 않습니다. 이런 앱은 가상 어댑터가 모든 트래픽을 넘겨받을 때만 회선을 탑니다.

판단 방법은 간단합니다. 클라이언트를 전역 모드로 바꿨을 때 앱이 정상으로 돌아오면 그 앱은 시스템 프록시를 읽지 않는 것이고, 그래도 안 되면 가상 어댑터조차 쓰지 못하는 것이므로 앱 자체의 네트워크 설정을 봐야 합니다.

판단 흐름

08

모바일 백그라운드 끊김과 기기 수 초과

모바일 기기에서의 끊김은 대부분 회선 문제가 아니라 시스템의 백그라운드 프로세스 제한 때문입니다. 두 플랫폼의 양상과 대처가 다릅니다.

iOS의 백그라운드 제한

iOS는 백그라운드 프로세스를 엄격하게 관리합니다. 백그라운드로 전환하면 연결은 시스템이 넘겨받지만 다른 앱의 백그라운드 활동은 제한됩니다. 그래서 화면을 잠갔다가 한참 뒤에 풀면 네트워크가 복구되기까지 몇 초가 걸립니다.

시스템 설정에서 VPN 구성의 '필요 시 연결'이 켜져 있어야 합니다. 그렇지 않으면 시스템이 유휴 상태에서 먼저 끊어 버립니다. 또 하나 흔한 지점은 저전력 모드입니다. 켜면 시스템이 백그라운드 새로 고침을 미뤄 연결 복구가 느려지지만, 완전히 끊기지는 않는 것이 보통입니다.

Android의 배터리 최적화와 자동 시작

Android는 제조사별 정책 차이가 큽니다. 기본 배터리 최적화는 화면이 꺼진 뒤 백그라운드 네트워크를 제한하고, 클라이언트 서비스가 제한되면 끊김으로 나타납니다.

시스템 설정에서 클라이언트를 배터리 최적화 예외로 등록하고 자동 시작과 백그라운드 활동을 허용해야 합니다. 일부 제조사는 별도의 절전 정책 스위치가 있어 따로 꺼야 합니다.

놓치기 쉬운 스위치가 하나 더 있습니다. '절전 모드에서 모바일 데이터 연결 끊기'입니다. 이 옵션이 켜져 있으면 화면이 꺼진 뒤 네트워크가 통째로 끊기고 연결도 자연히 끊깁니다. 점검할 때 이 항목부터 보세요.

셀룰러와 Wi-Fi 전환 시 재연결

이동 중에 기지국과 무선 네트워크를 자주 바꾸면 터널이 반복해서 재생성됩니다. 쓰지 않는 네트워크를 꺼 두면(예: 집에서는 셀룰러 데이터 끄기) 전환 횟수가 줄고 끊김도 줄어듭니다.

'기기 수 초과'가 이 서비스에 해당하지 않는 이유

다른 서비스에서 옮겨 온 사용자는 연결이 안 될 때 기기 수 초과를 먼저 의심하는 경우가 많습니다. 이 서비스의 구독은 동시 접속 기기 수에 제한이 없으며, 같은 계정을 여러 기기에서 동시에 사용해도 됩니다. 기기가 많다고 해서 접속이 끊기지 않습니다. Windows / macOS / iOS / Android / Linux 다섯 플랫폼에서 동시에 접속할 수 있습니다.

따라서 '하나를 연결하면 다른 하나가 끊긴다'는 현상이 나타난다면 원인은 기기 수가 아니라 아래 몇 가지 중 하나입니다.

실제 원인은 보통 무엇인가

첫째, 같은 구독을 두 기기의 클라이언트가 동일한 식별자로 동시에 연결해 서버가 이전 세션을 회수하는 경우입니다. 각 기기에서 독립적인 클라이언트 인스턴스를 사용하고, 기기 식별자가 포함된 같은 설정 파일을 복사해 쓰지 않으면 해결됩니다.

둘째, 로컬 네트워크가 터널 하나만 허용하는 경우입니다. 일부 공유기와 공용 네트워크는 동시에 만들 수 있는 터널 수를 제한하며, 그러면 나중에 연결한 쪽이 먼저 연결한 쪽을 밀어냅니다.

셋째, 계정 상태 이상입니다. 이 경우는 사용자 패널에서 바로 확인할 수 있으니 추측할 필요가 없습니다. 트래픽 소진, 요금제 만료는 명확히 표시되며 기기 수와는 무관합니다.

09

언제 고객 지원을 찾아야 하나: 문의에 첨부할 정보

앞의 여덟 장은 스스로 해결할 수 있는 대부분의 문제를 다룹니다. 남은 일부는 문의하는 것이 맞습니다. 다만 문의의 품질이 처리 속도를 좌우합니다.

직접 해결할 것과 문의할 것

문의에 반드시 첨부할 6가지

현상을 어떻게 서술할까

좋은 예: '저녁 8시 이후 특정 지역 중계 회선으로 고화질 영상을 보면 2분마다 한 번 버퍼링이 걸립니다. 다른 지역 중계 회선으로 바꾸면 정상입니다. 같은 시간대에 다른 기기로 같은 회선을 써도 정상입니다.'

나쁜 예: '너무 느려요. 빨리 고쳐 주세요.'

전자는 회선과 시간대를 바로 좁힐 수 있고, 후자는 상담원이 처음부터 다시 물어야 하므로 주고받는 데만 하루 이틀이 걸립니다.

문의 전에 먼저 할 세 가지

첫째, 클라이언트와 기기를 재시작해 일시적 상태를 배제합니다. 둘째, 다른 회선으로 다시 측정해 단일 회선 문제인지 전체 회선 문제인지 확인합니다. 셋째, 계정 상태가 정상인지, 트래픽이 소진되지 않았고 요금제가 만료되지 않았는지 확인합니다.

세 가지를 합쳐도 5분이 채 걸리지 않지만, 상당수의 문의를 걸러냅니다.

문의할 때 하지 말아야 할 세 가지

구독 주소를 문의에 붙이지 마세요. 상담에 필요한 것은 현상과 점검 결과이지 자격 증명이 아닙니다. 한 문의에 무관한 문제 세 개를 몰아넣지 마세요. 나눠서 보내는 편이 훨씬 빠릅니다. 답변을 기다리는 동안 설정을 계속 바꾸지 마세요. 현상이 달라지면 앞서 모은 정보가 무효가 됩니다.

문의를 접수한 뒤

문의 창구는 사용자 패널 안에 있으며 로그인 후 접수할 수 있습니다. 접수 후 같은 문제를 중복 접수하지 마세요. 중복 문의는 처리 순서를 흐트러뜨립니다.

환불이 필요하다면 이 서비스는 7일 무조건 환불을 제공하며, 구체적인 조건은 이용약관 페이지를 기준으로 합니다. 가격과 요금제 전체 목록은 요금제 페이지에, 회선 분포는 노드 페이지에서 확인할 수 있으며 두 곳의 수치는 이 페이지와 동일합니다.