Quote:
Originally Posted by David Goodman
|
No virtual web server can respond appropriately if you simply hit it via the IP address, as they need the name of the site encoded in the URL in order to decide what content to serve.
Quote:
|
No further resolution is needed. If he can't get to https://69.63.143.195 (which he can't) it's not a DNS problem. Period.
|
The traceroute output doesn't show that he can't hit it with a web browser; what it demonstrates that network hops after a certain point are having ICMP (either requests or replies) filtered, or a router is choosing to drop packets with the ICMP_TIME_EXCEEDED flag set. Very common across network boundaries.
Also, ICMP != TCP. So a failure to get an ICMP response from an IP tells you zip about the state of TCP connections you may (or may not) be able to establish to that same IP or port - the only way is to try to connect using the appropriate protocol and/or ports - eg TCP/80 or TCP/443.
For example:
Broadly speaking, "connected" means you can reach it fine via TCP; any error after that is either a server-side configuration issue or a problem with the URL you provided.
A firewall filtering connections most often just times out w/ no handshake.
"connection refused" means a TCP reset was issued; usually means nothing listening on that port at the far end (so issued by the hosts' TCP stack), although sometimes a firewall is configured to reset instead of just quietly dropping packet(s).