What Happens on the Server When a Web Request Arrives

Your website and eleven others can share one IP address. A browser opens a connection to that address and says almost nothing about who it is looking for. One program on that machine then has to decide, in a couple of milliseconds, which of the twelve sites the visitor actually wanted, which certificate proves it, which directory to read from, and whether to answer the request itself or hand it to something else. It gets this right so reliably that almost nobody asks how.

This article picks up where what actually happens when you enter a URL hands off. That article follows the request out of the browser and across the network, and treats the server as one step. This one opens that step. It covers what a web server actually is, how one machine answers for many domain names, why the certificate and the site are chosen by two different mechanisms that can disagree, how the request reaches your application, and how to read the error when it does not. Every command output below is real: the local runs on a local Apache 2.4.66 with PHP-FPM 8.3.26 and a purpose-built nginx 1.29 configuration you can rebuild in a minute, both on 16 September 2026, and the runs against the live server behind petermartin.nl re-measured on 17 September 2026 after its virtual host configuration changed.

DNS gets you to the machine. The Host header gets you to the site. They are not the same step, and that is where most of the confusion lives.

Goal: after reading this you can explain why one IP address can serve a hundred sites, predict which one answers when something goes wrong, and tell from a single response header which layer produced it.

2. Where the Names Come From

Four words in this article carry history that explains the behaviour.

2.1 Server

The word names a role in the client/server model, not a box. RFC 9110 defines it as a program, and adds that a program can be a server on one connection and a client on another. That is not a technicality: a reverse proxy is exactly this, a server to the browser and a client to your application, which is why section 6.5 exists.

2.2 httpd, and the Letter d

Apache's binary is called httpd. The d is for daemon, the Unix word for a program that runs in the background with no terminal attached. The Apache Software Foundation's own history page uses exactly that phrase for the software Apache grew out of: "the public domain HTTP daemon developed by Rob McCool at the National Center for Supercomputing Applications". Thirty years later the name still tells you how to find the process.

2.3 Virtual Host

A host was a machine. Calling something a virtual host was a deliberate contradiction: it is one of several websites pretending, to the outside world, to be a machine of its own. The phrase entered the standards when HTTP/1.1 made it possible. Section 19.5.1 of RFC 2068, from January 1997, is titled "Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses", which is the whole motivation in one heading: addresses were scarce, sites were not.

2.4 Document Root

The directory a site's files are served from, and the boundary the server refuses to cross. Everything above it on the filesystem is invisible to the web by design. When a misconfiguration exposes a database password, it is usually because a file that should sit above the document root was placed inside it.

2.5 Origin Server

RFC 9110 reserves a separate term for the machine that actually holds the truth: "The term 'origin server' refers to a program that can originate authoritative responses for a given target resource." Caches, CDN edges and proxies answer on its behalf. The distinction matters the moment you deploy a change and cannot see it.

4. One Site on One Server

Start with the simplest case: one domain, one document root, static files.

4.1 From Path to File

The server takes the request path, appends it to the document root, and looks for what it finds there. Nothing more clever than that:

document root   /var/www/example.com/public
request path    /images/logo.png
file opened     /var/www/example.com/public/images/logo.png

Two rules fill the gaps. If the path names a directory, the server tries a list of index files in order (index.html, then index.php, in a typical configuration) and serves the first one that exists. If nothing matches, it either lists the directory, refuses with 403, or sends the request to a rewrite rule that turns it into something an application understands.

That last case is how every CMS works. There is no directory called /en/focus-on/web/ on the server behind this page: a rewrite rule sends the whole path to a single front controller, which reads it as a route.

4.2 A Static File, Answered by the Server Itself

Here is a real static response from the local Apache used for this article:

$ curl -skI https://local.test.nl/media/system/js/core.js
HTTP/1.1 200 OK
Date: Wed, 16 Sep 2026 15:40:07 GMT
Server: Apache/2.4.66 (Unix) OpenSSL/3.5.5
X-Content-Type-Options: nosniff
Last-Modified: Tue, 18 Aug 2026 15:10:00 GMT
ETag: "66c7-65953ae330200"
Accept-Ranges: bytes
Content-Length: 26311

