VPN 초보자를 위한 용어 정리: 노드·프로토콜·분할 라우팅·글로벌 모드 한눈에 보기

이 VPN 초보자 용어 정리는 먼저 흔히 혼동하는 부분부터 짚습니다. 클라이언트에서 나란히 보이는 ‘구독, 노드, 프로토콜, 분할 라우팅, 글로벌 모드’는 실제로 서로 다른 계층에 속합니다. 구독은 설정을 전달하고, 노드는 선택 가능한 접속 지점 또는 출구이며, 회선은 데이터가 거치는 경로를 설명합니다. 프로토콜은 클라이언트와 서버가 통신하는 방식을 정하고, 분할 라우팅 모드는 어떤 요청이 이 통로를 사용할지 결정합니다.

한 번의 이동 과정에 비유하면 더 쉽게 이해할 수 있습니다. 구독 링크는 업데이트되는 노선 안내서, 노드는 정류장, 직접 연결·중계·전용 회선은 이동 경로, 프로토콜은 차량과 도로가 사용하는 통신 규칙, 분할 라우팅 규칙은 어느 구간에서 빠른 길을 이용하고 어느 구간에서 현지 도로를 이용할지 정하는 내비게이션과 같습니다. 계층만 먼저 구분하면 클라이언트의 대부분 설정이 더 이상 어렵지 않습니다.

구독, 설정, 노드는 각각 무엇인가요?

구독 링크는 업데이트 가능한 설정 목록입니다

구독 링크는 보통 서비스 제공업체의 관리 패널에서 생성됩니다. 클라이언트가 이 링크에 접속하면 주소, 포트, 프로토콜, 전송 방식, 인증 정보, 노드 이름 등이 포함된 서버 설정을 가져옵니다. 일반 정보 페이지가 아니라 접근 권한이 포함된 설정 진입점이므로 포럼, 스크린샷 또는 공개 문서에 올리면 안 됩니다.

‘구독 가져오기’와 ‘노드 연결’은 서로 다른 작업입니다. 가져오기는 클라이언트가 사용 가능한 설정을 인식하게 하는 단계이고, 실제 데이터 전송을 시작하려면 목록에서 노드를 선택한 뒤 연결을 켜야 합니다. 일부 클라이언트는 구독을 정기적으로 새로 고치지만, 수동으로 업데이트해야 하는 경우도 있습니다. 서비스 제공업체가 접속 지점을 변경했는데 로컬 목록에 이전 내용이 남아 있다면, 오래된 노드를 계속 바꾸기보다 먼저 구독을 업데이트하는 편이 효과적입니다.

단일 노드 설정과 구독은 다릅니다

단일 노드 링크는 하나의 설정만 설명하므로 임시 가져오기나 정밀한 문제 확인에 적합합니다. 구독 링크는 여러 노드를 한곳에서 관리할 수 있으며, 서버에서 업데이트하면 클라이언트가 다시 가져와 변경 사항을 동기화할 수 있습니다. ‘가져오기 완료’라고 표시되었는데 새 노드가 보이지 않는다면 현재 연 그룹이 구독 그룹인지 로컬 설정인지 확인하고, 클라이언트가 캐시를 사용하고 있지 않은지도 살펴보세요.

노드 이름은 라벨일 뿐, 전체 네트워크 경로가 아닙니다

‘도쿄’, ‘싱가포르’, ‘로스앤젤레스’ 같은 이름은 보통 출구 위치, 접속 지점 또는 서비스 제공업체가 회선을 구분하기 위해 붙인 라벨입니다. 이름만으로 전체 경로를 단정할 수는 없습니다. 도쿄로 표시된 중계 노드가 가까운 접속 지점으로 먼저 연결된 뒤 최적화된 경로를 거쳐 도쿄 출구에 도달할 수도 있고, 직접 연결 노드는 장치가 원격 서버에 바로 연결하는 방식일 수 있습니다.

