이 VPN 용어 정리는 실제 사용 순서에 따라 설명합니다. 구독은 설정을 제공하고, 노드는 연결할 수 있는 지점이며, 프로토콜은 통신 방식을 정하고, 트래픽 분할은 어떤 요청을 프록시로 보낼지 결정합니다. 서로 역할이 다르므로 대체할 수 없습니다. 설정을 가져왔는데도 웹사이트가 열리지 않는다면 모든 문제를 회선 속도 탓으로 돌리지 말고 이 흐름을 따라 원인을 찾아보세요.
용어 한눈에 보기: 역할부터 구분하기
클라이언트 첫 화면에는 구독, 프록시, 정책 그룹, 모드가 함께 표시되는 경우가 많습니다. 이름이 비슷해도 기능은 다릅니다. 아래에서 각 항목의 역할을 확인하면 설정을 변경할 때 어느 부분을 조정하는지 알 수 있습니다.
| 용어 | 실제 역할 | 흔한 오해 |
|---|---|---|
| 구독 링크 | 클라이언트가 노드와 관련 설정을 가져오거나 업데이트하도록 합니다 | 웹사이트 주소도, 연결 터널 자체도 아닙니다 |
| 노드 | 서버 주소, 포트, 인증 정보, 프로토콜 등 연결 정보가 포함됩니다 | 지역 이름만으로 실제 경로나 플랫폼 이용 가능 여부를 알 수 없습니다 |
| 프로토콜 | 클라이언트와 서버의 통신 방식을 정합니다 | 새로운 이름이라고 해서 모든 네트워크에서 더 빠른 것은 아닙니다 |
| 정책 그룹 | 노드를 묶어 수동으로 선택하거나 설정에 따라 자동 선택하도록 합니다 | 그룹 이름이 실제 서버 이름과 일치하지 않을 수 있습니다 |
| 트래픽 분할 규칙 | 도메인, 주소, 프로세스 등의 조건에 따라 요청을 보낼 경로를 정합니다 | 노드를 선택해도 모든 앱이 해당 노드를 사용하는 것은 아닙니다 |
| 시스템 프록시 / TUN | 서로 다른 방식으로 앱의 트래픽을 클라이언트에 전달합니다 | 트래픽을 처리하는 방식과 글로벌·규칙 모드는 별개의 설정입니다 |
일상적으로 VPN이라고 부르는 말은 네트워크 프록시 서비스를 가리키기도 합니다. 엄밀히 말하면 시스템 수준의 VPN 터널과 앱 프록시는 작동 방식이 다릅니다. 어느 범위까지 적용되는지 확인하려면 제품 이름에 VPN이 들어 있는지만 보지 말고 클라이언트의 트래픽 처리 방식을 살펴보세요.
구독과 노드: 설정은 어디서 가져올까
구독 요금제와 구독 링크는 서로 다른 개념입니다
‘구독’은 요금 결제 관계를 뜻하기도 하고 설정을 업데이트하는 방식을 가리키기도 합니다. 월간 구독은 요금제 기간을 뜻하지만, 클라이언트의 구독 링크는 설정을 가져오는 주소입니다. 데이터 패키지를 구매한 뒤 구독 링크로 노드를 가져올 수도 있으므로 두 개념은 서로 모순되지 않습니다. 데이터 제공량, 유효 기간, 초기화 방식은 요금제 안내를 확인하세요.
구독에 서버 목록만 들어 있는 것은 아닙니다. 형식에 따라 정책 그룹, 트래픽 분할 규칙, DNS 설정이 포함되기도 하고 노드 매개변수만 제공되기도 합니다. 따라서 설정을 가져오는 데 성공했다는 것은 클라이언트가 설정을 받아들였다는 뜻일 뿐, 라우팅·DNS 확인·트래픽 처리가 모두 올바르다는 의미는 아닙니다.
노드에는 보통 서버 주소, 포트, 프로토콜, 인증 정보, 전송 매개변수가 포함됩니다. 클라이언트에 표시되는 지역 이름은 단순한 라벨입니다. 연결 지점의 지역, 트래픽의 최종 출구, 중간 전송 경로는 서로 다를 수 있으므로 이름만으로 웹사이트에 표시되는 출구 지역을 판단할 수 없습니다.
구독 링크에는 접속 정보가 포함될 수 있으므로 민감 정보로 취급하세요. 공개 포럼이나 스크린샷, 출처를 알 수 없는 구독 변환 사이트에 붙여 넣지 마세요. 유출이 의심되면 관리 페이지에서 제공하는 재설정 기능을 사용하고 클라이언트에 저장된 기존 주소도 업데이트하세요.
가져온 뒤 확인할 항목
- 관리 페이지에 로그인한 뒤 클라이언트 다운로드 페이지에서 지원 플랫폼과 설정 형식을 확인하고, 안내에 따라 구독 링크를 가져오세요.
- 클라이언트의 구독 또는 설정 화면에서 링크를 가져오세요. 형식 오류가 표시되면 노드 매개변수를 반복해서 바꾸기보다 사용 중인 클라이언트와 구독 유형이 맞는지 먼저 확인하세요.
- 업데이트를 실행하고 노드 목록이 표시되는지 확인하세요. 업데이트에 실패하면 링크가 온전한지, 현재 네트워크와 계정 상태는 정상인지 살펴보세요.
- 노드나 정책 그룹을 선택한 다음 용도에 맞게 시스템 프록시 또는 클라이언트가 지원하는 트래픽 처리 기능을 활성화하세요.
- 실제로 사용할 웹사이트나 앱을 열고 클라이언트 연결 로그에서 규칙이 적용되었는지, 어떤 경로로 나갔는지 확인하세요.
노드 목록이 비어 있다면 먼저 구독을 가져오는 과정부터 확인하세요. 목록은 정상인데 연결되지 않는다면 노드와 네트워크를 점검하세요. 이렇게 하면 ‘설정을 가져오지 못한 경우’와 ‘설정은 가져왔지만 연결되지 않는 경우’를 구분할 수 있습니다.
프로토콜: 통신 방식이지 속도 순위가 아닙니다
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC는 프록시 클라이언트에서 사용할 수 있지만 이름만 바꿔 서로 변환할 수는 없습니다. 클라이언트 엔진이 해당 프로토콜과 구체적인 매개변수를 지원해야 하며, 서버에도 이에 맞는 설정이 필요합니다.
- Shadowsocks: 암호화 프록시 프로토콜입니다. 클라이언트와 서버에서 호환되는 암호화 방식과 키 등의 매개변수를 사용해야 하며, 지원 여부는 버전에 따라 다를 수 있습니다.
- VMess: 인증 기능을 갖춘 프록시 프로토콜로, 여러 전송 방식을 함께 사용할 수 있습니다. 설정의 전송 유형과 보안 옵션은 서버와 일치해야 합니다.
- Trojan: 보통 TLS를 사용해 안전한 전송을 구성합니다. 인증 및 TLS 매개변수를 올바르게 설정해야 하며 도메인과 인증서 검증 설정을 임의로 끄거나 바꾸면 안 됩니다.
- VLESS: 경량 프록시 프로토콜입니다. 프로토콜 자체는 데이터를 암호화하지 않으므로 TLS, REALITY 등의 보안 방식을 함께 고려해야 합니다. 프로토콜 이름만으로 암호화 터널이라고 단정할 수 없습니다.
- Hysteria2와 TUIC: QUIC 기반 프록시 방식으로 UDP 통신을 사용합니다. UDP가 제한된 네트워크에서는 정상적으로 연결되지 않을 수 있습니다.
여기서는 개념을 설명할 뿐, VPNFK가 현재 모든 프로토콜을 제공한다는 의미는 아닙니다. 실제로 선택할 수 있는 항목은 관리 페이지의 설정과 클라이언트 지원 여부를 확인하세요. 일반 웹사이트에 접속할 수 있어도 현재 네트워크에서 선택한 프로토콜의 전송 방식이 허용된다는 뜻은 아닙니다.
선택 기준: 먼저 서버와 클라이언트가 모두 지원하는 설정을 선택한 뒤 실제 앱에서의 성능을 비교하세요. 프로토콜 이름만으로 속도, 안정성, 개인정보 보호 수준을 판단할 수는 없습니다. 전송 매개변수를 자주 직접 바꾸면 공식 설정에 따라 문제를 점검하는 것보다 오류가 생기기 쉽습니다.
회선 유형: 전용 회선, 중계, 직결
회선 유형은 트래픽이 어떤 네트워크 경로를 거치는지 설명하고, 프로토콜은 통신이 구성되는 방식을 설명합니다. 서로 다른 기준입니다. 같은 프로토콜도 여러 경로에 적용할 수 있고, 같은 경로에서 여러 프로토콜을 사용할 수도 있습니다.
직결은 보통 사용자가 해외 프록시 서버에 직접 연결하는 방식으로, 현지 통신사의 국제 출구와 라우팅 경로에 영향을 많이 받습니다. 여기서 ‘직결 노드’는 규칙의 DIRECT와 다릅니다. 전자는 여전히 프록시 연결일 수 있지만, 후자는 일반적으로 대상 요청을 프록시 출구로 보내지 않는다는 뜻입니다.
중계는 보통 먼저 한 지점에 연결한 뒤 해당 지점에서 출구로 트래픽을 전달하는 방식입니다. 전달 단계가 추가된다고 반드시 느려지는 것은 아닙니다. 첫 연결 지점과 이후 경로가 현재 네트워크에 더 적합하면 오히려 안정적일 수 있습니다. 반대로 중계라는 표시만으로 사용량이 많은 시간대의 품질을 보장할 수는 없습니다.
IEPL 전용 회선은 일반적으로 통신사가 특정 지점 사이의 전송에 제공하는 국제 이더넷 전용 회선을 뜻합니다. 사용자와 첫 연결 지점 사이, 출구와 대상 웹사이트 사이에는 다른 네트워크 구간이 남아 있습니다. 전용 회선이라는 이름은 경로의 일부를 설명할 뿐, 사용자부터 모든 웹사이트까지의 전체 연결 품질을 보장하지 않습니다.
회선을 비교할 때는 같은 기기와 비슷한 사용 환경에서 실제 작업을 해보세요. 웹페이지가 온전히 열리는지, 회의가 끊기지 않는지, 영상이 계속 버퍼링되는지 확인하면 됩니다. 클라이언트의 응답 시간 측정은 특정 조건에서의 결과일 뿐, 다운로드 처리량이나 패킷 손실, 앱에서의 사용 가능성을 대신 판단해 주지 않습니다. 노드 페이지에서 실제 회선 정보도 확인할 수 있습니다.
트래픽 분할과 글로벌 모드: 요청은 어디로 갈까
규칙 모드에서는 조건에 따라 출구 경로를 선택하며, 도메인·대상 주소·프로세스 등이 흔히 사용되는 조건입니다. 규칙은 보통 설정 순서대로 적용되므로 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 마지막 기본 규칙은 앞선 규칙에 일치하지 않은 요청을 처리합니다.
글로벌 모드는 보통 이미 클라이언트의 처리 범위에 들어온 트래픽을 선택한 프록시나 정책 그룹으로 보냅니다. 기기의 모든 앱이 자동으로 처리되는 것은 아닙니다. 시스템 프록시를 따르지 않는 앱은 글로벌 모드로 전환해도 프록시를 사용하지 않을 수 있습니다.
시스템 프록시와 TUN은 어떻게 다를까
시스템 프록시는 해당 설정을 지원하는 앱에 프록시 연결 지점을 제공합니다. 브라우저는 대개 시스템 프록시를 따르지만 게임, 명령줄 도구, 업무용 소프트웨어는 다르게 작동할 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 IP 트래픽을 처리하므로 일반적으로 적용 범위가 더 넓지만, 라우팅·제외 항목·시스템 권한·클라이언트 구현에 따라 달라집니다.
Windows와 macOS 클라이언트는 일부 트래픽 처리 기능을 활성화할 때 추가 권한이나 서비스 설치가 필요할 수 있습니다. 모바일 클라이언트는 시스템 VPN 인터페이스를 이용해 트래픽을 전달하는 경우가 많습니다. Linux에서는 데스크톱 프록시, 환경 변수, 앱 자체 설정도 함께 확인해야 합니다. 화면에 ‘연결됨’이라고 표시되어도 모든 프로세스가 같은 경로를 사용한다는 뜻은 아닙니다.
- ✅ 국내 웹사이트와 해외 웹사이트를 함께 이용하는 일상 업무: 출처가 명확한 규칙 설정을 우선 사용하고 필요한 앱의 트래픽이 예상한 출구로 나가는지 확인하세요.
- ✅ 특정 웹사이트만 문제가 있는 경우: 클라이언트를 다시 설치하기 전에 모드를 잠시 바꿔 비교하고 해당 도메인에 적용된 규칙을 확인하세요.
- ✅ 브라우저는 되지만 다른 소프트웨어는 안 되는 경우: 노드를 바꾸기 전에 트래픽 처리 범위와 소프트웨어 자체의 프록시 설정을 확인하세요.
- ❌ 글로벌 모드를 지역 제한의 만능 해결책으로 여기기: 플랫폼은 계정 지역, 출구 주소, 기타 신호를 근거로 이용을 제한할 수 있습니다.
AI 도구나 스트리밍 서비스를 이용할 때는 프록시 연결 여부와 플랫폼에서의 이용 허용 여부를 별도로 봐야 합니다. 연결에 성공해도 계정 자격, 콘텐츠 이용 권한, 지역별 규칙은 달라지지 않습니다.
DNS 누출과 자주 발생하는 연결 문제
DNS는 도메인 이름을 네트워크 주소로 변환합니다. DNS 요청은 시스템, 클라이언트 또는 앱 자체의 암호화 DNS 기능을 통해 전송될 수 있습니다. DNS 조회도 지정한 경로를 거치게 하려는 상황에서 요청이 실제로는 현지 네트워크의 DNS 서버로 전송된다면 흔히 말하는 DNS 누출이 발생할 수 있습니다.
암호화 DNS는 주로 DNS 서버까지의 조회 전송을 보호할 뿐, 웹사이트 접속을 자동으로 프록시 경유로 바꾸지는 않습니다. 반대로 프록시를 켰다고 모든 DNS 조회가 처리되는 것도 아닙니다. 클라이언트의 DNS 설정, 브라우저의 보안 DNS, 실제 라우팅을 함께 확인하세요.
검사 페이지에 현지 DNS 서버가 표시되면 문제 해결의 단서가 될 수 있지만, 트래픽 분할 설정도 함께 살펴봐야 합니다. 규칙에 따라 현지 서비스를 현지 DNS로 조회하도록 의도했을 수 있고, 제3자 검사 페이지가 모든 앱의 동작을 확인해 주는 것도 아닙니다. 검사 결과를 ‘일관되게’ 만들려고 DNS 설정 전체를 무작정 덮어쓰지 마세요.
용어를 추측하기보다 증상에 따라 원인 찾기
- 구독이 업데이트되지 않음: 주소가 온전한지, 계정을 사용할 수 있는지, 구독 형식이 맞는지, 현재 네트워크에서 구독 서비스에 접속할 수 있는지 확인하세요.
- 대부분의 노드에서 연결 실패: 시스템 시간, 네트워크 제한, 클라이언트 엔진 호환성을 확인한 다음 오류 로그에서 핸드셰이크나 인증 관련 메시지를 살펴보세요.
- 일부 앱에서만 실패: 앱이 프록시 처리 범위에 포함되는지, 적용된 규칙과 DNS 결과가 예상과 일치하는지 확인하세요.
- 특정 플랫폼에서만 지역 제한이 표시됨: 실제 출구와 플랫폼 규칙을 확인하세요. 해당 메시지만으로 프로토콜이 작동하지 않는다고 판단하지 마세요.
- 연결은 되지만 사용감이 불안정함: 백그라운드에서 대용량 작업을 일시 중지하고 비슷한 조건에서 회선을 바꿔 비교하세요. 프로토콜, DNS, 규칙을 한꺼번에 바꾸면 비교 기준을 잃게 됩니다.
고객 지원에 문의할 때는 운영체제, 클라이언트, 네트워크 환경, 선택한 회선, 재현 가능한 증상을 적어 주세요. 로그를 공유하기 전에 구독 주소, 인증 정보, 계정 정보를 가리고 확인하지 않은 설정 파일 전체를 보내지 마세요.
기억할 점: 구독은 ‘설정을 어디서 가져오는가’, 노드는 ‘어디에 연결하는가’, 프로토콜은 ‘어떻게 통신하는가’, 트래픽 분할은 ‘요청이 어떤 경로로 가는가’를 결정합니다. 이 순서대로 확인하면 모든 설정을 하나씩 바꾸는 것보다 원인을 찾기 쉽습니다.
실제 설정을 시작하려면 클라이언트 사용 가이드를 확인하세요. 원인을 알 수 없는 오류가 발생하면 민감 정보를 가린 증상을 정리해 고객 지원 페이지에서 문의할 수 있습니다. 먼저 문제가 발생한 단계를 파악한 뒤 설정을 바꾸거나 회선을 변경할지 결정하세요.