Ping Works, but HTTPS Doesn't: How to Find What Actually Broke

You've probably seen this before:

$ ping example.com
64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=18 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=54 time=17 ms

So the network works, right?

Then:

$ curl https://example.com
curl: (28) Connection timed out

Or your browser spins forever.

This is one of the most common traps in network troubleshooting: treating a successful ping as proof that "the network is fine."

It isn't.

ping answers one fairly narrow question. Your application depends on several other things succeeding after that.

What ping actually proves

Ping normally uses ICMP echo requests and replies.

If a host responds, you've learned something useful:

• your machine has some working route toward the destination
• packets can travel across at least part of that path
• the destination, or something representing it, is responding to ICMP

But an HTTPS connection needs much more.

A simplified path looks something like this:

Network interface
      |
Routing
      |
DNS
      |
TCP connection
      |
TLS handshake
      |
HTTP
      |
Application

And real networks can add more:

Proxy
VPN
Firewall
NAT
MTU problems
IPv4 / IPv6 differences

A successful ICMP echo doesn't prove all of those layers work.

That's why "but I can ping it" often doesn't get you very far.

DNS can still be the problem

There are a few variations here.

Suppose you run:

ping 1.1.1.1

and it works.

That says nothing about DNS.

Try:

dig example.com

or:

getent ahosts example.com

If name resolution fails, applications using hostnames will still be broken even though you have basic IP connectivity.

There's another wrinkle: your application and your diagnostic tool may not necessarily use DNS in exactly the same way.

Your system resolver, a browser using encrypted DNS, a VPN-provided resolver, and a corporate DNS setup can produce different behavior.

So "DNS works" can sometimes need a more specific question:

Which DNS, resolving what name, from which environment?

TCP can fail even when ping succeeds

HTTPS normally needs a TCP connection to port 443.

That is a completely different exchange from ICMP.

You can test it directly:

nc -vz example.com 443

or:

curl -v https://example.com/

A firewall might allow ICMP while blocking TCP 443.

The server might be reachable but not listening on the expected port.

A VPN route might send the application traffic somewhere different.

A proxy might be involved.

The path could simply behave differently for the traffic your application actually uses.

So this situation is perfectly possible:

ICMP       PASS
TCP :443   FAIL

There is no contradiction there.

You're testing two different things.

TCP working still doesn't prove HTTPS works

Let's say port 443 accepts a connection.

Great.

You're still not done.

Before HTTP can happen over HTTPS, the client and server need to complete a TLS handshake.

TLS can fail because of things like:

• certificate validation
• hostname mismatches
• TLS interception
• protocol incompatibility
• a middlebox interfering with the connection
• the wrong service running on the port

You can inspect that layer with tools such as:

openssl s_client -connect example.com:443 -servername example.com

or:

curl -v https://example.com/

At this point you can have:

DNS    PASS
TCP    PASS
TLS    FAIL

That is much more useful than saying "the internet is broken."

You now know roughly where to look.

And TLS working doesn't prove HTTP works

Suppose DNS resolves, TCP connects, and TLS completes.

The server can still return an HTTP error.

You might get:

403 Forbidden

or:

502 Bad Gateway

or:

503 Service Unavailable

That's a very different problem from a dead network path.

The connection reached the service.

The service responded.

The failure has moved farther up the stack.

That's why I like troubleshooting networking as a sequence of questions rather than one giant "does it work?" test.

Don't forget proxies

Proxies make this even more interesting.

Your shell might have:

HTTPS_PROXY=http://proxy.example:8080

while also having something like:

NO_PROXY=internal.example.com

Now two requests to different hosts may follow completely different paths.

One can go directly to the destination.

The other can go through a proxy.

If the proxy is down, misconfigured, or excluded incorrectly, the symptoms can look like an ordinary network failure even though the direct network path is perfectly healthy.

Testing both paths can matter.

For example:

curl -v https://example.com/

and, when appropriate:

curl --noproxy '*' -v https://example.com/

If one succeeds and the other doesn't, you've learned a lot.

Path MTU problems are another nasty case

Some failures are even stranger.

Small packets work.

Connections establish.

Then larger transfers hang or behave unpredictably.

This can happen when the effective MTU somewhere along the path is smaller than expected and Path MTU Discovery isn't working correctly.

That's one reason a simple ping can be especially misleading.

A tiny ICMP echo succeeding isn't proof that larger application traffic can make it through the same path successfully.

The useful question isn't "does the network work?"

A better question is:

What is the first layer that doesn't work?

Instead of:

Internet broken

you want to reach something more like:

Interface     PASS
DNS           PASS
TCP           PASS
TLS           FAIL
HTTP          SKIPPED

or:

Interface     PASS
DNS           FAIL
TCP           SKIPPED
TLS           SKIPPED
HTTP          SKIPPED

Those are very different problems.

And once you know which layer failed, the number of possible causes becomes much smaller.

Doing this manually

You absolutely can troubleshoot this with the standard tools.

Depending on the problem, I regularly reach for things like:

ip route
ping
dig
nc
curl
openssl
traceroute
mtr

Those tools are excellent.

The difficult part isn't usually running them.

It's deciding:

1. which test to run next
2. what its result actually proves
3. which later tests are meaningful after an earlier failure
4. whether two failures are related or independent

That is why I built Network Doctor.

The project is open source: Network Doctor on GitHub.

Instead of treating connectivity as one yes/no test, it probes the relevant layers independently and tries to identify where the evidence stops.

For example:

netdoc example.com

It can check things including the local interface, DNS, TCP, TLS, HTTP, proxy connectivity, and path MTU, then give you a diagnosis based on those results.

I still use the underlying tools when I need to dig deeper. Network Doctor isn't intended to replace curl, dig, mtr, or the rest.

The goal is to get to the right one faster.

The reverse is also true: ping can fail while everything works

There's another reason not to treat ping as the final authority.

Some networks and servers simply block or deprioritize ICMP.

You can see:

ping: no reply

while this works perfectly:

curl https://example.com/

From the application's perspective, that's not an outage.

The traffic you actually care about succeeded.

This is why good diagnostics need to test the protocol that matters instead of assuming ICMP represents every other kind of traffic.

A better troubleshooting habit

The next time you hear:

"It can't be the network. Ping works."

Ask what layer has actually been tested.

Work upward:

Do I have an interface and route?
        ↓
Can I resolve the name?
        ↓
Can I reach the service's port?
        ↓
Can I complete TLS?
        ↓
Can I make the application request?

If there is a VPN or proxy involved, test that path too.

The goal isn't to collect as much command output as possible.

The goal is to find the boundary between working and broken.

Once you know that boundary, network troubleshooting gets a lot less mysterious.