Last-Modified, ETag, Content-Length and Accept-Ranges are all facts the server read off the filesystem. It knows the size before it starts, it knows when the file changed, and it can serve a byte range out of the middle of it. That is why static files are cheap: there is nothing to decide.

4.3 What the Server Refuses to Do

The document root is a boundary, and the server enforces it before anything else looks at the path. Two attempts against the nginx test configuration from section 5.2:

$ curl -s -o /dev/null -w '%{http_code}\n' --path-as-is \
      -H 'Host: alpha.example' 'http://127.0.0.1:18080/../../etc/passwd'
400

$ curl -s -o /dev/null -w '%{http_code}\n' \
      -H 'Host: alpha.example' 'http://127.0.0.1:18080/%2e%2e%2f%2e%2e%2fetc/passwd'
400

Note the second one. The dots are percent-encoded, so the traversal is invisible until the path is decoded. The server decodes first and normalises second, which is why the encoded form fails in the same way. Directory traversal bugs are almost always a case of an application doing its own path handling and skipping that order.

4.4 Which Layer Answered? Read the Headers

Two requests for two files that do not exist, on the same server, in the same second:

$ curl -skI https://local.test.nl/nope.txt | head -3
HTTP/1.1 404 Not Found
Date: Wed, 16 Sep 2026 15:40:19 GMT
Server: Apache/2.4.66 (Unix) OpenSSL/3.5.5

$ curl -skI https://local.test.nl/nope.php | head -4
HTTP/1.1 404 Not Found
Date: Wed, 16 Sep 2026 15:40:19 GMT
Server: Apache/2.4.66 (Unix) OpenSSL/3.5.5
X-Powered-By: PHP/8.3.26

Same status code, two completely different journeys. The first 404 was decided by Apache, which looked for a file and did not find it. The second was forwarded to PHP-FPM, which started PHP, which produced a 404 and stamped it with X-Powered-By.

That header is a free diagnostic. If it is present, your application ran. If a page is broken and X-Powered-By is missing, the request never reached your code and no amount of debugging the application will help.

4.5 Static Is Nearly Free, and Dynamic Is Not

Three requests each for a static file and a CMS page on the live server behind petermartin.nl, measuring time to first byte over the same connection, on 16 September 2026:

$ curl -s -o /dev/null -w '%{time_starttransfer}\n' https://petermartin.nl/URL

/media/system/js/core.js     0.132  0.105  0.085
/en/                         0.306  0.231  0.231

Both figures include DNS, the handshakes and the network round trip, so neither is server time on its own. The difference between them is what matters: about 145 milliseconds, and all of it is the application. The web server handed over a file in the first case and started a PHP process, a database connection and a template render in the second.

This is the single most useful comparison to run on a slow site. If static files are fast and pages are slow, the web server is fine and the application is the problem. If both are slow, look at the network or the machine.

4.6 A Rewrite and a Redirect Are Not the Same Thing

Two mechanisms change which resource answers, and they get confused constantly because they are configured in the same block of the same file.

A rewrite is internal. The server changes the path it works with and answers the original request. One request, one response, and the browser never learns it happened: the address bar still shows what the visitor typed. Every CMS depends on this, which is how /en/focus-on/web/ becomes /index.php without anybody seeing it.

A redirect is external. The server answers with a 301 or a 302 and a Location header, and that request is finished. The browser then starts a new one from the top, possibly with a new DNS lookup and a new connection, certainly with a new round trip.

rewrite    GET /news/my-article   →  server reads /index.php internally
           1 request, 1 response, the URL never changes

redirect   GET /old               →  301 + Location: /new
           browser starts again   →  GET /new
           2 requests, 2 responses, the URL changes

The practical difference is cost. A rewrite is free. A redirect is an entire extra round trip, which is why a chain of three of them can cost more than the page they lead to, and why turning a redirect into a rewrite is sometimes the cheapest performance win available.

6. Handing the Work to an Application

Everything so far returned a file or a fixed string. Real sites run code, and the web server does not run it.

6.1 The Interface Between Two Programs

