VPN 초보자를 위한 완벽 가이드: 구독, 노드, 프로토콜과 분할 라우팅

이 VPN 초보자 가이드는 클라이언트에서 가장 자주 접하는 “구독, 노드, 프로토콜, 분할 라우팅”부터 설명하며, 네트워크 지식을 미리 알 필요가 없습니다. 먼저 설정이 어디에서 오고 트래픽이 어떤 경로를 지나는지 구분한 뒤, 어떤 요청에 국제 회선을 사용할지 판단하는 것이 핵심입니다. 개념을 이해하면 가져오기 실패, 노드는 연결되지만 웹페이지가 열리지 않는 문제, 중국 본토 웹사이트가 느려지는 문제도 모든 옵션을 무작정 바꾸지 않고 순서대로 점검할 수 있습니다.

구독 링크, 설정 파일, 노드란 무엇인가

구독 링크는 클라이언트가 설정을 읽어오는 주소입니다. 클라이언트가 이 주소에 접속하면 서비스에서 배포한 노드 이름, 서버 주소, 포트, 프로토콜 매개변수와 그룹 정보를 가져옵니다. 서비스 제공자가 진입점이나 매개변수를 조정할 때는 보통 클라이언트에서 구독만 업데이트하면 되며, 항목을 일일이 다시 입력할 필요가 없습니다.

구독 링크는 일상적인 웹 브라우징에 사용하는 일반 웹페이지가 아닙니다. 계정 설정과 연결된 접속 자격 정보가 포함될 수 있으므로 포럼, 속도 측정 페이지 또는 스크린샷에 공개해서는 안 되며, 출처가 불분명한 온라인 변환 도구에 제공하는 것도 피해야 합니다. 클라이언트 간 형식 변환이 필요하다면 서비스에서 제공하는 호환 형식을 우선 사용하거나 신뢰할 수 있는 환경에서 변환하세요.

설정 파일은 구독 링크와 목적이 비슷하지만 업데이트 방식이 다릅니다. 정적 설정 파일에는 내보낸 시점의 내용이 저장되고, 구독 링크를 사용하면 클라이언트가 서버의 최신 설정을 다시 가져올 수 있습니다. 노드 이름은 업데이트됐는데 클라이언트에 이전 목록이 계속 표시된다면 회선을 바로 사용할 수 없다고 판단하지 말고 먼저 “구독 업데이트”를 실행한 뒤 로컬 캐시를 확인하세요.

노드는 일반적으로 클라이언트에서 선택할 수 있는 하나의 연결 진입점을 뜻합니다. 이름에는 지역, 도시, 회선 유형 또는 용도 태그가 포함될 수 있지만, 이름만으로 전체 경로를 알 수는 없습니다. 같은 지역으로 표시된 두 노드가 각각 직접 연결, 중계 또는 전용 회선을 사용할 수 있으며, 같은 진입점도 현지 통신사, 접속 네트워크와 대상 웹사이트에 따라 성능이 달라질 수 있습니다.

구독을 가져오는 일반적인 절차

1. 서비스 패널에서 현재 클라이언트와 호환되는 구독 링크를 복사하고, 링크의 문자를 직접 삭제하거나 수정하지 마세요.
2. 클라이언트에서 “구독”, “설정 소스” 또는 “원격 설정”을 찾아 링크를 추가하고 저장하세요.
3. 한 번 업데이트한 뒤 목록에 구독 이름만 보이는 것이 아니라 노드 또는 정책 그룹이 표시되는지 확인하세요.
4. 대상 콘텐츠가 제공되는 지역과 가까운 노드를 선택한 다음 시스템 프록시 또는 터널 모드를 활성화하세요.
5. 대상 웹사이트를 열어 확인하세요. 실패하면 구독 업데이트 시간, 프로토콜 호환성, 시스템 프록시 상태와 DNS 설정을 순서대로 점검하세요.

직접 연결, 중계, IEPL 전용 회선의 차이

