Apache HTTP Server includes a powerful reverse proxy framework through the mod_proxy module family. With the right configuration, Apache can sit in front of one or more backend applications, forward client requests, terminate SSL connections, distribute traffic across multiple servers, and add an additional layer of security and control between users and your application infrastructure.

In this tutorial, you will configure Apache as a reverse proxy on Ubuntu using the mod_proxy module family. You will install Apache and enable the required proxy modules, set up basic request forwarding with ProxyPass and ProxyPassReverse, preserve client information through forwarded headers, distribute traffic across multiple backends with mod_proxy_balancer, configure SSL termination at the proxy layer, apply security hardening, and learn how to diagnose common mod_proxy errors in production.

Before you begin, ensure that you have an Ubuntu server running a recent supported release, such as Ubuntu 22.04 or Ubuntu 24.04, with a non-root user with sudo privileges and a firewall enabled.

For guidance on how to set up a non-root user with sudo privileges and a firewall enabled, refer to our Initial Server Setup with Ubuntu guide. If you are new to Apache on Ubuntu, you may also want to review How to Install the Apache Web Server on Ubuntu before continuing.

A reverse proxy is a server that sits between clients and one or more backend application servers. When a client requests a resource, it connects to the reverse proxy first. Apache evaluates routing rules (typically ProxyPass and ProxyPassReverse inside a VirtualHost), selects the appropriate backend, forwards the request, and returns the backend’s response as if Apache had generated it.

This differs from a forward proxy, which acts on behalf of clients browsing the internet. A reverse proxy acts on behalf of your applications. Clients see only the proxy’s hostname, IP address, and TLS certificate. Backend hostnames, internal ports, and server layout remain hidden. That separation lets you replace backends, add capacity, or apply patches without clients knowing how your infrastructure is organized.

Modern web stacks often rely on this pattern because application servers such as Node.js, Python WSGI apps, or Java servlets are built to process HTTP efficiently but are not always ideal as the public-facing edge. Apache handles the client connection, enforces policies at the boundary, and delegates work to specialized backends.

Why Use a Reverse Proxy?

Organizations adopt reverse proxies to consolidate cross-cutting concerns in one place. Instead of configuring TLS, request logging, rate limits, and access control on every application instance, you define those behaviors once at the proxy layer. The result is simpler operations, more consistent security, and an easier path to scale as traffic grows.

Decoupling Frontend and Backend Services

Backend applications are commonly bound to loopback addresses such as 127.0.0.1 or to private network interfaces that are not reachable from the public internet. This is intentional: the application process may lack hardening for direct exposure, or you may run several services on one host that should not each receive their own public port.

Apache bridges that gap by listening on well-known ports 80 and 443 while backends listen elsewhere. For example, Apache might accept all public traffic while a Node.js API listens on 127.0.0.1:3000. Path-based rules can send requests for /api/ to the API and serve static files from Apache directly. You gain a single domain and certificate for users while keeping application processes off the public network.

This architecture also simplifies change management. You can deploy a new backend version on a different port, switch the proxy target, or run blue-green deployments without clients updating URLs or DNS records. Multiple applications can share one public hostname, each routed by path or subdomain rules defined in Apache configuration.

SSL/TLS Termination

Encrypting traffic end-to-end is essential, but managing certificates on every backend is repetitive and increases the risk of expired or misconfigured certificates. With SSL termination, the client establishes HTTPS with Apache, and Apache decrypts the connection using your site certificate before forwarding traffic internally.

Apache can forward decrypted HTTP to backends on a trusted private network, or re-encrypt the connection to backends that require HTTPS using SSLProxyEngine On and related SSLProxy* directives. The first approach is common when backends sit on the same host or VLAN; the second is used when internal traffic must also be encrypted for compliance.

Centralizing TLS at the proxy means certificate renewals, cipher suite selection, and HTTP Strict Transport Security apply in one configuration file. Application frameworks can run plain HTTP locally and avoid duplicating TLS setup, which is especially helpful when backends are containers or short-lived processes that would otherwise need their own certificate distribution. For production HTTPS, you can obtain and renew certificates with Let’s Encrypt and Certbot on Apache.

Load Balancing

A single backend eventually becomes a bottleneck. Apache addresses this with mod_proxy_balancer, which defines a pool of backend members and distributes incoming requests among them. Load-method modules such as mod_lbmethod_byrequests, mod_lbmethod_bytraffic, and mod_lbmethod_bybusyness control whether Apache balances by request count, bytes transferred, or current backend load.

Session stickiness is available when an application stores session data locally rather than in a shared store. Apache can pin a client to the same backend for the duration of a session so stateful apps behave correctly. When a member fails health checks or stops responding, traffic can shift to healthy members, improving availability without taking the entire site offline.

Load balancing at the proxy is a practical way to scale horizontally: add another application instance, register it as a BalancerMember, and Apache begins sending it traffic without changing client-facing URLs.

Caching and Performance Optimization

Not every request needs to reach a backend. For resources that change infrequently, such as images, stylesheets, and public API responses with short TTLs, Apache can cache responses using mod_cache and mod_cache_disk, honoring HTTP cache headers and administrator-defined rules. Serving cached content from Apache reduces CPU and I/O on application servers and improves response times for repeat visitors.

Apache is not primarily a dedicated caching proxy like Varnish, but caching at the edge still matters in mixed workloads where Apache already terminates TLS and serves static files. Compression with mod_deflate is another common optimization: Apache compresses responses before they cross the WAN, which helps clients on slower links without requiring every backend to implement compression independently.

How mod_proxy Fits into Apache’s Module Ecosystem

Apache implements reverse proxying through a modular family centered on mod_proxy. The core module provides shared infrastructure: connection management, proxy-related directives, and hooks that protocol-specific modules extend. You must enable mod_proxy for any reverse proxy configuration; companion modules add capabilities on top of that foundation.

mod_proxy_http is required for proxying HTTP and HTTPS backends and is the module most tutorials enable first. mod_proxy_balancer adds load balancing through BalancerMember entries and <Proxy balancer://name> configuration blocks. mod_proxy_wstunnel handles WebSocket upgrade requests for real-time applications. mod_proxy_fcgi forwards requests to FastCGI processes such as PHP-FPM, which is a common pattern for PHP hosting behind Apache.

