What Is the Apache Web Server?

Apache is the web server software that answers HTTP requests on a server you or your host controls, and it is free and open source under the Apache License 2.0. Apache is no longer the usage-share leader: W3Techs put it third on July 27, 2026, at 23.1% of all sites whose web server is known, behind Nginx (31.5%) and Cloudflare Server (29.0%) and ahead of LiteSpeed (15.1%). Share is not the same thing as a default, though. The web server you actually get depends on your operating system's packages, your hosting product, and the server image it was built from — so check yours rather than assume. And pick Apache for what it does: per-directory overrides, a large module library, embedded interpreters.

The Apache Group formed in February 1995 around a shared set of patches to NCSA's httpd, made its first public release (0.6.2) that April, and shipped Apache 1.0 on December 1, 1995. Within a year of the group forming, Netcraft's survey recorded Apache as the internet's #1 server. Members of that group created the Apache Software Foundation in 1999 to support the project, and the foundation still stewards it: the current stable release is 2.4.68, dated June 8, 2026.

One naming note first, because it decides which commands below you type. The program is httpd, and that is what Red Hat-family distributions (RHEL, Rocky, Fedora) call the binary, the service, and the config directory. Debian and Ubuntu package the same software as apache2 — apache2 binary, /etc/apache2, systemctl reload apache2. Same server, different packaging convention.

How Apache handles a request

Apache does not sit between the server and the browser — Apache runs on the server, and the client opens the connection. Here is the path a request takes on a typical Linux host.

1. Listen. Apache binds port 80 (HTTP) and port 443 (HTTPS) and accepts the incoming connection. A Multi-Processing Module does this part, and exactly one MPM is loaded at a time.

2. Pick the site. Apache matches the request's Host header against its VirtualHost blocks, which is how one IP address serves dozens of separate domains.

3. Map the URL to a file. The path is resolved under that virtual host's DocumentRoot: a request for /about.html on a typical hosting layout becomes /home/username/example.com/about.html.

4. Apply per-directory rules. Where AllowOverride permits it, Apache reads .htaccess in that directory and in every parent up to the DocumentRoot, on every single request, applying rewrites, redirects, and access rules. Apache has two configuration surfaces: the server-wide file (httpd.conf, or apache2.conf on Debian and Ubuntu) that usually needs root, and .htaccess, the per-directory file you can edit on most shared plans.

5. Serve or hand off. Static files — .html, .css, .jpg — go straight from disk. A .php request is handed to the configured handler, either mod_php in-process or PHP-FPM over mod_proxy_fcgi, which returns the generated HTML.

6. Respond and log. Apache returns a status code and body, writes a line to the access log, and either keeps the connection alive for the next request or closes it. One rule of thumb falls out of step 4: put settings in the main config when you can, because .htaccess is re-read on every request and each read costs latency.

Apache's Multi-Processing Modules and the RAM trade-off

An MPM is the component that binds the network ports, accepts requests, and dispatches child processes or threads to handle them. It is not a reliability feature, and the MPMs are not additive: exactly one is loaded at a time. What an MPM buys you, per the Apache documentation, is cleaner support across operating systems and the ability to tune the concurrency model to the site.

prefork — one process per connection, no threads. Choose it when you must run code that is not thread-safe, which historically means mod_php.

worker — threads inside a small number of processes, so far less memory per connection.

event — worker plus a dedicated listener thread that parks keep-alive connections, so idle sockets do not tie up a worker. On Unix-like systems that support threads and thread-safe polling (epoll or kqueue), event is the default, which the docs note means "almost always" on a modern OS. Windows builds use mpm_winnt instead.

The trade-off is memory against concurrency. Under prefork every child holds its own PHP interpreter, so the ceiling is RAM rather than CPU. Do the arithmetic for your own box: multiply MaxRequestWorkers by the resident memory of one Apache child, which ps -ylC httpd --sort:rss (or -C apache2) will show you. If 40 children each hold 30 MB, that is 1.2 GB committed and request 41 waits for a child to free up. That ceiling is exactly what Nginx's event loop was written to avoid. Check which MPM you are running with httpd -l (or apachectl -l), which lists the compiled-in modules including the MPM.

Apache vs. Nginx: how to choose

Choose between Apache and Nginx on features, because the share numbers no longer settle it — and the common third answer is to run both.

Choose Apache when you need .htaccess overrides you can edit without root access, an embedded interpreter such as mod_php, or a specific module from Apache's library — the project's own home page counts 100+ modules for rewriting, proxying, load balancing, and scripting.

Choose Nginx for high concurrency, static-heavy sites, or a memory-constrained server: its event loop holds thousands of open connections without dedicating a process to each one.

Run both with Nginx in front as a reverse proxy — terminating TLS, serving static files, absorbing slow clients — and Apache behind it on port 8080 running the application. That is the answer whenever your requirement list has items from both columns.

Apache trails Nginx by roughly eight percentage points of known-server share (23.1% versus 31.5%, W3Techs, July 27, 2026), which is a reason to compare features rather than a reason to migrate. For the deeper comparison — request handling, configuration, security, and performance under load — read NGINX vs. Apache.

Which Apache version you should be running

Run 2.4.x, because it is the only branch that still gets patches. The current stable release is 2.4.68, dated June 8, 2026, and the project describes the 2.4.x branch as the best available version. The 2.2 branch is end-of-life: its final release was 2.2.34 in July 2017, and the project states that no further patches, bug fixes, or security updates will be provided. W3Techs finds 99.8% of Apache sites already on version 2 (July 2026), so the real risk is not version 1 — it is an unpatched 2.2, or a 2.4 build nobody has updated in two years.

