I have an application, a simple web page, accessible via port 80 on an apache webserver on a RHEL linux distribution.

This server has a ServerName "xyz.domain.com" and is accessible via 2 network interfaces.

From both networks telnet xyz.domain.com 80 is fine: the server is available. Problem is that, from network 2, wget http://xyz.domain.com/index.html goes on timeout.

I wasn't the person who set up those machines, according to you what the problem could be? Maybe some iptables configuration?

I followed the advice to put the verbose flag and I have the following, it seems that a "TCP NODE RELAY" is set, what does that mean? On the network where it works it is not present, I think that's the cause.

* Connected to xyz.domain.com ( port 80 (#0)
> GET / HTTP/1.1
> Host: xyz.domain.com
> User-Agent: curl/7.56.1
> Accept: */*
 0     0    0     0    0     0      0      0 --:--:--  0:00:20 --:--:--     
 0* Recv failure: Connection was reset
* stopped the pause stream!
 0     0    0     0    0     0      0      0 --:--:--  0:00:21 --:--:--     0
* Closing connection 0
curl: (56) Recv failure: Connection was reset
  • TCP NODE RELAY" is actually TCP NODELAY and not an issue but for background: curl.haxx.se/libcurl/c/CURLOPT_TCP_NODELAY.html
    – HBruijn
    Jun 24, 2019 at 11:40
  • Run the tcpdump and capture the traffic with successful and unsuccessful attempts. You've write about timeout, but curl shows connection refuse. Jun 24, 2019 at 12:17

1 Answer 1


Use a verbose flag when testing with wget or curl to see more of what's happening rather than just the resulting time-out.

Without that I can only make some educated guesses:

  • actual web clients will not only make a connection but will also follow HTTP protocol directives:
    • the clients will honor web proxy settings (for instance a http_proxy environment variable is set/missing, there is no corresponding https_proxy or a proxy_ignore is needed)
    • HTTP 301 & 302 redirects http://www.example.com may redirect at HTTP protocol level to HTTPS or another site, and that other domain/port is what is blocked.
    • somewhat related: standards compliant browser should honour HSTS (preload) settings and your browser be going to https regardless of the http URL
  • Updated with the log of the verbose curl. It seems something in the other network gets in the middle, after that the remote host closes the connection.
    – Phate
    Jun 24, 2019 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .