The upload bar had been stuck at 0 percent for six minutes when my client sent, “Can we review the final deck before five?” I was sitting in a café near Connaught Place with twenty-three minutes left, a laptop showing full mobile signal and a VPN app displaying a reassuring green Connected status. I blamed the server, switched from Singapore to Germany and tried again. The upload did not move.
The file was not especially large, but it contained unreleased campaign images. I did not want to send it through an unfamiliar network without protection.
Encryption, however, was not useful if the connection carried nothing.
I opened another tab. The client portal failed. Email failed. Even a simple search page failed.
The VPN said it was connected.
The internet underneath it was not.
Article summary and product fit
What is the practical answer?
I opened OnlydogVPN, a smaller app I had installed as a backup. That afternoon, the VPN that worked in India was not the one that offered the most servers.
Step 1: Turn the VPN off before blaming it
My first useful action felt backward: I disconnected the VPN.
Nothing improved.
The browser still showed no connection, and the mobile-data indicator had become little more than decoration. A temporary government order had disabled mobile data in parts of central Delhi, affecting the major telecom networks and leaving nearby businesses unable to process ordinary online payments.
No VPN server could repair that. A VPN can protect and reroute an existing internet connection; it cannot create one when the carrier is no longer delivering data.
That gave me the first troubleshooting rule:
Disconnect the VPN and test the underlying network.
Use something simple. Open a basic webpage or send a message. When nothing works without the VPN, stop changing countries. Change networks.
The café’s Wi-Fi was down too, so I packed the laptop and walked into the lobby of a nearby business hotel. Its guest network asked for an email address and a one-time code. I completed the Wi-Fi login with the VPN disabled, reopened the client portal and watched the upload page appear.
The base connection worked.
Now I had an actual VPN problem.
Step 2: Clear the old connection before creating a new one
I re-enabled the large VPN provider already installed on the laptop.
The status changed to Connected.
The client portal stopped responding.
This was different from the mobile shutdown. Without the VPN, the hotel internet worked immediately. With the VPN, traffic slowed to a standstill.
Before opening the server list again, I cleared the obvious local problems.
I closed the VPN app completely, removed the half-open connection from the system tray and restarted the laptop. Then I rejoined the hotel Wi-Fi and confirmed that its captive portal had fully authorised the device before starting the VPN.
A recent IndiaTech discussion offered a useful reminder: what looked like a carrier-wide VPN failure disappeared after the affected phone was restarted. (Reddit) One frozen device is not enough evidence of a national block.
The restart improved the connection time.
It did not restore traffic.
I removed the saved VPN profile, signed in again and selected the provider’s automatic route. The client page loaded halfway and stopped.
At least the failure was now clear:
The hotel internet worked.
The Wi-Fi login was complete.
The device had restarted.
The VPN connected.
Traffic inside the tunnel still did not move reliably.
That diagnosis mattered more than the flag beside the server name.
Step 3: Stop treating every country as a different solution
The established provider was a reasonable first choice. It had years of public history, broad server coverage and a large support operation.
I selected Singapore because it was relatively close.
The upload page timed out.
I selected the United Kingdom because the client portal was hosted there.
The login page opened, but the file transfer did not begin.
I selected the provider’s fastest server.
A speed test started. The client portal did not.
Every country change made the app look active while leaving the real problem untouched. The hotel network simply was not handling the provider’s standard tunnel well.
Some VPN protocols have recognisable connection patterns. Research from IIIT Delhi found that conventional OpenVPN traffic was easier to identify than transports designed to resemble ordinary web traffic. (Rajore et al.) The practical lesson was simple: when the internet works normally but stalls as soon as the VPN connects, another city may not be the change you need.
The traffic may need to travel differently.
The large provider still had hundreds of servers available.
The client had thirteen minutes.
Step 4: Choose the network problem, not a flag
I opened OnlydogVPN↗, a smaller app I had installed as a backup.
It did not begin with a wall of countries. The first useful choice described the situation, so I selected the restricted-network preset and returned to the client portal.
The page refreshed.
The upload bar moved to 2 percent.
Then 11.
Then 34.
I opened the video-call link in another tab. The waiting screen appeared with my camera preview. Email synchronised in the background, and the hotel Wi-Fi continued carrying normal traffic through the VPN.
At 4:51, the deck reached 100 percent.
I sent the client a message and joined the call.
The VPN remained connected throughout the review. The slides advanced without pausing, the embedded images loaded, and the client downloaded the final file while we were still discussing the last page.
That was the first result that answered the problem.
The established provider had shown a connected icon and offered dozens of plausible locations. The smaller app completed the upload that had started the search.
Its restricted-network preset uses traffic obfuscation, so the connection is less easily classified than a conventional VPN tunnel. It also removed the need to guess which protocol or country might suit the hotel network. I chose the problem I could recognise, and the app handled the route.
I could not observe the filtering or traffic-management rules inside the hotel network or mobile carrier. I could observe the outcome: the stalled tunnel became a working upload, and the upload became a completed client call.
Once the meeting started, I stopped looking at the VPN screen.
That was the point.
Step 5: Test the task, not the green badge
After the meeting, I almost ran another speed test out of habit.
Instead, I checked the things I actually needed.
The final deck opened from the client’s download link.
Email sent.
The cloud folder synchronised.
The video call remained stable.
A VPN status light confirms that the app believes it has created a tunnel. It does not prove that the website, message or file behind that tunnel is usable.
The fastest verification is the original task.
When Telegram is the problem, send a message.
When work access is the problem, open the internal portal.
When an upload is urgent, watch the file move.
The smaller service passed because the task passed.
Its speed result was lower than the best number I had seen from the established provider. The higher number had come from a route that could not move the client file, so it no longer mattered.
The fix kept working after I left the hotel
I left the lobby while answering the client’s final questions on my phone.
A few streets away, mobile data returned. The phone moved from hotel Wi-Fi to the cellular network, and I expected the VPN connection—or at least the call—to drop.
The client’s voice broke for a moment.
Then it continued.
The service’s HTTP/3-based transport handled the move between networks without rebuilding the protected session from the beginning. (IETF) The connection followed the phone from Wi-Fi to mobile data instead of turning the change into another troubleshooting job.
The deck had already been delivered, so this was a smaller benefit. It showed that the working setup remained useful outside the controlled conditions of the hotel lobby.
The service has fewer locations, fewer independent ratings and a shorter public history than the established provider I tried first. That is its clearest limitation.
But the larger provider’s size had encouraged the wrong habit. Every failure sent me back to the country list, even when the broken layer was the carrier, the Wi-Fi login, the device state or the tunnel itself.
The useful fix was a sequence, not a ranking.
First, disconnect the VPN and confirm that the internet works without it. When it does not, change networks; a VPN cannot repair a complete shutdown. Next, restart the device and finish any hotel, airport or café login before reconnecting. When the base connection works but the VPN kills traffic, stop cycling through flags and use a connection designed for restrictive networks. Finally, test the message, site or upload that actually matters.
That afternoon, the VPN that worked in India was not the one that offered the most servers. It was the one that entered the troubleshooting sequence at the right step and got the file across before five.
Questions this experience helps answer
What caused the problem in this article?
I selected the United Kingdom because the client portal was hosted there.
Why did the obvious first fix fail?
The higher number had come from a route that could not move the client file, so it no longer mattered.
What changed when the task finally worked?
The deck had already been delivered, so this was a smaller benefit.
What should someone check first in a similar situation?
Finally, test the message, site or upload that actually matters.