<aside>
☁️ 클라우드웨이브 시리즈 · W02 · 4/5 · 예상 읽기 6~8분
</aside>
애플리케이션이 외부 요청을 모두 직접 받아야 한다고 생각했지만, 앞단 계층을 두면 보호와 관찰의 책임을 분리할 수 있다.
TLS는 상대를 인증하고 전송 구간을 보호한다. 리버스 프록시는 외부 요청을 받아 내부 애플리케이션으로 전달하며 TLS 종료, 경로 분기, 제한, 분산을 수행할 수 있다. 인증서와 개인 키는 공개 글에 포함하지 않는다.
수신 포트, 서버 이름, 경로별 처리, 백엔드 전달 순서로 설정을 읽는다. 적용 전 구문을 확인하고 변경 후 프록시 로그와 애플리케이션 로그를 함께 본다.
server {
listen 443 ssl;
server_name example.com;
location / { proxy_pass http://app_backend; }
}
flowchart LR
A["관찰"] --> B["원인 분리"]
B --> C["안전한 변경"]
C --> D["다시 확인"]
외부에는 단일 진입점을 두고 내부 서비스 노출을 줄인다. TLS 성공, 라우팅 성공, 백엔드 성공은 각각 별도 확인 대상이다.
포워드 프록시는 사용자를 대신해 외부로 나가고 리버스 프록시는 서버를 대신해 내부로 전달한다. TLS 종료가 내부 구간 보호까지 자동으로 해결하지도 않는다.
프록시를 점검할 때는 클라이언트와 내부 웹 서버 사이에서 어느 계층이 요청을 받고 전달하는지 먼저 구분해야 한다. 포워드 프록시는 클라이언트 대신 외부 요청을 처리하는 방향이고, 리버스 프록시는 외부 요청을 받아 내부 서버로 전달하는 방향이다. 여기에 SSL 또는 TLS 처리가 프록시에서 끝나는지, 내부 애플리케이션까지 이어지는지에 따라 확인해야 할 설정과 관찰 지점이 달라진다. 따라서 외부에서 들어온 요청의 수신 지점, 내부로 전달되는 대상, 암호화 처리가 끝나는 지점을 나누어 본다. 그래야 프록시의 연결 문제와 애플리케이션의 응답 문제를 한 원인으로 오해하지 않는다.