La directiva ProxyPass especifica el mapeo de peticiones entrantes al servidor backend (o un cluster de servidores conocido como grupo de Balanceo). El ejemplo más sencillo hace proxy de todas las solicitudes ("/") a un solo backend:

Para asegurarse de ello y que las cabeceras Location: generadas en el backend se modifican para apuntar al proxy inverso, en lugar del propio backend, la directiva ProxyPassReverse suele ser necesaria a menudo:

Solo se hará proxy de ciertas URIs, como se muestra en este ejemplo:

En este ejemplo, se hará proxy al backend especificado de cualquier solicitud que comience con la ruta/images/, si no se gestionarán localmente.

Aunque los ejemplos de más arriba son útiles, tienen la deficiencia en la que si el backend cae, o recibe mucha carga, hacer proxy de esas solicitudes no aporta grandes beneficios. Lo que se necesita es la habilidad de definir un grupo de servidores backend que puedan gestionar esas peticiones y que el proxy inverso pueda balancear la carga y aplicar tolerancia a fallos entre los backend. A veces a este grupo se le llama cluster, pero el término para Apache httpd es balanceador. Se puede definir un balanceador usando las directivas Proxy and BalancerMember como sigue:

El esquema balancer:// es lo que le dice a httpd que estamos generando un grupo de balanceo, con el nombre myset. Incluye 2 servidores backend, que httpd llama BalancerMember. En este caso, se hará proxy inverso de cualquier petición para /images/ haćia uno de los 2 backend. La directiva ProxySet especifica que el Balanceador myset usa un algoritmo que balancea basado en los bytes de entrada/salida (I/O).

Puede ajustar numerosos parámetros de los balanceadores y los workers definiéndolos a través de la directiva ProxyPass. Por ejemplo, asumiendo que quisieramos que http://www3.example.com:8080 gestionara 3 veces más tráfico con un timeout de 1 segundo, ajustaríamos la configuración como sigue:

Puede también ajustar varios escenarios de tolerancia a fallos, detallando qué workers e incluso balanceadores deberían usarse en tales casos. Por ejemplo, la siguiente configuración implementa 2 casos de tolerancia a fallos: En el primero, solo se envía tráfico a http://hstandby.example.com:8080 si todos los demás workers en el balanceador myset no están disponibles. Si ese worker tampoco está disponible, solo entonces los workers de http://bkup1.example.com:8080 y http://bkup2.example.com:8080 serán incluidos en la rotación:

La "magia" de esta configuración de tolerancia a fallos es configurar http://hstandby.example.com:8080 con la marca de estado +H, que lo pone en modo hot standby (en reserva), y hace que los 2 servidores bkup# parte del set nº 1 de balanceo de carga (el valor por defecto es 0); para tolerancia a fallos, Los "hot standby" (si existen) se usan primero cuando todos los workers activos están indisponibles; los set de balanceo con números inferiores se usan siempre primero.

Una de las carasterísticas más útiles y singulares de los proxy inverso de Apache httpd es la aplicación embebida balancer-manager. Similar a mod_status, balancer-manager muestra la configuración actual que está funcionando y el estado de los balanceadores activados y workers que están en uso en ese momento. Aun así, no solo muestra estos parámetros, también permite reconfiguración dinámica, en tiempo real, de prácticamente todos ellos, incluido añadir nuevos BalancerMember (workers) a un balanceo existente. Para activar esta capacidad, se tiene que añadir lo siguiente a la configuración:

Cuando se accede al proxy inverso en la url (p.e: http://rproxy.example.com/balancer-manager/, verá una página similar a la siguiente:

Este formulario permite al administrador ajustar varios parámetros, desactivar workers, cambiar los métodos de balanceo de carga y añadir nuevos workers. Por ejemplo, haciendo click en el balanceador, verá la siguiente página:

Y haciendo click en el worker, mostrará esta página:

Para hacer que estos cambios sean persistentes en los reinicios del proxy inverso, asegúrese de que BalancerPersist está activado.

Antes de que httpd haga proxy de una petición a un worker, puede "comprobar" si ese worker está disponible mediante el parámetro de configuración ping para ese worker usando ProxyPass. A menudo es más útil comprobar el estado de los workers no disponibles, con un método dinámico. Esto se consigue con el módulo mod_proxy_hcheck.

En el balancer-manager el estado actual, o status, de un worker se muestra y puede ser configurado/reseteado. El significado de estos estados es como sigue: