Why Does Nginx Keep Stopping? 5 Checks to Find and Fix the Problem

If Nginx keeps stopping, restarting the service may restore your website temporarily, but it will not necessarily fix the underlying problem. A failed configuration test, duplicate port binding, missing SSL certificate, out-of-memory (OOM) kill, or unavailable upstream application can all cause Nginx-related downtime or errors.

The first step is to determine whether the Nginx service has actually stopped or whether it is still running but failing to serve requests correctly. This guide shows you the commands to run, the log messages to look for, and the fixes that address common causes without hiding the underlying problem.

Note: the commands, file paths and service names below are representative of common Debian/Ubuntu and RHEL/AlmaLinux-family installations. Actual paths and service names (for example php-fpm vs php8.2-fpm, or /etc/nginx/ vs a custom install prefix) vary by distribution, package manager and installation method — always confirm the exact path on your own server before applying a fix.

Run These 5 Checks First

Run these commands on a Linux server with systemd. Use an account with appropriate privileges; add sudo where required. Review the output before making configuration changes.

1. Test the Nginx Configuration

sudo nginx -t

This checks the configuration syntax and attempts to open files referenced by the configuration, helping identify problems before a reload or restart. See the official Nginx command-line documentation.

Successful output typically looks like this:

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

If the test fails, note the file path and line number in the error. Correct that issue before restarting Nginx.

2. Check the Service Status

sudo systemctl status nginx --no-pager -l

Look for the service state, the most recent exit status, and any error messages. Depending on the distribution and service configuration, you may see active (running), inactive (dead), or failed.

If Nginx is failed, the status output can help identify the last reported error. If it is running, continue troubleshooting instead of assuming the service needs a restart.

3. Read the Nginx Service Journal

sudo journalctl -u nginx -n 100 --no-pager
sudo journalctl -u nginx --since "30 minutes ago" --no-pager

The first command displays recent service messages; the second limits the results to the last 30 minutes. Look for repeated failures, configuration errors, signals, exit codes, and restart attempts around the time the problem occurred.

4. Check Which Process Owns Ports 80 and 443

sudo ss -ltnp

This lists listening TCP sockets and, where permissions allow, the processes that own them. Check whether ports 80 and 443 are already occupied by another web server or process.

If another service is listening on a required port, Nginx may fail to start with an error such as bind() failed. Do not terminate the other process until you identify what it does and confirm which service should own the port. On a cPanel server running Nginx as a reverse proxy in front of Apache, for example, confirm which of the two is expected to own ports 80/443 before changing anything — see our guide on choosing and configuring a cPanel firewall if the conflict turns out to be firewall-related rather than a second web server.

5. Check for Out-of-Memory Kills and Kernel Errors

sudo journalctl -k --since "2 hours ago" --no-pager
sudo journalctl -k --since "2 hours ago" --no-pager | grep -Ei 'oom|out of memory|killed process'

Look for messages indicating that the kernel’s out-of-memory (OOM) handler killed Nginx or another process. If the system has no relevant journal entries, inspect the available kernel logs or your monitoring system.

For a quick memory overview, run:

free -h
ps -eo pid,comm,%mem,%cpu --sort=-%mem | head -15

If Nginx is being killed under memory pressure, investigate the process named in the kernel log. The problem may originate in PHP-FPM, a database, another application, or the overall server workload rather than Nginx itself. If repeated OOM kills coincide with a traffic surge, it’s also worth ruling out whether the server is simply exceeding its allocated resources — see our guide on diagnosing a “Bandwidth Limit Exceeded” or resource-exhaustion error.

Is Nginx Stopped or Is the Website Returning an Error?

These problems are related but require different fixes. A website returning an error does not automatically mean that the Nginx service has stopped.

Start with the service state and error logs. This prevents you from spending time fixing the wrong component.

1. Configuration Errors That Prevent Nginx From Starting

A configuration change can cause Nginx to fail during startup or prevent a reload from applying successfully. Common causes include invalid directives, missing semicolons, malformed server blocks, incorrect include paths, and references to certificate files that no longer exist.

Run the configuration test first:

sudo nginx -t

Example: Invalid Directive or Syntax

A syntax error might produce output similar to this:

nginx: [emerg] unknown directive "server_nam" in /etc/nginx/conf.d/site.conf:8
nginx: configuration file /etc/nginx/nginx.conf test failed

