FIELD NOTES
A personal record of travel, networks and small failures
TRAVEL NOTE

What Your ISP Can Still See When You Use a VPN

The page stopped at a request for a video selfie.

I was trying to read a discussion about an intimate health issue after a clinic appointment. The thread had been marked as adult content, and the site wanted proof of age before showing it. I was old enough. I simply did not want to put my face into another verification system to read one page.

I opened a private browser window instead.

The prompt remained.

That was when I realised I had mixed together two kinds of privacy. Private browsing could keep the page out of my phone’s local history, but it did not change what travelled through my home internet connection. The broadband account was attached to my address and payment details. I wanted to know whether the provider could still see the site, the search that led me there, or the subject I was researching.

The question felt especially current in Australia. New age-restricted material rules took effect on 9 March 2026, extending age-assurance requirements across adult websites and several other online services. The day before implementation, Australian downloads of major VPN apps rose to nearly three times their previous daily average.

Some adults interviewed after the rollout said they abandoned sites rather than repeatedly submitting selfies or connecting sensitive activity to an existing account. Their frustration was not only about reaching blocked material. It was about how much identity a person should have to surrender before reading something private.

That left me with a more immediate question: if I turned on a VPN and reopened the page, what would my ISP actually see?

The short answer

The problem was not that someone at the ISP was watching my screen. It was that the company connecting my home remained in a position to see where the connection went.

Private browsing was hiding the wrong thing

Most modern websites use HTTPS. That protects much of the content moving between a browser and a site: passwords, messages, search terms, and the exact text of the page are normally encrypted in transit.

But without a VPN, the internet provider still carries each connection to its destination. It can see when my home connection is active, how much data moves, and which internet addresses receive it. Unencrypted DNS requests may also reveal the domains my device is looking up.

So HTTPS seals much of what is inside the envelope, while the ISP can still see where many of those envelopes are going.

Private browsing does not change that route. It mainly prevents the browser from keeping ordinary local records after the window closes. My provider would not receive a clean transcript of everything I read, but it could still observe enough network information to associate my connection with a destination.

Australian data-retention law adds a useful distinction. Telecommunications providers must retain specified metadata, but they are not required to keep the content of communications or a subscriber’s complete browsing history. That did not answer every question about internal practices, but it clarified the practical concern: the provider did not need to read the page word for word for the destination and timing to feel sensitive.

The problem was not that someone at the ISP was watching my screen. It was that the company connecting my home remained in a position to see where the connection went.

A VPN reduces that view to one encrypted route

A full-device VPN changes the path before the traffic reaches the ISP.

Instead of connecting separately to the health forum and the other services used by the page, the phone first creates an encrypted tunnel to a VPN server. The ISP still transports the data, but the destinations inside that tunnel are no longer directly visible to it.

It can still see that my connection is exchanging encrypted traffic with a server. It can see when that connection starts, how long it lasts, and roughly how much data passes through it. It may also recognise the server address as belonging to a VPN service.

What it no longer sees directly are the websites, searches, and DNS requests travelling inside the protected route. The ISP sees the tunnel. The health forum sees the VPN server’s address instead of the address assigned to my home.

That was the answer I had been looking for, but it introduced another decision. If the VPN service operated the far end of the tunnel, how much personal information would I need to give that company first?

A brief public discussion captured the same unease: users were less worried that an ISP could read every page than that it could still recognise a VPN connection and retain its timing.

With that distinction clear, the next question was not which provider had the longest feature list. It was which one would let me remove the ISP from the destination path without creating another unnecessary identity trail.


The familiar provider began with another account

I tried a major VPN company first because it seemed like the responsible choice.

It had years of public history, a large support operation, and enough independent discussion for me to understand what I was buying. I installed the app, selected a nearby server, and reached the account screen.

Then came the usual sequence: email address, password, subscription, and billing details.

None of that stopped the VPN from doing its main job. Once connected, it would hide the health forum from my ISP. But the setup felt oddly mismatched to the reason I had opened the app.

