A New VPN Location Does Not Reset Notification Permission
Notification permission belongs to the site's origin, not to your IP. See which layer holds each grant and why push delivery looks broken over a VPN.
The idea that a VPN change can reset a site's notification permission is wrong in a way that costs people real time. Nothing about your exit address is part of the permission record. A site's grant is stored against its origin inside one browser profile, so moving from one server to another leaves it exactly where it was. What does change is your session, and that is usually what people are actually looking at when they decide the VPN did something to their notifications.
Three stores that look like one setting
The permission is one record, the operating system's notification switch is another, and the site's own subscription state is a third. Each is revoked in a different place by a different action.
| Layer | Where it lives | What actually revokes it |
|---|---|---|
| Permission grant | Browser profile, keyed by origin | Site settings, site reset, or clearing site data |
| OS delivery switch | Operating system notification settings | The OS per-app or per-browser toggle |
| Push subscription | Push service, bound to a service worker registration | Unsubscribe, or a subscription the service considers expired |
What the grant is attached to
Web notification permission is per origin and per profile. It follows https://app.example.com rather than your public address, which is why the same site asked on a different machine still has to ask again, and why a different VPN endpoint does not produce a new prompt. Check it where it is recorded: the notifications panel in site settings lists granted origins, and the page itself can report its state.
chrome://settings/content/notifications
navigator.permissions.query({name: 'notifications'})
chrome://serviceworker-internalsThe query reports the state the origin already has without prompting for a new one, and the service worker page is where a registration and its push subscription live or fail to live. If the grant is there and delivery still fails, you are looking at the third layer rather than the first.
The push path is its own relationship
Web Push adds a subscription the page does not control directly. The browser requests a PushSubscription from a push service, hands the page an endpoint URL, and delivery later goes to that endpoint and is passed to the registered service worker. MDN's PushSubscription documentation describes the endpoint as a custom URL at a push server for the subscribing worker, which is the whole point: it is a delivery capability, not a public address you publish.
Two consequences follow. First, an endpoint URL should be treated as sensitive, so it does not belong in a public support thread. Second, the push service enforces its own authentication, so holding the URL alone is not proof that anyone can send an authenticated message. When you unsubscribe, the browser tells the push service to invalidate the subscription, and that is the action that ends delivery. Switching VPN servers is not that action.
Why the VPN looks guilty
Change your exit address and many sites re-authenticate you, rotate a session cookie, or re-render their settings page from scratch. Notifications from that site can then stop for reasons that have nothing to do with permission: the new session is not the subscribed one, the site re-checks its own marketing consent, or a region rule hides the feature. Delivery can also fail because the push endpoint host is unreachable or slow through the new path, which looks identical to a revoked permission from the outside.
Read the layers separately before concluding anything. The permission panel says whether the grant exists; the service worker list says whether a registration and subscription exist; the OS switch says whether the browser may display anything at all.
Change what you meant to change
If you want notifications to stop, revoke the grant for that origin and unsubscribe the site's push setting, then confirm the OS switch is not the only thing standing between the site and your lock screen. Blocking future notifications does not delete the account data the site already has, and that is a separate request to the site.
If you want a different network path, change the VPN. It affects session identity, geo rules and which servers you can reach, and it leaves notification permission untouched.
Treat a notification's content with the same suspicion over a VPN as without one. A familiar browser rendering a message is not evidence that the sender or the link is legitimate.