Portal Loads on One Phone Not Another on Piso WiFi: How to Compare Two Devices Properly

Up: Troubleshooting | Portal Not Loading | Portal Not Secure

This post covers only the one device works, one device does not case. If the portal will not load on any device, go to the Portal Not Loading guide. If the portal loads but browsing stops after payment, go to the No Internet After Paying guide. If the portal shows a Not Secure warning, go to the Portal Shows Not Secure guide.

Symptom Check: Compare Like With Like

Before you change anything, note these points for both devices. A comparison is only useful if the test is the same on both.

Test point	Working device	Failing device
Exact WiFi name joined
Mobile data on or off
VPN on or off
Browser used, and incognito or normal window
Address typed, in the address bar or search box
Portal result: opens, loops, warning, or search page
Private DNS, private relay, or private address setting

If the working device used an incognito window and the failing device used a normal window with saved cache, that alone can explain the difference. Repeat the test with the same browser mode on both devices before you conclude the failing phone is broken.

Likely Causes, in Order

Cause 1: Different browser state, cache, or extension

A normal browser window can carry a stale portal page, a saved redirect, or an extension that blocks the portal. An incognito window starts clean. If the portal opens in incognito on the failing phone, the cause is browser state, not the machine and not the phone hardware.

Cause 2: Mobile data, VPN, or private relay still on

A phone on mobile data can skip the WiFi portal completely. A VPN, including one that starts automatically, can route traffic away from the local portal. Private relay on iPhone can have a similar effect. If these are on for the failing phone and off for the working phone, the portal test is not a fair comparison.

Cause 3: Private DNS or private address difference

Private DNS on Android, set to a custom hostname, can block a local portal. A private WiFi address that changed between connections can make the machine treat the same phone as a new device, which matters more for an existing session than for first portal load, but it can also confuse a session that is already active. Compare these settings, but do not change a private address setting in the middle of a paid session and expect the old session to return.

Cause 4: Address typed differently

Typing the portal address into a search box, adding an extra zero, adding a space, or using a lowercase L instead of the digit 1 will fail on any device. If the working phone typed the address correctly and the failing phone did not, the difference is typing, not hardware. Use the gateway from the Router or Gateway field on each device, and type it in the address bar with http:// in front of it.

Cause 5: Different WiFi band, signal, or saved network

One phone may be on a stronger signal, a different band, or the exact WiFi name, while the other is on a weaker signal, a repeater with a different name, or a similarly named network nearby. Move both phones to the same spot, close to the machine, and confirm the exact WiFi name on both before you compare portal results.

Cause 6: Device limit, session, or account state on the failing device

If the failing device already has an active, paused, or expired session record, or if a device limit has been reached, the portal may behave differently on that device than on a fresh device. This does not mean the phone is broken. Check the portal timer and session state on the failing device, and tell the operator if the portal shows a session you do not recognise.

User Checks, in a Fair Order

1. Move both phones to the same spot, close to the machine, and confirm the exact WiFi name on both.
2. Turn off mobile data and any VPN on the failing phone, until the portal opens.
3. Type the gateway from the failing phone’s own Router or Gateway field, in the address bar, with http:// in front of it, not in the search box.
4. Try an incognito or private window on the failing phone. If the portal opens there, clear the normal window cache or keep using incognito for that session, and note that the cause was browser state.
5. Check Private DNS on Android and private relay on iPhone, and set them to Off or Automatic while you log in.
6. Turn WiFi off and on once on the failing phone, then forget and rejoin the network only as a last device step, because forgetting can clear a session record and make a paused session harder to recover.
7. Do not pay again on the failing phone until the portal opens cleanly and shows the correct rates, because a payment on a confused session can create a second record.

What the Comparison Tells the Operator

A clean comparison tells the operator whether the problem is device specific or machine specific. If the portal opens on a second clean device, the operator will focus on the failing device settings listed above. If the portal later fails on the second device as well, with the same clean test, the problem is more likely machine side, such as a portal loop, a DHCP fault, or a gateway conflict, and the operator checks in the Portal Not Loading guide apply.

When you report, give the operator the comparison table from the symptom check, not just “my phone does not work”. That table saves a round of questions and prevents a machine restart that would not fix a device setting.

Operator Checks, Labelled as Operator Only

Customers should not change machine, access point, or platform settings themselves. For the operator, the checks are:

• Check whether the failing device appears in the session list, and whether it has an active, paused, expired, or blocked record that explains a different portal result.
• Check whether a device limit, a session replacement, or a portal mode change happened between the working test and the failing test.
• Check whether the access point or repeater serving the failing phone’s spot is different from the one serving the working phone’s spot, and whether that access point needs a check.
• Test the portal as a customer on a phone that has never joined the machine before, in an incognito window, to confirm the portal itself is clean.
• Do not ask the customer for banking passwords, social media passwords, or admin passwords to check a device difference.

Proof to Show the Operator

Include, in one message:

• Machine location and WiFi name, exactly as shown on both devices.
• Device types, such as Android phone model or iPhone model, if you know them, and browser used on each.
• The comparison table: WiFi name, mobile data, VPN, browser mode, address typed, and portal result for each device.
• Whether the portal opened in an incognito window on the failing device.
• Whether you had an active or paused session on the failing device before the test.

Prevention

For users, prevention is simple: use the same clean test every time, mobile data off, VPN off, address bar not search box, and incognito if a normal window behaves strangely. Keep a note of the gateway from your own device, so you do not guess it under pressure. For operators, prevention is a clear WiFi name, a clear rate sign, and a portal test as a new customer after any change, so a device difference is not mistaken for a machine fault.

Frequently Asked Questions About One Phone Works and Another Does Not

My friend’s phone opens the portal, mine does not. Is my phone broken?

Not necessarily. Browser cache, VPN, mobile data, Private DNS, private relay, typing, signal, and WiFi name can all differ between two phones. Work through the fair comparison in order before concluding the phone is broken.

Should I reset my phone if the portal will not load on it?

No, not as a first step. A phone reset is far too drastic for a portal problem. Try incognito, mobile data off, VPN off, Private DNS or private relay off, and forget and rejoin as a last device step, in that order.

The portal opened on my phone yesterday, but not today, while my friend’s phone still works. What changed?

Something on your phone or your session changed: a browser update, a VPN that started automatically, a private address change, a cached redirect, a paused session that expired, or a move to a weaker signal spot. Note what changed since yesterday, and report it with the comparison table.

Can I just use my friend’s phone to pay, and then use my phone?

No, not reliably. Sessions are usually tied to one device. Paying on a friend’s phone creates a session for that phone, not for yours. Fix the portal on your own phone first, or ask the operator whether transfer is offered on that machine, as explained in the Transfer Time to Another Device guide.

The portal loads in incognito but not in my normal browser. Should I just use incognito every time?

For that session, yes, incognito is a reasonable workaround, because it proves the cause was browser state. For the long term, clear the normal window cache for that portal, disable any extension that blocks it, and check for a saved redirect, so you do not need incognito every time.

Both phones failed after I changed a setting on mine. Did I break the machine?

Unlikely, unless you changed a machine setting as an owner. A customer phone setting cannot break a machine for other customers. If both phones now fail with a clean test, report it as a machine side problem, with the comparison table and the time it started.

What to Read Next

If the portal will not load on any device, go to the Portal Not Loading guide. If the portal shows a Not Secure warning, go to the Portal Shows Not Secure guide. If you paid and have no time, go to the No Internet After Paying guide. If your session disappeared after a pause, go to the Session Expired While Paused guide. If you want the general diagnostic method, go to the Troubleshooting pillar.