VMware ESXi and vSphere Cluster Management

Configure Apache HTTP Server as a Reverse Proxy

Learn to configure Apache on Debian or Ubuntu as a secure reverse proxy for an HTTP backend, including modules, virtual hosts, access rules, testing, and troubleshooting.

A reverse proxy is a frontend server that accepts client requests and forwards them to one or more backend, or origin, services. In this lesson, Apache HTTP Server accepts requests for a hostname and sends them to an upstream HTTP server.

Clients connect to Apache using the public or internal proxy hostname. They do not need proxy-specific client settings. Apache chooses the upstream destination from its configuration, receives the backend response, and returns that response to the client under the proxy hostname.

This differs from direct origin access. With direct access, the client connects to the backend server itself. With reverse proxying, the backend can remain on a private network while Apache provides the client-facing endpoint.

How a reverse proxy is used

  • Publish an internal application through a reachable Apache server.
  • Place backend systems behind a firewall or another network boundary.
  • Provide a stable frontend hostname even when the backend service changes.
  • Centralize access control, logging, TLS termination, and request handling.
  • Distribute requests across several backends when load-balancing features are configured.

A single ProxyPass target is not load balancing. Load balancing requires additional configuration, such as Apache's proxy-balancer modules and multiple backend members.

Reverse proxy versus forward proxy

A forward proxy represents clients. A client deliberately sends requests through it to reach arbitrary remote resources. A reverse proxy represents servers: clients request a known frontend hostname, and the frontend selects the backend.

Characteristic — Reverse proxy — Forward proxy

Who configures it — The service or site administrator — The client or client network administrator

Who it represents — Backend servers — Clients

Typical use case — Publish and protect applications — Control or filter outbound client traffic

Client awareness — Usually transparent to clients — Clients must use the proxy explicitly

ProxyRequests — Must be Off — Usually On

Primary security concern — Exposing an unintended application or backend — Becoming an open proxy

ProxyRequests controls forward-proxy behavior. It must be disabled for this reverse-proxy setup. If it is enabled on an exposed server, unauthorized users may use Apache to proxy arbitrary destinations, creating an unsafe open proxy.

ProxyVia controls how Apache handles Via headers in proxied HTTP messages. The setting should match the header-handling policy for your environment. The example below uses ProxyVia On.

Prerequisites

  • A Debian- or Ubuntu-style system with Apache installed.
  • Basic knowledge of sudo, Apache services, virtual hosts, and HTTP.
  • A hostname that resolves to the Apache server, using DNS or a local hosts-file entry.
  • An HTTP backend reachable from the Apache host.
  • Knowledge of the private network and firewall rules that should protect the service.

Apache modules required for HTTP proxying

mod_proxy is Apache's core proxy framework. mod_proxy_http adds support for proxying HTTP requests to HTTP upstreams. It is also involved when Apache proxies to HTTPS upstreams, which additionally requires suitable TLS configuration such as SSLProxyEngine On.

mod_proxy_connect implements the HTTP CONNECT method, primarily for tunneling in a forward proxy. It is not normally required for a basic HTTP reverse proxy.

sudo a2enmod proxy proxy_http

Only enable CONNECT support when you intentionally need CONNECT tunneling and have designed appropriate restrictions:

sudo a2enmod proxy_connect

Verify that the modules are loaded before testing the site:

apache2ctl -M | grep -E 'proxy_module|proxy_http_module|proxy_connect_module'

Item — Purpose — Used in basic HTTP reverse proxy — Important notes

mod_proxy — Core proxy framework — Yes — Required by proxy features

mod_proxy_http — HTTP and HTTP-based upstream proxying — Yes — Required for an HTTP backend

mod_proxy_connect — CONNECT tunneling — No — Mainly relevant to controlled forward proxies

ProxyRequests — Enables forward-proxy requests — No; keep it Off — Prevents an open proxy

ProxyVia — Controls Via headers — Policy-dependent — Configure deliberately

ProxyPass — Maps a local path to an upstream URL — Yes — Defines reverse-proxy routing

ProxyPassReverse — Rewrites suitable backend redirects — Yes — Helps redirects use the public URL

Require ip — Restricts clients by source IP or network — Optional — Uses Apache 2.4 authorization syntax

Global Apache proxy configuration

On Debian and Ubuntu, distribution-managed module configuration is commonly stored under /etc/apache2/mods-enabled/. The proxy settings are commonly found in /etc/apache2/mods-enabled/proxy.conf. This file is global module configuration, not a site-specific virtual host.

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

Ensure the forward proxy is disabled and apply the chosen Via-header policy:

ProxyRequests Off
ProxyVia On

Do not use a broad proxy authorization rule as a substitute for application access control. ProxyPass defines where reverse-proxy requests go. A proxy access-control block governs permission to use proxy functions, especially forward-proxy behavior; it is not normally the main mechanism for protecting a reverse-proxied application.

Location — Purpose — Example content

/etc/apache2/mods-enabled/ — Enabled module configuration — proxy.conf and module load files

/etc/apache2/sites-available/ — Definitions for available virtual hosts — reverse_proxy.conf

/etc/apache2/sites-enabled/ — Enabled site definitions, usually symbolic links — The enabled reverse-proxy site

Create the reverse-proxy virtual host

Create a site file in the available-sites directory. The example uses msn.local as the client-facing hostname and www.msn.com as the upstream example from the scenario. Replace both values with names appropriate for your environment.

sudoedit /etc/apache2/sites-available/reverse_proxy.conf
<VirtualHost *:80>
    ServerName msn.local

    ProxyPass        /  http://www.msn.com/
    ProxyPassReverse /  http://www.msn.com/

    <Location />
        Require ip 192.168.0.0/16
    </Location>
