해외 네트워크 장애 해결 가이드

점검 개요: 장애가 어느 계층에서 생겼는지 먼저 판단합니다

점검의 목표는 모든 설정을 하나씩 바꿔 보는 것이 아니라, 최소한의 동작으로 문제가 발생한 구간을 특정하는 것입니다. 해외 접속은 최소 네 구간을 거칩니다. 기기 → 로컬 네트워크, 로컬 네트워크 → 회선 진입점, 회선 진입점 → 대상 사이트, 대상 사이트 → 결과 반환. 어느 구간에서 문제가 생기든 사용자 눈에는 똑같이 「안 열린다」로 보이지만, 해결 방법은 전혀 다릅니다.

먼저 「연결이 안 된다」와 「연결은 되지만 느리다」는 완전히 다른 문제임을 구분해야 합니다. 전자는 연결 수립 자체가 실패한 것이고, 후자는 연결은 되지만 품질이 부족한 것이며, 두 문제의 점검 경로는 겹치지 않습니다. 섞어서 설정을 바꾸면 문제만 더 복잡해집니다. 시간선도 두 가지로 나눠 봐야 합니다. 처음 설정부터 실패했다면 설정 방식이나 플랫폼 호환성 문제일 가능성이 크고, 한동안 쓰다가 갑자기 안 된다면 네트워크 환경, 회선 스케줄링, 계정 상태 중 하나가 바뀐 경우가 많습니다. 시간선이 다르면 먼저 확인할 방향도 달라집니다.

4계층 모델: 증상을 구간에 대응시키기

이 표의 목적은 30초 안에 어디부터 손댈지 정하는 것입니다. 증상이 「로컬 네트워크」 행에 해당한다면 클라이언트를 먼저 끊고 로컬 네트워크 자체가 정상인지 확인하세요. 로컬 네트워크가 안 되는 상황에서는 어떤 프록시 설정도 효과가 없으므로, 클라이언트만 계속 만지는 건 시간 낭비입니다.

3단계 특정법

아래 세 단계로 변수를 하나씩 바꿔 보세요. 한 단계에서 조건 하나만 바꿔야 결과를 신뢰할 수 있습니다. 세 가지를 한꺼번에 바꾸면 복구되더라도 무엇 때문인지 알 수 없습니다.

1. 회선 바꾸기

   클라이언트에서 다른 회선으로 바꿔 보세요. IEPL 전용선을 우선으로 시도합니다. 바꾼 뒤 정상으로 돌아오면 문제는 원래 회선에 집중된 것이므로 회선 이름, 지역, 문제가 발생한 시간대를 기록해 두고 문의에 함께 첨부하세요. 바꿔도 여전히 실패한다면 2단계로 넘어갑니다.

2. 기기 바꾸기

   같은 계정으로 다른 기기에서 같은 회선에 연결해 보세요. 다른 기기가 정상이라면 원래 기기의 클라이언트나 시스템 설정 문제이므로 해당 플랫폼 장으로 돌아가 점검합니다. 두 기기 모두 실패하면 3단계로 넘어갑니다.

3. 네트워크 바꾸기

   현재 Wi-Fi나 유선 인터넷 대신 모바일 핫스팟으로 바꿔 다시 연결해 보세요. 핫스팟에서는 정상이라면 원래 네트워크의 출구, 공유기, 통신사 구간에 문제가 있는 것이며 계정이나 회선과는 무관합니다.

세 단계가 모두 실패하면 단일 지점의 문제가 아니라고 봐도 됩니다. 9장의 문의 절차로 바로 넘어가고, 클라이언트에서 계속 반복 시도하지 마세요. 재설치와 회선 전환을 반복하면 멀쩡하던 설정까지 망가져 이후 원인 파악이 더 어려워집니다.

점검 전에 기록할 다섯 가지 정보

기록은 형식이 아닙니다. 회선 스케줄링은 동적이라 같은 문제도 시간대에 따라 양상이 달라질 수 있습니다. 기록이 있어야 규칙성을 판단할 수 있고, 없으면 기억에 의존해 설명하게 되어 소통 비용이 몇 배로 늘어납니다.

• 문제가 발생한 시각(분 단위)과 해당 시간대
• 당시 사용한 회선 이름과 지역, 다른 회선으로 바꿔 봤는지 여부
• 클라이언트 플랫폼과 OS 버전(Windows / macOS / iOS / Android / Linux)
• 오류 메시지 원문이나 스크린샷. 「안 열린다」만 적지 마세요.
• 이미 시도한 조치. 예: 「회선 3개, 기기 2대, 네트워크 2개로 바꿔 봤음」

언제 고객 지원에 문의해야 할까

다음 상황은 자가 점검을 계속하지 말고 바로 문의를 접수하는 것이 좋습니다.

• 같은 계정으로 회선 2개 이상, 기기 2대 이상, 서로 다른 네트워크 2개에서 모두 연결되지 않음
• 특정 회선만 하루 넘게 계속 실패하고 다른 회선은 정상
• 계정 관련 이상: 로그인 불가, 구독 가져오기 실패, 주문·결제 상태가 예상과 다름
• 클라이언트 자체가 멈추거나 반복적으로 강제 종료되거나 설치가 끝나지 않음

