Syslog Ports Explained: UDP 514, TCP, and TLS 6514

A syslog port number only tells you where to send traffic if the receiver is listening there. You also need to match the transport: sending UDP to a TCP listener on the same numbered port will not work.

The traditional syslog default is UDP 514. Syslog over TLS uses TCP 6514 by default. Plain TCP syslog may use port 514, 601, 1514, or another port chosen by the implementation or administrator—there is no single universal TCP listener setting.

Start with the collector’s actual listener

Before changing a firewall or sender configuration, find out what the log collector expects:

• Is it listening for UDP, TCP, or TLS over TCP?
• Which destination port is configured?
• Is it bound to the external interface, or only to loopback?
• Does TLS require particular certificates or client authentication?

On a Linux collector, ss can check for local listeners:

sudo ss -lunp 'sport = :514'
sudo ss -ltnp 'sport = :514'
sudo ss -ltnp 'sport = :6514'

The first command checks UDP 514, the second TCP 514, and the third TCP 6514. Replace the port with the collector’s configured value if it uses a custom one. No matching output means there is no matching socket visible in that network namespace; it does not explain why the service is absent. Check that the collector is running and configured to accept remote traffic.

A listener bound to 127.0.0.1 is not reachable through the host’s external address. And a listening socket does not prove that a firewall or network path permits remote traffic. For more ways to inspect listeners—and why “listening” is not the same as “reachable”—see how to check open ports on Linux.

Match the sender to the transport

In common rsyslog forwarding syntax, one @ selects UDP and two @ characters select TCP:

*.* @logs.example.net:514
*.* @@logs.example.net:514

Use the line that matches the collector. These examples are not TLS configuration: TLS forwarding needs additional settings for the TLS-capable transport, certificates, and peer verification. The exact configuration depends on the installed rsyslog version and modules.

For example, if the collector is listening for TCP on port 1514, the sender must use TCP 1514. Opening UDP 514 in a firewall will not fix a mismatch. Configure the sender, collector, and network rules for the same transport and destination port.

The sender’s source port is not the syslog destination port. For TCP and TLS, the sender normally makes an outgoing connection toward the collector’s configured port. For UDP, allow the relevant UDP destination port through the network path.

Test connectivity without assuming success

For a TCP listener, nc can test whether a connection can be established:

nc -vz logs.example.net 514

Use the collector’s actual TCP port. A successful connection confirms that a connection was accepted; it does not confirm that syslog events are being parsed, retained, or stored.

For a TLS listener, you can try a handshake with:

openssl s_client -connect logs.example.net:6514

A receiver may require a client certificate or specific trust settings. A failed generic handshake is not conclusive proof that the port is closed; check the receiver’s TLS requirements and logs.

UDP has no connection handshake or delivery acknowledgement. A command reporting that it sent a datagram cannot prove the collector received it. Capture traffic on the collector while sending a test message:

sudo tcpdump -ni any 'udp port 514'

For plain TCP or TLS traffic, use a filter such as tcp port 514 or tcp port 6514. If you need to narrow a capture to traffic involving a particular host, tcpdump IP filters can help you add a host, source, destination, or subnet condition.

A packet capture shows traffic reaching the selected interface, not that the application accepted or stored it. Check the collector’s own logs as well.

A practical troubleshooting order

When logs do not arrive, work through the path in order:

1. Confirm transport and port. UDP and TCP are different listeners, even when they use the same port number. Check whether TLS is expected.
2. Check the collector. Verify its service is running, its network input is enabled, and it is bound to the intended interface and port.
3. Check the network path. Confirm that host firewalls and any network firewalls, security groups, or ACLs allow the correct protocol and destination port. A firewall rule cannot create a missing listener.
4. Capture traffic and inspect logs. If packets arrive but events do not appear, investigate the collector configuration, message compatibility, and application logs. If packets never arrive, check the sender destination, routing, and filtering between the hosts.
5. For TLS, check certificates. Verify trust, hostname expectations, certificate expiry, and whether mutual TLS is required.

Choosing between UDP, TCP, and TLS

UDP is widely used for traditional syslog, but it is best-effort: packets can be lost, reordered, or blocked without the sender knowing. TCP provides a connection, but that alone does not guarantee every event was processed or stored. TCP without TLS does not encrypt the messages.

When logs cross an untrusted network, use a properly configured TLS transport or another protected network path. Encryption depends on both endpoints being configured correctly; opening TCP 6514 by itself does not turn plain syslog into TLS.

The useful defaults to remember are UDP 514 for traditional syslog and TCP 6514 for syslog over TLS. For plain TCP, verify the collector’s configured port rather than guessing. The listener, sender, transport, and network rules all need to agree.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.