Server Unreachable? Diagnose Connectivity Before Opening a Ticket

Your VDS has stopped responding. Ping reports 100% packet loss, SSH will not connect, and the website appears to have left the internet without forwarding its mail.

This may indicate a provider network failure. It can also mean an expired service, an operating system that did not boot, an enthusiastic firewall rule, a blocked port, a DDoS null route, or a problem somewhere between your internet provider and the datacenter. These cases look similar from a browser but require very different fixes.

Here is a practical way to diagnose server connectivity and packet loss before opening a support ticket. We use a VDS as the example, although most of the process also applies to dedicated servers and other remotely hosted systems.

First confirm that the service should be online

Open the customer portal and check that the service is active and paid for the current billing period. Also look for suspension, expiration, abuse, or billing notices. Network diagnostics cannot find a route to a virtual machine that was switched off after its invoice expired.

Next, review your support tickets and provider notifications. Check the ITLDC status page for an incident or scheduled maintenance affecting your location. Check the status page of your home or office internet provider too. If you depend on another VPN, DNS, or network provider, check its notices as well. Planned maintenance is much easier to diagnose when you know it is planned.

Do not rely only on a green summary at the top of a status page. Confirm that the specific location and relevant component are operational, and read recent incident updates. A management portal can be healthy while one datacenter network is undergoing maintenance.

Check the server through its console

If the service is active, connect to its console. For a VDS, use the VNC console available in the service control panel. For a dedicated server, the BMC or IPMI interface with integrated IP KVM provides access to the operating system console.

These console connections do not depend on SSH or the operating system’s public network configuration, so they help separate a server problem from a path problem.

Confirm that the operating system has booted and is not waiting at an emergency shell, filesystem check, or bootloader prompt after a failed upgrade. Then inspect the network interface, IP address, default route, and firewall from the operating system.

On a Linux server, these commands provide a useful first look:

ip address
ip route
ping -c 20 1.1.1.1
ss -lntup

You can replace 1.1.1.1 with another known external address that responds to ICMP. The exact commands depend on the operating system and configuration. The important questions are simple: does the server have the expected address and a default route, can it reach an external IP, and is the required application listening?

If you recently changed Netplan, NetworkManager, systemd-networkd, routing, DNS, nftables, iptables, UFW, firewalld, or an application binding, revert the change and test again.

Problems can also appear after an operating system or package upgrade, especially if it updated the kernel, network manager, firewall, or interface configuration. Check whether the timing matches, then review the upgrade logs and changed configuration files. Work through the console: a broken SSH connection is not a particularly useful tool for repairing the network configuration that broke it.

Check for a DDoS null route or RTBH notification

Look for a notification saying that the server address was filtered with RTBH, also called a null route or blackhole route. Providers use this mechanism during some network floods to stop malicious traffic before it reaches the affected network or overwhelms shared infrastructure.

When an address is null-routed, complete packet loss from outside is expected. Restarting the VDS or reinstalling SSH will not change an upstream routing decision. Check the notice for the expected filtering period and wait for it to expire. Contact support if there is no clear end time, the notice says that the attack continues, or you need help evaluating protection options. Reference the notification in your ticket.

Test from more than one location

A failed test from one laptop proves that one path failed. It does not yet prove that the server is unreachable everywhere.

Use an external service such as Check-Host or ping.pe to ping the IP address from several regions. The ITLDC Looking Glass can run network tests from ITLDC locations and provides reference addresses for testing paths toward our network. Compare results from locations near you and near the server, then add a few more distant locations.

Interpret the pattern rather than one red result:

• If every location fails and the console also cannot reach the internet, investigate the VDS configuration, service state, null route, or provider network.
• If external locations reach the address but your home or office cannot, the server is not offline for everyone. The fault may be on your local network, with your ISP, or along that particular route.
• If several networks in one country or region fail while other regions work, collect traces from the affected networks. This may indicate regional routing, filtering, or protocol blocking, but the tests alone do not prove who applied it.
• If ping fails but the application works, ICMP may simply be filtered. Ping is a diagnostic signal, not a requirement for every service.

Try the same connection from another network, such as mobile data or a different office. If you normally use a VPN, disable it and repeat the test. If you normally connect directly, trying a reputable VPN provides a useful comparison path. If changing networks or toggling the VPN fixes the problem, contact the provider responsible for the failing connection. For a brief interruption, it may be enough to wait and test again.

Test the port, not only the IP address

An IP address can be reachable while one application is not. If SSH, HTTPS, a game server, or a VPN endpoint is the actual problem, test the relevant TCP or UDP port from multiple locations. Check-Host offers remote TCP checks, and local tools can test a TCP connection directly:

nc -vz xx.xx.xx.xx 22
curl -v --connect-timeout 10 https://xx.xx.xx.xx/

Replace xx.xx.xx.xx and the port with your real values. A timeout, a rejected connection, and an application error mean different things. A rejection often means that the host responded but nothing accepted the connection on that port. A timeout may mean that a firewall or network path silently dropped it. If the TCP connection succeeds but the application later returns an error, the path and listener are working. The problem is now higher up the stack.

On the VDS console, use ss -lntup on Linux to confirm that the service is listening on the expected port and address. A daemon bound only to 127.0.0.1 cannot accept public connections. Also check both the guest firewall and any firewall or security-group controls in the hosting panel.