A web server speaks HTTP. Your application speaks its own language. Between them sits an interface whose job is to turn one into the other, and the shape of it has barely changed since the first web servers learned to run programs.

RFC 3875, published in October 2004 to document what everybody was already doing, calls it "a simple interface for running external programs, software or gateways under an information server in a platform-independent manner". The server converts the request into named values - "meta-variables" in the RFC's language - and hands them over.

You have read those variables a thousand times without noticing where they came from:

REQUEST_METHOD    GET
QUERY_STRING      page=2&sort=name
SCRIPT_NAME       /index.php
SERVER_NAME       example.com
REMOTE_ADDR       203.0.113.55

In PHP those arrive as $_SERVER['REQUEST_METHOD'] and the rest. The names are CGI meta-variables from a specification older than most of the web, and they survive because every later interface kept them.

What changed is the plumbing. Classic CGI started a fresh process for every single request, which is correct, simple and slow. FastCGI keeps a pool of processes running and passes requests to them over a socket. PHP's implementation of that is FPM, the FastCGI Process Manager, and it is how most PHP is served today.

6.2 Two Process Trees, Not One

A server running PHP this way is two separate programs. They can be restarted separately, they fail separately, and they can run as different users. On the local stack used for this article:

$ ps -o pid,ppid,user,args        # in the web server container
  PID  PPID USER     COMMAND
    1     0 root     httpd -DFOREGROUND
    8     1 daemon   httpd -DFOREGROUND
    9     1 daemon   httpd -DFOREGROUND
   10     1 daemon   httpd -DFOREGROUND
   92     1 daemon   httpd -DFOREGROUND

$ ps -o pid,ppid,user,args        # in the PHP container
  PID  PPID USER     COMMAND
    1     0 dockerus php-fpm: master process (/usr/local/etc/php-fpm.conf)
    7     1 dockerus php-fpm: pool www
    8     1 dockerus php-fpm: pool www

Each tree is a parent that manages and children that work. Apache's parent runs as root here because binding to port 443 requires it, and hands every request to an unprivileged child. PHP-FPM needs no privilege at all in this setup and runs entirely as an ordinary user, parent included. The pattern is deliberate in both cases: if a worker is compromised, it is not root.

Now the arithmetic, which is where sites fall over. Two pool www processes were running at that moment, but that is the starting size rather than the limit. The pool in this configuration is:

pm                   = dynamic
pm.start_servers     = 2      # how many exist when nothing is happening
pm.max_children      = 5      # the actual ceiling
pm.min_spare_servers = 1
pm.max_spare_servers = 3

So this server runs at most five PHP requests at a time. A sixth visitor does not get an error; the request waits in a queue until a worker is free. If that queue fills too, the connection is refused and the web server turns it into a gateway error, which is section 6.4. This is the most common cause of a site that is fine at 10 visitors and unusable at 30, and no amount of database tuning fixes it, because the requests never reach the database. The numbers above are a development default - a production pool is sized against the memory a single request uses, not guessed.

6.3 What "The Site Is Down" Usually Means

Stop PHP-FPM and leave the web server running. Here is what a visitor sees:

$ docker stop phpfpm

$ curl -skI https://local.test.nl/media/system/js/core.js | head -2
HTTP/1.1 200 OK                      # static files: perfectly fine
Date: Wed, 16 Sep 2026 15:40:27 GMT

$ curl -skI https://local.test.nl/en/ | head -4
HTTP/1.1 500 Proxy Error             # anything dynamic: gone
Date: Wed, 16 Sep 2026 15:40:27 GMT
Server: Apache/2.4.66 (Unix) OpenSSL/3.5.5
Connection: close

The web server is up. It accepted the connection, negotiated TLS, matched the virtual host, found the file, and served it. Only the handoff failed, and the error log says precisely that:

[proxy:error] AH00898: DNS lookup failure for: phpfpm returned by /index.php

Which is worth reading twice, because it is a good example of an error message telling the truth in an unhelpful way. Nothing is wrong with your site's DNS. The web server could not resolve the internal name of its own PHP backend, because the container serving that name had stopped.

The lesson generalises. "The site is down" almost never means the web server is down. It means one of the things behind it is, and the status code tells you which.

