How to Fix: With the `experimental-https` and `-H` options, the next dev will show a different URL

When Next.js runs with experimental HTTPS and a custom host via -H 0.0.0.0, the dev server can print a misleading browser URL. The server is reachable, but the displayed address may switch to a different hostname than the one developers expect, which creates confusion during local testing, mobile device validation, and certificate checks.

Understanding the Root Cause

This issue happens because host binding and display URL generation are not the same thing. When you start next dev with -H 0.0.0.0, the process binds the development server to all network interfaces. That is a valid listening address, but it is not always the ideal hostname to show users in terminal output.

Once –experimental-https is enabled, Next.js also has to decide which hostname to use for the generated HTTPS URL. At that point, the dev server may derive a display value from local machine resolution, certificate assumptions, or internal hostname formatting rather than preserving the exact host passed through -H. The result is that the terminal can show a URL that differs from the host developers explicitly provided.

In practice, this is mostly a display inconsistency, not always a runtime failure. The app may still be accessible through the expected local or LAN address, but the printed URL can be wrong, unexpected, or less useful for testing on other devices.

This becomes more noticeable with HTTPS because certificate trust, hostname matching, and network interface selection matter more than they do with plain HTTP. A mismatch between the displayed URL and the actual host you intend to use can lead to browser warnings or failed access from phones, tablets, containers, or virtualized environments.

Step-by-Step Solution

The safest approach is to treat 0.0.0.0 as a bind address only and open the app using the exact hostname or IP address you want to test.

1. Start the dev server intentionally

corepack npx next dev -H 0.0.0.0 --experimental-https

This tells Next.js to listen on every interface. That part is correct for cross-device access on your local network.

2. Do not rely on the printed URL alone

If the terminal shows a different host, manually open the address you actually want to test:

• localhost over HTTPS
• 127.0.0.1 over HTTPS
• Your machine’s LAN IP, such as device IP over HTTPS

Use the hostname that matches your real testing scenario instead of trusting the terminal output.

3. Prefer an explicit host for single-machine testing

If you only need the app on your current machine, bind directly to localhost:

corepack npx next dev -H localhost --experimental-https

This usually keeps the displayed address aligned with what you expect in the browser.

4. Use a LAN IP when testing from other devices

If you need phone or tablet access, find your machine’s local IP and bind with it explicitly:

corepack npx next dev -H 192.168.1.10 --experimental-https

Replace the example IP with your actual network address. This reduces ambiguity and makes the visible URL more meaningful for external devices.

5. Verify the certificate behavior

Because this bug appears with experimental HTTPS, check whether the browser certificate warning is tied to a hostname mismatch. If the generated certificate is valid for one host but you open another, the browser may complain even though the dev server itself is healthy.

6. Add a package script for consistency

To avoid team-wide confusion, standardize the command in package.json:

{
  "scripts": {
    "dev:https": "next dev -H localhost --experimental-https",
    "dev:https:lan": "next dev -H 0.0.0.0 --experimental-https"
  }
}

This makes the intended usage explicit: one command for local browser work, another for network testing.

7. Document the correct URL in your project README

If your team depends on HTTPS during development, add a short note explaining that the displayed URL may differ from the bind host when using 0.0.0.0. That prevents unnecessary debugging.

Common Edge Cases

1. Browser certificate warnings
If the printed hostname does not match the hostname in the generated certificate, the browser may show a security warning. This is especially common when switching between localhost, 127.0.0.1, and a LAN IP.

2. Docker, Codespaces, or remote dev containers
In containerized environments, 0.0.0.0 is often required for binding, but it should almost never be treated as the final browser URL. The externally accessible hostname may come from port forwarding or a remote tunnel instead.

3. Mobile device testing fails even though the server is running
The app may be listening correctly, but your phone cannot access the host shown in the terminal. Use the machine’s actual LAN IP and confirm firewall rules allow inbound traffic to the dev port.

4. Hosts file or custom local domains
If you use a custom local domain, the HTTPS certificate and the chosen hostname must align. Otherwise, the output may look valid while the browser rejects it.

5. Confusion between listen address and public URL
A common misunderstanding is assuming that -H 0.0.0.0 means you should browse to 0.0.0.0. It does not. That address means “listen everywhere,” not “open this exact URL in the browser.”

FAQ

Why does Next.js show a different URL when I pass -H 0.0.0.0?

Because 0.0.0.0 is a bind target, not necessarily the hostname Next.js chooses for terminal display under experimental HTTPS. The server can listen on all interfaces while still printing a different computed hostname.

Is this a real server bug or only a terminal output problem?

In many cases, it is primarily a display bug. The app still runs, but the shown URL can be misleading. It becomes a functional issue when the wrong hostname causes certificate warnings or sends developers to an unreachable address.

What is the best workaround until the issue is fixed?

Use localhost for same-machine development, or bind to a specific LAN IP when testing on other devices. Avoid depending on the printed URL when using -H 0.0.0.0 with –experimental-https.

The key takeaway is simple: bind broadly, browse explicitly. With experimental HTTPS, the host shown by next dev may not be the host you should actually open, so choose the browser URL based on your target environment rather than terminal output alone.