프로토콜·회선 선택 레퍼런스

6가지 프로토콜의 설계 선택

프록시 프로토콜이 해결해야 하는 문제는 세 가지로 나눌 수 있습니다. 트래픽을 통과 가능한 하나의 연결로 캡슐화하는 것, 양 끝단 사이에서 암호화와 무결성 검증을 수행하는 것, 그리고 링크 상의 중간 장비가 바이트 수준에서 내용을 판별할 수 없게 만드는 것입니다. 여섯 가지 주요 프로토콜은 이 세 가지에서 각기 다른 선택을 하며, 그 결과가 핸드셰이크 횟수, CPU 점유율, 패킷 손실 내성, 모바일 배터리 소모로 곧바로 드러납니다. 이 장에서는 설계 지향을 기준으로 하나씩 설명하며 순위를 매기지는 않습니다. 링크를 떼어 놓고 우열을 논하는 것은 의미가 없기 때문입니다.

Shadowsocks: 가장 얇은 한 겹의 캡슐화

Shadowsocks의 설계 목표는 절제되어 있습니다. 암호화된 TCP 또는 UDP 연결 하나로 트래픽을 출구까지 보내고, 위장 계층을 따로 얹지 않습니다. 암호화에는 AEAD 스위트를 쓰며, 흔한 조합은 AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305입니다. 이런 모드는 암호화와 무결성 검증을 한 단계로 합쳐, 암호화한 뒤 따로 검증값을 계산하던 왕복을 없앱니다. 내장 TLS가 없기 때문에 핸드셰이크 비용은 여섯 프로토콜 가운데 가장 낮은 축에 속하고, 지연에 민감한 상황에서 바로 이점을 봅니다. 대가는 트래픽 특성이 바깥 포장에 전적으로 달려 있다는 점입니다. 그대로 돌리면 고엔트로피 바이트의 TCP 스트림일 뿐이라, 심층 패킷 검사를 하는 장비라면 관심을 가질 수 있습니다. 실제 배포에서는 보통 Shadowsocks를 TLS 터널 안에 넣거나 다른 전송 계층과 조합합니다.

VMess: 신원과 시간 검증을 포함한 캡슐화

VMess는 프로토콜 헤더에 사용자 식별자와 타임스탬프를 담고, 서버는 이 두 항목으로 신원을 검증합니다. 여기서 흔히 발을 디디는 함정이 하나 있습니다. 클라이언트와 노드의 시간이 대체로 일치해야 하며, 편차가 크면 핸드셰이크가 그대로 거부됩니다. 증상은 설정을 항목별로 다 맞춰 봐도 연결이 되지 않는 것입니다. VMess 헤더는 여러 버전을 거쳤고, AEAD 버전은 헤더까지 무결성 보호에 포함해 헤더 필드가 도중에 변조되는 것을 막습니다. 오버헤드는 Shadowsocks보다 약간 높지만, 그 대가로 더 명확한 다중 사용자 모델과 더 세분화된 헤더 필드를 얻습니다. 하나의 노드에서 여러 구독자를 구분하기에 적합합니다.

Trojan: 트래픽을 표준 TLS 안에 넣기

Trojan의 발상은 프록시 트래픽을 표준 TLS 연결 안에 넣는 것입니다. 먼저 겉보기에 지극히 평범한 TLS 핸드셰이크를 마치고, 서버는 핸드셰이크가 끝난 뒤에야 비밀번호를 검증합니다. 링크 상의 중간 장비가 보는 것은 평범한 HTTPS 세션일 뿐이며, 목적지 도메인, 인증서 체인, 핸드셰이크 순서가 모두 일반적인 접속과 같습니다. 비밀번호가 맞지 않으면 서버는 이 연결을 실제 웹 서비스로 넘겨, 탐지하는 쪽이 정상적인 웹 페이지 응답을 받게 할 수 있습니다. 호환성이 좋다는 것이 장점이고, 대가는 TLS 계층이 하나 더 붙어 핸드셰이크 왕복이 하나 늘고 CPU가 대칭 암복호화를 한 번 더 해야 한다는 점입니다.

VLESS: 중복된 한 겹을 제거

VLESS의 지향은 해야 할 일만 하는 것입니다. 프로토콜 자체는 암호화하지 않고 암호화를 전적으로 외부 TLS에 맡겨, TLS 안에 암호화를 또 겹치는 중복 비용을 피합니다. XTLS 계열 흐름 제어와 결합하면 내부와 외부의 암호화를 중복 수행하지 않게 되어 CPU 점유율이 눈에 띄게 줄어듭니다. VLESS는 상태가 없어 서버가 사용자마다 세션 테이블을 유지할 필요가 없고, 노드 수평 확장이 쉽습니다. 안정적인 TLS 채널이 이미 있고 처리량과 CPU 효율을 최대로 끌어올리고 싶은 상황에 맞습니다. 반대로 외부 TLS 설정이 부적절하면 VLESS 자체에는 추가로 기댈 암호화가 없습니다.

Hysteria2: QUIC 위에서 다른 혼잡 제어

