This is a question about the "$status" log value when "proxy_read_timeout" occurs.

[박규철]

Hello.

I came to understand why 200 is stored in the $status variable when
proxy_read_timeout occurs.

Thank you for the reply.


2024년 1월 17일 (수) 오전 7:27, Maxim Dounin <mdounin at mdounin.ru>님이 작성:

> Hello!
>
> On Tue, Jan 16, 2024 at 01:15:09PM +0900, 박규철 wrote:
>
> > This is a question about the "$status" log value when
> "proxy_read_timeout"
> > occurs.
> > Nginx version in use: v1.25.3
> >
> > Contents of 1Mbyte size were requested to [Origin Server].
> > A response up to approximately 500Kbytes in size, including the header,
> was
> > received without delay.
> > However, after 500Kbytes, no response was received from Origin for 3
> > seconds and the connection (time-out)
> > Since the message "upstream timed out...while reading upstream" was
> logged
> > in the error log, I think the connection was lost due to the
> > "proxy_read_timeout 3s" setting.
> >
> > While checking the log, I noticed that the "$status" value in the access
> > log was different from what I thought.
> > In my opinion, if the connection was terminated by "proxy_read_timeout",
> > the "$status" value would be 5xx, but the "$status" value in the saved
> > access log was 200.
> >
> > A normal response was not completed due to "proxy_read_timeout", so I
> would
> > like to know why the "$status" value is stored as 200 instead of 5xx.
> > Should I check a variable other than "$status" for responses to abnormal
> > timeouts such as "proxy_read_timeout"?
>
> The $status variable shows the status as sent to the client in the
> response headers.  When proxy_read_timeout happens, the response
> headers are already sent, so $status contains 200 as sent to the
> client.
>
> For errors happened during sending the response body, consider
> looking into the error log.  Some generic information about
> successful request completion might be found in the
> $request_completion variable
> (http://nginx.org/r/$request_completion).  Note though that it
> might not be set for variety of reasons.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20240117/dc08aa41/attachment.htm>