회선과 프로토콜 기술 참고

01 · 계층

문제를 먼저 네 계층으로 되돌려 봅니다

같은 말이라도 「회선이 안 좋다」는 네 가지 전혀 다른 지점을 가리킬 수 있습니다. 이들을 분리해야 이후 판단이 서로 충돌하지 않습니다. 이 페이지는 선택 순서에 맞춰 정리한 기술 참고 자료입니다. 먼저 경로를 보고, 다음으로 프로토콜을 보고, 마지막으로 기기와 클라이언트를 봅니다. 처음 사용한다면 가이드 페이지의 기본 단계를 먼저 읽고 클라이언트를 설치해 연결해 보세요. 「왜 이렇게 선택하지?」「왜 빨랐다 느려졌다 하지?」 싶을 때 다시 이곳으로 돌아오면 됩니다.

네 계층이 각각 맡는 것

물리·라우팅 계층은 데이터가 로컬에서 출구까지 어떤 도시, 어떤 통신사, 어느 교환 지점을 거치는지 결정합니다. 지연의 하한을 정하고, 야간 피크에 어느 구간이 가장 먼저 줄을 서는지도 결정합니다. 클라이언트나 프로토콜을 바꿔도 이 계층의 경로는 바뀌지 않습니다.

전송 계층은 TCP 또는 QUIC(UDP)와 그 뒤의 혼잡 제어입니다. 손실이 생긴 뒤 어떻게 복구하는지, 윈도가 어떻게 커지는지, 여러 요청이 하나의 연결을 어떻게 공유하는지를 결정합니다. 체감상 「빨랐다 느려졌다」 하는 상당 부분이 이 계층에서 나옵니다.

프록시 프로토콜 계층은 Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 같은 이름들입니다. 인증 방식, 외부에 TLS를 두는지, 멀티플렉싱을 쓰는지, 추가 헤더가 얼마나 되는지를 결정합니다. 프로토콜은 물리 경로를 바꾸지 않지만 핸드셰이크 횟수, 재전송 전략, CPU 비용은 바꿉니다.

클라이언트·기기 계층에는 OS 버전, 권한, Wi-Fi 신호, 공유기 NAT 테이블, 절전 정책, DNS 설정, MTU가 포함됩니다. 이 계층이 가장 쉽게 간과되는데, 기기를 바꾸면 앞의 설정은 똑같아 보이는데 동작은 달라지기 때문입니다.

헷갈리기 쉬운 용어

노드는 접속 가능한 서버 또는 입구이고, 입구는 클라이언트가 먼저 연결하는 주소, 출구는 목표 사이트가 보는 주소, 착지는 출구가 위치한 지역입니다. 회선은 입구에서 출구까지의 경로 조합으로, 직결일 수도 있고 중계나 전용선을 거칠 수도 있습니다. 프로토콜은 클라이언트에서 입구까지 이 구간이 어떻게 통신하는지만 규정하며, 입구 이후에 어떤 길을 가는지는 회선이 결정합니다.

이 표는 위치를 좁히기 위한 것이며 실제 테스트를 대신하지 않습니다. 한 번에 변수 하나만 바꾸세요. 그러지 않으면 어느 항목이 효과를 냈는지 알 수 없습니다.

02 · 프로토콜

여섯 가지 프로토콜의 설계 트레이드오프

프로토콜은 브랜드가 아니고, 최신이라고 해서 항상 좋은 것도 아닙니다. 인증, 암호화, 전송, 멀티플렉싱에 관한 일련의 약속입니다. 아래에서는 설계 트레이드오프를 기준으로 설명하고 설정 코드는 붙이지 않습니다. 클라이언트마다 옵션 이름은 다를 수 있지만 판단 논리는 같습니다.

경량 포워딩형: Shadowsocks와 VLESS

Shadowsocks의 핵심은 단순함입니다. 사전 공유 키로 AEAD 암호화를 하고 TCP·UDP 요청을 출구로 전달합니다. 내장 멀티플렉싱도, 기본 제공 TLS 위장도 없지만 오버헤드가 작고 구현이 성숙해 공유기나 오래된 기기, 안정적인 포워딩만 필요한 상황에 적합합니다. 대가는 외부에서 보이는 특징이 뚜렷하지 않아 플러그인이나 중계로 보완해야 한다는 점이고, UDP 포워딩 가능 여부는 서버와 클라이언트 구현에 따라 다릅니다.

