<div dir="ltr"><div dir="ltr">Hello.<br></div><div dir="ltr"><br></div><div dir="ltr">I came to understand why 200 is stored in the $status variable when proxy_read_timeout occurs.<br><br>Thank you for the reply. <br></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2024년 1월 17일 (수) 오전 7:27, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>님이 작성:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Tue, Jan 16, 2024 at 01:15:09PM +0900, 박규철 wrote:<br>
<br>
> This is a question about the "$status" log value when "proxy_read_timeout"<br>
> occurs.<br>
> Nginx version in use: v1.25.3<br>
> <br>
> Contents of 1Mbyte size were requested to [Origin Server].<br>
> A response up to approximately 500Kbytes in size, including the header, was<br>
> received without delay.<br>
> However, after 500Kbytes, no response was received from Origin for 3<br>
> seconds and the connection (time-out)<br>
> Since the message "upstream timed out...while reading upstream" was logged<br>
> in the error log, I think the connection was lost due to the<br>
> "proxy_read_timeout 3s" setting.<br>
> <br>
> While checking the log, I noticed that the "$status" value in the access<br>
> log was different from what I thought.<br>
> In my opinion, if the connection was terminated by "proxy_read_timeout",<br>
> the "$status" value would be 5xx, but the "$status" value in the saved<br>
> access log was 200.<br>
> <br>
> A normal response was not completed due to "proxy_read_timeout", so I would<br>
> like to know why the "$status" value is stored as 200 instead of 5xx.<br>
> Should I check a variable other than "$status" for responses to abnormal<br>
> timeouts such as "proxy_read_timeout"?<br>
<br>
The $status variable shows the status as sent to the client in the <br>
response headers. When proxy_read_timeout happens, the response <br>
headers are already sent, so $status contains 200 as sent to the <br>
client.<br>
<br>
For errors happened during sending the response body, consider <br>
looking into the error log. Some generic information about <br>
successful request completion might be found in the <br>
$request_completion variable <br>
(<a href="http://nginx.org/r/$request_completion" rel="noreferrer" target="_blank">http://nginx.org/r/$request_completion</a>). Note though that it <br>
might not be set for variety of reasons.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div><div><br></div></div>