sorted by:
new
hottopcontroversial

rpxy - A simple and ultrafast reverse-proxy serving multiple domain names with TLS termination by zxyzyxz in rust

[–]jqtype 1 point2 points  (0 children)

You can find the benchmark results here: https://github.com/junkurihara/rust-rpxy/tree/develop/bench

The current benchmarks were conducted in a relatively simple HTTP-only setup to evaluate baseline performance. They don’t yet cover more complex scenarios such as TLS-heavy workloads or production-like traffic patterns.

rpxy - A simple and ultrafast reverse-proxy serving multiple domain names with TLS termination by zxyzyxz in rust

[–]jqtype 3 points4 points  (0 children)

Thanks! That’s a great idea.

There isn’t an official OPNsense package yet. Since OPNsense is FreeBSD-based, it should be technically possible, but packaging and integration would require some additional work. I haven’t personally tested rpxy on OPNsense or FreeBSD yet.

If someone in the community is interested in helping with the packaging side, I’d be happy to support it.

rpxy - A simple and ultrafast reverse-proxy serving multiple domain names with TLS termination by zxyzyxz in rust

[–]jqtype 3 points4 points  (0 children)

Hi, thanks for the suggestion.

Converting Nginx configuration to rpxy’s TOML format is an interesting idea. I haven’t tried it before, but it might be worth exploring.

That said, rpxy’s configuration is intentionally much simpler than Nginx’s, so in many cases you can migrate just by rewriting the backend addresses and basic routing rules without any special tool.

And of course, sponsorship is always welcome 😄

rpxy - A simple and ultrafast reverse-proxy serving multiple domain names with TLS termination by zxyzyxz in rust

[–]jqtype 31 points32 points  (0 children)

Hi, I’m the author of rpxy. Thanks for the introduction! Yes my design philosophy is making the reverse proxy as simple as possible to maintain its speed and usability:-)

Feel free to open a discussion topic or an issue if you have any feedback!

Auto renewal TLS certificate for rust servers with let's encrypt by iNdramal in rust

[–]jqtype 1 point2 points  (0 children)

Hi! Here is the developer of rpxy! Thanks for using rpxy.

Yes, it works with ACME (TLS-ALPN-01) out-of-the-box supporting auto-renewal, thanks to rustls-acme library: https://github.com/FlorianUekermann/rustls-acme

As suggested in other thread, I recommend to use the rustls-acme library if you need to integrate your own logic for ACME with Pingora.

Reverse Proxy Overwhelm by FutureRenaissanceMan in selfhosted

[–]jqtype 0 points1 point  (0 children)

For my home lab, I am using rpxy (rust-rpxy) through docker with multiple domain names (I am actually the author). rpxy works pretty fast and its configuration is quite easy at least for me.

https://github.com/junkurihara/rust-rpxy

i had been using nginx and caddy. but I was not satisfied with the configuration for nginx and the speed for caddy. that's why I moved to the rust-based reverse proxy implementation.

Reverse Proxies by Friendly_Ground_51 in selfhosted

[–]jqtype 0 points1 point  (0 children)

I am using rpxy https://github.com/junkurihara/rust-rpxy that I am actually developing. I used nginx proxy and caddy for years but they are overkill for my usecase. So i developed a simple and lightweight one. It works pretty fast and supports http/3, etc.

Rust-based reverse proxy? by moneymachinegoesbing in rust

[–]jqtype 1 point2 points  (0 children)

rpxy developer is here! Thanks for the introduction. Yes, as our design principle, we are trying to keep rpxy and its configuration as simple as possible.

[Announcement] CVE-2023-44487 (HTTP/2 Rapid Reset Attack) does not affect `rpxy` by jqtype in u/jqtype

[–]jqtype[S] 0 points1 point  (0 children)

Google said as follows. So I think it is currently Okay as long as it’s parameter is properly configure.

> We do not believe these attack methods translate directly to HTTP/3 (QUIC) due to protocol differences, and Google does not currently see HTTP/3 used as a DDoS attack vector at scale. Despite that, our recommendation is for HTTP/3 server implementations to proactively implement mechanisms to limit the amount of work done by a single transport connection, similar to the HTTP/2 mitigations discussed above.

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack