In the process of deploying or modifying Nginx configuration, many users often overlook a key detail: the uniqueness and correctness of the port. If there is an error in binding the port, repeated listening or incorrect format in the Nginx configuration file, it is likely to cause port conflicts, and then Nginx startup failure, inaccessible pages, abnormal service termination and other problems. Especially on cloud servers with multiple sites and multiple services running at the same time, port conflicts can easily cause confusion that is difficult to troubleshoot.

What are the manifestations of cloud server ports being occupied by Nginx?

When Nginx configuration errors cause port conflicts or occupation, the system usually has the following typical manifestations:

• Nginx startup fails, and execution of systemctl start nginx reports an error;
• The error log indicates that the port is occupied;
• The web page cannot be accessed, and the browser prompts 502/503;
• Nginx crashes and restarts repeatedly, and CPU/memory increases abnormally;
• Accessing a port returns the wrong site content (cross-domain confusion).

These problems often appear to be service crashes on the surface, but the root cause lies in the wrong port listening configuration.

Principle analysis: Why does Nginx port configuration go wrong?

1. Multiple binding listeners

Nginx supports listen directives to bind IP and ports, such as:

listen 80;
listen 127.0.0.1:80;

If you configure both sites to listen to 0.0.0.0:80, it will cause a conflict, because 0.0.0.0 means listening to all IPs, and multiple listeners will grab each other's ports.

2. Accidental occupation by multiple processes

Sometimes the port is occupied by other services (such as Apache, Tomcat, Node.js), and Nginx does not check the existing port usage when configuring.

3. Configuration format error

Spelling errors, missing semicolons, and repeated definitions of the same server block may cause Nginx to be abnormal when trying to listen to the port.

Actual combat troubleshooting steps: Five steps to quickly locate the source of the problem

Step 1: Confirm port occupation

sudo lsof -i :80

or

sudo netstat -tulnp | grep :80

You will see output similar to:

nginx 1203 root 6u IPv4 123456 0t0 TCP *:80 (LISTEN)

If multiple programs are found to listen to the same port, further analysis is required.

Step 2: Check whether there is repeated listening in the Nginx configuration

Use the following command to check the listen directive in all configuration files:

grep -Rn "listen" /etc/nginx/

Key points to check:

• Are listen 80 written in multiple sites;
• Is the same port bound to default_server by multiple server blocks;
• Are duplicate IPv4 and IPv6 port configurations written.

Recommended method:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
}

Step 3: Verify that the Nginx configuration file is valid

sudo nginx -t

The correct output should be:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If the error "bind() to 0.0.0.0:80 failed" is reported, it means there is a port conflict or configuration syntax problem.

Step 4: Locate the source of the process occupying the port

If it is not Nginx itself that occupies the port, it may be another process. You can use:

ps -ef | grep 80

Further confirm the process PID, then:

sudo kill -9

Or use systemctl stop apache2 to shut down conflicting services.

Step 5: Temporarily release the port and restart the service

Restart Nginx after confirmation:

sudo systemctl restart nginx

If the system has multiple users with different operating habits, the port can be temporarily released:

fuser -k 80/tcp

Nginx is a flexible and powerful tool, but its flexible configuration can also easily lead to hidden dangers, especially in multi-service deployment or complex cloud server environments, where any wrong port configuration may cause serious service interruption. I hope the detailed practical experience in this article can help you calmly deal with the problem of Nginx port occupation.