using digitalocean loadbalancer, how to get real ip?

Posted January 9, 2018 15.8k views
Load Balancing

Digital ocean’s Loadbalancer does not send X-Forwarded-For header, so how to get real ip info with load balancer?

1 comment

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.

Submit an Answer
6 answers
  • Thanks for this!

    In kubernetes, I have to create a config-map for nginx with the following details:

    kind: ConfigMap
    apiVersion: v1
      name: ingress-nginx-ingress-controller
      namespace: name_of_your_workspace
      proxy-real-ip-cidr: ','
      use-proxy-protocol: 'true'

    where is the external ip of your load balancer.

    you also need to set the proxy_enabled flag in your load balancer using annotations:

    kind: Service
    apiVersion: v1
      name: ingress-nginx
      namespace: ingress-nginx
      annotations: "true"
      labels: ingress-nginx ingress-nginx

    as mentioned in this post.

The Load Balancer takes care of automatically renewing the Let’s Encrypt certificate for you. The only issue is when you host multiple vhosts behind the LB and you cant get a wildcard certificate or upload different certificates on the LB.

DigitialOcean Load Balancers set the X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers to give backend nodes information about the original request. Though you’ll need to ensure that you web server or application is configured to log that.

For example, if you were using Nginx, you could capture the original IP for a request by configuring a custom log_format directive and using it in your access_log directive. On Ubuntu , you would need to edit the main Nginx config located at /etc/nginx/nginx.conf Here’s a very simple example as a proof of concept:

        log_format from-lb 'Original IP: $http_x_forwarded_for';
        access_log /var/log/nginx/access.log from-lb;

Of course, you’ll likely want to log more information than that. Here’s a more detailed log format that matches the default output but replaces uses the origin IP address:

        log_format main '$http_x_forwarded_for - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent"' ;

        access_log /var/log/nginx/access.log main;

If you’re using Nginx, you can find more details about configuring logging in this tutorial. If you aren’t, let us know what web server you’re using, and we can help more.

by Justin Ellingwood
Understanding the logging mechanisms of your server will help you diagnose problems and avoid larger problems down the road. In this article, we will explore Nginx's logging capabilities. We will discuss the configuration options and the tools that can be used to maintain your logs.

In case of https this only works when you do the SSL offloading on the load balancer. So if you need the client’s real IP address, don’t use certificate passthrough.

DO LB doesn’t pass user’s real ip when using https passthrough. In such case you must use SSL termination at Load balancer it self, however this is real deal if you’re using let’s encrypt free SSL with http01 validation. Because you have to re-new and re-upload licenses manually.

@GrantZvolsky — amazing answer, did the trick for me! The link to blog post is broken though, sadly :) Would love to read it!

  • Thank you! It’s back up. The blog mostly serves as a canary of an app that I’m working on. Apparently I accidentally misconfigured production while playing with a dev cluster. Time to set up some health checks. I’m happy to hear that the blog’s single blogpost is useful to someone :)