Port 5222 XMPP client – Free, Online, Private

What listens on 5222

Port 5222 is the XMPP client connection, RFC 6120. The IANA name is xmpp-client. A client opens TCP, receives a stream header, and may upgrade with STARTTLS before it authenticates and binds a resource. The server-to-server port is 5269, xmpp-server, a different number. File transfer and group chat can negotiate other ports or use in-band data. A deployment that only opens 5222 allows clients and does not allow federation. UDP 5222 is reserved. HTTP binding and WebSocket XMPP often ride on 443 and never touch 5222. If your users are on a web client, check 443 first.

The IANA service name is xmpp-client: XMPP Client Connection. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 5222. The service described here is the TCP one. 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 5222

Service notes for port 5222: the IANA name is xmpp-client (XMPP Client Connection), and the program people mean is XMPP client. TCP 5222 is the IANA xmpp-client port. Clients connect here. Server-to-server XMPP is 5269, which is not this assignment. UDP 5222 is reserved. Require STARTTLS and refuse cleartext authentication. A certificate mismatch trains users to click through it, which is the real failure mode on this port. S2S on 5269 has its own certificate check via the domain's SRV records. Do not expose the admin interface on 5222. Rate-limit logins. A public XMPP server is supposed to be public to its users. It is not supposed to be an open relay for registrations if you left in-band registration on. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 5222, you are on the wrong page.

Clients aimed at 5223 are using the old implicit-TLS convention, which is not the RFC 6120 port. A server that only speaks STARTTLS on 5222 will reject them. Another trap is an SRV record pointing at a host that does not listen, while the A record's host does, or the reverse. Clients that honor SRV and clients that do not will disagree. Another is a firewall allowing 5222 and blocking 5269, so local users work and federation times out. Another is a proxy timeout that is shorter than a quiet client. Raise the idle timeout.

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 5222 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. The process is your XMPP server, on TCP 5222, on the address the SRV record names. openssl s_client after STARTTLS, or a real client, proves the stream. A TCP connect only proves the socket.

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.

• 5222 is client to server. 5269 is server to server.
• UDP 5222 is reserved.
• 5223 is a legacy implicit-TLS port, not the registered client port.
• A web XMPP client may be using 443 and never connect here.

Linuxsudo ss -lptn 'sport = :5222'
sudo lsof -nP -iTCP:5222 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:5222 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.5222[^0-9]'

Windowsnetstat -ano | findstr :5222
Get-NetTCPConnection -LocalPort 5222

Remotenc -vz host 5222