HTTPS는 되는데 HTTP는 왜 안 될까?
NCP 리스너 설정으로 해결한 사례
도메인 연결과 SSL 인증서 적용까지 모두 마쳤다.
브라우저에서 https://example.com으로 접속했을 때도 문제없이 작동했다.
그런데 http://example.com으로 접속해보니 아무 반응이 없었다.
서버 로그에도 기록이 없고, 요청이 들어온 흔적조차 없었다.
결국 원인은 로드밸런서의 리스너 설정 부족이었다.
HTTP와 HTTPS, 뭐가 다를까?
웹사이트 주소는 http:// 또는 https://로 시작한다.
단순히 알파벳 하나의 차이처럼 보이지만, 실제로는 보안 수준이 크게 다르다.
- HTTP: 데이터를 암호화하지 않고 전송한다.
요청이 중간에 가로채이면, 내용이 그대로 노출될 수 있다. - HTTPS: SSL 인증서를 통해 데이터를 암호화해서 전송한다.
비밀번호, 쿠키, 개인정보 등을 안전하게 보호할 수 있다.
요즘은 대부분의 서비스가 HTTPS를 기본으로 사용한다.
브라우저는 HTTPS가 없는 사이트에 보안 경고를 띄우고,
검색 엔진도 HTTPS 사용 여부를 평가에 반영한다.
HTTPS는 잘 되는데 HTTP는 왜 안 될까?
HTTPS로 접속했을 때는 잘 작동했기 때문에,
서버나 포트 설정 문제는 아니라고 판단했다.
하지만 HTTP로 접속했을 땐 응답 자체가 없었다.
서버에 요청이 도달하지 않았다는 건,
로드밸런서에서 요청을 처리하지 못한 것이라는 의미다.
로드밸런서에서 리스너는 어떤 역할을 할까?
NCP의 로드밸런서는 요청을 받아 처리할 포트를
리스너(listener)를 통해 정의한다.
- 80 포트 리스너: HTTP 요청 수신
- 443 포트 리스너: HTTPS 요청 수신
LB는 리스너가 등록된 포트만 처리할 수 있기 때문에,
HTTP 요청을 처리하려면 80 포트 리스너가 반드시 필요하다.
해결 방법: HTTP 리스너 추가 + HTTPS 리디렉션 설정
문제 해결을 위해 다음 두 가지를 설정했다.
- 80 포트 리스너 추가
- HTTP 요청을 HTTPS로 리디렉션
설정 단계 (NCP 콘솔 기준)
1. 리스너 추가
- 포트: 80
- 프로토콜: HTTP
- 동작: 리디렉션
2. 리디렉션 규칙 설정
- 리디렉션 대상: https://${host}${path}
- 타겟 그룹은 연결하지 않음
→ 리디렉션만 수행하고 서버에 전달하지 않기 때문
설정 후 확인
이제 http://example.com으로 접속해보면
자동으로 https://example.com으로 리디렉션되고,
서버도 정상적으로 요청을 처리한다.
정리
- HTTP는 암호화되지 않은 연결이고,
HTTPS는 암호화된 안전한 연결이다. - NCP에서는 SSL 인증서를 서버가 아닌 로드밸런서에 등록한다.
서버는 항상 80 포트로 요청을 받는다. - HTTP 요청이 무시된다면, LB에 80 포트 리스너가 없을 가능성이 높다.
- HTTP 요청을 HTTPS로 전환하려면,
로드밸런서에서 리디렉션 설정을 직접 해야 한다.
참고: 서버에서 리디렉션하면 안 되는 이유
“그냥 Nginx에서 리디렉션 설정하면 안 되나?”라는 생각이 들 수 있다.
하지만 NCP 구조에서는 SSL 인증서가 서버가 아니라 LB에만 등록된다.
HTTP 요청도 LB에서 걸러지면 서버까지 도달하지 못하기 때문에,
리디렉션은 서버가 아닌 로드밸런서 레벨에서 처리해야 한다.
마무리
HTTPS만 적용했다고 해서 끝이 아니다.
HTTP 요청까지 안전하게 HTTPS로 전환되도록 유도하는 구성이 필요하다.
이번 설정을 통해, 단순히 보안을 적용하는 것을 넘어서
사용자의 진입 경로를 관리하고, 서비스를 완성도 있게 운영하는 방식을 배웠다.