프로토콜 레퍼런스:6가지 프로토콜과 3가지 회선 구조

6가지 프로토콜은 각각 무엇을 해결하는가

하나의 프록시 프로토콜은 세 가지 일을 동시에 처리해야 합니다. TCP와 UDP 트래픽을 하나의 터널로 캡슐화하고, 그 터널이 중간 장비 눈에는 터널처럼 보이지 않게 만들고, 양 끝단에서 인증과 암호화를 마치는 것입니다. 이 세 가지의 우선순위를 어떻게 두느냐에 따라 프로토콜이 갈립니다. 이 점을 이해하고 나면 프로토콜 이름들을 볼 때 “어느 쪽이 더 강한가”를 고르는 것이 아니라 “이 링크에 무엇이 빠져 있는가”를 고르는 일이라는 게 보입니다.

Shadowsocks: 가장 가벼운 한 겹의 캡슐화

Shadowsocks는 가장 초기의 경량 설계 중 하나입니다. 핵심은 암호화된 SOCKS5 터널 하나이며, AEAD 계열 알고리즘(AES-256-GCM, ChaCha20-Poly1305 등)으로 페이로드를 암호화합니다. 프로토콜 위장은 하지 않습니다. 자신을 HTTPS인 척하지 않고, 트래픽 자체에 평문 흔적이 없다는 것만 보장합니다.

장점은 구현이 단순하고 클라이언트 지원 범위가 가장 넓으며 핸드셰이크 오버헤드가 가장 작다는 점입니다. 대가는 트래픽 형태가 고정적이라는 것입니다. 지속적인 양방향 랜덤 바이트 흐름이고 포트도 반드시 443은 아닙니다. 네트워크 장비가 “비표준 포트의 지속적 암호화 스트림”을 분류할 때 이것이 기댈 외피가 없습니다. UDP 지원도 구현에 따라 달라서 클라이언트마다 동작이 일정하지 않습니다.

VMess: 프로토콜과 전송을 두 계층으로 분리

VMess는 UUID 신원과 타임스탬프 검증을 갖추고 있고, 전송 계층을 교체할 수 있어 WebSocket, gRPC, HTTP/2, mKCP 같은 외피를 씌울 수 있습니다. 이것이 구조적인 최대 장점입니다. 동일한 인증 로직을 다른 외관에 붙일 수 있고, 한 외관이 맞지 않으면 다른 것으로 바꾸면 됩니다.

대가는 프로토콜 자체가 복잡하다는 점입니다. 타임스탬프 검증은 클라이언트와 서버의 시간 오차가 허용 범위 안에 있어야 하므로 기기 시간이 부정확하면 인증이 그대로 실패합니다. 그런데 실패 안내는 대개 “연결 시간 초과”로만 나와서 원인을 한눈에 알기 어렵습니다. 구버전의 AlterID 메커니즘은 호환성을 위해 추가 신원 파생을 남겨 두었는데, 지금은 불필요한 오버헤드와 재전송 공격 면을 줄이기 위해 0으로 두는 것이 보통 권장됩니다.

Trojan: 자신을 표준 TLS 한 번으로 위장

Trojan의 발상은 가장 직접적입니다. 클라이언트가 먼저 서버와 실제 TLS 핸드셰이크를 수행하고, 비밀번호는 TLS 채널 안에서 인증 자격 증명으로 쓰입니다. 중간 장비 입장에서 이 연결은 평범한 HTTPS 사이트 접속과 다르지 않습니다. 프로토콜 수준에서 실제로 그렇기 때문입니다.

대가는 인증서가 반드시 있어야 하고 443 포트를 점유해야 하며, 인증서가 만료되거나 설정이 틀리면 회선 전체가 곧바로 사용 불가가 된다는 점입니다. 또한 “서버 운영 품질”에 가장 크게 의존하는 프로토콜입니다. 인증서 체인, SNI, HTTP 응답 위장 중 어느 하나만 잘못돼도 외관이 드러나거나 연결이 실패합니다.

VLESS: VMess의 감산 버전

VLESS는 프로토콜 계층에 내장된 암호화와 일부 검증을 덜어내고, 보안은 외부의 TLS 또는 Reality에 맡기며 자신은 가벼운 신원 전달만 합니다. 캡슐화가 한 겹 줄어서 핸드셰이크가 더 빠르고 CPU 오버헤드가 더 낮으며, XTLS 방식과 결합하면 전달 손실을 아주 낮게 유지할 수 있습니다.

대가는 자체적으로 암호화를 제공하지 않는다는 점입니다. 설정에서 TLS가 제대로 켜지지 않으면 보안은 전적으로 외부 계층에 달려 있습니다. 이는 “기본이 TLS”인 Trojan과 다릅니다. VLESS를 고르는 전제는 외부 전송이 이미 제대로 설정됐는지 확인하는 것이지, 암호화 없이 그대로 써도 되는 프로토콜로 여기는 것이 아닙니다.

Hysteria2: 손실이 많은 링크를 위한 QUIC 방식

Hysteria2는 QUIC(UDP) 기반이며 혼잡 제어를 자체 탑재합니다. 겨냥하는 지점은 TCP 계열 프로토콜이 손실이 많은 링크에서 드러내는 약점입니다. QUIC는 사용자 공간에서 혼잡 제어를 구현하므로 무작위 손실에 둔감한 알고리즘을 쓸 수 있고, TCP처럼 손실 하나하나를 혼잡 신호로 해석하지 않아도 됩니다.

