먼저 핵심부터 살펴보겠습니다. 구독은 설정을 가져오는 수단이고, 노드는 연결 지점이며, 회선은 네트워크 경로를 설명합니다. 프로토콜은 연결 방식을 정하고, 트래픽 분산은 요청을 어느 경로로 보낼지 결정합니다. 차이를 알면 설정을 무작정 바꾸지 않고 순서대로 가져와 연결할 수 있습니다.
일상적인 대화에서는 프록시 클라이언트도 VPN이라고 부르지만, 실제로 처리하는 범위는 다를 수 있습니다. 시스템 프록시는 프록시 설정을 따르는 앱에만 적용될 수 있고, 가상 네트워크 어댑터 모드는 더 많은 트래픽을 처리할 수 있지만 라우팅 및 제외 규칙의 영향을 받습니다. 따라서 ‘연결됨’ 표시만으로 모든 앱이 같은 출구를 이용한다고 단정할 수는 없습니다.
구독과 노드: 설정을 가져오는 주소와 설치 파일은 다릅니다
요금제에서 말하는 ‘구독’은 보통 서비스 이용 기간을 뜻하고, 클라이언트에서 말하는 ‘구독’은 설정을 가져오는 출처를 뜻합니다. 혼동하기 쉬운 부분입니다. 구독 링크는 설정을 가져올 수 있는 주소입니다. 클라이언트가 이를 읽어야 사용 가능한 노드와 인증 방식, 적용 가능한 규칙을 확인할 수 있습니다. 클라이언트 다운로드 주소가 아니며, 브라우저에서 열면 자동으로 연결되는 웹페이지도 아닙니다.
노드는 설정에 포함된 연결 옵션으로, 보통 서버 주소, 포트, 인증 정보와 프로토콜 매개변수로 구성됩니다. 화면에 표시되는 지역명은 선택을 돕기 위한 것이지 네트워크 경로를 증명하는 정보는 아닙니다. 같은 지역에도 연결 지점과 출구 조합이 다를 수 있고, 이름이 달라도 일부 기반 시설을 공유할 수 있습니다.
구독을 업데이트한다는 것은 서비스 측에서 제공하는 설정을 다시 가져오는 것입니다. 요금제를 변경하거나 클라이언트 데이터를 초기화하는 작업은 아닙니다. 서비스에서 노드를 조정하면 이전 설정이 작동하지 않을 수 있으며, 업데이트를 통해 변경 사항을 반영할 수 있습니다. 다만 로컬 네트워크 문제까지 해결해 주지는 않습니다. 구독을 직접 수정해 노드를 추가했다면 다음 업데이트 때 변경 내용이 덮어써지는지도 확인하세요.
링크에 계정 식별 정보나 액세스 토큰이 포함될 수 있습니다. 전체 링크나 QR 코드, 설정 파일을 공개하지 마세요. 고객 지원에 화면을 보낼 때도 해당 정보를 가리고, 이미 노출됐다면 계정 관리 화면에서 재설정할 수 있는지 확인하거나 문의를 접수하세요.
회선: IEPL 전용 회선, 중계, 직접 연결
회선은 데이터가 기기에서 출구까지 이동하는 경로를 설명합니다. 직접 연결은 보통 클라이언트가 해외 서버에 바로 연결하는 방식입니다. 중계는 경로에 전달용 연결 지점을 추가합니다. IEPL은 통신사가 제공하는 국제 이더넷 전용 회선 서비스입니다. 실제 서비스에서는 경로 일부 구간에만 전용 회선을 사용할 수 있으므로, 요금제에 ‘전용 회선’이라고 표시되어도 기기부터 대상 웹사이트까지 전체 경로를 단독으로 사용한다고 볼 수는 없습니다.
| 용어 | 일반적인 의미 | 이 표현만으로 단정할 수 없는 점 |
|---|---|---|
| 직접 연결 | 클라이언트가 서버에 직접 연결하며, 네트워크 간 경로는 로컬 통신사의 라우팅에 영향을 받습니다. | 반드시 빠르거나 불안정하다는 뜻은 아닙니다. |
| 중계 | 먼저 전달용 연결 지점에 접속한 뒤, 해당 지점이 다음 서버로 데이터를 전달합니다. | 연결 지점이 추가되어도 전체 경로가 전용 회선을 사용한다는 뜻은 아닙니다. |
| IEPL 전용 회선 | 전송 구간 일부에 통신사가 제공하는 전용 이더넷 연결을 사용합니다. | 로컬 접속 구간, 출구, 대상 웹사이트 모두 혼잡하지 않다는 보장은 없습니다. |
‘입구’와 ‘출구’도 구분해야 합니다. 입구는 기기가 처음 연결하는 지점이고, 출구는 대상 웹사이트에 표시되는 접속 출처입니다. 출구 지역은 콘텐츠 목록이나 계정 위험 관리에 영향을 줄 수 있지만, 웹사이트는 계정 지역 등 다른 정보도 참고합니다. 회선 이름만으로 스트리밍 서비스를 이용할 수 있다고 단정할 수 없으므로 실제 접속을 확인해야 합니다.
프로토콜: 연결 방식이 속도 순위를 뜻하지는 않습니다
프로토콜은 클라이언트와 서버가 데이터를 주고받고, 신원을 확인하며, 전송을 보호하는 방식을 정합니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 널리 쓰이는 프로토콜 이름이지만, 아무 클라이언트에서나 서로 바꿔 쓸 수 있는 옵션은 아닙니다. 클라이언트의 코어와 버전, 서버 설정이 서로 맞아야 합니다.
Shadowsocks는 암호화 프록시 프로토콜로, 양쪽에서 호환되는 알고리즘을 사용해야 합니다. VMess는 자체 인증 및 암호화 방식을 갖추고 있습니다. Trojan은 보통 TLS로 연결을 보호합니다. VLESS 자체에는 데이터 암호화 기능이 없으며, TLS 같은 보안 전송 방식과 함께 사용하는 경우가 많습니다. 따라서 프로토콜 이름만 보고 전체 연결의 보호 방식이 정해졌다고 판단할 수는 없습니다.
Hysteria2와 TUIC은 QUIC 기반이며, 하위 전송 계층에서 UDP를 사용합니다. 일부 네트워크에서 UDP를 제한하면 연결이 정상적으로 설정되지 않을 수 있습니다. 반대로 UDP 기반이라고 항상 더 빠른 것도 아닙니다. 혼잡 제어, 로컬 패킷 손실, 서버 자원과 경로 품질이 모두 사용 경험에 영향을 줍니다. 초보자는 서비스에서 명확히 지원하는 설정을 우선 사용하고, 프로토콜이나 전송 계층, 인증서 옵션을 무작정 바꾸지 않는 것이 좋습니다.
클라이언트에서 TLS 인증서 오류가 발생하면 시스템 시간, 서버 이름, 설정의 유효 기간부터 확인하세요. 오류를 없애려고 ‘인증서 검증 건너뛰기’를 함부로 켜지 마세요. 원격 서버의 신원을 확인하는 보안이 약해질 수 있습니다. 이 글은 업계 용어를 설명하며, JiuVPN이 위 프로토콜을 모두 제공한다는 의미는 아닙니다.
트래픽 분산과 모드: 규칙을 확인한 뒤 출구를 선택합니다
트래픽 분산은 도메인, 주소 또는 기타 조건에 따라 요청을 어디로 보낼지 정하는 기능입니다. 일반적인 처리 방식에는 직접 연결, 프록시, 차단이 있습니다. 규칙 모드에서는 설정된 규칙을 순서대로 확인하며, 보통 먼저 일치하는 유효 규칙이 적용됩니다. 일치하는 규칙이 없으면 기본 정책을 따릅니다. 규칙 세트는 재사용할 수 있는 조건 목록이고, 정책 그룹은 후보 노드 중 하나를 선택합니다. 두 기능은 서로 다릅니다.
‘글로벌 모드’는 보통 프록시 코어로 들어오는 요청을 지정된 정책으로 일괄 처리합니다. ‘규칙 모드’는 규칙에 따라 요청을 각각 처리합니다. 다만 글로벌 모드라고 해서 기기 전체의 트래픽을 처리하는 것은 아닙니다. 코어로 들어오지 않은 앱 트래픽에는 영향을 주지 않을 수 있습니다. ‘글로벌’과 ‘가상 네트워크 어댑터’는 해결하는 문제가 다릅니다. 전자는 트래픽을 배분하는 방식을, 후자는 어떤 트래픽을 받아들일지를 결정합니다.
평소에는 서비스에서 제공하는 규칙 설정을 먼저 사용하고, 특정 웹사이트에 접속할 수 없을 때 해당 요청에 어떤 규칙이 적용됐는지, 어떤 출구를 사용했는지 확인하세요. 글로벌 모드와 규칙 모드를 계속 바꾸면 노드 문제와 트래픽 분산 오류를 구분하기 어려워집니다. 설정을 바꿀 때는 한 번에 하나만 변경하고, 원래 설정을 남겨 두면 원인을 파악하기 쉽습니다.
DNS와 유출: 접속이 되더라도 DNS 확인 경로를 점검하세요
DNS는 도메인 이름을 IP 주소로 변환합니다. 프록시 연결과 DNS 조회가 항상 같은 경로를 이용하는 것은 아닙니다. 앱이 시스템 DNS를 사용할 수도 있고 자체 암호화 DNS를 사용할 수도 있습니다. 클라이언트에 따라 원격 DNS 조회나 가상 주소 방식을 쓰기도 합니다. 웹페이지가 열린다는 사실은 접속 경로가 작동한다는 뜻일 뿐, DNS 조회가 예상한 경로로 이루어졌음을 증명하지는 않습니다.
DNS 유출은 일반적으로 조회가 예상한 경로를 통하지 않아, 조회 정보를 받아서는 안 되는 쪽에 도메인 요청이 노출되는 상황을 말합니다. 점검할 때는 테스트 웹페이지에 표시된 지역만 보고 결론 내리지 말고 클라이언트, 시스템, 브라우저의 DNS 설정을 함께 확인하세요. 트래픽 분산 설정에 따라 직접 연결할 도메인을 로컬에서 조회하도록 의도한 경우도 있으므로, 이를 잘못된 설정과 구분해야 합니다.
브라우저의 암호화 DNS는 DNS 조회의 전송을 보호할 뿐, 웹페이지 요청까지 자동으로 프록시를 통하게 하지는 않습니다. DNS 오류가 발생하면 먼저 서비스에서 권장하는 DNS 설정으로 되돌린 뒤 브라우저에 별도 설정이 있는지 확인하세요. 출처가 불분명한 규칙과 DNS 주소를 한꺼번에 추가하지 마세요.
클라이언트 가져오기: 사용자 패널에서 연결 확인까지
먼저 호환되는 클라이언트를 선택한 다음 구독을 가져오세요. 모든 소프트웨어가 같은 구독 형식을 지원하는 것은 아닙니다. 링크를 열 수 있다고 해서 링크에 포함된 설정까지 읽을 수 있는 것은 아닙니다. ‘형식 오류’가 표시되면 링크 매개변수를 바꾸기보다 사용자 패널에서 제공하는 가져오기 방법을 먼저 확인하세요. JiuVPN 클라이언트와 구독 메뉴는 로그인 후 이용할 수 있습니다.
- 플랫폼과 다운로드 출처를 확인하세요. 서비스에서 제공하는 다운로드 메뉴에서 호환 클라이언트를 받고, 해당 플랫폼의 안내에 따라 설치하세요. 다른 코어용 설정 파일을 현재 클라이언트에 그대로 덮어쓰지 마세요.
- 호환되는 구독을 가져오세요. 사용자 패널에서 구독 메뉴를 찾아 클라이언트에 맞는 가져오기 방식을 선택하세요. 링크를 복사해 가져올 때는 전체 주소를 구독 주소 입력란에 붙여넣고, 단일 노드 편집란에는 입력하지 마세요.
- 업데이트한 뒤 결과를 확인하세요. 노드 목록이 표시되는지 확인합니다. 목록이 비어 있다면 구독 가져오기 또는 파싱 오류를 살펴보고, 로컬 네트워크와 링크 전체 복사 여부, 계정 상태를 확인하세요. 연결 버튼만 반복해서 누르지 마세요.
- 노드와 모드를 선택하세요. 기본 규칙과 사용할 노드 하나로 먼저 연결해 보세요. 시스템에서 네트워크 설정 추가나 가상 네트워크 어댑터 권한을 요청하면, 방금 설치한 클라이언트에서 보낸 안내인지 확인하세요.
- 실제 앱에서 확인하세요. 대상 웹사이트나 앱을 열고 클라이언트 연결 기록에서 적용된 규칙과 출구를 확인하세요. 브라우저는 작동하지만 다른 앱이 작동하지 않는다면 먼저 트래픽이 처리되는 범위를 확인하세요.
Windows, macOS, Linux에서는 시스템 프록시와 가상 네트워크 어댑터를 통한 연결 방식을 흔히 사용하며, 후자는 추가 권한이나 구성 요소가 필요할 수 있습니다. Android는 보통 시스템 VPN 인터페이스로 트래픽을 처리하고, iOS 클라이언트는 대개 시스템 네트워크 설정을 추가해야 합니다. 메뉴 구성은 클라이언트마다 다르며, 같은 플랫폼의 모든 소프트웨어가 동일한 기능을 제공하는 것은 아닙니다.
JiuVPN의 Windows, Android, macOS, Linux 클라이언트는 로그인 후 다운로드할 수 있으며, iOS 링크는 유효한 요금제가 있어야 이용할 수 있습니다. 다운로드 메뉴와 구독 메뉴는 용도가 다르므로 소프트웨어를 받은 뒤에도 안내에 따라 설정을 완료해야 합니다. 사용자 패널에서 클라이언트 받기, 자세한 방법은 플랫폼별 가이드를 참고하세요.
연결 문제 확인: 원인을 찾은 뒤 설정을 조정하세요
‘노드 연결 테스트에 성공했다’고 해서 서비스가 정상 작동한다고 단정할 수는 없습니다. 클라이언트 테스트는 연결 성립 여부나 테스트 주소 접속만 확인할 수 있습니다. 화상 회의, 웹페이지, 파일 동기화는 서로 다른 경로와 전송 방식을 사용할 수 있습니다. 먼저 구독 업데이트 실패, 연결 실패, 특정 앱에서만 발생하는 문제 중 어디에 해당하는지 구체적으로 확인하세요.
- ✅ 먼저 프록시 연결을 끊고 로컬 네트워크가 작동하는지 확인한 다음, 클라이언트에서 구독 업데이트가 완료됐는지 살펴보세요.
- ✅ 선택한 정책 그룹이 직접 연결, 차단 또는 작동하지 않는 옵션이 아니라 실제로 사용할 수 있는 노드를 가리키는지 확인하세요.
- ✅ 대상 요청에 적용된 규칙과 출구를 확인해 회선 문제와 규칙 적용 오류를 구분하세요.
- ✅ 시스템 프록시, 가상 네트워크 어댑터, 앱 설정을 대조해 대상 앱의 트래픽이 클라이언트로 들어가는지 확인하세요.
- ✅ 문의를 접수할 때는 플랫폼, 클라이언트, 오류 메시지와 재현 방법을 설명하고 접속 정보는 가리세요.
- ❌ 네트워크 트래픽을 처리하는 클라이언트를 여러 개 동시에 실행하지 마세요. 라우팅, 프록시, DNS 설정이 서로 덮어쓸 수 있습니다.
같은 노드에서 특정 웹사이트만 오류가 난다면 웹사이트 자체의 상태, 계정 요건 또는 출구 주소 제한이 원인일 수도 있습니다. 노드를 바꿔 비교해 볼 수는 있지만, 그 결과만으로 프로토콜이 ‘작동하지 않는다’고 단정할 수는 없습니다. 오류 메시지를 보관하면 반복해서 재설치하는 것보다 문제 해결에 도움이 됩니다. 재현 과정을 명확히 설명하면 고객 지원도 설정 문제와 회선 문제를 더 빠르게 구분할 수 있습니다.
구독으로 설정을 가져오고, 노드에서 연결 옵션을 선택합니다. 프로토콜은 양쪽이 통신하는 방식을 정하고, 회선은 데이터를 전송하며, 트래픽 분산은 요청의 경로를 정합니다. 호환되는 설정을 가져온 뒤 대상 앱에서 연결을 확인하세요. 문제가 생기면 모든 설정을 다시 바꾸기보다 이 흐름에 따라 하나씩 점검하세요.