$ guides / nginx / nginx-address-already-in-use ▌

Operations Guides

nginx: bind() to 0.0.0.0:80 failed (98: Address already in use)

The error log shows [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) and the master process exits. During a reload, old workers keep running with the previous configuration, so users may not notice immediately. During system boot or a manual start, the service is down.

Error 98 is EADDRINUSE. The nginx master binds listening sockets before forking workers. If the kernel reports port 80 is occupied, nginx cannot start or apply the new configuration. The holder might be a different service, a stale nginx master after a crash, or another nginx instance. Inside the same configuration, conflicting socket options for the same address:port can also trigger the error.

A failed reload leaves the previous configuration active, so the error may not surface until a systemd restart or log rotation triggers a full stop-start cycle.

What this means

Error 98 means the configured IP:port tuple is already bound to an active socket. On Linux, only one process normally holds a given TCP listen endpoint. The exception is coordinated use of SO_REUSEPORT across workers, which nginx supports via the reuseport listen option since version 1.9.1. Outside that controlled case, the kernel rejects duplicate binds.

The nginx master binds all listening sockets before forking workers. A bind failure at startup is fatal: the master logs [emerg] and exits. During a reload (nginx -s reload or kill -HUP), the master spawns new workers that inherit existing sockets. If the new configuration adds listen addresses, the master attempts to bind them. A bind failure during reload does not kill old workers, so the previous configuration stays active and may mask the problem until the next restart.

flowchart TD
    A[bind failed 98 on port 80] --> B{Who holds the port?}
    B -->|ss/lsof shows non-nginx| C[Stop other service or reconfigure port]
    B -->|ss/lsof shows nginx| D{PID matches active master?}
    D -->|Yes| E[Conflicting listen options or reuseport conflict]
    D -->|No| F[Stale master or orphaned workers]
    E --> G[Audit nginx -T for overlaps]
    F --> H[Kill stale processes and remove stale PID file]

Common causes

Cause	What it looks like	First thing to check
Another process holds port 80	nginx fails to start; `ss` shows apache, httpd, or another listener	`sudo ss -tlnp
Stale nginx master after crash or SIGKILL	PID file exists but the recorded process is dead; orphaned workers still serve traffic	`systemctl status nginx` and `ps aux
Conflicting `listen` socket options	`[emerg] bind() ... failed (98: Address already in use)`; same address:port declared with incompatible parameters (for example, mixed `reuseport` or mismatched `ipv6only`)	`nginx -t` and `nginx -T \| grep -E '^\slisten\s+.\b80\b'`
`SO_REUSEPORT` conflict	Mixed `reuseport` usage across server blocks for the same address, or two nginx instances launched with `reuseport`	Config diff for `reuseport` and process list
IPv6 dual-stack overlap	Duplicate `[::]:80` attempts, or overlapping IPv4 and IPv6 listen directives that collide on the same socket	`nginx -t` output and `nginx -T` for overlapping addresses

Quick checks

Run these read-only commands before making changes.

# Show all listeners on port 80 with owning process
sudo ss -tlnp | grep ':80'

# Alternative: show processes using port 80
sudo lsof -i :80

# Check systemd's view of the service state and main PID
sudo systemctl status nginx

# List running nginx processes to spot duplicate masters
ps aux | grep '[n]ginx: master'

# Read the recorded master PID
cat /var/run/nginx.pid
# or on some distributions:
cat /run/nginx.pid

# Dump effective configuration and grep for port 80 listeners
nginx -T 2>/dev/null | grep -E '^\s*listen\s+.*\b80\b'

# Verify which processes hold the port using fuser
sudo fuser -v 80/tcp

How to diagnose it

