Which Port Is Nginx Listening On? Check and Change It Safely

Nginx commonly serves HTTP on TCP port 80 and HTTPS on TCP port 443, but those conventions don’t tell you what a particular server is actually listening on. The active listen directives and the running system do.

If a site won’t load, start by checking both: what Nginx is configured to do, and which ports are open right now.

Find the configured listeners

Nginx’s listen directive appears inside a server block. For example, this configures an HTTP listener on port 80:

server {
    listen 80;
    server_name example.com;
}

A TLS-enabled server block might use port 443:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /path/to/certificate.pem;
    ssl_certificate_key /path/to/private-key.pem;
}

The certificate paths here are placeholders; use the paths from your certificate setup. A site could instead listen on a custom port, or bind to a particular IP address.

To inspect the configuration Nginx actually loads—including included files—run:

sudo nginx -T | grep -nE '^[[:space:]]*listen[[:space:]]'

This is more reliable than guessing which configuration file to edit. The full nginx -T output can contain internal configuration details, so review it before sharing it publicly.

For more detail on what the configuration test and dump show, see this guide to checking an Nginx configuration.

Check what is listening now

Configuration shows what Nginx is set up to load. The operating system’s socket list shows what is listening at the moment.

On Linux, run:

sudo ss -ltnp

Look for local addresses ending in the expected port, such as :80, :443, or a custom port. The options request listening TCP sockets and, with sufficient permissions, process details.

An address like 0.0.0.0:80 means the service is listening on port 80 on all local IPv4 interfaces. [::]:80 indicates an IPv6 wildcard listener; depending on system settings, it may also accept IPv4 connections.

If your expected port is absent, check whether Nginx is running and whether its configuration loaded successfully. On a system using systemd, you can inspect the service with:

systemctl status nginx

Port 80 is the conventional HTTP port, but a listener alone doesn’t guarantee that a remote client can reach it. For background on the convention, see what port 80 is used for.

Change an Nginx listening port

First identify the relevant server block in the loaded configuration. To move an HTTP listener from port 80 to port 8080, change its directive to:

listen 8080;

If Nginx should stop accepting connections on port 80, replace or remove the old listener. Adding listen 8080; without removing listen 80; may leave both ports active—that can be intentional, so check the complete configuration rather than assuming one directive replaces another.

Before applying the change, test the configuration:

sudo nginx -t

If the test fails, don’t reload. Fix the reported issue and test again. Once it passes, reload Nginx on a systemd-managed Linux host:

sudo systemctl reload nginx

Then check the sockets again:

sudo ss -ltnp

A reload asks Nginx to apply the configuration without the planned interruption of a full restart. On systems that don’t use systemd, use the service manager or reload procedure for that installation.

If clients still can’t connect

Troubleshoot the path in layers instead of changing ports at random:

• Configuration: Does sudo nginx -T show the intended listen directive? Does sudo nginx -t pass?
• Service: Is Nginx running, and did it successfully load the configuration?
• Port conflict: Is another process already listening on the address and port? Check sudo ss -ltnp.
• Firewall or network: A local listener can exist while a host firewall, cloud firewall, router, or upstream network blocks remote traffic.
• Containers: Check both the port Nginx listens on inside the container and the host port published to clients. They can differ, so changing only one side may not fix the connection.

The useful distinction is simple: the listen directives describe Nginx’s configured endpoints, while ss shows current listening sockets. Check both, validate changes before reloading, and investigate firewalls or port mappings if the listener exists but remains unreachable.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.