게시판에 502가 뜨면 애플리케이션부터 재시작하고 싶어집니다. 그런데 앱이 8081번 포트에서 정상 동작하고 Nginx만 8080번으로 요청을 보내는 상황이라면, 재시작을 반복해도 같은 화면을 보게 됩니다. 이 글은 Nginx와 HTTP 애플리케이션이 같은 Linux 서버에서 실행되고, Nginx 오류 로그에 연결 거절이 찍힌 상황을 다룹니다.
오류 로그에 찍힌 목적지
Nginx에서 upstream은 요청을 넘겨받는 뒤쪽 서버를 뜻합니다. 브라우저의 502 화면을 확인했다면, 먼저 실패한 요청의 시각과 경로를 기준으로 Nginx 오류 로그를 찾습니다. 아래는 게시판 조회 요청에 대해 구성한 가상 로그입니다.
2026/11/06 10:00:10 [error] *42 connect() failed (111: Connection refused) while connecting to upstream, request: "GET /board HTTP/1.1", upstream: "http://127.0.0.1:8080/board"이 줄에서 볼 것은 실패 단계와 목적지입니다. while connecting to upstream은 뒤쪽 서버에 연결을 맺는 단계였다는 뜻이고, upstream에는 그 요청에서 Nginx가 실제로 연결을 시도한 주소와 포트가 들어 있습니다. 이 경우 확인할 대상은 127.0.0.1:8080입니다. NGINX 이슈 트래커 — upstream 연결 거절과 502 사례
같은 502라도 연결 후 응답 헤더를 읽는 단계에서 실패했다면 조사 범위가 달라집니다. 여기서는 오류 로그에 Connection refused가 있는 요청만 골라 앱 상태와 연결 설정을 비교합니다.
앱 종료와 포트 불일치의 증거
포트를 확인할 때는 숫자와 함께 어느 주소에서 어떤 프로세스가 연결을 받는지 봅니다. 아래 명령은 앱이 board.service라는 systemd 서비스로 실행된다는 가정입니다. 실제 환경에서는 서비스 이름과 로그 조회 시각을 바꿔 실행합니다.
sudo ss -ltnp
systemctl status board.service --no-pager
sudo journalctl -u board.service --since '2026-11-06 09:58:00' --until '2026-11-06 10:03:00' --no-pagerss -ltnp는 현재 연결을 받는 TCP 소켓과 주소·포트, 확인 가능한 프로세스 정보를 보여 줍니다. Linux 매뉴얼 — ss
systemctl status는 서비스의 현재 상태를 보는 데 쓰고, journalctl -u는 오류가 난 시각 전후의 종료·재기동 기록을 찾는 데 씁니다. 장애 후 자동으로 앱이 올라왔다면 현재 상태는 active로 보일 수 있습니다. systemd 공식 매뉴얼 — journalctl
| 장애 시점과 대조할 관찰 | 다음 확인 |
|---|---|
| 8080에서 연결을 받는 앱이 없고, 첫 502 직전에 앱 종료가 기록됨 | 종료 전후 앱 로그에서 종료 원인과 정상 재기동 여부를 확인합니다. |
| 앱이 127.0.0.1:8081에서 연결을 받고 응답하지만, Nginx 로그에는 8080이 찍힘 | 배포 기준의 포트를 확인해 Nginx 연결 설정과 앱 시작 설정 중 어느 쪽이 달라졌는지 확인합니다. |
| 지금은 8080이 열려 있지만 장애 당시 앱 기록을 확보하지 못함 | 당시 종료 여부는 보류하고 첫 502 시각, 배포·재기동 이력, 오류가 사라진 시각을 대조합니다. |
설정 대조와 같은 경로 재검증
포트가 엇갈렸다면 실행 중인 Nginx와 같은 바이너리와 설정 경로를 기준으로 nginx -T를 확인합니다. 실패한 호스트와 요청 경로에 해당하는 server·location에서 proxy_pass의 목적지를 찾고, 그룹 이름이 지정돼 있으면 해당 upstream 블록의 서버 주소와 포트까지 따라갑니다. NGINX 공식 문서 — proxy_pass
nginx -T는 디스크의 설정 파일을 검사하고 출력합니다. 수정한 파일이 아직 재적용되지 않았다면 로그에 기록된 연결 대상과 다를 수 있으므로 최근 설정 변경·재적용 기록도 확인합니다. NGINX 공식 문서 — 명령줄 옵션
8081이 의도된 포트라면 아래처럼 앱의 읽기 전용 경로를 직접 확인합니다. 이 예시는 Nginx가 /board를 같은 경로로 전달한다고 가정합니다. 실제로는 upstream에 전달되는 경로와 필요한 Host 헤더를 맞춰야 합니다.
curl -i --max-time 5 http://127.0.0.1:8081/board8081에서 기대한 응답을 확인했다면 배포 기준에 따라 잘못된 쪽의 설정을 수정합니다. Nginx 설정을 바꾼 경우 nginx -t로 검사한 뒤 운영 절차에 따라 재적용합니다. 이후 실제 서비스 주소에서 같은 게시판 조회를 다시 실행해 기대한 응답이 돌아오는지, 같은 연결 거절이 다시 찍히지 않는지 확인합니다.
결론
장애 기록에는 첫 502 시각, Nginx가 시도한 주소·포트, 앱이 연결을 받던 주소·포트, 그 시간대의 종료·재기동 기록을 함께 남깁니다. 종료 기록이 맞물리면 앱이 내려간 이유를 조사하고, 앱이 다른 포트에서 응답했다면 배포 기준과 양쪽 설정의 차이를 찾습니다. 당시 기록이 부족하다면 확인한 사실까지만 남겨 두는 편이 다음 조사에 도움이 됩니다.