Nginx Reverse Proxy Setup Guide for Node.js, Docker, and SSL

Overview

If you are configuring Nginx as a reverse proxy, you are usually solving a small set of recurring problems: exposing an application on standard web ports, terminating SSL, forwarding traffic to an internal app process, and keeping hostnames, headers, and timeouts consistent. Whether your app runs directly on the server or inside a container, the core pattern stays the same.

At a high level, Nginx sits in front of your application and accepts requests on port 80 or 443. It then forwards those requests to an upstream service such as a Node.js app listening on localhost:3000 or a Docker container exposed on an internal network. In many production setups, Nginx also handles redirects from HTTP to HTTPS, serves static assets, and standardizes logging.

Use this guide as a pre-deployment checklist for these common goals:

• Expose a Node.js app without binding it directly to the public internet
• Route a domain or subdomain to an internal service
• Enable SSL at the proxy layer
• Proxy to a Docker container or Compose service
• Reduce avoidable deployment and troubleshooting issues

Before you begin, confirm these assumptions:

• Your DNS already points the domain or subdomain to the target server
• Nginx is installed and running on the host machine
• Your app is reachable locally, even if it is not yet public
• You have shell access and permission to edit Nginx configuration files

If DNS is still in progress, it helps to verify that first with a propagation workflow. If needed, see Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types and DNS Propagation Checker Guide: How to Verify Record Changes and Troubleshoot Delays.

Checklist by scenario

This section gives you a reusable checklist by deployment pattern. Start with the scenario closest to your setup, then adapt the examples to your server paths, domains, and ports.

Scenario 1: Nginx for Node.js on a single server

This is the most common pattern for small production apps: a Node.js process listens on a local port and Nginx proxies public traffic to it.

Checklist:

1. Make sure your Node.js app is running on a fixed internal port, such as 3000.
2. Bind the app to localhost or the server interface you intend to use internally.
3. Create an Nginx server block for your domain.
4. Forward requests with proxy_pass to the app port.
5. Pass through standard proxy headers.
6. Test the config before reloading Nginx.

A basic HTTP configuration might look like this:

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

This gives you a practical baseline for nginx for node.js. If your app uses WebSockets, the upgrade-related headers matter. If it does not, they are still commonly included in Node-oriented setups because they avoid future surprises.

Operationally, also make sure your process stays running under a process manager or service definition. The reverse proxy only helps if the upstream app is stable.

Scenario 2: Add SSL and redirect HTTP to HTTPS

Once your domain resolves correctly and your server can receive traffic on ports 80 and 443, you can layer in SSL. The exact certificate workflow depends on your environment, but the Nginx structure remains consistent.

Checklist:

1. Issue or install a certificate for the target hostname.
2. Create an HTTP server block that redirects to HTTPS.
3. Create an HTTPS server block with certificate paths.
4. Keep the same proxy headers in the SSL-enabled block.
5. Reload Nginx and test both HTTP and HTTPS responses.

Example structure:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

For most teams, a good nginx ssl setup means keeping certificate management simple, using clean redirects, and verifying that the app receives the correct forwarded protocol. Many frameworks rely on X-Forwarded-Proto to understand whether the original request was secure.

Scenario 3: Nginx Docker reverse proxy

If the application runs in Docker, Nginx can still live on the host or inside another container. For a straightforward setup, many teams run Nginx on the host and proxy to a published container port. More container-native setups place both services on the same Docker network.

Checklist:

1. Confirm the container is actually reachable from the host or Nginx container.
2. Decide whether Nginx will proxy to 127.0.0.1:published_port or a Docker service name on a shared network.
3. Avoid exposing unnecessary app ports publicly if Nginx is the intended entry point.
4. Keep container restarts and name changes in mind when choosing upstream references.
5. Retest after every Compose or image change.

Host-based Nginx example:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Shared-network example, where Nginx can resolve the service name:

