프로토콜 및 회선 기술 가이드

프로토콜과 회선 이해: 연결의 두 가지 구조

클라이언트에서 "연결" 버튼을 클릭하면 실제로는 두 가지 독립적인 일이 일어납니다. 첫째, 기기가 특정 프로토콜로 데이터를 캡슐화하고 암호화하여 공용 네트워크에서 안전하게 전송합니다. 둘째, 이 암호화된 데이터는 특정 회선 경로를 따라 기기에서 출발해 여러 중간 노드를 거쳐 최종 목적지 서버에 도달합니다. 프로토콜과 회선은 서로 독립적인 두 축입니다. 같은 프로토콜도 다른 회선에서 실행될 수 있고, 같은 회선도 다른 프로토콜을 수용할 수 있습니다.

많은 사용자는 "연결되는지"만 신경 쓰지만, 고급 사용자는 이 두 가지 구조를 이해하면 대부분의 모호한 문제를 해결할 수 있다는 것을 알게 됩니다. "회선을 바꿔도 왜 여전히 느리지?" "이 프로토콜은 왜 폰에서 배터리를 특히 많이 먹지?" "왜 항상 저녁 피크 시간에 끊기지?" 이런 질문의 답은 프로토콜과 회선의 상호작용 속에 숨어 있습니다.

프로토콜 계층: 데이터가 어떻게 캡슐화되고 전송되는가

프록시 프로토콜이 해결하는 핵심 문제는 공용 네트워크에서 데이터를 안전하고 은밀하게 전송하는 방법입니다. 각 프로토콜은 서로 다른 암호화 알고리즘, 핸드셰이크 절차, 위장 전략을 사용합니다. 어떤 프로토콜은 극도의 경량성을 추구하고(예: Shadowsocks), 어떤 프로토콜은 일반 HTTPS 트래픽으로 위장하는 데 최적화되어 있으며(예: Trojan), 어떤 프로토콜은 현대 전송 프로토콜의 특성을 활용해 네트워크 지터에 대응합니다(예: Hysteria2).

프로토콜 선택은 세 가지 핵심 지표에 영향을 미칩니다: 연결 설정 속도, 전송 처리량, 리소스 사용량. 연결 설정 속도는 연결 버튼을 클릭한 후 얼마나 빨리 브라우징을 시작할 수 있는지 결정합니다. 전송 처리량은 스트리밍, 파일 다운로드 같은 대용량 트래픽 시나리오의 상한을 결정합니다. 리소스 사용량은 기기의 CPU와 메모리 소모에 영향을 미치며, 모바일 기기에서는 직접 배터리 소모로 이어집니다.

회선 계층: 데이터가 어떤 경로를 타는가

회선은 데이터가 사용자에서 목적지 서버까지 가는 물리적 경로를 결정합니다. 직결 회선은 목적지 지역 서버에 직접 연결하는 방식으로 경로가 가장 짧지만 국제 출구 혼잡의 영향을 크게 받습니다. 중계 회선은 중간 노드를 거쳐 "우회"하는 방식으로 지연이 약간 높을 수 있지만 더 안정적입니다. 전용선은 통신사급 고품질 링크로, 서비스 제공자가 임대하거나 자체 구축하여 지연과 안정성이 모두 보장됩니다.

VPNXE는 120개 이상의 국가 / 190개 이상의 회선을 제공하며, 회선마다 토폴로지 유형이 다릅니다. 회선 토폴로지를 이해하면 다음과 같은 판단을 할 수 있습니다: 어떤 회선은 낮에는 매우 빠르다가 밤에는 왜 버벅일까? 전용선은 비싸지만 왜 가치가 있을까? "노드가 많을수록 좋다"는 말이 왜 완전히 맞지는 않을까?

다음 장에서는 프로토콜과 회선 두 축을 각각 자세히 살펴보고, 마지막으로 시나리오별 선택 권장안을 제시합니다. 순서대로 읽어도 되고, 관심 있는 장으로 바로 건너뛰어도 됩니다. 각 회선은 노드 페이지에 유형 표시가 있으므로, 읽고 나면 그 표시의 의미를 이해할 수 있습니다.

주요 프록시 프로토콜의 설계 트레이드오프

현재 주요 프록시 프로토콜은 여섯 가지입니다: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC. 각각의 중점이 다르므로, 이러한 차이를 이해하는 것이 선택의 전제 조건입니다. 아래에서 하나씩 설명합니다.

Shadowsocks: 가볍고 널리 쓰이는 프로토콜

