What is a CDN (content delivery network)?

• Servers and Infrastructure
• Updated: 4 October 2026
• About 11 min read

How a CDN works and how it is put in place

1. 1

   The CDN sits between the visitor and your server

   Technically, a CDN can be thought of as a reverse proxy spread around the world. A reverse proxy that you place in front of your own server receives requests, answers from its cache and hides the application behind it; a CDN does the same job on your behalf, at many locations at once.

   In this arrangement the server where your site actually lives is called the origin server, and the CDN's servers close to the visitor are called edge servers. The request reaches the edge first:

   • Cache hit: If the requested file is at the edge, it is served from there directly; no request goes to the origin server.
   • Cache miss: If the file is missing or has expired, the edge fetches it from the origin server, passes it to the visitor and, if allowed, stores it.

   : Enlarge

2. 2

   What does a CDN give you?

   • Delivery from a nearby server: As the distance between visitor and server is shorter, waiting time falls, especially for visitors from distant countries.
   • Caching: Content that does not change, such as images, style sheets and scripts, is served from the edge; the number of requests reaching your origin server and its bandwidth use go down.
   • Filtering attack traffic: A CDN network is designed to absorb heavy traffic that a single server could not cope with; many providers also offer DDoS protection and a WAF (web application firewall). For details, see the DDoS and bot attacks guide.
   • SSL: The CDN sets up the HTTPS connection between the visitor and itself; in most cases it also provides and renews the certificate. For what SSL is, see the What is SSL? guide.

   A CDN does not solve every problem: pages generated separately for each visitor (basket, my account, admin panel) cannot be served from the cache and are still produced on your origin server. A slow database query does not get faster with a CDN.

   : Enlarge

3. 3

   Putting it in place: DNS is pointed at the CDN

   The details differ from provider to provider, but the general flow is the same:

   1. Add the site to the CDN: Add your domain name in the provider's control panel and enter the address of your origin server.
   2. Point the DNS: Either the domain's nameservers are switched to the CDN provider, or the relevant record (for example www) is pointed at the address the CDN gives you. From then on, visitors who look up your domain receive the CDN's address.
   3. Choose the SSL mode: Set it so that HTTPS is used both between the visitor and the CDN and between the CDN and the origin server.
   4. Review the caching rules: Decide what is stored and for how long; leave personal pages out.
   5. Test and restrict the origin: Once the site works properly through the CDN, restrict direct access to the origin server.

   Before changing the DNS, check that all existing records (especially the MX and TXT records used for email) are present in full at the new location. Email traffic does not pass through the CDN; the email records must go on pointing directly at your mail server.

   : Enlarge

4. 4

   Read the real visitor IP correctly

   Once the CDN is in place, it is no longer the visitor that connects to your server but the CDN's servers. Unless a setting is made, the access logs, rate limiting and every IP-based check in the application see the CDN's address and not the visitor's. The CDN passes on the visitor's real address in an HTTP header; the common one is X-Forwarded-For, and some providers add headers of their own.

   This header must be trusted only if the request really came from the CDN; otherwise anyone can write the header by hand and pretend to come from another address. The Nginx setting is covered in a separate section below.

   : Enlarge

5. 5

   You decide what is cached

   Whether the CDN stores a response, and for how long, is largely determined by the Cache-Control header your server sends. The rule is simple: content that is the same for everyone may be cached; content that differs from person to person must not be. A "my account" page cached by mistake can lead to one user's details being shown to another visitor.

   : Enlarge

The real visitor IP in Nginx

Nginx uses the set_real_ip_from and real_ip_header directives for this. The first states which addresses' connections are trusted, the second which header the real address is read from:

# Inside the http block
# The current IP ranges published by your CDN provider (those below are examples)
set_real_ip_from 198.51.100.0/24;
set_real_ip_from 203.0.113.0/24;

# The header the real visitor address is read from (as recommended by your provider)
real_ip_header X-Forwarded-For;
real_ip_recursive on;

• In the set_real_ip_from lines, enter only the IP ranges published by your CDN provider. Entering a wide range or all addresses here means anyone can forge the header.
• Providers update their IP ranges from time to time; check the list at regular intervals. Requests from a range you have missed will still show the CDN's address.
• For real_ip_header, use the header recommended in your provider's documentation.
• With real_ip_recursive on;, if the header holds several addresses, the trusted ones are skipped and the last non-trusted address is taken.

These directives belong to Nginx's realip module. The module is not part of a default build of Nginx from source; the ready-made packages of the distributions mostly include it. If the directive is not recognised, nginx -t will say so.

