If you have ever tried to figure out why an application, database, or API is unreachable, you have likely run into a frustrating network diagnostic wall. A standard ping succeeds, and a default path trace completes without issues—yet your application connections continue to time out. This disconnect happens because standard diagnostic tools are port-blind. To diagnose real-world network path issues, you need to execute a traceroute command port test that targets the exact network port your application uses.

In this comprehensive guide, we will explore how to run a traceroute command with port specification on every major operating system, demystify why default traces often fail, and show you how to identify firewalls blocking your traffic.

Demystifying Traceroute: Default Ports and Protocols (UDP vs. ICMP)

To understand why you need to target a specific port, it is essential to first grasp how default routing diagnostics work. Under the hood, traceroute does not simply send a packet and wait for it to reach the destination. Instead, it utilizes a clever manipulation of the IP protocol’s Time-to-Live (TTL) field to force intermediate routers along the network path to identify themselves.

When you initiate a trace, the tool sends out packets with a TTL of 1. The first router the packet encounters decrements the TTL by 1. Since the TTL is now 0, the router discards the packet and sends back an ICMP "Time Exceeded" message. Traceroute records this router's IP and measures the round-trip time (RTT). It then repeats this process with a TTL of 2, 3, 4, and so on, until a packet finally reaches the target destination.

However, the protocol and port utilized during this diagnostic process differ significantly depending on your operating system:

• Windows (tracert): By default, the native Windows tracert utility uses ICMP Echo Requests (similar to a standard ping). ICMP is a Layer 3 protocol, meaning it operates entirely below the transport layer. Consequently, ICMP has no concept of ports (TCP or UDP). If you try to run a native tracert with a port, you will quickly find that the command line does not support any such option.
• Linux and macOS (traceroute): Unix-like systems take a different approach. By default, they send UDP (User Datagram Protocol) packets. Rather than targeting a standard service port, they target a range of high-numbered, unlikely-to-be-used destination ports—usually starting at 33434 and incrementing by one for each subsequent probe (up to 33534). When the packet reaches the final destination, the host realizes no service is listening on that high UDP port and returns an ICMP "Port Unreachable" packet, signaling that the trace is complete.

The Problem with Default Configurations

While these default behaviors work fine in an open network, they are highly prone to failure in modern enterprise environments. Security policies are restrictive. Today, firewalls, cloud security groups, and Internet Service Providers (ISPs) actively filter or drop unsolicited ICMP and high-port UDP traffic.

If a firewall along the path drops UDP port 33434 or blocks ICMP Echo Requests, you will see rows of frustrating asterisks (* * *) representing timed-out hops. However, this does not mean the target server is down. The server might be perfectly healthy and actively serving web traffic on TCP port 443 (HTTPS). To bypass these arbitrary blocks and get an accurate network path diagnostic, you must force your system to run a traceroute using the exact TCP port of your application.

The Core Problem: Why You Must Trace Specific Ports

In a production network environment, troubleshooting connectivity is rarely about whether a server is physically online. It is almost always about whether a specific port is open, routed correctly, and allowed through the security chain.

Imagine you are a systems administrator, and your users are complaining that they cannot access a secure API hosted on port 8443. You try to ping the server, and it works. You try a standard Windows tracert, and it completes successfully in 12 hops. Yet, the API connection itself continues to time out.

What is happening here? A firewall or load balancer along the network path is configured with an Access Control List (ACL) that permits general ICMP traffic (allowing ping and tracert to work) but explicitly blocks or misroutes traffic destined for TCP port 8443.

To diagnose this issue, a standard end-to-end port check (like telnet or Netcat) will only tell you that the port is closed or blocked; it won't tell you where the packet is being dropped. By running a traceroute command with port filtering—specifically executing a TCP-based traceroute targeting port 8443—you can trace the exact path those API packets take. The trace will proceed normally through your local network, cross into your ISP, and then stop precisely at the router or firewall that is discarding your port-specific packets. This allows you to pinpoint the exact device responsible for the block.

How to Run Traceroute Command with Port on Linux and macOS

