ThisCalculator

Everyday

Ping Works but HTTPS Fails: DNS to TLS Trace

Updated · Standard formula, shown below

Ping Works but HTTPS Fails: DNS to TLS Trace

If ping succeeds but HTTPS requests fail, the break is almost always between DNS resolution and the TLS handshake — specifically, the browser can resolve the hostname but cannot establish a secure connection to the server. This article traces the exact path from ICMP echo to TLS negotiation, identifies the most common failure points, and gives you a step-by-step method to isolate the culprit.

What Ping Actually Tells You

Ping uses the Internet Control Message Protocol (ICMP) to send an echo request to an IP address. It does not use TCP or UDP, and it does not involve DNS or any application-layer protocol. When you type ping example.com, your operating system first resolves the hostname via DNS, then sends ICMP packets to that IP. A successful reply means the host is reachable at the network layer and is responding to ICMP — nothing more.

This distinction matters because HTTPS traffic uses TCP port 443 and then a TLS handshake. ICMP can pass through firewalls and network paths that block or interfere with TCP. Conversely, a server can be fully up and responding to ping while its web service is down, its firewall drops TCP 443, or a middlebox resets the connection. So a successful ping narrows the problem to the layers above IP — but it does not tell you which one.

The HTTPS Connection Path: DNS → TCP → TLS

When you request https://example.com, the browser goes through these steps in order:

  1. DNS resolution — the browser asks a resolver (usually your router or ISP) for the IP address of example.com.
  2. TCP handshake — the browser sends a SYN packet to port 443 on that IP, the server replies SYN-ACK, the browser sends ACK.
  3. TLS handshake — the browser sends a ClientHello, the server responds with ServerHello, certificate, and key exchange; they agree on cipher suites and session keys.
  4. HTTP request — after TLS is established, the browser sends the actual GET request over the encrypted channel.

A failure at any of these steps produces different symptoms. Ping only verifies step 0 (basic IP reachability). If HTTPS fails, you need to test each subsequent layer.

Common Failure Points and How to Identify Them

Here are the typical culprits, ordered from most to least common, with a quick way to test each:

  • DNS returns wrong or no IP — run nslookup example.com and nslookup example.com 8.8.8.8. If the first fails but the second works, your local DNS is the problem. If both return a different IP than expected, you may have a poisoned cache or a malicious entry.
  • Firewall blocks TCP 443 — run telnet example.com 443 or nc -vz example.com 443. If the connection times out or is refused, a firewall (local, network, or server-side) is dropping the port. Ping uses ICMP, which is often allowed even when TCP 443 is not.
  • TLS certificate issues — use openssl s_client -connect example.com:443 -servername example.com. If you get a certificate error, the server’s certificate is expired, self-signed, or mismatched. Browsers will block the connection even though TCP works.
  • TLS version or cipher mismatch — the same openssl command will show the negotiated protocol and cipher. If the server only supports TLS 1.0 and your browser requires TLS 1.2, the handshake fails.
  • HTTP/2 or SNI issues — some servers misconfigure SNI (Server Name Indication). Try curl -v https://example.com and look for the Server name line. If it is empty, the server may be sending the wrong certificate.

Step-by-Step Troubleshooting Trace

Follow this order to isolate the break:

  1. Check DNS — nslookup example.com and nslookup example.com 1.1.1.1. If the first fails, your resolver is broken. If the second gives a different IP, you have a DNS issue.
  2. Check TCP connectivity — nc -vz example.com 443. If this fails, the problem is network-level: firewall, routing, or the server’s web service is down.
  3. Check TLS handshake — openssl s_client -connect example.com:443 -servername example.com. Look for CONNECTED and Verify return code. If you see a non-zero verify code, the certificate is invalid.
  4. Check HTTP response — curl -v https://example.com. This shows the full TLS handshake and the HTTP status. If you get a 403 or 500, the server is reachable but rejecting the request.
  5. Compare with a different network — try the same URL from a phone on cellular data. If it works there, the problem is on your local network or ISP.

Why DNS Can Break While Ping Still Works

Ping requires DNS resolution to get the IP address. If DNS is broken, ping itself would fail with ping: cannot resolve example.com. So if ping succeeds, DNS worked at that moment. However, the browser may use a different DNS path than the command line. Browsers often use their own DNS-over-HTTPS (DoH) or cache entries that can be stale or poisoned. A common scenario: the OS resolver works, but the browser’s DoH resolver returns a different (wrong) IP. To test, disable DoH in your browser or use curl --doh-url to replicate the browser’s behavior.

Another subtle issue: DNS can return multiple IPs (round-robin). Ping may use the first one, which is reachable, while the browser uses a later one that is blocked. Check nslookup output for multiple A records and test each IP with nc -vz.

Firewalls and Middleboxes: The Silent Interference

Many corporate networks and some ISPs block ICMP for security or traffic shaping, but allow TCP 443. The reverse is also possible: they allow ICMP but block or interfere with TCP 443. Deep packet inspection (DPI) firewalls may reset connections that look like TLS but do not match expected patterns. If you are behind such a device, you may see ping succeed, TCP connect succeed, but the TLS handshake fails with a timeout or reset. Testing from a different network (e.g., phone hotspot) is the fastest way to confirm this.

Also check your local firewall (Windows Defender, iptables, etc.). Some configurations allow ICMP but block outbound TCP 443. Temporarily disabling the firewall (with caution) can isolate this.

Frequently Asked Questions

Why does ping work but the browser says “site can’t be reachedâ€�? The browser uses TCP 443 and TLS, which are separate from ICMP. A firewall may block 443, the server’s web service may be down, or DNS may return a different IP to the browser than to ping.

How do I test if port 443 is open? Use telnet example.com 443 or nc -vz example.com 443. If you see “Connection refused� or a timeout, the port is blocked or the service is not listening.

What does a TLS handshake failure look like? In openssl s_client, you may see “no peer certificate available� or “SSL routines:ssl3_read_bytes:tlsv1 alert protocol version�. In a browser, you get an error like “ERR_SSL_VERSION_OR_CIPHER_MISMATCH�.

Can DNS-over-HTTPS cause this? Yes. If your browser uses DoH and the DoH resolver returns a different IP than your system DNS, you can get a connection failure even though ping works. Disable DoH or compare results with curl --doh-url.

Why does ping work but curl fails with “Could not resolve hostâ€�? That means curl’s DNS lookup failed. Ping may have used a cached entry. Flush your DNS cache (ipconfig /flushdns on Windows, sudo systemd-resolve --flush-caches on Linux) and retry.

Is it safe to disable my firewall to test? Only temporarily and on a trusted network. If disabling the firewall fixes the issue, re-enable it and add an exception for your browser or for TCP 443 outbound.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.