Nginx

What is Nginx and what does it do?

Nginx is an HTTP server, reverse proxy and traffic-handling layer. It can serve static files directly, forward requests to application servers and apply connection, header, caching or access rules at the public boundary.

Its event-driven worker model handles many connections without assigning one operating-system thread to every connection. The master process reads configuration and manages workers, while workers process network events and requests.

How a request finds its destination

Request handling starts with an address and port. Nginx selects a server block using the listening socket and the request host name. It then compares the URI with location rules inside that server.

The chosen location decides what happens next. It may map the URI to a file, return a response, invoke another protocol handler or use the proxy module to contact an upstream application. Server and location selection are therefore part of application behavior even though they live outside application code.

One site with static and proxied paths

This configuration sends API requests to an application on the local machine and serves an HTML entry point for the remaining site paths:

server {
    listen 80;
    server_name example.test;

    location /api/ {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://127.0.0.1:3000;
    }

    location / {
        root /srv/site;
        try_files $uri $uri/ /index.html;
    }
}

The example uses a reserved test domain and a loopback upstream. Real deployment also needs TLS, access policy, logs, timeouts and an explicit decision about which forwarded headers the application may trust.

Proxy URI and header semantics

Small syntax differences can change the request received upstream. The URI in proxy_pass and the trailing slash on a location influence whether a prefix is preserved or replaced. Representative paths should be tested after every routing change.

Forwarded headers cross a trust boundary. A backend should trust client identity or scheme headers only when they come from a controlled proxy path. Nginx may replace an untrusted incoming value rather than append it, depending on the surrounding proxy chain.

The operational boundary

Nginx fits static delivery, reverse proxying and a clean front door for one or more application services. It gives routing and transport behavior an independently operable layer.

The boundary is configuration interaction. Location precedence, rewriting, buffering, request limits and timeouts can produce behavior that passes syntax validation but remains logically wrong. Configurations should stay small, be validated before reload and be tested with actual host names, paths and failure cases. A proxy cannot make an unhealthy upstream reliable by itself.