웹서버 로그에 프록시 또는 업스트림 오류가 보여요

프록시나 업스트림 요청에서 오류가 발생하면 응답 코드만 보고 서버 중단으로 판단하지 않습니다. 응답 본문과 요청 URL의 스킴·포트, TLS가 끝나는 구간을 함께 기록한 뒤 연결 실패, 응답 시간 초과와 HTTP/HTTPS 불일치를 구분합니다.

적용되는 시작 상황

다음 관찰값을 확인합니다.

• Bad Request: This combination of host and port requires TLS
• HTTP 502: Bad gateway
• HTTP 504: Gateway timeout
• Error 522: connection timed out

먼저 기록할 것

1. 문제가 발생한 URL 또는 기능과 최초 발생 시각을 기록합니다.
2. 화면, 브라우저 개발자 도구, 서버 로그, 관리자 도구 중 실제로 확인한 위치를 기록합니다.
3. 오류 문구 또는 상태 코드를 원문 그대로 기록합니다.
4. 클라이언트 요청 URL과 프록시 upstream의 스킴·호스트·포트를 기록합니다.
5. 브라우저, CDN, 로드 밸런서, 웹서버 중 TLS가 끝나는 구간을 확인합니다.
6. 최근 배포·설정·도메인·프록시 변경이 있었다면 변경 시각과 범위를 기록합니다.

상황별 다음 단계

HTTP와 HTTPS 포트가 맞지 않는지 확인합니다

오류 원문에 This combination of host and port requires TLS가 있으면 연결 시간 초과보다 요청 스킴을 먼저 확인합니다. 예를 들어 TLS가 설정된 8443 포트를 http://로 요청하면 서버가 평문 요청을 거부할 수 있습니다. 포트 번호만으로 프로토콜을 추정하지 말고 현재 서버 설정과 실제 요청 URL을 비교합니다.

확인할 요청: https://backend.example.com:8443/잘못된 요청: http://backend.example.com:8443/

프록시에서 TLS를 끝낸 뒤 원본에는 HTTP로 전달하는 구성도 있고, 원본까지 HTTPS로 전달하는 구성도 있습니다. 브라우저 주소만 바꾸지 말고 프록시 upstream 설정과 원본의 수신 방식을 같은 구간끼리 비교합니다. X-Forwarded-Proto 헤더만 바꿔도 실제 평문 연결이 TLS로 바뀌지는 않습니다.

Spring Boot 내장 Tomcat이면 server.port와 server.ssl.*, Elasticsearch이면 http.port와 xpack.security.http.ssl.enabled를 확인합니다. HTTPS로 전환한 뒤 인증서 신뢰 오류가 발생하면 검증을 끄지 말고 서버 인증서를 서명한 CA를 클라이언트가 신뢰하도록 설정합니다.

수정 후 재확인합니다

1. 변경 전 요청 스킴·호스트·포트와 오류 원문을 기록합니다.
2. 클라이언트에서 프록시, 프록시에서 원본으로 이어지는 각 요청 구간을 확인합니다.
3. 한 구간만 수정하고 같은 요청을 다시 실행합니다.
4. 오류가 사라졌거나 다음 정상 인증 단계로 바뀌었는지 확인합니다.
5. 프록시와 원본 로그에서 같은 오류 원문이 다시 발생하지 않는지 확인합니다.

curl -k, verify_certs: false, NODE_TLS_REJECT_UNAUTHORIZED=0으로 인증서 검증을 끈 결과는 완료로 판단하지 않습니다. 위 조건과 일치하지 않으면 원문을 보존하고 담당자에게 전달합니다. 비밀번호·토큰·세션 쿠키·결제 정보·개인정보는 전달하지 않습니다.