Troubleshooting VPS Network and SSH Issues

Network issues feel urgent because they block all other work. Start from the outside in: can you ping the IP? Does TCP reach port 22 or 443? Is the service listening inside the guest? Only then change configuration.

Nexelya status and your service power state should be confirmed before deep guest debugging—an stopped VM explains total loss of connectivity.

From an external host, ping the primary IP. Absence of ping may be normal if ICMP is filtered—test TCP with nc -zv IP 22 or curl -v https://IP. If TCP fails externally but works via KVM localhost curl, suspect guest firewall or wrong bind address (0.0.0.0 vs 127.0.0.1).

Verify the IP assigned in the panel matches what you are targeting. Stale DNS records are a frequent cause of apparent outages after migration.

Connection refused means nothing listens on the port or a firewall dropped the packet—check sshd status and UFW. Connection timed out suggests network path or firewall blackhole. Permission denied (publickey) indicates key mismatch—compare authorized_keys with your local pubkey fingerprint.

Use the Nexelya KVM console to inspect sshd logs in /var/log/auth.log when locked out. Temporarily allow your IP in the firewall from console if you misconfigured deny rules.

• ss -tlnp | grep 22 — confirm sshd listening.
• ufw status verbose / firewall-cmd --list-all.
• ip addr and ip route for missing default gateway.

If package installs fail with unknown host, check /etc/resolv.conf and systemd-resolved. Outbound SMTP port 25 may be restricted by policy—use authenticated relay providers on port 587/465 for application mail.

Escalate when the panel shows running but ARP or routing fails from multiple external networks, hypervisor-level issues are suspected, or IP allocation does not match routing tables. Include traceroute, MTR, timestamps, and service ID for faster resolution from the Nexelya operations team backed by Nexelya infrastructure staff.

If only one geographic region cannot reach your IP, suspect upstream filtering or GeoIP blocks—not always hypervisor issues.

MTU mismatches on VPN tunnels cause subtle failures; try lowering MTU to 1400 on overlay interfaces.

Document baseline traceroutes when healthy so comparisons during incidents are meaningful.