Cloudflare를 쓰는데 한국에서 사이트가 느릴 때, LAX 엣지부터 확인하세요

같은 PC, 같은 KT 회선에서 주소 두 개를 연달아 열었습니다.

cloudflare.com은 colo=ICN, 서울 엣지였습니다. 제 회사 사이트는 colo=LAX, 로스앤젤레스였습니다.

같은 Cloudflare인데 한쪽은 서울에서, 한쪽은 태평양 건너에서 응답하고 있었습니다. 사이트가 묘하게 느리다는 체감은 이 한 줄에서 풀렸습니다.

같은 순간, 다른 도시

Cloudflare를 거치는 사이트는 주소 뒤에 /cdn-cgi/trace를 붙이면 엣지가 직접 답합니다. 원 서버를 거치지 않아 엣지까지의 비용만 보입니다.

curl -s https://cloudflare.com/cdn-cgi/trace | grep colo
curl -s https://내사이트주소/cdn-cgi/trace | grep colo

colo 뒤의 세 글자가 응답한 데이터센터의 공항 코드입니다. 한국 사용자라면 ICN이 정상입니다.

2026-07-29 새벽, 저는 이 차이를 처음 봤습니다. 전날 밤 업무 시스템 쪽 캐시 예외를 손봐 배포한 뒤, 사이트들이 너무 느리다는 체감을 재 보던 중이었습니다.

캐시가 맞아도 630ms

전날 손본 캐시 규칙으로는 풀리지 않았습니다. 캐시 히트 상태에서도 630ms가 걸렸습니다.

캐시가 줄이는 것은 원 서버 왕복이고, 사용자와 엣지 사이 거리는 그대로 남습니다.

엣지가 로스앤젤레스에 있으면 캐시가 아무리 잘 맞아도 매 요청이 태평양을 왕복합니다. 이 지점에서 캐시 튜닝을 멈추고 경로를 보기로 방향을 바꿨습니다.

원인은 IP 대역

두 달 반쯤 뒤인 10-11에 같은 회선에서 다시 쟀습니다. 조건은 KT 서울 유선, 일요일 17:22~17:24, 호스트당 trace 10회입니다.

원 서버를 타지 않는 응답인데도 LAX 쪽은 0.4초를 넘었습니다. 서버 쪽 수정과 무관한 값입니다.

다음으로 호스트 이름은 그대로 두고 연결할 IP만 바꿔 봤습니다. colo가 따라서 바뀌었습니다.

엣지를 정하는 기준은 그 존에 배정된 IP 대역이었습니다. 무료와 Pro 존이 받는 대역이 KT에서 LAX로 나가고 있었습니다.

업무 앱 주소를 서울행 Cloudflare IP에 강제로 붙이자 첫 응답이 0.62.2초에서 0.060.08초로 떨어졌습니다. 원 서버 왕복을 포함한 값입니다.

이 강제 연결은 진단용으로만 썼습니다. 제 존에 배정된 IP가 아니어서 언제든 거절당할 수 있고, 실제로 다른 서울 IP 하나는 403을 돌려줬습니다.

경로 추적도 같은 그림이었습니다. LAX 대역은 태평양을 건넌 뒤 미국에서 Cloudflare로 넘어갔고, ICN 대역은 국내에서 바로 넘어갔습니다.

같은 시각 ping은 LAX 쪽 평균 134~137ms, ICN 쪽 3ms였습니다.

느린 것보다 무거운 것

지연만 문제였다면 0.4초 정도로 끝났을 겁니다. 처리량을 재 보고 나서 체감 랙의 정체가 보였습니다.

LAX 경로가 1/12에서 1/50 수준이었습니다. ping 손실은 0%였는데 TCP 전송만 무너졌습니다.

페이지 하나를 그리는 정적 자산 22개를 연결 하나로 차례로 받아 보면 차이가 더 커집니다(17:35~17:37, 3회).

전부 캐시 히트였는데 LAX는 4.2초, 66.5초, 75.2초로 흔들렸습니다. ICN은 0.41~0.50초에 머물렀습니다.