VLESS는 오히려 가벼운 전송 운반체에 가깝습니다. 자체적으로 암호화를 담당하지 않고 보안 경계를 외부 TLS나 REALITY에 넘깁니다. 프로토콜 헤더가 작고 상태가 적어 XTLS 계열 흐름 제어와 결합하면 중복 암호화를 줄일 수 있습니다. 장점은 높은 처리량과 낮은 CPU로 장시간 대용량에 적합하다는 것이며, 전제는 외부 설정이 올바르다는 것입니다. 외부에 신뢰할 수 있는 TLS가 없다면 VLESS가 알아서 암호화를 제공하지는 않습니다.

TLS 위장형: Trojan과 VMess

Trojan은 인증을 TLS 연결 안에 넣어 외부에서는 평범한 HTTPS 접속처럼 보입니다. 강도는 프로토콜 이름이 아니라 인증서, TLS 버전, 서버 설정에 달려 있습니다. 도메인과 인증서가 있고 일반 사이트와 입구를 공유해야 하는 상황에 적합하지만, 설정이 잘못되면 핸드셰이크 실패가 경량 프로토콜보다 찾기 어렵습니다.

VMess는 사용자 ID와 타임스탬프로 인증하고 요청 헤더에 필드가 많으며 멀티플렉싱을 지원합니다. 호환성이 좋아 예전 클라이언트에서도 쓸 수 있지만, 헤더 오버헤드와 구현 복잡도가 조금 높고 시스템 시간에 민감합니다. 기기 시간 오차가 크면 「설정은 맞는데 연결이 안 된다」는 상황이 생길 수 있습니다.

QUIC형: Hysteria2와 TUIC

Hysteria2는 QUIC(UDP) 기반으로 혼잡 제어를 더 공격적으로 운용해, 손실이 많고 RTT가 높은 링크에서 대역폭을 더 잘 끌어올립니다. 연결 마이그레이션을 지원해 스마트폰이 Wi-Fi에서 셀룰러로 넘어가도 연결을 완전히 다시 세우지 않아도 됩니다. 대가는 UDP 품질에 대한 민감도입니다. 로컬 네트워크나 통신사가 UDP를 제한하거나 손실이 크면 체감이 확 떨어지고, QUIC은 사용자 공간에서 처리되므로 CPU와 배터리 비용이 보통 경량 TCP 프로토콜보다 큽니다.

TUIC도 QUIC을 사용하며 0-RTT, 멀티플렉싱, 연결 마이그레이션을 강조해 네트워크를 자주 바꾸고 빠른 복구가 필요한 상황에 적합합니다. 비교적 최신이라 클라이언트별 구현 차이가 더 큽니다. 문제가 생기면 회선을 판단하기 전에 클라이언트 버전과 UDP 도달 가능 여부를 먼저 확인하세요.

선택할 때의 세 가지 오해

프로토콜 이름만 보고 외부 계층을 보지 않는 것. VLESS는 TLS가 없으면 암호화가 없고, Trojan의 강도는 인증서와 TLS 설정에 달려 있으며, Shadowsocks는 플러그인이 외부에서 어떻게 보일지를 결정합니다. 프로토콜 이름은 입구일 뿐이고 보안 경계는 외부 계층에 있습니다.

멀티플렉싱을 만능으로 여기는 것. 멀티플렉싱은 핸드셰이크를 줄이지만 하나의 TCP 연결 위에서 생기는 헤드오브라인 블로킹이 모든 스트림에 영향을 줍니다. QUIC의 멀티플렉싱은 TCP식 헤드오브라인 블로킹은 없지만 UDP 품질에 영향을 받습니다. 대화형 브라우징과 대용량 파일 다운로드에 적합한 연결 전략은 서로 다릅니다.

클라이언트 구현을 무시하는 것. 같은 프로토콜이라도 클라이언트마다 혼잡 제어, 버퍼, 로그 수준, 배터리 정책이 다릅니다. 「같은 회선인데 클라이언트를 바꾸니 정상」이라면 문제는 대개 프로토콜 자체가 아니라 구현에 있습니다.