6.4 502 and 504 Are Two Different Sentences

When the backend fails, the error depends on how it failed. A purpose-built nginx with two broken routes makes the difference visible - one pointing at a port where nothing listens, one at a backend that accepts the connection and then says nothing, with proxy_read_timeout 3s:

$ curl -s -o /dev/null -w '%{http_code}  %{time_total}s\n' http://.../dead/
502  0.000941s

$ curl -s -o /dev/null -w '%{http_code}  %{time_total}s\n' http://.../slow/
504  3.004037s

The elapsed time is the diagnosis. 502 came back in under a millisecond, because the connection was refused immediately: the backend is not running. 504 took 3.004 seconds, which is the configured timeout to three decimal places: the backend is running and is too slow, or is stuck.

nginx's error log names both causes without ambiguity:

connect() failed (111: Connection refused) while connecting to upstream
upstream timed out (110: Operation timed out) while reading response header from upstream

Do not memorise this as a rule across all servers. The measurement in 6.3 returned 500 Proxy Error from Apache for a failure that nginx would have called 502. The timing distinction holds everywhere; the exact code does not.

6.5 Behind a Proxy, Your Application Sees the Proxy

Put anything in front of your web server - a CDN, a load balancer, nginx in front of Apache, a container ingress - and the connection your application sees comes from that thing, not from the visitor. Two nginx configurations proxying to the same backend, which simply reports what it received:

# proxy_pass with nothing else configured
remote_addr       = 172.19.0.3        <- the proxy, not the visitor
x_forwarded_for   =                   <- empty
x_forwarded_proto =                   <- empty
host              = app               <- the UPSTREAM name, not the site

# the same proxy_pass, with three headers set
remote_addr       = 172.19.0.3
x_forwarded_for   = 172.19.0.1        <- the visitor
x_forwarded_proto = http
host              = correct.example   <- the site the visitor asked for

The three lines that fix it:

proxy_set_header Host              $host;
proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Every symptom of getting this wrong looks like an application bug:

• Every visitor has the same IP address in your logs and analytics. That address is the proxy.
• Rate limiting and brute-force protection lock out everybody at once, because to the application there is only one client.
• Canonical URLs, redirects and generated links point at an internal name like app, because the Host header was replaced.
• An infinite redirect loop on an HTTPS site. The proxy terminates TLS and speaks plain HTTP to the backend, so the application sees http, redirects to https, and the proxy sends it round again. X-Forwarded-Proto exists precisely for this, and the application has to be told to trust it.

RFC 7239 standardised all of this into one Forwarded header in June 2014, noting that the common practice was "non-standard header fields such as X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto". Twelve years on, the non-standard three are still what you will find in almost every configuration, alongside X-Forwarded-Host, which some setups use to carry the original hostname when the proxy overwrites Host with the upstream name instead of preserving it.

One warning: these headers are supplied by whoever connects. A client can send X-Forwarded-For: 1.2.3.4 directly and your application will believe it unless the proxy overwrites the header and the application only trusts it from known proxy addresses. Treat an unfiltered X-Forwarded-For as user input, because that is what it is.

6.6 The Cost of Per-Directory Configuration

Apache can be configured from files inside the document root. It is the feature that made shared hosting usable, because a customer with no server access can still write rewrite rules, and it is the reason .htaccess exists in every Joomla and WordPress install.

It is not free, and Apache's own documentation says so:

When AllowOverride is set to allow the use of .htaccess files, httpd will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested.

And it does not look in one directory, it walks the whole chain. For a file in /www/htdocs/example, the documentation lists four lookups that happen on every single request, "even if none of those files are present":

/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess

nginx has no equivalent and never will, which is the single largest architectural difference between the two. Directives live in the main configuration, are read once at startup, and cost nothing per request. The trade is flexibility for speed, and it is why moving a site from Apache to nginx means porting its .htaccess rules by hand.

If you control the main configuration, move the rules there and set AllowOverride None. If you are on shared hosting, you cannot, and that is the honest price of the convenience.

8. Best Practices

