Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

UEM and Load Balancer


I am monitoring an application which has all users' requests go thru a load balancer,  which in turn send the requests to the web servers.  All the Client IP that I see  in the  "User Actions" dashlet is the load balancer's IP.  Is there any way to get around that and detect the true client IP that sent the requests instead of the load balancer's IP?





Dynatrace Champion
Dynatrace Champion

The load balancer is likely stripping off the header needed.

The list of possible headers we use can be seen (or modified) in Settings/dynaTrace Servers/Geographical Locations. ClientIPSettings.png

You could check if there is a header not in this list being passed, or more likely, have the load balancer pass one of these headers.




Hi Guys ,

I have a similar issue to the above one , I'm seeing a load balancer IP address for all Clients , could you help what should I do to see the real client IP ?



I have the same issue. We are using a load balancer and I am seeing load balancer IP for all clients.

Dynatrace Pro
Dynatrace Pro


load balancers have to follow the HTTP standard. LBs are in a way a bit like a proxy (i.e. middle man between the client and the server). The protocol tells us that each request must contain the IP address of the sender so in our case it is no longer the client but the load balancer's IP.

The browser talks to the load balancer and the LB talks to the web server.

This is why we have lost the source IP from the browser.

Luckily these devices can use other headers to keep the source IP. They basically move the original source IP into another header so that it can be retained.

These headers are listed in Dave's reply and you can chose the priority.

The trick is to get your load balancer's administrator to enable one of these headers if not already done.

F5 for instance don't have this setting turned on by default!



Dynatrace Champion
Dynatrace Champion

I believe it is also a problem if the traffic is HTTPS and the LB doesn't terminate the SSL because the LB is not able to add any HTTP headers to the encrypted traffic. I have had customers who were told by their LB admins that it was not going to be possible to get the real client IP due to the way the LB architecture was implemented (with SSL being used).

yes I totally agree with no SSL termination, no processing can occur around headers as they would be encrypted.


Just my two cents, load balancers have the option to either replace the source IP address, or preserve the source IP address instead of forcing its own IP as the "client". Similar to Florent's insight.

It is just a simple config which could be set up and help you to see the real client or browser IP address.

Hope this helps,



We had to solve the same problem (the client-ip being picked up by dynatrace was that of the load balancer that routed the web request and not that of the originating client).

We use F5 balancers, so we asked our network team to add a simple "iRule" to the configuration for our load-balanced URL:

HTTP::header insert X-Forwarded-For [IP::remote_addr]

This rule tells the load balancer to populate the http header field X-Forwarded-For with values from the remote_addr field. As described earlier, the X-Forwarded-For field is then picked up by Dynatrace as Client IP.

Easy peasy. 🙂



we face the same problem. Unfortunatelly we can't solve it by your suggestions.

We use SSL between client and server. The loadbalancer must not terminate the connection due to security guidelines.

Can you think of another way to pass the IP of the User to our servers?

I appreciate your help.



Dynatrace Champion
Dynatrace Champion

Hi Simon,

From what I have read, I think it depends on the load balancer configuration options available and at what layer of the OSI model the load balancer operates. There appear to be ways to configure the LB, assuming it can work at the TCP Layer rather than the Application Layer. Also, there apparently are options that involve terminating and re-encrypting (if needed). So I think it is best to engage the load balancer team and explore what options might exist for your particular installation. Even if another options exists, policy may prevent it's use. Also, there may be performance implications, "non-standard" implementation complaints, or similar issues that arise.

Here is an interesting article on F5, specifically:

Perhaps someone else on the forum can provide more information based on past experience overcoming this issue.





unfortunatelly we see no option do get the IP through the load balancer.

We had the idea to extend the JavaScript Agent to get the Clients IP and pass it somehow within the request.

Any ideas on that?

There seem to be some options to use JS to get the client IP:

But I do not have any ideas beyond this. I also saw some references to people using cookies to persist the client IP, but you would be limited to using a BT to split on that value since our Geo Location requires a header. If the JS could be added to the page and a header passed, that would work for us. I am not sure if it would be possible to extend the JS agent or modify the injection to add additional JS code to set the client IP, but it seems a promising work around to try.



With the netscaler, you can forward using Mac Addresses, this preserves the source IP.


Also the Netscaler can "Use Source IP". i.e. pass it though to the client. The problem here is if you use a CDN, you only see the IP of the CDN.



We now know that our server log the client ip.

We try to set a header with the client-ip supposing it is X-Client-Ip we have to use in this case.

I let you know if that worked

You can find the list of supported headers we check under the server settings in "Geographical Locations". If needed, you can add to the list or modify the priority...

Thank you.

Our Server now adds the X-Client-Ip header.

Dynatrace seems not to notice it or if it does, nothing happens.

I switched the X-Client-Ip header from the geolocations-options at the top.

And I added the X-Client-Ip header in the servlet sensor configuration.

None the less when I look at a purepath the webrequest-details do not list the X-Client-Ip header.

What am I missing?

Hi Simon,

First, are you seeing the actual Client IP now in the PurePath top pane (after you add the Client IP column by right clicking on any column header)?

Second, did you change the Web Server sensor properties to capture the X-Client-Ip header? If so, you should see it in the PurePath when you right click on the Web Request node in the tree.

If you modified the Servlet sensor properties to capture the header, right click on a servlet method node (check that the API column shows "Serlvet").

I would check the Web Server capture (assuming you have a web server agent) and then the Servlet capture.

It sounds like maybe you were checking the Web Request node of the tree, but had captured the header at the Servlet layer.

If you continue to have problems seeing the header captured, you might want to temporarily "wild card" the capture using asterisk or a blank Attribute column just to see exactly what headers are present.



Yeah you were right. it was the wrong sensor. Thank you.


We too are facing the same issue, but i could able to find a easy workaround. Though the client IP is replaced by LB IP, browser details will still be showing as client m/c. Hence use a browser/version which is not common in your project (like Safari) and you can see the requests sent by this browser on UEM easily.