Downloads

Introduction to Apache HTTP Server

Learn what Apache HTTP Server is, how HTTP requests reach it, and how to install, configure, secure, monitor, and troubleshoot a first Apache website.

Apache HTTP Server is one of the most widely used open-source web server applications. This guide introduces Apache, commonly called Apache or httpd, and explains how it receives web requests, serves files, routes domains, connects to application backends, and records useful diagnostic information.

You should be comfortable with basic Linux commands, files and permissions, URLs, IP addresses, ports, DNS, text editors, and administrative privileges such as sudo.

What Apache HTTP Server Is

Apache HTTP Server is open-source software that accepts HTTP and HTTPS connections and returns responses. A response might contain a static HTML file, an image, a stylesheet, a redirect, an error message, or the result of an application running elsewhere.

A simplified request path looks like this:

  1. A browser or other client requests a domain name.
  2. DNS resolves the domain name to an IP address.
  3. The client connects to the server, usually on port 80 for HTTP or 443 for HTTPS.
  4. Apache selects configuration rules, often including a virtual host.
  5. Apache serves a file from a document root, invokes an application integration, or forwards the request to a backend.
  6. Apache returns an HTTP response and records the request in its logs.

Why Apache Is Used

  • Static websites: Apache can efficiently serve HTML, CSS, JavaScript, images, and downloads.
  • Application front ends: It can provide a public endpoint for an application server.
  • Virtual hosting: One server can host multiple domains or separate sites.
  • Reverse proxying: Apache can forward requests to private application services.
  • TLS termination: Apache can handle HTTPS encryption while an internal service uses another protocol.
  • Redirects and access control: Configuration can redirect URLs, restrict directories, and control access.

Apache is modular: optional modules add capabilities rather than every feature being built into the base server. It also supports many operating systems, has extensive documentation, and has a mature ecosystem. The tradeoff is that its configuration can become complex. Its processing model and module choices should match the workload, especially when serving many concurrent connections or dynamic applications.

Web Request and Response Fundamentals

The web uses a client-server model. A client, such as a browser or curl, sends a request. A server receives the request, performs work, and sends a response.

DNS maps a name such as example.test to an IP address. The client then establishes a network connection to a numbered port. HTTP commonly uses port 80, while HTTPS commonly uses port 443.

An HTTP request contains a method such as GET, a path, and headers. Headers provide metadata such as the requested host, accepted formats, and cookies. An HTTP response contains a numeric status code, response headers, and usually a response body.

  • 2xx means success.
  • 3xx means redirection.
  • 4xx usually indicates a client or request problem.
  • 5xx usually indicates a server or backend problem.

HTTPS is HTTP protected by TLS. A TLS certificate helps authenticate the hostname and allows the client and server to establish encrypted traffic. Encryption protects data in transit, but it does not automatically make an application or server secure.

Apache Architecture

The Apache installation normally includes a main server process, child processes or threads, configuration files, optional modules, and log files. The main process reads configuration and coordinates request handling. The exact process and thread behavior depends largely on the selected Multi-Processing Module (MPM).

  • prefork: Uses separate processes and is compatible with some older, process-oriented integrations.
  • worker: Uses multiple processes with multiple threads.
  • event: Uses an event-oriented design to handle connections efficiently, particularly keep-alive connections.

Apache is not itself a PHP, Python, Java, or other application runtime. It may serve static files, connect to PHP through an embedded module or PHP-FPM using FastCGI, or forward requests to an application server. The application runtime performs application work; Apache handles the web-server role and integration.

Installing and Managing Apache

Package names and paths vary by Linux distribution. Debian-derived systems commonly use the package and service name apache2. Red Hat-derived systems commonly use httpd. Installation and service management require administrative privileges.

On Debian or Ubuntu:

sudo apt update
sudo apt install apache2

On RHEL, Rocky Linux, AlmaLinux, or Fedora:

sudo dnf install httpd