03 · 핸드셰이크

연결 수립과 첫 패킷 시간

「웹페이지를 열려면 몇 초를 기다린다」와 「대용량 파일 다운로드가 느리다」는 다른 문제입니다. 전자는 대개 연결 수립에서 막히고, 후자라야 처리량을 봅니다. 첫 패킷 시간을 쪼개면 어느 구간이 느린지 빠르게 판단할 수 있습니다.

한 번의 접속에 핸드셰이크가 몇 번 필요한가

클라이언트가 먼저 DNS를 조회해 도메인을 IP로 바꾸고, 입구와 TCP 연결을 맺어 핸드셰이크를 마칩니다. 외부가 TLS라면 TLS 핸드셰이크를 하고, 이어서 프록시 프로토콜 자체의 인증과 요청 헤더가 붙습니다. 입구가 요청을 출구로 전달하고, 출구는 목표 사이트와 다시 DNS, TCP, TLS를 수행합니다. 사용자가 보는 「첫 패킷」은 이 단계들이 겹쳐진 결과입니다.

이 가운데 로컬 DNS와 입구까지의 RTT는 대개 짧고, 입구에서 출구, 출구에서 목표까지의 경로가 더 깁니다. 즉 첫 패킷이 느린 것이 반드시 입구까지가 느리다는 뜻은 아니며, 출구에서 목표까지 구간이 줄을 서 있을 수도 있습니다. 반대로 입구가 가까이 있고 출구도 목표 근처라면 첫 패킷은 눈에 띄게 짧아집니다.

연결 재사용과 0-RTT

브라우저와 클라이언트 모두 연결을 재사용합니다. HTTP/2는 하나의 TCP 위에서 여러 요청을, HTTP/3는 하나의 QUIC 연결 위에서 여러 스트림을 돌리고, 프록시 클라이언트도 여러 요청을 하나의 터널로 묶을 수 있습니다. 재사용은 핸드셰이크 횟수를 줄이지만 여러 스트림을 하나의 연결에 묶습니다. 하위에서 손실이 생기면 TCP에서는 모든 스트림이 재전송을 기다려야 하고, QUIC에서는 해당 스트림만 영향을 받습니다.

TLS 1.3과 QUIC은 세션 재개를 지원해 두 번째 연결에서 0-RTT로 데이터를 미리 보낼 수 있습니다. 실제로 왕복 한 번을 줄여 주지만 무조건 빠른 것은 아닙니다. 서버가 0-RTT 데이터를 거부할 수 있고, 일부 네트워크는 재전송 공격 보호를 더 신중하게 다룹니다. 0-RTT를 「무조건 더 빠름」으로 여기면 판단을 그르치기 쉽습니다.

시간, DNS, MTU

시간 동기화는 VMess의 타임스탬프 인증에 영향을 주고 TLS 인증서 유효기간 판정에도 영향을 줍니다. 기기 시간 오차가 크면 「설정은 맞는데 핸드셰이크가 실패」하는 형태로 나타납니다. 시스템 자동 시간을 켜 두는 것이 가장 간단한 점검입니다.

DNS는 첫 조회에 얼마나 기다려야 하는지, 그리고 어느 입구로 해석되는지를 결정합니다. 브라우저 자체 DoH가 시스템 DNS를 우회해 클라이언트와 브라우저가 다른 주소를 볼 수 있으니, 점검할 때는 누가 조회하고 있는지부터 확인하세요.

MTU는 캡슐화 후에도 통과할 수 있는 최대 패킷 길이입니다. 프록시는 원본 데이터 앞에 헤더를 한 겹 더 붙이므로, 경로 MTU가 작으면 큰 패킷이 버려져 「작은 페이지는 열리는데 큰 파일은 멈춘다」거나 「TLS 핸드셰이크는 끝나는데 데이터가 흐르지 않는다」는 형태로 나타납니다. 이런 문제는 흔히 회선이 느린 것으로 오판됩니다.

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