노드는 사용자가 보는 진입점이고, 회선은 로컬에서 진입점까지 또는 진입점에서 대상 네트워크까지 데이터가 어떤 경로를 사용하는지 설명합니다. 회선 태그는 1차 선택에 도움이 되지만 실제 품질은 로컬 네트워크, 출구 혼잡, 대상 사이트의 상호접속과 클라이언트 프로토콜에도 영향을 받습니다. 선택할 때는 “노드 지역”과 “회선 유형”을 나누어 살펴보세요.

직접 연결이라고 항상 더 빠른 것은 아닙니다. 로컬에서 해외 진입점까지의 공용 네트워크 경로가 안정적이면 직접 연결이 전달 단계를 줄일 수 있습니다. 반대로 망 간 상호접속 품질이 좋지 않다면 중계가 더 적합한 진입점을 통해 경로를 개선할 수 있습니다. IEPL은 국제 이더넷 전용 회선을 뜻하는 업계 용어지만, 서비스마다 전용 회선의 진입점·출구와 이후 경로를 다르게 설계하므로 이름만으로 모든 트래픽이 같은 전송 방식을 사용한다고 판단할 수 없습니다.

초보자는 회선 선택 시 먼저 대상 콘텐츠가 제공되는 지역으로 필터링한 뒤 회선 유형을 비교하면 됩니다. 예를 들어 일본 지역용 콘텐츠에 접속한다면 단순히 지리적으로 가까운 노드를 고르기보다 일본에 종단된 진입점을 우선 확인하세요. 일상적인 문서, 코드 저장소 또는 웹 브라우징에는 연결 안정성과 도메인 조회가 정상인지 여부를 우선 살펴보는 것이 좋습니다.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2와 TUIC

프로토콜은 클라이언트와 서버가 연결을 수립하고, 신원을 확인하며, 데이터를 캡슐화하고, 전송 방식을 선택하는 방법을 정합니다. 프로토콜 이름만으로 노드 지역을 알 수 없고 속도도 보장되지 않습니다. 서버가 동일한 프로토콜을 지원해야 하며, 클라이언트도 해당 전송 방식과 보안 매개변수를 올바르게 구현해야 연결이 수립됩니다.

Shadowsocks

Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버, 포트, 암호화 방식과 비밀번호가 포함됩니다. 기존의 시스템 수준 VPN보다는 프록시에 가까우며, 모든 애플리케이션을 인계받을 수 있는지는 클라이언트가 시스템 프록시, 가상 네트워크 어댑터 또는 투명 프록시 기능을 제공하는지에 따라 달라집니다. 브라우저는 접속되지만 다른 애플리케이션은 접속되지 않는다면 노드만 확인하지 말고 클라이언트의 인계 모드를 점검하세요.

VMess와 VLESS

VMess는 V2Ray 생태계에서 널리 사용되는 프로토콜로, 인증과 프로토콜 계층 처리를 포함하며 시스템 시간이 크게 어긋난 경우 등에 민감합니다. VLESS는 더 간결한 인증 및 데이터 구조를 사용하고, 자체적으로 완전한 전송 암호화를 제공하지 않으므로 보통 TLS, REALITY 또는 지원되는 다른 보안 전송 방식과 함께 사용합니다. 가져올 때는 서버 주소만 복사하지 말고 전송 유형, 호스트 이름, 경로, 보안 계층과 인증 식별자 등의 매개변수도 유지해야 합니다.

Trojan

Trojan은 일반적으로 TLS 연결 위에서 작동하며, 설정에는 서버 이름, 인증서 검증과 비밀번호가 포함됩니다. 클라이언트 시간, 서버 이름 또는 인증서 검증 매개변수가 일치하지 않으면 TLS 핸드셰이크 단계에서 연결이 실패할 수 있습니다. 인증서 검증을 끄는 것은 일반적인 해결책이 아닙니다. 구독이 완전한지, 시스템 시간이 정확한지, 클라이언트가 설정에 사용된 전송 방식을 지원하는지 확인하는 편이 더 합리적입니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 모두 UDP 기반 QUIC 기술을 활용하며, 패킷 손실이나 변동이 있는 네트워크에서 전송 환경을 개선하고 동시 데이터 스트림을 지원하는 데 초점을 둡니다. 모든 네트워크에서 더 빠른 것은 아닙니다. 일부 사무실 네트워크, 공용 네트워크 또는 라우터 장비가 UDP를 제한하면 핸드셰이크 실패, 곧바른 연결 종료 또는 소량의 데이터만 전송되는 문제가 발생할 수 있습니다. 이 경우 관련 없는 분할 라우팅 규칙을 계속 수정하기보다 TCP와 TLS 기반의 호환 노드로 전환해 비교하세요.

