VPN 용어 정리: 노드, 회선 유형, 프로토콜, 글로벌·규칙 모드

구독, 노드, IEPL 전용 회선, 프로토콜, 분할 라우팅, 글로벌 모드와 규칙 모드. 초보자가 헷갈리기 쉬운 용어와 각각의 역할을 한눈에 정리했습니다.

구독을 가져온 뒤에도 노드와 규칙 모드를 선택해야 하는 이유는 무엇일까요? VPN 용어를 먼저 정리하면, 구독은 설정을 제공하고 노드는 연결 대상을 지정하며 회선은 데이터가 오가는 경로, 프로토콜은 통신 방식을 설명합니다. 분할 라우팅 규칙은 요청이 어느 경로로 전달될지 정합니다. 각각 담당하는 단계가 달라 서로 대신할 수 없습니다.

일상적인 대화에서는 프록시 구독과 시스템 VPN을 모두 VPN이라고 부르기도 하지만, 기술적으로는 범위가 다릅니다. 프록시 클라이언트는 시스템 프록시를 따르는 앱만 처리할 수도 있고, 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리할 수도 있습니다. 따라서 화면에 ‘연결됨’이라고 표시되어도 기기의 모든 요청이 같은 경로를 이용한다는 뜻은 아닙니다.

구독, 노드, 클라이언트는 각각 무엇일까요?

클라이언트는 설정을 읽고 연결을 수립하며 분할 라우팅을 처리하는 기기용 소프트웨어입니다. 노드는 보통 클라이언트에서 선택하는 연결 설정으로, 서버 주소와 포트, 인증 정보, 프로토콜 매개변수를 포함합니다. 노드 이름은 구분하기 위한 라벨일 뿐 실제 네트워크 경로 전체를 정확히 나타내지는 않습니다.

구독 링크는 노드 목록이나 전체 설정을 가져오는 경로입니다. 클라이언트가 링크를 읽어야 해당 내용을 가져올 수 있습니다. 링크 자체는 연결 성공을 보장하는 인증 정보도, 고정된 특정 회선도 아닙니다. 서버 측 설정이 바뀌면 새 주소나 규칙을 반영하도록 클라이언트에서 구독을 업데이트해야 할 수 있습니다.

설정 가져오기, 연결 대상, 실행 도구를 구분하세요
용어 역할 이것만으로는 알 수 없는 것
구독 링크 클라이언트에 노드 또는 설정 제공 요금제 유효 여부나 현재 연결 여부를 의미하지 않음
노드 연결 대상과 인증·프로토콜 매개변수 지정 이름만으로 물리적 위치나 실제 속도를 알 수 없음
클라이언트 연결, 프록시 진입점, 분할 라우팅 설정 실행 설치만으로 시스템 트래픽이 처리되는 것은 아님
정책 그룹 노드를 묶어 설정에 따라 수동 또는 자동으로 선택 자동 선택이 대상 웹사이트에 최적의 환경을 보장하지 않음

‘구독’은 요금제의 결제 관계를 뜻하기도 하므로 문맥에 따라 해석해야 합니다. ‘구독 업데이트’는 보통 설정을 새로고침한다는 뜻이지 갱신 결제를 뜻하지 않습니다. ‘구독 만료’는 계정 혜택이 종료된다는 뜻일 수 있습니다. 이런 안내를 보면 클라이언트의 업데이트 결과와 계정의 요금제 상태를 각각 확인하세요.

구독 링크에는 액세스 토큰이 포함되는 경우가 많으므로 인증 정보처럼 안전하게 보관하세요. 포럼이나 스크린샷에 공개하거나 출처가 불분명한 온라인 변환 도구에 입력하지 마세요. 유출이 의심되면 계정에서 제공하는 재설정 기능으로 링크를 변경하고 각 기기에서도 업데이트하세요. 기존 링크가 무효화되는 범위는 서비스 안내를 따릅니다.

IEPL 전용 회선, 중계, 직접 연결은 어떻게 다를까요?

직접 연결은 일반적으로 기기가 현지 통신사 네트워크를 통해 별도의 국내 중계 진입점을 거치지 않고 해외 서비스 진입점에 연결되는 방식입니다. 경로의 혼잡도와 국제 네트워크 연결 품질은 현지 네트워크와 통신사의 라우팅에 따라 달라집니다. 직접 연결이라고 해서 암호화되지 않는 것은 아닙니다. 암호화 방식은 연결 프로토콜과 설정에 따라 결정됩니다.

