# Why won’t my phone open my local dev site?

> Use the computer's LAN address, check the dev server's bind host and port, then trace API calls and HTTPS-only browser features on the phone.

Canonical HTML: https://canopyide.dev/guides/phone-cannot-open-localhost-dev-server
Article date: 2026-09-28

The page works in Canopy Preview on your computer, but `localhost:3000` fails on your phone. The phone's `localhost` means the phone itself. To inspect the same local app on a second device, use the computer's reachable LAN address and the server's actual port, then check whether the page's API requests and browser features work from that new origin.

## Use the computer's address, not the phone's localhost

Start the app from the intended checkout in Canopy Servers and read the URL and port printed by that process. On the computer, find its LAN address on the Wi-Fi or wired network the phone can reach. On the phone, open `http://<computer-LAN-address>:<actual-port>`; do not type `0.0.0.0` or the computer's `localhost` URL into the phone browser. The phone and computer generally need a route between them, such as the same reachable local network. Guest Wi-Fi, client isolation, a VPN, or a firewall can prevent that route even when both devices appear to have Internet. First try the LAN URL on the computer itself. If it fails there, fix the server's bind or port before investigating the phone.

*The first observation determines which boundary to inspect.*

| What you see | Check next | Likely owner |
| --- | --- | --- |
| Computer's localhost works; its LAN URL fails on the computer | Server bind host and printed port | Dev server configuration |
| Computer LAN URL works; phone times out | Network route, guest isolation, firewall, VPN | Local network or host firewall |
| Phone loads HTML but app actions fail | Browser API requests and backend bind/URL | App configuration or API server |
| Phone loads but camera or service worker fails | HTTPS and secure-context requirement | Browser origin or preview setup |
| Phone shows another branch or app | Actual port, process working directory, and checkout | Local service selection |

## Check what address the dev server listens on

A process listening only on the loopback interface can serve the computer's browser while refusing LAN connections. Vite's current server documentation lists `localhost` as its default and supports `--host 0.0.0.0` or `--host` for LAN listening. Check the repository's actual script before adding a flag; its framework or configuration may already provide one. Next.js currently documents `next dev` with a default hostname of `0.0.0.0`, so a Next app that still cannot be reached may have a different network or app-level problem. Use the printed port rather than assuming a default: Vite can choose the next free port unless strict port is enabled. Save only the verified project command in Canopy, then retest the same LAN URL.

- `0.0.0.0` is a listening address, not a phone URL.
- Check the host process and its working directory before changing any firewall setting.
- A Windows WSL2 setup may need additional networking configuration even when Vite listens on all addresses.

## When the page opens but the app fails, follow its requests

The frontend can load over the computer's LAN address while its JavaScript still calls `http://localhost:5000` or a local Supabase URL. In the phone browser, that second `localhost` also points to the phone, so forms and data may fail even though the page renders. Inspect the app's network errors through the browser's remote debugging tools or the server logs; identify the exact request host, status, and component. A relative `/api` route or development proxy can keep browser requests on the frontend origin when the project supports that design. Vite documents a development proxy for selected paths. If the backend must be reached directly, it needs its own reachable bind and approved origin configuration. Do not solve a failed local request by silently swapping to production API keys or data.

- Match the phone's page URL and failing request URL separately.
- Check authentication cookies, allowed origins, and callback URLs when the request arrives but login fails.
- Verify a safe read and write against the intended development data target after changing an API URL.

## Account for HTTPS-only browser behavior

A page on `http://localhost` may be treated as a secure context by browsers, while a page reached through an ordinary `http://192.168...` address generally is not. MDN documents that service workers require a secure context and provides `window.isSecureContext` to check the browser's decision. If camera access, service workers, or another protected API works on the computer but fails on the phone, check this origin difference before asking an agent to rewrite the feature. Use an HTTPS development route with a trusted certificate or an approved preview deployment when the feature requires it. A tunnel can provide a temporary reachable URL, but it must be configured for the app and its backend deliberately; a development server exposed to other people should not have production data or unattended admin paths behind it.

- Compare the exact browser origin and `isSecureContext` result on each device.
- Test the entire login, API, and callback path on the same HTTPS route if one is introduced.
- Do not disable host or CORS protections broadly just to make one phone test pass.

## Choose local page access or agent control deliberately

Canopy Remote lets an authorized phone or browser control a running Canopy host: inspect terminals, agents, changes, services, and usage through its own optional access route. That does not automatically publish the app's development server as a website your phone can browse. For a same-network page test, use the app's LAN URL and the checks above. For an off-network product demo, use the project's approved preview deployment or an authenticated tunnel configured for the app; check which local and external services the demo will contact. For remote agent supervision, use Canopy Remote and verify the host, session, branch, and live process after a reconnect. Keep a note with the tested URL, port, checkout, network, and backend target so the next session does not debug yesterday's server.

- Distinguish 'see the page on a phone' from 'control the coding agent from a phone.'
- Stop a temporary access route when its test is finished.
- Review the final diff if an agent changes bind, CORS, authentication, or environment settings.

## Copyable resources

### Phone cannot open local app: diagnosis card

Use a test account and redacted network identifiers; do not share credentials or customer data.

````text
App checkout, branch, and Canopy service command: [ ]
Printed local URL and actual port: [ ]
Computer LAN URL and result on computer: [ ]
Phone network and same LAN URL result: [ ]
Server bind host and framework: [ ]
Firewall, guest Wi-Fi, VPN, or WSL boundary checked: [ ]
If page loads, failing API request host/status: [ ]
Backend, auth callback, and development data target: [ ]
Browser secure-context result and feature tested: [ ]
Final working URL, test result, changed files, and owner: [ ]
````

## Frequently asked questions

### Why does localhost work on my laptop but not my phone?

Each device has its own loopback address. Use the laptop's reachable LAN address and the app's actual port, then confirm the server listens on a LAN interface.

### Should I put 0.0.0.0 in my phone browser?

No. It tells a server which interfaces to listen on. In the browser, use the computer's LAN address and the port the server printed.

### Why does the page load on my phone while Save fails?

The frontend may be reachable while its API URL still names localhost on the phone or another unavailable service. Inspect the request host and backend configuration before changing app code or data settings.

### Does Canopy Remote make my local website public?

Canopy Remote is an optional way to control and inspect the running desktop host. Publishing or tunneling the app's development server is a separate setup.

## Sources and further reading

- [Vite server host, port, proxy, and allowed-host documentation](https://vite.dev/config/server-options)
- [Next.js CLI: development hostname and port](https://nextjs.org/docs/app/api-reference/cli/next)
- [MDN: secure contexts and localhost exception](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Secure_Contexts)
- [Canopy app README: Preview, Servers, and Remote scope](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)

## Related Canopy pages

- [Run a website, API, and background worker in one workspace](https://canopyide.dev/guides/run-local-development-servers.md)
- [How do I stop two agent worktrees from using the same port?](https://canopyide.dev/use-cases/avoid-dev-server-port-collisions-with-worktrees.md)
- [Debug an agent-built page using the browser console and network log](https://canopyide.dev/guides/debug-agent-built-page-with-console-and-network.md)
- [Resume a local coding agent from your phone](https://canopyide.dev/use-cases/resume-coding-agent-from-phone.md)
- [Is my local AI-built app using the production database?](https://canopyide.dev/guides/is-local-ai-built-app-using-production-database.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.