What it means: Nginx encountered an unrecognized directive in the specified file and line.

How to fix it:

1. Open the file named in the error.
2. Inspect the reported line and the surrounding configuration block.
3. Correct the typo or invalid directive.
4. Run sudo nginx -t again.
5. Only reload or restart Nginx after the test succeeds.

Do not copy a directive from another server without checking that it is supported by your installed Nginx version and any required modules.

Example: Duplicate Listen Port or Address

An error may look like this:

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

What it means: Another process or conflicting socket configuration is preventing Nginx from binding to the requested address and port.

Check the listener:

sudo ss -ltnp | grep -E ':(80|443)\b'

Inspect the Nginx configuration for relevant listening directives:

sudo nginx -T 2>&1 | grep -nE 'listen .*(:80|:443|80|443)'

The output of nginx -T can contain configuration details, domain names and other sensitive information. Review it locally and avoid publishing the full output publicly.

How to fix it: Identify which service owns the port. If Apache, another Nginx instance, a container, or a proxy is supposed to own it, adjust the architecture or listener configuration accordingly. Remove accidental duplicate/conflicting configuration only after confirming it is not required. If a security suite or firewall is also binding or redirecting these ports, rule that out too — our BitNinja vs. Imunify360 comparison covers how each platform’s firewall and WAF modules interact with the web server layer.

Example: Missing SSL Certificate or Private Key

Nginx may report an error similar to:

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": BIO_new_file() failed
nginx: configuration file /etc/nginx/nginx.conf test failed

What it means: The configured certificate path may be incorrect, the file may have been removed, or Nginx may not be able to access it.

Check the configured path and file:

sudo ls -l /etc/letsencrypt/live/example.com/
sudo readlink -f /etc/letsencrypt/live/example.com/fullchain.pem

Replace the example domain with your actual certificate path. Certificate directories vary by installation method, and symbolic links may point to files in a separate archive directory.

How to fix it: Restore or renew the certificate using your certificate-management workflow, correct the configuration path, and verify the relevant file permissions. Never make a private key world-readable to work around a permission error.

Once the path and permissions are corrected, run sudo nginx -t before reloading the service.

2. Resource Limitations and Out-of-Memory Kills

Nginx may stop if the operating system terminates its process during severe memory pressure. However, high CPU usage or low available memory alone does not prove that an OOM kill occurred. Confirm the cause using kernel logs and system monitoring.

Check memory and system pressure:

free -h
uptime
sudo journalctl -k --since "2 hours ago" --no-pager | grep -Ei 'oom|out of memory|killed process'

Look for the exact process killed by the kernel and the timestamp. If the message identifies PHP-FPM or another application, investigate that process as well.

What to Do If Memory Pressure Is the Cause

• Check whether traffic or concurrent requests increased immediately before the incident.
• Inspect PHP-FPM worker counts, database activity and other memory-intensive processes.
• Review Nginx worker connections and buffer settings rather than increasing them blindly.
• Check whether the server or service is subject to a systemd, container or hosting-provider memory limit.
• Consider additional RAM, swap or workload distribution when monitoring confirms that capacity is insufficient.
• Set up alerts for memory pressure and repeated service failures.

Swap can help absorb some memory pressure, but it is not a substitute for sufficient RAM when the server is persistently overloaded. Avoid changing multiple resource settings at once; measure the effect of each change.

3. Third-Party Modules and Version Compatibility

Third-party Nginx modules can introduce compatibility problems, especially after a package update or when a module was built against a different Nginx version. A missing shared module or unsupported directive may prevent Nginx from starting.

Check the installed version and build options:

nginx -v
nginx -V 2>&1

Then test the configuration and read the exact error message. If the error names a module or directive, verify that the module is installed and compatible with the current binary.

Recommended approach:

1. Record the current Nginx version and installed modules.
2. Review package updates or module changes made before the failure began.
3. Test updates in staging where possible.
4. Keep a known-good configuration backup.
5. Roll back only the change that caused the failure, using your normal package-management and deployment process.

Do not remove modules or replace the Nginx binary indiscriminately on a production server. First establish which component caused the failure.

4. Upstream Problems: Why Nginx Returns 502 or 504

If systemctl status nginx reports active (running) but your website returns a 502 or 504 error, the Nginx service itself may be healthy. The failure may be between Nginx and the application it proxies requests to.

