Web Server

A web server is software, even though nearly everyone also uses the phrase for the machine. Strictly, it is a program bound to ports 80 and 443 that speaks HTTP: it accepts a request, works out which site and which path are being asked for, and returns a status code with a body. The hardware underneath is incidental, and a single virtual server will happily run one web server program answering for dozens of unrelated domains through name-based virtual hosts. Most real deployments chain two layers. At the front the web server does what it is genuinely excellent at: terminating the encrypted session, negotiating HTTP/2, reading static assets straight off disk, compressing responses, applying rate limits and rewriting paths. Anything dynamic is passed backwards over a socket to a separate process, PHP-FPM or a Node service or a pool of Python workers, whose output is passed back out to the visitor. That second role explains why nginx is so routinely described as a reverse proxy: it acts for the machines behind it rather than for the client in front of it. Which is why the choice people imagine they are making is usually not exclusive at all. Plenty of stacks run nginx at the front with Apache behind it, the first holding connections and certificates, the second honouring the per-directory rules an application expects, and neither one being the web server in any useful sense. The settings that decide what a visitor feels sit on whichever program is doing that part of the job, and they cost nothing to switch on: compression left off sends every page at full size, missing cache headers make returning visitors download assets they already hold, HTTP/2 unnegotiated puts requests back into single file, and an upload limit inherited from a default refuses an ordinary attachment. Misconfiguration gets expensive faster than that, too. A rule that hands out .env or the .git directory as plain text gives away credentials and the whole history of the codebase in one request, and a browsable directory publishes a folder nobody meant to share. Every item there is a line of configuration rather than an argument for changing product. It is also the first place to look when things break, because the access log holds every request alongside the response it received: a wall of gateway errors means the application process behind died or never started, while a wall of not-found responses means the rewrite rules did. The identical arrangement is running on shared hosting, assembled by somebody else, where the only part you can usually touch is a file of .htaccess rules.

Which program, and what for