Squid reverse proxy: maintenance mode

Question

Currently I am trying to configure my squid (3.1) reverse proxy to always display a static webpage when the one and only backend webserver is under maintenance. There is no need for an automatic switchover. The maintenance mode shall be activated by a manual config change.

The squid docs and wiki were not really helpful on this point. My idea was to block every request and display a static webpage as a deny_info with a 200 status code like so:

acl everyone src 0.0.0.0/0.0.0.0
## Testing with my client ip address:
# acl everyone src 10.123.0.40/32
http_access deny everyone
deny_info 200:/etc/squid/maintenance.html everyone

I placed that snippet before any other http_access rule and tried that configuration by only blocking my own clients traffic but there was no effect using squid -k reconfigure. It may work when I use sudo service squid restart but I do not want to test it right now because at the time there a many users using that service and a squid restart takes about half a minute (for every test).

My questions:

1. Is that configuration correct for that purpose?
2. Do I need to use sudo service squid restart for the changes to take effect or is there simply something wrong?
3. Is there a better solution to display a static maintenance page?

Thanks in advance.

Answer 1

• squid 3.1.x is like thousand years old.
• squid 3.x completely lost the ability to soft reconfiguring, thus it requires restart to apply config changes. This means you will lose your client connections to the site. Each time it will be like a flash-DoS.

To conclude: this renders squid unsuitable for using as a reverse-proxy for a website in a production environment. Consider using nginx.

If despite these warnings you are still planning to stick with squid, then you should write an redirector which will be checking if a decoy page should be in effect, to neutralize the restart problem. This redirector may be written using any script language you know: perl, python, ruby or even /bin/sh. The logic is simple: the redirector will check some sign (for example a file flag) if the decoy page should be shown, if not - it will simply pass the request to a backend. It may even check the viability of such backends.

But nginx has this functionality out-of-the-box.