중계 연결은 연결 경로에 중계 서버를 추가해 기기가 먼저 진입점에 연결되고, 해당 진입점이 다음 서버로 트래픽을 전달하는 방식입니다. 달라지는 것은 경로의 구성입니다. 가까운 진입점이 일부 구간의 연결 환경을 개선할 수 있지만, 중계 노드의 부하와 대역폭, 이후 경로도 중요합니다. 진입점까지의 거리만으로 판단할 수는 없습니다.

IEPL은 보통 국제 이더넷 전용 회선을 뜻하며, 데이터를 전달하는 링크의 유형입니다. 서비스 제공업체가 일부 국제 구간의 트래픽을 이 전용 회선으로 전달할 수 있지만, 클라이언트에 표시된 ‘IEPL’이라는 이름만으로는 충분하지 않습니다. 회선 안내를 따로 확인해야 합니다. 기기에서 진입점까지, 출구에서 대상 웹사이트까지의 모든 구간이 전용 회선인 것은 아닙니다.

‘접속 지역’과 ‘출구 지역’도 구분해야 합니다. 전자는 기기가 연결되는 진입점의 위치이고, 후자는 일반적으로 대상 웹사이트에 표시되는 출발 네트워크의 위치입니다. 지역 라벨 하나가 두 위치를 모두 설명하지는 않을 수 있습니다. 웹사이트 접속 가능 여부는 계정 지역, 콘텐츠 이용 권한, 출구 주소 판별의 영향을 받을 수도 있습니다.

판단 기준: 회선 유형은 어떤 경로를 이용하는지, 프로토콜은 데이터를 어떻게 전달하는지를 설명합니다. 전용 회선이라는 이름만으로 속도 향상, 개인정보 보호 강화, 특정 웹사이트 지원을 단정할 수는 없습니다. 회선을 선택할 때는 실제 용도에 맞춰 전체 경로와 성능을 확인하세요.

Shadowsocks 등 프로토콜은 무엇을 결정할까요?

프로토콜은 클라이언트와 서버가 데이터를 인증하고 캡슐화해 전송하는 방식을 정합니다. 연결을 수립하려면 클라이언트가 해당 프로토콜과 세부 매개변수를 지원해야 합니다. 프로토콜 이름은 속도 등급이나 개인정보 보호 수준을 종합적으로 평가한 결과가 아닙니다. 구현 버전, 서버 설정, 네트워크 환경 모두 결과에 영향을 줍니다.

  • Shadowsocks: 암호화 프록시 프로토콜입니다. 클라이언트와 서버의 주소, 포트, 비밀번호, 암호화 방식이 일치해야 합니다. 구현 방식에 따라 확장 기능 지원 여부가 다를 수 있습니다.
  • VMess: 인증 및 암호화 메커니즘을 포함하는 프록시 프로토콜로, 여러 전송 방식과 함께 사용할 수 있습니다. 노드를 복사할 때 전송 매개변수를 누락하면 연결되지 않을 수 있습니다.
  • Trojan: 일반적으로 TLS를 기반으로 프록시 연결을 수립합니다. 인증서 검증, 서버 이름, 인증 매개변수를 올바르게 설정해야 합니다. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용해서는 안 됩니다.
  • VLESS: 경량 프록시 프로토콜입니다. 자체적으로 페이로드를 암호화하지 않으므로 보통 TLS나 다른 보안 전송 방식과 함께 사용합니다. 이름만 보고 전체 연결의 보호 방식을 판단할 수는 없습니다.
  • Hysteria2 및 TUIC: 둘 다 QUIC 기반 전송 방식을 사용하며 UDP 네트워크에 연결할 수 있어야 합니다. 네트워크에서 UDP가 제한되면 다른 연결 방식을 사용해야 할 수 있습니다.

위 내용은 업계에서 일반적으로 사용하는 프로토콜을 설명하며, VPNCG가 모든 프로토콜을 제공한다는 뜻은 아닙니다. 실제로 사용할 수 있는 설정은 계정에 제공된 구성과 클라이언트 지원 여부를 확인하세요. 가져오기 중 ‘지원하지 않는 유형’이 표시되면 노드가 비활성 상태라고 단정하기 전에 클라이언트 코어와 구독 형식을 확인하세요.

글로벌·규칙·직접 연결 모드, 어떻게 선택할까요?