이 명령은 공개 예제 사이트 하나만 측정하며 계정 정보는 포함하지 않습니다. dns는 조회 시간, connect는 TCP 핸드셰이크, tls는 TLS 핸드셰이크, first는 첫 바이트, total은 전체 시간입니다. 여러 번 실행해 중간값을 보는 편이 한 번의 결과보다 참고 가치가 큽니다.

04 · 리소스

리소스 사용량과 모바일 배터리

프로토콜 비교에는 흔히 「경량」「고효율」이라고 적히지만 리소스 사용량은 단일 숫자가 아닙니다. 최소한 CPU, 메모리, 무선 모듈 깨우기 횟수, 배터리 정책이 포함됩니다. 같은 프로토콜이라도 데스크톱과 오래된 스마트폰에서 성능이 전혀 다를 수 있습니다.

CPU는 어디에 쓰이는가

첫째는 암호화입니다. AES 하드웨어 명령을 지원하는 기기에서는 AES-GCM 비용이 매우 낮고, 하드웨어 가속이 없으면 ChaCha20 같은 스트림 암호가 보통 더 저렴합니다. 둘째는 TLS로, 핸드셰이크, 인증서 검증, 레코드 계층 암복호화에 연산이 듭니다. 셋째는 QUIC으로, 사용자 공간에서 구현되어 혼잡 제어, 재전송, 스트림 관리를 포함하므로 커널의 TCP보다 CPU 비용이 큰 편입니다. 넷째는 멀티플렉싱과 로그로, 연결이 많을수록 로그가 상세할수록 비용이 커집니다.

따라서 「VLESS가 Trojan보다 가볍다」는 특정 외부 계층과 특정 클라이언트에서만 성립하고, 「Hysteria2가 약한 네트워크에서 빠르다」는 말도 모든 기기에서 배터리를 덜 쓴다는 뜻은 아닙니다. 판단할 때는 프로토콜 이름만이 아니라 전체 경로를 봐야 합니다.

배터리는 어디에 쓰이는가

모바일 배터리는 주로 암호화 연산이 아니라 무선 모듈의 깨우기 횟수에서 소모됩니다. 하트비트마다, 재연결마다, DNS 조회마다 셀룰러나 Wi-Fi 모듈이 저전력 상태에서 깨어납니다. 하트비트 간격이 너무 짧으면 기기가 자주 깨고, 너무 길면 NAT 타임아웃에 끊겨 다음 요청에서 연결을 다시 세워야 합니다. 클라이언트 기본값은 보통 절충안이므로 「항상 온라인」을 위해 하트비트를 매우 공격적으로 조정하는 것은 권장하지 않습니다.

네트워크 전환도 전력을 씁니다. 스마트폰이 Wi-Fi에서 셀룰러로, 다시 Wi-Fi로 넘어가면 TCP 연결이 끊길 수 있어 클라이언트가 재연결해야 합니다. QUIC의 연결 마이그레이션은 재수립을 줄여 주지만 마이그레이션 자체도 암호화 상태와 경로 검증을 처리해야 합니다. 절전 정책, 백그라운드 제한, 저전력 모드는 클라이언트가 백그라운드에서 연결을 유지할 수 있는지에 모두 영향을 줍니다.

기기와 상황에 맞춘 선택

VPNVL 월 구독은 기기 수 제한이 없어 여러 기기에서 동시에 사용할 수 있습니다. 다만 기기마다의 배터리와 성능은 별개의 문제이므로 서로 대체할 수 없습니다.

불필요한 소모를 줄이는 습관

첫째, 필요할 때만 분기하세요. 필요한 앱만 프록시를 타게 하고 나머지는 직결해 불필요한 암호화와 포워딩을 줄입니다. 둘째, 이중 프록시를 피하세요. 프록시 위에 프록시를 얹으면 패킷마다 암호화와 포워딩이 한 번 더 붙습니다. 셋째, 상세 로그는 꺼 두세요. 문제를 찾을 때만 켜고 평소에는 기본값을 유지합니다. 넷째, 「항상 켜기」를 유일한 목표로 삼지 마세요. 전원에 연결된 기기는 계속 켜 두어도 되지만 배터리 기기는 필요할 때 켜는 편이 낫습니다. 다섯째, 클라이언트를 주기적으로 업데이트하세요. 혼잡 제어, 재연결 전략, 배터리 최적화가 버전마다 개선되지만 무조건 최신을 쫓기보다 안정 버전을 우선하세요.

