문제 해결 가이드: 증상별 단계적 진단

점검 프레임: 먼저 장애 계층 파악

장애 대응에서 가장 시간을 잡아먹는 부분은 복구가 아니라 방향을 잘못 잡는 일입니다. 똑같이 '연결이 안 된다'는 증상도 계정 상태, 로컬 네트워크, 클라이언트 설정, 대상 서비스 자체에서 비롯될 수 있고, 이 네 지점은 위치도 처리 방식도 전혀 다릅니다. 무작정 회선을 바꿔가며 시도하면 같은 오류를 몇 번씩 되풀이할 뿐 아니라 진짜 단서를 덮어 버리기 쉽습니다.

이 장에서는 먼저 계층형 프레임과 정보 수집 체크리스트를 제시합니다. 이어지는 여덟 장은 구체적인 증상별로 펼쳐지며, 각 장은 따로 읽어도 되지만 먼저 이 장의 분류 절차를 3분 정도 따라 하며 문제가 어느 계층에 속하는지 확인한 뒤 해당 장으로 이동하시길 권합니다. 서비스를 처음 접하는 분은 시작 가이드에서 가입, 요금제 선택, 구독 가져오기까지의 흐름을 먼저 마치고 여기로 돌아오셔도 됩니다.

네 계층이 각각 맡는 역할

계정 계층. 계정 계층은 '연결할 자격이 있는가'를 봅니다. 구독이 유효 기간 안에 있는지, 이번 달 트래픽을 다 썼는지, 요금제가 만료되지 않았는지 — 이 세 가지가 클라이언트가 서버에서 유효한 회선 설정을 받을 수 있는지를 결정합니다. VPNWing의 월 구독은 세 가지입니다: ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며 트래픽은 개통일 기준으로 매월 초기화됩니다. 별도로 트래픽 팩 ¥158/300GB, ¥358/1000GB, ¥658/3000GB는 다 쓸 때까지 유효하고 영구히 만료되지 않습니다. 이번 달 한도를 다 쓴 경우 클라이언트는 보통 연결은 되지만 곧 끊기거나, 구독이 만료되었다는 안내를 바로 띄웁니다. 사용 중 요금제를 업그레이드하면 차액이 남은 일수로 환산되며 주기를 다시 계산할 필요가 없습니다.

네트워크 계층. 네트워크 계층은 '로컬에서 밖으로 나갈 수 있는가'를 봅니다. Wi-Fi 신호 품질, 공유기 상태, 사용 중인 네트워크가 특정 포트를 제한하는지, DNS가 정상적으로 조회되는지가 여기에 포함됩니다. 판단 방법은 단순합니다. 클라이언트를 완전히 종료하고 기기 자체 네트워크로 평소 쓰는 국내 사이트 몇 곳에 접속해 보세요. 이 단계에서 막히면 문제는 VPNWing과 무관합니다.

클라이언트 계층. 클라이언트 계층은 '설정이 맞는가'를 봅니다. 클라이언트 버전, 구독이 제대로 가져와졌는지, 분할 라우팅 규칙이 대상 도메인을 직접 연결로 판정했는지, 시스템 프록시나 가상 네트워크 어댑터를 다른 프로그램이 점유하고 있는지가 해당됩니다. 이 계층의 문제는 회선 장애로 오해되기 쉽습니다. 증상이 똑같이 '연결은 되는데 안 열린다'이기 때문입니다.

대상 서비스 계층. 대상 서비스 계층은 '상대가 정상인가'를 봅니다. 어떤 사이트는 데이터센터 IP 대역을 제한하고, 어떤 서비스는 특정 시간대에 점검을 진행하며, 또 어떤 지역 제한은 회선과 무관하게 나가는 IP의 소속 지역만 봅니다. 판단 방법은 다른 지역의 회선으로 바꿔 같은 사이트를 다시 시도하는 것입니다. 모든 회선에서 실패한다면 대상 쪽 문제일 가능성이 큽니다.

3분 분류: 순서대로 한 번씩

1. 사용자 패널을 열어 구독 상태, 남은 트래픽, 만료 시각을 확인합니다. 이 단계에서 계정 계층을 배제합니다.
2. 클라이언트를 완전히 종료하고 기기 자체 네트워크로 평소 쓰는 사이트 두 곳에 접속해 로컬 네트워크 자체가 쓸 만한지 확인합니다. 이 단계에서 네트워크 계층의 기본 연결성을 배제합니다.
3. 클라이언트를 다시 열고 현재와 다른 회선으로 바꿉니다. 가능하면 지역과 회선 유형을 함께 바꿔 보세요. 예를 들어 직접 연결에서 IEPL 전용선으로 옮기는 식입니다. 이 단계에서 단일 회선 문제인지 전반적인 문제인지 가릅니다.
4. 브라우저에서 앞서 정상임을 확인한 사이트에 먼저 접속하고, 이어서 이전에 실패한 대상 사이트에 접속합니다. 두 단계를 비교하면 '전체가 안 되는 것'과 '특정 사이트만 안 되는 것'을 구분할 수 있습니다.
5. 위 항목이 모두 정상인데 대상 사이트만 여전히 실패한다면, 실패할 때 표시된 구체적인 안내 문구를 기록해 두고 해당 장에서 심층 점검을 진행하세요.

이 다섯 단계를 거치면 대부분의 문제는 어느 장에서 다뤄야 할지 정해집니다. 남은 시간은 반복 시행착오가 아니라 세부 확인에 쓰시면 됩니다.

동시 접속 대수에 대한 흔한 오해

VPNWing은 동시 접속 대수를 제한하지 않으며, 하나의 계정으로 Windows, macOS, iOS, Android, Linux에서 함께 사용할 수 있습니다. 기기마다 따로 개통할 필요가 없습니다. 따라서 '연결 수'나 '기기 수' 관련 안내를 보게 된다면 보통은 계정 한도가 아니라 로컬 환경의 연결 테이블이 가득 찬 경우입니다.

흔한 원인은 두 가지입니다. 첫째, 가정용 공유기의 NAT 세션 테이블 용량이 한정되어 있어 같은 네트워크에서 대용량 다운로드, 동영상, 게임 연결이 동시에 몰리면 새 연결이 실패합니다. 증상이 '기기 수 초과'와 매우 비슷합니다. 둘째, 운영체제 자체의 파일 디스크립터나 포트 점유가 한계에 도달한 경우입니다. 두 경우의 공통 특징은 일부 기기의 연결을 끊거나 대용량 작업을 잠시 멈추면 곧바로 회복된다는 점입니다. 이 특징에 해당한다면 공유기를 재부팅하고 동시 연결 수를 줄이는 쪽이 해법이며, 요금제를 바꿀 일은 아닙니다.

문의 접수 전에 준비할 정보

문의에 정보가 완비될수록 확인이 빠릅니다. 아래 항목은 한 번에 첨부하시길 권합니다:

• 가입할 때 사용한 사용자 이름. 비밀번호는 제공하지 않아도 됩니다.
• 문제가 발생한 플랫폼과 OS 버전. 예: Windows 클라이언트, macOS 클라이언트, iOS 클라이언트, Android 클라이언트, Linux 클라이언트.
• 클라이언트에 표시된 회선 이름과 회선 유형. 예: 도쿄 · IEPL 전용선, 홍콩 · 중계.
• 장애가 시작된 시점, 그리고 계속 이어지는지 간헐적인지.
• 재현 절차: 클라이언트를 켜는 순간부터 문제가 나타날 때까지의 동작 순서.
• 오류 안내 원문 또는 스크린샷. '연결이 안 됩니다'라고만 적지 마세요.
• 이미 진행한 자가 점검 항목. 예: 어떤 회선으로 바꿔 봤는지, 어떤 네트워크 환경에서 시도했는지, 클라이언트를 재설치했는지.

바로 문의를 접수해야 하는 상황

