회선과 프로토콜: 기술 선택 가이드

6가지 프로토콜의 설계 차이

이 6가지 프로토콜은 클라이언트에서 보통 나란히 선택지로 놓입니다. 신형이 구형을 대체하는 관계가 아니라 서로 다른 제약에 맞춘 서로 다른 선택입니다. 어떤 것은 오버헤드를 최소로 줄였고, 어떤 것은 호환성을 최대로 끌어올렸고, 어떤 것은 패킷 손실 환경을 위해 설계되었습니다. '어느 것이 더 강한가'를 외우는 것보다 차이를 이해하는 편이 훨씬 쓸모 있습니다.

Shadowsocks: 가볍고 직접적

Shadowsocks의 설계 목표는 단순합니다. 최소한의 오버헤드로 TCP와 UDP 트래픽을 암호화해 전달하는 것입니다. 사전 공유 키로 세션 키를 유도하고 패킷마다 AEAD 암호화를 적용하며, 복잡한 인증 핸드셰이크를 내장하지 않고 서버 측 사용자 체계도 없습니다. 그 결과 첫 패킷 오버헤드가 작고 서버 자원 사용량이 낮아, 한 사람이나 소수 기기 사용에 적합합니다. 대가는 위장 계층이 없다는 점입니다. 트래픽 형태가 그대로 암호화된 TCP 스트림이라 일반 TLS 웹 트래픽과 다릅니다. 추가 TLS 계층이 필요할 때는 보통 클라이언트 플러그인이나 외부 포워딩으로 처리합니다.

VMess: 사용자 체계를 갖춘 캡슐화

VMess는 프로토콜 헤더에 사용자 식별자와 타임스탬프를 담고, 서버는 이를 근거로 요청이 유효한지, 어느 사용자의 것인지 판단합니다. 덕분에 다중 사용자·다중 기기 환경에 자연스럽게 맞습니다. 같은 입구에서 사용자별로 분기하고 각각 사용량을 셀 수 있습니다. 대가는 헤더가 Shadowsocks보다 조금 크다는 점, 그리고 시간에 민감하다는 점입니다. 클라이언트와 서버의 시간 차이가 허용 범위를 넘으면 아예 연결되지 않아 '노드 테스트 시간 초과'처럼 보이지만 네트워크 자체는 정상입니다. 이런 메시지가 뜨면 먼저 기기 시간을 자동 동기화로 설정한 뒤 다시 시도하세요.

Trojan: 표준 TLS를 타는 쪽

Trojan은 인증 정보를 TLS 핸드셰이크 이후의 애플리케이션 데이터에 넣고, 포트는 보통 443을 씁니다. 핸드셰이크 과정은 HTTPS 사이트에 접속할 때와 다르지 않습니다. 장점은 호환성입니다. 중간 장비가 보는 것은 표준 TLS 연결 하나입니다. 대가는 인증서와 도메인을 유지해야 한다는 점입니다. 인증서가 만료되거나 교체되면 곧바로 연결 실패로 이어집니다. TLS 핸드셰이크 자체도 왕복 한 번의 오버헤드를 더하므로 첫 패킷 지연은 순수 TCP를 쓰는 Shadowsocks보다 약간 높습니다.

VLESS: 암호화를 TLS에 맡기기

VLESS는 프로토콜 자체의 암호화 계층을 없애고 가벼운 헤더와 인증만 남겼으며, 암호화는 전적으로 외부 TLS나 REALITY에 맡깁니다. 장점은 서버 CPU 사용량이 더 적고 헤더가 더 짧아 고처리량 환경에서 대역폭을 채우기 쉽다는 것입니다. 단점은 신뢰할 수 있는 외부 계층이 반드시 필요해 단독으로는 의미가 없다는 점입니다. 일반 사용자라면 VLESS와 Trojan의 체감 차이는 대개 회선 차이보다 작으므로 이 때문에 계속 갈아탈 필요는 없습니다.