Shadowsocks는 가장 클래식한 프록시 프로토콜 중 하나로, 방화벽 환경에서 경량의 저지연 암호화 터널을 제공하는 것이 설계 목표입니다. SOCKS5 프록시 모드를 사용하며, 암호화 방식이 간단하고(보통 AES-256-GCM 또는 ChaCha20-Poly1305), 핸드셰이크 절차가 짧아 연결 설정 속도가 빠르고 CPU 점유율도 낮습니다. 생태계가 매우 성숙하여 거의 모든 클라이언트가 기본 지원하고, 설정 형식도 가장 간단합니다. 단점은 암호화 트래픽 특성이 비교적 뚜렷하여 심층 패킷 검사 환경에서 식별되기 쉽다는 점입니다.

VMess: V2Ray의 핵심 프로토콜

VMess는 V2Ray 프로젝트에서 도입된 프로토콜로, Shadowsocks의 트래픽 특성이 뚜렷한 문제를 해결하는 것이 설계 목표입니다. UUID를 신원 식별자로 도입하고, 매 연결마다 무작위 요청 ID를 생성하며, AEAD 암호화와 결합하여 트래픽 특성을 식별하기 어렵게 만듭니다. VMess는 다중화도 지원하여 하나의 TCP 연결에서 여러 요청을 동시에 전송할 수 있어 핸드셰이크 오버헤드를 줄입니다. 대가는 프로토콜 헤더가 더 복잡해져 연결 설정 속도가 Shadowsocks보다 약간 느리고 CPU 점유율도 약간 높습니다.

Trojan: HTTPS 트래픽으로 위장

Trojan의 핵심 아이디어는 "정상적인 HTTPS 트래픽으로 위장"하는 것입니다. TLS 프로토콜을 외부 레이어로 직접 사용하여 서버와 클라이언트 간 통신이 평범한 HTTPS 웹사이트처럼 보이게 만들어, 심층 패킷 검사 앞에서 식별되기 매우 어렵습니다. Trojan은 추가 암호화 레이어가 필요 없고(TLS가 이미 암호화하므로) VMess보다 오버헤드가 낮고 연결 속도도 빠릅니다. 설정이 비교적 간단하며 도메인과 인증서만 있으면 되므로, 여러 시나리오에서 은밀성과 성능을 모두 갖춘 선택지입니다.

VLESS: VMess의 중복 제거 개선

VLESS는 VMess의 개선판으로, 핵심 변화는 VMess의 중복 암호화 레이어를 제거한 것입니다. VMess는 요청 본문을 AEAD로 암호화하지만, VLESS는 외부에 TLS 암호화가 이미 있다면 이 암호화 레이어는 불필요하다고 봅니다. CPU 오버헤드와 연결 지연만 늘릴 뿐입니다. 따라서 VLESS는 VMess보다 가볍고 연결 설정이 빠르며, VMess의 식별 저항 능력은 유지합니다. VLESS는 보통 XTLS와 함께 사용되며, XTLS는 TLS 핸드셰이크 후 원시 트래픽을 직접 투과시켜 오버헤드를 더 줄입니다.

Hysteria2: QUIC 기반의 패킷 손실 대응 설계

Hysteria2는 QUIC 프로토콜을 기반으로 합니다. QUIC는 UDP 위에서 동작하는 전송 프로토콜로, 자연스러운 혼잡 제어와 연결 마이그레이션 기능을 갖추고 있습니다. Hysteria2의 강점은 혼잡 제어 알고리즘입니다. 네트워크를 "최선형"으로 가정하고 공격적인 전송 전략으로 가용 대역폭을 채우기 때문에, 패킷 손실률이 높은 네트워크(예: 저녁 피크 시간의 국제 출구)에서 TCP 기반 프로토콜보다 더 나은 성능을 보이는 경우가 많습니다. 대가는 네트워크 상태가 좋을 때 대역폭을 과도하게 사용할 수 있고, 일부 네트워크에서는 UDP 트래픽이 제한될 수 있다는 점입니다.

TUIC: 경량 QUIC 프로토콜

TUIC도 QUIC를 기반으로 하지만 설계 방향은 Hysteria2와 다릅니다. "오버헤드 최소화"를 추구하며, QUIC 위에 아주 얇은 프록시 캡슐화만 추가하고 Hysteria2처럼 공격적인 혼잡 제어는 없습니다. TUIC는 특히 모바일 시나리오에 적합합니다. QUIC의 연결 마이그레이션 특성 덕분에 Wi-Fi와 셀룰러 네트워크 전환 시 연결이 끊기지 않고, UDP 전송은 TCP 스택에 대한 의존성을 줄여 배터리 소모를 낮추는 데 도움이 됩니다.