반대로 다음 상황은 먼저 자가 점검을 권합니다. 기기 한 대만 문제이거나, 특정 사이트 하나만 안 열리거나, 특정 시간대에만 느려지거나, 회선만 바꾸면 복구되는 경우입니다. 모두 단일 지점 현상이라 답변을 기다리는 것보다 직접 확인하는 편이 빠릅니다.

아예 연결 불가: 로컬 네트워크부터 계정 상태까지

「아예 연결 불가」는 클라이언트에서 연결을 눌러도 「연결 중」에서 멈춰 있거나 곧바로 연결 실패가 뜨고, 어떤 사이트도 열리지 않는 상태를 말합니다. 이 장은 가까운 쪽에서 먼 쪽 순서로 점검합니다. 기기 → 시스템 → 로컬 네트워크 → 회선 → 계정. 순서를 건너뛰지 마세요. 건너뛰며 설정을 바꾸면 변수가 한꺼번에 여러 개 생겨서 「바꾸기 전에는 어땠는지」조차 설명할 수 없게 됩니다.

클라이언트의 세 가지 상태부터 이해하기

클라이언트의 「연결됨」은 로컬 터널이 만들어졌다는 뜻일 뿐, 외부 출구가 살아 있다는 뜻은 아닙니다. 실제로 적용됐는지는 외부 IP가 바뀌었는지로 확인해야 합니다. 그래서 첫 단계는 버튼 색을 보는 것이 아니라 IP 확인 페이지를 열어 외부 IP의 지역이 선택한 회선의 지역과 일치하는지 보는 것입니다. 일치하지 않으면 트래픽이 실제로 나가지 않은 것이므로, 이후의 모든 「안 열린다」 판단은 성립하지 않습니다.

다섯 플랫폼의 클라이언트 모두 실행 로그를 제공합니다(일부 플랫폼에서는 「연결 로그」). 로그 마지막 줄을 보면 어느 단계에서 막히는지 대개 알 수 있습니다. 핸드셰이크에서 멈추면 로컬 네트워크가 포트를 막고 있거나 시스템 시간이 어긋난 경우가 많고, 인증에서 멈추면 계정이나 구독 상태에 문제가 있는 경우가 많습니다. 로그에 짧은 간격으로 재연결이 반복되면 로컬 네트워크가 불안정하거나 네트워크 어댑터가 절전 상태에 들어간 경우가 많습니다.

시스템 시간 오차는 가장 놓치기 쉬운 원인

연결 과정은 TLS 핸드셰이크에 의존하며, TLS는 기기 시간이 표준시와 몇 분 이내로 맞아야 합니다. 시스템 시간이 어긋나면 「연결 중」에서 계속 멈추거나 인증서 오류가 뜨는데, 사용자는 회선이 고장 났다고 생각하고 회선만 계속 바꾸다 보니 문제가 그대로 남습니다.

• Windows: 설정 → 시간 및 언어 → 날짜 및 시간에서 「자동으로 시간 설정」을 켭니다.
• macOS: 시스템 설정 → 일반 → 날짜 및 시간에서 자동 설정을 켭니다.
• iOS: 설정 → 일반 → 날짜 및 시간에서 「자동 설정」을 켭니다.
• Android: 설정 → 시스템 → 날짜 및 시간에서 자동 설정을 켭니다(제조사에 따라 메뉴 경로가 조금씩 다릅니다).

수정한 뒤 클라이언트를 다시 시작해 한 번 더 시도하세요. 오랫동안 네트워크에 연결하지 않은 기기는 시간 오차가 수십 분까지 쌓일 수 있으므로, 이런 경우에는 특히 시간을 먼저 맞추고 다른 항목을 확인해야 합니다.

로컬 네트워크와 보안 소프트웨어

• 서드파티 방화벽이나 보안 소프트웨어의 「네트워크 보호」, 「트래픽 모니터링」 기능이 터널 생성을 막을 수 있으니 잠시 끄고 다시 시도해 보세요.
• 시스템 프록시 설정에 예전 프록시 주소가 남아 있는지 확인하세요(Windows: 설정 → 네트워크 및 인터넷 → 프록시).
• 공유기의 인터넷 사용 관리, 자녀 보호, 광고 차단 기능이 회선 진입점을 의심 대상으로 차단할 수 있습니다.
• 회사나 학교 네트워크는 일반 포트만 허용하는 경우가 있는데, 이럴 때는 프로토콜이나 포트를 바꾸면 대개 복구됩니다.

회선 바꾸기와 프로토콜 바꾸기

먼저 IEPL 전용선으로 바꿔 다시 시도하세요. 모든 회선이 실패한다면 프로토콜을 바꿉니다. Trojan, VLESS, Hysteria2, Shadowsocks 사이에서 한 번에 하나씩만 바꿔 보세요. 특정 네트워크에서 특정 프로토콜이 차단되는 일은 흔하며, 다른 프로토콜로 바꾸면 곧바로 복구되는 경우가 많습니다. 재구매나 구독 재등록은 필요하지 않습니다.

계정 상태 자가 점검

