이 VPN 용어 총정리는 실제 사용 흐름을 따라 설명합니다. 구독은 설정을 클라이언트에 전달하고, 노드는 연결할 접속 지점을 정하며, 프로토콜은 통신 방식을 규정하고, 분할 터널링은 요청마다 경로를 선택합니다. 각 요소의 역할을 이해하면 ‘가져오기 성공’과 ‘접속 성공’을 구분할 수 있고, 연결 문제가 생겼을 때 관련 없는 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.
클라이언트와 구독·노드의 관계
클라이언트는 기기에서 연결, 노드 선택, 분할 터널링을 실행하는 소프트웨어입니다. 구독은 보통 서비스가 설정 정보를 제공하는 경로이며, 클라이언트가 이를 읽으면 사용할 수 있는 노드와 관련 매개변수를 가져옵니다. 노드는 서버 주소, 포트, 인증 정보, 프로토콜, 전송 설정 등이 포함된 구체적인 연결 정보입니다. 반드시 독립된 물리 서버 한 대에 대응하는 것은 아닙니다.
일상적으로 ‘VPN’은 네트워크 가속 도구를 통칭하는 말로 쓰이지만, 애플리케이션 계층 프록시와 시스템 수준 VPN 터널은 완전히 같지 않습니다. 일부 프록시 클라이언트는 시스템 VPN 인터페이스를 이용해 트래픽을 처리합니다. 그렇다고 원격 통신에 사용하는 프로토콜까지 전통적인 VPN 프로토콜이라는 뜻은 아닙니다. 어떤 범위의 트래픽이 처리되는지 확인하려면 앱 이름만 볼 것이 아니라 클라이언트가 실제로 트래픽을 처리하는 방식을 살펴봐야 합니다.
| 용어 | 실제 역할 | 이 정보만으로는 알 수 없는 점 |
|---|---|---|
| 클라이언트 | 설정을 읽고 연결과 규칙을 실행 | 설치가 끝났다고 사용할 수 있는 연결이 수립된 것은 아닙니다 |
| 구독 링크 | 설정 정보를 가져오고 업데이트 | 업데이트에 성공해도 모든 노드에 접속할 수 있는 것은 아닙니다 |
| 노드 | 구체적인 연결 매개변수 제공 | 지역 이름만으로 접속 지점과 출구가 모두 그 지역에 있다고 단정할 수 없습니다 |
| 프로토콜 | 클라이언트와 서버의 통신 방식 정의 | 프로토콜 이름만으로 회선 품질을 판단할 수 없습니다 |
| 분할 터널링 규칙 | 요청별로 프록시·직접 연결·차단 중 하나를 선택 | 규칙이 있다고 해서 모든 앱의 트래픽이 처리되는 것은 아닙니다 |
구독 링크와 클라이언트 가져오기
구독 링크는 일반적인 소개 페이지가 아닙니다. 계정 권한을 확인하는 인증 정보가 포함되는 경우가 많으며, 링크를 열면 노드 목록이나 클라이언트 설정이 반환됩니다. 웹페이지에서 링크가 열린다고 해서 현재 클라이언트가 반환된 형식을 지원하는 것은 아닙니다. 일부 클라이언트는 전체 설정을 읽고, 다른 클라이언트는 노드 공유 정보만 받아들입니다. 두 형식은 서로 바꿔 쓸 수 없습니다.
‘구독 업데이트’는 설정을 다시 가져오는 작업이지, 요금제를 갱신하거나 데이터 사용량을 초기화하는 작업이 아닙니다. 노드가 변경된 뒤에도 이전 설정에 작동하지 않는 주소가 남아 있을 수 있습니다. 반면 업데이트 요청 자체가 실패한다면 모든 회선을 사용할 수 없다고 단정하기 전에 설정을 가져오는 네트워크 경로, 링크 상태, 형식 호환성을 먼저 확인해야 합니다.
- 서비스 관리 화면에서 해당 클라이언트용 구독 링크를 확인하고, 먼저 플랫폼별 가져오기 안내를 읽습니다.
- 클라이언트의 구독 또는 설정 관리 메뉴에서 가져온 뒤 설정 이름과 노드 목록이 표시되는지 확인합니다.
- 해당 설정을 선택하고 연결을 활성화합니다. 필요에 따라 시스템 프록시 또는 터널을 통한 트래픽 처리를 켭니다.
- 대상 서비스에 접속한 다음 규칙 적용 여부와 출구 정보를 확인합니다. ‘가져오기 성공’만으로는 설정이 완료된 것이 아닙니다.
노드와 접속·출구 지역
접속 지점은 기기가 가장 먼저 연결하는 서비스 진입점이고, 출구는 대상 웹사이트에 표시되는 공인 IP 주소입니다. 두 지점은 서로 다른 지역에 있을 수 있습니다. 노드 이름에 표시된 지역은 보통 출구 위치를 안내하지만, 이름은 표시에 불과합니다. 실제 위치는 서비스 안내와 출구 확인 결과를 함께 살펴봐야 합니다.
같은 출구 지역이라도 접속 지점과 전송 경로는 다를 수 있습니다. 노드 이름에 표시된 지역이 가까운지만 비교해 연결을 선택해서는 안 됩니다. 클라이언트의 측정 결과가 대상 웹사이트 이용 경험 전체를 보여주는 것도 아닙니다. 측정은 노드까지의 일부 경로만 확인할 수 있으며, 웹페이지 이용에는 도메인 조회, 원격 응답, 연결 재사용, 앱 자체 처리 과정도 영향을 줍니다.
출구 IP의 지역 판별은 웹사이트가 사용하는 IP 주소 데이터베이스에 따라서도 달라집니다. 확인 페이지에 표시된 지역과 특정 플랫폼이 판단하는 지역이 서로 다른 경우도 흔합니다. 스트리밍이나 AI 서비스는 계정 지역, 결제 정보, 자체 정책을 함께 고려해 접근을 제한할 수 있으므로 출구를 바꾼다고 이용 자격이 보장되지는 않습니다. IP 확인으로 기본 출구 정보를 살펴볼 수 있지만, 최종적으로는 대상 서비스에 표시되는 안내를 따르세요.
전용 회선·중계·직접 연결의 차이
이 용어들은 클라이언트 프로토콜이 아니라 네트워크 경로를 설명합니다. 직접 연결은 일반적으로 기기가 공용 인터넷을 통해 해외 접속 지점에 연결하는 방식입니다. 중계는 먼저 한 접속 지점에 연결한 뒤, 그곳에서 다음 회선으로 트래픽을 전달하는 방식입니다. 여기서 말하는 ‘직접 연결 회선’과 규칙의 ‘직접 연결’ 동작은 의미가 다릅니다. 전자는 여전히 프록시 서비스를 사용할 수 있지만, 후자는 보통 선택된 프록시 노드를 거치지 않고 요청을 보내는 것을 뜻합니다.
IEPL은 보통 국제 이더넷 전용 회선을 가리키며, 통신사가 제공하는 지역 간 전용 전송 경로를 강조하는 용어입니다. 전체 접속 경로 중 일부 구간에만 사용될 수 있으며, 기기에서 접속 지점까지 또는 출구에서 대상 웹사이트까지의 경로 전체를 자동으로 포함하지는 않습니다. 전용 회선 구간이 정상이어도 로컬 네트워크나 대상 서비스 때문에 속도가 느려질 수 있습니다.
따라서 전용 회선이 곧 개인정보 보호 정책을 뜻하는 것은 아니며, 중계 방식이 반드시 더 나쁘거나 직접 연결이 항상 더 빠른 것도 아닙니다. 접속 지점의 위치, 전용 회선을 사용하는 구간, 현재 네트워크와의 적합성을 확인한 다음 평소 이용 시간대에 필요한 작업을 직접 테스트하세요. 이 글은 업계 용어를 설명하며, VPNVD가 여기 언급된 모든 회선이나 프로토콜을 제공한다는 뜻은 아닙니다. 실제 설정은 관리 화면과 서버 페이지의 안내를 확인하세요.
자주 쓰이는 프로토콜과 호환성
프로토콜은 통신하는 양쪽이 데이터를 어떤 방식으로 캡슐화하고 전송하며 검증할지 정합니다. 전송 방식, 암호화 설정, TLS 구성, 인증 매개변수는 서로 맞춰 사용해야 하는 경우가 많습니다. 노드가 어떤 프로토콜을 쓰는지만 알아서는 작동하는 설정을 직접 만들기 어렵습니다. 클라이언트에 해당 기능을 지원하는 코어가 없다면 노드 이름을 바꾸어도 호환성 문제는 해결되지 않습니다.
- Shadowsocks: 암호화 프록시 프로토콜입니다. 실제 보안성과 호환성은 사용 버전, 암호화 방식, 구현에 따라 달라지므로 약칭만으로 판단할 수 없습니다.
- VMess: V2Ray 생태계에서 자주 사용되며 자체 인증 및 데이터 보호 기능을 포함합니다. 연결에 실패하면 설정값뿐 아니라 기기의 시간이 정확한지도 확인해야 합니다.
- Trojan: 일반적으로 TLS를 사용해 전송을 보호합니다. 인증서 검증과 서버 이름 설정이 중요하므로 문제를 해결하려고 인증서 확인을 함부로 끄지 마세요.
- VLESS: 경량 프록시 프로토콜입니다. 자체적으로 완전한 전송 암호화를 제공하지 않으므로 설정의 TLS, REALITY 같은 보안 계층과 함께 이해해야 합니다.
- Hysteria2: QUIC 기반이며 하위 전송 계층으로 UDP를 사용합니다. UDP 제한, 혼잡 제어, 설정 호환성이 모두 연결 상태에 영향을 줄 수 있습니다.
- TUIC: QUIC 전송을 활용하는 프로토콜입니다. 실제 지원 여부는 클라이언트 구현에 따라 다르며, Hysteria2의 설정값을 그대로 함께 사용할 수는 없습니다.
TCP와 UDP는 전송 계층의 개념이지 ‘안전’과 ‘위험’을 구분하는 말이 아닙니다. UDP 기반 방식도 암호화로 보호할 수 있으며, UDP를 허용하는 환경이라고 해서 모든 앱에 적합한 것도 아닙니다. 연결되지 않는다면 먼저 현재 네트워크가 필요한 전송 방식을 허용하는지 확인한 뒤 클라이언트 버전과 전체 설정을 점검하세요.
분할 터널링·규칙 모드·글로벌 모드
분할 터널링은 조건에 따라 요청을 처리할 경로를 선택하는 방식입니다. 도메인, 대상 주소, 앱 프로세스, 지역 데이터베이스 등이 자주 쓰이는 조건이며, 프록시·직접 연결·차단 등이 대표적인 동작입니다. 규칙은 보통 클라이언트가 정한 순서대로 적용되지만, 도메인 조회 방식과 규칙 모음의 전개 방식, 코어 구현에 따라 실제 동작이 달라질 수 있습니다. 서로 다른 클라이언트의 규칙을 같은 것으로 간주해서는 안 됩니다.
규칙 모드에서는 조건에 맞는 요청마다 다른 경로를 사용하므로 로컬 서비스, 근거리 네트워크, 국제 회선 간 경계를 유지하기 좋습니다. 글로벌 모드는 보통 클라이언트가 처리하는 요청을 선택한 프록시 그룹으로 보내는 방식입니다. 규칙이 누락되었는지 임시로 확인할 때 유용하지만, 기기의 모든 트래픽이 반드시 프록시를 통과한다는 뜻은 아닙니다.
특히 ‘프록시 그룹’과 ‘노드’를 구분해야 합니다. 프록시 그룹은 선택을 위한 묶음으로, 노드를 직접 지정할 수도 있고 설정에 따라 자동으로 선택할 수도 있습니다. 글로벌 모드에서 자동 전환 중인 그룹을 선택하면 출구가 바뀔 수 있습니다. 연결을 계속 유지해야 하는 작업이라면 그룹의 선택 정책을 먼저 확인한 뒤 노드를 고정할지 결정하세요.
같은 노드에서 규칙 모드는 실패하지만 글로벌 모드는 성공한다면 규칙 적용 여부와 도메인 조회를 확인해 볼 만합니다. 두 모드 모두 실패한다면 트래픽 처리 범위, 노드 연결 상태, 대상 서비스의 제한을 이어서 점검하세요. 이 비교는 원인 범위를 좁히는 데 도움을 줄 뿐, 장애 원인을 바로 확정해 주지는 않습니다.
시스템 프록시·TUN과 플랫폼별 차이
시스템 프록시는 이 설정을 지원하는 앱에 프록시 접속 정보를 전달하는 방식이며, 일부 앱은 이를 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받은 뒤 클라이언트가 전달하는 방식입니다. TUN은 더 많은 앱의 트래픽을 처리할 수 있지만 라우팅, 제외 목록, 권한, 클라이언트 구현의 영향을 받습니다. 켠다고 해서 모든 문제가 자동으로 해결되는 것은 아닙니다.
Windows와 macOS 클라이언트에는 시스템 프록시와 TUN 설정이 각각 제공될 수 있습니다. 브라우저 확장 프로그램의 프록시는 일반적으로 해당 브라우저에만 적용되므로 데스크톱 앱까지 연결된 것은 아닙니다. Linux에서는 데스크톱 프록시 설정, 앱 환경 변수, 시스템 라우팅도 자주 관련됩니다. 터미널 프로그램이 프록시를 사용하는지는 별도로 확인해야 합니다.
Android와 iOS 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽 처리용 터널을 구성하는 경우가 많습니다. 앱별 분할 터널링, 백그라운드 연결 유지, 지원 프로토콜은 시스템 권한과 클라이언트 기능에 따라 달라집니다. 데스크톱에서 가져오기에 성공했다고 해서 모바일에서도 같은 형식이 지원된다고 단정할 수 없습니다. 클라이언트는 관리 화면의 다운로드 페이지에서 받은 뒤 해당 플랫폼 안내에 따라 설정하세요.
DNS 누출과 개인정보 보호의 범위
DNS는 도메인 이름을 IP 주소로 변환합니다. 일반적으로 DNS 누출은 보호된 경로를 따라야 할 DNS 조회 요청이 다른 경로로 전달되는 상황을 뜻합니다. 출구 IP가 바뀌었다는 사실만으로 DNS 요청도 같은 경로를 사용한다고 단정할 수는 없습니다. 브라우저의 암호화 DNS, 시스템 DNS 리졸버, 클라이언트의 DNS 정책이 각각 적용될 수 있습니다.
암호화 DNS는 DNS 서비스까지의 통신을 보호하지만, DNS 요청이 선택된 노드를 거친다는 뜻은 아닙니다. 일부 확인 페이지에 여러 DNS 서비스가 표시되더라도 개수만으로 누출 여부를 판단할 수 없습니다. 브라우저가 별도로 DNS를 조회하도록 설정되었는지, DNS 서비스가 어디에 속하는지, 예상한 경로가 무엇인지 함께 살펴봐야 합니다.
HTTPS는 앱과 대상 웹사이트 사이의 통신을 보호하고, 프록시나 터널은 별도의 연결 경로를 담당합니다. 서로 대신할 수 있는 기능이 아닙니다. 인증서 오류가 발생하면 민감한 정보를 입력하지 말고 기기 시간, 네트워크 인증 페이지, 인증서 체인을 점검하세요. 경고를 무시해 연결을 ‘복구’하려고 해서는 안 됩니다.
연결 오류 발생 시 점검 목록
문제 해결은 계층별로 진행하고, 한 번에 조건 하나만 바꾸며 변경 전후의 상태를 기록하세요. 프로토콜, 노드, DNS를 동시에 바꾸면 접속이 복구되더라도 원인을 알기 어려워 다음에도 처음부터 다시 시도해야 합니다.
- ✅ 프록시를 사용하지 않아도 기본 네트워크가 작동하는지 먼저 확인하고, 로컬 연결 끊김이나 공용 네트워크 접속 절차 미완료를 배제합니다.
- ✅ 구독 업데이트 여부, 설정 선택 여부, 요금제 상태를 확인합니다. 설정 가져오기와 노드 연결은 각각 따로 점검합니다.
- ✅ 시스템 프록시 또는 TUN이 해당 앱의 트래픽을 처리하는지 확인하고, 프록시 그룹이 실제로 예상한 노드를 가리키는지 살펴봅니다.
- ✅ 노드를 그대로 둔 상태에서 규칙 모드와 글로벌 모드를 비교한 다음 대상 요청에 어떤 규칙이 적용되었는지 확인합니다.
- ✅ 출구와 DNS 경로를 확인합니다. 문의할 때는 오류 메시지와 발생 상황을 남기고 인증 정보와 전체 구독 링크는 가리세요.
- ❌ 인증서 검증 끄기, 출처를 모르는 설정 가져오기, 여러 옵션을 반복해서 바꾸기를 일반적인 해결 방법으로 삼지 마세요.
마지막으로 다음 흐름을 기억하세요. 구독은 설정을 제공하고, 클라이언트는 설정을 실행하며, 노드는 서비스에 연결하고, 프로토콜은 통신을 전달하며, 규칙은 경로를 정합니다. 각 용어의 역할을 이해한 뒤 화면의 스위치와 안내를 살펴보면 어디에서 문제가 생겼는지 더 정확히 설명할 수 있습니다. 추가 설정 안내는 초보자 가이드에서 확인할 수 있습니다. 도움이 필요하면 고객 지원에 문의하면서 이미 점검한 내용을 알려주세요.