This is a graph showing connection count from nginx's stab_status, the drops in graph are server restarts done manually.

NGINX status - by year

I find this behaviour strange, looks like some leakage. I think there are connections hanging that should be closed, but they stay in writing state.

Is this normal? Should I take an action? If so, in which direction?

I tried changing nginx's keepalive, and then some kernel settings like this https://gist.github.com/perusio/2154235

But this behaviour hasn't change.

The server is a VPS with one processor available and 1024mb ram.

EDIT1: versions

nginx version: nginx/1.6.2 built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) TLS SNI support enabled configure arguments: --add-module=/root/ngx_pagespeed-release- --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-http_ssl_module --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --without-http_scgi_module --with-ipv6 --with-http_stub_status_module --sbin-path=/usr/sbin/nginx --with-http_spdy_module

Note that it runs ngx_pagespeed

EDIT2: More info

Nginx is working as a reverse proxy for uwsgi/django app. I'll monitor uwsgi and post the results to see better if uwsgi has something to do.

  • Have you found a solution for this? I am having lookalike problem. Dec 14, 2015 at 9:01
  • I haven't found a solution yet
    – jperelli
    Dec 14, 2015 at 12:45

3 Answers 3


As described by the stub_status module documentation, a connection in the writing state means :


The current number of connections where nginx is writing the response back to the client.

So you should investigate on your server response times and check why it takes so long for your clients to get nginx's replies and close the connection afterwards : slow network, high data volumes, chunked transfer-encoding, websockets ...

  • Thanks, I added more info "Nginx is running as a reverse proxy for a uwsgi/django app". I'll install a munin plugin to monitor uwsgi to see if there is something happenning with it.
    – jperelli
    Mar 17, 2015 at 1:35

If some of your servers use SPDY or HTTP/2, your problem has its roots in a defect in the integration of this protocols. You can have a look in nginx ticket #714.

The current status is:

There is at least one connection leak in HTTP/2 as fixed in nginx 1.11.3, and the fix is not yet available in 1.10.x. Please try 1.11.x instead.

  • This was the correct answer in my case. It doesn't look like this fix will be back-ported into the 1.10 production branch so the fix is either to move to the "mainline" (aka dev) branch or just disable http2.
    – Nick
    Jan 11, 2017 at 12:09

This seems to be normal behavior, as there will always be clients who have an unreliable connection leaving the server's connections in a "sending" state. They aren't reading any more data but Nginx will still wait until the send_timeout before closing the connection.

These may also be attacks where the malicious clients deliberately do that to exhaust the server's available connections & file descriptors, so if this becomes a real issue you should try lower the value mentioned above.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .