This topic describes how to use self-service tools and manual troubleshooting to identify issues when an ECS instance can be pinged but a service port is inaccessible. It includes steps to verify security groups, firewalls, port listening status, and link interruptions. -

If you can ping an ECS instance from a client but cannot access a service port, a node on the network path might be blocking the port.

Use the self-service troubleshooting tool

You can use the Alibaba Cloud self-service troubleshooting tool to quickly check security group configurations, the instance's internal firewall, and the listening status of common application ports. The tool provides a clear diagnostic report.

Click to go to self-service troubleshooting page, and switch to the target region.

If the self-service troubleshooting tool cannot identify the issue, proceed with the following manual troubleshooting steps.

Manual troubleshooting

Step 1: Perform a quick check

Go to the ECS console - Instances page.
Click the ID of the destination instance to go to its details page:
1. Ensure that its status is Running and not Stopped or another abnormal status.
2. Confirm that the IP address you use for the connection is the elastic IP address (EIP) currently attached to the instance. If the instance uses a dynamically allocated public IP address, the address might change after a restart.

Step 2: Differentiate between Connection timed out and Connection refused

On your local computer, you can use the telnet or nc command to test the port and observe the returned error message.

# Run on your local computer's terminal (using port 80 as an example)
telnet <Your instance's public IP> 80
# Or
nc -vz <Your instance's public IP> 80

These two errors indicate different types of issues:

A Connection timed out error indicates that the request packet was silently dropped by a firewall device on the network path and no response was received. Go to Scenario 1: Handle a Connection timed out error.
A Connection refused error indicates that the request packet reached the server's operating system, but the system found no program listening on the port and therefore rejected the connection. Go to Scenario 2: Handle a Connection refused error.

Scenario 1: Handle a Connection timed out error

Check the Alibaba Cloud security group.
1. Go to the ECS console - Security Groups page.
2. Find the security group associated with the ECS instance. In the Actions column, click Manage Rules.
3. Select the Inbound tab and check whether a rule allows access to the destination port.
  - If no rule allows access to the destination port, add an inbound security group rule for the port. For more information, see Add a security group rule.
  - If a rule already allows access to the destination port, continue with the following steps.
Check the instance's internal firewall.
Linux instances
This section uses CentOS 7.9 as an example. The operations may differ for other Linux versions.
1. Connect to the Linux instance.
  For more information, see Use Workbench to connect to a Linux instance over SSH.
2. Run the following command to check the firewall status.
  systemctl status firewalld
  If the output contains Active: inactive (dead), the firewall is disabled. No further action is needed.
  If the output contains Active: active (running), the firewall is enabled. Proceed to the next step.
3. Run the following command to view the ports that are open in the firewall.
  firewall-cmd --list-all
  If the output contains ports: 80/tcp, a firewall rule already allows access to port 80. No further action is needed.
  If the output does not contain ports: 80/tcp, run the following command to allow access to port 80.
  firewall-cmd --zone=public --add-port=80/tcp --permanent
  If success is returned, it indicates that access to TCP port 80 is allowed.
Windows instances
This section uses Windows Server 2012 as an example. The operations are similar for other Windows Server versions.
1. Connect to the Windows instance.
  For more information, see Use Workbench to connect to a Windows instance over RDP.
2. Click the icon in the lower-left corner to open Server Manager.
3. In the upper-right corner, choose Tools > Windows Firewall With Advanced Security.
4. Check the firewall status.
  If the firewall is disabled, no action is needed.
  If the firewall is enabled, perform the following steps.
  On the Windows Firewall With Advanced Security page, click Inbound Rules.
  Check the status of Windows Remote Management - Compatibility Mode (HTTP-In).
  If the rule is enabled, no action is needed.
  If the rule is not enabled, right-click the rule and then click Enable Rule.

Scenario 2: Handle a Connection refused error

A Connection refused error indicates that the firewall allowed the connection, but no application on the server was available to accept it. To resolve this, you can check the port's listening status.

Linux instances

This section uses CentOS 7.9 as an example. The operations may differ for other Linux versions.