• 요금제가 유효 기간 내인지, 트래픽을 모두 썼는지(트래픽은 개통일 기준으로 매월 초기화됩니다).
• 구독 주소를 다른 사람과 공유해 로그인 상태가 서로 밀어내고 있지 않은지
• 짧은 시간에 여러 지역에서 반복 로그인해 이상 접속으로 판정되지 않았는지

가입에는 이메일 주소가 필요 없고 아이디 + 비밀번호만으로 가입이 끝나므로, 계정 관련 작업은 모두 사용자 패널 안에서 처리합니다. 비밀번호를 잊었다면 패널의 재설정 절차를 따르면 되고, 추가로 제공할 정보는 없습니다.

증상 대조표

연결은 되지만 페이지가 안 열림

이 유형의 공통점은 클라이언트는 연결됨으로 표시되는데 브라우저에서 페이지가 계속 로딩만 되거나 「사이트에 연결할 수 없음」이 뜬다는 것입니다. 우선 회선은 건드리지 말고 아래 순서대로 트래픽이 실제로 프록시를 타는지 확인하세요. 「연결은 됐는데 안 열린다」의 대부분은 처음 두 단계에서 걸러집니다.

「연결됨」은 「프록시 적용됨」이 아니다

클라이언트는 두 가지 방식으로 동작합니다. 시스템 프록시 모드는 시스템 프록시 설정만 바꾸는 방식으로, 브라우저와 이 설정을 따르는 앱만 프록시를 타고 다른 앱은 영향을 받지 않습니다. TUN(가상 네트워크 어댑터) 모드는 시스템 프록시를 인식하지 않는 앱까지 포함해 모든 트래픽을 가져갑니다. 클라이언트가 시스템 프록시 모드인데 브라우저에 프록시 설정을 가로채는 확장 프로그램이 깔려 있으면 시스템 설정이 덮어써져서, 클라이언트는 연결됐다고 하는데 브라우저는 여전히 안 열리는 상황이 됩니다.

판단 방법은 간단합니다. 본 서비스의 IP 확인 페이지를 열어 표시되는 외부 IP의 지역이 선택한 회선의 지역과 같은지 보세요. 다르면 트래픽이 프록시를 타지 않은 것이므로 클라이언트 모드나 브라우저 확장 프로그램이 원인이고, 같다면 프록시는 정상 적용된 것이니 다음 항목을 확인하면 됩니다.

명령줄로 문제 범위를 한 계층으로 좁히기

브라우저가 보여주는 오류 메시지는 대개 두루뭉술하지만, 명령줄을 쓰면 범위를 곧바로 좁힐 수 있습니다. 아래 세 줄은 각각 대상 사이트에 도달할 수 있는지, 도메인이 해석되는지, 해석 결과가 안정적인지를 확인합니다.

# 1. 대상 사이트에 도달할 수 있는지 확인(예시 도메인이므로 실제 접속할 사이트로 바꾸세요)
curl -I --max-time 10 https://www.example.com

# 2. DNS 해석만 수행해 도메인이 주소로 해석되는지 확인
nslookup www.example.com

# 3. 지정한 DNS로 다시 해석해 두 결과가 일치하는지 비교
nslookup www.example.com 1.1.1.1

curl이 200 또는 301을 반환하면 연결 자체는 살아 있으므로 문제는 브라우저 쪽입니다. curl은 시간 초과인데 nslookup은 결과가 나오면 출구나 대상 사이트에 문제가 있습니다. nslookup 자체가 실패하면 8장의 DNS 점검으로 바로 넘어가세요. 세 번의 테스트는 같은 네트워크 환경에서 해야 결과를 비교할 수 있습니다.

상황별 판단

• 모든 사이트가 안 열릴 때: DNS와 터널이 적용됐는지 먼저 보고, 그다음 회선, 마지막으로 계정 상태를 확인합니다.
• 일부 사이트만 안 열릴 때: 분할 규칙에서 해당 도메인이 직결로 지정돼 있는지, 대상 사이트가 점검 중인지 확인합니다.
• 브라우저만 안 열리고 다른 앱은 정상일 때: 브라우저 확장 프로그램과 브라우저 자체 암호화 DNS 설정을 확인합니다.
• 기기 한 대만 안 열릴 때: 다른 기기와 비교해 계정 문제가 아니라 기기 측 문제인지 확인합니다.

IPv6 때문에 생기는 「반쪽짜리 정상」

일부 인터넷 회선은 IPv4와 IPv6 주소를 함께 부여하고, 시스템은 IPv6를 우선 사용합니다. 회선이 IPv4만 처리한다면 「어떤 사이트는 열리고 어떤 사이트는 계속 로딩만 되는」 것처럼 보이는 무작위 현상이 나타날 수 있습니다. 해결 방법은 두 가지입니다. 클라이언트에서 TUN 모드를 켜 모든 트래픽을 터널로 보내거나, 시스템 네트워크 설정에서 IPv6를 잠시 끄고 다시 측정해 결과를 비교하는 것입니다.

대상 사이트 측 문제

대상 사이트 자체의 장애도 무시하면 안 됩니다. 다른 회선, 다른 기기, 다른 네트워크로 같은 사이트에 각각 접속해 봤을 때 셋 다 실패하고 다른 사이트는 모두 정상이라면, 문제는 대상 사이트 측에 있는 것이므로 본 서비스와는 무관하며 상대가 복구될 때까지 기다리면 됩니다.