국제 구간 어딘가의 혼잡으로 보이지만 어느 구간인지는 사용자 쪽에서 확정할 수 없습니다. 크기는 시간대마다 달라질 수 있다는 단서도 같이 붙여 둡니다.

플랜을 올리면 풀릴까

처음 떠오르는 해법은 유료 플랜입니다. 커뮤니티에서 플랜별로 하나씩 세워 둔 측정용 도메인을 같은 회선에서 10회씩 재 봤습니다.

플랜마다 도메인이 하나뿐인 표본이라 다른 도메인은 다를 수 있습니다. 측정 도구 쪽도 보장이 없다고 적어 둡니다.

Pro는 같은 회선에서 여전히 LAX였습니다. Business는 일본으로 붙었지만 존 하나에 월 250달러이고, 피어링 사정이 바뀌면 다시 나빠질 수 있습니다.

Argo 같은 경로 최적화 상품도 봤습니다. 공식 문서상 Argo는 엣지와 원 서버 사이 구간을 다룹니다.

사용자가 처음 들어가는 엣지가 LAX인 문제는 건드리지 못해서 후보에서 뺐습니다.

프록시를 끈 날

회사 사이트 본체는 국내 엣지가 있는 호스팅(Vercel)에 있었습니다. 그 앞에 Cloudflare를 한 겹 더 얹어 LAX를 돌고 있던 셈입니다.

프록시는 위 재측정보다 먼저인 07-29 그날 껐습니다. 루트와 www의 프록시를 끄고 DNS만 남겨 호스팅 CDN으로 바로 붙였습니다.

결과는 이랬습니다. 측정 조건은 같은 KT 회선, 07-29 전환 전후입니다.

응답 헤더에서 cf-ray가 사라지고 호스팅 쪽 헤더가 서울 엣지(icn1)를 가리키면 전환이 끝난 겁니다.

루트가 0.49초에 머문 이유도 헤더에 있었습니다. 엣지는 서울로 왔지만 페이지를 만드는 함수가 미국 동부에서 돌고 있었습니다.

함수 리전을 옮기려면 데이터 저장소 리전부터 맞춰야 해서 따로 떼어 둔 과제입니다.

끄기 전에 확인한 것

프록시 스위치는 클릭 한 번이지만 그 뒤에 기대고 있던 기능이 함께 빠집니다. 저는 끄기 전에 인증서와 리다이렉트부터 봤습니다.

원 서버가 유효한 인증서를 이미 갖고 있는지 확인했습니다. Cloudflare가 대신 인증서를 내주던 구조라면 끄는 순간 브라우저에 경고가 뜹니다.

www를 루트로 넘기는 리다이렉트를 누가 처리하는지도 봤습니다. Cloudflare 규칙으로 걸어 뒀다면 프록시를 끄면 그 규칙도 같이 멈춥니다.

반대 방향의 함정도 있습니다. Cloudflare 터널로 연결한 하위 도메인은 프록시를 끄면 그 즉시 끊깁니다.

터널 주소는 Cloudflare 안에서만 풀리기 때문입니다.

그래서 저는 루트와 www만 껐고, 터널 뒤의 업무 앱 주소들은 그대로 뒀습니다.

이쪽은 원 서버 IP를 드러내는 DNS 직결과 서울 VPS 프런트(월 5~17달러 선) 사이에서 고를 문제로 남아 있습니다.

직결은 비용이 없는 대신 엣지 방화벽과 DDoS 흡수를 잃습니다. VPS 프런트는 IP를 숨겨 주지만 서버 한 대가 새 장애 지점이 됩니다.

이런 구조라면 어디까지 직결할지부터 그려 보세요.

지금 측정값을 기술 상담에 붙여 보내셔도 됩니다.

판단표

같은 증상이 의심되면 아래 순서대로 보시면 됩니다. 제 측정 조건은 KT 서울 유선, 2026-07-29와 10-11입니다.

마지막 단계에서 고를 수 있는 선택지는 이렇습니다.

SKB와 LG유플러스, 모바일 회선은 제가 재 보지 못했습니다. 방문자 대부분이 다른 통신사라면 1번과 2번을 그 회선에서 10회씩 먼저 재 보세요.