✅ 가져온 뒤 먼저 구독을 업데이트하고 노드 목록이 변경되었는지 확인하세요.
✅ 구독 링크를 접근 자격 정보로 취급하고 신뢰할 수 있는 장치와 클라이언트에만 보관하세요.
✅ 노드를 바꾼 뒤에는 목록의 선택 표시만 보지 말고 클라이언트에 표시된 현재 설정을 확인하세요.
❌ ‘가져오기 완료’를 네트워크 연결 완료로 이해하지 마세요. 연결 스위치는 별도로 켜야 합니다.
❌ 도시 라벨만으로 회선 유형을 추측하지 말고 서비스 제공업체의 회선 설명을 함께 확인하세요.

빠른 판단: 업데이트 가능한 설정 진입점이 보이면 구독이고, 목록에서 선택할 수 있는 각 항목은 보통 노드입니다. 노드가 출구에 도달하는 방식이 바로 회선 토폴로지에 해당합니다.

직접 연결, 중계, IEPL 전용 회선의 차이

회선 유형은 ‘데이터가 장치에서 출구까지 어떻게 이동하는가’에 대한 설명입니다. 프로토콜과 나란히 사용되지만 같은 개념은 아닙니다. 같은 프로토콜도 직접 연결, 중계 또는 전용 회선 경로에서 모두 사용할 수 있습니다. 프로토콜은 연결과 캡슐화를 담당하고, 회선은 데이터가 기반 네트워크를 통해 전달되는 방식을 결정합니다.

회선 유형	기본 경로	일반적인 특징	확인할 지표
직접 연결	장치가 원격 접속 지점 또는 출구에 직접 연결	구조가 단순하며 실제 성능은 현지 통신사와 국제 네트워크 경로의 영향을 크게 받음	핸드셰이크 상태, 피크 시간대 변동, 패킷 손실과 라우팅 변화
중계	가까운 접속 지점으로 먼저 연결한 뒤 목표 출구로 전달	상태가 좋지 않은 일부 공용 네트워크 구간을 피할 수 있지만 접속 지점과 중계 경로가 모두 결과에 영향을 줌	접속 지점까지의 거리, 전달 안정성, 출구 부하와 귀환 경로
IEPL 전용 회선	접속 지점과 해외 구간 사이를 기업용 전용 회선으로 전달한 뒤 목표 네트워크에 연결	핵심 국제 구간이 일반 공용망 우회에 전적으로 의존하지 않아 보통 경로의 일관성을 중시함	접속 품질, 전용 회선 제공 범위, 출구 측 네트워크와 장애 전환

직접 연결이 항상 느린 것은 아니며, 중계가 항상 빠른 것도 아닙니다. 장치가 사용하는 네트워크에서 원격 접속 지점까지의 경로가 좋다면 직접 연결은 간결한 선택이 될 수 있습니다. 공용망의 국제 구간이 크게 흔들린다면 적절한 중계가 더 안정적일 수 있습니다. IEPL은 접속 지점 사이의 전달 방식을 설명할 뿐, 장치에서 최종 웹사이트까지 모든 구간이 전용 회선이라는 뜻은 아닙니다. 접속 지점까지의 경로와 출구에서 목표 서비스까지의 경로는 각각 해당 네트워크를 거칩니다.

주요 프로토콜 이름은 어떻게 이해해야 하나요?

프로토콜은 클라이언트와 서버가 데이터를 인증·암호화·캡슐화·전송하는 방식을 정합니다. 초보자는 프로토콜 이름을 속도 순위로 받아들일 필요가 없습니다. 네트워크의 UDP 허용 여부, 시스템의 관련 커널 지원, 전송 계층 설정, 서버 부하와 기반 회선에 따라 결과가 달라집니다. 아래 설명은 클라이언트 옵션을 이해하기 위한 기준이며, 프로토콜에 영구적인 우열을 부여하기 위한 것이 아닙니다.

Shadowsocks

