Why a browser test can show several IP addresses

Core idea

WebRTC gathers ICE candidates from local interfaces, STUN-derived server-reflexive addresses, and TURN relays. A browser HTTP proxy does not necessarily control every media path.

For Why a browser test can show several IP addresses, map IP, DNS, cookies, account state, location permission, headers, and browser characteristics. Each signal comes from a different component. A proxy changes the exit path for supported traffic, but it does not clear the profile or revoke browser permissions.

What the primary source establishes

The practical goal is to verify why a browser test can show several ip addresses in one controlled, authorized workflow and separate documented behavior from client-specific assumptions.

The primary source, RFC 8828, defines the technical baseline but not every client and provider configuration. Read the normative behavior with its version and then verify your implementation. Treat anything beyond the source as a product feature that needs separate confirmation.

Controlled lab

Collect ICE candidates on a controlled page without a call or media transfer. Compare a clean direct profile with browser proxy settings, classify host, server-reflexive, and relay candidates, then test TURN or policy separately.

Step-by-step verification

On a test page you control, record candidate types and compare with WebRTC disabled or TURN-only policy. Redact real local addresses from reports.

Use a clean test profile and a page that reports only required diagnostic values. Save a direct baseline, then connect the proxy without changing cookies, locale, or permissions. Change one signal at a time so route effects remain separate from browser state.

Check the network channels the application actually uses: HTTPS, DNS, and WebRTC where relevant. Do not trust one unknown diagnostic widget. For sensitive work, use a controlled endpoint with minimal logging and automatic deletion.

• Collect direct ICE
• Repeat with proxy
• Classify candidates
• Test TURN separately

Evidence to retain

Keep candidate type, address family, time, and configuration. Mask private addresses and do not resolve mDNS labels.

Record signal categories and whether they matched instead of storing a complete fingerprint. Exit country, DNS mode, and cookie state are often enough. Exact coordinates, account IDs, and a full user agent usually add risk without improving diagnosis.

Define report columns and time format before the run. A result without context becomes a guess: the address, cache state, and changed condition are unknown. Record controlled failures as well as successes so the check proves that it can distinguish states.

Interpreting the result

Several IP values do not automatically mean identity exposure; candidate type and reachability matter, and blocking UDP can break legitimate calls.

An HTTP proxy may not control UDP/STUN. Multiple candidates do not by themselves prove content leakage.

One successful run confirms only one client, route, and moment. Repeat while changing one variable and state the limits. When observation conflicts with documentation, rule out cache, client version, and intermediaries before creating a reproducible support case.

Worked decision process

Map observers for Why a browser test can show several IP addresses: local network, DNS provider, proxy, origin, browser profile, and account. List the signals each receives and why they are required. An IP change affects only part of this map.

Test clean and working browser profiles separately. Hold cookies, locale, time zone, and permissions constant, then vary one signal. Identify which component produced every reported address before disabling features or adding extensions.

Use a short retention period for diagnostics. Exit country, time, and discrepancy category often suffice. Keep exact coordinates, account IDs, full fingerprints, and page content only when justified, then remove raw artifacts after the issue closes.

Common mistakes

A new IP does not create a new identity, and private browsing is not total anonymity. One proxy switch may not control every UDP channel. If several addresses appear, identify the source of each before changing configuration or disabling application features.

Stop when errors rise, a source returns a limit, the task would require bypassing protection, or secrets enter logs. Save sanitized diagnostics and correct the cause first. More concurrency or another IP can hide the fault and add load without improving evidence.

Rollout and maintenance criteria

Define the decision boundary before rollout: which observation permits continuation, which requires review, and which stops the workflow. Record acceptable error ratio, maximum wait, and the owner of every exception so a temporary failure cannot silently become permanent configuration.

Review real load, cost, and quality after the first week. Schedule a small control after client, proxy-service, or network changes. Archive outdated instructions with their replacement date and reason so operators do not follow conflicting configurations.

Operational checklist

Turn the successful experiment into a short procedure covering owner, safe configuration, limits, and stop conditions. Every run needs a terminal status. After browser, library, or network changes, run a small control before the main queue.

• Signals are mapped
• A test profile is used
• One factor changes
• Relevant channels are checked
• Data is minimized
• Claims match the measured scenario