5672 AMQP / RabbitMQ TCP Flagship

What it's for

Port 5672 is the default port for AMQP (Advanced Message Queuing Protocol), most commonly encountered via RabbitMQ, one of the most widely deployed message brokers. Applications publish messages to exchanges and consume them from queues over this port, enabling asynchronous, decoupled communication between services — a producer doesn't need to know or wait for a consumer to be immediately available.

This pattern shows up constantly in background job processing (sending emails, generating reports, processing uploads), event-driven microservice architectures, and anywhere you want to smooth out load spikes by buffering work in a queue rather than processing everything synchronously.

Protocol basics

• Protocol: TCP, needed for reliable, ordered delivery of messages between producers, the broker, and consumers.
• Exchange/queue/binding model. AMQP's core abstraction involves publishers sending messages to exchanges, which route them to queues based on bindings (routing rules) — this indirection is what allows flexible routing patterns (direct, fanout, topic, headers-based).
• Acknowledgment-based reliability. Consumers acknowledge messages after successful processing; unacknowledged messages can be redelivered, which is central to AMQP's "at-least-once delivery" guarantees.
• Persistent connections with channels. Clients typically open one TCP connection to port 5672 and multiplex multiple lightweight "channels" over it, rather than opening a new connection per operation.

Security considerations

• Port 5672 should not be exposed to the public internet in typical architectures — like other backend infrastructure ports, it belongs on a private network reachable only by the services that need it.
• Always configure authentication — RabbitMQ ships with a default guest/guest account that's restricted to localhost connections by default, but this default should never be relied upon or extended to remote access.
• Use TLS for connections crossing any untrusted network boundary, and consider per-service credentials with scoped permissions (RabbitMQ supports fine-grained per-vhost, per-queue permissions) rather than one shared broad-access account.
• Monitor queue depth and consumer health — a security or reliability incident often first shows up as messages piling up unprocessed, which is also a useful operational signal independent of security concerns.

Troubleshooting

"Connection refused" on port 5672:

• RabbitMQ isn't running, or a firewall/security group is blocking the port between your application and the broker

Messages published but never consumed:

• Check the exchange-to-queue binding — a common mistake is publishing to an exchange with no binding routing messages into the queue your consumer is actually reading from

Consumer keeps reprocessing the same message:

• The consumer isn't acknowledging messages after processing (or is crashing before acknowledgment), causing RabbitMQ to redeliver — verify your acknowledgment logic runs after successful processing, not before

High memory usage / broker becomes unresponsive:

• Often caused by queues growing unbounded because consumers have stopped or fallen behind — set queue length limits or dead-letter policies so a stuck consumer doesn't cause unbounded memory growth on the broker

Comparison / FAQ

Should I use RabbitMQ or Kafka for my project?

RabbitMQ (AMQP) fits traditional task-queue patterns well — discrete jobs that get processed and acknowledged. Kafka is generally the better fit for high-throughput event streaming where you need to replay historical events or have many independent consumers reading the same stream at their own pace.

Why is my RabbitMQ queue growing without being processed?

Check whether consumers are actually connected and healthy, and whether they're correctly acknowledging messages after processing — a crashed or disconnected consumer, or one that never acknowledges, will cause messages to accumulate.

Is the default RabbitMQ guest account a security risk?

The guest account is restricted to localhost-only connections by default specifically to prevent it from being a remote attack vector, but it should still be disabled or have its password changed in any real deployment, since localhost restrictions can sometimes be inadvertently bypassed by misconfiguration.

What is port 4369 used for alongside 5672?

EPMD (Erlang Port Mapper Daemon) on port 4369 helps RabbitMQ's underlying Erlang runtime discover other nodes in a clustered deployment — it's an internal clustering mechanism, not something application clients connect to directly.