초보자에게 가장 안전한 선택 기준은 프로토콜 이름을 좇는 것이 아니라 서비스가 기본 제공하고 클라이언트가 완전히 지원하는 설정을 우선 사용하는 것입니다. 여러 프로토콜을 사용할 수 있다면 현재 네트워크가 UDP를 허용하는지, 시스템 수준의 인계가 필요한지, 대상 애플리케이션이 안정적인지를 함께 비교하세요.

시스템 프록시, TUN 모드와 VPN 모드의 차이

데스크톱 클라이언트의 일반적인 “시스템 프록시”는 운영체제의 프록시 설정을 변경해 해당 설정을 따르는 애플리케이션이 HTTP 또는 SOCKS 요청을 로컬 클라이언트로 보내도록 합니다. 브라우저는 대체로 시스템 프록시를 사용할 수 있지만 일부 게임, 명령줄 프로그램과 자체 네트워크 스택을 구현한 애플리케이션은 이를 무시할 수 있습니다. 따라서 “브라우저는 정상인데 다른 프로그램은 직접 연결”되는 현상은 인계 범위의 문제인 경우가 많습니다.

TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 다양한 IP 트래픽을 클라이언트로 보낸 다음 규칙에 따라 처리합니다. 적용 범위가 넓은 만큼 라우팅 충돌, 권한, 방화벽과 다른 네트워크 도구의 영향도 더 쉽게 받습니다. 활성화 후 로컬 프린터, LAN 기기 또는 사내 네트워크에 접속할 수 없다면 모든 사설 주소를 원격으로 전달하기보다 LAN 우회 규칙을 확인하세요.

모바일 플랫폼은 일반적으로 시스템이 제공하는 VPN 인터페이스를 통해 트래픽을 인계받습니다. 상태 표시줄에 VPN 표시가 나타나는 것은 시스템 터널 인터페이스가 활성화됐다는 뜻일 뿐, 모든 도메인이 원격 노드를 거친다는 의미는 아닙니다. 클라이언트는 여전히 규칙에 따라 일부 트래픽을 직접 연결할 수 있으며, 이는 규칙 모드에서 정상적인 동작입니다.

• 브라우저만 사용할 수 있음: 시스템 프록시와 애플리케이션 자체의 프록시 설정을 확인하세요.
• 모든 애플리케이션에 접속할 수 없음: 노드 연결, 터널 권한, 기본 라우팅과 DNS를 확인하세요.
• LAN 기기에 접속할 수 없음: 사설 네트워크 우회와 라우팅 충돌을 확인하세요.
• 다른 네트워크로 바꾸면 복구됨: 기존 네트워크가 UDP, 프록시 포트 또는 특정 전송을 제한하는지 확인하세요.

전체 모드, 규칙 모드와 직접 연결 모드 선택 방법

전체 모드는 일반적으로 클라이언트가 인계받은 트래픽을 현재 프록시 노드로 일괄 전달하는 방식입니다. 규칙 모드에서 접속되지 않지만 전체 모드에서는 접속된다면 “문제가 분할 라우팅 규칙과 관련 있는지”를 임시로 확인하는 데 유용합니다. 이때는 프로토콜 자체보다 도메인 매칭, 규칙 우선순위 또는 DNS 조회를 중점적으로 살펴봐야 합니다.

전체 모드는 모든 상황의 기본 해답으로 적합하지 않습니다. 중국 본토 웹사이트, LAN 서비스와 접속 지역에 민감한 애플리케이션까지 원격으로 전달되면 경로가 우회되거나 로그인 환경이 바뀌고 로컬 리소스에 접근할 수 없게 될 수 있습니다. “전체”라는 말도 클라이언트가 성공적으로 인계받은 트래픽에만 해당하며, 시스템 프록시나 터널의 제어를 받지 않는 프로그램은 여전히 직접 연결될 수 있습니다.

