This is based on an email I send my .NET team at work
Sorry for missing the last couple weeks. Today I want to show you ngrok.
Have you ever wanted to let someone connect to a development version of your webapp and test something out? It’s a pain to configure IIS Express to allow external configurations, and to use real IIS you’d have to set up a deployment, configure a host binding, probably stop using SQL Server LocalDB and switch to SQL Express, and if the person wasn’t on the local network you’d be out of luck anyway.
Ngrok solves this problem by creating a public domain that tunnels into your local server.
For windows you just have to unzip a package and open a command line
prompt inside that extracted folder. Run
ngrok.exe to see the help
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
So if you wanted to debug a site in IIS Express running on port 55204, you
ngrok http 55204:
1 2 3 4 5 6 7 8 9 10 11
Now you just need to point your browser, or your mobile device at http://4ae9df86.ngrok.io to get your site running.
Oops. Now you get 400 Bad Request with a message about a bad host name.
The problem is that the ngrok passes through the public facing host name
4ae9df86.ngrok.io) as the HTTP Host header. IIS Express doesn’t bind
to that host, and so you get the 400.
Ngrok solves this with a flag to instruct the proxy to rewrite the host
ngrok http --host-header=rewrite 55204. Now
If you checkout http://localhost:4040 in your browser, you’ll find a history of requests that ngrok proxied. You can explore each request and response and even replay them for debugging.
CTRL+C in the terminal to end the proxy.
I’ve found it really useful for debugging localhost sites on mobile devices. The website lists a few other use-cases and I’d encourage you to check it out.