VPN 초보 용어 가이드: 구독, 노드, 회선, 프로토콜, 트래픽 분할

이 VPN 초보 용어 가이드는 구독, 노드, 회선, 프로토콜, 트래픽 분할부터 설명합니다. 먼저 서로의 관계를 살펴보세요. 구독은 설정 정보를 제공하고, 클라이언트는 그 정보를 불러옵니다. 노드는 연결 대상, 회선은 데이터가 지나는 경로, 프로토콜은 통신 방식이며, 트래픽 분할은 요청을 어느 경로로 보낼지 결정합니다.

이 용어들을 익히는 목적은 기술 목록을 외우는 데 있지 않습니다. ‘가져오기는 성공했지만 접속할 수 없음’, ‘웹페이지는 열리는데 앱은 작동하지 않음’ 같은 상황에서 어느 부분을 확인해야 할지 파악하는 데 있습니다. 먼저 화면에 표시된 용어를 살펴본 뒤, 실제로 적용할 수 있는 사용 단계로 이어가겠습니다.

구독 링크와 유료 구독: 이름은 같아도 서로 다른 개념

유료 구독은 결제 관계로, 계정에서 이용할 수 있는 서비스와 데이터 사용량을 정합니다. 구독 링크는 클라이언트가 설정 정보를 가져오는 경로로, 일반적으로 노드 매개변수가 포함되며 정책 그룹, 트래픽 분할 규칙, DNS 설정이 들어갈 수도 있습니다. 결제를 마쳤다고 설정이 클라이언트에 자동으로 추가되는 것은 아닙니다. 링크를 복사했다고 연결이 시작되는 것도 아닙니다.

호환되는 클라이언트에 구독을 가져오면 클라이언트가 링크의 내용을 요청해 설정을 저장합니다. 이후 ‘구독 업데이트’를 누르면 보통 노드와 규칙을 새로고침하며, 결제를 갱신하는 것은 아닙니다. 계정 만료, 데이터 소진, 링크 재설정, 현재 네트워크에서 설정 주소에 접속할 수 없는 상황 등이 업데이트 실패의 원인일 수 있으니 각각 확인하세요.

구독 링크를 공개 게시판에 함부로 올려서는 안 됩니다. 링크에 계정을 식별하는 인증 정보가 포함될 수 있으며, 링크를 얻은 사람이 해당 설정을 사용할 수도 있습니다. 문제를 확인할 때는 전체 링크와 토큰을 가리고, 이미 공개했다면 먼저 관리 페이지에서 재설정 기능을 제공하는지 확인한 뒤 다시 가져오세요.

‘가져오기 성공’은 클라이언트가 설정을 받아들였다는 뜻일 뿐입니다. 연결이 실제로 설정되는지, 대상 앱의 트래픽이 프록시를 거치는지, 웹사이트에 접속할 수 있는지는 별도로 확인해야 합니다.

노드, 지역, 출구: 목록에서 실제로 선택하는 항목

노드는 클라이언트가 연결하는 서버의 접속 지점 또는 설정 항목입니다. 노드 이름에 표시된 지역은 보통 출구 위치를 알려주지만, 이름 자체가 측정 결과는 아닙니다. 접속 지점은 가까운 네트워크에 있고 중계를 거쳐 다른 지역에서 대상 웹사이트에 접속할 수도 있습니다. 따라서 접속 지점의 주소와 웹사이트에 표시되는 출구 주소가 다를 수 있습니다.

출구 IP는 대상 웹사이트에서 확인되는 네트워크의 출처입니다. 웹사이트에 표시되는 지역 콘텐츠에 영향을 줄 수는 있지만, 계정 자격, 결제 지역, 플랫폼 이용 허가를 단독으로 결정하지는 않습니다. 특정 지역 노드로 바꿔도 계정 지역까지 달라지는 것은 아니며, 플랫폼을 반드시 이용할 수 있다고 판단할 수도 없습니다.

노드 옆의 지연 시간 테스트는 대개 특정 탐색 요청의 왕복 시간을 측정합니다. 클라이언트마다 테스트 주소가 다를 수 있고 연결 경로의 일부만 확인할 수도 있습니다. 응답이 표시되면 후보를 고르는 참고 자료가 될 수 있지만, 다운로드 속도로 환산할 수는 없으며 장시간 연결이 안정적이라는 증거도 아닙니다.

IEPL 전용 회선, 중계, 직결: 차이는 경로에 있습니다

직결은 일반적으로 클라이언트가 서비스 제공업체가 마련한 중계 지점을 추가로 거치지 않고 서버에 직접 연결하는 것을 뜻합니다. 여기서 ‘직접’은 연결 구조를 설명하는 말이지, 지리적으로 가장 가까운 경로라는 뜻은 아닙니다. 실제 트래픽은 여전히 통신사 네트워크를 거치며, 국제망의 혼잡이나 경로 변경이 사용 환경에 영향을 줄 수 있습니다.

중계는 클라이언트와 출구 사이에 전달 단계를 추가하는 방식입니다. 접속 지점에 도달하기 쉬워질 수도 있지만 새로운 병목이 생길 수도 있습니다. 중계 회선이 적합한지는 이름에 ‘최적화’가 들어 있는지만 볼 것이 아니라 실제 사용 중 연결 상태, 지속 전송, 장애 복구를 확인해야 합니다.

IEPL은 국제 이더넷 전용 회선으로, 프록시 프로토콜이 아닌 네트워크 전송 서비스입니다. IEPL이라고 표시된 회선은 일반적으로 서비스 제공업체가 전송 경로의 일부에 이 전용 회선을 사용한다는 의미입니다. 현지 기기에서 대상 웹사이트까지 모든 구간이 전용 회선으로 연결된다는 뜻은 아닙니다. 현지 무선 네트워크, 접속 통신사, 출구에서 대상 웹사이트까지의 경로도 중요합니다.

따라서 회선 유형과 프로토콜은 구분해서 살펴봐야 합니다. 같은 프로토콜도 서로 다른 경로에서 작동할 수 있고, 같은 유형의 경로에 서로 다른 프로토콜을 사용할 수도 있습니다. 비교할 때는 기기, 네트워크, 대상 앱을 가능한 한 동일하게 유지하고 연결이 끊기거나 다시 연결되는지 관찰하세요.

Shadowsocks, VMess, Trojan, VLESS: 프로토콜은 속도 순위가 아닙니다

프로토콜은 클라이언트와 서버가 데이터를 주고받는 방식을 정합니다. 특정 프로토콜을 지원하더라도 모든 설정 형식, 전송 방식, 확장 기능을 지원하는 것은 아닙니다. 클라이언트에서 사용하는 코어와 버전도 호환성에 영향을 줍니다. 아래 내용은 개념 설명이며 VPN37이 모든 프로토콜을 제공한다는 뜻은 아닙니다.

• Shadowsocks: 앱 트래픽을 전달할 때 자주 쓰이는 암호화 프록시 프로토콜입니다. 클라이언트와 서버에서 호환되는 암호화 방식과 매개변수를 사용해야 합니다.
• VMess: 인증과 암호화를 제공하는 프록시 프로토콜로, 관련 프록시 코어에서 자주 사용됩니다. 일부 설정은 시스템 시간에 영향을 받으므로 기기 시간이 맞지 않는다면 확인해 볼 필요가 있습니다.
• Trojan: 일반적으로 TLS를 사용해 암호화 연결을 설정하므로 인증서 검증과 서버 이름 설정이 중요합니다. 연결에 실패하더라도 인증서 검증을 끄는 것을 일반적인 해결책으로 삼아서는 안 됩니다.
• VLESS: 자체적으로 데이터를 암호화하지 않으며 보통 TLS와 같은 보안 전송 방식을 함께 사용합니다. 이름만 보고 통신이 암호화되었다고 단정할 수 없으며, 전체 설정을 확인하지 않고 보안성을 판단해서도 안 됩니다.
• Hysteria2와 TUIC: QUIC 기반 프록시 방식으로 UDP 통신을 사용합니다. 현재 네트워크에서 UDP를 제한하면 사용 가능 여부에 영향을 줄 수 있으며, QUIC을 사용한다는 이유만으로 반드시 더 빠르다고 단정할 수 없습니다.

초보자는 서비스 안내에 명시된 호환 클라이언트와 설정 형식을 우선 사용하세요. ‘가장 강력한 프로토콜’을 찾아다닐 필요는 없습니다. 프로토콜을 바꾸면 전송 방식과 연결 동작도 함께 달라질 수 있으므로, 문제를 확인할 때 한 번에 한 가지 요소만 변경해야 원인을 찾기 쉽습니다.

트래픽 분할, 전역 모드, TUN: 어떤 트래픽이 연결에 들어가나요?

규칙 모드는 도메인, 대상 주소, 프로세스 등의 조건에 따라 처리 방식을 선택합니다. 일반적으로 직결하거나 프록시 정책 그룹에 전달하거나 연결을 차단합니다. 규칙은 순서대로 일치 여부를 확인하는 경우가 많아 앞쪽 규칙이 뒤쪽 규칙보다 먼저 적용될 수 있습니다. 따라서 규칙을 추가했다고 해서 실제 요청에 적용되었다고 볼 수는 없습니다.

전역 모드는 일반적으로 프록시 코어에 들어온 트래픽을 하나의 정책으로 처리합니다. 여기서 핵심은 ‘프록시 코어에 들어온’ 트래픽입니다. 앱이 시스템 프록시를 거치지 않으면 전역 모드로 바꿔도 해당 앱의 트래픽을 처리하지 못할 수 있습니다. 브라우저에서는 웹페이지가 열리는데 명령줄 도구는 연결에 실패한다면, 도구가 시스템 프록시 설정을 읽지 않는 것일 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스로 시스템 트래픽을 받은 뒤 클라이언트가 처리합니다. 일반적으로 시스템 프록시 설정만 사용하는 것보다 더 많은 트래픽을 처리할 수 있지만, 라우팅, 권한, 제외 목록, 클라이언트 구현에 따라 달라집니다. TUN은 전역 모드와 같은 뜻이 아닙니다. TUN은 트래픽이 클라이언트에 들어오는 방식을, 전역 모드는 들어온 트래픽에 어떤 정책을 적용하는지를 가리킵니다.