대가는 UDP 특성이 뚜렷하다는 점입니다. 일부 네트워크는 UDP를 속도 제한하거나 등급을 낮추는데, 그럴 때 성능이 갑자기 나빠지고 이 악화는 환경 때문이라 파라미터를 바꿔도 해결되지 않습니다. 또한 사용자 공간 프로토콜 스택은 커널 TCP보다 CPU 사용량이 높아서, 저전력 기기에서는 이 차이가 더 크게 벌어집니다.

TUIC: 더 미니멀한 QUIC 프록시

TUIC 역시 QUIC 기반이며 설계는 “극도로 단순한 QUIC 프록시”에 가깝고, 0-RTT 핸드셰이크 복구를 지원합니다. 연결 수립 왕복이 적고 재연결이 빨라, 끊김과 재연결이 잦은 모바일 환경에 적합합니다.

대가는 생태계가 Hysteria2보다 좁다는 점입니다. 일부 클라이언트와 패널은 아직 지원하지 않습니다. 선택 전에 사용 중인 클라이언트 버전이 이를 인식하는지 먼저 확인하세요. 그렇지 않으면 “설정은 맞게 썼는데 클라이언트가 인식하지 못하는” 상황이 생깁니다.

핸드셰이크, 오버헤드와 연결 수립 속도

프로토콜 사이에서 가장 먼저 측정 가능한 차이는 “연결 하나를 세우는 데 몇 번의 왕복이 필요한가”입니다. 이 숫자가 첫 화면 속도를 좌우하며, 특히 국가 간 링크에서는 왕복 한 번이 100밀리초를 넘습니다.

연결 한 번의 왕복 횟수

“연결”을 누른 뒤 첫 바이트가 나갈 때까지 피할 수 없는 단계는 다음과 같습니다.

1. 도메인 조회: 클라이언트가 도메인으로 서버에 접속한다면 먼저 주소를 조회해야 합니다. IP로 직접 연결하면 이 단계를 생략할 수 있습니다.
2. TCP 3방향 핸드셰이크: 왕복 한 번, 예외는 없습니다.
3. TLS 핸드셰이크: TLS 1.3은 왕복 한 번, TLS 1.2는 왕복 두 번입니다. 이 계층은 Trojan, VLESS over TLS, 그리고 TLS를 씌운 VMess에만 있습니다.
4. 프록시 프로토콜 자체의 인증: 대부분의 프로토콜은 인증을 첫 데이터 패킷에 실어 보내므로 왕복을 추가로 차지하지 않습니다.
5. 대상 사이트 자체의 핸드셰이크: 프록시는 바이트를 전달할 뿐이고, 대상 사이트의 연결 비용은 그대로 존재합니다.

왕복 150밀리초의 국가 간 링크에서는 TCP와 TLS 1.3만으로도 300밀리초가 걸립니다. 소프트웨어가 느린 게 아니라 물리적 거리가 정한 값입니다. 어떤 클라이언트 최적화도 소프트웨어 계층 비용을 줄일 수는 있어도, 빛이 광섬유를 달리는 시간을 줄이지는 못합니다.

각 프로토콜이 이 시간축에서 차지하는 위치

Shadowsocks는 TLS 계층이 없고 인증이 첫 패킷에 합쳐져 있어 이론상 왕복 1회 후 바로 데이터를 보낼 수 있습니다. VMess도 인증을 첫 패킷에 두어 왕복은 늘지 않지만, 첫 패킷에서 타임스탬프와 UUID를 해석하므로 CPU를 조금 더 씁니다. Trojan과 VLESS over TLS는 완전한 TLS 핸드셰이크를 거쳐야 하므로 Shadowsocks보다 왕복이 하나 더 들고, 그 대가로 “HTTPS처럼 보인다”는 점을 얻습니다.

Hysteria2와 TUIC는 QUIC를 씁니다. QUIC는 전송 핸드셰이크와 암호화 핸드셰이크를 합쳐 최초 연결이 왕복 1회이고, TUIC는 0-RTT 복구를 지원해 세션 티켓이 유효한 동안에는 재연결에 추가 왕복이 필요 없습니다. 이것이 “잦은 끊김과 재연결” 상황에서 QUIC 계열이 갖는 실제 우위이며, 마케팅 문구가 아닙니다.

CPU와 메모리의 실제 비용

암복호화는 공짜가 아니지만 현대 CPU에서는 아주 저렴합니다.

• AES-GCM은 AES-NI를 지원하는 x86 프로세서에서 하드웨어 가속을 받아 처리량이 수 GB/s 수준까지 나오므로, 프록시 연결 하나로는 그 한계를 채우지 못합니다.
• ARM 기기(스마트폰, 공유기, TV 박스)는 AES 명령어 집합 지원이 고르지 않아 ChaCha20-Poly1305가 대체로 더 빠릅니다. 모바일에서 ChaCha20을 권하는 이유도 여기에 있습니다.
• QUIC 계열 프로토콜은 사용자 공간에서 프로토콜 스택을 구현하므로 패킷마다 사용자 공간을 드나들어야 해 CPU 사용량이 커널 TCP보다 확실히 높습니다. 저전력 기기에서는 이 차이가 “팬이 돈다”거나 “배터리가 빨리 준다”로 증폭됩니다.
• 메모리 측면의 주된 비용은 연결마다 잡히는 버퍼입니다. 멀티플렉싱은 여러 연결을 하나의 터널로 압축해 핸드셰이크와 버퍼를 줄이지만, 그 대가로 헤드오브라인 블로킹이 생깁니다.