Hysteria2는 QUIC 위에서 동작합니다. 즉 UDP를 씁니다. 가장 실제적인 차이는 혼잡 제어에 있습니다. BBR 같은 알고리즘을 선택할 수 있어 패킷 손실률이 높은 링크에서도 비교적 높은 처리량을 유지합니다. 전통적인 TCP 혼잡 제어처럼 손실을 만나면 창을 크게 줄여 버리지 않기 때문입니다. 대가도 분명합니다. UDP 트래픽은 일부 네트워크에서 속도 제한이나 하위 등급 처리를 받습니다. QUIC은 사용자 공간에서 구현되므로 패킷마다 사용자 공간 복사와 타이머 처리를 거쳐야 하고, CPU 점유율이 커널 TCP보다 높습니다. 모바일에서 오래 쓰면 배터리 소모도 더 큽니다.

TUIC: QUIC 위의 멀티플렉싱과 0-RTT

TUIC 역시 QUIC을 기반으로 하며, 초점은 멀티플렉싱과 빠른 복구에 있습니다. 하나의 QUIC 연결 위에 여러 논리 스트림을 병렬로 실을 수 있고, 세션을 이미 맺은 클라이언트가 다시 연결할 때는 0-RTT로 왕복 하나를 절약합니다. 선택의 구조는 Hysteria2와 비슷하며, UDP 링크를 쓸 수 있는지가 체감 상한을 그대로 결정합니다. UDP가 잘 통하는 네트워크에서는 TUIC의 첫 패킷 시간이 매우 좋습니다. UDP가 제한되는 네트워크에서는 오히려 안정적인 TCP 회선만 못합니다.

결론은 소박합니다. 링크 품질이 좋고 오버헤드를 낮추고 싶다면 Shadowsocks와 VLESS가 더 적합합니다. 호환성과 위장이 필요하면 Trojan이 더 안정적입니다. 링크 손실이 심하면 Hysteria2와 TUIC의 혼잡 제어가 처리량을 되살립니다. 모바일에서 오래 켜 두는 경우에는 커널 공간의 TCP 계열 프로토콜이 배터리에 더 우호적입니다. VPNLW의 230+ 회선은 지역별로 사용 가능한 프로토콜이 표시되어 있고, 구독을 가져오면 클라이언트가 회선에 맞는 프로토콜 조합을 내려받으므로 설정을 직접 조립할 필요가 없습니다.

클릭에서 첫 패킷까지: 핸드셰이크에서 벌어지는 일

사용자가 체감하는 빠르고 느림은 서로 다른 두 가지 양으로 결정됩니다. 하나는 첫 패킷 시간, 즉 링크를 눌러 첫 바이트를 받을 때까지의 간격이고, 다른 하나는 지속 처리량, 즉 전송이 시작된 뒤의 속도입니다. 첫 패킷 시간은 왕복 횟수가, 처리량은 대역폭과 혼잡 제어가 좌우합니다. 이 둘은 자주 뒤섞여 이야기되기 때문에 트러블슈팅에서 방향을 잘못 잡기 쉽습니다. 분명히 핸드셰이크만 느린데 계속 대역폭이 큰 회선만 갈아 끼우는 식입니다.

한 번의 요청에 몇 번의 왕복이 필요한가

웹 요청 하나를 뜯어 보면 대략 다음 단계를 거칩니다. 첫 단계는 이름 해석으로, 로컬 캐시에 기록이 없으면 DNS에 묻기 위해 한 번 이상 왕복해야 합니다. 프록시 모드에서는 해석을 원격에서 처리할 수 있고, 그러면 로컬에서 노드까지 구간에 협상이 한 번 더 붙습니다. 두 번째는 노드까지의 전송 핸드셰이크로, TCP는 왕복 하나가 필요합니다. 세 번째는 TLS 핸드셰이크로, TLS 1.3은 전체 핸드셰이크에 왕복 하나를 쓰고 세션 복원 시에는 0-RTT까지 가능합니다. 네 번째는 프록시 프로토콜 자체의 협상입니다. VLESS와 Trojan은 추가 왕복이 사실상 없고, VMess는 식별자와 시간을 검증해야 하며, QUIC 계열은 왕복 하나 또는 0-RTT입니다. 다섯 번째는 노드에서 목적지 사이트까지로, 이 구간은 착지 데이터센터에서 목적지까지의 물리적 거리와 라우팅 품질에 달려 있습니다. 여섯 번째에야 데이터가 돌아옵니다.

이 구간들을 더해 보면 흔한 현상 하나가 설명됩니다. 어떤 사이트를 처음 열 때는 분명히 느린데 두 번째에는 빨라지는 것입니다. 원인은 회선이 좋아진 것이 아니라 연결 풀과 TLS 세션 티켓이 재사용되어 이후 몇 번의 핸드셰이크가 생략된 것입니다.

0-RTT가 아끼는 것과 그 대가

TLS 1.3의 세션 복원은 클라이언트가 첫 비행 패킷에 애플리케이션 데이터를 함께 실을 수 있게 합니다. 이것이 0-RTT입니다. QUIC도 이 메커니즘을 이어받았습니다. 절약되는 것은 온전한 왕복 하나이며, 대양을 건너는 링크에서는 첫 패킷 시간이 상당히 줄어듭니다. 대가는 재전송 위험입니다. 링크 상의 공격자가 이 0-RTT 데이터를 가로채 다시 보낼 수 있으므로, 규격은 멱등 요청에만 쓰도록 권고합니다. 클라이언트가 실제로 0-RTT를 쓰는지는 구현과 로컬 캐시 상태에 달려 있어, 반드시 일어나는 일로 가정할 수는 없습니다. ‘왜 어떤 때는 빠르고 어떤 때는 느린가’를 살필 때 기억해 둘 만한 항목입니다.

