Fix an Nginx “Address already in use” error

Identify the process holding an Nginx listening port, resolve duplicate instances, and distinguish normal virtual hosts from socket conflicts.

Best practices
Illustration of server operations and request logs

bind() failed (98: Address already in use) means Nginx cannot bind the address and port in the message. Identify the current listener and the service it belongs to before stopping anything. A second Nginx master, another web server, or a published container port may already own that socket.

Find the listener

For TCP port 80 on Linux:

sudo ss -ltnp 'sport = :80'
# Alternative:
sudo lsof -nP -iTCP:80 -sTCP:LISTEN

Use the actual failing port if it is 443 or another value. Inspect the PID, listening address, process arguments, and owning service or container.

Listener Next step
Apache or another web server Confirm whether it serves traffic; retain the existing entry point or assign a different port.
An existing Nginx master Check for duplicate startup. Reloading that instance may be all you need.
Node, Tomcat, or another application Decide whether it should listen on an internal port behind Nginx.
A container port publication Change the port mapping through the container's deployment configuration.

Use the right instance's management interface

For a systemd unit actually named nginx:

sudo systemctl status nginx
sudo nginx -t

Make sure the test uses the same binary, prefix, and configuration as the service. Reload an existing instance after a successful test. Start a stopped instance only after resolving the port conflict. Stopping another service requires understanding its traffic; disabling it permanently is a separate decision.

For an extra manually started instance, confirm its master PID and PID-file configuration before sending a graceful quit:

sudo nginx -s quit

Use that instance's -p and -c options when applicable. This command locates the master through its configured PID file. Do not use pkill -9 nginx as a routine repair.

If you change listen, update load-balancer targets, container mappings, and firewall rules too.

Check the effective configuration

sudo nginx -T

Review this output locally because included configuration can contain internal addresses or credentials. Multiple virtual hosts sharing listen 80; are normal. Repeated declarations within one block or conflicting socket options need to be resolved according to the exact configuration-test error.

listen [::]:80; uses ipv6only=on by default, so it can coexist with a separate IPv4 listener. Explicitly setting ipv6only=off can make an IPv6 wildcard socket accept IPv4 connections too, creating an overlap. See the listen directive.

Prevent repeat conflicts

Give each published port a clear owner and use one startup mechanism per instance. After a change, check the actual listeners, service logs, and a test request rather than relying only on a successful command exit.

FAQ

Why can I see a port but no process name?

Use sufficient permissions and check the correct host or container network namespace. The process may also have exited between checks. TIME_WAIT describes a closed TCP connection, not a process still listening; it is not a reason to restart the network stack.

Can a reload change listening ports?

Yes. Nginx attempts to open the new sockets and rolls back if it cannot apply the configuration. On success, new workers take over while old workers finish existing connections. Check logs if the old configuration remains active. See Nginx reload behavior.

What if IPv6 is disabled on the host?

Configure only the required IPv4 listeners. ipv6only=on still requires an IPv6 socket and cannot work around disabled IPv6 support.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting