IP Addresses

Darwinium profiles IP Address through several technologies to check for corroboration vs. anomalies. Those assist indicating where VPN, Proxies or other connection manipulation is being used.

Returned in attributes of the form:

profiling.tcp_connection['PRIMARY'].ip_address
profiling.tcp_connection['HTTPS_PROFILING'].ip_address
profiling.tcp_connection['WEBRTC'].ip_address
profiling.tcp_connection['DNS'].ip_address
profiling.tcp_connection['FORWARD_FOR'].ip_address
profiling.tcp_connection['SDK_WIFI'].ip_address

TcpConnectionContext

✅ = Yes, ❌ = No, ❓ = Not the determining factor

PRIMARY

The primary public-facing IP of the request — the IP the outside world sees.

• Source: Captured at the CDN edge (CloudFront, Cloudflare, or Akamai) when a CDN is in the path. For JS-API deployments, is captured when the browser requests the Darwinium profiling tag. CDN takes priority when both are present.
• Useful for: General geolocation and network context. Detecting bots or scripted traffic that bypasses page or app profiling entirely, since those sessions will lack the dwn-profiling header.

HTTPS_PROFILING

The device's IP as observed by a direct HTTPS connection from the client to Darwinium's infrastructure, bypassing intermediate layers.

• Source: Client-initiated HTTPS request to the Darwinium packet fingerprinting server aps.wowscale.com. The request is visible in browser dev tools as what appears to be an image load.
• Useful for: Comparing the connection characteristics against PRIMARY to detect proxy or VPN use. Because this connection is made directly from the device, it is more likely to reflect the true client IP and can pierce through some proxy configurations that would otherwise mask it.

WEBRTC

The device's IP as captured server-side during a WebRTC probe, independent of browser or OS proxy settings.

• Source: TCP connection from the client to the Darwinium STUN/TURN server ats.wowscale.com during a WebRTC ICE negotiation. Because WebRTC bypasses proxy configurations at the OS and browser level, this IP is captured outside of normal routing.
• Useful for: Detecting VPN or proxy mismatches. A discrepancy of characteristics between WEBRTC and PRIMARY is a signal that the user's visible IP has been manipulated. Best used in combination with HTTPS_PROFILING for cross-validation.`

DNS

The IP of the DNS resolver used by the device to resolve a Darwinium-controlled domain - typically the user's ISP resolver or a public DNS provider.

• Source: A unique, never-before-seen subdomain under *.dxf.wowscale.com is generated per session. The DNS lookup must propagate all the way to Darwinium's authoritative DNS server, which records the IP of the resolver that made the query.
• Useful for: Identifying the user's ISP or DNS provider, and detecting broad geographic mismatches. Due to DNS resolver routing, this IP may only approximate the user's rough country or continent - it should not be relied on for precise location. A mismatch between DNS resolver geography and PRIMARY can be a secondary indicator of VPN or Proxy use, albeit the pattern is fairly common with genuine users too.

FORWARD_FOR

The originating IP declared by a forward proxy via the standard X-Forwarded-For HTTP header.

• Source: Extracted from the X-Forwarded-For header added by a proxy or load balancer in the request path. The value is self-declared by the proxy and not independently verified. Currently only parsed on Cloudflare, which does forward this header.
• Useful for: Confirming the presence of a proxy and classifying its type. Comparing this IP against PRIMARY can indicate whether the proxy is transparent, distorting, or anonymous. Its presence alone is a useful signal that the client is not connecting directly.

SDK_WIFI

The device's IP as seen directly over its Wi-Fi interface, captured by the native mobile SDK.

• Source: Observed directly from the device's active Wi-Fi network interface. App-level proxy configurations do not affect this value; however, device-level or network-level VPNs may. Mobile SDK only, and read Wifi state permission needs to be enabled to capture.
• Useful for: Identifying the physical Wi-Fi network a mobile device is connected to. Comparing against PRIMARY or WEBRTC can help detect device-level VPN use or unusual routing configurations on mobile applications.

WEBRTC_FROM_JS

The public IP self-reported by the browser via JavaScript during WebRTC ICE candidate gathering.

• Source: Client-side JavaScript ICE candidate collection — the browser reports its own perceived public IP without a server-side connection being required.
• Useful for: Complementing the server-side WEBRTC signal. Comparing the two can reveal discrepancies between what the browser reports and what the server observes, which may indicate manipulation or misconfiguration.

WEBRTC_UDP_JS

The public IP gathered from the UDP ICE candidate path via JavaScript.

• Source: Client-side JavaScript ICE candidate collection, specifically the UDP candidate. In some network environments the UDP and TCP paths route differently, producing a distinct IP.
• Useful for: Identifying network path differences between UDP and TCP routing, which can surface unusual network topologies or selective traffic routing policies.

WEBRTC_UDP_LOCAL

The private or LAN IP address of the device, as reported via WebRTC ICE candidates.

• Source: Client-side JavaScript ICE candidate collection — the local/private IP (e.g. 192.168.x.x) exposed during ICE gathering.
• Useful for: Detecting virtualised or emulated environments, where the private IP range or format may differ from a real physical device. Can also help identify unusual internal network configurations not visible from public-facing IP signals.