Is it possible to run PRTG behind an nginx reverse proxy?

Hello,

Thank you very much for your KB-Post. To be honest, we ourselves have not run any tests iwth nginx systems running as reverse proxies. Therefore we cannot offer guidance on it unfortunately. Hopefully other PRTG users can jump in here though!

best regards.

Yes, I run prtg behind an nginx reverse proxy with no issues. You will need to point nginx to 127.0.0.1 and not local host, if IPV6 is enabled on your nginx and prtg servers.

@pir8radio - Are you running PRTG on a separate domain/subdomain on nginx, or as a subdirectory? It's possible to set it up on its own domain/subdomain (https://kb.paessler.com/en/topic/67905-using-nginx-webserver-as-ssl-proxy-for-prtg), but I've never been able to get it to work under a subdirectory.

In other words, http://myprtginstall.example.com and http://myprtginstall.com will work, but http://example.com/prtg will not.

And if you *are* using it under a subdirectory, can you share the relevant section of your nginx config file? I've tried to set this up numerous ways and it just never works.

Has anyone here got the links included in your email notifications to work? I also had a small issue with reports, but resolved that with editing reportheader.html I'm using IIS as my RP server, and describe my issues in more detail here: https://kb.paessler.com/en/topic/44613-using-windows-iis-as-ssl-proxy-for-prtg but the concept should be the same.

Late reply but yes, has been successfully running PRTG cluster behind NGINX with NGINX setup to failover web requests to nodes should the master fail. They are all separate servers, not sub directories on the same host. The only problem found so far is the iOS app that requires re-authentication when failed over between nodes but notifications are still being delivered to iOS ok.

Sorry I guess we don't get alerted when new posts are put in. I'll try @gjch to see if that alerts you.

I use subdomain, but if you share your subdirectory nginx config we can probably figure it out, if you have not already.

@Curtis Kayfish to cure your reports issue (where they just sit there and load, no graphics) add the below to your nginx config, replace my port number with whatever you are using. I have not found an easy way to fix the email links.

sub_filter ':8077' '';

this will remove the port from the responses to the client. if you use a different port (other than 80 or 443) then you can do something like sub_filter ':8077' '999'; where 999 is the external port.

I am looking at this now. I have it basically figured out with a test PRTG server running behind and nginx instance with TLS disable on PRTG. The big question is whether there is any advantage to having PRTG run behind Nginx.

It does seem that when any single client is accessing PRTG and is active in terms of clicking through lots of pages with dynamic graphs being generated, a lot of TCP sessions are generated. We are talking about potentially more than a 60 TCP connections per client ( in fact potentially well over 100 connections based on some testing I am doing now ). With TLS activated, each of these sessions involves a quite processor intensive security negotiation. Depending on the architecture of the web server, establishing these new connections can be quite onerous in terms of starting new threads or even processes.

I actually was just trying to drive my PRTG instance very hard using a session from Chrome and a session from Firefox. What I noticed was that Firefox was responding much more quickly and that it wasn't causing a ramp up in the number of TCP sessions on PRTG. It seems that two things are going on:

• Firefox is much more efficient in terms of reusing its established connections for multiple HTTP requests
• PRTG is slowed by receiving requests on new TCP connections or at least the time to completion of the web requests is much longer when made through a new TCP connection.

Nginx is supposed to do an excellent job out of the box in reducing the amount of TCP connections established to the web server. In the case of my chrome browser, it should terminate the hundreds of connections and funnel them into a reduced number of open connections to the PRTG web server. I can see from my Firefox browser that this leads to a much snappier response.

I was actually hesitating to deploy nginx myself until I just ran these tests. The benefit I am seeing does not include turning off TLS on the web server and that should further improve performance. I will post again once I have things up and running.

Hello there,

Thanks a lot for sharing this. I'll mark your response as "Best Answer" here.

Kind regards,
Birk Guttmann, Tech Support Team

To disable the warning about running on a non-secure connection on the PRTG server see this:

https://kb.paessler.com/en/topic/79959-disable-enable-ssl-encryption-for-the-prtg-website

I have the X-Real-IP set but in the PRTG webserver log I'm still seeing my proxy IP and not the real IP. Is there anything I need to do to tell PRTG to use it for logs?

proxy_set_header X-Real-IP $remote_addr;

Hi Crawc,

The headers proxy_set_header X-Real-IP $remote_addr; are exclusively used in NGINX environments, PRTG won't use / resolve these headers. Therefore it's expected that the source IP address of the proxy is visible in the webserver log files.

We haven't tested it, but you could try the official X-Forwarded-For Headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

Kind regards,
Felix Saure, Technical Support Team

I used the example posted above and PRTG doesn't seem to use X-Forwarded-For when present for logs. Can this be something fixed so the logs are accurate?

    location / {
                proxy_pass http://backend;
                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;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
    }

Hey Crawc,

We are currently working on a new webserver, I'll forward your wish internally to see if we can consider this for the future.

At the moment I cannot tell you if or when this is going to make it in PRTG, pardon.

Kind regards,
Felix Saure, Technical Support Team