핸드셰이크 비용이 증폭되는 이유

핸드셰이크 시간은 “새 연결을 열 때” 한 번만 지불됩니다. 브라우저는 같은 사이트에 대해 연결을 재사용하지만, 현대 웹페이지는 여러 도메인에 걸쳐 있습니다. 통계, 폰트, 이미지, API가 각각 다른 도메인에 있어서 페이지 한 번 로딩에 새 연결이 열 개 이상 생기기도 합니다. 이때 핸드셰이크 왕복이 열 배 이상으로 증폭되며, 이것이 “프로토콜이 첫 화면 속도에 영향을 준다”는 말의 실제 근거입니다.

반대로 영상 재생이나 대용량 파일 다운로드처럼 연결을 오래 유지하는 상황에서는 핸드셰이크가 한 번만 일어나므로 프로토콜 간 핸드셰이크 차이가 거의 드러나지 않습니다. 그래서 같은 프로토콜도 상황에 따라 체감이 전혀 달라질 수 있고, “어느 프로토콜이 빠른가”를 논하기 전에 어떤 상황인지부터 밝혀야 합니다.

모바일의 배터리 계산

스마트폰의 전력 소모는 네 갈래로 구성됩니다. CPU 암복호화, 무선 주파수 송수신, 시스템 웨이크업 횟수, 화면과 하드웨어 디코딩입니다. 프로토콜이 영향을 주는 것은 앞의 세 가지인데, 대부분의 사용자가 체감하는 “프록시를 켜면 배터리가 빨리 준다”는 사실은 세 번째, 즉 웨이크업 횟수에서 옵니다.

무선 주파수 웨이크업의 비용

이동통신의 무선 상태 기계에는 여러 단계가 있습니다. 유휴, 저전력, 고전력입니다. 유휴에서 고전력으로 넘어가는 데 수백 밀리초가 걸리고, 그동안 전력 소모는 최대치의 몇 배입니다. 어떤 연결이 10초마다 하트비트 패킷을 보낸다면 무선 모듈은 10초마다 깨어나야 하고, 하루로 계산하면 8천 번이 넘는 웨이크업이 됩니다.

• TCP 계열 프로토콜의 keepalive는 보통 설정할 수 있으며, 시스템 수준 TCP keepalive 기본 간격은 매우 깁니다(시간 단위). 애플리케이션 계층에서 하트비트를 보내지 않아도 됩니다.
• QUIC 계열 프로토콜은 NAT 매핑을 유지하기 위해 기본적으로 주기적 keep-alive를 사용하며, 간격은 보통 10여 초에서 수십 초입니다. QUIC가 모바일에서 전력을 더 쓰는 주된 이유가 바로 이것이며, 암복호화 자체 때문이 아닙니다.

그래서 “프로토콜을 바꾸면 전기가 절약된다”는 말은 정확히는 “주기적 하트비트를 없애면 전기가 절약된다”는 뜻입니다. 같은 QUIC 연결이라도 하트비트 간격을 10여 초에서 2분으로 늘리면 전력 차이가 아주 뚜렷해집니다.

암복호화가 차지하는 실제 비중

AES 명령어 집합을 지원하는 스마트폰에서 AES-GCM 처리량은 이동통신 대역폭 상한을 크게 웃돌기 때문에 암복호화에 쓰는 CPU 시간은 무시할 수준입니다. 실제로 CPU를 먹는 것은 QUIC의 사용자 공간 스택입니다. 패킷마다 사용자 공간과 커널 공간 사이 복사가 한 번씩 일어나고, 최고 속도로 계속 내려받는 동안 CPU가 오랫동안 높은 주파수를 유지합니다.

반대로 웹 서핑이나 메시지 확인처럼 트래픽 자체가 적은 용도라면 QUIC의 CPU 비용이 드러날 여지가 없고, 배터리 차이는 다른 요인에 묻힙니다.

백그라운드 유지와 “아직 연결된 것처럼 보이는” 상태

iOS와 Android 모두 백그라운드 앱을 회수합니다. 프록시 앱은 보통 시스템 VPN 프레임워크를 통해 동작하고 이 통로는 비교적 안정적이지만, 앱 내부 타이머는 여전히 시스템에 의해 조절됩니다. 그 결과 화면을 잠근 뒤 한참 있다가 다시 풀면 연결은 남아 있는 것처럼 보이는데 첫 요청만 눈에 띄게 느립니다. 터널을 다시 세우거나 재협상해야 하는 상태입니다.

이 “아직 연결된 것처럼 보이는” 상태는 완전히 끊긴 것보다 다루기 번거롭습니다. 클라이언트의 자동 재연결 로직이 작동하지 않기 때문입니다. 잠금 해제 후 첫 웹페이지가 몇 초간 비어 있는 일이 잦다면 클라이언트에서 “끊기면 자동 재연결”을 켜거나, 오래 쓰지 않을 때는 차라리 수동으로 끊으세요.

배터리 절약을 위한 실전 요령