Remotely connect to the Linux instance.
For more information, see Log on to a Linux instance using Workbench.
Run the following command to check whether the port is being listened on.
```
netstat -an | grep [$Port]    # Replace [$Port] with the actual port number
```
- If the following information is returned, it indicates that port 80 is being listened on.
- If different information is returned, port 80 is not in a listening state because the service has not started. Start the service and check again.

Windows instances

This section uses Windows Server 2012 as an example. The operations are similar for other Windows Server versions.

Log on to a Windows instance using the Workbench terminal (RDP).
In Windows PowerShell, run the following command to check whether the port is being listened on.
```
netstat -ano | findstr "[$Port]"   # Replace [$Port] with the actual port number
```
- If the following information is returned, it indicates that port 80 is being listened on.
- If different information is returned, port 80 is not in a listening state because the service has not started. Start the service and check again.

Perform a deep check with probe tools

You can use a port availability probe tool to test whether a node is blocking the port and causing the access failure.

Use a port availability probe tool

For Linux local clients

On Linux systems, you can use traceroute to probe port availability. The traceroute tool tracks the route that Internet Protocol (IP) packets take to a destination address. It sends TCP packets to the destination port to check the port's connectivity along the entire path from the source to the destination server.

Install traceroute

sudo yum install -y traceroute

traceroute command

The common format for the traceroute command is as follows.

traceroute [-n] -T -p <Destination port number> <Host>

-n: Uses IP addresses directly instead of hostnames (disables reverse DNS lookups).
-T: Probes using TCP.
-p: Sets the probe port number.
<Destination port number>: The port number to probe, such as 80.
<Host>: The address of the destination server to probe, such as 192.168.XXX.XXX.

Test example

The following shows an example command and its output:

[test@centos ~]# traceroute -n -T -p 22 223.5.XXX.XXX
traceroute to 223.5.XXX.XXX (223.5.XXX.XXX), 30 hops max, 60 byte packets
 1 5X.X.X.X 0.431 ms 0.538 ms 0.702 ms
 2 10.88.XXX.XXX 0.997 ms 1.030 ms 10.88.XXX.XXX 1.309 ms
 3 58.96.XXX.XXX 0.393 ms 0.390 ms 58.96.XXX.XXX 0.423 ms
 4 202.123.XXX.XXX 1.110 ms 202.123.XXX.XXX 0.440 ms 0.440 ms
 5 63.218.XXX.XXX 1.744 ms 63.218.XXX.XXX 1.076 ms 1.232 ms
 6 63.223.XXX.XXX 1.832 ms 63.223.XXX.XXX 1.663 ms 63.223.XXX.XXX 1.616 ms
 7 63.223.XXX.XXX 2.776 ms 63.223.XXX.XXX 1.585 ms 1.606 ms
 8 * * 202.97.XXX.XXX 2.537 ms
 9 202.97.XXX.XXX 6.856 ms * *
10 * * *
11 * * *
12 * * 119.147.XXX.XXX 8.738 ms
13 119.147.XXX.XXX 8.248 ms 8.231 ms *
14 * 42.120.XXX.XXX 32.305 ms 42.120.XXX.XXX 29.877 ms
15 42.120.XXX.XXX 11.950 ms 42.120.XXX.XXX 23.853 ms 42.120.XXX.XXX 29.831 ms
16 42.120.XXX.XXX 11.007 ms 42.120.XXX.XXX 13.615 ms 42.120.XXX.XXX 11.956 ms
17 42.120.XXX.XXX 21.578 ms 42.120.XXX.XXX 13.236 ms *
18 * * 223.5.XXX.XXX 12.070 ms !X

For Windows local clients

On Windows systems, you can use tracetcp to probe port availability. The tracetcp tool also sends TCP packets to probe the network path and analyze whether an intermediate node is blocking the destination port.

Install tracetcp

Download and install the WinPcap library from the official WinPcap website.
Download tracetcp from the official tracetcp website.
Unzip the downloaded tracetcp file to the C:\Windows directory.
Important
If you unzip the file to a non-system directory, you must manually modify the system environment variables to ensure that the command can be invoked directly.