세 가지 상황에서는 자가 점검을 이어가기보다 문의를 바로 접수하는 편이 효율적입니다. 첫째, 같은 계정의 모든 기기와 모든 회선이 같은 시간대에 전부 실패하는 경우. 둘째, 클라이언트가 시작하거나 구독을 가져오는 단계에서 오류와 함께 종료되어 메인 화면으로 들어가지 못하는 경우. 셋째, 해당 장의 절차를 끝까지 따라 했는데도 문제가 안정적으로 재현되는 경우입니다.

문의는 사용자 패널 안에서 접수할 수 있고, 접수 후 같은 페이지에서 답변을 확인할 수 있습니다. 요금이나 환불과 관련된 문제라면 VPNWing은 30일 이유 불문 환불을 제공하므로 문의에 주문 정보를 적으면 되고, 별도 자료를 더 준비할 필요는 없습니다.

완전 연결 불가: 세 구간을 나눠 판단

'완전 연결 불가'는 클라이언트가 연결을 맺지 못하는 상태를 말합니다. 버튼이 계속 돌기만 하거나, 진행률이 특정 퍼센트에서 멈추거나, 연결됨이 표시되자마자 곧바로 미연결로 돌아가는 경우입니다. 이 세 가지는 원인이 크게 다르므로 먼저 어느 쪽인지 가르면 시행착오를 절반 이상 줄일 수 있습니다.

세 가지 '연결 불가'의 차이

첫째는 핸드셰이크 이전 실패입니다. 연결을 누르면 곧바로 오류가 뜨고, 로딩이 도는 시간조차 매우 짧습니다. 보통 클라이언트가 회선 진입점과 세션을 아예 맺지 못했다는 뜻이며, 원인은 로컬 네트워크나 진입점 도달성에 있습니다.

둘째는 핸드셰이크 도중 실패입니다. 수 초에서 수십 초 동안 돌다가 실패합니다. 네트워크 경로 자체는 뚫려 있고, 인증·설정 전달·암호화 협상 단계에서 막힌 상태입니다.

셋째는 핸드셰이크 직후 끊김입니다. 잠깐 연결됨이 표시되었다가 몇 초 안에 다시 미연결로 돌아갑니다. 이런 문제는 설정 완결성, 시스템 프록시 충돌, 보안 소프트웨어의 차단과 관련된 경우가 많습니다.

핸드셰이크 이전: 먼저 로컬 환경 확인

첫 단계는 언제나 직접 연결 대조입니다. 트레이로 최소화하는 것이 아니라 클라이언트를 완전히 종료한 상태에서, 기기 자체 네트워크로 평소 쓰는 사이트 두 곳에 접속해 보세요. 이 단계에서 열리지 않는다면 문제는 VPNWing이 아니므로 로컬 네트워크를 먼저 손봐야 합니다. 공유기 재부팅, Wi-Fi 대역 전환, 또는 셀룰러 네트워크로 바꿔 비교해 보세요.

두 번째로 시스템 시간을 확인합니다. 암호화 핸드셰이크는 인증서 유효 기간 검증에 의존합니다. 오랜 절전 후 깨어난 기기나 시간대를 수동으로 바꾼 기기에서 흔히 발생하는데, 시스템 시간이 크게 어긋나면 핸드셰이크가 첫 단계에서 실패하고 오류 안내도 대개 매우 모호합니다. 각 플랫폼의 자동 시간 동기화 스위치는 시스템 설정에 있으니 켠 뒤 클라이언트를 다시 시작해 보세요.

세 번째로 보안 소프트웨어를 확인합니다. 일부 백신과 방화벽은 클라이언트가 만드는 가상 네트워크 어댑터를 비정상 네트워크 인터페이스로 판정해 차단합니다. 이때 클라이언트는 연결됨으로 표시되지만 시스템에는 새 네트워크 인터페이스가 나타나지 않습니다. 클라이언트를 화이트리스트에 추가하거나 보호 기능을 잠시 끄고 대조 테스트를 해 보세요. 테스트가 끝나면 반드시 원래대로 되돌리세요.

네 번째로 다른 프록시 프로그램이 함께 실행 중인지 확인합니다. 두 클라이언트가 동시에 시스템 프록시를 점유하거나 가상 네트워크 어댑터를 만들면 설정을 서로 덮어써서 결국 양쪽 다 연결되지 않습니다. 한 번에 하나만 남기세요.

핸드셰이크 도중: 인증과 구독

네트워크 경로가 정상임을 확인했다면 다음은 구독입니다. 사용자 패널에서 세 가지를 확인하세요. 구독이 유효 기간 안에 있는지, 이번 달 트래픽이 남아 있는지, 요금제가 만료되지 않았는지. 이 가운데 하나라도 충족되지 않으면 클라이언트는 인증 단계에서 거부됩니다.

구독 가져오기 실패도 '연결 불가'로 나타납니다. 판단 방법은 클라이언트에서 구독 갱신을 한 번 수동으로 실행해 성공 안내가 뜨는지 보는 것입니다. 갱신이 실패한다면 뒤의 구독 갱신 장으로 바로 넘어가세요. 전체 점검 경로가 정리되어 있습니다.

클라이언트 버전과 구독 형식이 맞지 않는 경우도 있습니다. 구독 내용은 클라이언트 유형에 따라 다른 형식으로 내려가므로, 설정을 직접 붙여 넣은 적이 있다면 형식이 어긋나 파싱이 실패할 수 있습니다. 이때는 현재 설정을 비우고 패널에서 구독을 새로 받아 오세요. 기존 설정 위에 덧붙이지 마세요.

핸드셰이크 이후: 연결되자마자 끊김

잠깐 연결된 뒤 곧바로 끊기는 경우 흔한 원인은 세 가지입니다.

첫째, 분할 라우팅 규칙이 로컬 네트워크와 충돌하는 경우입니다. 예를 들어 규칙이 클라이언트 자체의 업데이트 도메인을 프록시로 보내는데 그 도메인이 프록시 쪽에서 도달 불가능하면, 클라이언트가 시작 시 자체 점검에 실패합니다. 클라이언트 업데이트 도메인을 직접 연결 규칙에 넣거나, 잠시 전역 모드로 바꿔 대조해 보세요.

둘째, MTU 불일치입니다. 캡슐화된 패킷이 경로 MTU를 넘는데 제대로 분할되지 않으면 큰 패킷이 버려지고, 결과적으로 연결은 되지만 몇 초 안에 끊깁니다. 일부 이동통신망과 전화 접속 환경에서 더 흔하며, 뒤의 '연결은 되는데 페이지가 안 열림' 장에 자세한 판단 방법이 있습니다.

셋째, 계정이 다른 곳에서 중복 로그인된 경우입니다. VPNWing은 동시 접속 대수를 제한하지 않지만, 같은 계정이 짧은 시간에 많은 기기에서 반복 로그인하면 서버가 보호 목적의 속도 제한을 걸 수 있습니다. 다른 기기에서 재연결을 반복하고 있지 않은지 확인하세요.

증상 대조표

그래도 연결되지 않을 때

지역과 유형이 다른 회선을 최소 두 개(직접 연결 하나, IEPL 전용선 하나) 바꿔 보고, 네트워크 환경도 최소 한 번 바꿔 봤는데 문제가 안정적으로 재현된다면 문의를 접수해야 합니다. 문의에 클라이언트가 표시한 전체 오류 문구, 장애 시작 시각, 이미 시도한 회선 이름을 함께 적으면 처리 시간이 눈에 띄게 줄어듭니다.

특정 회선이 특정 시간대에만 사용할 수 없다면 다른 회선으로 바꿔 계속 쓰시고, 문의에 해당 회선 이름과 시간대를 적어 두세요. 표적 점검에 도움이 됩니다.

연결은 되는데 페이지가 안 열림: 분할 라우팅, DNS, MTU

클라이언트는 연결됨이고 상태 표시도 정상인데 브라우저가 계속 돌기만 하거나, 일부 사이트만 열리지 않는 경우입니다. 점검 항목 가운데 가장 흔하면서도 가장 오해하기 쉬운 유형입니다. 원인은 거의 '회선 고장'이 아니라 '트래픽이 올바른 길로 가지 않는 것'입니다.