Additional modules extend the family for specialized deployments. mod_proxy_ajp proxies to Java application servers over the AJP protocol. mod_proxy_hcheck performs backend health checks so failed members can be removed from rotation. mod_proxy_html rewrites links in HTML responses when backend URLs differ from the public URL space.

Key directives work across these modules. ProxyPass maps an incoming URL path to a backend URL. ProxyPassReverse adjusts response headers so redirects and asset URLs reflect the public hostname clients use. ProxyRequests Off must be set to disable forward-proxy mode; leaving forward proxying enabled can turn your server into an open proxy and is a serious security risk.

Because each module registers only what it needs, you load a lean subset of functionality. One Apache instance can terminate TLS, proxy REST APIs, balance a cluster, and upgrade WebSocket connections without pulling in unrelated protocol handlers. On Ubuntu and Debian, enable modules with a2enmod, restart Apache so LoadModule directives take effect, and verify the loaded set with apache2 -M | grep proxy before writing VirtualHost rules.

Apache’s reverse proxy functionality is not implemented through a single standalone module. Instead, Apache uses a collection of related modules that work together to support different protocols, backend communication methods, and proxy features. This modular architecture is one of the reasons Apache remains highly flexible in complex web server environments.

At the center of this system is the core mod_proxy module, which provides the foundational proxy framework responsible for request forwarding, connection handling, and proxy infrastructure management. However, mod_proxy alone is not enough to proxy application traffic. Apache relies on additional protocol-specific submodules to handle the actual communication between the proxy server and backend services.

This separation allows administrators to enable only the components required for their deployment. A simple HTTP reverse proxy may only require mod_proxy and mod_proxy_http, while a more advanced environment using WebSockets, PHP-FPM, or load balancing may require several additional modules.

Each module extends Apache’s proxy capabilities for a particular purpose.

The Core mod_proxy Module

The base mod_proxy module provides Apache’s core proxy engine. It handles the general framework required for forwarding requests between clients and backend servers. This includes managing proxy connections, request routing, shared proxy directives, worker definitions, and communication flow between Apache and backend services.

The core module also provides important directives such as:

• ProxyPass
• ProxyPassReverse
• ProxyRequests
• <Proxy>
• BalancerMember

Although mod_proxy provides the infrastructure, it cannot proxy HTTP traffic by itself. Additional protocol handlers are required depending on the type of backend connection being used.

mod_proxy_http

The mod_proxy_http module is the most commonly used proxy submodule. It enables Apache to proxy standard HTTP and HTTPS traffic to backend application servers.

In most reverse proxy deployments, this module handles communication between Apache and backend web applications such as:

• Node.js applications
• Python web frameworks
• Internal Apache or Nginx servers
• Java application servers
• Containerized web applications

For example, when Apache forwards requests to a backend application running on:

http://127.0.0.1:3000

the request handling is performed through mod_proxy_http.

This module supports standard HTTP request and response handling, persistent backend connections, chunked transfer encoding, header forwarding, and HTTP protocol negotiation.

A typical configuration using mod_proxy_http looks like this:

ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/

Because most modern web applications communicate over HTTP or HTTPS, mod_proxy_http is usually the first proxy submodule administrators enable.

mod_proxy_balancer

The mod_proxy_balancer module adds load balancing capabilities to Apache’s proxy framework. Instead of forwarding all traffic to a single backend server, Apache can distribute requests across multiple backend nodes.

This module becomes important in high-availability or horizontally scaled environments where several application instances handle incoming traffic simultaneously.

Apache supports multiple balancing methods, including:

• Request-count balancing (byrequests)
• Traffic-size balancing (bytraffic)
• Pending-request balancing (bybusyness)

The module also supports session persistence, commonly referred to as sticky sessions, where repeat requests from the same client are consistently routed to the same backend server.

A simplified load-balanced configuration might look like this:

<Proxy "balancer://mycluster">
    BalancerMember http://10.0.0.11:8080
    BalancerMember http://10.0.0.12:8080
</Proxy>

ProxyPass / balancer://mycluster/

Internally, mod_proxy_balancer works together with other proxy protocol modules such as mod_proxy_http, since the balancer itself does not directly implement HTTP communication.

mod_proxy_wstunnel

Modern web applications increasingly rely on WebSockets for persistent, real-time communication. Standard HTTP proxying is not sufficient for handling WebSocket upgrade requests because WebSockets transition from traditional HTTP request-response behavior into a long-lived bidirectional connection.

The mod_proxy_wstunnel module enables Apache to proxy WebSocket traffic using the ws:// and wss:// protocols. In Apache 2.4.47 and later, WebSocket upgrades can also be handled through mod_proxy_http using upgrade parameters, although mod_proxy_wstunnel remains widely used. For Node.js and similar real-time apps, see also Nginx as a Reverse Proxy for Node or Angular for an alternative edge-server approach.

This module is commonly used with:

• Real-time dashboards
• Chat applications
• Live notification systems
• Multiplayer game servers
• Streaming applications

When a client initiates a WebSocket connection, Apache detects the protocol upgrade request and tunnels the persistent connection to the backend application.

A typical WebSocket proxy configuration looks like this:

ProxyPass /socket ws://127.0.0.1:3000/socket
ProxyPassReverse /socket ws://127.0.0.1:3000/socket

Without mod_proxy_wstunnel, Apache may return upgrade-related errors or fail to maintain persistent WebSocket sessions.

mod_proxy_fcgi

The mod_proxy_fcgi module enables Apache to communicate with FastCGI backend services. This is particularly important in PHP environments that use PHP-FPM instead of Apache’s older embedded mod_php processing model.

In modern Linux distributions, PHP-FPM has largely become the preferred approach because it separates PHP execution from the web server process, improving performance, scalability, and resource isolation.

Instead of forwarding HTTP traffic, mod_proxy_fcgi forwards FastCGI requests to backend FastCGI workers.

A common PHP-FPM integration looks like this:

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

This configuration allows Apache to pass PHP requests through a Unix socket to the PHP-FPM service.

Although mod_proxy_fcgi is not typically used for general reverse proxying of web applications, it is still part of the broader mod_proxy ecosystem and is widely deployed in Apache-based PHP hosting environments.

Comparing Common mod_proxy Submodules

The following table summarizes the primary Apache proxy submodules and their typical use cases:

In most modern Ubuntu reverse proxy deployments, administrators typically enable at least the following modules:

