Phone Cannot Open the Page: Check the Listen Address

The laptop serves the page at localhost, the phone joins the same VPN, and the browser on the phone reports that the site cannot be reached. Nothing is wrong with the tunnel yet, because the tunnel only delivers packets. A development server bound to the loopback interface never accepts a connection addressed to anything else, so the first place to look is the listening socket rather than the VPN.

Work through the socket, the bind setting, the firewall rule and the URL, in that order.

The Socket Answers a Narrower Question

A listener created on 127.0.0.1 accepts traffic from the machine itself and refuses everything that arrives on another address. A listener on the wildcard address accepts on every local interface, including the VPN one, which is wider than most development setups need. A listener bound to one specific VPN address is the narrowest useful option, and it only works while that address exists.

Two naming traps follow from that. In the phone browser, localhost means the phone, not the laptop. The wildcard address is a bind value rather than something to type into a URL. Anyone who tests with either of them will report a failure that never involved the network.

IPv6 adds a third case, because a socket can accept IPv4 and IPv6 depending on options that are easy to overlook. Read the address family in the listing. A wildcard entry for one family does not describe the other.

Read the Listen Address

Inspect the socket before changing configuration. The local address, port and owning process together identify whether the server is reachable from the VPN at all.

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

A local address of 127.0.0.1 settles the question: no firewall change will help, because the application is not listening on the VPN interface. A wildcard or the VPN address means the socket is fine and the next boundary applies.

Confirm the owning process too, since an unrelated service on a common port can make the table look correct while the intended server never started. Match the executable path, not only the name. A stale process from an earlier run is a frequent impostor.

Change the Bind Through the Application

Use the framework's documented listen-address option and restart the process. If the laptop owns the private address 10.77.0.1, the phone's URL becomes http://10.77.0.1:8080/ and that address must be routed through the VPN; nothing else about the setup changes.

Do not add arbitrary addresses to Windows or alter the gateway to force a bind. Those changes outlive the debugging session and surprise the next person. A server started before the VPN address exists can also fail to bind, so starting order matters for a transient interface. Give it a retry or start it after the tunnel. A bind failure at boot looks exactly like a firewall problem the next morning.

For HTTPS, keep the service hostname and certificate validation intact. A certificate warning on a raw address is a naming problem, not a step to click through, and private DNS has to agree with the listener you chose.

Open One Rule, Not the Whole Network

Once the socket accepts on the VPN address, the firewall decides whether the request arrives. Scope the rule to this application, this protocol, this local port and the authorised remote source, and confirm which profile is active on the VPN adapter.

Use the source address Windows actually sees, including any translation the gateway performs, because a rule written for the original client address will not match a translated one.

A page that loads and shows an application error is progress: HTTP rejection is a different failure from no TCP connection, and the next investigation belongs to the application's own access policy rather than to the network.

Finish by requesting the page from the intended phone and confirming that an excluded device still cannot reach it. A working listener with a rule that admits everything is not the same result.