먼저 두 가지 범위를 구분

첫째는 전부 안 됨입니다. 연결 후 어떤 사이트도 열리지 않습니다. 이전에 정상적으로 접속되던 사이트도 마찬가지입니다. 이런 문제는 보통 시스템 프록시 설정, 가상 네트워크 어댑터가 트래픽을 제대로 잡지 못함, 또는 DNS가 완전히 먹통인 경우에 발생합니다.

둘째는 일부만 안 됨입니다. 어떤 사이트는 정상이고 다른 사이트는 열리지 않거나, 같은 사이트라도 첫 화면은 열리는데 상세 페이지로 들어가면 실패합니다. 이런 문제는 보통 분할 라우팅 규칙, DNS 조회 결과, MTU에서 비롯됩니다.

판단 방법은 간단합니다. 연결 후 사이트 세 곳을 차례로 방문하세요. 국내 사이트 하나, 평소 쓰는 해외 사이트 하나, 앞서 실패했던 대상 사이트 하나입니다. 세 결과의 조합만으로도 방향이 거의 잡힙니다.

방향 1: 분할 라우팅 규칙

분할 라우팅 규칙은 어떤 트래픽이 프록시로 가고 어떤 트래픽이 직접 연결로 갈지를 정합니다. 규칙에 문제가 생기면 전형적인 증상이 두 가지로 나타납니다.

첫째, 프록시로 가야 할 트래픽이 직접 연결로 가는 경우입니다. 대상 도메인이 규칙에서 직접 연결로 판정되면 요청이 로컬 네트워크에서 그대로 나가므로 당연히 열리지 않습니다. 규칙 라이브러리 갱신이 늦었거나 대상 사이트가 도메인을 바꿨을 때 생깁니다. 클라이언트의 규칙 목록에서 대상 도메인을 검색해 어느 규칙에 걸리는지 확인하세요. 실제로 직접 연결로 판정된다면 프록시 규칙을 하나 추가하거나, 잠시 전역 모드로 바꿔 검증하면 됩니다.

둘째, 직접 연결로 가야 할 트래픽이 프록시로 가는 경우입니다. 국내 사이트가 프록시 통로로 들어가 오히려 느려지거나 실패합니다. 연결성에는 영향이 없지만 트래픽을 낭비하고, 회선이 느리다는 오해를 부르기 쉽습니다.

판단 요령: 전역 모드로 바꿔 다시 시도해 보세요. 전역 모드에서 대상 사이트가 열린다면 문제는 분할 라우팅 규칙에 있습니다. 전역 모드에서도 열리지 않는다면 DNS와 MTU를 계속 확인하세요.

방향 2: DNS 조회

DNS 문제의 전형적인 증상은 주소로는 핑이 통하는데 도메인으로는 열리지 않는 것입니다. 도메인 조회가 잘못된 결과를 돌려주거나, 조회 요청에 아예 응답이 없는 경우입니다.

판단 방법은 명령줄에서 같은 도메인을 한 번 조회해 보고 반환된 주소가 타당한지 보는 것입니다. 조회 결과가 명백히 이상하거나 조회가 시간 초과된다면 DNS 단계로 확인해도 됩니다.

처리 방법은 침습성이 낮은 순서로 세 가지입니다:

1. 클라이언트에서 DNS 모드를 바꿉니다. 대부분의 클라이언트가 시스템 따르기, 내장 DNS 사용, 업스트림 지정 같은 옵션을 제공하며, 내장 DNS로 바꾸면 통신사 조회 문제를 피해가는 경우가 많습니다.
2. 사용 가능한 업스트림 DNS를 직접 지정합니다. 설정 후에는 시스템 DNS 캐시를 한 번 비워야 합니다. 그렇지 않으면 이전 조회 결과가 계속 쓰입니다.
3. 특정 도메인만 조회가 이상하다면 클라이언트에서 그 도메인만 조회 방식을 따로 지정하거나, 주소로 직접 접속해 대조해 보세요. 이 방법은 검증용이며 평소에는 도메인을 쓰시길 권합니다.

방향 3: MTU와 단편화

MTU 문제는 증상이 꽤 뚜렷합니다. 작은 페이지는 열리는데 큰 페이지는 로딩 중간에 멈추고, 이미지가 일부만 보이거나, 동영상이 첫 프레임에서 멈추거나, 로그인 페이지가 제출 후 계속 돌기만 합니다. 캡슐화된 패킷이 경로가 허용하는 최대 길이를 넘었는데 경로상의 장비가 분할에 필요한 제어 메시지를 제대로 돌려주지 않아 큰 패킷이 조용히 버려지는 것입니다.

판단 방법은 분할을 허용하지 않는 탐침 패킷으로 테스트하는 것입니다. Windows에서는 ping의 -f와 -l 조합을, macOS와 Linux에서는 ping의 -D와 -s 조합을 사용해 패킷 길이를 조금씩 늘려 가며, 분할 없이도 응답이 오는 최대값을 찾습니다. 여기에 헤더 길이를 더하면 사용 가능한 MTU가 됩니다.

처리 방법은 클라이언트나 시스템 네트워크 설정에서 MTU를 낮추는 것입니다. 흔히 1400 근처의 값을 쓰지만, 구체적인 값은 위 탐침 결과로 정해야 하며 남의 숫자를 그대로 베끼지 마세요. 조정 후에는 연결을 끊었다 다시 맺어 설정을 적용하세요.

명령줄로 범위 좁히기

아래 명령은 연결성 확인용이며 계정 정보와는 무관합니다:

# 도메인 조회 결과 확인
nslookup example.com

# 대상 도달 가능 여부 확인(연결성 검증 전용)
ping -c 4 example.com

# HTTP 응답 헤더 확인, 네트워크 문제인지 사이트 문제인지 판별
curl -I https://example.com

Windows에서는 ping -c 4를 ping -n 4로 바꾸세요. nslookup이 이상한 주소를 반환하면 DNS 문제이고, 조회는 정상인데 ping이 모두 시간 초과되면 라우팅이나 분할 라우팅 문제이며, ping은 정상인데 curl -I가 시간 초과되면 MTU나 대상 사이트 쪽 문제일 가능성이 큽니다.

처리 순서

분할 라우팅 규칙, DNS, MTU 순서로 점검하시길 권합니다. 세 가지의 판단 비용이 차례로 올라가기 때문입니다. 분할 라우팅은 전역 모드로 한 번 바꿔 보면 되고, DNS는 명령 한 줄이면 되며, MTU는 여러 번의 탐침이 필요합니다. 이 순서를 따르면 대부분의 문제는 앞의 두 단계에서 해결됩니다.

세 단계가 모두 정상인데도 대상 사이트가 열리지 않는다면 다른 지역의 회선으로 바꿔 다시 시도하세요. 회선을 바꾼 뒤 회복된다면 원래 회선에서 해당 사이트로 가는 경로 문제이므로 기록해 두고 문의하면 됩니다. 회선을 바꿔도 그대로인데 로컬 네트워크에서 그 사이트는 정상이라면, 대상 쪽에서 해당 지역의 나가는 IP를 제한했을 가능성이 큽니다.

속도 저하: 대역폭 부족인지 경로가 돌아가는지 구분

'느리다'는 가장 모호한 피드백입니다. 같은 '느리다'도 로컬 대역폭 부족, 회선 경로가 돌아가는 문제, 대상 사이트의 속도 제한, 기기 자체가 백그라운드에서 다른 작업을 돌리는 경우까지 원인이 다양합니다. 먼저 병목을 특정 구간으로 좁힌 다음 최적화를 논하세요.

먼저 병목 구간 확인

완전한 접속 경로는 네 구간으로 나눌 수 있습니다. 기기에서 공유기까지, 공유기에서 통신사까지, 통신사에서 회선 진입점까지, 회선 출구에서 대상 사이트까지입니다. 네 구간 중 어디든 혼잡하면 최종 증상은 '느림'으로 같지만 처리 방식은 전혀 다릅니다.

