Server Unreachable: Diagnostic Steps
Step-by-step guide to diagnosing server access issues using ping, SSH, port checks, firewall verification, and network routing analysis.
Table of Contents
Introduction
Being unable to access your server can stem from many different causes: network issues, firewall rules, service crashes, or hardware failures. In this guide, we'll walk through the steps you should follow to systematically diagnose server access issues.
Step 1: Ping Reachability Check
First, check if your server is reachable on the network:
# Simple ping test
ping -c 10 SERVER_IP
# Ping with timeout
ping -c 10 -W 3 SERVER_IP
Interpreting Ping Results
| Result | Meaning | Possible Cause |
|---|---|---|
| Replies received | Server is reachable on network | Issue may be at service level |
| Request timeout | Packets not reaching destination | Firewall, network issue, or server down |
| Destination unreachable | Routing issue | Wrong IP, network config error |
| 100% packet loss | Complete access loss | Server down or no network connection |
On REXE servers, when an IP has no rules at all, all ports are open. If your IP has rules, Default Block is automatically activated; in that case, ICMP (ping) may also require a rule (Ping toggle) from Path Panel.
Step 2: SSH Connection Test
If ping works, test the SSH connection:
# SSH connection test (verbose mode)
ssh -v root@SERVER_IP
# SSH with timeout
ssh -o ConnectTimeout=10 root@SERVER_IP
# SSH on specific port
ssh -p 2222 root@SERVER_IP
SSH Error Messages
# Connection refused — SSH service not running or wrong port
ssh: connect to host SERVER_IP port 22: Connection refused
# Connection timed out — Firewall blocking or server unreachable
ssh: connect to host SERVER_IP port 22: Connection timed out
# No route to host — Network routing issue
ssh: connect to host SERVER_IP port 22: No route to host
# Permission denied — Authentication failure
Permission denied (publickey,password)
Step 3: Port Access Check
Check if specific ports are open:
# Port check with telnet
telnet SERVER_IP 22
telnet SERVER_IP 80
# Port check with nc (netcat)
nc -zv SERVER_IP 22
nc -zv -w 5 SERVER_IP 80
# Port scan with nmap
nmap -p 22,80,443 SERVER_IP
Port States
| State | Meaning |
|---|---|
| open | Port is open and service is listening |
| closed | Port is reachable but no service |
| filtered | Firewall is blocking the port |
| timeout | Connection timed out |
Step 4: Firewall Check
REXE Path Panel Check
On REXE servers, when an IP has no rules at all, all ports are open. When your IP has at least one rule, Default Block is automatically activated and the relevant port must be opened with a filter rule for access:
- Log in to Path Panel or the Rule Management product in your customer panel
- Click on the relevant IP address
- Verify filter rules exist for required ports
- Confirm rules are in propagated status
Path Panel rules may take 2-5 minutes to reach propagated status. Newly created rules may not be active immediately.
Even if the panel shows the rule as not yet propagated (not updated), the rule has most likely already been deployed within 2-5 minutes. The status may update with a delay due to the panel's status-check interval or the time it takes for the rule to be applied across all nodes on the Path side (except ours). This is only a visual delay in the panel; the port has in fact already been opened in the system.
Server-Side Firewall
If you have console access to the server:
# Check iptables rules
sudo iptables -L -n -v
# UFW status
sudo ufw status verbose
# firewalld status
sudo firewall-cmd --list-all
# nftables rules
sudo nft list ruleset
Temporarily Disable Firewall (For Testing)
# Disable UFW
sudo ufw disable
# Flush iptables rules
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
Disabling the firewall leaves your server vulnerable. Use only for testing and re-enable immediately after.
Step 5: Service Status Check
If you have console access, check service status:
# SSH service status
sudo systemctl status sshd
# Web server status
sudo systemctl status nginx
sudo systemctl status apache2
# List all running services
sudo systemctl list-units --type=service --state=running
# List failed services
sudo systemctl list-units --type=service --state=failed
# Check listening ports
sudo ss -tlnp
sudo netstat -tlnp
Step 6: Network Routing Check
# Route analysis with traceroute
traceroute SERVER_IP
# Detailed analysis with mtr
mtr -r -c 50 SERVER_IP
# Local routing table
ip route show
Step 7: Console Access
If network access is unavailable, try alternative access methods:
REXE Customer Panel
- Log in to my.rexe.tr
- Click on the relevant service
- Use VNC Console or IPMI access
- Try the server restart option
Troubleshooting Checklist
#!/bin/bash
SERVER_IP="SERVER_IP_ADDRESS"
echo "=== Server Access Check: $SERVER_IP ==="
echo -e "\n[1] Ping Check:"
ping -c 5 -W 3 $SERVER_IP 2>&1 | tail -2
echo -e "\n[2] SSH Port (22) Check:"
nc -zv -w 5 $SERVER_IP 22 2>&1
echo -e "\n[3] HTTP Port (80) Check:"
nc -zv -w 5 $SERVER_IP 80 2>&1
echo -e "\n[4] HTTPS Port (443) Check:"
nc -zv -w 5 $SERVER_IP 443 2>&1
echo -e "\n[5] Traceroute:"
traceroute -m 15 $SERVER_IP 2>&1
echo -e "\n=== Check Complete ==="
Common Scenarios and Solutions
| Scenario | Possible Cause | Solution |
|---|---|---|
| Ping not working, no ports open | Server down or no network | Restart server from REXE panel |
| Ping works but SSH won't connect | SSH service crashed or port blocked | Create rule for SSH port in Path Panel |
| SSH connects but website won't load | Web server service crashed | Connect via SSH and restart nginx/apache |
| All ports show as filtered | Firewall blocking all traffic | Check Path Panel rules |
| Intermittent connection drops | Network packet loss or DDoS | Take mtr report, share with REXE support |
Conclusion
Following a systematic approach is important for resolving server access issues. Start with ping checks and progressively verify port access, firewall rules, and service status. Don't forget to check Path Panel firewall rules on REXE servers. If the issue persists, contact REXE support with mtr reports and check results.
Related Articles
SSH Connection Problem: Can't Connect to Server
SSH connection troubleshooting guide: Path.net firewall rules, Default Block, creating a filter rule for SSH port, and step-by-step troubleshooting.
RDP Connection Problem: Can't Connect to Windows Server
RDP connection troubleshooting guide: Path.net firewall rules, Default Block, creating a filter rule for RDP port, and step-by-step troubleshooting.
How to Run an MTR Test and Submit Results to Support
Guide to running MTR network tests with WinMTR and Linux MTR, creating ICMP filter rules, and submitting results to support. Diagnose packet loss and latency.