Identify iCloud Private Relay by capture point—not by port alone

To identify Apple’s iCloud Private Relay, first decide which side of the service you can observe. On a client’s network, correlate Private Relay service-name lookups with connections to the returned addresses. At a website, compare the connecting client address with Apple’s published relay egress ranges.

UDP port 443 alone is not a Private Relay signature. A DNS query alone is not proof of a working relay session. The useful result is a classification supported by several observations—not a reconstruction of someone’s browsing history.

Inspect only devices, networks and server logs you own or are authorized to examine. Keep captures private; redact addresses, identifiers, tokens and payloads before sharing examples.

What your capture point can see

Private Relay sends protected requests through two relays. Apple operates the first, or ingress, relay; a separate provider operates the second, or egress, relay. The first sees the user’s original public IP address but not the requested website name. The second connects to the website using a relay IP address without knowing the user’s original address. Apple’s service explanation describes this separation.

Observation point	Useful evidence	Important limit
Client LAN, access point or gateway	Visible service DNS, destination addresses, transport, timing and byte counts	Protected website names and requests are inside the relay connection
Website’s public-facing edge	Connecting source IP matched against relay egress ranges	The relay address is not the user’s original IP or a unique user identifier
Origin behind a CDN or reverse proxy	Client address supplied by your correctly configured, trusted edge	The origin’s immediate socket peer may be your proxy rather than the relay

Apple documents coverage for Safari browsing, DNS resolution and insecure HTTP app traffic. Do not assume every connection from an Apple device is relayed. Apple’s developer guidance defines the service’s scope.

On the client network: correlate DNS and transport

1. Capture one authorized client

Start capturing before the test device connects or begins the test. Prefer a client-side or LAN-side capture where you can distinguish that device. A WAN-side capture after NAT may combine several devices under one source address.

Record the OS version, capture interface, test time and Private Relay status for the current network. If you need help selecting an interface, see how to capture packets from a wireless client.

2. Find the relay service lookups

Apple identifies these hostnames as necessary for Private Relay traffic:

• mask.icloud.com
• mask-h2.icloud.com

Use this Wireshark display filter, not a capture filter:

dns.qry.name == "mask.icloud.com" || dns.qry.name == "mask-h2.icloud.com"

The hostnames come from Apple’s network guidance; dns.qry.name is documented in Wireshark’s DNS field reference.

For each matching exchange, inspect:

• Query source and time: which client asked, and when?
• Response code: was resolution successful, rejected or unanswered?
• Answer records: which IPv4 and IPv6 addresses were returned? Follow any CNAME chain and note the TTL.

A lookup is consistent with service discovery, but does not establish that Private Relay is enabled or working. An NXDOMAIN response, an empty answer or repeated unanswered queries does not demonstrate successful relay use.

This distinction matters in real telemetry. Cisco’s Black Hat USA 2026 report recorded 4.42 million requests for mask.icloud.com, with 99.7% blocked. Those are DNS request counts—not counts of successful relay sessions, users or visited pages.

No matching DNS packet is also inconclusive: the answer may already be cached, resolution may be encrypted, or the capture may have started too late.

3. Follow connections to the returned addresses

Now inspect traffic between that client and the addresses in its DNS answers. Apple documents Private Relay’s QUIC transport over UDP port 443 with TLS 1.3. Start with:

udp.port == 443

This selects traffic with source or destination UDP port 443, as defined in Wireshark’s UDP reference. Narrow the result to the client and answer addresses using the packet address fields or the Conversations window.

Look for a conversation that begins near the successful lookup and carries bidirectional traffic during the test. Also check existing conversations: a relay connection may already be established. If Wireshark recognizes QUIC, inspect that protocol tree too—but do not treat a QUIC label as an application identity. Ordinary HTTP/3 traffic can use the same transport and port.

Do not reject Private Relay solely because UDP is absent. Apple’s December 2021 architecture overview documents HTTP/2 over TLS 1.3 as a fallback when QUIC is blocked. Check TCP conversations to the observed service addresses as well; do not introduce blocking merely to force a different signature.

4. Validate with a controlled request

For stronger attribution, use your own test device and a public test website you control:

1. Confirm Private Relay is enabled and available on the test network.
2. Check that capture timestamps and server logs use comparable clocks and time zones.
3. Start the capture, then visit the test site in Safari.
4. Correlate the time with the candidate relay conversation.
5. Check whether the request’s client IP at your website matches Apple’s egress ranges.

If permitted, repeat with Private Relay temporarily disabled on that test device, then restore its original setting. Record the actual observations rather than assuming a particular address or transport change must occur.

The settings screen alone does not prove a specific flow was relayed. A controlled request ties device state, network traffic and server-side evidence together. Apple’s architecture overview also describes multiplexing website connections over a single QUIC connection, so timing alone cannot assign each burst of relay traffic to a particular website.

At a website: match the egress IP range

Apple’s developer page links its current IP geolocation feed and explicitly recommends the relay IP list for recognizing Private Relay connections. Use the feed linked under “Access IP geolocation feeds”, rather than copying a fixed list from a blog.

A practical classification workflow is:

1. Obtain the connecting client IP at the public-facing edge. Behind a proxy, use only the client-address mechanism configured for your trusted proxy chain—not an arbitrary incoming forwarding header.
2. Parse the feed’s address ranges as networks and test IP membership. Handle both IPv4 and IPv6; string-prefix matching is not subnet matching.
3. Record the matching range and feed retrieval time with the classification.
4. Refresh the feed periodically. If an update fails, retain the last successful version but flag its age in your classification records. For historical logs, prefer a retained feed from the observation period.

This is an egress check. The published website-facing ranges should not be used as an ingress destination list for identifying a client’s connection to Apple’s first relay.

Apple also describes geo-IP annotations such as an Organization value of “iCloud Private Relay,” but database labels are supporting evidence. An Apple or CDN ASN, a generic “proxy” label or coarse geolocation alone is less specific than membership in the service’s published ranges.

Treat a match as Private Relay egress, not as a user identity or evidence of abuse. Apple notes that multiple users can share one relay address and recommends handling these addresses similarly to carrier-grade NAT or enterprise addresses. Its server guidance explains the implications for IP-based controls.

Report only what the evidence establishes

Keep three outcomes separate:

• Service lookup observed: the client resolved—or attempted to resolve—a documented hostname.
• Likely relay connection observed: successful resolution was followed by compatible traffic to the returned address during the test.
• Relay egress identified: a request reached your website from an address in the applicable published egress feed.

Neither a service lookup nor an outer encrypted conversation reveals the protected destination website. Packet sizes and timing can describe network behavior, but they are not a reliable browsing-history decoder. For the broader visibility boundary, see what HTTPS hides in a packet capture—and what it leaves visible.