Syslog over TCP uses port 514 (plaintext) or 6514 (TLS-encrypted, RFC 5425). The two daemons: rsyslog (default on most Linux distros) and syslog-ng (the alternative, more flexible config). The team that centralizes logs from network gear (Cisco, Fortinet, Palo Alto) and Linux servers uses rsyslog as the receiver, with TLS for any untrusted network path.
Table of contents
- The two ports
- rsyslog receiver setup
- rsyslog sender setup
- syslog-ng setup
- Where the logs land
- How this fits the rest of the stack
- FAQ
The two ports
UDP 514 - the classic syslog port. Connectionless, no acknowledgment, no encryption. The team that uses UDP syslog on a trusted internal network is fine; the team that uses it across an untrusted network loses logs to network drops and gets no confidentiality.
TCP 514 - the same port number, but TCP. Connection-oriented, the receiver acknowledges, no encryption. The team that wants reliable delivery uses TCP 514 on a trusted network.
TCP 6514 - syslog over TLS (RFC 5425). Encrypted, authenticated, reliable. The team that forwards syslog across an untrusted network (DMZ, public cloud, multi-region) uses 6514.
rsyslog receiver setup
On the log server, enable the TCP receiver:
# /etc/rsyslog.d/10-tcp-receiver.conf
module(load="imtcp")
input(type="imtcp" port="514")
Restart: sudo systemctl restart rsyslog. The receiver is now listening on TCP 514.
For TLS:
module(load="imtcp"
StreamDriver.Name="gtls"
StreamDriver.Mode="1"
StreamDriver.Authmode="x509/certvalid")
input(type="imtcp" port="6514")
And configure the cert paths in /etc/rsyslog.d/20-tls.conf (cert, key, CA bundle). The team that uses Let’s Encrypt for the host’s web cert reuses it for the syslog TLS layer.
rsyslog sender setup
On each sender:
# /etc/rsyslog.d/20-remote.conf
*.* @@logs.example.com:514
The double @@ is TCP. Single @ is UDP. Restart rsyslog.
For TLS:
action(type="omfwd"
protocol="tcp"
target="logs.example.com"
port="6514"
StreamDriver="gtls"
StreamDriverMode="1"
StreamDriverAuthMode="x509/certvalid")
syslog-ng setup
For syslog-ng, the equivalent is the syslog() source and destination:
source s_net { tcp(ip(0.0.0.0) port(514)); };
destination d_files { file("/var/log/remote/$HOST/$YEAR$MONTH$DAY.log"); };
log { source(s_net); destination(d_files); };
The team that picks syslog-ng over rsyslog usually does so for the more readable config syntax or the better pattern-matching support.
Where the logs land
By default, rsyslog writes remote logs to /var/log/. The team that centralizes uses a separate path: /var/log/remote/<hostname>/. A pattern using template:
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log"
*.* ?RemoteLogs
& ~
The & ~ means “stop processing after writing to this template” - prevents the message from also being written to the local /var/log/syslog.
The team that ships these to a log aggregator (Loki, Elasticsearch, Splunk) adds a Filebeat or Logstash input on top.
FAQ
Should I use UDP or TCP for syslog?
TCP. The reliability of TCP - retransmission, ordering, flow control - is worth the small overhead. UDP syslog drops messages on network blips; TCP does not.
Is port 514 privileged?
Yes - it is below 1024. The rsyslog/syslog-ng daemons need to start as root to bind to 514 (or use the systemd socket activation pattern). The team that cannot run as root uses a non-privileged port like 1514.
What is the difference between syslog and journald?
journald is systemd’s native log system. It writes binary logs to /var/log/journal/. The team that uses journald can forward to syslog with journalctl -o export or the systemd-journal-upload service. journald is the modern default; rsyslog is the legacy layer that network gear still uses.
Can I send logs over the public internet?
Yes, with TLS on port 6514. The team that ships logs across the public internet without TLS has credentials and PII visible to anyone with a packet capture. The team that uses 6514 with cert validation has encryption and authentication.
How do I see what is being received?
tcpdump -i any port 514 or tcpdump -i any port 6514. The team that debugs a missing log stream uses this to confirm the sender is actually transmitting.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: