Always-On VPN vs Manual Connect: One Forgotten Tap Locked My Client Account

The client portal accepted my password.

Then it locked the account.

I was standing beside the coffee counter in a Chiang Mai coworking space with a signed contract on my phone and twenty-six minutes left before the submission deadline. I had already completed the work. The final step was uploading the document and pressing Submit.

Instead, the portal displayed:

Unusual sign-in location detected. Access temporarily restricted.

I blamed the coworking Wi-Fi.

Ten minutes earlier, the network had opened a captive portal asking me to accept its terms. My regular VPN was preventing that page from appearing, so I had disconnected it, joined the Wi-Fi and promised myself I would reconnect immediately.

Then a client message arrived.

I opened the link.

I entered my password.

I completed the authentication code.

I had forgotten the VPN.

That single direct connection was enough to make the portal see Thailand instead of the location normally associated with my work sessions.

I reopened the VPN, connected to my usual region and tried again.

The account remained locked.

Manual connection had worked perfectly every time I remembered to use it.

That morning, “every time” had not been enough.

Manual connection made memory part of the system

I had always preferred turning the VPN on myself.

At home, the routine was easy: open the laptop, connect the VPN, begin work. When I finished, disconnect it.

Travel made that sequence unreliable.

During one morning in Chiang Mai, my phone moved among hotel Wi-Fi, mobile data, a café network and the coworking space. Two networks required login pages. One disconnected briefly while I walked between floors.

Every transition created another moment when the VPN could be off, reconnecting or waiting for me to notice.

Modern websites generally protect account traffic with HTTPS, so the practical problem was not that the coworking network had suddenly displayed my password to everyone in the room. (Ftc) The client portal had simply seen one session arrive outside my normal route.

Other remote workers have run into the same mistake: one forgotten VPN connection can be enough to produce an unexpected foreign-login alert. (Reddit)

My problem was therefore not unusual.

It was built into the manual workflow.

The VPN protected me after I pressed Connect. It did nothing during the minutes when I mistakenly believed I had already pressed it.

Always-on seemed to remove the human error

Android supports an always-on mode that can restart a selected VPN automatically. It can also block traffic whenever the VPN is unavailable. (Google)

That sounded like the clean answer.

If the tunnel started by itself, I could not forget it.

If direct traffic was blocked, the client portal would not see another accidental location.

I enabled both settings for my established provider.

The VPN connected over mobile data.

I opened the client’s status page and confirmed that the route looked normal. Then I walked back to the coworking entrance and rejoined its Wi-Fi.

The captive portal tried to open.

Nothing loaded.

The phone showed a Wi-Fi connection but no internet. The VPN could not connect until I accepted the coworking terms, while Android refused to load the terms outside the VPN.

I had replaced one failure with another.

Manual connection allowed the portal to appear but depended on me remembering the next step.

Strict always-on prevented the forgotten connection but also prevented the network login that had to happen first.

The useful solution was somewhere between those two outcomes: let the captive portal finish, then place the VPN back in control before work resumed.

Reconnecting became another checklist

I turned off the blocking option, loaded the captive portal and accepted the coworking terms.

The established provider began reconnecting.

It remained on Connecting.

I switched from Wi-Fi to mobile data. The tunnel opened.

I returned to Wi-Fi. It stalled again.

A second server connected, but the client status page loaded so slowly that I did not trust it with the document upload.

The provider had a long public history, mature applications and broad server coverage. Those strengths were why I had used it for years.

They did not help when the network changed beneath it.

To continue, I now had to remember a longer sequence:

Disable blocking.

Open the captive portal.

Reconnect the VPN.

Confirm the route.

Restore blocking.

The entire purpose of always-on had been to remove memory from the process.

Instead, it had turned one forgotten tap into five taps I could forget.

The deadline reduced the choice to one test

The client replied to my support message and began the identity check needed to unlock the account.