Some older systems use yum instead of dnf. Common systemd operations are:

sudo systemctl status apache2
sudo systemctl start apache2
sudo systemctl stop apache2
sudo systemctl restart apache2
sudo systemctl reload apache2
sudo systemctl enable apache2
sudo systemctl disable apache2

Use httpd instead of apache2 on systems using that service name:

sudo systemctl status httpd
sudo systemctl start httpd
sudo systemctl reload httpd
sudo systemctl enable httpd

A reload asks Apache to reread configuration without unnecessarily terminating existing work. A restart stops and starts the service. Always test configuration syntax before either operation.

sudo apachectl configtest
sudo apache2ctl configtest
sudo httpd -t

The available test command depends on the distribution. A successful syntax test does not prove that DNS, permissions, certificates, firewall rules, or application connectivity are correct.

Common Files and Directory Layout

Exact paths differ by operating system and package distribution. The following locations are common examples.

Debian-derived systems: package apache2; main configuration commonly /etc/apache2/apache2.conf; site definitions commonly /etc/apache2/sites-available/ and /etc/apache2/sites-enabled/; modules commonly use /etc/apache2/mods-available/ and /etc/apache2/mods-enabled/; document root often /var/www/html; logs often /var/log/apache2/.

Red Hat-derived systems: package httpd; main configuration commonly /etc/httpd/conf/httpd.conf; additional configuration commonly /etc/httpd/conf.d/; document root often /var/www/html; logs often /var/log/httpd/.

Server-wide configuration affects the Apache installation as a whole. Per-site configuration is usually placed in virtual-host definitions. A .htaccess file is an optional per-directory configuration file. Apache only honors the directives allowed by the relevant AllowOverride setting. These files can be useful when site owners cannot edit the main configuration, but they add lookup overhead, can hide configuration, and can create security problems when overly broad overrides are permitted.

Core Configuration Concepts

Apache configuration is declarative: directives describe the desired behavior rather than implementing an algorithm step by step. A directive is a configuration instruction such as Listen or DocumentRoot. Lines beginning with # are comments. Configuration files can include other files, allowing distributions to divide settings into manageable pieces.

Settings apply according to configuration context. A server-wide directive may affect all sites, a VirtualHost container may affect one site, and a Directory container may affect one filesystem path. Some settings are inherited or overridden according to Apache's configuration rules, so the active result may depend on more than one file.

ServerName — identifies the primary hostname; commonly server-wide or inside a virtual host; example: ServerName example.test.

Listen — defines addresses and ports where Apache accepts connections; example: Listen 80.

DocumentRoot — identifies the public filesystem directory; example: DocumentRoot /var/www/example.test/public.

Directory — applies access and option rules to a filesystem path; example: <Directory /var/www/example.test/public>.

DirectoryIndex — lists default files for directory requests; example: DirectoryIndex index.html index.php.

ErrorLog — selects the error-log destination; example: ErrorLog /var/log/apache2/example-error.log.

CustomLog — selects the access-log destination and format; example: CustomLog /var/log/apache2/example-access.log combined.

LogLevel — controls error-message detail; increase it temporarily while diagnosing a problem.

A directory rule commonly needs to grant access explicitly on modern Apache installations:

<Directory /var/www/example.test/public>
    Require all granted
</Directory>

Serving a First Website

For a simple local test, create a document root and an HTML file, ensure Apache can traverse the directories and read the file, then request it:

sudo mkdir -p /var/www/example.test/public
printf '%s\n' '<h1>Hello from Apache</h1>' | sudo tee /var/www/example.test/public/index.html
sudo apachectl configtest
sudo systemctl reload apache2
curl -I http://localhost/

The exact service and configuration paths may require adjustment. A browser request to http://localhost/ tests the local machine. A request to http://SERVER_IP/ tests access through the server's IP address. A public domain requires DNS records that point the domain to the server's public IP address.

