<div dir="ltr">Hello<div><br></div><div>Just to close that conversation, it seems this was an error of our devops in charge of alerting, who was using curl in a bad way.</div><div><br></div><div>Best regards,</div><div><br></div><div>Sébastien</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 6 mai 2024 à 11:33, Sébastien Rebecchi <<a href="mailto:srebecchi@kameleoon.com">srebecchi@kameleoon.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello!<div><br></div><div>There is nothing regarding this issue in nginx logs.</div><div><br></div><div>Now I think the issue is not with nginx itself, but in front of nginx, with Linux itself.</div><div>We monitor using curl, and it seems that curl can print status code 0 when it can not establish a connection with the server.</div><div>I think the Linux kernel is not configured properly to handle our connection peaks. Looking at net.core.somaxconn, we have the default of 128. More generally, I will deep dive into this and possibly other kernel settings to see if optimizing them will solve the problem. For information, on each of our servers we have an average of around 80K simultaneous TCP connections globally and around 35K in state ESTABLISHED (according to netstat/ss -nta), and more during high peaks.</div><div>I saw this doc section which is a good starting point <a href="https://www.nginx.com/blog/tuning-nginx/#Tuning-Your-Linux-Configuration" target="_blank">https://www.nginx.com/blog/tuning-nginx/#Tuning-Your-Linux-Configuration</a></div><div>If you have any advice on other settings to increase, this would be very appreciated.</div><div><br></div><div>I will keep you in touch about my investigations, to confirm at least that there is no bug on nginx side, which i am quite confident about now.<br></div><div><br></div><div>Thank you very much for your help!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 4 mai 2024 à 20:47, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>> a écrit :<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 Sat, May 04, 2024 at 07:31:43PM +0200, Sébastien Rebecchi wrote:<br>
<br>
> Hello<br>
> <br>
> What does it mean when nginx returns an http status code 0?<br>
> <br>
> We see that cause we monitor nginx response status code, which is used as<br>
> front of our apps. The apps themselves can not return 0, only 200 or 500.<br>
> So it seems issue here comes from nginx itself which can not process the<br>
> connection under high peak of load, but why 0, is that expected?<br>
<br>
Status code 0 as seen in nginx http access logs means that nginx <br>
wasn't able to generate any reasonable status code, even some <br>
generic failure like 500 (Internal Server Error), yet the request <br>
was closed.<br>
<br>
This usually happens due to some fatal issues, like unexpected <br>
conditions (which might indicate a bug somewhere), unexpected <br>
errors, or memory allocation errors if it wasn't possible to <br>
return 500.<br>
<br>
In most cases there should be additional details in the error log <br>
explaining the reasons.  If there aren't any, or reasons aren't <br>
clear, it might be a good idea to dig further.<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@freenginx.org" target="_blank">nginx@freenginx.org</a><br>
<a href="https://freenginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">https://freenginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div></div>
</blockquote></div>