How to Check if a Port is Open? TCPing Online Test and Troubleshooting Guide

Your server responds to Ping, but your website won't load. DNS looks fine, yet SSH, an API, or some service keeps timing out. In such cases, the problem isn't whether the server is online—it's whether the corresponding TCP port can actually establish a connection.

For example, websites typically need ports 80 and 443, SSH commonly uses port 22, and some APIs, control panels, or custom services use other ports. Simply pinging an IP only helps determine basic network reachability; it doesn't prove those ports are accessible.

That's where TCPing is more direct than regular Ping. With TCPing, you can initiate a connection test to a specific TCP port on a domain or IP, quickly determining whether the port itself is inaccessible or if the issue lies higher up, such as in HTTP, the application, or other layers. Let's start from a practical troubleshooting perspective and see how to check if a port is open, and where to look after TCPing shows timeout or connection refused.

1. What Does Checking a Port Actually Mean?

When you visit a website or connect to a server, you not only need the correct IP address but also need to connect to the corresponding service port on the server.

For example:

Take an HTTPS website as an example.

When a browser visits:

https://www.example.com/

After DNS resolution, the client typically needs to connect to TCP port 443 on the target server or CDN node before proceeding with the TLS handshake and subsequent HTTPS requests.

The entire process can be simplified as:

Enter domain
   ↓
DNS resolves to IP
   ↓
Connect to TCP port 443
   ↓
TLS handshake
   ↓
Send HTTPS request
   ↓
Server returns page

So when we say "is port 443 open," what we really want to confirm is: Can the current test node establish a TCP connection to port 443 on the target address? This is a point often overlooked when troubleshooting why a website won't load: If the server IP is reachable, it doesn't mean the service port is accessible. A server can be online, but if Nginx isn't running, the security group doesn't allow it, or the firewall blocks it, port 443 may not be reachable from the public internet.

2. Why Can Ping Succeed but the Port Still Be Closed?

Many people start troubleshooting by pinging the server.

For example:

ping example.com

If you get a normal response, you might assume: "The server is up, so the network should be fine." In reality, that's only half true. Ping uses the ICMP protocol, which is better for checking if a host responds, measuring round-trip latency, and detecting packet loss. TCPing, on the other hand, tests a specific TCP service port, not ICMP.

For example:

Target server
IP: 203.0.113.10

Ping:
Normal

TCP 443:
Timeout

This result isn't contradictory. It means the server can still respond to ICMP at the network layer, but the TCP port 443 required for HTTPS isn't establishing a connection. The reverse can also happen. Some servers, CDNs, or firewalls disable ICMP Ping, so you might see:

Ping:
100% timeout

TCP 443:
Normal

The website still loads fine. Therefore, it's best to understand these tools separately during troubleshooting:

If you just want to confirm whether ports like 80, 443, 22, or other TCP ports are open and reachable from the public internet, TCPing is usually more direct than regular Ping.

3. How to Use TCPing Online Test

For occasional port checks, you don't need to log into the server or install a TCPing client. Using an online TCPing tool to test from public nodes is often more convenient. Especially when you encounter issues like "I can access it, but users in other regions can't," testing only from your own computer isn't very useful.

Using Chahu for TCPing Online Testing

Chahu's network testing tools combine Ping, TCPing, HTTP(S), and Traceroute tests, making them suitable for continuous troubleshooting of websites and servers. Its TCPing feature verifies TCP connectivity to a specified port, rather than just checking ICMP responses.

Steps:

The actual test is straightforward: first, enter the domain or server IP you want to check, for example:

www.example.com

or:

203.0.113.10

Then, enter the TCP port you want to test. For a regular website, you can start with port 80.

For HTTPS websites, check port 443.

For SSH services, check port 22.

After configuration, start the test. The node will attempt to connect to the specified TCP port on the target address.

What's really worth paying attention to isn't just "open" or "closed," but also:

• Which test nodes connected successfully;

• Which regions timed out;

• Whether there are significant differences between China Telecom, China Unicom, and China Mobile;

• Whether TCP connection time is abnormal;

• Which IP actually responded.

Chahu uses multiple regional probe nodes for network tests. The value of multi-node results isn't just telling you "the port failed," but helping you determine the scope of the problem.

For example:

Beijing Telecom     Normal
Shanghai Unicom     Normal
Guangzhou Mobile    Normal
Chengdu Telecom     Timeout
Chongqing Telecom   Timeout

This result is quite different from:

