VPN초보자 가이드: 구독 링크·노드·프로토콜·분할 터널링 한눈에 보기

구독·노드·클라이언트: 관계부터 살펴보기

‘구독’은 결제 주기도 뜻할 수 있습니다. 월간 구독은 요금제 이용 기간이고, 구독 링크는 설정을 가져오는 기술적인 경로입니다. 링크를 새로 고치는 것은 보통 설정을 다시 가져오는 작업일 뿐, 갱신이나 트래픽 초기화를 의미하지 않습니다. 사용량과 만료 상태, 결제 방식은 계정 페이지에서 확인하세요.

같은 서비스라도 클라이언트마다 서로 다른 형식의 설정을 제공할 수 있습니다. 어떤 링크는 노드만 반환하고, 전체 설정에는 규칙과 DNS, 정책 그룹까지 포함되기도 합니다. 가져오기 전에 계정 페이지에서 해당 클라이언트용 항목을 선택하세요. 링크 모양이 비슷하다는 이유만으로 호환된다고 판단해서는 안 됩니다.

프로토콜과 암호화: 이름만으로 속도를 판단할 수 없습니다

프로토콜은 클라이언트와 서버가 데이터를 주고받고 연결을 인증하는 방식을 정합니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 프록시 클라이언트에서 볼 수 있지만, 서로 마음대로 바꿔 쓸 수 있는 선택지는 아닙니다. 서버에서 사용하는 프로토콜에 맞춰 클라이언트가 해당 프로토콜과 매개변수를 지원해야 합니다.

• Shadowsocks: 암호화 방식과 키를 맞춰야 하는 암호화 프록시 프로토콜입니다. 전통적인 의미의 기기 전체 VPN 터널은 아니며, 기기 전체의 트래픽을 처리하려면 보통 클라이언트의 가상 네트워크 인터페이스 기능이 필요합니다.
• VMess: 인증과 암호화 기능을 갖추고 있으며 다양한 전송 방식과 함께 사용할 수 있습니다. 프로토콜 이름뿐 아니라 전송 계층 관련 설정도 클라이언트에서 올바르게 읽어야 합니다.
• Trojan: 일반적으로 TLS로 통신을 보호합니다. 인증서 검증과 서버 이름 등의 매개변수를 올바르게 설정해야 하며, 연결을 위해 검증을 함부로 끄면 안 됩니다.
• VLESS: 자체적으로 콘텐츠를 암호화하지 않습니다. TLS, REALITY 등의 보안 계층과 해당 전송 설정을 함께 고려해야 하며, 이름이 다르다는 이유로 암호화 강도를 순위 매겨서는 안 됩니다.
• Hysteria2와 TUIC: QUIC 기반이며 UDP 전송에 의존합니다. 현재 네트워크에서 UDP를 제한한다면 클라이언트가 설정을 인식하더라도 연결이 제대로 되지 않을 수 있습니다.

이는 일반적인 개념 설명이며 VPNQO가 모든 프로토콜을 제공한다는 뜻은 아닙니다. 실제 지원 범위는 계정 페이지와 클라이언트 안내를 확인하세요. 노드 속도는 로컬 네트워크, 진입 지점의 혼잡도, 국제 경로, 출구 서버 부하, 대상 웹사이트의 상태에도 영향을 받으므로 프로토콜 이름만으로 판단할 수 없습니다.

‘코어’는 클라이언트 내부에서 프로토콜 처리와 규칙 실행을 담당하는 구성 요소입니다. 그래픽 인터페이스 이름이 비슷해도 서로 다른 코어나 버전을 사용할 수 있습니다. ‘알 수 없는 프로토콜’, ‘지원하지 않는 설정 항목’ 같은 오류가 나타나면 이해하기 어려운 설정을 직접 삭제하기보다 클라이언트 호환성부터 확인하세요.

IEPL 전용 회선·중계·직결 구분하기

회선 유형은 전송 경로를, 프로토콜은 통신 방식을 설명합니다. 서로 다른 개념입니다. 같은 프로토콜을 사용하는 노드라도 경로는 다를 수 있고, 전용 회선이 일부 구간에 쓰여도 기기부터 대상 웹사이트까지 모든 구간이 전용망이라는 뜻은 아닙니다.

직결: 기기에서 해외 진입 지점으로 직접 연결

여기서 ‘직결 회선’은 일반적으로 기기가 로컬 통신사의 공용 인터넷 경로를 통해 해외 서버에 직접 연결되는 것을 뜻합니다. 경로가 비교적 단순하지만 로컬 통신사의 국제 출구와 공용망 혼잡도에 따라 성능이 달라질 수 있습니다. 분할 터널링 규칙의 ‘직결’ 동작과는 다릅니다. 후자는 보통 요청을 프록시를 거치지 않고 보내는 방식입니다.

중계: 진입 지점으로 연결한 뒤 출구로 전달

