跪拜 Guibai
← All articles
Frontend · Backend · Nginx

Docker Nginx Reverse Proxy to Node, Step by Step

By 东风破_ ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Running Nginx in Docker with a reverse proxy to a local Node process is the smallest deployable unit that resembles a real production topology. Understanding the port-mapping and volume-mount mechanics here prevents the most common Docker networking mistakes when moving from localhost-only development to containerized services.

Summary

A Node.js Express app listens on port 1314. Instead of exposing that port directly, an Nginx container listens on port 80 and forwards traffic to the Node service via proxy_pass. Docker's port mapping (-p 80:80) routes host traffic into the container, and a volume mount (-v) injects the nginx.conf that defines the forwarding rule. The Node process runs on the host and is reachable from the container through host.docker.internal.

The result is a clean separation: Nginx handles request entry and routing, Node handles business logic. Users never see the backend port, and the setup mirrors a minimal production deployment pattern where a reverse proxy sits in front of application services.

Common Docker lifecycle commands — ps, stop, rm, rmi — round out the workflow, making the whole stack manageable from the terminal.

Takeaways
An Nginx container on port 80 can proxy requests to a Node service running on the host at port 1314 via host.docker.internal.
Docker's -p flag maps a host port to a container port; -p 80:80 sends all localhost:80 traffic into the Nginx container.
The -v flag mounts a local nginx.conf into the container at /etc/nginx/nginx.conf, so configuration changes on the host take effect inside the container without rebuilding the image.
proxy_pass in the Nginx location block is the single line that forwards incoming requests to the backend service.
Users never see the backend port; the reverse proxy hides the internal service topology behind a standard HTTP port.
Docker ps, stop, rm, and rmi commands provide basic lifecycle management for containers and images.
Conclusions

The tutorial uses host.docker.internal to let a container reach a service running directly on the host, which is a pragmatic bridge for developers not yet ready to containerize every service but still wanting to practice reverse-proxy patterns.

Mounting a single config file instead of baking it into a custom image keeps the setup trivial to iterate on — change the file, restart the container, and the new routing takes effect immediately.

Concepts & terms
Reverse Proxy
A server that sits in front of backend services and forwards client requests to them, hiding the backend's actual address and port from the client.
Docker Port Mapping (-p)
A Docker run flag that binds a port on the host machine to a port inside the container, allowing external traffic to reach the containerized service.
Docker Volume Mount (-v)
A Docker run flag that maps a file or directory from the host filesystem into the container, letting the container read host files — commonly used to inject configuration without rebuilding the image.
host.docker.internal
A special DNS name that resolves to the host machine's IP address from inside a Docker container, enabling containers to reach services running directly on the host.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