Beijing Telecom     Timeout
Shanghai Unicom     Timeout
Guangzhou Mobile    Timeout
Chengdu Telecom     Timeout
Chongqing Telecom   Timeout

The troubleshooting direction is clearly different: the former suggests regional routing, ISP, or access policy issues, while the latter should prioritize checking the server, firewall, security group, and service status. Also, note: If your domain is behind a CDN, TCPing the domain typically tests the CDN edge node's port, not your origin server's port. If you really want to confirm whether your origin server's port 443 or other ports are working, you need to test using the origin server's IP separately.

4. How to Interpret TCPing Results

After running TCPing, don't just look at a red or green status and move on. Different failure results have different meanings.

1. TCP Connection Successful

For example, if the test shows:

TCP 443
Connected
38 ms

This means the current test node successfully established a TCP connection to port 443 on the target address.

At least you can confirm:

• The target IP is reachable;

• Port 443 is not completely inaccessible;

• The current test node isn't blocked by an ingress firewall.

But note: TCPing success doesn't guarantee the website is working. TCP connection is just one step in the website access process. After that, there are:

TCP connection
   ↓
TLS handshake
   ↓
HTTP request
   ↓
Web server
   ↓
Application
   ↓
Database

So it's entirely possible to see:

TCP 443: Normal
HTTP: 502 Bad Gateway

or:

TCP 443: Normal
HTTP: 500 Internal Server Error

At this point, repeatedly testing the port is pointless. You should shift focus to HTTP status codes, web server logs, and application logs.

For example, Chahu's HTTP status checker can help you see whether the page returns 200, 301, 302, 404, 500, or other statuses.

2. Connection Timed Out

Timeout is a common TCPing failure.

Simply put, the test node tried to establish a TCP connection but didn't receive a proper response within the timeout period.

Common causes include:

• The cloud server security group doesn't allow the port;

• The Linux or Windows firewall drops the connection;

• The IDC or upstream firewall blocks it;

• CDN or DDoS protection security policies restrict it;

• Network routing issues;

• The target server is unreachable;

• Access restrictions for certain regions or IP ranges.

There's a common misconception here: TCPing timeout doesn't simply mean "the server hasn't opened this port." If a firewall in the middle drops the packets, you'll also see a timeout. So after a timeout, you should continue to investigate by looking at the node coverage, server listening status, and firewall rules.

3. Connection Refused

If you see:

Connection Refused

The situation is different from a timeout.

Connection refused usually means the request reached the target host, but the target port isn't accepting the connection.

For example:

Server online
   ↓
Network normal
   ↓
Request reaches server
   ↓
No service listening on port 443
   ↓
Connection Refused

In this case, you should check:

• Is Nginx or Apache running?

• Is the SSH service working?

• Is the application running?

• Is the program listening on the correct port?

• Is the service only listening on 127.0.0.1?

• Did the service just crash or fail to restart?

Instead of checking network routes, logging into the server to check service status is usually faster.

5. How to Troubleshoot a Closed Port

When a port is unreachable, the worst thing is to check things randomly. You might change DNS, restart Nginx, then check the firewall, only to find out the cloud security group wasn't configured. When troubleshooting, follow this chain:

Is DNS resolution correct?
        ↓
Is the target IP correct?
        ↓
Is the TCP port connectable?
        ↓
Is the server listening on that port?
        ↓
Is the system firewall allowing it?
        ↓
Is the cloud security group allowing it?
        ↓
Is CDN / WAF / DDoS protection blocking it?
        ↓
Is there a network routing issue?

1. First, Verify DNS Resolution

If you're testing:

example.com:443

The first step is to confirm which IP the domain resolves to.

Especially if you recently:

• Changed servers;

• Modified DNS records;

• Integrated a CDN;

• Switched to a DDoS-protected IP;

• Adjusted geo-DNS settings;

If access issues occur after such changes, check DNS first.

Because if the domain resolves to the wrong server, testing port 443 repeatedly won't help.

If you notice different regions resolve to different IPs, don't immediately assume DNS is broken. When using CDN or geo-DNS, it's normal to return different IPs based on region and ISP.

What you really need to confirm is:

Are these IPs the node addresses your service should be using?

2. Check Basic Server Reachability

Once DNS is fine, use Ping to check the basic network status of the target IP.

If multiple regions can ping successfully and latency is stable, the server's basic network connectivity is likely intact.

But if Ping times out, don't immediately assume the server is down.

Because the server might have ICMP disabled.