mod_proxy
mod_proxy_http
mod_headers

Additional modules are enabled depending on the application requirements and deployment architecture.

Before configuring Apache as a reverse proxy, you first need to install Apache HTTP Server and verify that the required proxy modules are available on the system. On Ubuntu, the mod_proxy module family is included with the standard Apache package installation, although the modules are not always enabled by default.

Installing Apache on Ubuntu

Ubuntu packages Apache HTTP Server as apache2. Begin by updating the package index:

sudo apt update

Next, install Apache:

sudo apt install apache2

After the installation completes, Ubuntu automatically starts the Apache service and enables it to start during boot.

You can verify that Apache is running with:

sudo systemctl status apache2

If the service started successfully, you should see output similar to this:

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-05-19 06:59:03 UTC; 16s ago
       Docs: https://httpd.apache.org/docs/2.4/
   Main PID: 3083 (apache2)
      Tasks: 55 (limit: 2318)
     Memory: 5.1M (peak: 5.3M)
        CPU: 51ms
     CGroup: /system.slice/apache2.service
             ├─3083 /usr/sbin/apache2 -k start
             ├─3086 /usr/sbin/apache2 -k start
             └─3087 /usr/sbin/apache2 -k start

You can also confirm that Apache is serving requests locally by using curl:

curl http://localhost

If Apache is functioning correctly, the command returns the default Apache HTML page.

Understanding Apache Modules on Ubuntu

Apache uses a modular architecture in which features are loaded through individual modules instead of being built directly into the core server binary. Reverse proxy functionality is provided through the mod_proxy module family, which consists of several separate modules responsible for handling different proxy protocols and features.

On Ubuntu, Apache modules are managed through two primary directories:

/etc/apache2/mods-available/

This directory contains all module definition files installed on the system.

Enabled modules are symlinked into:

/etc/apache2/mods-enabled/

This structure allows Ubuntu administrators to enable or disable Apache features without manually editing the main configuration file.

Most proxy-related modules are shipped as dynamically loadable shared modules, which means they can be activated only when needed. This keeps the Apache process lighter and reduces unnecessary functionality in the running server.

Verifying Available Proxy Modules

Before enabling reverse proxy functionality, it is useful to confirm that the required modules are installed on the system.

You can list available proxy modules with:

ls /etc/apache2/mods-available/ | grep proxy

You should see output similar to this:

proxy.conf
proxy.load
proxy_http.load
proxy_balancer.load
proxy_wstunnel.load
proxy_fcgi.load

This output confirms that the proxy module files are present and available for activation.

Each file corresponds to a specific Apache module. For example:

• proxy.load loads the core mod_proxy framework
• proxy_http.load enables HTTP and HTTPS proxying
• proxy_balancer.load adds load balancing support
• proxy_wstunnel.load enables WebSocket proxying
• proxy_fcgi.load supports FastCGI backends such as PHP-FPM

Not every deployment requires all of these modules, but verifying their availability helps ensure the server is ready for later configuration steps.

Checking Which Modules Are Currently Loaded

Even if the modules exist on disk, they may not currently be enabled in the active Apache configuration.

You can display all loaded Apache modules with:

apache2ctl -M

To filter only proxy-related modules, use:

apache2ctl -M | grep proxy

If some proxy modules are already enabled, you may see output similar to this:

proxy_module (shared)
proxy_http_module (shared)

If no proxy modules appear, they have not yet been activated. You will enable the required modules in the next section.

Verifying Apache Configuration Syntax

Before modifying Apache configuration files, it is good practice to verify that the current configuration is valid.

Run:

sudo apache2ctl configtest

If Apache does not detect any syntax issues, the command returns:

Syntax OK

Using configtest before and after configuration changes is an important habit because Apache refuses to reload invalid configurations. Verifying syntax early helps prevent unnecessary downtime and makes troubleshooting easier.

After verifying that the proxy modules are available on the system, the next step is to enable the modules required for reverse proxy functionality. On Ubuntu, Apache modules are typically enabled using the a2enmod utility, which creates symbolic links from the mods-available directory into mods-enabled.

Because Apache separates proxy functionality into multiple modules, enabling only the core mod_proxy module is not sufficient for most deployments. You must also enable the protocol-specific submodules that handle communication with backend servers.

For a standard HTTP reverse proxy configuration, the minimum required modules are:

• mod_proxy
• mod_proxy_http

Additional modules may be required later depending on your deployment requirements, such as load balancing, WebSocket support, SSL proxying, or custom header manipulation.

Enabling the Core Proxy Modules

Begin by enabling the core proxy framework and HTTP proxy module:

sudo a2enmod proxy
sudo a2enmod proxy_http

The proxy module provides Apache’s base proxy infrastructure, while proxy_http enables forwarding HTTP and HTTPS requests to backend application servers.

After running these commands, Ubuntu creates symbolic links for the module configuration files under:

/etc/apache2/mods-enabled/

You can verify that the modules were enabled successfully with:

ls /etc/apache2/mods-enabled/ | grep proxy

You should now see entries similar to:

proxy.conf
proxy.load
proxy_http.load

Enabling Additional Common Proxy Modules

Many reverse proxy deployments also require additional Apache modules beyond the basic HTTP proxy components.

For example, mod_headers is commonly used to forward client information and manipulate request headers:

sudo a2enmod headers

If you plan to configure load balancing later in the tutorial, enable the balancing modules now:

sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

The proxy_balancer module provides the load balancing framework, while lbmethod_byrequests enables Apache’s request-count balancing algorithm.

For WebSocket support, enable:

sudo a2enmod proxy_wstunnel

If you intend to terminate SSL/TLS connections or proxy HTTPS traffic, you should also enable Apache’s SSL module:

sudo a2enmod ssl

At this stage, enabling extra modules even if they are not immediately required can simplify later configuration steps, especially in test environments.

Understanding What a2enmod Does

The a2enmod command does not directly modify the main Apache configuration file. Instead, it activates modules by creating symbolic links from the mods-available directory into mods-enabled.

For example, enabling mod_proxy creates links similar to:

/etc/apache2/mods-enabled/proxy.load
/etc/apache2/mods-enabled/proxy.conf

This modular structure makes Apache configuration easier to manage because features can be enabled or disabled independently without editing large configuration files manually.

To disable a module later, you can use the complementary a2dismod command:

