Web Servers & Reverse Proxies
Apache httpd: The Original Web Server, Still Earning Its Place
Apache httpd powered three decades of the web, and the Apache Running After Maturity era is real: the event MPM made mod_php-class workloads concurrent, modules cover everything from authentication to server-side caching, and .htaccess keeps shared hosting manageable. Its stereotype is outdated in performance terms but accurate in trade terms, and knowing the tradeoffs keeps Apache a legitimate option rather than an apology.
Key points
- The event MPM is the modern platform: a fixed pool of worker threads feeds keep-alive connections asynchronously, which is why current Apache no longer collapses under concurrency like old prefork benchmarks; prefork is only right for non-thread-safe modules and remains a deliberate exception.
- The module surface is the feature: mod_ssl, mod_security (the standard WAF), mod_rewrite, mod_proxy plus balancer fans, and authentication modules for every era; modules can be compiled in or loaded with a2enmod-class tooling with per-host overrides, which is why shared hosting still runs Apache first.
- .htaccess is a two-edged cultural feature: directory-level override puts full configuration power in users' hands (per-site redirects, PHP flags, security madness), but each request pays filesystem-lookup and parse cost; where performance matters and rules are stable, move htaccess rules into the server config.
- Reverse proxying is real but secondary: mod_proxy/AJP and mod_pagespeed-class options exist, though for edge work nginx/caddy/traefik-class proxies usually win; the common modern shape is Apache behind a faster front for legacy app estates (and WordPress shared hosting, where htaccess is load-bearing).
- Field-tested configuration discipline: apachectl configtest after changes, separate virtual hosts per site, modsecurity not just installed but ruleset-tuned (Paranoia Level 1 defaults), mod_evasive/limitreq-style modules for flood handling, and logging errors plus access with rate fields for the log analysis layers.
- The honest verdict in 2026: Apache is a superb application server and a mediocre edge proxy; run it where its modules and directory overrides carry the workload, front it with a lean reverse proxy when scale needs it, and never let htaccess scans go unmonitored (they are a persistent exploitation surface on shared hosting).
Field note
A WordPress hosting estate we took over ran Apache with 1,700 .htaccess files across sites, some of them contradictory. We moved stable rules into vhost configs, kept per-site overrides where owners needed them, and the shared host's p99 latency dropped by a third without buying anything.
Frequently asked questions
Do we even still run Apache in 2026?
Yes, and for good reasons: the .htaccess ecosystem (WordPress/Drupal-class shared hosting), mod_security maturity, and module coverage for legacy stacks. Replacing it wholesale is a workload decision, not a fashion one.
Which MPM should we run?
Event for anything modern, prefork deliberately for legacy non-thread-safe modules (some PHP extension stacks and older libraries); worker is mostly history at this point. Measure your own traffic after any MPM switch.
Is .htaccess bad?
Not 'bad', it costs performance per request and widens the attack surface in shared hosting, but it is the entire reason shared hosting works at all; the discipline is moving stable rules up to vhost config and watching directory-level overrides.
How does mod_security fit the security stack?
It is the most widely deployed open WAF layer, excellent at filtering obvious exploit classes (SQLi patterns, path traversal, admin probes) but noisy without tuning; pair it with logs and per-site rule exceptions (see our firewall-configuration article for the server-side complement).
How Kinetikatech helps with web servers & reverse proxies
We've handled this hundreds of times: The programs that accept connections and decide how requests flow: nginx, Apache, LiteSpeed, Caddy, and Traefik, plus the configuration habits that make them fast, cached, and hard to take down. With Website Speed Optimization and Server Management, you get the full loop, we assess, we implement, we watch it around the clock, and we pick up within 30 minutes when it matters.