Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

Situation: server running RHEL, Apache, etc with mod_proxy. Was working fine up to a recent restart. Now is throwing "(111)Connection refused: proxy: HTTP: attempt to connect to <IP>:8000 ( failed".

More info:
1) the server it is trying to proxy to is itself - but on port 8000
2) this was working fine prior to restarting
3) there is no evidence of changes to httpd.conf or iptables prior to restart

Im not v familiar with mod_proxy so there are several questions:
1) does it require that iptables have port 8000 open? 'nmap -P0 server -p 8000' shows this port is closed. No evidence that this port has ever been specifically opened.
2) does it require that httpd.conf have 'Listen 8000'? It's not there.

So im puzzled as to how to debug this. Is this an iptables issue? or an httpd.conf issue? I tried adding the 'Listen 8000' directive but it didn't fix the problem. And since the httpd.conf file hadn't been edited in years Im assuming this line was never there.

Running RHEL AS Release 3 (Taroon Update 9) - no SELinux to deal with.

share|improve this question
If it's proxying to itself, then yes, it definitely needs to be listening on the port you're proxying to. If you're proxying to a different port, then you're usually proxying to a different web server, not to Apache itself. What service or application are you trying to proxy to? – Shane Madden Jun 26 '12 at 1:02
This system was dumped on me by a disgruntled former employee who left recently. He had it set up with numerous "toolkits" that he proxy-ed to from various sites. These are all on port 8000. I have httpd.conf files going back many years and none have 'listen 8000' in them. – ethrbunny Jun 26 '12 at 12:31
up vote 0 down vote accepted

This system was dumped on me by a disgruntled former employee who left recently. He had it set up with numerous "toolkits" that he proxy-ed to from various sites


So, you don't want Apache listening on 8000 - it was almost certainly a different web server of some kind.

You have a bit of a forensics task in front of you - the other web server may be set up as a service and have failed to start at boot (in which case there should be a script for it in /etc/init.d, or it may have (shudder) been just started and nohup'd manually after reboots by your former colleague.

If there's nothing useful in init.d, your best first step might be to check the root user's history to see if anything looks like web server software being started.

There are just a plethora of different web server options out there, so it's hard to try to specifically dig around in the system for web servers in general, but we may be able to narrow it down. Do you know what those 'toolkits' were running, as far as what kind of dynamic content they were using (Java? Ruby? Python?)? If we know what the content is and where it's stored, then it might be easier to track down the web server that was handling the content.

share|improve this answer
Yeah. Forensics. As in dead bodies. Bleah. I got it working by modifying the mod_proxy settings.. this wasn't the original solution but it will do for now. TY. – ethrbunny Jun 26 '12 at 17:06

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.