Configuring FusionReactor to show "real ip address" when behind a load balancer or other proxy

Note: This blog post is from 2019. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

TLDR: If you know how request headers work, and how some LBs/proxies pass one in with the "real" IP address (and why you should care), and assuming you know WHICH header is used on your server, then you can jump to the next to last section below, "Telling FR to use that header".

What I share in this post applies to anyone using pretty much any version of the (wonderful) FusionReactor server monitor, which can monitor any Java application or server, including CFML engines like CF and Lucee, as well as app servers like Tomcat, or Spring applications, or caching servers like Redis or elastiCache, and so on.

Where are IP addresses shown in FR?

First, to be clear, the IP address is shown in many places, from the list of requests (like Requests>History), to the details of a request, to the CP email alerts, to the FR request logs, to the details of a request (shown later). I show examples of each of these below:

Why should I care if I see the real ip address?

In all these places, there are times when it's very important to know the real ip address (or at least what is reported by clients to be their ip address--even if they may be faked), rather than simply the IP address of your load balancer or proxy.

For instance, if you saw that all the requests in a few seconds were coming from a single IP address (or small set of them), that may be a clue that the traffic is automated (and could be killing your server). Or if you saw that they had the exact same user agent but different IPs (within a matter of seconds) or vice-versa, that would be suspicious.

I have talked in the past on the topic of unexpected impact of automated traffic, whether in this very old posts and presentation from a couple of years ago.

And I still help people about every other week (in my troubleshooting consulting) find and deal with such unexpected, automated traffic (which may not be legitimate search engine spiders or other traffic they may find acceptable).

So again the issue is that if your FR pages like the above show nearly all the requests coming from ONLY some one or a few IPs, that suggests they are all coming through some proxy or LB, and you should try to tweak FR to show the 'real" IP address.

Where is the "real" IP address tracked?

In order to change FR to show the "real" ip address, we need to first find out if it may be being passed into your server as a "header" from your load balancer or proxy. Most do that, or can be configured to do it. If you think you already know the header, you can skip to the next step. If it doesn't work for you, come back here and try again.

FR can show all the headers being passed into a request. Look at the details for any request, then see its available "headers" tab. There, look for a header like "x-real-ip", or "x-forwarded-for", or the like: any whose value shows a different IP address:

And you can see above that my site I have BOTH an "X-Forwarded-For" AND a "CF-Connecting-IP" header (the latter is from CloudFlare. More on that below).

Sometimes you may see different headers with different IP addresses. In that case, you really just need to do some experimentation (such as by making your own requests) to determine which header is really presenting the "real" IP address.

Configuring FR to use that header

Then, once you've identified which header holds the real ip address, you'd want to copy that header name and visit the FR UI and its Requests>Settings>Proxy page (remember, we're talking about the header that some "proxy" or load balance might pass in.) There you will see a field where you can choose from one of the listed values, but note that it does NOT make clear that if you have found your server uses some OTHER header, you can just paste that in.

Once you save that change, the change takes effect immediately. If you then look at the FR Requests>History page, you should now see that the ip addresses shown are the "real ones". If you do not, check if you made a mistake in the preceding steps.

Can something other than FR affect the IP address shown here, when you are behind a proxy?

Finally, some observant viewers may notice that I did not in fact have my proxy value set in FR. That's because I did something else, outside of FR, which took care of this need.

In my case, I wanted not only FR but also my underlying app server to have the real IP address (in my case, it was ColdFusion but it could have been Lucee or Tomcat, or any other Java-based application). And to do that, I instead leveraged a feature in Tomcat (because CF, like Lucee, runs on Tomcat) called the RemoteIPValve. Because I did that, the IP address was changed in the "real" IP address header, even before the request got to FR. (FR is a wrapper inside of the Java server, and it must simply be that happens in the request process before FR sees it.)

For those who want to know more, I blogged about leveraging Tomcat's "remoteipvalve" feature elsewhere, and I set it to use the "CF-Connecting-IP" header that Cloudflare sends in. (There are likely similar extensions in other Java apps and app servers that could handle the change of the IP header in such a way.)

Why then does this FR feature I describe above exist? and why might one choose that instead? Well, it could be that someone won't have the ability (or desire) to change Tomcat to use that valve (or its equivalent in another Java engine). Or it may simply be that the only concern about knowing the "real IP" is in FR and its features/logs/alerts.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed