Apache HTTP Server

Apache HTTP Server, often called httpd, accepts HTTP requests and produces HTTP responses. It can serve files, run content handlers, terminate TLS, and forward traffic to application backends.

The useful mental model is a modular request-processing engine. The core server handles the connection and coordinates the request. Loaded modules add capabilities at defined stages. Configuration directives decide which modules act, where they act, and which content or backend produces the response.

This model explains Apache httpd's range. One installation can host static sites, expose application handlers, enforce access rules, or work as a reverse proxy. It also explains the main operational risk: configuration from several scopes and modules can combine in ways you did not intend.

Where Apache httpd fits

Apache httpd sits between clients and content. A browser or API client connects to a listening address and port. The server selects a virtual host, maps the requested URL, applies the relevant configuration, and invokes modules or handlers. It then returns a status code, headers, and an optional body.

Common roles include:

• serving HTML, images, style sheets, and downloads from a document tree;
• hosting several DNS names on one server with virtual hosts;
• terminating TLS with mod_ssl;
• forwarding requests to application servers with mod_proxy;
• adding authentication, authorization, rewriting, compression, caching, and logging through modules;
• exposing server activity through a restricted mod_status endpoint.

Apache httpd is not an application runtime by itself. Dynamic content requires a handler, a gateway such as CGI or FastCGI, an embedded third-party module, or a separate application reached through a proxy.

The core, modules, and one MPM

The core contains only basic server functions. Modules provide most extended behavior. Some modules are compiled into the server. Others are dynamic shared objects loaded at startup with LoadModule.

You can inspect the active build instead of guessing:

httpd -l    # statically compiled modules
httpd -M    # loaded modules, including dynamic modules

Package maintainers may rename the binary or provide wrapper commands. Use your installation's service and package documentation when paths or command names differ.

One special module controls how the server accepts and dispatches work. This is the multi-processing module, or MPM. Exactly one MPM is active at a time.

• prefork uses child processes without worker threads. Its compatibility model matters when code is not thread-safe.
• worker uses child processes with multiple threads in each child.
• event builds on the threaded model and handles some connection work asynchronously, reducing the need to hold a worker thread for every connection.

The active MPM shapes concurrency, memory use, and tuning. MaxRequestWorkers limits the simultaneous requests the server will serve. Treat an MPM change as an architectural decision, not a generic speed switch.

Configuration is scoped policy

Apache httpd reads plain-text configuration when it starts or restarts. The main file is commonly named httpd.conf, but its location and the surrounding file layout depend on how the server was built and packaged. Include and IncludeOptional can assemble the configuration from several files.

A directive is a name followed by arguments:

ServerName www.example.com
DocumentRoot "/srv/www/example"

Containers limit where enclosed directives apply:

<Directory "/srv/www/example">
    Require all granted
</Directory>

<Location "/health">
    Require all granted
</Location>

The distinction between these containers is fundamental:

• <Directory> and <Files> match filesystem objects.
• <Location> matches URL space, even when no file exists.
• <VirtualHost> selects policy for one site or listener identity.
• <Proxy> applies policy to proxied resources.

Use filesystem containers to protect filesystem content. A URL can map to a file through more than one route, so a <Location> restriction alone may not protect that file.

Configuration sections are merged in a defined order. Later processing can modify or override earlier results. A request may therefore receive policy from the main server, a virtual host, directory sections, files sections, location sections, and module-specific rules. When behavior surprises you, trace the scopes that match the request before changing directives.

Virtual hosts choose the site

A virtual host lets one server present more than one site. Name-based virtual hosts share an IP address and use the requested host name to distinguish sites. IP-based virtual hosts use separate addresses.

A representative name-based virtual host looks like this:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    DocumentRoot "/srv/www/example"
    ErrorLog "logs/example-error.log"
    CustomLog "logs/example-access.log" combined

    <Directory "/srv/www/example">
        Require all granted
    </Directory>
</VirtualHost>

ServerName identifies the primary name. ServerAlias adds alternate names. DocumentRoot selects the default file tree for that virtual host.

Use apachectl -S or the equivalent httpd -S invocation to see how the server parsed addresses, ports, and names. This is more reliable than reading one file while overlooking an included definition.

From URL to response