sudo a2dismod proxy_wstunnel

However, avoid disabling modules that are actively referenced by VirtualHost configurations, as Apache may fail to start if required modules are missing.

Verifying Loaded Modules

After enabling the required modules, verify that Apache now loads them correctly.

Run:

apache2ctl -M | grep proxy

You should see output similar to:

proxy_module (shared)
proxy_http_module (shared)
proxy_balancer_module (shared)
proxy_wstunnel_module (shared)

You can also confirm that the headers module is loaded:

apache2ctl -M | grep headers

Expected output:

headers_module (shared)

Verifying loaded modules before proceeding helps avoid configuration errors later when Apache encounters unknown directives associated with unloaded modules.

Restarting Apache After Enabling Modules

After enabling new modules, restart Apache so the changes take effect:

sudo systemctl restart apache2

You can verify that the service restarted successfully with:

sudo systemctl status apache2

If Apache encounters configuration or module-loading errors during startup, the service status output usually provides a short error summary. More detailed information can be found in the Apache error log:

/var/log/apache2/error.log

Before continuing, it is also a good idea to run a configuration syntax check:

sudo apache2ctl configtest

If everything is configured correctly, Apache returns:

Syntax OK

At this point, Apache is fully prepared for reverse proxy configuration.

With the required proxy modules enabled, you can now configure Apache to function as a reverse proxy. In a basic reverse proxy setup, Apache accepts incoming client requests and forwards them to a backend application server running locally or on another system within the network.

Apache performs this forwarding primarily through the ProxyPass and ProxyPassReverse directives provided by the mod_proxy module family.

In this example, Apache will listen publicly on port 80 and forward requests to a backend application running on:

http://127.0.0.1:3000

This type of configuration is common for applications built with frameworks such as Node.js, Django, Flask, Express, or Spring Boot, where the application server itself is not intended to be exposed directly to the internet.

Understanding Reverse Proxy Request Flow

Before configuring Apache, it is useful to understand how requests move through the proxy layer.

In a reverse proxy deployment:

1. A client sends a request to Apache
2. Apache receives the request on behalf of the backend application
3. Apache forwards the request internally to the backend server
4. The backend application processes the request and returns a response
5. Apache relays the response back to the client

The client never communicates directly with the backend application server.

This architecture allows Apache to act as a stable frontend layer while backend services remain isolated from direct public access.

Disabling Forward Proxying

One of the most important security settings in any reverse proxy configuration is disabling forward proxy functionality.

Apache can operate as both:

• A reverse proxy
• A forward proxy

A forward proxy accepts requests from clients and retrieves arbitrary internet resources on their behalf. Unless intentionally configured, this behavior should always remain disabled because open forward proxies are a major security risk and are frequently abused.

To ensure Apache only functions as a reverse proxy, set:

ProxyRequests Off

This directive should typically be placed inside the relevant VirtualHost block or within a dedicated proxy configuration file.

Never leave ProxyRequests enabled unless you explicitly intend to run a controlled forward proxy service.

Understanding ProxyPass

The ProxyPass directive tells Apache to forward requests from a specific URL path to a backend server.

The basic syntax is:

ProxyPass <frontend-path> <backend-url>

For example:

ProxyPass / http://127.0.0.1:3000/

This configuration instructs Apache to forward all requests received under / to the backend application running on port 3000.

When a client requests:

http://your-server-ip/about

Apache internally forwards the request to:

http://127.0.0.1:3000/about

The backend application processes the request normally, and Apache returns the response to the client.

The trailing slashes in ProxyPass directives are important because they affect how Apache maps request paths between the frontend and backend URLs. Inconsistent slash usage can produce unexpected routing behavior.

Understanding ProxyPassReverse

The ProxyPassReverse directive rewrites certain backend response headers before Apache returns them to the client.

This becomes necessary because backend applications may generate redirects or response headers that reference internal backend URLs rather than the public-facing proxy URL.

For example, suppose the backend application sends a redirect header like:

Location: http://127.0.0.1:3000/login

Without ProxyPassReverse, the client may receive the internal backend address directly, which can break routing or expose internal infrastructure details.

Adding:

ProxyPassReverse / http://127.0.0.1:3000/

instructs Apache to rewrite those backend-generated headers so the client continues interacting only with the public proxy URL.

In most reverse proxy configurations, ProxyPass and ProxyPassReverse are used together.

Creating a Basic Reverse Proxy VirtualHost

Apache routes traffic using VirtualHost blocks. On Ubuntu, VirtualHost configurations are typically stored under:

/etc/apache2/sites-available/

Create a new VirtualHost configuration file:

sudo nano /etc/apache2/sites-available/reverse-proxy.conf

Add the following configuration:

<VirtualHost *:80>
    ServerName example.com

    ProxyRequests Off

    ProxyPreserveHost On

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

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

This configuration performs several important tasks:

• Apache listens for HTTP traffic on port 80
• Forward proxy functionality is disabled
• Incoming requests are forwarded to the backend application
• Backend redirects are rewritten correctly
• Dedicated access and error logs are created for easier troubleshooting

The ProxyPreserveHost On directive tells Apache to forward the original Host header from the client request instead of replacing it with the backend server’s hostname. Many modern web applications rely on the original host value for routing, redirects, multi-tenant behavior, or framework configuration.

Enabling the VirtualHost Configuration

After saving the file, enable the new site configuration:

sudo a2ensite reverse-proxy.conf

If the default Apache site is still enabled, you may optionally disable it to avoid conflicts:

sudo a2dissite 000-default.conf

Before restarting Apache, validate the configuration syntax:

sudo apache2ctl configtest

If the configuration is valid, Apache returns:

Syntax OK

Now restart Apache:

sudo systemctl restart apache2

Testing the Reverse Proxy

After Apache restarts successfully, test the reverse proxy configuration by visiting:

http://your-server-ip

or:

http://your-domain.com

If the backend application is running correctly, you should see the application content served through Apache rather than directly from the backend server.

You can also test the proxy behavior with curl:

curl -I http://your-server-ip

The response headers should indicate that Apache handled the request while the backend application generated the content.

At this stage, Apache is functioning as a basic reverse proxy.

In a reverse proxy deployment, backend applications do not communicate directly with clients. Instead, all requests first pass through Apache before being forwarded internally to the application server. As a result, backend applications often see the reverse proxy server itself as the source of incoming traffic unless Apache explicitly forwards the original client information through HTTP headers.