브라우저 확장 프로그램과 보안 소프트웨어

광고 차단, 스크립트 관리, 프록시 전환 확장 프로그램은 모두 요청 경로를 바꿉니다. 점검할 때는 전부 잠시 끄고 정상으로 돌아오는지 확인한 뒤 하나씩 켜서 어떤 확장 프로그램이 영향을 주는지 찾아내세요. 몇 분이면 끝나지만 복잡해 보이는 문제 상당수를 걸러낼 수 있습니다.

구독 업데이트 실패: 링크, 캐시, 상태 점검

구독은 클라이언트가 회선 목록을 받아오는 통로입니다. 업데이트가 실패해도 클라이언트는 보통 마지막으로 성공한 노드를 그대로 유지하므로, 「연결은 되지만 노드 목록이 예전 것」인 경우도 있고 구독 업데이트 실패가 바로 뜨는 경우도 있습니다. 어느 쪽인지 먼저 확인한 뒤 대응하세요. 전자는 대개 사용에 지장이 없고, 후자는 즉시 처리해야 합니다.

먼저 확인할 세 가지

• 기기가 지금 정상적으로 인터넷에 연결돼 있어야 합니다. 구독 업데이트 자체가 정상적인 네트워크 요청을 필요로 하므로, 오프라인 상태에서 업데이트를 누르면 오류가 나는 게 당연합니다.
• 시스템 시간이 자동 설정돼 있어야 합니다. 시간이 어긋나면 요청이 TLS 단계에서 실패하는데, 오류 메시지는 대개 네트워크 문제처럼 보입니다.
• 요금제가 유효 기간 내이고 트래픽이 남아 있어야 합니다(트래픽은 개통일 기준으로 매월 초기화됩니다).

세 가지가 모두 정상일 때 다음으로 넘어가세요. 이 세 항목이 구독 업데이트 실패의 가장 흔한 원인을 덮고 있으므로, 먼저 배제하면 시간을 크게 아낄 수 있습니다.

구독 주소의 형태

구독 주소는 자격 증명이 포함된 링크로, 클라이언트가 이 링크로 회선 목록을 가져옵니다. 아래는 형식 예시일 뿐이며, 실제 주소는 사용자 패널에 로그인해 「개요」 페이지에서 복사하세요.

# 구독 주소 예시: 형식 설명용이며 실제로 사용할 수 있는 주소가 아닙니다
https://example.com/sub?token=YOUR_TOKEN

# 일부 클라이언트는 유형별로 다른 형식을 반환하도록 지원합니다(예시)
https://example.com/sub?token=YOUR_TOKEN&flag=clash

구독 주소는 계정에 묶여 있고 접근 자격 증명을 포함하므로 비밀번호와 같습니다. 단체 채팅방에 올리거나, 캡처해서 보내거나, 공개된 설정 파일이나 코드 저장소에 붙여 넣지 마세요. 여러 기기에서 쓸 때는 각 기기에 같은 주소를 따로 가져오면 되고, 별도 신청도 필요 없으며 기기 수 제한도 받지 않습니다.

두 가지 가져오기 방식

링크 가져오기를 우선으로 권합니다. 노드 직접 추가는 예비 수단으로, 클라이언트에 서버 주소, 포트, 프로토콜, 자격 증명을 하나씩 입력하는 방식입니다. 직접 추가한 노드는 이후 업데이트를 따라가지 않으므로, 수동으로 넣은 회선이 연결되지 않으면 링크 가져오기 방식으로 되돌려 회선 자체가 조정된 것인지 먼저 확인하세요.

업데이트 실패의 흔한 원인

업데이트 주기와 시점

일주일에 한 번 업데이트를 권합니다. 회선이나 지역을 바꿀 때, 속도가 떨어진 것 같을 때도 프로토콜을 급하게 바꾸지 말고 먼저 수동으로 한 번 업데이트해 보세요. 업데이트 후 노드 목록은 지역별로 다시 묶입니다. 특정 지역의 노드 수가 달라졌다면 대개 서버에서 회선을 조정하는 중이므로, 잠시 후 다시 업데이트하면 됩니다.

속도 저하와 저녁 시간대 지연

「느리다」는 결과일 뿐 원인이 아닙니다. 병목이 어느 구간인지 먼저 측정한 뒤 무엇을 바꿀지 정하세요. 이 장은 「로컬 측정 → 출구 측정 → 회선 조정」 순서로 진행합니다. 순서를 뒤집으면 로컬 대역폭 문제를 회선 문제로 오해하기 쉬워, 회선만 여러 개 바꿔도 나아지지 않습니다.

로컬 대역폭부터 측정

클라이언트를 끊고 로컬 인터넷의 실제 속도를 한 번 측정해 기록한 뒤, 클라이언트를 연결하고 다시 측정하세요. 두 결과의 차이가 바로 프록시 구간에서 생기는 손실입니다. 로컬 인터넷 자체의 수치가 낮다면 어떤 회선으로 바꿔도 빨라지지 않으므로, 이때는 통신사에 먼저 문의해야 합니다.