Hysteria2: 패킷 손실 환경을 위해 설계

Hysteria2는 QUIC 기반으로 UDP 위에서 동작하며 혼잡 제어와 대역폭 협상을 자체적으로 갖추고 있습니다. 강점은 높은 패킷 손실과 장거리 링크입니다. TCP는 이런 링크에서 손실이 생길 때마다 혼잡 윈도를 줄였다가 다시 늘리지만, Hysteria2는 사용자 영역에서 더 적합한 알고리즘으로 처리량을 유지할 수 있습니다. 대가는 세 가지입니다. UDP가 일부 네트워크에서 속도 제한을 받거나 아예 버려질 수 있고, 이동통신망 전환 시 연결을 다시 맺어야 하며, UDP 계열 트래픽은 MTU에 더 민감해서 단편화 설정이 틀리면 '연결은 되는데 큰 파일이 전송되지 않는' 형태로 나타납니다.

TUIC: QUIC 위의 다중화

TUIC도 QUIC 기반이며 다중화와 연결 마이그레이션에 초점을 둡니다. 하나의 QUIC 연결 안에서 여러 요청을 병렬로 처리하고, 한 요청의 패킷 손실이 다른 요청을 막지 않습니다. Wi-Fi에서 셀룰러로 전환할 때 QUIC의 연결 식별자 덕분에 세션을 이어갈 수 있어 다시 핸드셰이크할 필요가 없습니다. 적용 상황은 Hysteria2와 비슷하고, 차이는 주로 클라이언트의 혼잡 제어 구현에서 나옵니다. 마찬가지로 UDP 사용 가능 여부에 묶여 있어, 네트워크가 UDP를 허용하지 않으면 둘 다 쓸 수 없습니다.

하나만 기억한다면: TCP 계열 프로토콜의 '얼마나 안정적인가'의 하한은 회선이 정하고, UDP 계열 프로토콜은 '패킷이 유실될 때도 굴러가는가'를 정합니다. 프로토콜을 고르기 전에 회선을 먼저 보세요. 순서가 뒤바뀌면 잘못된 축에서 계속 시도하게 됩니다. 피크 시간대에 혼잡한 직결 회선을 Trojan에서 VLESS로, 다시 Hysteria2로 바꿔 봐도 체감은 대개 본질적으로 달라지지 않습니다.

연결 수립 속도와 리소스 사용량

웹페이지가 느리게 열리면 대부분 대역폭이 부족하다고 생각합니다. 실제로 더 흔한 원인은 왕복 횟수입니다. 새 연결을 맺을 때마다 핸드셰이크를 거치고, 핸드셰이크에는 왕복이 필요하며, 왕복 시간은 물리적 거리와 경로 품질이 결정합니다. 대역폭은 '얼마나 빨리 전송되는가'를, 왕복은 '얼마나 빨리 전송이 시작되는가'를 결정합니다.

완전한 TCP + TLS 연결은 대략 이렇게 진행됩니다. 먼저 도메인을 해석하고(왕복 한 번일 수 있음), TCP 3방향 핸드셰이크(왕복 한 번), TLS 1.3 핸드셰이크(왕복 한 번, 세션 재사용 시 생략 가능), 그다음 프로토콜 자체 인증, 마지막에야 HTTP 요청입니다. 즉 도메인 하나를 콜드 스타트하는 데 최소 몇 번의 왕복이 필요하고, 페이지가 서로 다른 도메인을 여러 개 참조하면 그만큼 반복됩니다. '대역폭은 큰데 첫 화면이 느린' 상황이 드물지 않은 이유입니다.

QUIC은 전송 핸드셰이크와 TLS 핸드셰이크를 합쳐 첫 연결에 왕복 한 번, 세션 복구 시에는 0회 왕복으로 데이터까지 실어 보냅니다. UDP 계열 프로토콜이 '웹페이지를 여는 첫 순간' 더 빠르게 느껴지는 주된 이유이며 대역폭과는 무관합니다. 대가는 UDP가 네트워크에서 제한되면 그 경로를 아예 쓸 수 없고 대체 수단이 없다는 점입니다.

