이 VPN 용어 정리는 구독, 노드, 프로토콜, 트래픽 분할이라는 네 가지 대표 항목부터 시작해 클라이언트 화면의 각 설정이 무엇을 제어하는지 설명합니다. 먼저 다음 원칙을 기억하세요. 구독은 클라이언트에 설정을 전달하고, 노드는 트래픽이 통과할 위치를 정하며, 프로토콜은 클라이언트와 서버의 통신 방식을 규정하고, 트래픽 분할 규칙은 어떤 요청에 회선을 사용할지 결정합니다. 서로 연결되어 있지만 같은 설정은 아닙니다.
연결 문제의 상당수는 개념을 혼동해서 발생합니다. 예를 들어 구독을 성공적으로 가져왔다고 해서 모든 노드가 지금 연결 가능한 것은 아닙니다. 노드 이름에 특정 지역이 표시되어 있어도 전체 네트워크가 전용 회선이라는 뜻은 아니며, 프로토콜을 바꾼다고 잘못된 DNS 설정이 자동으로 수정되지도 않습니다. 각 계층의 역할을 이해하면 문제를 해결할 때 버튼을 반복해서 누르는 대신 연결 경로를 단계별로 확인할 수 있습니다.
구독, 설정 파일, 구독 URL이란 무엇인가
구독은 서버에서 관리하는 설정 목록이라고 이해할 수 있습니다. 목록에는 노드 주소, 포트, 인증 정보, 프로토콜 매개변수, 전송 방식, 표시용 노드 이름 등이 포함될 수 있습니다. 사용자가 호환 클라이언트에 구독 URL을 가져오면 클라이언트가 목록을 읽어 선택 가능한 노드를 생성합니다. 단순히 일반 웹페이지를 여는 방식은 아닙니다.
구독 URL과 단일 노드 설정의 차이는 관리 방식에 있습니다. 단일 설정은 하나의 연결 지점만 설명하므로 회선이 조정되면 다시 가져와야 하는 경우가 많습니다. 구독은 하나의 진입점에서 여러 설정을 업데이트할 수 있습니다. 클라이언트에서 ‘구독 업데이트’를 실행하면 서버가 제공하는 목록을 다시 가져오지만, 로컬 그룹·속도 측정 결과·사용자 지정 규칙을 유지할지는 클라이언트의 병합 방식에 따라 달라집니다.
구독 URL에는 계정이나 요금제 권한을 식별하는 정보가 포함되는 경우가 많으므로 접근 자격 증명처럼 다뤄야 합니다. 공개 페이지, 공유 문서 또는 스크린샷에 올리지 마세요. 클라이언트에서 구독을 삭제하는 것만으로는 서버가 이미 발급한 접근 자격 증명이 변경되지 않습니다. URL이 실수로 공개됐다면 로컬에서 다시 가져오기만 하지 말고 서비스 관리 화면에서 재설정해야 합니다.
- ✅ 가져오기 전에 클라이언트가 구독에 사용된 프로토콜과 설정 형식을 지원하는지 확인하세요.
- ✅ 업데이트 전에 로컬 사용자 지정 그룹과 규칙이 원격 설정으로 덮어써지는지 확인하세요.
- ✅ 구독 URL을 계정 자격 증명으로 관리하고 공개된 환경에서 전달하지 마세요.
- ❌ ‘구독 가져오기 성공’을 모든 노드의 연결 테스트가 완료된 것으로 해석하지 마세요.
가져온 후 클라이언트에서 실제로 하는 일
가져오기 과정에는 일반적으로 구독 콘텐츠 가져오기, 설정 파싱, 프록시 그룹 생성, 규칙 불러오기가 포함됩니다. 이 단계가 끝나야 클라이언트 화면에 노드가 표시됩니다. 가져오기 단계에서 오류가 발생했다면 URL 유효성, 네트워크 접근, 설정 형식 또는 클라이언트 호환성에 문제가 있을 가능성이 큽니다. 노드는 표시되지만 연결되지 않는다면 프로토콜 매개변수, 시스템 시간, 네트워크 환경, 서버 상태를 계속 확인해야 합니다.
QR 코드 가져오기와 URL 붙여넣기는 본질적으로 다르지 않습니다. QR 코드는 텍스트를 전달하기 편한 이미지로 인코딩한 것일 뿐입니다. 가져온 후에는 구독 이름, 노드 목록, 업데이트 시간을 확인해 만료된 설정을 클라이언트 문제로 오인하지 않도록 하세요.
노드, 서버, 회선은 어떻게 다른가
노드는 클라이언트에서 선택할 수 있는 연결 설정입니다. 일반적으로 서버의 한 진입점을 가리키며 프로토콜과 인증 매개변수를 포함합니다. 노드 이름에는 국가·지역·도시·진입점 유형·용도 태그 등이 들어갈 수 있지만, 이름만으로는 실제 네트워크 경로를 완전히 알 수 없습니다.
서버는 인프라를 가리키는 개념에 가깝습니다. 물리 장비, 가상 인스턴스 또는 프록시 서비스를 운영하는 환경일 수 있습니다. 하나의 서버에 여러 노드 설정을 올릴 수 있고, 하나의 노드가 스케줄링 시스템을 통해 서로 다른 백엔드를 가리킬 수도 있습니다. 따라서 노드 수만으로 실제 서버 규모를 추정할 수 없으며, 화면의 각 행을 완전히 독립된 하드웨어로 봐서도 안 됩니다.
회선은 데이터가 사용자 네트워크에서 진입점으로 이동하고, 출구를 거쳐 대상 서비스에 도달하는 경로를 뜻합니다. 로컬 접속, 통신사 간 연결, 국제 전송, 중계 진입점, 최종 출구가 포함됩니다. 노드는 사용자가 클릭할 수 있는 설정 진입점이고, 회선은 트래픽이 실제로 지나가는 네트워크 경로입니다.
| 용어 | 주요 의미 | 흔한 오해 | 확인할 핵심 |
|---|---|---|---|
| 노드 | 클라이언트에서 연결할 수 있는 하나의 설정 | 모든 노드가 독립된 물리 장비에 대응한다 | 지역, 프로토콜, 진입점, 현재 연결 상태 |
| 서버 | 프록시 서비스를 호스팅하는 컴퓨팅 및 네트워크 자원 | 서버 위치가 반드시 최종 출구 위치와 같다 | 실제 출구, 라우팅, 서버 배포 방식 |
| 회선 | 로컬 네트워크에서 대상 서비스까지 트래픽이 지나가는 경로 | 노드 이름만으로 전체 경로의 품질을 알 수 있다 | 진입 방식, 중계 경로, 출구, 대상 네트워크 |
| 출구 | 대상 웹사이트가 확인하는 네트워크 출처 | 진입 지역과 출구 지역은 항상 같다 | 출구 주소, DNS 확인 위치, 대상 서비스 정책 |
직접 연결, 중계, IEPL 전용 회선
직접 연결 회선은 일반적으로 클라이언트가 서비스 제공업체가 마련한 별도의 진입점을 거치지 않고 해외 서버와 직접 연결하는 방식을 뜻합니다. 구조는 단순하지만 로컬 통신사, 망 간 연결, 국제 공용망 라우팅 변화의 영향을 크게 받을 수 있습니다. 거리가 가깝다고 반드시 안정적인 것은 아닙니다. 네트워크 경로는 지도상의 직선이 아니기 때문입니다.
중계 회선은 먼저 더 가까운 곳이나 상호 연결 조건이 좋은 진입점에 연결한 다음, 해당 진입점이 트래픽을 대상 출구로 전달하는 방식입니다. 중계를 사용하면 일부 불리한 공용망 경로를 피하고 서버 측에서 출구를 조정하기 쉬워지지만, 경로 단계가 늘어납니다. 진입점·전달 구간·출구 중 어느 한 곳에서든 혼잡이 발생하면 최종 사용 경험에 영향을 줄 수 있습니다.
IEPL 전용 회선은 일반적으로 특정 네트워크 엔드포인트를 연결하는 국제 이더넷 전용 회선 기능을 뜻합니다. 일반 국제 공용망과는 라우팅 구성 및 자원 보장 방식이 다르지만, ‘전용 회선’이라고 해서 사용자 기기부터 대상 웹사이트까지 모든 구간을 완전히 독점한다는 의미는 아닙니다. 사용자와 진입점 사이의 접속망, 출구와 대상 서비스 사이의 네트워크, 로컬 무선 환경도 최종 연결에 영향을 줍니다.
프록시 프로토콜 이름은 각각 무엇을 뜻하는가
프로토콜은 클라이언트와 서버가 세션을 만들고, 권한을 인증하고, 데이터를 캡슐화하고, 전송을 처리하는 방식을 규정합니다. 프로토콜 이름이 회선 품질을 의미하는 것은 아닙니다. 같은 프로토콜도 서로 다른 네트워크에 배포할 수 있고, 서로 다른 프로토콜이 같은 출구를 공유할 수도 있습니다. 실제 사용 경험은 네트워크 경로, 서버 부하, 클라이언트 구현, 전송 계층, 대상 앱의 영향을 함께 받습니다.
| 프로토콜 | 핵심 특징 | 설정 시 확인할 항목 |
|---|---|---|
| Shadowsocks | 가볍고 암호화된 프록시 프로토콜로, 클라이언트 생태계가 넓습니다 | 암호화 방식, 인증 정보, 클라이언트 지원 여부 |
| VMess | V2Ray 생태계에서 흔히 사용되며 인증과 다양한 전송 조합을 지원합니다 | 사용자 식별자, 전송 방식, TLS, 경로 매개변수가 일치하는지 확인 |
| Trojan | TLS와 함께 사용되는 경우가 많으며 일반적인 암호화 트래픽과 비슷한 연결 형태를 만듭니다 | 도메인, 인증서 검증, 비밀번호, 전송 설정 |
| VLESS | 인증과 전송 계층이 비교적 분리되어 있으며 TLS 같은 보안 계층과 함께 구성하는 경우가 많습니다 | 사용자 식별자, 흐름 제어, 전송 방식, 보안 계층 설정 |
| Hysteria2 | QUIC와 UDP를 기반으로 하며 복잡한 네트워크에서 혼잡 제어를 활용해 전송을 유지하는 데 중점을 둡니다 | UDP 사용 가능 여부, 인증, TLS, 서버 매개변수 |
| TUIC | QUIC 기반 프록시 프로토콜로 다중화와 UDP 전달을 지원합니다 | 클라이언트 버전 호환성, 혼잡 제어, 인증서 검증 |
프로토콜 매개변수는 왜 완전히 일치해야 하는가
프록시 연결은 서버 주소 하나만 확인하는 작업이 아닙니다. 클라이언트와 서버는 포트, 인증 정보, 전송 방식, TLS 설정, 도메인, 경로 등에서도 서로 일치해야 합니다. 핵심 필드가 하나라도 맞지 않으면 시간 초과, 핸드셰이크 실패, 인증서 오류가 발생하거나 연결이 만들어진 뒤 데이터가 전혀 흐르지 않을 수 있습니다.
Trojan과 TLS를 사용하는 VLESS·VMess 설정은 도메인과 인증서 검증을 올바르게 처리해야 하는 경우가 많습니다. 검증을 건너뛰면 인증서 설정 문제를 일시적으로 피할 수 있지만 클라이언트가 서버 신원을 확인하는 능력이 약해지므로 일반적인 문제 해결 방법으로 사용해서는 안 됩니다. 시스템 시간, 도메인, 인증서 체인, 구독 콘텐츠가 서로 일치하는지 확인하는 편이 적절합니다.
Hysteria2와 TUIC는 QUIC와 UDP에 의존합니다. 일부 사무실 네트워크, 공용 네트워크, 라우터 장비는 UDP를 제한하므로 설정이 올바르더라도 안정적인 통신이 어려울 수 있습니다. TCP 기반 호환 설정으로 전환해 문제를 좁혀 볼 수 있지만, 특정 프로토콜이 모든 네트워크에서 본질적으로 더 우수하다는 뜻은 아닙니다.
프로토콜 선택의 핵심은 최신 기술을 무조건 고르는 것이 아닙니다. 먼저 클라이언트가 완전히 지원하는지 확인하고, 현재 네트워크가 해당 전송 방식을 처리할 수 있는지 살펴본 뒤 실제 앱에서 지속적인 연결을 검증하세요. 프로토콜 이름은 통신 방식을 보여줄 뿐 속도와 안정성을 단독으로 보장하지 않습니다.
시스템 프록시, TUN, VPN 인터페이스는 어떻게 작동하는가
데스크톱 클라이언트의 ‘시스템 프록시’는 일반적으로 운영체제의 프록시 설정을 바꿔 해당 설정을 따르는 앱이 HTTP 또는 SOCKS 요청을 클라이언트에 전달하도록 합니다. 설정은 간단하지만 모든 프로그램이 시스템 프록시를 읽는 것은 아닙니다. 일부 게임, 명령줄 도구, 독립 업데이트 프로그램, 자체 네트워크 스택을 구현한 앱은 계속 직접 연결할 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스를 만들어 IP 계층에 가까운 위치에서 트래픽을 받은 뒤 규칙에 따라 프록시 또는 직접 연결 경로로 전달합니다. 시스템 프록시를 지원하지 않는 프로그램까지 더 폭넓게 처리할 수 있고 UDP에도 적합하지만, 추가 시스템 권한이 필요한 경우가 많으며 보안 소프트웨어·다른 네트워크 도구·기업 네트워크 정책과 충돌할 수 있습니다.
Android와 iOS의 프록시 클라이언트는 일반적으로 운영체제가 제공하는 VPN 인터페이스를 사용해 트래픽을 처리합니다. 여기서 ‘VPN’은 운영체제가 제공하는 네트워크 터널 기능을 가리키는 경우가 많으며, 인터페이스를 통과하는 데이터는 여전히 Shadowsocks, Trojan 또는 다른 프록시 프로토콜로 전달될 수 있습니다. macOS는 네트워크 확장을 통해 비슷한 기능을 구현하는 경우가 많고, Windows 클라이언트는 시스템 프록시와 TUN을 함께 제공할 수 있습니다. 두 모드는 적용 범위와 권한 요구 사항이 다릅니다.
- ✅ 브라우저는 접속되지만 독립 앱이 연결되지 않는다면 해당 앱이 시스템 프록시를 따르는지 확인하세요.
- ✅ UDP를 처리해야 하거나 프록시 설정을 읽지 않는 프로그램이라면 TUN 모드를 검토하세요.
- ✅ TUN을 켠 뒤 네트워크 이상이 발생하면 라우팅 충돌, 권한, 다른 네트워크 도구를 확인하세요.
- ❌ 네트워크를 동시에 제어하는 여러 클라이언트를 켜고 자동으로 라우팅을 조정해 주길 기대하지 마세요.
‘LAN 연결 허용’은 무엇을 뜻하는가
이 옵션은 일반적으로 같은 LAN의 다른 기기가 현재 클라이언트가 열어 둔 프록시 포트에 연결할 수 있도록 합니다. 다른 기기에 설정을 자동으로 제공하거나 접근 제어를 자동으로 완료하지는 않습니다. 켠 뒤에는 수신 주소, 방화벽, 인증 설정을 확인해 신뢰할 수 없는 네트워크 환경에 로컬 프록시 포트가 노출되지 않도록 하세요. 프록시를 공유할 필요가 없다면 로컬 기기에서만 접근하도록 유지하는 편이 관리하기 쉽습니다.
글로벌 모드, 규칙 모드, 직접 연결 모드 중 무엇을 선택할까
글로벌 모드는 일반적으로 클라이언트가 제어하는 트래픽을 현재 프록시 노드를 통해 일괄 처리합니다. 특정 앱이 트래픽 분할 규칙 때문에 프록시를 사용하지 않는지 확인하거나 출구를 잠시 검증할 때 유용합니다. 다만 글로벌 모드라고 해서 운영체제의 모든 데이터가 반드시 처리되는 것은 아닙니다. 클라이언트가 시스템 프록시만 활성화한 경우 시스템 프록시를 따르지 않는 프로그램은 계속 직접 연결할 수 있습니다.
규칙 모드는 도메인, IP, 앱, 포트 또는 규칙 집합에 따라 프록시·직접 연결·차단을 결정합니다. 불필요한 우회를 줄일 수 있어 일상적인 사용에서 더 흔히 선택됩니다. 규칙은 계속 관리해야 합니다. 도메인 변경, 콘텐츠 전송 네트워크 조정, 앱의 새 연결 추가로 기존 규칙의 판단이 불완전해질 수 있습니다.
직접 연결 모드는 일반적으로 트래픽이 프록시를 거치지 않도록 합니다. 로컬 네트워크 자체가 정상인지 확인하거나 로컬 네트워크에서만 허용되는 리소스에 접근할 때 적합합니다. 직접 연결은 ‘클라이언트를 종료한다’는 뜻과 완전히 같지 않습니다. 클라이언트가 여전히 DNS, 가상 인터페이스, 규칙 처리를 담당할 수 있으며 구체적인 동작은 구현에 따라 달라집니다.
| 모드 | 트래픽 처리 방식 | 적합한 상황 | 주의할 점 |
|---|---|---|---|
| 글로벌 | 제어 범위 내 요청을 모두 프록시로 처리 | 노드 검증 및 트래픽 분할 누락 점검 | 로컬 서비스가 불필요하게 우회될 수 있고, 제어되지 않는 앱은 계속 직접 연결할 수 있음 |
| 규칙 | 도메인·주소·앱 조건에 따라 경로 선택 | 일상적인 접속에서 로컬 및 국제 트래픽을 함께 사용 | 규칙 집합을 업데이트하고 잘못된 매칭에 주의 |
| 직접 연결 | 요청이 프록시 노드를 거치지 않음 | 로컬 리소스 접속 및 기본 네트워크 점검 | 클라이언트의 DNS 또는 가상 인터페이스가 계속 작동할 수 있음 |
트래픽 분할 규칙은 어떤 순서로 매칭되는가
대부분의 규칙 엔진은 위에서 아래로 확인하고, 규칙이 매칭되면 다음 규칙을 더 이상 검사하지 않으며 마지막에는 기본 규칙으로 처리합니다. 따라서 더 구체적인 앱 또는 도메인 규칙은 범위가 넓은 지역 규칙보다 앞에 두는 것이 일반적입니다. 범위가 넓은 규칙이 먼저 매칭되면 뒤의 정밀한 규칙은 적용되지 않습니다.
대상 앱 전용 도메인 → 지정 프록시 그룹
로컬 서비스 도메인 → 직접 연결
LAN 주소 → 직접 연결
그 밖의 미매칭 요청 → 기본 그룹이 예시는 우선순위를 보여 주기 위한 것이며 바로 복사해 사용할 수 있는 설정 문법은 아닙니다. 클라이언트마다 YAML, JSON, 그래픽 규칙 또는 자체 형식을 사용하므로 필드 이름도 통일되어 있지 않습니다. 수정하기 전에 설정이 로컬에서 관리되는지 원격 구독에서 생성되는지 확인해 구독 업데이트 후 사용자 지정 내용이 사라지는 일을 피하세요.
DNS 누수, 이름 확인, 출구 위치
도메인에 접속하기 전 기기는 일반적으로 DNS를 통해 도메인을 IP 주소로 변환합니다. 웹 트래픽은 프록시를 통과하지만 DNS 질의가 로컬 네트워크에서 직접 전송되면 이름 확인 요청이 예상한 경로를 따르지 않게 되며, 이를 흔히 DNS 누수라고 합니다. 조회 중인 도메인이 노출될 수 있고, 로컬에서 얻은 결과와 프록시 출구 지역이 일치하지 않아 접속 문제가 발생할 수도 있습니다.
클라이언트의 일반적인 DNS 처리 방식에는 시스템 확인기 사용, 원격 서버로 질의 전달, 암호화 DNS를 통한 결과 수신, 규칙 엔진으로 도메인별 확인 경로 선택 등이 있습니다. 암호화 DNS는 질의 전송 과정을 보호할 수 있지만, 요청이 여전히 로컬 네트워크에서 직접 나간다면 자동으로 ‘프록시 출구를 따라 확인’하는 것은 아닙니다. 판단할 때는 질의가 어디에서 나가고 누가 응답하며 결과가 어떤 경로로 전달되는지 함께 확인해야 합니다.
일부 클라이언트는 가상 주소 방식을 사용해 도메인을 예약 주소에 먼저 매핑한 뒤 내부에서 도메인을 복원하고 트래픽 분할을 적용합니다. 시스템에 IP만 요청하는 프로그램을 처리하는 데 도움이 되지만, 일부 LAN 서비스·기업용 소프트웨어·실제 주소를 기준으로 판단하는 앱은 예외 규칙이 필요할 수 있습니다. Fake IP, 원격 DNS, DNS 하이재킹 같은 옵션은 이름만 보고 켜거나 끄지 말고 클라이언트 문서와 현재 모드를 함께 확인해야 합니다.
- ✅ 대상 웹사이트가 열리지 않지만 알고 있는 주소를 직접 입력하면 접속될 때는 먼저 DNS 확인을 점검하세요.
- ✅ 출구 지역은 올바른데 콘텐츠 지역 판정이 이상하다면 DNS와 앱 캐시를 함께 확인하세요.
- ✅ 노드를 바꾼 뒤에는 DNS 캐시와 앱 연결을 새로 고쳐 이전 세션을 계속 사용하지 않도록 하세요.
- ❌ DNS를 바꾸는 것이 모든 연결 문제를 해결하는 만능 방법이라고 생각하지 마세요.
클라이언트 옵션의 일반적인 점검 순서
플랫폼마다 클라이언트 화면은 크게 다르지만 점검 순서는 일관되게 유지할 수 있습니다. 먼저 구독이 정상적으로 업데이트되는지 확인하고, 다음으로 노드 매개변수로 연결을 만들 수 있는지 확인한 뒤 시스템 트래픽 제어 방식을 점검하고 마지막으로 규칙과 DNS를 처리하세요. 이 순서를 따르면 기본 연결이 성립하기 전에 복잡한 트래픽 분할 설정을 성급하게 수정하는 일을 피할 수 있습니다.
- 구독 상태 확인: 구독이 아직 유효한지, 최근 업데이트에 파싱 오류가 없는지, 필요한 노드가 목록에 표시되는지 확인합니다.
- 호환 노드 선택: 클라이언트가 명확히 지원하는 프로토콜을 사용하고 시스템 시간과 TLS 관련 정보를 확인합니다.
- 기본 연결 검증: 일시적으로 글로벌 모드에서 대상 서비스에 접속해 노드 문제와 규칙 누락을 구분합니다.
- 제어 범위 확인: 브라우저는 되지만 다른 앱이 되지 않을 때 TUN 또는 시스템 VPN 인터페이스가 필요한지 판단합니다.
- DNS 점검: 이름 확인 경로가 트래픽 분할 대상과 일치하는지 확인하고 회선을 바꾼 뒤 계속 재사용되는 이전 연결을 정리합니다.
- 일상 규칙 복원: 기본 연결이 안정된 후 규칙 모드를 다시 활성화하고 대상 요청이 실제로 어느 그룹에 매칭됐는지 확인합니다.
로그도 중요한 단서입니다. 구독 파싱 오류, 연결 시간 초과, TLS 핸드셰이크 실패, DNS 질의 실패, 규칙 매칭은 보통 서로 다른 기록을 남깁니다. 로그를 읽을 때는 가장 먼저 발생한 핵심 오류를 찾고 이후에 반복되는 재시도 메시지에 묻히지 않도록 하세요. 고객 지원 문의를 제출할 때 오류 유형, 클라이언트 이름, 플랫폼, 사용 모드, 문제가 발생한 노드 유형을 제공할 수 있지만 구독 URL·인증 정보·전체 설정은 가려야 합니다.
일상적으로 사용하는 경우에는 기본 매개변수를 자주 수정할 필요가 없습니다. 구독을 최신 상태로 유지하고, 현재 네트워크와 호환되는 노드를 선택하며, 규칙 모드로 사용하고, 특정 앱이 제어되지 않을 때 TUN과 DNS를 확인하는 것만으로도 대부분의 일반적인 상황에 대응할 수 있습니다. 설정을 직접 편집해야 한다면 하나의 문제를 기준으로 항목을 조정하고 매번 변수 하나만 바꾸세요. 결과를 더 쉽게 판단할 수 있습니다.