Without proper proxy header forwarding, backend applications may log incorrect client IP addresses, generate inaccurate redirects, fail to detect HTTPS connections properly, or apply security rules incorrectly.

To solve this problem, Apache can forward additional request headers that preserve important information about the original client request, including:

• The client IP address
• The original host requested by the client
• The original protocol (HTTP or HTTPS)
• Custom metadata headers

These headers are commonly referred to as proxy headers or forwarded headers.

Why Forwarded Headers Matter

Consider a typical reverse proxy deployment:

Client ---> Apache Reverse Proxy ---> Backend Application

When the backend application receives the request, the TCP connection originates from Apache rather than the client browser. Without forwarded headers, the application may incorrectly interpret:

• Apache’s IP address as the client IP
• Internal backend hostnames as the public hostname
• HTTP as the connection protocol even when the client used HTTPS

This can create several problems in production environments.

For example:

• Application logs may contain only the proxy server’s IP address
• Rate limiting systems may fail because all traffic appears to come from one source
• Authentication systems may incorrectly detect request origins
• Redirects may generate internal URLs instead of public-facing URLs
• Secure cookies may fail if the backend cannot detect HTTPS usage

Forwarded headers allow Apache to preserve the original request context so backend applications can behave correctly.

Preserving the Original Host Header

By default, Apache may replace the incoming Host header with the backend server’s hostname during proxying. Some backend applications rely heavily on the original Host value for routing, domain-based configuration, multi-tenant behavior, or URL generation.

To preserve the original host requested by the client, enable:

ProxyPreserveHost On

For example, if a client requests:

https://app.example.com

Apache forwards the original Host header to the backend application instead of replacing it with:

127.0.0.1:3000

This is especially important for:

• Applications using virtual host routing
• Frameworks that generate absolute URLs
• Multi-domain deployments
• OAuth and authentication callbacks
• Applications behind HTTPS proxies

In most modern reverse proxy deployments, enabling ProxyPreserveHost is recommended unless the backend explicitly requires a different host header.

Forwarding the Original Client IP Address

One of the most commonly forwarded headers is X-Forwarded-For.

This header contains the original client IP address and allows backend applications to identify the real source of requests rather than the proxy server itself.

Apache can append the client IP automatically using:

ProxyAddHeaders On

This directive is enabled by default in many Apache installations, but explicitly enabling it improves configuration clarity.

When enabled, Apache adds headers similar to:

X-Forwarded-For: 203.0.113.25
X-Forwarded-Host: app.example.com
X-Forwarded-Server: proxy-server

The backend application can then read the X-Forwarded-For header to determine the original client IP address.

In environments involving multiple proxies or CDNs, the header may contain a comma-separated list of addresses representing the full proxy chain.

Forwarding HTTPS and Protocol Information

Backend applications often need to know whether the original client connection used HTTP or HTTPS.

This becomes important for:

• Secure cookies
• Redirect generation
• Authentication systems
• CSRF protections
• URL generation

When Apache terminates HTTPS connections at the proxy layer, the backend application may only see an internal HTTP connection unless the protocol information is forwarded explicitly.

A common approach is to add the X-Forwarded-Proto header:

RequestHeader set X-Forwarded-Proto "https"

This tells the backend application that the original client connection used HTTPS even if Apache forwards traffic internally over plain HTTP.

You can also dynamically preserve the protocol using environment variables:

RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}

This configuration automatically forwards either http or https depending on the incoming client request.

Because the RequestHeader directive belongs to the mod_headers module, ensure that mod_headers is enabled:

sudo a2enmod headers

Setting Custom Proxy Headers

Apache also allows administrators to define custom request headers for backend services.

For example:

RequestHeader set X-Proxy-Server "Apache-Reverse-Proxy"

Custom headers are commonly used for:

• Internal service identification
• Debugging and tracing
• Application-specific routing
• API gateway integrations
• Security metadata

You can also unset headers if necessary:

RequestHeader unset X-Unwanted-Header

This provides fine-grained control over the information passed to backend services.

Complete VirtualHost Example with Forwarded Headers

The following example combines several commonly used reverse proxy header settings:

<VirtualHost *:80>
    ServerName example.com

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyAddHeaders On

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}

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

This configuration ensures that backend applications receive:

• The original host requested by the client
• The original client IP address
• The original request protocol
• Properly rewritten redirects

Together, these settings allow backend applications to function correctly behind the Apache reverse proxy layer.

Applying the Configuration Changes

After modifying the VirtualHost configuration, validate the Apache syntax:

sudo apache2ctl configtest

If the syntax is valid, reload Apache:

sudo systemctl reload apache2

Reloading applies the configuration changes without fully restarting the web server.

Verifying Forwarded Headers

You can verify forwarded headers from the backend application itself or by inspecting incoming request headers.

For example, many backend frameworks expose request header information for debugging purposes. Alternatively, you can temporarily configure a simple backend service that echoes request headers to confirm that Apache forwards the expected values.

A properly forwarded request may include headers similar to:

X-Forwarded-For: 203.0.113.25
X-Forwarded-Host: example.com
X-Forwarded-Proto: https

At this point, your reverse proxy configuration preserves the original client request context correctly.

Apache can distribute incoming requests across multiple backend servers using the mod_proxy_balancer module. This approach improves scalability, increases availability, and helps prevent a single application server from becoming overloaded. If you use Nginx instead of Apache at the edge, a similar pattern is covered in How To Set Up Nginx Load Balancing.

In a load-balanced deployment, Apache sits in front of several backend application servers and forwards requests according to a balancing algorithm.

Enabling the Load Balancing Modules

Before configuring load balancing, enable the required Apache modules:

sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

The proxy_balancer module provides Apache’s load balancing framework, while lbmethod_byrequests enables request-based balancing.

After enabling the modules, reload Apache:

sudo systemctl reload apache2

Defining Backend Servers with BalancerMember

Apache groups backend servers into a logical pool using a <Proxy> block. Individual backend servers are added with the BalancerMember directive.

For example:

<Proxy "balancer://mycluster">
    BalancerMember http://127.0.0.1:3001
    BalancerMember http://127.0.0.1:3002
</Proxy>

In this configuration, balancer://mycluster acts as the name of the backend pool, while each BalancerMember entry defines a backend application server.

Apache distributes incoming requests across these backend members automatically.

Configuring the Load Balancing Method

Apache supports multiple balancing algorithms. The most commonly used methods are:

For most deployments, the byrequests method provides a simple and effective balancing strategy.

You can configure the balancing method using ProxySet:

ProxySet lbmethod=byrequests

Configuring Sticky Sessions

Some applications store session data locally on individual backend servers. In these cases, requests from the same client must consistently reach the same backend node. This behavior is commonly called sticky sessions or session persistence.

Apache supports sticky sessions using the stickysession option.

For example:

<Proxy "balancer://mycluster">
    BalancerMember http://127.0.0.1:3001 route=node1
    BalancerMember http://127.0.0.1:3002 route=node2

    ProxySet lbmethod=byrequests stickysession=ROUTEID
</Proxy>

In this configuration, each backend server is assigned a route identifier. The backend application must then set a cookie containing the matching route value so Apache can route future requests from the same client to the correct backend server.

Sticky sessions are commonly used in applications that do not use shared session storage.

Complete Load Balancer Configuration Example

The following example configures Apache as a reverse proxy load balancer with two backend application servers:

<VirtualHost *:80>
    ServerName example.com

    ProxyRequests Off
    ProxyPreserveHost On

    <Proxy "balancer://mycluster">
        BalancerMember http://127.0.0.1:3001
        BalancerMember http://127.0.0.1:3002

        ProxySet lbmethod=byrequests
    </Proxy>

    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/

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

In this configuration, Apache receives incoming requests on port 80 and distributes them evenly between two backend application servers.

Testing the Load Balancer

After saving the configuration file, verify the Apache syntax:

sudo apache2ctl configtest

If the configuration is valid, reload Apache:

sudo systemctl reload apache2

You can then test the load balancer by sending repeated requests to the proxy server:

curl http://your-server-ip

If the backend applications return different responses, you should see Apache alternating traffic between the backend servers.

At this point, Apache can distribute traffic across multiple backend servers using mod_proxy_balancer.

In many production deployments, Apache handles HTTPS connections at the reverse proxy layer instead of requiring every backend application server to manage its own SSL/TLS configuration. This approach is commonly referred to as SSL termination or TLS offloading.

With SSL termination, the client establishes an encrypted HTTPS connection with Apache. Apache decrypts the traffic and then forwards the request internally to the backend application over either HTTP or HTTPS.

Centralizing TLS handling at the proxy layer simplifies certificate management, reduces configuration duplication across backend servers, and allows Apache to enforce consistent HTTPS policies.

Enabling the SSL Module

Before configuring HTTPS VirtualHosts, enable Apache’s SSL module:

sudo a2enmod ssl

After enabling the module, reload Apache:

sudo systemctl reload apache2

Obtaining an SSL Certificate

To configure HTTPS, you need a valid SSL certificate and private key. For local testing, you can create a self-signed certificate for Apache.

For production environments, certificates are commonly issued by Let’s Encrypt or a commercial certificate authority.

Ubuntu systems typically store SSL certificates under directories such as:

/etc/ssl/certs/

and private keys under:

/etc/ssl/private/

If you use Let’s Encrypt with Certbot, certificate files are typically located under /etc/letsencrypt/live/your-domain/.

Configuring HTTPS Reverse Proxying

Create or edit your HTTPS VirtualHost configuration:

sudo nano /etc/apache2/sites-available/reverse-proxy-ssl.conf

Add a configuration similar to the following:

<VirtualHost *:443>
    ServerName example.com

    SSLEngine On
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyAddHeaders On

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    RequestHeader set X-Forwarded-Proto "https"

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

In this configuration, Apache accepts HTTPS traffic on port 443, decrypts the client connection, and forwards requests to the backend application running on port 3000.

The X-Forwarded-Proto header informs the backend application that the original client request used HTTPS.

Proxying to HTTPS Backends

In some environments, backend application servers also use HTTPS. In these cases, Apache must establish an encrypted connection to the backend server as well.

To allow HTTPS proxy connections, enable:

SSLProxyEngine On

You can then proxy requests to an HTTPS backend:

ProxyPass / https://127.0.0.1:8443/
ProxyPassReverse / https://127.0.0.1:8443/

Without SSLProxyEngine On, Apache refuses HTTPS proxy connections to backend servers.

Configuring Backend Certificate Verification

When proxying to HTTPS backends, Apache can verify backend SSL certificates to prevent insecure or untrusted connections.

Certificate verification is controlled with directives such as:

SSLProxyVerify require
SSLProxyCheckPeerName On
SSLProxyCheckPeerExpire On

These settings instruct Apache to:

• Verify that the backend certificate is trusted
• Validate the backend hostname
• Check whether the certificate has expired

In internal development or testing environments, administrators sometimes disable certificate verification for self-signed certificates:

SSLProxyVerify none
SSLProxyCheckPeerName Off

However, disabling verification reduces security and should generally be avoided in production environments.

Redirecting HTTP Traffic to HTTPS

Most production reverse proxy deployments redirect all HTTP traffic to HTTPS.

You can create a separate HTTP VirtualHost for redirection:

<VirtualHost *:80>
    ServerName example.com

    Redirect permanent / https://example.com/
</VirtualHost>

This ensures all client traffic uses encrypted HTTPS connections.

Enabling the HTTPS Site

After saving the configuration, enable the site:

sudo a2ensite reverse-proxy-ssl.conf

Verify the Apache configuration syntax:

sudo apache2ctl configtest

If the syntax is valid, reload Apache:

sudo systemctl reload apache2

Testing HTTPS Proxying

After Apache reloads successfully, test the HTTPS reverse proxy by visiting:

https://your-domain.com

You can also verify the SSL connection using curl:

curl -I https://your-domain.com

If the configuration is working correctly, Apache should terminate the HTTPS connection and proxy requests successfully to the backend application.

At this point, Apache is handling encrypted client traffic at the reverse proxy layer.

After configuring Apache as a reverse proxy, it is important to secure the proxy layer properly. A poorly configured reverse proxy can expose backend infrastructure, allow unintended proxy behavior, or create unnecessary attack surfaces.

Ensure Forward Proxying Is Disabled

One of the most critical security settings is disabling forward proxy functionality.

Always ensure the following directive is present:

