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

Why an Adult Site Keeps Asking You to Verify Your Age Again

I had already proved I was an adult.

The site asked me to do it again.

The first check happened the previous evening on my phone. I used facial age estimation, waited for the confirmation screen and opened the page normally.

The next morning, I joined the hotel Wi-Fi, opened a private browser window and returned to the same site.

The camera prompt reappeared.

I assumed the first verification had not saved. I completed it again, reached the page and closed the private window when I finished.

That evening, the site asked for my face a third time.

I cleared the browser cache, restarted the phone and tried once more.

The verification screen returned before the page did.

At that point, the problem was no longer proving my age. It was understanding why the site kept treating me as though I had never done so.

The short answer

I was asking the site to recognise one continuous adult visitor while repeatedly arriving through a different entrance with no previous session attached.

The Site Had Not Necessarily Forgotten

Since stronger UK age-check requirements took effect in July 2025, adult services have adopted different ways to remember that a visitor passed an age gate.

Ofcom’s 2026 review found that many services associate the result with an account, device or another persistent signal. Active users are not always asked to repeat the full check, although a new login or suspicious change can trigger another request. (Ofcom)

That distinction explained the apparent contradiction.

The site may not have stored my face or identity document. It may only have retained a simple result—adult or not adult—and connected it to the browser, device or account used during verification.

When I returned in a different context, that connection disappeared.

From my perspective, I was the same person.

From the site’s perspective, I looked like a new visitor asking for restricted content.

The first place to look, then, was not the verification provider. It was the browser session I kept replacing.

Private Browsing Erased the Evidence

My attempt to be more private had created the most obvious problem.

Websites use cookies and browser storage to remember what has happened between visits. That can include a login, preferences or a token showing that a required step has already been completed. (MDN)

A private window keeps temporary storage separate from the ordinary browser. When the last private tab closes, that session data is removed.

That was exactly what I had been doing:

Verify.

Open the page.

Close the private window.

Erase the browser’s memory of the successful check.

Return later as an apparently new visitor.

The site was not repeatedly rejecting the same proof. I was repeatedly deleting the small piece of browser state that told it the proof had already been accepted.

Once I saw that sequence, another detail made sense. A result stored in one browser would not automatically appear in another browser, on another device or inside a new private session.

The verification belonged to the remembered session—not to me everywhere on the Internet.

The Hotel Network Changed the Visit Again

Private browsing explained why the result disappeared. The hotel Wi-Fi introduced a second change.

Without a VPN, the site saw a British connection and immediately applied its UK age gate. I opened the established VPN already installed on my phone, selected a server outside the UK and refreshed the same tab.

The prompt remained.

That tab had already entered the UK flow. Changing the route underneath it did not restart the visit.

So I opened another private window.

The age prompt disappeared, but a CAPTCHA replaced it.

I completed the challenge and reached the homepage. When I opened another page, a second challenge appeared. The next server restored the age gate. A third loaded the page frame without its contents.

The provider had a large network and years of public history, which was why I had trusted it. But every attempt changed another part of the session.

A new server meant a new IP address.

A new private window meant new browser storage.

Closing the window erased whatever the site had remembered.

I was asking the site to recognise one continuous adult visitor while repeatedly arriving through a different entrance with no previous session attached.

Some Repeat Checks Are Intentional

Deleted cookies were not the only possible cause.

Ofcom also found that some services repeat age checks after events such as a new login, a change in behaviour or another risk signal. (Ofcom) A visitor who suddenly appears through a new country, device or shared VPN address may therefore be asked to prove age again even when an earlier result still exists somewhere else.

Public discussions reflect the same practical confusion: people verify on one device or session, then assume the result will follow them automatically to another. (Reddit)

That was the part I had misunderstood.

“Verified once” felt as though it should mean “verified forever.”

In practice, it often meant “verified in this remembered context.”

Once the context disappeared—or changed too sharply—the site asked again.


Rotating Servers Made the Session Less Continuous

I returned to the established provider and tried to create one clean visit.

This time, I connected before opening the site. I used my ordinary browser profile rather than a private window and selected a route outside the UK.

The page opened without an age check.

Then an unusual-traffic warning appeared.

I changed servers.

The next route produced a CAPTCHA. Another returned me to the regional age gate. The provider’s automatic option sent me back to the first shared address.

Shared VPN exits can attract additional challenges because many unrelated users arrive through the same IP address. (Cloudflare)

I could not observe the site’s internal filtering rules, so I could not know whether each interruption came from the address, the country change, the broken session continuity or several signals together.

The visible pattern was enough.

