Nginx is the best way to proxy for most cases today on commodity hardware
January 23, 2019
Nginx is the best way to proxy for most cases today on commodity hardware
Score 9 out of 10
Vetted Review
Verified User
Overall Satisfaction with Nginx
We use Nginx widely as our primary way of proxying and SSL termination. Specifically, our highly-available architecture used for both a bidding environment and serving ads are designed with Nginx. We have had success building out some applications with deeper Nginx integration as well, our own home-built CDN.
- SSL handling
- Configuration is very unique, and has a learning curve, but powerful and generally clear
- Very active user groups
- Decent customer support
- Customer support can be strangely condescending, perhaps it's a language issue?
- I find it a little weird how the release versions used for Nginx+ aren't the same as for open source version. It can be very confusing to determine the cross-compatibility of modules, etc., because of this.
- It seems like some (most?) modules on their own site are ancient and no longer supported, so their documentation in this area needs work.
- It's difficult to navigate between nginx.com commercial site and customer support. They need to be integrated together.
- I'd love to see more work done on nginx+ monitoring without requiring logging every request. I understand that many statistics can only be derived from logs, but plenty should work without that. Logging is not an option in many environments.
- When we first migrated our primary bidding environment architecture to Nginx, it was under duress due to Apache's inability to keep up when we consolidated away from an HAProxy model to a central HTTP proxy. So we even when we did not know what we were doing, we were able to make it work in a bad situation, and everyone was quite happy.
- The biggest complaint I have is that I find the module compilation requirements for nginx+ rather burdensome. If we pay for Nginx+, I'd love to see then have pre-built modules for ready for each release of more modules. We are spending our own time engineering an in-house solution for module testing for nginx+ releases, which is disappointing.
- I've also, as the primary Nginx person at my organization, inserted my expertise into other projects, and have saved our company lots of money getting rid of big $$$ appliances for general SSL proxying.
- Speaking of Nginx replacing SSL appliances, we had an instance where we had to suddenly enable elliptic-curve SSL ciphers and our big $$$ appliances (you know who they are), were falling over. Even their SSL accelerator cards, after all, are just a few extra cores to process SSL. But in an environment of our size, we use DNS to spread the load to hundreds of frontend proxies with dozens of cores each to spread this load out, all at a lower price than ONE of the appliance pairs running Nginx. We couldn't even tell the change in load in our Nginx architecture when we enabled the ciphers.
NetApp, f1, etc., [I've] used them all. I find using commodity hardware across diverse endpoints running software solutions is cheaper while being more available than individual hardware solutions. and I find Nginx to be the best proxy solution that can do everything we need.