이 표에서 알 수 있듯이 프로토콜 선택에 "최고"는 없고 "현재 네트워크 조건에 가장 적합한" 것만 있습니다. 패킷 손실이 낮은 네트워크 환경에서는 TCP 기반 프로토콜(Trojan, VLESS)이 더 빠른 경우가 많고, 패킷 손실이 높은 환경에서는 QUIC 기반 프로토콜(Hysteria2, TUIC)이 더 유리합니다.

연결 설정 속도와 리소스 사용량 비교

"연결 버튼을 클릭한 후 몇 초를 기다려야 한다"는 사용자들의 가장 흔한 불만 중 하나입니다. 이 대기 시간은 두 부분으로 구성됩니다: 프로토콜 핸드셰이크 시간과 회선 연결 시간. 각각의 영향 요인을 이해하면 문제가 어느 계층에서 발생하는지 판단하는 데 도움이 됩니다.

프로토콜 핸드셰이크: 클릭부터 터널 구축까지

프로토콜 핸드셰이크 과정은 대략 다음과 같습니다: 클라이언트가 연결 요청 전송, 서버가 신원 확인, 양측이 암호화 파라미터 협상, 터널 구축. 각 프로토콜은 이 단계에서 왕복 횟수가 다릅니다.

• Shadowsocks: 핸드셰이크에 왕복 1회만 필요합니다. 클라이언트가 암호화된 SOCKS5 요청을 직접 보내면 서버가 복호화 후 즉시 응답합니다. 가장 빠른 핸드셰이크입니다.
• Trojan / VLESS: TLS 핸드셰이크가 필요하며, 보통 1~2회 왕복입니다(TLS 1.3은 1회 왕복). 여기에 신원 확인을 더하면 총 약 2회 왕복입니다.
• VMess: TLS 외에 자체 핸드셰이크 레이어가 하나 더 있습니다(TLS를 사용하지 않는 경우). 요청 ID와 암호화 파라미터를 교환하기 위한 추가 왕복이 필요합니다. 총 왕복 수는 약 3회입니다.
• Hysteria2 / TUIC: QUIC 기반이며, QUIC 핸드셰이크는 1회 왕복입니다(0-RTT 또는 1-RTT). 여기에 프로토콜 자체 인증을 더하면 총 약 2회 왕복입니다.

실제 네트워크 환경에서 각 왕복은 약 20~80ms가 소요됩니다(회선 지연에 따라 다름). 따라서 Shadowsocks의 핸드셰이크는 50ms 이내에 완료될 수 있지만, VMess는 150ms 이상이 필요할 수 있습니다. 이 차이는 육안으로 거의 느껴지지 않지만, 잦은 재연결 시나리오(예: 모바일에서 Wi-Fi와 셀룰러 네트워크 전환)에서는 누적되면 뚜렷해집니다.

전송 처리량: 대용량 트래픽 시나리오의 상한

처리량은 프로토콜 자체의 전송 효율과 네트워크 조건이 함께 영향을 미칩니다. TCP 기반 프로토콜은 TCP의 혼잡 제어 알고리즘에 제약을 받아 패킷 손실률이 1%를 초과하면 처리량이 급격히 떨어집니다. QUIC 기반 프로토콜은 더 공격적인 혼잡 제어를 내장하여 패킷 손실률이 높은 환경에서도 더 높은 처리량을 유지할 수 있습니다.

실제 사용 경험에서는 회선의 대역폭 상한도 결정적인 역할을 합니다. VPNXE 요금제는 트래픽 기준으로 과금하며 단일 연결의 대역폭 상한을 제한하지 않습니다. 하지만 회선마다 실제 대역폭 능력이 다르며, 전용선 회선은 보통 더 안정적인 고대역폭을 제공합니다. 대용량 트래픽이 필요하다면 요금제 페이지에서 각 등급의 트래픽 할당량을 참고하여 자신의 사용 패턴에 맞는 등급을 선택하는 것이 좋습니다.

리소스 사용량: CPU와 메모리

암호화와 복호화가 CPU 점유율의 주요 원인입니다. AES-256-GCM과 ChaCha20-Poly1305는 모두 효율적인 AEAD 암호화 알고리즘으로, 최신 프로세서에서는 하드웨어 가속(Intel AES-NI, ARMv8 Crypto Extensions)을 지원하므로 CPU 점유율이 일반적으로 병목이 되지 않습니다. 하지만 오래된 기기나 저전력 기기에서는 암호화 오버헤드가 확대됩니다.

메모리 사용량 측면에서는 각 연결마다 일정한 버퍼가 할당됩니다. 프로토콜 헤더가 복잡할수록 단일 연결의 메모리 사용량이 높아집니다. VMess는 프로토콜 헤더가 더 복잡하여 단일 연결 메모리 사용량이 Shadowsocks보다 약 20~30% 높습니다. 동시에 많은 연결을 생성하는 시나리오(예: 브라우저에서 수십 개의 탭을 동시에 여는 경우)에서는 이 차이가 누적됩니다.