Once the setting is in place, the access logs, security settings such as rate limiting and the client address seen by the application all use the visitor's real address.

Caching, Cache-Control and personal content

Give static files that do not change a long cache lifetime:

# Versioned static files: may stay in the cache for a long time
location ~* \.(css|js|webp|png|jpg|svg|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

On pages that differ from person to person (my account, basket, orders, admin panel, anything a logged-in user sees), forbid storing the response in shared caches. Do this in the right place, in the application that generates the page:

<?php
// Page specific to a logged-in user: must not be stored in shared caches.
// Has to be sent before any output.
header('Cache-Control: private, no-store');

• private: the response may be stored only in the visitor's own browser; it may not be stored in shared caches such as a CDN.
• no-store: the response is not stored anywhere.
• public, max-age=…: the response may be stored anywhere for the stated number of seconds.

Whether HTML pages are cached by default depends on the provider. Before telling a page rule to "cache everything", make sure there is no personal content under those addresses. For caching settings on the server side, see the caching and compression guide.

Cache purging and versioned file names

When you update a file on the server, the old copy at the edge goes on being served until it expires. There are two solutions:

• Purging the cache: Through the provider's control panel or API you ask for particular addresses, or the whole cache, to be deleted. It works, but it has to be remembered at every release; nor can it delete the copy in the visitor's own browser.
• Versioned file names: When the file changes, its name or address changes too: style.4f2a1c.css or style.css?v=12 in place of style.css. As the new address is not in any cache, both the CDN and the browser fetch the new file at once. With this method, static files can safely be given a very long cache lifetime.

Use versioned names as the standing arrangement; keep purging for urgent fixes and HTML pages. Whether the query string (?v=12) is part of the cache key depends on the provider's settings; if you are not sure, choose the method that changes the file name.

Restrict direct access to the origin server

Someone who knows the origin server's IP address can bypass the CDN and connect to the server directly; the CDN's filtering and protection layer is then out of the picture. Measures:

• Restriction at the firewall: Open the web ports (80 and 443) only to the CDN's IP ranges. This is the most robust method, because the request never reaches the web server.
• Restriction on the web server: If you have no access to the firewall, you can apply the same check in Nginx (example below).
• Authenticated connection: Some providers offer an option that makes the origin server accept only connections carrying the CDN's client certificate.
• Do not leak the address: Remove old DNS records that point straight at the origin server (unused subdomains, for example). If the address was public before, ask your hosting provider for a new IP address if possible.

# Inside the http block: is the address that opened the connection in a CDN range?
geo $realip_remote_addr $from_cdn {
    default          0;
    198.51.100.0/24  1;
    203.0.113.0/24   1;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    # The certificate paths are examples
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    # Reject direct connections that do not come from the CDN
    if ($from_cdn = 0) {
        return 403;
    }

    root /var/www/example.com;
}

The detail here matters: when set_real_ip_from is used, Nginx replaces the client address with the visitor's address, so the allow and deny directives now look at the visitor's address and not the CDN's. In the example, the address that actually opened the connection is read from the $realip_remote_addr variable. For general server hardening advice, see the server and hosting security guide.

Encrypt the connection between the CDN and the origin

The padlock in the visitor's browser only shows the connection between the visitor and the CDN. The connection between the CDN and your origin server is a separate one, and it must be encrypted as well. With many providers this is a choice of SSL mode:

• Avoid: the mode in which the CDN connects to the origin over plain HTTP. The visitor sees "secure", but the data travels unencrypted on the second half of the journey.
• Choose: the mode in which the CDN connects to the origin over HTTPS and verifies the origin server's certificate. This requires a valid certificate on the origin server; some providers also issue an origin certificate that only their own network trusts.

For installing a certificate on the origin server, see the HTTPS in Nginx guide. Bear one more thing in mind: as the CDN terminates the HTTPS connection on its own servers, it can see the content of your traffic; take this, and the place where personal data is processed, into account when choosing a provider.

Frequently asked questions

Related guides

• What is a reverse proxy?What a reverse proxy does, typical architectures, the real visitor IP and headers, how it relates to a CDN, and a short Nginx example.
• DDoS and bot attacksSigns, CDN and WAF, rate limiting, caching and working together with your hosting provider.
• Caching and compression in NginxHow to set up caching and compression in Nginx correctly with static file headers, gzip and proxy_cache.
• What is load balancing?How requests are spread across several servers, the Nginx upstream settings, health checks and the session problem.