규칙 모드는 도메인, 대상 주소, 앱 등의 조건에 따라 요청을 프록시, 직접 연결, 차단 등의 동작으로 분류합니다. 클라이언트마다 지원하는 조건이 다르며, 규칙은 순서대로 적용되는 경우가 많습니다. 따라서 앞에 있는 포괄적인 규칙이 뒤의 세부 규칙보다 먼저 적용될 수 있습니다.

글로벌 모드는 일반적으로 클라이언트가 이미 처리하는 요청을 선택한 프록시 정책으로 일괄 전달합니다. 핵심은 ‘이미 처리하는 요청’이라는 점입니다. 시스템 프록시를 따르지 않는 앱이나 제외된 앱, 가상 네트워크 인터페이스로 들어오지 않은 트래픽은 이 모드의 제어를 받지 않을 수 있습니다. 글로벌 모드라고 해서 기기 전체에 프록시가 강제로 적용되는 것은 아닙니다.

직접 연결 모드는 일반적으로 이미 처리 중인 요청을 원격 프록시를 거치지 않고 대상에 직접 전달합니다. ‘직접 연결 회선’과는 서로 다른 개념입니다. 전자는 라우팅 동작이고 후자는 기기와 서비스 진입점 사이의 경로 유형입니다. 화면에 표시된 ‘직접 연결’은 어느 설정에 있는지 살펴 문맥에 맞게 이해해야 합니다.

평소에는 용도에 맞는 규칙 설정을 사용하면 됩니다. 특정 웹사이트에 문제가 생기면 비교를 위해 잠시 글로벌 모드로 전환해 볼 수 있습니다. 글로벌 모드에서는 되지만 규칙 모드에서 실패한다면 규칙 적용과 DNS 결과를 확인해 보세요. 두 모드 모두 실패하면 노드, 네트워크, 대상 서비스를 점검하세요. 비교는 원인 범위를 좁히는 데 도움이 되지만, 그 자체만으로 장애 원인을 입증하지는 않습니다.

DNS 누출과 출구 주소는 어떤 관계일까요?

DNS는 도메인 이름을 주소로 변환합니다. 웹 요청이 프록시를 이용한다고 해서 DNS 요청도 반드시 프록시를 이용하는 것은 아닙니다. DNS 요청은 운영체제, 브라우저, 클라이언트, 앱에서 각각 보낼 수 있으며, 사용하는 DNS 서버와 전송 경로도 다를 수 있습니다.

일반적으로 DNS 누출은 예정된 터널이나 프록시 경로로 보내야 할 DNS 요청이 다른 경로를 통해 DNS 서버에 도달하는 상황을 뜻합니다. 이 경우 조회한 도메인이 노출되거나 분할 라우팅 결과가 예상과 달라질 수 있습니다. 하지만 검사 페이지에서 표시된 DNS 서버 지역과 출구 지역이 다르다는 사실만으로 누출이라고 단정할 수는 없습니다. 설정과 요청 경로를 함께 확인해야 합니다.

암호화 DNS는 DNS 요청이 전송되는 구간을 보호하지만, 요청이 프록시를 통해 전달된다는 뜻은 아닙니다. 브라우저에서 별도로 활성화한 암호화 DNS가 클라이언트의 예상 DNS 처리 과정을 우회할 수도 있습니다. 문제를 점검할 때는 브라우저 설정, 클라이언트 DNS 정책, 시스템 설정을 함께 확인하세요. 웹페이지에 표시된 출구 주소만 확인해서는 충분하지 않습니다.

프록시 연결과 웹사이트 HTTPS는 서로 다른 구간을 보호합니다. 민감한 계정에 접속할 때는 도메인과 인증서 안내를 확인하세요. 출구 주소가 바뀌어도 로그인된 계정을 웹사이트가 식별하지 못한다는 뜻은 아니며, 모든 앱의 트래픽이 프록시를 통과한다는 뜻도 아닙니다.

플랫폼마다 연결 결과가 다른 이유는 무엇일까요?

Windows와 macOS 클라이언트는 시스템 프록시 진입점을 제공하는 경우가 많고, 일부는 TUN 모드도 지원합니다. TUN은 가상 네트워크 인터페이스를 통해 네트워크 트래픽을 처리하며 일반적으로 관련 권한이 필요하고 라우팅과 DNS에 영향을 줄 수 있습니다. 처리할 수 있는 트래픽 범위가 넓어지지만, 제외 항목과 프로토콜 지원, 라우팅 동작은 구현 방식에 따라 다릅니다.