Chahu's official troubleshooting content also mentions that Ping is only a reference; if a server or CDN blocks ICMP, Ping may show 100% packet loss while HTTP services still work. Therefore, you need to verify actual service ports like TCP 80 and 443.

3. Check if the Server is Listening on the Port

This is a very common cause of port failures.

For example, an HTTPS website should listen on:

443

But if the Nginx service isn't running, public access will fail.

On Linux, you can run:

ss -lntp

Some systems also support:

netstat -lntp

If port 443 is listening properly, you'll typically see something like:

LISTEN 0 511 0.0.0.0:443

If you can't find 443 at all, check the web server configuration instead of external routes.

Also, pay attention to the listening address.

For example:

127.0.0.1:8080

means the service is only listening on the loopback address.

It might work fine from inside the server, but external devices can't connect.

4. Check the Server Firewall

If the service is listening but public TCPing still times out, check the system firewall.

Common ones include:

• firewalld;

• iptables;

• nftables;

• Windows Defender Firewall.

For example, if Nginx is listening on:

0.0.0.0:443

but the firewall doesn't allow external TCP 443 traffic, public tests will still fail.

In this case, you'll often see:

Local curl on server: Normal
Public TCPing: Timeout

5. Check the Cloud Security Group

If you're using Alibaba Cloud, Tencent Cloud, AWS, Azure, or other cloud providers, note that there's usually a security group layer outside the system firewall.

This is often the real reason why "local services work fine, but the public can't connect" on new servers.

For example, you deployed a new service:

TCP 8443

The program is running:

0.0.0.0:8443

Local access works fine.

But public TCPing keeps timing out.

In this case, check the cloud platform's security group inbound rules to see if TCP 8443 is allowed.

6. Check CDN, WAF, and DDoS Protection Policies

If your website uses CDN, WAF, or DDoS protection, the actual access path has an extra layer.

For example:

User
 ↓
CDN / DDoS protection
 ↓
Origin server

In this case, users being able to connect to the CDN's port 443 doesn't mean the CDN can connect to your origin server.

You might see:

Client → CDN 443: Normal
CDN → Origin 443: Failed

The symptom might not be a browser "connection timeout," but rather:

502 Bad Gateway
504 Gateway Timeout

In this case, check:

• CDN origin port;

• Origin server firewall;

• Origin server IP whitelist;

• Origin protocol (HTTP/HTTPS);

• Origin Host configuration;

• DDoS protection access control;

• WAF security rules.

6. Common Port Failure Scenarios

In real-world troubleshooting, most failures don't tell you clearly "security group port 443 is not open." You usually just see "website won't load," "SSH won't connect," or "API suddenly times out." Here are some typical scenarios.

Scenario 1: Ping Works, but Port 443 is Unreachable

For example:

DNS: Normal
Ping: Normal
TCP 443: Timeout

Check in this order:

Nginx / Apache
      ↓
Is 443 listening?
      ↓
System firewall
      ↓
Cloud security group
      ↓
CDN / DDoS protection policies

At this point, studying Ping latency further is pointless.

Scenario 2: Port 80 Works, but Port 443 Doesn't

For example:

TCP 80: Normal
TCP 443: Failed

This means the server's overall network isn't down.

The problem is clearly with the HTTPS entry point.

Check:

• Is 443 listening?

• HTTPS virtual host configuration;

• Firewall rules for 443;

• Cloud security group;

• CDN HTTPS configuration.

SSL certificate misconfiguration usually occurs after the TCP connection is established, so if you can't even establish a TCP connection on 443, don't focus on certificates first.

Scenario 3: Server Can Connect Locally, but External Connections Fail

For example, from inside the server:

curl http://127.0.0.1:8080

returns normally, but external tests to:

203.0.113.10:8080

keep timing out.

In this case, check:

Service listening address
Security group
System firewall
NAT
Port forwarding
IDC ACL

Especially confirm whether the program is only listening on:

127.0.0.1:8080

instead of:

0.0.0.0:8080

Scenario 4: Only One ISP Fails to Connect

For example:

Telecom: Normal
Unicom: Normal
Mobile: Widespread timeouts

In this case, check:

• Routing from Mobile to your data center;

• CDN Mobile nodes;

• BGP routing;

• Firewall rules for IP ranges;

• Regional access controls;

• DDoS mitigation routes.

You can also use Traceroute or MTR to determine where the issue starts.

Scenario 5: TCPing Works, but the Website Still Won't Load

This is another common misconception.

For example:

TCP 443: Normal
Website: Won't load

If TCP connections are working, there's no need to keep focusing on whether the port is open.

