> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Summary

> NGINX configuration guide covering server blocks, HTTP to HTTPS redirects, rewrites, reverse proxying, upstream load balancing, and caching best practices

This lesson consolidates the most important NGINX concepts covered in this module. Use this as a quick reference when configuring server blocks, redirects, proxying, load balancing, and caching.

## Server blocks and server\_name

* NGINX uses server blocks (virtual hosts) to host multiple sites on a single server.
* The `server_name` directive is matched against the HTTP `Host` header to select the appropriate server block. Ensure your DNS records and client `Host` headers align with the configured `server_name` values to avoid unexpected routing.

## Redirecting HTTP to HTTPS

The simplest and most efficient way to redirect all HTTP traffic to HTTPS is with a `return` inside a server block. This performs a fast external redirect without extra processing:

```nginx theme={null}
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
```

## Rewrites and regex

* Use `rewrite` rules when you need to transform request URIs, perform conditional internal redirects, or normalize incoming paths before they reach a backend or a `location` block.
* Regular expressions in `rewrite` and `location` directives are powerful but can be costlier than prefix matches; use them only when necessary and test your expressions thoroughly.

## Upstreams and proxying

* An `upstream` block defines a pool of backend servers that NGINX can forward requests to. This is a common pattern for reverse proxies and load balancers.

Example upstream and proxy configuration:

```nginx theme={null}
upstream backend {
    server app1.example.com;
    server app2.example.com;
}

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

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
```

## Load-balancing algorithms

NGINX supports several load-balancing methods. Choose the one that best fits your traffic patterns and state requirements.

| Algorithm | Use case | Example |
| - | - | - |
| round-robin (default) | Even distribution across servers | `upstream backend { server app1; server app2; }` |
| weighted round-robin | Prefer certain servers with `weight=` | `server app1.example.com weight=3;` |
| `ip_hash` | Simple session affinity by client IP (sticky) | `ip_hash;` inside `upstream` |

```nginx theme={null}
upstream backend_weighted {
    server app1.example.com weight=3;
    server app2.example.com weight=1;
}

upstream backend_sticky {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
```

`ip_hash` offers basic session affinity by hashing client IPs, but it has limitations with autoscaling and failover. For robust sticky sessions consider cookies or a dedicated session store such as Redis.

## Reverse proxy vs. load balancer

* Reverse proxy: Forwards client requests to one or more backend application servers. Even a single backend benefits from a reverse proxy for TLS termination, compression, caching, request/response header manipulation, and security filtering.
* Load balancer: Distributes traffic across multiple backend nodes to balance load and provide failover. A meaningful load-balanced setup usually requires at least two backend nodes so requests can fail over when one node is down.

## Caching

Caching reduces latency and backend load by serving repeated responses from a local cache. Configure cache keys, TTLs, and cache-control headers carefully to avoid serving stale or incorrect content.

Example `proxy_cache` configuration:

```nginx theme={null}
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m;

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

    location / {
        proxy_cache my_cache;
        proxy_cache_bypass $cookie_nocache;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_pass http://backend;
    }
}
```

## Quick reference table

| Topic | Directive(s) | Short description |
| - | - | - |
| Server block | `server`, `listen`, `server_name` | Define virtual hosts and match requests by `Host` header |
| HTTP → HTTPS | `return 301 https://$host$request_uri;` | Fast external redirect from HTTP to HTTPS |
| URI rewrite | `rewrite`, `return` | Transform or internally redirect URIs using regex |
| Proxying | `proxy_pass`, `proxy_set_header` | Forward requests to upstream backends |
| Upstream pool | `upstream { ... }` | Define backend server pools for proxying/load balancing |
| Caching | `proxy_cache_path`, `proxy_cache` | Store backend responses on the NGINX host to speed repeats |

![A presentation slide titled "Summary" listing three points: that a reverse proxy forwards requests to backend services, that reverse proxies and load balancers differ, and that Nginx can be used as a cache server to boost performance. The slide has a blue gradient panel on the left and numbered markers for each point.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Summary/reverse-proxy-nginx-cache-summary.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=bea04cfe7209f41255422deba421df1b)

## Links and references

* [NGINX Documentation — Admin Guide](https://nginx.org/en/docs/)
* [NGINX — Reverse Proxy Examples](https://nginx.org/en/docs/http/ngx_http_proxy_module.html)
* [Best practices for caching with NGINX](https://www.nginx.com/blog/benefits-of-caching-static-content-with-nginx/)

And that wraps it up for this module.

> **[Watch Video](https://learn.kodekloud.com/user/courses/nginx-for-beginners/module/c78ff9cb-c15d-4f85-92fc-abee5ed98b20/lesson/924e21e1-b2e9-4b6d-b35e-8b1f6ed56a62)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.