Shadowsocks는 가벼운 암호화 프록시 프로토콜로, 설정에는 보통 서버 주소, 포트, 암호화 방식과 비밀번호가 포함됩니다. 구현 범위가 넓고 클라이언트 호환성이 좋아 일반적인 웹과 앱 분할 라우팅에 적합합니다. 다만 어떤 도메인을 직접 연결할지는 자체적으로 결정하지 않으며, 구체적인 분할 라우팅은 클라이언트 규칙이 처리합니다.

VMess와 VLESS

VMess에는 신원 인증과 시간 관련 메커니즘이 있어 장치 시간 오차로 핸드셰이크가 실패할 수 있습니다. VLESS는 프로토콜 자체를 더 간결하게 설계했으며, 실제 보안성과 전송 성능은 외부 TLS, 전송 방식, 서버 설정에 크게 좌우됩니다. VLESS를 볼 때는 프로토콜 이름만 확인하지 말고 TLS, WebSocket 또는 다른 전송 계층과 함께 구성되었는지도 살펴봐야 합니다.

Trojan

Trojan은 보통 TLS 위에서 동작하며 연결 형태가 일반적인 암호화 웹 트래픽과 유사합니다. 인증서, 도메인과 서버 설정이 올바르게 맞물려야 합니다. 인증서 만료, 잘못된 시스템 시간, 도메인 확인 문제 또는 중간 네트워크 간섭도 핸드셰이크 실패로 나타날 수 있으므로 문제 해결을 비밀번호 변경만으로 끝내서는 안 됩니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 모두 QUIC 및 UDP 기반 전송을 중시하며, 일정한 패킷 손실이나 지터가 있는 네트워크에서도 비교적 좋은 처리량과 반응성을 유지할 수 있습니다. 하지만 현재 네트워크가 UDP를 엄격하게 제한한다면 연결이 성립하지 않거나 정상 작동하는 TCP 경로보다 성능이 떨어질 수 있습니다. ‘웹 전송 프로토콜은 되지만 QUIC 계열 프로토콜은 되지 않는’ 상황이라면 노드 고장으로 단정하기보다 네트워크의 UDP 지원 여부를 먼저 확인하세요.

프로토콜	주요 전송 특징	확인할 사항	선택 기준
Shadowsocks	가벼운 암호화 프록시, 폭넓은 구현	암호화 방식, 포트, 인증 정보와 분할 라우팅 규칙	클라이언트 호환성과 간결한 설정을 우선 고려
VMess	신원 및 시간 관련 검증 포함	시스템 시간, 전송 계층, 신원 정보	검증된 서버 설정이 이미 있는 환경에 적합
VLESS	프로토콜 계층이 간결하며 TLS와 함께 사용하는 경우가 많음	TLS, 도메인, 전송 방식과 서버 측 매개변수	전체 전송 설정을 함께 보고 판단하며 이름만 보지 않음
Trojan	보통 TLS를 기반으로 연결	인증서, 도메인 확인, 시스템 시간과 포트	TLS 경로가 정상 작동하는 네트워크에 적합
Hysteria2	QUIC 및 UDP 기반, 효율적인 전송 중시	UDP 연결 가능 여부, 혼잡 제어와 현지 네트워크 제한	UDP 조건이 좋거나 네트워크 변동이 있는 환경에 적합
TUIC	QUIC 및 UDP 기반, 동시 전송 지원	UDP 연결 가능 여부, 인증서와 클라이언트 구현	플랫폼 지원과 현재 네트워크 조건을 함께 고려

프로토콜 결론: 네트워크 환경을 떠난 ‘최고의 프로토콜’은 없습니다. 먼저 클라이언트가 완전히 지원하고 안정적으로 핸드셰이크할 수 있는 프로토콜을 선택한 뒤 지속 전송과 앱 호환성을 비교하세요. 연결되지 않을 때는 UDP, TLS, 시스템 시간과 구독 설정을 확인하면 됩니다.