기본 원칙 하나: 프록시를 거친 속도는 로컬 회선 대역폭을 넘을 수 없습니다. 가정용 회선의 업로드가 원래 작다면 어떤 회선으로 바꿔도 업로드 방향이 빨라지지 않습니다. 마찬가지로 집 안의 다른 기기가 시스템 업데이트나 클라우드 동기화를 돌리고 있으면 가용 대역폭이 먼저 잠식됩니다.

구간별 측정 방법

첫 단계, 클라이언트를 끄고 로컬 네트워크에서 국내 사이트까지의 속도를 한 번 측정해 기록합니다. 이것이 기준값입니다.

둘째, 클라이언트를 켜고 같은 지역 사이트까지의 속도를 측정합니다. 이 단계에서 눈에 띄게 떨어진다면 문제는 기기와 공유기 사이 구간이므로 Wi-Fi 신호 세기, 대역(2.4GHz와 5GHz는 실제 처리량 차이가 큽니다), 동일 채널 간섭 여부를 확인하세요.

셋째, 클라이언트를 켠 상태로 대상 지역 사이트까지의 속도를 측정합니다. 이 단계가 국제 구간 링크 품질을 보여줍니다.

세 결과를 함께 보세요. 첫 단계부터 느리면 로컬 문제, 첫 단계는 정상인데 둘째가 크게 떨어지면 클라이언트나 공유기 문제, 앞의 두 단계가 정상인데 셋째가 느리면 그때가 국제 회선 문제입니다.

강조하자면, 한 번의 속도 측정 결과는 변동이 큽니다. 측정 서버 부하, 시간대, 브라우저 캐시의 영향을 받습니다. 판단할 때는 세 번 이상 연속 측정해 단일 최고값이 아니라 중앙값을 보세요.

회선 선택: 지리적 근접성이 최적 경로는 아니다

많은 분이 '가까울수록 빠르다'고 생각하지만 실제로는 늘 그렇지 않습니다. 국제 구간 링크 품질은 직선거리보다 라우팅 홉 수, 경유하는 백본, 독립 통로 사용 여부에 달려 있습니다. 세 가지 회선 유형의 차이는 이렇게 이해하면 됩니다:

회선 유형 설명: IEPL 전용선은 독립 통로를 쓰고, 중계는 백본 노드를 경유하며, 직접 연결은 로컬 회선에서 바로 나갑니다. 전체 지역과 유형 목록은 회선 목록 페이지에서 확인할 수 있습니다.

어떤 회선이 낮에는 좋다가 저녁에 눈에 띄게 느려진다면 공용 링크가 피크 시간대에 혼잡한 것일 가능성이 크며, IEPL 전용선으로 바꾸면 보통 개선됩니다. 어떤 회선이 시간대와 무관하게 늘 느리다면 경로가 돌아가는 문제일 가능성이 크므로 유형을 바꾸는 것보다 지역을 바꾸는 편이 효과적입니다. 회선을 고르는 일반적인 방법은 지역·회선 유형·용도별 회선 선택 글을 참고하세요.

클라이언트 설정의 영향

놓치기 쉬운 설정 항목:

• 프로토콜과 암호화 스위트. 암호화 강도가 높을수록 연산 부담이 커집니다. 구형 모바일 기기나 보급형 공유기처럼 저전력 기기에서는 이 부담이 병목이 될 수 있습니다. 기기 성능이 제한적이라면 부담이 낮은 조합을 고르세요.
• 멀티플렉싱. 켜면 여러 연결이 하나의 터널을 공유해 핸드셰이크 횟수를 줄일 수 있지만, 패킷 손실률이 높은 링크에서는 막힘이 커질 수 있습니다. 켜고 끄며 비교해 보세요.
• 분할 라우팅 규칙의 복잡도. 규칙 항목이 매우 많으면 요청마다 매칭을 한 번씩 해야 해서 저성능 기기에서는 체감되는 지연이 생깁니다. 규칙을 간소화하거나 도메인 접미사 매칭으로 바꾸면 완화됩니다.
• 백그라운드 작업. 시스템 업데이트, 클라우드 동기화, 사진 백업은 백그라운드에서 대역폭을 차지하며 대개 야간에 자동으로 시작됩니다. 속도 문제를 볼 때는 이 작업들의 상태를 먼저 확인하세요.

요금제 한도 문제일 때

속도 저하와 함께 연결이 불안정하다면 사용자 패널을 열어 이번 달 트래픽을 먼저 확인하세요. VPNWing의 월 구독 세 가지는 각각 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며 트래픽은 개통일 기준으로 매월 초기화됩니다. 이번 달 한도가 거의 소진되면 일부 클라이언트가 안내를 표시합니다.

특정 달에만 사용량이 많다면 트래픽 팩으로 보충할 수 있습니다: ¥158/300GB, ¥358/1000GB, ¥658/3000GB. 다 쓸 때까지 유효하며 영구히 만료되지 않습니다. 트래픽 팩과 월 구독 한도는 별도로 계산되어 서로 충돌하지 않습니다. 장기적으로 사용량이 현재 단계를 넘는다면 월 구독을 업그레이드하는 편이 유리하며, 차액은 남은 일수로 환산됩니다. 세 단계의 전체 비교는 요금제와 가격 페이지에서 볼 수 있습니다.

한 번의 속도 측정으로 결론 내지 말 것

속도 측정 결과는 영향을 주는 변수가 너무 많아 한 번의 숫자로는 판단 근거가 되지 못합니다. 어떤 회선이 자신에게 맞는지 판단하는 더 실용적인 방법은, 자신이 주로 쓰는 시간대에 자주 방문하는 사이트로 며칠 연속 관찰하는 것입니다. 대부분의 시간대에 안정적이라면 한 번 측정값이 낮게 나왔다고 회선을 바꿀 필요는 없습니다.

위 방법으로 구간별 측정을 마쳤는데 병목이 국제 회선에 있고, 지역이 다른 회선을 최소 두 개 바꿔도 개선이 없다면 세 번의 측정 시각, 회선 이름, 결과를 함께 문의에 접수하세요.

야간 피크 렉: 혼잡 원인과 회선 전환

낮에는 연결이 모두 정상인데 저녁 7시에서 11시 사이에 렉이 생기고, 동영상이 자주 버퍼링하며, 회의 음성이 끊긴다면 기기 고장일 가능성은 낮습니다. 국제 구간 링크의 공용 자원이 피크 시간대에 가득 찬 것입니다.

왜 하필 저녁일까

국제 접속 경로에는 공유되는 구간이 있습니다. 평일 저녁은 가정 네트워크 사용이 가장 몰리는 시간대로, 동영상·게임·다운로드·화상회의가 한꺼번에 몰려 국제 출구 대역폭이 크게 점유됩니다. 동시에 대상 쪽 서버도 자체 피크 시간대라 응답 속도가 함께 떨어집니다.

이는 두 가지를 뜻합니다. 첫째, 야간 피크의 렉은 양쪽이 겹친 결과인 경우가 많아 전적으로 회선 문제는 아닙니다. 둘째, 같은 유형의 회선으로 바꾸기만 하면 개선 폭이 제한적일 수 있습니다. 새 회선도 같은 혼잡 링크를 지나기 때문입니다.

세 회선 유형의 피크 시간대 차이

회선 유형마다 혼잡에 대한 민감도가 다릅니다:

• IEPL 전용선은 독립 통로를 써서 공용 인터넷 혼잡 구간을 거치지 않으므로 피크 시간대 영향이 가장 작습니다. 대신 단위 비용이 높아 주로 안정성이 중요한 용도에 쓰입니다.
• 중계는 백본 노드를 경유해 앞 구간은 최적화된 경로를 쓰고 뒤 구간은 여전히 공용 링크를 공유합니다. 피크 시간대 성능은 전용선과 직접 연결 사이입니다.
• 직접 연결은 로컬 회선에서 곧바로 나가므로 전적으로 공용 링크에 의존하며, 피크 시간대 변동이 가장 큽니다.

