VPN 용어 정리: 구독, 노드, 회선 유형, 프로토콜 한 번에 이해하기
구독, 노드, 회선 유형, 프로토콜, 분할 터널링, 전역·규칙 모드라는 여섯 단어는 클라이언트 화면과 요금제 안내에 반복해서 등장하지만, 정작 한자리에서 제대로 설명해 주는 곳은 드뭅니다. 이 글은 '개통에서 연결까지'의 순서로 하나씩 풀어 보며, 용어마다 한 줄 정의와 판단 방법, 실제로 마주치는 함정을 함께 짚습니다.
이 VPN 용어 해설은 알파벳 순서가 아니라 한 번의 연결이 일어나는 순서를 따릅니다. 먼저 노드 목록을 받고, 어느 서버에 연결할지 정하고, 데이터가 어떤 경로로 갈지 결정한 다음에야 암호화 이야기를 합니다. 이 순서로 이해하면 여섯 단어가 더 이상 뒤섞이지 않습니다.
왜 이 여섯 용어는 늘 뒤섞여 쓰일까
아무 클라이언트나 열어 보면 '구독'과 '노드'가 나란히 있고, '회선 유형'은 요금제 페이지에 적혀 있고, '프로토콜'은 노드 상세 정보에 숨어 있고, '분할 터널링'은 한 화면짜리 스위치입니다. 단어는 다 아는데 문제가 생겼을 때 어느 계층이 문제인지 말할 수 없으면 '노드 바꿔 보기'만 반복하게 됩니다. 열 번째를 바꿔도 안 되면 사람도 지칩니다.
연결 한 번을 네 계층으로 나누면 훨씬 선명해집니다.
- 계정 계층: 구독. 클라이언트가 어떤 노드를 받을 수 있는지 결정합니다.
- 입구 계층: 노드. 어느 서버에 어떤 파라미터로 연결할지 결정합니다.
- 경로 계층: 회선 유형. 데이터가 로컬에서 착지 지점까지 어떻게 가는지 결정합니다.
- 핸드셰이크 계층: 프로토콜. 어떻게 암호화하고 TCP를 쓸지 UDP를 쓸지 결정합니다.
분할 터널링과 전역/규칙 모드는 이 네 계층에 속하지 않습니다. 둘 다 라우팅 계층의 스위치로, 전자는 '어떤 트래픽이 프록시를 타는가'를, 후자는 '이 규칙이 실제로 적용되는가'를 결정합니다.
| 용어 | 한 줄 정의 | 문제가 생기면 먼저 볼 것 |
|---|---|---|
| 구독 | 클라이언트가 노드 목록을 받아 오는 링크 | 링크가 온전한지, 다른 사람에게 전달되지 않았는지 |
| 노드 | 서버 한 대의 접속 파라미터 묶음 | 주소, 포트, 프로토콜, 비밀번호가 설정과 일치하는지 |
| 회선 유형 | 데이터가 로컬에서 착지 지점까지 가는 경로 | 피크 시간대에 흔들리는지, 중간 구간이 공용 인터넷을 거치는지 |
| 프로토콜 | 클라이언트와 노드 사이의 핸드셰이크와 암호화 방식 | 시스템 시간, TLS, UDP 제한 여부 |
| 분할 터널링 | 어떤 트래픽이 프록시를 타고 어떤 트래픽이 직접 연결되는지 | 규칙 순서와 마지막 기본 규칙 |
| 전역 모드와 규칙 모드 | 클라이언트 전체의 라우팅 스위치 | 전역 모드를 잘못 켜서 규칙이 전부 무효화되지는 않았는지 |
이제 이 순서대로 하나씩 풀어 보겠습니다.
구독: 링크 하나, 본질은 계정 자격 증명
구독(subscription)은 URL 하나입니다. 클라이언트가 일정 주기로 이 URL에 요청을 보내 노드 목록을 받아 옵니다. base64로 인코딩된 ss://, vmess://, trojan://, vless://, hysteria2:// 링크 묶음일 수도 있고, Clash / mihomo가 바로 읽는 YAML 설정일 수도 있습니다. 이른바 '구독 가져오기'란 이 URL을 클라이언트에 넘기면 나머지는 클라이언트가 알아서 처리한다는 뜻입니다.
놓치기 쉬운 세 가지:
- 구독 갱신은 전체 교체입니다. 클라이언트가 링크를 다시 요청하면 서버가 준 내용이 그대로 덮어씁니다. 직접 고친 노드 이름, 정렬, 메모는 한 번 갱신하면 사라집니다.
- 구독에는 계정 상태가 함께 실릴 수 있습니다. 일부 서버는 응답 헤더에 만료 시각과 사용량(
subscription-userinfo)을 붙이고, 클라이언트는 이를 첫 화면에 표시합니다. 이 헤더를 지원하는 정도는 클라이언트마다 달라서, 안 보인다고 해서 없는 것은 아닙니다. - 가져오기 실패와 연결 실패는 다른 문제입니다. 구독 가져오기 실패는 보통 메신저가 링크를 잘라 먹었거나, 기기 시간 오차가 커서 TLS 핸드셰이크가 깨졌거나, 현재 네트워크에서 패널 도메인에 접근할 수 없는 경우입니다. 노드 연결 실패는 다른 계층의 문제입니다.
노드: 이름 하나가 아니라 접속 파라미터 묶음
노드(node)는 클라이언트가 착지 서버에 연결하는 데 필요한 모든 파라미터입니다. 주소, 포트, 프로토콜, 암호화 방식, 비밀번호 또는 UUID, 전송 계층(TCP / WebSocket / gRPC), TLS 사용 여부와 SNI, 경로까지. 하나라도 빠지면 핸드셰이크가 되지 않습니다.
그래서 '노드 이름'과 '노드'는 다른 것입니다. 이름은 라벨일 뿐이라 무엇으로 바꿔도 연결됩니다. 실제로 연결을 좌우하는 것은 위의 파라미터입니다. 같은 착지 서버에서 포트나 전송 계층을 달리해 여러 노드를 파생시킬 수 있고, '노드 수'와 '회선 수'가 자주 어긋나는 이유도 여기에 있습니다.
노드가 쓸 만한지 판단할 때 속도 측정 한 번만 보지 마세요. 연속 핸드셰이크가 여러 번 모두 성공하는지, 피크 시간대에 속도가 눈에 띄게 떨어지는지, 장기 연결(화상 회의, SSH 세션)이 중간에 끊기지 않는지. 이 세 가지가 한 번의 최고 속도보다 훨씬 많은 것을 알려 줍니다.
회선 유형: 직결, 중계, 전용선의 차이
회선 유형은 경로를 설명합니다. 데이터가 로컬에서 출발해 착지 서버에 이르기까지 중간에 어떻게 지나가는지입니다.
- 직결: 클라이언트가 착지 서버에 바로 연결하며 전 구간이 공용 인터넷을 지납니다. 비용이 가장 낮고, 피크 시간대에 공용 인터넷 혼잡의 영향을 가장 크게 받습니다.
- 중계: 먼저 중계 입구에 연결하고, 중계 서버가 착지 지점으로 전달합니다. 입구 주소는 바꿀 수 있고 착지는 그대로 두므로 직결보다 안정적이지만, 중간 구간은 여전히 공용 인터넷입니다.
- IEPL 전용선: 통신사급 국제 이더넷 전용선으로, 중간 구간이 공용 인터넷을 지나지 않고 대역폭도 상대적으로 전용입니다. 지연과 지터를 더 잘 통제할 수 있지만 비용도 가장 높습니다.
| 유형 | 경로 | 특징 | 적합 |
|---|---|---|---|
| 직결 | 로컬 → 착지, 전 구간 공용 인터넷 | 비용 낮음, 피크 시간대 변동이 큼 | 간단한 자료 검색, 가벼운 브라우징 |
| 중계 | 로컬 → 중계 → 착지 | 입구 교체 가능, 직결보다 안정적이나 중간 구간은 여전히 공용 인터넷 | 일상 웹 서핑, 소셜 미디어, 일반 다운로드 |
| IEPL 전용선 | 로컬 → 전용선 입구 → 착지, 중간 구간이 공용 인터넷을 지나지 않음 | 지연과 지터를 더 잘 통제, 피크 시간대에도 비교적 안정적 | 화상 회의, 장기 연결, 스트리밍 |
현재 사이트의 회선과 요금제 정보는 바로 대조해 볼 수 있습니다. 90+ 개국, 190+ 회선, 동시 접속 기기 수 제한 없음, 첫 결제 후 7일 이내에 무조건 환불 신청 가능.
프로토콜: 여섯 가지 핸드셰이크 방식, 어떻게 고를까
프로토콜은 클라이언트와 노드가 어떻게 핸드셰이크하고, 어떻게 암호화하며, TCP를 쓸지 UDP를 쓸지를 결정합니다. '암호화 강도'와는 다른 이야기입니다. 주류 프로토콜의 외곽 암호화는 모두 충분하고, 실제 체감을 좌우하는 것은 전송 특성이 내가 있는 네트워크 환경과 맞는지입니다.
| 프로토콜 | 전송 기반 | 특징 | 주의할 점 |
|---|---|---|---|
| Shadowsocks | TCP / UDP, AEAD 암호화 | 가볍고 오버헤드가 적으며 클라이언트 지원 범위가 넓음 | 트래픽 특성이 뚜렷해 표적 식별에 노출되기 쉬움 |
| VMess | TCP / WebSocket / gRPC, TLS 적용 가능 | V2Ray 계열의 오래된 프로토콜, 멀티플렉싱 지원 | 검증이 시간에 의존하므로 양단 시간 오차가 크면 핸드셰이크 실패 |
| VLESS | 보통 TLS 적용(Reality 포함) | 자체 암호화는 없고 외곽 TLS에 의존, 오버헤드가 한 겹 적음 | 설정 항목이 많고 SNI와 위장 대상이 짝을 이뤄야 함 |
| Trojan | TLS | 일반 HTTPS 트래픽으로 위장, 비밀번호 인증 | 도메인과 인증서가 필요하고 비밀번호가 틀리면 바로 연결 실패 |
| Hysteria2 | QUIC(UDP) | 약전계, 높은 패킷 손실 환경에서도 동작 | UDP에 의존하므로 일부 네트워크에서 UDP가 제한되거나 품질이 떨어짐 |
| TUIC | QUIC(UDP) | 멀티플렉싱, 빠른 핸드셰이크, 낮은 지연 | 마찬가지로 UDP 품질의 영향을 받음 |
세 가지 선택 기준
- 네트워크가 UDP에 우호적: Hysteria2, TUIC는 패킷 손실 상황에서 더 안정적이며 모바일 네트워크와 장거리 국제 구간에 적합합니다.
- 네트워크가 UDP를 제한: TLS 계열을 우선하세요. VMess + TLS, VLESS + Reality, Trojan 모두 443 포트를 쓸 수 있습니다.
- 구형 기기, 구형 클라이언트: Shadowsocks의 호환성이 가장 좋아 거의 모든 클라이언트가 지원합니다.
분할 터널링: 어떤 트래픽이 프록시를 타고 어떤 트래픽이 직접 연결되는가
분할 터널링(routing)은 순서가 있는 규칙 묶음입니다. 클라이언트가 위에서 아래로 매칭하다가 하나 맞으면 멈추므로, 개수보다 순서가 중요합니다.
자주 쓰는 규칙 유형:
DOMAIN/DOMAIN-SUFFIX/DOMAIN-KEYWORD: 도메인으로 매칭합니다.IP-CIDR/GEOIP: IP 대역이나 지리적 소속으로 매칭합니다.PROCESS-NAME: 프로세스 이름으로 매칭하며 데스크톱에서만 지원합니다.RULE-SET: 외부 규칙 집합을 참조해 일괄 관리에 편리합니다.MATCH(일부 클라이언트는FINAL): 기본(폴백) 규칙으로 반드시 맨 마지막에 둡니다.
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN-KEYWORD,github,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY이 규칙의 의미는 이렇습니다. example.com과 그 하위 도메인은 직접 연결, 도메인에 github이 들어가면 프록시, 중국 본토 IP로 해석되면 직접 연결, 나머지는 전부 프록시. MATCH를 첫 줄로 옮기면 뒤의 모든 규칙이 실행되지 않습니다. 증상은 '규칙을 썼는데 전혀 효과가 없다'입니다.
DNS 누수: 분할 터널링 밖의 나머지 절반
DNS 누수란 도메인 조회 요청이 프록시 경로를 따라가지 않고 로컬 네트워크로 나가는 것을 말합니다. 결과는 두 가지입니다. 어떤 도메인에 접속했는지가 로컬 DNS에 드러나고, 조회 결과가 오염되어 잘못된 주소를 받을 수 있습니다.
흔한 방법은 프록시가 DNS를 해석하게 하는 것입니다. fake-ip 모드에서는 클라이언트가 로컬에서 가짜 주소를 만들어 앱에 돌려주고, 실제 해석은 착지 측에서 이루어집니다. 대신 실제 IP에 의존하는 일부 소프트웨어(같은 LAN 기기 검색, 일부 온라인 게임)가 오작동할 수 있으므로, 해당 도메인에 직접 연결 규칙을 추가하거나 fake-ip-filter에 넣어야 합니다.
분할 터널링 자체 점검
- ✅ 중국 본토 사이트를 열었을 때 연결 상세에 직접 연결로 표시되면 규칙이 정상적으로 매칭된 것입니다.
- ✅ 해외 사이트를 열었을 때 연결 상세에 프록시 경유로 표시되면 기본 규칙이 작동한 것입니다.
- ❌ 모든 트래픽이 프록시 경유로 표시된다면 보통 모드가 전역에 머물러 규칙이 매칭에 참여하지 못한 경우입니다.
- ❌ 해외 사이트가 직접 연결로 나간다면 규칙 순서가 뒤바뀌었거나 기본 규칙이 빠졌을 가능성이 큽니다.
- ❌ 도메인 조회가 여전히 로컬 통신사에서 이루어진다면 DNS 누수가 있으므로 DNS 설정을 확인해야 합니다.
전역 모드와 규칙 모드: 두 스위치를 혼동하지 마세요
클라이언트는 보통 세 가지 모드를 제공합니다:
- 전역: 모든 트래픽이 프록시를 타며 분할 터널링 규칙은 전혀 적용되지 않습니다.
- 규칙: 분할 터널링 규칙에 따라 결정되며, 일상 사용에는 이 모드를 고르세요.
- 직접 연결: 모든 트래픽이 프록시를 타지 않습니다.
전역 모드의 가장 큰 쓰임새는 점검이지 일상 사용이 아닙니다. '어떤 사이트가 열리지 않는다'면 먼저 전역으로 바꿔 보세요. 전역에서 열리면 노드, 회선, 프로토콜에는 문제가 없고 규칙에 문제가 있다는 뜻이고, 전역에서도 안 열리면 노드나 네트워크 자체의 문제입니다. 이 순서만 지켜도 노드를 계속 바꾸며 낭비하는 시간을 크게 줄일 수 있습니다.
플랫폼별 클라이언트: 같은 구독이라도 동작은 다릅니다
구독은 공통이지만 클라이언트는 그렇지 않습니다. 같은 노드 목록이라도 운영체제가 다르면 동작이 전혀 다를 수 있습니다.
- Windows: Clash Verge Rev(mihomo 코어), v2rayN이 흔하며, 시스템 프록시 또는 TUN 모드를 선택할 수 있습니다.
- macOS: ClashX Meta, Surge 등이 있으며, TUN 모드는 시스템 확장 승인이 필요합니다.
- iOS: Shadowrocket, Stash 등이 시스템 VPN 설정을 통해 트래픽을 가져갑니다. 백그라운드 유지가 시스템 제약을 받아 오래 백그라운드로 두면 끊길 수 있습니다.
- Android: Clash Meta for Android, v2rayNG 등이 있으며, 첫 연결 시 VPN 서비스 권한 승인이 필요합니다.
- Linux: 대부분 mihomo, sing-box 코어를 systemd로 돌립니다. TUN 모드는 root 또는 그에 맞는 네트워크 권한이 필요합니다.
차이는 네 가지에 집중됩니다. 지원하는 프로토콜 부분집합, 분할 터널링 규칙 문법, DNS 처리 방식, TUN 권한입니다. 클라이언트를 바꾸기 전에 지금 쓰는 프로토콜을 지원하는지 먼저 확인하세요. 일부 클라이언트는 QUIC 계열 프로토콜 지원이 늦어서, Hysteria2 노드로 시험했다가 연결이 안 된다고 해서 노드 문제라고 단정할 수는 없습니다.
여섯 단어를 하나로 잇기: 연결 한 번의 전 과정
- 클라이언트가 구독 링크로 노드 목록을 받아 옵니다.
- 사용자가 노드를 하나 고르면 클라이언트가 주소, 포트, 프로토콜, 비밀번호를 읽습니다.
- 트래픽이 먼저 분할 터널링 규칙을 지나 프록시를 탈지 직접 연결할지 정해지고, 전역/규칙 모드가 이 규칙의 적용 여부를 결정합니다.
- 프록시를 타는 트래픽은 프로토콜에 따라 암호화되어, 회선 유형이 정한 경로로 착지 지점에 도달합니다.
- 착지 서버가 복호화한 뒤 목적지 사이트에 접속하고, 데이터는 같은 경로로 돌아옵니다.
이 순서로 점검하면 거의 헛바퀴를 돌지 않습니다. 구독으로 노드를 받아올 수 있는지, 노드 파라미터가 맞는지, 모드가 실수로 전역에 있지 않은지 확인하고, 마지막에 회선과 프로토콜을 의심하세요.
자주 묻는 질문
구독을 갱신했더니 노드가 전부 바뀌었는데, 오류인가요?
아닙니다. 구독 갱신은 전체 교체이므로 서버가 노드 목록을 조정하면 그대로 반영됩니다. 직접 고친 이름과 정렬이 덮어써지는 것은 정상 동작입니다.
같은 노드가 PC에서는 연결되는데 모바일에서는 안 되나요?
먼저 양쪽의 프로토콜과 전송 계층 설정이 같은지 확인하고, 그다음 모바일이 연결된 네트워크에서 UDP를 제한하는지 보세요. QUIC 계열 프로토콜은 UDP에 의존합니다. 같은 구독이라도 클라이언트마다 해석되는 파라미터가 가끔 다를 수 있습니다.
전역 모드에서는 열리는데 규칙 모드에서는 안 열리나요?
노드 자체에는 문제가 없다는 뜻이고, 문제는 분할 터널링 규칙에 있습니다. 규칙 순서, 기본 규칙의 존재 여부, 그리고 대상 도메인이 직접 연결 목록으로 잘못 분류되지 않았는지 확인하세요.
TUN 모드를 꼭 켜야 하나요?
꼭 그렇지는 않습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱만 가져갈 수 있습니다. TUN 모드는 네트워크 계층에서 가져가므로 시스템 프록시를 인식하지 않는 프로그램까지 커버하지만, 더 높은 권한이 필요하고 설정도 복잡합니다. 사용 환경에 맞게 고르면 됩니다.