HTTP 504 Gateway Timeout와 클라이언트 타임아웃

클라이언트는 60초를 기다릴 준비가 되어 있다. 그런데 10초 뒤에 HTTP 504를 받는다. 클라이언트 타임아웃을 2분으로 늘린다고 게이트웨이에 50초가 더 생기는 것은 아니다.

504는 요청을 완료하려는 동안 업스트림에서 제때 응답을 받지 못한 게이트웨이나 프록시를 뜻한다. 게이트웨이는 이미 결정을 내리고 응답을 돌려보냈다. 클라이언트는 그 응답을 문제없이 읽을 수 있다.

어느 중개자가 보냈는가

발신자는 포워드 프록시일 수 있다. 사이트가 운영하는 뒷단 게이트웨이일 수도 있다. CONNECT 내부의 일반적인 종단 간 TLS에서는 그 보호된 목적지 교환에서 나온 HTTP 응답이 CONNECT 자체의 거부와 같지 않다.

단계, 응답 헤더, 오류 페이지 문구, 그리고 가능하면 일치하는 로그를 남긴다. 서버 이름은 단서일 수 있지만 틀림없는 귀속으로 다루어서는 안 된다. 경로에는 클라이언트에 설정한 것보다 더 많은 중개자가 있을 수 있다.

그다음 그 업스트림 작업이 왜 끝나지 않았는지 살펴본다. 도달 가능성, 과부하된 서비스, 업스트림이 예상대로 처리하지 못하는 요청 본문, 애플리케이션 동작이 모두 관련될 수 있다. 숫자 상태만으로는 User-Agent를 바꾸거나 타임아웃 옵션 하나를 추가하는 것이 보편적 해법임을 증명하지 못한다.

같은 요청을 비교한다

다른 도구가 동작하면 메서드, 대상, 본문 인코딩, 인증, 경로를 비교한다. "브라우저에서 URL이 열린다"는 것은 서비스 클라이언트를 통한 multipart 전송과의 완전한 비교가 아니다.

발신 게이트웨이를 운영한다면 그 업스트림 예산을 지원되는 작업량과 주변 기한에 맞춘다. 운영하지 않는다면 그 결과를 증거로 남기고 운영자가 문서화한 접근 또는 지원 경로를 이용한다. 로컬에서 더 오래 기다린다고 이미 도착한 응답이 바뀌지는 않는다.