속도 측정 시 두 가지를 주의하세요. 두 번 모두 같은 측정 서비스를 써야 결과를 비교할 수 있습니다. 백그라운드 다운로드, 클라우드 동기화, 시스템 업데이트는 대역폭을 가득 채워 결과를 크게 왜곡하므로 꺼 두세요. 측정 결과는 서버 부하의 영향을 받으므로 한 번의 결과로 판단하지 말고 세 번 연속 측정해 중간값을 보는 편이 더 믿을 만합니다.

회선 유형의 차이

세 가지 회선 유형 모두 110+ 개 국가 / 250+ 개 회선 범위에 포함되며, 클라이언트에서 지역과 유형으로 바로 필터링할 수 있습니다. 저녁 시간대에 IEPL 전용선을 우선 권하는 이유는 전용선 통로가 공용 인터넷의 국제 출구를 거치지 않아 전체 혼잡의 영향을 덜 받기 때문입니다. 직결 회선은 경로가 가장 짧지만, 오히려 피크 시간대에 공용 출구 혼잡에 가장 쉽게 발목이 잡힙니다.

프로토콜과 오버헤드

프로토콜은 캡슐화 방식과 추가 오버헤드를 결정합니다. Hysteria2는 QUIC 기반이라 패킷 손실이 많은 네트워크에서 더 안정적이며, 회선 품질 변동이 큰 상황에 적합합니다. Trojan과 VLESS는 TLS를 사용해 호환성이 좋고 대부분의 일상 사용에 맞습니다. Shadowsocks는 오버헤드가 작아 오래된 기기에서 더 나은 성능을 보입니다. 프로토콜은 언제든 바꿀 수 있으며, 바꾼 뒤에는 한 번 다시 연결하면 되고 구독을 다시 가져올 필요는 없습니다.

기기 측 병목

• Wi-Fi 대역: 2.4GHz는 범위가 넓지만 속도 상한이 낮으므로 가까이 있을 때는 5GHz를 우선 연결하세요.
• 오래된 기기의 암호화 성능: 구형 프로세서는 암호화·복호화 부담이 커서 페이지는 열리지만 영상이 끊기는 증상으로 나타납니다.
• 백그라운드 작업: 시스템 업데이트, 클라우드 동기화, 게임 플랫폼 다운로드가 대역폭을 계속 차지합니다.
• 공유기 성능: 보급형 공유기는 여러 기기를 동시에 쓸 때 인터넷 회선보다 전달 능력이 먼저 한계에 닿을 수 있습니다.

저녁 시간대 대응 순서

아래 순서대로 하나씩 시도하고, 한 번에 한 항목만 바꾼 뒤 곧바로 다시 측정하세요.

1. IEPL 전용선으로 전환

   대상 사이트와 가까운 지역을 우선 선택하세요. 같은 지역에 전용선이 여러 개라면 하나씩 시도하며 피크 시간대에 어느 회선이 더 안정적인지 기록하세요.

2. 프로토콜 전환

   Trojan, VLESS, Hysteria2, Shadowsocks 중 다른 것으로 바꿔 보세요. 특히 패킷 손실이 뚜렷할 때는 QUIC 기반 프로토콜의 개선 폭이 더 큰 편입니다.

3. 분할 규칙 확인

   한국 내 사이트는 직결로 보내 터널 안의 불필요한 트래픽을 줄이고, 대상 사이트를 실수로 직결로 통과시키는 규칙이 없는지도 확인하세요.

4. 로컬 문제가 아닌지 확인

   다른 기기, 다른 네트워크로 다시 측정하세요. 원래 기기만 느리다면 문제는 기기나 로컬 네트워크에 있는 것이며 회선과는 무관합니다.

시간대별 증상과 권장 조치

특정 시간대에만 느려지고 회선을 바꾸면 뚜렷하게 나아진다면, 계정이나 기기 문제가 아니라 국제 출구 혼잡이라고 봐도 됩니다. 스포츠 중계처럼 지연에 민감한 상황의 회선 선택 기준은 스포츠 중계 VPN 추천 글에서 정리했습니다.

잦은 끊김과 모바일 백그라운드 종료

연결 끊김은 두 가지입니다. 하나는 실제로 끊겨서 클라이언트 상태가 미연결로 돌아가는 경우, 다른 하나는 「가짜 끊김」으로 클라이언트는 연결됨으로 표시되는데 트래픽이 멈춘 경우입니다. 둘은 점검 방향이 완전히 다르므로 먼저 구분해야 잘못된 방향에서 헤매지 않습니다.

진짜 끊김과 가짜 끊김 구분하기

• 진짜 끊김: 클라이언트 상태가 미연결로 돌아가고 로그에 끊김 기록이 남습니다. 로컬 네트워크, 네트워크 어댑터 절전, 구간 품질을 확인합니다.
• 가짜 끊김: 상태는 연결됨인데 페이지가 열리지 않습니다. 연결 유지(keep-alive) 설정, DNS, 시스템의 클라이언트 프로세스 회수를 확인합니다.