규칙 모드는 도메인, IP, 애플리케이션 프로세스 또는 규칙 세트에 따라 트래픽을 프록시, 직접 연결 또는 차단으로 보낼지 결정합니다. 일반적으로 로컬 서비스와 LAN은 직접 연결하고 국제 접속이 필요한 도메인은 프록시를 사용합니다. 규칙은 보통 순서대로 매칭되므로 범위가 넓은 규칙을 앞에 배치하면 뒤의 구체적인 규칙이 가려질 수 있습니다.

직접 연결 모드는 트래픽이 원격 프록시를 거치지 않는 방식입니다. 프록시를 일시 중지하거나 LAN 리소스에 접속하거나 로컬 네트워크가 정상인지 점검할 때 사용합니다. 직접 연결에서도 로컬에서 접속 가능한 웹사이트가 열리지 않는다면 문제는 노드가 아니라 기본 네트워크, 브라우저 캐시 또는 로컬 DNS에 있을 수 있습니다.

실용적인 선택 순서

1. 처음 가져온 후 규칙 모드를 사용하고 대상 콘텐츠 지역에 맞는 노드를 선택하세요.
2. 접속에 실패하면 잠시 전체 모드로 전환해 규칙 누락인지 판단하세요.
3. 전체 모드에서도 실패하면 노드 연결, 프로토콜 호환성, 시스템 시간과 DNS를 확인하세요.
4. 로컬 서비스에 문제가 생기면 직접 연결로 전환해 비교하고 LAN 우회 규칙을 확인하세요.
5. 원인을 확인한 뒤 규칙 모드로 돌아와 필요한 도메인 또는 애플리케이션 규칙만 수정하세요.

DNS 누수란 무엇이며, 왜 “연결은 되는데 열리지 않는” 문제가 생길까

사용자가 도메인을 입력하면 시스템은 먼저 DNS를 통해 해당 주소를 조회합니다. 웹 트래픽은 프록시로 들어가는데 DNS 조회는 여전히 로컬 네트워크가 지정한 리졸버로 전송되면, 로컬 조회 제공자가 조회한 도메인을 볼 수 있습니다. 이를 보통 DNS 누수라고 합니다. 또한 조회 결과와 프록시 출구 지역이 일치하지 않아 대상 웹사이트가 잘못된 주소나 지역 페이지를 반환하거나 연결에 실패할 수도 있습니다.

DNS 누수는 테스트 페이지 하나만으로 결론 내려서는 안 됩니다. 브라우저가 자체 암호화 DNS를 사용하거나 운영체제가 캐시를 유지할 수 있고, 클라이언트가 도메인별로 서로 다른 리졸버를 사용할 수도 있습니다. 올바른 점검 방법은 먼저 현재 인계 모드를 확인한 다음 클라이언트의 DNS 옵션과 분할 라우팅 로직을 살펴보는 것입니다.

DNS 점검 절차

1. 클라이언트에서 원격 DNS, 프록시 DNS 또는 터널이 인계받는 조회 기능을 활성화했는지 확인하세요.
2. 규칙 모드가 IP와 매칭하기 전에 도메인을 먼저 조회하는지 확인하세요. 클라이언트마다 처리 순서가 다를 수 있습니다.
3. 시스템과 브라우저의 DNS 캐시를 삭제한 뒤 노드에 다시 연결해 이전 결과의 영향을 제거하세요.
4. 브라우저 자체의 암호화 DNS를 잠시 끄고 비교해 조회 요청을 누가 전송하는지 확인하세요.
5. TUN을 활성화한 뒤 전혀 조회되지 않는다면 가상 인터페이스 DNS, 시스템 방화벽과 다른 네트워크 도구가 충돌하는지 확인하세요.

