[Nginx] Docker Nginx 리버스 프록싱이 되지 않을 때

DoubleDeltas·2025년 4월 29일

오류해결

목록 보기
5/5

증상

  • docker compose를 사용해 네트워크를 구축하고 컨테이너를 연결하고 있었다.
  • Nginx Docker에서 도커 네트워크에 있는 다른 컨테이너에 proxy_pass가 되지 않는 문제가 발생했다.
  • 컨테이너의 네트워크는 모두 연결되어 있었고, curl 등을 보내봐도 응답이 잘 날아오지만, nginx를 통해 보내면 응답이 정상하지 않아 524 timeout이 발생하는 상황이었다.

발견

  • nginx가 실제로 연결하는 주소인 $upstream_addr를 알아내기 위해 다음과 같이 로그 포맷을 만들어 지정했다.
http {
  log_format with_upstream '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'upstream: $upstream_addr';
  
  ...
  
  server {
		access_log /var/log/nginx/access.log with_upstream;
  }
  
}
  • 이후 로그를 보니, 도커 네트워크 내부 주소인 172.0.0.x가 아닌 이상한 주소로 연결되어 있었다. 검색을 해보니, 해당 서버 컴퓨터에서 사용 중이던 ISP의 DNS 서버 주소였다. 즉, nginx가 외부 네트워크에서 도커 상의 주소를 찾으려다 실패해 생기는 오류였던 것이다.

해결

  • docker-compose.yml의 nginx 컨테이너 블록에, 아래와 같은 블록을 집어넣는다.
dns:
  - 127.0.0.11
  • dns는 말 그대로 해당 도커 컨테이너의 dns 주소를 강제로 설정하는 블록이다. 127.0.0.11은 docker network가 사용하는 DNS IP 주소이다.
  • 설정 후 docker compose를 다시 up 했더니 정상적으로 연결됨을 확인할 수 있었다.

하소연

  • ChatGPT의 도움을 받았지만, 환각 현상 때문에 몇 번 길을 돌아갔던 것 같다. (다른 주소로 redirection 되고 있다느니... 업스트림 주소를 넣어달라니깐 호스트 주소를 넣는던지...)
  • 환각 현상보다 문제해결을 더 괴롭혔던 것은 서버를 켜기만 하면 집요하게 문을 두드려보는 웹 스캐너 봇들이었다. robots.txt 따위 보지 않고 GET 요청을 찔러대는 봇들 때문에, 문제를 파악하는 것이 더 어려웠다. (POST 요청이 GET 요청으로 바뀌는 오류인 줄 알았다.)
profile
유사 개발자

0개의 댓글