What does ping mean? Ping is ineffective but doesn't affect internet access. I tested four servers with 32 bytes to figure it out

troubleshooting network issues, nine out of ten people first try pinging. But what exactly is this command doing? Why do some servers never ping while the network remains perfectly healthy? A few days ago, I got itchy and used Python to create a 32-byte packet and sent it out, ping 223.5.5.5, 119.29.29, our own website, and 114.114.114 one by one before I finally figured it out.

ping is shouting for the mountain, not for a phone call

ping This term comes from submarine sonar: make a "ping" sound, and listen to the echo to calculate distance. The ping on the internet is exactly the same—your computer sends a small packet, the other party copies it back as is, and the time it takes for you to go back and forth is the network speed between the two of you. No connection was needed between the two; once they posted, it was done, and neither owed the other.

it follows the ICMP protocol and does not belong to either TCP or UDP. So strictly speaking, ping doesn't take up ports or handshakes—it's the most primitive code for 'Are you alive?' or 'I'm alive.' Windows defaults to 32 bytes per send, Linux 56 bytes by default, in groups of four, which is why the replies you see always say "Byte = 32."

the code I manually wrote, to put it bluntly, it's just three steps: assemble a packet with a "echo request" and send it out, squat at the door waiting for an "echo response," and clock the meter. The result sent to 223.5.5.5 (Alibaba public DNS) looks like this:

reply from 223.5.5.5: byte=32 time=13ms TTL=113
reply from 223.5.5.5: byte=32 time=12ms TTL=113

thirteen milliseconds, four shots and four retracts. In one line of replies, there were actually three or four pieces of information, and the rest were unfolded one by one.

the string of numbers in the replies is all talking

"time" is the easiest to understand: it takes time to go back and forth. Within 1ms is a household matter; a few milliseconds to tens of milliseconds are within the province; over a hundred milliseconds, it's basically outside the province or overseas. I've mapped the specific tiers in this article game latency . My home ping router gateway is always 1ms, and ping 223.5.5.5 is about 10ms. These two numbers are healthy, and the section from home to the carrier is connected.

the real information is the TTL. It means "lifespan"—for each packet passing through a router, the number decreases by 1; when it drops to 0, the router throws away the packet, preventing a packet from wandering online forever. So the TTL you receive is equal to the "initial value at departure" minus "how many routers you passed along the way."

initial value depends on the other party's operating system: Windows factory 128, Linux and macOS factory 64, and many network devices have 255. In my round, I managed to get all three types: 223.5.5.5 with TTL=113, 113 is 128 minus 15, which means the other side is a Windows machine, and the middle jump was 15 jumps; 119.29.29.29 (Tencent DNS) returns to 51, 64 minus 51 is 13 jump; Our website replied 46, left 18 jumps. TTL should be stable in the same ping. If it fluctuates between large and low, it means the packet takes a different route each time—routers choose routes according to routing table, and if the road is blocked, it will change lanes. This is not an illusion.

By the way, when you see TTL=57 or 63, which are close to 64, don't guess how many jumps—they're probably in the same city; TTL drops to around 30, and the road is quite far. This number can also be used in reverse: when switching server data centers, I got a TTL from 49 to 117 by ping, confirming the traffic has been switched to the new data center—the jump count is mostly reduced, so the location has definitely changed.

"time" and bag size can be combined. Normally, those 32 bytes are just small stones; ping big packages is like throwing bricks—stretch the bag to 1472 bytes before sending it. Which section of the road is loose or which crystal connector is loose, the big package will be exposed as soon as it passes. Why is it specifically 1472? Because the 1500 cabin is equipped with 20-byte IP connectors plus 8-byte ICMP connectors, the remaining load is exactly this large. I calculated this number in MTU . Small packets get through and big packages are lost; ninety percent of the time it's a problem with the cable, not the internet.

ping worked, but the webpage wouldn't open

this is the most common confusing record. ICMP is just a live probing event, essentially knocking on the door and asking, "Is anyone there?" For a webpage to work, it's a complete pipeline: first translate the domain name into an IP, then establish a TCP connection with the other party, and finally transfer data. If any link fails, the webpage can't open, and none of these links are checked for ping.

