Common Reasons Why Cloud Server Ports Are Unreachable and How to Fix Them

Recently a reader asked why a cloud server’s port could not be accessed even though the server appeared to be running. This classic problem is addressed by enumerating common causes and their solutions to aid troubleshooting.

1. Application Not Started

The simplest mistake is trying to diagnose the server while the application itself has not started successfully.

If you use a control panel such as BT (BaoTa) Linux instead of manually running a JAR, the panel may show the service as "running" briefly before it crashes back to "not started" due to system anomalies.

To verify that the application is running, use the Linux ps command, for example:

ps aux | grep <your project name>

If the process is active, the output will resemble the screenshot below.

2. Port Listening Errors

Beyond starting the application, ensure it is listening on the intended port. Use netstat to inspect port usage:

netstat -ntlp | grep <your port number>

If the port is correctly bound, you will see output similar to the following image.

Notice the :::8104 and :::* entries, which indicate the program is listening on all IPv4 addresses at port 8104 and accepting connections from any source. Different values may cause remote access failures, requiring a change to the application’s port configuration.

3. Cloud Provider Security Group

When using a cloud server for the first time, many overlook the security‑group rules. Open the security‑group settings in your cloud console and ensure the required inbound port is allowed.

The screenshot shows the source set to 0.0.0.0/0 , which permits all IPs. For production, restrict this to specific IP ranges; for learning, allowing all may be acceptable.

4. Server Firewall

Linux distributions include built‑in firewalls. After opening the cloud‑side port, also verify the OS firewall configuration.

On Ubuntu you can check the firewall status with either of the following commands:

# 查看防火墙状态
sudo iptables -L
sudo systemctl status firewalld

If the application still cannot be reached, you may temporarily stop the firewall (not recommended for production):

sudo systemctl stop firewalld
sudo systemctl disable firewalld

5. Application‑Level Restrictions

Beyond the OS firewall, the application itself may block certain IPs. For example, the BT Linux security panel can impose IP restrictions, and Nginx or custom code can also filter requests.

6. Server Network Issues

In extreme cases the server may lose network connectivity or its network configuration may be mis‑set. Use ping or traceroute to test connectivity:

ping <your server address>
traceroute <your server address>

7. User‑Side Problems

Sometimes the issue lies with the client: a local network outage, ISP problems, or the user’s IP being blocked by the server (e.g., overseas IP restrictions). Verifying the client’s network and, if necessary, switching to a different network often resolves the problem.

Another scenario is when the server blocks overseas IPs, causing some users to lose access while others can connect.

In the example that prompted this article, the issue turned out to be an overseas IP block; switching to a domestic network restored connectivity.