Problems you can have with applications behind a reverse proxy:
- If the language or app uses IP addresses to keep sessions, the only IP address reaching the application will be the proxy ones. Using
varnish you can add the
X-Forwarded-for header with the original IP address and make the app recognize it.
- Session handling in load balanced environments is tricky. You must use a shared resource for the servers to keep their session information so a logged user can reach any of the backends of a load balanced apps and keep its session. Databases and Memcached are popular choices for session sharing.
- If the reverse proxied app uses absolute URLs on their responses, they may break the rewriting on the proxy. I.e. an app that does 302 redirects to an URL different than the proxy one.
I currently use nginx on the frontend and varnish behind it to do proxy and load balancing/backend checking. As a single point of failure, is very important to use a cluster solution on the reverse proxy/load balancer.
I use corosync/pacemaker (Linux HA, most recent version) for load balancing the load balancers: three load balancers, each one with an external IP address, RR balanced using DNS (one name points to the three IP adresses). If one of the machines is down the IP address designated to it is moved by corosync to one of the other two remaining machines. Also if I add more machines/IP addresses they are automatically balanced and if all but one machines are down all IPs will be on the one that is up. You can use corosync to do active-active, active-passive and many other cluster configs.