Library Look up only what you need, then get back to the task.

Inspect Open Ports and Listening Services

Check which ports are listening, which process owns them, and whether that actually matches the service you expect.

Task guide

Inspect Open Ports and Listening Services

People often jump to firewall or network conclusions before confirming that the service is even listening. Port inspection narrows the problem quickly.

Networking and Remote Access 15 min both
Use this when

Use this when you need to verify that a network service is listening locally before blaming DNS, routes, or firewalls.

Goal

Answer three questions clearly:

  • Is the service listening?
  • On which port and interface?
  • Which process owns it?

Safe sequence

  1. Check local listening sockets.
  2. Filter to the expected port if known.
  3. Map the socket to the owning process or service.
  4. Confirm that the process is the intended application.
  5. Only then move outward to firewall, route, or remote tests.

Windows notes

  • Get-NetTCPConnection is useful for local inspection.
  • Pair port inspection with service status if the socket should belong to a Windows service.
  • Use process inspection to confirm the owner is not an unrelated application.

Linux notes

  • ss -lntp or netstat-style tools can reveal listening sockets and owning processes.
  • If permissions block process ownership details, inspect as appropriate and carefully.
  • Pair the socket with systemd or process inspection if the service is managed.

Move on when

  • You know whether the port is actually listening.
  • You know what process owns it.
  • You know whether the next step is service repair, firewall inspection, or remote connectivity testing.
Before you start
  • Know the service name or at least the expected port.
  • Decide whether you are checking local listen state or remote reachability.
  • Be ready to map a listening socket back to a process or service.
Verify with
  • Confirm the expected port is listening on the expected interface.
  • Confirm the owning process or service matches the software you intended.
  • If the port is listening, move to firewall, routing, or remote checks next.
Avoid these mistakes
  • Do not assume ping proves the service is healthy.
  • Do not stop random processes just because they have a socket open.
  • Do not confuse local listen state with remote accessibility.
Move on when
  • You can verify listen state on Windows and Linux.
  • You can map a socket to the software that owns it.
  • You know when to move from port inspection to service, firewall, or remote-path checks.
Reflect before you leave
  • How did checking listen state narrow the problem before firewall or DNS work?
  • What is the difference between a local listening socket and remote reachability?

Review this task again in about 1, 7, 21 days.