VPN vs Shadowsocks: The Proxy Opened Google—The Smaller VPN Kept the Meeting Alive

The client’s face appeared for three seconds.

Then the meeting window turned white.

I was in a Shanghai hotel room with nineteen minutes left before a contract review involving six people in four time zones. The updated proposal was in Google Drive. The comments were in Gmail. The client expected me to share the final pricing sheet during the call.

My established VPN showed Connected.

Google Meet disagreed.

I switched from the automatic server to Japan.

The meeting page reached the camera preview and stopped.

Singapore opened Gmail but not Drive.

A US route remained on Connecting until the meeting reminder appeared again.

I blamed the hotel Wi-Fi.

Without the VPN, local websites loaded immediately. The services I needed for work did not.

A colleague had sent me a Shadowsocks subscription before the trip. I had installed the client but left it untouched because the ordinary VPN felt simpler.

Now the ordinary option was failing, and the calendar showed sixteen minutes.

I imported the subscription link.

Thirty-two proxy nodes appeared.

Shadowsocks offered a different route—and another decision

I had treated Shadowsocks as a technical backup for people who enjoyed configuring servers.

That was only partly true.

Shadowsocks is a split-proxy system. A client encrypts selected traffic and sends it to a remote server, which forwards it to the destination. The client, server and configuration are separate parts rather than one managed commercial service. (Shadowsocks)

That difference made it a reasonable response to the hotel network.

My established provider had offered many conventional VPN routes. None had opened the full meeting workflow reliably.

Shadowsocks approached the restriction differently.

The practical catch was already visible on my screen: the protocol had given me thirty-two nodes, but it had not told me which one would carry a forty-five-minute client call.

The first node looked like the answer

I selected a Singapore node with a low latency number beside it.

Gmail opened.

Google Drive followed.

The pricing spreadsheet loaded before I finished checking the clock.

I joined the meeting.

The client appeared.

The audio was clear.

For several minutes, Shadowsocks looked decisively better than the established VPN. It had restored the services I needed without forcing me through another list of familiar VPN countries.

I began presenting.

The client asked to see the revised payment schedule.

I clicked Share screen.

The preview appeared, froze and disappeared.

The call continued for another ten seconds.

Then everyone’s video stopped at once.

The Shadowsocks client showed the Singapore node as unavailable.

I switched to Tokyo.

Google Meet returned, but I had to rejoin the call and request screen-sharing permission again.

The client waited while I reopened the spreadsheet.

Tokyo lasted four minutes.

Then the audio began arriving in fragments.

Shadowsocks had reached the services.

The node had not stayed available long enough to complete the meeting.

A subscription link hid the real dependency

I had thought I was comparing a VPN with Shadowsocks.

In practice, I was also depending on the subscription operator supplying the nodes.

The client was only the interface. The remote servers belonged to the subscription service, and their capacity and maintenance determined whether the connection stayed usable.

Research into China’s subscription-based circumvention ecosystem has found that these services can perform well while also suffering from takedowns, configuration difficulties and operational instability. (Arxiv)

That was exactly what my meeting had become.

When the Singapore node worked, it was fast.

When it disappeared, the client could only offer another node.

I selected Hong Kong.

The meeting opened, but the client’s document portal displayed an access error.

I selected Osaka.

The portal worked, while Meet returned to the loading screen.

The node list was useful for experimentation.

The client call was not an experiment.

Every switch interrupted the conversation, changed the route and forced another reconnection.

Shadowsocks had reached services the established VPN could not.

It had not removed the need to manage the network during the meeting.

A strong protocol could not repair an unstable node

Shadowsocks was built for networks that classify or block ordinary connections. Its encrypted proxy design made it less recognisable than many conventional VPN patterns. (Shadowsocks)

That advantage was real.

It was also only part of the result.

The meeting still depended on the remote node remaining fast, reachable and properly routed. A well-designed protocol could not make an overloaded or removed server stay online.

Travellers describe the practical frustration simply: one node works, then the user has to switch again when it slows or disappears. (Reddit)

I was already doing exactly that.

Singapore.

Tokyo.

Hong Kong.

Osaka.

Each one solved a different slice of the workflow.

None carried the client from the opening slide to the decision.

By then, the question had changed.

I no longer needed the connection that opened first.

I needed the one that would still be working when the client reached the contract terms.

The client stopped waiting for my network