Windows와 macOS 클라이언트는 시스템 프록시와 TUN을 함께 제공할 수 있습니다. 모바일 플랫폼은 시스템 VPN 인터페이스로 트래픽을 처리하는 경우가 많습니다. 이때 VPN 아이콘은 시스템 네트워크 인터페이스가 활성화되었다는 뜻일 뿐, 모든 앱의 트래픽이 프록시를 거친다는 의미는 아닙니다. Linux에서는 데스크톱 앱과 명령줄 도구가 서로 다른 프록시 설정을 사용할 수도 있으므로 앱별로 확인하세요.

DNS 누출, 출구 확인, 연결 결과

DNS는 도메인 이름을 주소로 변환합니다. 웹페이지 콘텐츠가 프록시를 거치더라도 도메인 조회는 다른 네트워크 경로를 사용할 수 있습니다. 조회 요청이 예상한 경로를 따르지 않고 현지 네트워크나 예상하지 못한 DNS 서비스에서 처리되면 일반적으로 DNS 누출이라고 합니다. 예상한 경로에서 벗어났는지는 클라이언트 모드와 규칙을 함께 살펴봐야 합니다.

암호화 DNS는 기기와 DNS 서비스 사이의 조회 전송을 보호할 수 있지만, 조회 요청이 자동으로 프록시를 거친다는 뜻은 아닙니다. DNS 서비스 자체는 여전히 조회 내용을 처리합니다. 일부 클라이언트는 Fake-IP로 가상 주소를 반환한 뒤 연결 시 도메인 이름을 복원합니다. 이는 트래픽 분할 구현 방식이며 웹사이트의 실제 주소가 해당 가상 주소로 바뀐다는 뜻은 아닙니다.

확인할 때는 출구 지역, DNS 조회 경로, 실제 앱 동작을 각각 살펴보세요. 테스트 페이지는 해당 페이지에서 확인할 수 있는 요청만 보여주므로 모든 앱을 대표하지 않습니다. 브라우저의 자체 보안 DNS, 기존 연결, 캐시 때문에 결과가 클라이언트 설정과 다르게 보일 수 있습니다. 노드를 계속 바꾸기보다 로그와 함께 확인하세요.

클라이언트 설치부터 확인까지: 순서대로 설정하기

1. 접속 경로와 호환성을 확인합니다. 사용자 패널에서 클라이언트를 다운로드한 뒤 플랫폼과 지원되는 설정 형식을 확인하세요. 호환되지 않는 소프트웨어에 임의의 구독 링크를 입력하지 마세요.
2. 설정을 가져오고 업데이트합니다. 클라이언트의 구독 메뉴를 사용해 노드와 정책 그룹이 생성되는지 확인하세요. 업데이트에 실패하면 먼저 계정 상태, 링크 유효성, 네트워크 접속 가능 여부를 확인합니다.
3. 노드와 모드를 선택합니다. 먼저 용도에 맞는 지역을 고른 다음 시스템 프록시나 TUN이 활성화되어 있는지 확인하세요. 처음에는 설정에 포함된 규칙을 그대로 사용하고 출처가 불분명한 규칙을 여러 개 겹쳐 적용하지 않는 편이 좋습니다.
4. 실제 앱에서 확인합니다. 사용할 웹사이트나 도구를 열고 출구가 예상한 위치인지 확인한 뒤, 클라이언트 로그에서 해당 요청에 어떤 정책이 적용되었는지 살펴보세요.
5. 문제를 하나씩 확인합니다. 설정이 업데이트되지 않으면 구독을 확인하고, 노드에 연결되지 않으면 네트워크와 매개변수를 확인하세요. 특정 앱에서만 문제가 발생하면 트래픽 처리 방식, DNS, 해당 앱의 설정을 살펴보세요.

• ✅ 문제 확인용 스크린샷을 공유하기 전에 구독 링크, 토큰, 계정 인증 정보를 가리세요.
• ✅ 정상 작동이 확인된 설정을 따로 저장해 두고, 업데이트 후 문제가 생기면 변경 사항부터 비교하세요.
• ✅ 지원팀에 문의할 때는 ‘안 돼요’라고만 하지 말고 플랫폼, 클라이언트, 네트워크 환경, 오류 메시지를 함께 알려주세요.
• ❌ 인증서 검증을 끄거나 임의로 인증서를 설치하는 방법을 일반적인 해결책으로 사용하지 마세요.

데이터 사용량과 요금은 계정 정책을 별도로 확인하세요. VPN37의 월간 데이터는 가입일을 기준으로 매월 초기화되며, 데이터 팩은 소진될 때까지 사용할 수 있고 만료되지 않습니다. 동시 접속 기기 수에는 제한이 없지만, 요금제 데이터가 무제한이라는 뜻은 아닙니다. 계정은 이메일 주소 없이 사용자 이름과 비밀번호만으로 만들 수 있습니다. 자세한 요금제와 데이터 사용량은 요금제 및 데이터 안내에서, 이용 방법은 사용 가이드에서 확인하세요.