• 스마트폰에서는 TCP 계열 프로토콜을 우선 쓰고, QUIC 계열은 약전계 상황에 남겨 두세요.
• 지연이 더 낮은 근거리 회선을 고르세요. 핸드셰이크 왕복이 짧을수록 무선 모듈이 고전력에 머무는 시간도 짧아집니다.
• 불필요한 앱별 프록시는 끄세요. 필요한 앱만 터널을 지나가게 하면 상시 연결 수가 줄어듭니다.
• 하트비트 간격을 늘리세요. 단, NAT 타임아웃으로 매핑 테이블이 지워지지 않는 네트워크여야 합니다.
• 오래 영상을 볼 때는 전력 차이가 주로 화면과 하드웨어 디코딩에서 나오므로 프로토콜 간 차이는 희석됩니다.

회선 구조: 직결, 중계, 전용선

프로토콜이 “어떻게 캡슐화하는가”를 정한다면, 구조는 “어느 길로 가는가”를 정합니다. 국가 간 상황에서는 구조가 체감에 미치는 영향이 대개 프로토콜보다 큽니다. 같은 프로토콜이라도 구조가 다른 회선으로 바꾸면 프로토콜을 세 번 바꾼 것보다 차이가 뚜렷할 수 있습니다.

직결

클라이언트가 해외 데이터센터의 공인 주소에 직접 연결하고, 트래픽은 통신사의 국제 출구를 지납니다.

• 구조가 가장 단순하고 중간 단계가 없어 기준 지연이 가장 낮습니다.
• 다만 국제 출구는 공유 자원입니다. 야간에는 출구 큐가 길어지며 손실과 지연이 함께 올라가고, 이 혼잡은 서비스 제공자가 통제할 수 없습니다.
• 적합: 가벼운 웹 브라우징, 비혼잡 시간대, 비용에 민감한 상황.

직결의 문제는 “느리다”가 아니라 “예측할 수 없다”입니다. 한산한 시간에는 중계보다 빠를 수 있고 야간에는 전혀 쓸 수 없을 수도 있는데, 두 상태 사이에 아무런 예고도 없습니다.

중계

클라이언트가 먼저 국내 중계 진입점에 연결하고, 그 진입점이 다시 해외 착지점으로 연결합니다.

• “마지막 구간”의 불확실성을 통제 가능한 한 구간으로 모읍니다. 클라이언트에서 중계 진입점까지는 국내 백본을 지나 대체로 안정적이고, 진입점에서 착지점까지는 최적화된 국가 간 라우팅을 지납니다.
• 대가는 홉이 하나 늘어 기준 지연이 증가한다는 점입니다. 중계 노드 자체의 처리 능력도 병목이 될 수 있어, 대역폭이 부족한 중계는 직결보다 못합니다.
• 핵심 지표는 “중계가 있느냐”가 아니라 “중계 구간의 국가 간 라우팅이 최적화됐느냐”입니다. 같은 중계라도 공인 출구를 지나는 것과 최적화 라우팅을 지나는 것은 전혀 다른 일입니다.

그래서 서비스 제공자마다 중계 회선의 체감 차이가 크게 벌어질 수 있습니다. 이름은 같아도 뒤에 있는 라우팅 정책이 완전히 다르기 때문입니다. 판별 방법은 하나뿐입니다. 야간 혼잡 시간대에 직접 써 보는 것.

전용선

종단 간 논리 전용선(IEPL, MPLS 계열)으로, 대역폭을 독점 또는 준독점하며 공인 출구의 혼잡 지점을 지나지 않습니다.

• 지연이 안정적이고 손실이 낮아, 야간에도 한산한 시간대와 비슷한 성능을 냅니다.
• 비용이 높고 총 대역폭이 제한적이어서 보통 주요 지역에만 구축되며 모든 국가를 커버할 수는 없습니다.
• 적합: 실시간성이 중요한 상황. 예를 들어 화상회의, 게임, 원격 데스크톱, 안정성에 민감한 업무.

전용선은 “더 빠른” 것이 아니라 “더 안정적인” 것입니다. 절대 지연이 직결보다 반드시 낮지는 않지만, 밤 8시에 재든 새벽 2시에 재든 숫자가 비슷해야 하며, 바로 그 점이 값어치입니다.

지연은 무엇으로 구성되는가

1. 물리적 전파: 빛은 광섬유에서 1밀리초당 약 200킬로미터를 갑니다. 상하이에서 로스앤젤레스까지 직선거리는 약 10500킬로미터이고, 편도 광경로를 우회 계수 1.4배로 계산하면 약 14700킬로미터, 편도 약 73밀리초, 왕복 약 146밀리초입니다. 이것이 물리적 하한이며 어떤 최적화도 넘어설 수 없습니다.
2. 라우팅 우회: 실제 경로가 항상 최단 경로를 지나는 것은 아니며, 우회는 수십 밀리초를 더합니다.
3. 대기 지연: 출구가 혼잡하면 패킷이 큐에서 기다립니다. 이 항목은 야간에 몇 배로 늘어날 수 있고, 가장 통제하기 어려운 항목입니다.
4. 프로토콜 핸드셰이크: 앞 장에서 본 것처럼 계층이 하나 늘 때마다 왕복이 하나 늘어납니다.

그래서 “이 회선은 지연이 40밀리초”라는 말은 출발지와 도착지를 명시할 때만 의미가 있습니다. 같은 노드라도 광저우에서 재는 것과 하얼빈에서 재는 것은 두 배까지 차이가 날 수 있습니다.

