Contents9
“We put Cloudflare in front, so we are protected.” The sentence is half true. A reverse proxy placed in front of a website or an application changes a lot: flood attacks stop before the server, suspicious requests are filtered, files leave from a cache close to the visitor. But it only sees what goes through it, and it sometimes acts on your behalf without you asking. This article sorts out which is which, as part of our guide to the cloud infrastructure foundation.
We use Cloudflare as the example because we use it and its settings are publicly documented. The same setup exists elsewhere: at the big clouds (Amazon CloudFront with AWS WAF, Azure Front Door, Google Cloud Armor), at delivery networks such as Fastly, Akamai or the European Bunny, or with a reverse proxy installed on your own server. The questions in this article apply to all of them.
In short
A reverse proxy receives every request instead of your server, and only forwards those that pass its rules.
At Cloudflare, protection against flood attacks is included in every plan, from the network layer up to the application.
It does not protect a vulnerable application, a server reachable directly, or stolen credentials.
It can change what your site serves, robots.txt included: check the production URL, not your code.
Everything goes through it: an outage of the proxy is an outage of your services, and the recovery plan must allow for it.
What a reverse proxy does
Definition
Reverse proxy
A server placed in front of your services, which receives visitors’ requests in their place, decides what to do with them (refuse, answer from its cache, forward) and sends the response back. The visitor only talks to the proxy; your server only talks to the proxy.
The path of a request behind a proxy
- The visitor
They request a page at your usual address.
- The proxy
It filters, encrypts, and answers from its cache when it can.
- Your server
It only receives what the proxy let through.
- The response
It goes back through the proxy, which may cache it.
That position explains everything else: the proxy protects what goes through it, and only that.
What it protects
Flood attacks. An attack that swamps a server with requests brings it down, however good its code. A global network absorbs that volume before it reaches you. Cloudflare’s DDoS protection documentation states that standard, unmetered protection, from the network layers up to the application layer, is included in every plan.
Suspicious requests. The web application firewall checks incoming web and API requests and filters undesired traffic based on rulesets: rules managed by the vendor, rules you write, rate limits. The scope depends on the plan: the entry plan gets a single managed ruleset and a single rate limiting rule.
Encryption and caching. The proxy presents a certificate to visitors, and serves files that do not change from its cache. A static site gains the most: its entire pages are files.
Your server’s address. When DNS records go through the proxy, visitors only see the proxy’s addresses. On one condition, covered below: that nothing else gives the real address away.
What it does not protect
What goes through the proxy
Flood attacks aimed at your domain
Requests that match a known rule
Encryption between the visitor and the proxy
The load of files served from cache
What escapes it
A server reachable directly at its address
An application flaw the rules do not recognise
A stolen password or API key, used normally
Data lost without a backup
The directly reachable server. In its page on protecting the origin server, Cloudflare lists what can reveal the real address: DNS records that are not proxied (SPF, TXT), a mail server hosted on the same machine, DNS history from before the proxy was set up. Its counter-measures: only accept traffic from Cloudflare’s addresses on the server, authenticate the proxy’s requests, or use an outbound tunnel that avoids any public address. And change the server’s address after onboarding.
The application itself. A web application firewall recognises known attacks; it does not fix a vulnerable plugin or faulty logic. Updates remain your job, as our article on hacked WordPress sites shows.
Credentials. A login with a stolen password or API key looks like a normal login. That risk is handled elsewhere: a password manager for the team and protecting the API keys of AI projects.
A proxy also acts on your behalf
A proxy can change what your site serves: add headers, rewrite a URL, inject a file. These options are useful when you choose them, and traps when they are on by default.
Watch out
A client found out at the audit
At Palmora Property, a real estate agency in Phuket that we support, the robots.txt in the repository allowed every crawler. The one served in production started with a block added by Cloudflare, the “managed robots.txt”, absent from the code, which refused GPTBot, ClaudeBot and Google-Extended among others. The audit of 22 July 2026 caught it, and the option was switched off the same day.
The rule that follows is simple: check what the production URL serves, not what the repository contains. The consequences of that block for visibility in AI assistants are covered in our article on what makes a website citable by AI.
A single point of passage
Everything goes through the proxy: if it goes down, your services go down with it, even if your server is fine. Cloudflare published a detailed account of its outage on 18 November 2025:
- 11:20 UTC
Cloudflare’s network starts failing to deliver traffic. A bot management configuration file, grown too large after a permissions change in a database, crashes the proxy software.
- 17:06 UTC
All of Cloudflare’s systems are functioning normally again.
This is not an argument against proxies: a lone server goes down too, and more often. It is an argument for writing it into the plan. Three precautions are enough: an external probe that tests the service through the proxy (see our guide to monitoring), a written procedure to serve the site without the proxy if the outage lasts, and access to the proxy account stored with the other emergency access in the disaster recovery plan.
What we do
From the field
This site’s name servers have been at Cloudflare since 2 October 2026, and its pages have been served by Cloudflare’s network since 18 October 2026. The setup holds because the pages are files with no personal data; form enquiries are stored in a storage space bound to the EU jurisdiction restriction. Redirects, security headers and host configuration are written in the site’s repository and reviewed like code.
On a server of your own, the same principle applies on a smaller scale: a single reverse proxy in front of every service, which centralises certificates and access rules, with the services themselves closed to the internet.
Where to start
- List what is exposed.
Every domain and subdomain, what it serves, and whether it goes through the proxy.
- Close direct access.
The server only accepts the proxy, then change its address if it has already circulated.
- Review the options switched on.
Bot management, rewrites, added files: keep what you chose, remove the rest.
- Check what is served.
Robots.txt, headers and redirects, at the production URL.
- Plan for the outage.
An external probe, a written bypass procedure, emergency access.
The rest of the project
The proxy is only one layer of the foundation. Where to host depends on the use (dedicated server, VPS or cloud) and the bill needs watching (what inflates a cloud bill). What the proxy does not protect is handled by backups, by a well-run database (managed or self-hosted Postgres) and by infrastructure you know how to rebuild (infrastructure as code). Kubernetes is not needed to put a proxy in front of a few services (when you do not need it), and n8n in production sits behind it like the rest (self-hosted n8n). Email, which can give away a server’s address, has its own article (Google, Microsoft or a European host). On the decision side: which tools to move out of SaaS first, the three-year cost of leaving SaaS, cloud migration without breaking things, sovereign cloud in Europe, the hardware to run an AI model and NIS2 in France.
Our self-hosted stack installs your tools behind a single reverse proxy, on a server of your own, with tested backups and operating documentation: €5,500 and three weeks.
Frequently asked questions
Is Cloudflare enough to secure a website?
No. It protects what goes through it: flood attacks, requests that match its rules, encryption between the visitor and the proxy. It does not fix a vulnerable application, does not protect a server reachable directly, and does not detect a login with stolen credentials. Updates, access control and backups remain your responsibility, whatever proxy sits in front.
Does a static site need a proxy?
A static site has no application server to protect, but it gains from the same setup: encryption, a cache close to the visitor and absorption of flood attacks. Most static site hosts already work this way. The point to watch is the same: options that change what the site serves, such as a robots.txt added by default, which you only see by checking the production URL.
What happens if Cloudflare goes down?
The services that go through it become unreachable, even if your server is running. The outage of 18 November 2025 showed it on a large scale. Prepare a monitoring probe that tests through the proxy, a written procedure to serve the site without it if the outage lasts, and emergency access to the account, stored in the recovery plan.
Are there European alternatives to Cloudflare?
Yes. European delivery networks such as Bunny offer caching, protection and filtering rules, and a reverse proxy can also run on your own server in Europe. Compare protection against flood attacks, the web application firewall, where logs are stored and how easy it is to leave. The choice follows the same criteria as choosing a host.
Sources
- Cloudflare, DDoS protection (new tab)developers.cloudflare.com
- Cloudflare, web application firewall (WAF) (new tab)developers.cloudflare.com
- Cloudflare, protect your origin server (new tab)developers.cloudflare.com
- Cloudflare, Cloudflare outage on November 18, 2025 (new tab)blog.cloudflare.com
Jim · founder of Brain Plus AI
Also in infrastructure and cloud
Practical guide7 min
Monitoring: knowing a service is down before customers do
An outage discovered by a customer costs twice: the lost service, and the trust. What monitoring should watch, from the outside as well as the inside, who should receive the alert, and how to avoid the one nobody reads any more.
Practical guide13 min The topic guide
Cloud infrastructure: the foundation for all your projects
Before the first project, a cloud infrastructure foundation settles accounts, access, backups and budget once and for all, and every later project inherits it. What it contains, where to put it, what it costs and why running it matters more than installing it.
Practical guide8 min
Disaster recovery plan: what has to be written down
The day a server, a data centre or an account disappears, it is too late to decide the order of things. What a disaster recovery plan must contain, the two figures management must set, and how to know it works.