리소스 사용량은 양쪽으로 나눠 봅니다. 클라이언트 쪽에서는 암·복호화가 주요 CPU 비용입니다. AES 계열은 하드웨어 가속을 지원하는 프로세서에서 비용이 매우 낮고, 일부 모바일 프로세서에서는 ChaCha20이 더 효율적입니다. 서버 쪽에서는 동시 연결 수에 연결당 메모리를 곱한 값과, UDP 계열 프로토콜이 유지해야 하는 세션 테이블이 주요 비용입니다. 다중화는 연결 수를 줄여 주지만 그만큼 한 연결에서 유지할 상태가 늘어나므로, 메모리를 내주고 왕복을 얻는 거래입니다.

놓치기 쉬운 점이 하나 있습니다. 클라이언트의 '지연 테스트'는 입구까지의 탐사 왕복을 재는 것이지 착지점까지의 왕복도, 웹페이지 로딩 시간도 아닙니다. 입구가 가깝고 착지점이 멀면 테스트 숫자는 좋아 보이지만 실제 페이지는 여전히 느립니다. 실제 체감을 판단하려면 그 숫자 하나가 아니라 전체 로딩과 영상 버퍼링을 봐야 합니다.

모바일 배터리와 트래픽 사용량

스마트폰에서 전력이 소모되는 지점은 세 곳입니다. 무선 모듈이 반복해서 깨어나는 것, 암·복호화가 CPU를 쓰는 것, 연결이 끊겼다가 다시 맺어지는 것입니다. 세 가지 모두 프로토콜과 회선에 관련되지만 비중은 다릅니다. 많은 사람이 '암호화가 전기를 많이 먹는다'고 생각하지만, 실제로 가장 흔한 소모 원인은 하트비트와 재연결입니다.

먼저 하트비트를 봅니다. 네트워크 주소 변환 테이블 항목이 만료되지 않도록 클라이언트는 주기적으로 작은 패킷을 보내 연결을 유지합니다. 간격이 너무 짧으면 무선 모듈이 유휴 상태에서 자주 깨어나 전력 소모가 커지고, 너무 길면 중간 장비가 연결을 회수해 다음 사용 시 재연결이 필요하며 그때 다시 전체 핸드셰이크가 일어납니다. 적절한 간격은 사용 중인 네트워크의 테이블 만료 시간에 따라 다릅니다. 가정용 회선, 회사 네트워크, 통신사 네트워크가 각각 다르므로 클라이언트는 보통 보수적인 기본값을 제공하고 조정 항목을 함께 둡니다. 확신이 없으면 기본값을 쓰고, 눈에 띄게 이상할 때만 조정하세요.

다음은 재연결입니다. 모바일 환경에서 가장 비싼 동작이 재연결입니다. Wi-Fi에서 셀룰러로 바뀌거나, 엘리베이터를 드나들거나, 지하철 터널을 지날 때마다 발생합니다. TCP 계열 프로토콜은 네트워크가 바뀌면 반드시 다시 핸드셰이크해야 합니다. QUIC 계열은 연결 식별자로 세션을 옮길 수 있지만, 새 경로에 도달할 수 있고 중간 장비가 UDP를 막지 않는다는 전제가 필요합니다. 그래서 '모바일에서는 UDP 계열이 전기를 덜 먹는다'는 말은 일정 조건에서만 성립합니다. 전환이 잦고 UDP가 사용 가능할 때는 성립하지만, 반대라면 재연결이 더 많아져 오히려 전력을 더 씁니다.

