Port 5672 AMQP – Free, Online, Private

What listens on 5672

Port 5672 is AMQP. The IANA name is amqp, assigned for TCP, UDP, and SCTP. The broker you are running is almost certainly TCP. RabbitMQ's default listener for AMQP 0-9-1 is 5672. AMQP over TLS defaults to 5671 on that broker, which is a different number. The management UI defaults to 15672 and speaks HTTP. A client library aimed at 15672 will not open a channel. AMQP 1.0 is a different protocol that some brokers expose on 5672 and some do not. Read the broker's listener list. UDP and SCTP rows exist in the registry and are not how application clients connect.

The IANA service name is amqp: AMQP. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 5672. 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 5672

Service notes for port 5672: the IANA name is amqp (AMQP), and the program people mean is AMQP. TCP 5672 is the IANA amqp port. AMQP 0-9-1 brokers, including RabbitMQ, listen here. AMQP 1.0 and TLS use other ports. SCTP is also registered. An AMQP port with the default guest user is a remote code and data path if guest is allowed from anywhere other than localhost. Delete guest, or keep its loopback restriction. Put 5672 on the application network. Use 5671 with real certificates for anything that crosses an untrusted network. A user that can configure an exchange can often publish to anywhere. Separate publishers and consumers. The management port is a second door and needs its own authentication. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 5672, you are on the wrong page.

People open 5672 in the security group and leave the broker bound to localhost, which is RabbitMQ's safer default in some installs. ss shows 127.0.0.1. Another trap is a client using amqps:// against 5672, so the first byte is TLS and the broker answers with AMQP. Another is the reverse, amqp:// against 5671. Another is a heartbeat shorter than a load balancer's idle timeout, or longer, so connections drop at 60 seconds. Another is confusing 5672 with Kafka's 9092. The client libraries are not interchangeable.

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 5672 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 broker process should own TCP 5672 on the application address. A localhost-only socket is a local broker. From the app, a protocol header exchange is the real test. nc only shows that TCP completed.

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.

• 5671 is the usual AMQP-over-TLS port. 5672 is cleartext AMQP.
• 15672 is the RabbitMQ management UI, HTTP, not AMQP.
• guest@localhost is not a remote login.
• UDP and SCTP are registered. Application clients use TCP.

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

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

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

Remotenc -vz host 5672