판단 방법은 끊김이 발생한 순간 IP 확인 페이지를 바로 열어 보는 것입니다. 열리면 터널은 살아 있으므로 애플리케이션 계층 문제이고, 열리지 않으면 터널이 실제로 끊긴 것입니다. 몇 초면 끝나지만 이후 점검 방향을 결정해 줍니다.

데스크톱: 네트워크 어댑터 절전과 전원 관리

• Windows: 장치 관리자 → 네트워크 어댑터 → 속성 → 전원 관리에서 「전원을 절약하기 위해 컴퓨터가 이 장치를 끌 수 있음」을 해제합니다.
• Windows: 제어판 → 전원 옵션에서 계획을 「고성능」으로 바꿔 프로세서와 네트워크 어댑터가 자주 저전력으로 내려가지 않게 합니다.
• macOS: 시스템 설정 → 배터리에서 「저전력 모드」를 끄거나, 사용 중에는 전원을 연결합니다.

이 세 가지가 데스크톱 연결 끊김의 가장 흔한 원인입니다. 무선 어댑터가 유휴 상태에서 절전에 들어가면 복구에 시간이 걸려, 일정 간격으로 버벅이거나 아예 끊기는 증상이 나타납니다.

모바일: 백그라운드 프로세스 회수

iOS와 Android 모두 메모리가 부족하거나 절전 모드일 때 백그라운드 프로세스를 회수합니다. 프록시 프로세스가 회수되면 다른 앱으로 잠깐 전환했다가 돌아왔을 때 연결이 이미 끊겨 있고 아무런 알림도 없습니다.

• iOS: 설정 → 일반 → 백그라운드 앱 새로 고침에서 클라이언트를 허용하고, 저전력 모드도 함께 끕니다.
• Android: 설정 → 앱 → 클라이언트 → 배터리에서 「제한 없음」을 선택하거나 절전 예외 목록에 추가합니다.
• Android: 최근 앱 목록에서 클라이언트를 잠가 일괄 정리로 종료되지 않게 합니다.
• 시스템에 내장된 「스마트 절전」, 「딥 슬립」류 기능이 클라이언트를 제한하지 않도록 해제합니다.

네트워크 전환 시 재연결

Wi-Fi에서 모바일 네트워크로 바꾸거나 다른 Wi-Fi로 로밍할 때는 터널을 다시 만들어야 합니다. 일부 시스템은 십여 초를 기다린 뒤 복구되는데 이는 정상입니다. 계속 복구되지 않으면 수동으로 끊고 다시 연결하면 되고, 기기를 재부팅할 필요는 없습니다. 두 네트워크를 자주 오갈 때는 연결이 안정된 뒤에 오래 걸리는 작업을 시작하는 편이 좋습니다.

공유기와 모뎀

오래 켜 둔 공유기는 세션 테이블이 가득 차거나 메모리 사용량이 높아질 수 있고, 이때는 프록시 연결만 끊기는 게 아니라 네트워크 전체가 간헐적으로 버벅입니다. 모뎀과 공유기의 전원을 한 번 껐다 켜고 하루 정도 지켜보세요. 끊김 빈도가 뚜렷하게 줄면 문제는 로컬 네트워크 장비에 있습니다.

밴드 통합과 로밍

일부 공유기는 2.4GHz와 5GHz를 같은 이름으로 묶는데, 기기가 대역 사이를 오갈 때 연결이 잠깐 끊깁니다. 집에 공유기가 여러 대일 때 로밍 설정이 맞지 않아도 같은 현상이 생깁니다. 두 대역을 서로 다른 이름으로 나누고 하나에 고정 연결해 끊김이 줄어드는지 확인해 보세요.

반복 재설치보다 규칙성 기록이 더 유용

끊김 간격, 지속 시간, 당시 사용한 회선과 네트워크 유형을 기록하세요. 일정한 간격으로 끊긴다면 대개 연결 유지나 절전 설정 때문이고, 불규칙하게 끊긴다면 구간 품질이나 로컬 네트워크 문제일 가능성이 큽니다. 안드로이드 기기는 제조사별 절전 정책 차이가 크므로, 설치부터 예외 목록 등록까지의 전체 과정은 안드로이드 VPN 처음부터 글을 참고하세요.

특정 앱 프록시 미적용

브라우저는 정상인데 특정 데스크톱 프로그램, 게임, 명령줄 도구가 연결되지 않는다면 대개 회선 문제가 아니라 그 앱이 프록시를 타지 않는 것입니다. 원인은 세 가지로 모입니다. 프록시 모드, 분할 규칙, 앱 자체의 네트워크 동작 방식입니다. 이 세 가지를 순서대로 확인하면 대부분 원인을 찾을 수 있습니다.

프록시 모드가 대상을 결정한다

분할 규칙의 매칭 순서

분할 규칙은 도메인, IP, 앱 이름 순으로 매칭되며 먼저 걸리는 규칙이 우선 적용됩니다. 대상 도메인이 직결 규칙에 들어 있거나 더 앞선 규칙에 먼저 걸리면, 그 앱은 클라이언트의 앱 목록에 있더라도 프록시를 타지 않습니다.

