VPN 초보 용어를 빠르게 살펴보고 먼저 작동 순서를 이해해 보세요. 구독은 클라이언트에 설정을 전달하고, 노드는 연결의 입구와 출구를 정하며, 프로토콜은 통신 방식을 규정하고, 분할 라우팅 규칙은 어떤 요청을 어느 경로로 보낼지 결정합니다. 각 개념은 서로 다른 계층에 있으므로 이름만 보고 연결 속도나 개인정보 보호 수준을 판단할 수는 없습니다.
일상적인 대화에서 “VPN”은 프록시 클라이언트나 국제 회선 서비스를 통칭하는 말로도 쓰입니다. 엄밀히 말해 시스템 수준의 터널과 앱 프록시는 서로 다릅니다. 클라이언트에 VPN 권한 안내가 표시되는 것은 시스템 네트워크 인터페이스를 사용한다는 뜻일 뿐, 특정 프로토콜을 사용하거나 모든 앱의 요청이 프록시를 거친다는 의미는 아닙니다.
용어 한눈에 보기: 설정, 연결, 라우팅 구분하기
낯선 설정을 만나면 먼저 ‘설정을 어디서 가져오는지’, ‘서버에 어떻게 연결하는지’, ‘요청이 어디로 향하는지’ 중 무엇을 해결하는 기능인지 살펴보세요. 아래 표에서 자주 쓰이는 용어를 각 역할에 맞게 정리했습니다.
| 용어 | 실제 의미 | 헷갈리기 쉬운 점 |
|---|---|---|
| 구독 링크 | 노드 또는 전체 설정을 가져오고 업데이트하는 주소입니다. | 클라이언트 설치 파일이나 공개 공유 링크가 아닙니다. |
| 노드 | 클라이언트에서 선택할 수 있는 서버 연결 매개변수입니다. | 목록에 표시된 이름이 각각 독립된 물리 서버를 뜻하는 것은 아닙니다. |
| 회선 유형 | 입구에서 출구까지의 네트워크 경로를 설명합니다. 예를 들어 직결, 중계, 전용 회선이 있습니다. | 통신 프로토콜과는 다르며, 이름만으로 속도를 알 수 없습니다. |
| 프로토콜 | 클라이언트와 서버가 데이터를 인증하고 캡슐화해 전송하는 방식을 정합니다. | 클라이언트가 해당 프로토콜을 지원해도 현재 서비스에서 제공한다는 뜻은 아닙니다. |
| 분할 라우팅 규칙 | 도메인, 주소, 프로세스 등의 조건에 따라 직결·프록시·차단을 선택합니다. | 규칙 적용 결과와 현재 선택된 노드는 별개의 설정입니다. |
| DNS | 도메인을 네트워크 주소로 변환해 이후 연결에 사용합니다. | 웹페이지가 프록시를 거쳐도 DNS 조회까지 반드시 프록시를 거치는 것은 아닙니다. |
| TUN | 가상 네트워크 인터페이스를 통해 트래픽을 연결하는 방식입니다. | 노드 프로토콜이 아니며, 실제 적용 범위는 라우팅과 클라이언트 구현에 따라 달라집니다. |
구독 링크와 클라이언트: 설정을 가져오는 방법
클라이언트는 기기에서 실행되는 소프트웨어이고, 구독 링크는 클라이언트가 설정을 불러오는 경로입니다. 서비스 제공업체가 노드 주소를 변경하면 새 설정을 받기 위해 구독을 업데이트해야 하는 경우가 많습니다. 구독 업데이트는 계정 변경과 다르며, 현재 선택된 노드가 자동으로 바뀌는 것도 아닙니다.
구독 형식에는 노드 정보만 들어 있을 수도 있고, 정책 그룹·DNS·분할 라우팅 규칙이 포함될 수도 있습니다. 가져온 뒤에는 모든 설정이 준비됐다고 가정하지 말고 클라이언트에서 실제로 생성된 설정을 확인하세요. 형식 비호환, 파싱 오류, 구독 만료로 노드 목록이 비어 보일 수 있습니다.
- 서비스 패널에서 사용할 클라이언트에 맞는 구독 주소를 확인하고, 신뢰할 수 있는 경로에서 설치 파일을 받습니다.
- 클라이언트의 설정 또는 구독 관리 메뉴에서 링크를 가져옵니다. 형식을 선택해야 한다면 패널 안내를 따르세요.
- 업데이트를 실행한 뒤 노드와 정책 그룹이 표시되는지, 파싱 오류가 있는지 확인합니다.
- 노드와 실행 모드를 선택한 다음 시스템 프록시 또는 클라이언트가 요구하는 네트워크 처리 방식을 활성화합니다.
- 실제 웹페이지나 앱으로 연결을 확인하세요. ‘연결됨’ 표시만으로 요청이 의도한 출구를 거친다고 단정할 수는 없습니다.
노드와 회선: 출구 지역이 전체 경로를 뜻하지는 않습니다
노드 이름에는 보통 지역이나 용도에 대한 정보가 포함되지만, 이름만으로 실제 네트워크 경로를 알 수는 없습니다. 입구와 출구가 서로 다른 지역일 수 있으며, 웹사이트에는 보통 출구 주소가 표시됩니다. 출구 위치가 콘텐츠 플랫폼의 계정 지역, 결제 지역 또는 이용 가능한 콘텐츠를 반드시 결정하는 것도 아닙니다.
직결은 보통 기기가 해외 서버에 직접 연결되는 방식입니다. 중계는 먼저 입구에 연결한 뒤 출구로 전달하는 방식입니다. IEPL 전용 회선은 이더넷 전용 회선을 통한 전송 방식을 가리키며, 서비스에 따라 경로의 일부만 전용 회선을 사용할 수 있습니다. 나머지 접속 구간과 출구 구간도 이용 경험에 영향을 줍니다.
이러한 명칭은 서비스 제공업체마다 의미가 다를 수 있습니다. 전용 회선은 암호화 프로토콜이 아니며, 이름만으로 낮은 지연 시간이나 전용 대역폭, 특정 플랫폼 이용 가능성을 판단할 수 없습니다. 선택할 때는 경로 안내를 확인하고 자신의 네트워크 환경에서 웹페이지 로딩, 앱 연결, 지속 전송 상태를 점검하세요.
프로토콜 이름: 최신보다 호환성이 중요합니다
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC는 프록시 클라이언트에 표시될 수 있지만, 필요에 따라 바꿔 쓰는 선택 항목은 아닙니다. 서버와 클라이언트의 프로토콜, 인증, 전송, 보안 매개변수가 서로 일치해야 합니다.
Shadowsocks는 합의된 암호화 방식을 사용해 프록시 통신을 처리합니다. VMess에는 고유한 인증 및 통신 방식이 있고, Trojan은 일반적으로 TLS로 전송을 보호합니다. VLESS 자체는 데이터를 암호화하지 않으므로 적절한 보안 전송 방식과 함께 구성해야 합니다. 프로토콜 이름만 보고 연결이 암호화됐다고 단정하지 마세요.
Hysteria2와 TUIC는 모두 QUIC 기반이며, 일반적으로 네트워크에서 해당 UDP 통신을 허용해야 합니다. 현재 네트워크가 UDP를 제한하면 연결이 제대로 설정되지 않을 수 있습니다. 그렇다고 구독 자격 증명이 잘못됐다거나 다른 프로토콜도 사용할 수 없다고 판단할 수는 없습니다.
초보자는 패널에서 제공하는 호환 설정을 사용하는 것이 좋습니다. TLS 검증, 서버 이름, 전송 매개변수를 임의로 수정하지 마세요. 인증서 오류가 발생하면 검증을 건너뛰기보다 기기 시간과 설정 출처를 확인하세요. 이 글은 업계 용어를 설명하며 VPN76이 위 프로토콜을 모두 제공한다는 뜻은 아닙니다.
분할 라우팅, 규칙 모드와 글로벌 모드
분할 라우팅은 경로를 결정하는 방식이며, 규칙 모드는 이러한 결정을 실행하는 방법 중 하나입니다. 흔히 국내 서비스는 직결하고 국제 회선이 필요한 요청은 프록시 정책 그룹으로 보내도록 설정합니다. 정책 그룹에서 사용할 노드를 정하므로 ‘규칙에 따른 경로 선택’과 ‘노드 선택’은 이어지는 단계입니다.
규칙은 보통 클라이언트에 정의된 순서대로 적용되며, 나머지 요청은 최종 기본 규칙이 처리합니다. 도메인·주소·프로세스 중 무엇을 기준으로 매칭할 수 있는지는 클라이언트와 실행 플랫폼에 따라 다릅니다. 규칙을 추가해도 달라지는 점이 없다면 순서, 대상 정책 그룹, 설정 적용 여부부터 확인하세요.
전역 모드는 보통 클라이언트가 처리하는 요청을 지정된 프록시나 정책 그룹으로 일괄 전달합니다. 분할 라우팅 문제를 잠시 점검할 때 유용합니다. 하지만 기기의 모든 네트워크 트래픽이 반드시 처리된다는 뜻은 아닙니다. 시스템 프록시를 따르지 않는 앱, 로컬 네트워크 예외, 터널에 포함되지 않은 트래픽은 다른 경로를 사용할 수 있습니다.
선택 기준: 평소에는 설정 출처가 명확한 규칙 모드를 우선 사용하고, 문제를 점검할 때만 전역 모드와 잠시 비교하세요. 전역 모드는 작동하지만 규칙 모드에 문제가 있다면 구독을 반복해서 바꾸기보다 규칙 적용 결과와 정책 그룹을 먼저 확인하세요.
DNS 누수: DNS 조회 경로도 확인하세요
도메인에 접속하기 전에 기기는 보통 먼저 IP 주소를 조회합니다. DNS 조회가 프록시를 통해 전달되어야 하는데 실제로는 로컬 네트워크의 DNS 리졸버로 전송된다면 예상치 못한 DNS 누수가 발생할 수 있습니다. 이는 조회 정보가 노출되는 문제이며, 웹페이지 본문이 이미 읽혔다는 뜻은 아닙니다.
DNS는 운영체제, 브라우저의 암호화 DNS 기능, 클라이언트가 각각 처리할 수 있습니다. 암호화 DNS는 조회 전송을 보호하지만 리졸버는 조회 내용을 알 수 있습니다. 암호화를 켰다고 조회가 선택한 노드를 통과하는 것도 아닙니다. 문제를 점검할 때는 리졸버 선택과 조회 경로를 함께 확인해야 합니다.
- ✅ 현재 설정된 DNS 모드와 리졸버 출처를 확인하고 클라이언트 문서와 일치하는지 점검합니다.
- ✅ 브라우저에서 별도의 DNS 방식을 설정했는지 확인해 클라이언트 규칙과 예상치 못하게 조합되지 않도록 합니다.
- ✅ 신뢰할 수 있는 DNS 검사 페이지를 참고하고 클라이언트 연결 기록과 함께 경로를 판단합니다.
- ✅ 설정을 바꾼 뒤 다시 연결해 확인하고, 캐시와 앱 자체 DNS 조회에 따른 차이도 살펴봅니다.
- ❌ 검사 페이지에 표시된 지역이나 리졸버 수만으로 개인정보 보호가 완전히 적용됐다고 판단하지 마세요.
HTTPS는 브라우저와 웹사이트 사이의 데이터 전송을 보호하며, 프록시 터널의 보호 범위는 구체적인 구현에 따라 달라집니다. ‘익명·로그 미보관’은 서비스의 개인정보 처리 방침을 설명하는 표현이지, 웹사이트 로그인 계정·브라우저 식별 정보·결제 정보 간의 연관성을 없애지는 않습니다.
플랫폼별 차이: 같은 구독이어도 사용 방법은 다를 수 있습니다
Windows와 macOS 클라이언트에는 시스템 프록시, TUN 등 서로 다른 트래픽 처리 방식이 있을 수 있습니다. 시스템 프록시는 앱이 프록시 설정을 따르는 데 의존하는 경우가 많고, TUN은 추가 권한이나 네트워크 구성 요소 설치가 필요할 수 있습니다. 처리 방식을 바꾼 뒤에는 클라이언트 아이콘만 보는 대신 대상 앱의 연결을 다시 확인하세요.
Android 클라이언트는 시스템 VPN 인터페이스로 트래픽을 처리하는 경우가 많으며, 백그라운드 배터리 제한이 지속 실행에 영향을 줄 수 있습니다. iOS 클라이언트는 시스템 네트워크 확장 기능의 관리를 받으므로 앱별 분할 라우팅 등의 기능을 데스크톱 안내에 그대로 적용할 수 없습니다. Linux에서는 서비스 프로세스, 라우팅, DNS 설정을 함께 구성해야 할 수 있으며, 설정을 가져오는 것만으로 시스템 트래픽 처리가 완료되지는 않습니다.
다른 플랫폼으로 옮길 때는 클라이언트가 지원하는 프로토콜, 구독 형식, 규칙 문법을 각각 확인하세요. 이름이 같은 설정도 적용 범위가 다를 수 있습니다. 기본 사용 방법은 이 사이트의 초보자 가이드를 참고하고, 다른 플랫폼의 설정 조각을 그대로 복사하지 마세요.
연결 문제: 설정, 라우팅, 앱 순서로 점검하기
노드 목록이 비어 있다면 먼저 구독 업데이트와 형식 파싱을 확인하세요. 목록은 정상인데 연결할 수 없다면 권한, 네트워크 연결 가능 여부, 프로토콜 호환성을 점검합니다. 일부 앱에서만 문제가 생기면 시스템 프록시, TUN 적용 범위, 분할 라우팅 규칙을 살펴보세요. 이런 순서로 확인하면 서로 다른 계층의 문제를 혼동하지 않을 수 있습니다.
설정은 한 번에 하나씩만 바꾸고 변경 전후의 증상을 기록하세요. 지원 페이지에 문의할 때 운영체제, 클라이언트 이름, 사용 모드, 민감 정보를 가린 오류 메시지를 제공할 수 있습니다. 구독 링크, 비밀번호, 접근 토큰은 반드시 숨기세요.
기억할 점: 구독은 설정을 전달하고, 노드는 연결 대상을 정하며, 프로토콜은 통신 방식을 정하고, 규칙은 요청의 경로를 결정하며, DNS는 이름을 주소로 변환합니다. 먼저 각 계층이 정상인지 확인한 뒤 회선이 자신의 이용 환경에 적합한지 판단하세요.