05 · 토폴로지

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

회선 토폴로지는 「입구에서 출구까지 어떻게 가는가」를 설명합니다. 프로토콜 이름보다 지연, 지터, 야간 피크 성능을 더 직접적으로 결정합니다. VPNVL 노드 페이지가 회선을 직결, 중계, IEPL 전용선 세 가지로 표기하는 이유가 여기에 있습니다.

직결: 경로는 가장 짧지만 연동 품질에 의존

직결은 클라이언트가 출구 노드에 바로 연결되는 방식으로, 입구와 출구가 같은 서버 또는 같은 데이터센터입니다. 장점은 경로가 짧고 핸드셰이크가 적으며 구현이 단순하다는 것이고, 단점은 중간 구간이 로컬 통신사와 목표 데이터센터 사이의 연동 품질에 전적으로 달려 있다는 점입니다. 연동이 좋으면 직결은 매우 깔끔하고, 연동이 나쁘거나 야간 피크에 줄을 서면 직결도 흔들립니다. 직결은 거리가 가깝고 목표 사이트와 출구 지역이 맞는 상황에 적합합니다.

중계: 한 홉을 더해 더 안정적인 중간 구간 확보

중계는 클라이언트가 먼저 입구에 연결하고, 입구가 트래픽을 중계 노드로 넘기며, 마지막으로 중계 노드가 출구로 전달합니다. 직결보다 홉이 하나 많아 이론적으로는 지연이 조금 늘지만, 중계 노드는 보통 연동이 더 좋은 위치에 있어 「로컬 통신사에서 국제 구간」까지를 품질을 더 통제할 수 있는 경로로 바꿀 수 있습니다. 중계의 가치는 최단이 아니라 안정성에 있습니다. 직결이 야간 피크에 흔들릴 때 중계가 더 매끄러운 경우가 많습니다.

중계에도 전제가 있습니다. 입구는 사용자와 가까워야 하고, 중계 구간은 대역폭이 충분해야 하며, 출구는 목표 사이트의 요구를 충족해야 합니다. 어느 한 구간이 혼잡하면 장점이 상쇄됩니다. 그래서 「중계」는 고정된 품질이 아니라 하나의 경로 설계입니다.

전용선: 고정 통로, 안정성 우선

IEPL 전용선은 입구와 출구 사이에 비교적 고정된 통로를 사용해 일반 트래픽과 같은 공용 연동 구간을 두고 경쟁하지 않습니다. 장점은 지터가 작고 야간 피크에 더 안정적이라는 것이며, 장시간 회의, 해외 업무, 끊김에 민감한 업무에 적합합니다. 대가는 비용이 더 높다는 점이고, 게다가 「입구에서 출구」 구간만 덮습니다. 사용자 집의 Wi-Fi, 로컬 통신사, 목표 사이트는 전용선 범위 밖입니다.

그래서 전용선은 마법이 아닙니다. 집의 회선이 이미 혼잡하거나 Wi-Fi 신호가 나쁘면 전용선도 마지막 구간을 구해 주지 못합니다. 올바른 기대는 전용선이 중간 구간의 불확실성을 낮춰 문제를 로컬과 목표 양쪽으로 좁혀 주어 점검이 쉬워진다는 것입니다.

같은 회선이 도시마다 다르게 느껴지는 이유

「마지막 1마일」이 다르기 때문입니다. 통신사, 단지, 접속 방식이 다르면 같은 입구까지의 경로와 연동 품질도 달라지고, 같은 도시에서도 광랜과 이동통신의 결과가 반대로 나올 수 있습니다. 노드 페이지가 제공하는 것은 회선 유형과 커버 지역이며, 사용자 집마다의 보장 값이 아닙니다. 회선을 고를 때는 입구가 가까운지 먼저 보고, 중간 구간이 안정적인지 다음으로 보고, 마지막으로 출구가 목표 사이트의 지역 요구를 충족하는지 확인하세요.

06 · 혼잡

손실과 야간 피크 혼잡