most typical way to divide is to separate IP and domain ping. Ping 223.5.5.5 is working, ping www.baidu.com is not working. The router is fine, but the DNS parsing this step is broken. Changing DNS fixes it. I've written in this article about how to check this issue. Conversely, if ping domain controllers or web pages still spins, the problem lies in the TCP layer or the other party's website itself, which has little to do with the router.

narrow down the room to the point: Ping Gateway only means the small segment of your router is active; no optical modem, broadband, or outstanding bills are checked. That time my wife said there was no internet, I pinged the gateway for 1ms and it worked fine, then ping the external network all timed out—I ran it out, and it was the optical modem's cable loose. I elaborated on the three-stage ping-by-packet positioning method in the WiFi packet loss article, using the gateway as the dividing line, testing it and getting it accurately.

ping is blocked, but the internet is fine

this was the most exciting discovery I've found in this round of testing. 114.114.114.114, an old public DNS, I sent four times and timed out four times, and didn't get a single packet back. According to the logic of 'If ping doesn't work, it's disconnected,' this server should have shut down long ago? But I immediately sent a domain query to port 53, and in 39 milliseconds received a 61-byte response, which was fast and efficient.

reason is simple: its firewall has thrown ICMP away. Many servers and routers default to discarding external pings, because flood ping is the cheapest attack method—a few machines sending massive ICMP can block small pipes, and if they don't respond, it's actually self-defense. The router's backend switches for "DoS attack prevention" and "WAN port ping ban" are managed by this type. I tested the impact of these switches in the firewall .

Therefore, the correct reading of 'ping not working' is 'the other party ignored you,' not 'the road is cut off.' It could be that the other party doesn't allow ping, or a router in the middle lost the ICMP, or it really did disconnect—these three situations can't be distinguished by ping alone, so you need to move on to the next one. Not just the server, but some home optical modems don't even return to the external network direction for pinging. The test address the technician asked you to ping during fault reporting is not the same as that.

tracert is using TTL as a probe, jumping and asking for

Since packets that pass through a router with TTL minus 1 or reduced to 0 are thrown away, we can use the opposite: intentionally sending a packet with TTL=1, the first router will reset to zero after subtraction, so it can only throw it, but before throwing, it will politely reply with a "timeout" message containing its own IP. TTL=2 lets you catch a second fish, TTL=3 lets you catch a third, and by adding them one by one, the way home lights up with every hop. The tracert command does exactly that; the principle is exactly the same as what I made by hand.

I ran a section on a company computer with 172 segments on the internal network. The first few jumps looked like this: the first jump was 172.18.0.1 half a millisecond, the company gateway; Second jump 192.168.5.1, exchange between the upper floors in the building; The third pop-up shows an address starting with 100.64—this is the operator's compound's address, and this applies to CGNAT broadband. I wrote in my article on Public Network IP how to recognize it; The fourth jump is 118.121.3.181, 5 milliseconds, and it's already on the metropolitan area network.

the fifth and sixth jumps are two asterisks, overtime. Don't worry, this is very common—the intermediate router is busy forwarding and too busy to handle probes, or is simply configured not to return such packets, but it doesn't affect legitimate traffic flow. An asterisk only indicates 'no response on this jump'; whether the road is open depends on whether the jump count lights up again later or if the finish line responds. In my round, the jump count kept coming on, the finish line was 223.5.5.5, normal response, no issues on the road.

four symptoms identified and followed in five steps

put all of these together to form a quick reference table:

The

order is simple: first ping 127.0.0.1 to confirm you're fine, then ping the gateway to confirm the house is fine, then ping 223.5.5.5 to confirm you can leave, and finally ping the domain name to confirm the translation is fine. Wherever the four steps break, search for the corresponding section. If you're still confused, just trace it and see which hopping the connection drops off—the first three hops are a matter for your home and the carrier, but if you disconnect at the tenth hopping open, you can basically disconnect from your own router.

ping The command is small, but it hasn't changed for over forty years, relying on simplicity. Next time you see a "request timeout," think of the 114 server—they don't reply, and life is fine.