This is based on an email I send my .NET team at work
Happy Friday,
Sorry for missing the last couple weeks. Today I want to show you ngrok.
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
message:
1 | c:\apps>ngrok |
So if you wanted to debug a site in IIS Express running on port 55204, you
would run ngrok http 55204
:
1 | ngrok by @inconshreveable (Ctrl+C to quit) |
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
header in-flight: ngrok http --host-header=rewrite 55204
. Now
everything works.
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.
Press 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.