패킷 손실, 지터와 야간 혼잡

“야간에 느려진다”는 국가 간 접속에서 가장 흔한 불만이자 가장 오해받는 현상입니다. 그것은 하나의 원인이 아니라 연쇄 반응의 결과입니다.

패킷 손실은 어디서 오는가

• 비트 오류: 광섬유의 비트 오류율은 극히 낮아 정상 링크에서 비트 오류로 인한 손실은 무시할 수 있습니다. 무선 구간(4G, 5G, Wi-Fi)은 예외로, 신호가 약하면 비트 오류율이 뚜렷하게 올라갑니다.
• 큐 오버플로: 라우터 버퍼가 가득 차서 뒤에 온 패킷이 버려집니다. 국가 간 링크에서 가장 큰 손실 원인입니다.
• 정책적 손실: 일부 네트워크 장비는 특정 유형의 트래픽을 속도 제한하거나 버립니다. QUIC 계열 프로토콜이 특정 네트워크에서 불안정한 이유이기도 합니다.

세 가지 손실은 대응 방식이 완전히 다릅니다. 비트 오류는 무선 환경을 바꾸는 수밖에 없고, 큐 오버플로는 구조를 바꾸거나 시간대를 피하면 되고, 정책적 손실은 프로토콜이나 포트를 바꾸는 수밖에 없습니다. 출처를 구분하지 않고 파라미터만 만지는 것은 대개 헛수고입니다.

야간 혼잡은 어떻게 생기는가

저녁 7시부터 11시까지 가정용 인터넷 동시 사용이 늘고, 국제 출구의 총 트래픽이 설계 용량에 근접하거나 넘어섭니다. 출구 장비가 큐잉을 시작하고, 이어서 연쇄가 일어납니다.

1. 큐가 길어지고 지연이 올라갑니다.
2. 큐가 가득 차면 손실이 시작됩니다.
3. TCP는 손실을 혼잡 신호로 해석해 혼잡 윈도를 절반으로 줄이고, 처리량이 급감합니다.
4. 사용자는 느리다고 느껴 새로고침하고 재시도하며 새 연결이 몰려들어 혼잡이 더 심해집니다.

이것은 양의 피드백이라서 야간 체감 저하는 선형이 아니라 어느 지점을 넘으면 갑자기 나빠집니다. “8시까지는 괜찮았는데 8시 5분에 갑자기 안 된다”는 느낌이 드는 이유가 여기에 있습니다.

왜 1퍼센트의 손실이 대역폭 절반을 망가뜨리는가

TCP 처리량은 대략 “세그먼트 크기 ÷ (왕복 시간 × 손실률의 제곱근)”에 비례합니다. 왕복 150밀리초, 손실률 1퍼센트이면 단일 TCP 연결의 이론 처리량은 최대치의 아주 작은 부분으로 떨어집니다. “속도 측정 사이트에서는 만점인데 웹페이지는 느린” 상황이 동시에 나타나는 이유이기도 합니다. 속도 측정은 다중 스레드 병렬을 쓰고, 웹페이지는 단일 연결을 쓰기 때문입니다.

이 점을 이해하면 많은 “미스터리”가 풀립니다. 같은 시간, 같은 회선에서 다운로더는 만점을 내는데 브라우저는 버벅인다면 브라우저 문제가 아니라 병렬 모델이 다르기 때문입니다.

QUIC 계열이 손실이 많을 때 유리한 이유

QUIC는 사용자 공간에서 혼잡 제어를 구현하며, 흔히 쓰는 알고리즘은 대역폭과 왕복 시간을 모델링해 손실 하나하나를 혼잡 신호로 보지 않습니다. 무작위 손실이 주를 이루는 링크에서 처리량을 더 잘 유지할 수 있습니다. 대가는 “진짜 혼잡”에 대한 반응도 둔하다는 점이어서, 실제로 대역폭이 부족할 때는 다른 트래픽에 덜 관대하게 동작합니다.

다시 말해 QUIC 계열은 “더 빠른” 것이 아니라 “손실에 더 관대한” 것입니다. 링크가 손실 없이 깨끗하면 TCP 계열과 뚜렷한 차이가 없고, 손실이 시작될 때 차이가 벌어집니다.

버퍼 팽창

가정용 공유기와 일부 통신사 장비는 큰 버퍼를 씁니다. 버퍼가 큰 것은 순간적인 폭주에는 좋지만, 지속적으로 포화 상태가 되면 대기 지연이 수백 밀리초까지 치솟습니다. 증상은 이렇습니다. 속도 측정은 정상인데 클릭할 때마다 잠깐씩 기다리게 되고, 영상은 재생되지만 진행 바를 끌면 로딩이 돕니다.

판별 방법: 로컬 게이트웨이와 해외 대상의 왕복 시간을 동시에 관찰하세요. 게이트웨이 자체가 흔들리면 문제는 로컬에 있고, 게이트웨이는 안정적인데 해외 대상이 흔들리면 문제는 국가 간 구간에 있습니다. 이 한 단계만으로도 점검 범위를 절반으로 줄일 수 있습니다.

지터가 지연보다 체감에 더 큰 영향을 준다