지연, 지터, 손실, 처리량은 서로 다른 네 가지 지표입니다. 지연은 데이터가 한 번 가는 데 걸리는 시간, 지터는 지연의 변동, 손실은 패킷이 도착하지 않는 것, 처리량은 단위 시간에 보낼 수 있는 양입니다. 야간 피크에 가장 흔한 것은 「서버 고장」이 아니라 어느 구간이 줄을 서면서 지연이 오르고 손실이 늘고 처리량이 떨어지는 현상입니다.

손실이 왜 모든 것을 느리게 만드는가

TCP는 손실을 혼잡 신호로 해석합니다. 손실이 감지되면 혼잡 윈도를 줄여 전송 속도를 낮추고, 이후 천천히 다시 올립니다. 링크 RTT가 길수록 회복이 느리고, 손실이 잦을수록 윈도가 좀처럼 커지지 않습니다. QUIC도 재전송하지만 스트림을 따로 처리해 한 스트림의 손실이 모든 스트림을 기다리게 하지는 않습니다. 다만 UDP가 제한되거나 손실이 심한 네트워크에서는 QUIC의 장점도 상쇄됩니다.

그래서 「1% 손실」이 업무마다 미치는 영향은 전혀 다릅니다. 실시간 음성은 가끔 끊기는 정도일 수 있지만 대용량 다운로드는 속도가 눈에 띄게 떨어지고, 대화형 웹은 「한 번 누르면 한참 기다린다」로 나타납니다. ping 결과 하나로 전체 체감을 요약하지 마세요.

야간 피크의 흔한 원인

첫째, 국제 구간 혼잡입니다. 야간 피크에는 해외 트래픽이 몰려 공용 연동에 줄이 서고 지연과 손실이 함께 올라갑니다. 둘째, 가정의 업로드 대역이 꽉 차는 경우입니다. 가족이 영상을 보거나 백업을 올리거나 업데이트를 받으면 공유기 큐가 길어집니다. 셋째, Wi-Fi 간섭입니다. 이웃 채널과 겹치거나 거리가 멀거나 벽이 막으면 손실과 지터로 나타납니다. 넷째, 공유기 NAT 테이블이나 세션 수가 빠듯한 경우입니다. 오래된 기기는 연결이 많아지면 느려집니다. 다섯째, MTU 불일치입니다. 큰 패킷이 버려지고 작은 패킷은 정상입니다. 여섯째, UDP 제한입니다. QUIC 계열 프로토콜이 일부 네트워크에서는 오히려 TCP보다 못합니다.

자주 간과되는 경우가 하나 더 있는데 버퍼 팽창입니다. 공유기 버퍼가 커서 큐가 길어져도 패킷은 버려지지 않아 속도 측정은 괜찮게 나오는데 체감은 매우 답답합니다. 이런 문제는 공유기의 큐 관리나 속도 제한으로 완화해야 하며 프로토콜을 바꿔도 도움은 제한적입니다.

야간 피크 혼잡인지 판단하는 방법

먼저 시간을 기록하세요. 19:00부터 23:00에만 나빠지고 낮에는 정상이라면 공유 링크 혼잡에 가깝고, 하루 종일 나쁘면 로컬 네트워크, 입구 선택, 기기 문제에 가깝습니다. 다음으로 변수를 바꿉니다. 같은 시간에 회선 유형을 바꿔 중계나 전용선이 확실히 안정적이라면 문제는 중간 구간에 있습니다. 모든 회선이 똑같다면 로컬을 먼저 확인하세요. 그다음 매체를 바꿉니다. 유선과 Wi-Fi를 비교해 무선 간섭을 배제합니다. 마지막으로 프로토콜을 바꿉니다. TCP와 QUIC을 각각 한 번씩 시험해 UDP 제한 여부를 판단합니다.

점검할 때 시스템에 내장된 네트워크 진단이나 경로 추적 도구로 경로가 바뀌는지 볼 수 있지만, 한 번의 ICMP 지연을 결론으로 삼지 마세요. ICMP는 제한되거나 다른 큐를 탈 수 있어 참고용일 뿐입니다. 더 중요한 것은 「같은 시간대, 같은 대상, 다른 회선」의 비교입니다. 현재 출구 주소를 확인해야 한다면 네트워크 진단 페이지에서 볼 수 있습니다.

