Ssl – How to use SSL behind a load balancer and still get the client IP

What they're telling you is that if you choose to have the SSL end point on your end be in the load balancer (rather than a server that the load balancer routes to) then you should be aware that regardless of how safe the data was on the way to the load balancer than once it leaves the load balancer it is in the clear. In a private data center it is not uncommon to have SSL processing offloaded to load balancers or specialized hardware and then have the inner pipe (the one that was formerly wrapped in SSL) continue off to regular webservers for servicing.

The warning they give is that if your cloud servers are not in the same datacenter as your load balancer that if you unwrap the ssl session in the load balancer the traffic from their to the webservers will be transparent and routed across the public network.

As for your speculation on the X-forwarded-for stuff, you misunderstood what they meant. They are saying that if your web-service wants to ensure that clients are using SSL but you are stripping off the SSL wrapper at the load balancer that they can have the load balancer stick an extra header for your webserver so that you know that the client DID use SSL even though your webserver will say that no SSL is in use.

hope that helps you out

In the comments, you have verified that nginx process was running and telnet localhost 443 was working. But it doesn't mean that the outside party can reach your nginx. One layer you should check was firewall. It will inspect and drop the packet flowing to nginx if you don't allow rule to port 443.

Sidenote: Nginx error 400 Bad request, usually means that you telnet to nginx in https port but your request wasn't clear text or incomplete (e.g. no HTTP headers defined)