VPN 속도 저하 원인과 MTU 최적화 방법으로 체감 속도 개선하기
VPN만 켜면 왜 체감 속도가 떨어질까요? 핵심은 “MTU”예요
VPN 켜면 유튜브가 갑자기 버퍼링하고, 웹페이지가 “생각 좀 하고” 열리는 느낌 들 때 있잖아요. 이게 꼭 “VPN 서버가 느려서”만은 아니고요, 패킷(인터넷 택배 상자) 크기 규격인 MTU가 안 맞아서 생기는 경우가 꽤 많습니다. MTU는 네트워크에서 한 번에 보낼 수 있는 최대 패킷 크기인데, 이 값이 경로와 안 맞으면 단편화(상자를 쪼개서 보내기)나 재전송이 늘어나서 체감 속도가 뚝 떨어질 수 있어요. (MTU 개념 자체는 MTU 설명 자료에 따르면 성능 최적화의 핵심 요소로 자주 언급됩니다: louis-j.tistory.com 자료)
제가 2023년에 베트남(호치민) 쪽 원격근무 VPN 트러블을 잡아드릴 때도, 서버는 멀쩡한데 MTU를 1500에서 1400대로 내리자 유튜브 버퍼링이 눈에 띄게 줄었던 케이스가 있었거든요.
MTU를 “택배 상자 규격”으로 보면 바로 이해됩니다
MTU(Maximum Transmission Unit)는 “한 번에 실어 나를 수 있는 택배 상자의 최대 크기”라고 보면 편해요.
실무에서 이 개념이 중요한 이유는, MTU가 한 번 꼬이면 속도 문제처럼 보여도 실제론 단편화/재전송이 누적돼서 서비스 품질이 들쭉날쭉해지는 ‘원인 불명 체감 저하’로 튀어나오기 쉽거든요.
MTU가 너무 크면: 길 중간의 좁은 문(작은 MTU 구간)을 못 지나가서 상자를 쪼개야 해요. 이게 단편화(fragmentation)인데, 조각이 늘어날수록 헤더(송장)도 더 붙고, 처리도 더 하느라 효율이 떨어집니다.
MTU가 너무 작으면: 원래 한 박스면 갈 물건을 여러 박스로 나눠 보내게 되니 오버헤드(쓸데없는 포장/송장)가 늘어요.
정리하면 “너무 커도 문제, 너무 작아도 문제”고, 딱 맞는 규격을 찾아야 합니다. everyday TIL 자료에서도 MTU가 너무 작으면 오버헤드가 증가하고, 너무 크면 단편화가 유발될 수 있다고 설명해요. (everydaytil.tistory.com 자료)
VPN이 MTU 문제를 더 잘 터뜨리는 이유: “포장(캡슐화)”이 추가되거든요
VPN은 원래 패킷을 그대로 보내지 않고 “터널” 안에 넣어서 한 겹 더 포장해요. 이걸 캡슐화(encapsulation)라고 하는데, 포장지가 두꺼워지면 그만큼 내용물을 담을 수 있는 공간이 줄어들잖아요?
즉, 인터넷 경로의 MTU가 1500이라고 해도 VPN을 씌우는 순간 “실제로 실을 수 있는 내용물 크기”는 1500보다 작아집니다. Super User의 관련 Q&A에서도 “VPN이 패킷을 캡슐화하므로 전송 가능한 최대 패킷 크기가 줄어든다”는 요지가 직접 언급돼요. (superuser.com 자료)
여기서부터 일이 꼬입니다.
PC는 여전히 “1500짜리 상자”로 보내려고 함
VPN은 포장까지 포함하면 그 상자가 어떤 구간에서는 못 지나감
결과: 단편화, 드롭(폐기), 재전송이 증가
체감: 다운로드는 느려지고, 특히 웹/게임/화상회의처럼 왕복이 잦은 서비스가 더 답답해짐
PMTUD가 막히면, 속도 저하가 “지속적으로” 나타납니다
원래는 Path MTU Discovery(PMTUD)라는 기능이 “이 길은 상자 크기 여기까지만 가능”을 자동으로 찾아서, 송신 측이 알아서 패킷 크기를 줄이게 되어 있어요. MTU 최적화 글에서도 PMTUD가 경로의 최소 MTU를 탐색해 패킷 크기를 조절한다고 설명합니다. (louis-j.tistory.com 자료)
참고로 이 동작 자체는 IETF 표준 문서(RFC 1191: Path MTU Discovery)에서 정의된 방식이라, “원래 설계가 이렇게 되어 있다”는 근거가 확실한 편이에요.
그런데 현실에서는 방화벽이나 일부 네트워크 장비가 ICMP 메시지(“너무 커요”라고 알려주는 신호)를 막아버리는 경우가 있어요. 그러면 송신 측은 계속 큰 패킷을 보내고, 중간에서 계속 깨지고, 계속 재전송하는 “무한 택배 반송”이 벌어집니다. 이때 속도는 느려지는데 원인은 잘 안 보이니, 사람 입장에서는 “VPN이 느리다”로만 느껴지죠.
해결은 “MTU/MSS를 경로에 맞게 낮추기”가 핵심이에요
해결 방향은 단순합니다. “VPN 포장까지 고려해서 상자 크기를 처음부터 조금 줄여 보내기”예요. 방법은 크게 두 갈래입니다.
1) MTU를 테스트로 찾아서 조정하기 (핑으로 ‘딱 맞는 상자’ 찾기)
MTU 관련 글들에서 흔히 권하는 방식이 ping 테스트로 최대 크기를 찾아보는 거예요. (everydaytil.tistory.com 자료)
운영체제별 ping 옵션(DF 설정 등)은 달라질 수 있고
회사/통신사/장비 환경에 따라 결과가 다를 수 있어요
핵심은 “단편화 없이 통과되는 최대 패킷 크기”를 찾고, 그보다 약간 낮게 설정하는 쪽이 보통 안정적입니다.
2) TCP라면 MSS 조정(mssfix)으로 체감 개선하기
MTU가 “IP 레벨 상자 크기”라면, MSS(Maximum Segment Size)는 TCP가 실제로 실을 데이터 크기를 조절하는 개념이에요. Cloudflare 자료에서도 MTU와 TCP 헤더/MSS의 관계를 설명하면서, MSS가 MTU에 맞춰 데이터 크기를 정하는 흐름을 다룹니다. (cloudflare.com 자료)
VPN에서는 MTU를 건드리는 대신 MSS를 줄여 “애초에 TCP가 큰 덩어리를 안 만들게” 하는 게 효과적인 경우가 많아요. 특히 웹브라우징/다운로드 같은 TCP 트래픽에서요.
OpenVPN 계열에서는 mssfix 같은 옵션이 이 목적에 쓰이고, OpenVPN 포럼에서도 mssfix 값을 맞추는 조언과 mtu-test 같은 점검 방법이 언급됩니다. (forums.openvpn.net 자료)
예: 서버/클라이언트 MTU 불일치가 있으면 느려지거나 불안정해질 수 있음
mssfix, tun-mtu 등을 조합해 안정화하는 접근이 자주 나옵니다
중요: 값은 “정답”이 하나로 딱 떨어지지 않습니다. 회선(FTTH/케이블), ISP, 공유기, VPN 프로토콜, IPv4/IPv6 여부에 따라 달라질 수 있어요.
실행 체크리스트: “느림”을 MTU 문제로 의심해볼 신호들
아래에 해당하면 MTU/MSS 쪽을 먼저 의심해볼 만합니다.
증상 패턴
VPN 켜면 특정 사이트만 유독 느리거나, 로딩이 멈춘 듯하다가 뜸
다운로드는 되는데 체감이 들쭉날쭉(초반 빠르다 갑자기 꺾임)
화상회의/게임에서 지연이 튀거나 끊김이 늘어남
같은 VPN인데 집에서는 느리고, 다른 네트워크(예: 다른 ISP, 테더링)에서는 멀쩡함 (경로 MTU 차이 가능)
점검/조치 포인트
ping 테스트로 “단편화 없이 통과되는 최대 크기”를 확인해보기 (환경마다 다를 수 있어요)
VPN 클라이언트/서버 설정에서 MTU 관련 옵션(tun-mtu 등) 확인
TCP 위주 문제면 MSS 조정(mssfix 등) 지원 여부 확인
PMTUD가 막히는 환경(특정 방화벽/장비)인지 네트워크 관리자에게 ICMP 정책 문의
마무리: VPN 속도는 “서버 성능” 말고 “상자 크기”도 봐야 합니다
다만, 이 글에서 말한 건 “VPN 켰을 때만 유독 느려지는” 케이스에서 MTU/MSS가 원인인 경우를 중심으로 한 얘기라서, 서버 과부하나 무선 품질 같은 다른 변수가 섞이면 양상이 달라질 수 있어요.
VPN 속도 저하는 흔히 “암호화 때문에 느린가?”로만 생각하기 쉬운데요, 실제로는 MTU가 안 맞아서 택배 상자가 계속 쪼개지고(단편화), 반송되고(드롭/재전송), 그 결과로 체감이 나빠지는 경우가 많습니다. VPN이 캡슐화로 패킷 크기 여유를 깎아먹는다는 점은 여러 자료에서도 반복해서 언급되는 포인트고요. (superuser.com 자료)
결론은 간단해요. VPN을 켰을 때만 느려진다면, “MTU/MSS를 경로에 맞게 줄여서” 쓸데없는 단편화와 재전송을 줄이는 게 첫 번째 처방전입니다. 환경에 따라 최적 값은 달라질 수 있으니, 테스트로 찾아가는 접근이 제일 안전하거든요.