🛰️ 프록시 3부작의 마지막 편이다. 1편에서 프록시(리버스 프록시/CDN)의 개념을, 2편에서 SSL/TLS 모드 불일치 문제를 다뤘다. 그런데 SSL 모드를 고쳤는데도 여전히 느렸고, 그 뒤를 추적하는 과정에서 예상을 몇 번이나 뒤엎는 반전이 이어졌다. 결론부터 말하면, 이번 지연은 클라우드플레어 전체도, 내 통신사 전체도 아니라 “이 존(zone)에 배정된 특정 IP 프리픽스”라는, 훨씬 좁고 구체적인 지점의 문제였다.

1. Full (Strict)로 고쳤는데도 여전히 느렸다

2편에서 SSL/TLS 모드를 Flexible에서 Full (Strict)로 바꿔 리다이렉트 왕복 문제를 없앴다. 그런데 체감 속도는 크게 달라지지 않았다. 뭔가 다른 원인이 남아있다는 뜻이었고, 이번엔 추측 대신 클라우드플레어의 진단 엔드포인트로 직접 확인하기로 했다.

curl https://vinaida.xyz/cdn-cgi/trace

2. 반전 하나 — 프록시가 꺼져 있었다

첫 결과는 예상 밖이었다. 클라우드플레어의 진단 텍스트가 아니라 워드프레스가 만든 순수한 404 에러 페이지가 그대로 돌아왔다. 이건 요청이 클라우드플레어를 거치지 않고 오리진 서버까지 직행했다는 뜻 — 프록시(오렌지 구름)가 언제부턴가 꺼져 있었다는 신호였다. 2편에서 오리진 자체 속도를 측정하려고 잠시 꺼뒀다가 되돌리는 걸 깜빡했던 것. 다시 오렌지 구름으로 켜고 재시도했다.

3. 반전 둘 — loc=KR인데 colo=SJC

프록시를 다시 켠 뒤 재실행하자 제대로 된 진단 텍스트가 나왔다.

ip=221.153.xxx.xxx
loc=KR
colo=SJC
tls=TLSv1.3

클라우드플레어는 방문자를 한국(KR)으로 정확히 인식했지만, 실제 응답은 미국 서해안 San Jose 엣지가 처리했다.

4. traceroute로 병목 지점 특정

지연이 급증한 6→7번 홉(112.174.91.30 → 112.174.87.26)은 클라우드플레어 네트워크에 들어가기도 전, 같은 IP 대역 안에서 발생했다. whois로 확인하니 이 대역은 Korea Telecom(KT, AS4766) 소유였다. 여기까지만 보고 “KT 전체가 클라우드플레어와 국내 피어링이 안 된다”고 결론 내렸었다. 하지만 이건 성급한 결론이었다.

5. 반전 셋 — 다른 Cloudflare 사이트는 멀쩡했다

같은 KT 회선에서 다른 클라우드플레어 기반 사이트로도 같은 테스트를 해봤다.

6. 반전 넷 — 존에 배정된 두 IP 모두 같은 문제

vinaida.xyz에 배정된 애니캐스트 IP는 nslookup으로 확인하니 두 개였다(104.21.85.49, 172.67.202.118). 혹시 둘 중 하나만 문제인가 싶어 각각 tracert를 떠봤다.

두 IP 모두 같은 게이트웨이, 같은 클라우드플레어 프리픽스(141.101.72.x)로 몰려 똑같이 우회하고 있었다. 반면 discord.com/cloudflare.com은 141.101.82.x 프리픽스를 썼다. 즉 진짜 원인은 “KT 전체”도 아니고 “IP 하나”도 아니라, vinaida.xyz 존에 배정된 141.101.72.x 프리픽스 자체가 KT 국내 직결 경로(218.145.42.210)에서 빠져 있다는 것이었다.

7. 마지막 시도 — DNS 레코드 삭제 후 재생성

클라우드플레어 커뮤니티에서 종종 언급되는 방법대로, DNS A 레코드를 완전히 삭제했다가 다시 만들면 새로운 애니캐스트 IP 풀에서 재배정받을 수 있지 않을까 시도해봤다.

nslookup vinaida.xyz
→ 172.67.202.118, 104.21.85.49  (재생성 전과 완전히 동일)

8. 세 편에 걸친 원인의 층위 정리

9. 남은 유일한 방법 — Cloudflare 지원팀 문의

이 지점까지 좁혀낸 이상, 남은 방법은 하나다. 지금까지 뽑아낸 이 비교 데이터(같은 KT 회선에서 141.101.82.x 프리픽스는 5ms, 141.101.72.x 프리픽스는 135ms) 그대로를 근거로 클라우드플레어 지원팀에 문의하는 것. 프리픽스 단위까지 특정된 구체적인 증거가 있으니, 해당 존을 국내 피어링이 더 원활한 프리픽스 풀로 재배정해달라고 요청할 근거는 충분하다.

10. 이번 3부작에서 남는 것

/cdn-cgi/trace로 어느 엣지가 응답하는지 확인하고, tracert로 구간별 지연을 뜯어보고, whois로 그 구간의 소속을 확인하고, 마지막으로 같은 조건에서 다른 사이트와 비교하는 것 — 이 네 가지만으로 “내가 고칠 수 있는 문제”와 “내 통제 밖의 문제”를 프리픽스 단위까지 정확히 구분할 수 있었다. 특히 “다른 대조군과 비교해보기” 없이 첫 tracert 결과만 보고 “KT 전체가 문제”라고 성급히 결론 내렸던 건 이번에 얻은 가장 큰 교훈이다. 비슷한 문제를 겪는다면, 결론을 내리기 전에 반드시 같은 CDN을 쓰는 다른 사이트와 나란히 비교해보길 권한다.