When a visitor requests a directory, Apache checks the DirectoryIndex list, commonly including index.html or index.php. If no index file exists, Apache may return 403 or display a directory listing if listing is enabled. Directory listing should normally remain disabled unless it is an intentional requirement.

Name-Based Virtual Hosts

A virtual host lets one Apache instance serve separate websites. The client sends the requested hostname in the HTTP Host header. Apache compares that value with ServerName and ServerAlias, then selects the matching VirtualHost configuration.

<VirtualHost *:80>
    ServerName example.test
    ServerAlias www.example.test
    DocumentRoot /var/www/example.test/public

    <Directory /var/www/example.test/public>
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/example.test-error.log
    CustomLog ${APACHE_LOG_DIR}/example.test-access.log combined
</VirtualHost>

A second site can use another hostname and document root, for example shop.example.test and /var/www/shop.example.test/public. In a real deployment, each DNS name must resolve to the server. On distributions with available/enabled conventions, create the definition in sites-available and enable it with the distribution's site-enabling mechanism, then test and reload Apache.

Configure a deliberate default virtual host for unknown hostnames. It should serve minimal neutral content or reject the request rather than exposing an unintended site or administrative files. The first matching virtual host can otherwise become the default for an address and port.

Logging and Basic Monitoring

An access log records incoming requests, hostnames, paths, response codes, and often response sizes and user-agent details. An error log records startup failures, syntax problems, permission denials, missing files, module issues, and request-processing errors. Use both: the access log shows what happened, while the error log often explains why.

sudo tail -f /var/log/apache2/access.log
sudo tail -f /var/log/apache2/error.log
sudo tail -f /var/log/httpd/access_log
sudo tail -f /var/log/httpd/error_log
curl -I http://localhost/

200 — successful response; investigate the returned content if it is unexpected.

301 — permanent redirect; inspect redirect targets and canonical-host rules.

302 — temporary redirect; inspect application or redirect configuration.

403 — forbidden; inspect permissions, Directory rules, and access-control policy.

404 — resource not found; inspect the selected virtual host, document root, and URL path.

500 — internal server error; inspect the error log, modules, scripts, and .htaccess.

502 — bad gateway; inspect reverse-proxy connection to the backend.

503 — service unavailable; inspect backend health, capacity, and maintenance settings.

Security Fundamentals

  • Apply least privilege to administrative accounts, service accounts, files, and directories. Apache should not need write access to the entire website.
  • Keep the operating system, Apache, modules, application runtimes, and dependencies patched.
  • Disable unnecessary modules and remove default content that should not be public.
  • Keep directory listing disabled unless explicitly needed.
  • Limit AllowOverride and avoid allowing arbitrary users to change security-sensitive behavior through .htaccess.
  • Expose only required network ports. Firewalls commonly allow TCP 80 and 443 for a public web server, while administrative ports should be restricted.
  • Use valid TLS certificates, protect private keys, and avoid placing credentials, backups, source repositories, or configuration secrets beneath a document root.
  • Test every configuration change and keep a backup or rollback copy before editing production files.

HTTPS Introduction

HTTPS uses TLS to encrypt HTTP traffic and authenticate a hostname. Apache commonly listens on port 443 in a separate HTTPS virtual host. The SSL/TLS module must be available, and the virtual host references the certificate and private-key files.

<VirtualHost *:443>
    ServerName example.test
    DocumentRoot /var/www/example.test/public

    SSLEngine on
    SSLCertificateFile /path/to/certificate.pem
    SSLCertificateKeyFile /path/to/private-key.pem

    <Directory /var/www/example.test/public>
        Require all granted
    </Directory>
</VirtualHost>

Certificate issuance and renewal are operational tasks often automated with an ACME client. The certificate hostname must match the requested domain, the chain must be complete, and port 443 must be reachable. An HTTP virtual host may redirect to HTTPS:

Redirect permanent / https://example.test/