모바일 배터리 성능: 프로토콜이 배터리 수명에 미치는 영향

모바일 기기 사용자는 배터리에 특히 민감합니다. 같은 스마트폰이라도 프록시를 켠 후 배터리 수명 차이가 최대 20~30%에 달할 수 있습니다. 이 차이는 세 가지 측면에서 발생합니다: 암호화 연산의 전력 소모, 네트워크 전송의 전력 소모, 연결 유지 전략.

암호화 연산의 전력 소모

모든 데이터 전송에는 암호화와 복호화가 필요합니다. 모바일 기기에서는 이 연산을 CPU 또는 전용 암호화 유닛이 수행합니다. AES-256-GCM은 하드웨어 가속을 지원하는 칩(거의 모든 최신 스마트폰 SoC가 지원)에서 전력 소모가 매우 낮지만, ChaCha20-Poly1305는 하드웨어 가속이 없는 일부 오래된 칩에서 더 많은 전력을 소모합니다.

더 중요한 것은 프로토콜 헤더의 복잡성입니다. 프로토콜 헤더가 복잡할수록 계산해야 할 바이트 수가 많아지고 전력 소모도 높아집니다. VMess는 프로토콜 헤더 구조가 복잡하여 모바일에서 암호화 연산 전력 소모가 Shadowsocks보다 약 15~20% 높습니다.

네트워크 전송의 전력 소모

모바일 무선 모듈(RF)은 스마트폰에서 가장 전력을 많이 소모하는 부품 중 하나이며, 전력 소모는 전송 시간에 비례합니다. TCP 기반 프로토콜은 패킷 손실 시 재전송을 유발하여 전송 시간을 늘리고 RF 모듈의 작동 시간을 증가시킵니다. QUIC 기반 프로토콜(TUIC, Hysteria2)은 패킷 손실 시 더 빠르게 복구하여 불필요한 전송을 줄이므로, 약한 네트워크 환경에서 오히려 더 전력 효율적일 수 있습니다.

또 하나 간과하기 쉬운 요소는 연결 마이그레이션입니다. QUIC 프로토콜은 연결 마이그레이션을 지원하여 Wi-Fi와 셀룰러 네트워크 사이를 전환할 때 연결이 끊기지 않고 다시 핸드셰이크할 필요가 없습니다. 즉, 스마트폰이 네트워크를 전환할 때마다 "터널 재구축"이라는 고전력 과정을 겪지 않아도 됩니다. TUIC는 이 측면에서 특히 뛰어납니다.

연결 유지 전략

많은 클라이언트는 기본적으로 연결을 유지하여 저지연을 확보하지만, 이는 데이터 전송이 없어도 연결이 살아 있다는 뜻입니다. 모바일 기기의 유휴 연결은 적지만 지속적인 전력을 소모합니다. 클라이언트가 "요청 시 연결"(앱이 필요할 때만 터널 구축)을 지원하면 전력 소모를 크게 줄일 수 있습니다.

모바일 배터리 절약 실천

프로토콜 선택 외에도 클라이언트 설정 몇 가지가 전력 소모에 직접 영향을 미칠 수 있습니다. 첫째, 불필요한 백그라운드 연결을 끄세요. 많은 앱이 푸시 수신을 위해 연결을 유지하지만 대부분의 앱은 그럴 필요가 없습니다. 둘째, "요청 시 연결" 모드를 선택하여 앱이 요청을 보낼 때만 터널을 구축하세요. 셋째, Wi-Fi 신호가 안정적인 환경에서는 셀룰러 네트워크보다 Wi-Fi를 우선 사용하세요. Wi-Fi는 셀룰러 네트워크보다 전력 소모가 훨씬 낮습니다.

VPNXE 클라이언트는 모바일을 위한 배터리 절약 최적화가 되어 있습니다. 기본적으로 TUIC 또는 Shadowsocks를 사용하며(네트워크 조건에 따라 다름), 요청 시 연결 모드를 지원합니다. 기기 상황에 맞게 조정할 수 있습니다. iOS에서 사용한다면 iOS VPN 설정 가이드를 참고하여 클라이언트의 구체적인 설정 단계를 확인할 수 있습니다.

회선 토폴로지: 직결, 중계, 전용선

회선 토폴로지는 데이터가 기기에서 목적지 서버까지 어떤 노드를 거치는지 결정합니다. 토폴로지 유형을 이해하면 많은 네트워크 경험 차이를 설명할 수 있고, 더 적합한 회선을 선택하는 데도 도움이 됩니다.

