Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a web application, which is served by a standalone app. Sometimes the JVM it's running in crashes, but most often, I need to take it down to deploy a new version or to update the system. For various reasons it has to serve HTTP/HTTPS requests directly, so I can't use a proxy in front of it.

Is there some way to have the system itself (Ubuntu Linux) answer HTTP requests when the app is down? Or, in other words, is there some way to configure the server so that whenever the normal response would be "connection refused", it would serve some static (503) page instead? If possible, it would be great if it could handle HTTPS as well.

share|improve this question
What's doing your actual web serving? – Chopper3 May 9 '11 at 17:20
it's a custom app doing its own web serving.. – xs0 May 9 '11 at 17:27
If it is a custom app, it may have a custom setting for this. If not, you might be able to script something to send requests to the server and based on the response, take actions. Say if it does not receive a response, it could then shut it down and pull up a backup server app (a lamp stack or nginx or anything else) that has a basic version of the site to use while the main one is down. – MaQleod May 9 '11 at 18:02
up vote 4 down vote accepted

You could use haproxy in tcp mode to transparently proxy the requests. Your application server won't know the difference, except that the remote ip will be the localhost. It will return an error to the client if it can't contact the backend server by default. You can also specify a backup server, to which requests are routed to when the backend goes down.

If you truly want to avoid any "proxy", you could use iptables to redirect the ports. You would run a server like nginx to serve the error files on an unused port. With a monitoring script (or a daemon like Monit), you could redirect the application's port to your error server with a rule like:

iptables -t nat -A PREROUTING -i eth0 -p tcp \
--dport $SVC_PORT -j REDIRECT --to-port $ERROR_PORT

Your monitoring system would need to dynamically insert or delete the rules as the availability of services change.

share|improve this answer
I was just about to suggest the same thing! The backup server could even be running on the same physical server as the default server, either running a separate instance of the web server, or a different web server entirely. – Joe May 9 '11 at 18:11
@Joe - yes, I've often used a local nginx instance (simply because of its tiny resource usage) as the backup server for custom error pages. – JimB May 9 '11 at 18:21
Thanks for the pointer, haproxy looks like a neat tool. But, like I said - I can't really use a proxy in front of the app. The solution, if it exists, would have to involve the kernel/OS in some way, I guess.. – xs0 May 10 '11 at 8:26
@xs0 - can you explain why you can't use a proxy? It makes it hard to offer solutions when we don't know what the restrictions are – JimB May 10 '11 at 13:49
My app is a SaaS thing and the configuration of the whole set-up is constantly changing (based on what its users are doing), including IPs that are listened on, domains that are served, SSL certificates, etc. Unless you know of a proxy that can do this (i.e. be run-time-configurable without restarting)? – xs0 May 11 '11 at 14:32

There's no way to do this directly (I.E. if the app is down, the app is down and will not return anything, even an error)
You can, however, run something like NGINX which can send custom errors if the main server is down or if it returns an error.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.