Summary

본 포스트에서는 평소 헷갈리고 난해하게 느껴졌던 두 가지 개념에 대해 학습한 내용을 정리해봤습니다.

• trust proxy 설정
  • e.g. Express 에서의 설정
• X‑Forwarded‑Proto Header

이 두 개념이 왜 필요한지, nginx 등 리버스 프록시(Reverse Proxy) 구조를 사용하는 서버 구성에서 어떤 역할을 하는지, 그리고 실제로 어떻게 설정해야 하는지에 대해 학습하고 이해한 내용을 정리해봤습니다!

1. 기본 개념 정리

1.1 리버스 프록시 서버(Reverse Proxy Server) 환경에서 생기는 문제

Reverse Proxy Server 뒤에 애플리케이션 서버를 두는 경우에 다음과 같은 이슈가 생깁니다.

• 클라이언트가 실제로 HTTPS (혹은 HTTP) 로 접속했는지, 애플리케이션 서버가 알기 어습니다. Proxy 에서 SSL 을 해제하고 내부적으로 HTTP 로 넘길 수 있기 때문입니다.
• 클라이언트의 실제 IP 주소가 프록시 서버의 IP 로 보일 수 있습니다. 즉, req.connection.remoteAddress 등이 클라이언트가 아닌 프록시 IP 로 나올 수 있습니다.
• 호스트명(host), 포트(port), 스킴(scheme, HTTP vs HTTPS) 등이 프록시 환경에서 왜곡되거나 누락될 수 있습니다.

이런 문제들 때문에 애플리케이션 레벨에서 내 뒤에 신뢰할 수 있는 프록시가 있다 는 것을 인식하고, 프록시가 전달해준 헤더(e.g. X‑Forwarded‑Proto, X‑Forwarded‑For, X‑Forwarded‑Host) 를 신뢰하거나 해석할 수 있도록 설정해주는 것이 중요합니다.

1.2 X‑Forwarded‑Proto Header

• X‑Forwarded‑Proto Header 는 클라이언트가 어떤 스킴(scheme) 으로 요청했는지를 프록시가 애플리케이션 서버에 전달하는 용도로 흔히 사용됩니다.
• 예를 들어 클라이언트가 https://example.com 으로 접속했고 프록시가 SSL 종료(termination) 를 한 뒤 내부적으로 애플리케이션 서버로 http:// 요청을 한다면, 프록시는 X‑Forwarded‑Proto: https Header 를 붙여서 원래는 HTTPS 였어요 라고 알려줄 수 있습니다.
• 애플리케이션 서버에서는 이 헤더를 보고 req.protocol (Express 기준) 을 https 로 인식하게 할 수 있습니다.
• 다만 이 헤더가 클라이언트에서 임의로 조작될 수 있으므로, 신뢰할 수 있는 프록시 뒤에서만 헤더를 믿겠다 (trust proxy) 식의 설정이 필요합니다.
• 또한 nginx 등의 설정에서 proxy_set_header X‑Forwarded‑Proto $scheme; 같은 형태로 설정할 때 주의해야 합니다. 만약 Load Balancer → nginx → Application 라인의 흐름이라면 중간에서 헤더가 덮어쓰기(overwrite) 될 수 있습니다.