Recommended Free Tools
An nginx failure on port 443 is usually one of two problems: error 98 means another process already owns the port, while error 13 means nginx lacks permission to bind a privileged port. Read the exact error, identify the process or policy blocking the socket, correct that cause, then run sudo nginx -t before restarting.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Read the error before changing anything
The wording in the error log determines the troubleshooting path. These messages look similar but require different fixes:
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Message | Meaning | First action |
|---|---|---|
bind() to 0.0.0.0:443 failed (98: Address already in use) |
Another socket is already listening on TCP port 443, or a second nginx instance is trying to claim it. | Find the listener with ss or lsof. |
bind() to 0.0.0.0:443 failed (13: Permission denied) |
The process does not have permission to bind a port below 1024, or a security policy is denying the operation. | Check how nginx is started, then check capabilities and mandatory access controls. |
Error starting userland proxy: listen tcp4 0.0.0.0:443: bind: address already in use |
A container runtime cannot publish host port 443 because another process has it. | Inspect host listeners and container port mappings. |
Do not treat an error 98 as a certificate problem. TLS certificates are loaded after the listening socket is created; a certificate change cannot free an occupied port. Conversely, changing ports will not solve error 13 if the service is still trying to use a privileged port without the required privilege.
Fix error 98: another process owns port 443
1. Identify the listener
Run one of these commands on the host where nginx is failing:
#1 Best Overall
sudo ss -tlnp | grep ':443'
or:
sudo lsof -i :443
The output should show the local address, PID and program name. A listener on 0.0.0.0:443 accepts connections on every IPv4 interface; a listener on a specific address can still conflict with nginx if nginx is configured for that same address. Record the PID before stopping anything.
If neither command returns a process, check both IPv4 and IPv6 output, remove the grep filter temporarily, and repeat while the failing service is being started. A short-lived process or a container proxy can release the port between checks.
2. Check for a second nginx instance
It is common to start nginx manually while a system service is already running. Inspect the processes and service state:
ps aux | grep nginx
sudo systemctl status nginx
If two master processes appear, use the service manager to keep one instance and stop the other. Do not kill worker processes one by one while leaving the master running; the master can recreate them or continue holding the socket. If nginx was launched from a custom prefix, locate its master process and stop it using that installation’s control method, then start only the intended systemd service.
3. Find the service that should not be on 443
Typical owners include a second web server, a reverse-proxy add-on, a container, or a self-hosted application with its own HTTPS endpoint. The process name from ss or lsof is more reliable than guessing from the symptom.
- If the service is unnecessary, stop it and disable its automatic start using its normal service or application controls.
- If it is required, move that service to another host port and let nginx proxy to it.
- If a container publishes
443:443, change the host side of the mapping, for example to8443:443, then reload the container. - If an appliance or add-on manages the port, stop add-ons one at a time and recheck the listener so you can identify the exact conflict.
Stopping an unknown PID is risky. Confirm the executable and its role first; interrupting a database, management interface or monitoring service can create a separate outage.
4. Check Docker and other container runtimes
A container runtime reports the conflict as a “userland proxy” or “listen tcp4” error when it cannot publish host port 443. Check running containers and their published ports with the runtime’s normal inspection command. Then either stop the container that owns 443 or change its host mapping. A mapping such as 8443:443 leaves the application listening on 443 inside the container while exposing it on 8443 on the host.
In a reverse-proxy design, nginx listens publicly on 443 and forwards to the container’s high host port or private network address. Update the nginx proxy_pass target only after the container is reachable on the new port, and test the configuration before restarting.
5. Check nginx configuration for duplicate listeners
Even with no other application, nginx can fail when enabled virtual hosts contain conflicting listen 443 declarations or when an old file is included unexpectedly. Search the complete configuration tree, including files pulled in by include directives:
sudo nginx -T 2>/dev/null | grep -n "listen .*443"
nginx -T prints the assembled configuration, so it exposes files that are not obvious from the main configuration file. Look for duplicate server blocks, stale backup files that are still included, and a second configuration prefix. Multiple HTTPS server blocks are valid when they share a socket and differ by server name, but each must use compatible listen parameters.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallRemove or disable obsolete files rather than deleting them blindly. If a deployment tool recreates them, correct the template or the enabled-site link so the conflict does not return at the next reload.
Fix error 13: permission denied on a privileged port
TCP ports below 1024 are privileged on typical Linux systems. The usual nginx model is a root-owned master process that opens the socket, followed by worker processes running as a less-privileged account. Error 13 indicates that this model is not being used successfully, or that another security control is denying the bind.
Confirm how nginx starts
Check the service definition and the effective process user. A custom systemd unit with a non-root User= setting, a manually launched binary, or a rootless container can all produce this error. The master process must have permission to bind 443 even if workers later drop privileges.
Starting the distribution-provided service through its service manager normally supplies the expected privilege transition:
sudo systemctl start nginx
sudo systemctl status nginx
Do not make every worker run as root just to hide the error. Keep the master privileged only for socket setup and run request workers under the account configured by nginx.
Grant a bind capability when a non-root master is intentional
Linux can grant the nginx executable the CAP_NET_BIND_SERVICE capability so it can open ports below 1024 without a root process. A commonly used command is:
sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx
The binary path varies by distribution and installation method; find the actual executable before applying the capability. Capabilities can be lost when a package upgrade replaces the binary, so verify them after upgrades and document the choice for whoever maintains the host. Granting a capability to a network-facing executable changes its security profile; use the service manager’s standard root-master arrangement unless there is a clear reason not to.
Rootless Docker or Podman
A rootless container generally cannot publish a host port below 1024. Publish a port above 1024, such as 8443, and place a privileged host-level reverse proxy in front of it, or use the container runtime’s documented privileged-port mechanism. Changing only the container’s internal application port does not help if the host mapping still requests 443:443.
SELinux and AppArmor policies
Mandatory access controls can return permission denied even when the Unix user appears correct. On systems using SELinux or AppArmor, inspect the security audit or denial logs around the failed start and verify that the nginx profile is allowed to create a listening web socket. If a policy intentionally restricts the service, adjust the policy through the distribution’s supported administration tools rather than disabling enforcement globally. The exact commands and port labels differ by distribution, so use the policy documentation for that system.
Configure HTTPS correctly on modern nginx
An HTTPS server block should put the TLS parameter on the listen directive:
Best Value
server {
listen 443 ssl;
server_name example.test;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# location blocks and proxy settings go here
}
The standalone ssl on; directive is obsolete: it became obsolete in nginx 1.15.0 and was removed in nginx 1.25.1. On current releases, replace it with listen 443 ssl;. Leaving ssl on; in an old configuration can cause a configuration-test failure after an upgrade, which is separate from a socket conflict but must be corrected before nginx can start.
Since nginx 1.11.0, ssl_certificate may be specified more than once to load certificates of different types, such as RSA and ECDSA. This does not require separate 443 sockets; the server blocks still share the listening address. Keep the certificate and key paths readable by the nginx master and protected from ordinary users.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Listen parameters apply to the socket as a whole. If several server blocks share 443, keep their listen options consistent; a parameter on one block can affect the shared socket and produce confusing behaviour in another block.
A safe recovery sequence
Use this order after correcting the underlying cause:
- Capture the exact error from the nginx log or service status, including the numeric code.
- For error 98, identify the listener with
sudo ss -tlnp | grep ':443'orsudo lsof -i :443, then stop or reconfigure the owning service. - For error 13, confirm the master process privilege, container mode and security-policy denials. Use the normal root-master service model or deliberately grant
CAP_NET_BIND_SERVICE. - Print the assembled nginx configuration and inspect every 443 listener:
sudo nginx -T. - Correct obsolete directives, duplicate includes, certificate paths or listen parameters.
- Validate without interrupting the running service:
sudo nginx -t. Do not restart if this test fails. - Apply the validated configuration:
sudo systemctl restart nginx. A reload is preferable for a configuration-only change when nginx is already healthy:sudo systemctl reload nginx. - Confirm the service state and listener again with
sudo systemctl status nginxandsudo ss -tlnp | grep ':443', then make a local HTTPS request to verify the expected virtual host responds.
When the port still will not bind
The listener returns after you stop it
An enabled service, container restart policy, supervisor or appliance may immediately reclaim 443. Watch the process name and PID while stopping it, then disable the responsible auto-restart mechanism or change its configured port. Rebooting without changing that owner usually reproduces the same failure.
No listener is visible, but nginx reports error 98
Check for a second network namespace or container, multiple nginx installations, and a stale process that appears only during startup. Compare the binary path in the process list with the binary tested by nginx -t. Also inspect both IPv4 and IPv6 sockets and run the listener command immediately after the failure.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The test passes but restart fails
nginx -t checks configuration syntax and referenced files; it does not guarantee that another service will leave 443 free at restart time. Re-run the listener check, inspect the system journal for the failing unit, and verify that systemd is starting the same nginx installation whose configuration you tested.
Changing 443 to another port appears to fix nginx, but clients cannot connect
That is expected if clients still use the standard HTTPS port. A high port is a diagnostic or internal-backend solution, not a public replacement unless users are directed to the new port or another proxy terminates HTTPS on 443.
Quick Recap
Quick decision checklist
- Error 98: find the owner of 443; stop it, move it, or proxy to it.
- Error 13: restore the root-master privilege model, grant the narrowly scoped bind capability, or move a rootless container above port 1024.
- Duplicate configuration: inspect
nginx -Tfor every includedlisten 443line. - Modern TLS syntax: use
listen 443 ssl;; removessl on;on nginx versions where it is obsolete or removed. - Before any restart: run
sudo nginx -t, then restart or reload only after it reports a successful test.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