중계 회선은 먼저 트래픽을 진입 서버로 보낸 다음 해외 출구 서버로 전달합니다. 중계를 통해 경로를 조정할 수 있지만, 전달 단계가 하나 더 있다고 해서 자동으로 빨라지거나 느려지는 것은 아닙니다. 진입 지점의 품질, 전달 경로, 혼잡 시간대의 부하를 함께 살펴야 합니다. ‘중계’라는 표시만으로 사용 경험을 판단할 수 없습니다.

IEPL: 경로의 일부 구간에 이더넷 전용 회선을 사용

IEPL은 국제 이더넷 전용 회선을 뜻합니다. 서비스에서 ‘IEPL 회선’이라고 하면 일반적으로 국제 구간에 이러한 회선을 사용한다는 의미이며, 구체적인 범위는 서비스 안내를 확인해야 합니다. 기기에서 진입 지점까지, 출구에서 대상 웹사이트까지는 공용 인터넷을 거칠 수도 있습니다. 따라서 혼잡이나 패킷 손실이 없거나 특정 플랫폼을 언제나 이용할 수 있다고 단정할 수 없습니다.

분할 터널링·전역 모드·TUN의 차이

규칙 모드는 일치하는 규칙에 따라 트래픽 경로를 선택하므로 여러 용도로 함께 사용하기 좋습니다. 예를 들어 로컬 서비스는 직결하고 국제 출구가 필요한 도메인은 프록시로 보낼 수 있습니다. 규칙에는 대개 적용 순서가 있어 앞선 규칙이 일치하면 뒤의 규칙은 적용되지 않을 수 있습니다. 일치하는 규칙이 없을 때는 설정의 기본 정책이 적용됩니다.

클라이언트의 전역 모드는 보통 이미 클라이언트에 들어온 트래픽을 선택한 프록시 정책으로 모두 전달한다는 뜻입니다. 기기 전체의 트래픽을 처리한다는 보장은 없습니다. 시스템 프록시를 사용하지 않는 앱은 요청이 클라이언트에 들어오지 않을 수 있으므로 전역 모드로도 처리할 수 없습니다.

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하는 방식으로, 더 많은 앱의 트래픽을 클라이언트로 전달할 수 있습니다. 프로토콜도 아니고 전역 모드와 같은 기능도 아닙니다. TUN과 규칙 모드는 함께 사용할 수 있습니다. 먼저 가상 인터페이스로 트래픽을 받아들인 뒤 규칙에 따라 경로를 나눕니다. 실제로 처리되는 범위는 시스템 권한과 라우팅, 제외 설정에 따라 달라집니다.

Android와 iOS 클라이언트는 시스템에서 제공하는 VPN 인터페이스로 트래픽을 전달하는 경우가 많아 상태 표시줄에 VPN 아이콘이 표시될 수 있습니다. 그렇다고 내부에서 전통적인 VPN 프로토콜을 사용한다는 뜻은 아닙니다. Windows, macOS, Linux에서는 시스템 프록시나 TUN 등 다양한 진입 방식을 사용하며, 구체적인 기능은 앱 구현에 따라 달라집니다.

DNS·출구 IP·누수 확인

DNS는 도메인 이름을 IP 주소로 변환하며, 이후 웹사이트에 연결하는 과정과는 별개입니다. DNS 요청은 시스템이나 브라우저, 클라이언트에서 보낼 수 있습니다. 웹페이지에 프록시로 접속하더라도 DNS 요청이 반드시 같은 경로를 거치는 것은 아닙니다.

DNS 누수는 일반적으로 DNS 요청이 예상한 터널이나 프록시 경로를 따르지 않고 원하지 않는 DNS 서버로 전달되는 상황을 뜻합니다. 규칙에서 로컬 도메인을 로컬 DNS로 확인하도록 설정했다면 로컬 DNS 서버가 나타나도 반드시 오류는 아닙니다. 누수 여부를 판단하기 전에 설정이 어떤 동작을 기대하는지 확인하세요. DNS 서버의 지역이 다르다는 이유만으로 누수라고 단정하지 마세요.

브라우저의 암호화 DNS, 시스템 DNS 설정, 클라이언트의 DNS 처리 기능은 서로 영향을 줄 수 있습니다. 문제를 확인할 때는 클라이언트 안내에서 권장하는 조합을 먼저 사용하고 여러 설정을 한꺼번에 바꾸지 마세요. 암호화 DNS는 DNS 요청의 전송을 보호하지만 웹 트래픽의 출구를 자동으로 바꾸지는 않으며 프록시 연결과도 다릅니다.

출구를 확인하려면 이 사이트의 IP 확인 페이지를 열어 해당 웹 요청의 출구 정보를 확인할 수 있습니다. 이 결과만으로 다른 앱이나 DNS, 다른 주소 체계의 트래픽도 같은 경로를 사용한다고 증명할 수는 없습니다. 네트워크에서 IPv6을 지원한다면 클라이언트의 IPv6 처리 또는 차단 정책도 확인하세요. IPv4만 확인하고 검증을 끝내지 마세요.