07 · 선택

상황별 프로토콜과 회선 선택

모든 상황에 맞는 설정은 없습니다. 권장 순서는 회선을 먼저 정하고, 프로토콜을 다음으로 정하고, 마지막으로 클라이언트를 조정하는 것입니다. 회선은 경로와 안정성을, 프로토콜은 핸드셰이크와 비용, 약한 네트워크 성능을, 클라이언트는 그 능력을 얼마나 끌어낼 수 있는지를 결정합니다.

AI 도구와 장시간 연결

ChatGPT, Claude, Gemini 같은 도구의 공통점은 「하나의 연결을 오래 유지하면서 스트리밍 응답을 계속 받는다」는 것입니다. 첫 패킷에 극도로 민감하지는 않지만 도중에 끊기거나 재인증하는 것에는 민감합니다. 선택할 때는 안정성을 우선하세요. 중계나 전용선 + Trojan/VLESS over TLS로 연결 재수립을 줄이고, 대화 도중에 노드를 자주 바꾸지 마세요. 출구 지역은 서비스 요구에 맞아야 하며 그렇지 않으면 지역 제한을 만날 수 있습니다. 자세한 내용은 ChatGPT용 VPN 추천 글에서 다룹니다.

스트리밍과 4K

스트리밍에서 중요한 것은 지속 처리량과 출구 IP의 신뢰도입니다. 직결도 중계도 괜찮지만 핵심은 출구 지역이 대상 플랫폼과 맞고 회선이 야간 피크에 충분한 여유를 갖는 것입니다. Hysteria2는 손실이 많은 링크에서 더 안정적일 수 있지만 플랫폼이 UDP나 데이터센터 IP를 제한한다면 TCP 계열로 돌아가는 편이 간단합니다. VPNVL의 지원 지역 페이지에 플랫폼별 사용 가능 지역이 정리되어 있으니 고르기 전에 대조해 보세요.

해외 업무와 회의

회의는 지터에 가장 민감하고 절대 지연에는 상대적으로 덜 민감합니다. IEPL 전용선의 가치가 여기서 가장 뚜렷합니다. 고정 통로가 큐를 줄여 장시간 연결이 끊기지 않습니다. 프로토콜은 TCP 계열인 Trojan이나 VLESS를 고르고, 클라이언트 분기로 사내망과 로컬 서비스를 프록시에서 제외해 불필요한 포워딩을 줄이세요. 출장 상황이라면 출장 VPN 추천의 사용량 추정과 체크리스트를 참고하세요.

모바일과 게임

스마트폰은 Wi-Fi와 셀룰러를 자주 오가므로 연결 마이그레이션을 지원하는 QUIC 프로토콜이 편합니다. 다만 UDP 제한 여부가 불확실하다면 TCP 대안을 하나 준비하세요. 게임은 지연과 지터를 보므로 입구는 가까운 곳, 출구는 게임 서버와 같은 지역을 고르고 유선이나 5GHz Wi-Fi를 우선하며 백그라운드 다운로드를 동시에 돌리지 마세요.

예산과 요금제를 어떻게 조합할까

선택은 클라이언트 안에서만 일어나지 않고 구매할 때도 일어납니다. VPNVL 월 구독은 개통일 기준으로 매월 트래픽이 초기화됩니다. ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이고, 트래픽 팩은 다 쓰면 끝나지만 영구히 만료되지 않으며 ¥158/300GB, ¥358/1000GB, ¥658/3000GB입니다. 사용량이 일정하면 월 구독, 사용량이 들쭉날쭉하거나 여유를 두고 싶다면 트래픽 팩을 조합하세요. 예산이 빠듯하다면 10위안대에서 무엇을 살 수 있는지를 먼저 보고 조합 방식을 정하세요.

언제 서비스 업체를 바꿔야 하는가

모든 회선, 모든 프로토콜, 모든 기기가 같은 시간에 사용할 수 없다면 로컬 네트워크와 계정 상태를 먼저 확인하세요. 특정 회선만 오랫동안 불안정하면 회선을 바꾸고, 특정 프로토콜만 특정 네트워크에서 안 되면 프로토콜을 바꾸세요. 모든 회선이 야간 피크에만 장기간 혼잡하고 다른 시간대는 정상일 때에야 업체의 용량을 고려하면 됩니다. 「업체를 바꾼다」를 첫 반응으로 삼으면 더 간단한 해결을 놓치기 쉽습니다.