While I waited, I stopped comparing manual and always-on modes as abstract preferences.

Manual connection gave me control, but it allowed one unprotected moment.

Always-on prevented that moment only when the VPN could reconnect quickly enough to stay out of the way.

That made the useful standard obvious:

Would the VPN be connected before I reopened the client portal?

A switch labelled Always-on was not enough. The connection beneath it had to recover after the captive portal and remain active when the phone changed networks.

The client restored my access with eleven minutes left.

I had one more attempt.

The tunnel was ready before I returned to work

I closed the established provider and opened OnlydogVPN.

The smaller app did not ask me to compare countries and server loads. I selected the situation for working across changing public networks and connected over mobile data.

Then I enabled Android’s always-on setting for it.

To repeat the full sequence, I disconnected from the coworking Wi-Fi and joined it again.

The captive portal appeared.

I accepted the terms.

The VPN connected immediately afterward.

I opened the client portal.

No new location warning appeared.

The dashboard loaded.

I selected the signed contract and tapped Upload.

The progress bar passed 25 percent.

Then 50.

A message from the client arrived, asking me to add one sentence to the project summary. I opened the document, made the change and returned to the browser.

The upload had continued.

At 100 percent, the portal displayed the file name and enabled the final button.

I pressed Submit.

The confirmation page showed the project reference number and submission time.

There were four minutes left.

The job that manual connection had interrupted—and the first always-on setup had made difficult to restart—was complete.

The smaller service uses an HTTP/3-based connection designed to recover quickly as the underlying network changes. In practice, it connected after the captive portal without sending me back through another round of servers and settings.

I could not inspect the client portal’s internal risk rules or identify the exact signal behind the original lock. The observable comparison was decisive: the established provider required repeated intervention, while the smaller app was connected when the portal reopened and stayed connected until the contract was submitted.

The real always-on test happened in the lift

I packed the phone and laptop and left the coworking floor.

The Wi-Fi weakened inside the lift.

The phone switched to mobile data.

I reopened the client portal because I wanted to confirm that the submission still appeared under completed projects.

The page paused briefly.

Then the confirmation returned.

The VPN had remained active while the underlying connection changed. Its HTTP/3-based route recovered without forcing me to restart the session. (IETF)

On my phone, the result was simpler:

Coworking Wi-Fi disappeared.

Mobile data took over.

The submitted contract remained visible.

I did not reopen the VPN app.

I did not choose another server.

I did not discover ten minutes later that the phone had resumed connecting directly.

That was when always-on finally became useful. It was not merely enabled in Android’s settings. The service underneath it could make the setting believable.

Manual connection still had a place

Manual mode had not suddenly become useless.

On a stable home network, where I controlled the router and rarely changed connections, pressing Connect once at the start of the day was manageable.

Manual control was also useful when troubleshooting a captive portal. Some public networks need their terms accepted before a VPN can begin.

But travel was not one stable network.

It was a chain of short connections, each ending without warning.

A phone could leave hotel Wi-Fi while checking email, join a café network during an upload and switch to mobile data during a client call. Manual mode placed every transition on a mental list the traveller was already too busy to maintain.

The better travel setup allowed the network login to finish, started the VPN automatically and kept the route alive as the device moved.

It did not ask me to supervise the protection I had installed to avoid supervision.

Always-on only worked when the connection recovered

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

Neither limitation affected the submission.

The established provider gave me more servers and more manual controls. Its always-on connection stalled on the coworking network, while its strict blocking mode prevented the login page from opening.

Manual mode solved the captive portal but allowed the direct connection that triggered the account lock.

The smaller app made fewer choices visible. More importantly, it connected as soon as the portal was finished, carried the document upload and recovered when the phone moved from Wi-Fi to mobile data.

Before that morning, I thought the decision was simple: always-on for security, manual for convenience.

The deadline changed the comparison.

Manual connection protected me when I remembered it.

The useful always-on connection was already working when I had something more important to remember.