직결 회선: 최단 경로, 하지만 국제 출구의 영향

직결 회선은 데이터가 국제 출구를 통해 목적지 서버에 직접 도달하며 중간에 중계 노드를 거치지 않습니다. 이 회선은 경로가 가장 짧아 이론적 지연이 가장 낮지만, 국제 출구 대역폭과 혼잡의 영향을 가장 크게 받습니다. 중국에서 해외로 나가는 국제 출구는 저녁 피크 시간(베이징 시간 20:00~24:00)에 뚜렷한 혼잡이 발생하여 직결 회선의 지연이 급증하고 패킷 손실률이 상승합니다.

직결 회선은 지연에 민감하고 네트워크 상태가 좋은 시나리오에 적합합니다. 예를 들어 짧은 웹 브라우징, 온라인 문서 협업 등이 있습니다. 하지만 저녁 피크 시간에는 직결 회선의 안정성이 크게 떨어집니다.

중계 회선: 우회가 더 안정적

중계 회선은 사용자와 목적지 서버 사이에 하나 이상의 중간 노드를 삽입합니다. 중간 노드의 역할은 단순한 "우회"가 아니라 혼잡한 경로를 피하도록 돕는 것입니다. 예를 들어, 중국에서 미국으로 가는 직결 회선은 저녁 피크 시간에 심하게 혼잡할 수 있지만, 먼저 홍콩 중계 노드에 연결한 후 홍콩에서 미국으로 가면 경로는 더 길지만 각 구간의 품질이 더 좋습니다.

중계 회선의 지연은 보통 직결 회선보다 10~30ms 높지만 안정성은 크게 향상됩니다. 대가는 중계 노드의 유지 관리 비용이 추가된다는 점이며, 따라서 중계 회선의 요금은 직결보다 높은 경우가 많습니다.

전용선: 통신사급 품질

전용선은 서비스 제공자가 이미 임대했거나 자체 구축한 통신사급 링크입니다. 공용 네트워크 중계와 달리 전용선은 독립된 대역폭 할당량, 더 낮은 패킷 손실률, 더 안정적인 지연을 제공합니다. 전용선은 보통 IEPL(International Ethernet Private Line) 기술을 사용하여 로컬 네트워크에 가까운 품질을 제공할 수 있습니다.

전용선 회선은 지연이 가장 낮고 안정성이 가장 높지만 비용도 가장 높습니다. VPNXE 요금제에서 고가 요금제는 더 많은 전용선 회선 옵션을 제공하며, 저가 요금제는 직결 및 중계 회선이 중심입니다.

현재 회선의 토폴로지 판단 방법

VPNXE의 노드 페이지에서 각 회선의 유형 표시를 확인할 수 있습니다. 클라이언트에서도 현재 회선의 토폴로지 정보를 볼 수 있습니다. 특정 회선이 특정 시간대에 불안정하다면 같은 지역의 다른 회선으로 전환해 보세요. 지역이 같아도 토폴로지 유형이 다를 수 있습니다.

패킷 손실과 저녁 피크 혼잡의 원인

"왜 낮에는 멀쩡하다가 밤만 되면 버벅이지?" 이것은 거의 모든 네트워크 사용자가 겪어본 문제입니다. 저녁 피크 혼잡은 특정 서비스 제공자의 문제가 아니라 글로벌 인터넷 인프라의 공통 현상입니다. 그 원인을 이해하면 더 합리적인 회선 선택을 할 수 있습니다.

패킷 손실이란 무엇인가

패킷 손실은 데이터 패킷이 네트워크 전송 중에 유실되는 현상입니다. 네트워크 장비(라우터, 스위치)의 버퍼가 가득 차면 새로 도착한 데이터 패킷이 폐기됩니다. 패킷 손실률은 네트워크 품질을 측정하는 핵심 지표 중 하나입니다. 패킷 손실률이 1%를 초과하면 TCP 프로토콜의 처리량이 급격히 떨어집니다. TCP가 혼잡 제어 모드로 전환하여 전송 속도를 낮추고 유실된 패킷을 재전송하기 때문입니다.

패킷 손실이 사용자 경험에 미치는 영향은 다양합니다. 웹 페이지 로딩이 느려지고, 동영상이 버퍼링되며, 게임 지연이 급증하는 것이 모두 패킷 손실의 전형적인 증상입니다. 패킷 손실률이 높은 네트워크에서는 대역폭이 아무리 높아도 실제 사용자 경험은 좋지 않습니다.

저녁 피크 시간에 왜 혼잡한가