지연이 높아도 안정적이면 사용자는 적응합니다. 지연이 그리 높지 않아도 지터가 크면 영상은 자주 버퍼링하고 음성은 끊기며 게임은 순간이동합니다. 회선을 고를 때 지터의 가중치를 평균 지연보다 높게 두어야 합니다. 많은 클라이언트가 “지연” 숫자 하나만 보여 주는데, 그 숫자는 보통 여러 번 측정한 평균이라 지터를 알 수 없습니다. 직접 여러 번 연속 측정해 변동 폭을 봐야 합니다.

상황별 선택

앞의 장들은 원리였고, 이 장은 결론입니다. 전제가 있습니다. 아래 권장은 모두 “회선 자체는 사용 가능하다”는 상태를 기준으로 합니다. 회선이 야간에 이미 심하게 혼잡하다면 프로토콜을 바꾸는 것은 완화일 뿐 치료가 아닙니다.

일상 웹과 사무

VLESS over TLS 또는 Trojan을 권장합니다.

이유: 웹페이지 로딩은 짧은 연결을 대량으로 발생시켜 핸드셰이크 왕복이 증폭됩니다. 이 두 프로토콜은 표준 TLS를 쓰고 연결 재사용과 결합되어 첫 화면 경험이 안정적이며, 트래픽 외관이 일반 HTTPS라 여러 네트워크 환경에서 호환성이 가장 좋습니다. 사무 환경에서는 QUIC 계열을 권하지 않습니다. 짧은 연결에서는 QUIC의 핸드셰이크 우위가 뚜렷하지 않고, 사용자 공간 스택의 CPU 비용이 저사양 노트북에서 체감되기 때문입니다.

4K 스트리밍

VLESS 또는 Trojan에 중계나 전용선을 조합하는 것을 권장합니다.

이유: 스트리밍은 연결을 오래 유지하고 대용량이 지속되는 상황이라 대역폭 안정성이 우선입니다. TCP 계열 프로토콜은 대역폭이 충분하면 만점을 낼 수 있고, 전용선이나 최적화된 중계는 야간 출구 혼잡을 피할 수 있습니다. 사용 중인 네트워크가 UDP에 우호적이라면 Hysteria2도 선택지입니다. 손실이 있는 링크에서 비트레이트 유지가 더 좋아 플레이어의 화질 강등을 덜 유발합니다. 사이트의 스트리밍 시청 페이지에 플랫폼별 회선 권장과 비트레이트와 대역폭의 관계에 대한 자세한 설명이 있습니다.

온라인 게임

Trojan 또는 VLESS를 권장하며, 근거리 노드를 고르고 멀티플렉싱은 켜지 마세요.

이유: 게임은 지연과 지터에 민감하고 대역폭에는 둔감합니다. TCP 계열 프로토콜의 지연 곡선이 더 평평합니다. 멀티플렉싱은 여러 연결을 하나의 터널에 밀어 넣어, 터널에 손실이 생기면 모든 연결이 함께 막힙니다(헤드오브라인 블로킹). 증상은 “게임 한 판 내내 갑자기 모두의 지연이 튀는” 것으로 나타납니다.

게임 자체가 UDP 포워딩을 필요로 한다면 클라이언트와 서버 모두에서 UDP가 켜져 있는지 확인하세요. 그렇지 않으면 “로그인은 되는데 대전에 들어가지지 않는” 상황이 생깁니다. 지연과 손실에 대한 더 많은 실측 방법은 게임 상황의 지연과 패킷 손실 분석을 참고하세요.

대용량 파일 다운로드와 업데이트

Hysteria2를 권장합니다.

이유: 다운로드는 순수 처리량 상황이라 지연에 둔감합니다. 손실이 많은 링크에서 QUIC 계열의 처리량 우위가 가장 뚜렷합니다. 대가는 CPU 사용량이 높다는 점으로, 저전력 기기에서는 오히려 병목이 될 수 있습니다. 다운로드 속도가 오르지 않는데 CPU는 포화 상태라면 기기 연산 능력이 먼저 한계에 닿은 것입니다.

모바일 장시간 대기

Trojan 또는 VLESS를 권장합니다. 이유는 배터리 장에서 설명했습니다. QUIC 계열의 주기적 keep-alive가 무선 모듈을 계속 깨웁니다. 안드로이드의 백그라운드 유지와 절전 정책에는 별도의 세부 사항이 있으니 안드로이드 실측 비교를 참고하세요.

약전계 환경

Hysteria2 또는 TUIC를 권장합니다.

이유: 약전계의 전형적 특징은 손실률이 높고 지터가 크다는 것입니다. TCP 계열 프로토콜은 이런 상황에서 혼잡 윈도를 반복적으로 줄여 “속도가 들쭉날쭉”해집니다. QUIC 계열의 혼잡 제어는 무작위 손실에 둔감해 속도가 더 고릅니다. 공공장소 Wi-Fi, 신호가 한두 칸뿐인 이동통신, 고속철도 안이 모두 여기에 해당합니다.

AI 도구를 함께 써야 할 때

AI 도구의 API 호출은 짧은 요청이지만 단일 응답이 아주 길 수 있습니다(생성형 응답은 스트리밍으로 반환됩니다). 이런 상황은 첫 패킷 지연에 민감하고 대역폭 요구는 중간 정도이므로, VLESS나 Trojan에 중계 회선을 조합하는 것을 권장합니다. 자세한 내용은 사이트의 AI 도구 특집을 참고하세요.

단계별 트러블슈팅과 자가 점검

