Loading…

Network Connectivity

How to Troubleshoot Cloud Server Network Connectivity Issues

Last updated: 16 Oct- 2026

When your cloud server cannot be reached, cannot reach the internet, or fails on one service, the fault is usually in one of five places: the network configuration, the route, DNS, the firewall, or the service itself.

This guide tests each in order so you can find the cause quickly.

Before you begin: If SSH or RDP is down, use your console access or contact ICSDC support. Take a snapshot or backup before changing network or firewall settings, because a wrong change can lock you out.

Step 1: Identify the symptom

Test from a second network, such as a mobile hotspot, to rule out your local connection. Then note which applies:

  • The server is unreachable from outside.
  • The server cannot reach the internet.
  • Only one port or service fails.
  • IP addresses work but domain names fail (go to Step 4).

Step 2: Check the IP address and gateway

Linux:

ip -br addrip route

Windows (Command Prompt or PowerShell):

ipconfig /all

Confirm the interface is up, has the IP address assigned to your server, and has a default gateway. On Linux, ip route should show a default via line. A Windows address starting with 169.254 means no valid address was obtained. If the address or gateway is missing or wrong, correct it in your network configuration (netplan, NetworkManager, or Windows adapter settings), or ask support to confirm your assigned values.

Step 3: Test the gateway and an external IP

ping -c 4 <gateway-IP>ping -c 4 8.8.8.8

On Windows, use ping <gateway-IP> and ping 8.8.8.8.

  • Gateway fails: Recheck the IP address, subnet mask, and gateway from Step 2.
  • Gateway works, 8.8.8.8 fails: The problem is upstream routing or an outbound firewall rule. Continue to Step 5.
  • Both work: Basic connectivity is fine. Go to Step 4.

Some networks block ICMP, so a failed ping is not conclusive. Confirm with the TCP test in Step 7.

Step 4: Check DNS

nslookup icsdc.com

If the lookup fails but pinging an IP address works, DNS is the problem. On Linux, check resolvectl status (systemd-resolved) or /etc/resolv.conf. On Windows, check "DNS Servers" in ipconfig /all, and run ipconfig /flushdns to clear the cache. Set a resolver the server can reach, then retry.

Step 5: Trace the network path

Linux (install the mtr package if needed):

mtr -rwc 10 <destination>

Windows:

tracert <destination>

Loss that starts at one hop and continues through every later hop points to a fault at that hop. Loss at a single middle hop with none afterwards is usually ICMP rate limiting and can be ignored. If the fault is outside your server, send the output to ICSDC support.

Step 6: Check the listening service and the firewall

On the server, confirm the service listens on the expected port:

sudo ss -tulpn

A service bound only to 127.0.0.1 accepts local connections only. Change its bind address to 0.0.0.0 or the server's IP in its configuration, then restart it.

Next, review the firewall:

sudo ufw status verbose        # Ubuntusudo firewall-cmd --list-all   # RHEL-based systems

On Windows, open Windows Defender Firewall with Advanced Security and check Inbound Rules for the port. To open one port on Ubuntu:

sudo ufw allow 443/tcp

Warning: Before enabling ufw, allow your SSH port first (sudo ufw allow 22/tcp, or your custom port) to avoid locking yourself out. Never disable the firewall permanently as a fix; open only the required port.

Also check any network-level firewall in front of the server. If ICSDC manages it, ask support to confirm the rule, or review the options under firewall security.

Step 7: Test the port from a client

Linux or macOS:

nc -zv <server-IP> 443

Windows PowerShell:

Test-NetConnection <server-IP> -Port 443

TcpTestSucceeded : True means the connection worked. "Connection refused" means the server was reached but nothing is listening or the connection was rejected: recheck Step 6. A timeout usually means packets are dropped by a firewall or lost on the route: recheck the firewall rules and Step 5.

Verify the fix

Repeat the failed test from an outside network: ping, the port test, then open the application. If it still fails, collect the output of ip addr, ip route, mtr, ss -tulpn, and your firewall status, and contact ICSDC support.