How can I check if a port is listening on a Linux server?
-
2It's not quite clear what you're asking. What do you mean by "open"? Do you mean some server is listening on that port? Or do you mean it's allowed by the system firewall? Or what? – David Schwartz Sep 07 '11 at 17:47
-
1I think a port is being blocked on my server and want to unblock/open it again. – James Anderson Sep 07 '11 at 17:49
-
16`netstat -an | grep PORTNUMBER | grep -i listen` If the output is empty, the port is not in use. – automatix Sep 28 '13 at 13:12
-
2`nc -w5 -z -v
`, you should get something like `Connection to 127.0.0.1 9000 port [tcp/*] succeeded!`, otherwise port is closed. -
A topic that contains an answer also for kernel level services and programs https://serverfault.com/questions/1078483/how-to-find-out-what-service-is-listening-on-a-specific-port-of-a-ubuntu-server/1079542#1079542 – CrazyTux Oct 05 '21 at 18:30
7 Answers
You can check if a process listens on a TCP or UDP port with netstat -tuplen
.
To check whether some ports are accessible from the outside (this is probably what you want) you can use a port scanner like Nmap from another system. Running Nmap on the same host you want to check is quite useless for your purpose.
- 20,747
- 3
- 46
- 50
-
59GNU netstat knows the parameters `-t`, `-u`, `-p`, `-l`, `-e`, and `-n`. Thanks to the options parser it can be expressed as `-tuplen`. http://linux.die.net/man/8/netstat – joschi Apr 26 '13 at 09:53
-
4Also, the `telnet` command usually does only supports TCP, so you're out of luck if the service you want to check runs on another protocol. – joschi Apr 26 '13 at 09:55
-
1
-
3
-
1Use it with sudo: `sudo netstat -tuplen`. This will give you processes owned by not just you, but also by others, and, it will print additional details (like PID/Program Name) if they aren't already displayed as a non-root user. – John Red Dec 19 '17 at 14:59
-
2
-
netstat -an | grep [PORTNUMBER] | grep -i listen if no output, its open. – Anand Varkey Philips Aug 10 '18 at 13:59
-
1@AnandVarkeyPhilips That just means that there's no process listening on the given port. – joschi Aug 12 '18 at 16:40
-
2-t: TCP; -u: UDP; -p: show programs; -l: show only listening sockets; -e: extend (shows details); -n: numeric (shows IPs instead of hostnames) – SigmaX Jul 08 '19 at 20:58
-
3According to article: https://computingforgeeks.com/netstat-vs-ss-usage-guide-linux/ `netstat` is deprecated, and `ss` is it's replacement, so you can do `ss -an`, `ss -tuplen` or for tcp listening sockets `ss -ntlp`. – Alek_A Feb 07 '20 at 10:17
-
Quickest way to test if a TCP port is open (including any hardware firewalls you may have), is to type, from a remote computer (e.g. your desktop):
telnet myserver.com 80
Which will try to open a connection to port 80 on that server. If you get a time out or deny, the port is not open :)
- 1,746
- 2
- 11
- 11
-
1
-
7
-
1Says: telnet: connect to address 82.165.148.224: Connection refused – James Anderson Sep 07 '11 at 17:42
-
8Written above: `if you get a time out or deny, the port is not open` – Industrial Sep 07 '11 at 18:09
-
2What if you don't have perms to install telnet? Is there another standard tool? – KC Baltz Jan 14 '14 at 23:40
-
1But how do you know whether the connection was blocked at the server end or at your own originating end (perhaps you're behind a firewall when you test)? – Magnus Nov 26 '14 at 19:48
-
-
9I tried “telnet myhost 22” and get a timeout. But I can ssh into that machine. ?! – Torsten Bronger Sep 06 '18 at 10:59
-
This is non standard. Telnet isn't installed on Linux distros by default--nor should it be. Get that dinosaur out of here. – Russell Trahan Aug 11 '22 at 22:28
-
OK, in summary, you have a server that you can log into. You want to see if something is listening on some port. As root, run:
netstat -nlp
this will show a listing of processes listening on TCP and UDP ports. You can scan (or grep) it for the process you're interest in,and/or the port numbers you expect to see.
If the process you expect isn't there, you should start up that process and check netstat again. If the process is there, but it's listening on a interface and port that you did not expect, then there's a configuration issue (e.g., it could be listening, but only on the loopback interface, so you would see 127.0.0.1:3306 and no other lines for port 3306, in the case of the default configuration for MySQL).
If the process is up, and it's listening on the port you expect, you can try running a "telnet" to that port from your Macbook in your office/home, e.g.,
telnet xxxxxxxxxxxx.co.uk 443
That will test if (assuming standard ports) that there's a web server configured for SSL. Note that this test using telnet is only going to work if the process is listening on a TCP port. If it's a UDP port, you may as well try with whatever client you were going to use to connect to it. (I see that you used port 224. This is masqdialer, and I have no idea what that is).
If the service is there, but you can't get to it externally, then there's a firewall blocking you. In that case, run:
iptables -L -n
This will show all the firewall rules as defined on your system. You can post that, but, generally, if you're not allowing everything on the INPUT chain, you probably will need to explicitly allow traffic on the port in question:
iptables -I INPUT -p tcp --dport 224 -j ACCEPT
or something along those lines. Do not run your firewall commands blindly based on what some stranger has told you on the Internet. Consider what you're doing.
If your firewall on the box is allowing the traffic you want, then your hosting company may be running a firewall (e.g., they're only allowing SSH (22/tcp), HTTP (80/tcp) and HTTPS (443/tcp) and denying all other incoming traffic). In this case, you will need to open a helpdesk ticket with them to resolve this issue, though I suppose there might be something in your cPanel that may allow it.
-
-
1"iptables -D" followed by whatever else you had after the "-I" in the original command. Basically, look up the documentation. – cjc Sep 10 '13 at 11:45
-
1I'd highly recommend using `ufw` (just `apt install ufw` then see `man ufw`) it's a more user-friendly frontend for `iptables`. – Nagev Jun 10 '20 at 10:40
I use the combo of netstat
and lsof
:
netstat -an | grep <portnumber>
lsof -i:<portnumber>
To see if the port is being used, and what is using it.
- 17,829
- 23
- 82
- 134
If you are connected to the system and can run a command as root then you can check the output of iptables
iptables -L -vn
this will list the firewall rules and which ports are open target ACCEPT
and any explicitly closed ports target REJECT
.
- 53,385
- 32
- 133
- 208
- 114,104
- 20
- 206
- 289
-
1And if you have firewalld, it's simpler `firewall-cmd --query-port=port/protocol`, e.g. `firewall-cmd --query-port=80/tcp`. – Agostino Jul 20 '18 at 16:00
lsof -i :ssh
will list all processes with the ssh port open, both listening and active connections.
- 3,471
- 18
- 19
-
-
1@ElijahLynn Actually `sudo` is required for any connections opened by other users (and likely `LISTEN` ports which are opened by services such as `ssh` or `http`). – Alexis Wilke Mar 07 '20 at 17:53
If you need to script such a test, the solution by Serhii Popov (see comment to question) is probably the best since nc
is capable of searching the TCP stack for an open port³ instead of attempting an actual connection.
The simplest form is:
nc -z <ip> <port>
The command returns true if it find the specified <ip>:<port>
combo as being opened (i.e. one of your services is listening).
So now you can write a script to wait until the port is open:
while ! nc -z <ip> <port>
do
sleep 1
done
Note 1: I tried the -w
command line option and that did not seem to do anything. Either way the command returns immediately. I think that the -w
is not useful with -z
.
Note 2: to help debug, try with the -v
command line option.
Note 3: nc -z ...
actually creates a socket()
and then attempts to bind()
it and connect()
. If that works, it deems the port open.
- 2,057
- 1
- 18
- 33
-
2`-w` is very useful if the port is not open and packages are dropped, otherwise `nc` will wait forever. – Carl Hörberg Jul 15 '20 at 20:02