이 VPN 초보 용어 가이드는 클라이언트 화면에 자주 나오는 개념부터 살펴봅니다. 구독은 설정을 제공하고, 노드는 연결 지점을 나타내며, 프로토콜은 통신 방식을 정하고, 분할 라우팅은 요청이 어떤 경로로 갈지 결정합니다. 서로 같은 기능이 아닙니다. 각 항목의 역할을 파악한 뒤 설정 가져오기, 연결 상태, 실제 접속 결과를 확인하면 모든 문제를 ‘노드 문제’로 단정하는 일을 피할 수 있습니다.
용어 빠른 정리: 계정부터 접속 요청까지
일상에서 VPN은 시스템 수준의 가상 사설망을 뜻하기도 하고, 국제 회선을 제공하는 프록시 서비스를 통칭하기도 합니다. 이름이 비슷해도 구현 방식은 다를 수 있습니다. 어떤 트래픽이 실제로 처리되는지 확인하려면 앱 이름이나 연결 아이콘만 볼 것이 아니라 시스템 프록시, 터널 인터페이스, 라우팅 설정을 살펴봐야 합니다.
| 용어 | 실제 의미 | 혼동하기 쉬운 점 |
|---|---|---|
| 요금제 구독 | 계정으로 구매한 서비스와 데이터 제공 혜택입니다. | 설정을 가져올 때 사용하는 구독 링크와는 다릅니다. |
| 구독 링크 | 클라이언트가 노드나 설정을 가져오는 주소이며, 인증 정보가 포함될 수 있습니다. | 일반적인 공식 사이트 주소나 공개 공유 링크가 아닙니다. |
| 노드 | 서버 주소, 포트, 인증 정보 등이 포함된 연결 설정입니다. | 표시된 지역만으로 실제 데이터 전송 경로를 모두 알 수는 없습니다. |
| 프로토콜 | 클라이언트와 서버가 따르는 통신 규칙입니다. | 프로토콜 이름만으로 회선 품질이나 속도를 보장할 수는 없습니다. |
| 정책 그룹 | 규칙에서 사용하는 노드 또는 처리 방식의 모음입니다. | 한 그룹을 바꿔도 다른 그룹의 선택까지 바뀌지는 않을 수 있습니다. |
| 분할 라우팅 규칙 | 도메인, 주소 또는 기타 조건에 따라 요청 처리 방식을 정합니다. | 규칙 모드를 사용해도 모든 해외 사이트에 프록시가 자동 적용되는 것은 아닙니다. |
| 시스템 프록시 | 시스템 프록시 설정을 따르는 앱에 프록시 연결 지점을 제공합니다. | 기기의 모든 앱이 프록시를 사용하게 되는 것은 아닙니다. |
| TUN 모드 | 가상 네트워크 인터페이스로 트래픽을 받아 처리합니다. | 실제 적용 범위는 권한, 라우팅, 제외 설정에 따라 달라집니다. |
| DNS | 도메인 이름을 네트워크 주소로 변환하는 조회 방식입니다. | 웹 트래픽이 프록시를 거친다고 해서 DNS 조회 요청까지 프록시를 거치는 것은 아닙니다. |
웹페이지에 접속할 때는 보통 여러 단계가 이어집니다. 앱이 요청을 보내면 시스템이나 클라이언트가 도메인을 조회하고, 규칙에 따라 직결 또는 프록시를 선택합니다. 프록시 요청은 노드를 거쳐 대상 사이트에 도달합니다. 이는 이해를 돕기 위한 단순화된 흐름이며, 캐시와 원격 DNS 조회, 클라이언트 코어에 따라 실제 처리 순서는 달라질 수 있습니다.
구독 링크와 클라이언트 설정 가져오기
‘구독’은 의미가 혼동되기 쉬운 용어입니다. 요금제에서 말하는 구독은 결제 관계를 뜻하지만, 클라이언트의 구독은 보통 업데이트할 수 있는 설정 소스를 가리킵니다. 링크에는 노드만 들어 있을 수도 있고 정책 그룹, 규칙, DNS 설정이 포함될 수도 있습니다. 가져오기에 성공했다는 것은 클라이언트가 내용을 읽었다는 뜻일 뿐, 모든 회선이 정상 작동한다는 의미는 아닙니다.
클라이언트마다 지원하는 형식은 다릅니다. 같은 링크라도 노드 목록을 반환할 수 있고 특정 코어용 설정 파일을 제공할 수도 있습니다. 파일 확장자만 보고 호환성을 판단하지 마세요. 인증 정보가 포함된 링크를 출처가 불분명한 사이트에 제출해 형식을 변환하는 것도 피해야 합니다.
- 서비스 계정 페이지에서 현재 클라이언트에 맞는 설정을 받고, 사용 플랫폼과 가져오기 방법을 확인합니다.
- 클라이언트에서 구독, 설정 또는 가져오기 메뉴를 찾습니다. 링크를 붙여 넣고 업데이트한 다음 노드와 설정 이름이 표시되는지 확인합니다.
- 가져온 설정의 모드, 정책 그룹, DNS 설정을 확인합니다. 자동 선택 그룹이 있다면 어떤 노드를 참조하는지도 살펴봅니다.
- 노드를 선택하고 필요한 트래픽 처리 방식을 활성화한 뒤 대상 사이트에 접속해 확인합니다. 연결 버튼이 켜졌는지만 확인해서는 안 됩니다.
- 업데이트에 실패하면 다운로드, 인증, 형식 오류 중 무엇인지 먼저 확인한 뒤 네트워크, 링크 유효성, 코어 호환성을 각각 점검합니다.
구독 링크는 계정 인증 정보처럼 안전하게 보관해야 합니다. 스크린샷, 공개 문의 게시물, 공유 문서에는 전체 주소와 토큰을 가리세요. 유출된 경우 서비스의 재설정 기능을 이용하거나 계정 지원 채널에 문의하세요.
‘구독 업데이트’와 ‘규칙 업데이트’도 구분해야 합니다. 설정에 따라 규칙이 구독과 함께 전달되기도 하고, 별도의 규칙 리소스를 참조하기도 합니다. 노드는 새로고침됐는데 접속 경로가 그대로라면 규칙 리소스가 업데이트되지 않았거나 앱이 기존 연결을 계속 사용 중일 수 있습니다.
노드, IEPL 전용 회선, 중계와 직결
노드는 클라이언트에서 선택할 수 있는 연결 설정이며, 반드시 별도의 물리 서버 한 대를 뜻하지는 않습니다. 여러 이름이 같은 진입점을 공유할 수 있고, 진입 지역과 출구 지역이 다를 수도 있습니다. 사이트에는 보통 출구 주소가 표시되므로 지역별 접속 문제는 노드 이름만 볼 것이 아니라 출구와 사이트 자체의 판정 기준을 함께 확인해야 합니다.
직결과 중계는 데이터 전송 경로를 설명합니다
회선에서 직결은 보통 클라이언트가 해외 서비스 진입점에 직접 연결하는 방식입니다. 중계는 먼저 중계 지점에 연결한 뒤 트래픽을 출구로 전달합니다. 중계가 특정 구간의 라우팅을 개선할 수도 있지만, 경유 구간이나 혼잡을 늘릴 수도 있습니다. 중간 전달 지점이 하나 더 있다고 해서 반드시 느리거나 안정적이지 않다고 단정할 수는 없습니다.
규칙에서 말하는 ‘직결’은 또 다른 개념입니다. 대상 요청이 프록시 출구를 거치지 않는다는 뜻입니다. 이 용어를 볼 때는 서비스 회선의 경로를 설명하는지, 특정 요청에 대한 클라이언트의 처리 결과를 뜻하는지 먼저 확인해야 합니다.
IEPL이라고 해서 전체 접속 구간이 전용으로 보장되는 것은 아닙니다
IEPL은 일반적으로 국제 이더넷 전용 회선을 뜻합니다. 서비스 업체가 IEPL 회선이라고 안내하더라도 진입점과 출구 사이의 일부 구간에만 적용될 수 있습니다. 기기에서 진입점까지, 출구에서 대상 사이트까지는 각각 별도의 네트워크 조건에 영향을 받습니다. IEPL은 애플리케이션 계층 프로토콜과는 다른 개념이며, 이름만으로 낮은 지연 시간, 고정 대역폭, 스트리밍 서비스 이용 가능성을 보장한다고 볼 수 없습니다.
선택 기준: 먼저 대상 사이트에 접속할 수 있는지, 이용 시간대에 안정적인지 확인한 뒤 회선 표기를 살펴보세요. 지역, 전송 경로, 프로토콜은 각각 구분해서 이해해야 합니다. ‘전용 회선’이나 ‘직결’이라는 이름만으로 전체 이용 환경을 판단할 수는 없습니다.
프로토콜 이름과 클라이언트 코어 호환성
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC는 프록시 클라이언트 설정에서 볼 수 있지만 서로 마음대로 바꿔 쓸 수 있는 옵션은 아닙니다. 서버가 요구하는 인증, 암호화, 전송, 보안 계층 매개변수가 클라이언트 설정과 일치해야 합니다. 프로토콜 이름을 바꾼다고 기존 노드가 다른 프로토콜로 변환되지는 않습니다.
- Shadowsocks: 암호화 프록시 프로토콜 계열에 속합니다. 클라이언트는 서버에서 사용하는 구체적인 암호화 방식을 지원해야 합니다. ‘Shadowsocks 지원’ 여부만 확인하고 모든 설정이 호환된다고 판단해서는 안 됩니다.
- VMess와 VLESS: 서로 다른 프로토콜입니다. VLESS 자체는 전송 암호화를 제공하지 않으므로 적절한 보안 계층과 함께 사용하는 경우가 많습니다. 사용자 인증과 연결 암호화는 별개의 개념입니다.
- Trojan: 일반적으로 TLS 연결을 통해 프록시 통신을 전달합니다. 인증서 검증과 서버 이름 등의 설정이 연결에 영향을 줄 수 있으므로, 인증서 검증을 끄는 것을 일반적인 해결책으로 삼아서는 안 됩니다.
- Hysteria2와 TUIC: 둘 다 QUIC 기반 방식이며 UDP에 의존합니다. 현재 네트워크에서 UDP가 제한되면 연결이 성립하지 않을 수 있습니다. 그렇다고 계정에 문제가 있다는 뜻은 아닙니다.
앱 화면은 인터페이스 역할을 하고, 실제 설정 해석과 연결은 코어가 담당합니다. 같은 앱도 버전에 따라 지원 범위가 다를 수 있습니다. ‘지원하지 않는 프로토콜’이나 ‘알 수 없는 필드’ 오류가 뜨면 회선 문제를 의심하기 전에 코어와 설정 형식의 호환성을 먼저 확인하세요.
여기서는 일반적인 기술 개념을 설명하며 VPNPast가 위의 모든 프로토콜이나 임의의 서드파티 클라이언트 설정을 제공한다는 뜻은 아닙니다. 실제 사용 가능한 방식은 계정의 다운로드 메뉴, 설정 안내, 클라이언트 지원 여부를 기준으로 확인하세요.
분할 라우팅, 규칙 모드, 전역 모드
분할 라우팅은 조건에 따라 요청을 서로 다른 경로로 보내는 방식입니다. 대표적인 처리 결과로는 직결, 특정 프록시 정책 그룹으로 전달, 연결 거부가 있습니다. 규칙은 도메인, 대상 주소, 프로세스 등의 정보를 기준으로 삼을 수 있지만, 어떤 조건을 사용할 수 있는지는 클라이언트 코어와 운영체제 권한에 따라 달라집니다.
많은 클라이언트는 규칙을 순서대로 확인하고, 먼저 일치하는 규칙에 따라 요청을 처리합니다. 일치하는 규칙이 없으면 최종 처리 항목으로 넘어갑니다. 포괄적인 규칙을 구체적인 규칙보다 앞에 두면 뒤의 규칙이 적용되지 않을 수 있습니다. 규칙을 수정할 때는 현재 코어의 문법을 확인하고 다른 클라이언트의 규칙을 그대로 붙여 넣지 마세요.
전역 모드라고 해서 기기 전체의 트래픽을 처리하는 것은 아닙니다
규칙 모드는 설정에 따라 요청의 경로를 정합니다. 전역 모드는 일반적으로 클라이언트에 들어온 요청을 전역 정책에 따라 처리합니다. 여기서 중요한 점은 ‘클라이언트에 들어온 요청’이라는 것입니다. 시스템 프록시를 따르지 않는 앱의 요청은 프록시 코어에 아예 전달되지 않을 수 있어, 전역 모드로 바꿔도 결과가 달라지지 않을 수 있습니다.
TUN 모드는 처리 범위를 넓힐 수 있지만 라우팅, 권한, 제외 설정의 영향을 받습니다. 모바일 기기에 시스템 VPN 표시가 나타나는 것은 보통 앱이 시스템 터널 인터페이스를 사용한다는 뜻이며, 이것만으로 내부에서 어떤 프로토콜을 사용하는지 단정할 수는 없습니다.
- ✅ 웹사이트는 접속되지만 특정 앱은 안 될 때: 먼저 해당 앱이 시스템 프록시를 따르는지, 또는 터널을 통한 트래픽 처리가 필요한지 확인하세요.
- ✅ 노드를 바꿔도 출구가 그대로일 때: 첫 화면에 표시된 노드만 바꾸지 말고 대상 요청에 적용된 정책 그룹을 확인하세요.
- ✅ 전역 모드는 작동하지만 규칙 모드는 실패할 때: 적용된 규칙, 최종 처리 항목, DNS 결과를 확인해 설정 문제의 범위를 좁히세요.
- ❌ 노드, DNS, 규칙, 코어를 한꺼번에 변경하기: 변수가 뒤섞여 원인을 파악하기 어려워집니다. 원래대로 되돌아가더라도 무엇이 해결했는지 알기 어렵습니다.
DNS 누출과 플랫폼별 차이
DNS 누출은 개인정보 보호나 라우팅 정책에 따라 처리되어야 할 DNS 조회 요청이 예상하지 못한 경로나 DNS 서버를 통해 전송되는 현상입니다. 웹사이트에 프록시 주소가 표시된다고 해서 DNS 요청도 같은 경로를 따랐다고 볼 수는 없습니다. 반대로 검사 페이지에 특정 DNS 서버의 지역이 표시되는 것만으로 누출을 단정할 수도 없습니다. 해당 서버에 실제로 어떤 경로로 접속했는지 확인해야 합니다.
브라우저의 암호화 DNS, 시스템 DNS 서비스, 클라이언트 내장 DNS, 캐시가 동시에 작동할 수 있습니다. 점검할 때는 클라이언트의 DNS 처리 범위와 브라우저가 의도한 설정을 우회하는지 확인하세요. 암호화 DNS는 DNS 서버까지의 조회 전송을 보호하지만 DNS 요청과 웹 요청이 자동으로 같은 출구를 사용하게 만들지는 않습니다.
Windows와 macOS에서는 시스템 프록시와 가상 인터페이스 권한을 구분해야 합니다. iOS와 Android는 보통 운영체제가 제공하는 터널 인터페이스로 트래픽을 처리하며, 앱별 분할 라우팅 지원 여부는 운영체제와 클라이언트에 따라 다릅니다. Linux에서는 데스크톱 프록시, 환경 변수, 시스템 서비스, 라우팅 설정이 관련될 수 있습니다. 명령줄 도구가 데스크톱 브라우저의 설정을 그대로 사용한다고 단정할 수는 없습니다.
따라서 기기를 바꿀 때 다른 플랫폼의 설정 절차를 그대로 따라 하지 마세요. VPNPast는 Windows, macOS, iOS, Android, Linux를 지원합니다. 플랫폼별 설정은 사용 가이드에서 확인하고, 클라이언트는 계정 다운로드 메뉴에서 받으세요.
용어를 문제 해결 순서로 연결하기
문제가 생기면 먼저 증상을 구체적으로 설명하고 어느 단계에서 발생하는지 확인하세요. 노드가 보이지 않는다면 구독 다운로드와 설정 형식부터 살펴봅니다. 노드는 있지만 연결되지 않는다면 인증, 프로토콜, 네트워크 연결 상태를 확인합니다. 연결은 되지만 접속할 수 없다면 분할 라우팅, DNS, 출구, 대상 사이트의 제한을 이어서 점검하세요. 연결 테스트와 실제 서비스 접속은 서로 다른 요청을 사용할 수 있으므로 같은 결과로 볼 수 없습니다.
- 설정 출처 확인: 올바른 계정의 설정을 가져왔는지, 현재 클라이언트에 맞는 형식인지 확인하세요. 문의할 때 인증 정보는 공개하지 마세요.
- 요청 경로 확인: 클라이언트 연결 기록에서 대상, 적용 규칙, 정책 그룹을 확인하고 개인정보가 드러나지 않도록 가리세요.
- 한 번에 한 항목만 변경: 먼저 같은 정책 그룹의 노드를 바꾸고, 모드나 DNS 설정은 따로 검증하세요. 변경할 때마다 결과를 기록합니다.
- 실제 이용 환경에서 확인: 필요한 웹사이트나 앱을 열어 로그인, 콘텐츠 로딩, 연결 유지 여부를 확인하세요. 테스트 아이콘만 보고 판단하지 마세요.
핵심 정리: 구독은 ‘설정을 어디서 가져오는가’, 노드는 ‘어디에 연결하는가’, 프로토콜은 ‘어떻게 통신하는가’, 분할 라우팅은 ‘요청이 어느 경로로 가는가’를 결정합니다. 먼저 문제가 어느 단계에 속하는지 파악한 뒤 해당 설정을 조정하는 편이 클라이언트를 반복해서 재설치하는 것보다 효과적입니다.
기술 설정과 별도로 요금제의 데이터 제공 조건과 개인정보 보호 정책도 확인해야 합니다. VPNPast는 로그를 저장하지 않으며, 이메일 주소 없이 사용자 이름과 비밀번호만으로 계정을 만들 수 있습니다. 동시 접속 기기 수에는 제한이 없고 14일 환불 보장을 제공합니다. 이러한 서비스 조건이 기기의 권한 관리나 대상 사이트 자체의 접속 정책을 대신하는 것은 아닙니다.