# Cloudflare in front of your website: firewall rules and SSL errors > How to put a site behind Cloudflare without breaking it: the right SSL mode, useful WAF rules on the free plan and the most common 52x errors. URL: https://codegea.com/en/cloudflare-in-front-of-your-website-firewall-and-ssl Servers · 2026-10-19 · Derian Pinto Putting a site behind Cloudflare takes a few minutes, and two things can go wrong: the site stops loading because of the SSL setup, or the firewall rules block legitimate traffic. This guide covers both, with what to check before turning anything on. One clarification: codegea.com only uses Cloudflare for DNS and R2 (we cover it in [how codegea.com is built](/en/how-codegea-is-built-nextjs-payload-turso-r2)). This is the general procedure for a site on a server of your own, such as a VPS. ## What changes when you put it in front In Cloudflare, each DNS record has a switch: orange cloud (traffic goes through Cloudflare) or gray cloud (DNS only). With orange, visitors no longer talk to your server, they talk to Cloudflare, and Cloudflare talks to your server. That is where the firewall, cache and SSL apply. That means **two encrypted connections**: visitor to Cloudflare and Cloudflare to your server. And how you configure the second one is behind most of the problems. ## The SSL mode: problem number one SSL/TLS has four modes: - **Off:** no encryption. Don't use it. - **Flexible:** encrypts visitor to Cloudflare, but Cloudflare talks to your server **unencrypted**. - **Full:** encrypts both legs, accepting any certificate on your server. - **Full (strict):** encrypts both legs and requires a valid certificate on your server. Use **Full (strict)**, with a valid certificate on your server (a free Let's Encrypt one works; we install it in [configuring SSL, backups and firewall on your server](/en/setting-up-ssl-backups-and-a-firewall-on-your-server)). The classic redirect loop shows up with **Flexible**: your server sees the request arrive over HTTP, redirects it to HTTPS, Cloudflare requests it again over HTTP, and so on forever. The browser shows "too many redirects". Switching to Full (strict) fixes it. ## 52x errors If Cloudflare can't talk to your server, it shows its own error page: - **521:** the server refused the connection. Usually it is down or the server's firewall blocks Cloudflare. - **522:** the connection timed out. The server didn't respond in time. - **525:** the encryption between Cloudflare and your server failed. - **526:** your server's certificate is not valid (with Full strict). If it happens, look at your server's firewall first. If you closed it to accept only certain IPs, it has to allow Cloudflare's. ## WAF rules on the free plan According to Cloudflare's documentation, the free plan includes custom rules, **one** rate limiting rule and the free managed ruleset. Useful examples for WordPress: - **Block ****`xmlrpc.php`** if you don't use it. It is a usual target for brute-force attacks. Expression: `(http.request.uri.path eq "/xmlrpc.php")`, action **Block**. - **Challenge on the login.** `(http.request.uri.path eq "/wp-login.php")`, action **Managed Challenge**. Exclude users you already identify if it gets in the way. - **One rate limiting rule** on the login, to slow repeated attempts from the same IP. Three precautions: 1. **Don't put challenges on paths used by automated services.** Payment gateway webhooks, APIs, `admin-ajax.php` or the feed can break if you ask them to solve a challenge. 2. **Start in log mode** (*Log*) and review the events before moving to **Block**. 3. **Check that you don't block Googlebot.** Look at the crawl stats in Search Console after turning it on. ## "Under Attack" mode There is an emergency mode, *I'm Under Attack*, that shows visitors a checking screen before letting them in. The documentation describes it as a last resort: it pauses normal access, can affect your analytics and third-party tools that depend on JavaScript, and is off by default. It can be applied to the whole zone or just one path, such as `/admin`, with a configuration rule. Use it during an attack, not as a permanent setting. ## Cache: carefully By default, Cloudflare caches static files (images, CSS, JavaScript), not HTML. That is fine. If you turn on full-page caching, exclude anything tied to a session: admin panel, cart, customer account. ## And if your site is on Vercel It doesn't follow this scheme. Vercel already brings its own delivery network and firewall, and its documentation advises against putting another proxy in front. That is why on our site we leave Cloudflare for DNS and storage only. ## Short list before turning on the orange cloud 1. Valid certificate on the server and **Full (strict)** mode. 2. The server's firewall allows Cloudflare's IPs. 3. WAF rules in **Log** mode first. 4. You tested login, cart, contact form and webhooks. 5. You know how to switch back to gray cloud if something fails.