Android Hotspot and VPN Setup: The VPN Icon on My Phone Never Covered the Laptop

The client portal rejected my laptop for the third time.

Access unavailable from this network.

I was sitting in the unfinished lobby of a construction site outside Istanbul, with twenty-two minutes left to submit a revised tender. The final drawings were on my laptop. The signed approval was in my email. The upload package was 680 MB.

There was no building Wi-Fi yet.

I turned on my Android phone’s hotspot.

The laptop connected.

On the phone, my established VPN showed a green shield and a server in Germany. The same client portal opened normally in the phone’s browser.

I assumed the laptop was protected by the same route.

It was not.

I refreshed the laptop page.

The access warning returned.

I changed the VPN server on the phone, disabled the hotspot and turned it back on.

The laptop reconnected.

The portal still refused to open.

Then I checked the public IP address on both devices.

The phone showed the VPN server.

The laptop showed the mobile carrier.

The VPN icon had been telling the truth about the phone.

I had assumed it was also speaking for every device connected behind it.

The hotspot shared mobile data, not the VPN tunnel

Android describes hotspot tethering as a way to share the phone’s mobile-data connection with another phone, tablet or computer. (Google)

A VPN app does something different. It creates a protected route for traffic handled through the phone’s VPN interface. (Google)

Those two functions can run at the same time without becoming the same connection.

On a standard Android setup, a laptop connected to the phone’s hotspot usually receives internet access from the mobile connection but does not automatically inherit the phone’s VPN route. Sharing that VPN through the hotspot generally requires specialised configuration or a rooted device. (Protonvpn) ()

That explained every result on my screens.

The phone browser entered the client portal through Germany.

The tethered laptop went directly through the carrier.

Changing servers on the phone could never fix the laptop because the laptop was not using those servers.

The problem was not which VPN location I had selected.

The problem was where I had installed the VPN.

The green shield had created a false sense of completion

The established provider’s Android app had worked properly.

It had years of public history, a mature mobile application and a large server network. When I opened the client portal on the phone, the protected route behaved exactly as expected.

The mistake was mine.

I had looked at one green shield and treated it as a status indicator for the entire hotspot.

That assumption is common enough to appear repeatedly in public Android discussions: the phone shows an active VPN, while a tethered computer still exposes the carrier connection. (Reddit) ()

The laptop had never appeared inside the VPN app’s device list.

No setting confirmed that hotspot clients were included.

I had simply connected two devices and mentally merged their network paths.

With nineteen minutes remaining, the useful question changed.

I no longer needed to make the phone’s VPN cover the laptop indirectly.

I needed to protect the laptop directly.

“Always-on” did not mean “everyone behind the phone”

I opened Android’s VPN settings and enabled the provider as an always-on connection.

The shield stayed visible.

The phone’s browser continued using the VPN.

The laptop continued showing the carrier IP.

I checked split tunnelling next.

That setting controlled which applications on the phone used the tunnel. The hotspot was not another Android app waiting to be added to the list. It was a separate connection serving another device.

The terminology had encouraged the wrong expectation.

Always-on meant the phone should keep its VPN active.

It did not mean every computer, tablet or television using the phone as a router would automatically join it.

By then, fourteen minutes remained.

The tender portal still would not open on the laptop, and sending the package from the phone was unrealistic. The archive was large, the drawings needed one final filename check and the submission form required several reference numbers from a spreadsheet.

The work belonged on the laptop.

So did the VPN.

Installing the established provider directly took me halfway there

I downloaded the established provider’s laptop app over the hotspot.

Then came the account login.

I entered the email address.

I opened my password manager.

I approved the new-device verification on the phone.

The app connected.

The client portal finally opened on the laptop.

That confirmed the diagnosis immediately. The hotspot itself had not been the problem. The laptop simply needed its own VPN route.

I signed in to the portal, selected the tender package and began the upload.

Eight percent.

Fifteen.

Then the phone shifted from 5G to LTE.

The laptop remained connected to the hotspot, but the VPN changed to Reconnecting.

The portal stopped at 21 percent.

When the tunnel returned, the upload session had expired.

I selected another server and began again.

The carrier signal changed once more.

The upload stopped at 17 percent.

The established provider had now solved the device-coverage problem but introduced a new one. Its laptop route did not recover quickly enough when the Android hotspot’s underlying mobile connection changed.

I had nine minutes left.

Direct installation was necessary.

It was not sufficient unless the connection could survive the phone’s network.

The smaller app connected the laptop without another account chase

