Using Cloudflare or Another Proxy With Kapsule

How to put a third-party proxy or CDN in front of a KapsuleHost site, including the two settings that break sites, the records that must never be proxied, and how to undo it.

Kapsule runs its own nameservers and its own global edge network, so most of what a third-party proxy offers is already available here, integrated and supported. You can still put one in front if you want to. This page shows you how, and what it costs you.

What You Gain and What You Give Up

Moving for a specific feature you have tested and need is a good reason. Moving because a forum post said to trades a supported setup for an unsupported one.

Note that most providers, Cloudflare included, require you to delegate the whole domain to their nameservers on entry-level plans. You cannot proxy one hostname and leave the rest of your DNS with us. Moving your nameservers moves everything: web records, mail records, verification records, all of it.

The Two Settings That Break Everything

1. Use Full (Strict) SSL, Never Flexible

Your Kapsule site has a real, publicly trusted certificate and redirects plain HTTP to HTTPS at the origin.

If your proxy is set to Flexible SSL, it talks plain HTTP to your origin. Your origin redirects that to HTTPS. The proxy fetches it again over HTTP. Round and round. Visitors see ERR_TOO_MANY_REDIRECTS and the site is unusable.

Set SSL mode to Full (strict). Your origin certificate is valid and publicly trusted, so strict validation passes. This is the most common cause of a site breaking the moment a proxy is switched on.

2. Do Not Intercept the Certificate Challenge Path

Certificates are issued and renewed by proving control of the domain over plain HTTP, at /.well-known/acme-challenge/. That request must reach the Kapsule origin and return the exact answer. Anything at the proxy that intercepts it breaks issuance and, three months later, renewal:

• Bot protection, "under attack" mode, or any managed challenge serving an interstitial page.
• Firewall, custom or page rules that match on path or user agent, or that rewrite the path.
• Caching that serves a stale 404 for the challenge path.
• Forcing HTTPS on the challenge path itself, before a certificate exists to serve it with.

Add an explicit rule excluding /.well-known/ from every one of those features.

Paid certificates ordered through Kapsule are validated over DNS instead, so proxying does not affect those. See SSL Certificates.

Moving Your DNS to Cloudflare

Step 1: Copy your current records. Open the DNS tab for your site in KPanel and write down every record: type, name, value, priority. Do not skip ones you do not recognise. Third-party verification records and the mail records below are what people lose. Automatic importers miss records regularly, so this list is what you check the import against and what you restore from later.

Step 2: Add the domain and check the import. Add the domain at Cloudflare and let it scan your DNS. Compare the result line by line against your list and add anything missing by hand. Values must match exactly, including trailing dots and quoting on TXT records.

Step 3: Decide what is proxied. Every record gets a proxy toggle, usually an orange or grey cloud. Proxied means traffic for that hostname goes through their network; unproxied means DNS resolves straight to the real address. Proxy only records that serve website traffic. The next section is the definitive list.

Step 4: Change the nameservers. Only once the records are correct, point the domain at the nameservers Cloudflare gives you. If the domain is registered with Kapsule, use the Nameservers page, covered in Nameservers. Otherwise use your registrar's panel. Delegation takes minutes to hours to be visible everywhere.

Which Records Must Never Be Proxied

Proxying a record that is not web traffic does not protect it. It replaces the answer with the proxy's address, so the service on the other end stops working.

The rule underneath: proxy hostnames that serve HTTP and HTTPS to browsers, and nothing else.

Keeping Your Email Working

Mail is the most common casualty of a nameserver move, and it often goes unnoticed for a day or two because incoming mail simply stops arriving rather than producing a visible error.

If your mailboxes are with Kapsule, four things must be true afterwards:

1. The MX record exists and is unproxied, pointing at mail.kapsulehost.com with priority 10.
2. SPF is a single record. A domain is allowed exactly one. Ours looks like v=spf1 include:_spf.kapsulehost.com ~all. If you also send through another service, their hosts belong inside that one record, not a second one.
3. Every DKIM record came across. Each domain has its own signing keys published as TXT records under _domainkey. There is more than one, and mail signed with a key whose record is missing fails authentication.
4. DMARC came across. The _dmarc record tells receiving servers what to do with mail that fails the checks above.

The Deliverability tab on any mailbox shows what is currently published and what is missing, with the correct values to copy. Check it after the nameservers have propagated. SPF, DKIM and DMARC Explained covers what each record does.

Mail is sent and received on the real mail hostname directly, so it never passes through the proxy. Your mail client settings do not change.

What You Lose: The Real Client IP

Kapsule reads the real visitor IP from a forwarded header, but only when the request arrives from our own edge network or the machine itself. Any other source is untrusted, deliberately, because a forwarded header can be forged by anyone. A third-party proxy is not on that trust list, and there is no supported way to add one.

So everything depending on the visitor's IP sees the proxy instead:

There is a worse version. The platform automatically blocks addresses generating a burst of errors or failed logins. Behind a proxy that activity all appears to come from the proxy, so one badly behaved visitor can get an entire proxy data centre temporarily blocked, taking out everyone else routed through it. We cannot fix that from our side.

Do Not Stack Two CDNs

Running Kapsule CDN with a third-party proxy in front does not double your performance. It gives you two caches disagreeing, two sets of purge rules, and a very hard problem to debug.

There is also a concrete blocker: enabling Kapsule CDN requires our edge to issue a certificate for your hostname, which requires the hostname to resolve to our edge. If DNS points at a third-party proxy instead, that certificate never issues and the CDN silently does nothing.

Pick one. If you want theirs, turn Kapsule CDN off first, before you delegate your nameservers away. If you want ours, turn the proxy off. Enabling Kapsule CDN normally writes the required edge records for you, but only when your DNS is hosted with us; otherwise publish them yourself using the edge hostname on the CDN tab.

Coming Back to Kapsule DNS

1. Open the DNS tab in KPanel and check the records still match what is live at the proxy. Add anything you created there since you left.
2. Turn the proxy toggle off on every record at the third-party service, so the zone shows real addresses. Confirm the site still loads.
3. Change the nameservers at your registrar back to ns1.kapsulecloud.com, ns2.kapsulecloud.com, ns3.kapsuledns.com and ns4.kapsuledns.com.
4. Once delegation moves, confirm the site loads over HTTPS with a valid certificate.
5. Check the Deliverability tab on a mailbox and confirm the mail records are present.
6. Re-enable Kapsule CDN if you want it, and confirm the certificate issues.

When It Goes Wrong

• ERR_TOO_MANY_REDIRECTS: SSL mode is Flexible. Change it to Full (strict).
• Certificate expired or invalid: renewal was blocked. Add the /.well-known/ exclusion, then reissue from the panel. See SSL Certificates.
• Mail stopped arriving: the MX record is missing, proxied, or pointing at the wrong host. See Email Not Receiving.
• Mail sends but lands in spam: an SPF, DKIM or DMARC record did not come across. Fix what the Deliverability tab flags. See Why Are My Emails Going to Spam?.
• Changes not appearing: two caches. Purge both, then check in a private window.
• Some visitors cannot reach the site, others can: likely an automatic block on one proxy data centre. See Opening a Support Ticket.
• The domain stopped resolving right after the nameserver change: usually a stale DNSSEC delegation record. Ask your registrar to remove it.
• Mixed content warnings: unrelated to the proxy, but often noticed at the same time. See Fixing Mixed Content.

Related Guides

• Enabling the CDN
• Purging the CDN Cache
• Nameservers
• DNS Basics
• Security
• Hosting Glossary