Find the current socket holder. Run sudo ss -tlnp | grep ':80'. If the process is not nginx, you have a cross-service conflict.
If nginx holds the port, check whether it is the expected master. Compare the PID from ss or lsof with the PID in /var/run/nginx.pid and with systemctl status nginx. A mismatch means a stale master or orphaned workers are holding the socket.
Check for a stale PID file. If the PID file references a process that no longer exists, the file is stale. Do not delete it blindly until you confirm no nginx workers remain.
Test configuration for duplicate or conflicting listens. Run nginx -t. Then run nginx -T and inspect all listen directives. Identical listen directives across server blocks merge; nginx uses server_name to route. However, directives specifying the same address:port with incompatible socket options (such as reuseport or ipv6only) create separate bind attempts that collide. Also look for overlapping IPv4 and IPv6 declarations that resolve to the same socket.
Inspect reuseport consistency. If some server blocks declare listen 80 reuseport and others declare listen 80 without it on the same address, the binding behavior is unpredictable and may fail. Ensure all directives for the same address:port either use reuseport uniformly or not at all.
Review IPv6 and dual-stack listens. Overlapping listen 80 and listen [::]:80 directives in multiple server blocks can collide if socket options are not aligned. Inspect nginx -T for duplicate address:port combinations, including IPv6 variants.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Worker process count	Confirms the master spawned the expected workers	Count below `worker_processes` or zero after startup
Stub status availability	Network-level confirmation that nginx accepted the new generation	Timeout or non-200 after a reload
Error log `[emerg]` rate	Bind failures, syntax errors, and resource exhaustion surface here	Any `[emerg]` during startup or reload events
Dropped connections (`accepts > handled`)	A growing gap means nginx cannot process new connections	`accepts > handled` in stub_status
File descriptor usage per worker	Orphaned sockets and leaked FDs prevent new binds	FD count near limit without matching connection count
Listen queue overflow (`TcpExtListenOverflows`)	Kernel drops connections before nginx sees them	Counter increasing while traffic is present

Fixes

Another process holds the port

If ss shows apache, httpd, a load balancer sidecar, or an application server bound to port 80, choose one:

Stop the conflicting service and disable it.
Reconfigure the other service to listen on a different port.
Reconfigure nginx to use a non-standard port.

Moving nginx away from port 80 requires updating downstream load balancers, DNS records, or user bookmarks.

Stale nginx master or orphaned workers

If the socket holder is an nginx process that does not match your active service:

Compare the PID from ss or lsof with /var/run/nginx.pid. If the file references a dead process, it is stale.
If the stale master is still alive, send QUIT to its PID. Warning: if the PID file is stale, use the PID from ss instead of the file to avoid killing the wrong process.
```
sudo kill -QUIT <stale-master-pid>
```
If workers are orphaned because the master died to SIGKILL or OOM, terminate them directly. Warning: this drops active connections. Use the specific PIDs from ss or ps. If you run multiple nginx instances, avoid broad pkill because it targets all workers on the host.
```
sudo kill -TERM <orphaned-worker-pid>
```
After confirming no nginx master is running, remove the stale PID file:
```
sudo rm -f /var/run/nginx.pid
```
Start nginx through systemd to ensure proper PID tracking:
```
sudo systemctl start nginx
```

Conflicting `listen` socket options

Audit all files included by nginx.conf, especially sites-enabled/*.conf. Look for the same address:port declared with different socket options across server blocks. Remember that identical listen directives merge; the conflict comes from incompatible parameters such as reuseport, ipv6only, or bind. Consolidate options so all directives for a given address:port match.

SO_REUSEPORT conflicts

Since nginx 1.9.1, listen 80 reuseport creates a separate socket per worker using the Linux SO_REUSEPORT option. This is safe only when applied consistently. If your configuration mixes reuseport on some blocks and omits it on others for the same address, or if two independent nginx instances both use reuseport for the same port, bind failures can occur. Align the configuration so all listen directives for the same address:port share the same options.

Prevention

Run nginx -t before every reload. A syntax or bind check failure during reload leaves the previous config active, which masks drift.
Manage nginx through systemd rather than invoking the binary directly. systemd prevents accidental double-starts and tracks the main PID.
Set worker_shutdown_timeout (available since nginx 1.11.11) to bound how long old workers linger during reloads. Without it, long-lived connections can stall worker shutdown indefinitely.
Monitor error logs for [emerg] after every reload. Alerting on emerg-level messages catches bind failures immediately instead of at the next restart.
Keep the pid directive in nginx.conf synchronized with the systemd unit’s expected PID file path.
After any unclean shutdown (OOM kill, SIGKILL, host panic), validate socket state with ss before restarting. Orphaned workers may still hold the listening socket.
When generating configuration from templates, ensure that included snippets do not inject hidden listen directives into the same address space.

How Netdata helps

Correlate stub_status metrics with error log [emerg] spikes to distinguish startup failures from backend slowdowns.
Alert when accepted connections exceed handled connections to detect silent reload failures.
Track per-process file descriptor utilization to catch orphaned sockets from stale masters before they block new binds.
Surface kernel-level TcpExtListenOverflows to reveal silent connection drops that stub_status cannot see.
Monitor worker process count against the configured value to detect when a startup or reload produces fewer workers than expected.

The Netdata solution

Web server monitoring with Netdata

Netdata monitors NGINX with per-second request, connection, and latency metrics plus ML anomaly detection. Correlate connection and file-descriptor exhaustion, upstream cascade failures, buffer spill, and TLS CPU with the host signals behind them.

See web server monitoring → Start monitoring free