Common upstream services include PHP-FPM, Node.js applications, Python application servers, and other HTTP services.

Example: Connection Refused

connect() failed (111: Connection refused) while connecting to upstream

Likely cause: Nginx attempted to connect to an upstream address or port where no service was accepting connections, or the target rejected the connection.

Check the upstream listener:

sudo ss -ltnp
sudo systemctl status php-fpm --no-pager -l

The service may be named differently, such as php8.2-fpm or php8.3-fpm. Use the actual service name installed on your server.

Verify that the upstream address in the Nginx configuration matches the application’s actual listening address. If the application has stopped, investigate its own journal and configuration before restarting it.

Example: Upstream Timeout

upstream timed out (110: Connection timed out) while reading response header from upstream

Likely cause: The upstream application did not return a response within the expected time. It may be overloaded, blocked on a database query, waiting on another service, or processing a slow request.

Check the application logs, resource usage and response times before changing proxy timeouts. Increasing a timeout without resolving an overloaded or stalled backend can make users wait longer without fixing the cause.

Example: PHP-FPM Socket Missing or Inaccessible

connect() to unix:/run/php/php-fpm.sock failed (2: No such file or directory)

Likely cause: The configured socket path does not exist, the PHP-FPM service is stopped, or the Nginx configuration references a socket that differs from the one PHP-FPM actually creates.

Check the available sockets and PHP-FPM service:

sudo find /run/php -maxdepth 1 -type s -ls
sudo systemctl status php-fpm --no-pager -l

Use the correct PHP-FPM service name and socket path for your distribution. If the socket exists but access is denied, check the socket’s owner, group and permissions rather than applying broad permissions to the runtime directory.

5. Network, DNS and Firewall Problems

Network issues can make a website appear unavailable even when Nginx remains running. Examples include DNS records pointing to the wrong address, firewall rules blocking incoming traffic, incorrect listening addresses, and routing problems between a reverse proxy and its upstream.

Check the local listeners:

sudo ss -ltnp | grep -E ':(80|443)\b'

Test the local HTTP response while supplying your domain name:

curl -I --resolve example.com:80:127.0.0.1 http://example.com/

Replace example.com with your domain. If Nginx is not listening on loopback, uses a different address, or redirects to HTTPS, adapt the test to match your configuration.

For HTTPS, you can test the local endpoint with:

curl -kI --resolve example.com:443:127.0.0.1 https://example.com/

The -k option disables certificate validation for this diagnostic request, so use it only to isolate connectivity from certificate-validation issues. It is not a production security fix.

If local requests succeed but external connections fail, investigate DNS, the server’s public IP, cloud security groups, routing and firewall rules. Do not disable the firewall wholesale as a troubleshooting shortcut — if CSF, FirewallD, APF or another firewall manager is in the mix, see our cPanel firewall software comparison for how each one’s rule backend and WHM integration behave.

6. Find the Error in Nginx Logs

Nginx error logs often contain the most useful evidence of startup failures and request-processing problems. On many Debian- and RHEL-based installations, the default error log is /var/log/nginx/error.log, but the actual path depends on the package and configuration.

Read recent entries:

sudo tail -n 100 /var/log/nginx/error.log

Follow new entries while reproducing the issue:

sudo tail -f /var/log/nginx/error.log

If that path does not exist, inspect the configured error-log path and the service journal:

nginx -V 2>&1 | grep -o -- '--error-log-path=[^ ]*'
sudo journalctl -u nginx -n 100 --no-pager

The compiled-in path may differ from a path overridden by configuration. In containers, Nginx logs may be directed to standard error and collected by the container runtime.

Common Log Messages and Their Meaning

For reliable troubleshooting, correlate Nginx error logs, systemd messages, application logs and kernel events by timestamp. The first error that appears before the outage is often more useful than the later messages produced during recovery attempts.

7. Check systemd Restart Behavior Safely

Systemd can automatically restart a service after certain failures. For a long-running service, Restart=on-failure is a common recovery policy, but automatic restarts should not replace root-cause analysis.

Inspect the effective service configuration:

systemctl cat nginx
systemctl show nginx -p Restart -p RestartUSec -p StartLimitIntervalUSec -p StartLimitBurst

On many systems, Nginx’s packaged service already includes suitable service-management settings. Review the existing unit before creating an override.

When an Override Is Appropriate