연결 재사용과 헤드 오브 라인 블로킹

멀티플렉싱은 여러 요청을 하나의 연결에 담아 반복되는 핸드셰이크를 생략합니다. TCP에서는 한 연결 안의 데이터가 엄격히 순서를 지키므로, 앞의 패킷 하나가 사라지면 뒤의 모든 스트림이 그 재전송을 기다려야 합니다. 이것이 헤드 오브 라인 블로킹입니다. QUIC은 전송 계층에서 스트림을 분리해, 한 스트림의 손실이 다른 스트림에 영향을 주지 않습니다. 대가는 스트림마다 상태를 따로 유지해야 해 메모리와 스케줄링 비용이 더 든다는 점입니다. 멀티플렉싱을 켤지는 상황에 따라 판단해야 합니다. 요청이 몰리고 연결 수가 제한될 때는 재사용의 이득이 분명하고, 단일 대용량 전송에서는 다른 스트림과 같은 윈도를 다투지 않아도 되므로 오히려 끄는 편이 안정적입니다.

첫 패킷 시간을 직접 재는 방법

브라우저 개발자 도구의 네트워크 패널에서 각 요청의 대기, DNS, 연결, TLS, 첫 바이트 단계별 소요 시간을 바로 볼 수 있습니다. 명령줄에서는 curl의 단계별 타이밍을 쓸 수 있습니다:

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://example.com/

이 명령을 연결 수립 전후에 각각 한 번씩 실행하면 그 차이가 핸드셰이크 비용입니다. 예시 도메인은 표기 방식 설명용이며, 실제 구독 주소를 온라인 도구나 공개 스크린샷에 붙여 넣지 마세요.

이 표를 이해하고 나면 ‘회선이 느리다’는 판단이 훨씬 정확해집니다. 첫 번째만 느리면 문제는 핸드셰이크와 해석에 있고, 열 때마다 느리면 왕복 횟수에 문제가 있으며, 첫 패킷은 빠른데 전송이 느리면 대역폭과 혼잡 제어가 원인입니다. 세 경우의 대응 방식은 완전히 다릅니다.

CPU, 메모리와 모바일 배터리

프로토콜 선택은 데스크톱에서는 주로 속도에 영향을 주지만, 모바일에서는 배터리 지속 시간에도 영향을 줍니다. 배터리는 추상적인 지표가 아니라 CPU 웨이크업 횟수, 무선 모듈 동작 시간, 메모리 할당과 회수 빈도가 함께 만들어 내는 결과입니다. 같은 구독이라도 노트북에서는 차이를 못 느끼지만, 스마트폰에서는 한 시간과 세 시간의 차이가 될 수 있습니다.

암호화 스위트의 하드웨어 가속

AES-GCM은 AES-NI를 지원하는 x86 프로세서와 ARMv8 암호화 확장이 있는 모바일 칩에서 하드웨어 명령으로 처리되어 바이트당 비용이 매우 낮습니다. ChaCha20-Poly1305는 순수 소프트웨어 구현이 더 빠른 방식이라, 하드웨어 가속이 없는 구형 기기에서는 오히려 유리합니다. 대부분의 클라이언트는 CPU 능력에 따라 자동으로 고르고, 일부만 수동 지정이 필요합니다. 구형 안드로이드 기기의 암호화 스위트를 AES에서 ChaCha20으로 바꾸면 발열과 방전 속도가 눈에 띄게 줄어드는 경우가 있습니다. 비용은 거의 들지 않지만 자주 잊히는 조정입니다.

사용자 공간과 커널 공간의 차이

TCP는 운영체제 커널이 처리하므로 패킷이 네트워크 카드에서 애플리케이션까지 필요한 복사만 거칩니다. QUIC은 사용자 공간에서 구현되어 패킷마다 시스템 호출 한 번, 사용자 공간 복사 한 번, 타이머 검사 한 번을 거칩니다. 데스크톱 프로세서에서는 이 정도 비용이 무시할 만하지만, 모바일 프로세서에서는 곧바로 배터리와 발열로 바뀝니다. Hysteria2와 TUIC를 스마트폰에서 오래 쓸 때 배터리 지속 시간이 TCP 계열보다 대체로 짧은 이유도 여기에 있습니다. QUIC 계열이 나쁘다는 뜻이 아니라, 강점은 손실이 있는 링크에 있고 대가는 배터리에 있으니 상황에 맞게 저울질해야 한다는 뜻입니다.

하트비트와 연결 유지

NAT 장비는 유휴 매핑을 회수하므로 클라이언트는 주기적으로 하트비트를 보내 통로를 유지해야 합니다. 하트비트 간격이 짧을수록 끊길 확률은 낮아지지만 무선 모듈이 깨어나는 횟수도 늘어납니다. 모바일에서는 하트비트 간격을 길게 두고 시스템 수준의 네트워크 유지 기능과 함께 쓰는 것이 합리적입니다. 데스크톱에서는 간격을 짧게 유지해 더 빠른 복구를 얻을 수 있습니다. ‘화면을 잠갔다가 돌아오면 매번 다시 연결된다’면 먼저 하트비트 간격을 확인하고, 노드를 급히 바꾸지는 마세요.

