SadServers
  • Scenarios
  • Labs
    All Labs Linux & Bash Web Servers Databases Data Processing Docker Kubernetes CI/CD Infrastructure as Code Tooling / Applications
  • Dashboard
  • Solutions
    For Individuals For Businesses
  • Ranking
  • Newsletter
  • Documentation
    FAQ Support Pro Accounts Pro+ Accounts Business Accounts Gift API CLI/TUI Privacy Troubleshooting Interviews
  • Blog
  • Pricing
  • Gift
    Gift Purchase Gift Redeem
  • About
Log In - Sign Up
  1. Labs
  2. Apache
  3. Guide

Guide

Concepts and learning path

Troubleshooting

Failure modes and fixes

Cheatsheet

Commands to keep handy

Apache guide

What Apache does in production

Apache listens on ports (typically 80 and 443), matches each request to a virtual host, and either serves files from disk or forwards the request to a backend via mod_proxy. Access control, URL rewriting, TLS termination, and compression are handled by loadable modules. On SadServers scenarios you debug real configs: wrong Listen ports, broken vhosts, missing modules, and permission errors on log or document directories.

How a request is handled

When a client connects, the typical workflow is:

  1. TCP accept — Apache receives the connection on a Listen port
  2. TLS handshake — if HTTPS, mod_ssl negotiates the certificate (vhost selected by SNI)
  3. Virtual host match — Apache picks a <VirtualHost> using ServerName, ServerAlias, and port
  4. URL mapping — DocumentRoot, Alias, ProxyPass, or rewrite rules determine the handler
  5. Access check — Require directives allow or deny the request
  6. Response — static file, CGI, or proxied backend response; logged to access_log / error_log

If no vhost matches, the first vhost for that port is used as the default — a common source of "wrong site" bugs.

Configuration layout

Paths differ by distribution:

  • Debian/Ubuntu — /etc/apache2/apache2.conf, sites in sites-available/ / sites-enabled/, modules via a2enmod / a2dismod
  • RHEL/CentOS/Rocky — /etc/httpd/conf/httpd.conf, vhosts in conf.d/, modules in modules/

Always run a syntax check before reload: apache2ctl configtest (Debian) or httpd -t (RHEL).

Key concepts to know

  • Virtual hosts — ServerName / ServerAlias matching against the Host header
  • Modules — LoadModule, a2enmod proxy, MPM choice (prefork, worker, event)
  • Logs — ErrorLog for failures; CustomLog for access; check these first
  • Reverse proxy — ProxyPass / ProxyPassReverse to app servers (Gunicorn, Node, etc.)
  • systemd — apache2 or httpd unit; reload does not drop existing connections
  • .htaccess — per-directory overrides (if AllowOverride permits); slower than vhost config

Learning resources

  • Apache HTTP Server documentation — httpd.apache.org/docs/2.4 (official 2.4 reference)
  • Virtual hosts — httpd.apache.org/docs/2.4/vhosts (name-based vhost guide)
  • mod_proxy — httpd.apache.org/docs/2.4/mod/mod_proxy (reverse proxy directives)
  • apache2ctl(8) — manpages.debian.org/apache2ctl (Debian control tool)

Practice scenarios

Hands-on Apache scenarios on live Linux VMs: apache

Troubleshooting →
SadServersSadServers

Real-world Linux and DevOps scenarios for hands-on learning and technical assessment.

Uptime Robot ratio (30 days)
Product
  • Scenarios
  • For Individuals
  • For Businesses
  • Pricing
Resources
  • FAQ
  • Blog
  • Newsletter
Company
  • About Us
  • Support
  • Privacy Policy
  • Terms of Service
  • Contact
Connect With Us
info@sadservers.com

Made in Canada 🇨🇦
Updated: 2026-06-13 16:06 UTC – 2d2950a