Android 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 처리하는 경우가 많으며 앱별 분할 라우팅을 지원할 수도 있습니다. iOS와 iPadOS 클라이언트는 일반적으로 시스템 네트워크 확장 기능을 사용합니다. 스위치 이름이 비슷해도 각 플랫폼의 규칙 기능이 완전히 같다는 보장은 없습니다. 백그라운드 제한, 네트워크 전환, 다른 네트워크 도구도 연결에 영향을 줄 수 있습니다.

Linux에서는 그래픽 클라이언트와 명령줄 코어를 모두 사용할 수 있습니다. 코어를 실행하는 것만으로 데스크톱 프록시나 시스템 라우팅이 자동 설정되지는 않을 수 있습니다. 여러 플랫폼에서 문제를 점검할 때는 노드 이름만 비교하지 말고 ‘트래픽이 어떻게 클라이언트에 들어오는지’를 확인하세요. 클라이언트 다운로드와 설정 방법은 사용 가이드를 참고하세요.

구독 가져오기부터 연결 문제 점검까지

  1. 설정 출처 확인. 계정에 로그인한 뒤 공식 제공 경로에서 클라이언트에 맞는 구독을 가져오세요. 요금제 상태, 구독 형식, 클라이언트 지원 여부는 각각 확인해야 합니다.
  2. 가져오기 결과 확인. 클라이언트가 설정을 제대로 읽었는지, 선택할 수 있는 노드가 표시되는지 확인하세요. ‘링크를 저장함’을 ‘설정을 성공적으로 다운로드함’과 혼동하지 마세요.
  3. 노드와 모드 선택. 용도에 맞는 노드와 규칙 설정을 먼저 선택한 다음 시스템 프록시 또는 플랫폼에 맞는 트래픽 처리 방식을 활성화하세요. 여러 네트워크 도구가 동시에 라우팅을 변경하지 않도록 주의하세요.
  4. 실제 앱으로 확인. 웹페이지와 대상 앱이 각각 작동하는지 확인하고, 필요하면 연결 로그에서 규칙 적용 여부, DNS 실패, 핸드셰이크 오류를 살펴보세요. 로그를 공유하기 전에 인증 정보와 구독 주소를 삭제하세요.
  5. 증상에 따라 원인 범위 좁히기. 노드가 없으면 먼저 구독을 확인하세요. 노드는 있지만 핸드셰이크에 실패하면 네트워크와 프로토콜을 확인하세요. 웹페이지는 열리지만 특정 앱이 실패하면 트래픽 처리 여부를 확인하세요. 특정 웹사이트에서만 문제가 생기면 규칙과 대상 서비스를 점검하세요.

클라이언트에 표시되는 ‘지연 시간’은 보통 특정 테스트 대상과 방법을 기준으로 측정합니다. 다운로드 속도나 화상 회의 품질로 바로 환산할 수는 없습니다. 테스트에 성공했다는 것은 해당 항목을 통과했다는 뜻일 뿐입니다. 지속적인 데이터 전송, 패킷 손실, 지터, 대상 서비스 상태에 따라 실제 사용 환경은 달라질 수 있습니다.

  • ✅ 구독 업데이트는 설정을 동기화하는 작업입니다. 요금제 변경이 필요한지는 계정 혜택을 확인하세요.
  • ✅ 노드를 바꾼 뒤에는 같은 앱과 비슷한 네트워크 환경에서 비교하세요. 여러 설정을 동시에 바꾸지 마세요.
  • ❌ 노드 이름에 지역, 전용 회선, 프로토콜이 표시되어 있다고 해서 모든 용도에 적합하다고 단정하지 마세요.
  • ❌ 구독 인증 정보를 공개하지 말고, 인증서 검증 해제를 기본 문제 해결 방법으로 사용하지 마세요.

초보자를 위한 점검 순서: 먼저 구독을 제대로 가져왔는지 확인하고, 다음으로 노드 연결 여부를 살펴보세요. 이어서 앱 트래픽이 클라이언트로 들어오는지 확인한 뒤 규칙과 DNS를 점검하면 됩니다. 모든 설정을 계속 바꾸는 것보다 단계별로 확인하는 편이 문제를 찾기 쉽습니다.

서비스를 선택할 때도 회선 안내, 결제 규칙, 고객 지원 경로를 각각 확인하세요. 용어는 작동 방식을 설명할 뿐, 근거를 대신하지 않습니다. 연결 문제를 더 해결해야 한다면 먼저 도움말 센터를 확인한 뒤 계정 문의 티켓으로 민감 정보를 삭제한 오류 내용과 재현 절차를 보내 주세요.

무료로 시작