28 Jul 2026 09:41 AM
Hi team,
Why in some cases we see the IPs from unknown hosts but in others we don't. Why do we not see it in this case?
Shouldn't we see it in all cases?
Thanks in advance!
Solved! Go to Solution.
28 Jul 2026 10:22 AM
Could you scroll down a bit to show tab with client IP's
Also, depending on your privacy settings, this can result in different values being returned.
For example, with the following configuration, every IP address will be truncated to a /24 subnet, meaning the last part of the IP will always be returned as 0.
28 Jul 2026 12:09 PM
There is nothing in Client IPs
And this is disabled
29 Jul 2026 01:02 AM
Hi @elenaperez
The reason the Client IPs tab is empty here is not IP Masking. Masking anonymizes/truncates captured IPs but it doesn't make the field disappear it would still show a truncated value.
The empty tab means Dynatrace never captured an IP for these calls at all. In this case that's expected, because the calls falling into "unknown hosts, pages or devices" here are backend RPC/service calls (e.g., XMLRPCServer, ISWebServiceRegisters) — not browser-originated requests. There's no RUM beacon and typically no X-Forwarded-For/X-Real-IP header on service-to-service calls, so there's no IP for OneAgent to extract.
A few things that can affect this:
Missing forwarding headers: if calls pass through Envoy/Istio Ingress and the proxy doesn't forward X-Forwarded-For or X-Real-IP, Dynatrace has nothing to read.
IP Determination settings (Settings > Web and mobile monitoring > IP determination): useful when a custom header carries the real client IP through multiple proxy hops but this only helps if an IP is present in some header to begin with.
Non-HTTP/RPC traffic: for backend service calls without browser origin, there's often no client IP concept in the payload at all, so this is expected behavior rather than a bug.
Could you confirm whether these XMLRPC/RPC calls are expected to pass through a proxy that sets X-Forwarded-For or a similar header? If not, this would be expected behavior rather than a configuration gap on our end.
Thanks,
Sujit
Featured Posts