🐳Docker Learning Hub
Lesson 19 • Reverse proxy with Nginx
Lesson 19

Reverse proxy with Nginx

This page explains how one front-facing service can receive browser traffic and then forward requests to the correct container behind the scenes.

What it does

Nginx receives requests first, then forwards them to the right app or service based on path, host, or rule.

Why it helps

It centralizes domains, SSL, routing, and port management so app containers can stay focused on application logic.

Common pattern

Browser traffic often hits Nginx on port 80 or 443, and Nginx forwards traffic to internal containers on their private ports.

Single app routing

Browser
Nginx
App container

Split routing

/ goes to frontend
/api goes to backend
One domain, multiple services

Why not expose every container directly

  • Port handling becomes messy fast.
  • Domain setup becomes harder to organize.
  • SSL setup gets repeated in multiple places.
  • Traffic flow becomes less predictable.

Where Nginx adds value

  • Routing requests to frontend or backend.
  • Serving static files efficiently.
  • Acting as the public web entry point.
  • Handling HTTPS before traffic reaches the app.

Simple proxy idea

Browser -> nginx:80 nginx -> frontend:3000 nginx -> backend:5000

The user only sees the public web address. Internal container ports remain hidden behind the proxy.

Beginner confusion to avoid

Nginx is not replacing your backend. It is standing in front of it, guiding incoming traffic to the correct destination.

Reverse proxy memory guide

Nginx is the front desk
Requests arrive there first.
Your app stays behind it
The app does not need to directly manage every public traffic concern.
Routing becomes cleaner
One domain can serve multiple containers.
Public ports and internal ports stay separated
That makes the overall setup easier to control.

Next page: Lesson 20 brings frontend, backend, and database together into one full stack Docker workflow.