시스템의 백그라운드 제한도 계산에 넣어야 합니다. iOS와 Android 모두 화면이 꺼진 뒤 일정 시간이 지나면 백그라운드 앱을 정지시키고, 클라이언트가 정지되면 연결은 자연히 끊깁니다. 이는 프로토콜 문제가 아니며 어떤 프로토콜이든 마찬가지입니다. 오래 상시 접속이 필요한 상황에서는 클라이언트가 계속 돌아가며 기다리게 하는 대신, 시스템의 주문형 연결 기능을 써서 네트워크가 바뀔 때 시스템이 클라이언트를 깨우도록 해야 합니다.

트래픽 사용량 측면에서 프로토콜 헤더 자체가 차지하는 비중은 아주 작고, 실제 사용량에 영향을 주는 것은 재전송과 하트비트입니다. 패킷 손실이 심한 회선에서는 재전송 때문에 실제 소비량이 예상보다 훨씬 커집니다. 하트비트 패킷은 작지만 하루에 수백 번이면 무게가 됩니다. 트래픽 패키지를 사용량 기준으로 과금할 때 이 두 항목을 눈여겨볼 만합니다. VPNWu의 트래픽 패키지는 다 쓸 때까지 유효하며 영구히 만료되지 않고, 월 구독의 트래픽은 개통일 기준으로 매달 초기화됩니다. 두 과금 방식 모두 클라이언트에서 실제 사용량을 한 번 확인해 자신의 예상과 맞춰 보길 권합니다.

자체 점검 방법입니다. 시스템 기본 배터리 사용량 통계로 '연결 상태에서 일정 시간 대기'와 '연결하지 않은 상태에서 같은 시간 대기'의 소모 차이를 비교하고, 클라이언트 연결 로그에서 그 시간 동안 재연결이 몇 번 있었는지 세어 봅니다. 재연결이 많다면 프로토콜을 바꾸는 것보다 회선 유형을 바꾸는 편이 대개 더 효과적입니다. 먼저 경로를 안정시키고 나서 캡슐화 방식을 논하는 순서입니다.

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

회선은 이 페이지에서 체감에 가장 큰 영향을 주면서도 가장 적게 논의되는 부분입니다. 프로토콜은 캡슐화 방식을 정하고, 회선은 데이터가 실제로 어느 길로 가는지를 정합니다. 같은 가정용 회선이라도 어떤 회선에 붙느냐에 따라 피크 시간대 경험이 한 단계씩 달라지는데, 클라이언트의 프로토콜 옵션은 하나도 바뀌지 않습니다.

직결

직결은 입구와 착지점이 같은 곳에 있어 데이터가 사용자 쪽에서 착지 데이터센터로 곧장 도달하는 방식입니다. 경로가 가장 짧아 이론상 지연이 가장 낮습니다. 약점은 품질이 이 공용 링크의 상태에 전적으로 달려 있다는 점입니다. 피크 시간대에 혼잡해지면 직결 회선도 일반 해외 접속과 함께 줄을 서므로 지터가 눈에 띄게 커집니다. 직결은 지연에 민감하지만 피크 시간대 안정성까지 요구하지는 않는 상황, 예를 들어 낮 시간 업무나 잠깐의 자료 조회에 적합합니다.

중계

중계는 사용자와 착지점 사이에 입구 노드를 하나 더 둡니다. 사용자는 먼저 자신과 가까운 입구에 연결되고, 입구가 서비스 제공자의 자체 링크를 통해 트래픽을 착지점으로 보냅니다. 홉이 하나 늘어 이론상 몇 밀리초가 더 붙지만, 가는 구간이 품질을 더 통제할 수 있는 링크로 바뀌기 때문에 피크 시간대 지터는 대개 직결보다 작습니다. 중계형 회선 간의 차이는 주로 중계 노드의 대역폭과 스케줄링 정책에서 나오며, 고를 때 봐야 할 것은 노드 개수가 아니라 운영 측의 용량입니다.

전용 회선

