How to Run a Website Connectivity Test: Diagnosing Unreachable Sites and Network Connection Issues

Whether you're handling website operations, doing front-end development, or you're just an ordinary user, the first thing most people do when a site suddenly won't load is ping the domain from the command line. If the ping fails, they assume the server is down; if it succeeds, they're puzzled why the browser still reports a connection timeout. In practice, neither conclusion is reliable.

From the moment a URL is entered to the moment a page finishes loading, a request has to pass through domain resolution, network routing, TCP connection setup, the TLS handshake, the HTTP request, and the server's internal response. If any one of these stages gets stuck, what the user sees is often just "the page won't open" or "it keeps loading."

An effective website connectivity test is never just a single Ping. It works through the layers one by one: DNS resolution, network path, service ports, and HTTP status codes. Only by first figuring out exactly which step the request dies at can you accurately decide whether to call the ISP, fix a DNS record, adjust a firewall, or log into the server and restart a service.

1. What Is a Website Connectivity Test?

Put simply, a website connectivity test checks whether a user's current network can reach the target website normally. But "connectivity" here isn't a single state.

A complete website visit roughly goes through:

Enter domain
↓
DNS resolution
↓
Get target IP
↓
Establish network connection
↓
TCP connection to port 80/443
↓
TLS handshake (HTTPS)
↓
Send HTTP request
↓
Server returns content
↓
Browser loads page

Failure at any one of these layers can make a website unreachable. For example: the domain doesn't resolve to an IP; the server IP responds to Ping but port 443 isn't open; port 443 accepts connections but Nginx returns 502; HTTP returns 200 but page resources fail to load; some regions can access the site normally while others keep timing out. On the surface, all of these are called "the website won't open," but the actual causes are completely different. The point of a website connectivity test isn't to get a simple "up" or "down" — it's to determine as precisely as possible which layer is the first to show a problem.

2. What Does a Website Connectivity Test Check?

Following a troubleshooting logic, a complete test usually covers the following five layers:

1. DNS Resolution Check

The domain must first be translated into an IP address before any further access can happen. If the DNS configuration itself is wrong, every network test that follows is pointless.

• Common issues: wrong A record or CNAME, local DNS cache not refreshed after a resolution change, expired domain or resolution suspended by the registrar, misconfigured CDN CNAME, and so on.

• What to check: whether different regions and different DNS servers (such as 114.114.114.114 or 8.8.8.8) return consistent IPs that match expectations.

2. Ping Test (ICMP Basic Network)

Once DNS is working, Ping lets you observe the physical link from your location to the target IP.

• What to check: RTT latency, packet loss rate, and whether there's a regional routing outage.

• Pitfall warning: A failed Ping does not mean the website is unreachable. Many servers, CDN nodes, and cloud provider firewalls (such as Alibaba Cloud security groups or Cloudflare) disable the ICMP protocol by default (Ping blocking). In that case, Ping shows a timeout, but the site's port 443 is still perfectly accessible.

3. TCP Service Port Test

This is a check that's closer to real business traffic than Ping. Web services rely on specific ports to establish connections:

• HTTP service: port 80

• HTTPS service: port 443

• Remote management / databases: 22 (SSH), 3306 (MySQL), etc.

If Ping works but port 443 refuses connections, traffic is reaching the server but a TCP connection can't be established. Typical causes include: the web service isn't running, the system firewall (iptables/ufw) isn't allowing the port, the cloud server security group is missing a port rule, or the CDN origin port is misconfigured.

4. HTTP/HTTPS Status Code Response

A reachable port only means "the path is open." Whether the service can actually handle the request depends on the HTTP response status code:

• 200 OK: request succeeded, the link is basically fine.

• 403 Forbidden: the service is fine, but the request was blocked by the server's WAF or permission rules.

• 404 Not Found: the web service is fine, but the requested path or file doesn't exist.

• 502 Bad Gateway / 504 Gateway Timeout: the gateway or reverse proxy (such as Nginx) received the request, but the backend application service (Java, Python, PHP, etc.) isn't running or timed out.