VPNWing은 현재 120+ 국가 / 160+ 회선을 제공하며 세 가지 회선 유형을 모두 갖추고 있습니다. 일상 브라우징은 보통 직접 연결로 충분합니다. 야간 피크가 주 사용 시간대라면 IEPL 전용선이나 중계를 우선 고르세요. 전체 회선 목록과 유형 표시는 회선 목록 페이지에서 지역별로 확인할 수 있고, 각 회선에 유형이 표기되어 있습니다.

먼저 집 안 변수부터 배제

문제를 회선 탓으로 돌리기 전에 2분만 투자해 로컬 요인을 배제하세요:

1. 집 안의 다른 기기가 대용량 작업을 하고 있지 않은지. 시스템 업데이트, 클라우드 동기화, TV 박스의 동영상 캐싱은 대역폭을 차지하며 대개 저녁에 자동으로 시작됩니다.
2. Wi-Fi가 이웃의 동일 채널 신호에 간섭받고 있지 않은지. 야간 피크는 이웃도 인터넷을 많이 쓰는 시간대라 2.4GHz 대역 간섭이 뚜렷하게 심해집니다. 5GHz 대역으로 바꾸면 보통 즉시 개선됩니다.
3. 공유기를 오랫동안 재부팅하지 않았는지. 일부 가정용 공유기는 몇 주 연속 켜 두면 세션 테이블이 조각나 새 연결이 느려집니다. 한 번 재부팅해 대조해 보세요.
4. 기기 자체가 성능을 낮추고 있지 않은지. 노트북은 배터리 모드에서 성능이 제한되어 암호화·복호화 부담이 커집니다.

이 네 가지를 배제한 뒤에 회선 문제로 판단해야 정확합니다.

할 수 있는 다섯 가지

첫째, 용도에 맞게 회선을 고르세요. 화상회의와 대용량 파일 전송은 IEPL 전용선을 우선하고, 일상 브라우징과 짧은 동영상은 중계나 직접 연결로 충분합니다. 모든 상황에 같은 회선을 쓸 필요는 없습니다.

둘째, 대용량 작업은 시간대를 피하세요. 시스템 업데이트, 백업, 대용량 다운로드는 낮이나 늦은 밤으로 옮겨 피크 시간대를 피할 수 있습니다.

셋째, 동시 작업을 줄이세요. 같은 계정의 동시 접속 대수는 제한이 없지만, 고대역폭 작업을 여러 개 동시에 돌리면 서로 자리를 뺏습니다. 야간 피크에는 불필요한 백그라운드 동기화를 잠시 멈추세요.

넷째, 불필요한 연산 부담을 끄세요. 성능이 제한된 기기에서는 부담이 낮은 암호화 조합을 고르면 처리 여력을 조금 확보할 수 있습니다.

다섯째, 시간대와 회선을 기록하세요. 특정 회선이 정해진 시간대에 안정적으로 느려진다면 기록해 두세요. 이 기록은 회선 문제인지 전반적인 혼잡인지 판단하는 데 값지고, 문의할 때 가장 유용한 정보이기도 합니다.

속도 보장에 대해

분명히 말씀드리면, VPNWing은 구체적인 속도 수치를 보장하지 않습니다. 국제 구간 링크의 실제 속도는 로컬 대역폭, 대상 사이트, 시간대, 라우팅 등 여러 요인의 영향을 받으며, 어떤 고정된 속도 약속도 실제 상황을 반영하지 못합니다. 확인할 수 있는 것은 회선 유형과 커버리지입니다. 120+ 국가 / 160+ 회선, 세 가지 회선 유형 선택 가능, 동시 접속 대수 제한 없음입니다.

야간 피크의 렉이 일상 사용을 방해할 정도이고 전용선 유형으로 바꿔도 개선이 없다면, 구체적인 시간대와 회선 이름, 사용 상황을 적어 문의를 접수하시길 권합니다. 이런 문제는 회선별로 하나씩 확인해야 하는 경우가 많아, 정보가 구체적일수록 확인이 빠릅니다.

잦은 끊김: 재연결 전략과 네트워크 전환

끊김은 연결 불가보다 더 짜증납니다. 진행 중인 일을 방해하기 때문입니다. 끊김을 볼 때 핵심은 '재연결'이 아니라 끊김의 규칙을 찾는 것입니다. 간격이 일정한지, 특정 동작과 동시에 발생하는지, 특정 네트워크에서만 나타나는지 말입니다. 규칙이 확인되면 원인은 거의 정해집니다.

세 가지 끊김 패턴

첫째, 간격이 일정한 경우. 몇 분 또는 몇십 분마다 거의 같은 간격으로 끊깁니다. 이런 문제는 보통 keep-alive 메커니즘, 하트비트 타임아웃, 서버의 세션 시간 제한과 관련됩니다.

둘째, 무작위로 나타나는 경우. 일정한 간격이 없이 몇 시간 동안 끊기지 않다가 십 분에 세 번 끊기기도 합니다. 이런 문제는 네트워크 환경과 관련된 경우가 많습니다. Wi-Fi 신호 변동, 기지국 간 이동통신 전환, 업스트림 링크의 흔들림 등입니다.

셋째, 유휴 후 끊기는 경우. 쓰는 동안에는 끊기지 않다가 한동안 놔두었다 돌아오면 이미 끊겨 있습니다. 전형적인 NAT 세션 타임아웃으로, 고장이 아니라 예상된 동작입니다.

판단 방법은 간단합니다. 끊긴 시각을 세 번 이상 기록해 간격이 비슷한지 보세요. 세 번이면 패턴을 보기에 충분합니다.

규칙적인 끊김: keep-alive와 타임아웃

간격이 일정하다면 먼저 클라이언트의 keep-alive 설정을 확인하세요. 대부분의 클라이언트가 하트비트 간격이나 keep-alive 스위치를 제공하며, 켜 두면 클라이언트가 주기적으로 작은 패킷을 보내 세션을 유지합니다. keep-alive를 끄면 경로상의 중간 장비가 오랫동안 데이터가 없다는 이유로 세션을 회수해, 일정 간격으로 끊기는 것처럼 보일 수 있습니다.

두 번째 확인 지점은 서버의 세션 시간 제한입니다. 일부 회선은 부하 분산을 위해 단일 연결의 최대 유지 시간을 두고, 시간이 되면 강제로 재연결합니다. 이 경우 끊긴 직후 곧바로 재연결에 성공하고, 다시 같은 시간만큼 안정적으로 쓸 수 있습니다. 이 특징에 해당한다면 고장이 아니므로 세션 정책이 다른 회선으로 바꾸는 것을 고려하세요.

세 번째 확인 지점은 시스템 절전입니다. 노트북 덮개를 닫거나 모바일 기기를 잠그면 시스템이 네트워크 활동을 멈추고, 깨어날 때 터널은 이미 만료되어 있습니다. 시스템 전원 설정에서 절전 중에도 네트워크 장치가 활동하도록 허용하거나, 깨어난 뒤 수동으로 재연결하는 습관을 들이세요.

무작위 끊김: 네트워크 전환과 신호

무작위 끊김은 네트워크 환경을 중심으로 확인합니다.

Wi-Fi 신호 변동. 공유기와 거리가 멀거나 벽이 사이에 있거나 주변에 같은 채널 기기가 많으면 패킷 손실률이 올라갑니다. 손실이 일정 수준을 넘으면 클라이언트가 링크를 사용할 수 없다고 판단해 재연결을 겁니다. 공유기 가까이에서 다시 대조해 보세요. 끊김 빈도가 뚜렷하게 줄면 신호 문제입니다.

이동통신 전환. 이동 중에는 기기가 기지국 사이를 옮겨 다니며, 전환할 때마다 데이터 연결이 잠깐 끊깁니다. 클라이언트가 빠르게 재연결하지 못하면 증상은 끊김으로 나타납니다. 출퇴근 경로에서 특히 두드러지는 네트워크 특성이며, 대응 방향은 클라이언트의 자동 재연결을 켜고 재시도 간격을 줄이는 것입니다.