전용 회선은 입구에서 착지점까지 점대점 전용 채널을 지나며 공용 인터넷 트래픽과 혼잡을 공유하지 않습니다. 특징은 안정적인 지연, 작은 지터, 낮은 패킷 손실률이고, 대가는 높은 비용이라 보통 인기 착지점에만 배치됩니다. 화상 회의, 실시간 협업, 장시간 안정 연결 같은 상황에서 전용 회선의 가치는 최대 대역폭이 아니라 '피크 시간대에도 흔들리지 않는다'는 데 있습니다. 가끔 영상만 본다면 전용 회선의 개선이 체감되지 않을 수 있습니다.

회선을 고르는 순서는 이렇게 권합니다. 먼저 착지 지역을 정하고(콘텐츠와 서비스가 어디에 있는지), 다음으로 회선 유형을 정하고(피크 시간대에도 안정적이어야 하는지), 마지막에 프로토콜을 정합니다. 반대로 프로토콜부터 고르면 이미 혼잡한 회선 위에서 캡슐화만 계속 바꾸게 되어 시간만 쓰고 효과는 없습니다. 회선 페이지의 각 회선에는 유형 라벨이 붙어 있고, 그 라벨이 위의 세 가지 중 하나를 가리킵니다. '중계'를 '한 바퀴 더 돌아서 더 느리다'고 이해하지 마세요. 중계가 최적화하는 것은 가는 구간입니다.

패킷 손실과 피크 시간대 혼잡의 원인

패킷 손실은 고장이 아니라 일상입니다. 링크 어느 구간이든 큐가 가득 차면 뒤에 온 패킷이 버려지고, 무선 환경에서는 간섭도 손실을 만듭니다. 문제는 손실이 있느냐 없느냐가 아니라, 손실이 어느 구간에서 얼마나 오래 발생하고 프로토콜이 그것을 어떻게 처리하느냐입니다.

흔한 원인은 네 가지입니다. 로컬 무선: Wi-Fi 간섭, 거리, 채널 혼잡으로 모든 회선이 느려지며 회선을 바꿔도 소용없습니다. 가정용 회선의 업로드: 업로드가 꽉 차면 확인 패킷이 나가지 못해 다운로드도 영향을 받고, 다운로드 중 끊기는 형태로 나타납니다. 국제 링크 피크: 저녁 시간대에 해외 방향 트래픽이 몰려 공용 링크에 줄이 생기고, 특정 시간대에 느려지다 다른 시간대에는 정상입니다. 착지 데이터센터 출구: 착지 측 대역폭이 포화되어 특정 회선만 느리고 같은 지역의 다른 회선은 정상입니다.

TCP는 패킷 손실에 매우 민감하게 반응합니다. 손실을 감지하면 혼잡 윈도를 절반으로 줄이고 다시 천천히 늘립니다. 짧은 연결이 가장 큰 영향을 받습니다. 웹페이지 하나의 요청 십여 개가 한 연결에 몰려 있으면 손실 한 번에 연결 전체가 재전송을 함께 기다립니다. QUIC은 이 문제를 스트림 단위로 쪼갭니다. 한 스트림에서 손실이 나도 다른 스트림은 그대로 진행되므로, UDP 계열 프로토콜이 손실 환경에서 체감이 더 매끄러운 것입니다.

피크 시간대의 양상은 '아예 못 쓴다'가 아니라 지연 상승, 지터 확대, 영상 자동 화질 저하입니다. 이 시간대에 가장 효과적인 방법은 프로토콜을 바꾸는 것이 아니라 회선 유형을 바꾸는 것(직결에서 중계나 전용으로)입니다. 병목이 캡슐화가 아니라 경로의 혼잡에 있기 때문입니다. 프로토콜을 바꾸는 것은 줄 서는 방식만 바꿀 뿐이고 줄 자체는 짧아지지 않습니다.

계층별 점검 순서

