Reverse Proxy Guide

In addition to being a "basic" web server, and providing static and
dynamic content to end-users, Apache httpd (as well as most other web
servers) can also act as a reverse proxy server, also-known-as a
"gateway" server.

In such scenarios, httpd itself does not generate or host the data,
but rather the content is obtained by one or several backend servers,
which normally have no direct connection to the external network. As
httpd receives a request from a client, the request itself is proxied
to one of these backend servers, which then handles the request, generates
the content and then sends this content back to httpd, which then
generates the actual HTTP response back to the client.

There are numerous reasons for such an implementation, but generally
the typical rationales are due to security, high-availability, load-balancing
and centralized authentication/authorization. It is critical in these
implementations that the layout, design and architecture of the backend
infrastructure (those servers which actually handle the requests) are
insulated and protected from the outside; as far as the client is concerned,
the reverse proxy server is the sole source of all content.

See also

The ProxyPass
directive specifies the mapping of incoming requests to the backend
server (or a cluster of servers known as a Balancer
group). The simpliest example proxies all requests ("/")
to a single backend:

ProxyPass "/" "http://www.example.com/"

To ensure that and Location: headers generated from
the backend are modified to point to the reverse proxy, instead of
back to itself, the ProxyPassReverse
directive is most often required:

As useful as the above is, it still has the deficiencies that should
the (single) backend node go down, or become heavily loaded, that proxying
those requests provides no real advantage. What is needed is the ability
to define a set or group of backend servers which can handle such
requests and for the reverse proxy to load balance and failover among
them. This group is sometimes called a cluster but Apache httpd's
term is a balancer. One defines a balancer by leveraging the
<Proxy> and
BalancerMember directives as
shown:

The balancer:// scheme is what tells httpd that we are creating
a balancer set, with the name myset. It includes 2 backend servers,
which httpd calls BalancerMembers. In this case, any requests for
/images will be proxied to one of the 2 backends.
The ProxySet directive
specifies that the myset Balancer use a load balancing algorithm
that balances based on I/O bytes.

Hint

You can adjust numerous configuration details of the balancers
and the workers via the various parameters defined in
ProxyPass. For example,
assuming we would want http://www3.example.com:8080 to
handle 3x the traffic with a timeout of 1 second, we would adjust the
configuration as follows:

You can also fine-tune various failover scenarios, detailing which
workers and even which balancers should accessed in such cases. For
example, the below setup implements 2 failover cases: In the first,
http://hstandby.example.com:8080 is only sent traffic
if all other workers in the myset balancer are not available.
If that worker itself is not available, only then will the
http://bkup1.example.com:8080 and http://bkup2.example.com:8080
workers be brought into rotation:

The magic of this failover setup is setting http://hstandby.example.com:8080
with the +H status flag, which puts it in hot standby mode,
and making the 2 bkup# servers part of the #1 load balancer set (the
default set is 0); for failover, hot standbys (if they exist) are used 1st, when all regular
workers are unavailable; load balancer sets are always tried lowest number first.

One of the most unique and useful features of Apache httpd's reverse proxy is
the embedded balancer-manager application. Similar to
mod_status, balancer-manager displays
the current working configuration and status of the enabled
balancers and workers currently in use. However, not only does it
display these parameters, it also allows for dynamic, runtime, on-the-fly
reconfiguration of almost all of them, including adding new BalancerMembers
(workers) to an existing balancer. To enable these capability, the following
needs to be added to your configuration:

Warning

Do not enable the balancer-manager until you have secured your server. In
particular, ensure that access to the URL is tightly
restricted.

When the reverse proxy server is accessed at that url
(eg: http://rproxy.example.com/balancer-manager/, you will see a
page similar to the below:

This form allows the devops admin to adjust various parameters, take
workers offline, change load balancing methods and add new works. For
example, clicking on the balancer itself, you will get the following page:

Whereas clicking on a worker, displays this page:

To have these changes persist restarts of the reverse proxy, ensure that
BalancerPersist is enabled.

Before httpd proxies a request to a worker, it can "test" if that worker
is available via setting the ping parameter for that worker using
ProxyPass. Oftentimes it is
more useful to check the health of the workers out of band, in a
dynamic fashion. This is achieved in Apache httpd by the
mod_proxy_hcheck module.

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.