이 VPN 초보자 용어 가이드는 클라이언트의 구독, 노드, 프로토콜, 직결, 중계, 전체 프록시와 트래픽 분할 규칙을 설명합니다. 각 설정은 같은 계층에 속하지 않습니다. 구독은 설정을 전달하고, 노드는 선택 가능한 출구를 나타내며, 프로토콜은 통신 방식을 정하고, 모드와 규칙은 어떤 연결이 노드를 거칠지 결정합니다. 먼저 계층을 구분한 뒤 구독을 가져오고 노드를 전환하면 클라이언트 화면의 낯선 설정도 쉽게 이해할 수 있습니다.
구독과 노드는 무엇이 다른가
구독은 설정을 가져오는 입구이며, 단일 노드와는 다릅니다
구독은 보통 하나의 링크 형태로 제공됩니다. 클라이언트가 해당 링크에 접속하면 서버에서 노드 이름, 서버 주소, 포트, 프로토콜 매개변수와 함께 그룹 정보가 제공될 수 있습니다. 하나의 구독에는 여러 노드가 포함될 수 있으며, 서버에서 회선을 조정하면 내용이 업데이트되기도 합니다. 따라서 ‘구독을 가져왔다’는 것은 설정 목록이 클라이언트에 들어왔다는 뜻일 뿐, 현재 연결이 이미 성립했다는 의미는 아닙니다.
구독 링크에는 접속 자격 정보가 포함될 수 있으므로 계정 인증 정보처럼 다뤄야 합니다. 링크를 공개 속도 측정 페이지, 포럼 이미지, 공유 문서 또는 출처가 불분명한 변환 도구에 붙여 넣지 마세요. 자신의 다른 기기에서 사용해야 한다면 신뢰할 수 있는 방식으로 전달하고, 더 이상 사용하지 않는 기기에서는 구독과 캐시된 설정을 삭제할 수 있습니다.
노드는 한 번의 연결에 사용하는 진입점과 출구의 조합입니다
클라이언트 목록의 ‘일본’, ‘싱가포르’ 같은 지역명은 보통 노드의 출구 또는 회선 용도를 나타내지만, 이름은 단순한 라벨일 뿐입니다. 실제 연결에는 진입 서버, 전송 경로, 프로토콜과 출구 주소도 관여합니다. 노드를 선택하면 클라이언트가 해당 설정에 따라 터널 또는 프록시 연결을 시도하고, 연결에 성공한 뒤 현재 트래픽 분할 규칙에 해당하는 트래픽만 노드로 전달됩니다.
노드와 서버를 완전히 같은 의미로 보기도 어렵습니다. 하나의 서버에서 서로 다른 프로토콜 설정을 제공할 수 있고, 하나의 서비스 회선이 여러 진입점을 통해 제공될 수도 있습니다. 사용자에게 더 유용한 판단 기준은 ‘연결 가능한 완전한 설정’입니다. 핸드셰이크가 가능한지, 현재 네트워크에 적합한지, 출구 지역이 필요한 서비스와 맞는지, 지속적인 전송에서 안정적인지를 확인하세요.
- ✅ 구독을 가져온 뒤 먼저 업데이트를 실행해 클라이언트가 최신 설정을 받았는지 확인하세요.
- ✅ 지리적으로 가까운 노드부터 테스트한 다음, 이용하려는 서비스가 있는 지역에 맞춰 조정하세요.
- ✅ 구독 업데이트 실패와 노드 연결 실패를 따로 기록하세요. 서로 다른 문제 계층에 해당합니다.
- ❌ ‘목록에 노드가 보인다’는 사실을 ‘노드에 연결됐다’는 뜻으로 여기지 마세요.
- ❌ 구독 링크나 전체 연결 매개변수가 포함된 QR 코드를 공개하지 마세요.
직결·중계·IEPL 전용 회선은 어떻게 다른가
회선 유형은 로컬 네트워크에서 출구 서버까지 데이터가 어떤 경로로 이동하는지를 설명합니다. 직결, 중계, IEPL 전용 회선은 클라이언트 버튼의 고정된 명칭이 아니며 서비스 제공업체마다 다른 라벨을 사용할 수 있습니다. 판단할 때는 노드 이름에 ‘최적화’나 ‘전용 회선’이 적혀 있는지만 보지 말고 실제 네트워크 구성을 확인해야 합니다.
| 회선 유형 | 기본 경로 | 일반적인 특징 | 확인할 항목 |
|---|---|---|---|
| 직결 | 로컬 네트워크에서 해외 노드로 직접 연결 | 경로가 단순하며 로컬 통신사와 국제망 연결 상태의 영향을 크게 받음 | 망 간 라우팅, 저녁 시간대 혼잡, 현재 네트워크의 프로토콜 제한 여부 확인 |
| 중계 | 가까운 진입점에 먼저 연결한 뒤 진입점에서 출구로 전달 | 진입점을 이용 지역 가까이에 둘 수 있고 서버에서 이후 경로를 조정할 수 있음 | 로컬 네트워크에서 진입점까지와 진입점에서 출구까지를 각각 확인 |
| IEPL 전용 회선 | 진입점과 출구 사이에 기업용 국제 전용 회선 자원 사용 | 공용 인터넷에 노출되는 구간이 대체로 적지만 로컬 접속과 출구 상태의 영향을 여전히 받음 | 명칭이 실제 회선과 일치하는지 확인하고 진입점 연결 가능 여부 점검 |
직결의 장점은 구조가 명확하다는 점입니다. 로컬 네트워크에서 목표 노드로 직접 연결하므로 서버 측 전달 단계가 하나 줄어듭니다. 하지만 국제 회선이 우회하거나 혼잡해지면 클라이언트가 중간 경로를 스스로 바꾸기 어렵습니다. 중계 회선은 연결을 가까운 진입점으로 보낸 뒤 서버 네트워크를 통해 출구로 전달하므로 조정 여지가 더 큽니다. 다만 진입점이나 중계 구간에 문제가 생기면 연결이 실패할 수 있습니다.
IEPL은 국제 이더넷 전용 회선 계열 서비스를 부르는 일반적인 명칭으로, 핵심은 진입점과 출구 사이의 전송 방식입니다. 기기에서 진입점까지의 로컬 네트워크까지 전용 회선이 된다는 뜻은 아니며, 마케팅 라벨 하나만으로 실제 구성을 판단할 수도 없습니다. 선택할 때는 서비스 제공업체의 회선 설명, 연결 안정성, 실제 접속 결과를 함께 확인하고 회선 이름을 무조건적인 보장으로 받아들이지 마세요.
주요 프로토콜은 무엇을 결정하는가
프로토콜은 클라이언트와 서버가 데이터를 인증하고 캡슐화하며 전송하는 방식을 정합니다. 프로토콜 이름만으로 속도나 안정성을 판단할 수는 없습니다. 실제 성능은 네트워크 품질, 서버 설정, 전송 계층, 혼잡 제어와 클라이언트 구현의 영향도 받습니다. 초보자는 모든 매개변수를 직접 입력할 필요는 없지만, 프로토콜이 호환되지 않을 때 어떤 현상이 나타나는지는 알아두는 것이 좋습니다.
| 프로토콜 | 구분 | 전송 및 암호화 핵심 | 사용 시 주의사항 |
|---|---|---|---|
| Shadowsocks | 암호화 프록시 프로토콜 | 공유 키와 선택한 암호화 방식으로 프록시 트래픽 보호 | 클라이언트와 서버의 암호화 방식, 비밀번호, 포트가 일치해야 함 |
| VMess | 인증 기능을 갖춘 프록시 프로토콜 | TCP, WebSocket 등의 전송 방식과 함께 사용하는 경우가 많음 | 사용자 식별자, 전송 방식, 보안 계층 설정이 서로 맞아야 함 |
| Trojan | TLS 기반 프록시 방식 | 일반적으로 표준 TLS를 이용해 암호화 연결 수립 | 도메인, 인증서, 비밀번호와 서버 이름 설정이 핸드셰이크에 영향을 줌 |
| VLESS | 경량 인증 및 전송 프레임워크 | 프로토콜 자체는 콘텐츠를 암호화하지 않으며 보통 TLS 같은 보안 계층에 의존 | 서버에서 요구하는 전송 보안 설정을 생략할 수 없음 |
| Hysteria2 | QUIC 기반 전송 프로토콜 | UDP에서 실행되며 복잡한 네트워크 환경을 고려한 혼잡 제어 방식 사용 | 현재 네트워크에서 UDP를 제한하면 정상적으로 핸드셰이크하거나 전송하지 못할 수 있음 |
| TUIC | QUIC 기반 프록시 프로토콜 | UDP와 QUIC 연결을 이용해 프록시 트래픽 전달 | 클라이언트가 해당 버전을 지원하고 UDP 통신을 허용해야 함 |
Shadowsocks의 설정은 비교적 간단하지만 프록시 프로토콜에 해당하므로 이름만 보고 완전한 시스템 VPN으로 이해해서는 안 됩니다. VMess, Trojan, VLESS는 서로 다른 전송 방식이나 TLS 설정과 함께 구성되는 경우가 많아 같은 프로토콜 이름 아래에서도 핸드셰이크 경로가 달라질 수 있습니다. Hysteria2와 TUIC는 QUIC와 UDP를 기반으로 하므로 패킷 손실이나 지터가 있는 환경에서 기존 TCP 방식과 다르게 동작할 수 있습니다. 단, 현재 네트워크에서 UDP가 정상적으로 통과해야 합니다.
클라이언트에 ‘시간 초과’가 표시되면 서버에 연결할 수 없거나 포트가 제한되었거나 도메인 확인에 실패했거나 UDP가 통하지 않는 경우일 수 있습니다. ‘인증 실패’라면 자격 정보와 구독 만료 여부를 먼저 확인하고, ‘TLS 핸드셰이크 실패’라면 시간, 도메인, 인증서와 서버 이름을 점검해야 합니다. 연결에 실패했다고 모든 매개변수를 무작정 바꾸지 마세요. 오류 메시지가 보통 점검 방향을 알려줍니다.
전체·규칙·직결 모드는 어떻게 선택할까
연결이 수립된 뒤에도 클라이언트는 어떤 요청을 프록시로 보낼지 결정해야 합니다. 이 결정은 실행 모드와 트래픽 분할 규칙이 담당합니다. 노드는 ‘어디로 나갈지’를 정하고, 분할은 ‘어떤 트래픽을 노드로 보낼지’를 정하므로 서로 대신할 수 없습니다.
전체 모드
전체 모드는 보통 클라이언트가 제어할 수 있는 모든 네트워크 요청을 선택한 노드로 보냅니다. 트래픽 분할 누락을 확인할 때 유용합니다. 어떤 웹사이트가 전체 모드에서는 열리고 규칙 모드에서는 열리지 않는다면 노드 자체보다 규칙 매칭이나 DNS 정책에 문제가 있을 가능성이 큽니다. 전체 모드에서는 로컬 웹사이트, 로컬 네트워크 기기 또는 프록시가 필요 없는 앱까지 우회할 수 있으므로 장기간 유지하기에 항상 적합한 것은 아닙니다.
규칙 모드
규칙 모드는 도메인, IP, 애플리케이션 또는 규칙 세트에 따라 프록시, 직결 또는 거부를 결정합니다. 도메인 규칙은 전체 도메인이나 접미사를 매칭할 수 있고, IP 규칙은 확인된 주소에 의존합니다. 앱별 분할은 운영체제와 클라이언트가 프로세스 식별을 지원하는지에 따라 달라집니다. 규칙에 우선순위가 있다면 일반적으로 먼저 일치한 규칙이 적용되므로, 범위가 넓은 규칙을 앞에 두면 뒤의 정밀한 규칙이 가려질 수 있습니다.
직결 모드
직결 모드는 트래픽을 노드에 보내지 않고 현재 네트워크를 직접 사용합니다. 프록시의 영향을 잠시 중단하거나 로컬 네트워크 리소스에 접속하거나 비교 테스트를 할 때 적합합니다. 직결은 클라이언트 종료와 같은 뜻이 아닙니다. 일부 클라이언트는 로컬 DNS, 가상 네트워크 어댑터 또는 시스템 프록시 설정을 그대로 유지할 수 있으므로 점검이 끝난 뒤 시스템 네트워크 상태가 복구되었는지도 확인해야 합니다.
요청 발생
→ 클라이언트가 대상 도메인, IP 또는 애플리케이션 정보를 읽음
→ 순서에 따라 트래픽 분할 규칙 매칭
→ 프록시, 직결 또는 거부 실행
→ 프록시 요청을 현재 노드로 전달
→ 노드가 요청을 대상 서비스로 전달규칙 모드에서 가장 흔한 오해는 웹사이트의 기본 도메인만 확인하는 것입니다. 현대적인 웹페이지는 로그인, 이미지, 스크립트, API와 미디어 리소스를 동시에 불러오며, 이러한 리소스가 서로 다른 도메인에서 제공될 수 있습니다. 기본 페이지는 프록시를 사용하지만 API 도메인은 직결되면 페이지는 열려도 로그인할 수 없거나 버튼이 작동하지 않거나 이미지가 표시되지 않을 수 있습니다. 브라우저 개발자 도구와 클라이언트 연결 로그를 이용하면 예상과 다르게 분할된 도메인을 찾을 수 있습니다.
시스템 프록시·가상 네트워크 어댑터·앱 프록시의 차이
클라이언트가 트래픽을 제어하려면 운영체제가 제공하는 접점이 필요합니다. 일반적인 접점으로는 시스템 프록시, 가상 네트워크 어댑터, 앱 자체의 프록시 설정이 있습니다. 연결 버튼이 성공으로 표시되는 것은 클라이언트와 노드 사이에 연결이 수립되었을 가능성을 보여줄 뿐입니다. 특정 앱이 실제로 노드를 통과하는지는 현재 제어 방식에 해당 앱이 따르는지에 따라 달라집니다.
시스템 프록시는 운영체제의 프록시 설정을 변경합니다. 브라우저와 시스템 설정을 따르는 앱은 보통 사용할 수 있지만, 일부 게임, 명령줄 도구 또는 자체 네트워크 스택을 구현한 소프트웨어는 이를 무시할 수 있습니다. 가상 네트워크 어댑터 모드는 클라이언트에서 TUN으로 표시되는 경우가 많으며 네트워크 계층에서 더 넓은 범위의 트래픽을 제어합니다. 시스템 프록시를 읽지 못하는 앱에 적합하지만 추가 권한이 필요할 수 있고 로컬 네트워크와 라우팅 충돌도 적절히 처리해야 합니다. 앱 프록시는 특정 소프트웨어 내부에 로컬 프록시 주소를 입력하는 방식으로 해당 소프트웨어에만 영향을 줍니다.
| 플랫폼 | 일반적인 트래픽 제어 방식 | 사용자에게 표시되는 권한 요청 | 점검 방향 |
|---|---|---|---|
| Windows | 시스템 프록시 또는 가상 네트워크 어댑터 | 가상 네트워크 어댑터 설치, 네트워크 접근 또는 관리자 권한 요청 | 시스템 프록시 잔여 설정, 방화벽과 가상 네트워크 어댑터 라우팅 확인 |
| macOS | 시스템 프록시, 네트워크 확장 또는 가상 인터페이스 | 네트워크 확장과 시스템 네트워크 설정 권한 | 확장이 활성화되어 있는지, 다른 소프트웨어가 시스템 프록시를 변경했는지 확인 |
| iOS | 시스템에서 제공하는 VPN 네트워크 확장 | VPN 설정 추가를 허용하는 시스템 확인 | 설정 활성화 여부, 필요 시 연결, 현재 네트워크 권한 확인 |
| Android | 시스템 VPN 서비스 | VPN 연결 수립을 위한 시스템 확인 | 배터리 절약 제한, 백그라운드 실행과 앱별 트래픽 분할 설정 확인 |
플랫폼에 따라 클라이언트 화면은 크게 다를 수 있지만 근본적인 문제는 비슷합니다. 구독이 업데이트되었는지, 노드가 핸드셰이크할 수 있는지, 시스템이 네트워크 인터페이스 생성을 허용하는지, 대상 앱이 제어 범위에 포함되는지, 트래픽 분할 규칙이 일치하는지를 확인해야 합니다. 플랫폼을 바꾼 뒤 같은 이름의 버튼을 기계적으로 찾기보다 클라이언트가 시스템 프록시, 가상 네트워크 어댑터 또는 시스템 VPN 서비스를 사용하는지 먼저 확인하고 권한과 라우팅을 점검하세요.
DNS 유출과 확인 경로는 어떻게 이해할까
DNS는 도메인 이름을 IP 주소로 변환합니다. DNS 유출은 일반적으로 실제 트래픽은 프록시를 통과하도록 설정했지만 도메인 조회는 로컬 네트워크가 지정한 DNS 서비스로 전송되어 조회 경로와 프록시 정책이 일치하지 않는 상황을 말합니다. 이는 개인정보 보호 경계의 문제일 뿐 아니라 현재 출구 지역에 적합하지 않은 주소로 웹사이트가 확인될 수 있어 연결 지연, 지역 판정 오류 또는 페이지 리소스 로딩 실패를 일으킬 수 있습니다.
클라이언트마다 DNS 처리 방식은 다릅니다. 원격 노드에 조회를 맡기거나, 로컬 암호화 DNS를 사용하거나, 트래픽 분할 규칙에 따라 나누어 조회하거나, 가상 네트워크 어댑터 모드에서 시스템 조회를 제어하기도 합니다. ‘원격 DNS’, ‘로컬 DNS’, ‘Fake IP’, ‘규칙에 따른 조회’ 같은 옵션이 보여도 기능을 많이 켜는 데만 집중하지 말고 현재 모드에서 클라이언트가 DNS를 제어해야 하는지 먼저 이해하세요.
- 연결 전에 현재 네트워크가 사용하는 확인 결과와 출구 상태를 기록합니다.
- 노드를 활성화한 뒤 대상 웹사이트의 실제 트래픽이 클라이언트를 통과하는지 확인합니다.
- DNS 테스트 결과에 여전히 로컬 네트워크가 지정한 DNS 서비스만 표시되는지 확인합니다.
- 결과가 예상과 다르면 클라이언트의 DNS 모드, 시스템 및 브라우저의 보안 DNS, 트래픽 분할 규칙이 서로 덮어쓰고 있지 않은지 확인합니다.
- 오래된 확인 결과가 판단을 방해하지 않도록 시스템과 브라우저의 DNS 캐시를 삭제한 뒤 다시 테스트합니다.
구독 가져오기부터 연결 확인까지 전체 과정
용어를 이해했다면 정해진 순서에 따라 처음 설정을 완료할 수 있습니다. 핵심은 먼저 설정이 유효한지 확인하고, 다음으로 노드 연결을 확인한 뒤, 마지막으로 트래픽 분할과 DNS를 점검하는 것입니다. 문제가 생겨도 범위를 명확한 단계로 좁힐 수 있습니다.
- 플랫폼에 맞는 클라이언트를 받습니다. 링크를 붙여 넣을 수 있는지만 보지 말고 클라이언트가 구독에 사용된 프로토콜을 지원하는지 확인하세요.
- 구독 링크를 가져옵니다. 구독 관리 또는 설정 메뉴에 링크를 붙여 넣고 저장한 뒤 업데이트를 실행합니다. 클라이언트가 QR 코드 스캔을 지원하더라도 QR 코드가 자신의 계정 페이지에서 생성된 것인지 확인하세요.
- 노드 목록을 확인합니다. 목록이 비어 있지 않은지 확인하고 인식할 수 없는 프로토콜이나 설정 오류 메시지가 표시되는지도 살펴보세요.
- 노드를 하나 선택합니다. 처음 테스트할 때는 지리적으로 가깝고 용도가 분명한 회선을 선택하고 자동 전환과 복잡한 부하 분산 전략은 동시에 사용하지 마세요.
- 트래픽 제어 모드를 선택합니다. 브라우저 테스트는 먼저 시스템 프록시를 사용하고, 더 많은 앱을 제어해야 할 때 플랫폼 지원 여부에 따라 가상 네트워크 어댑터 또는 시스템 VPN 서비스를 활성화하세요.
- 연결을 수립합니다. 버튼 색상만 보지 말고 클라이언트 로그의 확인, 핸드셰이크, 인증과 시간 초과 정보를 살펴보세요.
- 출구와 접속을 확인합니다. 출구 지역이 선택한 노드와 일치하는지 확인하고 로컬 웹사이트, 대상 웹사이트, 실제로 사용할 앱을 각각 테스트하세요.
- 규칙 모드로 전환합니다. 전체 모드가 작동하면 규칙을 활성화하고 다시 테스트하세요. 차이가 발생하면 매칭되지 않은 도메인이나 앱을 대상으로 규칙을 조정합니다.
- DNS를 확인합니다. 비즈니스 트래픽과 DNS 조회가 서로 다른 정책을 사용하지 않도록 확인 경로가 현재 트래픽 제어 방식과 일치하는지 점검하세요.
구독이 업데이트되지 않으면 먼저 링크가 완전한지, 시스템 시간이 정확한지, 현재 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요. 구독은 업데이트되지만 모든 노드가 실패한다면 프로토콜 호환성, 네트워크 권한, 현재 네트워크의 UDP 또는 특정 포트 제한을 중점적으로 점검해야 합니다. 특정 노드만 실패한다면 해당 노드, 연결된 진입점 또는 회선 상태의 문제일 가능성이 더 큽니다.
브라우저에서는 접속되지만 다른 앱에서는 접속되지 않는다면 시스템 프록시와 가상 네트워크 어댑터의 차이를 확인하세요. 전체 모드는 정상인데 규칙 모드에서 문제가 생기면 규칙 매칭과 DNS를 점검해야 합니다. 웹페이지는 열리지만 로그인이나 미디어 로딩에 실패한다면 관련 하위 도메인이 다른 트래픽 분할 정책을 사용하는지도 살펴보세요.
- ✅ 구독 업데이트가 완료되었고 클라이언트가 포함된 프로토콜을 인식합니다.
- ✅ 선택한 노드가 핸드셰이크를 완료했으며 인증 또는 인증서 오류가 없습니다.
- ✅ 대상 앱이 현재 프록시 또는 가상 네트워크 어댑터의 제어 범위에 포함됩니다.
- ✅ 트래픽 분할 규칙이 기본 도메인, API 도메인과 리소스 도메인에 일관된 정책을 적용합니다.
- ✅ DNS 확인 경로가 프록시 모드와 일치합니다.
- ❌ 문제가 해결되지 않은 상태에서 출처가 서로 다른 설정을 여러 개 연속으로 가져오지 마세요.
클라이언트 설정을 이해한 뒤 선택하는 원칙
클라이언트 설정은 몇 가지 계층으로 나눌 수 있습니다. 구독은 설정을 전달하고, 노드는 연결 대상을 제공하며, 프로토콜은 통신 방법을 정의합니다. 회선은 중간 경로를 결정하고, 트래픽 제어 방식은 어떤 앱이 클라이언트를 거칠지 정하며, 분할 규칙은 각 요청이 프록시와 직결 중 어디로 갈지 결정합니다. DNS 설정은 도메인 확인 경로를 담당합니다. 낯선 설정을 발견하면 먼저 어느 계층에 속하는지 판단하면 그 변경이 무엇에 영향을 주는지 대체로 추론할 수 있습니다.
초보자는 복잡한 설정을 위해 모든 기능을 켤 필요가 없습니다. 안정적인 방법은 정상적으로 연결되는 기본 설정을 하나 유지한 뒤 규칙, 가상 네트워크 어댑터, 자동 선택 또는 사용자 지정 DNS를 단계적으로 추가하는 것입니다. 변경할 때마다 동일한 접속 확인을 수행하고 복원 가능한 설정 버전도 보관하세요. 그러면 각 설정의 역할을 이해할 수 있고 네트워크 환경이 바뀌어도 이미 작동하는 상태로 빠르게 돌아갈 수 있습니다.