Skip to content

how can i find open ports in my server or computer

How can I quickly find listening/open ports on my computer ?

You can use the NETSTAT command to quickly see all the used and listening ports on your computer. Note it is not a complete substitute for a port scanning tool. If you’d like to have your computer remotely scanned for open ports use our Security Scan instead.

To see a list of listening ports, open Command Prompt and type:

C:\> netstat -an |find /i “listening”

You can change “listening” to “established” to see what ports your computer actually communicates with.

It is also useful to use the -o switch with the NETSTAT command to also get a list of all the owning process ID associated with each connection. You can then use those process ids (PIDs) to find out the name of the processes associated with open/listening ports in the Windows Task Manager

C:\> netstat -ao |find /i “listening”

To see all open, closing, established and listening ports, simply use:

C:\> netstat -a (or netstat -ao in XP/Win2k3)

You can also make the netstat command refresh periodically by adding a number of seconds at the end, for example, to make it refresh every 5 seconds, use something like:

C:\> netstat -an 5

The netstat command has a number of other useful command line parameters, you can see short description of all of them using: netstat /?
Also, you might want to perform an outside port scan to see what ports are accepting connections according to an external machine. See: SG Security Scan
You can see process identifiers using the following command at the command prompt: tasklist and tasklist /svc


netstat -an | find “8080”

from telnet


telnet 8080



The telnet command connects to the host you specify as the first argument on the port you specify as the second argument (or 23, if you only specify a single argument).

When you tried to execute telnet port, it tried to connect to the server port on port 23. Since there is no server with the address port (unless you specified it in your pc’s hosts file), telnetcouldn’t connect to it.

I’m guessing the second command failed, because doesn’t accept connections on port 8080 (the second argument of the command).

I don’t see any instructions in the link you provided.

EDIT: If you’re trying to connect to localhost, use telnet localhost (to connect to port 23) or telnet localhost <port> (replace <port> with the port you are trying to connect to).



What if I get no response?

On the other hand if the telnet session does not succeed and fails to connect you may get output similar to the below.

C:\>telnet 1111

Connecting To…Could not open connection to the host, on port 1111: Connect failed

In this example I’m trying to connect to on a random port 1111, however it fails, what could be the problem?

The remote server might not be listening on that port: The server you’re trying to connect to might not have any services listening on the port you’re trying to connect on, in this instance it will not respond and the connection will fail as it’s not expecting connections on the port. If you have access to the remote server you could run a command such as ‘netstat’ to get an idea of what ports the server is listening on and accepting connections for.

The remote server may not be responding on that port: The server you’re trying to connect to might be listening on the port, however it may be running a firewall which is configured to block the connection resulting in a failure of the telnet client. If you have access to the remote server confirm with ‘netstat’ that a service is listening on the port specified, then investigate any firewalls in use such as Windows firewall or iptables. The telnet client is a good tool for testing server security quickly if you want to see if a server is responding on a port that it shouldn’t be.

The connection may be blocked in your own network, or otherwise somewhere else along the route: Perhaps you are running a firewall in your own network which is blocking various outbound ports, the connection attempt may not even leave your local network depending on your configuration. You could simply try disabling your firewall and performing the test again to rule this out as being part of the problem.



VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Post a Comment

You must be logged in to post a comment.