저녁 피크 시간(베이징 시간 19:00~24:00)은 글로벌 인터넷 트래픽이 가장 집중되는 시간대입니다. 이 시간대의 사용자 행동은 매우 동질적입니다: 퇴근 후 집에서 동영상 시청, 게임, 소셜 미디어 이용. 이러한 집중 트래픽은 국제 출구 대역폭을 가득 채우며, 특히 중미, 중유럽 등 인기 방향의 국제 링크에서 두드러집니다.

국제 출구의 대역폭은 제한된 자원이며, 통신사는 피크 시간에 정책에 따라 대역폭을 할당합니다. 실제 트래픽이 설계 용량을 초과하면 라우터가 패킷을 폐기하기 시작하고 혼잡 제어 메커니즘이 작동하여 사용자가 느끼는 것은 "느려짐"과 "불안정"입니다.

프로토콜이 패킷 손실에 대응하는 방법

TCP 기반 프로토콜(Shadowsocks, VMess, Trojan, VLESS)은 TCP의 혼잡 제어 알고리즘을 엄격히 따릅니다. 패킷 손실이 감지되면 TCP는 즉시 전송 속도를 낮춘 후 천천히 회복합니다. 이 메커니즘은 패킷 손실률이 낮을 때는 잘 작동하지만, 패킷 손실률이 높을 때는 처리량이 급감합니다.

QUIC 기반 프로토콜(Hysteria2, TUIC)은 더 공격적인 전략을 사용합니다. Hysteria2의 혼잡 제어 알고리즘은 네트워크를 "최선형"으로 가정하며, 소량의 패킷 손실 때문에 전송 속도를 크게 낮추지 않고 지속적으로 가용 대역폭을 탐색하여 처리량을 유지합니다. 이로 인해 Hysteria2는 패킷 손실률 3~5%의 네트워크에서도 좋은 처리량을 유지할 수 있습니다.

사용자 측에서 할 수 있는 것

저녁 피크 혼잡에 대응하여 사용자 측에서 몇 가지 실용적인 전략이 있습니다. 첫째, 회선 전환. 같은 지역의 다른 회선이 다른 물리적 경로를 탈 수 있으며 혼잡 정도가 크게 다릅니다. 둘째, 프로토콜 전환. 클라이언트가 지원한다면 저녁 피크 시간에 Hysteria2 또는 TUIC로 전환해 보세요. 셋째, 사용 시간 조정. 지연에 민감하다면(예: 화상 회의) 저녁 피크 시간을 피하세요.

VPNXE 클라이언트에는 스마트 회선 선택 기능이 내장되어 있어 각 회선의 실시간 품질을 자동으로 감지하고 최적의 회선을 추천합니다. 클라이언트에서 이 기능을 켜면 저녁 피크 혼잡에 자동으로 대응할 수 있습니다.

사용 시나리오별 프로토콜 선택 방법

"최고"의 프로토콜은 없고 "현재 시나리오에 가장 적합한" 프로토콜만 있습니다. 아래에서 일반적인 사용 시나리오별 선택 권장안을 제시합니다.

실용적인 선택 의사결정 프로세스

어떤 프로토콜을 선택해야 할지 확신이 없다면 다음 절차에 따라 빠르게 결정할 수 있습니다:

1. 먼저 네트워크 조건 확인: 현재 네트워크의 패킷 손실률이 높다면(예: 저녁 피크 시간) Hysteria2 또는 TUIC를 우선 선택하세요. 네트워크 품질이 좋다면 어떤 프로토콜이든 사용 가능합니다.
2. 다음으로 기기 유형 확인: 모바일은 TUIC 또는 Shadowsocks를 우선 고려하세요(배터리 절약). 데스크톱은 프로토콜에 민감하지 않으므로 시나리오에 따라 선택할 수 있습니다.
3. 마지막으로 사용 시나리오 확인: 게임과 실시간 통신은 저지연 프로토콜(Shadowsocks, VLESS)을 우선하고, 스트리밍과 대용량 파일은 고처리량 프로토콜(Hysteria2)을 우선합니다.

프로토콜과 회선의 조합

프로토콜과 회선은 독립적이지 않습니다. 흔한 오해는 "전용선 회선을 선택하면 반드시 저지연을 얻을 수 있다"는 것입니다. 하지만 프로토콜 자체가 높은 패킷 손실 환경에서 성능이 좋지 않다면 아무리 좋은 회선도 낭비될 수 있습니다. 반대로, 직결 회선의 품질이 충분히 좋다면 경량 프로토콜(예: Shadowsocks)과 결합하여 훌륭한 경험을 제공할 수 있습니다.

