Flow chart of nginx+apache+uvcorn infrastructure

In an NGINX + Apache + Uvicorn architecture, NGINX acts as the public-facing reverse proxy and load balancer. It handles static files and SSL/TLS termination, passing dynamic requests to Apache, which then proxies them to Uvicorn for Python/ASGI processing. [1, 2, 3, 4, 5]

The traffic routing process follows this structured pipeline: [1]

1. Client & NGINX (Reverse Proxy)

• The Request: An HTTP/HTTPS request from a client hits your server.
• NGINX: Receives the traffic, manages SSL termination, serves static assets (images, CSS), and applies security rules.
• Routing Rule: NGINX matches location blocks (e.g., matching /api) and forwards dynamic requests to the Apache HTTP Server. [1, 2, 3, 4, 5]

2. Apache (Web Server)

• Request Handling: Apache receives the request, potentially processing .htaccess rules, basic authentication, or PHP modules if required.
• Proxy Module: Apache is configured with mod_proxy (usually via ProxyPass directives) to tunnel the incoming request over the network to the Uvicorn ASGI server.
• Connection: This is usually done via a TCP connection or a UNIX domain socket. [1, 2, 3]

3. Uvicorn (ASGI Application Server)

• ASGI Interface: Uvicorn receives the request and translates the raw HTTP connection into Python-native standard ASGI events.
• Worker Processes: The Uvicorn worker process parses the application logic and returns the response back up the chain.
• Application: Executes the Python framework (e.g., FastAPI, Starlette) and sends the response back through Apache and NGINX to the client. [1, 2, 3]

Visual Architecture Flow

The complete request pipeline flows in this sequence:

text

[ Client (Browser / App) ]
           │
           ▼
[ NGINX (Reverse Proxy / Load Balancer) ]  ───┐ (Serves static files)
           │                                 │
  (Proxies dynamic traffic)                  │
           │                                 │
           ▼                                 │
[ Apache HTTP Server (Module mod_proxy) ]    │
           │                                 │
  (Proxies to Python App)                    │
           │                                 │
           ▼                                 │
 [ Uvicorn (ASGI Application Server) ]       │
           │                                 │
           ▼                                 │
 [ Python Framework (FastAPI/Starlette) ]    │
           │                                 │
           └─────────◄───◄───◄───◄───────────┘ 

== Version 2

Here’s a clean flow chart of a typical Nginx + Apache + Uvicorn setup (often used when Nginx is the front proxy, Apache handles legacy/static or PHP, and Uvicorn serves a Python ASGI app like FastAPI).

How it works (simple breakdown)

1. Client → Nginx

• Nginx is the entry point.
• Handles SSL termination, routing, and load balancing.

2. Nginx routes traffic based on rules

• /api → Uvicorn (Python ASGI app)
• / or .php → Apache

3. Apache path

• Serves:
  • PHP apps (WordPress, legacy systems)
  • Static files (if configured)
• Uses modules like mod_php, mod_wsgi, etc.

4. Uvicorn path

• Runs Python ASGI app:
  • FastAPI
  • Starlette
  • Django (ASGI mode)
• Handles async requests efficiently

5. Response flows back

• Uvicorn/Apache → Nginx → Client

---

Common real-world variant

Sometimes Apache is behind Nginx only for legacy reasons:

Client → Nginx → (Apache for PHP) + (Uvicorn for Python APIs)

---