VPN 초보자 FAQ는 주로 세 가지 문제로 나뉩니다. 계정을 여러 기기에서 사용할 수 있는지, 트래픽과 속도가 어떤 관계인지, 클라이언트 연결 후 어떻게 관리해야 하는지입니다. 많은 장애는 회선 자체가 아니라 구독 미업데이트, 절전 기능에 따른 백그라운드 연결 중단, 잘못된 분할 라우팅 규칙 또는 로컬 네트워크가 계속 처리하는 DNS에서 발생합니다.
아래에서는 실제 점검 순서에 따라 10가지 질문에 답합니다. 각 항목은 먼저 결론을 제시한 뒤 판단 방법을 설명합니다. 모든 프로토콜 이름을 미리 알 필요는 없습니다. 먼저 계정, 구독, 회선과 시스템 설정을 확인하면 대부분의 문제를 찾을 수 있습니다.
질문 1: 하나의 계정을 여러 기기에서 사용할 수 있나요?
결론: IWVPN 요금제는 기기 수를 제한하지 않으므로 본인의 여러 기기에 설정할 수 있습니다. 단, 모든 기기의 사용량은 같은 계정의 요금제 트래픽에서 차감됩니다. 컴퓨터에서 파일을 다운로드하고 태블릿에서 동영상을 재생하며 다른 기기에서 시스템을 업데이트하면 발생한 데이터가 기기별로 따로 제공되는 것이 아니라 계정 사용량에 함께 반영됩니다.
여러 기기에서 사용할 때는 클라이언트와 기기에 알아보기 쉬운 이름을 지정하고 구독 출처를 일관되게 유지하는 것이 좋습니다. 특정 기기를 장기간 사용하지 않는다면 로컬 설정을 바로 삭제할 수 있습니다. 기기를 바꿀 때 기존 클라이언트의 캐시 폴더를 복사할 필요는 없습니다. 새 기기에 호환 클라이언트를 설치한 뒤 사용자 패널에서 구독을 다시 가져와 추가하면 됩니다.
- ✅ 각 기기에서 본인 계정으로 발급받은 구독 링크를 사용하세요.
- ✅ 공유 기기에서는 사용자 패널에서 로그아웃하고 브라우저에 로그인 상태를 장기간 남겨 두지 마세요.
- ✅ 더 이상 사용하지 않는 기기에서는 로컬 구독과 프록시 설정을 삭제하세요.
- ❌ 구독 링크를 공개 문서, 단체 채팅 캡처 또는 공개 코드 저장소에 붙여 넣지 마세요.
질문 2: 요금제 트래픽 계산에는 어떤 데이터가 포함되나요?
결론: 프록시 회선을 통해 전송되는 업로드와 다운로드 데이터는 모두 트래픽으로 차감됩니다. 웹페이지 열기, 이미지 로드, 동영상 시청과 파일 다운로드는 다운로드 트래픽에 해당합니다. 첨부파일 전송, 백업 업로드와 화상회의 송출은 업로드 트래픽입니다. 구체적인 집계는 사용자 패널 표시를 기준으로 확인하세요. 운영체제의 앱별 사용량은 점검에 참고할 수 있지만 서비스 청구량과 동일하게 보기는 어렵습니다.
연결을 유지하는 것 자체는 보통 주요 사용량 원인이 아닙니다. 실제로 주의할 부분은 백그라운드 동기화, 클라우드 백업, 앱 자동 업데이트와 고비트레이트 미디어입니다. 전역 프록시를 사용하면 더 많은 앱이 회선을 거치고, 규칙 기반 분할 라우팅은 규칙에 일치하는 요청만 프록시로 보내므로 두 모드의 트래픽 양상은 크게 다를 수 있습니다.
| 요금제 유형 | 포함 트래픽 | 과금 방식 |
|---|---|---|
| 월간 요금제 | 60GB | ¥9.9 / 월 |
| 월간 요금제 | 250GB | ¥18 / 월 |
| 월간 요금제 | 500GB | ¥28 / 월 |
| 트래픽 패키지 | 300GB | ¥158 |
| 트래픽 패키지 | 1000GB | ¥358 |
| 트래픽 패키지 | 3000GB | ¥658 |
질문 3: 트래픽 초기화는 어떤 기준일에 진행되나요?
결론: 월간 요금제의 트래픽은 개통일을 기준으로 매월 초기화되며, 자연월 기준이라고 단정해서는 안 됩니다. 다음 초기화 시점은 월초를 기준으로 임의 계산하지 말고 사용자 패널의 요금제 상태에서 확인하세요. 별도 트래픽 패키지는 만료되지 않으며 월간 요금제와 초기화 방식이 다릅니다.
클라이언트에 표시되는 트래픽과 패널의 수치가 다르면 먼저 구독을 업데이트한 뒤 클라이언트를 다시 열어 확인하세요. 클라이언트는 로컬 추정치, 마지막 동기화 결과 또는 현재 설정에서 발생한 트래픽만 표시할 수 있습니다. 계정 전체 사용량은 서버 측 패널에서 확인하는 것이 가장 정확합니다. 여러 기기를 동시에 사용하면 이런 표시 차이가 더 쉽게 발생합니다.
질문 4: 속도가 느려졌다면 속도 제한인가요?
결론: 트래픽 한도와 연결 속도는 서로 다른 지표이므로 한 번 느려졌다고 속도 제한으로 단정할 수 없습니다. 실제 속도는 로컬 인터넷 회선, 무선 네트워크 품질, 통신사 라우팅, 회선 거리, 현재 노드 부하, 프로토콜 특성과 대상 웹사이트의 응답 성능에 모두 영향을 받습니다. 같은 회선이라도 웹사이트에 따라 결과가 다를 수 있습니다.
점검할 때는 한 번에 하나의 변수만 바꾸세요. 먼저 프록시를 거치지 않은 로컬 네트워크가 정상인지 확인한 다음 같은 지역의 회선으로 전환하세요. 이후 가까운 지역과 먼 지역의 성능을 비교합니다. 특정 앱만 느리다면 전체 연결보다 분할 라우팅, DNS 또는 대상 서비스에 원인이 있을 가능성이 큽니다.
- 대용량 파일 다운로드, 클라우드 동기화와 시스템 업데이트를 일시 중지하세요.
- 현재 네트워크에서 일반 웹사이트에 안정적으로 접속할 수 있는지 확인하세요.
- 구독을 업데이트해 노드 목록이 오래되지 않았는지 확인하세요.
- 같은 네트워크에서 회선만 변경하고 여러 클라이언트 옵션을 동시에 수정하지 마세요.
- 클라이언트 로그에서 시간 초과, 핸드셰이크 실패와 DNS 오류를 확인하세요.
- 무선 네트워크 변동이 크다면 더 안정적인 접속 방식으로 바꾼 뒤 다시 측정하세요.
질문 5: VPN 연결을 계속 켜 두어야 하나요?
결론: 무조건 계속 켤 필요는 없으며, 이용 목적과 분할 라우팅 방식에 따라 결정하면 됩니다. 국제 회선이 필요한 앱은 규칙 기반 분할 라우팅으로 처리하고 로컬 서비스는 직접 연결로 유지할 수 있습니다. 이렇게 하면 불필요한 트래픽을 줄이고 출구 지역 변경으로 로컬 웹사이트에서 추가 인증이 발생하는 상황도 피할 수 있습니다.
전역 프록시를 사용하면 시스템 프록시가 가로채는 거의 모든 요청이 현재 회선을 거치게 됩니다. 규칙 모드에서는 도메인, IP, 프로세스 또는 규칙 집합에 따라 연결 경로를 결정합니다. 초보자는 규칙 모드부터 시작하는 편이 좋지만 규칙 출처가 신뢰할 수 있고 최신 상태인지 확인해야 합니다. 접속에 문제가 생기면 잠시 전역 모드로 전환해 비교할 수 있습니다. 전역 모드는 정상이고 규칙 모드만 실패한다면 대개 규칙 매칭이 원인입니다.
모바일 운영체제는 절전 정책으로 백그라운드 클라이언트를 중지할 수 있습니다. 보통 화면을 잠근 뒤 연결이 끊기고 앱으로 돌아왔을 때 복구되는 형태로 나타납니다. 이 경우 클라이언트의 백그라운드 실행을 허용하고 시스템이 VPN 권한을 자동으로 철회하지 않았는지 확인하세요. 옵션 이름은 운영체제마다 다르므로 현재 기기의 설정 화면을 기준으로 확인해야 합니다.
질문 6: 기기를 바꾸거나 시스템을 재설치한 뒤 어떻게 이전하나요?
결론: 기존 설정 폴더를 복사하는 것보다 클라이언트를 다시 설치하고 구독을 다시 가져오는 편이 안전합니다. 기존 폴더에는 만료된 캐시, 오래된 규칙, 시스템 경로와 인증서 상태가 포함될 수 있으며 플랫폼이 다르면 인식할 수 없는 필드가 생길 수도 있습니다. 구독 링크가 회선 목록을 복원하는 주요 경로입니다.
- 사용자 패널에 들어가 요금제가 계속 사용 가능한 상태인지 확인하세요.
- 새 기기에 운영체제와 호환되는 클라이언트를 설치하세요.
- 패널에서 구독 링크를 가져와 클라이언트의 구독 가져오기 기능으로 추가하세요.
- 구독을 한 번 업데이트하고 회선 이름과 그룹이 정상적으로 표시되는지 확인하세요.
- 회선을 선택해 연결한 다음 웹페이지 접속과 DNS 해석을 점검하세요.
- 새 기기가 정상 작동하는 것을 확인한 뒤 기존 기기의 구독 설정을 삭제하세요.
IWVPN은 이메일 주소 없이 가입할 수 있으며 사용자 이름과 비밀번호는 직접 안전하게 보관해야 합니다. 패널에 로그인할 수 없다면 검색 엔진이나 출처가 불분명한 페이지에 인증 정보를 다시 입력하지 말고 사이트 내 진입 경로에서 로그인 페이지로 이동하세요. 필요한 경우 문의 티켓을 통해 계정 문제를 처리할 수 있습니다.
질문 7: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 중 무엇을 선택해야 하나요?
결론: 프로토콜에는 네트워크 환경과 무관한 절대적인 순위가 없습니다. 서버에서 제공하고 클라이언트가 완전히 지원하는 설정을 우선 사용하세요. Shadowsocks는 가벼운 프록시 프로토콜로 클라이언트 생태계가 성숙했습니다. VMess와 VLESS는 관련 프록시 코어에서 흔히 사용되며, VLESS는 간결한 인증 방식을 중시합니다. 실제 전송 특성은 함께 사용하는 전송 계층과 보안 설정에 따라 달라집니다. Trojan은 보통 TLS와 함께 사용되며 일반적인 암호화 연결과 유사한 형태를 보입니다.
Hysteria2와 TUIC는 UDP 기반 전송 설계를 사용하므로 패킷 손실이나 지터가 있는 환경에서 기존 TCP 방식과 다른 성능을 보일 수 있습니다. 단, 현재 네트워크에서 UDP 통신이 안정적으로 허용되어야 합니다. 회사, 학교 또는 공공 네트워크가 UDP를 많이 제한한다면 연결이 구성되지 않을 수 있습니다. 이때는 이해하지 못하는 하위 매개변수를 반복해서 수정하기보다 서버에서 제공하는 다른 호환 회선으로 전환하세요.
플랫폼마다 클라이언트 지원 범위도 다릅니다. Windows와 macOS 클라이언트는 대체로 시스템 프록시, 가상 네트워크 어댑터와 규칙 관리 기능을 비교적 완전하게 제공합니다. Android에서는 앱별 프록시가 흔해 터널에 포함할 앱을 지정할 수 있습니다. iOS는 시스템 네트워크 확장 방식의 제약을 받으며 가져오기 형식과 백그라운드 동작은 클라이언트에 따라 달라집니다. 가져오기 전에 파일을 추가할 수 있는지만 보지 말고 구독에 사용된 프로토콜을 지원하는지 확인하세요.
질문 8: 구독 링크란 무엇이며 얼마나 자주 업데이트해야 하나요?
결론: 구독 링크는 클라이언트가 회선 설정을 가져오는 주소이며 일반 웹페이지 북마크가 아닙니다. 클라이언트가 링크를 읽으면 노드 이름, 서버 주소, 포트, 프로토콜 매개변수와 그룹 정보를 가져옵니다. 회선이 변경되어도 로컬 클라이언트가 이를 자동으로 알아차린다고 보장할 수 없습니다. 노드를 사용할 수 없거나 회선 목록에 이상이 있거나 패널에서 설정 업데이트를 안내할 때는 구독을 수동으로 업데이트하세요.
구독 업데이트와 속도 측정, 연결은 서로 다른 작업입니다. 업데이트는 설정을 가져오는 역할만 하고, 속도 측정은 클라이언트와 노드 사이의 응답을 확인하며, 연결은 실제 데이터 통로를 구성합니다. 일부 클라이언트는 업데이트 성공을 표시해도 이전 노드가 목록에 남을 수 있습니다. 이 경우 해당 구독의 업데이트 정책을 확인하거나 중복 구독을 삭제한 뒤 패널에서 다시 가져오세요.
사용자 패널 열기
→ 구독 링크 가져오기
→ 클라이언트에 구독 추가
→ 구독 업데이트
→ 회선 선택
→ 연결 구성
→ 접속 및 DNS 확인구독 링크는 계정 인증 정보와 같은 수준으로 관리해야 합니다. 링크가 공개된 적이 있다면 기존 링크를 더 이상 배포하지 말고 사용자 패널이나 지원 채널을 통해 처리하세요. 채팅 메시지나 브라우저 기록만 삭제한다고 복사된 링크까지 무효화되었다고 확인할 수는 없습니다.
질문 9: IEPL 전용 회선, 중계 회선과 직접 연결은 어떻게 다른가요?
결론: 세 방식의 주요 차이는 로컬 네트워크에서 목적지 출구로 들어가기 전 데이터가 지나가는 경로에 있습니다. 직접 연결은 사용자 네트워크가 해외 서버에 바로 연결되는 방식으로 경로가 단순하지만 통신사의 국제 라우팅에 더 크게 좌우됩니다. 중계 회선은 더 가깝거나 품질이 안정적인 입구에 먼저 연결한 뒤 중계 링크를 통해 출구로 전달하므로 복잡한 공용 인터넷 경로에서 발생하는 일부 변동을 줄일 수 있습니다.
IEPL 전용 회선은 전용 전송 경로를 사용하는 국제 이더넷 전용 회선 방식을 의미합니다. 일반 공용 인터넷 직접 연결과 경로 구성 방식이 달라 연결 안정성을 중시하는 환경에 더 적합한 경우가 많습니다. 다만 전용 회선이라고 해서 대상 웹사이트가 항상 빠른 것은 아닙니다. 사용자와 입구 사이의 로컬 네트워크, 출구와 대상 서비스 사이의 경로, 대상 서버 자체가 최종 사용 환경에 영향을 줍니다.
| 회선 유형 | 경로 특징 | 판단 방법 |
|---|---|---|
| 직접 연결 | 로컬 네트워크가 출구에 직접 연결 | 현재 네트워크의 국제 라우팅 성능을 먼저 테스트 |
| 중계 | 먼저 중계 입구로 들어간 뒤 대상 출구로 이동 | 같은 지역의 직접 연결 회선과 안정성 비교 |
| IEPL 전용 회선 | 전용 전송 경로로 국제 연결 경로 구성 | 지속 연결, 저녁 시간대 사용과 장시간 전송 성능을 확인 |
회선을 선택할 때는 먼저 출구 지역이 대상 서비스의 요구에 맞는지 확인한 다음 경로 유형을 살펴보세요. 물리적 거리가 가까우면 일반적으로 전송 지연을 줄이는 데 유리하지만 실제 테스트를 대신할 수는 없습니다. 노드 이름에 있는 ‘고속’이라는 표현만으로 판단하지 말고 클라이언트의 한 번 측정한 결과를 전체 다운로드 성능으로 간주하지도 마세요.
질문 10: DNS 누수와 분할 라우팅 규칙은 어떻게 확인하나요?
결론: 연결에 성공한 뒤에도 도메인 해석과 실제 트래픽이 예상한 경로로 흐르는지 확인해야 합니다. DNS는 도메인 이름을 주소로 변환합니다. 브라우저 트래픽은 프록시를 통과하지만 DNS 요청은 로컬 네트워크가 계속 처리한다면 해석 지역 불일치, 잘못된 도메인 해석 또는 로컬 DNS 제공업체에 접속 기록이 노출되는 문제가 발생할 수 있습니다.
분할 라우팅 규칙은 요청을 프록시로 보낼지, 직접 연결할지 또는 차단할지를 결정합니다. 도메인으로 매칭하는 규칙은 리디렉션, 콘텐츠 전송 도메인과 앱 자체의 해석 방식에 영향을 받을 수 있습니다. IP로 매칭할 때는 주소 목록을 제때 업데이트해야 합니다. 특정 웹사이트의 홈 화면은 열리지만 이미지, 로그인 또는 동영상이 실패한다면 서로 다른 리소스 도메인이 다른 출구로 배정된 것이 흔한 원인입니다.
- ✅ 연결 후 클라이언트의 DNS 모드가 활성화되어 있고 현재 프록시 모드와 함께 작동하는지 확인하세요.
- ✅ 시스템에 충돌하는 수동 프록시, 이전 VPN 설정 또는 기존 DNS 설정이 남아 있는지 확인하세요.
- ✅ 특정 앱에 문제가 생기면 앱별 프록시 규칙에서 해당 앱이 제외되었는지 확인하세요.
- ✅ 규칙 모드가 실패하면 잠시 전역 모드로 비교한 뒤 누락된 규칙을 찾으세요.
- ✅ DNS나 규칙을 변경한 뒤 기존 해석 캐시를 정리하고 연결을 다시 구성하세요.
- ❌ 시스템 네트워크를 동시에 제어하는 클라이언트를 여러 개 설치하고 활성화하지 마세요.
브라우저의 보안 DNS가 클라이언트가 예상한 해석 경로를 우회할 수도 있습니다. 시스템 프록시는 정상인데 브라우저 결과만 이상하다면 브라우저에서 별도의 DNS 제공업체를 사용하도록 설정했는지 확인하세요. 가상 네트워크 어댑터 모드를 사용할 때는 라우팅 테이블을 현재 클라이언트가 관리하는지도 확인해야 합니다. 다른 네트워크 도구가 기본 경로를 다시 변경하지 않도록 주의하세요.
위 점검을 마친 뒤에도 연결되지 않는다면 클라이언트의 오류 유형, 사용 플랫폼, 선택한 회선과 문제가 발생한 상황을 저장한 뒤 사이트 내 지원 채널로 제출하세요. 전체 구독 링크나 계정 인증 정보를 공개적으로 보내지 마세요. 명확한 환경 정보가 있으면 지원 담당자가 계정 상태, 회선 문제와 로컬 설정 문제를 구분하는 데 도움이 됩니다.