이중 네트워크 동시 사용. 일부 기기는 Wi-Fi와 셀룰러를 함께 켜 두고 시스템이 둘 사이를 지능적으로 전환합니다. 전환하는 순간 터널이 끊깁니다. 이중 네트워크 가속이 필요 없다면 하나를 꺼 두시길 권합니다.

업스트림 링크 흔들림. 같은 네트워크의 다른 기기도 같은 시각에 인터넷이 끊긴다면 문제는 통신사나 업스트림에 있으며 VPNWing과 무관합니다. 프록시를 거치지 않는 기기를 함께 관찰해 판단하세요.

유휴 후 끊김: NAT 세션 타임아웃

가정용 공유기와 통신사 게이트웨이는 모두 NAT 세션 테이블을 유지하며, 각 항목에는 수명이 있습니다. 오랫동안 데이터가 없는 연결은 회수되고, 회수되면 터널이 끊깁니다. NAT를 쓰는 모든 네트워크에서 나타나는 현상이며 VPNWing만의 문제는 아닙니다.

처리 방법은 두 가지입니다. 하나는 클라이언트의 keep-alive를 켜서 연결 위에 항상 소량의 데이터가 흐르게 하는 것, 다른 하나는 공유기 설정에서 NAT 세션 타임아웃을 늘리는 것입니다. 일부 공유기가 이 옵션을 제공하며 이름은 'TCP 타임아웃', '세션 유지' 같은 형태일 수 있습니다.

주의할 점은 keep-alive 간격을 너무 짧게 두지 않는 것입니다. 간격이 너무 짧으면 클라이언트가 계속 작은 패킷을 보내 이동통신 환경에서 배터리 소모가 늘어납니다. 대부분의 상황에서는 수십 초에서 몇 분 간격이면 충분합니다.

시스템 차원의 간섭

놓치기 쉬운 간섭 요인:

• 절전 정책. Windows의 절전 모드, macOS의 저전력 모드, Android와 iOS의 배터리 최적화는 모두 백그라운드에서 네트워크 활동을 제한합니다. 클라이언트를 화이트리스트에 추가하면 피할 수 있습니다.
• 보안 소프트웨어의 네트워크 제어. 일부 보안 소프트웨어는 프로그램별 네트워크 동작을 검사하며, 백그라운드에서 재연결 요청을 조용히 차단합니다.
• 가상 네트워크 어댑터 충돌. 다른 VPN이나 가상 머신 소프트웨어를 설치한 뒤 시스템에 가상 어댑터가 여러 개 남아 있으면 라우팅 우선순위가 엉켜 간헐적 끊김이 생깁니다. 쓰지 않는 가상 어댑터를 정리하면 보통 개선됩니다.
• 시스템 프록시 변경. 일부 프로그램이 주기적으로 시스템 프록시 설정을 바꾸며, 바꾸는 순간 연결이 끊깁니다. 그런 프로그램이 실행 중인지 확인하세요.

처리 체크리스트

1. 끊긴 시각을 세 번 이상 기록해 규칙이 있는지 확인합니다.
2. 클라이언트 keep-alive를 켜고 개선되는지 관찰합니다.
3. 다른 네트워크 환경에서 대조해 봅니다. 예: Wi-Fi에서 셀룰러로 전환.
4. 시스템 전원·절전 설정을 확인하고 클라이언트를 화이트리스트에 추가합니다.
5. 쓰지 않는 가상 네트워크 어댑터와 불필요한 프록시 프로그램을 정리합니다.
6. 회선 유형이 다른 회선으로 바꿔 대조합니다.

체크리스트를 모두 따라 했는데도 끊김이 안정적으로 나타나고, 끊긴 시각과 회선 이름을 제시할 수 있다면 문의를 접수하세요. 이런 문제는 서버 로그와 함께 확인해야 하는 경우가 많아 시각이 정확할수록 도움이 됩니다. 연결 성공률과 끊김률을 스스로 측정하는 방법은 안정성 자체 측정 방법 글에 재현 가능한 절차로 정리되어 있습니다.

구독 갱신 실패: 주소·시간·형식 세 가지 확인

구독은 클라이언트와 계정 사이의 설정 통로입니다. 클라이언트가 구독 주소로 주기적으로 요청을 보내 회선 목록, 분할 라우팅 규칙, 연결 파라미터를 받아 옵니다. 구독 갱신 실패는 클라이언트가 최신 설정을 받지 못했다는 뜻이며, 회선 목록이 비어 있거나 모든 회선이 시간 초과로 표시되거나 설정이 유효하지 않다는 안내가 뜰 수 있습니다.

구독은 어떻게 동작하나

구독 주소는 토큰이 붙은 링크이며, 토큰은 계정과 연결되어 있습니다. 클라이언트가 요청을 보내면 서버가 토큰으로 계정을 식별하고 해당 형식의 설정 내용을 돌려줍니다. 이 과정에서 문제가 생길 수 있는 지점은 세 곳입니다. 요청이 나갈 수 있는지, 서버가 이 토큰을 인정하는지, 돌아온 내용을 클라이언트가 파싱할 수 있는지입니다.

점검으로 옮기면 세 방향이 됩니다. 주소, 시간, 형식입니다.

짚어 둘 점은 구독 주소가 계정 자격 증명이라는 것입니다. 사용자 패널에서만 받아야 하며 공개된 채널에 붙여 넣거나 다른 사람에게 보내지 마세요. 주소가 유출된 것 같다면 패널에서 재설정할 수 있습니다.

방향 1: 주소 자체

가장 흔한 실패 원인은 주소가 불완전한 것입니다. 구독 주소는 대개 길어서 메신저, 메일, 메모에서 복사할 때 잘리거나 줄바꿈과 공백이 자동으로 붙기 쉽습니다.

세 가지를 확인하세요. 주소가 완전한 프로토콜 헤더로 시작하고 중간에 공백이나 줄바꿈이 없는지, 메신저가 일부 문자를 링크나 이모지로 자동 변환하지 않았는지, 주소 끝의 파라미터 특히 토큰 부분이 온전한지.

또 다른 흔한 원인은 보안 소프트웨어가 주소를 바꾸는 경우입니다. 일부 보안 소프트웨어는 모든 암호화 요청을 중간에서 검사하며, 요청을 바꾸면 서버가 토큰을 식별하지 못합니다. 클라이언트에서 같은 주소로 두 번 요청해 보고, 두 번 모두 실패하는데 브라우저로 다른 사이트는 정상이라면 해당 검사를 잠시 끄고 대조해 보세요.

방향 2: 시간과 인증서

구독 요청은 암호화 연결로 이루어지고, 인증서 검증은 시스템 시간에 의존합니다. 시스템 시간이 크게 어긋나면 인증서가 무효로 판정되어 요청이 핸드셰이크 단계에서 실패합니다. 이때 클라이언트가 보여 주는 안내는 대개 '갱신 실패'뿐이고 구체적인 이유는 알려 주지 않습니다.

확인 방법: 시스템 시간 설정을 열어 자동 시간 설정이 켜져 있는지, 시간대가 올바른지 확인하세요. 시간대를 넘나드는 이동, 장기간 절전, 수동 시간 변경이 모두 편차를 만들 수 있습니다.

시간이 맞는데도 실패한다면 암호화 트래픽을 가로채는 소프트웨어가 설치되어 있는지 보세요. 이런 소프트웨어는 시스템 인증서 체인을 바꿔 클라이언트가 서버 인증서를 검증하지 못하게 만듭니다.

방향 3: 형식 일치

구독 내용은 클라이언트 유형에 따라 다른 형식으로 내려갑니다. 클라이언트 유형을 잘못 인식했거나 수동으로 맞지 않는 형식을 골랐다면 파싱이 실패합니다.

판단 방법: 패널에서 구독을 새로 받아 오면서 클라이언트 유형에 맞는 형식을 고르세요. 직접 조합하지 마세요. 클라이언트가 여러 형식을 지원한다면 클라이언트가 자동 인식한 형식을 우선 사용하세요.