백그라운드 유지와 절전 정책

iOS는 백그라운드 네트워크 권한을 엄격히 제한해, 앱이 백그라운드로 들어가 일정 시간이 지나면 중단되고 프록시도 함께 끊깁니다. 안드로이드의 절전 정책은 백그라운드 앱의 네트워크 접근을 제한하며, 흔한 증상은 화면을 잠근 지 몇 분 뒤 메시지가 오지 않는 것입니다. 해결책은 클라이언트를 시스템 절전 예외 목록에 넣고 백그라운드 실행을 허용하는 것입니다. 이 단계는 선택 사항이 아니라 모바일에서 오래 쓰기 위한 전제 조건입니다. 구체적인 조작 순서는 안드로이드 관련 가이드 글에 화면 단위로 설명되어 있습니다.

앱별 프록시가 가장 직접적인 배터리 최적화

필요한 앱만 프록시를 타게 하면 세 가지를 동시에 줄일 수 있습니다. 전체 트래픽, 암복호화 횟수, 무선 모듈 동작 시간입니다. 시스템 업데이트, 앱 스토어 다운로드, 같은 네트워크 안의 백업 같은 트래픽은 해외 노드를 거칠 이유가 전혀 없습니다. 대부분의 클라이언트가 앱별 선택을 지원하므로 한 번 설정해 두면 오래 유지됩니다. 트래픽 한도가 있는 요금제라면 이 항목이 상당한 트래픽을 아껴 주기도 합니다.

이 몇 가지를 조정하고 나면 모바일 체감 개선이 회선을 바꾸는 것보다 뚜렷할 때가 많습니다. 회선은 상한을 정하고, 설정은 실제 소모를 정합니다.

직결, 중계와 전용선

회선 하나는 세 구간으로 나눌 수 있습니다. 사용자에서 입구까지의 접속 구간, 입구에서 착지까지의 국제 구간, 착지에서 목적지까지의 착지 구간입니다. 세 구간 가운데 서비스 제공자가 능동적으로 최적화할 수 있는 곳은 국제 구간뿐이고, 회선 유형의 차이도 주로 이 구간에서 갈립니다. 이 점을 이해하면 같은 도시를 향한 두 회선의 지연은 비슷한데 야간 혼잡 시간대의 모습은 전혀 다른 이유가 설명됩니다.

직결: 경로가 가장 짧고 품질은 가장 예측 불가

직결은 노드 데이터센터가 해외에 바로 있고 사용자 트래픽이 국제 출구를 거쳐 곧장 데이터센터로 들어가는 방식입니다. 경로가 짧고 추가 홉이 없어 링크 품질이 좋을 때 지연이 가장 낮습니다. 단점도 분명합니다. 국제 구간을 같은 출구를 쓰는 모든 사용자와 공유하므로 야간 혼잡을 피할 수 없습니다. 직결 회선은 예비용으로 두거나, 지연에 극도로 민감하면서 변동은 감수할 수 있는 상황에 적합합니다. 직결만 유일한 선택으로 두는 것은 체감을 남의 출구 대역폭에 거는 일과 같습니다.

중계: 통제 불가능한 구간을 통제 가능한 구간으로

중계는 사용자에게 더 가까운 위치에 입구를 둡니다. 예를 들어 홍콩이나 일본입니다. 사용자는 먼저 입구에 접속하고, 입구가 최적화된 경로를 따라 착지로 포워딩합니다. 중계의 가치는 물리적 거리를 줄이는 데 있지 않고, 모든 사용자와 함께 국제 출구에 몰리는 상황을 스케줄링된 백본 경로로 바꾸는 데 있습니다. 입구 노드는 통합 스케줄링도 할 수 있어, 특정 착지 회선이 혼잡하면 트래픽을 다른 회선으로 돌립니다. 대가는 홉이 하나 늘어 기본 지연이 직결보다 약간 높다는 점이지만, 지터는 대체로 더 작고 야간 혼잡 시간대의 낙폭도 완만합니다.

전용선: 비용으로 확실성을 사는 방식

IEPL 같은 전용선은 통신사가 제공하며 대역폭과 경로에 명확한 서비스 등급 협약이 있어 공인 인터넷 트래픽과 같은 큐를 다투지 않습니다. 그 결과 지연이 안정적이고 패킷 손실이 낮으며 야간 혼잡 시간대의 영향도 뚜렷하지 않습니다. 비용은 세 방식 가운데 가장 높아 보통 일부 회선에만 제공됩니다. 어떤 회선이 전용선인지 판단하려면 이름 표기를 보거나, 라우트 추적으로 국제 구간의 홉 수와 경유 네트워크를 관찰하면 됩니다. 홉이 적고 경로가 안정적이며 국제 구간이 소수 네트워크에 집중되어 있다면 대개 최적화된 경로입니다.

지연과 지터는 서로 다른 지표

