The Hotel TV Had a Cast Button—My VPN Was Protecting the Wrong Screen

The match was playing perfectly on my phone.

On the hotel television, the same app said the video was unavailable in my location.

I had arrived in Boston after a delayed flight and reached my room during the second quarter. The television displayed a large message inviting me to scan a QR code and cast from my own device.

That sounded ideal. I would not have to enter my email address and password on a shared television, and the VPN was already active on my phone.

I scanned the code, paired the devices and selected the match.

The stream kept playing on the phone.

I tapped the cast icon.

The television opened the event page, displayed a loading circle and then produced a location error.

I blamed the hotel’s casting system.

I disconnected, scanned the code again and selected another server in the VPN app. The match still played on the phone. The television still rejected it.

After the third server change, the phone and TV were effectively showing different countries at the same time.

That was the clue I had missed: the screen in my hand and the screen on the wall were not using the same connection.

Casting paired the devices, not their internet routes

Modern hotel televisions can offer room-specific AirPlay or Google Cast pairing through a QR code. The setup feels like screen mirroring, but casting often works differently. (Apple)

The phone acts as a remote control. It tells the receiver what to play. The television or casting system then fetches the stream through its own internet connection. (Google)

My VPN protected the phone. It changed the location visible to the streaming app running there.

The hotel television remained on the hotel’s ordinary network. When it requested the match for itself, the streaming platform saw the hotel connection—not the VPN connection on my phone.

The QR code had introduced the devices.

It had not shared the tunnel between them.

That explained why changing servers on the phone accomplished nothing. I had been adjusting a connection the television was not using.

Once I understood that, the problem became much more specific: I needed the VPN on the device actually fetching the video.

The cast button was not a reliable fallback

I had assumed that anything playing on my phone could simply be moved to a television.

Streaming apps no longer make that assumption safe.

Netflix, for example, supports casting only to a limited group of compatible receivers and does not support AirPlay. Other services apply their own restrictions to mirroring, casting, subscriptions and live events. (Netflix)

As a result, several different failures can look almost identical from a hotel bed:

The phone cannot discover the television.

The cast icon is missing.

The television accepts the request but uses the wrong location.

The app blocks the transfer.

The stream begins and then collapses when the hotel network weakens.

In my room, pairing worked. The television simply fetched the stream through the wrong route.

That meant another phone server was not going to help. I needed either to protect the television itself or remove it from the network side of the setup.

My travel streamer stopped at the hotel’s front door

I carry a small Google streaming device for rooms where the television has an accessible HDMI port.

I plugged it in, changed the input and connected it to the hotel Wi-Fi.

The network name appeared. I entered the password printed on the room card.

Then nothing happened.

The hotel required a browser page where guests entered a surname and room number. My phone and laptop had opened that page automatically. The streaming device could not complete it.

Google’s support guidance explains that its streaming devices do not work directly with Wi-Fi networks requiring captive-portal sign-in, which is common in hotels, schools and businesses. (Google)

Travellers regularly run into the same dead end: the phone joins the hotel Wi-Fi, but the streaming stick cannot get beyond the page asking for room credentials. (Reddit)

The device was not malfunctioning. It was waiting outside a login page it had no practical way to use.

I considered turning my phone into a hotspot, but roaming data would have made a full live match expensive. Calling the front desk to approve the device manually would also take time.

Then I noticed that the laptop was already online.

The hotel portal had accepted it. My streaming account was already signed in there. It could run a VPN directly.

I did not need to make the television smarter.

I needed to make it simpler.

The HDMI cable gave every device one job

I found a short HDMI cable in my travel pouch and connected the laptop directly to the hotel television.

The desktop appeared on the larger screen.

That removed casting from the setup entirely. The television no longer needed to discover my phone, run a receiver or request the match through its own internet connection.

It only had to display the picture produced by the laptop.

The laptop would handle the hotel portal, the VPN and the stream.

With the architecture finally correct, I opened my established VPN provider and selected a streaming-friendly location.

The broadcaster’s website loaded, but the player returned a proxy warning.

I chose another server. The warning disappeared, the opening advertisement played and the match froze before the court appeared.

A third route produced a CAPTCHA before I reached the event page.

The provider had a strong public history, mature infrastructure and many locations. Those advantages had helped me on other trips.