점검 방법은 클라이언트의 연결 로그를 열고 문제가 되는 앱을 한 번 조작한 뒤, 해당 연결 기록이 로그에 나타나는지 보는 것입니다. 기록이 없으면 트래픽이 클라이언트에 들어오지도 않은 것이고, 기록은 있는데 직결로 표시되면 규칙이 통과시킨 것입니다. 기록이 있고 프록시를 탔다면 문제는 앱 자체나 대상 사이트에 있습니다.

흔한 설정 오류

• 규칙 목록에 「직결」 항목을 직접 추가한 뒤 삭제하는 걸 잊음
• 일부 프로세스만 프록시 대상으로 지정해 해당 앱이 목록에 없음
• 앱이 자체 네트워크 스택을 사용함. 일부 다운로드 도구와 게임 플랫폼은 시스템 프록시를 우회합니다.
• 앱이 IPv6를 우선 사용하는데 회선은 IPv4만 처리함

게임과 UDP 앱

게임류 앱은 UDP를 많이 쓰는데 시스템 프록시는 보통 TCP 트래픽만 처리하므로, 「브라우저는 되는데 게임은 안 들어가진다」는 전형적인 현상입니다. 이런 앱은 클라이언트에서 TUN 모드를 켜고 UDP 전달을 지원하는지 확인해야 합니다. 켠 뒤 지연이 오히려 높아지면 지연이 더 낮은 지역 노드로 바꾸세요.

AI 도구 앱

ChatGPT, Claude, Gemini 같은 AI 도구는 연결 안정성에 더 민감합니다. 대부분 장기 연결을 사용하므로 중간에 끊기면 세션을 다시 만들어야 하고, 「로그인 후 계속 로딩만 됨」이나 「답변이 중간에 끊김」으로 나타납니다. 이럴 때는 IEPL 전용선으로 먼저 바꾸고, 해당 앱이 프록시 대상에 포함되는지 확인하세요. 더 자세한 방법은 ChatGPT 가속 페이지에 정리해 두었습니다.

적용 여부 확인

가장 직접적인 확인 방법은 문제가 되는 앱에서 프록시를 타야만 열리는 주소에 접속해 보거나, 앱에 내장된 네트워크 진단으로 출구 주소를 확인하는 것입니다. 본 서비스의 IP 확인 페이지로 현재 출구를 확인해도 됩니다. 데스크톱에서 전역 프록시와 분할 규칙 중 무엇을 고를지, 부팅 시 자동 실행은 어떻게 설정하는지는 Windows VPN 추천 글에 정리했습니다.

DNS 오류와 외부 IP 자가 점검

DNS는 도메인을 IP 주소로 변환하는 역할을 합니다. DNS에 문제가 생기면 증상이 헷갈리기 쉽습니다. 페이지는 안 열리는데 메신저류 앱은 정상이거나, 같은 기기에서 어떤 도메인은 해석되고 어떤 도메인은 안 되기도 합니다. 어느 유형인지 먼저 구분한 뒤 무엇을 바꿀지 정하세요.

세 가지 유형 구분하기

세 유형은 대응이 다릅니다. 해석 실패는 대개 로컬 DNS 서비스를 쓸 수 없는 상태이고, 해석 이상은 해석 경로에 간섭이 있는 경우가 많습니다. DNS 유출은 설정 문제이므로 해석 요청을 터널 안으로 되돌려야 합니다.

IP 확인 페이지로 하는 세 가지 자가 점검

• 외부 IP의 지역이 선택한 회선의 지역과 일치하는지
• DNS 유출 경고가 뜨는지
• 클라이언트를 끊기 전과 후에 각각 확인해 두 결과가 다른지 비교

확인은 내 IP 페이지에서 할 수 있으며, 별도 도구 설치나 명령줄 지식이 필요하지 않습니다. 세 가지 결과를 기록해 두었다가 문의에 함께 첨부하면 됩니다.

클라이언트의 DNS 설정

회선에 내장된 DNS 해석을 우선 사용해 해석 요청이 터널을 따라 나가게 하세요. DNS를 공용 주소로 직접 바꾸면 해석 요청이 터널을 우회해 로컬 통신사로 돌아갈 수 있고, 해석 결과에 영향을 줄 뿐 아니라 해석 기록이 터널 밖에 노출됩니다. 분명한 이유가 없다면 클라이언트가 내려주는 DNS 설정을 직접 바꾸지 마세요.

브라우저 내장 암호화 DNS

일부 브라우저에는 암호화 DNS(DoH)가 내장돼 있어, 켜면 시스템과 클라이언트의 DNS 설정을 우회합니다. 브라우저에서만 해석 이상이 나타난다면 이 옵션을 먼저 끄거나 「시스템 설정 따르기」로 바꾼 뒤 다시 확인하세요. 자주 놓치는 항목이지만 「다른 앱은 다 정상인데 브라우저만 안 열린다」는 현상을 설명해 줍니다.

명령줄 점검

# 시스템 기본 DNS로 해석
nslookup www.example.com

# 지정한 DNS로 해석해 두 결과가 일치하는지 비교
nslookup www.example.com 1.1.1.1

# Windows: 로컬 DNS 캐시 비우기
ipconfig /flushdns

# macOS: 로컬 DNS 캐시 비우기
sudo dscacheutil -flushcache

