On this page
What Nginx configuration covers
Nginx is the web server and reverse proxy in front of a large share of modern websites and APIs. It serves static files, terminates HTTPS, passes requests to your application and can cache, compress and limit traffic. Nginx configuration is the work of setting all of that up correctly for your site, instead of leaving defaults and half-understood snippets in place.
Small configuration details have large effects: a missing header breaks logins behind a proxy, a low upload limit breaks media uploads, and a wrong cache rule can show one customer another customer’s page. We work through each of these on purpose.
Signs your Nginx setup needs work
- Uploads fail with a 413 error, or long requests time out with a 504.
- The site loads slowly even though the server is barely busy.
- Several sites on one server share a single tangled configuration file.
- An e-commerce or coaching site is hammered by bots on its login or search pages.
- Nobody dares edit the configuration because a mistake once took everything down.
What’s included
- One server block per site or application, with clear, commented structure.
- HTTPS with modern TLS settings, HTTP to HTTPS and www or non-www redirects settled.
- HTTP/2, gzip or Brotli compression and correct caching headers for static assets.
- Upload size, timeout and buffer settings matched to what your application does.
- Rate limiting on sensitive endpoints such as login, search and APIs.
- Security headers and blocking of hidden files and common probe paths.
- Log formats useful for debugging, with rotation configured.
- Configuration stored in version control, tested with a config check before reload.
How we approach it
- Read the current configuration and logs to understand how traffic flows today.
- Agree the target behaviour: domains, redirects, caching and limits.
- Rewrite or tidy the configuration in a staging copy and validate it.
- Apply with a graceful reload, then test from outside: redirects, headers, TLS and uploads.
- Document the layout so adding a new site is a small, safe change.
Tools and related setup
We work with Nginx on Ubuntu and Debian, often alongside PHP-FPM, Node.js and Python application servers, or Docker containers. Certificates come from Let’s Encrypt with automatic renewal. Where Cloudflare sits in front, we configure Nginx to trust its forwarded IP headers so logs and rate limits see real visitor addresses rather than Cloudflare’s.
What affects timeline and cost
Configuring Nginx for one site is quick. Larger jobs involve many domains, complex rewrite rules migrated from Apache, caching of dynamic content, or high-traffic tuning that needs load testing. Existing undocumented configurations take longer to untangle than fresh setups.
If you run several servers, we can manage the configuration centrally with Ansible so the same shared settings, such as TLS and security headers, are applied consistently everywhere instead of drifting apart over time.
How we organise a multi-site configuration
On servers that host several sites, such as an agency box or a SaaS product with separate app, API and marketing domains, structure matters more than any single directive. We keep the layout predictable so anyone can find and change the right thing safely:
- One file per site or application, named after its domain, so there is no hunting through a single huge file.
- Shared snippets for TLS settings, security headers and proxy headers, included where needed rather than copied into every block.
- A default server block that rejects requests for unknown hostnames, so the server does not serve a random site to scanners.
- Separate access and error logs per site, which makes debugging one client’s problem much faster.
- Comments explaining unusual rules, especially redirects and caching exceptions that exist for business reasons.
- Everything in version control, so every change has an author, a date and a way to roll back.
With this structure, adding a new site becomes copying a template, adjusting the domain and upstream, running a configuration test and reloading. That is a routine task rather than a risky one, which is the whole point.
Common mistakes
- Reloading without running a configuration test first.
- Caching pages that contain logged-in or cart data.
- Forgetting forwarded headers, so the application thinks every visitor has the same IP or that the site is plain HTTP.
- Copying tuning values from a blog post written for a very different server.
Related: Reverse Proxy Setup, SSL Installation and Apache Configuration. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Can you move our site from Apache to Nginx?
Yes. We translate rewrite rules and .htaccess behaviour into Nginx configuration and test the important URLs before switching.
Will changes cause downtime?
No, if done properly. Configuration is tested first and applied with a graceful reload, which does not drop active connections.
Can Nginx cache our WordPress or WooCommerce site?
Yes, with care. Public pages can be cached while cart, checkout and account pages are excluded based on cookies and paths.
Do you work with Nginx inside Docker?
Yes. The same principles apply, with configuration mounted from version control and certificates handled consistently.
Can you add rate limiting without blocking real customers?
Yes. We start with generous limits on specific sensitive paths, watch the logs for what real traffic looks like, and tighten gradually. Limits apply per visitor IP, with Cloudflare’s forwarded address used when it sits in front.
Talk to us about nginx configuration
Virtual hosts, caching, compression and rate limiting configured the right way.