평균 지연이 낮다고 체감이 좋은 것은 아닙니다. 화상 회의가 무서워하는 것은 지터, 즉 지연의 변동입니다. 대용량 파일 전송이 무서워하는 것은 패킷 손실이며, 손실은 혼잡 제어의 윈도 축소를 부릅니다. 전용선이 이 두 지표에서 갖는 우위가 평균 지연에서의 우위보다 뚜렷합니다. ‘전용선으로 바꾼 뒤 숫자는 별로 안 내려갔는데 회의는 끊기지 않는다’는 사용자 피드백이 바로 지터를 말하는 것입니다.

선택 기준은 단순합니다. 일상 브라우징과 영상은 중계로 충분하고, 회의·실시간 협업·끊김에 대한 무관용이 필요한 상황은 전용선을 씁니다. 직결은 예비와 가벼운 상황에 남겨 둡니다. VPNLW의 회선 목록은 지역별로 회선 유형이 표시되어 있어, 노드 페이지에서 지역으로 필터링한 뒤 하나씩 대조할 수 있습니다.

지연, 패킷 손실과 야간 혼잡

이 장에서는 가장 자주 나타나는 세 가지를 설명합니다. 지연이 왜 높아지는지, 패킷 손실은 왜 생기는지, 저녁에는 왜 유난히 느린지입니다. 원인을 이해하고 나면 ‘회선이 고장 난 걸까’ 하는 의문 대부분은 스스로 판단할 수 있고, 매번 문의를 넣지 않아도 됩니다.

지연은 네 부분으로 구성

첫째는 전파 지연으로, 신호가 매질을 지나는 시간이며 물리적 거리가 정합니다. 최적화할 수 없습니다. 둘째는 전송 지연으로, 데이터를 링크에 올리는 시간이며 대역폭과 패킷 크기가 정합니다. 셋째는 대기 지연으로, 데이터가 라우터 큐에서 기다리는 시간이며 혼잡할 때 급격히 치솟습니다. 넷째는 처리 지연으로, 장비의 포워딩과 암복호화, 프로토콜 스택 처리 시간입니다. 넷 가운데 최적화 여지가 있는 것은 대기 지연과 처리 지연뿐입니다. 물리적 거리가 정하는 하한은 넘을 수 없으며, 우회 경로가 때로 더 빠른 이유도 여기에 있습니다. 혼잡한 노드를 피해 가는 경로는 직선 경로보다 총 시간이 짧을 수 있습니다.

패킷 손실은 어디서 오는가

패킷 손실의 흔한 원인은 네 가지입니다. 첫째는 큐 오버플로로, 링크의 특정 홉에서 버퍼가 가득 차 뒤에 온 패킷이 그대로 버려집니다. 둘째는 무선 간섭으로, Wi-Fi와 이동통신은 간섭이 심한 환경에서 무작위 손실이 생깁니다. 셋째는 장비의 속도 제한과 정책으로, 일부 네트워크는 특정 유형의 트래픽에 속도 제한을 걸고 초과분을 버립니다. 넷째는 MTU 불일치로, 패킷이 포워딩 과정에서 분할되고 분할 조각이 사라지면 전체 패킷을 다시 보내야 합니다. 원인별 대응은 다릅니다. 큐 오버플로는 회선을 바꾸고, 무선 간섭은 접속 방식을 바꾸고, 속도 제한은 포트나 프로토콜을 바꾸고, MTU 문제는 클라이언트의 MTU 설정을 조정합니다.

혼잡 제어가 패킷 손실의 대가를 결정

전통적인 TCP 혼잡 제어는 패킷 손실을 혼잡 신호로 봅니다. 손실을 감지하면 혼잡 윈도를 크게 줄이고 처리량이 곧바로 무너집니다. BBR은 발상을 바꿉니다. 링크의 대역폭과 최소 왕복 시간을 계속 추정하고 그 추정값에 맞춰 보내므로, 손실이 반드시 속도 저하로 이어지지 않습니다. Hysteria2가 손실이 있는 링크에서 더 나은 성능을 내는 근본 이유가 이것입니다. 더 빠른 것이 아니라 손실에 반응하는 방식이 다른 것입니다. 이 점을 이해하면 ‘같은 노드인데 프로토콜만 바꿨더니 속도 차이가 이렇게 큰 이유’를 두고 고민하지 않게 됩니다.

야간에 느려지는 이유

국제 출구의 대역폭은 공유 자원입니다. 저녁은 사용 피크 시간대로, 출구 링크가 가득 차 큐가 길어지고 대기 지연이 올라가며, 큐가 넘치면 손실이 시작됩니다. 증상은 평소보다 높아진 지연, 상승한 손실률, 떨어진 처리량이며, 같은 시간대 안에서도 변동이 큽니다. 전용선과 최적화 중계의 가치가 이 시간대에 가장 뚜렷합니다. 같은 출구의 공인 인터넷 트래픽과 큐를 다투지 않기 때문입니다. 저녁에만 느리고 낮에는 정상이라면, 로컬 네트워크나 클라이언트 문제가 아니라 공유 출구의 혼잡으로 판단하면 됩니다.

자가 측정의 한계

ping은 ICMP를 쓰며 TCP와 반드시 같은 큐를 지나지 않습니다. ping 값이 낮다고 프록시가 빠른 것은 아닙니다. 속도 측정 도구는 순간 처리량을 재므로, 연속으로 샘플링해야 안정성이 보입니다. 합리적인 관찰 방법은 같은 시간대에 여러 번 샘플링해 지터와 손실률을 보는 것이지, 단일 최고값을 붙들고 보는 것이 아닙니다. 속도 측정 대상 자체의 대역폭이 병목일 수도 있으니, 착지 위치에 더 가까운 측정 대상을 골라야 결과에 참고 가치가 생깁니다.