08 · 점검

계층별 점검 절차

점검의 목표는 「모든 설정을 다 시험해 보는 것」이 아니라 최소한의 변수로 문제를 찾는 것입니다. 아래 다섯 단계를 순서대로 진행하며 각 단계마다 기록을 남기세요. 다섯 단계 후에도 해결되지 않으면 「연결이 안 된다」 한마디보다 기록을 가지고 지원에 문의하는 편이 훨씬 효과적입니다.

1. 범위를 정합니다. 기기 하나인지 모든 기기인지, 사이트 하나인지 모든 사이트인지, 하루 종일인지 야간 피크인지. 이 세 질문에 답하면 문제는 이미 절반으로 줄어듭니다.
2. 로컬을 확인합니다. 유선과 Wi-Fi를 각각 한 번씩 시험하고, 시스템 시간 자동 동기화를 확인하고, 프록시를 두 개 동시에 켜 두지 않았는지, DNS가 브라우저나 보안 소프트웨어에 의해 바뀌지 않았는지, 공유기 업로드가 꽉 차지 않았는지 확인합니다.
3. 변수는 하나만 바꿉니다. 회선을 먼저 바꾸고, 다음 프로토콜, 다음 기기 순으로 바꿉니다. 바꿀 때마다 결과를 기록하세요. 회선, 프로토콜, DNS를 동시에 바꾸면 어느 항목이 효과를 냈는지 알 수 없습니다.
4. 로그를 봅니다. 클라이언트 로그의 핸드셰이크 실패, DNS 타임아웃, TLS 오류, 연결 재설정은 「안 열린다」보다 정보량이 많습니다. 스크린샷을 찍거나 로그를 복사하기 전에 구독 주소와 토큰은 먼저 가리세요.
5. 정보를 갖고 도움을 요청합니다. 시간, 기기와 OS, 회선 이름, 프로토콜, 오류 메시지, 이미 시도한 단계. 정보가 구체적일수록 찾는 속도가 빠릅니다.

흔한 증상과 대처

연결은 되는데 웹페이지가 열리지 않음. 먼저 DNS를 보세요. 브라우저 자체 DoH가 클라이언트를 우회할 수 있습니다. 다음으로 시스템 프록시가 절반만 켜져 있지 않은지, 마지막으로 MTU를 봅니다. 특히 작은 페이지는 열리고 큰 페이지에서 멈추는 경우입니다.

특정 앱만 안 됨. 분기 규칙에서 이 앱이 제외되어 있는지 확인하세요. 일부 앱은 인증서 피닝을 사용해 프록시 인증서를 받지 않고, 일부 앱은 UDP만 사용하는데 현재 회선의 UDP가 불가능할 수 있습니다.

자주 끊김. 스마트폰 절전 정책, Wi-Fi 로밍, NAT 타임아웃, 하트비트 간격이 모두 원인이 될 수 있습니다. 절전 제한을 먼저 끄고 네트워크를 바꿔 비교하세요. 이동통신에서만 끊긴다면 연결 마이그레이션 능력이 더 좋은 프로토콜을 우선 고려하세요.

속도가 느림. 첫 패킷이 느린지 처리량이 낮은지 먼저 구분하고, 기기 CPU가 꽉 찼는지, Wi-Fi 신호와 공유기는 어떤지 확인한 다음 회선 유형을 바꾸세요. 프로토콜 이름만 붙들고 있지 마세요.

보안과 개인정보 경계

점검할 때 구독 주소, 토큰, 전체 로그를 공개 그룹이나 스크린샷에 그대로 올리지 마세요. VPNVL은 로그를 기록하지 않지만 구독 주소 자체가 접속 자격 증명입니다. 비밀번호처럼 다루세요. 도움이 필요할 때는 회선 이름, 프로토콜, 오류 유형, 시간만 제공하고 자격 증명은 제공하지 마세요.

자주 묻는 질문