Usage

In Windows PowerShell or the cmd command line, enter the tracetcp command. The common format for the tracetcp command is as follows.

tracetcp <IP>:<Port>

Note

<IP>: The IP address or domain name of the destination server.
<Port>: The destination port to probe.

For more information about tracetcp parameters, run the tracetcp -? command to view the help information.

Test example

The following shows an example command and its output:

C:\ >tracetcp www.aliyun.com:80
Tracing route to 140.205.XX.8 on port 80
Over a maximum of 30 hops.
1 3 ms 4 ms 3 ms 10.102.XXX.XXX
2 13 ms 3 ms 4 ms 10.102.XXX.XXX
3 3 ms 3 ms 2 ms 140.205.XXX.XXX
4 4 ms 3 ms 3 ms 180.163.XXX.XXX
5 5 ms 4 ms 7 ms 101.95.XXX.XXX
6 6 ms 5 ms 7 ms 124.74.XXX.XXX
7 8 ms 8 ms 8 ms 124.74.XXX.XXX
8 10 ms 10 ms 8 ms 114.80.XXX.XXX
9 9 ms 9 ms 11 ms 42.120.XXX.XXX
10 * * * Request timed out.
11 Destination Reached in 8 ms. Connection established to 140.205.XXX.XXX
Trace Complete.

Analysis of probe results

If a port is blocked at a specific hop, no data is returned from subsequent hops. This helps you identify the abnormal node. You can then query the IP address to find its carrier and report the issue.

Case 1

Probe result: No data is returned after the third hop, which indicates that the port is blocked at this node.

Analysis: A query shows that this node has an internal IP address. The issue is likely caused by a security policy on the on-premises network. Contact your local network administrator for further investigation.

C:\> tracetcp www.aliyun.com:135
Tracing route to 115.102.XXX.XXX on port 135
Over a maximum of 30 hops.
1       3 ms    3 ms    3 ms    10.102.XXX.XXX
2       4 ms    3 ms    3 ms    10.102.XXX.XXX
3       3 ms    3 ms    3 ms    140.205.XXX.XXX
4       *       *       *       Request timed out.
5       *       *       *       Request timed out.
6       *       *       *       Request timed out.
7       *       *       *       Request timed out.
8       *       *       *       Request timed out.
9       *       *       *       Request timed out.
10      *       *       *       Request timed out.
11      *       *       *       Request timed out.
12      *       *       *       Request timed out.
Trace Complete.

Case 2

Probe result: As shown in the following output, no data is returned after the 11th hop, which indicates that the port is blocked at this node.

Analysis: A query shows that this node belongs to China Mobile Beijing. You need to report the issue to the carrier.

[root@mycentos ~]# traceroute -T -p 135 www.baidu.com
traceroute to www.baidu.com (111.13.XXX.XXX), 30 hops max, 60 byte packets
 1  * * *
 2  111.13.XXX.XXX (111.13.XXX.XXX)  4.115 ms  4.397 ms  4.679 ms
 3  112.15.XXX.XXX (112.15.XXX.XXX)  901.921 ms  902.762 ms  902.338 ms
 4  200.35.XXX.XXX (200.35.XXX.XXX)  2.187 ms  1.392 ms  2.266 ms
 5  * * *
 6  58.200.XXX.XXX (58.200X.XXX.XXX)  1.688 ms  1.465 ms  1.475 ms
 7  63.128.XXX.XXX (63.128.XXX.XXX)  27.729 ms  27.708 ms  27.636 ms
 8  * * *
 9  * * *
10  200.38.XXX.XXX (200.38.XXX.XXX)  28.922 ms 200.38.XXX.XXX (200.38.XXX.XXX)   29.030 ms  28.916 ms
11  204.35.XXX.XXX (204.35.XXX.XXX)  29.169 ms  28.893 ms 204.35.XXX.XXX (204.35.XXX.XXX)  30.986 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *