httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Greenlees" <>
Subject Re: [users@httpd] Much More Betterer, but not quite Perfect...
Date Mon, 13 Apr 2009 13:23:20 GMT
Brian Mearns wrote:

> As for your problem...

A useful tool that can help diagnose the issues below is shieldsup on
a port scan that tells you what ports ( if any ) are open. since it's
coming from outside the isp it also finds blocked ports from them.

> It's hard to say why the connection is timing out or what that
> indicates. You are right in that the fact that it did not outright
> refuse the connection is promising, but it does not necessarily mean
> that it's a server issue. In fact, unless you specifically did
> something to provide different content or access restrictions for
> requests inside the LAN versus outside, then I would guess that it's
> *not* a server issue since you were able to access it from inside the
> LAN without a timeout. There are other possibilities, but my guess is
> that the request is not making to the httpd server. The best way to
> find out is to check your server's access logs. If you have a typical
> setup, then you probably have a CustomLog directive in your httpd.conf
> file, which should point you to the location of this log. In general,
> this log will show you at least one line for each request made to the
> server, so you can monitor it for changes when you access it remotely
> (e.g., from your neighbor's house). If it doesn't change, it most
> likely means the request isn't making it to the server. Similarly, you
> have an ErrorLog, which is worth checking as well, though it doesn't
> sound like the server is encountering an error.
> So assuming the request is not making it to the server, there's a
> couple of possibilities. The general path for the request is going to
> be: neighbor's system, neighbor's router, neighbor's ISP, your ISP,
> your router, your system, your server. Your neighbor's system, and
> router are both unlikely to be the culprit unless he/she had a
> specific reason to block access to your IP address in the past.
> Similarly with his ISP, though it's slightly more likely that they
> would be filtering packets based on destination address if they've had
> complaints about your address in the past (not necessarily because of
> you, the IP address has most likely been assigned to a bunch of other
> people before you).
> That leaves your ISP, your router, and your system before reaching the
> server. ISP is a distinct possibility, it's not at all uncommon for
> ISP's to block port 80 (the default HTTP port) for their residential
> clients so you have to buy an expensive professional account if you
> want to run a website. You can check with them directly, or probably
> just searching the web will tell you whether that provider in that
> area is known for blocking port 80. However, usually when an ISP
> blocks a port, you just plain can't connect.
> Router's are somewhat less consistent about what they do with ports;
> it's possible that it would keep the connection open for an extended
> period of time if it doesn't know what to do with it, which would lead
> to a timeout. This is particularly common on port 80 as most routers
> have a built in web server for router administration, so if it's not
> properly configured for remote access to this then it could be causing
> a problem. But if you've forwarded port 80, and don't have any
> firewall rules set up that would interfere, then it's probably not the
> router, either.
> Which only leaves your system and the server itself. Do you have
> firewall on the system? E.g., Norton security, windows firewall,
> zonealarm? Any of these could very well be causing problems.
> Another possibility is that your DNS is not set up correctly. Instead
> of connecting to your domain name, try typing your router's public IP
> directly into the address bar in your neighbor's browser. If that
> works, then it means your domain name is mapped to someone else's IP
> address which is the one that's timing out.
> Okay, so to summarize: first check your logs to see if the access is
> getting to the server. If it is, then you're right, there's something
> wrong with your server set up. (By the way, you're right, just editing
> the conf file does not change the server, you need to restart the
> server for the changes to take effect). If it's not, trying connecting
> via your IP address instead of domain name. If that doesn't help,
> check your server's Firewall and your router's setup for firewall and
> port forwarding. If all that looks ok, find out if your ISP interferes
> with port 80. After you do all that, get back to us (the list) with
> what you found out, and someone can try to help from there.
> Good luck,
> -Brian

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message