두 해석 결과가 다르면 해석 경로에 간섭이 있다는 뜻입니다. 캐시를 먼저 비우고 클라이언트의 DNS 설정을 기본값으로 되돌린 뒤 다시 연결하세요. 캐시를 비운 뒤 첫 해석은 보통 조금 느린데 이는 정상입니다.

DNS는 정상인데 페이지가 여전히 안 열릴 때

해석도 정상이고 외부 IP도 맞는데 페이지가 열리지 않는다면 문제는 DNS가 아닙니다. 3장으로 돌아가 「상황별 판단」에 따라 점검을 이어가고, 분할 규칙과 브라우저 확장 프로그램 두 가지를 중점적으로 보세요.

기기 수, 계정 공유와 문의 접수

이 장은 계정 관련 문제와, 앞의 여덟 장을 모두 점검한 뒤에 무엇을 해야 하는지를 다룹니다. 계정 문제의 특징은 로컬에서 아무리 고쳐도 나아지지 않고 계정 쪽에서 확인해야만 원인을 찾을 수 있다는 점입니다.

기기 수 제한 없음이 뜻하는 것

VPNPF 요금제는 기기 수 제한이 없습니다. 같은 계정으로 Windows, macOS, iOS, Android, Linux에서 동시에 사용할 수 있고, 기기마다 따로 구매할 필요도, 기기 수를 세면서 쓸 필요도 없습니다. 새 기기로 바꿀 때는 새 기기에 구독을 그대로 가져오면 됩니다.

많은 서비스가 기기 수로 과금하며, 초과하면 「기기 수 초과」를 알리고 요금제 업그레이드를 요구합니다. 본 서비스 요금제에는 이런 제한이 없으므로 자기 기기 사이를 오갈 때 기기 수를 걱정할 필요가 없습니다. 로그인 후 접속이 밀려나는 경우가 있다면 기기 수 제한보다는 계정 공유 때문일 가능성이 큽니다.

계정 공유가 부르는 결과

구독 주소는 계정에 묶여 있어 계정 자격 증명과 같습니다. 구독 주소를 공유하는 것은 계정을 남에게 넘겨주는 것과 같습니다. 여러 사람이 한 계정을 함께 쓰면 세 가지 결과가 따라옵니다. 동시 연결 수가 대량으로 점유돼 정작 본인이 쓸 때 느려지고, 로그인 상태가 서로 밀어내 재로그인을 자주 요구하며, 비정상 로그인 기록이 생겨도 출처를 판단할 수 없습니다.

가족이나 동료에게도 써야 한다면 같은 구독 주소를 함께 쓰기보다 계정을 따로 만드는 편이 좋습니다. 가입에는 이메일 주소가 필요 없고 아이디 + 비밀번호만으로 끝나므로, 가족용 계정을 하나 더 만드는 부담은 거의 없습니다.

이런 경우에는 반드시 문의를 접수하세요

• 계정에 로그인할 수 없고 재설정 절차도 진행되지 않음
• 구독 가져오기가 실패하고 기기와 네트워크를 바꿔도 계속 실패
• 주문이나 결제 상태가 실제와 다름
• 환불이 필요함(60일 무조건 환불)
• 이 가이드의 앞 여덟 장을 모두 점검했는데도 문제가 남아 있음

문의에 첨부할 정보

정보가 충분하면 보통 한 번에 원인을 찾습니다. 부족하면 주고받는 데만 반나절이 걸립니다. 아래 목록대로 정리해 문의에 그대로 붙여 넣으면 됩니다.

1. 계정 정보

   가입할 때 사용한 아이디. 비밀번호는 적지 마세요. 문의에는 비밀번호가 필요 없고, 누구도 비밀번호를 요구하지 않습니다.

2. 문제가 발생한 시각

   분 단위로 적고 시간대를 함께 표기하세요. 시각 정보는 회선 조정인지 로컬 네트워크 변동인지 판단하는 데 도움이 됩니다.

3. 회선 이름과 지역

   문제가 생겼을 때 사용한 회선 이름과 지역, 다른 회선으로 바꿔 봤는지와 그 결과

4. 클라이언트와 시스템

   사용한 플랫폼(Windows / macOS / iOS / Android / Linux)과 OS 버전, 클라이언트 버전 정보

5. 오류 메시지 원문 또는 스크린샷

   클라이언트의 오류 문구를 그대로 복사하거나 전체 오류 정보가 담긴 스크린샷을 첨부하세요. 「안 열린다」는 설명만으로는 부족합니다.

6. 이미 진행한 점검

   예: 「회선 3개, 기기 2대, 네트워크 2개로 바꿔 봤지만 증상이 동일함」. 이 항목이 있으면 확인을 주고받는 한 차례를 줄일 수 있습니다.

접수 후

문의는 사용자 패널 안에서 접수하며, 로그인 후 바로 넣고 진행 상황도 볼 수 있습니다. 접수 전에 이 가이드에서 해당 증상 장을 먼저 찾아보세요. 대부분의 문제는 자가 점검 단계에서 해결됩니다. 결제 수단은 알리페이, 위챗, USDT를 지원하며, 주문 관련 문의에는 결제 시각과 금액만 적으면 됩니다. 결제 내역 스크린샷 외에 민감한 정보를 제공할 필요는 없습니다.