Cloudflare + DigitalOcean Integration Guide 2026

A practical guide to putting Cloudflare in front of a DigitalOcean Droplet, from DNS migration through locking the Cloud Firewall to Cloudflare-only traffic.

Placing Cloudflare in front of a DigitalOcean Droplet is a widespread pattern among developers because it hides your server's true IP, distributes load through a CDN, and provides DDoS protection without any additional cost on the DigitalOcean side. This article walks you through each step from DNS migration, enabling Proxy, setting up SSL, to locking the Cloud Firewall to accept only Cloudflare traffic, plus common pitfalls and how to fix them.

Why Use Cloudflare in Front of Your Droplet

DigitalOcean Droplets come with a public IP exposed directly to the internet from day one, unlike some PaaS providers that hide the origin IP automatically. This means anyone who knows your Droplet's IP can send traffic directly without needing your domain, whether it's scanning for vulnerabilities, brute-forcing SSH, or even small-scale DDoS attacks that spike your CPU/bandwidth until the site crashes. Placing Cloudflare in front solves this on multiple levels at once. First, it masks your origin IP—when you enable Proxy (Orange Cloud), visitors only see Cloudflare's IP addresses, not your Droplet's true IP, unless it leaks through other channels like a mail server or forgotten proxied subdomain. Second, Cloudflare provides Layer 3/4/7 DDoS protection free on every plan, including the Free tier, covering volumetric attacks that a lone Droplet cannot withstand. Third, the Anycast CDN with edge nodes worldwide means users in Thailand or Southeast Asia load pages faster even if your Droplet is in a distant region like nyc1 or ams3, because static assets cache near the user instead. Fourth, Cloudflare offers free SSL/TLS for users, reducing reliance on Let's Encrypt alone for client-facing traffic (though you still need a certificate between Cloudflare and your Droplet if you want Full Strict encryption). Fifth, static content like images, CSS, and JavaScript cached at the edge reduces load on your Droplet directly, allowing small instances with just 1 vCPU/1 GiB RAM starting at $6/month to handle much more traffic without immediate upgrade. For teams running public websites on Droplets—whether WordPress, Node.js apps, or static sites—connecting Cloudflare is a worthwhile step with almost no downside if configured correctly.

• Hide your Droplet's origin IP from regular users by enabling Proxy
• Free L3/L4/L7 DDoS protection even on the Cloudflare Free plan
• Anycast CDN reduces latency for users in Thailand/Southeast Asia even if your Droplet is far away
• Reduce your Droplet's CPU/bandwidth load because static assets cache at the edge

Migrating DNS to Cloudflare

A point users often miss: the first step of connecting Cloudflare to your Droplet is migrating your domain's DNS management to Cloudflare. Start by logging into the Cloudflare dashboard and clicking Add a Site, then enter your domain name. The system automatically scans for existing DNS records, whether they're stored at your registrar or at DigitalOcean's DNS. If you were already using DigitalOcean as your DNS provider via doctl, you can export all records for comparison using the command doctl compute domain records list yourdomain.com to verify Cloudflare captured every record correctly, especially MX records for email (if they disappear after migration, your domain's email stops working immediately). After reviewing, add or update your A record to point to your Droplet's public IP, and check any AAAA records for IPv6 as well. Next, Cloudflare provides a pair of nameservers in the form of aida.ns.cloudflare.com and walt.ns.cloudflare.com—you must set these at your registrar (GoDaddy, Namecheap, or local Thai registrars). This step is critical because it transfers full DNS control from DigitalOcean or your old registrar to Cloudflare. Before changing nameservers, lower the TTL of important records like your domain's A record to 300 seconds at least 24–48 hours ahead of time, so cutover happens quickly and propagates globally faster when you make the switch. Nameserver changes typically take anywhere from minutes to 24–48 hours to propagate, depending on the registrar and the resolvers users are using. During this time, monitor the Cloudflare dashboard for an automatic notification once the nameservers have changed and your domain is fully active.

• Use doctl compute domain records list to verify all records before migration if you used DO DNS
• Check MX records completely so domain email doesn't break after migration
• Lower TTL to 300 seconds at least 24–48 hours before the actual cutover
• Change nameservers at your registrar to the pair Cloudflare provides

Enabling Proxy (Orange Cloud) + SSL Full Strict

