Run / Nginx Optimization
Routing, caching, TLS, compression, upstreams and rate limits configured for the application in front of them.
TechSteps tunes Nginx for the application actually behind it: request routing, cache rules with correct exclusions, TLS and connection settings, compression, upstream and proxy buffer configuration, and rate limits that stop abuse without blocking customers. Generic configuration snippets copied from the internet are a common cause of the problems this work fixes.
What this solves
Nginx is fast by default and easy to configure badly. Most production configurations are assembled from tutorials, each snippet correct in its original context and questionable in combination.
The results are consistent: caching applied where it should not be, proxy buffers too small so responses are written to disk on every request, upstream timeouts that do not match the application, gzip enabled for content that is already compressed, and rate limits that trigger for legitimate users.
Because Nginx sits in front of everything, a configuration problem here looks like an application problem. Time gets spent optimizing code that was never the constraint.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Including included files and the order they load. A surprising proportion of problems are a location block that never matches because an earlier one already did.
Time to first byte, cache hit ratio, upstream response time and error rates. Without a baseline the improvement cannot be demonstrated.
Nginx logs can record upstream response time. If the application is taking a second to respond, that is not an Nginx problem, and knowing this prevents a lot of wasted effort.
Cache rules that expose personalized content, or rate limits blocking real users, are more urgent than shaving milliseconds. We deal with those first.
Configuration validated with a syntax check, applied on staging where one exists, and reloaded rather than restarted so live connections are not dropped.
Comments explaining non-obvious directives, because the next person to touch this will otherwise remove something load-bearing.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Session cookies not excluded from the cache key, so one user is served another user's page. This is a data exposure, not a performance bug, and it is alarmingly common.
Nginx writes every response larger than the buffer to a temporary file on disk. Throughput drops and the cause is invisible unless you know to look for it.
A report or export that legitimately takes 45 seconds hits a 30 second timeout and returns 504. The application is blamed for a configuration limit.
Gzipping images, video or archives spends CPU to make files slightly larger. Compression should target text-based content only.
A limit tuned against imagined abuse blocks legitimate bursts, such as a customer loading a gallery. Limits should be derived from the traffic you actually observe.
Questions we actually get asked
Nginx is reporting it, and it usually is not the cause. A 502 means the upstream did not respond acceptably, most often because the PHP-FPM or application worker pool is exhausted, or the application crashed on that request. The fix is normally worker sizing or an application bug, and the logs will distinguish them.
Nginx caching is faster because it serves without invoking the application at all. It is also less aware of your application, so invalidation needs designing. A common good arrangement is Nginx caching for anonymous traffic with explicit bypass rules, and application-level caching for the rest.
HTTP/2 is worth having and is essentially free on any modern setup. HTTP/3 helps most on unreliable mobile networks. Neither is a substitute for reducing what the page loads, and neither will rescue a slow upstream.
Yes. Nginx validates configuration before applying it and reloads without dropping connections. We test the syntax, apply on staging where one exists, then reload. The risk is in what the configuration does rather than in applying it.
Very much. Cloudflare handles what it can serve from the edge; everything else reaches your origin, and that is Nginx. The two also have to agree about what is cacheable, because contradictory rules between edge and origin are a frequent source of confusing behavior.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.