502 (Bad Gateway) response

증상

Apache httpd mod_proxy 경유 요청의 응답 상태가 502 (Bad Gateway) response입니다.

확인

1. 현재 프록시 경유 요청의 응답 상태가 502 (Bad Gateway) response인지 확인합니다.
2. 원본 서버 응답 헤더에 콜론 없는 행이 있는지와 현재 ProxyBadHeader 설정이 IsError인지 확인합니다.

이 두 조건이 함께 확인되면 mod_proxy가 요청을 중단하고 502를 반환하는 동작과 일치합니다.

관련 동작

• IsError는 요청을 중단하고 502 (Bad Gateway) response가 됩니다. 기본값입니다.
• Ignore는 잘못된 헤더 행을 전송되지 않은 것처럼 처리합니다.
• StartBody는 첫 번째 잘못된 헤더 행을 받은 뒤 헤더 읽기를 끝내고 나머지를 본문으로 처리합니다.

StartBody는 헤더와 본문 사이의 빈 행을 넣지 않는 백엔드 서버를 처리하는 데 도움이 될 수 있습니다.

재확인과 주의

원본 응답 헤더 형식을 먼저 수정하거나 설정 한 항목만 변경한 뒤 같은 프록시 경유 요청에서 502가 사라졌는지 확인합니다. ProxyBadHeader Ignore 또는 StartBody는 비정상 헤더를 허용하거나 본문으로 처리해 응답 의미가 달라질 수 있으므로, 원본 서버 응답을 확인하지 않은 채 기본 동작을 바꾸지 마세요.

관찰값 기록

문제가 발생한 URL 또는 화면, 표시 시각, 운영 환경과 최근 변경 사항을 먼저 기록합니다. 화면이나 로그에 오류 문구가 일부만 보이면 앞뒤 문장을 보존하고 비밀번호·토큰·쿠키·개인정보는 가립니다.

다음 항목을 실제 값과 함께 확인합니다.

1. 현재 프록시 경유 요청의 응답 상태가 502 (Bad Gateway) response인지 확인합니다.
2. 원본 서버 응답 헤더에 콜론 없는 행이 있는지와 현재 ProxyBadHeader 설정이 IsError인지 확인합니다.
3. 원본 응답 헤더 형식을 먼저 수정하거나 설정 한 항목만 변경한 뒤, 같은 프록시 경유 요청에서 502가 사라졌는지 확인합니다.

판정 기준

오류 문구가 일치해도 같은 원인이 확정되는 것은 아닙니다. 웹서버·런타임·운영체제·플랫폼과 최근 변경 사항을 비교하고, 기대한 관찰값이 나오지 않으면 다음 단계로 넘어가지 않습니다. 이 문서는 출처가 확인한 범위만 설명하며, 범위를 벗어난 원인과 조치는 단정하지 않습니다.

안전한 다음 확인

설정·권한·데이터를 변경하기 전에 백업과 되돌리기 방법을 기록합니다. 운영 환경의 방화벽 전체 해제, 인증서 검증 우회, 데이터 삭제, 비밀값 공개를 기본 조치로 사용하지 않습니다. 확인 결과가 문서의 조건과 다르면 관련 Platform·Component 문서와 공식 출처를 먼저 확인합니다.

원인 분포

[Observation] 수집된 3건에서 확인된 원인 범위는 다음과 같습니다. 이는 관측된 사례 기준이며 실제 발생 빈도를 의미하지 않습니다.

• [Observation] 백엔드 keepalive 연결 재사용 중 백엔드가 연결을 닫는 경쟁 상태가 IBM 사례와 Server Fault 사례에서 제시되었습니다.
• [Observation] 네트워크 상태와 백엔드 동작은 Red Hat 사례에서 원인 범위로 제시되었습니다.
• [Observation] Timeout 또는 ProxyTimeout 설정은 Red Hat 사례에서 확인 대상으로 제시되었습니다.
• [Hypothesis] 동일한 오류 문구가 있어도 연결 재사용 경쟁 상태, 네트워크·백엔드 문제, 시간 제한 문제를 구분해야 합니다.

오진 함정

• [Observation] proxy: error reading status line from remote server와 502만으로 원인을 확정할 수 없습니다. Red Hat 사례는 네트워크·백엔드·keepalive·과거 프록시 경쟁 상태를 함께 원인 범위로 제시합니다.
• [Observation] 일부 요청만 실패하더라도 프록시 연결 재사용 경로가 관련될 수 있습니다. Server Fault 사례에서는 직접 백엔드 연결은 성공했지만 프록시 경로에서 일부 요청이 실패했습니다.
• [Observation] 백엔드에 직접 연결했을 때 성공한다는 사실만으로 백엔드 자체 문제를 배제할 수는 없습니다. 프록시의 keepalive 재사용 설정이 별도 변수로 남습니다.

환경 매트릭스

환경	관찰된 증상	사례에서 확인된 관련 조건 또는 조치
IBM HTTP Server + mod_proxy_http + Apache httpd 2.2.x	간헐적 상태 줄 읽기 오류와 502	백엔드 keepalive 재사용 중 연결 종료 경쟁 상태, PK96410 수정본
JBoss EAP + Apache httpd + mod_proxy	상태 줄 읽기 오류 후 502	네트워크·백엔드·keepalive·프록시 경쟁 상태 확인, Timeout/ProxyTimeout 및 proxy-nokeepalive 검토
Apache 2.2 + SOAP 백엔드 역방향 프록시	일부 요청 실패, 직접 연결은 성공	연결 재사용 경로, force-proxy-request-1.0·proxy-nokeepalive·proxy-initial-not-pooled 검토

진단 순서

1. [Observation] 프록시 로그에서 proxy: error reading status line from remote server와 502의 발생 시점 및 간헐성 여부를 확인합니다.
2. [Observation] 동일 요청을 프록시 없이 백엔드에 직접 연결해 결과 차이를 확인합니다. Server Fault 사례에서는 직접 연결이 성공했습니다.
3. [Observation] 백엔드 keepalive 연결 재사용 및 연결 종료 시점의 경쟁 가능성을 확인합니다.
4. [Observation] 네트워크와 백엔드 상태, Timeout 또는 ProxyTimeout 조건을 확인합니다.
5. [Observation] 사용 중인 Apache httpd 버전과 과거 프록시 경쟁 상태 수정 여부를 확인합니다. 사례에는 Apache httpd 2.2.10 및 IBM PK96410이 관련 수정으로 제시되었습니다.
6. [Observation] 연결 재사용 회피가 필요하면 사례에 제시된 proxy-nokeepalive, force-proxy-request-1.0, proxy-initial-not-pooled 설정의 적용 가능성을 검토합니다.
7. [Observation] 수정 후 같은 조건에서 502와 상태 줄 읽기 오류가 재현되지 않는지 확인합니다.