분할 라우팅·규칙·글로벌 및 직접 연결 모드

모드 설정은 트래픽이 어디로 이동할지 결정합니다. 많은 초보자가 ‘글로벌’을 장치의 모든 데이터가 터널로 들어가는 방식으로 이해하지만, 실제 범위는 클라이언트의 트래픽 처리 방식에 따라 달라집니다. 시스템 프록시만 사용하는 경우 시스템 프록시 설정을 따르는 앱만 처리됩니다. TUN을 켜면 보통 더 많은 시스템 계층 트래픽을 처리할 수 있지만 플랫폼 권한, 프로토콜 유형과 제외 규칙의 영향을 받을 수 있습니다.

규칙 모드

규칙 모드는 도메인, IP, 앱 또는 규칙 집합을 기준으로 트래픽의 이동 경로를 결정합니다. 국제 웹사이트는 선택한 노드를 거치게 하고, 현지 서비스는 직접 연결로 유지하며, 광고 도메인은 규칙에 따라 차단할 수도 있습니다. 일상적인 사용에 적합하지만 규칙이 최신 상태인지가 중요합니다. 도메인 소유권 변화, 콘텐츠 전송 네트워크 전환, 앱의 새로운 인터페이스 사용으로 잘못 판단할 수 있기 때문입니다.

글로벌 모드

글로벌 모드는 보통 클라이언트가 처리할 수 있는 트래픽을 현재 노드로 통일해 보냅니다. ‘규칙이 잘못 판단한 것인지’를 확인할 때 유용합니다. 규칙 모드에서 특정 서비스가 열리지 않지만 글로벌 모드에서는 열린다면 문제는 대개 규칙 매칭, DNS 결과 또는 앱이 올바르게 처리되지 않은 데 있습니다. 확인이 끝나면 규칙 모드로 돌아가 현지 서비스까지 원격 출구를 거치지 않도록 할 수 있습니다.

직접 연결 모드

직접 연결 모드는 원격 노드를 거치지 않습니다. 프록시를 잠시 중지하되 클라이언트는 계속 실행하거나, 문제가 현지 네트워크에서 비롯되었는지 확인할 때 사용합니다. 직접 연결과 프록시 모두 목표에 접근하지 못한다면 문제는 회선에만 있는 것이 아닐 수 있습니다. 현지 DNS, 브라우저 캐시, 시스템 네트워크 또는 목표 서비스 자체의 상태가 원인일 수도 있습니다.

시스템 프록시와 TUN

시스템 프록시는 주로 HTTP 또는 SOCKS 프록시 진입점을 설정합니다. 브라우저와 시스템 프록시를 따르는 앱은 쉽게 연결되지만 일부 앱은 이를 우회합니다. TUN은 가상 네트워크 인터페이스를 만들어 시스템 네트워크 계층에서 더 많은 트래픽을 포착하므로 프록시 설정을 읽지 않는 앱에 더 효과적입니다. 대신 관련 시스템 권한이 필요하고 방화벽, 기업용 네트워크 도구 또는 다른 가상 네트워크 인터페이스와 충돌할 수 있습니다.

DNS 누출과 확인 경로가 중요한 이유

도메인에 접속하기 전에 장치는 보통 DNS를 통해 해당 주소를 조회합니다. 서비스 트래픽은 원격 노드를 통과하지만 DNS 조회는 현지 네트워크의 확인 서버로 전송된다면 DNS 경로와 접속 경로가 일치하지 않을 수 있습니다. 그 결과는 개인정보 문제에 그치지 않을 수 있습니다. 목표 서비스가 현재 출구 지역에 맞지 않는 주소를 반환하거나, 분할 라우팅 규칙이 잘못된 확인 결과를 받을 수도 있습니다.

