Proxy 프록시란 무엇인가
🛰️ 어제 이 블로그의 접속 지연 문제를 붙잡고 씨름하다가, 범인이 클라우드플레어(Cloudflare)의 “프록시”였다는 걸 알게 됐다. 프록시(Proxy)라는 단어 자체가 “대리인”이라는 뜻이라는 걸 새삼 깨닫고 나니, 그동안 그냥 켜두기만 했던 이 오렌지색 구름 아이콘의 정체가 궁금해졌다. 오늘은 프록시 서버의 개념부터 작동 원리, 설정과 해제, 그리고 왜 필요한지까지 처음부터 끝까지 정리해본다.
1. 프록시(Proxy)란 무엇인가
프록시(Proxy)는 사전적으로 “대리인”, “대리”라는 뜻이다. 네트워크 세계에서도 의미는 똑같다. 내 컴퓨터(클라이언트)와 목적지 서버 사이에서, 요청을 대신 전달해주는 중간 대리인 역할을 하는 서버가 바로 프록시 서버다.
비유하자면 이렇다. 내가 직접 가게에 가서 물건을 사는 대신, 심부름꾼에게 “이거 사다 줘”라고 하면 심부름꾼이 가게에 가서 물건을 받아 나에게 전달해준다. 가게 주인은 나를 직접 본 적이 없고, 심부름꾼만 상대한다. 여기서 심부름꾼이 바로 프록시다.
클라이언트는 프록시를 통해 서버와 통신한다. 서버는 실제 요청자를 직접 보지 못한다.
즉, 프록시 서버는 클라이언트와 서버 사이에 끼어들어 요청과 응답을 중계하는 존재다. 이 단순한 구조 하나가 보안, 속도, 캐싱, 익명성, 접근 제어 등 셀 수 없이 많은 용도로 활용된다.
2. 프록시의 두 가지 큰 갈래: 정방향 vs 역방향
프록시는 “누구를 대신하느냐”에 따라 크게 두 종류로 나뉜다. 이 구분을 이해하면 이후 클라우드플레어 이야기가 훨씬 명확해진다.
🔵 포워드 프록시 (Forward Proxy)
클라이언트 쪽을 대신하는 프록시다. 여러 명의 내부 사용자가 프록시 하나를 거쳐 외부 인터넷에 나간다.
- 회사 사내망에서 외부 사이트 접속 시 필터링/로깅
- VPN, 우회 접속(지역 제한 회피)
- 서버 입장에선 “누가” 요청했는지 프록시 뒤에 숨겨짐
🟣 리버스 프록시 (Reverse Proxy)
서버 쪽을 대신하는 프록시다. 여러 명의 외부 사용자가 프록시 하나를 거쳐 내부 서버에 접근한다.
- CDN(콘텐츠 전송 네트워크), 로드 밸런서가 대표적
- 클라우드플레어, Nginx 리버스 프록시 등
- 클라이언트 입장에선 “진짜 서버”가 프록시 뒤에 숨겨짐
3. 리버스 프록시(CDN)는 정확히 무슨 일을 하는가
클라우드플레어 같은 CDN을 도메인 앞에 세우면, 방문자의 요청은 실제 내 서버로 곧장 가지 않는다. 먼저 클라우드플레어의 엣지 서버(Edge Server)를 거친 뒤, 필요할 때만 내 실제 서버(Origin Server)로 전달된다.
이 구조 덕분에 다음과 같은 일이 자동으로 일어난다.
- 캐싱(Caching): 이미지, CSS, JS 같은 정적 파일을 엣지 서버가 미리 저장해두고, 방문자에게 더 가까운 위치에서 즉시 응답한다. 내 서버까지 갈 필요가 없으니 훨씬 빠르다.
- IP 은닉: 방문자와 공격자 모두 클라우드플레어의 IP만 보게 되고, 내 서버의 실제 IP는 감춰진다.
- DDoS 방어: 악성 트래픽이 몰려도 클라우드플레어 엣지에서 대부분 걸러지고, 내 서버까지 도달하지 못한다.
- SSL/TLS 처리: 방문자↔클라우드플레어 구간의 암호화를 클라우드플레어가 대신 처리해줄 수 있다.
- 로드 밸런싱: 서버가 여러 대일 경우 트래픽을 분산시켜준다.
4. 오렌지 구름 vs 회색 구름 — 실제 설정 화면 이해하기
클라우드플레어 DNS 설정 화면에는 각 레코드마다 구름 모양 아이콘이 있고, 이걸 클릭하면 주황색↔회색으로 바뀐다. 이게 바로 “프록시를 켜고 끄는” 스위치다.
Proxied (오렌지 구름)
프록시 켜짐. 트래픽이 클라우드플레어 엣지를 거친다. 캐싱·보안·IP 은닉이 모두 적용된다.
DNS only (회색 구름)
프록시 꺼짐. 클라우드플레어는 단순히 도메인 이름을 IP 주소로 바꿔주는 DNS 역할만 하고, 트래픽은 곧바로 내 서버로 직행한다.
즉 회색 구름 상태는 클라우드플레어를 “주소록”으로만 쓰는 것이고, 오렌지 구름은 클라우드플레어를 “대리인(리버스 프록시)”으로 세워두는 것이다.
DNS 레코드 화면 예시 (개념)
유형 이름 콘텐츠 프록시 상태
A your-domain.com your-server-ip 🟠 Proxied
CNAME www your-domain.com 🟠 Proxied
A mail your-server-ip ⚪ DNS only ← 메일 서버는 보통 프록시 제외※ 실제 값은 예시로 대체했다. 위처럼 웹 트래픽용 레코드는 오렌지로, 메일(MX 연계 A레코드)이나 SSH 접속용 서브도메인 등 프록시가 오히려 방해되는 레코드는 회색으로 두는 게 일반적이다.
5. 어제 겪은 문제 — 프록시가 접속 지연의 원인이었던 이유
보통 프록시(CDN)를 켜면 오히려 사이트가 빨라지는 게 상식이다. 캐싱과 전 세계 엣지 서버 덕분이다. 그런데도 접속 지연이 발생했다면, 다음과 같은 원인들을 의심해볼 수 있다.
- SSL/TLS 모드 불일치: 클라우드플레어의 암호화 모드(Flexible / Full / Full(Strict))가 내 서버의 실제 인증서 상태와 맞지 않으면, 이중 리다이렉트나 핸드셰이크 재시도가 발생해 지연이 생긴다.
- 동적 콘텐츠 위주 사이트: 정적 파일이 거의 없고 매번 서버에서 새로 렌더링해야 하는 페이지(예: 로그인 세션, API 호출이 많은 앱)는 캐싱 이득이 적고, 오히려 엣지→오리진 왕복 구간(홉)이 하나 늘어나는 셈이 된다.
- 캐시 설정 미비: 캐시 규칙(Cache Rules)을 제대로 설정하지 않으면 매번 오리진 서버까지 요청이 그대로 전달돼, “프록시를 거치는 오버헤드”만 추가되고 캐싱의 이득은 못 보는 상황이 생긴다.
- 지역별 엣지 노드 이슈: 특정 지역에서 클라우드플레어 엣지 노드 자체의 응답이 느리거나, 오리진 서버와 엣지 간 회선 경로가 비효율적인 경우.
- 워드프레스 등 CMS와의 캐시 충돌: 플러그인 레벨 캐시와 클라우드플레어 캐시가 서로 꼬여서 페이지가 오래된 버전으로 뜨거나, 캐시 무효화(purge)가 꼬이는 경우.
이런 이유들 때문에 원인을 특정하기 전까지는, 일시적으로 프록시를 회색 구름(DNS only)으로 내려서 “프록시 구간을 제거한 순수 접속 속도”와 비교해보는 것이 가장 확실한 진단 방법이다. 나 역시 이 과정에서 문제 구간이 프록시(정확히는 SSL 모드 설정)에 있다는 걸 확인할 수 있었다.
6. 프록시, 언제 켜고 언제 꺼야 할까
| 상황 | 권장 설정 | 이유 |
|---|---|---|
| 일반 웹사이트 (블로그, 홈페이지) | 🟠 Proxied | 캐싱·보안·속도 이점을 대부분 누릴 수 있음 |
| 메일 서버 연동 레코드 | ⚪ DNS only | 프록시를 거치면 메일 프로토콜이 정상 동작하지 않음 |
| SSH / FTP 접속용 서브도메인 | ⚪ DNS only | HTTP(S) 외의 프로토콜은 프록시 처리 대상이 아님 |
| 서버 실제 IP 노출 위험이 있는 API | 🟠 Proxied | IP 은닉과 DDoS 방어가 중요한 경우 |
| 원인 진단 중인 접속 지연 | ⚪ 일시적으로 해제해 비교 | 프록시 구간을 제거한 순수 속도와 비교해 원인 특정 |
7. 설정/해제 방법 요약
- 클라우드플레어 대시보드 로그인 → 해당 도메인 선택
- 왼쪽 메뉴에서 DNS → Records 이동
- 변경하려는 레코드 오른쪽의 구름 아이콘 클릭
- 🟠(Proxied) ↔ ⚪(DNS only) 토글
- 변경은 즉시 적용되지만, DNS 전파 특성상 전 세계 반영까지 몇 분 정도 소요될 수 있음
8. 마무리
결국 프록시란 “대리인”이라는 단어 뜻 그대로, 누군가를 대신해서 요청을 주고받아주는 중간 서버다. 포워드 프록시는 나(클라이언트)를 대신하고, 클라우드플레어 같은 리버스 프록시는 내 서버를 대신한다. 평소엔 속도와 보안을 모두 챙겨주는 고마운 존재지만, 어제처럼 SSL 모드나 캐시 설정이 어긋나 있으면 오히려 병목 구간이 될 수도 있다는 걸 직접 겪으며 배웠다.
🛰️ 다음엔 클라우드플레어의 SSL/TLS 모드(Flexible / Full / Full Strict) 차이와, 실제로 어떤 설정이 내 접속 지연을 일으켰는지 구체적인 진단 과정을 별도 포스트로 정리해볼 예정이다.