Back to blog
Linux & Servers August 20, 2026

How to Fix Nginx Emerg Bind to Port 80 Failed Errors

How to Fix Nginx Emerg Bind to Port 80 Failed Errors

When starting or restarting Nginx, you may encounter a crash that prevents the web server from initializing. When you check your server logs or run a service status check, you will find this emergency error message:

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

In TCP/IP networking, a single network socket address (combination of IP and port) can only be bound to a single listening process at a time. The error code 98 indicates that another process is already listening on TCP port 80, blocking Nginx from claiming the port.

If you are asking: How do I fix Nginx emerg bind to port 80 failed errors? This guide covers identifying the conflicting process, terminating socket listeners, resolving internal Nginx config conflicts, and setting up external monitors.


1. Identifying the Process Holding Port 80

To resolve the bind failure, you must find which process is currently listening on port 80. Run either of these network utility commands:

Using lsof (List Open Files)

sudo lsof -i :80

Using ss (Socket Statistics)

sudo ss -tulpn | grep :80

The output will display the listening process name and its Process ID (PID):

tcp  LISTEN  0  511  0.0.0.0:80  0.0.0.0:*  users:(("apache2",pid=1234,fd=4))

In the example output above, Apache (apache2) is running under PID 1234 and holding the socket open.


2. Resolving Common Port Conflicts

Based on the socket search output, execute the appropriate cleanup steps:

Case 1: Apache Web Server is Running

If Apache was installed as a dependency or default package, stop and disable it:

sudo systemctl stop apache2
sudo systemctl disable apache2

Case 2: Orphaned Nginx Processes

Sometimes, the master Nginx systemd service stops, but orphaned worker processes remain active. Check for active workers:

ps aux | grep nginx

If orphaned workers are present, terminate them manually:

sudo pkill nginx

Case 3: Docker Container Port Mappings

If a Docker container is mapped to port 80 on the host system:

  1. Check container mappings: docker ps
  2. If you find a container mapping 0.0.0.0:80->80/tcp, stop the container: docker stop <container_id>.
  3. Reconfigure the mapping in your docker-compose.yml to use a different host port (e.g., 8080:80).

3. The SRE Nuclear Option: Fuser Socket Termination

If you are during a production incident and need to free port 80 immediately, use the fuser command to kill any process currently holding the TCP socket open:

sudo fuser -k 80/tcp
  • -k (kill): Sends a SIGKILL signal directly to all process IDs associated with the specified socket.

After freeing the port, start Nginx:

sudo systemctl start nginx

4. Conflict Resolution Matrix

Use the matrix below to match socket conflict causes with their specific solutions:

Conflicting ProcessVerification CommandResolution Command
Apache (apache2 / httpd)sudo systemctl status apache2sudo systemctl stop apache2
Docker Daemon (docker)docker ps | grep :80docker stop <container_id>
Orphaned Nginx workersps aux | grep nginxsudo pkill nginx
Internal Nginx Config Duplicatesudo nginx -tRemove duplicate listen 80 lines.

5. Auditing Internal Nginx Configuration Conflicts

If the socket statistics command (ss or lsof) returns no active external process, the conflict is likely internal. This happens when multiple server blocks in your Nginx configuration files try to bind the same IP and port combination without unique virtual host configurations.

Test your Nginx configuration for syntax errors and duplicate bindings:

sudo nginx -t

If Nginx logs a duplicate listener error, search your configuration files for duplicate listen 80; directives. Ensure every server block listening on port 80 has a unique server_name directive to allow Nginx to route traffic correctly.


6. Proactive Outage Alerting with Pingzo

A port binding conflict will cause Nginx to crash, taking down all hosted web services. Local server checks might fail to detect this if they only monitor backend processes (like Node.js or database engines) without verifying that the external web server is listening.

Pingzo protects your applications by providing external endpoint auditing:

  • External Verification: Pingzo continuously calls your domain over HTTP/HTTPS, verifying that Nginx is active on port 80 and responding successfully.
  • WhatsApp Incident Logs: If Nginx crashes due to a port bind conflict during a deployment, Pingzo registers the outage instantly and forwards a critical alert to your WhatsApp.
  • Decoupled Infrastructure Checking: Because Pingzo monitors your site externally, it detects availability drops even if your host server is locked up and unable to send local system logs.
Try Pingzo Free

Know before your users do

Connect official WhatsApp notification channels, Discord webhooks, Telegram bots, and public status pages. Start in 30 seconds.

Create Free Monitor