If you are running a Linux distribution (such as Ubuntu, Debian, CentOS, or Red Hat) or macOS, the native traceroute utility includes built-in support for TCP traces targeting specific ports.

Method 1: Using the Native traceroute with TCP (-T)

To run a traceroute over a specific TCP port on Linux, you must use the -T flag to switch the protocol from UDP to TCP, and the -p flag to specify your destination port.

The Command Syntax: sudo traceroute -T -p <port_number> <destination>

Note: You must prepend this command with sudo (or run it as root). This is because crafting custom TCP packets with specific TTL values requires raw socket manipulation, which is restricted to administrative accounts for security reasons.

Example: Tracing Path to a Web Server on Port 443 (HTTPS): sudo traceroute -T -p 443 google.com

Simulated Command Output:

traceroute to google.com (142.250.190.46), 30 hops max, 60 byte packets
 1  gateway (192.168.1.1)  0.421 ms  0.395 ms  0.380 ms
 2  10.0.0.1 (10.0.0.1)  1.230 ms  1.198 ms  1.150 ms
 3  isp-edge.net (203.0.113.5)  4.521 ms  4.490 ms  4.412 ms
 4  backbone-router.net (198.51.100.12)  12.310 ms  12.280 ms  12.250 ms
 5  142.250.190.46 (142.250.190.46)  14.102 ms  14.050 ms  13.980 ms

In this example, the trace completes successfully because port 443 is wide open, and all intermediate routers allow TCP traffic to pass through.

Method 2: Using tcptraceroute

On some legacy Linux systems, or macOS environments where the default traceroute command has limited features, tcptraceroute is the preferred tool. It is a specialized utility written specifically to bypass firewalls by sending TCP SYN packets.

Step 1: Install tcptraceroute

If it is not already installed on your system, you can easily install it using your package manager:

• Ubuntu / Debian: sudo apt-get update && sudo apt-get install -y tcptraceroute
• CentOS / RHEL: sudo yum install epel-release && sudo yum install -y tcptraceroute
• macOS (via Homebrew): brew install tcptraceroute

Step 2: Execute the Trace

Unlike the standard traceroute command, tcptraceroute takes the port number as a separate argument at the end of the command.

The Command Syntax: sudo tcptraceroute <destination> <port_number>

Example: Tracing to an SSH Server on Port 22: sudo tcptraceroute example.com 22

Using tcptraceroute ensures that even if the remote host blocks ICMP and UDP, you will get a perfect hop-by-hop map of the path because firewalls must allow your TCP SYN packets through to let legitimate SSH traffic function.

How to Run Traceroute Command with Port on Windows

Troubleshooting a specific port on Windows is slightly more complicated. The native Windows Command Prompt tool, tracert, is extremely basic and does not support port specification.

The PowerShell Myth: Test-NetConnection

Many Windows administrators attempt to use PowerShell’s modern networking cmdlet as a workaround: Test-NetConnection -ComputerName example.com -TraceRoute -Port 443

Warning: This does not do what you think it does!

While this command runs successfully, PowerShell actually executes two completely independent actions. First, it performs a direct TCP handshake connection to the host on port 443 and reports if the port is open (returning TcpTestSucceeded : True). Second, it runs a standard ICMP-based traceroute to find the path. The actual path trace does not use port 443. If an intermediate firewall is blocking port 443 but allowing ICMP, Test-NetConnection will show a successful port test but a failing traceroute path, leading to highly confusing diagnostic data.

To run a true port-specific traceroute on Windows, you must rely on one of the three robust workarounds below.

Workaround 1: Using tracetcp (The Ultimate Command-Line Workaround)

tracetcp is a fantastic, free command-line utility for Windows that operates similarly to Linux's tcptraceroute. It uses TCP SYN packets to bypass firewalls and trace paths over any TCP port.

Step 1: Install Npcap (Crucial Prerequisite)

Because Windows does not support raw socket creation natively, tracetcp requires a packet capture library to inject packets.

1. Download the latest version of Npcap from the official website.
2. Run the installer.
3. Important: During installation, make sure to check the box that says "Install Npcap in WinPcap API-compatible Mode". If you skip this step, legacy utilities like tracetcp will not be able to interact with the network driver.

Step 2: Download and Install tracetcp

1. Download the tracetcp zip package from its GitHub repository.
2. Extract the archive.
3. Move the tracetcp.exe file into your C:\Windows\System32 folder (which places it in your system's default PATH, allowing you to run it from anywhere), or keep it in a dedicated folder and add that folder to your System Environment Variables.

Step 3: Run the Command

Open Command Prompt or PowerShell as Administrator and run your trace.

The Command Syntax: tracetcp <destination>:<port_number> or tracetcp <destination> -p <port_number>

Example: Tracing to an Email Server on Port 25 (SMTP): tracetcp mail.example.com:25

This will generate a clean, hop-by-hop output using TCP SYN packets on port 25, showing you exactly where your mail server packets are being discarded.

Workaround 2: Using Nmap (Universal Diagnostic Tool)

If you do not want to go through the manual setup of tracetcp, you can use Nmap (Network Mapper). Nmap is the industry-standard security tool and includes an exceptionally powerful traceroute engine.

Step 1: Download Nmap

Download and install Nmap for Windows from the official website. The installer automatically handles the Npcap installation for you.

Step 2: Run the Nmap Traceroute

Open Command Prompt as Administrator and execute Nmap with the traceroute and port parameters.

The Command Syntax: nmap -Pn --traceroute -p <port_number> <destination>

• -Pn: Instructs Nmap to skip host discovery (pinging). This is critical because if the target blocks pings, Nmap will assume the server is offline and refuse to run the trace.
• --traceroute: Triggers the path tracing engine.
• -p <port_number>: Restricts the scan and trace strictly to your desired TCP port.

Example: Tracing a Database Server on Port 1433 (MSSQL): nmap -Pn --traceroute -p 1433 database.example.com

Simulated Nmap Output:

Nmap scan report for database.example.com (198.51.100.50)
PORT     STATE SERVICE
1433/tcp open  ms-sql-s

TRACEROUTE (using port 1433/tcp)
HOP RTT      ADDRESS
1   0.51 ms  192.168.1.1
2   1.20 ms  10.0.0.1
3   4.11 ms  isp-gateway.net (203.0.113.1)
4   8.54 ms  backbone-router.net (198.51.100.1)
5   ... (No response)
6   14.30 ms database.example.com (198.51.100.50)

Nmap's output is incredibly clean, showing the open state of the port and the exact path the database packets traveled.

Workaround 3: Utilizing Windows Subsystem for Linux (WSL)

If you are running Windows 10 or 11 with Windows Subsystem for Linux (WSL) enabled, you can bypass native Windows limitations entirely. Simply open your WSL bash terminal (Ubuntu, Debian, etc.) and run the standard Linux commands:

sudo apt-get update && sudo apt-get install -y traceroute sudo traceroute -T -p 443 example.com

This gives you a native Linux networking environment right inside Windows, providing the best of both worlds.

Analyzing the Output: How to Spot Port-Blocking Firewalls

Now that you know how to run a traceroute command with port options across all operating systems, the next step is learning how to analyze the results to identify where network blocks are occurring.

When interpreting a port-specific trace, you will generally encounter three scenarios:

Scenario 1: A Successful, Complete Trace

If your trace goes all the way from hop 1 to the destination server's IP address, and the final hop shows a valid latency time (e.g., 12.5 ms), the network path is fully functional.

• What this means: If you still cannot connect to the application, the issue is not network routing or firewalls. The problem is likely at the application level—such as the service daemon not running on the target server, or the service listening on the wrong network interface (e.g., binding to 127.0.0.1 instead of 0.0.0.0).

Scenario 2: Destination-Level Blocking

Your trace proceeds smoothly through the local network, traverses the public internet backbone, reaches the very last hop (often the hosting provider's edge gateway), and then suddenly times out at the final destination:

9   18.42 ms  cloud-provider-backbone.net (192.0.2.55)
10  * * *
11  * * *

• What this means: The packet reached the hosting infrastructure, but the destination server's local firewall (like Windows Firewall, iptables, or cloud security groups) explicitly dropped the connection request on that specific port. You need to verify the server's local firewall rules and ensure the application is configured to accept incoming traffic on that port.

Scenario 3: Mid-Path Transit Blocking

The trace begins normally but completely stops at an intermediate hop far before reaching the destination:

4   4.22 ms  local-isp-gateway.net (203.0.113.10)
5   * * *
6   * * *
7   * * *

• What this means: An intermediate network router or ISP firewall is actively filtering or discarding traffic on that specific TCP port. This is common when testing port 25 (SMTP), as many residential and business ISPs block port 25 entirely to prevent outbound spam. If you encounter this, you will need to contact the owner of the blocking router (identifiable by the IP address on the hop immediately preceding the timeouts) or consider routing your application traffic over an alternative, unblocked port (such as port 587 for secure mail).

Advanced Tools & Best Practices for Network Path Diagnostics

While port-specific traceroute commands are invaluable, combining them with other diagnostic utilities will elevate your troubleshooting capabilities.

1. Using MTR (My Traceroute) for Real-Time Analysis

mtr combines the functionality of ping and traceroute into a continuously updating, real-time diagnostic screen. It allows you to observe trends in packet loss and latency spikes over time.

You can run mtr in TCP mode targeting a specific port on Linux: sudo mtr -T -P <port_number> <destination>

This provides a live dashboard where you can watch how network congestion affects your specific application port over several minutes.

2. Follow Best Practices to Avoid False Diagnostics

• Don't Panic Over a Single Non-Responding Hop: If you see a row of numbers, followed by a single hop of asterisks (* * *), followed by more successful hops, the network path is perfectly healthy. Some core internet routers are configured to deprioritize or completely ignore ICMP/UDP/TCP packets with a low TTL to protect their CPU resources. If subsequent hops respond, no packets were dropped.
• Run Traces from Multiple Source Networks: If an application port seems blocked, run a trace from your office network, then run another from a cellular hotspot or home network. This helps isolate whether the block is local to your corporate firewall or global.
• Test Both Protocols (TCP vs. UDP): Some services, such as DNS (port 53), support both TCP and UDP. Always run a trace for both protocols to ensure comprehensive troubleshooting.

Frequently Asked Questions

Can I specify a port when using the native Windows tracert command?

No. The native Windows tracert utility only supports the ICMP protocol, which does not have ports. To run a traceroute on a specific port in Windows, you must use alternative tools like tracetcp (which requires Npcap) or nmap.

What default port does the traceroute command use?

By default, the Windows tracert utility uses ICMP Echo Requests and does not use any port. On Linux and macOS, the native traceroute utility uses UDP, targeting high-numbered destination ports ranging from 33434 to 33534.

Does PowerShell's Test-NetConnection run a traceroute on a specific port?

No. Although the Test-NetConnection -TraceRoute -Port <port> command is valid, PowerShell runs these tests as two completely separate operations. The TCP port check is a direct connection test, while the route trace is executed using standard ICMP packets, completely ignoring the specified port during the trace.

Why do I need admin/root privileges to run a TCP traceroute?

Operating systems restrict the creation of "raw sockets" to administrative or root users. Tools like traceroute -T and tcptraceroute must craft custom TCP packets with artificially low TTL values to conduct the trace, a process that requires low-level network driver access only granted to administrators.

What is the difference between traceroute and tcptraceroute?

Traditional traceroute uses UDP or ICMP probes. tcptraceroute is a specialized tool that sends TCP SYN packets to a specific port. Because it mimics legitimate application traffic, tcptraceroute is much better at bypassing firewalls and mapping realistic routing paths for web services.

Conclusion

Diagnosing network issues becomes significantly easier once you move past port-blind tools like ping and standard tracert. By mastering the traceroute command port options, you can bypass restrictive firewalls, trace paths using actual TCP SYN packets, and pinpoint network drop-offs with absolute precision. Whether you are running a native traceroute -T on Linux or configuring tracetcp and nmap on Windows, executing a traceroute command with port specifications is a mandatory skill for any modern system administrator or network engineer.