What a web server actually does

A web server is a program that waits for requests and answers them. The two names you will meet most are Apache and Nginx, with a few others like LiteSpeed in hosting circles. For a plain request, such as a picture, the server finds the file on disk and sends it. For anything dynamic, it hands the work to another program and passes the answer back.

That sounds modest, and in one sense it is. But nearly everything that happens between a browser asking for a page and a page arriving passes through this program's configuration: which site a request belongs to, where its files live, which URLs are rewritten, which headers are attached, who is allowed in, and how the connection is encrypted. When a site misbehaves, this layer is often the one hiding the explanation.

What follows describes what the web server does, how it keeps many sites apart, how it works with PHP and the database, and how to read and test its configuration without breaking a live site.

Waiting, listening and answering

A web server spends most of its life listening on two network ports: 80 for plain HTTP and 443 for HTTPS. When a connection arrives, the server reads the request, works out what is being asked for, produces a response, and writes it back. Then it goes back to waiting, or serves the next request on the same connection.

How it handles many visitors at once is where the main designs differ. Older Apache setups gave each connection its own process or thread. Current Apache usually runs an event-based module, and Nginx was built around an event loop from the start: a few worker processes each juggle thousands of connections, doing work only when data is ready. For a visitor the difference is invisible. For a server with limited memory, it decides how many people can be served before it starts to struggle.

The server also does the tedious, essential parts of HTTP: reading headers, handling keep-alive so connections are reused, negotiating HTTP/2, compressing responses, and logging each request. It writes a line to the access log for every request it answers, which is one of the most useful facts about it. The log is a diary of everything your site has been asked for.

One server, many sites

A single machine usually hosts many websites. When a request arrives, the browser includes the hostname it asked for. The server looks that name up in its configuration, where each site is described by a block called a virtual host (Apache) or server block (Nginx), and serves the matching folder. That is how thousands of domains can share one IP address.

For HTTPS there is a catch. The hostname is inside the encrypted request, but the server needs to choose the right certificate before decryption. The browser therefore sends the name early, in the TLS hello, as the server name indication. The server picks the certificate for that name, and later reads the same name from the request to choose the site. If a request names something the server does not recognise, it falls back to a default block, often the first one defined. That is why a mistyped or new domain pointing at the right IP sometimes shows somebody else's site or a placeholder page.

A minimal server block in Nginx looks like this:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.php index.html;

    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
}

And the Apache equivalent:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/public
    SSLEngine on
    SSLCertificateFile    /etc/ssl/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/example.com/privkey.pem
</VirtualHost>

Static files and dynamic pages

When the request is for a file that exists, such as an image, a stylesheet or a PDF, the server maps the URL path onto the site's folder, checks that the file is readable, works out its type from the extension, and sends it with the right headers. This is the fast case. A decent server can send thousands of such files a second from one core.

When the request is for a PHP script, the server does not run the code itself. It passes the request to a PHP process and waits for the result. On modern setups this is PHP-FPM, a pool of PHP workers the web server talks to over a local socket. In the older Apache arrangement, PHP ran inside the web server's own processes. Splitting them lets the web server stay small and fast while PHP workers are sized and restarted separately, and it allows each account on a shared server to run its own pool with its own limits.

The PHP script loads WordPress or whatever application it belongs to, which asks the database for content, assembles the page and returns it. The web server relays that back to the browser. The number of PHP workers, not the web server, usually sets the ceiling on how many dynamic pages can be built at once. When all workers are busy, new requests wait in a queue, and when the queue overflows or times out, visitors see 502, 503 or 504 errors.

Apache and Nginx, without the holy war

Apache is the old hand. It can read settings from .htaccess files inside your site's folders, which makes shared hosting flexible because customers can change behaviour without touching the main configuration. The price is a little speed, since the server checks for those files on each request. Nginx reads its configuration centrally, handles huge numbers of connections efficiently, and is often used as a front door that passes requests on to something else. Many setups combine them. For most small sites, the difference is invisible next to how the application is written.

None of this is a ranking. A tidy Apache with a page cache will outrun a careless Nginx setup. The better question is which one your host runs, since that decides where your rules go and what syntax they use. A rewrite rule from an Apache tutorial does nothing on Nginx, and vice versa, which is one of the most common sources of copy-and-paste failure.

Rules you will bump into

Rewrite rules turn pretty addresses into real scripts, which is how WordPress permalinks work. Headers tell browsers how long to cache a file. Access rules decide who can see which folder. Compression squeezes text before sending it. When a site misbehaves in a way that has nothing to do with the application, the cause is often a rule in this layer: a rewrite that loops, a header that caches too long, a permission that blocks a folder.

The standard block WordPress writes into .htaccess shows the idea:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

In words: if the requested path is not a real file and not a real directory, hand it to index.php, which looks at the URL and decides what to show. Nginx expresses the same thing with try_files $uri $uri/ /index.php?$args;.

A redirect rule is another everyday case, here sending the old address to a new one permanently:

Redirect 301 /old-page/ https://www.example.com/new-page/

The redirect generator writes these for both Apache and Nginx. The ordering of rules matters, since the first match usually wins, and a catch-all rule above a specific one will swallow it.

Logs: what the server remembers

Two files tell you most of what you need. The access log has one line per request, with the visitor's address, time, the request, the status code and the size. The error log records what went wrong, from missing files to PHP failures and configuration problems. On common Linux layouts they live here:

/var/log/nginx/access.log      /var/log/nginx/error.log
/var/log/apache2/access.log    /var/log/apache2/error.log    (Debian, Ubuntu)
/var/log/httpd/access_log      /var/log/httpd/error_log      (RHEL family)

A typical access log line looks like this:

203.0.113.7 - - [05/Oct/2026:09:14:02 +0000] "GET /blog/ HTTP/2.0" 200 18432 "-" "Mozilla/5.0 ..."

On shared hosting, the panel usually offers a log viewer or a download of raw logs, per site. Reading them for a few minutes after a problem tells you more than guessing. A burst of 404s for /wp-login.php from a single address is a bot. A line of 500s that begins at 14:02 points at the change you made at 14:01. The status code reference explains what each number means.

What changes by hosting type

On shared hosting, you do not touch the main configuration. You get a panel, a PHP version selector, and often .htaccess support, and the host manages the rest, including the web server's version and security settings. On a VPS or dedicated server, the web server is yours to install, configure and update, and that includes making sure certificates are renewed and logs do not fill the disk. Managed WordPress platforms usually run a tuned Nginx or similar stack and expose only the options that are safe, which is why some familiar tricks are unavailable there. With a CDN or reverse proxy in front, another web server sits between visitors and yours, so rules can be applied at either point, and a redirect set in both places is a standard loop.

Things people ask

Do I need to know which web server my host uses?

It helps. It tells you whether .htaccess rules will work, and which syntax any copied snippet needs. Response headers (the server line) often reveal it, though some hosts hide that.

Why did my .htaccess change do nothing?

Either the server is not Apache-compatible, the folder's settings do not allow overrides, or a cache is serving the old result. Test with a command line request, not just a browser.

Can a bad rule break the whole site?

Yes. A syntax error in .htaccess usually produces a 500 error for that folder and everything below it. Restore your backup copy and the site returns.

Is it safe to edit the configuration on a live server?

With care. Keep a copy, change one thing, run the syntax test, reload, then check the site and the error log. Pick a quiet time.