One VPN Completed the Age Check—The Other Kept Restarting It

The age-verification page accepted my face scan, displayed a confirmation, and sent me straight back to the beginning. I was on hotel Wi-Fi with a well-known VPN connected, trying to open an adult site I already used at home. The first attempt ended with another age prompt. The second produced a CAPTCHA. On the third, the site said the session had expired. I changed browsers, cleared the site data, and completed the scan again. The verification succeeded every time. Access did not.

I was in Newcastle for a two-night work trip.

The hotel connection was public, so browsing without protection did not appeal to me. I was not trying to avoid the site’s age requirement. I had selected the available estimation method and followed every instruction.

I simply wanted the successful result to remain valid long enough for the library to open.

Instead, one VPN turned a two-minute check into a loop.

That changed the question. I was no longer asking whether a VPN could reach the site.

I was asking why one VPN could carry the verification through to the end while another kept breaking it.

The successful scan was only the middle of the process

Age assurance had become a normal part of UK access rather than an occasional warning. By June 2026, Ofcom said 64 of the UK’s 100 most popular pornography services had introduced age assurance, while another ten were blocking UK users. (Ofcom)

From my side, the process looked simple:

Open the site.

Complete the check.

Return to the content.

But the confirmation screen was not the finish line.

The browser still had to return from the verification provider to the original session. If the route changed or looked suspicious during that handoff, the site could add a CAPTCHA, discard the result, or start the process again.

That matched what I was seeing.

The age check accepted me.

The route around it kept failing.

Once that distinction was clear, changing cameras, browsers, and cookies stopped making sense. The next thing to examine was the VPN exit carrying the session.

The established provider had chosen a crowded exit

The VPN I was using had years of public history, mature applications, and a large server network.

Those were good reasons to trust it before the trip.

Its automatic mode selected a fast nearby server. Ordinary pages loaded immediately, and the connection felt responsive.

The age-verification flow behaved differently.

After the first loop, I checked the exit address. It belonged to a large shared VPN location used by many customers at once.

A site does not have to dislike the individual user to distrust the address. A heavily reused exit may already be associated with automated traffic, repeated login attempts, scraping, or earlier abuse. Security systems can also recognise that the address belongs to a data centre rather than an ordinary home connection. (Didit)

My own session was legitimate.

It still arrived through an address carrying the history of everyone who had used it before me.

The VPN was connected.

The exit simply did not look ordinary enough to the site.

Changing servers created a new problem each time

I selected another server manually.

The age page opened.

I completed the scan.

The browser returned to the adult site and displayed a CAPTCHA.

I solved it.

The age prompt appeared again.

A third server avoided the CAPTCHA, but the hotel Wi-Fi weakened for several seconds. The VPN reconnected through another exit, and the verified session disappeared.

That recovery would have been helpful during ordinary browsing.

Here, it made the journey look less consistent.

The age check began from one shared address and returned from another.

From the site’s perspective, the user had entered a sensitive verification flow, vanished briefly, and reappeared through a different route.

The provider gave me many more servers to try, but each choice reopened the same questions:

Was the address already recognised as a VPN?

Did it have a poor reputation?

Would the app keep using it if the hotel connection dropped?

The server list looked impressive until I had to test it one address at a time.

At that point, abundance had become trial and error.

The inconsistency was the clue

Other users have described the same practical mismatch: one VPN location reaches an age-gated service while another from the same provider triggers detection or another verification request. (Reddit)

That detail mattered because it ruled out the idea that a site simply “supports” or “blocks” an entire VPN brand.

The site sees the route in front of it.

One exit may look stable and unremarkable enough to complete the handoff.

Another may arrive through a crowded address, trigger extra scrutiny, and change again before the session finishes.

Both VPN apps can display the same green Connected status.

Only one route may survive the entire process.

The question was no longer which provider offered the most servers.

It was which connection could avoid becoming the most suspicious part of an otherwise valid age check.

A free extension protected too little of the journey

I briefly installed a free browser VPN.

It required no payment and connected within seconds.

