Dev Tunnels URL changed? Why the address changes and how to keep one

Why does a Dev Tunnels address change?

A Dev Tunnels address is generated from the tunnel, the port and the Microsoft region that hosts it, for example https://0pbvlk3m-7032.usw2.devtunnels.ms. You can choose a tunnel ID for commands, but Microsoft doesn’t use it in the address, and it has said it has no plans to support custom names.

So the address stays the same only while you keep using the same tunnel. Anything that replaces the tunnel gives you a new address, and every webhook and OAuth registration pointing at the old one stops working. The next three sections cover the usual causes.

Was it a temporary tunnel?

Running devtunnel host without first running devtunnel create makes a temporary tunnel, which is deleted when the connection closes; the next run gets a new address. In Visual Studio, a temporary tunnel gets a new URL each time Visual Studio starts.

Create a persistent tunnel once with devtunnel create, or choose Persistent when creating the tunnel in Visual Studio, then host that same tunnel each time.

Did the tunnel expire?

Dev Tunnels deletes a tunnel after 30 days with no activity, and 30 days is the longest expiration you can set. Each use restarts the 30 days, so a tunnel you use daily stays. One you use only occasionally, such as for a monthly integration test, can be deleted between uses, and the replacement has a new address.

One developer described changing 40 files that contained the old address after their tunnel expired.

Did the tunnel come back in a different region?

The region code, such as usw2 or euw, is part of the address. A recreated tunnel can be placed in a different region from the old one. Developers roughly equally close to two regions have reported tunnels switching between uks1 and euw, breaking a registered webhook.

A July 2026 report describes tunnels recreated in West Europe coming back in a different cluster: “create succeeds, URL silently changes.” The .NET Aspire Dev Tunnels integration added a Region option in version 13.5 to pin the region.

How do I keep the same callback address?

Reuse one persistent tunnel, and use it at least once every 30 days. Before a demo or integration test, compare its address with what your webhook and OAuth providers have registered. If it changed, register the new address and send one test delivery or sign-in.

If that upkeep isn’t worth it, use a service where you choose the address and it doesn’t depend on a region. The steps for Groundhog are below.

Move your app from Dev Tunnels to Groundhog

Groundhog has no monthly data cap. Its limits apply per minute and to requests in progress instead: for example, 6,000 new requests a minute per workspace and 200 requests in progress per tunnel, with request bodies up to 100 MB (Dev Tunnels allows 16 MB). See every limit.

The command that replaces devtunnel host -p 5000 is groundhog host my-tunnel --port 5000.

1. Sign in and create a free workspace.
2. Create a tunnel named, for example, my-tunnel, and copy its connection key. Names are unique across Groundhog, so pick your own.
3. Install the CLI, which needs the .NET 10 SDK:

   Install Groundhog

   Shell

   dotnet tool install --global Groundhog.Cli --version 0.4.0-preview.7

4. Enter the key privately in your terminal. Then, with your app running on port 5000, connect it, using your app’s real port:

   Connect your local app

   Shell

   groundhog host my-tunnel --port 5000

   Your app is now at https://my-tunnel.groundhog.unifinity.com, and that address stays the same each time you connect.

5. Replace the old Dev Tunnels address with the new one in your OAuth and webhook settings, then send one test sign-in or delivery.

Using .NET Aspire? Connect from your AppHost instead.