502 Bad Gateway
`502 Bad Gateway`는 프록시 또는 게이트웨이가 업스트림 서버에서 유효하지 않은 응답을 받았을 때 표시됩니다. 오류 화면의 Cloudflare 브랜딩과 같은 시각의 프록시·원본 로그를 구분해 확인합니다.
빠른 답변
- 우선 확인할 원인
- 502 Bad Gateway가 보이면 먼저 오류 화면의 응답 주체를 확인하고, 같은 시각의 프록시·로드 밸런서·원본 서버 로그에서 업스트림 응답 오류를 찾아야 합니다. 502만으로 특정 언어·CMS·호스팅 원인을 단정할 수는 없습니다.
- 먼저 확인할 항목
- 오류 화면 또는 HTTP 응답에 `502 Bad Gateway`가 표시되는지 확인하고, 전체 URL·발생 시각·응답 헤더를 기록합니다.
- 적용 범위
- 현재 증상과 본문에 적은 관찰 조건이 함께 확인된 경우
- 출처 확인일
- 2026-08-29
- 최종 검토
- 2026-08-29
- 수정일
- 2026-08-29
- 정정 이력
- 2026-07-29 이후 기록 없음
- 관련 기술
현재 증상
- 애플리케이션 오류 메시지
- 사이트 접속 불가
먼저 확인할 항목
오류 화면 또는 HTTP 응답에 `502 Bad Gateway`가 표시되는지 확인하고, 전체 URL·발생 시각·응답 헤더를 기록합니다.
Cloudflare를 쓰는 사이트라면 Cloudflare 브랜딩 유무를 확인합니다. 브랜딩이 있으면 원본 서버가 표준 502를 반환한 경우이며, 브랜딩이 없는 빈 오류 화면이면 Cloudflare에서 발생한 오류일 수 있습니다.
프록시 또는 로드 밸런서와 원본 서버의 같은 시각 로그에서 업스트림 연결·응답 형식·원본 서버 오류를 확인합니다.
한 항목을 수정했다면 같은 URL을 다시 요청해 502가 사라졌는지, 프록시를 거치지 않은 요청과 결과가 다른지 확인합니다.
피해야 할 조치
주의
- 502만으로 PHP, WordPress, IIS, Nginx, AWS 등 특정 환경의 원인을 단정하지 않습니다.
- 오류 화면과 로그를 확인하지 않은 채 프록시 설정·헤더·리다이렉트·서버 구성을 한 번에 변경하지 않습니다.
환경별 원인과 조치
증상
브라우저 또는 HTTP 클라이언트에 502 Bad Gateway가 표시됩니다. 이 코드는 프록시·게이트웨이·로드 밸런서가 업스트림 서버에서 유효하지 않은 응답을 받은 상태를 뜻합니다.
확인
- 오류가 난 전체 URL, 발생 시각, 응답 헤더를 기록합니다.
- Cloudflare를 쓴다면 오류 화면에 Cloudflare 브랜딩이 있는지 확인합니다.
- 프록시 또는 로드 밸런서와 원본 서버에서 같은 시각의 로그를 확인합니다.
Cloudflare 브랜딩이 있으면 원본 서버가 표준 502를 반환한 경우입니다. 브랜딩이 없는 빈 오류 화면이면 Cloudflare에서 발생한 오류일 수 있습니다. 두 경우의 담당 영역이 다르므로 화면을 먼저 구분합니다.
Nginx에서 502가 보일 때
Nginx가 오류 화면을 반환했다면 먼저 적용 중인 업스트림 주소와 같은 시각의 로그를 비교합니다. 502만 보고 Nginx, 애플리케이션, PHP-FPM 중 하나를 원인으로 정하지 않습니다.
1. 적용 중인 설정을 확인합니다
운영 서버에서 아래 명령을 실행할 권한이 있다면 설정을 변경하지 않고 결과만 확인합니다.
nginx -Tnginx -T는 설정 문법을 검사하고 Nginx가 읽은 설정을 출력합니다. 결과에서 오류가 난 server·location의 proxy_pass 또는 fastcgi_pass 대상 주소를 확인합니다. 출력에 인증 정보나 내부 주소가 포함될 수 있으므로 원문 전체를 외부에 게시하지 않습니다.
PHP-FPM을 사용한다면 Nginx의 fastcgi_pass 대상과 PHP-FPM pool의 listen 값을 비교합니다. 한쪽이 TCP 주소와 포트를 사용하고 다른 쪽이 Unix 도메인 소켓을 사용하거나, 소켓 경로가 다르면 같은 대상을 가리키지 않습니다. Unix 도메인 소켓이면 웹 서버 프로세스가 접근할 수 있도록 설정된 listen.owner, listen.group, listen.mode도 함께 기록합니다.
2. 업스트림 관찰값을 같은 요청으로 묶습니다
Nginx는 다음 값을 접근 로그 형식에 기록할 수 있습니다.
| 로그 변수 | 확인할 값 |
|---|---|
$upstream_addr | 실제로 선택된 업스트림 IP·포트 또는 Unix 도메인 소켓 |
$upstream_status | 업스트림이 반환한 상태 또는 업스트림을 선택하지 못했을 때의 502 |
$upstream_connect_time | 업스트림 연결에 걸린 시간 |
$upstream_header_time | 업스트림 응답 헤더를 받기까지 걸린 시간 |
$upstream_response_time | 업스트림 응답을 받는 데 걸린 시간 |
현재 로그에 이 값이 없다면 장애 중에 즉시 형식을 바꾸지 말고, 기존 오류 로그와 접근 로그에서 전체 URL·발생 시각·요청 식별자를 먼저 맞춥니다. 로그 형식 변경은 별도의 검토와 재현 계획을 세운 뒤 적용합니다.
3. 관찰 결과에 따라 다음 확인 대상을 정합니다
| 관찰 결과 | 다음 확인 |
|---|---|
proxy_pass·fastcgi_pass 대상이 계획한 주소와 다름 | 현재 설정의 대상 주소와 실제 애플리케이션 수신 주소를 담당자와 비교합니다. |
| Nginx 로그에는 요청이 있고 업스트림 애플리케이션 로그에는 같은 요청이 없음 | 두 서버 사이의 주소·포트·소켓 경로와 접근 권한을 확인합니다. |
| 업스트림 애플리케이션 로그에 같은 요청과 오류가 있음 | Nginx 설정을 먼저 바꾸지 않고 해당 애플리케이션 오류를 기준으로 확인합니다. |
| 502가 일정 시간이 지난 뒤 발생함 | 504와 혼동하지 않도록 실제 상태 코드와 upstream_*_time을 확인합니다. proxy_read_timeout은 전체 요청 시간이 아니라 연속 읽기 사이의 제한 시간입니다. |
설정을 수정하기로 했다면 먼저 다음 명령으로 문법과 참조 파일을 검사합니다.
nginx -t검사가 통과했다는 사실은 업스트림 주소와 애플리케이션 상태가 정상이라는 뜻이 아닙니다. 설정 적용 전후에 같은 URL과 로그 값을 비교해야 합니다.
재확인
업스트림 응답 또는 프록시 설정에서 확인한 한 항목만 수정한 뒤 같은 URL을 다시 요청합니다. 가능하면 프록시를 거치지 않은 요청과 경유 요청의 결과도 비교합니다.
주의
502만으로 특정 언어·CMS·호스팅의 원인을 단정하지 마세요. 로그 확인 없이 프록시 설정, 헤더, 리다이렉트, 서버 구성을 한 번에 바꾸지 않습니다.
관찰값 기록
문제가 발생한 URL 또는 화면, 표시 시각, 운영 환경과 최근 변경 사항을 먼저 기록합니다. 화면이나 로그에 오류 문구가 일부만 보이면 앞뒤 문장을 보존하고 비밀번호·토큰·쿠키·개인정보는 가립니다.
다음 항목을 실제 값과 함께 확인합니다.
- 오류 화면 또는 HTTP 응답에
502 Bad Gateway가 표시되는지 확인하고, 전체 URL·발생 시각·응답 헤더를 기록합니다. - Cloudflare를 쓰는 사이트라면 Cloudflare 브랜딩 유무를 확인합니다. 브랜딩이 있으면 원본 서버가 표준 502를 반환한 경우이며, 브랜딩이 없는 빈 오류 화면이면 Cloudflare에서 발생한 오류일 수 있습니다.
- 프록시 또는 로드 밸런서와 원본 서버의 같은 시각 로그에서 업스트림 연결·응답 형식·원본 서버 오류를 확인합니다.
- 한 항목을 수정했다면 같은 URL을 다시 요청해 502가 사라졌는지, 프록시를 거치지 않은 요청과 결과가 다른지 확인합니다.
판정 기준
오류 문구가 일치해도 같은 원인이 확정되는 것은 아닙니다. 웹서버·런타임·운영체제·플랫폼과 최근 변경 사항을 비교하고, 기대한 관찰값이 나오지 않으면 다음 단계로 넘어가지 않습니다. 이 문서는 출처가 확인한 범위만 설명하며, 범위를 벗어난 원인과 조치는 단정하지 않습니다.
안전한 다음 확인
설정·권한·데이터를 변경하기 전에 백업과 되돌리기 방법을 기록합니다. 운영 환경의 방화벽 전체 해제, 인증서 검증 우회, 데이터 삭제, 비밀값 공개를 기본 조치로 사용하지 않습니다. 확인 결과가 문서의 조건과 다르면 관련 Platform·Component 문서와 공식 출처를 먼저 확인합니다.
참고 자료
AWS · 공식 자료 · 확인 범위: AWS Application Load Balancer는 대상에 연결하려 할 때 TCP RST를 받으면 HTTP 502 Bad gateway를 반환할 수 있다고 설명합니다. · 확인일: 2026-07-27
MDN Web Docs (Mozilla) · 공식 자료 · 확인 범위: HTTP 502는 게이트웨이 또는 프록시 역할의 서버가 업스트림 서버에서 유효하지 않은 응답을 받았음을 나타냅니다. · 확인일: 2026-07-27
Cloudflare · 공식 자료 · 확인 범위: 원본 웹 서버가 표준 HTTP 502 응답을 반환하면 Cloudflare는 Cloudflare 브랜딩이 있는 HTTP 502 오류를 반환합니다., Cloudflare에서 발생한 502 오류는 Cloudflare 브랜딩이 없는 빈 페이지로 나타날 수 있습니다. · 확인일: 2026-07-27
NGINX · 공식 자료 · 확인 범위: Nginx의 proxy_pass는 요청을 지정한 업스트림 주소나 Unix 도메인 소켓으로 전달합니다., proxy_read_timeout은 전체 응답 시간이 아니라 업스트림의 두 연속 읽기 사이의 제한 시간이며, 그 시간 안에 데이터가 없으면 연결을 닫습니다. · 확인일: 2026-08-29
NGINX · 공식 자료 · 확인 범위: Nginx는 업스트림 주소, 연결 시간, 헤더 수신 시간, 전체 응답 시간과 업스트림 상태를 로그 형식에 사용할 수 있는 변수로 제공합니다., 업스트림 서버를 선택하지 못하면 upstream_status에는 502가 기록됩니다. · 확인일: 2026-08-29
NGINX · 공식 자료 · 확인 범위: Nginx의 fastcgi_pass는 요청을 지정한 FastCGI 서버 주소로 전달합니다., fastcgi_pass에는 IP와 포트 또는 Unix 도메인 소켓을 지정할 수 있습니다. · 확인일: 2026-08-29
NGINX · 공식 자료 · 확인 범위: nginx -t는 설정 문법과 설정에서 참조한 파일을 검사합니다., nginx -T는 같은 검사를 수행하고 적용된 설정 파일도 출력합니다. · 확인일: 2026-08-29
The PHP Group · 공식 자료 · 확인 범위: PHP-FPM pool의 listen은 FastCGI 요청을 받을 IP와 포트 또는 Unix 도메인 소켓 경로를 지정합니다., Unix 도메인 소켓을 사용할 때 listen.owner, listen.group, listen.mode로 웹 서버의 읽기·쓰기 권한을 설정할 수 있습니다. · 확인일: 2026-08-29