가까운 곳에서 먼 곳으로: 먼저 로컬 게이트웨이가 안정적인지, 다음으로 입구에 도달할 수 있는지, 마지막으로 착지점을 봅니다. 세 구간 중 어디서 지속적인 손실이 시작되는지가 문제 지점입니다. 명령줄의 mtr은 각 홉의 손실을 나열해 주며, 한 번 돌리는 것보다 수십 번 연속으로 돌리는 편이 훨씬 의미 있습니다.

# 1. 먼저 로컬 게이트웨이가 안정적인지 확인(예시 주소를 자신의 공유기 주소로 교체)
ping -c 20 192.168.1.1

# 2. 다음으로 해외 경로 각 홉의 손실과 지연 확인, 50회 연속 샘플링
mtr -rwzc 50 example.com

# 3. 다른 회선으로 위 두 단계를 반복해 같은 시간대의 차이 비교

샘플링 방법도 통일해야 합니다. 같은 시간대, 같은 대상, 최소 세 라운드, 라운드당 50회로 하고 평균값, 최댓값, 손실률을 기록합니다. 한 번의 결과만 보면 순간적인 지터에 속기 쉽습니다. 서로 다른 시간대의 두 회선을 그대로 비교해서도 안 됩니다. 피크 시간대와 새벽 사이의 차이가 두 회선 사이의 차이보다 클 수 있습니다.

사용 상황별 프로토콜 선택

앞 장들은 나눠서 설명했고, 이 장은 그것을 합쳐 씁니다. 선택 순서는 상황 → 회선 유형 → 프로토콜 → 클라이언트 설정입니다. 순서가 뒤바뀌면 단순한 문제가 복잡해집니다. 예를 들어 특정 프로토콜을 쓰기로 정한 뒤 그 프로토콜을 돌릴 수 있는 회선을 찾고, 마지막에 그 회선이 피크 시간대에 버티지 못한다는 것을 알게 됩니다.

웹과 업무

웹 브라우징의 특징은 짧은 연결이 많다는 것입니다. 페이지 하나에 연결이 십여 개 열리고 각각 핸드셰이크를 합니다. 이때는 최대 대역폭보다 첫 패킷 지연이, 최고 속도보다 회선의 왕복 시간이 중요합니다. 프로토콜 측면에서는 헤더 오버헤드가 작은 쪽(Trojan, VLESS)을 고르고, 체감 차이는 주로 회선에서 나옵니다. 업무 시스템에서 작은 파일 업로드·다운로드가 많다면 업로드도 한번 보세요. 업로드가 혼잡하면 다운로드도 함께 영향을 받습니다.

화상 회의와 실시간 음성

회의 트래픽은 양방향이고 지속적이라 대역폭보다 지터에 민감합니다. 지터가 크면 소리가 끊기고 화면이 멈췄다가 따라잡습니다. UDP 계열 프로토콜은 손실 상황에서 매끄러움이 더 좋아, 전용 회선이나 품질이 좋은 중계 회선과 조합하면 이 상황의 우선 선택이 됩니다. 사용 중인 네트워크가 UDP를 허용하지 않으면 TCP 계열로 돌아가도 쓸 수 있지만, 손실 시 통째로 멈추는 현상이 더 자주 나타납니다.

AI 도구의 장기 연결

이런 도구는 대부분 스트리밍 응답을 씁니다. 요청 하나가 수십 초에서 몇 분까지 유지되며 그동안 데이터가 계속 돌아옵니다. 연결이 끊기면 답변이 중단되고 다시 시작하는 비용이 큽니다. 그래서 최고 속도보다 안정성이 우선입니다. TCP 계열 프로토콜과 중계 회선을 고르는 편이 '테스트 숫자가 더 작은' UDP 조합보다 실용적입니다. 같은 이유로 이런 상황에서는 노드를 자주 바꾸는 것도 적합하지 않습니다.

대용량 파일과 백업

