>> It isn't apache
>> I have the same problem with #telnet 127.0.0.1 80 , so DNS must be OK,
>> mustn't be?
> That "telnet localhost 80" and "telnet 127.0.0.1 80" both behave
> the same only means that the telnet program is able to translate
> "localhost" into "127.0.0.1". But at the other end of the TCP
> stream, whatever is listening on port 80 may be trying to
> translate 127.0.0.1 to its corresponding hostname and failing
> to do so.
Hmm, upon further thought, I've realized this is probably not correct
if the original poster accurately reported what they saw, i.e. that
it hangs after the "Trying 127.0.0.1..." line.
If it were an issue of DNS on the server side of the TCP socket,
then it should print this:
$ telnet localhost 80
Connected to localhost.
and THEN hang. In other words, I'm fairly sure that there is no way
for Apache to know the remote end's address until it calls accept(),
and at that point the TCP stack will finish setting up the connection.
And if Apache doesn't know the address, it can't be having a DNS
problem doing a reverse lookup on the address, because you can't do
the lookup without knowing the address, obviously.
So I think this is probably not a DNS problem. Which leaves something
like packet filtering or routing.
And since they said it behaves differently for different ports, that
would pretty much rule out routing as a possible problem.