VPN을 처음 접하는 사용자가 막히는 지점은 설치 버튼보다 서로 연결된 여러 질문인 경우가 많습니다. 여러 기기를 동시에 쓰면 서로 연결을 빼앗는지, 데이터 사용량은 무엇으로 구성되는지, 속도 저하가 속도 제한 때문인지, 연결을 계속 유지해야 하는지부터 확인해야 합니다. 네트워크 엔지니어가 될 필요는 없지만, 기기·클라이언트·프로토콜·회선·데이터 한도가 각각 어떤 역할을 하는지는 구분해야 합니다.
먼저 전체 원칙을 정리하면 다음과 같습니다. 클라이언트는 기기에서 트래픽을 처리하고, 프로토콜은 전송 방식을 정하며, 노드는 출구 위치를 결정합니다. 회선 유형은 국제 연결 경로에 영향을 주고, 구독은 사용 가능한 노드와 규칙을 클라이언트에 전달합니다. 문제가 생기면 모든 설정을 무작정 바꾸기보다 이 순서대로 하나씩 점검하는 편이 효과적입니다.
기기와 연결: 동시 사용 가능 여부와 기기별 체감 차이
질문 1: 여러 기기에서 같은 구독을 함께 사용할 수 있나요?
먼저 서비스의 기기 정책을 확인해야 합니다. 29VPN 요금제는 기기 수를 제한하지 않으므로 구독을 본인의 컴퓨터, 태블릿 등 여러 기기에 가져올 수 있습니다. 기기 수 제한이 없다고 해서 모든 기기의 네트워크 환경이 같은 것은 아닙니다. 같은 설정도 가정용 광대역에서는 안정적이지만 공용 무선 네트워크에서는 결과가 다를 수 있습니다. 접속 네트워크, 라우팅 품질, UDP 사용 가능 여부가 모두 영향을 주기 때문입니다.
각 기기는 별도로 데이터를 사용합니다. 컴퓨터에서 파일을 내려받고, 태블릿에서 영상을 재생하며, 다른 기기에서 클라우드 동기화를 진행하면 업로드와 다운로드가 모두 구독 사용량에 포함됩니다. 데이터 사용량이 갑자기 늘었다면 현재 손에 든 기기만 보지 말고, 구독을 가져왔으며 백그라운드에서 네트워크에 연결될 수 있는 모든 기기를 함께 확인해야 합니다.
질문 2: 같은 노드인데 기기마다 속도가 다른 이유는 무엇인가요?
노드 이름이 같다는 것은 같은 출구 설정을 사용한다는 뜻일 뿐, 전체 경로가 같다는 의미는 아닙니다. 컴퓨터는 유선 네트워크를 통해 통신사 백본으로 연결될 수 있고, 태블릿은 혼잡한 무선 채널을 먼저 거칠 수 있습니다. 클라이언트마다 시스템 프록시, 가상 네트워크 어댑터, UDP 전달, DNS 처리 방식도 다릅니다. 기기 성능이 낮으면 암호화·복호화와 패킷 전달 자체가 리소스를 차지할 수 있습니다.
비교할 때는 가능한 한 변수를 통제하세요. 기기를 같은 네트워크에 연결하고, 같은 노드와 같은 테스트 대상을 사용하며, 동기화나 다운로드 중인 앱을 닫은 뒤 각각 테스트합니다. 한 기기에서만 문제가 생기면 해당 기기의 클라이언트 모드, 시스템 권한, 로컬 네트워크를 먼저 확인하세요. 모든 기기가 동시에 느려졌다면 접속 네트워크나 회선 혼잡을 의심할 수 있습니다.
- ✅ 같은 접속 네트워크에서 동일한 노드와 동일한 접속 대상을 비교하세요.
- ✅ 시스템에서 다른 프록시, 필터 또는 가상 네트워크 어댑터가 동시에 실행 중인지 확인하세요.
- ✅ 클라우드 드라이브 동기화, 앱 업데이트, 대용량 파일 전송을 일시 중지한 뒤 다시 확인하세요.
- ❌ 노드 목록의 지연 시간 표시만으로 실제 다운로드 속도나 영상 재생 환경을 판단하지 마세요.
데이터 사용량 계산과 요금제 변경: 업로드·다운로드와 정산 기준 확인
질문 3: VPN 데이터 사용량은 어떻게 계산되나요?
일반적으로 프록시 터널을 통과하는 업로드와 다운로드를 모두 사용량으로 봅니다. 웹페이지를 열면 페이지 리소스를 다운로드하는 동시에 요청을 업로드합니다. 영상 재생은 주로 다운로드가 많지만 재생 위치, 인증, 버퍼링 요청으로 업로드도 발생합니다. 클라우드 동기화, 화상 회의, 파일 전송은 양방향 데이터가 크게 발생할 수 있습니다. 프로토콜 캡슐화에도 필요한 전송 오버헤드가 있으므로 클라이언트 표시값, 시스템 네트워크 통계, 서비스 패널 기록이 바이트 단위로 정확히 일치하지 않을 수 있습니다.
분할 라우팅 모드에 따라 집계 범위가 달라집니다. 규칙에 따라 국내 웹사이트가 직접 연결되면 일반적으로 프록시 터널을 거치지 않습니다. 노드로 전달된 요청만 암호화된 경로에 들어갑니다. 글로벌 모드에서는 인지하기 어려운 백그라운드 요청을 포함해 더 많은 앱 트래픽이 노드를 통과합니다. 사용량을 관리하려면 연결을 자주 끊기보다 어떤 앱과 도메인이 실제로 프록시를 거쳐야 하는지 확인하는 것이 중요합니다.
| 사용 상황 | 주요 데이터 방향 | 놓치기 쉬운 발생 원인 | 관리 방법 |
|---|---|---|---|
| 웹페이지와 문서 | 주로 다운로드 | 이미지, 글꼴, 자동 재생 콘텐츠 | 규칙 기반 분할 라우팅을 사용해 관련 없는 사이트가 노드를 거치지 않게 하세요. |
| 온라인 동영상 | 지속적인 다운로드 | 사전 로딩, 자동 화질 향상 | 화면과 네트워크 환경에 맞는 화질을 선택하세요. |
| 클라우드 동기화 | 양방향 전송 | 백그라운드 사진 동기화, 버전 기록, 중복 동기화 | 필요에 따라 동기화 앱을 제외하거나 백그라운드 작업을 일시 중지하세요. |
| 원격 근무 | 업무에 따라 달라짐 | 회의 화면, 첨부파일, 코드 저장소 | 국제 접속이 필요한 서비스만 터널로 보내세요. |
질문 4: 월중 업그레이드는 어떻게 계산되며, 남은 데이터는 유지되나요?
요금제 업그레이드에는 모든 서비스에 적용되는 공통 계산 방식이 없습니다. 어떤 시스템은 한도를 즉시 전환하고, 어떤 시스템은 다음 정산 주기에 적용하며, 남은 기간을 기준으로 차액을 표시하기도 합니다. 기존 데이터가 유지되는지도 월간 한도인지 영구적으로 만료되지 않는 데이터 패키지인지에 따라 다르므로, 한 상품의 규칙을 다른 상품에 그대로 적용해서는 안 됩니다.
변경하기 전에는 사용자 패널에 표시된 결제 금액, 적용 시점, 현재 한도와 변경 후 한도를 기준으로 판단하세요. 패널에 이 정보가 명확히 표시되지 않는다면 먼저 문의 페이지에서 확인한 뒤 요금제를 변경하세요. “업그레이드”라는 단어만 보고 반드시 일할 계산된다고 추측하거나, 사용하지 않은 한도가 새 요금제로 자동 이월된다고 가정하지 마세요.
속도와 속도 제한: 회선 혼잡·접속 품질·한도 상태부터 구분하기
질문 5: 속도가 갑자기 떨어지면 서비스가 속도를 제한한 것인가요?
반드시 그런 것은 아닙니다. 속도는 로컬 기기, 무선 네트워크, 접속 통신사, 국제 연결 구간, 노드 출구, 대상 웹사이트가 함께 작용한 결과입니다. 어느 한 구간에서든 혼잡이 발생하면 다운로드 속도 저하, 영상 버퍼링, 간헐적인 연결 끊김으로 나타날 수 있습니다. 대상 웹사이트 자체가 출구 지역, 요청 빈도, 콘텐츠 전송 노드에 따라 응답을 조정할 수도 있습니다.
요금제나 한도 차원의 제한이 있는지 확인하려면 먼저 패널 상태와 남은 한도를 확인하세요. 그런 다음 여러 노드, 여러 회선 유형, 여러 시간대의 성능을 비교합니다. 모든 노드가 느리지만 접속 네트워크를 바꾸면 회복된다면 기존 네트워크를 점검해야 합니다. 특정 지역만 문제가 생기면 해당 지역까지의 경로 문제일 수 있습니다. 웹페이지는 정상인데 특정 앱만 실패한다면 분할 라우팅, DNS 또는 UDP 호환성 문제에 가깝습니다.
- 다른 기기에서 진행 중인 다운로드, 업데이트, 동기화 작업을 일시 중지하세요.
- 요금제 상태와 데이터 한도가 정상인지 확인하세요.
- 같은 지역에서 노드를 바꿔 단일 노드 문제인지 판단하세요.
- 그다음 직접 연결, 중계 또는 IEPL 전용 회선 등 회선 유형을 비교하세요.
- 접속 네트워크를 바꾼 뒤 다시 테스트해 문제가 로컬에 있는지 원격에 있는지 확인하세요.
질문 6: VPN을 계속 켜 둬야 하나요?
정해진 답은 없습니다. 국제 협업 도구, 원격 리소스 또는 지역별 콘텐츠에 계속 접속해야 한다면 연결을 유지하고 규칙 기반 분할 라우팅을 사용해 국내 서비스는 직접 연결할 수 있습니다. 자료를 가끔 확인하는 정도라면 작업이 끝난 뒤 연결을 끊어도 됩니다. 중요한 것은 무조건 켜 두거나 끄는 것이 아니라 현재 작업에 맞는 연결 모드를 선택하는 것입니다.
글로벌 모드는 일시적인 문제 확인에 적합합니다. 규칙이 요청을 매칭하지 못해 실패했는지 빠르게 판단할 수 있지만, 모든 상황의 기본 설정으로 사용하기에는 적합하지 않습니다. 규칙 모드는 장기 사용에 더 알맞으며 불필요한 우회와 데이터 사용량을 줄일 수 있습니다. 모바일 기기는 절전, 화면 잠금, 네트워크 전환으로 터널을 일시적으로 다시 만들 수 있으며, 이것이 반드시 구독 만료를 의미하지는 않습니다.
프로토콜과 회선: 이름이 다르면 해결하는 문제도 다릅니다
질문 7: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 중 무엇을 선택해야 하나요?
이 이름들은 서로 다른 프록시 프로토콜이나 전송 체계를 뜻하며 속도 등급을 의미하지 않습니다. Shadowsocks는 구조가 비교적 단순하고 생태계가 성숙했습니다. VMess는 V2Ray 생태계에서 흔히 사용되며 인증과 여러 전송 조합을 포함합니다. Trojan은 보통 TLS와 함께 사용되고, VLESS는 가벼운 인증 방식에 가깝고 TLS나 Reality 같은 전송 보안 방식과 조합되는 경우가 많습니다.
Hysteria2와 TUIC는 주로 QUIC와 UDP 전송을 기반으로 하며, 지연 시간이 길거나 패킷 손실이 있는 네트워크에서 기존 TCP 방식과 다른 성능을 보일 수 있습니다. 단, 접속 네트워크에서 UDP를 안정적으로 사용할 수 있어야 합니다. 일부 사내 네트워크나 공용 네트워크는 UDP를 제한하므로, 이때는 TCP 연결이 가능한 프로토콜이 오히려 사용하기 쉽습니다.
초보자는 프로토콜 이름만 보고 이른바 “가장 빠른” 방식을 좇을 필요가 없습니다. 먼저 구독에서 추천하는 설정을 사용하세요. 연결에 실패하면 접속 네트워크가 UDP를 지원하는지, 클라이언트가 해당 프로토콜과 호환되는지, 대상 앱이 UDP를 필요로 하는지에 따라 조정합니다. 프로토콜 설정에는 서버 주소, 포트, 인증 정보, 전송 계층, TLS 매개변수가 포함되며 하나라도 맞지 않으면 연결에 실패합니다.
| 프로토콜 또는 체계 | 전송 특성 | 선택 시 확인할 점 |
|---|---|---|
| Shadowsocks | 가벼운 프록시 프로토콜로, 지원하는 클라이언트가 많음 | 암호화 방식과 인증 정보가 일치하는지 확인 |
| VMess | V2Ray 생태계에서 흔히 사용되며 다양한 전송을 조합할 수 있음 | 클라이언트가 구독에 포함된 전송 설정을 완전히 지원해야 함 |
| Trojan | 일반적으로 TLS 전송과 함께 사용 | 도메인, 인증서 검증, 서버 이름이 일치해야 함 |
| VLESS | 가벼운 인증 방식으로, 다양한 보안 계층과 조합 가능 | 클라이언트의 TLS 또는 Reality 지원 여부 확인 |
| Hysteria2 | QUIC와 UDP 기반 | 현재 접속 네트워크에서 UDP를 사용할 수 있는지 먼저 확인 |
| TUIC | QUIC와 UDP 기반 | 클라이언트 버전과 매개변수 호환성 확인 |
질문 8: 직접 연결, 중계, IEPL 전용 회선은 어떻게 다른가요?
직접 연결은 기기에서 해외 노드로 바로 연결하는 방식입니다. 경로는 단순하지만 국제 구간은 주로 국내 통신사의 공용 인터넷 라우팅에 좌우됩니다. 중계 방식은 더 가깝거나 적합한 접속 지점에 먼저 연결한 뒤 중계 경로를 통해 출구로 전달하며, 일부 공용 인터넷 경로를 개선하는 것이 목적입니다. 다만 중계 접속 지점 자체가 병목이 될 수도 있습니다. IEPL 전용 회선은 국제 이더넷 전용 회선을 통해 전송되며, 일반 공용 인터넷 직접 연결과 라우팅 구성이 다르고 국제 연결 구간을 더 안정적으로 관리하는 데 중점을 둡니다.
회선 라벨은 접속 지역과 함께 이해해야 합니다. 같은 중계 회선도 통신사에 따라 성능이 다를 수 있으며, IEPL이라고 해서 대상 웹사이트가 반드시 더 빠른 것은 아닙니다. 마지막에는 출구에서 대상 서비스까지의 네트워크를 거쳐야 하기 때문입니다. 회선을 고를 때는 먼저 출구 지역을 정한 다음 같은 출구에서 회선 유형을 비교하세요. 이렇게 해야 지역 거리와 회선 품질을 혼동하지 않을 수 있습니다.
구독 가져오기와 개인정보 점검: 클라이언트·DNS·분할 라우팅 규칙
질문 9: 구독 링크는 어떻게 가져오며, 업데이트 후 노드가 바뀌지 않는 이유는 무엇인가요?
구독 링크는 업데이트 가능한 설정 진입점입니다. 일반적인 과정은 사용자 패널에서 구독 주소를 복사한 뒤 호환 클라이언트에서 “URL에서 가져오기” 또는 “구독 추가”를 선택하고 저장하는 것입니다. 이후 수동으로 업데이트하고 노드 목록에서 회선을 선택합니다. 클라이언트마다 버튼 이름은 다를 수 있지만, 핵심은 구독을 가져오고 설정을 해석한 다음 노드를 선택해 시스템 프록시 또는 가상 네트워크 어댑터 모드를 시작하는 것입니다.
가져온 뒤 노드가 보이지 않는 흔한 원인은 복사한 내용이 완전하지 않거나, 클라이언트가 구독에 포함된 프로토콜을 지원하지 않거나, 시스템 시간이 잘못되어 TLS 검증에 영향을 주거나, 현재 네트워크에서 구독 주소에 접근할 수 없는 경우입니다. 업데이트 후에도 노드가 바뀌지 않는다면 클라이언트가 캐시를 읽고 있거나, 잘못된 구독 그룹을 업데이트했거나, 기존 설정과 새 설정이 동시에 존재할 수 있습니다.
- ✅ 사용자 패널에서 완전한 구독 링크를 다시 복사하고 문자를 직접 수정하지 마세요.
- ✅ 클라이언트가 구독에서 제공하는 프로토콜과 전송 유형을 지원하는지 확인하세요.
- ✅ 올바른 구독 그룹에서 업데이트를 실행하고 업데이트 시간이 바뀌었는지 확인하세요.
- ✅ 중복된 기존 그룹을 삭제하기 전에 새 그룹이 정상적으로 해석되었는지 확인하세요.
- ❌ 인증 정보가 포함된 구독 링크를 공개 페이지나 공유 문서에 게시하지 마세요.
Windows와 Linux 클라이언트는 일반적으로 시스템 프록시, 가상 네트워크 어댑터, 라우팅을 세밀하게 제어할 수 있습니다. iOS와 iPadOS 클라이언트는 시스템 권한을 통해 VPN 설정을 추가해야 합니다. Android 클라이언트는 앱별 분할 라우팅을 제공할 수 있지만, 구체적인 기능은 클라이언트 구현에 따라 다릅니다. 클라이언트를 선택할 때는 화면이 비슷한지보다 프로토콜 호환성, 구독 업데이트, 규칙 모드, 로그를 통한 문제 해결 기능을 먼저 확인하세요. 단계별 안내가 필요하다면 사용 가이드에서 플랫폼별 시작 방법을 확인할 수 있습니다.
질문 10: DNS 누출이란 무엇이며, 분할 라우팅 규칙은 어떻게 확인하나요?
DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 프록시는 연결되어 있지만 도메인 조회를 로컬 네트워크가 직접 처리하면 조회 경로가 프록시 출구와 달라질 수 있으며, 이를 일반적으로 DNS 누출이라고 합니다. 이 경우 로컬 DNS 서비스에 도메인 조회가 노출되거나, 대상 서비스가 조회 지역과 접속 출구의 불일치를 감지해 연결 또는 지역 판단에 이상이 생길 수 있습니다.
점검할 때는 DNS 요청을 누가 처리하는지, 조회 결과가 어디에서 반환되는지, 실제 연결이 예상한 노드를 통과하는지를 함께 확인해야 합니다. 클라이언트에 “연결됨”이라고 표시되는 것만으로는 충분하지 않습니다. 가상 네트워크 어댑터 모드를 사용하면 클라이언트가 시스템 트래픽을 더 완전하게 처리할 수 있지만 다른 네트워크 필터링 소프트웨어와 충돌할 수 있습니다. 시스템 프록시 모드는 더 가볍지만 시스템 프록시 설정을 따르지 않는 모든 앱을 포함하지는 않을 수 있습니다.
분할 라우팅 규칙은 일반적으로 도메인, IP, 앱 또는 규칙 그룹에 따라 직접 연결·프록시·차단을 결정합니다. 규칙 순서가 중요합니다. 더 포괄적인 규칙이 먼저 적용되면 뒤의 세부 규칙이 작동하지 않을 수 있습니다. 특정 웹사이트가 열리지 않을 때는 잠시 글로벌 모드로 전환해 비교해 보세요. 글로벌 모드에서는 작동하지만 규칙 모드에서 실패한다면 모든 노드를 바꾸기보다 도메인 규칙, DNS 조회, 최종 매칭 결과를 확인해야 합니다.
- ✅ 현재 클라이언트가 규칙 모드, 글로벌 모드, 직접 연결 모드 중 무엇을 사용하는지 확인하세요.
- ✅ 연결 로그에서 도메인, 대상 주소, 적용된 규칙, 선택된 출구를 확인하세요.
- ✅ DNS를 클라이언트가 처리하는지, 조회 경로가 예상과 일치하는지 확인하세요.
- ✅ 글로벌 모드로 잠시 비교해 문제가 분할 라우팅 규칙에서 비롯되었는지 판단하세요.
- ❌ DNS나 시스템 라우팅을 변경하는 여러 클라이언트를 동시에 실행하지 마세요.
열 가지 질문을 하나로 연결하면 안정적인 사용 흐름을 만들 수 있습니다. 기기 수는 설정 분포를 결정하고, 데이터 사용량은 터널을 통과하는 양방향 전송으로 구성됩니다. 요금제 변경은 패널의 정산 정보를 기준으로 하며, 속도 문제는 경로별로 나누어 확인해야 합니다. 프로토콜과 회선은 접속 조건과 목표 지역에 맞춰 선택합니다. 마지막으로 구독을 올바르게 가져오고 DNS 경로를 관리하며 분할 라우팅 규칙을 확인하면 클라이언트가 예상대로 작동합니다.