VPN용어 정리: 구독, 노드, 회선 유형, 프로토콜, 분할 터널링, 전역·규칙 모드 한 번에 정리

구독에서 연결까지: 클라이언트에서 만나는 용어의 등장 순서

클라이언트를 처음 열면 큰 스위치 하나가 아니라 목록 하나가 보입니다. 등장 순서를 정리해 두면 이후에 나오는 모든 용어가 제자리를 찾습니다.

전체 흐름은 이렇습니다: 구독 링크 받기 → 클라이언트에 가져오기 → 클라이언트가 구독 주소를 요청해 노드 목록 받기 → 목록에서 노드 하나 선택 → 클라이언트가 분할 터널링 규칙에 따라 어떤 트래픽을 이 노드로 보낼지 결정 → 연결 수립. 아래에서 이 순서대로 하나씩 풀어 봅니다.

구독 링크는 파라미터가 붙은 URL로, 서버 쪽 구성 파일을 가리킵니다. 클라이언트가 이 주소를 요청하면 여러 노드가 담긴 구성이 내려오고, 각 노드에는 서버 주소, 포트, 프로토콜, 암호화 파라미터가 들어 있습니다. 계정 자격 증명도 함께 담겨 있어 구성이자 열쇠입니다.

노드는 목록의 한 줄로, 접속할 수 있는 서버 입구 하나에 해당합니다. 노드 이름에는 HK, JP, SG, US 같은 접두사가 자주 붙는데, 이는 해당 회선의 출구가 어느 국가·지역에 있는지를 뜻하며 트래픽이 그 나라 안에서만 돈다는 의미는 아닙니다.

지연 시간은 클라이언트가 노드에 한 번 프로브를 보내 측정한 왕복 밀리초 값으로, 정렬 참고용으로만 적합합니다. 프로브 패킷은 아주 작고 실제 트래픽 경로와 완전히 같지 않을 수 있으므로 지연이 낮다고 다운로드가 빠른 것은 아닙니다. 대역폭과 트래픽은 또 다른 축으로, 요금제의 트래픽 한도와 회선 자체의 용량에 따라 결정됩니다.

노드와 회선 유형: 직결, 중계, IEPL 전용선의 차이

노드 이름은 출구가 어디인지만 알려 주고, '어떻게 가는지'는 알려 주지 않습니다. 내 기기에서 출구 서버까지의 구간을 업계에서는 회선이라고 부르며, 흔히 세 가지 방식으로 구성합니다.

직결: 클라이언트가 출구 서버의 공인 주소에 바로 접속합니다. 경로가 가장 짧고 비용도 가장 낮지만, 국제 구간이 공용 인터넷을 지나기 때문에 저녁 피크에 국제 회선이 혼잡해지면 지연 변동이 두드러집니다.

중계: 클라이언트가 먼저 가까운 중계 서버에 접속하고, 그 서버가 출구로 트래픽을 전달합니다. 국제 구간을 최적화된 경로로 지날 수 있어 보통 직결보다 안정적이며, 대신 한 단계 포워딩이 늘어납니다.

IEPL 전용선: IEPL은 International Ethernet Private Line의 약자로, 통신사급 점대점 전용선을 뜻합니다. 국제 구간이 공용 인터넷 출구를 거치지 않아 패킷 손실과 지터가 더 작고 비용도 가장 높아, 주로 안정성이 중요한 상황에 쓰입니다.

MeyeVPN의 회선 기준은 다음과 같습니다. 노드를 고를 때 회선 유형으로 먼저 걸러 낸 뒤, 원하는 지역에서 지연이 낮은 몇 개를 선택하세요. 전체 지역과 회선 분포는 노드 페이지에서 확인할 수 있습니다.

프로토콜: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC는 각각 무엇인가

프로토콜이 결정하는 것은 세 가지입니다: 클라이언트와 서버가 어떻게 핸드셰이크하는지, 어떤 방식으로 암호화하는지, 데이터가 TCP로 가는지 UDP로 가는지. 회선 유형과는 다른 개념입니다. 회선은 '패킷이 어떻게 가는지', 프로토콜은 '패킷이 어떤 모습인지'를 다룹니다. 사용자 입장에서는 프로토콜이 구독으로 자동 내려오므로 보통 직접 고를 필요가 없습니다.

