Logging out of a VPN app is not the same as removing a relay

A user closes the VPN window, sees the disconnected icon, and considers the matter finished. If the installed product also forwards other people's traffic, that icon answered a much smaller question than the one being asked. Three separate outcomes sit behind a single disconnect button, and only one of them is about your own session. Work them in order, because each has different evidence and a different owner.

Three outcomes hide behind one disconnect button

Your own session ending is the narrowest outcome: the client stops carrying the traffic you selected, and the tunnel state returns to idle. Forwarding participation ending is a different event, because it concerns a component that serves requests for someone else and the authorization that permits it. Stored records being handled is a third event entirely, since it involves information the provider already kept on its side.

Those three do not share a switch. Uninstalling a local application does not delete a remote record, and deleting an account does not necessarily stop a background component from running on a device you forgot about. Each outcome also has its own owner: you, the device administrator, or the provider's support team. Confusing them produces the familiar situation where everyone believes the work is finished and one of the three jobs is still open.

The confusion is understandable, because all three are reported through the same interface. A tray icon can only describe the state the client knows about, and a client that has been told to stop showing a connected state has no reason to mention a helper process. Treat the icon as a status light for one subsystem, not as an inventory.

What the published policy actually promises

Some free products say plainly that using them can place a device on a peer network. Hola's privacy notice dated April 14, 2026 is one example: it warns that people using the free tier of its listed services can end up acting as a peer on the Bright Data network. That is a conditional statement published by the provider, not proof that a specific device or edition is forwarding requests right now.

Read such a statement for its conditions: which products, which editions, which platforms, and what the user is said to consent to. A sentence that covers "listed products and services" does not automatically cover an older build, a paid tier or a browser extension that has been removed from the store.

It also does not tell you what the operator retains after participation stops. Retention periods, account records and request logs are governed by separate sections of the same document, and often by a different team than the one that ships the client.

Check the local component, not the window

Start from what is installed and running on the device, because that is the part you can verify. A VPN client that uses a system extension, a helper daemon or a browser extension leaves more than one artifact, and the visible application is usually the least informative of them.

launchctl list | grep -i -E 'vpn|relay|peer'
ss -tunp state established | grep -v 127.0.0.1

The first command lists launchd jobs whose labels mention the relevant terms, which is where a background helper appears on macOS. The second prints established sockets with owning processes on Linux, so a connection you did not initiate has a chance to show itself. Neither command is a complete audit, and neither proves intent, but both beat reading a menu bar icon.

On Windows the equivalent first step is a service and process listing rather than a launchd query, and on any platform the browser extension inventory matters when the product ships one. Record what you find with timestamps before changing anything, because the state after removal is not reconstructable later.

A shared exit address is not an inventory

A dashboard showing an address you recognize does not establish that a particular device is forwarding traffic. For a request to traverse your machine there must be a working path that performs the forwarding, and an idle application window is not evidence of that path. The reverse is also true: an unused window says nothing about components that run without a window.

Addresses are weak identifiers in general. Carrier-grade NAT, office egress and shared provider exits all put many clients behind one public address, so an address seen in a log may belong to any of them.

When several devices share an exit, separate the one being retired from the others before drawing conclusions. That means listing the authorized devices and their own connection records, not matching a single address to a single machine.

Close the loop with evidence, not a cleanup utility

Use the provider's official opt-out or removal process, and keep a record of what was removed and when. Follow the documented steps for the exact product and platform, since instructions for another edition rarely enumerate every component on this one.

If activity continues after supported removal, preserve the relevant timestamps, process names and connection records, then contact the legitimate operator or the device administrator. Write down what you observed before you changed anything, because the post-removal state cannot be reconstructed afterwards. Reaching for a scrubbing tool whose publisher nobody can name turns a question about one address into a genuine incident. A support ticket with a timeline is worth more than a machine scrubbed by something nobody can name.

Finish by writing down which of the three outcomes you actually completed: session ended, component removed, records addressed. A note that names one of them honestly is more useful than a checklist that claims all three because the icon went grey.