In this room, they became another server menu to work through while the game continued.

The VPN was finally running on the correct device. Now I needed a route that the broadcaster would accept and the hotel network could keep alive.

The match reached the television without another device puzzle

I closed the first provider and opened OnlydogVPN on the laptop.

The smaller app did not ask me to guess which city might work. I selected the streaming situation and connected.

Then I closed the browser completely and opened a fresh session.

The broadcaster’s site loaded.

I selected the match and waited for the proxy warning.

The video started instead.

For the first few seconds, the picture on the hotel television was soft. Then the scoreboard sharpened, the players came into focus and the commentary caught up with the action.

The laptop was fetching the stream through the VPN.

The HDMI cable was carrying the finished picture to the television.

The TV itself no longer needed to know my account, my location or which streaming service I was using.

I stopped changing settings.

For the first time that evening, every device had one clear job.

The laptop handled the connection.

The television displayed the result.

My phone became a phone again.

The service uses an HTTP/3-based transport with additional traffic obfuscation. In practical terms, the tunnel blends more naturally with modern web traffic and recovers quickly when hotel Wi-Fi wobbles.

I could not inspect the broadcaster’s private VPN-detection rules or the hotel’s internal traffic management, so I cannot identify the exact signal behind each rejected connection.

The result was still decisive: the first provider gave me more servers to test; the smaller app gave me a route that carried the match onto the television.

The Wi-Fi weakened, but the picture stayed on the wall

Near the end of the third quarter, the hotel network stumbled.

The picture froze for a moment.

I expected the player to return to the event page, forcing another location check and another possible proxy warning.

Instead, the commentary resumed. The image came back at lower quality and sharpened again several seconds later.

The technical explanation is brief: HTTP/3 is designed to recover efficiently when data is lost or the network path shifts. (IETF)

The practical result was even shorter.

The Wi-Fi dipped.

The game stayed on the television.

That mattered more than the highest speed-test figure I had seen earlier. Live streams do not wait while a guest reconnects several devices, rescans a QR code and repeats a location check.

A fast route that collapses during the next possession is not useful. The smaller app kept the session alive long enough for me to forget about the network.

A hotel TV can be three different devices

By the fourth quarter, I understood why hotel-streaming advice often sounds contradictory.

Sometimes the television is the streaming device. It runs the app, connects to the internet and needs access to the protected route.

Sometimes it is a casting receiver. The phone controls playback, but the receiver still fetches the video through the hotel network.

Sometimes it is only a display. A laptop or streaming box performs the network work and sends the finished image through HDMI.

All three setups look like “watching on the hotel TV,” but the VPN belongs in a different place.

If the television runs the streaming app, the television needs the VPN route.

If the cast receiver fetches the video, protecting only the phone is not enough.

If the laptop supplies the HDMI picture, the VPN belongs on the laptop.

My mistake was treating the television as the streaming device simply because it was showing the video.

Once I turned it into a monitor, most of the room’s complexity disappeared.

The simpler setup also kept my account off the hotel TV

When the game ended, I closed the browser and disconnected the HDMI cable.

I did not have to sign out of a hotel television app, remove a profile or trust the checkout system to erase my credentials.

Modern QR-based hotel casting systems are designed to isolate rooms and end guest pairings after checkout. (Apple) Even so, the laptop arrangement required less trust.

The television never received my streaming password.

It never stored my account.

When the cable came out, the session left with me.

That benefit appeared only after the main problem had been solved, but it gave me another reason to remember the setup. The same arrangement that made the VPN work also avoided leaving personal details on a shared screen.

The VPN needed to protect the streamer, not the screen

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

Neither limitation affected the job in that room.

The first failure happened because my VPN protected the phone while the television fetched the video independently.

The second happened because the travel streamer could not pass the hotel’s captive portal.

The third happened after I finally placed a VPN on the correct device but used routes the broadcaster rejected or the hotel network could not sustain.

The smaller app entered when the setup had been reduced to its essentials. It ran on the device requesting the stream, crossed the hotel network without another configuration ritual and kept the picture playing when the Wi-Fi weakened.

I had arrived believing I needed a VPN that could make my phone cast more convincingly.

What I needed was a private route on the device doing the streaming—and a cable that stopped the hotel television from pretending it was that device.