One Port, Two Listeners? SO_REUSEPORT vs SO_REUSEADDR, the Real Distinction

Rolling deployments break when a second container tries to bind a port already held by its predecessor; knowing when to enable SO_REUSEPORT instead of SO_REUSEADDR prevents these stalls and lets multi-process services scale without a shared-listener lock.

By default, binding the same IP+port twice fails with EADDRINUSE, which is why most people say one port holds one program. The kernel's conflict check actually hinges on two things: the bound address+port pair and the reuse flags on the socket. SO_REUSEADDR only shortens the TIME_WAIT delay on restart; it never allows two processes to listen simultaneously. SO_REUSEPORT, available since Linux 3.9, permits multiple processes to bind one port, and the kernel distributes inbound connections via a four-tuple hash.

Multi-process servers such as Nginx use SO_REUSEPORT to make each worker hold its own socket, removing the forwarding bottleneck and the thundering herd/lock contention of a shared listener. The trick also enables zero-downtime restarts: new and old processes bind together, then the old one exits gracefully. The failure mode shows up in container rolling releases when the new instance lacks SO_REUSEPORT and cannot bind the host port, stalling the deploy or triggering a rollback. The distinction to remember: TIME_WAIT calls for SO_REUSEADDR, coexistence calls for SO_REUSEPORT.