• Configure a default virtual host deliberately. Give it a blank page or a 404 and no site content. If you skip this, one of your real sites becomes the catch-all for every scanner and every misconfigured domain pointed at your address.
• Test the bare IP address as well as the hostname. It is the fastest way to find out what your default site actually is, and whether your hardening reached it.
• Use curl --resolve to test before DNS moves. It sets DNS, SNI and Host together, so the whole request is realistic including the certificate check.
• Compare a static file against a page when a site is slow. If static is fast and pages are slow, stop looking at the web server.
• Read the elapsed time on a gateway error. Instant means refused, which is a dead process. Exactly the timeout means running and stuck, which is a different investigation.
• Check X-Powered-By, or whatever your stack sets, before debugging application code. If it is absent, the request never reached your application.
• Set Host, X-Forwarded-For and X-Forwarded-Proto on every proxy_pass, and configure the application to trust them only from your proxy's address.
• Count your PHP workers against your busiest minute. A pool of two serves two requests at a time no matter how fast the database is.
• Keep secrets above the document root. The boundary is enforced for free; a file placed inside it is one misconfigured handler away from being downloadable.
• Move .htaccess rules into the main configuration when you can, and set AllowOverride None. Apache's own documentation recommends it, and it removes a filesystem lookup per directory per request.
• Read the primary documentation rather than a tutorial. Virtual host selection is fully specified in Apache's name-based virtual hosts page and nginx's server names page, and the protocol rules behind them are in RFC 9110 and RFC 9112. All four are free and all four are shorter than the blog post you were about to read.

10. Summary

• A web server is a program, not a machine. RFC 9110 defines it as a role held for one connection, which is why a reverse proxy can be a server and a client at the same time.
• Every request is five decisions: which certificate, which site, which path, who produces the bytes, what goes back.
• The IP address stops mattering the moment the packets arrive. The hostname is carried in the request, not in the routing.
• SNI picks the certificate and the Host header picks the site. Measured on one live server, a request with the right SNI and the wrong Host was served by a different website, and a request with no SNI and the right Host was served correctly under the default site's certificate.
• Every server has a default virtual host, chosen deliberately or by accident, and it answers for the bare IP, unknown names and every scanner on the internet.
• The default site is the one your hardening misses. On the server measured here the Server header is suppressed everywhere, and the default site's built-in 404 page still signs itself openresty in the body. Hiding the header is not hiding the server.
• Static files are nearly free. On the live site a static file arrived in 85 to 132 ms and a CMS page in 231 to 306 ms over the same connection; the roughly 145 ms difference is entirely the application.
• A 404 with X-Powered-By and a 404 without it came from two different programs. That header tells you whether your code ran.
• "The site is down" usually means the application is down. With PHP-FPM stopped, static files still returned 200 and only dynamic pages failed.
• 502 is instant and 504 takes exactly the timeout - measured at 0.0009 s and 3.004 s against a 3-second limit. The clock is the diagnosis.
• Behind a proxy your application sees the proxy, including its hostname, unless three headers are set - and those headers are user input unless you filter them.
• An absolute-form request line overrides the Host header, by requirement, so host filtering that reads only the header is incomplete. On HTTP/2 and HTTP/3 the name travels as the :authority pseudo-header instead, and the two are "no longer permitted to disagree".
• The hostname is chosen by the client, and the server only routes on it. An application that builds password-reset links or canonical URLs from the incoming name is trusting a value anyone can set.
• A rewrite is internal and free; a redirect is a whole extra round trip. Same configuration file, completely different cost.
• PHP-FPM refuses to execute a file whose real extension is not PHP, which is the last line of defence against an uploaded image being run as code.
• Enabling .htaccess costs a filesystem lookup per parent directory per request, present or not, by Apache's own documentation.

THE FIVE DECISIONS  (in order, on every request)
 1 certificate   ├→ chosen by SNI, before encryption exists
 2 which site    ├→ chosen by Host: / :authority, after it
 3 which path    ├→ document root + path + index + rewrites
 4 who answers   ├→ a file, or an application behind FastCGI
 5 what goes out └→ status + headers + body