형식 불일치의 또 다른 증상은 '갱신은 성공했는데 회선 목록이 비어 있음'입니다. 요청은 성공했지만 돌아온 내용이 제대로 파싱되지 않았다는 뜻입니다. 이때는 현재 설정을 비우고 다시 가져오세요. 기존 설정 위에 덧붙이지 마세요.

명령줄로 주소 도달성 확인

아래 예시는 자리표시자 주소를 쓰며 방법 설명만을 위한 것입니다. 실제 구독 주소로 바꿔 공개된 장소에 붙여 넣지 마세요:

# 구독 주소 도달 가능 여부 확인, 응답 헤더만 확인
curl -I "https://example.com/sub?token=YOUR_TOKEN"

# 반환 내용의 앞 몇 줄을 확인해 설정인지 오류 페이지인지 판별
curl -s "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

첫 명령이 4xx나 5xx를 반환하면 서버가 요청을 거부한 것이므로 토큰과 주소 완전성을 중점적으로 확인하세요. 200이 돌아왔는데 두 번째 명령의 출력이 설정 텍스트가 아니라 웹페이지라면 요청이 중간 장비에서 가로채이거나 리다이렉트된 것입니다.

다시 가져오기 전체 절차

1. 사용자 패널에서 구독이 유효한 상태이고 이번 달 트래픽이 남아 있는지 확인합니다.
2. 구독 주소를 다시 복사하고, 복사한 뒤에는 먼저 순수 텍스트 편집기에 붙여 넣어 불필요한 문자가 없는지 확인합니다.
3. 클라이언트에서 현재 설정을 삭제합니다. 가능하면 먼저 내보내 백업하고, 덮어쓰지 마세요.
4. 새 설정을 만들고 주소를 붙여 넣은 뒤 갱신이 끝날 때까지 기다립니다.
5. 회선 목록에 내용이 있는지 확인하고 아무 회선이나 골라 연결을 테스트합니다.
6. 클라이언트가 지원한다면 자동 갱신을 켜고 합리적인 간격을 설정합니다.

그래도 실패할 때

위 세 단계를 모두 확인했는데도 구독 갱신이 실패한다면 다른 네트워크 환경에서 한 번 더 갱신해 보세요. 일부 공용 네트워크는 비표준 요청을 차단합니다. 네트워크를 바꿔 성공했다면 원래 네트워크에 제한이 있다는 뜻입니다.

모든 네트워크 환경에서 실패한다면 문의를 접수할 때 갱신 실패 안내 문구, 사용 중인 클라이언트 플랫폼, 실패가 시작된 시각, 여러 네트워크에서 재현되는지를 함께 적어 주세요. 전체 구독 주소를 문의에 붙이지 말고 토큰 끝자리만 알려 주세요.

특정 앱만 프록시를 못 씀: 분할 라우팅과 전달 방식

브라우저는 모두 정상인데 특정 앱만 계속 연결되지 않는 경우가 있습니다. 이런 문제는 앞 장들과 점검 발상이 완전히 다릅니다. '네트워크가 안 통하는' 것이 아니라 '이 앱의 트래픽이 예상대로 터널로 들어가지 않는' 것입니다.

왜 특정 앱만 안 될까

앱마다 네트워크 요청을 처리하는 방식이 크게 다릅니다. 어떤 앱은 시스템 프록시 설정을 따르고, 어떤 앱은 자체 네트워크 스택을 구현하며, 어떤 앱은 도메인 조회를 완전히 건너뛰고 주소를 직접 쓰고, 또 어떤 앱은 UDP를 우선 사용합니다. 분할 라우팅 규칙은 보통 도메인이나 프로세스로 매칭되므로, 앱의 동작이 규칙의 적용 범위를 벗어나면 트래픽이 새어 나갑니다.

판단의 첫 단계는 이 앱이 실제로 프록시를 거치는지 확인하는 것입니다. 클라이언트를 연결한 뒤 클라이언트의 연결 로그에서 해당 앱의 요청 기록이 보이는지 확인하세요. 기록이 없으면 트래픽이 터널에 아예 들어오지 않은 것이고, 기록은 있는데 요청이 실패하면 터널에는 들어왔지만 대상 쪽에서 거부한 것입니다.

원인 1: 시스템 프록시를 읽지 않음

시스템 프록시는 일종의 약속으로, 앱이 지킬 수도 있고 무시할 수도 있습니다. 일부 앱은 시스템 프록시 설정을 조회하지 않고 연결을 직접 맺어, 트래픽이 터널을 건너뛰고 그대로 나갑니다.

처리 방법은 클라이언트를 TUN 모드로 바꾸는 것입니다. 클라이언트에 따라 가상 네트워크 어댑터 모드나 강화 모드라고 부르기도 합니다. TUN 모드는 네트워크 계층에서 트래픽을 잡으므로 앱이 시스템 프록시를 따르는지에 의존하지 않아 적용 범위가 넓습니다.

대신 TUN 모드는 더 높은 시스템 권한이 필요하고, 일부 시스템에서는 보안 소프트웨어와 충돌할 수 있습니다. 전환 후 시스템 네트워크가 이상해지면 먼저 모드를 되돌린 뒤 점검하세요.

원인 2: 하드코딩된 조회 주소

일부 앱은 조회 서버 주소를 내장하거나 서버 주소를 코드에 고정해 시스템 조회를 완전히 건너뜁니다. 이 경우 분할 라우팅 규칙에 해당 도메인을 적어 두어도 매칭되지 않습니다.

판단 방법: 클라이언트의 연결 로그에서 대상 주소를 보세요. 로그에 도메인이 보이면 시스템 조회를 거친 것이고, 주소가 보이면 앱이 자체적으로 처리한 것입니다.

처리 방법은 두 가지입니다. 하나는 해당 앱의 대상 주소 대역을 프록시 규칙에 추가하는 것, 다른 하나는 클라이언트를 전역 모드로 바꿔 모든 트래픽을 터널로 보내는 것입니다. 전역 모드는 임시로만 쓰시길 권합니다. 장기간 켜 두면 트래픽을 낭비하고 국내 사이트도 느려집니다.

원인 3: UDP와 QUIC

대부분의 프록시 프로토콜은 TCP 지원이 완비되어 있지만 UDP 지원은 구현에 따라 다릅니다. 앱이 주로 UDP를 쓴다면(음성 통화, 실시간 대전 게임, 일부 메신저) 클라이언트에서 UDP 포워딩이 켜져 있지 않을 경우 해당 트래픽은 그대로 실패합니다.

관련된 또 다른 문제는 QUIC입니다. QUIC은 UDP 기반이며 많은 사이트가 기본 전송 방식으로 사용합니다. UDP가 차단되어 있고 클라이언트가 폴백 처리를 하지 않으면, 웹페이지가 계속 돌기만 하는데 다른 브라우저로는 열리는 현상이 나타납니다.

처리 방법: 클라이언트에 UDP 포워딩 옵션이 있다면 켜세요. 브라우저에만 영향이 있다면 브라우저 설정에서 QUIC을 끄고 TCP로 강제 폴백하면 됩니다. 게임과 음성 앱은 UDP 지원이 좋은 회선을 우선 고르세요.

원인 4: 인증서 고정

소수 앱은 서버 인증서 지문을 코드에 고정해 특정 인증서만 신뢰합니다. 이런 앱은 어떤 중간자 복호화를 거쳐도 실패하며, 프록시가 하는 일이 바로 그와 비슷합니다.

증상은 앱이 네트워크 오류나 안전하지 않은 연결을 알리는데, 같은 기기의 브라우저로 같은 서비스는 정상인 경우입니다. 이런 문제는 보통 클라이언트 쪽에서 해결할 방법이 없고, 해당 앱의 도메인을 직접 연결 규칙에 넣어 로컬 네트워크로 나가게 하는 수밖에 없습니다. 로컬 네트워크에서 그 서비스 자체에 접속할 수 없다면 앱 쪽 조정을 기다리는 수밖에 없습니다.

앱 유형별 대조

점검 순서

