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've got an Apache 2.0.52 server on CentOS 4 that front-ends a couple of App servers (mix of Jetty and Tomcat). Apache has a handful of virtual hosts configured like this:

    DocumentRoot "/mnt/app_web/html"

    SSLEngine on
    SSLCertificateFile      /etc/httpd/conf/ssl.crt/server.crt
    SSLCertificateChainFile /etc/httpd/conf/ssl.crt/chain.crt
    SSLCertificateKeyFile   /etc/httpd/conf/ssl.key/server.key
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

    RewriteEngine on
    RewriteRule ^/app1/(.*)$$1 [P,L]
    RewriteRule ^/app2/(.*)$$1 [P,L]

However, I'm getting the following errors in the logs intermittently:

[Fri Dec 04 07:19:41 2009] [error] (113)No route to host: proxy: HTTP: attempt to connect to ( failed

I initially tried turning off IPv6, and that seemed to largely cure it, but I still have sporadic bursts of these messages.

Additionally, we're running memcache on same front-end and during the times when I'm getting those messages in Apache's log, the following command doesn't work:

echo stats | nc 11211

No messages are printed, but neither are the stats printed. I am completely lost as to how to proceed with troubleshooting this. =(

share|improve this question
up vote 0 down vote accepted

To solve this problem you need to add rule(s) in the 'iptables' of your App servers. For Red Hat Enterprise the file is '/etc/sysconfig/iptables' . It should be the same for CentOS.

You probaly have one or more rules that accept NEW connection from the front-ends that look like these:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 'IP of the front-ends' --dport 'port number' -j ACCEPT


-A RH-Firewall-1-INPUT -m state --state NEW -m multiport -m tcp -p tcp -s 'IP of the front-ends' --dports 'ports numbers' -j ACCEPT

Your problem shoud be solved by adding rules that send a tcp-reset to the front-ends for each SYN packet that passed throught the preceedings rules. The rules should looks like these:

-A RH-Firewall-1-INPUT -m tcp -p tcp -s 'IP of the front-ends' --dport 'port number' --syn -j REJECT --reject-with tcp-reset


-A RH-Firewall-1-INPUT -m multiport -m tcp -p tcp -s 'IP of the front-ends' --dports 'ports numbers' --syn -j REJECT --reject-with tcp-reset

Add the rules near the end of your 'iptables' just before the rule that looks like:

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Good luck.


share|improve this answer
While this didn't exactly fix the problem, it did point the way to a proper resolution - specifically the iptables rules allowed access to tomcat only if the request was IPv4 (d'oh!) We also shuffled a couple of PHP apps off the front-end server to another VM and we've been error-free for a couple of months now. Thanks! (I'd upboat but I don't have the rep on this shard =/) – BonkaBonka Sep 9 '10 at 17:32
IPv6 was a red-herring. The root cause is IPTables' connection tracking. Disabling it has permanently cured the issue. – BonkaBonka May 6 '15 at 3:01

I had this problem (113 - No route to host) on CentOS 6.5 with Apache 2.2, although it was only intermittent- about every 20 mins. I doubt it is related to your issue but this may help someone.

I captured the network traffic on both ends using Wireshark and discovered that ICMP host administratively prohibited packets were sometimes being returned by the App server in response to a SYN packet from the Reverse Proxy. However, most of the time the SYNs were being accepted.

Based on Paul's answer, I checked the iptables rules- indeed the rules of course were fine to accept NEW connections on port 8009.

I decided to reset iptables with the command:

service iptables restart

After restarting iptables the '113 - No route to host' problem has gone away completely.

share|improve this answer
This came back to bite us again a while ago and we finally found the root cause - IPTables connection tracking. Turning that off truly cured the problem. – BonkaBonka May 6 '15 at 3:00

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.