location / {
    proxy_pass http://app:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

For containerized applications, stability often depends more on networking clarity than on Nginx syntax. If the proxy cannot reach the upstream service, the config can look correct while all requests still fail. For a deeper container deployment workflow, see Docker Deployment Tutorial for Small Production Apps.

Scenario 4: Multiple apps on one server

One of the strongest reasons to configure Nginx server blocks well is to host several services behind one public IP. You might route api.example.com to a Node API, app.example.com to a frontend service, and the apex domain to a marketing site.

Checklist:

1. Create a separate server block per domain or subdomain.
2. Use explicit server_name values.
3. Point each block to the correct upstream port or service.
4. Keep logs separate if you expect independent troubleshooting.
5. Document the mapping between domain, app, port, and deployment path.

This is where Nginx becomes part of your broader hosting and infrastructure discipline. If DNS records are still being wired up for subdomains, related guides like How to Connect a Domain to Vercel Without DNS Errors or How to Connect a Domain to Netlify: DNS Records, SSL, and Common Fixes can help for mixed hosting environments.

What to double-check

Before you call the deployment finished, verify the parts that most often cause quiet failures. This is the section worth revisiting every time your app, domain, SSL workflow, or container layout changes.

1. DNS points where you think it points

If the domain does not resolve to the intended server, Nginx will never see the request. Confirm the correct A, AAAA, or CNAME records are in place and that old records are removed when appropriate. In migrations, stale DNS is often mistaken for an Nginx issue.

2. The upstream app is reachable locally

Test the app directly from the server before testing through Nginx. For example, use curl http://127.0.0.1:3000 or the equivalent internal address. If that fails, fix the application or container networking first.

3. Nginx config syntax is valid

Always test the configuration before reload. A simple syntax mistake can take down unrelated sites on the same server. The habit matters more than the command itself: validate, then reload.

4. Forwarded headers match app expectations

Many applications need the original host, client IP, and protocol. Missing or inconsistent headers can break session handling, redirects, callback URLs, rate limiting, and audit logs.

5. SSL paths and hostnames match

Certificate and key paths must be correct, readable by the service, and associated with the hostnames in your server block. If you add a new subdomain later, make sure the certificate coverage still matches the Nginx configuration.

6. Timeouts and body size fit your app

File uploads, slow API operations, and long-lived connections may need tuning. If requests fail only in production and only through the proxy, check whether default limits are too strict for your application behavior.

7. Logs are enabled and easy to find

When troubleshooting, access logs and error logs save time. A well-placed log path is often more useful than adding complexity to the configuration. Keep enough separation to identify which app or vhost is producing errors.

8. Firewall rules allow intended traffic

Your app may be healthy and Nginx may be correct, but public traffic still fails if ports 80 and 443 are blocked. In cloud environments, also check security groups or equivalent network policy layers.

Common mistakes

Most reverse proxy issues are not exotic. They are usually small mismatches between DNS, app ports, headers, certificates, and reload steps. Here are the mistakes that show up repeatedly.

Proxying to the wrong port

This is the most common issue in both Node.js and Docker setups. An app may have moved from port 3000 to 8080, or a container may publish a different host port than expected. Keep a single source of truth for service-to-port mappings.

Using the public domain as the upstream target

In many cases, Nginx should proxy to a local or internal address, not back out through the public hostname. Using the public domain can create loops, unnecessary external dependency, or confusing failures.

Forgetting the Host header

Without proxy_set_header Host $host;, some applications will generate incorrect redirects or fail virtual host logic. This small directive carries a lot of practical weight.

Skipping HTTP to HTTPS redirects

If you intend the site to be secure by default, add a dedicated redirect block. Leaving both HTTP and HTTPS active without a clear redirect policy can create inconsistent behavior and duplicate entry paths.

Reloading without validation

Fast edits in production invite mistakes. The safe routine is simple: edit, test config, then reload. Treat this as part of the deployment checklist, not an optional extra.

Assuming Docker networking works like localhost

Inside containers, 127.0.0.1 refers to the container itself, not the host or another service. This often causes confusion in nginx docker reverse proxy setups. Be explicit about whether the upstream is a host port or a service on the same Docker network.

Not documenting the final working state

A reverse proxy setup that works today becomes a mystery six months later if nobody records the domain, SSL source, upstream address, container name, and reload procedure. Even a short runbook prevents repeated rediscovery.

If your deployment workflow is automated, it is worth connecting this proxy checklist with CI/CD practices. A practical next read is GitHub Actions Deployment Guide: Build, Test, and Deploy Web Apps Reliably.

When to revisit

A reverse proxy configuration should not be treated as a one-time task. Revisit it whenever the inputs around it change. That includes app architecture, domains, SSL management, and deployment workflow.

Review your Nginx setup when:

• You launch a new app, subdomain, or environment
• You move a service into or out of Docker
• You change app ports, process managers, or internal networking
• You add SSL for the first time or replace certificate automation
• You migrate DNS providers or update DNS records
• You place a CDN or additional proxy layer in front of the server
• You add file uploads, WebSockets, or long-running API requests
• You update deployment workflows before a busy release cycle

A simple action plan helps keep this evergreen:

1. List each public hostname and the service it should reach.
2. Confirm DNS resolves to the intended server.
3. Confirm the app is reachable internally.
4. Review Nginx server blocks, upstream targets, and SSL coverage.
5. Test configuration and reload safely.
6. Verify redirects, headers, and logs with real requests.
7. Document the working state for the next migration or incident.

If you maintain mail records on the same domain, keep web and email DNS changes coordinated so one fix does not break another part of the stack. For that side of domain infrastructure, see SPF, DKIM, and DMARC Setup Guide for Google Workspace, Microsoft 365, and Custom Domains.

The practical takeaway is simple: a good Nginx reverse proxy setup is less about clever configuration and more about disciplined checks. When Node.js apps, Docker networking, and SSL are all changing around you, a repeatable checklist is what keeps the edge of your infrastructure calm.