다운로드와 백업에서 보는 것은 지속 처리량입니다. 이 상황에서는 프로토콜 헤더 오버헤드가 거의 무시할 수준이고, 속도를 결정하는 것은 회선 대역폭과 양쪽 CPU입니다. VLESS는 암호화를 TLS에 맡겨 프로토콜 계층 오버헤드가 작아 고처리량에서 대역폭을 채우기 쉽습니다. 동시에 트래픽 기준도 확인해야 합니다. 월 구독 트래픽은 개통일 기준으로 매달 초기화되고, 트래픽 패키지는 다 쓸 때까지 유효하며 영구히 만료되지 않으므로, 시간이 일정하지 않은 백업 작업에는 트래픽 패키지가 더 적합합니다.

흔한 오해가 세 가지 있습니다. 첫째, 새 프로토콜이 반드시 빠르지는 않습니다. 프로토콜은 캡슐화만 정하고 병목은 대개 경로에 있습니다. 둘째, 숫자 하나가 전부를 대표하지 못합니다. 클라이언트 지연은 입구까지의 탐사값입니다. 셋째, 시간대가 다르면 비교할 수 없습니다. 피크 시간대와 새벽의 차이가 두 회선 사이의 차이보다 클 수 있습니다. 이 세 가지만 기억해도 반복적인 시행착오에 쓰는 시간을 크게 줄일 수 있습니다.

자체 점검과 검증: 연결한 다음에

연결됐다고 해서 올바른 경로로 가는 것은 아닙니다. 출구가 어느 나라인지, 도메인 해석이 터널을 타는지, 큰 패킷이 통과하는지는 각각 따로 확인해야 합니다. 이 셋은 서로 완전히 다른 증상에 대응하므로, 한데 섞어서 점검하면 길을 돌아가게 됩니다.

출구 주소와 소속 지역

가장 간단한 검증은 출구 주소를 보는 것입니다. 연결한 뒤 이 사이트의 네트워크 진단 페이지를 열면 현재 출구와 소속 지역이 표시됩니다. 연결을 끊고 다시 조회했을 때 두 결과가 달라야 트래픽이 실제로 회선을 탄 것입니다. 두 번이 같다면 클라이언트가 전역 트래픽을 잡지 못했거나 현재 앱이 직결 규칙에 걸린 것입니다. 이 단계를 마친 뒤에야 속도를 논하는 것이 의미 있습니다.

도메인 해석과 분기 규칙

해석이 터널 안에서 이루어지는지가 '해석 결과'와 '실제 출구'의 일치 여부를 결정합니다. 분기 규칙에서 일부 도메인만 프록시하면 해석은 로컬에서 이루어질 수 있고, 일부 사이트는 열리고 일부는 안 열리는 형태로 나타납니다. 점검 방법은 간단합니다. 임시로 전역 모드로 바꿔 보세요. 문제가 사라지면 분기 규칙의 문제이므로 규칙 목록을 확인하면 되고, 프로토콜을 바꿀 필요는 없습니다.

MTU와 단편화

UDP 계열 프로토콜은 MTU에 더 민감합니다. 전형적인 양상은 웹페이지는 열리고 채팅도 되는데 영상이 멈추고, 큰 파일이 전송되지 않고, 특정 앱이 계속 로딩만 도는 것입니다. 원인은 큰 패킷이 경로에서 버려지고 작은 패킷은 정상 통과하기 때문입니다. 해결은 클라이언트에서 MTU를 낮추거나 단편화를 켜는 것입니다. 항목 이름은 클라이언트마다 다르고 보통 프로토콜 설정 안에 있습니다. 조정한 뒤에는 웹페이지가 열리는지만 보지 말고 큰 파일로 다시 테스트하세요.

# 현재 출구 주소 확인(예시 도메인을 임의의 에코 주소 서비스로 교체)
curl -s https://example.com/ip

# 경로 MTU 확인: 먼저 1500으로 시도하고 실패하면 단계적으로 낮추기
ping -c 3 -M do -s 1472 example.com

