Nginx Reverse Proxy with InfluxDB2

Hi.

I am trying to setup a reverse proxy so I can securely send data to my Influxdb2 server. ( I have SSL working already )
I have setup a working system for Grafana as well as WrodPress and they work great.
I have had massive problems with setting up InfluxDB though.

I access the website areas like so :
They all are accessed on the same open port ( 443 ) then redirected with Nginx Reverse Proxy

WordPress website : URL/
Grafana website : URL/grafana/

I want to be able to access InfluxDB on : URL/influxdb2

Grafana is hosted on port 3000 internally and it redirects perfectly, I don’t see why Influxdb wouldn’t do the same ?

But I keep getting Bad Gateways or too many redirection errors from my browser when trying the URL/influxdb2 path.

Here are my Nginx config settings :
( public facing website URL has been replaced with just URL )

server {

        # Add index.php to the list if you are using PHP
        root /var/www/html;
        index index.php index.html index.htm index.nginx-debian.html;

        server_name URL;

        location /grafana/ {
                proxy_pass http://localhost:3000;
        }

        location /influxdb2/ {
                proxy_pass http://localhost:8086;
        }

        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

        }


    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/btads.hopto.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/btads.hopto.org/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

I know I did change a few things when I got Grafana to work in the Grafana setup file but I can not find anything that I should change in InfluxDB2.

My InfluxDB2 config file only contains :

bolt-path = "/var/lib/influxdb/influxd.bolt"
engine-path = "/var/lib/influxdb/engine"

I feel like something should be changed here but this is getting to be way over my head if I am honest.

Any advice would be of great help.

I should mention that I was able to have this all working before I started setting up the server changes, it was perfectly working locally, now however I can not even access the system on my local network.
The Database is running on a Pi without a screen so remote access is important.

Are you trying to access the InfluxDB 2 UI? Or just the API? Sounds like you are trying to access both from the description, but I wanted to double check.

One thing that makes this difficult is that InfluxDB 2 doesn’t currently support configuring a “base path” like grafana does, see Add HTTP proxy base path/prefix configuration option for UI · Issue #21009 · influxdata/influxdb · GitHub

Depending on how you are trying to access InfluxDB, I might be able to suggest some different nginx configurations. Do you have the option of running the InfluxDB server via a subdomain? Like influxdb2.url.com.

1 Like

I would like to access it right now with the UI just to see if things are working.
But I do need to automatically send HTML end point requests from my IoT device so both I suppose ?

I have read up onthe HTML endpoints recently, I am still holding out hope that I can make this work as it really is my only option.

If subdomains is the only option you can think of then I will have to make that work if you would be so kind.
Right now I am using a free no-IP host name so I hope I can make a subdomain ontop of that one, I will try now.

If you could let me know the Nginx setup you suggest that would be great as even if no-ip does not let me do subdomains on their free service I will need to buy a actual domain of my own soon.

The closest you will be able to get without using a subdomain is to have your influxdb2 location block configuration like this:

  location /influxdb2/ {
    proxy_pass http://localhost:8086/;
  }

This is identical to what you have posted above, except for the trailing / on the proxy_pass line. What this will do is have requests with the path of /influxdb2/rest/of/path reaching the proxy server be altered to /rest/of/path (dropping the leading /influxdb part) when they are received by the influxd process. By doing this, you should be able to reach the API endpoints using URL/influxdb2/api/v2. The critical limitation with this approach is that the UI will not work when trying to access it through the reverse proxy. This is because the HTML/CSS/JS files in the UI code have hard-coded links to to <hostURL>/fileName.js for example, which currently cannot be set to include the influxdb2 path. So if you were to try to load the UI, you would get the index.html page, but it would include links to things like <hostURL>/file.js that your browser will try to load, but it won’t be able to find them since the proxy is set up to forward requests on the influxdb2 path and won’t have file.js on the root path. So the UI won’t work with this approach - but you should be able to access the API and use the CLI to interact with the server. Let me know how it works if you go with this approach, as I haven’t tested it extensively!

Using a subdomain for setting up the reverse-proxy to influxdb would be the most robust way to do this since we don’t currently have an option for setting a subpath like you can do with Grafana. Using a subdomain, you should be able to set up a a separate server block to reverse-proxy to influxdb. It would look something like the below at a minimum, + you would need to add the extra config for SSL on the subdomain.

 server {
        server_name influxdb.URL.com;
        location / {
            proxy_pass       http://localhost:8086;
        }
 }

Hopefully that helps. Manually configuring nginx, especially with SSL, can be a little tricky, so let me know if you run into any other issues.

H wbaker.

So I got the system up and running with the UI over a subdomain with SSL, I am extreemly happy with myself I wont lie.

For those out there trying this, I used LetsEncrypt Cert-bot after getting things working on my main and subdomain sites ( over http ) and it does all the SSL stuff automatically for you if you ask it to.
No idea how correct that actually is but I do have SSL now so I am happy.

( To be clear, I can login to the UI and everything perfectly with an external connection, or in my case with a VPN on my browser to get “back in” to my system without it throwing too much of a fit.)

I thought I had a problem but I don’t now, just a question, and I was halfway through typing up my massive problem I thought I had when I gave it one more try and it worked :slight_smile:

I would like to ask about it though ( if you dont mind, I’d love to learn )

So, I could not connect to the data base how I did it before, with the new updated URL, but I could ping the site and all that, then while I was trying things I used /api/v2/ping to see what would happen.
I got back a response, 401, a step in the right direction.

I swear the URL and commands did not change between these tests but now when I pass the correct Auth Token I can write to it as normal.

I would like to know if you think it is at all possible that the Database needs a “ping” to get paths correct before it will work ?
Even as I type this I am sure that is not the case and think I must have gotten the commands wrong the first time but I have to ask for curiosity.

Anyway, thank you for your time, I am one very happy InfluxDB user right now :smiley:

Glad you got everything working!

I can’t think of any reason specifically why you would need to ping the database for the rest of the paths to work. My guess would be that the behavior you observed was related to DNS propagation of the subdomain or something related to caching.

Thanks, yea after a lot of wondering and reviewing what I did, I realized I was using the wrong URL then changed it and it worked ( not realizing that I actually changed it ).

Not my best moment, but it works so I am happy, thanks again for the help.