Peakhour.IO - IP Intelligence

Privacy Relay, Corporate VPN, or Residential Proxy?

2026-08-01T12:00:00+10:00

An application sees a login from an address that does not match the user's apparent location. The connection belongs to a relay, VPN, or proxy network.

That is a reason to look closer. It is not a reason to call the user malicious.

Privacy relays, corporate VPNs, consumer VPNs, carrier-grade NAT, and residential proxies all weaken the old assumption that an IP address describes one person in one place. They do it for different reasons and with different operating models. A security policy that reduces them to anonymous=true will either miss abuse or punish legitimate users.

Privacy Services Deliberately Separate Identity from Destination

Apple says iCloud Private Relay uses separate internet relays so no single party can see both who a user is and which sites they visit. It also lets the user preserve a general location or use a broader country-and-time-zone location. Apple's Private Relay overview explains the scope and the role of the relay addresses.

That design changes what a website can infer from the source IP. It does not remove the session, account, route, browser, or request behaviour available to the application.

A corporate VPN creates a different pattern. Many employees may exit through a small set of company gateways. The source can be stable and organisation-owned, but the address still represents a population rather than one device. A consumer VPN may rotate gateways and mix unrelated subscribers. Carrier-grade NAT can make a normal mobile or broadband address shared even when no privacy product is involved; RFC 6598 documents shared address space reserved for carrier deployments.

Residential proxy services are different again. A remote operator deliberately routes through consumer or ISP connectivity so the destination sees the household exit. Mobile proxy services use the same broad model through carrier connectivity, but should remain separately labelled because their sharing and attribution conditions differ. Either form of supply may come from an informed participant, an embedded SDK, compromised software or another path.

The network categories matter. They still do not establish intent.

Define the Expected Population

Policy should reflect the application and route.

A workforce portal may know its corporate VPN ranges and require device or certificate evidence. A consumer service should expect mobile networks, privacy relays, travel, and shared households. A country-restricted service may need stronger location verification than an online catalogue. An API used by fixed partners can enforce network expectations that would be unreasonable on a public login page.

Ask:

Is this network type expected for this user population?
Is the route public, authenticated, sensitive, or expensive?
Does the account have established device and session history?
Is the apparent location material to the transaction?
Can the client provide another form of evidence?
What does a false rejection cost?

The answer determines whether the network signal should be ignored, logged, challenged, or combined with stronger controls.

Use Context to Separate Risk from Privacy

Peakhour IP Intelligence and Residential Proxy Detection place network context beside credentials, device history, fingerprints, behaviour, route, and recent events.

Consider two logins through privacy infrastructure.

The first uses an established session, familiar device history, a normal route sequence, and one successful authentication. The second attempts many accounts, carries an exposed credential, has no normal session history, and repeats the same failure pattern across rotating addresses.

Both hide or replace the direct source address. Only one presents a strong account-abuse pattern.

The policy should be able to express that difference. Blocking every relay or VPN is not contextual security. It is a network-category ban.

Geography Needs the Same Restraint

IP geolocation is an estimate of network presence, not proof of a person's physical location. VPN gateways, relays, mobile routing, satellite networks, corporate egress, and proxy exits can all separate the address from the user.

Use geography as evidence proportionate to the decision. A content preference may tolerate a coarse estimate. A regulated transaction may require account evidence, verified identity, payment context, or an explicit location control beyond an IP lookup.

Avoid impossible-travel rules that treat every IP change as physical movement. A session can switch between mobile, Wi-Fi, VPN, and relay paths without the person travelling at all. Look for continuity in the account, device, session, and behaviour before escalating.

Choose an Action That Can Be Recovered From

The action can then scale with the evidence:

Allow expected privacy or corporate access with consistent session evidence.
Log an unfamiliar network category on low-consequence routes.
Apply tighter rate limits when repeated behaviour spans accounts or rotating exits.
Challenge an interactive client when network change appears beside account risk.
Require step-up verification for recovery, payment, or access-control changes.
Block confirmed automated abuse with bounded route and policy scope.

Challenges are not perfect humanity tests. Automation can complete them, while privacy tools, accessibility software, or broken browser environments can cause legitimate failures. Measure completion and provide a recovery path.

Retain the Reason

When a policy acts, retain the network category, source, route, contributing evidence, action, and outcome. “Anonymous IP” is too vague for support or incident review.