• Shadowsocks: 경량 프록시 프로토콜로, SOCKS5에 자체 암호화(AEAD 계열, 예: chacha20-ietf-poly1305, aes-256-gcm)를 한 겹 더한 구조입니다. 오버헤드가 작아 공유기처럼 성능이 제한된 기기에 적합합니다.
• VMess: V2Ray 프로젝트의 자체 프로토콜로, UUID로 사용자를 식별하고 WebSocket, gRPC, HTTP/2 등 다양한 전송 방식을 지원합니다. 초기 구현은 타임스탬프 검증에 의존해서 클라이언트 시스템 시간이 크게 어긋나면 핸드셰이크가 바로 실패합니다. 초보자가 '연결이 안 된다'고 느끼는 흔한 원인 중 하나입니다.
• VLESS: VMess의 경량화 후속 프로토콜로, 자체 암호화를 내장하지 않고 TLS나 전송 계층의 보호에 의존합니다. 구조가 더 단순하고 오버헤드가 낮아 XTLS, REALITY 같은 방식과 자주 함께 쓰입니다.
• Trojan: 프록시 세션을 표준 HTTPS 트래픽으로 위장하며, 보통 443 포트에서 동작합니다. 겉보기에는 일반 사이트 접속과 같습니다.
• Hysteria2: QUIC(UDP) 기반 프로토콜로 혼잡 제어를 자체 내장해 패킷 손실이 많거나 회선이 불안정한 환경에서 더 안정적입니다. UDP에 의존하기 때문에 UDP를 제한하는 네트워크에서는 연결되지 않습니다.
• TUIC: 역시 QUIC 기반이며 멀티플렉싱과 연결 마이그레이션을 지원해 Wi-Fi에서 셀룰러로 전환할 때 연결이 끊기기 어렵습니다.

분할 터널링 규칙, 전역과 규칙 모드: 세 가지 모드 선택법

클라이언트 상단에는 보통 전역, 규칙, 직접 연결 세 가지 모드가 있으며, 이들은 한 가지를 결정합니다. 어떤 트래픽이 노드를 거치는가입니다.

• 전역 모드: 국내 사이트를 포함한 모든 트래픽을 노드로 보냅니다. 동작이 예측 가능하지만 국내 사이트가 멀리 돌아가 로딩이 느려지고, 일부 서비스는 출구 주소가 바뀌어 본인 확인을 요구할 수 있으며, 트래픽 소모도 더 빠릅니다.
• 규칙 모드: 내장된 분할 터널링 규칙에 따라 하나씩 매칭합니다. 일반적인 규칙 세트는 도메인과 IP 대역으로 나뉘어 국내 도메인과 국내 IP는 직접 연결하고, 해외 접속이 필요한 트래픽은 노드로 보냅니다. 데스크톱 클라이언트는 프로세스 단위로도 지정할 수 있습니다.
• 직접 연결 모드: 모든 트래픽이 노드를 거치지 않습니다. 프록시를 잠시 끄되 클라이언트는 실행 상태로 두는 것과 같아 비교 점검에 편리합니다.

분할 터널링 규칙은 바로 이 매칭 로직 자체입니다. 'X에 매칭되면 Y로 보낸다'는 항목들의 모음으로, 도메인 접미사, IP 대역, 프로세스 이름, 그리고 직접 추가한 사용자 규칙을 포함합니다. 규칙 모드의 경험이 좋은지는 규칙 세트가 얼마나 최신으로 유지되는지에 크게 좌우됩니다.

• ✅ 일상 브라우징과 업무: 규칙 모드를 사용해 국내는 직접 연결, 해외 접속이 필요한 트래픽은 노드로
• ✅ 브라우저만 노드를 거치게 하려면: 데스크톱의 프로세스 분할 터널링 또는 모바일의 앱별 프록시 사용
• ✅ 특정 사이트가 해외 출구에서 어떻게 동작하는지 확인할 때: 잠시 전역 모드로 전환하고, 확인 후 규칙 모드로 복귀
• ❌ 전역 모드를 켜 둔 채 국내 영상을 오래 시청: 트래픽이 멀리 돌아 로딩이 느려짐
• ❌ '규칙 모드가 작동하지 않는다'를 '서비스 고장'으로 단정: 먼저 대상 도메인이 규칙에 의해 직접 연결로 판정됐는지 확인

DNS 누출과 구독 업데이트: 놓치기 쉬운 두 가지

