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

VPN Connected but Only Some Apps Work: The Green Badge Hid What Was Outside the Tunnel

The contract opened in my browser, but the cloud-drive attachment stayed at zero. Signal showed new messages yet dropped every call before it rang. Telegram text worked, while the client’s voice note remained behind a spinner. I blamed the hotel Wi-Fi, changed VPN servers, and watched the app display the same reassuring word each time: Connected. Nothing I actually needed became more reliable.

I was in Moscow, preparing documents for a supplier whose accounting team would close in thirty-five minutes. I needed to download a revised contract, join a brief Signal call to confirm one clause, sign the document, and upload it to a foreign client portal.

The browser could reach the portal through the VPN. That made the failures elsewhere feel random.

They were not. My phone was sending different apps through different routes.

Russia’s expanding internet restrictions had already made app behavior uneven. Mobile disruptions and platform blocking increasingly left residents with one service working normally, another loading only text, and a third failing altogether.

Over time, I had responded by changing the VPN’s per-app settings. Banking and taxi apps were excluded because they behaved better on the direct connection. A local delivery app was excluded after rejecting a shared VPN address. During an earlier trip, I had also created an allowed-app list.

Those decisions made sense individually. Together, they had left me with a VPN configuration I no longer understood.

The icon was visible, but the apps needed for the contract were not all inside the tunnel.

The short answer

The browser worked because it was inside the VPN. Some local apps worked because I had deliberately left them outside. Signal and the cloud drive were still using the restricted mobile network I had been trying to avoid.

“Connected” described the tunnel, not the whole phone

The established provider had a large server network, years of public history, and enough Android controls to handle almost any routing preference.

That flexibility was why I had chosen it.

It was also why the failure was difficult to see.

I opened the split-tunneling settings. The list contained apps I remembered excluding and several I did not. The browser was protected. Signal appeared to be outside the tunnel. The cloud-drive app sat somewhere in the middle of an old configuration I had built over several trips.

Android lets a VPN protect only selected apps or exclude selected apps from the tunnel. That feature is useful when a bank, taxi app, printer, or local service needs the ordinary connection.

It also explained the pattern on my screen.

The browser worked because it was inside the VPN. Some local apps worked because I had deliberately left them outside. Signal and the cloud drive were still using the restricted mobile network I had been trying to avoid.

The status badge was not wrong. A VPN connection existed.

It simply was not carrying the whole job.

I added Signal to the protected list and reconnected.

Messages refreshed, but the call still failed.

I added the cloud-drive app. Its folders appeared, yet the contract upload stopped after a few megabytes.

The more apps I moved, the less certain I became about what the phone was doing. Recent Android versions can also expose VPN app exclusions at the system level, creating another place where traffic may be sent outside the tunnel.

The controls were understandable one by one. Under a deadline, they had become a routing puzzle.

Fixing one app exposed another exception

I cleared the old exclusions and restarted the VPN.

The cloud-drive upload began.

Signal rang this time, but the audio disappeared as soon as the call connected. Meanwhile, the local taxi app stopped loading pickup locations, and my banking app displayed a security warning.

That was why the exceptions had accumulated in the first place.

Protecting everything disrupted local services that disliked the VPN. Excluding selected apps risked leaving an important work tool on the restricted connection. The provider gave me the controls, but it still expected me to build the right combination while the supplier waited.

A public Signal troubleshooting thread captured the same practical problem: one routing choice restored the app while another broke the call. The lesson was not that Signal should always be inside or outside a VPN. It was that app-level routing could fail selectively while the rest of the phone appeared normal.

That matched what I was seeing. “Some apps work” did not prove that the VPN was healthy. It proved only that one route worked for one part of the device.

I tried another server.

The browser became slower. The upload returned to zero. Signal messages arrived, but the call still had no usable audio.

Changing countries did nothing because the real problem was already on the phone. My apps were not travelling together.

The supplier had twenty-one minutes left.

At that point, I stopped looking for the correct server. I needed one connection that could carry the entire sequence: call, download, browser session, signature, and upload.


The next attempt carried the task, not one selected app

I disconnected the larger provider and opened OnlydogVPN.

Instead of rebuilding an app list, I selected the preset for a restrictive network and returned to Signal.

The call rang.

My supplier answered, and the audio remained clear while we confirmed the revised payment clause. I opened the contract from the chat and saved it to the phone.

Then I switched to the cloud-drive app.

The revised document downloaded completely.

I signed it, opened the client portal in the browser, and started the upload.

The progress bar moved past the point where it had previously stalled.

Twenty-eight percent.

Fifty-six.

One hundred.

The portal displayed the signed contract and generated a confirmation number. I sent it to the supplier with nine minutes remaining.

Only after the task was complete did the design difference need explaining.

The smaller app’s situation-based preset kept the work apps on one protected route instead of asking me to reconstruct several old exclusions. Its HTTP/3-based transport and obfuscation handled the restrictive connection without turning every application into a separate configuration decision.

I could not observe every filtering rule inside the mobile network or every internal routing decision made by the two VPN applications. I could see the result: the earlier setup protected the browser while Signal and the cloud workflow failed in different ways; the smaller app carried the call, download, browser session, and upload together.

The green badge had never been the correct test.

The completed contract was.

Some apps should bypass a VPN—but not by accident

The experience did not make split tunneling useless.

There are good reasons to exclude an app. A bank may challenge a shared VPN address. A local delivery service may need the user’s real region. A printer or smart-home app may require direct access to the local network.

The problem is that every exception becomes another route to remember.

Months later, the VPN may show “Connected” while an excluded messaging app or newly installed cloud service continues using the ordinary network. On a restricted connection, that appears as an app bug: one service works, another times out, and a third loads text but not calls or attachments.

The established provider offered enough controls to repair the configuration. Given time, I could clear the lists, test every app, and rebuild the exceptions carefully.

Time was exactly what I did not have.

The smaller service replaced that troubleshooting session with a preset tied to the situation in front of me. Its main advantage was not a longer feature list. It was removing unnecessary routing decisions between the failure and the finished task.

A smaller benefit appeared when I left the hotel lobby. The phone moved from Wi-Fi to mobile data while the supplier sent one final document. The connection recovered, and the attachment continued downloading without another server choice.

That gave me a reason to keep the app installed after the deadline. My work rarely stays inside one browser or on one network. It moves between chat, calls, document storage, verification screens, and changing connections.

The service has fewer locations, fewer independent reviews, and a shorter public history than the established provider. Someone who needs detailed per-app rules may prefer the larger control panel.

My problem was the opposite. I already had more rules than I could see.

The established VPN proved that one app could reach the internet through a tunnel. The smaller app proved that the entire job could reach its destination.

Questions this experience may leave you with

What was actually causing the problem?

The browser worked because it was inside the VPN. Some local apps worked because I had deliberately left them outside. Signal and the cloud drive were still using the restricted mobile network I had been trying to avoid.

Why did the obvious fixes fail?

The more apps I moved, the less certain I became about what the phone was doing. Recent Android versions can also expose VPN app exclusions at the system level, creating another place where traffic may be sent outside the tunnel.

What should you check first?

That matched what I was seeing. “Some apps work” did not prove that the VPN was healthy. It proved only that one route worked for one part of the device.

What finally changed the result?

Months later, the VPN may show “Connected” while an excluded messaging app or newly installed cloud service continues using the ordinary network. On a restricted connection, that appears as an app bug: one service works, another times out, and a third loads text but not calls or attachments.

What is worth remembering?

The established VPN proved that one app could reach the internet through a tunnel. The smaller app proved that the entire job could reach its destination.