The record should show whether the deciding factor was proxy use, an exposed credential, failure velocity, a new device, a route sequence, or several observations agreeing. That evidence lets the team tune the control without adding broad exceptions that erase protection.

Privacy and security are not opposing verdicts attached to an address. They are requirements the application has to handle at the same time.

Google Chrome IP Protection vs Apple Private Relay

2023-10-25T13:00:00+11:00

Apple Private Relay and Google Chrome IP Protection both reduce how much a destination can learn from a user's original IP address. The similarity ends quickly.

Apple protects eligible Safari browsing for iCloud+ subscribers. Chrome protects selected third-party requests in Incognito. A security policy needs that scope before it decides what the changed address means.

Apple Private Relay

Apple's Private Relay documentation describes two separate relays. Apple operates the first and can see the subscriber's source address without seeing the requested destination. A third-party content provider operates the second, assigns a temporary address and connects to the destination without receiving the subscriber's original address.

Users can preserve their general location or use a broader country-and-time-zone location. Private Relay is part of iCloud+ and protects supported Safari browsing. It is not a full-device VPN.

Chrome IP Protection

Chrome's IP Protection documentation describes a narrower request filter. In Incognito, Chrome proxies third-party requests when the third-party domain is on the Masked Domain List. It uses two chained proxies and supplies a coarse-geolocation address.

The protected resource is embedded in another site. Chrome does not describe IP Protection as proxying every top-level request or all device traffic.

The Operational Difference

Question	Apple Private Relay	Chrome IP Protection
Who receives it?	Eligible iCloud+ users who enable Private Relay	Chrome users browsing in Incognito with the feature available
What traffic is in scope?	Supported Safari browsing	Listed third-party requests
How is the destination reached?	Two separate relays	Two chained proxies
What address reaches the destination?	A temporary address with selected location precision	A proxy address with coarse geolocation
Is it a full VPN?	No	No

Neither service is a residential proxy marketplace. The user activates a browser privacy feature; a remote buyer is not renting the user's connection as an exit.

That does not make every relayed request trustworthy. It means the network label should be accurate. If a login or transaction is risky, the application should explain that decision with account, route, client and behaviour evidence rather than calling privacy use malicious.

The current policy guide is Privacy Relay, Corporate VPN, or Residential Proxy?. For the broader network taxonomy, see Residential Proxy vs VPN vs Tor.

Google Chrome's IP Protection and Online Privacy

2023-10-24T13:00:00+11:00

Google Chrome's IP Protection has moved well beyond the broad proposal we first covered in 2023. Its current scope is specific: selected third-party requests in Incognito are proxied when the third-party domain appears on Chrome's Masked Domain List.

That detail changes the security discussion. IP Protection is not a general-purpose VPN and it does not replace the address for every request made by the browser.

What Chrome Proxies

Google's IP Protection overview says the feature applies to requests made in a third-party context to domains on the public Masked Domain List. A top-level site and its ordinary first-party requests are outside that stated scope.

Chrome replaces the user's original address with an address carrying coarse geolocation. The implementation uses two chained proxies so neither proxy should receive both the original client identity and the final origin identity. Blind-signed authentication tokens are intended to prevent the proxy from linking handled traffic back to the signed-in Chrome account.

This is a privacy control aimed at cross-site tracking. It should not be described as a general anonymity service.

What a Website Will Notice

A listed third party can receive requests from the proxy address rather than the user's direct address. That weakens IP-based linking across sites and may alter geolocation, rate and reputation assumptions at the third-party service.

The top-level application still has its own first-party request, session, account and route evidence. Security teams should avoid turning one network category into a verdict. A Chrome privacy relay, corporate VPN, consumer VPN and residential proxy have different operating models even when each obscures the original source address somewhere in the journey.

Keep Abuse Controls Attached to the Route

An application should handle the network change the same way it handles other privacy infrastructure: retain the category, then evaluate what the request is trying to do.

On public content, the changed address may require no action. On login, recovery or payment, combine it with account history, credential evidence, device continuity, request sequence and recent outcomes. Rate limits should use keys that survive shared or changing addresses.

Privacy Relay, Corporate VPN, or Residential Proxy? provides the operational policy. For the browser comparison, read Google Chrome IP Protection vs Apple Private Relay.