Can't Connect to Your Server? Troubleshooting with ping, tcping and mtr
SSH timeouts, failed Remote Desktop connections and websites that won't load are the most common server problems. The cause could be your local network, a link along the route, the server's firewall, or the service itself not running. If you troubleshoot in the order "is it reachable, is the port open, what does the route look like," you can pinpoint most problems within minutes.
Key Takeaways
- Server connection problems can be troubleshot in the order "ping for reachability, tcping for ports, mtr for routing, VNC for the server internals," which pinpoints most problems within minutes.
- A failed ping does not necessarily mean a server is unreachable, because many servers and firewalls disable ICMP, so a port test with tcping, nc or Test-NetConnection is needed to confirm.
- A port test result of
Connection refusedmeans the server is reachable but nothing is listening on that port, whiletimed outusually points to a firewall, a security group rule that isn't open, or a network route issue. - In mtr results, packet loss that starts at a certain hop and continues to the final hop indicates a problem at or near that hop, while loss at a single intermediate hop with a healthy destination is usually ICMP rate limiting and can be ignored.
- IMIDC cloud servers and dedicated servers both offer a VNC console in the Client Center for checking from inside the server, and IMIDC's technical support team responds to tickets 24/7.
Who This Is For / Prerequisites
- Local computer: Windows 10/11, macOS or Linux.
- The server's public IP and the port you need to reach (SSH defaults to 22, RDP to 3389, websites to 80/443).
- Access to the IMIDC Client Center so you can check server status and use the VNC console.
Guide / Steps
1. Rule Out the Simplest Causes First
Before running any tests, confirm three things: the server shows as running in the Client Center; it hasn't expired or exceeded its traffic quota; and you can access other websites normally from your local machine. If multiple devices on multiple networks all fail to connect at the same time, move on to the steps below.
2. ping: Check Whether the IP Is Reachable
# Windows (send 20 packets)
ping -n 20 SERVER_IP
# macOS / Linux
ping -c 20 SERVER_IP
- Replies with no packet loss: the network layer is basically fine; the problem is likely the port or the service.
- All requests time out: the server may be down, the IP may be blocked or null-routed, or the server may have ICMP disabled. A failed ping doesn't necessarily mean you can't connect; confirm with a port test.
3. tcping / nc / telnet: Check Whether the Port Is Open
Port tests reflect the real situation better than ping.
Windows (built into PowerShell):
Test-NetConnection SERVER_IP -Port 22
TcpTestSucceeded : True in the output means the port is reachable. You can also use the third-party tcping.exe for continuous testing: tcping -t SERVER_IP 22.
macOS / Linux:
# Test a port with nc: -z scans without sending data, -v shows details, -w 3 sets a 3-second timeout
nc -zv -w 3 SERVER_IP 22
# Or use telnet (install separately)
telnet SERVER_IP 22
# For websites, check the HTTP response directly
curl -I -m 10 https://your-domain.com
How to read the results:
succeeded/Connected: the port is open; the problem is at the application layer (username/password, keys, application config).Connection refused: the server is reachable, but nothing is listening on that port. Usually the service isn't running or the port was changed.timed out: packets are being dropped, most often due to a firewall, a security group rule that isn't open, or a network route issue.
4. mtr / tracert: Locate Problems Along the Route
If ping shows heavy packet loss or the port times out, find out which segment of the path is at fault.
# Install on Linux
apt install -y mtr-tiny # Debian / Ubuntu
dnf install -y mtr # Rocky / AlmaLinux
# Install on macOS (requires Homebrew)
brew install mtr
# Send 100 packets and generate a report
sudo mtr -rwc 100 SERVER_IP
Windows users can use the built-in commands:
tracert SERVER_IP
pathping SERVER_IP
What to look for: if packet loss starts at a certain hop and continues all the way to the final hop, the problem is at or near that hop. If loss appears only at a single intermediate hop while the destination is fine, it's most likely a router rate-limiting ICMP and can be ignored. When ICMP is filtered, you can also use NextTrace in TCP mode: nexttrace -T -p 22 SERVER_IP.
5. Check from Inside the Server via VNC
If you can't connect from your local machine, open the VNC console in the Client Center, log in to the server and check the services and firewall:
# Check which ports are listening
ss -tlnp
# Check SSH service status
systemctl status ssh # Debian / Ubuntu
systemctl status sshd # Rocky / AlmaLinux
# View firewall rules
ufw status verbose
firewall-cmd --list-all
iptables -L -n --line-numbers
# Test the server's own outbound connectivity
ping -c 4 1.1.1.1
If the server can't reach the internet at all, its network interface configuration may have been changed. Check whether the output of ip addr and ip route looks normal.
6. Include This Information When You Submit a Ticket
To help our engineers locate the problem quickly, include the following in your ticket:
- Server IP and product name (don't send passwords in a ticket; if login is needed, we'll arrange it separately).
- When the problem started, whether it's ongoing, and which ports or services are affected.
- Your local public IP, region and ISP (you can look these up on sites such as ipinfo.io).
mtrortracertresults from your location to the server, plusTest-NetConnection/ncoutput.- If you can log in via VNC, the
mtrreturn-path results from the server to your local IP. - Whether you've recently changed the firewall, SSH port or network configuration.
FAQ
Ping fails but the website loads. Is something wrong?
No. Many servers and firewalls disable ICMP; as long as your service ports work, you're fine.
Only I can't connect, and everyone else is fine?
Most likely it's your local ISP's route, or your local IP has been blocked by the server's firewall (e.g. fail2ban). Try testing over a mobile hotspot, and check the ban list via VNC.
I can't connect after changing the SSH port?
Make sure the new port is allowed in the firewall. On SELinux systems you also need to run semanage port -a -t ssh_port_t -p tcp NEW_PORT.
The server suddenly went completely offline and all pings time out?
It may have been hit by a DDoS attack and temporarily null-routed, or the server kernel may have crashed. Check the status in the Client Center first, then submit a ticket to confirm.
Summary
When troubleshooting connection problems, work in this order: "ping for reachability, tcping for ports, mtr for routing, VNC for the server internals." You can pinpoint the vast majority of issues yourself. Both IMIDC cloud servers and dedicated servers offer a VNC console in the Client Center for self-recovery. If you've confirmed the problem is on the network route or data center side, put the test results above into a ticket; our technical support team is online and responds 24/7.