5. Page Resources and Front-End Loading

Even when HTTP returns 200, the page can still show a blank screen or broken layout. This requires further investigation:

• whether the CDN node hosting static resources (CSS/JS/images) is timing out;

• whether cross-origin (CORS) requests are being blocked;

• whether the API returns data in an unexpected format.

3. How Do You Run a Website Connectivity Test?

If you're just doing a one-off check on a site that won't open, there's no need to set up complex commands and packet-capture environments from the start. A more practical approach is to use Chahu's Ping, DNS, TCPing, HTTP status, and website speed test tools to check each stage separately.

Step 1: Check Domain Resolution First

Start by confirming whether the domain has expired and whether resolution points to the correct IP. If you just switched CDNs or changed servers, check DNS propagation first.

Step 2: Then Check Ping

Once DNS is working, use Chahu's online Ping test to check the target IP.

Don't just look at whether it's "reachable." Also watch for: whether RTT has risen noticeably; whether there's packet loss; whether only some regions are affected; whether results differ greatly across ISPs. If Ping times out but the HTTP site still works fine, there's no need to keep worrying about ICMP.

Step 3: Test Ports 80 and 443

If the site still won't open, continue with a TCP connection check.

For an HTTPS site, focus on testing port 443.

If port 443 can't be connected to at all, then check the server security group, firewall, service listeners, or CDN configuration.

This layer is usually much closer to the user's actual network state when accessing the website than a simple Ping.

Step 4: Check the HTTP Status Code

Once the port is fine, check what status the website actually returns.

This step often lets you categorize the problem quickly:

200: the service is responding normally overall.

403: focus on access permissions, WAF, or firewall.

404: focus on the URL or site configuration.

502 / 503 / 504: focus on the origin server, application service, or reverse proxy.

Compared to the vague symptom of "the website won't open," the HTTP status code gives you a much clearer direction for troubleshooting.

4. Combined Diagnostic Guide for Common Test Results

In real operations, combinations of test results across different layers often map directly to specific root causes:

Scenario 1: DNS Resolution Failed

• Diagnosis: the request never reached the target server.

• Direction: check the domain status, NS records, and whether the A/CNAME records are misconfigured, or whether the TTL hasn't expired.

Scenario 2: DNS OK + Ping Timeout + HTTPS (443) Returns 200 Normally

• Diagnosis: the website itself is completely fine.

• Direction: the server or CDN node simply has ICMP disabled. No action needed.

Scenario 3: Ping OK + Port 443 Connection Fails

• Diagnosis: basic routing is fine, but the service isn't accepting requests.

• Direction: check whether the server security group allows port 443, whether the Nginx/Apache process has crashed, and whether the SSL certificate binding has an error.

Scenario 4: Port 443 OK + HTTP Returns 502 / 504

• Diagnosis: the network and the entry web server (such as Nginx) are both fine; the problem is on the backend.

• Direction: check whether the backend application bound to Nginx (Node.js, Go, Java, PHP-FPM, etc.) is down, or whether the database connection is timing out. If a CDN is in use, check whether the origin-facing IP between the CDN and the origin server is being blocked by the origin firewall.

Scenario 5: Local Access Works, but Users in Some Regions Report It Won't Open

• Diagnosis: a single-point test can't reflect the real situation across the whole network — this is a regional network issue.

• Direction: use a multi-node probing tool to investigate. It's usually caused by an abnormal route on a specific ISP, regional DNS pollution, a CDN node failure, or a WAF rule mistakenly blocking IPs from that region.

5. What Order Should You Follow for Website Connectivity Testing?

If you test randomly every time something breaks, it's easy to spend ages and still have no idea what's going on. I'd recommend sticking to a fixed order:

Domain
↓
DNS
↓
Ping
↓
TCP 80 / 443
↓
HTTP / HTTPS
↓
Page load
↓
Server / CDN / origin

Step 1: Confirm the Domain First

Check whether the domain itself is fine. This includes: whether it has expired; whether DNS has taken effect; whether the domain you're accessing is spelled correctly.

