VPN 관련 용어는 많아 보여도 하나의 연결 과정을 따라가면 쉽게 이해할 수 있습니다. 서비스 제공자가 먼저 구독 링크를 제공하면 클라이언트가 그 안의 노드 설정을 읽고, 프로토콜에 따라 연결을 설정합니다. 이후 트래픽은 직접 연결, 중계 또는 IEPL 같은 회선을 거치며, 마지막으로 분할 라우팅 규칙이 어떤 요청을 프록시로 보낼지 결정합니다. 이 흐름을 파악하면 대부분의 클라이언트 옵션이 더 이상 서로 무관한 용어처럼 보이지 않습니다.
일상적인 대화에서 ‘VPN’은 네트워크 프록시와 가속 서비스를 통칭하는 경우가 많지만, 기술적으로는 전통적인 VPN 터널이 아닐 수도 있습니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC은 서로 다른 프록시 프로토콜 또는 프로토콜 체계에 속합니다. 시스템 설정에 표시되는 VPN 스위치 역시 클라이언트가 운영체제의 가상 네트워크 인터페이스를 이용해 트래픽을 처리한다는 의미일 수 있습니다. 연결 방식을 판단할 때는 제품명만 보지 말고 프로토콜, 클라이언트 작동 모드와 실제 라우팅을 함께 확인해야 합니다.
구독 링크부터 시작하기: 일반적인 다운로드 주소가 아닙니다
구독 링크는 클라이언트가 읽는 설정 진입점입니다. 클라이언트가 링크에 접속하면 보통 노드 이름, 서버 주소, 포트, 프로토콜 매개변수와 그룹 정보를 받아 선택 가능한 노드 목록으로 정리합니다. 서비스 제공자가 회선을 업데이트하면 사용자는 클라이언트에서 구독을 새로 고칠 수 있어 서버 설정을 하나씩 직접 수정할 필요가 없습니다.
구독 링크와 단일 노드 설정은 같은 것이 아닙니다. 전자는 지속적으로 업데이트되는 설정 목록에 가깝고, 후자는 특정 연결 하나만 설명합니다. 일부 클라이언트는 단일 공유 링크 가져오기도 지원하지만, 단일 설정에는 구독에 포함된 이후 변경 사항이 자동으로 반영되지 않습니다. 기기를 옮길 때는 클라이언트의 ‘URL에서 가져오기’ 또는 ‘구독 추가’ 기능을 우선 사용하고, 구독 내용을 웹페이지처럼 직접 열지 마세요.
- ✅ 서비스 패널에서 구독 주소 전체를 복사하고, 시작 부분·끝부분·쿼리 매개변수가 빠지지 않았는지 확인하세요.
- ✅ 해당 클라이언트에서 단일 노드 서버 입력란이 아니라 구독 추가를 선택하세요.
- ✅ 가져온 뒤 한 번 업데이트하여 노드 이름과 그룹이 정상적으로 표시되는지 확인하세요.
- ✅ 구독 주소를 변경한 뒤에는 만료된 설정을 삭제하여 이전 노드를 잘못 선택하지 않도록 하세요.
- ❌ 구독 주소를 공개적으로 공유할 수 있는 회선 목록처럼 취급하지 마세요.
노드는 회선이 아닙니다: 직접 연결·중계·IEPL의 차이
노드는 클라이언트에서 선택할 수 있는 연결 진입점으로, 보통 지역·도시·용도 또는 회선 유형으로 이름을 정합니다. 즉 ‘어떤 설정에 연결할 것인가’를 나타냅니다. 회선은 사용자 네트워크와 출구 서버 사이에서 데이터가 어떻게 전송되는지를 설명하며, ‘트래픽이 어떤 경로를 거치는가’를 뜻합니다. 같은 지역에도 여러 회선이 있을 수 있고, 하나의 회선이 클라이언트에서 여러 노드로 표시될 수도 있습니다.
직접 연결은 일반적으로 사용자 네트워크가 서비스 제공자가 구축한 전용 진입점이나 전달 서버를 거치지 않고 해외 서버에 직접 연결하는 방식을 의미합니다. 경로는 단순하지만 현지 통신망에서 대상 지역까지의 공용 인터넷 라우팅에 영향을 크게 받습니다. 저녁 시간대의 혼잡, 통신망 간 우회 또는 국제 출구 변동으로 인해 같은 노드도 네트워크 환경에 따라 성능이 달라질 수 있습니다.
중계는 사용자와 출구 서버 사이에 전달 진입점을 추가하는 방식입니다. 사용자가 먼저 가까우면서 안정적인 중계 서버에 연결하면, 중계 서버가 트래픽을 최종 출구로 전달합니다. 적절한 중계는 불안정한 공용 인터넷 경로 일부를 피하는 데 도움이 될 수 있지만, 서버를 더 많이 거친다고 반드시 빨라지는 것은 아닙니다. 진입점 품질, 전달 경로와 출구 부하가 모두 중요합니다.
IEPL은 일반적으로 통신사가 제공하는 국제 이더넷 전용 회선 상품을 뜻합니다. 프록시 서비스에서 IEPL 노드는 회선의 일부가 전용 회선 또는 전용 전송 자원을 사용하여 일반적인 국제 공용 인터넷 경로에 대한 의존도를 낮춘다는 의미인 경우가 많습니다. 이를 ‘모든 구간이 완전히 독점된다’고 단순하게 이해해서는 안 되며, 노드 이름만으로 실제 품질을 판단할 수도 없습니다. 현지 네트워크, 대상 지역과 실제 사용하는 애플리케이션을 함께 고려하는 것이 더 현실적인 선택 방법입니다.
| 용어 | 설명하는 대상 | 주요 특징 | 판단 방법 |
|---|---|---|---|
| 노드 | 클라이언트의 연결 설정 | 주소·포트·프로토콜·이름 포함 | 지역·용도·현재 연결 가능 여부 확인 |
| 직접 연결 | 현지 네트워크에서 출구까지의 공용 인터넷 경로 | 경로 구조가 단순하고 공용 인터넷 라우팅의 영향을 크게 받음 | 먼저 현지 네트워크에서 대상 지역까지의 성능을 테스트하기 적합 |
| 중계 | 전달 진입점을 거치는 전송 경로 | 통신망 간 구간과 국제 구간의 경로를 조정할 수 있음 | 직접 연결이 불안정할 때 전환하여 비교 |
| IEPL | 전용 회선 또는 전용 전송 자원 | 일부 일반 공용 인터넷 구간에 대한 의존도 감소 | 이름만 보지 말고 실제 연결 품질을 확인 |
| 출구 | 최종적으로 대상 웹사이트에 접속하는 서버 | 대상 웹사이트에 표시되는 출구 지역을 결정 | 콘텐츠 지역과 접속 목적에 따라 선택 |
주요 프로토콜 읽는 법: 이름은 달라도 역할은 비슷합니다
프로토콜은 클라이언트와 서버가 핸드셰이크, 인증, 암호화와 데이터 전송을 수행하는 방식을 정합니다. 노드 지역이 같다고 하여 하위 프로토콜까지 같은 것은 아니며, 프로토콜이 같아도 회선 품질이 동일하지는 않습니다. 프로토콜은 호환성, 전송 특성과 네트워크별 성능에 영향을 주고, 회선은 데이터가 실제로 거치는 네트워크 경로를 결정하므로 두 개념을 나누어 이해해야 합니다.
Shadowsocks
Shadowsocks는 가벼운 암호화 프록시 프로토콜로, 설정에는 보통 서버, 포트, 비밀번호와 암호화 방식이 포함됩니다. 구현이 성숙하고 지원 클라이언트가 많아 일반적인 웹과 애플리케이션 프록시에 적합합니다. 전통적인 기업용 VPN은 아니며, 모든 시스템 트래픽이 자동으로 프록시를 통과하도록 결정하지도 않습니다. 최종 적용 범위는 클라이언트의 시스템 프록시, TUN 모드와 분할 라우팅 설정에 따라 달라집니다.
VMess와 VLESS
VMess는 V2Ray 생태계에서 자주 사용되며 자체 인증과 전송 설정을 갖습니다. VLESS는 신원 인증과 암호화 전송의 역할을 더 분리하며, 실제 배포에서는 보통 TLS, REALITY 또는 다른 전송 방식과 함께 사용됩니다. VMess나 VLESS를 볼 때는 프로토콜 이름만 비교하지 말고 전송 계층, 서버 이름, 인증서 관련 매개변수와 클라이언트가 전체 설정을 지원하는지 확인해야 합니다.
Trojan
Trojan은 보통 TLS 위에서 작동하며, 설정에는 서버 주소, 비밀번호, 포트와 서버 이름이 자주 포함됩니다. 올바른 TLS 설정이 필요하므로 시스템 시간이 크게 틀렸거나 서버 이름이 일치하지 않거나 인증서 검증에 실패하면 연결이 수립되지 않을 수 있습니다. 인증서 검증 해제는 일반적인 문제 해결 방법으로 사용하지 말고, 설정이 완전한지와 클라이언트 버전이 호환되는지부터 확인해야 합니다.
Hysteria2와 TUIC
Hysteria2와 TUIC은 모두 UDP 기반 QUIC 전송을 활용하고 혼잡 제어를 적용해 특정 네트워크 환경에서 전송 성능을 개선합니다. 그렇다고 모든 네트워크에서 항상 더 빠른 것은 아닙니다. 현재 네트워크가 UDP를 제한하거나, 라우터 처리에 문제가 있거나, 공용 네트워크가 장시간 UDP 세션에 적합하지 않다면 TCP 기반 방식보다 연결이 불안정할 수 있습니다. 이 경우 클라이언트 매개변수를 계속 높이기보다 프로토콜이나 회선을 변경해야 합니다.
| 프로토콜 | 주요 전송 기반 | 초보자가 확인할 설정 | 일반적인 호환성 문제 |
|---|---|---|---|
| Shadowsocks | TCP와 UDP | 암호화 방식·비밀번호·포트 | 구형 클라이언트가 새로운 암호화 방식을 지원하지 않음 |
| VMess | 여러 전송 계층과 함께 사용 가능 | 신원 정보·전송 방식·TLS 매개변수 | 가져오기 과정에서 전송 계층 설정이 누락됨 |
| VLESS | TLS, REALITY 등의 방식과 함께 사용 가능 | 신원 정보·흐름 제어·서버 이름 | 클라이언트에 해당 전송 기능이 없음 |
| Trojan | TLS와 TCP | 비밀번호·서버 이름·인증서 검증 | 시간·도메인 또는 인증서 매개변수가 일치하지 않음 |
| Hysteria2 | QUIC과 UDP | 인증·TLS·대역폭 관련 설정 | 현재 네트워크가 UDP를 제한함 |
| TUIC | QUIC과 UDP | 신원 정보·TLS·혼잡 제어 | 클라이언트 버전 또는 UDP 환경이 호환되지 않음 |
분할 라우팅과 전체 모드: 어떤 트래픽을 프록시로 보낼지 결정하기
노드에 연결한 뒤에도 클라이언트는 트래픽의 방향을 결정해야 합니다. 직접 연결은 요청이 프록시 노드를 거치지 않는 방식이고, 프록시는 요청을 현재 노드나 프록시 그룹으로 전달하는 방식입니다. 거부는 클라이언트가 요청을 바로 차단하는 동작입니다. 분할 라우팅 규칙은 도메인, IP 주소, 애플리케이션, 포트 또는 규칙 세트에 따라 요청을 이러한 동작으로 배분합니다.
규칙 모드는 분할 라우팅 모드라고도 합니다. 일반적으로 국내 웹사이트와 로컬 네트워크 리소스는 직접 연결로 유지하고, 국제 회선이 필요한 요청은 프록시로 보내며, 광고나 알려진 위험 도메인은 거부합니다. 불필요한 우회를 줄이고 출구 지역 변경으로 인해 현지 서비스에서 추가 인증이 발생하는 문제를 피할 수 있다는 장점이 있습니다. 반면 규칙을 관리해야 하며, 대상 웹사이트가 새 도메인이나 공유 인프라를 사용하면 기존 규칙이 잘못 판단할 수 있습니다.
전체 모드는 보통 클라이언트가 처리할 수 있는 대부분의 트래픽을 프록시로 전달하는 방식입니다. ‘규칙이 적용되지 않은 것인지’를 확인할 때나 짧은 시간 동안 출구를 통일해야 할 때 적합합니다. 다만 전체 모드라고 해서 기기의 모든 트래픽을 클라이언트가 처리할 수 있는 것은 아닙니다. 시스템 프록시는 일반적으로 프록시 설정을 따르는 애플리케이션에만 영향을 주고, TUN 모드는 더 넓은 범위를 처리하지만 운영체제 권한, 라우팅 우선순위와 애플리케이션 자체 네트워크 구현의 영향을 받을 수 있습니다.
직접 연결 모드는 요청이 프록시를 우회하도록 하며, 프록시의 영향을 잠시 중지하거나 문제가 노드에서 비롯되었는지 확인할 때 사용할 수 있습니다. 모드를 바꾼 뒤에는 대상 애플리케이션을 다시 여는 것이 좋습니다. 기존 연결이 이전 네트워크 세션을 계속 재사용하면 모드가 적용되지 않은 것처럼 보일 수 있습니다.
- ✅ 일상적인 웹 이용에는 정상적으로 관리되는 규칙 모드를 우선 사용하여 현지 접속과 국제 접속이 각각 적절한 경로를 사용하도록 하세요.
- ✅ 특정 웹사이트가 열리지 않으면 잠시 전체 모드로 전환하여 규칙 누락인지 확인하세요.
- ✅ 현지 서비스에 문제가 생기면 해당 도메인이 실수로 프록시로 분류되지 않았는지 확인하세요.
- ✅ 로컬 네트워크 프린터, 파일 공유 또는 라우터 관리 페이지에 문제가 생기면 로컬 네트워크 주소가 직접 연결로 유지되는지 확인하세요.
- ❌ 전체 모드를 속도 향상 스위치로 이해하지 마세요. 전체 모드는 트래픽의 방향만 바꿉니다.
클라이언트 가져오기: 시스템 프록시와 TUN은 서로 다릅니다
플랫폼마다 클라이언트 화면은 크게 다르지만 핵심 작업은 같습니다. 구독을 저장하고, 노드를 해석하고, 연결을 설정한 뒤 트래픽을 처리합니다. 가져오기에 성공했다는 것은 설정이 클라이언트에 들어갔다는 뜻일 뿐, 시스템 트래픽이 이미 프록시를 통과한다는 의미는 아닙니다. 시스템 프록시, VPN 설정 또는 TUN 모드를 켜고 운영체제가 요구하는 네트워크 권한도 부여해야 합니다.
데스크톱 운영체제의 시스템 프록시는 주로 운영체제의 프록시 설정에 기록됩니다. 브라우저와 시스템 설정을 따르는 대부분의 애플리케이션이 이를 사용하지만, 일부 게임·명령줄 프로그램과 자체 네트워크 스택을 구현한 소프트웨어는 설정을 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 통해 더 넓은 범위의 TCP, UDP와 DNS 요청을 처리합니다. 더 많은 애플리케이션을 포함해야 할 때 적합하지만 기업용 VPN, 가상 머신, 컨테이너 네트워크 또는 보안 소프트웨어와 라우팅 충돌이 발생하기도 쉽습니다.
모바일 플랫폼은 보통 운영체제가 제공하는 VPN 인터페이스를 통해 로컬 터널을 설정합니다. 상태 표시줄에 VPN 표시가 나타난다는 것은 클라이언트가 시스템 터널 권한을 얻었다는 뜻이며, 하위 계층이 반드시 전통적인 VPN 프로토콜을 사용한다는 의미는 아닙니다. iOS는 백그라운드 실행, 네트워크 확장과 구독 가져오기에 플랫폼 제한이 있습니다. Android는 선택지가 더 많지만, 제조사별 시스템 버전에 따라 백그라운드 유지, 배터리 정책과 항상 연결 설정을 처리하는 방식이 다를 수 있습니다.
Windows와 macOS에서는 TUN 드라이버나 네트워크 확장 기능을 설치할 때 관리자 승인이 필요할 수 있습니다. Linux 클라이언트는 그래픽 인터페이스, 명령줄 코어와 투명 프록시 방식을 함께 제공하는 경우가 많아 라우팅 테이블, DNS 서비스와 방화벽 규칙을 더 명확하게 설정해야 합니다. 초보자는 처음부터 가장 복잡한 투명 프록시를 추구할 필요가 없습니다. 먼저 클라이언트 권장 모드로 구독과 노드가 작동하는지 확인한 뒤, 필요한 애플리케이션 범위에 맞춰 조정하세요.
| 처리 방식 | 적용 범위 | 적합한 상황 | 주의할 점 |
|---|---|---|---|
| 브라우저 프록시 | 지정한 브라우저 또는 확장 프로그램 | 웹 접속만 처리 | 다른 애플리케이션은 자동으로 따르지 않음 |
| 시스템 프록시 | 시스템 프록시 설정을 따르는 애플리케이션 | 일반적인 데스크톱 웹 이용과 업무용 애플리케이션 | 일부 프로그램은 시스템 설정을 우회함 |
| TUN 모드 | 가상 인터페이스를 통해 라우팅되는 트래픽 | 게임·명령줄과 더 많은 애플리케이션 | 다른 네트워크 도구와 충돌할 수 있음 |
| 모바일 시스템 터널 | 운영체제가 처리를 허용한 애플리케이션 트래픽 | 모바일 기기의 통합 연결 | 백그라운드 정책과 시스템 권한의 영향을 받음 |
DNS 누출이란 무엇인가: 도메인 조회도 올바른 경로로 보내야 합니다
웹사이트에 접속하기 전에 기기는 보통 DNS를 통해 도메인을 IP 주소로 변환합니다. 웹 트래픽은 프록시를 통과하지만 DNS 조회가 현지 네트워크가 제공하는 DNS 서버로 직접 전송되면 조회 경로와 접속 경로가 달라질 수 있습니다. 이를 일반적으로 DNS 누출이라고 합니다. 조회 중인 도메인이 노출될 수 있고, 현재 출구 지역에 적합하지 않은 주소가 반환되어 웹사이트가 열리지 않거나 콘텐츠 지역 판단이 잘못되거나 연결이 우회될 수도 있습니다.
클라이언트에서 흔히 사용하는 방식에는 프록시 DNS, 암호화 DNS, 가상 IP와 규칙 기반 DNS 분할이 있습니다. 프록시 DNS는 조회를 프록시 경로로 전달하고, 암호화 DNS는 HTTPS 또는 TLS로 조회 전송을 보호합니다. 가상 IP는 먼저 클라이언트가 관리하는 주소를 애플리케이션에 반환한 뒤 도메인 규칙에 따라 실제 요청을 전달합니다. 어느 방식이든 환경과 무관하게 항상 우월한 것은 아니며, 핵심은 DNS 결과가 분할 라우팅 동작과 일치하는지입니다.
예를 들어 어떤 도메인이 프록시로 분류되었지만 DNS 조회가 현지 직접 연결을 거쳐 특수한 결과를 반환하면 이후 연결이 실패할 수 있습니다. 반대로 현지 서비스가 원격 DNS로 보내지면 현지 네트워크에 적합하지 않은 주소를 받을 수도 있습니다. 문제를 확인할 때는 도메인에 적용된 규칙, DNS 서버 선택, IPv6 활성화 여부와 브라우저가 시스템과 별도로 보안 DNS를 사용하는지 함께 점검해야 합니다.
문제 해결 순서에 따라 처리하기: 설정에서 애플리케이션까지 범위를 단계적으로 좁히기
초보자는 여러 매개변수를 연달아 바꾸기 쉽지만, 그러면 어떤 변경이 효과가 있었는지 알 수 없게 됩니다. 더 안정적인 방법은 한 번에 하나의 변수만 바꾸면서 구독, 노드, 프로토콜, 처리 모드, DNS와 실제 애플리케이션을 단계별로 확인하는 것입니다.
- ✅ 먼저 구독을 새로 고쳐 클라이언트에 인증 실패, 설정 해석 실패 또는 구독 만료가 표시되지 않는지 확인하세요.
- ✅ 같은 유형의 다른 노드를 선택하여 문제가 단일 노드에서 발생하는지 아니면 클라이언트 전체의 문제인지 확인하세요.
- ✅ UDP가 제한된 네트워크에서는 TCP 기반의 사용 가능한 프로토콜로 바꾸어 비교하세요.
- ✅ 규칙 모드에 문제가 있을 때 잠시 전체 모드로 전환하여 규칙 누락 여부를 확인하세요.
- ✅ 브라우저는 작동하지만 다른 애플리케이션이 작동하지 않는다면 현재 시스템 프록시만 켜져 있는지 확인하세요.
- ✅ 도메인은 열리지 않지만 알려진 서비스에 직접 접속할 수 있다면 DNS 설정과 조회 경로를 확인하세요.
- ✅ 설정을 바꾼 뒤 연결을 다시 설정하고 대상 애플리케이션의 기존 네트워크 세션을 종료하세요.
- ❌ 프로토콜, 노드, DNS와 분할 라우팅 규칙을 동시에 변경하지 마세요. 원인을 찾기 어려워집니다.
‘노드에 연결할 수 없음’과 ‘대상 웹사이트에 접속할 수 없음’도 구분해야 합니다. 전자는 보통 핸드셰이크 단계에서 발생하며 클라이언트에 시간 초과, 인증 또는 인증서 관련 오류가 표시됩니다. 후자는 잘못된 분할 라우팅, 부적절한 DNS 결과, 웹사이트의 지역 정책 또는 애플리케이션 캐시 때문일 수 있습니다. 프록시 연결을 설정할 수 있다는 것은 클라이언트와 서버 사이의 통로가 형성되었다는 뜻일 뿐, 모든 대상 서비스가 정상적으로 응답한다는 의미는 아닙니다.
속도 측정도 실제 사용 환경을 검증하는 과정을 대신할 수 없습니다. 웹페이지 최초 로딩 속도, 장시간 연결 안정성, 파일 전송과 실시간 통신은 회선에 요구하는 조건이 서로 다릅니다. 초보자라면 먼저 연결 안정성, DNS와 분할 라우팅이 올바른지 확인한 뒤 자신의 용도에 맞는 노드를 비교하는 것이 단일 테스트 결과를 반복해서 좇는 것보다 의미 있습니다.