트러블슈팅의 핵심은 계층화입니다. “연결되는가”와 “빠른가”를 분리하고, “빠른가”를 다시 지연, 손실, 대역폭 세 가지로 나눕니다. 각 계층에서 변수를 하나만 바꿔야 어느 단계가 효과를 냈는지 알 수 있습니다.

1단계: 트래픽이 실제로 터널을 지나는지 확인

“연결됨” 표시가 트래픽이 실제로 회선을 지난다는 뜻은 아닙니다. 검증 방법은 세 가지입니다.

1. 출구 IP 확인: 연결 전후에 한 번씩 조회하면 달라야 하고, 소속 지역이 회선이 위치한 지역이어야 합니다.
2. DNS 확인: 조회 요청은 터널 내부의 리졸버가 처리해야 하며 로컬 통신사가 처리하면 안 됩니다. DNS가 로컬로 나가면 “연결은 되는데 일부 사이트가 열리지 않는” 증상이 생깁니다.
3. 앱별 검증: 앱별 프록시를 켰다면 대상 앱이 프록시 목록에 있는지 확인하세요.

전체 절차는 사이트 글 VPN이 실제로 적용됐는지 확인하는 방법에 있습니다. 명령줄에서는 이렇게 확인할 수 있습니다.

# 1. 현재 출구 IP 확인(예시 주소이며, 순수 텍스트 IP를 반환하는 아무 서비스로 바꿔도 됩니다)
curl -s https://example.com/ip

# 2. 현재 사용 중인 DNS 서버 확인
nslookup example.com
# 출력에서 "Server:" 뒤에 오는 값이 실제로 사용되는 리졸버 주소입니다

# 3. 연속으로 측정해 평균만 보지 말고 지터를 확인
ping -c 20 example.com

ping은 ICMP를 사용하며, 일부 회선은 ICMP의 우선순위를 TCP와 다르게 처리합니다. ping이 정상이라고 TCP가 정상인 것은 아니고 그 반대도 마찬가지입니다. TCP 왕복을 재려면 curl로 각 단계 소요 시간을 보세요.

curl -o /dev/null -s -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://example.com

이 숫자들이 시간이 어느 구간에서 쓰였는지 바로 알려 줍니다. time_namelookup이 크면 DNS 문제, time_connect가 크면 TCP 핸드셰이크나 링크 문제, time_appconnect가 time_connect보다 훨씬 크면 TLS 핸드셰이크가 느린 것이며 보통 회선 왕복이 너무 길거나 인증서 체인이 너무 긴 경우입니다.

2단계: 연결되지 않음

순서대로 확인하고 단계를 건너뛰지 마세요.

• 구독 만료 여부: 트래픽을 다 쓰거나 기간이 만료되면 클라이언트는 여전히 “연결됨”을 표시하지만 모든 요청이 거부됩니다. 가장 흔하면서도 가장 놓치기 쉬운 항목입니다.
• 기기 시간: VMess는 타임스탬프 검증에 의존하므로 시간 오차가 크면 인증이 그대로 실패합니다. 자동 동기화를 켜세요.
• 프로토콜과 포트 일치 여부: 서버 설정은 바뀌었는데 클라이언트 구독이 갱신되지 않은 것이 흔한 원인입니다. 구독을 다시 받아 오세요.
• 로컬 방화벽: 일부 보안 소프트웨어가 비표준 포트의 아웃바운드 연결을 차단하면 모든 회선이 연결되지 않는 것처럼 보입니다.
• 인증서: Trojan과 VLESS over TLS는 인증서에 의존합니다. 인증서가 만료되면 클라이언트는 “연결 시간 초과”가 아니라 TLS 핸드셰이크 실패를 보고합니다.

3단계: 연결은 되는데 느림

1. 회선 교체: 같은 회선도 시간대에 따라 성능 차이가 큽니다. 먼저 구조가 다른 회선으로 바꿔 비교하세요.
2. 프로토콜 교체: 같은 회선에서 프로토콜만 바꿔 보세요. TCP 계열이 느린데 QUIC 계열이 정상이라면 링크에 손실이 있다는 뜻입니다.
3. 시간대 확인: 느려지는 시점을 기록하세요. 저녁에 고정적으로 느려지면 출구 혼잡이고, 하루 종일 그렇다면 회선 자체의 문제입니다.
4. 단일 연결 확인: 단일 스레드 다운로드로 테스트하세요. 다중 스레드는 빠른데 단일 스레드가 느리면 손실이나 버퍼 팽창이 있다는 뜻입니다.
5. MTU 확인: QUIC는 MTU에 민감합니다. 경로 MTU 블랙홀의 증상은 “핸드셰이크 성공, 작은 요청 정상, 큰 요청 멈춤”입니다. MTU를 낮춰(예: 1280) 다시 시도하세요.

4단계: 일부 앱에서만 문제가 있음

• 앱별 프록시 목록에 해당 앱이 포함되어 있는지.
• 앱이 자체 DNS나 암호화 DNS를 사용해 터널 내부 조회를 우회하고 있는지.
• 앱이 IPv6를 강제하는데 터널은 IPv4만 프록시하고 있는지.
• 앱이 인증서 피닝을 사용해 중간 프록시와 호환되지 않는지.

이 계층은 점검 비용이 가장 큽니다. 앱마다 네트워크 동작이 다르기 때문입니다. 효과적인 방법은 먼저 브라우저로 터널 자체에 문제가 없음을 확인하고, 그다음 앱을 하나씩 점검하는 것입니다.