For ordinary static content, Apache httpd appends the request's URL path to DocumentRoot. If the document root is /srv/www/example, a request for /images/logo.svg maps to /srv/www/example/images/logo.svg before other mapping rules change the result.

Modules can replace that default mapping:

• mod_alias maps a URL prefix to another filesystem location or sends a redirect;
• mod_rewrite transforms requests using rules and conditions;
• mod_proxy maps a URL to a backend server;
• handlers generate content without a corresponding static file.

Prefer the narrowest feature that expresses the job. Use Redirect for a straightforward redirect and Alias for a straightforward path mapping. Reach for rewrite rules when matching or transformation truly requires them.

Main configuration and .htaccess

.htaccess files provide per-directory configuration without access to the main server configuration. Apache httpd reads them during requests when AllowOverride permits them.

If you administer the server, put policy in the main configuration. It is read at startup, easier to audit, and avoids per-request directory searches. Reserve .htaccess for delegated environments where content owners need limited control. If delegation is required, grant only the override categories or individual directives they need.

TLS and reverse proxying

With mod_ssl, an HTTPS virtual host listens on a TLS port, enables the SSL engine, and references a certificate and private key:

Listen 443
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile "/path/to/www.example.com.cert"
    SSLCertificateKeyFile "/path/to/www.example.com.key"
</VirtualHost>

This is the minimum shape, not a complete production TLS policy. Certificate automation, supported protocol versions, cipher policy, revocation handling, private-key protection, and renewal monitoring require explicit operational ownership.

With mod_proxy, Apache httpd can forward selected requests to a backend:

ProxyPass "/app/" "http://app.internal:8080/"
ProxyPassReverse "/app/" "http://app.internal:8080/"

ProxyPass maps incoming requests to the backend. ProxyPassReverse rewrites relevant redirect headers from that backend so clients continue to address the public proxy. Proxying does not remove the need to set timeouts, preserve the intended client and host information, restrict administrative endpoints, and monitor backend health.

Operate from evidence

Test configuration syntax before every reload:

apachectl configtest
apachectl -t

A graceful restart checks the configuration and asks existing workers to finish open connections while replacement workers take over:

apachectl graceful

The exact service command may differ on your platform. The invariant is the workflow: test, apply through the supported control path, then inspect logs and traffic.

Start troubleshooting with the error log. ErrorLog chooses its destination, while LogLevel controls severity and can raise detail for one module. The access log records processed requests through CustomLog and LogFormat.

mod_status can report active and idle workers, traffic counters, uptime, and current activity. Its status endpoint exposes operational detail, so restrict access rather than publishing it as an open dashboard.

Security and operational limits

Apache httpd is one layer in a service, not the whole security boundary. Keep the server, modules, application code, and operating system updated. Protect the executable, configuration, and log directories from untrusted writes. Run request-serving children under an unprivileged account.

Set resource limits from measured workloads. Request timeouts, keep-alive timeouts, request-size limits, and MaxRequestWorkers can reduce resource exhaustion. Values that are too tight can also reject legitimate clients or exhaust application capacity elsewhere.

Load only the modules you need. Every active module adds behavior and may add directives, handlers, or exposed endpoints. Treat third-party modules as executable code in the server process.

Apache httpd's flexibility is also its main limit. A configuration assembled from many includes, overrides, modules, and overlapping sections can become difficult to reason about. For a narrowly defined static or proxy role, a simpler server may reduce operational surface. Apache httpd is a strong fit when its module ecosystem, per-directory delegation, or mixed serving roles solve a real requirement.

A path to working competence

1. Identify the binary, active MPM, loaded modules, configuration root, and log destinations on your platform.
2. Read the effective includes and map each directive to its scope.
3. Configure one static virtual host and verify host selection with the parsed virtual-host report.
4. Trace one URL from virtual-host selection through mapping, access control, handler selection, and logging.
5. Add TLS in a test environment and define certificate renewal ownership.
6. Proxy one path to a test backend and verify redirect, timeout, and failure behavior.
7. Test a broken configuration, confirm the test catches it, then practice a graceful reload with a valid change.
8. Build dashboards and alerts from access logs, error logs, server status, and external probes.
9. Study section merging, the active MPM, and the exact modules used by your production role.