VPNXE 클라이언트는 각 회선에 대해 개별적으로 프로토콜을 지정할 수 있습니다. 즉, 같은 회선에서 다른 프로토콜을 시도하여 현재 네트워크 조건에 가장 적합한 조합을 찾을 수 있습니다. 설정 방법이 확실하지 않다면 클라이언트의 스마트 회선 선택 기능이 결정하도록 맡기면 됩니다.

VPNXE의 스마트 회선 선택

VPNXE 클라이언트에는 스마트 회선 선택 로직이 내장되어 있어 현재 네트워크 조건에 따라 프로토콜과 회선을 자동으로 선택합니다. 구체적으로, 클라이언트는 각 회선의 지연과 패킷 손실률을 주기적으로 측정한 후 지연이 가장 낮고 패킷 손실률이 가장 낮은 회선을 선택합니다. 수동으로 개입할 필요 없이 클라이언트가 지속적으로 최적화합니다.

특정 프로토콜을 선호한다면 클라이언트 설정에서 수동으로 지정할 수도 있습니다. 클라이언트는 각 회선에 대해 개별적으로 프로토콜을 지정할 수 있으므로, 다양한 시나리오에서 다른 프로토콜을 사용할 수 있습니다.

구독과 클라이언트: 설정이 어떻게 적용되는가

요금제를 구매하면 사용자 패널에서 구독 링크를 받게 됩니다. 이 링크에는 계정 정보와 회선 목록이 포함되어 있으며, 클라이언트는 이를 파싱하여 모든 설정을 가져옵니다.

구독 링크에는 무엇이 들어 있나

구독 링크는 본질적으로 암호화된 설정 파일입니다. 여기에는 계정 식별자, 사용 가능한 모든 회선 목록, 각 회선의 프로토콜 유형, 서버 주소, 포트, 암호화 방식, 트래픽 및 만료 시간 등이 포함됩니다. 클라이언트는 구독을 새로고침할 때마다 이 데이터를 다시 가져오므로, 서비스 제공자 백엔드에서 수정한 모든 설정이 클라이언트에 동기화됩니다.

VPNXE를 예로 들면, 사용자 패널의 "구독" 페이지에서 전용 구독 링크를 찾을 수 있습니다. 클라이언트의 "구독"란에 복사하면 클라이언트가 자동으로 파싱하여 회선 목록을 로드합니다.

클라이언트가 구독을 파싱하는 방법

클라이언트마다 파싱 방식이 약간 다르지만 기본 흐름은 동일합니다: 클라이언트가 구독 링크로 HTTPS 요청 전송 → 서버가 암호화된 설정 파일 반환 → 클라이언트가 복호화 및 파싱 → 회선 목록 생성. 전체 과정은 몇 초면 충분합니다.

VPNXE는 Windows, macOS, iOS, Android, Linux 등 다양한 클라이언트를 지원합니다. 다운로드 센터에서 해당 플랫폼의 클라이언트를 받을 수 있습니다. iOS 사용자는 일부 클라이언트를 App Store에서 받아야 한다는 점에 유의하세요(구체적으로는 거주 지역에 따라 다름).

설정 파일의 일반적인 형식

구독 파일은 보통 URI 형식을 사용하며, 각 줄이 하나의 회선을 나타냅니다. 전형적인 회선 URI는 다음과 같습니다:

vmess://eyJ2IjoiMiIsInBzIjoi5Li65Y2M5pe76ZWcIiwiYWRkIjoiZXhhbXBsZS5jb20iLCJwb3J0IjoiNDQzIiwiaWQiOiJ5b3VyLXV1aWQiLCJuZXQiOiJ0Y3AifQ==

이 URI는 Base64로 인코딩된 JSON이며, 디코딩하면 회선의 서버 주소, 포트, 사용자 ID 등의 정보가 포함되어 있습니다. 프로토콜마다 URI 접두사가 다릅니다: Shadowsocks는 ss://, VMess는 vmess://, VLESS는 vless://, Trojan은 trojan://, Hysteria2는 hysteria2://, TUIC는 tuic://입니다.

구독 가져오기의 일반적인 절차

대부분의 클라이언트에서 구독 가져오기는 세 단계면 충분합니다: 클라이언트의 "구독" 또는 "설정" 페이지 열기 → 구독 링크 붙여넣기 → "업데이트" 또는 "가져오기" 클릭. 클라이언트가 자동으로 설정을 다운로드하고 파싱하며, 회선 목록이 메인 화면에 나타납니다.

VPNXE 공식 클라이언트를 사용한다면 가져오기 과정이 더 간단합니다: 로그인 페이지에서 사용자 이름과 비밀번호를 입력하면(이메일 주소 불필요) 클라이언트가 자동으로 구독을 가져와 회선 목록을 로드합니다.