파라미터 빠른 조회와 흔한 오해

마지막 장에서는 클라이언트의 스위치들을 하나씩 정리하고, 흔한 오해 몇 가지를 나열합니다. 이 장은 도구 페이지처럼 써도 됩니다. 헷갈리는 옵션이 있으면 돌아와서 확인하세요.

클라이언트의 몇 가지 스위치

• TLS: 켜면 트래픽 외관이 HTTPS가 됩니다. Trojan과 VLESS는 반드시 켜야 하고, Shadowsocks와 VMess는 TLS를 씌울 수 있지만 왕복이 하나 늘어납니다.
• XTLS와 Reality: VLESS의 두 가지 전송 최적화입니다. 전자는 암복호화 계층의 복사를 줄이고, 후자는 서버가 자체 인증서 없이도 실제 TLS 특성을 보이게 합니다. 둘 다 서버 협조가 필요하며 클라이언트에서만 켜면 효과가 없습니다.
• 멀티플렉싱: 여러 연결을 하나의 터널로 재사용합니다. 핸드셰이크 횟수를 줄이지만 손실이 있는 링크에서는 헤드오브라인 블로킹을 유발합니다. 웹 브라우징에는 켜도 되지만 게임과 음성에는 권하지 않습니다.
• UDP 포워딩: UDP 트래픽이 터널을 지날지 결정합니다. 게임, 음성, 일부 영상 통화가 여기에 의존합니다. 끄면 해당 앱들은 직접 연결되거나 사용할 수 없습니다.
• 혼잡 제어: QUIC 계열 프로토콜에서 보통 선택할 수 있습니다. 대역폭 모델링 기반 알고리즘은 손실이 많은 링크에서 처리량이 좋지만, 진짜 혼잡 상황에서는 다른 트래픽에 덜 관대합니다.
• 앱별 프록시: 지정한 앱만 터널을 지나가게 합니다. 전력을 아끼고 간섭을 줄이지만, 설정이 잘못되면 “특정 앱이 연결되지 않는” 상황이 생깁니다.
• 구독 자동 업데이트: 최신 회선을 주기적으로 받아 옵니다. 켜 두는 것이 좋지만 너무 자주 설정하면 업데이트마다 잠깐씩 끊깁니다.

흔한 오해 여섯 가지

오해 1: 프로토콜이 최신일수록 빠르다.프로토콜이 정하는 것은 오버헤드와 손실 내성이고, 대역폭 상한은 회선과 착지점이 정합니다. 손실이 낮은 깨끗한 링크에서는 여섯 프로토콜의 처리량 차이가 회선 간 차이보다 훨씬 작습니다.

오해 2: 암호화가 강할수록 느리다.AEAD 계열 암호화는 현대 프로세서에서 비용이 아주 작고, 진짜 병목은 링크입니다. 암호화를 AES-256에서 ChaCha20으로 바꾸면 스마트폰에서는 측정 가능한 차이가 있을 수 있지만 데스크톱에서는 거의 느낄 수 없습니다.

오해 3: 지연이 낮으면 무조건 빠르다.지연은 “시작” 속도에 영향을 주고, 처리량은 손실과 혼잡 윈도에 달려 있습니다. 왕복 40밀리초에 손실 2퍼센트인 회선은 왕복 80밀리초에 손실이 거의 없는 회선보다 다운로드 속도가 느릴 수 있습니다.

오해 4: UDP는 무조건 속도 제한을 받는다.네트워크 환경에 따라 다르므로 일반화할 수 없습니다. 판별은 간단합니다. 같은 회선에서 TCP 계열과 QUIC 계열로 각각 단일 스레드 다운로드를 해 보고 비교하세요.

오해 5: 다중 프록시가 더 안전하다.계층을 겹치면 지연과 장애 지점만 늘어나고 단일 계층 암호화의 강도가 올라가지는 않습니다. 필요한 것은 계층 수가 아니라 올바른 프로토콜 설정입니다.

오해 6: 연결 수가 많을수록 빠르다.브라우저의 동시 연결 수에는 한계가 있어 그 이상은 새 연결이 대기합니다. 클라이언트를 여러 개 띄우고 터널을 여러 개 열면 서로 대역폭을 뺏을 뿐입니다.

이 매뉴얼 활용하기

이제 시도해 보기로 했다면 먼저 요금제 페이지에서 등급을 확인하세요. 월 구독은 ¥9.9에 60GB, ¥18에 250GB, ¥28에 500GB이며, 트래픽은 개통일 기준으로 매월 초기화되고 중간에 업그레이드하면 차액이 남은 일수로 환산됩니다. 별도로 트래픽 패키지 ¥158/300GB, ¥358/1000GB, ¥658/3000GB가 있으며 다 쓰면 끝이고 영구히 만료되지 않습니다. 모든 요금제는 기기 수 제한이 없고 알리페이, 위챗, USDT를 지원하며, 가입에 이메일 주소가 필요 없고 사용자 이름과 비밀번호만 있으면 됩니다. 최초 결제 후 7일 이내에 무조건 환불을 신청할 수 있습니다.

이미 구매했다면 사용 가이드를 따라 가져오기 절차를 한 번 진행하고, 다시 돌아와 상황에 맞게 프로토콜을 고르세요. 서비스 자체의 성격과 원칙을 먼저 알고 싶다면 사이트 소개를 보세요.