</VirtualHost>

Understanding the virtual-host directives

  • <VirtualHost *:80> defines a site listening on HTTP port 80 on the available local addresses.
  • ServerName msn.local identifies the hostname clients request. Apache uses the request's Host header to select the matching virtual host.
  • ProxyPass / http://www.msn.com/ maps the public root path to the upstream root URL.
  • ProxyPassReverse / http://www.msn.com/ adjusts suitable response redirects from the backend so clients can continue using the proxy-facing hostname.
  • Require ip 192.168.0.0/16 allows clients from the specified private network. Replace this with the actual permitted address or CIDR range.

Keep trailing slashes consistent. If the source path ends in /, the destination URL should normally end in / as well. For example, mapping /app/ to http://backend.example/app/ avoids surprising path concatenation behavior.

Choosing the Host header behavior

By default, Apache may send a Host header based on the upstream URL. Some applications require the original public hostname, while others require the backend hostname for virtual-host routing. Preserve the client Host header only when the backend is designed for it; otherwise, use the backend's expected host value. Test this explicitly because it can affect routing, cookies, absolute URLs, and application security checks.

Restrict access correctly

Apache 2.4 uses authorization directives such as Require ip. Put the rule in the virtual host or a suitable Location section for the frontend path that needs protection.

<Location /internal/>
    Require ip 192.168.0.0/16
</Location>

This restricts frontend clients as seen by Apache. It does not replace firewall rules between Apache and the backend. Use network controls to ensure that only approved systems can reach the backend port, and use Apache authorization to control which clients may use the frontend. Avoid broad proxy permissions or rules that accidentally allow arbitrary destinations.

Enable and apply the site

  1. Make sure DNS or a hosts-file entry maps the chosen ServerName to the Apache host.
  2. Enable the site:
sudo a2ensite reverse_proxy.conf
  1. Validate the complete Apache configuration:
sudo apache2ctl configtest

Continue only when the result is Syntax OK. Then reload Apache without interrupting existing connections where possible:

sudo systemctl reload apache2

A restart can be used when a reload is unsuitable:

sudo systemctl restart apache2

To inspect how Apache maps names to virtual hosts, use:

sudo apache2ctl -S

Request flow and verification

The request path is:

  1. An internal client requests http://msn.local/.
  2. DNS or the hosts file directs that hostname to Apache.
  3. Apache matches the ServerName and applies the virtual-host rules.
  4. ProxyPass selects http://www.msn.com/ as the upstream destination.
  5. The backend sends a response to Apache.
  6. Apache returns the response to the client under the msn.local hostname.

The client does not choose the upstream destination. That destination is selected by Apache's configuration.

curl -I http://msn.local/

For a more complete request, use verbose output:

curl -v http://msn.local/

Check the status code, response headers, and especially any Location header. Review the Apache access and error logs while testing. A proxied request should appear in the frontend Apache logs, and proxy connection failures generally produce useful error-log messages. A locally served file or the wrong default site often indicates hostname, site-enablement, or virtual-host selection problems.

Operational and security considerations

  • Keep ProxyRequests Off unless you are deliberately building a controlled forward proxy.
  • Use least-privilege client authorization and backend firewall rules.
  • For production HTTP services, consider HTTPS termination at Apache and configure TLS protocols, certificates, redirects, and security headers appropriately.
  • When proxying to an HTTPS backend, configure upstream TLS deliberately and consider certificate and hostname verification rather than blindly trusting the backend.
  • Document access and error logging, backend availability, timeout behavior, connection limits, and redirect handling.
  • Ensure the application knows its public base URL when it generates absolute links, redirects, or secure cookies.
  • Monitor backend failures and latency; a reverse proxy cannot make an unavailable backend healthy.

Troubleshooting

Invalid ProxyPass directive or unavailable proxy handler

Usually mod_proxy or mod_proxy_http is missing, or Apache was not reloaded after enabling the modules.

sudo a2enmod proxy proxy_http
sudo apache2ctl configtest
sudo systemctl reload apache2

403 Forbidden

The client address may not match the Require ip rule, or authorization may be applied in the wrong scope. Confirm the source address Apache sees, correct the CIDR range, and inspect the access and error logs.

502 Bad Gateway or 503 Service Unavailable

Apache may be unable to resolve or reach the backend, the service may be stopped, or the protocol, hostname, port, or path in ProxyPass may be wrong. Test name resolution and connectivity from the Apache host, then verify firewall paths and the upstream URL.

Redirects expose the backend hostname

Check that ProxyPassReverse matches the same source and destination paths as ProxyPass. Inspect the backend's Location response header. If redirects remain incorrect, the application may be generating absolute URLs and need its public base URL configured.

The wrong virtual host handles the request

Verify that the requested hostname resolves to Apache, that ServerName matches the client's Host header, and that the site is enabled. Run apache2ctl -S to inspect Apache's virtual-host map.

Apache behaves like an unintended forward proxy

Set ProxyRequests Off, reload Apache, and review all proxy-related configuration and access rules. Never expose unrestricted forward-proxy functionality to untrusted clients.

Exam-relevant notes

  • mod_proxy provides the proxy framework; mod_proxy_http is needed for HTTP upstreams.
  • ProxyRequests Off is the essential reverse-proxy safety setting.
  • ProxyPass routes requests; ProxyPassReverse handles suitable backend redirects.
  • ProxyVia controls Via-header behavior and is separate from routing.
  • Require ip is Apache 2.4 authorization syntax for source-network restrictions.
  • Always run apache2ctl configtest before reloading or restarting Apache.
  • A single ProxyPass destination does not provide load balancing.

For this lesson's complete configuration path, see Configure Apache As A Reverse Proxy.