The adult site opened, but the age-verification provider did not remain inside the same protected route. When the browser returned to the original tab, the site treated the result as a different session.

The prompt reappeared.

That attempt clarified the requirement even further.

Opening the first page was not enough.

The VPN had to carry the browser through the verification service, back into the original session, and onward to the player without exposing a new route halfway through.

I removed the extension.

By then, I did not want another list of locations or another temporary workaround.

I wanted one route chosen for the situation rather than one I had to diagnose myself.

The smaller app began with the task

OnlydogVPN was installed from an earlier test.

It had fewer server locations, a shorter public history, and fewer independent reviews than the established provider. Those were the reasons it had remained a backup.

That evening, fewer visible choices became an advantage.

The app did not begin with a map. It offered situation-based presets.

I selected private browsing on public Wi-Fi.

The service connected without asking me to compare nearby servers, switch protocols, or create a conventional email-and-password account.

Then I reopened the adult site.

The age prompt appeared again.

I started the same estimation process I had already completed several times.

The camera opened.

The result was accepted.

The browser returned to the site.

This time, the library appeared.

No CAPTCHA.

No expired-session message.

No second age prompt.

I selected a saved video and pressed play.

The controls appeared immediately.

I moved the progress bar forward.

Playback resumed.

The verification had finally produced the result it was supposed to unlock.

The connection survived the next Wi-Fi drop

A few minutes later, the hotel connection weakened again.

The video paused.

With the first provider, this was the moment the route had changed and the age-verification result had disappeared.

This time, the player remained open.

The protected connection recovered.

Playback continued.

The smaller app uses an HTTP/3-based route designed to recover across unstable networks, along with obfuscation intended to make the VPN traffic less obvious. The practical result was much simpler than the technology behind it.

The hotel Wi-Fi faltered.

The route stayed usable.

The verified session survived.

The major provider had reacted to the interruption by finding another exit.

The smaller app kept the working journey together.

That was the difference I could actually feel.

The site was judging the route, not the logo

It would have been easy to conclude that the age-verification provider preferred one VPN company.

The behaviour pointed to something more practical.

The site did not see the brand name displayed inside my app. It saw an exit address, its reputation, the type of network behind it, and whether the route remained consistent from the first request to the final page. (Didit)

That explained why two servers from the same large provider produced different outcomes.

It also explained why speed was not the deciding factor. The established provider’s nearby servers were fast, but they kept attracting scrutiny or changing during the handoff.

The smaller app did not make me search for the right combination.

Its task-based connection completed the check and remained stable afterward.

For age verification, that mattered more than how many replacement servers were waiting in the menu.

The quieter page appeared after the main problem was solved

When the video ended, I returned to the smaller app to disconnect.

Its blocked-request counter had increased while the adult site was open.

Advertising and tracking requests had been stopped around the page.

That had not solved the verification loop. The route had already done that.

But it addressed a smaller concern that naturally followed the first one.

The verification provider needed enough information to return an age result.

The adult site needed enough traffic to deliver the video.

Unrelated advertising and tracking services did not need every background request surrounding the session.

The counter made that reduction visible.

It gave me a reason to keep the app installed after the immediate access problem was over. The connection had not only completed the verification; it had also made the browsing session quieter once the content opened.

A working VPN completes the entire handoff

I could not observe the site’s internal filtering rules or the exact reputation score assigned to each exit address.

I could see the outcome.

The established provider connected quickly through a crowded shared exit. When that address triggered friction, its large network gave me more servers to test. When the hotel Wi-Fi weakened, it recovered through a different route and broke the verified session again.

The free extension opened the first page but failed to carry the complete verification process.

The smaller app selected a route from the situation, carried the browser through the age check, opened the library, and preserved playback when the network faltered.

That was why some VPNs appeared to work with age verification while others did not.

The difference was not the presence of a VPN connection.

It was whether the route looked ordinary enough to be accepted and stayed consistent long enough to complete the job.

For this session, dozens of replacement servers mattered less than one discreet route that never needed replacing.