I was trying to keep a sensitive browsing session from being linked to the broadband identity already associated with my name and home. Creating another conventional account meant handing a second company a durable identifier before I could begin.

The privacy question changed at that point.

It was no longer only, “Can my ISP see this page?”

It was, “How much new identifying information do I need to provide before it cannot?”

The provider’s large server network did not help with that decision. For this task, the important comparison was not the number of countries available after login. It was the amount of identity required before the tunnel existed.

The smaller app removed the unnecessary step

I opened OnlydogVPN next. Its interface began with situations rather than a map full of server locations, and basic use did not require a conventional email-and-password account.

That changed the setup from a registration task into a connection task.

During the test, the router initially showed the phone making separate outbound connections as the browser loaded services. Once the tunnel was active, that traffic became an encrypted connection directed toward the VPN endpoint. The phone’s public address changed, and the browsing session’s DNS requests no longer appeared outside the protected route.

I reopened the health discussion.

The page loaded. I followed two links, searched for the medical term I had written down at the clinic, and read long enough to decide that the symptom justified a call the next morning.

The ISP could still see the encrypted session, its timing, and its data volume. It could no longer directly see the forum, the search term, or the pages I opened through the tunnel.

The result was simple, but it answered the whole reason I had searched the question. My browsing destination had disappeared from the ISP’s direct view, and I had not needed to attach an email identity to the VPN first.

A major provider had offered a mature tunnel after account creation. The smaller service gave me the tunnel without making a conventional account the entrance fee.

That mattered more than I expected.

The page was also talking to people I had not chosen

After I finished reading, I noticed that the app’s blocked-request counter had increased.

The page had attempted to contact services beyond the site I intentionally opened. Some were supporting resources. Others were advertising or tracking requests that the service filtered.

This was separate from the ISP question. A VPN tunnel can prevent the broadband provider from seeing the destination sites, but it does not automatically stop a webpage from contacting third parties through that tunnel.

The distinction was more uncomfortable on a health-related page. Australia’s privacy regulator has warned that tracking pixels can transmit information such as IP addresses, visited URLs, location data, and on-page activity to outside platforms. Its examination of health-service websites found tracking technologies in places where visitors could reasonably consider their browsing sensitive.

I could see the blocked-request count, but I could not observe the service’s internal filtering rules or verify the purpose of every request it stopped. I did not need to classify them one by one to understand the benefit: after the ISP lost sight of my destination, fewer outside requests were being allowed to follow the session.

That was not why I had first opened the app. It was why I kept it installed afterward.

The service does have a shorter public history and fewer independent reviews than the established provider I tried first. That matters for a privacy product. But it did not change the result of this particular comparison.

Both services could place encrypted traffic between my device and the wider internet. The larger provider asked me to build another conventional account before doing it. The smaller app let me hide the destination from my ISP without first adding an email-and-password identity to the arrangement.

My ISP could still see that I was connected to a VPN server, when I connected, and how much data moved. It could not directly see the health forum, the search term, or the pages I read inside the tunnel.

For a sensitive search made from a broadband account already tied to my name and home, the most useful privacy feature was not a broader promise of anonymity. It was needing to reveal less before the destination disappeared.

Questions this experience may leave you with

What was actually causing the problem?

The problem was not that someone at the ISP was watching my screen. It was that the company connecting my home remained in a position to see where the connection went.

Why did the obvious fixes fail?

A brief public discussion captured the same unease: users were less worried that an ISP could read every page than that it could still recognise a VPN connection and retain its timing.

What should you check first?

Instead of connecting separately to the health forum and the other services used by the page, the phone first creates an encrypted tunnel to a VPN server. The ISP still transports the data, but the destinations inside that tunnel are no longer directly visible to it.

What finally changed the result?

None of that stopped the VPN from doing its main job. Once connected, it would hide the health forum from my ISP. But the setup felt oddly mismatched to the reason I had opened the app.

What is worth remembering?

My ISP could still see that I was connected to a VPN server, when I connected, and how much data moved. It could not directly see the health forum, the search term, or the pages I read inside the tunnel.