I closed the established provider and opened OnlydogVPN on the phone.

The smaller app displayed a verification code for adding another device.

I installed the laptop app and entered the code.

There was no second email-and-password login and no master password typed through the mobile connection.

The laptop joined the service directly.

That detail mattered because it removed the confusion at the centre of the setup.

The phone had its own protected route.

The laptop now had its own protected route.

The hotspot supplied internet access between them, but it no longer had to perform a job Android had not assigned to it.

I selected the situation for uploading work files over a mobile hotspot and connected.

Then I returned to the tender portal.

The login page opened.

The approval notification reached my phone.

The dashboard loaded.

I selected the archive.

The upload began.

Ten percent.

Twenty-five.

The phone dropped from 5G to LTE again.

The progress bar slowed but continued.

Forty.

Sixty-three.

The site manager walked into the lobby and asked whether the tender had gone.

“Almost,” I said, without believing it yet.

Eighty-six percent.

The portal processed the drawings.

A list appeared showing the proposal, approval letter and all twelve plan files.

I pressed Submit Tender.

The status changed to:

Submission received before deadline.

There were two minutes remaining.

Only after the receipt appeared did the connection design matter. The smaller service uses an HTTP/3-based, obfuscated route that recovered as the mobile path changed instead of forcing the upload session to start again.

I could not inspect the portal’s internal risk rules or the carrier’s filtering. The visible comparison was decisive: the VPN running only on the phone never covered the laptop, the established laptop route repeatedly lost the upload, and the smaller app completed it.

The hotspot became simpler once I stopped asking it to be a VPN router

After the submission, I looked at the setup again.

The Android phone had three clear responsibilities:

Maintain mobile service.

Create the Wi-Fi hotspot.

Provide the verification code used to add the laptop.

The laptop had two:

Run the applications required for the tender.

Protect its own traffic through its own VPN connection.

Nothing depended on hotspot traffic secretly entering the phone’s tunnel.

That made troubleshooting much easier.

When the portal failed before, I had changed servers on the wrong device.

When the laptop’s IP address remained unchanged, I had restarted the hotspot instead of checking its route.

When the phone showed a green shield, I had treated that as proof of protection somewhere the app could not see.

Once each device handled its own connection, the network diagram became almost boring.

That was exactly what I needed.

The route followed the laptop onto office Wi-Fi

The site office’s temporary broadband came online later that afternoon.

I disconnected the laptop from my Android hotspot and joined the new Wi-Fi.

The smaller service remained active.

The client portal refreshed without requesting another login.

The submission receipt stayed open.

The project messenger delivered a confirmation from the client:

Tender package complete. We have all files.

The laptop had changed from a phone’s mobile connection to the office access point, but the protected session recovered without another server choice. QUIC and HTTP/3 support maintaining connections as the underlying network path changes. (IETF) ()

That was a secondary benefit, but it completed the lesson.

The VPN belonged on the device doing the work.

Once it was there, the laptop could move between networks without depending on the phone to share more than internet access.

A hotspot VPN setup should begin with the destination device

There are specialised methods for sharing an Android VPN through tethering.

Some require root access.

Others use proxy software, custom ROM features or manual settings on every connected device.

Those methods can be useful for people who deliberately want the phone to act as a VPN router.

They were unnecessary for my tender.

I did not need to redesign Android networking.

I needed one laptop protected quickly.

Installing the service directly on that laptop was easier to verify and easier to trust. The IP check matched the VPN route. The work applications used it. The upload result proved it.

That leads to a practical order for Android hotspot setups:

First, turn on the hotspot and confirm that the second device has internet access.

Then install or activate the VPN on the device that will actually browse, upload, stream or work.

Finally, test the real application—not merely the shield icon on the phone.

The phone’s VPN status says what is happening on the phone.

The laptop’s result says what is happening on the laptop.

The smaller service protected the device that mattered

The smaller service has fewer locations and a shorter public history than the largest VPN providers.

Neither limitation affected the tender.

The established provider worked correctly on the Android phone, but the hotspot did not pass that tunnel to the laptop. Its directly installed laptop route later lost the upload when the mobile connection shifted.

The smaller app used a verification code to bring the laptop onto its own protected route, completed the 680 MB submission and stayed connected when the laptop moved from the hotspot to office Wi-Fi.

I began the afternoon believing the VPN icon on my phone covered everything connected beneath it.

The tender arrived when I stopped trying to stretch one icon across two devices and protected the laptop where the work was actually happening.