If your service policy needs adjustment, create a systemd drop-in rather than editing the vendor-supplied unit directly:

sudo systemctl edit nginx

For example, a long-running service might use the following policy if it fits the existing unit and operational requirements:

[Service]
Restart=on-failure
RestartSec=5s

This is an example, not a universal recommendation to change your current settings. Save the override, then apply and inspect it:

sudo systemctl daemon-reload
systemctl show nginx -p Restart -p RestartUSec

Before relying on automatic recovery, confirm that the configuration is valid and the underlying issue has been addressed. Systemd applies start-rate limits, so repeated failures can eventually leave the service in a failed state rather than restarting indefinitely.

Avoid restart loops. Repeatedly restarting Nginx when a certificate is missing, a port is occupied or the configuration is invalid can create more noise without restoring service. Monitor failures, preserve logs and alert an administrator when restarts repeat.

8. Maintenance Practices That Prevent Recurring Nginx Failures

Once the immediate issue is fixed, use the incident to reduce the likelihood of another outage.

• Validate changes: Run nginx -t before applying configuration updates.
• Back up configuration: Keep versioned copies of working configuration files and document changes.
• Monitor resource usage: Track memory, CPU, disk space and application processes.
• Monitor certificates: Alert before certificates expire and verify renewal workflows.
• Review application health: Monitor PHP-FPM or other upstream services, not just Nginx.
• Rotate logs: Make sure logs do not fill the filesystem and that important incident evidence is retained.
• Test upgrades: Review module compatibility and use staging when possible.
• Set meaningful alerts: Notify administrators about service failures, repeated restarts, OOM events and sustained upstream errors.

Monitoring should capture both service availability and user-facing results. A running Nginx process does not guarantee that the website’s backend is healthy. A compromised or malware-affected site can also produce intermittent failures that look like a server problem — see our guide on identifying and safely replacing a cracked or nulled WordPress plugin if the instability started after a plugin or theme change.

Final Checklist: What to Do When Nginx Keeps Stopping

1. Run sudo nginx -t and fix any reported configuration error.
2. Run sudo systemctl status nginx --no-pager -l to check whether the service is running or failed.
3. Review sudo journalctl -u nginx -n 100 --no-pager for recent failures.
4. Use sudo ss -ltnp to check for port conflicts.
5. Review kernel logs for OOM kills and other system-level errors.
6. Check Nginx’s error log for certificate, permission and upstream failures.
7. If Nginx is running, investigate 502/504 responses and the upstream application instead of blindly restarting Nginx.
8. After fixing the cause, test the configuration and restart or reload the service only as appropriate.
9. Configure monitoring and safe recovery policies, and investigate repeated failures rather than hiding them with automatic restarts.

Conclusion

If Nginx keeps stopping, the fastest way to find the cause is to combine a configuration test, service status, journal output, port inspection and kernel-log review. These checks help distinguish startup failures from memory-related termination, port conflicts, certificate problems and upstream application failures.

Once you identify the relevant error, apply the smallest safe correction, validate the configuration and verify that the website is responding normally. Systemd restart policies and monitoring can improve recovery, but they work best when paired with a clear diagnosis and a lasting fix.

Frequently Asked Questions

Why does Nginx keep stopping after a restart?

A restart may temporarily restore service without fixing the underlying cause. Run nginx -t, inspect systemctl status nginx, and review the service journal to identify whether a configuration error, missing file, port conflict or resource issue is recurring.

Can low RAM cause Nginx to stop?

Yes. Under severe memory pressure, the Linux kernel may terminate Nginx or another process. Confirm this through kernel logs before increasing memory or changing Nginx settings.

Why does my website show 502 while Nginx is running?

A 502 usually indicates that Nginx could not obtain a valid response from an upstream service. Check the Nginx error log, backend service status, socket or port configuration, and application logs.

Should I configure Nginx to restart automatically?

Systemd can restart Nginx after certain failures, but automatic recovery should not conceal recurring configuration, resource or dependency problems. Use a suitable restart policy with monitoring, alerts and start-rate limits.

Where are Nginx error logs stored?

A common location is /var/log/nginx/error.log, but the path depends on your installation and configuration. Check the configured error_log directive, the output of nginx -V, and journalctl -u nginx.

Official Documentation

• Nginx command-line parameters and configuration testing
• Nginx official documentation
• Nginx logging and error-log configuration
• systemd service restart policies