Measure packet loss and the route in both directions

If the problem persists, collect evidence while it is happening. Start with 20 to 50 ordinary ping packets from the affected device to the server:

ping -c 30 xx.xx.xx.xx

On Windows, run ping -n 30 xx.xx.xx.xx. Keep the complete output, including the sent, received, loss, and latency summary.

Then run MTR or traceroute from the affected device toward the server. Ten to twenty MTR cycles are usually sufficient for an initial ticket:

mtr --report --report-cycles 20 --no-dns xx.xx.xx.xx
traceroute -n xx.xx.xx.xx

On Windows, use WinMTR for a report with repeated measurements, or run:

tracert -d xx.xx.xx.xx

One direction shows only half the route. Internet routing is often asymmetric, so the return traffic may pass through different networks. Use the server console to run MTR or traceroute back to the public IP of the affected device or office gateway. If that endpoint does not answer ping, the trace can still reveal part of the return path. Mention the local filtering in your ticket.

Do not declare a router broken because one intermediate MTR hop shows 100% loss. Routers may limit or ignore diagnostic replies while continuing to forward normal traffic. Loss becomes meaningful when it begins at one hop and continues through later hops, especially to the destination. The destination’s ping and application behaviour matter more than one silent router in the middle.

Run tests from the actual problematic endpoint. A trace from an unrelated online tool is useful for comparison, but it cannot describe the path from your home or office. Do not crop the first or last hops unless revealing an address would create a genuine privacy concern; those hops often show whether the issue begins on the local network or near the server.

What to include in a support ticket

If the earlier checks do not identify the cause, open a support ticket through the customer portal. A useful ticket gives an engineer enough detail to reproduce or observe the symptom. Investigating a network anomaly is difficult when it has disappeared and nobody knows the conditions in which it occurred.

This is why the source network, destination, affected protocol or port, exact time, direction, and pattern all matter. “The server was slow yesterday” describes the experience but gives an engineer almost nothing to test. “Connections from this source address to this server begin losing packets every evening after 18:00 CEST” gives us something we can check, measure, and compare. Include:

1. The affected service and server IP address.
2. A short description of what fails, from which source IP or network, and whether it affects ICMP, a specific port, or an application.
3. Ping output containing 20 to 50 packets at the default packet size.
4. MTR, traceroute, or tracert output from the affected endpoint to the server and from the server back to the affected endpoint. For MTR, 10 to 20 cycles are enough for an initial report.
5. The exact test time, with date and time zone. “Now” becomes surprisingly unhelpful after a ticket waits in a queue; 2026-08-23 18:20 CEST does not.
6. Whether the issue is continuous or intermittent, and any pattern you have observed.
7. Whether a VPN tunnel was active on the client or server during the test.

If the server acts as a VPN endpoint and the measurements were made through the active tunnel, say so explicitly. Repeat the ping and route tests with the VPN tunnel disabled and attach both sets of results. Otherwise, support may investigate the hosting route while the actual loss occurs inside the tunnel, or do the reverse.

A good summary can be very short:

Since approximately 18:00 CEST, I see 15-25% packet loss and noticeable delays in SSH and HTTPS connections from yy.yy.yy.yy on ISP ExampleNet to my VDS at xx.xx.xx.xx. Attached are 30-packet ping results and 20-cycle MTR reports in both directions, collected at 18:20 CEST with the VPN disabled.

Attach the raw text output where possible. Screenshots are harder to search, copy, compare, and use with network tools.

Please do not use AI to write the ticket

This advice may sound unusual in 2026, but it comes from the people who have to read the result: do not ask AI to turn a simple issue into an elaborate support ticket.

AI-generated tickets often expand one useful sentence into several paragraphs of polished but irrelevant speculation. They may mention BGP, DNS, DDoS mitigation, firewall policy, and “upstream infrastructure anomalies” without providing the source IP, exact time, or a single usable MTR report. The result looks professional but takes longer to understand and may still omit the critical data needed to investigate the issue.

Our tickets are handled by real engineers, not by an AI system negotiating with another AI system. Write one or two plain sentences describing the symptom, then attach the requested measurements. Imperfect English is fine. Exact addresses, timestamps, directions, and test results are much more valuable than impressive terminology.

Use tools to collect evidence. Use your own words to say what is broken.

Diagnose first, then escalate with evidence

When a VDS appears unreachable, first make sure the cause is not the VDS or service itself. Start with the simplest questions: is the service paid and active, did the operating system boot, and did the problem appear after a configuration change or system update? A firewalld rule that took effect after a reboot can look remarkably similar to an external network outage.

Then check notifications and the status page, look for an RTBH notice, verify the listening ports, and compare tests from several networks. If only one access network fails, changing the server is unlikely to repair that provider’s route.

When support is needed, capture the failure while it is happening. Ping the destination, measure both directions with MTR or traceroute, record the exact time and time zone, and repeat the test without any VPN tunnel. A concise report with good evidence lets an engineer start investigating immediately instead of spending the first reply asking when, where, and in which direction the problem occurred.

There is an old rule: “A problem well stated is a problem half solved.” A clear ticket may also earn a little goodwill from support, because a precise problem is faster and more pleasant to investigate. There is one catch in the age of AI: polished prose is not the same as a well-stated problem. It still needs real measurements behind it.