TASK GUIDE

What to Check on Hotel Wi-Fi

Hotel Wi-Fi is convenient, but it is a network you do not control. Use this checklist before opening email, banking, work systems or other sensitive services. The goal is to confirm that you joined the intended network, understand what your browser can observe and recognise warning signs. No browser test can certify that a hotel connection is completely secure.

Published by the Terbit Editorial Team · Reviewed 19 October 2026

Quick checklist

  • Confirm the exact network name and sign-in method with hotel staff.
  • Disable automatic connection to open networks.
  • Complete the captive portal without bypassing certificate warnings.
  • Check your public IP, provider and IPv4/IPv6 connectivity.
  • If you use a trusted VPN, compare results before and after connecting.
  • Use HTTPS and multi-factor authentication for important accounts.
  • Forget the network when you leave.

1. Confirm the real hotel network

A misleading network can use a name that resembles the hotel’s official Wi-Fi. Ask reception for the exact spelling, whether a password is required and what the sign-in screen should look like. Do not assume the strongest signal is genuine. If two similar names appear, stop and confirm before entering a room number, surname or account credential.

Turn off automatic joining for open networks. Remove saved networks from earlier hotels if you no longer need them. These steps reduce the chance that your device reconnects to an unrelated network using a familiar name. They do not protect against every network attack, but they remove an avoidable source of confusion.

2. Prepare your device before travelling

Install operating-system, browser and security updates before the trip when practical. Use a screen lock and enable multi-factor authentication on important accounts. Keep a mobile-data option available for urgent work. A personal hotspot or mobile connection is not automatically risk-free, but it gives you an alternative when the hotel network behaves unexpectedly.

Avoid making major security changes while already connected to an uncertain network. Download VPN software and confirm your work-access instructions in advance. Use software from the vendor or your employer rather than a download promoted by an unexpected portal.

3. Complete the captive portal carefully

Many hotels redirect the first browser request to a captive portal for room verification, an access code or acceptance of terms. If the portal does not appear, open an ordinary non-sensitive webpage, disconnect and reconnect, or ask the hotel for assistance. Some devices also provide a “login to network” notification.

Do not bypass a browser certificate or privacy warning. Do not install an unfamiliar certificate, configuration profile, browser extension or device-management application merely to obtain access. A legitimate hotel may use a third-party portal, but unusual installation requests deserve verification with staff. Read permission prompts instead of accepting them automatically.

4. Establish a baseline with Terbit IP

Open Terbit IP before changing connection settings. Note the displayed network provider, country and approximate location. IP geolocation is an estimate; a different city may represent the internet provider’s routing centre rather than the hotel. Do not post or share the complete public IP address unless there is a clear support reason.

Next, run the IPv4/IPv6 connectivity test. It checks whether the browser can reach separate endpoints. A failed IPv6 or IPv4 result may reflect network design, filtering, temporary failure or browser conditions. It is not proof that the connection is safe or unsafe.

Run the WebRTC test and compare its browser-visible candidates with the public result. Private addresses and mDNS names can be expected browser behaviour and should not automatically be labelled leaks. An unsuccessful test is also inconclusive; it does not prove that nothing is exposed.

5. Check normal browsing behaviour

Open several familiar HTTPS websites. The browser should not present certificate warnings, repeated unexpected redirects or requests to re-enter unrelated account credentials. HTTPS helps protect content between the browser and the website, but it does not make every site trustworthy and does not hide the destination domain from every part of the network.

If email, banking or work systems behave differently from normal, stop. Use mobile data or contact the relevant support team through a trusted channel. Do not use a warning-free page as the sole evidence that the entire network is secure.

6. Compare a VPN before and after connection

If your employer or personal policy requires a VPN, record the baseline result first. Connect a trusted VPN, reload Terbit IP in the same browser and compare the public IP, provider and approximate location. A changed result is useful evidence that the tested browser traffic is taking a different route.

This comparison is not automatic VPN detection and is not a guarantee. Split tunnelling may send only selected traffic through the VPN. Other applications, DNS requests or existing sessions may behave differently. A VPN also does not replace software updates, HTTPS, strong passwords or multi-factor authentication. Follow your employer’s instructions for corporate systems.

Worked example: a normal comparison

You confirm “Hotel-Guest” with reception, join it and complete the room portal. Terbit IP shows the hotel’s internet provider and an approximate city that is 30 kilometres away. That city difference alone is not suspicious because IP location is approximate. The IPv4 test succeeds while IPv6 is unavailable.

You then connect your trusted VPN. The public IP and provider change, the approximate location becomes the VPN region, and the same HTTPS sites continue working. This is consistent with the tested browser traffic using the VPN. It does not prove that the hotel network, every application or the device is free from risk.

Worked example: when to stop

A network named “Hotel_Free_5G” appears, but reception provides a different name. The first network opens a portal asking you to install a profile and shows a certificate warning. Do not continue. Forget that network, tell the hotel and use the confirmed service or mobile data. Do not investigate by entering false credentials or downloading the requested file.

Troubleshooting common problems

The portal will not open

Disconnect and reconnect, temporarily disable the VPN, open a normal webpage, or use the device’s network-login notification. Confirm that date and time are correct. If the portal still fails, ask the hotel to reset or authorise the device. Re-enable the VPN only after access is established and compare results again.

The internet works, but one test fails

Retry once, then test another ordinary site. Network filtering or a temporary endpoint problem can cause an inconclusive result. Do not interpret failure as proof of protection. Record the time and the minimum details necessary if you need technical support.

The VPN connects, but the IP does not change

Reload the page, verify that the VPN reports an active connection and check whether split tunnelling excludes the browser. Disconnect and reconnect once. If the result remains unchanged, follow the VPN provider’s troubleshooting guidance or avoid sensitive activity until the routing is understood.

The connection keeps dropping

Move closer to the access point, forget and rejoin the network, or ask whether the hotel limits devices per room. Repeated drops during sensitive work increase the chance of interrupted sessions; use a more reliable connection rather than repeatedly submitting forms.

When to stop and seek help

  • The network name cannot be confirmed by hotel staff.
  • The browser displays a certificate, privacy or deceptive-site warning.
  • The portal requests unusual software, device-management access or credentials unrelated to the stay.
  • The connection repeatedly redirects, drops or behaves differently from the hotel’s instructions.
  • Your important account reports an unexpected login or security change.

After leaving the hotel

Forget the hotel network and disable automatic reconnection. Sign out of services used on a shared device and review important account notifications. If you ignored a warning, installed an unexpected profile or entered credentials into a doubtful portal, change the affected password from a trusted connection, review active sessions and contact the relevant provider.

What this checklist cannot prove

These checks observe browser-visible network behaviour at one moment. They do not inspect hotel routers, audit encryption for every application, detect all malicious activity, confirm the identity of every portal or guarantee account safety. Results can change when the device, browser, network, VPN server or time changes. Treat an inconclusive result as a reason to investigate, not as evidence of safety.

Primary references