keepalive upstream

Francis Daly francis at
Sun Oct 16 08:33:43 UTC 2016

On Sat, Oct 15, 2016 at 05:20:42AM -0700, Grant wrote:

Hi there,

> > I've been struggling with a very difficult to diagnose problem when
> > using apache2 and Odoo in a reverse proxy configuration with nginx.
> > Enabling keepalive for upstream in nginx seems to have fixed it.  Why
> > is it not enabled upstream by default as it is downstream?
> Does anyone know why this isn't a default?

My guess?

Historical reasons and consistency.

proxy_pass from nginx to upstream was HTTP/1.0, which default assumes
"Connection: close" unless the client explicitly says otherwise. And
(without checking) I guess that nginx was explicit about "close".

Then the option of proxy_http_version came about, which would allow you
take advantage of some extra features if you know that your upstream
uses them.

Arguably, "proxy_http_version 1.1" should imply "Connection: keep-alive"
if not explicitly overridden, but (again, my guess) it was cleaner and
simpler to make the minimum changes when adding support for the new
client http version, and the upstream server must be able to handle
"Connection: close".

If you want close, keep-alive, upgrade, or something else, you can add
it yourself. nginx has to pick one to use if none is specified, and it
looks like it picked the one that was already its default. Principle of
Least Surprise, for current users.

On the "downstream" side, nginx is a http/1.1 (or 2) server. If the
client connects using http/1.0, nginx will respond with "Connection:
close" unless the client said otherwise. If the client connects using
http/1.1, nginx will respond with "Connection: keep-alive" unless the
client said otherwise. That's the http server-side rules.

Also, I guess that nginx generally assumes that the things that it talks
to are correct. I'm not sure, but it sounds like you are reporting that
some combination of things that is your upstream was receiving whatever
http request nginx was making, and was responding in a way that nginx
was not expecting. If some part of that sequence was breaking the http
request/response rules, it would be good to know so that it could be fixed
in the right place.

Naively, it sounds like your upstream was taking the nginx "Connection:
close" part of the request and ignoring it. If that is the case, your
upstream is wrong and should be fixed, independent of whatever nginx does.

Francis Daly        francis at

More information about the nginx mailing list