Proxy 설정 뒷 이야기
🛰️ 지난 포스트에서 프록시(리버스 프록시)의 개념을 정리하면서, 어제 겪었던 접속 지연의 원인 후보로 “SSL/TLS 모드 불일치”를 짚어두었다. 이번엔 그 뒷이야기다. 클라우드플레어의 SSL/TLS 암호화 모드 3가지(Flexible / Full / Full Strict)가 정확히 뭐가 다른지, 그리고 실제로 어떤 설정이 내 사이트를 느리게 만들었는지 진단 과정을 그대로 복기해본다.
1. 왜 SSL/TLS “모드”가 따로 있는가
지난 글에서 봤듯, 클라우드플레어를 프록시(오렌지 구름)로 켜두면 요청 경로는 두 구간으로 나뉜다.
구간 A(방문자↔엣지)와 구간 B(엣지↔오리진), 이 두 구간을 각각 얼마나 암호화할지 정하는 게 SSL/TLS 모드다.
구간 A는 방문자와 클라우드플레어 사이, 구간 B는 클라우드플레어와 내 실제 서버(오리진) 사이다. SSL/TLS 모드는 이 두 구간을 각각 암호화(HTTPS)할지, 평문(HTTP)으로 둘지, 그리고 암호화한다면 인증서를 얼마나 엄격하게 검증할지를 결정한다.
2. 세 가지 모드, 정확히 뭐가 다른가
🔓 Flexible
구간 A만 암호화(HTTPS). 구간 B는 평문(HTTP)으로 통신.
- 오리진 서버에 SSL 인증서가 없어도 작동
- 오리진↔엣지 구간이 암호화되지 않아 보안상 가장 약함
- 오리진이 HTTP→HTTPS 강제 리다이렉트를 걸어두면 무한 리다이렉트 루프 위험
🔐 Full
구간 A, B 모두 암호화. 단, 오리진 인증서의 유효성은 검증하지 않음(자체 서명 인증서도 허용).
- 오리진에 SSL 인증서(자체 서명 포함)가 있어야 함
- 구간 B가 암호화되긴 하지만, 가짜 인증서로도 통과되므로 중간자 공격 위험은 남아있음
🛡️ Full (Strict)
구간 A, B 모두 암호화. 오리진 인증서를 신뢰 가능한 CA 발급본인지 엄격하게 검증.
- Let’s Encrypt 같은 정식 인증서, 또는 Cloudflare Origin CA 인증서 필요
- 인증서가 만료되거나 도메인 불일치 시 연결 자체가 실패(보안은 가장 강함)
- 공식적으로 권장되는 모드
| 모드 | 구간 A (방문자↔엣지) | 구간 B (엣지↔오리진) | 오리진 인증서 요구사항 |
|---|---|---|---|
| Flexible | 암호화(HTTPS) | 평문(HTTP) | 없음 |
| Full | 암호화(HTTPS) | 암호화(HTTPS) | 있으면 됨 (자체 서명 가능) |
| Full (Strict) | 암호화(HTTPS) | 암호화(HTTPS) | 신뢰된 CA 발급 + 유효기간 내 인증서 |
3. 실제 진단 과정 — 무엇이 느려지게 만들었나
이제 본론이다. 어제 접속 지연을 겪었을 때 실제로 밟았던 진단 순서를 그대로 정리한다.
현재 SSL/TLS 모드 확인
클라우드플레어 대시보드 → SSL/TLS → Overview에서 현재 적용 모드를 확인했다. 설정은 Flexible로 되어 있었다. 오리진 서버(워드프레스가 돌아가는 서버)에는 이미 Let’s Encrypt 인증서가 정상 설치되어 HTTPS가 되고 있었는데도, 클라우드플레어 쪽 설정은 예전 그대로 Flexible에 맞춰져 있었던 것이다.
오리진 서버의 리다이렉트 동작 확인
오리진 서버(워드프레스)는 보안 플러그인 설정상 HTTP 요청이 오면 무조건 HTTPS로 강제 리다이렉트하도록 되어 있었다. 이 부분을 curl로 직접 확인했다.
curl -I http://your-domain.com
# HTTP/1.1 301 Moved Permanently
# Location: https://your-domain.com/여기서 문제가 보인다. Flexible 모드에서는 클라우드플레어가 오리진에 HTTP로 요청을 보낸다. 그런데 오리진은 그 HTTP 요청을 받자마자 다시 HTTPS로 리다이렉트시킨다. 클라우드플레어는 그 리다이렉트를 다시 HTTP로 받아 처리하려다 보니, 이 과정이 반복되면서 불필요한 왕복(라운드트립)이 겹겹이 쌓이는 구조가 만들어져 있었다.
DNS만 우회해서 오리진 서버 자체 속도 측정
지난 포스트에서 다룬 방법대로, 문제 구간을 좁히기 위해 프록시(오렌지 구름)를 잠시 꺼서 클라우드플레어를 거치지 않는 순수 오리진 응답 속도를 측정했다.
curl -o /dev/null -s -w "총 소요시간: %{time_total}s\n" https://your-domain.com프록시를 끈 상태(DNS only)에서는 응답이 빨랐다. 즉 오리진 서버 자체의 성능 문제는 아니라는 게 확인됐고, 문제는 클라우드플레어를 거치는 구간(엣지↔오리진의 프로토콜 불일치)에 있다는 쪽으로 좁혀졌다.
SSL/TLS 모드를 Full (Strict)로 변경
오리진에 이미 유효한 Let’s Encrypt 인증서가 설치되어 있었으므로, Flexible 대신 Full (Strict)로 전환했다. 이렇게 하면 클라우드플레어가 오리진에도 HTTPS로 직접 요청하므로, “HTTP로 보냈다가 HTTPS로 리다이렉트되는” 불필요한 왕복 자체가 사라진다.
재측정으로 개선 확인
모드 변경 후 같은 방식으로 응답 시간을 다시 측정해 지연이 해소된 것을 확인했다. 리다이렉트 체인도 curl -IL로 확인해, 더 이상 중간에 HTTP↔HTTPS를 오가는 불필요한 홉이 없다는 것도 함께 검증했다.
curl -IL https://your-domain.com
# HTTP/1.1 200 OK ← 리다이렉트 없이 한 번에 응답4. 그래서 어떤 모드를 써야 하나
| 오리진 서버 상태 | 권장 모드 |
|---|---|
| 오리진에 SSL 인증서가 아예 없음 | Flexible (임시방편, 가급적 빨리 인증서부터 설치 권장) |
| 오리진에 자체 서명 인증서만 있음 | Full |
| 오리진에 Let’s Encrypt 등 정식 인증서가 있음 (일반적인 경우) | Full (Strict) — 대부분의 상황에서 최선 |
5. 마무리
결국 이번 지연의 본질은 “암호화 자체의 성능 문제”가 아니라, 구간별 설정이 서로 어긋나 있어서 생긴 불필요한 왕복이었다. 프록시(리버스 프록시) 구조를 이해하고 나니, 어느 구간에서 무엇이 어긋났는지 순서대로 좁혀갈 수 있었다. 오리진에 정식 인증서가 있다면 굳이 Flexible에 머물러 있을 이유가 없다. 지금은 Full (Strict)로 맞춰두고, 정기적으로 인증서 갱신 여부와 SSL/TLS 모드가 서로 맞는지 함께 확인하고 있다.