ProxyRequests Off

If forward proxying is enabled unintentionally, Apache may function as an open proxy that allows external users to relay traffic through your server. Open proxies are frequently abused for spam, malicious traffic routing, and anonymity services.

For most reverse proxy deployments, ProxyRequests Off should be set globally or inside every proxy-enabled VirtualHost.

Restrict Proxy Access with <Proxy> Blocks

Apache allows administrators to define access control rules for proxied resources using <Proxy> and <ProxyMatch> containers.

For example:

<Proxy "*">
    Require all denied
</Proxy>

This configuration denies access to all forward proxy destinations unless explicitly allowed.

You can also restrict access to specific backend paths or internal services:

<Proxy "http://127.0.0.1:3000/admin">
    Require ip 192.168.1.0/24
</Proxy>

Access controls become especially important in environments exposing internal applications through the reverse proxy layer.

Hide Backend and Server Information

By default, Apache and backend applications may expose unnecessary information through response headers such as:

Server: Apache/2.4.58
X-Powered-By: Express

These headers can reveal software versions and backend technologies that attackers may use for reconnaissance.

You can reduce information exposure by disabling or modifying headers.

First, reduce Apache version disclosure:

ServerTokens Prod
ServerSignature Off

Next, remove backend-specific headers using mod_headers:

Header unset X-Powered-By

ServerTokens Prod
ServerSignature Off

Backend-generated Server headers may require separate handling depending on the application stack.

These settings help minimize publicly exposed infrastructure details.

Configure Timeouts Carefully

Improper timeout settings can leave Apache vulnerable to resource exhaustion attacks or long-hanging backend connections.

Several directives help control proxy connection behavior:

ProxyTimeout 30
Timeout 60

The ProxyTimeout directive controls how long Apache waits for responses from backend servers, while Timeout affects general request handling behavior.

Choosing reasonable timeout values helps prevent stalled backend connections from consuming Apache worker resources indefinitely.

Apply Rate Limiting When Necessary

Public-facing reverse proxies may benefit from request rate limiting to reduce abusive traffic or denial-of-service attempts.

Apache provides several modules for traffic control, including:

• mod_ratelimit
• mod_evasive
• mod_qos

For example, mod_ratelimit can limit response bandwidth for specific content types or locations.

Although advanced rate limiting is outside the scope of this tutorial, implementing some form of request throttling is often beneficial for internet-facing services.

Restrict Access to Administrative Interfaces

Administrative endpoints such as Balancer Manager should never be exposed publicly without restrictions.

For example:

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require local
</Location>

If remote administrative access is required, restrict access using IP-based rules or authentication.

Leaving management interfaces publicly accessible can expose backend infrastructure details and balancing controls.

Test for Open Proxy Behavior

After configuring the reverse proxy, verify that Apache is not functioning as an unintended forward proxy.

You can perform a simple test with curl:

curl -x http://your-server-ip:80 http://example.com

If Apache correctly rejects the request, the server is not operating as an open proxy.

If the request succeeds unexpectedly, immediately verify:

• ProxyRequests Off is configured
• No permissive <Proxy> rules exist
• No unintended forward proxy modules or configurations are enabled

Keep Apache and Modules Updated

Because reverse proxies sit directly at the network edge, keeping Apache updated is essential.

Regularly update system packages with:

sudo apt update
sudo apt upgrade

Security updates frequently include fixes for:

• HTTP parsing vulnerabilities
• TLS weaknesses
• Request smuggling issues
• Denial-of-service vulnerabilities
• Module-specific security flaws

Applying updates promptly reduces exposure to publicly known vulnerabilities.

Validate Configuration Changes

After making security-related changes, always verify the Apache configuration syntax:

sudo apache2ctl configtest

If the syntax is valid, reload Apache:

sudo systemctl reload apache2

At this point, your Apache reverse proxy configuration is significantly more secure and production-ready.

Even small mistakes in reverse proxy configurations can cause Apache to fail to connect to backend services correctly. Misconfigured backend addresses, missing modules, SSL verification problems, or incorrect header handling can all lead to proxy-related errors.

When troubleshooting Apache reverse proxy issues, the first place to check is the Apache error log:

/var/log/apache2/error.log

You can monitor the log in real time with:

sudo tail -f /var/log/apache2/error.log

Apache configuration validation is also important before reloading the service:

sudo apache2ctl configtest

If Apache reports:

Syntax OK

the configuration syntax is valid.

The following sections cover several common mod_proxy errors and how to diagnose them.

502 Bad Gateway

A 502 Bad Gateway error usually means Apache could not successfully communicate with the backend application server.

Common causes include:

• The backend application is not running
• The backend is listening on the wrong port
• Firewall restrictions block the connection
• Incorrect ProxyPass target URLs
• Backend crashes or timeouts

For example, if Apache proxies requests to:

ProxyPass / http://127.0.0.1:3000/

but no application is listening on port 3000, Apache returns a 502 error.

Start by verifying that the backend service is running:

sudo ss -tulpn | grep 3000

You can also test the backend directly:

curl http://127.0.0.1:3000

If the backend does not respond locally, the issue is with the application rather than Apache.

The Apache error log often includes messages similar to:

AH01114: HTTP: failed to make connection to backend

which usually indicates connection failures between Apache and the backend server.

503 Service Unavailable

A 503 Service Unavailable error commonly appears in load-balanced environments using mod_proxy_balancer.

This error typically indicates that Apache considers all backend workers unavailable.

Common causes include:

• All backend servers are offline
• Health checks are failing
• Incorrect BalancerMember definitions
• Backend timeouts
• DNS resolution failures

Example configuration:

<Proxy "balancer://mycluster">
    BalancerMember http://127.0.0.1:3001
    BalancerMember http://127.0.0.1:3002
</Proxy>

Verify that every backend member is reachable:

curl http://127.0.0.1:3001
curl http://127.0.0.1:3002

If one or more backend servers are unavailable, Apache may temporarily disable them until they recover.

The error log may contain entries similar to:

AH01170: balancer://mycluster: All workers are in error state

which indicates that Apache could not route traffic to any healthy backend server.

SSL Handshake Failures to HTTPS Backends

When proxying requests to HTTPS backend servers, Apache may fail during SSL negotiation.

Common causes include:

• Invalid or expired backend certificates
• Self-signed certificates
• Hostname mismatches
• Missing SSLProxyEngine On
• Certificate verification failures