Check redirect targets carefully. A redirect loop can occur when Apache redirects every request to HTTPS while a proxy or load balancer communicates with Apache over HTTP without forwarding the original scheme correctly.

Dynamic Content and Reverse Proxying

Apache can serve static files directly or pass dynamic requests to another process. PHP may be integrated through an Apache module or through PHP-FPM using FastCGI. Python, Java, Node.js, and other applications commonly run as separate services.

A reverse proxy is a public server that receives client requests and forwards them to an upstream service. A basic structure using mod_proxy is:

<VirtualHost *:80>
    ServerName app.example.test

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

The required proxy modules must be enabled. The backend should normally listen on a private interface such as 127.0.0.1 rather than being directly exposed to the internet. Configure forwarding headers, such as the original host and scheme, when the application needs them, and ensure the backend trusts only appropriate proxy sources.

A Repeatable Troubleshooting Workflow

  1. Run the platform-appropriate configuration test.
  2. Check whether the Apache service is running.
  3. Confirm that Apache is listening on the expected addresses and ports.
  4. Check host firewall and cloud security rules.
  5. Verify DNS resolves to the intended IP address.
  6. Test locally with curl.
  7. Reproduce the problem and inspect the relevant access and error logs.
  8. Test externally only after local service and network checks succeed.

Interpret failures by layer. A DNS failure means the name does not resolve correctly. A connection failure often indicates a stopped service, wrong listener, firewall, or routing issue. A 403 often involves permissions or access rules. A 404 often involves the selected virtual host, document root, or path. A 500 often involves server configuration, scripts, or application code. A 502 or 503 usually points to an unavailable or unreachable backend.

If a reload fails after a recent edit, do not repeatedly restart the service. Read the syntax-test output and error log, correct or revert the latest change, run the test again, and reload only after it succeeds. A successful reload should then be verified with curl, the service status, and the logs.

Practical Exercises

Exercise 1: Serve a Static Homepage

Create index.html in a test document root, check that Apache can read the file and traverse its parent directories, request http://localhost/, and verify a 200 response.

Exercise 2: Route Two Local Virtual Hosts

Configure separate virtual hosts for example.test and shop.example.test, each with its own document root and log files. Test routing by sending the desired host header with curl:

curl -H 'Host: example.test' http://127.0.0.1/
curl -H 'Host: shop.example.test' http://127.0.0.1/

Exercise 3: Compare Log Entries

Make one normal request and one request for a missing page. Compare the 200 and 404 access-log entries, then check whether the error log contains additional information.

Exercise 4: Safely Apply a Change

Modify a virtual-host definition, run apachectl configtest or the equivalent command, reload Apache, and verify the result with curl and the site-specific logs.

HTTP and HTTPS Comparison

Protocol — HTTP uses plain HTTP; HTTPS uses HTTP over TLS.

Common port — HTTP uses 80; HTTPS uses 443.

Encryption — HTTP does not encrypt traffic; HTTPS encrypts traffic in transit.

Certificate — HTTP does not require a TLS certificate; HTTPS requires a valid certificate configuration.

Typical configuration — HTTP commonly uses a port-80 virtual host; HTTPS commonly uses a separate port-443 virtual host.

Exam-Relevant Notes

  • Apache HTTP Server, Apache, and httpd refer to the web-server software and its common executable or service naming; the Apache Software Foundation is the organization overseeing many projects.
  • DocumentRoot identifies the filesystem directory from which public files are served.
  • ServerName and ServerAlias identify hostnames for a virtual host, while Listen defines accepted addresses and ports.
  • MPMs control Apache's process and thread model. Prefork, worker, and event are broad alternatives.
  • Always validate syntax before reloading or restarting.
  • Access logs show requests and outcomes; error logs explain many failures.
  • HTTPS is HTTP protected by TLS, normally on port 443.
  • Apache can connect to application runtimes and backends but is not itself the application runtime.

For related foundational practice, see the Python guide for complete beginners and the Nmap introduction.