Every time I rotated servers, I made the visit look less stable.

The VPN changed my location successfully. It did not help the site keep one accepted version of the session alive.

That changed the comparison.

The useful service was not the one that gave me the largest number of countries to test. It was the one that let me establish one accepted route and stop changing the conditions around the visit.

The Smaller App Kept the Visit Together

I disconnected and opened OnlydogVPN.

Basic use did not require a conventional email-and-password account. That suited a situation in which I was already uncomfortable with the amount of identity information being requested.

The app did not begin with another country map either.

I selected the preset for reaching a restricted page and connected before opening the browser.

This time, I used my ordinary browser profile rather than a disposable private window. I opened a fresh tab, not the old tab that had already entered the UK age gate.

The homepage loaded.

The page I wanted opened next.

There was no camera prompt, document request or CAPTCHA loop. I moved between several pages without being asked to prove my age again.

That was the result I had been trying to create all day: one accepted route, one continuous browser context and no repeated verification.

The service uses task-based route selection with HTTP/3-based, obfuscated transport. The explanation was simple because the result was visible: I no longer had to rotate countries, rebuild the browser session or restart the visit after every challenge.

The established provider gave me more routes to manage.

The smaller app gave the site one stable visit to accept.

The Network Changed Without Restarting the Gate

Later, I left the hotel lobby and walked toward the lift.

The Wi-Fi weakened, and my phone moved onto mobile data.

The page paused briefly.

Then it continued.

I expected the network change to end the VPN session and send the next request through a British mobile address. That would have recreated the condition that triggered the age gate earlier.

Instead, the connection recovered. The next page opened without returning to verification.

That was the secondary benefit that made me keep the app installed.

The original problem was repeated age checks. Recovery across the network change prevented the session from falling back onto the local route and beginning the regional flow again.

I did not have to reopen the VPN, select another server or rebuild the browser session.

The service has fewer locations, fewer independent ratings and a shorter public history than the established provider I tried first. Those are real limitations in a broad comparison.

They did not determine what happened in the hotel.

The larger provider gave me more routes to rotate through, and each rotation disrupted the visit again. The smaller app supplied one usable route and kept it alive when the underlying network changed.

Clearing Cookies Was the Opposite of What I Needed

I had begun the troubleshooting process by deleting browser data.

That made sense when I thought a broken verification page was trapped in the cache.

Once the site had successfully recognised the session as adult, however, clearing everything removed the state I wanted it to retain.

The same was true of private browsing. It left less information on the phone after I closed the window, but it also guaranteed that the next visit would begin without the token or cookie recording the earlier result.

That creates a real privacy trade-off.

Keeping the remembered session reduces repeated checks.

Deleting it leaves less browser history but makes the site more likely to treat the next visit as new.

A VPN cannot preserve a cookie that the user deliberately deletes. What it can do is prevent the regional age gate from appearing in the first place and keep the accepted route stable after the page opens.

For me, that was more useful than completing the same identity check repeatedly.

The First Verification Had Probably Worked

By the end, I no longer believed the site had simply lost my result.

I had changed almost every condition around it.

I verified in a private window and then destroyed that window’s storage. I moved between hotel Wi-Fi and mobile data. I rotated through several VPN addresses. I refreshed tabs that had already entered a British age-check flow.

Each action made sense on its own.

Together, they made me look like a succession of unrelated visitors.

The established VPN changed the country but left me rebuilding the visit whenever a route was challenged. The smaller app let me begin outside the regional gate, use one ordinary browser context and keep the connection alive when the network changed.

The adult site had not necessarily asked the same recognised session to verify three times.

It had seen three disconnected visits—and the repeated prompts ended when OnlydogVPN kept the fourth one intact.

Questions this experience may leave you with

What was actually causing the problem?

I was asking the site to recognise one continuous adult visitor while repeatedly arriving through a different entrance with no previous session attached.

Why did the obvious fixes fail?

Ofcom also found that some services repeat age checks after events such as a new login, a change in behaviour or another risk signal. ( Ofcom ) A visitor who suddenly appears through a new country, device or shared VPN address may therefore be asked to prove age again even when an earlier result still exists somewhere else. (Org)

What should you check first?

The original problem was repeated age checks. Recovery across the network change prevented the session from falling back onto the local route and beginning the regional flow again.

What finally changed the result?

A VPN cannot preserve a cookie that the user deliberately deletes. What it can do is prevent the regional age gate from appearing in the first place and keep the accepted route stable after the page opens.

What is worth remembering?

The adult site had not necessarily asked the same recognised session to verify three times.