DNS가 주소를 정상적으로 반환하지만 연결이 계속 실패하는 경우도 흔합니다. 이때는 대상 트래픽이 실제로 프록시 규칙과 매칭됐는지, 노드가 해당 네트워크 유형을 지원하는지, IPv6 트래픽이 IPv4만 처리하는 설정을 우회하지 않는지를 확인해야 합니다. 클라이언트가 두 주소 유형을 모두 완전히 인계받지 못하면 같은 웹사이트가 어떤 때는 열리고 어떤 때는 열리지 않을 수 있습니다.

분할 라우팅 규칙이 도메인과 애플리케이션을 매칭하는 방식

분할 라우팅 규칙에는 일반적으로 도메인, 도메인 접미사, IP 대역, 지역 규칙, 애플리케이션 프로세스와 최종 기본 규칙이 포함됩니다. 도메인 접미사 규칙은 하나의 사이트와 하위 도메인까지 적용할 수 있지만, 대형 서비스는 콘텐츠 전송, 로그인, 이미지와 API 도메인에도 의존하는 경우가 많습니다. 홈 도메인만 추가하면 페이지 뼈대는 나타나도 콘텐츠 로딩에 실패할 수 있습니다.

규칙 순서도 중요합니다. 클라이언트는 일반적으로 위에서 아래로 내려가며 처음 일치하는 항목을 찾습니다. “모든 도메인 직접 연결”처럼 범위가 넓은 규칙이 앞에 있으면 뒤의 구체적인 프록시 규칙이 적용되지 않습니다. 앞의 조건에 해당하지 않는 요청을 처리하는 최종 규칙을 프록시로 할지 직접 연결로 할지도 전체 동작에 큰 영향을 줍니다.

IP 규칙에는 클라이언트가 먼저 대상 주소를 확보해야 한다는 전제가 있습니다. DNS 조회가 로컬에서 이루어지면 도메인이 프록시 출구와 맞지 않는 주소로 해석될 수 있고, 클라이언트가 원격 조회를 사용하면 결과가 달라질 수도 있습니다. 따라서 지역별 라우팅에 의존하는 웹사이트에는 도메인 규칙을 우선 사용하는 편이 이해하고 관리하기 쉽습니다.

LAN 및 로컬 서비스 → 직접 연결
국제 접속이 명확히 필요한 도메인 → 프록시
로컬 출구를 유지해야 하는 것으로 알려진 애플리케이션 → 직접 연결
매칭되지 않은 트래픽 → 현재 용도에 따라 기본 정책 선택

위 순서는 논리적인 예시일 뿐 바로 가져올 수 있는 설정이 아닙니다. 클라이언트마다 YAML, JSON, 그래픽 규칙 또는 전용 문법을 사용하며 필드 이름도 다릅니다. 규칙을 복사하기 전에 클라이언트 문서를 확인하고, 특히 도메인 접미사·완전한 도메인·키워드 매칭의 차이에 주의하세요.

Windows, macOS, Android, iOS와 Linux 클라이언트의 차이

같은 구독이라도 플랫폼에 따라 옵션이 완전히 동일하게 표시되지 않을 수 있습니다. 이는 보통 노드가 바뀌어서가 아니라 운영체제가 제공하는 네트워크 인터페이스, 백그라운드 제한과 클라이언트 구현이 다르기 때문입니다. 플랫폼을 옮길 때는 클라이언트 이름만 비교하지 말고 프로토콜과 전송 방식이 지원되는지 확인하세요.

Windows 클라이언트는 시스템 프록시와 TUN 모드를 함께 제공하는 경우가 많습니다. TUN에는 가상 네트워크 어댑터 드라이버와 관련 권한이 필요할 수 있으며, 기업 보안 정책이 드라이버 설치를 제한할 수도 있습니다. 클라이언트를 종료한 뒤에도 시스템이 인터넷에 연결되지 않는다면 시스템 프록시가 올바르게 복원됐는지 확인하세요.

macOS는 일반적으로 네트워크 확장을 통해 터널을 만들며, 처음 활성화할 때 관련 시스템 권한을 사용자가 승인해야 합니다. 시스템 프록시와 네트워크 확장은 서로 다른 기능으로 제어될 수 있으므로 메뉴 막대에 연결됨으로 표시되더라도 현재 어떤 인계 모드가 활성화됐는지 확인해야 합니다. 다른 방화벽이나 네트워크 필터 확장이 라우팅과 DNS에 영향을 줄 수도 있습니다.