Step 2: Check DNS

Confirm which IP the domain actually resolves to. This step is especially important if you just switched servers or CDNs.

Step 3: Check the Basic Network

Use Ping to see whether there's obvious high latency, packet loss, or regional timeouts.

Step 4: Test the Real Service Port

If the site uses HTTPS, focus on port 443.

If this layer fails, the browser will have a hard time establishing a normal HTTPS connection.

Step 5: Check the HTTP Status

Confirm what the web service actually returns: 200, 403, 404, or 5xx.

Step 6: Analyze Page Loading Last

If all the earlier links are fine and the site is just slow to open, then look at: TTFB; images; CSS; JavaScript; third-party resources; Core Web Vitals. At this point the question has shifted from "can the site connect?" to "why is the site slow?"

Following this order is usually far more efficient than guessing randomly from a browser error.

6. What's the Difference Between a Website Connectivity Test and a Ping Test?

These two concepts are often lumped together, but in reality, Ping is only one part of a website connectivity test.

The simplest way to understand it: Ping answers whether the IP network is roughly reachable; a website connectivity test answers whether the entire website access chain is working properly. So when a website won't open, don't draw conclusions from a single Ping.

7. What's the difference between a website connectivity test and a website speed test?

These two are also often confused. A website connectivity test cares about: whether it can be accessed. A website speed test cares about: how fast it is once accessed.

When troubleshooting a website that won't open, the worst approach is to randomly spot-check based on gut feeling. Whether you use command-line tools (such as dig, ping, telnet, curl) or the Chahu online testing platform, the core logic is the same: break the vague "website won't open" into clear stages: DNS, network, port, HTTP, and page rendering. As long as you filter layer by layer along the access chain from outside to inside and from bottom to top, you can quickly pinpoint the source of the failure and greatly shorten the troubleshooting time needed to restore service.

Related Q&A

1. When a website connection times out, how should I read tracert and mtr?
   These two look at intermediate routes. tracert is good for a quick view of the path, while mtr is better for running continuously for a few minutes to check packet loss. If packet loss starts at a certain hop and continues at later hops, that segment of the route may have a problem; if only the middle hop loses packets and the endpoint is normal, that router may simply not respond to ICMP.

2. What do Connection refused and Connection timed out each mean?
   Connection refused usually means the request reached the host, but no service is listening on the port, or it was explicitly rejected by a firewall. Connection timed out is more like the route is unreachable, the firewall is dropping packets outright, or the security group hasn't allowed it. One leans toward the service not running or a rule rejecting it; the other leans toward the link being swallowed.

3. When a CDN reports 502/504, how do I tell whether it's the CDN or the origin?
   First check the response headers for CDN identifiers, X-Cache, Server, and similar fields, then check the CDN console for origin-pull logs. If the edge node shows origin-pull failure, the problem is most likely at the origin or on the origin-pull link; if the edge itself reports the error, it may be a CDN configuration or node issue.

4. Some users can open it and some can't—why check IPv6 first?
   Some networks prefer IPv6. If the domain has an AAAA record but the server isn't listening on IPv6, or the firewall hasn't allowed it, users will get stuck. IPv4 users work fine while IPv6 users can't open it—in that case, temporarily disable AAAA or fix the IPv6 listener and rules.

5. Only my own computer can't open it—how do I troubleshoot proxy, VPN, and hosts?
   First turn off the proxy and VPN, then check whether hosts points the domain to an old IP. Proxies and VPNs change routing and DNS, while hosts is more direct and bypasses normal resolution. Try a phone hotspot; if others are fine, it's basically a local environment issue.

6. Can HTTP/2 or HTTP/3 cause a connectivity test to pass while the browser still can't open it?
   Yes. Some firewalls handle HTTP/2 or QUIC poorly, and after a handshake failure the browser may not smoothly fall back to HTTP/1.1. You can force access over HTTP/1.1, or check the browser's protocol column. If HTTP/1.1 works, investigate how the intermediate network handles UDP 443 or the newer protocol.