Filtering differs on Wi-Fi and mobile data because the phone may use a different resolver, network identity, encrypted DNS path, VPN state, or policy assignment after leaving the local network. Reproduce one hostname on each connection, confirm which resolver receives each fresh query, and compare the matched resource and action before changing policy. Fix the missing path or scope, not the filter.
Wi-Fi success proves only that the rule works on the Wi-Fi test path. It does not prove that the same phone, resolver, or identity exists on cellular. Preserve both states and compare them. If support changes policy first, a routing problem can masquerade as an exception problem and leave every other off-network device unresolved.
Treat the network switch as the experiment
Choose one phone, one exact hostname, and a ten-minute window. Keep the browser or app, user state, and test action constant. Request the hostname once on Wi-Fi, then turn Wi-Fi off and repeat on mobile data. Record local time, visible result, IP family when known, VPN state, browser Secure DNS state, expected resource, and expected policy action for each attempt.
| Evidence | Wi-Fi attempt | Mobile-data attempt |
|---|---|---|
| Resolver receiving fresh query | Observed resolver | Observed resolver |
| Resource or profile identity | Matched identity | Matched identity |
| Policy source and action | Rule evidence | Rule evidence |
| VPN or encrypted DNS state | Recorded state | Recorded state |
| User-visible result | Expected or unexpected | Expected or unexpected |
Use a genuinely new lookup when possible. An already loaded page or open application connection may continue without asking DNS again. DNS caches also reuse answers for a defined lifetime.1 If neither attempt creates a fresh query, the comparison is inconclusive; do not convert absence of resolver evidence into a policy diagnosis.
Follow the cellular query to its resolver
On Wi-Fi, a router may advertise a local or chosen resolver. On mobile data, the carrier, operating system, browser, VPN, security software, or an encrypted DNS configuration may select another resolver. The phone can therefore keep the same browser tab while leaving the policy path entirely. Confirm where the cellular query arrives rather than assuming the device name follows it.
- Look for the timestamped mobile-data query at the intended policy resolver.
- If absent, record the active browser, system, VPN, and security-app DNS choices before changing them.
- Check IPv4 and IPv6 because a protected path on one address family does not prove the other matches.
- Account for private relays or similar features that intentionally change parts of the connection path.
- Distinguish a captive-portal or connectivity failure from a successful lookup that received the wrong action.
Encrypted DNS is not inherently an error. It protects DNS transport between the client and its chosen resolver. The troubleshooting question is whether that chosen resolver is the approved policy resolver. Mozilla notes that Firefox DNS over HTTPS can bypass a local resolver and its filtering, while its protection modes and managed controls can change that behavior.3 Preserve privacy while resolving an unintended conflict.
Check whether resource identity survives roaming
A resolver needs a supported way to associate a roaming request with policy. A home or office source address may identify the Wi-Fi network, but a cellular address belongs to another path and can change. A device credential, managed profile, tunnel, or other provider-supported method may carry a resource identity off network. Verify the actual association rather than treating an IP address as a permanent person or device.
If the cellular query reaches the correct resolver but has no expected identity, it may receive a default policy. If it has the right identity but the wrong result, compare assignments and precedence. If it has the right identity and action but the app behaves differently, move above DNS and examine cached connections, application routing, proxy behavior, or content controls.
Separate policy drift from path drift
Path drift means the two tests use different resolvers or identities. Policy drift means both reach the intended resolver under the expected identity but evaluate different assignments or rules. Resolve path drift before editing policy. For policy drift, compare the effective baseline, enforced, resource, catalog, and exact-domain actions for the two events, including whether either action was merely log-only.
Different outcomes can be intentional. A household may protect a child resource differently from a parent phone; a team may apply a stricter managed-device policy than a personal device policy. The goal is not universal sameness. It is a result that matches the documented resource purpose on each network without weakening enforced Space or Tenant policy.
DNS evidence also has strict limits. It can show domain lookups and allow, block, redirect, or similar outcomes. It cannot see page contents, full URLs, searches, in-app chats, voice audio, or full browser history. RFC 9076 warns that DNS traffic can be triggered by applications and background activity, so use the controlled window rather than inferring user intent.2
Repair and retest the off-network case
Correct one proven boundary. Restore the approved roaming resolver method, repair the resource association, assign the intended reusable policy, or correct one mistaken domain action. Do not create a broad allow rule simply because mobile data was unfiltered; an allow rule at the Wi-Fi resolver cannot govern queries that never reach it.
Repeat the same Wi-Fi and mobile-data sequence. Confirm both fresh queries arrive where intended, carry the expected resource context, and match the documented action. Test one ordinary allowed task and one representative expected block on cellular. Record the root cause, corrected path or scope, owner, and when it should be reviewed after operating-system, browser, VPN, or carrier changes.
Wi-Fi versus cellular questions
Does a router DNS rule automatically follow a phone onto mobile data?
No. A router can direct or filter traffic that actually uses that network, but cellular data is a different access path. Off-network continuity requires the phone to reach the intended protected resolver through a supported device, operating-system, VPN, or provider method and to retain the policy identity expected by that resolver.
Should support disable browser Secure DNS during every cellular test?
No. First record whether it is active and which resolver receives the query. Disabling it immediately destroys a useful path difference and may reduce privacy. Change one setting only after evidence shows it conflicts with the intended policy, and follow the device owner's or administrator's approved configuration.
Can DNS filtering tell whether someone intentionally opened an app on mobile data?
No. DNS can show a domain lookup and policy outcome, but apps perform background refreshes, prefetching, and service requests. It cannot reveal page contents, searches, chats, voice audio, or full browser history. Use the short, reproduced test window to connect an event to a technical result without inferring intent.
Verify one roaming Veilty resource
In Veilty, put a household resource in its Space or a team resource in its Tenant and verify its intended off-network path. Reusable baseline and enforced policies can be assigned to either boundary; a resource may override baseline policy when permitted, but it cannot weaken enforced policy. Account invitations create membership only and grant no Space or Tenant access; accepted members need an assigned scoped role. Stored history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver still processes live requests. Compare one Wi-Fi and cellular event, correct the proven path or assignment, and retest both.