Android 클라이언트는 보통 시스템 VPNService 인터페이스를 사용하며 애플리케이션별 분할 라우팅을 제공할 수 있습니다. 배터리 최적화와 백그라운드 제한으로 화면이 잠긴 뒤 클라이언트 프로세스가 일시 중지되면 연결 표시는 남아 있지만 데이터가 계속 전송되지 않을 수 있습니다. 연결을 장시간 유지해야 한다면 해당 클라이언트의 백그라운드 실행 정책을 확인하세요.

iOS 클라이언트는 시스템 네트워크 확장을 통해 작동하며, 사용 가능한 프로토콜은 클라이언트 구현과 시스템 권한에 따라 달라집니다. 구독에 포함된 특정 전송 방식을 클라이언트가 지원하지 않으면 무시되거나 사용할 수 없는 항목으로 표시될 수 있습니다. 가져오기 전에 클라이언트 지원 목록을 확인하고, 인식되지 않는 필드를 직접 삭제한 뒤 연결을 계속하지 마세요.

Linux의 차이는 배포판, 데스크톱 환경, 라우팅 도구와 DNS 관리 구성 요소에서 더 많이 발생합니다. 명령줄 프록시는 프록시 환경 변수를 명시적으로 사용하는 프로그램에만 영향을 줍니다. 다른 애플리케이션까지 인계받으려면 보통 TUN, 정책 라우팅 또는 투명 프록시도 설정해야 합니다. 점검할 때는 인터페이스, 라우팅 테이블, DNS 관리와 방화벽 규칙을 각각 확인하세요.

연결 이상을 어떤 순서로 점검할까

프로토콜, 노드, DNS, 분할 라우팅과 시스템 프록시를 동시에 바꾸면 문제의 원인을 찾기 더 어려워집니다. 매번 변수 하나만 변경하고 어느 단계에서 결과가 달라졌는지 기록하는 편이 효과적입니다. 아래 순서는 설정 출처에서 시작해 애플리케이션 측까지 단계별로 확인합니다.

1. 구독 확인: 링크가 중간에 잘리지 않았는지, 업데이트 작업에 명확한 성공 안내가 표시되는지, 노드 목록이 오래된 캐시가 아닌지 확인하세요.
2. 클라이언트 호환성 확인: 클라이언트가 현재 프로토콜, 전송 방식과 보안 매개변수를 지원하는지 확인하세요.
3. 노드 연결 확인: 오류가 DNS, TCP, UDP, TLS 또는 인증 단계 중 어디에서 발생하는지 확인하세요.
4. 인계 방식 확인: 대상 애플리케이션이 시스템 프록시를 따르는지, 또는 TUN이나 시스템 VPN 인터페이스가 인계받았는지 확인하세요.
5. 분할 라우팅 확인: 잠시 전체 모드를 사용해 도메인이 잘못 직접 연결로 분류됐는지 비교하세요.
6. DNS 확인: 캐시를 삭제하고 원격 조회와 브라우저 자체 조회 설정을 대조하세요.
7. 로컬 환경 확인: 방화벽, 다른 VPN, 네트워크 필터 확장과 기업 정책의 충돌을 배제하세요.
8. 네트워크 변경 비교: 같은 설정이 다른 네트워크에서 작동한다면 기존 네트워크의 UDP 및 라우팅 제한을 중점적으로 확인하세요.

클라이언트 로그는 “연결되지 않는다”는 설명보다 더 많은 정보를 제공하지만, 로그를 공유하기 전에 구독 링크, 인증 정보, 서버 자격 증명과 로컬 파일 경로를 삭제해야 합니다. 기술 지원에 플랫폼, 클라이언트 버전, 인계 모드, 노드 프로토콜, 오류가 발생한 단계와 이미 진행한 비교 테스트를 알려주면 화면을 여러 장 연속으로 보내는 것보다 문제를 찾기 쉽습니다.