클라이언트의 ‘원격 DNS’, ‘로컬 DNS’, ‘암호화 DNS’, ‘스니핑’은 서로 다른 단계를 처리합니다. 원격 DNS는 보통 프록시가 필요한 도메인을 원격 경로로 확인하게 하고, 로컬 DNS는 현지 서비스와 직접 연결 도메인에 사용됩니다. 암호화 DNS는 장치와 확인 서버 사이의 조회 전송을 보호하며, 도메인 스니핑은 연결 데이터에서 도메인을 복원해 규칙이 경로를 판단하도록 돕습니다. 스니핑은 DNS의 대체 수단이 아니며 모든 앱의 확인 동작을 해결하지도 못합니다.

브라우저에 내장된 보안 DNS는 클라이언트가 지정한 시스템 확인 서버를 우회할 수도 있고, TUN이 올바르게 처리할 수도 있습니다. 구체적인 동작은 클라이언트 구현과 라우팅 설정에 따라 달라집니다. 같은 웹사이트의 결과가 브라우저와 다른 앱에서 다르다면 노드만 바꾸지 말고 브라우저 보안 DNS, 시스템 DNS와 클라이언트 로그를 각각 확인하세요.

✅ 프록시 도메인과 직접 연결 도메인이 규칙에 맞는 확인 경로를 사용하는지 확인하세요.
✅ 브라우저에서 독립적인 보안 DNS를 사용 중인지, 해당 요청이 클라이언트에서 처리되는지 확인하세요.
✅ DNS 설정을 바꾼 뒤 기존 캐시를 삭제하고 연결을 다시 설정하세요.
✅ 규칙 모드와 글로벌 모드를 비교해 문제가 도메인 매칭에서 비롯되었는지 판단하세요.
❌ 출구 주소가 바뀌었다는 사실만으로 DNS가 올바르게 처리되었다고 단정하지 마세요.

플랫폼마다 클라이언트 설정이 다른 이유

같은 구독을 여러 플랫폼에 가져와도 노드 이름은 같을 수 있지만 트래픽 처리 방식과 권한 모델은 다릅니다. Windows 클라이언트는 시스템 프록시와 TUN을 함께 제공하는 경우가 많고, macOS는 시스템 네트워크 확장 또는 프록시 설정에 의존합니다. Android는 시스템이 제공하는 VPN 인터페이스로 가상 네트워크를 만들며, iOS와 iPadOS는 시스템이 허용하는 네트워크 확장과 설정을 사용합니다.

따라서 ‘데스크톱에서는 되지만 모바일에서는 안 되는’ 현상이 반드시 구독 콘텐츠의 문제라는 뜻은 아닙니다. 모바일 운영체제는 백그라운드 활동을 제한할 수 있고, 네트워크를 바꾼 뒤 터널을 다시 설정해야 할 수도 있습니다. 데스크톱 운영체제는 방화벽, 백신, 기업 설정 또는 다른 가상 네트워크 어댑터의 영향을 더 쉽게 받을 수 있습니다. 플랫폼 차이는 앱별 분할 라우팅에도 나타납니다. 어떤 클라이언트는 프로세스나 앱별 선택을 지원하지만, 어떤 클라이언트는 도메인과 IP 규칙만 처리할 수 있습니다.

클라이언트의 코어 버전은 인식할 수 있는 프로토콜과 필드도 결정합니다. 오래된 코어가 새로운 Hysteria2, TUIC 또는 VLESS 전송 설정을 만나면 가져오기는 되지만 시작되지 않거나, 알 수 없는 필드를 그대로 무시할 수 있습니다. 구독을 업데이트한다고 클라이언트 코어까지 자동으로 업그레이드되지는 않습니다. ‘설정은 존재하지만 시작 오류가 발생하는’ 경우 클라이언트 버전과 프로토콜 지원 안내를 함께 확인하세요.

가져오기부터 연결까지의 전체 순서

