Run a ping and traceroute

When a service fails from a particular connection, support may ask for a ping and a traceroute to collect the resolved address, response times, apparent ICMP packet loss and the route seen from that network. Run both tests from the affected computer and connection, and note the date and time.

These tests provide network evidence, but on their own they do not identify the cause or check that HTTP, HTTPS, PHP or the database are working.

Windows

In Windows 10 or 11, open Start, type Terminal or Command Prompt and open the result. You do not need to run it as administrator.

Replace dominioconproblemas.com with the affected domain:

ping -n 50 dominioconproblemas.com

The first line shows the IP address Windows resolved the domain to. It may belong to the server, a proxy, a CDN or a load balancer:

Pinging dominioconproblemas.com [xx.xx.xxx.xxx] with 32 bytes of data:
Reply from xx.xx.xxx.xxx: bytes=32 time=256ms TTL=251
Reply from xx.xx.xxx.xxx: bytes=32 time=257ms TTL=251
...
Ping statistics for xx.xx.xxx.xxx:
    Packets: Sent = 50, Received = 50, Lost = 0
    (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 253ms, Maximum = 258ms, Average = 256ms

Without closing the window, run:

tracert dominioconproblemas.com

Wait until the trace finishes or shows that the maximum number of hops has been reached. Keep the command, the resolved address and the full output of both tests.

Select the text and use the window's Copy option. In Windows Terminal you can drag to select and right-click once to copy the selection.

macOS

Open Terminal and run:

ping -c 50 dominioconproblemas.com

Then run the traceroute:

traceroute dominioconproblemas.com

Keep the resolved address and the full output of both tests.

Linux

Open the terminal and run:

ping -c 50 dominioconproblemas.com

Then run the traceroute:

traceroute dominioconproblemas.com

Keep the resolved address and the full output of both tests.

If Linux says that traceroute is not installed, keep that message and note the distribution you are using. This guide does not cover installing packages with administrator privileges.

How to read the result

First check the IP address shown when the domain is resolved. If it is not the expected destination, check the A and AAAA records before blaming the route. A domain can resolve to several addresses or use a CDN, so compare the IP you see with its actual configuration.

No reply to ping does not prove that the server or the website is down. The destination or an intermediate device may filter or rate-limit ICMP while HTTP and HTTPS keep working.

In a tracert or traceroute, an asterisk means no reply was received to that probe within the timeout. On its own it does not prove that hop is dropping traffic:

• If later hops appear, the silent device kept forwarding at least those probes.
• Loss shown only at an intermediate hop may be due to ICMP reply rate-limiting.
• A break that starts at one hop and continues to the destination needs to be repeated and compared with other tests before attributing a cause.

Windows tracert uses ICMP probes. The traditional traceroute on macOS and Linux uses UDP by default, although it supports other methods. Firewalls may treat these probes differently. The route you see applies to that source, destination and moment; the return route may be different.

Send the test to support

Also include the URL and the error the browser shows, whether only IPv4 or IPv6 fails if you have checked, and whether the same website works from another connection. Copy the full text through a private channel: the trace may include addresses from your network and your ISP.

Do not run the tests from an external server instead of the affected connection. If the fault is intermittent, a sample collected during the problem is more useful than one taken afterwards, when everything is working.