AWS Lightsail의 Bitnami 워드프레스 이미지는 별도의 서버 구축 과정 없이 바로 운영을 시작할 수 있다는 점에서 매우 편리하다. 그러나 일정 기간 운영이 이어지면 공통적으로 나타나는 문제가 있다. 방문자가 많지 않음에도 간헐적인 지연이 발생하거나, 관리자 로그인 시도가 반복되고, 때로는 서버 부하가 급격히 상승하는 현상이다. 이 현상은 일반적으로 트래픽 증가로 오해되지만 실제 원인은 대부분 자동화된 접근 요청, 즉 크롤러와 스팸봇이다.
워드프레스는 구조적으로 외부 접근 지점이 많다. 로그인 페이지(/wp-login.php), 댓글 처리 요청, XML-RPC 호출, REST API 접근 등은 공개 주소를 통해 언제든지 접근 가능하다. 서버가 이러한 요청을 직접 처리하는 구조에서는 실제 방문자가 많지 않더라도 CPU 사용률이 증가하고, 작은 사양의 인스턴스에서는 결국 응답 지연이나 Gateway Timeout으로 이어질 수 있다.
이 문제를 해결하는 가장 표준적인 방법은 서버 성능을 높이는 것이 아니라 서버 앞단에 네트워크 계층을 하나 더 두는 것이다. Cloudflare는 바로 이 역할을 수행한다. Cloudflare는 DNS 서비스이면서 동시에 프록시 CDN이며, 방문자의 요청을 먼저 받아 캐시 가능한 콘텐츠는 자체적으로 처리하고 필요한 요청만 원본 서버(Lightsail 인스턴스)로 전달한다. 결과적으로 서버가 처리해야 하는 요청 수 자체가 감소하고, 보안 필터링까지 함께 적용된다.
다만 Cloudflare 적용 과정은 단순히 네임서버를 변경하는 것으로 끝나지 않는다. 도메인 설정, 서버 SSL 인증서, 프록시 SSL 모드가 정확히 맞물려야 정상적으로 동작하며, 이 관계를 이해하지 못하면 접속 불가 또는 무한 리디렉션이 발생한다. 아래 과정은 Lightsail Bitnami 워드프레스 환경에서 안정적으로 Cloudflare를 적용하기 위한 전체 절차이다.
네트워크 구조 이해
Cloudflare 적용 전후의 접속 경로는 다음과 같이 달라진다.
- 기존 구조: 사용자 → Lightsail 서버
- Cloudflare 적용 후: 사용자 → Cloudflare 엣지 서버 → Lightsail 서버
여기서 중요한 점은 HTTPS 연결이 한 번이 아니라 두 구간에서 각각 형성된다는 것이다.
- 사용자 ↔ Cloudflare
- Cloudflare ↔ 원본 서버(Lightsail)
즉 서버에도 인증서가 필요하며, Cloudflare에도 SSL 설정이 필요하다. 이 두 단계 중 하나라도 불완전하면 접속 오류가 발생한다.
1. Cloudflare에 도메인 등록 및 DNS 구성
Cloudflare 계정 생성 후 “Add a site”를 통해 도메인을 등록한다. 무료 플랜으로 충분하다. 등록 과정에서 기존 DNS 레코드가 자동으로 스캔되며, 이 단계에서 반드시 확인해야 하는 항목은 A 레코드이다.
A 레코드는 도메인이 가리킬 서버의 실제 IP 주소를 의미하며, Lightsail 인스턴스의 퍼블릭 IP가 정확히 입력되어 있어야 한다.
예시:
Type: A
Name: @
IPv4 address: Lightsail 퍼블릭 IP
Proxy status: Proxiedwww 접속을 위해 CNAME 레코드도 추가한다.
Type: CNAME
Name: www
Target: @
Proxy status: Proxied여기서 Proxy 상태는 반드시 활성화(주황색 구름)로 설정해야 한다. 회색 상태는 단순 DNS 역할만 수행하며 Cloudflare의 보안 및 캐시 기능이 적용되지 않는다.
2. 도메인 네임서버 변경
Cloudflare는 자체 네임서버를 제공한다. 이 값을 도메인 등록기관의 관리 화면에서 변경해야 한다. 기존 네임서버를 Cloudflare가 제공한 두 개의 주소로 교체하면, 도메인에 대한 DNS 질의는 Cloudflare를 통해 처리된다.
네임서버 변경 이후에는 전파 시간이 필요하다. 일반적으로 수 분에서 수 시간 사이에 완료되며, Cloudflare 대시보드에서 도메인 상태가 Active로 표시되면 적용이 완료된 것이다. 이 시점부터 방문자의 접속은 Cloudflare를 통해 전달된다.
3. Lightsail 서버 SSL 인증서 적용
Cloudflare를 적용하기 전에 원본 서버에는 반드시 HTTPS가 구성되어 있어야 한다. Bitnami 이미지는 인증서 자동 설치 도구를 포함하고 있다. 서버에 SSH로 접속한 후 아래 명령을 실행한다.
sudo /opt/bitnami/bncert-tool이 도구는 Let’s Encrypt 인증서를 발급하고 웹서버 설정을 수정하며, 워드프레스 사이트 주소를 HTTPS로 전환하고 HTTP 접근을 자동으로 HTTPS로 리디렉션한다. 이 단계가 완료되지 않은 상태에서 Cloudflare를 먼저 적용하면 SSL 충돌로 접속 오류가 발생한다.
4. Cloudflare SSL 모드 설정
Cloudflare 대시보드의 SSL/TLS → Overview 메뉴에서 SSL 모드를 설정한다. 이 단계가 전체 과정 중 가장 중요하다.
설정 값: Full (strict)
각 모드의 의미는 다음과 같다.
- Flexible: 사용자와 Cloudflare만 HTTPS, 서버는 HTTP → 리디렉션 루프 발생 가능
- Full: 서버 인증서 검증 없음 → 일부 로그인 문제 발생 가능
- Full (strict): 서버 인증서 검증 포함 → 정상 동작
Bitnami의 Let’s Encrypt 인증서를 사용한 환경에서는 Full (strict)만이 올바른 설정이다.
5. 워드프레스 HTTPS 인식 설정
프록시 환경에서는 실제 HTTPS 접속이 Cloudflare에서 종료되기 때문에 워드프레스는 접속을 HTTP로 오인할 수 있다. 이 경우 로그인 반복 이동 또는 ERR_TOO_MANY_REDIRECTS 오류가 발생한다.
서버에서 워드프레스 설정 파일을 수정한다.
sudo nano /opt/bitnami/wordpress/wp-config.php파일 마지막 부분에 아래 코드를 추가한다.
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
$_SERVER['HTTPS'] = 'on';
}저장 후 서버를 재시작한다.
sudo /opt/bitnami/ctlscript.sh restart이 설정은 프록시 뒤에 있는 서버가 HTTPS 요청임을 워드프레스에게 전달하는 역할을 한다.
6. Cloudflare 보안 및 성능 옵션
Cloudflare 적용 후 기본적인 보안 및 성능 기능을 활성화하면 효과가 크게 증가한다.
권장 설정:
- Always Use HTTPS: 활성화
- Automatic HTTPS Rewrites: 활성화
- Bot Fight Mode: 활성화
- 캐시 레벨: 기본(Standard) 유지
이 설정은 로그인 시도와 자동화된 요청을 상당 부분 차단하며, 정적 파일은 Cloudflare 엣지 서버에서 제공되어 원본 서버 부하가 감소한다.
적용 결과
설정이 정상적으로 완료되면 접속 주소는 HTTPS로 유지되며, 서버에 직접 도달하는 요청 수가 감소한다. 일반적으로 다음과 같은 변화가 나타난다.
- 관리자 로그인 시도 감소
- CPU 사용률 안정화
- 해외 접속 속도 개선
- 댓글 스팸 감소
- 간헐적 타임아웃 감소
Cloudflare의 효과는 서버 성능 향상이 아니라 요청 분산과 차단에 있다. 특히 소규모 Lightsail 인스턴스 환경에서는 체감 차이가 크게 나타난다.
결론
Cloudflare는 단순 CDN이 아니라 워드프레스 서버 앞단의 네트워크 보호 계층이다. Lightsail Bitnami 워드프레스 환경에서는 HTTPS 설정 이후 Cloudflare 적용을 통해 보안과 안정성을 동시에 확보할 수 있다. 핵심 조건은 세 가지다.
- 원본 서버에 HTTPS 인증서 적용
- 도메인 네임서버를 Cloudflare로 변경
- SSL 모드를 Full (strict)로 설정
이 구성이 완료되면 별도의 플러그인 없이도 워드프레스 운영 환경의 안정성을 크게 향상시킬 수 있다.