Question
Load Balancer sending incorrect X-Forwarded-Proto header to droplet
- Posted on November 17, 2022
- DigitalOcean DropletsDigitalOcean Managed Load BalancersLoad BalancingNginx
Asked by Charles Fahey
Hello all,
I am running up against the following scenario:
-
Using a load balancer with SSL termination, and Proxy Protocol enabled, directing traffic to a droplet running nginx;
-
nginx has been configured to accept the proxy protocol
server {
listen 80 proxy_protocol;
[...]
location ~ / {
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
- When looking at the raw headers as relayed by nginx to express, I always see the “X-Forwarded-Proto” reported as “http”, even though the “x-forwarded-port” is properly relayed as “443”.
This is breaking my attempts to set a secure session cookie from within my app.
Does anyone have any suggestions? Is this perhaps a bug in the Digital Ocean load balancer?
Thanks to all who have ideas!
- Charles
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Hollie's Hub for Good
Working on improving health and education, reducing inequality, and spurring economic growth? We’d like to help.
Get started for free
Enter your email to get $200 in credit for your first 60 days with DigitalOcean.
New accounts only. By submitting your email you agree to our Privacy Policy.
Heya,
The
X-Forwarded-Protoheader represents the protocol used to connect to the load balancer. Since you have SSL termination enabled on your DigitalOcean Load Balancer, clients connect to the Load Balancer using HTTPS. After that, the Load Balancer connects to your backend (nginx) using HTTP, which is whyX-Forwarded-Protois being set to “http”.The issue you’re seeing is a common one when using SSL termination on load balancers. Here’s how to solve it:
Trust the Header from the Load Balancer:
Since the traffic between your Load Balancer and the nginx server is internal (and thus can be considered safe from tampering), you can set
X-Forwarded-Prototo the value provided by the Load Balancer instead of letting nginx reset it. Here’s how:Replace this:
By making this change, you’re essentially passing along the
X-Forwarded-Protovalue as sent by the Load Balancer, instead of setting it to the$schemeused to connect to nginx.Ensure Your Application Trusts the Header:
Ensure that your Express (or any other) app is set up to trust proxy headers. In Express, this can be achieved with:
With this setting, Express will trust the
X-Forwarded-Protoheader and realize that the original request was made using HTTPS, even though it itself received the request over HTTP.Check SSL Termination on Load Balancer:
Make sure SSL termination is correctly set up on the DigitalOcean Load Balancer. The SSL certificate should be valid and applied. The incoming traffic on port 443 should be forwarded to port 80 on the backend droplets.
By implementing these changes, the
X-Forwarded-Protoheader passed to your application should correctly reflect the protocol used to connect to the Load Balancer (i.e., HTTPS), and you should be able to set secure session cookies from within your app.