How do you configure Nginx as an API gateway?
Learn how to configure Nginx as an API gateway with upstream routing, proxy_pass, TLS termination, rate limiting, and load balancing, plus example config.
Expected Interview Answer
You configure Nginx as an API gateway by defining upstream backend pools and using location blocks to route, proxy, and load-balance incoming API requests to the right microservice, while centralizing concerns like TLS termination, rate limiting, header rewriting, and authentication at the edge.
The core building blocks are upstream blocks (which group backend servers), server blocks (which listen on a port/hostname), and location blocks (which match request paths and forward them with proxy_pass). At the gateway you terminate TLS once, apply limit_req and limit_conn for throttling, set proxy headers (X-Forwarded-For, Host), enable caching where safe, and optionally use auth_request to delegate authentication to a separate service. This gives every microservice a single, uniform entry point instead of exposing each service directly.
- Single entry point for many microservices
- Centralized TLS termination and security
- Built-in load balancing and health checks
- Path-based routing to different backends
- Rate limiting and request throttling at the edge
- Header rewriting and response caching
AI Mentor Explanation
An API gateway is like the captain positioning fielders and deciding which bowler faces each batter. Every ball (request) is routed to the specialist best suited to it — spinner, pacer, or all-rounder (backend service). The captain also enforces the over limit (rate limiting) and reviews decisions (auth) so the eleven players work as one coordinated unit instead of chaotically.
Step-by-Step Explanation
Step 1
Define upstreams
Create an upstream block per backend service, listing each service instance's host and port for load balancing.
Step 2
Terminate TLS
Configure a server block to listen on 443 with ssl_certificate and ssl_certificate_key so encryption is handled once at the edge.
Step 3
Route by path
Add location blocks matching URL prefixes (for example /users/ and /orders/) and forward each with proxy_pass to the matching upstream.
Step 4
Set proxy headers
Pass Host, X-Real-IP, and X-Forwarded-For so backends still see the original client details.
Step 5
Apply rate limiting
Define limit_req_zone and apply limit_req in the relevant locations to throttle abusive or excessive traffic.
Step 6
Add auth and caching
Optionally use auth_request to delegate authentication and proxy_cache to cache safe responses at the gateway.
What Interviewer Expects
- Understanding of upstream, server, and location blocks
- Knowledge of proxy_pass and header forwarding
- Awareness of TLS termination at the edge
- Rate limiting with limit_req_zone
- Reasoning about centralizing cross-cutting concerns
Common Mistakes
- Forgetting to forward Host and X-Forwarded-For headers to backends
- Exposing backend services directly instead of routing through the gateway
- Confusing an API gateway with a plain reverse proxy and ignoring rate limiting or auth
- Not terminating TLS once at the edge and duplicating certs per service
- Hardcoding backend IPs instead of using upstream blocks
Best Answer (HR Friendly)
“An API gateway with Nginx is a single front door for many small services. Nginx checks and secures each request once, then sends it to the correct service behind the scenes, so users get one simple, safe entry point instead of dealing with each service separately.”
Code Example
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
upstream users_service {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
}
upstream orders_service {
server 10.0.0.21:8080;
}
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /etc/nginx/certs/api.crt;
ssl_certificate_key /etc/nginx/certs/api.key;
location /users/ {
limit_req zone=api burst=20 nodelay;
proxy_pass http://users_service;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /orders/ {
proxy_pass http://orders_service;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}Follow-up Questions
- How does an API gateway differ from a plain reverse proxy?
- How would you add authentication at the gateway with auth_request?
- How do you implement rate limiting per client with limit_req_zone?
- How can Nginx do canary or blue-green routing between service versions?
- What are the trade-offs of Nginx versus a dedicated gateway like Kong?
MCQ Practice
1. Which Nginx block groups multiple backend service instances for load balancing?
An upstream block defines a named group of backend servers that proxy_pass can balance requests across.
2. Which directive forwards a request from a location block to a backend?
proxy_pass sends the matched request to the specified upstream or backend URL.
3. Which pair of directives is used to enforce request rate limiting?
limit_req_zone defines a shared memory zone and rate, and limit_req applies it to a location.
Flash Cards
What does an Nginx upstream block do? — It defines a named pool of backend servers that Nginx load-balances requests across via proxy_pass.
Where should TLS be terminated in a gateway setup? — Once at the edge in the gateway's server block, so backends can stay on plain HTTP internally.
Which header preserves the original client IP? — X-Forwarded-For (set with $proxy_add_x_forwarded_for), plus X-Real-IP for the immediate client.
How does Nginx route by path? — location blocks match URL prefixes and each forwards to a different upstream with proxy_pass.