What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

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

Votes:

0

I found a post on your KB regarding how to set PRTG up to run behind an IIS reverse proxy, but I can't find anything on setting it up behind an nginx reverse proxy. Is this possible? And if so, do you have any further information regarding how it's done? I've tried to set it up numerous times and it just doesn't seem to want to work.

nginx prtg reverse-proxy

Created on Jan 14, 2016 1:24:48 AM



Best Answer

Accepted Answer

Votes:

4

This is my config for nginx to reverse proxy my PRTG server with TLS offload:

upstream prtgaero-rs {
        server prtgaero.palmbeach.k12.fl.us;
        keepalive 32;
}
server {
        listen 443 ssl;
        server_name prtgaero01.palmbeach.k12.fl.us
        ssl on;
        ssl_certificate         /etc/nginx/ssl/prtgaero01.crt;
        ssl_certificate_key     /etc/nginx/ssl/prtgaero01.pem;
        location / {
                proxy_pass http://prtgaero-rs;
                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 "";
        }
}

So my real PRTG server is listening on port 80 at prtgaero.palmbeach.k12.fl.us . The annoying thing is that you will be warned of the dangers of connecting on port 80 even though you are connecting securely to the reverse proxy.

I make nginx bind to a specific IP address that corresponds to hostname prtgaero01.palmbeach.k12.fl.us for which I have created a custom certificate and private key ( using a very useful tool called XCA ).

In the "location" block I use the proxy_pass directive to refer to the "upstream" block.

In order to make the HTTP keepalive function work to control the number of web connections from nginx to PRTG I have the "keepalive 32;" line in the upstream block and the lines: proxy_http_version 1.1; proxy_set_header Connection ""; in the location block. The other "proxy_set header" directives are just copied from example. The "X-..." directives are about letting the back end web server know the identity of the real web client ( not the nginx server that is directly connecting ).

What I observe having done this is that my TCP connections on the PRTG server won't go above 200 whereas without nginx I could push to 500 with a single browser ( Chromium on Linux ). I still see that Firefox gives a much snappier response than Chromium. I went onto a Windows system and confirmed that this is also the case for Chrome versus Firefox.

My big takeaway is that if you can use Firefox to work with PRTG you should . I think nginx adds value but switching to Firefox may be an easier less complex option.

I let the PRTG server settle down with no web clients and it drops to a resting level of under 20 TCP connection. I have very few sensors running from the core server and most of them are not TCP based. I mention this so that when I talk about going up to 200 TCP connections I am sure that the great majority are web connections and not random sensor activity.

I recently used a web load testing tool that would allow me to run some performance tests against PRTG. It can be set up to randomly request pages ( randomly pick a sensor ID from a list then randomly pick a table index like "Overview", "Live Data", request the page then wait a random amount of time before making another similar request. It can be told to simulate a huge population of users behaving in this way for a somewhat realistic test situation.

I may take the time to run some tests at a later date. Unfortunately I can't get my team to use the PRTG server much at all so performance with a heavy user load isn't that much of an issue for me.

Created on May 21, 2019 2:24:08 PM



14 Replies

Votes:

0

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.

Created on Jan 15, 2016 12:24:45 PM by  Torsten Lindner [Paessler Support]



Votes:

9

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.

Created on Feb 21, 2016 8:18:15 PM



Votes:

0

@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.

Created on Feb 24, 2016 2:59:26 PM

Last change on Feb 25, 2016 8:13:37 AM by  Torsten Lindner [Paessler Support]



Votes:

0

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.

Created on Feb 26, 2016 8:00:40 PM



Votes:

0

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.

Created on Aug 31, 2016 4:44:26 PM



Votes:

0

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.

Created on May 28, 2017 2:55:42 PM



Votes:

0

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.

Created on May 17, 2019 8:37:40 PM



Accepted Answer

Votes:

4

This is my config for nginx to reverse proxy my PRTG server with TLS offload:

upstream prtgaero-rs {
        server prtgaero.palmbeach.k12.fl.us;
        keepalive 32;
}
server {
        listen 443 ssl;
        server_name prtgaero01.palmbeach.k12.fl.us
        ssl on;
        ssl_certificate         /etc/nginx/ssl/prtgaero01.crt;
        ssl_certificate_key     /etc/nginx/ssl/prtgaero01.pem;
        location / {
                proxy_pass http://prtgaero-rs;
                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 "";
        }
}

So my real PRTG server is listening on port 80 at prtgaero.palmbeach.k12.fl.us . The annoying thing is that you will be warned of the dangers of connecting on port 80 even though you are connecting securely to the reverse proxy.

I make nginx bind to a specific IP address that corresponds to hostname prtgaero01.palmbeach.k12.fl.us for which I have created a custom certificate and private key ( using a very useful tool called XCA ).

In the "location" block I use the proxy_pass directive to refer to the "upstream" block.

In order to make the HTTP keepalive function work to control the number of web connections from nginx to PRTG I have the "keepalive 32;" line in the upstream block and the lines: proxy_http_version 1.1; proxy_set_header Connection ""; in the location block. The other "proxy_set header" directives are just copied from example. The "X-..." directives are about letting the back end web server know the identity of the real web client ( not the nginx server that is directly connecting ).

What I observe having done this is that my TCP connections on the PRTG server won't go above 200 whereas without nginx I could push to 500 with a single browser ( Chromium on Linux ). I still see that Firefox gives a much snappier response than Chromium. I went onto a Windows system and confirmed that this is also the case for Chrome versus Firefox.

My big takeaway is that if you can use Firefox to work with PRTG you should . I think nginx adds value but switching to Firefox may be an easier less complex option.

I let the PRTG server settle down with no web clients and it drops to a resting level of under 20 TCP connection. I have very few sensors running from the core server and most of them are not TCP based. I mention this so that when I talk about going up to 200 TCP connections I am sure that the great majority are web connections and not random sensor activity.

I recently used a web load testing tool that would allow me to run some performance tests against PRTG. It can be set up to randomly request pages ( randomly pick a sensor ID from a list then randomly pick a table index like "Overview", "Live Data", request the page then wait a random amount of time before making another similar request. It can be told to simulate a huge population of users behaving in this way for a somewhat realistic test situation.

I may take the time to run some tests at a later date. Unfortunately I can't get my team to use the PRTG server much at all so performance with a heavy user load isn't that much of an issue for me.

Created on May 21, 2019 2:24:08 PM



Votes:

0

Hello there,

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


Kind regards,
Birk Guttmann, Tech Support Team

Created on May 22, 2019 8:14:21 AM by  Birk Guttmann [Paessler Support]



Votes:

0

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

Created on Jan 16, 2023 2:47:32 PM



Votes:

0

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;

Created on Jan 16, 2023 4:07:35 PM



Votes:

0

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

Created on Jan 18, 2023 12:56:41 PM by  Felix Saure [Paessler Support]



Votes:

0

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 "";
    }

Created on Jan 19, 2023 2:35:04 PM



Votes:

0

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

Created on Jan 20, 2023 7:37:24 AM by  Felix Saure [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.