그대로 적어 볼 수 있는 기록 표

점검에서 가장 위험한 것은 기억에 의존하는 것입니다. 아래 항목을 사흘 연속 기록하면 문제는 대개 스스로 드러납니다.

점검 순서를 한 문장으로 정리하면 이렇습니다. 먼저 출구가 맞는지(회선을 탔는지) 확인하고, 다음으로 안정성(같은 시간대 여러 번 샘플링)을 확인하고, 마지막에 프로토콜을 조정합니다. 순서가 뒤바뀌면 회선 문제를 프로토콜 문제로 착각해 조정할수록 더 엉킵니다. 세 가지가 모두 맞지 않는다면 먼저 사용 가이드 페이지에서 기본 흐름대로 가져오기 과정을 다시 해 보세요. 그래도 안 되면 기록 표의 데이터를 가지고 지원에 문의하는 편이 '연결이 안 된다'고만 말하는 것보다 훨씬 도움이 됩니다.

용어 빠른 참조와 자주 묻는 질문

이 장은 다시 찾아보기 위한 것입니다. 용어는 등장 빈도 순으로 정리했고, 뒤의 문답은 가장 자주 받는 다섯 가지 질문을 다루며, 답은 결론보다 판단 근거를 주도록 했습니다.

RTT 왕복 시간

패킷을 보낸 뒤 응답을 받을 때까지의 시간. 대부분의 상호작용 경험은 대역폭이 아니라 이 값이 결정합니다.

JITTER 지터

여러 번의 왕복 시간 사이의 변동 폭. 회의와 음성은 지터에 가장 민감하고 최대 대역폭에는 오히려 둔감합니다.

LOSS 패킷 손실률

일정 시간 동안 버려진 패킷이 보낸 패킷에서 차지하는 비율. 짧은 연결은 손실에 더 민감한데, 한 번 손실이 나면 재전송 한 라운드를 기다려야 하기 때문입니다.

MUX 다중화

하나의 연결 안에서 여러 요청을 병렬로 처리하는 것. 핸드셰이크 횟수를 줄이는 대신 유지할 연결 상태가 늘어납니다.

0-RTT 제로 왕복 복구

세션 복구 시 핸드셰이크 왕복을 생략하고 첫 요청을 복구 패킷에 실어 보내는 것. 이전에 세션을 맺은 적이 있어야 합니다.

MTU 최대 전송 단위

한 번에 전송할 수 있는 최대 패킷 크기. UDP 계열 프로토콜은 여기에 추가 요구가 있어, 설정이 틀리면 큰 패킷이 전송되지 않는 형태로 나타납니다.

QUIC

UDP 기반 전송 프로토콜로, 전송 핸드셰이크를 TLS와 합치고 스트림 단위 재전송과 연결 마이그레이션을 지원합니다.

AEAD 인증 암호화

연관 데이터를 포함한 인증 암호화로 기밀성과 무결성을 동시에 보장하며, 현대 프로토콜의 기본 구성 요소입니다.

CC 혼잡 제어

송신 측이 패킷 손실과 지연을 근거로 전송 속도를 조정하는 알고리즘. TCP와 QUIC은 구현 전략이 달라 약한 네트워크에서의 성능도 다릅니다.

EDGE 입구와 착지점

입구는 사용자가 접속하는 첫 서버이고, 착지점은 최종적으로 외부 서비스에 접근하는 출구입니다. 둘 사이의 거리가 지연의 하한을 결정합니다.

자주 묻는 질문

관련 페이지: 첫 설정은 사용 가이드, 지역과 회선 유형으로 회선을 고르려면 회선 페이지, 요금제와 트래픽 패키지의 구체적인 가격은 요금제 페이지에서 확인하세요. 속도 측정 과정을 직접 재현해 보려면 가속기 속도 실측 방법을, 완전히 처음부터 시작한다면 해외 가속기 초보자 완전 가이드를 보세요.