이 VPN 초보자 용어 가이드는 가장 짧은 답부터 제시합니다. 구독은 업데이트할 수 있는 연결 설정 모음이고, 노드는 클라이언트에서 선택할 수 있는 접속 항목입니다. 회선은 데이터가 실제로 지나가는 네트워크 경로이며, 프로토콜은 클라이언트와 서버가 연결을 수립하고 유지하는 방식을 정합니다. 트래픽 분할은 어떤 요청을 선택한 회선으로 보낼지, 어떤 요청을 로컬 네트워크로 계속 처리할지 결정합니다.
이 용어들은 클라이언트 화면에 함께 표시되는 경우가 많지만 같은 계층의 개념은 아닙니다. 이를 혼동하면 ‘구독 업데이트’를 ‘회선 전환’으로 잘못 이해하거나, 노드를 사용할 수 없을 때 클라이언트를 계속 재설치하게 됩니다. 올바른 순서는 클라이언트가 구독을 읽는지 확인한 뒤 노드가 연결을 수립하는지 확인하고, 용도에 따라 회선을 선택한 다음 트래픽 분할과 DNS 설정이 예상대로 작동하는지 점검하는 것입니다.
구독 링크란 무엇인가
구독 링크는 클라이언트가 설정을 읽어 오는 주소라고 이해하면 됩니다. 서버는 이 주소를 통해 여러 노드 정보를 제공하고, 클라이언트는 이를 가져온 뒤 선택 가능한 목록으로 정리합니다. 노드 이름, 서버 주소, 포트, 프로토콜 매개변수와 인증 정보는 대개 구독 내용에 포함되므로 사용자가 하나씩 직접 입력할 필요가 없습니다.
구독이 지속적인 연결을 의미하는 것은 아닙니다. 가져오기에 성공했다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐이며, 실제로 연결을 클릭해야 클라이언트가 그중 하나의 노드로 세션을 수립합니다. 구독은 일반 웹페이지의 즐겨찾기 주소도 아닙니다. 브라우저에 직접 입력하면 인코딩된 텍스트가 표시되거나 설정 파일이 다운로드되거나 읽기 어려운 내용이 반환될 수 있으며, 이런 현상이 링크 자체의 오류를 의미하지는 않습니다.
가져오기, 업데이트, 전환의 차이
- ✅ 구독 가져오기: 설정 모음을 클라이언트에 추가하는 작업으로, 처음 사용하거나 재설치한 뒤 주로 진행합니다.
- ✅ 구독 업데이트: 서버에서 제공하는 노드 이름, 주소와 매개변수를 다시 받아 회선 변경 사항을 동기화합니다.
- ✅ 노드 전환: 이미 가져온 목록에서 다른 접속 항목을 선택하는 작업이며, 구독을 새로 만들지는 않습니다.
- ✅ 연결 시작: 현재 노드와 현재 트래픽 분할 모드에 따라 조건에 맞는 네트워크 요청을 클라이언트가 처리하도록 합니다.
- ❌ 구독 링크를 포럼, 스크린샷 또는 공유 문서에 공개적으로 붙여 넣지 마세요. 링크에 구독을 식별하는 인증 정보가 포함될 수 있습니다.
구독을 업데이트한 뒤 클라이언트가 기존 노드를 유지할 수도 있고 새 목록으로 덮어쓸 수도 있으며, 구체적인 동작은 소프트웨어 구현에 따라 다릅니다. 목록이明显히 오래되었다면 모든 설정을 삭제하고 반복해서 가져오기보다 클라이언트에 내장된 업데이트 기능을 먼저 사용하세요. 삭제하기 전에는 사용자 지정 트래픽 분할 규칙이 구독 설정과 같은 파일에 저장되어 있는지도 확인해야 함께 사라지는 일을 막을 수 있습니다.
노드, 서버와 회선은 어떻게 다른가
노드는 사용자에게 표시되는 연결 항목입니다. 일반적으로 서버 주소, 프로토콜과 필요한 매개변수를 포함하지만, 반드시 하나의 독립적인 물리 서버와 일치하는 것은 아닙니다. 여러 노드가 같은 인프라에서 제공될 수도 있고, 서로 다른 접속 지점을 통해 다른 출구로 연결될 수도 있습니다. 따라서 노드 수를 물리 서버 수와 동일하게 볼 수 없으며, 노드 수만으로 사용 경험을 판단할 수도 없습니다.
서버는 컴퓨팅 및 네트워크 기능을 제공하는 장비나 인스턴스입니다. 회선은 데이터가 클라이언트에서 접속 지점으로, 다시 출구로 이동하는 경로를 나타냅니다. 같은 출구 지역이라도 직접 연결, 중계 또는 IEPL 전용 회선처럼 경로가 다를 수 있습니다. 표시되는 지역은 같아도 네트워크 간 안정성, 혼잡 상황과 장애 전환 방식은 달라질 수 있습니다.
| 용어 | 주요 의미 | 사용자가 보통 확인할 수 있는 정보 | 이 정보만으로 바로 판단할 수 없는 것 |
|---|---|---|---|
| 노드 | 클라이언트에서 선택할 수 있는 연결 설정 | 지역, 이름, 프로토콜 또는 회선 표시 | 실제 물리 서버 수 |
| 서버 | 연결과 전달을 처리하는 인프라 | 기저 구조 전체가 표시되지는 않음 | 국경 간 경로의 안정성 |
| 회선 | 로컬 네트워크에서 접속 지점과 출구까지 이어지는 데이터 경로 | 직접 연결, 중계, 전용 회선 등의 유형 설명 | 모든 시간대의 고정 속도 |
| 출구 | 대상 웹사이트가 요청이 나간 위치로 인식하는 네트워크 위치 | 출구 지역과 확인된 공인 IP | 클라이언트에서 접속 지점까지의 전체 경로 |
직접 연결, 중계와 IEPL 전용 회선
직접 연결은 클라이언트가 원격 서버의 접속 지점에 바로 연결하는 방식입니다. 경로가 단순하고 추가 전달 단계가 적지만, 실제 성능은 로컬 통신사와 국제 네트워크 상태에 더 크게 좌우됩니다. 네트워크 간 라우팅이 바뀌거나 피크 시간대에 혼잡이 발생하면 같은 노드에서도 성능이 흔들릴 수 있습니다.
중계 회선은 먼저 더 가깝거나 상호 연결 조건이 좋은 접속 지점에 연결한 다음 중계 네트워크를 통해 출구로 데이터를 보냅니다. 핵심은 경로의 전반부를 조정해 로컬 네트워크가 원격지에 직접 연결할 때 발생하는 불안정한 라우팅을 줄이는 데 있습니다. 중계가 모든 직접 연결보다 본질적으로 빠른 것은 아니며, 접속 지점의 위치와 처리 용량, 당시 네트워크 상태를 함께 봐야 합니다.
IEPL은 일반적으로 기업 환경을 위한 국제 이더넷 전용 회선 연결을 뜻합니다. 일반 공용 인터넷 직접 연결보다 제어 가능한 국경 간 전송 경로를 중시합니다. 다만 클라이언트에서 접속 지점까지의 로컬 네트워크도 사용 경험에 영향을 주며, 서비스 제공업체의 연결 및 조정 방식도 중요합니다. 따라서 ‘전용 회선’이라는 표시는 회선 구조에 대한 설명으로 이해해야 하며, 어떤 환경에서도 성능이 흔들리지 않는다는 약속으로 받아들여서는 안 됩니다.
자주 쓰는 프로토콜 이름 읽기
프로토콜은 클라이언트와 서버가 데이터를 캡슐화하고 인증하며 전송하는 방식을 정합니다. 초보자가 모든 필드를 외울 필요는 없지만, 프로토콜이 호환성, 연결 방식, 전송 특성과 네트워크 적응성에 영향을 준다는 점은 알아 두어야 합니다. 프로토콜 이름이 같아도 서버 배포, 라우팅과 설정은 별개의 변수이므로 서비스마다 회선 품질이 같지는 않습니다.
| 프로토콜 | 핵심 이해 | 주요 확인 사항 |
|---|---|---|
| Shadowsocks | 가벼운 암호화 프록시 프로토콜로, 클라이언트 지원 범위가 넓고 설정 구조가 비교적 단순함 | 암호화 방식이 서버와 일치해야 하며, 구형 클라이언트는 최신 설정을 지원하지 않을 수 있음 |
| VMess | V2Ray 생태계에서 자주 사용되며, 설정에 인증·전송·보안 관련 매개변수가 포함됨 | 전송 계층 설정이 일치해야 하며 서버 주소만 복사해서는 안 됨 |
| Trojan | 일반적으로 TLS와 함께 연결을 수립하며, 올바른 인증서와 도메인 설정이 필요함 | 시스템 시간, 인증서 검증과 서버 이름 설정이 핸드셰이크에 영향을 줌 |
| VLESS | 비교적 간결한 인증 및 전송 프레임워크로, 다른 전송·보안 메커니즘과 함께 사용하는 경우가 많음 | 단일 매개변수가 아니므로 클라이언트가 해당 조합을 완전히 지원해야 함 |
| Hysteria2 | QUIC 기반 전송 방식으로, 복잡한 네트워크 환경에서 안정적인 전송을 유지하는 데 중점을 둠 | 네트워크의 UDP 제한이 연결 성능에 직접적인 영향을 줌 |
| TUIC | 마찬가지로 QUIC와 UDP를 기반으로 하며, 동시 전송과 연결 관리를 강조함 | 클라이언트와 서버의 버전, 인증 및 전송 매개변수가 호환되어야 함 |
Shadowsocks는 흔히 SS라고 줄여 부르며, 프록시 트래픽의 암호화와 전달을 담당합니다. VMess와 VLESS는 V2Ray 또는 호환 생태계에서 자주 사용되지만 인증 방식과 데이터 구조가 다르므로 이름이 비슷하다는 이유만으로 서로 바꿔 쓸 수 없습니다. Trojan 설정에는 TLS가 포함되는 경우가 많으며, 인증서 도메인, 서버 이름과 시스템 시간에 문제가 있으면 연결이 실패할 수 있습니다.
Hysteria2와 TUIC는 UDP 기반의 QUIC 기술을 사용합니다. 지연 시간이 길거나 패킷 손실이 있는 일부 네트워크에서는 더 잘 대응할 수 있지만, 회사 네트워크·학교 네트워크·라우터 또는 로컬 네트워크 환경에서 UDP를 엄격히 제한하면 연결을 정상적으로 수립하지 못할 수 있습니다. 이때는 계속 연결을 반복하기보다 TCP를 사용하는 호환 설정으로 전환하는 편이 더 효과적입니다.
프로토콜을 선택하는 실용적인 순서
- 먼저 구독에서 기본으로 추천하는 프로토콜을 사용하세요. 일반적으로 현재 서버 설정과 호환되기 때문입니다.
- 연결에 실패하면 단일 노드의 장애인지, 같은 프로토콜을 사용하는 모든 노드가 연결되지 않는지 구분하세요.
- UDP 계열 프로토콜이 전반적으로 실패한다면 구독에 포함된 TCP 기반 호환 회선을 시도하세요.
- TLS 핸드셰이크 오류가 발생하면 기기 시간, 인증서 검증, 도메인 매개변수와 클라이언트 버전을 확인하세요.
- 의미를 모르는 상태에서 전송·보안·인증 필드를 임의로 수정하지 마세요. 어느 한쪽이라도 일치하지 않으면 연결이 실패할 수 있습니다.
트래픽 분할, 글로벌 모드와 규칙 모드 선택하기
트래픽 분할은 도메인, IP, 애플리케이션 또는 기타 조건에 따라 요청의 경로를 결정하는 기능입니다. 클라이언트에는 보통 글로벌, 규칙, 직접 연결 등의 모드가 제공되지만 소프트웨어마다 명칭은 조금씩 다를 수 있습니다. 핵심은 버튼 위치를 외우는 것이 아니라 ‘어떤 트래픽을 프록시로 처리할지’를 명확히 이해하는 데 있습니다.
글로벌 모드는 일반적으로 클라이언트가 처리할 수 있는 요청을 현재 노드로 일괄 전달합니다. 임시 점검에 적합합니다. 규칙 모드에서 특정 웹사이트가 열리지 않지만 글로벌 모드에서는 접속된다면, 문제는 노드 자체보다 규칙 매칭이나 DNS 조회에 있을 가능성이 큽니다. 글로벌 모드라고 해서 기기의 모든 트래픽이 반드시 처리되는 것은 아니며, 실제 적용 범위는 클라이언트의 작동 방식, 시스템 권한과 앱 자체의 네트워크 구현에 따라 달라집니다.
규칙 모드는 조건에 맞는 요청만 노드로 보내고 나머지는 로컬 네트워크로 직접 연결합니다. 일상적인 사용에는 보통 규칙 모드가 더 적합합니다. 로컬 서비스는 우회하지 않고, 국제 웹사이트와 특정 앱은 규칙에 따라 처리할 수 있기 때문입니다. 규칙의 정확도는 규칙 세트 업데이트, 도메인 분류와 DNS 조회 결과에 따라 달라집니다.
직접 연결 모드는 보통 프록시 전달을 잠시 중지할 때 사용하지만, 일부 클라이언트는 시스템 프록시나 가상 네트워크 인터페이스를 계속 활성화된 상태로 둘 수 있습니다. 문제를 확인할 때는 모드 이름만 보지 말고 상태 표시줄, 시스템 프록시 스위치와 가상 네트워크 인터페이스 상태도 확인하세요.
| 모드 | 트래픽 처리 | 적합한 상황 | 주의할 점 |
|---|---|---|---|
| 글로벌 모드 | 처리 가능한 요청을 현재 노드로 일괄 전달 | 단시간 테스트, 규칙 누락 점검 | 로컬 서비스도 우회될 수 있으며 장기적인 규칙 관리의 대안이 아님 |
| 규칙 모드 | 도메인, IP 또는 앱 조건에 따라 프록시와 직접 연결을 선택 | 일상적인 웹 이용, 개발 도구와 스트리밍을 분류해 처리 | 오래된 규칙은 새 도메인이나 콘텐츠 전송 도메인을 놓칠 수 있음 |
| 직접 연결 모드 | 요청을 계속 로컬 네트워크로 처리 | 사용 일시 중지, 로컬 네트워크와 비교 테스트 | 클라이언트의 트래픽 처리 상태가 모드와 함께 완전히 해제되지 않을 수 있음 |
시스템 프록시 및 가상 네트워크 인터페이스 모드
시스템 프록시 모드는 운영체제의 프록시 설정을 따르는 앱에 주로 전달 기능을 제공합니다. 브라우저는 대체로 이를 사용할 수 있지만, 일부 명령줄 프로그램·게임 또는 자체 네트워크 스택을 구현한 앱은 시스템 프록시를 무시할 수 있습니다. 이런 프로그램은 별도의 프록시 환경 변수를 설정하거나 클라이언트가 제공하는 가상 네트워크 인터페이스 모드를 사용해야 할 수 있습니다.
가상 네트워크 인터페이스 모드는 흔히 TUN 모드라고 합니다. 시스템 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 처리하므로 시스템 프록시 설정을 읽지 않는 앱에 더 적합합니다. 대신 추가 시스템 권한이 필요하고, 방화벽·다른 네트워크 도구·기업 보안 소프트웨어 또는 기존 가상 네트워크 인터페이스와 라우팅 충돌이 발생하기 쉽습니다.
DNS 누출과 조회 경로
DNS는 도메인 이름을 네트워크 주소로 변환합니다. 노드에 연결한 뒤 웹 요청은 선택한 회선을 통과하더라도 도메인 조회는 로컬 네트워크가 제공하는 DNS가 처리할 수 있습니다. 이처럼 예상과 다른 조회 경로가 발생하는 상황을 일반적으로 DNS 누출이라고 합니다. 접속한 도메인의 조회 기록이 노출될 수 있고, 현재 출구에 적합하지 않은 주소가 반환되어 접속 문제가 생길 수도 있습니다.
규칙 기반 트래픽 분할은 도메인을 기준으로 판단하므로 DNS가 특히 중요합니다. 앱이 먼저 도메인을 IP로 변환하고 클라이언트가 최종 IP만 확인한다면 규칙이 원래 도메인을 기준으로 매칭되지 않을 수 있습니다. 최신 클라이언트에는 DNS 처리, 암호화 DNS, 원격 조회 또는 규칙에 따른 조회 서버 선택 기능이 제공되는 경우가 많지만 설정 명칭은 통일되어 있지 않습니다.
DNS 문제를 확인할 때는 조회 요청을 누가 처리하는지, 반환된 주소가 현재 네트워크에 적합한지, 브라우저에서 별도의 보안 DNS를 사용 중인지, 시스템에서 다른 네트워크 도구가 함께 실행 중인지 살펴봐야 합니다. 브라우저 내장 DNS, 운영체제 DNS와 클라이언트 DNS가 동시에 존재하면 최종 경로가 화면에 표시된 단일 스위치와 다를 수 있습니다.
- ✅ 클라이언트의 DNS 설정이 현재 트래픽 분할 모드와 맞는지 확인하세요. 연결 스위치만 켜서는 충분하지 않습니다.
- ✅ 브라우저가 별도의 DNS 설정을 사용하는지 확인하세요. 클라이언트의 시스템 수준 설정을 우회할 수 있습니다.
- ✅ 규칙 매칭에 문제가 있으면 규칙과 구독을 업데이트하고 기존 DNS 캐시를 삭제한 뒤 다시 테스트하세요.
- ✅ 글로벌 모드와 규칙 모드를 비교하세요. 규칙 모드에서만 문제가 발생한다면 도메인 매칭과 조회 경로를 먼저 확인하세요.
- ❌ 시스템 프록시, 라우팅 또는 DNS를 변경하는 클라이언트를 여러 개 동시에 사용하지 마세요. 충돌이 발생하면 점검 결과를 신뢰하기 어려워집니다.
플랫폼별 클라이언트 차이
Windows 클라이언트는 보통 시스템 프록시와 가상 네트워크 인터페이스 기능을 함께 제공합니다. 시스템 프록시를 사용할 때는 프로그램을 종료한 뒤 시스템 설정이 자동으로 복원되는지 확인하세요. 가상 네트워크 인터페이스를 사용할 때는 관리자 권한, 방화벽과 다른 가상 네트워크 소프트웨어를 살펴봐야 합니다. 시스템이 절전 모드에 들어갔거나 네트워크가 전환된 뒤 접속되지 않는다면 이전 라우팅 또는 프록시 상태가 제때 복원되지 않았을 수도 있습니다.
macOS는 네트워크 확장과 시스템 권한을 비교적 엄격하게 관리합니다. 가상 네트워크 인터페이스나 네트워크 확장을 처음 활성화할 때 시스템에서 권한 확인을 요청할 수 있습니다. 클라이언트마다 사용하는 네트워크 확장 구현이 다르며, 같은 종류의 도구를 여러 개 동시에 활성화하면 라우팅이 덮어써지기 쉽습니다. 문제를 확인할 때는 현재 클라이언트만 일시적으로 실행하세요.
Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 시스템 상태 아이콘은 인터페이스가 활성화되었음을 보여 주지만, 이것만으로 현재 노드가 반드시 연결되었다고 볼 수는 없습니다. 배터리 절약 정책, 백그라운드 제한과 네트워크 전환으로 장시간 연결이 끊길 수 있으므로 클라이언트가 필요한 백그라운드 작업을 유지하도록 허용해야 합니다.
iOS와 iPadOS도 시스템이 제공하는 네트워크 확장 기능에 의존합니다. 앱이 백그라운드로 전환되면 연결 상태는 시스템과 클라이언트가 함께 유지합니다. 설정을 정상적으로 가져왔지만 연결되지 않는다면 설정이 완전한지, 시스템 네트워크 권한이 허용되어 있는지, 동시에 활성화된 다른 네트워크 설정이 있는지 먼저 확인하세요.
Linux의 차이는 데스크톱 환경, 배포판의 네트워크 관리 방식과 명령줄 도구에서 더 많이 나타납니다. 브라우저는 데스크톱 프록시 설정을 읽을 수 있지만 터미널 프로그램은 대개 자체 프록시 환경 변수가 필요합니다. 컨테이너, 원격 세션과 하위 시스템은 독립적인 네트워크 네임스페이스를 사용할 수도 있으므로 호스트 시스템의 프록시를 기본적으로 상속한다고 볼 수 없습니다.
초보자를 위한 점검 순서
- 클라이언트를 사용하지 않은 상태에서 로컬 네트워크로 자주 쓰는 서비스에 정상적으로 접속할 수 있는지 확인하세요.
- 구독을 업데이트하고 같은 지역의 다른 노드를 선택해 테스트하여 단일 노드의 상태 문제인지 확인하세요.
- 프로토콜 유형을 바꾸어 특정 프로토콜만 호환되지 않는지, 아니면 모든 연결이 실패하는지 살펴보세요.
- 글로벌 모드로 잠시 비교 테스트하세요. 글로벌 모드는 작동하지만 규칙 모드가 작동하지 않는다면 규칙과 DNS를 확인하세요.
- 대상 앱이 시스템 프록시를 읽는지 확인하세요. 읽지 않는 경우에만 가상 네트워크 인터페이스나 앱 수준 설정을 검토하세요.
- 프록시, 라우팅과 DNS를 변경하는 다른 도구를 종료하여 여러 설정이 서로 덮어쓰지 않게 하세요.
- 클라이언트를 재시작하고 시스템 프록시가 복원되었는지 확인한 뒤 깨끗한 연결 테스트를 다시 진행하세요.
이 용어들을 하나의 전체 흐름으로 연결하기
정상적인 연결은 다음과 같이 이해할 수 있습니다. 클라이언트가 구독 링크에서 설정을 읽으면 목록에 여러 노드가 표시됩니다. 사용자가 노드를 선택하면 클라이언트는 해당 노드에 지정된 프로토콜로 서버와 연결을 수립합니다. 회선은 데이터를 해당 출구로 전달하고, 트래픽 분할 규칙은 어떤 요청을 이 회선으로 보낼지 결정합니다. DNS 설정은 도메인을 조회하는 방식을 정하고 규칙이 요청을 식별할 수 있는지에도 영향을 줍니다.
구독 업데이트에 실패하면 클라이언트가 새 설정을 가져오지 못합니다. 노드 연결에 실패하면 노드 상태, 프로토콜 호환성 또는 로컬 네트워크 제한이 원인일 수 있습니다. 특정 웹사이트만 이상하다면 트래픽 분할, DNS, 출구 지역과 대상 웹사이트 자체를 계속 확인해야 합니다. 브라우저는 작동하지만 다른 앱이 작동하지 않는다면 시스템 프록시 처리 범위와 플랫폼별 차이에 주목하세요.
회선을 선택할 때 노드 이름만 볼 필요는 없습니다. 웹페이지 접속과 개발 도구는 연결 안정성, 올바른 DNS와 장시간 연결 유지를 더 중요하게 봅니다. 동영상 시청은 대역폭을 계속 사용하고 대상 플랫폼의 콘텐츠 전송 정책에도 영향을 받습니다. 원격 회의는 지터, 패킷 손실과 네트워크 전환에 더 민감합니다. 용도가 다르면 적합한 회선도 달라집니다.