웹사이트에 표시되는 지역은 IP 데이터베이스 업데이트, 계정 지역, 캐시, 위치 권한의 영향도 받을 수 있습니다. 출구 IP가 바뀌어도 계정에 등록된 지역이 바뀌는 것은 아니며 대상 플랫폼에서 접속을 허용한다는 보장도 없습니다. 실제 페이지와 클라이언트 로그를 함께 확인하세요.

구독 가져오기부터 연결 확인까지

용어를 익혔다면 다음 순서에 따라 처음 연결을 설정할 수 있습니다. 메뉴 이름은 클라이언트마다 다르지만 기본 과정은 같습니다. 클라이언트 다운로드는 사용자 패널에서 확인하고, 플랫폼별 설정 방법은 사용 가이드를 참고하세요.

1. 클라이언트 호환성을 확인합니다. 운영체제와 클라이언트가 지원하는 프로토콜, 패널에서 제공하는 구독 형식을 확인하세요. 다운로드를 마쳤다고 연결 설정까지 준비된 것은 아닙니다.
2. 해당 클라이언트용 구독을 가져옵니다. 링크 가져오기 기능이나 패널에서 제공하는 가져오기 메뉴를 사용하세요. 노드 목록이 나타나는지 확인하고 형식 오류가 표시되면 먼저 가져오기 메뉴와 클라이언트가 맞는지 확인하세요.
3. 노드와 규칙 모드를 선택합니다. 용도에 맞는 지역부터 선택하고 무작위로 계속 바꾸지 마세요. 정책 그룹이 자동 선택으로 설정돼 있다면 실제로 사용 중인 노드를 확인하세요.
4. 트래픽 처리를 시작하고 권한을 확인합니다. 시스템 안내에 따라 네트워크 설정을 허용하세요. 데스크톱에서는 시스템 프록시나 TUN이 활성화됐는지 확인하고, 모바일에서는 앱을 전환한 뒤 시스템이 연결을 일시 중지하지 않도록 백그라운드 제한을 확인하세요.
5. 실제 요청을 확인합니다. IP 확인 페이지를 연 다음 실제로 사용하려는 웹사이트에 접속하세요. 결과가 다르면 클라이언트 스위치만 보지 말고 대상 도메인에 적용된 규칙을 확인하세요.

• ✅ 노드 목록이 업데이트됐고 선택한 노드에 뚜렷한 설정 파싱 오류가 없습니다.
• ✅ 트래픽 처리 방식을 확인했고 제외될 수 있는 앱이나 요청을 알고 있습니다.
• ✅ IP 확인 결과가 예상한 경로와 일치하며 대상 웹사이트에서 실제 작업을 할 수 있습니다.
• ✅ 로그를 공유하기 전에 구독 주소와 인증 정보, 개인 요청 정보를 가렸습니다.

연결되지 않을 때는 문제 구간별로 확인하세요

구독 업데이트 실패

먼저 로컬 네트워크와 패널 접속 상태, 링크가 온전한지 확인한 다음 계정 상태와 클라이언트의 형식 지원 여부를 살펴보세요. 복사 과정에서 공백이 들어갔거나 링크가 재설정됐거나 다른 클라이언트용 메뉴를 선택한 경우에도 가져오기에 실패할 수 있습니다. 실제 구독 링크를 모르는 사람에게 보내 변환을 맡기지 마세요.

노드 응답은 확인되지만 웹페이지가 열리지 않음

클라이언트의 연결 확인은 서버 연결이나 특정 테스트 주소만 점검할 수 있으며 모든 도메인과 전송 방식을 확인하는 것은 아닙니다. 시스템 프록시와 TUN, DNS, 규칙 적용 여부를 확인하세요. 특정 웹사이트만 실패한다면 사이트 자체 상태나 접속 제한도 고려해야 합니다.

웹페이지는 정상인데 특정 앱에서 문제가 발생함

먼저 앱이 시스템 프록시를 따르는지, UDP를 사용하는지, 분할 터널링에서 제외됐는지 확인하세요. 문제를 좁히기 위해 잠시 모드를 바꿔볼 수 있지만 전역 프록시를 장기적인 만능 해결책으로 사용하지 마세요. 앱이 정상화되면 일상적인 사용에 적합한 규칙 설정으로 되돌리세요.

연결은 됐지만 사용이 불안정함

같은 노드를 유지한 채 먼저 로컬 무선 네트워크의 변동과 백그라운드 제한을 확인한 다음 같은 지역의 다른 회선과 비교하세요. 한 번에 설정 하나만 바꾸고 문제가 발생한 상황과 오류 메시지를 기록하세요. 그래야 고객 지원 문의에 정보를 전달했을 때 회선과 클라이언트, 대상 서비스 중 어디에서 문제가 생겼는지 구분할 수 있습니다.