Hey HN, I built Tunn because I was frustrated with ngrok's latency and session limits.
It uses QUIC protocol instead of TCP, which gives ~4x lower latency with keep-alive connections (135ms avg vs 663ms for ngrok in my benchmarks).
Features:
- HTTP/TCP/UDP tunneling (ngrok doesn't support UDP)
- Built-in request inspector at localhost:4040
- QR code in terminal for quick mobile testing
- 0-RTT reconnect (instant reconnect on network change)
- Single binary, no dependencies
Sometimes I feel some of these rewrites or competitors to existing products just completely miss the point. We don't use ngrok because it has low latency or not. I'd say the amount of ngrok users that care that much about the latency you can shave off using QUIC is negligent.
Do you have any use cases where this is important?
Hey HN, I built Tunn because I was frustrated with ngrok's latency and session limits.
It uses QUIC protocol instead of TCP, which gives ~4x lower latency with keep-alive connections (135ms avg vs 663ms for ngrok in my benchmarks).
Features: - HTTP/TCP/UDP tunneling (ngrok doesn't support UDP) - Built-in request inspector at localhost:4040 - QR code in terminal for quick mobile testing - 0-RTT reconnect (instant reconnect on network change) - Single binary, no dependencies
Written in Rust, uses quinn for QUIC transport.
Install: curl -s https://tunn.uz/install | bash Then: tunn http 3000
Free tier available, pro is $3/mo for static ports and custom domains.
Happy to answer any questions about the QUIC implementation or architecture decisions.
How does this compare to cloudflare tunnels?
Sometimes I feel some of these rewrites or competitors to existing products just completely miss the point. We don't use ngrok because it has low latency or not. I'd say the amount of ngrok users that care that much about the latency you can shave off using QUIC is negligent.
Do you have any use cases where this is important?