Wrong IP with lighttpd reverse proxy

gunicornlighttpdreverse-proxy

I use a lighttpd reverse proxy to serve django with gunicorn. Now this config worked:

proxy.server = ("" => ( "" => (
    "host" => "127.0.0.1",
    "port" => 8000,
)))

Now i moved the gunicorn into a container and use:

proxy.server = ("" => ( "" => (
    "host" => "192.168.1.2",
    "port" => 8000,
)))

Now every request has the ip 192.168.1.1 as seen by gunicorn. I would understand, if the reverse proxy obfuscates the real IP, but why did it work with localhost then?

for both i get

X-Forwarded-For: client-ip
X-Host: the.domain
X-Forwarded-Proto: http

where the client-ip is public ip space.

the requests comes from

host:

nc: connect to 127.0.0.1 8000 from localhost (127.0.0.1) 44953 [44953]

container:

nc: connect to 192.168.1.2 8000 from host (192.168.1.1) 60027 [60027]

the container itself has ip 192.168.1.2, the host-bridge has 192.168.1.1 and the routes inside the container are:

default via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.2

the host has:

192.168.1.0/24 dev bridge  proto kernel  scope link  src 192.168.1.1

EDIT:
The X-Forwarded-For was the same for both requests. (Tested with nc -vlp 8000).

Best Answer

My bet? lighttpd is adding an X-Forwarded-For header, and Django has something hardcoded somewhere to know that 127.0.0.1 is unlikely to be the real remote IP address if that header's present.

You should verify that the X-Forwarded-For header is present, then get Django to use that as the remote address (looks like the way to do that is here).

Related Solutions

NGINX Reverse Proxy – URL Rewrite

Any redirect to localhost doesn't make sense from a remote system (e.g. client's Web browser). So the rewrite flags permanent (301) or redirect (302) are not usable in your case.

Please try following setup using a transparent rewrite rule:

location  /foo {
  rewrite /foo/(.*) /$1  break;
  proxy_pass         http://localhost:3200;
  proxy_redirect     off;
  proxy_set_header   Host $host;
}

Use curl -i to test your rewrites. A very subtle change to the rule can cause nginx to perform a redirect.

Nginx – wrong with the nginx reverse proxy configuration, with single server (and more later)

you are close, but there's no reverse proxy for http configured, only for https (in the above setup) — so it should show default content from document root. First server also lacks ending }.

You may configure both http and https in the same block, just use the ssl keyword in the listen directive (under the ssl port, so there's no need to set the ssl on directive):

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ...
    ssl_certificate /usr/local/nginx/conf/server1.crt;
    ssl_certificate_key /usr/local/nginx/conf/server1.key;
    ssl_session_cache shared:SSL:10m;
...

I must alert that using two different SSL certificates within the same IP is somewhat limited and complicated — that is because it would require HTTP renegotiation (since the request needs to be encrypted with the certificate before requesting the proper Host), so you'll probably need to separate the certificate by server block. For this, use a more specific, by IP listen:

server {
    listen 192.168.0.10:443 ssl; # for server1.mydomain.com
...

server {
    listen 192.168.0.11:443 ssl; # for server2.mydomain.com
...

I also recommend you use the Mozilla SSL Config Generator for best practices on SSL security.

EDIT1

To avoid the 400 error, just remove the directive ssl on; and reload. It was causing the http traffic to require SSL — you already indicated to use ssl on the line: listen 443ssldefault_server; (this means turn ssl on on this port).

The rest of the configuration is fine, but depending on your server response, you may need to adjust the proxy settings.

First, check if the spinning is client-side or server-side: access it with cURL or turn on web developer tools on your browser and check the network: if your browser is being redirected, you probably need to adjust the proxy_redirect or even make some string replacements on your server response.

Check it this way with cURL:

curl -i http://server1.mydomain.com

If you see a Location: header in your response, you'll need to finetune your proxy settings (that will depend on the response). For example, you may be accessing it as https then your proxy forwards as http and your backend server application redirects to https (but when the response goes through the proxy, it goes back to http to the browser). There are several ways of fixing it, by using proxy_set_header or even adjusting your backend server.

For example you could use:

proxy_set_header X-Forwarded-Proto $scheme;

But either your backend http server or your application would need to properly understand this.

Alternatively, if there's no redirect, but no response as well (or a No gateway response after the request timeout — 30s), check if your backend server is properly responding to the proxy server.

Please also note that you don't need a http server on your backend, you can use, for example, a FastCGI server directly — this sometimes has fewer downfalls.

EDIT2

Based on the cURL response, I see that the configuration is working as expected — the backend server response is asking for you to sign in. If the SSL certs weren't working, you wouldn't be able to curl -i https://server1.mydomain.com.

The traffic between frontend (proxy) and backend are made through http only (see the proxy_pass directive), and that's also usually expected (another encryption might add unnecessary overhead).

Now, if you wish to use https only, you have two options: either configure that in your backend (so that it forwards you to https://test1/users/sign_in) or use a different setting for nginx, where you strip the http:80 server and make it redirect everything to https:443. Something like this (be sure to remove the listen 80 from the next server block):

server {
    listen 80 default;
    server_name  _;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
...