이 다섯 가지 경우를 기억해 두면, 대부분의 문제는 문의를 넣기 전에 어느 계층인지 특정할 수 있습니다.

상황별 프로토콜 선택

선택에는 정해진 결정 순서가 있습니다. 먼저 회선을 보고, 다음으로 프로토콜을 보고, 마지막에 클라이언트 파라미터를 조정합니다. 회선은 물리적 상한을, 프로토콜은 같은 회선에서의 효율을, 클라이언트 파라미터는 세부 체감을 결정합니다. 순서가 뒤집히면 프로토콜만 계속 바꾸면서도 개선이 없는 순환에 빠집니다. 병목이 프로토콜에 있지 않기 때문입니다.

의사 결정 순서

첫 단계로 그 상황이 지터에 민감한지 묻습니다. 회의, 실시간 협업, 게임이 여기에 속하며 전용선을 우선합니다. 두 번째로 링크의 손실 상황을 봅니다. 무작위 손실이 오래 지속된다면 QUIC 계열의 혼잡 제어가 처리량을 되살릴 수 있습니다. 세 번째로 기기 유형과 배터리 제약을 봅니다. 스마트폰에서 오래 켜 두는 경우에는 TCP 계열을 우선합니다. 네 번째로 UDP 포워딩이 필요한지 봅니다. 일부 앱은 UDP에 의존하므로 클라이언트와 회선이 동시에 지원해야 합니다.

4K 스트리밍

4K 스트리밍은 지속 대역폭 요구가 1080p보다 확실히 높습니다. 비트레이트가 보통 두 자릿수 Mbps에 이르고, 무엇보다 안정성이 필요합니다. 버퍼가 한 번 바닥나면 로딩이 돌기 시작합니다. 선택의 핵심은 최고 속도가 아니라 지속 처리량과 회선 안정성입니다. TCP 계열 프로토콜에 중계나 전용선을 조합하는 편이 UDP에서 최고값을 좇는 것보다 대체로 안정적입니다. 사용 중인 네트워크가 UDP를 제한한다면 QUIC 계열이 오히려 발목을 잡습니다. 지역별 라이브러리와 출구 지역의 관계는 스트리밍 특집 글에 더 구체적인 대조가 있습니다.

화상 회의

회의는 지연과 지터에 민감하고 대역폭 요구는 높지 않습니다. 전용선이나 최적화 중계를 우선하고, 프로토콜은 TCP 계열이면 충분합니다. 회의 중에는 노드를 바꾸지 마세요. 전환이 몇 초의 중단을 만들고, 회의에서는 몇 초면 발언 한 토막이 끊깁니다. 회의 앱 자체가 UDP를 쓴다면 클라이언트가 UDP 트래픽을 버리고 있지 않은지 확인해야 합니다. 그렇지 않으면 소리는 들리는데 화면 공유가 보이지 않는 상황이 생깁니다.

대용량 파일과 백업

대역폭이 크고 지연이 높은 링크에서는 혼잡 제어의 영향이 확대됩니다. BBR 계열 알고리즘은 파이프를 가득 채울 수 있고, Hysteria2가 이런 상황에서 두드러집니다. 다만 트래픽 소모를 염두에 두어야 합니다. 전체 백업 한 번이면 보름치 요금제 한도를 쓸 수 있습니다. 이런 돌발 사용에는 트래픽 패키지가 더 적합합니다. 다 쓰면 끝이고 영구 만료가 없으므로, 한 달치 피크 때문에 월 구독을 올릴 필요가 없습니다.

모바일 장시간 상시 연결

배터리가 우선입니다. TCP 계열 프로토콜을 고르고, 하트비트 간격을 길게 두고, 앱별 프록시를 켭니다. 스마트폰에서 QUIC 계열로 대용량 다운로드를 오래 돌리는 것은 피하세요. 발열과 소모가 모두 눈에 띄게 늘어납니다. 메시지를 받고 웹을 보는 정도의 가벼운 사용이라면 프로토콜 차이를 거의 느끼지 못하므로, 가장 절전에 유리한 조합을 고르면 됩니다.

AI 도구와 장기 연결

AI 도구의 응답은 스트리밍 방식이라, 한 번의 대화가 수십 초짜리 장기 연결을 유지할 수 있습니다. 이런 상황은 대역폭 요구가 낮은 대신 안정성 요구가 높습니다. 연결이 끊기면 답변 전체가 무효가 됩니다. 낮은 지연을 좇기보다 안정적인 회선에 TCP 계열 프로토콜을 쓰는 편이 현실적입니다. 답변이 중간에 멈추는 일이 잦다면 프로토콜을 바꾸기 전에 회선 지터를 먼저 확인하세요. 관련 점검 방법은 도움말 센터에 더 세분화된 항목이 있습니다.

실시간 대전 게임

물리적 거리는 넘을 수 없는 제약이라 프로토콜이 할 수 있는 최적화는 제한적입니다. UDP 포워딩이 필요하고 회선 지터가 작아야 합니다. 대륙 간 대전의 지연 하한은 빛의 속도가 정하며 어떤 프로토콜도 넘을 수 없습니다. 기대치를 제자리에 두는 편이 노드를 계속 바꾸는 것보다 유용합니다.