Once your domain is active on Cloudflare, the next step is enabling Proxy—or Orange Cloud—on the DNS records that should route traffic through Cloudflare, such as the A record for www and your root domain. Click the cloud icon next to the record to toggle it from gray (DNS only) to orange (Proxied). Leave records that shouldn't go through Cloudflare in gray, such as subdomains for your mail server or dedicated SSH, because Cloudflare doesn't proxy all protocols. After enabling Proxy, immediately configure the SSL/TLS mode correctly. You have four choices: Off, Flexible, Full, and Full (strict). For a Droplet with an existing SSL certificate, Full (strict) is recommended because it forces Cloudflare to validate the Droplet's certificate strictly, protecting you against man-in-the-middle attacks between Cloudflare and your origin. Flexible mode only encrypts from users to Cloudflare but leaves Cloudflare-to-Droplet as plain HTTP, often causing redirect loops when your origin app already forces HTTPS. For the certificate on your Droplet, you have two options: use Let's Encrypt via Certbot as normal, or use a Cloudflare Origin CA Certificate (free, created from SSL/TLS > Origin Server > Create Certificate) that lasts up to 15 years and doesn't require renewal like Let's Encrypt does—but only works between Cloudflare and origin, not for direct browser access. After installing your certificate on Nginx or Apache, enable Always Use HTTPS from SSL/TLS > Edge Certificates so Cloudflare's edge redirects HTTP to HTTPS automatically, reducing the redirect burden on your Droplet.

• Enable Proxy only on records you want to route through Cloudflare (www, root), leaving others as DNS only
• Set SSL/TLS mode to Full (strict) if your Droplet already has a valid certificate
• Avoid Flexible mode because it often causes redirect loops with apps that enforce HTTPS
• Create a free Cloudflare Origin CA Certificate that lasts up to 15 years
• Enable Always Use HTTPS in Edge Certificates for automatic HTTP-to-HTTPS redirect at the edge

Configuring Firewall to Accept Only Cloudflare IP

Enabling Proxy alone is not enough because your Droplet's public IP is still reachable directly. If someone discovers your true IP, they can send requests directly around Cloudflare, defeating your DDoS and IP-masking strategy. The critical step is using DigitalOcean's Cloud Firewall—a free feature with no extra cost—to lock your Droplet so it accepts traffic on ports 80 and 443 only from Cloudflare's IP ranges. Cloudflare's official IPv4 and IPv6 CIDR blocks are listed at cloudflare.com/ips and should always be pulled fresh because Cloudflare updates ranges occasionally. The easiest way is using doctl to create a firewall with inbound rules covering all Cloudflare CIDR blocks, for example: doctl compute firewall create --name web-cf-only --droplet-ids DROPLET_ID --inbound-rules "protocol:tcp,ports:80,address:173.245.48.0/20 protocol:tcp,ports:443,address:173.245.48.0/20" then add the remaining ranges one at a time with doctl compute firewall add-rules FIREWALL_ID --rules "protocol:tcp,ports:443,address:173.245.48.0/20", repeating until all IPv4 and IPv6 ranges are covered. For other ports like SSH (22), create a separate rule allowing only your team's IP or VPN, not open to the world, because Cloud Firewall works as a per-port allowlist with zero extra cost no matter how many rules you add. One critical risk: if you forget to update your IP ranges when Cloudflare changes them, Cloudflare's edge nodes may temporarily fail to reach your origin, returning error 521/522 to users. That's why it's wise to write a script that pulls the latest IPs from cloudflare.com/ips, compares them to your current rules, and updates the firewall on a schedule (e.g., cron monthly) instead of setting once and forgetting.

1. Pull the latest Cloudflare IP ranges (both IPv4 and IPv6) from cloudflare.com/ips
2. Use doctl compute firewall create/add-rules to open ports 80/443 only from Cloudflare ranges
3. Keep SSH (port 22) on a separate rule allowing only your team's IP or VPN

Basic Caching and Page Rules

Worth highlighting here — another major benefit of placing Cloudflare in front of your Droplet is caching, which significantly reduces the load on your origin. The default Caching Level recommendation is Standard, which caches according to query strings normally, and you can adjust Browser Cache TTL in the Caching menu to control how long browsers cache static assets before requesting again. For more granular control, Cloudflare offers Cache Rules, a newer system replacing the old Page Rules, letting you set conditions and caching behavior per path flexibly. For example, create a rule to bypass cache on paths like /wp-admin and /api because they change frequently or relate to user sessions, then create another rule to set Cache Everything with a long Edge TTL (e.g., 1 month) for static files like .css, .js, .jpg, .png so edge nodes hold them longer and request from your Droplet less often. When you deploy new code or update static assets, purge the cache immediately so users don't see stale versions—either via Purge Everything in the dashboard or target specific files through the API for precision on high-traffic sites. If you're debugging and uncertain whether cache is interfering, enable Development Mode temporarily, which bypasses all cache for 3 hours automatically without needing per-file purges. Be extra careful with WordPress because you can end up with double-layer caching: the plugin cache inside your WordPress install plus Cloudflare's edge cache, and misalignment between them can cause stale content to linger unexpectedly.

1. Set Caching Level to Standard and tune Browser Cache TTL to suit your needs
2. Create a Cache Rule to bypass cache on /wp-admin and /api
3. Set Cache Everything with a long Edge TTL for static files like css/js/images
4. Purge cache immediately after deploying to prevent users from seeing old versions
5. Enable Development Mode temporarily when debugging to bypass all cache for 3 hours