Check yours with httpd -v or apachectl -v (apache2 -v on Debian and Ubuntu). If it reports 2.2, plan the upgrade rather than dropping it in: 2.4 replaced the old Order, Allow, and Deny access directives with Require, and although the mod_access_compat module still accepts the old syntax, the project discourages mixing the two. And do not panic at a vendor version number that trails the project's — distributions backport security fixes, so a supported vendor build of an older 2.4.x is patched even when the number looks behind. An unmaintained build is not.

HTTP/2 today, no HTTP/3 yet

Apache 2.4 speaks HTTP/1.1 and HTTP/2, and nothing newer. HTTP/2 arrives through mod_http2 (RFC 7540), available in 2.4.17 and later, and it stays off until you enable it with a Protocols directive — the documented example for a TLS virtual host is Protocols h2 http/1.1. Pick your MPM with that in mind: prefork is not supported by mod_http2 (Apache logs "The mpm module (prefork.c) is not supported by mod_http2", and the project's HTTP/2 guide warns of severe restrictions there), so HTTP/2 and mod_php pull in opposite directions.

HTTP/3 (RFC 9114) was published in June 2022, and four years later no stable Apache release implements it — the feature list on the project's home page stops at HTTP/2 — while Nginx and Caddy both ship it. That is not a reason to rule Apache out, but it does dictate the architecture: if you want HTTP/3 for visitors, terminate it at a CDN or a reverse proxy in front of Apache, which keeps speaking HTTP/1.1 or HTTP/2 to the origin.

Where Apache runs, and how it runs your code

Apache runs on Linux distributions, Microsoft Windows, macOS, and most Unix-like systems. It is the A in the LAMP stack — Linux, Apache, MySQL, PHP — the combination many Linux hosting plans and tutorials still assemble by default, which is why Apache and PHP are almost always discussed in the same breath.

Apache does not run programming languages itself; modules and FastCGI do. Perl runs under mod_perl. Python runs under mod_wsgi or FastCGI — the ASF's own mod_python was retired to the Apache Attic and is unmaintained, so it is not a starting point. PHP runs either embedded through mod_php, which pins you to the prefork MPM, or as PHP-FPM behind mod_proxy_fcgi, which lets you keep event. Authentication is modular in the same way: mod_auth_basic for .htpasswd files, mod_auth_digest, mod_authnz_ldap for directory servers, plus database back ends.

The Apache name and the ASF's rebrand

The Apache Software Foundation says the name was chosen "from respect for the various Native American nations collectively referred to as Apache," and it has also acknowledged the pun on "a patchy" server — the project began as a set of patches to NCSA httpd. The foundation has since revisited that choice. In July 2024 it stated that as a non-Indigenous entity it is inappropriate for the foundation to use Indigenous themes or language, and retired its feather logo; on September 11, 2025 it unveiled an oak-leaf logo and adopted "The ASF" as its public shorthand.

What did not change is the software's name. The foundation kept its legal name and its project names, so Apache HTTP Server is still Apache HTTP Server, still shipped as httpd, and the Apache License 2.0 is unaffected.

Apache on DreamHost, and how to check which server answers for your site

DreamHost runs both Apache and Nginx, so the answer depends on the product. DreamPress, DreamHost's managed WordPress hosting, serves with Nginx rather than Apache — DreamHost moved DreamPress customers to Nginx in December 2023, and its caching layer is Nginx-based today. DreamHost VPS hosting and DreamHost Dedicated hosting can run either one: the panel switches a server between Apache and Nginx under Servers & Usage → Manage → Server Configuration, which DreamHost's knowledge base documents step by step.

Check any site in one command: run curl -I https://example.com and read the Server: response header. If it answers "cloudflare" or another CDN name, you are seeing the edge rather than the origin, so test a hostname that bypasses the CDN.

The answer matters most when you move hosts or plans, because Nginx ignores .htaccess completely. Redirects, IP blocks, and rewrite rules that lived in that file stop applying the moment Nginx is serving the site, and they have to be rewritten into the server configuration.

Common Apache failures, and the fix for each

HTTP 500 for a whole directory. One bad line in .htaccess — a typo, or a directive belonging to a module that is not loaded — makes Apache return a 500 Internal Server Error for that directory and everything beneath it, even for files the rule never touched. Fix: comment out your last edit, reload, then read the error log for the AH-numbered line that names the file and line number.

.htaccess rules silently ignored. Two usual causes: AllowOverride is None for that directory in the server config, so Apache never reads the file at all; or the site is not on Apache (run the curl check above). Nothing errors — the rules simply do not apply, which is why this one costs people an afternoon.

403 Forbidden. Usually there is no index file and directory listing is switched off, or the permissions are wrong: the user Apache runs as needs read access to the file and traverse access on every directory above it. Add the index file, or fix the ownership and modes — this walkthrough of 403 errors covers the WordPress-specific causes too.

Slow under real traffic, fast in testing. With prefork, each child carries its own interpreter, so concurrency is capped by memory and requests queue while the CPU sits idle. Fix in this order: cache so fewer requests reach PHP, move PHP to PHP-FPM and switch to the event MPM, then add RAM.

So where does that leave you? If you want per-directory control you can edit without root, stay on Apache and learn .htaccess. If you are fighting concurrency on a small server, read NGINX vs. Apache before you tune anything else. Either way, run curl -I against your own domain first — a good share of Apache troubleshooting ends with the discovery that you were never on Apache.