What port does 'ping' work on?

ping doesn’t use a TCP or UDP port at all. Zero. None. Nada.

That’s because ping doesn’t even use TCP or UDP in the first place - it works on a completely different protocol layer: ICMP (Internet Control Message Protocol). You could sit there with Wireshark running and watch packets fly by all day, but you won’t find a dst port=80 or dst port=443 in a real ICMP ping. If you’re used to troubleshooting with tools like telnet or nc that always need a port number, this can feel super weird. But that’s the thing - ping just isn’t playing the same game.

But wait - what even is ICMP?

Think of ICMP as that behind-the-scenes guy in the network stack whose only job is to say things like:

• “Hey, are you alive?”
• “Oops, that host is unreachable.”
• “Packet size’s too big, try again.”

It’s not a “transport protocol” like TCP (which web servers use on port 80/443) or UDP (used for stuff like DNS on port 53). ICMP sits at the network layer (Layer 3 in the OSI model), alongside IP, instead of above it. That means it doesn’t care about ports - because ports live in Layer 4 (transport layer), which ICMP never touches.

In practice, ICMP is kind of like the postal service sending you a “return to sender” note instead of a full letter from a friend. It’s not there to carry your application’s content; it’s there to deliver status updates about the network itself. That’s why ping feels more like a “health check” than a conversation between two programs.

So what does ping actually send?

When you run something like:

ping 8.8.8.8

your computer is sending an ICMP Echo Request packet to that IP address. If the target’s alive (and not blocking you), it responds with an ICMP Echo Reply.

Here’s the key thing:

• ICMP packets don’t have TCP or UDP headers, so there’s no src port / dst port.
• Instead, they have their own ICMP header that contains things like:
  • Type - for echo request, it’s 8; for echo reply, it’s 0.
  • Code - usually 0 for echo, but other numbers for errors (like TTL expired).
  • Checksum - to make sure nothing got corrupted on the way.
  • Identifier and Sequence number - so your ping tool knows which reply belongs to which request.

If you capture this in Wireshark, you’ll literally see “ICMP Echo (ping) request” in the packet list, and under the IP header, there’s no sign of a port number. It’s pure ICMP payload. The identifier/sequence bits are the closest thing ping has to “session info,” and even those are just so your OS can match up requests and replies.

Message passing between two computers

Let’s visualize this. Two machines: Computer A wants to ping Computer B. Here’s how the ICMP message moves down and up through the layers:

Key Observation: Notice how the ICMP requests do not reach the transport layer (no TCP/UDP), so there’s nothing with a port=... field in it. The message just rides IP straight into ICMP land and back.

Why people think it uses a port

If you’ve ever used telnet or nc to check connectivity, you type something like:

nc -vz example.com 443

That works because TCP needs a destination port - it’s like calling someone’s phone and asking for a specific extension.

ping, on the other hand, is more like yelling across the hallway: “Hey Bob, you there?” It’s not asking for a particular service (port). It’s just checking if any service could respond, because the host itself is reachable.

The confusion probably comes from the fact that “port” has become the generic word for “connection check” in casual conversations. In reality, ping isn’t checking for any specific application’s availability - it’s just proving the IP layer works. That’s why ping can succeed even when all TCP/UDP ports are firewalled off.

Can you “ping” on a port?

Here’s where it gets confusing - some tools let you “ping a port”, but that’s not actually ICMP ping. For example:

nc -vz host 80

or

telnet host 22

Those are TCP connection attempts to a specific port. People call it “pinging a port”, but under the hood, it’s just a TCP SYN packet and not an ICMP echo.

The “ping a port” phrase stuck around because it’s a simple mental model: you want to check if something is alive, and ports are how TCP/UDP services are addressed. But from a technical perspective, it’s apples and oranges. ping is network-layer reachability; “pinging a port” is transport-layer service reachability.

Does ICMP have a “port” field? (Nope.)

Let’s break down the packet stack:

[ Ethernet frame ]
    ↓
[ IP header ]
    ↓
[ ICMP header ]
    ↓
[ Payload (timestamp, padding, etc.) ]

No TCP header. No UDP header. No ports. Just ICMP doing its thing.

If you look at the raw bytes, after the IP header ends, you get the ICMP type, code, checksum, and then the rest of the ICMP-specific data. There’s literally no 16-bit number that could be mistaken for a port in there. This is why packet filters like iptables or nftables don’t use --dport or --sport when matching ICMP - they match on --icmp-type instead.

Protocol Comparison Table

Here’s a comprehensive comparison between ICMP (ping) and port-based protocols:

Why this matters

If you’re debugging network connectivity and ping works but your app still can’t connect, it means:

• The host is reachable (ICMP got through).
• But the actual application port might be blocked (firewall, closed service, etc.).

On the flip side, some networks block ICMP entirely (common in corporate setups or security-hardened servers). In that case:

• ping will fail.
• But your web request might still work fine, because TCP/UDP are unaffected.

Knowing this difference can save you hours of head-scratching. I’ve seen folks waste an afternoon thinking a server was “down” because ping failed, only to find out ICMP was just filtered at the edge while the HTTP port was wide open.

Does Traceroute also use Ping?

While ping sends ICMP requests, whereas traceroute sends UDP packets with low TTLs and relies on ICMP Time Exceeded replies from routers.

Traceroute works by manipulating the TTL (Time To Live) value in outgoing packets and observing how routers respond. By default, traceroute sends UDP packets to high-numbered ports (typically starting at 33434 and incrementing for each probe), which are unlikely to match any listening service on the target host. As each packet’s TTL expires at a different router along the way, those routers reply with ICMP “Time Exceeded” messages, allowing traceroute to reveal each hop. When the packet finally reaches the destination, the host usually responds with an ICMP “Port Unreachable” message, confirming the end of the route.

Conclusion

Understanding that ping operates at the network layer using ICMP rather than transport layer protocols like TCP/UDP is crucial for effective network troubleshooting. When ping works but your application doesn’t connect, you know the network path is clear but there might be firewall rules or service issues at the specific port level.

Remember: ping tests if a host is reachable, while port-specific tools test if a particular service is available. Both have their place in your troubleshooting toolkit, but they’re solving different problems at different network layers.