ONE IP, MANY SITES
DNS  name → address        then the name is GONE from the connection
TLS  SNI names the host     → picks the CERTIFICATE
HTTP Host: names the host   → picks the SITE
     they can disagree; nothing requires a server to cross-check
     HTTP/2 + HTTP/3: the name is the :authority pseudo-header
     └→ there, Host and :authority may NOT disagree (RFC 9113/9114)

  SNI          Host         certificate        site that answers
  site A       site A       site A             site A
  site A       unknown      site A             THE DEFAULT SITE
  (none)       site A       the default's      site A

DEFAULT VIRTUAL HOST  answers for:
  the bare IP address / unknown hostnames / no Host header
  nginx   listen 80 default_server;     (a listen param, NOT server_name)
  apache  the FIRST <VirtualHost> listed for that address:port
  └→ if you did not choose one, a real customer site is it

NAME MATCHING ORDER
  nginx   exact → longest *.name wildcard → longest name.* → first regex
  apache  best address:port → ServerName → ServerAlias → first listed

TESTING WITHOUT CHANGING DNS
  curl --resolve name:443:IP https://name/    sets DNS + SNI + Host  (use this)
  curl -H 'Host: name' http://IP/             sets the header only
  openssl s_client -connect IP:443 -servername name
  openssl s_client -connect IP:443            no SNI → the DEFAULT cert

WHICH LAYER ANSWERED?
  X-Powered-By present   your application ran
  X-Powered-By absent    it did not; stop debugging the code
  Server:                the web server - when it is not suppressed
  built-in error page    signs itself in the BODY; no header setting hides it
  bare IP vs hostname    compare them: the default vhost is a different config

WHEN THE BACKEND FAILS  (the clock is the diagnosis)
  502  instant              connection refused   → process is not running
  504  exactly the timeout  accepted, no answer  → slow query / stuck / pool full
  500  varies               app error, OR apache's proxy failure
  503  varies               deliberate: maintenance, rate limit, no worker free
  static file still 200?    the web server is fine; only the app is gone

BEHIND A REVERSE PROXY  (set all three, trust none of them blindly)
  proxy_set_header Host              $host;
  proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  missing Host   → links and canonicals point at the upstream name
  missing XFF    → every visitor shares one IP; rate limits lock out everyone
  missing XFP    → https redirect loop, because the app only ever sees http
  RFC 7239 standardised "Forwarded"; nobody uses it

A REQUEST IS JUST TEXT
  GET /en/ HTTP/1.1          origin-form: Host: decides the site
  GET http://b/ HTTP/1.1     absolute-form: the URL WINS, Host: is ignored
  no Host / invalid Host     400, before any site is selected
  the name is CLIENT-SUPPLIED: route on it, never build links from it
  └→ reset links + canonicals come from configured site URL, not Host:

REWRITE vs REDIRECT  (same config file, different cost)
  rewrite   /news/x → /index.php internally   1 request,  URL unchanged
  redirect  /old    → 301 + Location: /new    2 requests, URL changes
  └→ a 3-hop redirect chain can cost more than the page it leads to

SERVER-SIDE COSTS
  .htaccess     one lookup per PARENT DIRECTORY per request, present or not
  FPM workers   pool size = max concurrent PHP requests; the rest queue
  static file   size, mtime and range all come free from the filesystem

Verified 16 September 2026 against RFC 9110, RFC 9112, RFC 9113 and RFC
9114 (all June 2022), RFC 6066 (January 2011), RFC 3875 (October 2004),
RFC 7239 (June 2014), RFC 2068 (January 1997) and RFC 1945 (May 1996),
plus the Apache 2.4 and nginx documentation.
Measurements: the live server behind petermartin.nl (17 Sep 2026), a
local Apache 2.4.66 with PHP-FPM 8.3.26, and a purpose-built nginx 1.29
configuration (both 16 Sep 2026).

The next time a site returns the wrong page, or the wrong certificate, or a gateway error that nobody can reproduce, the question to ask is not "is the server up". It is which of the five decisions went somewhere unexpected - and when a visitor swears they reached a completely different company's website by typing your domain, they probably did: they found the default virtual host, and somebody never configured one.