Next, check:

TLS handshake
   ↓
HTTP status code
   ↓
Web server
   ↓
Application (PHP / Java / Node.js, etc.)
   ↓
Database
   ↓
Third-party APIs

If you're getting 403, 404, 500, 502, or 504, the issue is in the HTTP or application layer.

7. How to Choose Between TCPing, Ping, and HTTP Checks

When troubleshooting network issues, you don't need to run all tools at once. First, determine what you're trying to confirm:

For example, if a website won't load, you can follow this order:

DNS
 ↓
Ping
 ↓
TCPing 80 / 443
 ↓
HTTP / HTTPS
 ↓
Traceroute / MTR

Of course, this isn't a fixed process. If the browser clearly returns:

HTTP 500

That means DNS, TCP, and HTTP communication have already reached the server response stage, so there's no need to start over with Ping.

If you see:

403 Forbidden

It also means the request likely reached the CDN, WAF, or web server, so focus on access control and security rules. Effective troubleshooting isn't about running every tool; it's about deciding which layer to check next based on current results.

The most common mistake when checking server ports is relying only on Ping. If the server responds to Ping, it only means there's basic IP connectivity; it doesn't prove that ports like 80, 443, or other TCP ports used by SSH or APIs can establish connections. Conversely, Ping timeout doesn't mean the server is down, because many servers and CDNs restrict ICMP. In practice, start with TCPing to test business ports, then use results from different regions and ISPs to determine the scope of the problem.

If all test nodes fail to connect, prioritize checking service listening, system firewall, and cloud security groups. If only a specific region or ISP is affected, look into routing, CDN nodes, and access control policies. If TCPing is normal but the webpage still won't load, continue checking TLS, HTTP status codes, and server applications. Following this layer-by-layer approach is far more effective than repeatedly restarting the server when a website doesn't load.

FAQ

1. Which is more serious: TCPing shows "Connection Refused" or "Timeout"?

From a troubleshooting perspective, "Refused" actually provides more information. It means your packets reached the target server, and the server responded, but no process is listening on that port. This is a clear signal that you don't need to check firewalls or security groups; go straight to the server and see if Nginx, SSH, or Java processes are down. "Timeout" is trickier because any layer in between could be dropping packets, so the scope is broader—you need to check everything from local firewalls to ISP backbone networks to the target server's security group.

2. I'm testing a domain, but the IP returned by TCPing is different from my origin server IP. Is this normal?

Absolutely normal. If your website uses a CDN, DDoS protection, or global acceleration service, the domain resolves to the edge node addresses of those providers, not your origin server's real IP. In this case, TCPing tests the path from the user to the CDN node. If it times out, it doesn't necessarily mean your origin server is down; it could be that a particular CDN node is having issues. To confirm whether your origin server's port is stable, test using the origin server's IP directly, bypassing the CDN.

3. I've allowed the port in the server firewall and added rules to the security group, but TCPing still times out. Why?

One often-overlooked area is the cloud server's internal routing table or policy-based routing. Some Linux distributions enable reverse path filtering by default. If requests come in via the public network interface, but the server's default gateway is misconfigured, the return packets might try to go out through another interface without a public IP, so they never reach the client. From the client's perspective, it looks like it's waiting for a handshake packet until it times out. In this case, log into the server and capture packets. If you see SYN packets but no SYN-ACK replies, the return routing is likely the problem.

4. If TCPing to a database port (like MySQL's 3306) succeeds, does that mean I can definitely connect to the database?

It only means the network layer is fine, but there are still several steps before you can actually query data. A successful TCP three-way handshake proves that the MySQL process is listening on 3306 and the firewall isn't blocking it. But next, there's MySQL's internal connection limit. If max_connections is reached, you can establish a TCP connection, but MySQL will reject the handshake request, and the client will report "Too many connections." Additionally, if the server uses iptables' connlimit module to limit concurrent connections per IP, TCPing might succeed occasionally, but connections will drop under load.

5. I switched to an uncommon port, like 12345, and TCPing works, but the service feels slow. Does the port number matter?

The port number itself doesn't matter, but ISPs may have rate-limiting policies for high ports. Some ISPs apply QoS throttling to non-standard ports (e.g., above 1024) on their backbone networks, giving them lower priority than ports 80 and 443. Also, if your server is overseas, using a high port like 12345 might trigger deep packet inspection in some regions, increasing latency. If your business allows, it's better to put external services on common SSL ports like 443 or 8443 for better compatibility and network quality.