← Back to Forum
1
Proxy
LocaltoNet vs ngrok vs self-hosted reverse proxy for local webhook testing
I've already got LocaltoNet forwarding to a local HTTP service and it works fine, so this isn't really a "how do I tunnel localhost" thing. I'm trying to settle on a boring default for webhook testing and quick temporary endpoints, and the stuff I care about is practical behavior: custom domains, request/header handling, basic auth or IP restrictions, TLS quirks, and how much friction there is when rotating URLs or sharing with teammates.
For anyone who's used both hosted tunnels and a self-hosted reverse proxy in front, what did you actually stick with day to day? Mostly wondering if the extra control from a proxy ended up being worth the setup, or if it just became one more thing to babysit.
Comments (6)
I stuck with ngrok-style hosted tunnels for webhook testing once I realized stable hostname + decent request inspection mattered more than proxy control, and putting my own reverse proxy in front only started making sense when I specifically needed custom auth/header rewrites. If your main pain is rotating URLs with teammates, the hosted option is just less annoying, the proxy setup paid off for me only when some vendor had picky callback validation.
Yeah, same general experience here, but the thing that finally pushed me toward a hosted tunnel for webhook work was TLS weirdness. A couple services were totally fine with my proxy setup until they suddenly cared about cert chain details or SNI, and I got tired of debugging that instead of the actual webhook payload.
Do you ever miss having a proxy for quick response/header tweaks though, or do you just handle that inside the local app now?
I just do the response and header tweaks in the local app now, usually with a tiny middleware or a throwaway route, because spinning up a proxy for that one-off stuff ended up being more friction than the tweak itself. The only time I still reach for a proxy is when I need to see exactly what the upstream service will get after rewriting, otherwise the tunnel plus app-level handling has been simpler for me.
Use a reverse proxy only if you need to preserve the exact incoming headers untouched, that's the one thing that kept biting me when I did app-level hacks instead. Some webhook providers sign against host/proto or are weird about duplicate header casing/order, and having Caddy or Nginx in front made it easier to mirror prod closely without stuffing that logic into the app.
Yeah, this was basically my line too, once the provider starts caring about the request shape in super specific ways, a tiny Caddy config suddenly feels less goofy than trying to fake it in app code. Did you keep that proxy setup around as a reusable template, or only spin it up for the annoying providers?
Yeah, a reusable Caddy file is probably the version of this that makes sense for me, only turning it on for the annoying providers instead of leaving it in the default path all the time. I havent tried templating it yet though, if you did, did you just parameterize host/proto bits or were you also preserving duplicate headers/body untouched somehow?
Please log in to post a comment.