사용자 패널에서 구독 링크를 복사하세요.문자를 직접 삭제하거나 수정하지 말고, 링크를 공개 온라인 변환 도구에 입력하지도 마세요.
플랫폼에 맞고 목표 프로토콜을 지원하는 클라이언트를 선택하세요.구독에 Hysteria2 또는 TUIC가 포함되어 있다면 클라이언트 코어가 해당 설정을 실제로 지원하는지 확인하세요.
‘URL에서 가져오기’ 또는 ‘구독 추가’를 사용하세요.가져오기가 끝나면 한 번 업데이트해 노드 목록이 정상적으로 불러와졌는지 확인하세요.
거리와 용도에 맞는 노드를 먼저 선택하세요.한 번의 지연 시간 측정 결과만으로 정렬하지 말고 직접 연결, 중계 또는 IEPL 회선 설명을 함께 참고하세요.
일상적인 사용에서는 먼저 규칙 모드를 선택하세요.일부 앱이 처리되지 않는다면 시스템 프록시, TUN 권한과 앱별 분할 라우팅을 확인하세요.
연결 후 실제 경로를 확인하세요.클라이언트에 ‘연결됨’이라고 표시되는지만 보지 말고 출구 위치, DNS 확인 결과와 목표 앱이 예상대로 작동하는지 확인하세요.
문제가 생기면 계층별로 확인하세요.먼저 구독을 업데이트하고, 노드를 바꾼 다음 규칙 모드와 글로벌 모드를 비교하고, 마지막으로 프로토콜·DNS·시스템 권한을 확인하세요.

초보자가 가장 자주 혼동하는 판단

노드가 많다고 프로토콜이 많은 것은 아닙니다.한 그룹의 노드가 모두 같은 프로토콜을 사용할 수도 있고, 하나의 출구에 여러 프로토콜 접속 지점이 제공될 수도 있습니다. 노드는 위치를 설명하고 프로토콜은 통신 방식을 설명하므로 서로를 대신할 수 없습니다.

연결되었다고 모든 앱이 처리되는 것은 아닙니다.클라이언트가 핸드셰이크에 성공했다는 것은 로컬 장치와 서버 사이의 통로가 만들어졌다는 뜻일 뿐입니다. 앱이 이 통로를 사용할지는 시스템 프록시, TUN, 앱 자체 프록시 설정과 분할 라우팅 규칙을 확인해야 합니다.

글로벌 모드라고 모든 기반 트래픽이 조건 없이 노드로 들어가는 것은 아닙니다.클라이언트는 시스템이 허용하고 자체적으로 지원하는 트래픽만 처리할 수 있습니다. 로컬 네트워크 접근, 제외된 앱, 특수 프로토콜 또는 다른 가상 인터페이스는 여전히 다른 경로를 사용할 수 있습니다.

전용 회선이라고 모든 구간이 종단 간 전용 네트워크인 것은 아닙니다.IEPL은 주로 접속 지점 사이의 전용 회선 전달을 설명하며, 장치에서 접속 지점까지와 출구에서 목표 서비스까지는 각각 다른 네트워크 경로를 사용합니다. 평가할 때는 회선 라벨 하나가 아니라 전체 경로를 확인해야 합니다.

지연 시간이 짧다고 지속 전송이 안정적인 것은 아닙니다.탐색 패킷은 매우 작지만 동영상, 다운로드와 회의는 회선을 계속 사용합니다. 패킷 손실, 지터, 혼잡 제어와 출구 품질이 단 한 번의 지연 시간보다 실제 체감 성능을 더 잘 설명하는 경우가 많습니다.

최종 암기: 구독은 ‘설정을 가져오는 것’, 노드는 ‘접속 지점 또는 출구를 선택하는 것’, 회선은 ‘어디를 거칠지 정하는 것’, 프로토콜은 ‘어떻게 전송할지 정하는 것’, 분할 라우팅은 ‘어떤 요청이 이를 사용할지 정하는 것’입니다. 문제가 생기면 이 계층을 따라 하나씩 확인하는 편이 설정을 무작정 바꾸는 것보다 효과적입니다.