Glossary
Web server
A web server is the HTTP boundary of an application: it handles static files, domains, TLS and request routing. The backend behind it makes decisions about users, orders and data.
Short definition
Software for the public HTTP entry point, not application business logic.
A web server evaluates an incoming HTTP request according to its domain and path. It can return CSS, JavaScript and images directly from a public directory. For dynamic content, it usually forwards the request to PHP-FPM over FastCGI or to another internal HTTP service as a reverse proxy.
A web server is neither a physical computer nor a synonym for the backend. nginx and Apache are specific implementations. One server can serve multiple domains and can run in Docker or directly on an operating system.
The problem it solves
It controls HTTP traffic in front of the application
A web server separates the public network entry point from the application runtime, workers and databases.
- accepting HTTP and HTTPS connections for a website, administration interface and API
- delivering static files with the correct MIME type
- forwarding PHP requests to PHP-FPM over FastCGI
- acting as a reverse proxy for an internal HTTP application or API
- handling domains, redirects, operational logs, limits and basic caching
Practical example
A public entry point for a PHP application through nginx
The configuration has an explicit public document root and routes application requests through a single front controller. It therefore does not allow arbitrary PHP files in the project or user-uploaded files to be executed.
This example is not a complete production configuration. TLS settings, limits, health checks and trusted proxy addresses must match the specific infrastructure, while the application must perform its own authentication and authorization checks.
server {
listen 443 ssl;
server_name shop.example.cz;
root /var/www/shop/public;
location /assets/ { try_files $uri =404; }
location / { try_files $uri $uri/ /index.php?$query_string; }
location = /index.php {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}
How it works
From an HTTP request to a response
Text diagram: client → web server → PHP-FPM or internal service → application → response to the client.
- The client sends a request A browser or API client addresses a domain, path and method over HTTP or HTTPS.
- The server selects the configuration Based on the host and URL, it selects a virtual host or server block and the appropriate location rule.
- Static or dynamic content It returns static assets directly, forwards PHP over FastCGI and can contact an internal HTTP service as a proxy.
- The application decides The backend evaluates identity, permissions, validation and business rules, and accesses the data.
- The server returns a response It records operational information and passes the response status, headers and content to the client.
Important parts
Files, routing and trusted infrastructure.
A web server creates a technical boundary but does not take over the meaning of application data.
Document root and MIME types
Only explicitly public files belong in the document root. Configuration, source code and sensitive uploads must not be publicly served.
FastCGI and PHP-FPM
PHP-FPM is not an HTTP server. The web server passes it a request over FastCGI, and PHP-FPM executes the application code.
TLS and redirects
The server can terminate TLS, enforce HTTPS and add some headers. HTTPS does not replace application permissions, however.
Reverse proxy
Forwarding to an upstream is one server role. Proxy headers can be trusted only when they come through an explicitly known chain.
Logs and limits
Access and error logs, request size limits and timeouts support operations. A very long HTTP request is not a suitable model for an import.
Benefits and limitations
A correct HTTP boundary does not solve the entire security design.
Benefits
- efficient delivery of static files without running the application
- centralised domains, TLS, redirects and operational logs
- separation of the public entry point from the PHP runtime and database
- the ability to serve multiple applications behind one public entry point
Common mistakes
- publicly exposing PHP-FPM, a database or an internal worker
- executing every file with a PHP extension, including uploads
- trusting client-supplied X-Forwarded-* headers without verification
- moving order authorization or rules into the web server configuration
When it makes sense
For every HTTP entry point, with the scope of configuration varying.
A web server is a natural entry point for a PHP application, API or server-rendered website. A simple project may need only a few rules for the document root and PHP-FPM; a larger environment also needs monitoring, limits, a proxy topology and secure TLS.
An HTTP request should not be turned into a long-running worker, however. Imports, exports and extensive synchronisation are better accepted as jobs and processed outside the limited request pool.
What to consider
Public configuration should be narrow and verified.
Every boundary between a client, proxy and application needs explicitly defined trust and measurable limits.
- keep the document root separate from source code and secrets
- pass only the required FastCGI parameters to PHP
- configure TLS, HTTPS redirects and security headers in coordination with the application
- define trusted proxies and forwarded headers correctly
- monitor error rates, timeouts, request sizes and response statuses
Common questions
A web server without common misconceptions
Is nginx a web server?
Yes. It can also act as a reverse proxy, cache and load balancer, but web server is the broader term.
Is PHP-FPM a web server?
No. It manages PHP FastCGI processes; HTTP is typically accepted by nginx or another web server.
Does a web server manage user permissions?
It can add technical protection, but the backend must decide access to an order or API action from application rules and data.
Is a reverse proxy the same as a web server?
No. A reverse proxy is the role of forwarding requests to another server; a web server may or may not perform that role.
How I run backends
I separate the public HTTP entry point from the application, workers and data.
When designing PHP applications, I connect the web server, runtime, database and integration services so the system can be monitored and evolved safely.