1. 앱의 트래픽이 클라이언트 로그에 나타나는지 확인합니다. 기록이 없으면 '시스템 프록시를 읽지 않음' 경로로 갑니다.
2. 기록은 있는데 실패한다면 로그의 대상 주소가 도메인인지 주소인지 보세요. 주소라면 하드코딩과 규칙 적용 범위를 확인합니다.
3. UDP와 관련이 있는지 봅니다. QUIC을 끄거나 UDP 포워딩을 켜서 대조합니다.
4. 그래도 실패한다면 인증서 고정을 확인하고, 해당 앱의 도메인을 직접 연결 규칙에 넣어 대조합니다.

특정 회선이 그 앱에 불리하다고 확인되면 다른 회선 유형으로 바꿔 시도하세요. 모든 회선이 같다면 앱 이름, 플랫폼, 클라이언트 로그의 대상 주소를 기록해 문의에 함께 첨부하세요. 원격 근무 상황에서 회의·협업 도구의 회선 선택 차이는 원격 근무용 회선 선택법 글을 참고하세요.

모바일 백그라운드 끊김과 DNS 조회 오류

모바일 문제는 두 가지에서 비롯됩니다. 시스템의 백그라운드 앱 제한, 그리고 네트워크를 바꾼 뒤 남아 있는 조회 결과입니다. 데스크톱에서는 드문 문제지만 모바일 기기에서는 꽤 흔합니다.

모바일에서 백그라운드 끊김이 생기는 이유

모바일 운영체제는 전력 절약을 위해 백그라운드 앱을 엄격하게 제한합니다. 클라이언트가 백그라운드로 밀리면 시스템이 일정 시간 후 네트워크 활동을 동결하고 터널이 만료됩니다. 다시 포그라운드로 돌아오면 클라이언트가 연결을 새로 맺어야 하며, 그동안 몇 초에서 수십 초의 중단이 생깁니다.

이는 시스템 설계에서 비롯된 것이지 클라이언트 고장이 아닙니다. 판단 방법은 간단합니다. 클라이언트를 포그라운드에 둔 채로 끊김이 생기는지 보세요. 포그라운드에서는 안정적이고 백그라운드에서만 끊긴다면 시스템의 백그라운드 제한입니다.

iOS와 Android의 차이

iOS는 백그라운드 네트워크 제한이 더 엄격합니다. 시스템이 VPN류 앱에 일정한 백그라운드 처리 시간을 주지만 무기한 유지하지는 않습니다. 오랫동안 쓰지 않으면 연결이 시스템에 의해 회수될 수 있습니다. iOS에서 할 수 있는 설정은 제한적이며, 주로 클라이언트의 백그라운드 새로 고침 허용, 저전력 모드 해제, 장시간 연결이 필요할 때 클라이언트를 포그라운드에 두는 정도입니다.

Android는 차이가 더 큽니다. 제조사마다 시스템 차원에서 추가적인 절전 최적화를 넣기 때문입니다. 흔한 설정 항목으로는 배터리 최적화 화이트리스트, 백그라운드 활동 제한, 자동 시작 권한, 백그라운드 잠금 같은 제조사 전용 스위치가 있습니다. 특정 브랜드 기기에서 클라이언트가 유난히 자주 끊긴다면 이 항목들을 먼저 확인하세요.

Linux 데스크톱은 모바일은 아니지만 비슷한 전원 관리 문제가 있습니다. 노트북 덮개를 닫아 절전에 들어간 뒤에는 네트워크 장치를 다시 초기화해야 할 수 있고, 터널이 만료됩니다.

모바일을 안정적으로 유지하는 설정

플랫폼별로 나눠 처리합니다:

1. 시스템 설정에서 해당 클라이언트를 찾아 배터리 최적화를 '제한 없음'으로 두거나 화이트리스트에 추가합니다.
2. 백그라운드 활동과 백그라운드 데이터 사용을 허용합니다.
3. 시스템의 스마트 절전, 최대 절전 모드를 끄거나, 그 모드에서 클라이언트를 예외로 지정합니다.
4. 클라이언트 설정에서 자동 재연결을 켜고 재시도 간격을 적절히 줄입니다.
5. 이동통신망에서 쓸 필요가 없다면 Wi-Fi에서만 연결을 유지하도록 설정해 전환에 따른 재연결을 줄일 수 있습니다.

이 설정들은 끊김 빈도를 줄여 주지만 완전히 없애지는 못합니다. 이동통신망 자체의 전환, 신호 음영 지역, 시스템의 자원 회수는 모두 짧은 중단을 만듭니다. 이는 모바일 환경의 고유한 특성입니다.

DNS 이상의 전형적인 증상

조회 문제는 모바일에서 더 흔합니다. 기기가 Wi-Fi와 셀룰러를 자주 오가며 전환할 때마다 조회 서버가 바뀌는데, 시스템 캐시에는 이전 조회 결과가 남아 있을 수 있기 때문입니다.

전형적인 증상은 세 가지입니다. 주소로는 핑이 통하는데 도메인은 열리지 않는 경우(조회 단계는 실패하지만 라우팅은 정상), 일부 도메인이 잘못된 주소로 조회되어 열었을 때 예상과 다른 페이지가 나오는 경우, 네트워크를 바꾼 뒤 한동안 모든 도메인이 열리지 않다가 몇 분 뒤 저절로 회복되는 경우(캐시 만료 후 자가 회복 과정)입니다.

판단 방법: 시스템에 내장된 네트워크 진단 도구를 쓰거나 조회 결과를 확인할 수 있는 앱을 설치해 같은 도메인을 한 번 조회하고, 반환된 결과가 타당한지 보세요. 조회 결과가 컴퓨터에서 확인한 것과 다르다면 조회 단계 문제로 확인해도 됩니다.

플랫폼별 DNS 캐시 정리

캐시를 정리하면 새 조회 결과가 즉시 반영됩니다:

• Windows: 명령 프롬프트에서 ipconfig /flushdns를 실행합니다.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder를 실행합니다.
• Linux: 배포판에 따라 다릅니다. systemd-resolved를 쓰는 시스템에서는 sudo resolvectl flush-caches를 실행합니다.
• iOS와 Android: 시스템이 공개한 캐시 정리 메뉴가 없으므로, 가장 간단한 방법은 비행기 모드를 한 번 켰다 끄거나 기기를 재부팅하는 것입니다.

정리한 뒤에는 클라이언트에서 조회 방식을 내장 조회로 설정해 통신사 조회 결과의 영향을 다시 받지 않도록 하세요. 현재 나가는 IP의 소속 지역만 확인하고 싶다면 사이트 내 IP 확인 페이지에서 한 번 조회해 보세요.

판단 순서와 마무리

모바일 문제는 이 순서로 점검하시길 권합니다:

1. 포그라운드에서 끊기는지 백그라운드에서 끊기는지 확인합니다. 백그라운드라면 시스템 절전 설정 경로로 갑니다.
2. 이동통신망에서만 나타나는지 확인합니다. 그렇다면 네트워크 전환과 신호를 확인하세요.
3. 모든 도메인이 실패하는지 일부 도메인만 실패하는지 확인합니다. 전부라면 조회와 터널 상태를, 일부라면 분할 라우팅 규칙을 확인하세요.
4. 조회 캐시를 정리하고 클라이언트의 조회 모드를 바꾼 뒤 다시 시도합니다.

순서대로 따라 했는데도 끊김이 잦다면 문의를 접수할 때 기기 모델과 OS 버전, 클라이언트 플랫폼, 끊김이 발생할 때의 네트워크 유형, 백그라운드 상태에서 발생했는지를 함께 적어 주세요. 이 정보가 시스템 제한인지 클라이언트 동작인지 판단하는 데 도움이 됩니다.

덧붙이자면 VPNWing은 동시 접속 대수를 제한하지 않아 모바일 기기와 컴퓨터가 같은 계정을 함께 쓸 수 있고, 모바일 기기를 따로 개통할 필요가 없습니다. 모바일에서 가끔 끊긴다는 이유로 다른 방법을 찾기보다 위 단계대로 설정을 조정해 보시면 대부분 뚜렷하게 개선됩니다.