When to Use This Feature (Real Use Cases)

Integrating Cloudflare and Droplet is ideal when your website or app is public-facing and at risk of attack or traffic spikes. Think WordPress or WooCommerce storefronts running real sales worried about DDoS during promotional periods, news or blog sites with readers scattered across multiple countries needing consistent page-load speeds, or public API endpoints that need basic rate limiting before hitting your origin. Another scenario worth considering: teams running small Droplets (1–2 vCPU) who want to stretch the lifespan of that spec as far as possible before upgrading, because static assets cached at the edge shoulder the load instead. On the flip side, some setups don't need Cloudflare proxy at all: internal tools or admin dashboards already guarded by VPN or WireGuard don't benefit from adding a proxy layer without compelling reason. Similarly, apps relying heavily on long-lived WebSocket connections need careful timeout and compatibility checks with your Cloudflare plan before going full proxy—especially real-time apps sensitive to even small latency increases from an extra hop at the edge. And sites with very low traffic and no specific security threat may not need the extra complexity, though setting it up costs nothing and pays off later as you grow, so the recommendation is to configure it from day one anyway.

1. WordPress/WooCommerce storefronts running real sales and worried about DDoS during peak traffic
2. Websites with readers spread across multiple countries needing consistent load speeds
3. Public APIs needing basic rate limiting before reaching your origin

Common Errors and Solutions

The most frequent problem is redirect loops or ERR_TOO_MANY_REDIRECTS, usually from setting SSL/TLS mode to Flexible while your Droplet's app already forces HTTP→HTTPS (like WordPress's Force HTTPS plugin), creating a cycle: Cloudflare sends HTTP to origin → origin redirects to HTTPS → loops endlessly. Fix: switch SSL mode from Flexible to Full or Full (strict). The second most common issue is error 521 (Web Server Is Down) or 522 (Connection Timed Out), which often isn't your Droplet actually being down but your Cloud Firewall blocking Cloudflare's IP by mistake, especially after you set up an allowlist firewall and forgot to update it when Cloudflare rotated ranges. Check by reviewing your Nginx/Apache logs to see if Cloudflare's IPs are reaching your Droplet at all—if not, your firewall is blocking them. The third problem is real visitor IPs disappearing from your Droplet's logs, replaced entirely by Cloudflare's IPs, breaking traffic analysis and rate-limiting rules that run at the origin. Fix: configure Nginx to read the CF-Connecting-IP header by adding set_real_ip_from 173.245.48.0/20; real_ip_header CF-Connecting-IP; for all Cloudflare ranges in nginx.conf, then reload. Fourth: mixed-content warnings appear because some resource links are hardcoded as http:// even though Always Use HTTPS is on. Fix: either rewrite the links in source code or use Cloudflare's Automatic HTTPS Rewrites feature to patch some of them. Fifth: after deploying new code, users still see old versions because cache is stale, fixed by running a cache purge every time you deploy—automate it through your CI/CD pipeline if possible.

1. Redirect loops: change SSL mode from Flexible to Full/Full Strict
2. Error 521/522 usually means Cloud Firewall is blocking Cloudflare's IP, not your Droplet being down
3. Real visitor IP missing from logs: use real_ip_header CF-Connecting-IP in Nginx

Best Practices

To keep your Cloudflare–Droplet setup solid and truly secure over the long term, follow these key principles. First, always use SSL/TLS mode Full (strict) in production—never rely on Flexible long-term because the channel between Cloudflare and origin won't be encrypted, opening the door to eavesdropping if anyone taps the network in between. Second, lock Cloud Firewall to Cloudflare IP ranges only, and add a second layer with Authenticated Origin Pulls, a Cloudflare feature that forces your origin to verify Cloudflare's client certificate before responding. This way, even if someone discovers your true IP and pretends to be Cloudflare, they can't answer without the right certificate. Third, rotate your Origin CA certificate periodically even though it lasts up to 15 years, because regular rotation reduces risk if it ever leaks without your knowledge. Fourth, pair DigitalOcean Monitoring with Alert Policies that notify you when CPU or bandwidth spikes unusually, because while Cloudflare filters malicious traffic well, you still need monitoring at the origin as a final safety net. Fifth, test your entire setup on a staging subdomain or test domain before going live on production, ensuring SSL, cache rules, and firewall rules work together correctly and don't break your site for real users. Finally, document your configuration in writing—which firewall rules you set up, which cache rules you created, which nameservers you're using—so your team or your future self can troubleshoot or expand the system quickly when needed.

• Always use SSL/TLS mode Full (strict) in production, never Flexible
• Enable Authenticated Origin Pulls alongside Cloud Firewall to block imposters lacking the certificate
• Rotate Origin CA certificates periodically even if they last up to 15 years

Get $200 Free Credit →