The server replies to ping. There is no packet loss. Yet the browser keeps loading—or displays “This site can’t be reached.”Sound familiar?
When ping works but a website won’t open, it is tempting to declare the network healthy and blame the application. But a successful ping answers only part of the question.The next step is to find out exactly where the web connection fails.
Ping uses ICMP Echo messages to test IP reachability. It does not test whether a web service is listening, whether HTTPS can establish a secure connection, or whether the application can process a request.Think of ping as confirming that someone answers the building’s intercom. It does not tell you whether the office you need is open.
A website can remain unavailable because of:
For a typical HTTPS connection over TCP, investigate name resolution, the TCP connection, TLS and then HTTP. HTTP/3 uses QUIC over UDP, so a TCP port test does not cover every browser connection path.
Before changing anything, record the URL, error message, time and affected users.
“This site can’t be reached,” a certificate warning and “503 Service Unavailable” point to different stages of the connection.
Ask:
These comparisons help narrow the investigation without immediately restarting services or modifying firewall rules.
Pinging an IP address does not test DNS. Even when a hostname responds to ping, confirm that it resolves to the intended destination.
Run:nslookup app.example.com
Replace the example hostname with the affected website.
Compare the result with the expected address and, where useful, a working device. Investigate stale records, incorrect DNS server settings or differences between internal and external DNS.
Multiple addresses are not automatically a fault: load-balanced services and CDNs can legitimately return different answers. Compare against the intended service configuration.
Do not assume that opening an HTTPS website by IP address is a reliable DNS test. Shared hosting and HTTPS depend on the requested hostname; using an IP can introduce a different certificate or virtual-host problem.
If the destination is correct, check whether the client can establish a TCP connection to the web service.
In Windows PowerShell:Test-NetConnection app.example.com -Port 443
Look for:TcpTestSucceeded : True
A successful result confirms that the TCP connection worked to the reported remote address and port. It does not confirm that TLS or the application works.
A failed result means you should investigate the path and listener. Possible causes include a firewall drop or rejection, a stopped service, an incorrect port, NAT configuration or a return-path problem.
For a plain HTTP service, test port 80. If the application uses a custom port, test that port instead.
A failed port test is evidence to investigate—not proof that the firewall is responsible.
An open HTTPS port can still produce a certificate warning or handshake failure.
Check the certificate’s validity dates, hostname coverage and trust chain. Also verify the client’s clock. In networks using HTTPS inspection, investigate the inspection device and the client’s trust configuration.
Use curl for connection details:curl -v --connect-timeout 10 --max-time 30 https://app.example.com/
On Windows, use curl.exe if curl resolves to a PowerShell alias.
The output can help distinguish connection failure, certificate verification failure and an HTTP response. Treat verbose output carefully before sharing it: it can contain sensitive request details.
Fix certificate or trust issues at their source. Disabling certificate verification is not a production solution.
If you receive an HTTP status code, a web-speaking component has responded. That component may be a proxy or gateway rather than the application server itself.
|
Response |
What it tells you |
What to investigate |
|
403 Forbidden |
The request was understood but refused. |
Authorization, access policy or WAF logs. |
|
404 Not Found |
The requested resource was not found. |
URL, application route or virtual-host configuration. |
|
502 Bad Gateway |
A gateway received an invalid upstream response. |
Backend service and gateway logs. |
|
503 Service Unavailable |
The service is currently unable to handle the request. |
Availability, capacity, maintenance and backend health. |
|
504 Gateway Timeout |
A gateway did not receive an upstream response in time. |
Backend delays and connectivity. |
Even a 200 response does not guarantee that the complete page works. A browser may load the main document while JavaScript files, APIs or authentication requests fail. Use the browser’s Network panel to identify the failing request.
Imagine this lab scenario:
The host can answer ICMP while no web service is listening on the required port.
After correcting the service problem, repeat the TCP test and open the website. Finally, verify the user’s actual task, such as signing in or opening a report.
Recovery is confirmed when the application works—not merely when ping replies.
Can a firewall allow ping but block a website?
Yes. ICMP and web traffic can match different rules. Successful ping does not prove that TCP port 443 is allowed.
Does a successful port 443 test prove HTTPS works?
No. It confirms the tested TCP connection. TLS negotiation and the HTTP request can still fail.
Can a website work when ping fails?
Yes. A device or network can block ICMP Echo while permitting web traffic.
Should I check DNS, ports or TLS first?
Start with the error and available evidence. For a hostname-based connection, checking DNS, then the required port, then TLS is a useful sequence. A clear certificate warning may let you focus on TLS sooner.
The most useful question is not simply, “Can I ping it?” It is, “Which part of this connection have I actually verified?”
Atmic Networks encourages learners to connect networking fundamentals with practical troubleshooting. Use this scenario in your lab: change one condition, observe the symptoms and explain what each test proves.
Your turn: ping succeeds, the website fails, and only one user is affected. What would you check first—and why?
