3 ms·
That is true, but that is only a small part of the usefulness of ngrok. It can tunnel TCP port, assigning you a random high-numbered port at their end (like wit
by pkaeding 11y ago
That is true, but that is only a small part of the usefulness of ngrok. It can tunnel TCP port, assigning you a random high-numbered port at their end (like with ssh -R).
But if you are tunneling an HTTP service, you can be assigned a random hostname (random.ngrok.com), or you can request a specific hostname (pkaeding-test.ngrok.com), and your service will be available over both HTTP (port 80) and HTTPS (port 443) on that hostname. This can be critical for testing webhook callbacks where the remote service only allows HTTPS on port 443.
Also, when you are tunneling HTTP services (using HTTP or HTTPS), ngrok will start a web UI running at localhost:3030, detailing all incoming requests. You can examine the headers and body from both request and response, and even replay requests. This is immensely helpful when debugging webhooks.
(I am not affiliated with ngrok, except as a happy user.)
- arianvanp 11y agoYeh true. But what I do in those scenarios is hack up an ngnix config with a (self-signed) wildcard certificate and map certain ports to https endpoints on certain subdomains using ngnix reverse-proxy stuff. So I expose :9000 on the remote host, and then map :9000 to blah.my.website.com:443 using ngnix
- pkaeding 11y agoYeah, that definitely works as well, and it is also what I did before I found ngrok. It is a few more hoops to jump through in order to get things flowing, though, and you don't get the introspection/replay functionality. You can use wireshark to inspect the traffic, I suppose, but again, it isn't as easy.