What causes Remote Preview failing to connect from mobile devices?

The device cannot reach the preview session — phone and computer on different networks (guest Wi-Fi, VPNs), firewalls blocking the connection, corporate networks isolating clients, or an expired session.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix Construct 3 Remote Preview Not Connecting on Phones

Quick answer: Put both devices on the same normal network, disable VPNs and client isolation, and re-create the session — Remote Preview needs a clean network path between the two.

Remote Preview is the fastest way to test touch on real devices — when it connects. The failures are network topology, nearly always. Here is the checklist.

How to fix it

1. Same network, really

Guest SSIDs, 2.4 vs 5 GHz with isolation, and phone-on-LTE all break the path — confirm both devices show the same network, and toggle Wi-Fi on the phone to force reconnection.

2. Kill VPNs and isolation

VPNs on either device reroute traffic away from the LAN; router 'AP/client isolation' (default on many guest networks) blocks device-to-device traffic entirely — disable both.

3. Open the firewall for the browser

Desktop firewalls that block the browser's local server connections stop preview — allow the browser on private networks (Windows' first-run network prompt matters).

4. Fall back to an export

On locked-down networks (offices, schools), a quick web export to any static host tests on-device in minutes — do not lose an afternoon to a router setting.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Construct 3 error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The bug you can't reproduce isn't gone — it's just invisible until you capture it from the player's device.