Nginx: What It Is and How It Works

Nginx is an open-source web server initially used as a web server but now also functions as a load balancer, HTTP cache, and reverse proxy. Many high-profile companies, including Microsoft, DuckDuckGo, Atlassian, Cisco, and Xerox, rely on Nginx. It is also used by industry giants such as Intel, Apple, Twitter, Facebook, and Google.

Origins of Nginx

Nginx was first released in 2004 by Igor Sysoev to solve the C10k problem, which refers to performance issues when managing 10,000 concurrent connections. Designed to optimize performance on a large scale, Nginx consistently outperforms other web servers, especially when handling simultaneous requests or static content.

How Nginx Works

Nginx was built to ensure high concurrency while minimizing memory usage. Unlike traditional web servers, it doesn't create new processes for each web request. Instead, it uses an asynchronous, event-driven approach, handling requests within a single thread. A master process manages multiple worker processes, which handle the actual request processing. Since Nginx is asynchronous, worker processes can handle multiple requests simultaneously without blocking others. Its ability to handle load balancing and serve static files efficiently makes it comparable to Apache.

Nginx vs. Apache

While Apache is one of the most popular open-source web servers, powering nearly half of all known websites, Nginx is gaining traction. According to W3Techs, Nginx powers around 42% of websites, while Apache is slightly higher. A survey by Netcraft of over 230 million domains showed Nginx usage at 26% compared to Apache's 31%.

However, when considering high-traffic sites, Nginx is the preferred choice:

• Over 62% of the top 1,000 sites

• Over 67% of the top 10,000 sites

• Nearly 61% of the top 100,000 sites

In contrast, Apache powers less than 17% of the top 1,000 sites and around 19% of the top 10,000 sites. Major sites like WordPress, NASA, and Netflix use Nginx due to its efficiency with resource-heavy traffic.

Nginx or Apache: Everything You Need to Know

To determine if your website runs on Apache or Nginx, you can check the HTTP server headers using Chrome Devtools or tools like GTmetrix and Pingdom. However, sites behind proxies (e.g., Cloudflare) may not reveal the underlying server.

When comparing Google search trends since 2004, Apache has seen a steady decline, while Nginx has experienced slight growth. Since 2018, Apache has also lost ground among popular sites.

Why This Matters Beyond the Numbers

The market-share figures above matter less than what they represent: high-traffic sites use Nginx because it keeps a single server responsive when several things are happening on it at once — serving a website, running a reverse proxy in front of an application, and load-balancing traffic across multiple backend servers. When we configure or migrate a client's server, deciding whether Apache or Nginx (or both, in a reverse-proxy setup) fits a specific workload is one of the concrete choices made during that project, not an abstract preference.

A Real Reverse Proxy Configuration

The most common real-world use of Nginx we set up for clients isn't as a standalone web server, but as a reverse proxy in front of an application server (Node.js, a Java backend, a Python app running on Gunicorn or uWSGI). A minimal working example, in /etc/nginx/sites-available/app.conf:

server {
    listen 80;
    server_name app.esempio.it;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nginx listens on the public port and forwards each request to the application running on an internal port; the proxy_set_header lines are what let the backend application see the real client IP and protocol, instead of seeing every request as coming from 127.0.0.1. The configuration is enabled with a symlink into sites-enabled and reloaded with nginx -t && systemctl reload nginx — running nginx -t first to validate the syntax avoids reloading into a broken configuration.

Errors You'll Actually Run Into

• 502 Bad Gateway — Nginx received a request but the backend it's proxying to didn't respond correctly, most often because the application isn't running, crashed, or is listening on a different port than the one configured in proxy_pass.
• 504 Gateway Timeout — the backend is running but took too long to respond; worth checking whether it's the application that's slow (a long database query, for example) before increasing proxy_read_timeout.
• "too many open files" in the error log under load — Nginx (and the OS) have a limit on open file descriptors; on a server handling many concurrent connections, this needs raising both in worker_rlimit_nofile and at the OS level (ulimit).
• Static content changes don't show up — Nginx's own configuration cache and browser caching headers (or a CDN in front of it) are the two most common causes; a hard refresh and checking the Cache-Control headers usually settles which one it is.

When It Makes Sense to Add Nginx in Front of Something

Putting Nginx in front of an existing application server is worth doing mainly for three reasons: TLS termination in one place instead of configuring certificates on every backend service, serving static files (images, CSS, JS) directly instead of routing them through the application, and load-balancing traffic across more than one backend instance using the upstream directive. For a single small internal application with limited traffic, this extra layer is often not worth the added complexity — it earns its place once there's more than one backend to route between, or once TLS and caching need to be managed centrally.

Solutions at Your Fingertips!

Having trouble using Nginx or want to learn more? Contact TN Solutions for professional IT support and assistance to help you find the right solution for Nginx and all your IT needs!