VPN 클라이언트에는 연결됨이라고 표시되는데 브라우저와 앱이 모두 오프라인으로 작동하지 않는 경우가 있습니다. 이때 VPN 서버 자체가 고장 났다고 단정하기보다 로컬 네트워크, DNS 응답, 시스템 프록시, 분할 터널링, 프로토콜과 회선 경로를 순서대로 확인하는 편이 빠릅니다. 연결 상태 표시는 암호화 터널이 만들어졌다는 뜻일 뿐, 모든 애플리케이션의 요청이 올바른 경로로 전달되고 있다는 의미는 아닙니다.
문제를 해결할 때는 여러 설정을 한꺼번에 바꾸지 않는 것이 중요합니다. 먼저 VPN을 끈 상태에서 인터넷이 정상인지 확인하고, 그다음 같은 기기와 네트워크에서 VPN을 다시 연결합니다. 특정 브라우저만 문제인지, 모든 브라우저와 메신저가 같은 증상을 보이는지도 구분해야 합니다. 범위를 좁히면 불필요하게 프로토콜과 운영체제 설정을 반복해서 변경하는 일을 줄일 수 있습니다.
90+
지원 국가
200+
지원 회선
5
지원 플랫폼
무제한
동시 기기
먼저 증상을 범위별로 나누기
가장 먼저 VPN을 해제했을 때 인터넷이 다시 작동하는지 확인하세요. VPN을 끄면 정상이고 켜면 모든 사이트가 열리지 않는다면 터널 경로, DNS, 프록시 또는 방화벽 충돌 가능성이 높습니다. 반대로 VPN을 꺼도 인터넷이 되지 않는다면 공유기, 이동통신 데이터, 공용 와이파이 인증 페이지와 같은 로컬 네트워크 문제를 먼저 해결해야 합니다.
특정 사이트 하나만 열리지 않는 경우에는 전체 인터넷 장애로 보지 않는 것이 좋습니다. 도메인 이름을 해석하지 못하는지, 해당 서비스가 현재 출구 주소를 제한하는지, 브라우저 캐시나 확장 프로그램이 요청을 가로채는지 확인해야 합니다. 모든 웹사이트와 앱이 동시에 오프라인이라면 브라우저보다 운영체제 네트워크 설정을 우선 살펴보세요.
| 증상 | 우선 의심할 원인 | 첫 번째 확인 항목 |
|---|---|---|
| VPN을 켜면 모든 앱이 오프라인 | DNS, 프록시, 라우팅 또는 방화벽 충돌 | 시스템 프록시와 킬 스위치 설정 |
| 브라우저만 접속 불가 | 브라우저 프록시, 확장 프로그램, 캐시 | 시크릿 창과 다른 브라우저 비교 |
| 일부 도메인만 접속 불가 | DNS 응답 또는 서비스별 차단 | 도메인 이름 대신 다른 웹서비스 확인 |
| 연결 직후 잠시 작동하다가 중단 | 회선 혼잡, 프로토콜 불일치, 자동 재연결 실패 | 다른 서버와 프로토콜로 재연결 |
로컬 네트워크와 킬 스위치 확인
공용 와이파이나 호텔, 카페, 학교 네트워크에서는 먼저 브라우저로 네트워크 인증 페이지를 열어야 인터넷을 사용할 수 있습니다. VPN이 자동으로 시작되면 인증 페이지로 이동하지 못하고, 클라이언트는 연결 상태를 표시하지만 실제 외부 통신은 차단될 수 있습니다. VPN을 잠시 해제한 뒤 일반 웹페이지를 열어 인증을 완료하고, 로컬 인터넷이 정상화된 다음 VPN을 다시 연결해 보세요.
공유기나 휴대전화 테더링으로 네트워크를 바꾸어 비교하는 것도 유용합니다. 다른 네트워크에서는 정상이라면 VPN 계정 전체보다 현재 접속망의 포트 제한, DNS 변조, 무선 인증과 라우팅 정책을 의심할 수 있습니다. 반대로 여러 네트워크에서 같은 기기만 계속 실패한다면 클라이언트 설정이나 운영체제 네트워크 스택을 점검해야 합니다.
킬 스위치 또는 네트워크 잠금 기능은 VPN 터널이 완전히 준비되지 않았을 때 트래픽이 외부로 나가지 않도록 막습니다. 보안 측면에서는 유용하지만, 터널이 연결된 것처럼 보이는데 라우팅이 완성되지 않은 상태에서는 모든 앱이 오프라인처럼 보일 수 있습니다. 문제를 진단할 때만 해당 기능을 잠시 완화하고, 원인을 확인한 뒤에는 다시 활성화하는 것이 안전합니다.
- ✅ VPN을 끈 상태에서 현재 와이파이 또는 모바일 네트워크가 정상인지 확인합니다.
- ✅ 공용 네트워크라면 브라우저로 인증 페이지를 먼저 완료합니다.
- ✅ 다른 네트워크에서 같은 VPN 프로필을 연결해 환경별 차이를 비교합니다.
- ❌ 원인을 모른 채 킬 스위치와 보안 기능을 계속 끈 상태로 사용하지 않습니다.
- ❌ 두 개의 VPN 클라이언트나 프록시 앱을 동시에 실행하지 않습니다.
DNS와 시스템 프록시 점검
VPN 터널이 만들어져도 DNS 요청이 잘못된 서버로 전달되면 도메인 이름을 해석하지 못해 웹사이트가 전부 다운된 것처럼 보일 수 있습니다. 이 경우 IP 주소를 직접 사용하는 일부 연결은 작동하거나, 이미 열어 둔 페이지는 보이지만 새 사이트만 열리지 않는 형태로 나타나기도 합니다. DNS 문제를 의심할 때는 브라우저 캐시만 삭제하지 말고 운영체제의 DNS 캐시와 VPN 클라이언트의 DNS 보호 옵션을 함께 확인해야 합니다.
Windows에서는 명령 프롬프트나 PowerShell에서 네트워크 어댑터 상태를 확인하고 DNS 캐시를 갱신할 수 있습니다. macOS와 Linux에서는 활성 네트워크 서비스와 resolv 설정이 VPN 연결 전후에 어떻게 바뀌는지 확인하세요. Android와 iOS는 시스템 설정의 개인 DNS, DNS 프로필, 콘텐츠 차단 앱이 VPN과 충돌할 수 있으므로 사용 중인 보안 앱을 잠시 중지해 비교할 수 있습니다. 운영체제마다 메뉴 이름은 다르지만 핵심은 VPN 연결 전후에 DNS 서버가 의도한 값으로 변경되는지 확인하는 것입니다.
시스템 프록시가 켜져 있는지도 반드시 살펴보세요. VPN 클라이언트가 자체적으로 프록시를 사용하는데 운영체제나 브라우저에 오래된 수동 프록시 주소가 남아 있으면 요청이 존재하지 않는 중계 서버로 전달될 수 있습니다. 브라우저별 프록시 설정, 운영체제의 자동 구성 스크립트, 광고 차단 앱과 개발자 도구의 프록시 항목을 차례로 확인하세요. VPN을 해제한 뒤에도 프록시가 남아 있으면 일반 인터넷까지 막힐 수 있습니다.
분할 터널링과 앱별 라우팅 확인
분할 터널링은 모든 트래픽을 VPN으로 보내지 않고 선택한 앱이나 도메인만 터널로 통과시키는 기능입니다. 잘못된 모드가 선택되면 브라우저가 VPN 밖으로 나가거나, 반대로 로컬 네트워크에서만 접근해야 하는 주소까지 VPN으로 보내져 연결이 실패할 수 있습니다. 연결 표시가 정상이어도 실제 사용하는 앱이 우회 목록에 포함되어 있는지 확인해야 합니다.
앱 제외 목록과 포함 목록은 의미가 서로 다릅니다. 제외 목록에서는 등록한 앱만 일반 인터넷을 사용하고 나머지가 VPN으로 이동할 수 있으며, 포함 목록에서는 등록한 앱만 VPN을 사용합니다. 두 목록에 같은 앱이 중복되거나, 브라우저의 백그라운드 프로세스와 메인 프로세스가 다르게 등록되어 있으면 예상과 다른 결과가 나타날 수 있습니다.
Clash Verge나 sing-box 같은 호환 클라이언트를 사용하는 경우에는 규칙의 우선순위, 기본 경로, DNS 모드와 가상 인터페이스 설정을 함께 확인해야 합니다. Shadowrocket에서는 전역 라우팅, 구성 파일의 규칙과 연결된 DNS 설정을 살펴보세요. 공식 Windows, macOS, Android, iOS, Linux 클라이언트에서도 분할 라우팅을 지원할 수 있지만 메뉴와 기본값은 서로 다를 수 있습니다. 구독 링크를 다시 가져오기 전에 현재 규칙을 백업하면 설정을 비교하기 쉽습니다.
서버와 프로토콜을 바꾸는 순서
기본 설정과 DNS가 정상인데도 인터넷이 되지 않는다면 현재 서버의 혼잡이나 접속망과의 경로 문제일 수 있습니다. 같은 지역의 다른 회선으로 바꾸어 출구 서버 문제인지 비교하고, 그다음 가까운 지역과 다른 지역의 서버를 각각 시험하세요. 서버 변경 뒤에는 기존 연결을 완전히 종료한 뒤 새로 연결해야 이전 세션과 캐시된 경로가 남지 않습니다.
프로토콜도 한 번에 하나씩 변경해야 합니다. WireGuard는 가볍고 빠른 터널을 구성하는 데 적합하지만 특정 네트워크에서 UDP 통신이 제한되면 연결 유지가 어려울 수 있습니다. OpenVPN은 TCP와 UDP 선택에 따라 동작 특성이 달라지며, TCP는 일부 제한 환경에서 연결에 도움을 줄 수 있지만 전송 효율이 항상 같지는 않습니다. Shadowsocks는 프록시 방식으로 동작하므로 시스템 전체 VPN 터널과 적용 범위가 다를 수 있습니다. VMess와 Trojan은 사용하는 클라이언트와 전송 설정에 따라 결과가 달라지고, Hysteria2는 UDP 기반 환경의 영향을 받을 수 있습니다.
따라서 프로토콜을 바꿀 때는 서버, 프로토콜, 전송 방식, 분할 터널링 상태를 기록하세요. 예를 들어 한 번에 서버와 프로토콜과 DNS를 모두 변경하면 문제가 해결되어도 어떤 항목이 원인이었는지 알 수 없습니다. 공식 클라이언트를 사용한다면 최신 프로필을 다시 동기화하고, 호환 클라이언트라면 구독 링크의 갱신 시점과 노드 설정이 정상적으로 반영되었는지 확인합니다.
| 변경 단계 | 확인할 설정 | 해석 방법 |
|---|---|---|
| 서버 변경 | 같은 지역의 다른 회선 | 한 서버만 실패하면 서버 상태나 경로 문제 가능성 |
| 지역 변경 | 가까운 지역과 다른 출구 지역 | 특정 지역 경로 또는 대상 서비스의 응답 차이를 비교 |
| 프로토콜 변경 | WireGuard, OpenVPN, Shadowsocks 등 | 현재 접속망의 UDP 또는 TCP 처리 차이를 확인 |
| 클라이언트 변경 | 공식 클라이언트와 호환 클라이언트 | 앱 자체의 규칙, 권한, 가상 인터페이스 문제를 구분 |
운영체제별 마지막 복구 절차
설정을 바로잡았는데도 이전 상태가 유지되면 VPN 프로필을 삭제하고 다시 가져오는 방법을 고려할 수 있습니다. Windows에서는 오래된 가상 어댑터와 네트워크 프록시가 남아 있는지 확인하고, macOS에서는 VPN 구성과 네트워크 서비스 우선순위를 점검하세요. Linux는 NetworkManager와 별도 터널 서비스가 동시에 실행되는지 살펴봐야 합니다. Android와 iOS에서는 설치된 VPN 프로필, 항상 켜진 VPN, 주문형 연결과 다른 보안 앱의 권한을 확인하는 것이 좋습니다.
재설치 전에는 서버 목록, 사용자 지정 DNS, 분할 터널링 규칙과 필요한 구독 정보를 안전한 곳에 기록하세요. 단순히 앱을 삭제하는 것만으로 시스템 프로필이 모두 제거되지 않는 운영체제도 있습니다. 재설치 후에는 기본 설정으로 먼저 연결한 다음, 필요한 기능을 하나씩 되돌리며 어느 설정에서 문제가 재현되는지 확인하세요.
끝까지 해결되지 않는다면 연결 로그에서 인증 실패, DNS 시간 초과, 라우팅 불가, TLS 오류, 터널 재협상 실패와 같은 문구를 확인합니다. 로그 전체를 공개 채널에 붙여 넣을 때는 사용자 이름, 구독 링크, 토큰과 내부 주소를 지워야 합니다. 지원을 요청할 때는 운영체제, 사용 중인 클라이언트, 연결한 서버, 프로토콜, 문제가 발생한 네트워크와 이미 시도한 조치를 함께 전달하면 같은 안내를 반복할 가능성이 줄어듭니다.
- ✅ VPN 해제 상태와 연결 상태를 같은 기기에서 비교합니다.
- ✅ 브라우저뿐 아니라 메신저와 다른 네트워크 앱의 동작도 확인합니다.
- ✅ DNS, 프록시, 분할 터널링, 서버, 프로토콜을 한 항목씩 변경합니다.
- ✅ 공식 클라이언트와 Clash Verge, sing-box, Shadowrocket의 설정 범위를 구분합니다.
- ❌ 출처를 확인하지 않은 구성 파일이나 구독 링크를 그대로 가져오지 않습니다.