What is Apache HTTP Server?

Apache HTTP Server (officially called httpd, short for “HTTP daemon” — a daemon is a program that runs quietly in the background) is one of the oldest and most widely deployed web servers in the world. A web server is the program that listens for browser requests and sends back web pages, images, and data. Apache has been around since 1995, and even though Nginx now gets more attention, Apache still powers a huge slice of the internet — especially shared hosting and older applications. Understanding it is essential because you will run into it constantly on real Linux servers.

Why Apache still matters

Apache’s biggest selling point is flexibility. It was designed to be configured in lots of different ways, and it lets each website (and even each folder) override settings on its own. That makes it the default choice for shared hosting providers, where hundreds of customers run sites on one machine and each needs to tweak their own behaviour without touching the main server config.

It is also the server that most legacy (older, already-built) applications expect — think classic WordPress setups, older PHP apps, and software written for the “LAMP stack” (Linux, Apache, MySQL, PHP). If you inherit an existing project, there is a very good chance Apache is already serving it.

When to use Apache: shared hosting, legacy LAMP/PHP apps, situations where you need per-directory configuration that non-admin users can edit, or any app whose docs assume Apache.

When NOT to use it: brand-new high-traffic sites serving mostly static files or acting purely as a reverse proxy — there, Nginx is usually lighter and faster. See Nginx vs Apache together for how teams often combine both.

The module system

Apache’s core is small. Almost every feature — rewriting URLs, SSL/TLS encryption (the padlock in your browser), compression, proxying — is added through modules. A module is a plug-in that switches a capability on. This keeps Apache lean: you load only what you need.

On Ubuntu you manage modules with two helper commands, a2enmod (“Apache 2 enable module”) and a2dismod (“disable module”). For example, to turn on the URL rewriting module:

sudo a2enmod rewrite
sudo systemctl restart apache2

Output:

Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2

You can list every module currently loaded:

apache2ctl -M

Output:

Loaded Modules:
 core_module (static)
 so_module (static)
 mpm_event_module (shared)
 authz_core_module (shared)
 rewrite_module (shared)
 ...

A few modules you will meet often:

Module	What it does	When you need it
`rewrite`	Rewrites and redirects URLs	Pretty URLs, forcing HTTPS
`ssl`	Adds HTTPS / TLS encryption	Any production site
`proxy` + `proxy_http`	Forwards requests to another app	Reverse proxy to Node/Python
`headers`	Add or change HTTP headers	Security headers, caching
`deflate`	Compresses responses (gzip)	Faster page loads

Modules are covered in depth in Apache modules.

.htaccess — per-directory config

This is Apache’s signature feature. A .htaccess file (the dot makes it hidden) is a small config file you drop inside any web folder. Apache reads it on every request and applies whatever rules it contains — redirects, password protection, blocking certain files — only to that folder and the folders beneath it.

The huge advantage: you can change a site’s behaviour without editing the main server config and without restarting Apache. That is exactly why shared hosting loves it — customers can manage their own rules in their own folder.

A tiny example that forces every visitor onto HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Performance gotcha: .htaccess is convenient but slow. Apache checks for these files in every directory on every request. On a busy site you own outright, put the same rules in the main config and turn .htaccess off with AllowOverride None. Reserve .htaccess for shared hosting where you have no other choice.

Full details live in Apache .htaccess.

The process / MPM model

How does Apache handle many visitors at once? Through an MPM — a “Multi-Processing Module”. This is the part of Apache that decides whether each connection gets its own process, its own thread, or a mix. You pick one MPM; they are mutually exclusive.

MPM	How it handles requests	Best for
`prefork`	One separate process per connection, no threads	Old non-thread-safe code (classic `mod_php`)
`worker`	Several processes, each with many threads	General use, lower memory than prefork
`event`	Like worker, but keeps idle connections cheap	The modern default for most sites

Ubuntu 22.04 and 24.04 ship with the event MPM enabled by default, which is the right choice for almost everyone. The main reason to switch back to prefork is running PHP the old way through mod_php, which is not thread-safe (it cannot safely share threads). The modern fix is to run PHP through PHP-FPM instead, which keeps you on the faster event MPM.

Check which MPM is active:

apache2ctl -M | grep mpm

Output:

 mpm_event_module (shared)

Where Apache lives on Ubuntu

On Ubuntu the package and service are called apache2, not httpd (that is the Red Hat / CentOS name — worth knowing for interviews). Here are the paths you will use constantly:

Path	What it holds
`/etc/apache2/apache2.conf`	The main config file
`/etc/apache2/sites-available/`	Available site configs (virtual hosts)
`/etc/apache2/sites-enabled/`	Symlinks to the sites currently switched on
`/etc/apache2/mods-available/`	All installable modules
`/var/www/html/`	Default web root (where your files go)
`/var/log/apache2/`	Access and error logs

A virtual host (or “vhost”) is how one Apache server hosts many different websites on the same machine — covered in Apache virtual hosts.

Best Practices

Prefer the event MPM and run PHP via PHP-FPM, not mod_php, for better performance.
Only enable the modules you actually use — every loaded module adds memory and attack surface.
On servers you control, set AllowOverride None and move .htaccess rules into the main config to avoid the per-request lookup cost.
Always test config changes with sudo apache2ctl configtest before restarting, so a typo never takes your site down.
Allow web traffic through the firewall explicitly with sudo ufw allow 'Apache Full' rather than disabling the firewall.
Use systemctl reload apache2 (graceful) instead of restart for config changes — it avoids dropping live connections.
Keep Apache patched with sudo apt update && sudo apt upgrade on a regular schedule; web servers are a common target.

What is Apache HTTP Server?

Why Apache still matters

The module system

.htaccess — per-directory config

The process / MPM model

Where Apache lives on Ubuntu

Best Practices

Related Topics