I apologised and asked for five minutes.

The meeting had already consumed twelve minutes without reaching the pricing decision.

Returning to the established VPN made little sense. Its earlier routes had not opened the full set of services.

Continuing through the Shadowsocks list meant asking the client to wait while I tested someone else’s infrastructure.

I closed the proxy client and opened OnlydogVPN.

The smaller app did not present a subscription link, cipher field or page of regional nodes. I selected the situation for a video meeting on a restrictive hotel network and connected.

Then I reopened the applications in the order I needed them.

Gmail refreshed.

Drive loaded the proposal.

The document portal opened.

Google Meet reached the camera preview.

I rejoined the call.

The client’s face appeared and stayed there.

I shared the pricing sheet.

The numbers became readable on everyone’s screen.

The client asked about the implementation schedule. I opened a second document while the screen share continued.

No route change was required.

No one waited for me to reconnect.

We reached the final slide, reviewed the revised payment terms and agreed on the next step.

The client said:

“Send the clean copy and we can move this to legal.”

I uploaded the final proposal to the portal.

The status changed to:

Document received.

The task that had started the comparison was complete.

Only then did the connection design matter. The smaller service uses an HTTP/3-based transport with added traffic obfuscation, giving the whole workflow one managed route instead of a list of proxy nodes to supervise.

I could not inspect the hotel network’s internal filtering rules or determine the precise reason each earlier route failed. The visible result was decisive: the established VPN never opened the complete workflow, Shadowsocks opened it temporarily, and the smaller app carried the meeting through the client’s decision.

My phone joined without another proxy setup

The client’s legal team sent an approval request while I was packing the laptop.

The signature link opened on my phone.

My Shadowsocks subscription was not configured there. Using it would have meant installing a compatible client, importing the subscription and choosing another node.

The smaller service offered a shorter handoff.

I displayed a verification code on the laptop and entered it on the phone.

The phone connected without another email-and-password login.

I opened the approval page, checked the document name and confirmed that the clean proposal matched the version discussed on the call.

The approval went through.

That did not repeat the main success. The meeting had already finished.

It removed the next, smaller friction: moving the workflow from the laptop to the phone without rebuilding the connection from a subscription link.

I had already spent enough of the morning acting as my own network administrator.

The connection survived the lift

I left the room and walked toward the lift.

The phone stayed on hotel Wi-Fi through the smaller service.

As the lift descended, the Wi-Fi disappeared.

Mobile data took over.

The legal portal paused briefly, then refreshed.

The VPN remained active.

Its HTTP/3-based route recovered as the phone changed networks. (IETF)

The result on the screen was simpler:

Hotel Wi-Fi vanished.

Mobile data appeared.

The approved document remained open.

I sent the client a final confirmation before reaching the lobby.

The message delivered.

That continuity mattered because travel networks rarely fail at a convenient moment. They disappear inside lifts, trains, taxis and hotel corridors—usually while the user is doing something more important than watching a connection indicator.

The smaller app had already completed the meeting.

Now it stayed useful after I left the room.

Shadowsocks still rewarded people who wanted control

The experience did not make Shadowsocks a poor tool.

Its strengths had been obvious.

The first working node opened Google services faster than the established VPN.

Its proxy design suited a restrictive network.

A knowledgeable user could operate a private server, control the endpoint and replace it when necessary.

For someone living behind long-term filtering, that control may be worth the effort.

But control creates work.

The user must obtain or maintain a server, select a client, import the configuration and replace the route when it stops working.

A subscription operator removes some of that setup, but then the quality of the experience depends on the operator’s nodes.

For a technically inclined resident, that can be an acceptable trade.

For a traveller staring at a meeting reminder, the more useful service was the one that managed the route instead of handing the route management back to me.

Connecting first was the wrong benchmark

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

Neither limitation affected the contract review.

The established provider offered brand recognition and many servers, but its tested routes could not open the full set of work applications.

Shadowsocks reached those services and showed why it remains valuable on restrictive networks. Its subscription nodes also turned the meeting into a cycle of testing, switching and reconnecting.

The smaller app asked for fewer decisions. It opened the meeting, held the screen share, delivered the proposal and followed the approval page from hotel Wi-Fi onto mobile data.

I began the morning asking whether a VPN or Shadowsocks was technically better.

The contract moved forward when I used the criterion the client could actually see: not which connection opened first, but which one was still there when they said yes.