VPN이나 국제 네트워크 서비스를 처음 살펴볼 때 가장 헷갈리는 부분은 버튼이 아니라 ‘구독, 노드, 프로토콜, 분할 라우팅’ 같은 용어입니다. 각 용어는 서로 다른 계층에 해당합니다. 구독은 설정을 전달하고, 노드는 선택 가능한 접속 대상을 뜻하며, 프로토콜은 클라이언트의 데이터 전송 방식을 결정합니다. 분할 라우팅 규칙은 어떤 연결을 프록시로 보낼지 정합니다. 계층을 나누어 이해하면 상품 설명과 클라이언트 화면이 훨씬 명확해집니다.
먼저 단순화한 데이터 흐름을 살펴보겠습니다. 앱이 요청을 보내면 클라이언트가 분할 라우팅 규칙에 따라 처리 방식을 결정합니다. 프록시가 필요한 요청은 지정된 프로토콜로 노드에 연결된 뒤 노드 또는 후속 중계 회선을 거쳐 대상 웹사이트로 전달됩니다. 프록시가 필요 없는 요청은 로컬 네트워크를 통해 직접 연결됩니다. 구독 링크 자체는 일상적인 웹 데이터를 전송하지 않으며, 주로 노드와 관련 매개변수를 클라이언트에 전달합니다.
구독 링크, 클라이언트와 설정 파일은 무엇인가요
구독은 업데이트 가능한 설정 창구입니다
프록시 도구에서 구독은 일반적으로 서비스 서버가 생성한 주소를 의미합니다. 클라이언트가 이 주소에 접속하면 노드 이름, 서버 주소, 포트, 프로토콜 유형, 인증 정보 및 기타 연결 매개변수를 가져올 수 있습니다. 서버에서 노드를 조정한 뒤 클라이언트에서 구독을 새로 고치면 항목을 하나씩 수동으로 입력하지 않아도 새 설정을 받을 수 있습니다.
구독 주소에는 계정이나 요금제를 식별할 수 있는 인증 정보가 포함되는 경우가 많으므로 공개 페이지, 스크린샷 또는 공유 문서에 게시해서는 안 됩니다. 구독 주소를 아는 사람은 노드 설정을 확인하거나 해당 요금제의 트래픽을 사용할 수 있습니다. 주소가 유출된 것으로 의심되면 클라이언트에서만 삭제하지 말고 서비스 패널을 통해 구독을 재설정해야 합니다.
클라이언트는 설정을 해석하고 연결하며 규칙을 실행합니다
클라이언트는 기기에 설치하는 소프트웨어입니다. 구독 내용을 읽고 노드 목록을 표시하며 프로토콜 연결을 수립한 뒤 현재 모드에 따라 시스템 또는 앱에서 발생한 네트워크 요청을 처리합니다. 클라이언트 이름이 다르다고 해서 하위 프로토콜까지 반드시 다른 것은 아니며, 하나의 프로토콜이 여러 클라이언트에서 구현될 수도 있습니다. 가져오기가 가능한지 판단할 때는 소프트웨어 이름만 비교하지 말고 클라이언트가 지원하는 프로토콜과 구독 형식을 확인해야 합니다.
설정 파일은 클라이언트가 읽을 수 있는 정적 설정입니다. 단일 노드만 포함할 수도 있고 노드 그룹, DNS 설정, 규칙 세트 및 정책 선택을 함께 포함할 수도 있습니다. 구독과 달리 정적 파일은 서비스 서버의 변경 사항을 자동으로 따르지 않습니다. 서버의 접속 창구가 바뀌면 기존 파일에 더 이상 유효하지 않은 정보가 남을 수 있으므로 장기간 사용할 때는 대개 다시 가져오거나 업데이트해야 합니다.
| 용어 | 주요 역할 | 흔한 오해 | 확인할 내용 |
|---|---|---|---|
| 구독 링크 | 클라이언트에 노드 설정을 전달하고 업데이트 | 구독을 일상적인 데이터 전송 프로토콜로 생각하는 것 | 신뢰할 수 있는 서비스 패널에서 발급되었는지, 유출되지 않았는지 |
| 클라이언트 | 설정을 해석하고 연결을 수립하며 분할 라우팅을 실행 | 클라이언트를 바꾸면 반드시 회선도 바뀐다고 생각하는 것 | 프로토콜 호환성, 시스템 권한 및 규칙 지원 여부 |
| 설정 파일 | 노드, DNS, 규칙 등의 정적 매개변수 저장 | 가져온 뒤 영구적으로 자동 업데이트된다고 생각하는 것 | 형식이 맞는지, 내용이 만료되지 않았는지 |
| 노드 | 클라이언트가 연결할 수 있는 네트워크 접속 창구 제공 | 노드 이름을 전체 회선과 동일하게 보는 것 | 접속 위치, 출구 위치 및 회선 유형 |
노드, 접속 지점, 출구와 회선의 차이
‘노드’는 클라이언트 화면에서 가장 흔히 볼 수 있는 선택 항목이지만, 노드 이름 하나가 전체 경로의 일부만 나타내는 경우가 많습니다. 클라이언트가 처음 연결하는 곳은 접속 서버이며, 대상 웹사이트가 최종적으로 확인하는 것은 대개 출구 주소입니다. 접속 지점과 출구는 같은 지역에 있을 수도 있고 중계 링크로 연결될 수도 있습니다. 노드 이름의 도시명이나 국기만으로는 실제 경로 전체를 판단할 수 없습니다.
직접 연결 회선
직접 연결은 일반적으로 클라이언트가 대상 지역에 있는 서버에 바로 연결하고, 서비스 제공자가 별도로 마련한 전달 지점을 거치지 않는 방식을 뜻합니다. 구조가 단순하고 추가 전달 단계가 적지만, 국제 구간은 현재 통신사의 공용 인터넷 라우팅에 더 크게 좌우됩니다. 저녁 시간대의 혼잡, 통신사 간 연동 변화 또는 로컬 네트워크 품질이 직접 연결의 체감 품질에 영향을 줄 수 있습니다.
중계 회선
중계 회선은 먼저 더 가깝거나 안정적인 접속 지점에 연결한 다음, 서비스 제공자가 마련한 링크를 통해 출구로 전달합니다. 중계의 목적은 품질이 낮은 공용 인터넷 구간을 피하거나 접속 지점을 사용자 네트워크에 더 가깝게 두는 데 있습니다. 중계를 사용한다고 지연 시간이 반드시 낮아지는 것은 아닙니다. 전달 과정에서 처리와 경로 비용이 늘어날 수 있기 때문입니다. 실제 효과는 접속 위치, 국제 구간 품질 및 출구 부하에 따라 달라집니다.
IEPL 전용 회선
IEPL은 기업용 국제 이더넷 전용 회선 상품을 설명할 때 자주 사용됩니다. 소매형 네트워크 서비스에서 IEPL이라고 표시한 경우, 국제 구간의 핵심 경로가 해당 전용 회선 또는 전용 회선 자원을 사용한다는 뜻인 경우가 많으며, 사용자의 기기가 독점 물리 회선에 직접 연결된다는 의미는 아닙니다. 상품 페이지에서는 ‘국제 구간의 회선 유형’과 ‘사용자에서 접속 지점까지의 로컬 공용 인터넷 연결’을 구분해 확인해야 합니다. 핵심 구간이 안정적이어도 로컬 접속 품질은 최종 사용 경험에 영향을 줍니다.
노드는 선택 가능한 접속 설정이고, 회선은 데이터가 실제로 지나가는 경로이며, 출구는 대상 웹사이트에 보이는 네트워크 위치를 결정합니다. 세 요소는 서로 관련되어 있지만 같은 개념은 아닙니다.
프록시 프로토콜은 무엇을 결정하나요
프로토콜은 클라이언트와 서버가 연결을 수립하고 신원을 인증하며 데이터를 캡슐화하고 전송을 처리하는 방식을 규정합니다. 프로토콜은 호환성, 핸드셰이크 방식, 패킷 손실 대응력 및 리소스 사용량에 영향을 주지만, 하나만으로 전체 회선의 속도를 결정할 수는 없습니다. 품질 좋은 회선도 맞지 않는 프로토콜을 사용하면 성능이 떨어질 수 있으며, 프로토콜 설정이 올바르더라도 하위 네트워크의 심한 혼잡을 해결할 수는 없습니다.
| 프로토콜 | 핵심 특징 | 적합한 사용 환경 | 사용 전 확인 사항 |
|---|---|---|---|
| Shadowsocks | 구조가 비교적 단순하며 암호화 방식과 비밀번호로 연결 | 클라이언트 호환성이 넓고 설정이 간단한 일반 프록시 | 암호화 방식이 클라이언트에서 지원되는지 |
| VMess | V2Ray 생태계에서 흔히 사용되며 인증과 전송 계층 조합을 포함 | WebSocket, TLS 등의 전송 설정을 함께 구성해야 하는 환경 | 전송 방식, 호스트 이름 및 경로가 반드시 일치해야 함 |
| Trojan | 일반적으로 TLS 연결에서 인증과 데이터 전송을 수행 | 표준 도메인과 인증서 설정이 마련된 서버 | 인증서, 도메인 및 시스템 시간이 정상인지 |
| VLESS | 인증 구조가 비교적 단순하며 외부 전송 계층의 보안 기능에 의존하는 경우가 많음 | TLS 또는 다른 전송 방식을 유연하게 조합해야 하는 환경 | 보안 계층과 전송 계층을 모두 설정해야 함 |
| Hysteria2 | QUIC과 UDP 기반이며 혼잡 제어로 변동이 있는 회선에 대응 | 지연 시간이 길거나 일정 수준의 패킷 손실이 있는 네트워크 | 로컬 네트워크에서 UDP를 안정적으로 전송할 수 있는지 |
| TUIC | 역시 QUIC과 UDP 기반이며 다중화와 연결 마이그레이션을 강조 | 모바일 네트워크 전환이 잦거나 동시 연결이 많은 환경 | 클라이언트와 서버 구현이 호환되는지 |
Shadowsocks의 ‘암호화 방식’은 프로토콜 설정의 일부이므로 방식을 변경할 때는 서버와 클라이언트가 반드시 일치해야 합니다. VMess, Trojan, VLESS는 TLS, WebSocket, gRPC 등의 전송 방식과 함께 구성되는 경우가 많습니다. 따라서 가져오기에 실패했다고 해서 인증 정보만의 문제라고 단정할 수 없으며, 도메인, 경로, 서비스 이름 또는 보안 계층 설정이 맞지 않을 수도 있습니다.
Hysteria2와 TUIC은 UDP에 의존합니다. 회사 네트워크, 학교 네트워크 또는 라우터 장비가 UDP를 제한하는 경우 클라이언트가 핸드셰이크를 완료하지 못하거나 연결 후 불안정해질 수 있습니다. 이때는 문제와 관련 없는 분할 라우팅 규칙을 계속 수정하기보다 사용 가능한 다른 프로토콜이나 회선으로 전환해야 합니다.
전체 모드, 규칙 모드와 직접 연결 모드
연결이 수립된 뒤에도 클라이언트는 각 요청을 어디로 보낼지 결정해야 합니다. 이 결정은 실행 모드와 분할 라우팅 규칙이 함께 처리합니다. 모드를 잘못 선택하면 로컬 웹사이트 접속이 불필요하게 우회되거나, 일부 앱이 연결되지 않거나, 로컬 네트워크 기기에 접근할 수 없거나, 연결된 것처럼 보여도 대상 앱이 프록시를 거치지 않는 현상이 나타날 수 있습니다.
전체 모드
전체 모드는 일반적으로 클라이언트가 가로챌 수 있는 모든 연결을 선택한 노드로 처리합니다. 규칙 문제를 임시로 확인할 때 유용합니다. 규칙 모드에서는 접속되지 않지만 전체 모드에서는 접속된다면 도메인 분류, 앱 규칙 또는 규칙 우선순위에 문제가 있을 수 있습니다. 다만 전체 모드에서는 원래 직접 연결이 적합한 로컬 서비스도 원격 출구를 거치게 되어 지연 시간이 늘어나고 웹사이트에 보이는 지역이 달라질 수 있습니다.
규칙 모드
규칙 모드는 도메인, IP, 앱, 프로세스 또는 규칙 세트에 따라 프록시, 직접 연결 또는 차단 여부를 결정합니다. 일상적인 사용에는 대개 규칙 모드가 더 적합합니다. 로컬 서비스는 직접 연결로 유지하고 국제 회선이 필요한 요청만 노드로 보낼 수 있기 때문입니다. 규칙 모드의 정확도는 규칙이 최신 상태인지, 클라이언트가 대상 도메인과 앱 트래픽을 식별할 수 있는지에 따라 달라집니다.
직접 연결 모드
직접 연결 모드는 일반 요청을 대개 프록시 노드로 보내지 않으며, 프록시를 일시 중지하거나 로컬 네트워크 상태와 비교할 때 사용할 수 있습니다. 그렇다고 클라이언트를 완전히 종료한 것과 같지는 않습니다. 일부 소프트웨어는 로컬 DNS, 가상 네트워크 어댑터 또는 시스템 프록시 설정을 계속 유지할 수 있습니다. 문제를 확인할 때는 클라이언트 상태와 시스템 네트워크 설정을 함께 살펴봐야 합니다.
- ✅ 규칙 문제인지 임시로 확인하려면 같은 노드를 유지한 채 전체 모드와 규칙 모드를 먼저 비교하세요.
- ✅ 로컬 및 국제 서비스를 일상적으로 이용할 때는 정상적으로 관리되는 규칙 모드를 우선 사용하세요.
- ✅ 로컬 네트워크 기기가 열리지 않으면 로컬 네트워크 대역이 실수로 프록시를 거치도록 설정되지 않았는지 확인하세요.
- ❌ 시스템 프록시 또는 가상 네트워크 어댑터를 동시에 제어하는 클라이언트를 여러 개 실행하지 마세요.
- ❌ 규칙의 의미를 확인하지 않은 채 기존 설정을 일괄 덮어쓰지 마세요.
DNS 누출과 도메인 확인이 중요한 이유
사용자가 도메인을 입력하면 기기는 보통 먼저 DNS를 통해 해당 IP 주소를 조회합니다. 웹 연결은 프록시를 통과하지만 DNS 조회가 로컬 네트워크에서 직접 이루어지면 로컬 DNS 서비스가 조회된 도메인을 확인할 수 있습니다. 이를 일반적으로 DNS 누출이라고 합니다. 지역 판단이 엇갈리는 문제도 생길 수 있습니다. 연결 출구는 한 지역에 있지만 DNS가 로컬 네트워크를 기준으로 결과를 반환하면 적절하지 않은 콘텐츠 서버로 연결될 수 있습니다.
클라이언트마다 DNS를 처리하는 방식은 완전히 같지 않습니다. 일부 클라이언트는 시스템 조회를 가로채 규칙에 따라 분할 처리하고, 일부는 암호화된 DNS를 사용하며, 또 일부는 가상 주소를 매핑해 도메인 규칙과 이후 연결을 연결합니다. 어떤 방식을 사용하든 목표는 도메인 조회와 연결 경로를 일치시키고, 로컬 도메인·로컬 네트워크 기기·기업 내부 도메인이 외부 DNS 서비스로 잘못 전달되지 않도록 하는 것입니다.
DNS 문제의 흔한 증상
- 노드에는 연결됨으로 표시되지만 특정 도메인이 열리지 않고, 알고 있는 IP 주소를 직접 입력하면 결과가 다릅니다.
- 노드를 바꾼 뒤에도 웹사이트의 지역이 바로 바뀌지 않고 기존 DNS 캐시가 계속 적용됩니다.
- 규칙은 도메인 일치를 전제로 하지만 앱이 IP를 직접 사용해 예상한 규칙이 적용되지 않습니다.
- 조회 요청이 내부 이름을 인식하지 못하는 DNS 서비스로 전송되어 로컬 네트워크 기기 이름이 확인되지 않습니다.
클라이언트 가져오기와 플랫폼별 차이
구독을 가져오는 기본 절차는 비슷합니다. 서비스 패널에서 구독 주소를 복사하고 호환 클라이언트에서 URL 가져오기 또는 구독 추가를 선택한 뒤 업데이트를 완료합니다. 그런 다음 노드를 선택하고 시스템 프록시 또는 가상 네트워크 어댑터 모드를 활성화합니다. 실제로 문제가 생기기 쉬운 부분은 시스템 권한, 프로토콜 호환성 및 트래픽 제어 범위입니다.
Windows 클라이언트는 시스템 프록시와 가상 네트워크 어댑터라는 두 가지 제어 방식을 제공하는 경우가 많습니다. 시스템 프록시는 시스템 설정을 따르는 앱을 주로 처리하고, 가상 네트워크 어댑터는 더 다양한 트래픽을 처리할 수 있지만 관련 네트워크 구성 요소를 설치하고 시스템 권한을 받아야 합니다. 브라우저는 작동하지만 특정 데스크톱 앱이 작동하지 않는다면 해당 앱이 시스템 프록시를 우회하는지 확인해야 합니다.
macOS는 네트워크 확장과 VPN 설정에 대해 명확한 시스템 승인 절차를 제공합니다. 클라이언트가 관련 기능을 처음 활성화할 때 시스템에서 사용자의 확인을 요청할 수 있습니다. 승인이 완료되지 않으면 클라이언트 화면에는 설정이 가져와진 것으로 표시되어도 시스템 트래픽이 제어되지 않을 수 있습니다. 클라이언트 업데이트 후 문제가 생겼다면 네트워크 확장이 계속 활성화되어 있는지도 확인해야 합니다.
iOS와 iPadOS의 클라이언트는 시스템 VPN 설정을 통해 트래픽을 제어하며, 처음 연결할 때 설정 추가를 승인해야 합니다. Android 클라이언트는 배터리 절약 정책, 백그라운드 제한 및 항상 켜기 설정의 영향을 받을 수 있습니다. 모바일 기기가 Wi-Fi에서 이동통신망으로 전환할 때 QUIC 기반 연결은 연결 마이그레이션을 통해 계속 작동할 수 있지만, 구체적인 결과는 클라이언트 구현과 네트워크 환경에 따라 달라집니다.
Linux 환경은 차이가 더 많습니다. 데스크톱 클라이언트는 시스템 프록시 또는 가상 네트워크 어댑터로 작동할 수 있고, 명령줄 프로그램은 환경 변수를 읽거나 투명 프록시가 제어해야 할 수 있습니다. 컨테이너, 서브시스템 및 원격 세션은 독립적인 네트워크 네임스페이스를 사용할 수도 있으므로 호스트의 브라우저가 작동한다고 해서 컨테이너 내부 요청도 같은 경로를 사용한다고 볼 수는 없습니다.
- ✅ 가져오기 전에 클라이언트가 구독에 포함된 프로토콜과 전송 방식을 지원하는지 확인하세요.
- ✅ 가져온 뒤 먼저 구독을 새로 고치고 노드 하나를 선택해 기본 연결을 테스트하세요.
- ✅ 시스템 프록시, 가상 네트워크 어댑터 또는 네트워크 확장이 실제로 활성화되었는지 확인하세요.
- ✅ 특정 앱에서만 문제가 생기면 독립적인 프록시 설정을 사용하는지 확인하세요.
- ❌ 인증 정보가 포함된 구독 주소를 공개 테스트 웹사이트에 붙여 넣지 마세요.
- ❌ 충돌하는 시스템 프록시, 가상 네트워크 어댑터 및 브라우저 확장을 동시에 활성화하지 마세요.
결제 전에 상품 사양 읽는 법
용어를 이해했다면 상품을 선택할 때 사양을 자신의 사용 경로에 맞춰 해석해야 합니다. 먼저 요금제가 기간제 트래픽인지 만료되지 않는 트래픽 패키지인지 확인하고, 지원 클라이언트와 프로토콜을 살펴보세요. 이후 접속 지점, 출구 및 회선 유형을 확인하고 환불 규정, 트래픽 재설정 방식과 기기 제한을 읽어야 합니다. 노드 이름, 프로토콜 수 또는 페이지의 단일 표시만으로 판단하지 마세요.
주로 웹 브라우징과 가벼운 업무에 사용한다면 최대 속도 측정보다 규칙 품질, DNS 처리 및 클라이언트 안정성이 더 중요할 수 있습니다. 장시간 동영상 재생에 사용한다면 지속 처리량, 회선 혼잡 및 출구 가용성을 살펴봐야 합니다. 여러 네트워크를 자주 오간다면 클라이언트 재연결 속도, UDP 환경 및 시스템 백그라운드 제한도 고려해야 합니다.
상품 페이지에서 ‘특정 프로토콜 지원’은 서버와 설정이 해당 기능을 갖추었다는 뜻일 뿐, 모든 플랫폼의 클라이언트에서 사용할 수 있다는 의미는 아닙니다. 마찬가지로 ‘특정 지역 노드’는 보통 출구 또는 노드 라벨을 설명할 뿐 접속 위치와 전체 라우팅을 보여주지는 않습니다. 정보가 명확하지 않다면 노드 페이지와 도움말을 확인하거나 고객센터에 항목의 의미를 문의하세요.
- ✅ 요금제에서 트래픽 계산 및 재설정 방식을 명확히 안내하는지 확인하세요.
- ✅ 자주 사용하는 플랫폼에 호환 클라이언트가 있고 필요한 프로토콜을 가져올 수 있는지 확인하세요.
- ✅ 노드 설명에서 접속 지점, 출구, 직접 연결, 중계 및 전용 회선을 구분하는지 확인하세요.
- ✅ 환불, 장애 점검 및 구독 재설정 안내가 명확한지 확인하세요.
- ✅ 분할 라우팅 규칙과 DNS 설정을 실제 사용 환경에 맞게 조정할 수 있는지 확인하세요.
- ❌ 노드 수를 연결 품질이나 안정성을 대신하는 지표로 보지 마세요.
자주 묻는 질문 한곳에서 확인
구독을 새로 고치면 수동 수정 내용이 덮어써지나요
클라이언트가 원격 설정을 관리하는 방식에 따라 다릅니다. 일부 클라이언트는 새로 고칠 때 구독 노드를 다시 생성하므로 직접 수정한 노드 항목이 서버 설정으로 되돌아갈 수 있습니다. 로컬 정책 그룹과 오버라이드 규칙은 별도로 저장될 수도 있습니다. 장기간 유지해야 하는 사용자 설정은 원격 노드를 직접 수정하지 말고 클라이언트가 지원하는 오버라이드, 병합 또는 로컬 규칙 기능에 저장해야 합니다.
노드에는 연결되지만 웹페이지가 열리지 않으면 노드가 고장 난 건가요
반드시 그렇지는 않습니다. 연결 상태는 클라이언트와 서버가 핸드셰이크를 완료했을 가능성을 보여줄 뿐입니다. 웹페이지가 열리지 않는 원인은 DNS, 분할 라우팅 규칙, 시스템 시간, 브라우저 프록시, 대상 웹사이트의 제한 또는 로컬 네트워크일 수도 있습니다. 먼저 여러 도메인을 테스트하고 전체 모드와 규칙 모드를 비교한 뒤 DNS와 시스템 제어 상태를 확인하세요.
같은 구독이 클라이언트마다 다르게 작동하는 이유는 무엇인가요
클라이언트마다 프로토콜 세부 사항, DNS, 규칙 문법, 가상 네트워크 어댑터 및 시스템 권한의 구현이 다릅니다. 일부 구독 변환 과정에서는 해당 클라이언트가 인식하지 못하는 필드가 제외될 수도 있습니다. 비교할 때는 노드, 프로토콜, DNS 및 실행 모드를 동일하게 맞춰야 하며, 그렇지 않으면 확인된 차이가 클라이언트 성능 차이만을 의미하지 않습니다.
회선과 프로토콜 중 무엇을 먼저 바꿔야 하나요
연결 자체가 전혀 수립되지 않으면 먼저 프로토콜 호환성, 인증 매개변수 및 네트워크의 UDP 또는 TLS 지원 여부를 확인하세요. 연결은 되지만 속도나 지연 시간이 불안정하다면 서로 다른 접속 지점과 회선을 우선 비교합니다. 특정 웹사이트에서만 문제가 생긴다면 먼저 출구, DNS 및 분할 라우팅 규칙을 확인하세요. 한 번에 하나의 변수만 바꾸면 재현 가능한 결론을 얻기 쉽습니다.