Jan Mikoláš
Glossary
nginx
nginx accepts web traffic, decides where to forward it and can serve part of the response itself. A correct configuration must preserve both the security and application context of a request.
Short definition
A web server and proxy in front of an application, not a replacement for it.
nginx can return images, JavaScript, CSS and other static files directly. For the dynamic part of an application, it usually acts as a reverse proxy: it accepts an HTTP request from a browser or API client and forwards it to a selected upstream such as PHP-FPM, a Symfony API or a Node.js service.
nginx does not execute PHP code itself. PHP uses a FastCGI connection to PHP-FPM, while an HTTP application uses proxy_pass. The distinction matters for path, header, timeout and security configuration. The proxy defines a network boundary, not order rules, permissions or domain logic.
Use cases
Where nginx creates a useful HTTP boundary
It most commonly sits between the public internet and an application, handling technical properties of HTTP traffic in one place.
- an HTTPS certificate and redirects from HTTP to HTTPS in front of a PHP application or API
- delivering public static files without burdening the application runtime
- routing different domains and paths to a website, administration interface or separate API
- forwarding a request into an internal Docker network without publishing the application and database ports
- setting the request body size, timeouts, headers, logs, caching and basic rate limiting
Practical example
A public API in front of a PHP application on a Docker network
The API at api.example.cz accepts HTTPS through nginx. nginx delivers any public files and sends all API requests to the app service on the internal network. Neither PostgreSQL nor Redis exposes a port; only the application or a designated worker accesses them.
For an order import, a worker performs the long-running job rather than keeping one nginx HTTP request open. The proxy has conservative timeouts for ordinary API calls, and its log shows whether a limit rejected the request or the upstream itself failed to respond in time.
upstream app_backend {
server app:8080;
}
server {
listen 443 ssl;
server_name api.example.cz;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://app_backend;
}
}How it works
From a public address to the application response
The configuration selects a virtual server and location block. That block either responds directly or selects the internal service that receives the request.
- Accepting the connection nginx listens on an HTTP or HTTPS port. For HTTPS, it uses a server certificate and can terminate the encrypted connection here; the client verifies the certificate validity.
- Server and location The hostname and URI select a server block and appropriate location. Rules should be unambiguous, particularly for prefixes, regular expressions and redirects.
- Static file or upstream nginx returns a static file itself. It forwards a dynamic request over FastCGI or as a reverse proxy to an application process or group of upstream servers.
- Headers and protective limits The proxy forwards the required Host and information about the original scheme and client address. It can also reject an excessively large request body or limit repeated requests.
- Response and observability The response returns to the client through nginx. Access and error logs should make it possible to distinguish a proxy error, an application error and a slow upstream.
Main parts
The configuration describes HTTP traffic and its boundaries
server, location and upstream operate at a different level from an application controller or database query.
http, server and location
Shared rules are defined in the http context, server represents a virtual host and location defines behaviour for a selected path. An overly broad rule can accidentally capture another URL.
Reverse proxy and upstream
proxy_pass forwards HTTP requests to another HTTP server. An upstream can group multiple backends for load balancing but needs clear health-check and failure behaviour.
FastCGI for PHP
PHP-FPM accepts FastCGI requests and is not used as a standard HTTP API. The configuration must identify the script correctly and must not allow unintended files in an upload directory to be executed.
TLS and forwarded headers
An application behind a proxy needs to know whether the original request used HTTPS. X-Forwarded-* headers can be trusted only from a known proxy under your control; a client can forge them.
Caching, buffering and limits
The proxy cache reduces upstream load only for safely selected shared content. Buffering, timeouts and limit_req affect operational resilience but must not change the meaning of a business operation.
Benefits and limitations
One HTTP boundary simplifies operations but requires precise configuration.
Benefits
- centralised HTTPS, domain routing and a basic HTTP policy
- fast delivery of static files without the PHP runtime
- hidden internal ports and the ability to route multiple applications behind one public entry point
- consistent access and error logs at the boundary between the client and application
What to watch for
- a location and proxy_pass combination with an incorrect slash can alter the forwarded path
- trusting incoming X-Forwarded-* headers allows the client scheme or address to be spoofed
- unsuitable timeouts, body sizes or retries can disrupt a long import or write operation
- a cache must not share personalised or state-changing responses among users
- rate limiting does not replace authentication, authorization or protection against every application attack
Where to draw the line
For HTTP traffic, not application logic.
nginx makes sense when a PHP application or API needs public HTTPS, multiple domains, static files, a separate application runtime or a shared entry point into a Docker environment. It keeps the database and internal workers off the public network while serving several applications from one place.
A small application on a managed platform may already have a provider-managed proxy, and extensive custom configuration would merely create another source of errors. Complex business conditions, external API calls and long imports should not be moved into nginx either; they belong in an application service or worker.
What to consider
Operational rules should be specific, measurable and minimal.
A good configuration first reduces public exposure and only then adds caching, limits or more complex routing.
- define a clear server_name, TLS configuration and expected redirects for each domain
- publicly expose only static directories intended for clients, not the entire project tree
- forward the required headers to the application and trust forwarded headers only from your own proxy chain
- configure timeouts, body limits and buffering according to the endpoint type and real operational data
- cache only responses that can be shared and invalidated safely
- monitor status codes, upstream response time and proxy errors separately from application logs
Common questions
What nginx does between a client and application
Is nginx an application framework?
No. It is a web server and proxy for HTTP traffic. Application routes, input validation and business rules remain in application code.
Does every application need its own nginx?
Not necessarily. A managed platform, load balancer or another proxy may already provide this role in front of the application. It depends on who owns the HTTP and TLS boundary.
Can an application safely trust X-Forwarded-For?
Only if the web server removes the client-supplied value and sets it itself, or if the application trusts only the known IP addresses of its own proxies.
Does nginx rate limiting secure the application?
It helps reduce traffic at the HTTP boundary but does not replace authentication, authorization, input validation or protection against flaws in application logic.
How I design application operations
I separate the public HTTP entry point from the application and its internal services.
For backends, I coordinate the application, database, cache, workers and integration services so the network boundary is clear and operations remain traceable.