요금제와 상황의 매칭도 한마디 보탤 만합니다. 월 구독 ¥9.9는 60GB를 포함해 가벼운 브라우징과 메시지류에 적합합니다. ¥18은 250GB로 일상적인 스트리밍과 업무를 포괄합니다. ¥28은 500GB로 과중한 시청과 여러 기기 동시 사용에 맞습니다. 트래픽은 개통일 기준으로 매월 초기화되고, 중간에 업그레이드하면 차액이 남은 일수로 환산됩니다. 갑작스러운 대용량 사용에는 트래픽 패키지가 더 유리합니다. ¥158은 300GB, ¥358은 1000GB, ¥658은 3000GB에 해당하며, 다 쓰면 끝이고 영구 만료가 없습니다.

플랫폼 지원과 구독 가져오기

프로토콜과 회선을 정했다면 마지막 구간은 클라이언트입니다. 같은 구독이라도 플랫폼에 따라 성능이 다를 수 있는데, 차이는 주로 커널의 프로토콜 지원 범위, 백그라운드 유지 정책, 프록시 처리 방식에서 나옵니다. 이 세 가지 차이를 이해하면 ‘같은 노드가 컴퓨터에서는 잘 되는데 스마트폰에서는 안 된다’는 혼란을 크게 줄일 수 있습니다.

다섯 플랫폼의 차이

Windows는 시스템 프록시와 TUN 두 가지 모드가 있습니다. 시스템 프록시는 시스템 설정을 따르는 앱에만 적용되고, TUN은 시스템 프록시를 따르지 않는 프로그램까지 처리할 수 있습니다. macOS는 권한 모델이 더 엄격해 TUN을 처음 켤 때 권한 승인과 네트워크 확장 설치가 필요합니다. iOS는 백그라운드 제한이 가장 엄격해 안내에 따라 구성을 추가해야 하고, 앱별 프록시 기능은 제한적입니다. 안드로이드는 앱별 프록시를 지원하지만 절전 정책에서 수동으로 예외를 둬야 합니다. Linux는 명령줄 클라이언트와 그래픽 클라이언트가 모두 있어, 프록시를 라우터 계층에 두고 같은 네트워크 전체가 하나의 출구를 공유하게 만들기에 적합합니다.

구독 가져오기 네 단계

첫 단계는 사용자 패널에 로그인해 구독 페이지로 들어가는 것입니다. 두 번째는 구독 링크를 복사하는 것입니다. 세 번째는 클라이언트에서 클립보드에서 가져오기를 선택하거나 링크를 직접 붙여 넣는 것입니다. 네 번째는 첫 가져오기 후 한 번 수동으로 업데이트해 노드 목록이 갱신되었는지 확인하는 것입니다. 네 단계를 마쳤다면 회선 하나를 골라 연결하고, 출구 주소를 확인하는 아무 페이지에서나 출구 지역이 선택한 회선과 일치하는지 확인하세요.

https://example.com/sub?token=YOUR_TOKEN

위 내용은 형식 예시이며, 실제 링크는 로그인 후 패널에서 받습니다. 구독 링크는 자격 증명과 같아, 이를 손에 넣은 사람이 여러분의 트래픽 한도를 쓸 수 있습니다. 공개 포럼이나 스크린샷에 붙이지 마세요. 유출이 의심되면 패널에서 구독을 재설정해 기존 링크를 무효화하면 됩니다.

구독을 갱신할 시점

노드 조정, 프로토콜 변경, 요금제 갱신 후에는 클라이언트에서 구독을 한 번 수동으로 업데이트해야 합니다. 일부 클라이언트는 정기 자동 업데이트를 지원하며, 간격은 몇 시간 수준으로 두는 것이 좋습니다. 너무 잦은 가져오기는 의미가 없고, 전환 중에 노드 목록이 잠시 사용할 수 없게 만들기도 합니다.

기기 수 제한 없음과 대역폭 분담

VPNLW 구독은 기기 수 제한이 없어 하나의 계정으로 Windows, macOS, iOS, Android, Linux에서 동시에 사용할 수 있습니다. 다만 회선의 대역폭은 공유되므로, 같은 시간에 여러 기기가 대용량 트래픽을 쓰면 기기 한 대가 쓸 수 있는 대역폭은 줄어듭니다. 가정에서는 다운로드 작업을 피크가 아닌 시간대로 옮기면 체감이 더 좋습니다. ‘기기 수 무제한’과 ‘대역폭 무제한’이 서로 다른 이야기인 이유도 여기에 있습니다. 전자는 권한이고, 후자는 물리적 자원입니다.

클라이언트는 사용자 패널 안에서 받을 수 있으며, 로그인 후 플랫폼별로 내려받으면 됩니다. 구독과 클라이언트를 모두 패널에 두고 마케팅 페이지에는 정적 설치 파일을 두지 않습니다. 이렇게 해야 버전과 계정 상태가 일치합니다.

계층별 트러블슈팅과 검증