For example:

SSLProxyEngine On

ProxyPass / https://127.0.0.1:8443/

If certificate verification fails, Apache may log errors similar to:

AH02039: Certificate Verification: Error

For internal testing environments using self-signed certificates, administrators sometimes temporarily disable verification:

SSLProxyVerify none
SSLProxyCheckPeerName Off

However, certificate verification should remain enabled in production whenever possible.

You can also test backend HTTPS connectivity directly:

curl -k https://127.0.0.1:8443

Header Forwarding Not Working Correctly

Backend applications may fail to detect the original client IP address, hostname, or HTTPS status if forwarded headers are missing or misconfigured.

Common symptoms include:

• Applications showing the proxy IP instead of the client IP
• Incorrect redirect URLs
• Secure cookies not working
• HTTPS detection failures

Verify that the relevant directives are configured:

ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}

Also ensure the mod_headers module is enabled:

sudo a2enmod headers

You can inspect forwarded headers from the backend application or by using debugging endpoints that display request headers.

Module Not Found or Unknown Directive Errors

Apache returns module-related errors when required proxy modules are not enabled.

Common examples include:

Invalid command 'ProxyPass'

or:

Invalid command 'RequestHeader'

These errors indicate that the associated Apache modules are missing or disabled.

Enable the required modules:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod headers

Then reload Apache:

sudo systemctl reload apache2

You can verify loaded modules with:

apache2ctl -M

Diagnosing Backend Connectivity Problems

If Apache cannot reach the backend server, verify:

• The backend service is running
• The correct IP address and port are configured
• No firewall rules block local traffic
• The backend listens on the expected interface

Useful diagnostic commands include:

ss -tulpn
curl http://127.0.0.1:3000

Testing the backend directly helps isolate whether the problem exists in Apache or in the backend application itself.

Reload Apache After Configuration Changes

After fixing configuration issues, always validate and reload Apache:

sudo apache2ctl configtest
sudo systemctl reload apache2

Using reload instead of restart applies configuration changes without fully interrupting active connections.

At this point, you have configured Apache as a reverse proxy using the mod_proxy module family, including support for forwarded headers, load balancing, SSL termination, WebSocket proxying, and basic security hardening.

1. What is the difference between ProxyPass and ProxyPassReverse?

ProxyPass maps incoming request URLs to a backend server URL. ProxyPassReverse rewrites Location, Content-Location, and URI headers in the backend response so redirects issued by the backend return the correct frontend URL to the client instead of the internal backend address.

2. Do I need to set ProxyRequests On to use Apache as a reverse proxy?

No. ProxyRequests On enables forward proxying, which allows external clients to route arbitrary traffic through your server. For a reverse proxy, keep ProxyRequests Off and use only ProxyPass directives to define specific backend mappings. Leaving ProxyRequests On without access controls creates an open proxy.

3. Which mod_proxy submodule is required for HTTP and HTTPS backend connections?

mod_proxy_http is required for proxying over HTTP and HTTPS protocols. The base mod_proxy module alone is not sufficient; mod_proxy_http must also be loaded. For HTTPS backends, mod_ssl with SSLProxyEngine On is additionally required.

4. How do I enable mod_proxy on Ubuntu or Debian?

Run sudo a2enmod proxy proxy_http and then sudo systemctl restart apache2. To add load balancing support, also enable proxy_balancer and a balancing algorithm module such as lbmethod_byrequests.

5. How does Apache mod_proxy compare to Nginx as a reverse proxy?

Apache mod_proxy integrates tightly with existing Apache-based server configurations and supports a wide module ecosystem. Nginx is generally preferred for high-concurrency reverse proxy workloads because of its event-driven, non-blocking architecture, as discussed in Apache vs Nginx: Practical Considerations. For an Nginx-based alternative, see How To Configure Nginx as a Reverse Proxy on Ubuntu. For servers already running Apache, mod_proxy adds reverse proxy capability without introducing a second web server process.

6. Can Apache mod_proxy handle WebSocket connections?

Yes. The mod_proxy_wstunnel submodule handles WebSocket proxying. You can use ProxyPass directives with the ws:// or wss:// scheme to forward WebSocket traffic to backend applications. The mod_proxy_wstunnel module must be enabled alongside mod_proxy.

7. What causes a 502 Bad Gateway error when using mod_proxy?

A 502 error usually means Apache could not communicate successfully with the backend application server, or the backend returned an invalid response. Common causes include the backend service not running, the backend listening on a different port than configured in ProxyPass, a firewall blocking the connection between the proxy and backend, or a timeout being exceeded. Check Apache’s error.log and confirm the backend is reachable from the proxy server with curl or nc (netcat).

8. How do I pass the original client IP address to the backend when using mod_proxy?

Enable ProxyAddHeaders On and ProxyPreserveHost On inside the VirtualHost block. Apache automatically appends headers such as X-Forwarded-For and X-Forwarded-Host. If you terminate SSL at the proxy, also set X-Forwarded-Proto with RequestHeader so backends can detect HTTPS connections.

In this tutorial, you configured Apache as a reverse proxy on Ubuntu using the mod_proxy module family. You installed Apache, enabled the required proxy modules, set up basic request forwarding with ProxyPass and ProxyPassReverse, preserved client information through forwarded headers, distributed traffic across multiple backend servers with mod_proxy_balancer, and configured SSL termination at the proxy layer. You also applied security hardening measures to protect the proxy configuration and reviewed how to diagnose common mod_proxy errors in production.

With this foundation, you can extend your reverse proxy setup to support more advanced configurations, such as path-based routing to multiple applications, WebSocket proxying with mod_proxy_wstunnel, or integrating health checks using mod_proxy_hcheck. For further reading, consult the Apache mod_proxy documentation or check out the following tutorials:

• How to Install the Apache Web Server on Ubuntu
• How To Set Up Apache Virtual Hosts on Ubuntu
• How To Secure Apache with Let’s Encrypt on Ubuntu
• How To Configure Apache HTTP with MPM Event and PHP-FPM
• How To Set Up a Node.js Application for Production on Ubuntu
• How To Serve Flask Applications with Gunicorn and Nginx on Ubuntu
• How To Configure Nginx as a Reverse Proxy on Ubuntu
• Apache vs Nginx: Practical Considerations