새벽 2시에 발생한 무한 HTTPS 리디렉션 루프 (그리고 X-Forwarded-Proto가 제 사이트를 구한 방법)

(dev.to)

Dev.to DevOps2026년 4월 30일개발자 도구

새벽 2시에 발생한 무한 HTTPS 리디렉션 루프 (그리고 X-Forwarded-Proto가 제 사이트를 구한 방법)

Nginx와 Apache가 결합된 하이브리드 호스팅 환경에서 잘못된 .htaccess 설정으로 인해 발생한 HTTPS 무한 리디렉션 루프 문제와 그 해결책을 다룹니다. Nginx가 TLS를 종료(Termination)할 때 발생하는 프로토콜 불일치를 X-Forwarded-Proto 헤더를 통해 해결하는 방법을 제시합니다.

이 글의 핵심 포인트

1Nginx-Apache 하이브리드 환경에서 HTTPS 리디렉션 설정 시 무한 루프 발생 가능성
2Nginx의 TLS 종료(TLS Termination)로 인해 Apache는 요청을 HTTP로 인식하는 문제
3Apache의 %{HTTPS} 변수가 프록시 환경에서는 부정확할 수 있음
4해결책으로 Nginx가 전달하는 X-Forwarded-Proto 헤더를 참조하는 규칙 적용
5인프라 구조(Reverse Proxy 존재 여부)에 따른 .htaccess 설정의 차별화 필요

이 글에 대한 공공지능 분석

왜 중요한가

단순한 도메인 설정 변경이 서비스 중단과 SEO 에러라는 막대한 손실로 이어질 수 있음을 보여줍니다. 인프라의 구조를 이해하지 못한 채 관습적인 코드를 적용했을 때 발생하는 운영 리스크를 경고합니다.

배경과 맥락

많은 매니지드 호스팅(SiteGround, Cloudways 등)은 성능을 위해 Nginx를 리버스 프록시로, 기능성을 위해 Apache를 백엔드로 사용하는 하이브리드 스택을 사용합니다. 이 구조에서 SSL 인증서는 Nginx에서 처리되므로, 뒤에 있는 Apache는 실제 요청이 HTTPS인지 알 수 없는 상태가 됩니다.

업계 영향

개발자가 사용하는 스택의 '추상화된 계층' 뒤에 숨겨진 동작 원리를 파악하는 것이 얼마나 중요한지 시사합니다. Stack Overflow의 일반적인 답변을 맹신하기보다, 현재 운영 중인 인프라의 프록시 레이어를 반드시 확인해야 함을 강조합니다.

한국 시장 시사점

AWS(ALB, CloudFront)나 Cloudflare를 사용하는 한국 스타트업들에게도 매우 유효한 사례입니다. 로드 밸런서나 CDN 뒤에 서버를 배치할 때, 원본 서버(Origin)가 클라이언트의 실제 프로토콜을 인식하지 못해 발생하는 설정 오류를 방지하기 위한 기술적 대비가 필요합니다.

이 글에 대한 큐레이터 의견

이 사례는 기술적 부채나 단순한 실수라기보다 '인프라 가시성(Infrastructure Visibility)의 부재'에서 오는 전형적인 운영 사고입니다. 스타트업 창업자 관점에서 이러한 사고는 서비스 가용성(Availability)을 직접적으로 타격하며, 특히 검색 엔진 최적화(SEO)에 치명적인 에러를 남겨 장기적인 유입 감소를 초래할 수 있습니다.

개발자들에게는 '작동하는 코드'를 넘어 '환경을 이해하는 코드'를 작성할 것을 요구합니다. 특히 클라우드 네이티브 환경으로 갈수록 네트워크 계층이 복잡해지므로, X-Forwarded-Proto와 같은 헤더 전달 메커니즘을 이해하는 것은 단순한 트러블슈팅 능력을 넘어 안정적인 서비스를 구축하기 위한 필수 역량입니다. 따라서 배포 전 스테이징 환경에서 프록시 레이어를 포함한 전체 네트워크 흐름을 검증하는 프로세스를 구축하는 것이 실행 가능한 핵심 인사이트입니다.

원문 보기 →