트러블슈팅에서 가장 나쁜 것은 시작하자마자 노드를 바꾸는 것입니다. 연결은 계층적으로 수립되므로 어느 계층에서 문제가 생겨도 증상은 ‘연결 안 됨’으로 같습니다. 계층별로 배제하는 편이 반복 시행착오보다 훨씬 빠릅니다. 이 장에서는 그대로 따라 할 수 있는 절차와 각 단계의 검증 명령을 제시합니다.

6계층 모델

첫 계층은 접속 계층입니다. 기기가 네트워크에 연결되어 있는지, Wi-Fi가 정상인지, 강제 포털에 막혀 있지 않은지 봅니다. 두 번째는 이름 해석으로, 도메인이 올바른 주소로 해석되는지, 로컬 DNS에 의해 가로채이지 않았는지 확인합니다. 세 번째는 전송 핸드셰이크로, 노드와 TCP 또는 UDP 연결을 맺을 수 있는지 봅니다. 네 번째는 프로토콜 협상으로, 신원 검증이 통과하는지, 시간이 동기화되어 있는지 확인합니다. 다섯 번째는 분할 규칙으로, 이 트래픽이 규칙에 의해 통과되는지 봅니다. 여섯 번째는 애플리케이션 계층으로, 목적지 서비스 자체가 정상인지 확인합니다.

계층별 검증 방법

접속 계층은 게이트웨이에 ping을 보내 로컬 링크를 확인합니다. 이름 해석은 nslookup에 공용 리졸버를 지정해 대조합니다. 전송 핸드셰이크는 curl의 상세 출력으로 연결이 맺어지는지, TLS가 완료되는지 봅니다. 프로토콜 협상은 클라이언트 로그의 핸드셰이크 결과를 보며, 실패하면 대개 명확한 오류 코드가 남습니다. 분할 규칙은 전역 모드와 대조합니다. 애플리케이션 계층은 다른 목적지 사이트로 바꿔 목적지 서비스 자체의 장애를 배제합니다.

ping -c 4 192.168.1.1
nslookup example.com 1.1.1.1
curl -v --max-time 10 https://example.com/
traceroute example.com

이 네 개의 명령이 앞의 세 계층을 덮습니다. 예시 주소는 일반적인 표기이며, 게이트웨이는 자신의 네트워크 실제 주소로 바꾸면 됩니다.

분할 규칙이 만드는 가짜 장애

규칙 모드에서는 일부 도메인이 직결로, 일부가 프록시로 갑니다. 특정 앱만 열리지 않고 다른 앱은 정상이라면 먼저 전역 모드로 바꿔 대조하세요. 전역에서 정상이면 규칙 문제이고, 전역에서도 이상하면 회선이나 프로토콜 문제입니다. 이 대조만으로도 점검 범위를 한 번에 절반으로 줄일 수 있어 가장 시간을 아끼는 단계입니다. 규칙 문제는 보통 사용자 정의 규칙의 오타, 지나치게 넓은 도메인 접미사 매칭, 또는 규칙 세트 미갱신에서 비롯됩니다.

시간 동기화가 중요한 이유

VMess 같은 프로토콜은 타임스탬프로 검증을 하므로, 시스템 시간 편차가 크면 핸드셰이크가 거부됩니다. 증상은 설정은 맞고 노드도 살아 있는데 연결이 되지 않는 것입니다. 기기의 자동 시간 동기화가 켜져 있는지 확인하세요. 오래 잠들어 있던 노트북과 구형 기기에서 가장 흔합니다.

언제 문의를 넣어야 하는가

계층별 검증을 마쳤는데도 원인을 특정할 수 없을 때 문의를 넣으세요. 문의에는 플랫폼과 클라이언트, 사용한 회선, 문제가 발생한 시간대, 이미 수행한 검증 단계와 결과를 적습니다. 정보가 온전한 문의는 처리 속도가 확실히 빠릅니다. 기본 정보를 주고받으며 확인할 필요가 없기 때문입니다. 특정 시간대에만 문제가 생긴다면 구체적인 시각을 적어 두면 회선 측 기록과 대조하기 좋습니다.

용어와 파라미터 빠른 참조

이 장에서는 앞에서 사용한 용어를 한데 모아 정리하고, 서비스 자체의 파라미터도 함께 실었습니다. 용어는 한글과 영문을 섞어 배열했으며 엄격한 분류는 두지 않았습니다.

용어 목록

요금제와 트래픽 패키지

서비스 파라미터

커버리지: 120+ 국가 / 230+ 회선. 기기: 수 제한 없음. 지원 플랫폼: Windows / macOS / iOS / Android / Linux. 결제 수단: 알리페이 / 위챗 / USDT. 환불: 7일 무조건 환불. 가입: 이메일 주소 불필요, 사용자 이름과 비밀번호만으로 가입. 암호화는 군사 등급 암호화를 적용합니다.

이어 읽기

단계별로 첫 설정을 마치고 싶다면 빠른 시작 가이드를, 구간과 트래픽 패키지를 비교하려면 요금제와 가격을, 지역별로 회선을 고르려면 글로벌 회선 목록을 보세요. 자주 묻는 질문은 도움말 센터에 모여 있습니다. 이어서 읽을 세 편의 확장 글도 있습니다. 초보자 용어 빠른 참조, 지역 라이브러리와 4K 대역폭 실측 비교, 안드로이드 백그라운드 유지와 앱별 프록시입니다.