설정이 적용되었는지 확인하는 방법

구독을 가져온 후 회선을 선택하고 연결을 클릭하세요. 연결에 성공하면 IP 조회 페이지에서 출구 IP가 변경되었는지 확인할 수 있습니다. 선택한 회선이 위치한 지역의 IP가 표시된다면 설정이 적용된 것입니다.

일반적인 문제와 문제 해결

프로토콜과 회선의 원리를 이해해도 실제 사용 중에는 다양한 문제가 발생할 수 있습니다. 아래에서 가장 흔한 문제와 해결 방법을 정리했습니다.

연결 실패, 하지만 회선 목록은 정상 표시

이 경우는 보통 로컬 네트워크 환경 때문입니다. 다음 순서로 확인하세요: 첫째, 기기가 인터넷에 정상적으로 접속되는지 확인하세요. 브라우저를 열어 아무 웹사이트나 방문해 보세요. 웹사이트조차 열리지 않는다면 문제는 로컬 네트워크에 있습니다. 둘째, 프로토콜 전환을 시도하세요. 일부 네트워크 환경은 UDP 트래픽을 제한하여 QUIC 기반 프로토콜이 연결되지 않을 수 있습니다. TCP 프로토콜로 전환하면 됩니다. 셋째, 방화벽 설정을 확인하세요. 일부 방화벽은 프록시 연결을 차단하므로 클라이언트를 화이트리스트에 추가해야 합니다.

연결 성공, 하지만 속도가 매우 느림

속도가 느린 원인은 보통 회선 혼잡 또는 부적절한 프로토콜 선택입니다. 다음 순서로 확인하세요: 첫째, 회선 전환. 현재 회선이 저녁 피크 혼잡 상태일 수 있으므로 같은 지역의 다른 회선으로 전환하면 개선되는 경우가 많습니다. 둘째, 프로토콜 전환. 현재 TCP 프로토콜을 사용 중이라면 Hysteria2 또는 TUIC로 전환해 보세요. 셋째, 로컬 네트워크 확인. 로컬 Wi-Fi 자체가 느리다면 프록시가 이를 개선할 수 없습니다.

연결이 자주 끊김

잦은 끊김은 보통 네트워크 불안정 때문입니다. 다음을 시도해 보세요: 첫째, 회선 전환. 현재 회선의 품질이 좋지 않을 수 있습니다. 둘째, 자동 재연결 활성화. 대부분의 클라이언트가 끊김 후 자동 재연결을 지원하므로 켜두면 자동으로 복구됩니다. 셋째, 기기 전원 관리 확인. 일부 기기의 절전 모드는 백그라운드 네트워크 활동을 제한하여 연결이 끊길 수 있습니다.

일부 웹사이트가 열리지 않음

일부 웹사이트만 열리지 않고 다른 웹사이트는 정상이라면, 목적지 웹사이트가 프록시 트래픽에 특별한 제한을 두고 있을 수 있습니다. 다음을 시도해 보세요: 첫째, 회선 전환. 회선마다 IP 주소 대역이 다르며 일부 IP는 목적지 웹사이트에 차단될 수 있습니다. 둘째, 프로토콜 전환. 일부 웹사이트는 TLS 트래픽에 더 친화적이므로 Trojan 또는 VLESS로 전환하세요. 셋째, DNS 설정 확인. 일부 클라이언트는 원격 DNS를 사용하는데, 파싱이 실패하면 로컬 DNS 모드로 전환하세요.

모바일 배터리 소모 이상

모바일에서 프록시를 켠 후 배터리 소모가 눈에 띄게 증가했다면 다음을 확인하세요: 첫째, 요청 시 연결이 켜져 있는지. 켜져 있지 않으면 클라이언트가 지속적으로 연결을 유지하여 배터리 소모가 증가합니다. 둘째, 프로토콜 선택. TUIC와 Shadowsocks는 모바일에서 전력 소모가 가장 낮습니다. 셋째, 백그라운드 앱. 일부 앱이 잦은 요청을 보내 터널이 지속적으로 데이터를 전송하게 할 수 있습니다.

구독을 가져올 수 없음

구독 링크를 클라이언트로 가져올 수 없다면 다음을 확인하세요: 첫째, 링크가 완전한지. 구독 링크는 보통 매우 길어서 복사할 때 잘리기 쉽습니다. 둘째, 계정이 유효한지. 요금제가 만료되지 않았는지 확인하세요. 셋째, 클라이언트 버전. 오래된 버전의 클라이언트는 일부 프로토콜을 지원하지 않을 수 있으므로 최신 버전으로 업그레이드하세요.