DNS 누출은 트래픽은 이미 노드를 거치는데 도메인 조회 요청은 여전히 로컬 통신사 DNS 서버로 나가는 상황을 말합니다. 결과는 두 가지입니다. 조회 결과가 오염되어 '분명히 연결됐는데 열리지 않는' 경우가 생기고, 조회 기록을 통해 어떤 도메인에 접속하는지가 드러납니다.

클라이언트에서 흔히 쓰는 처리 방식은 두 가지입니다. 하나는 프록시가 DNS 조회를 맡아 노드 쪽에서 해석한 뒤 결과를 돌려주는 방식이고, 다른 하나는 암호화 DNS(DoH / DoT)를 사용해 평문 조회를 암호화 전송으로 바꾸는 방식입니다. 둘 다 조회 요청이 로컬 DNS에 남지 않게 하는 것이 목적입니다.

확인 방법: 노드에 연결한 뒤 DNS 누출 검사 페이지를 열어, 페이지에 표시되는 해석 서버가 로컬 통신사 서버인지 보세요. 여전히 그렇다면 DNS 인수가 적용되지 않은 것이므로 클라이언트 설정에서 '원격 DNS'를 켜거나 암호화 DNS 주소를 직접 지정하면 됩니다.

구독 업데이트는 또 하나의 쉽게 잊는 작업입니다. 서버 쪽에서 노드를 추가·삭제하거나 회선을 조정해도 클라이언트는 자동으로 알지 못하므로 구독을 다시 받아와야 합니다. 매주 한 번 수동으로 업데이트하거나, 클라이언트에서 자동 업데이트를 켜 두는 것을 권합니다(보통 매일 또는 매주로 설정 가능). 특정 지역에 분명히 노드가 있는데 계속 보이지 않는다면 먼저 구독을 업데이트한 뒤 점검하세요.

시작 전 점검 목록과 자주 묻는 질문

앞의 내용을 바로 따라 할 수 있는 점검 목록으로 압축했습니다:

• ✅ 구독을 가져온 뒤 먼저 수동으로 한 번 업데이트해 노드 목록이 최신인지 확인
• ✅ 모바일에서는 클라이언트를 시스템 배터리 최적화 예외 목록에 추가해 백그라운드 정리로 끊기지 않게
• ✅ 데스크톱에서는 클라이언트에 가상 네트워크 어댑터 생성 또는 시스템 프록시 설정 권한이 있는지 확인
• ✅ 연결 후 DNS 누출 검사를 한 번 해서 조회가 로컬 통신사로 새지 않는지 확인
• ❌ 구독의 프로토콜 파라미터를 직접 수정하지 않기 — 잘못 고치면 바로 연결되지 않습니다
• ❌ 구독 링크를 공개된 곳에 올리지 않기, 캡처할 때도 전체 링크가 보이지 않게

노드가 많을수록 좋은가요?

아닙니다. 노드가 많다는 것은 선택할 수 있는 출구가 많다는 뜻이지만, 실제 경험을 좌우하는 것은 회선 유형과 해당 시간대의 혼잡도입니다. 수십 개 노드를 반복해서 시험하기보다 회선 유형으로 먼저 걸러 내고, 지연이 낮은 몇 개 중에서 안정적인 하나를 골라 오래 쓰는 편이 낫습니다.

지연이 낮은 노드가 항상 더 빠른가요?

꼭 그렇지는 않습니다. 지연은 프로브로 측정한 왕복 시간으로 응답이 빠른지를 보여 줄 뿐이고, 다운로드 속도는 회선 용량, 출구 대역폭, 상대 서버의 제한에도 영향을 받습니다. 영상이 끊기는지와 웹페이지가 빠른지는 애초에 다른 문제입니다.

전역 모드와 규칙 모드 중 어느 쪽이 더 안전한가요?

둘 다 암호화 강도와는 무관하고 차이는 트래픽 경로에만 있습니다. 일상에서는 규칙 모드를 쓰면 국내 트래픽이 직접 연결되어 오히려 국제 구간을 덜 지납니다. 특정 사이트가 해외 출구에서 어떻게 동작하는지 잠시 확인해야 할 때만 전역 모드로 전환하세요.

프로토콜을 직접 골라야 하나요?

보통은 필요 없습니다. 구독에 각 노드의 프로토콜이 이미 지정되어 있고 클라이언트가 자동으로 사용합니다. 사용 중인 네트워크가 특정 전송(예: UDP)을 제한할 때만 다른 프로토콜의 노드로 바꾸면 됩니다.