Port 514 syslog – Free, Online, Private

What listens on 514

UDP 514 is syslog. The IANA name on the UDP row is syslog, cited to RFC 5426. The messages are one datagram each, with a priority and a text body, and they are not acknowledged. Losing them is normal under load. TCP 514 is a different registration, the shell service, historically rsh. Opening TCP 514 because you meant to receive logs opens a remote-shell port instead, or it opens nothing useful and you conclude syslog is down. TLS syslog, when you deploy it, is usually 6514, not this port. IANA's syslog row that operators mean is UDP.

The IANA service name is syslog: syslog over UDP. The practical transport is UDP. The checks below use UDP. A UDP socket has no listen state in the TCP sense, so lsof will not show -sTCP:LISTEN and nc cannot complete a handshake. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 514

Service notes for port 514: the IANA name is syslog (syslog over UDP), and the program people mean is syslog. UDP 514 is the IANA syslog port. TCP 514 is a different service, shell. Do not treat a TCP probe of 514 as a syslog test. Syslog over UDP has no authentication. Anyone who can send a packet can write a line into your log, and anyone on the path can read it. Do not expose UDP 514 to the internet. Send logs over a private network, or use a TLS transport and a real acknowledgement if the logs matter. A forged line that says an admin logged in is a good way to hide in noise. If this host is not a log collector, it should not listen. Clients send to a collector. They do not need a public listener. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 514, you are on the wrong page.

A collector that listens on TCP 514 and a fleet that sends UDP 514 will collect nothing and both sides will look configured. Match the transport. Another trap is a firewall that allows the UDP in and the disk that fills, so the daemon dies and the port closes. The port check fails after the disk check would have. Another is rsh still installed and bound to TCP 514 on an old image. That is the shell service. Remove it. Another is expecting nc -vzu to show a syslog conversation. It will not.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 514 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. On the collector, look for UDP 514. Then send one datagram, with logger or a small UDP write, and see it land. A TCP listener on 514 is not syslog. Confirm the binary. From outside the log network, the port should not answer.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• UDP 514 is syslog. TCP 514 is shell, the old rsh service. They share a number and not a protocol.
• There is no handshake. A lost UDP packet is silent.
• TLS syslog is typically 6514, not 514.
• A public collector will be filled with other people's noise and forgeries.

Linuxsudo ss -lpun 'sport = :514'
sudo lsof -nP -iUDP:514

macOSsudo lsof -nP -iUDP:514
netstat -anv -p udp | grep '\.514[^0-9]'

Windowsnetstat -ano | findstr :514
Get-NetUDPEndpoint -LocalPort 514

Remotenc -vzu host 514