Cloudflare

What this page is for: put your project behind Cloudflare, give the panel an API token, and let it set the ~20 Cloudflare options a 6ammart site needs.

You need

• Your domain, and the ability to change its nameservers at the company you bought it from (GoDaddy, Namecheap, Hostinger, your local registrar…).
• A free Cloudflare account. The free plan is enough for everything on this page except three items, which the panel marks clearly.

The short version. Add your domain to Cloudflare, paste one API token on This panel, and press Set this up for me. The panel reads your Cloudflare settings, changes only the ones that are different from what a 6ammart site needs, and then tells you exactly what it changed and what it left alone and why.

Connecting the token also changes how the rest of the panel behaves, and this is the part worth doing early: with a token, the panel creates your DNS records for you and gets real certificates by writing a DNS record rather than by serving a file over port 80. Domains and HTTPS stop being a manual step.

The one rule: every record is proxied

Every DNS record this panel creates is proxied — the orange cloud. There is no switch to turn that off, and the panel will never suggest one.

The reason is the whole point of putting Cloudflare there. A record that is not proxied publishes your server's IP address in public DNS, for anyone to read and aim at. Cloudflare then protects the parts of your site that go through it and nothing at all on the parts that do not. Half-proxied is the shape that looks protected and is not.

One consequence follows, and the panel handles it for you:

Cloudflare's free certificate covers your domain and one level below it. example.com and shop.example.com are covered. dash.shop.example.com is not — a proxied name that deep answers every HTTPS connection with a handshake failure at Cloudflare's edge, before your server is even dialled, unless you have bought Cloudflare's advanced certificate product.

So the panel picks names that fit. A name that would sit deeper is written with a hyphen instead of a dot:

If you type the deeper form by hand, the panel refuses it and shows you the spelling that works. Nothing is ever created unproxied as a way around this.

Your mail records are not web records. MX records and the TXT records that go with them (SPF, DKIM, DMARC) are not proxied by Cloudflare at all — that is how mail works everywhere. The panel never touches them, and neither should you when you move your domain to Cloudflare.

The simplest setup: one Cloudflare account for everything

Recommendation: keep every domain on this server in ONE Cloudflare account.

That single choice decides how much of this page you ever have to read:

A Cloudflare API token can never see a second Cloudflare account — that is Cloudflare's rule, not the panel's, and there is no permission that gets around it. So a domain in a different account always costs one more token to keep alive. That is fine and fully supported; it is simply more to look after.

Use a second Cloudflare account only when the domain genuinely belongs to somebody else — typically your customer, who wants to own their own domain. If all the domains are yours, put them all in one Cloudflare account.

The Cloudflare tab in the panel says which of the two you are in, at the top, and how many accounts it is currently talking to.

Two words you need first: site and token

Everything on this page follows from two rules Cloudflare does not bend.

A Cloudflare "site" (they also call it a zone) is ONE domain. myshop.com is one site. myapp.com is a second site, even if it is the same business. But shop.myshop.com, panel.myshop.com and www.myshop.com are all inside the myshop.com site, because they end with the same domain.

An API token can only ever see ONE Cloudflare account. There is no setting that lets a token reach into a second account. If your project's domain is in your customer's Cloudflare account and your panel's domain is in yours, one token cannot cover both — you need one token in each.

That is why the Cloudflare tab asks which part of the server you are working on before it asks for anything else:

• This panel — the address you open the panel on.
• One line per project — the addresses that project serves (its admin domain, its website domain, its websocket domain).

Each one keeps its own token, and each one shows its own Cloudflare sites. If a project has no token of its own, the panel tries the panel's token — so a normal one-account setup still needs one token, pasted once.

How many tokens do I actually need?

Short answer, in the order of "simplest first":

• One domain, with everything one level below it, is the cheapest and simplest setup there is: one Cloudflare site, one token, one place to look, and every name inside Cloudflare's free certificate. If you are still choosing your domains, choose this.
• Same Cloudflare account for everything is nearly as simple: your domains are several Cloudflare sites, but one token reaches all of them. Paste it once on This panel and every project will use it.
• Separate Cloudflare accounts (for example: the panel is in your account and the shop is in your customer's) needs one token per account. Open the project that owns those domains and paste its token there. Nothing is shared, and removing one token never touches another.

You do not have to work this out in advance. Paste one token, and the panel tells you plainly — by name — which of your addresses it can and cannot reach, and what to do about each one.

What Cloudflare is

Without it, your domain name points straight at your server. Every visitor — a real customer, a scanner, an attacker — knocks on your server's door directly, and your server's address is written in public DNS for anyone to read.

Cloudflare sits in the middle. Your domain points at Cloudflare, and Cloudflare talks to your server. Visitors never learn where your server is.

That one change buys you five things:

• Your server's address disappears. An attacker cannot aim at an address they cannot find.
• Attack traffic never arrives. Cloudflare absorbs it in their network. Your server never spends a single CPU cycle on it.
• Your photos come from nearby. Cloudflare keeps a copy of your product images and your site's CSS and JavaScript in the data centre closest to each customer. Pages open faster and your server does far less work.
• Free HTTPS at the edge, on top of the certificate this panel installs.
• Certificates without port 80. With the token connected, the panel proves a name is yours by writing a DNS record. That works through the proxy, needs no inbound port, and always produces a real certificate.

Why this server wants it

SixPanel already turns away unknown traffic as cheaply as a server possibly can — an unknown hostname gets its connection closed on port 80 and refused during the handshake on 443 — and it rate-limits floods. But those packets still reach your server: they use your bandwidth, your CPU and your connection limit. A rate limit is a shield, not a wall.

Cloudflare is the wall. It is also the only free way to keep your server's address secret once your domain is public. The health check warns you when a name still points straight at the server.

This does not change your HTTPS. SixPanel keeps issuing and renewing your certificate. Cloudflare adds a second certificate in front, for the part of the trip between the visitor and Cloudflare. You do not have to do anything about certificates on this page.

Add your site to Cloudflare

Do this once, in a browser. It takes about ten minutes plus waiting time.

1. Create a free account at cloudflare.com and press Add a site.
2. Type your domain without www and without https:// — for example myshop.com. Choose the Free plan.
3. Cloudflare reads your current DNS records and shows them to you. Check that the records for your site are there. Add any that are missing.
4. Cloudflare gives you two nameserver names. Go to the company where you bought the domain, find the nameserver setting, remove what is there, and put Cloudflare's two names in.
5. Wait. Cloudflare emails you when the change is live — usually minutes, sometimes a few hours.

Careful with your email records. If you receive email at this domain, make sure your MX records and any TXT records for mail (SPF, DKIM) came across to Cloudflare. The panel never touches them, and neither should you.

When Cloudflare says the site is Active, come back to the panel.

Create the API token

The token is how the panel changes settings and creates records for you. It is not your password and it is not a Global API Key — never paste either of those anywhere.

A token is a key to your Cloudflare site. Only create it for the domains you want the panel to manage, and delete it in Cloudflare if you ever sell the server.

Create it in the Cloudflare account that holds the domains you are about to manage. A token created in the wrong account verifies happily and then finds nothing — the panel will tell you so, by name, but it saves time to get this right first.

The same list is on the Cloudflare tab in the panel, right above the box you paste into. You do not have to keep this page open while you click through Cloudflare.

First: which of the two kinds of token are you making?

Cloudflare has two, they look identical once created, and only one of them needs an extra field. This trips people up because Cloudflare's own dashboard now offers the second kind first.

Both work perfectly with the panel and both do exactly the same job here. The difference is only in how Cloudflare lets the panel check the token: a user token is checked against your user, an Account API token can only be checked against its account, so the panel needs to be told which account that is.

The Account ID is not a secret and it is not a second password. It is a 32-character name that Cloudflare shows beside the token, and again on the right-hand side of your Cloudflare dashboard home page. Paste it into the Account ID box under the token box — the box is closed by default because most tokens do not need it, and the panel opens it for you and asks if your token turns out to be the account kind.

If you have a free choice, a user token is one field less to look after.

Then: create it

1. In Cloudflare, go to API Tokens (either place — see the table above) and press Create Token.
2. Scroll past the ready-made templates to the bottom and choose Create Custom Token → Get started.
3. Give it a name you will recognise, for example SixPanel — myshop.com.
4. Permissions. Each line is three boxes: a group on the left, a permission in the middle, and a level on the right. Leave the left box on Zone for every line below, then use the middle box's search to find the name. Press + Add more for each extra line.

Level "Edit" includes reading. You do not add a Read line as well.

Cloudflare renames these entries from time to time. If one is missing, pick the closest match — Zone WAF used to be called Firewall Services, and Cache Rules used to live under Cache Settings. Any permission you leave out simply makes those rows on the panel page say they could not be read. Nothing else breaks, and nothing you already applied is undone.

1. Zone Resources. Choose Include → Specific zone → your domain. Add a line for every domain this part of the server uses.

Prefer specific zones over "All zones". All zones is one click less and hands the panel a key to every domain in that Cloudflare account, including ones that have nothing to do with this server. A token scoped to the domains it manages can do nothing else, wherever it ends up.

1. Leave Client IP Address Filtering and TTL alone unless you know you want them. A TTL (expiry date) is supported: the panel stores the date, shows it on the page, and warns you on the Cloudflare tab and the Health tab two weeks before it runs out — because the first thing a dead token breaks is the cache purge after a deploy, silently, and after that your certificate renewals.
2. Press Continue to summary, check the line it shows you, then Create Token.
3. Copy the token. Cloudflare shows it once.
4. In the panel, open Settings → the Cloudflare tab, pick the part of the server this token is for (This panel, or the project), paste the token — plus the Account ID if it is an account token — and press Verify and save.

The panel checks the token with Cloudflare before storing it, then finds every Cloudflare site that matches the domains of that part of the server. It answers straight away with what it found — and, if one of your addresses is missing, says which one and why.

The token is kept on your own server, readable only by root, and the panel never shows it again — only the last four characters, so you can tell two tokens apart. The Account ID is stored the same way and is never sent back to your browser either. Each part of the server keeps its own token: removing one never affects another.

Two honest footnotes

Page Rules and account tokens. Cloudflare's Page Rules endpoint refuses account-owned tokens outright, no matter which permissions you gave it. So with an account token that one read always fails, and the panel says so on the zone card instead of pretending it checked and found none. Nothing is unapplied and nothing is broken: it only means that if caching misbehaves, check Cloudflare → Rules → Page Rules by hand, because a Page Rule beats every cache rule on this page. A user token reads them normally. Adding the Page Rules → Read line costs nothing either way.

Bot fight mode. The panel does not switch this on for you. It is one of the four rows you decide yourself, and the reason is specific to this product: Cloudflare cannot aim bot fight mode at part of your site — not from this panel, and not with a rule you add afterwards, because it does not run on the same engine those rules do. A 6ammart server is almost entirely app traffic: every customer, store and rider phone calls the API with a plain HTTP client, and your payment provider confirms a paid order with a machine-to-machine call. Bot fight mode can decide any of those looks automated and ask the caller to run a small piece of JavaScript first — which a phone app and a payment provider cannot do. The call then fails, and the way it fails is orders that stop arriving and paid orders that never confirm. Turn it on only if you will watch your orders afterwards, and turn it straight back off here if they stop.

There is a second, smaller reason it may not switch on at all: on the Free plan Cloudflare often refuses to set this through the API even with the permission granted, and answers with a bare "Bad Request". The panel translates that and points you at the dashboard switch instead: Security → Bots → Bot Fight Mode. On Pro and above the feature is replaced by Super Bot Fight Mode, which is configured in Cloudflare and which the panel reports as such. So the Bot Management line is genuinely optional — everything else on the page works without it.

What the page shows

When you open the Cloudflare tab you are looking at the panel itself. That view has two halves:

• the panel's own address and its settings, and
• your projects, one line each: which Cloudflare site it uses, how many of its addresses are behind the orange cloud, how many recommended settings are still waiting, and whether it has a token at all. Press Open on a line to work on that project.

A project view shows that project's domains only — and one card per Cloudflare site. A project on two separate domains gets two cards, each with its own plan, its own settings and its own state, because Cloudflare keeps them apart and so must the panel. A project on subdomains of one domain gets one card, because that really is one Cloudflare site.

Anything the token cannot reach is listed on its own, naming the address and what to do about it. Nothing on your server is broken when that appears — the panel simply cannot read or change Cloudflare for that address yet.

Set this up for me

This is the button to press. It is at the top of the page whenever anything is different from what a 6ammart site needs.

What it does, in order:

1. Reads your Cloudflare site again, right now. Not a saved copy — the live settings, the live DNS records, the live rules.
2. Works out what is different from the recommendation.
3. Shows you the list before it does anything: what it will change, in one sentence each, and what it will deliberately leave alone, with the reason.
4. Changes only the things that are different. Anything already correct is not touched at all.
5. Empties Cloudflare's copy of your site afterwards, but only if it changed something that affects caching.
6. Prints a report as the last line of the job: what it changed, what it could not change and why, and what it skipped on purpose.

It never touches anything you created by hand in the Cloudflare dashboard.

Three kinds of thing are always left alone by this button, and it says so:

• settings your Cloudflare plan does not include,
• the four rows marked "Read before turning this on" (HSTS, bot fight mode, hotlink protection and the cipher list) — those are decisions, so you make them one at a time,
• any row you told the panel to keep (see below).

There is also a Re-write every setting button, tucked behind a small heading. It writes everything again, including the settings that already match. You will almost never need it — use it only if you suspect Cloudflare did not save something.

Sync works in both directions

Every row on the page is compared with the recommendation each time you open it. When one does not match, you have two honest answers, and the page gives you a button for each:

"Fix this" — take the recommendation. The panel changes that one setting on that one Cloudflare site.

"Keep Cloudflare's value" — the other direction. You looked at the row and decided the value in Cloudflare is the one you want here. The panel:

• sends nothing to Cloudflare,
• remembers that this value is your choice,
• stops counting the row as work — the verdict at the top no longer nags,
• and never changes it in Set this up for me.

A kept value is still watched, not ignored. If somebody changes that setting in Cloudflare again later, the row goes back to saying changed in Cloudflare, because your choice no longer describes what is live. Press Use the recommendation on a kept row to undo it.

Think twice before keeping your own version of the two rules rows. They carry the rule that lets your payment provider's callbacks through and the rule that stops signed-in pages being cached. The panel warns you before it accepts a keep on those.

What the panel does for you

Each card shows one row per setting: what Cloudflare says now, what this server recommends, why it matters in plain words, what pressing Fix would do, and a switch. A short What is different right now card near the top lists only the rows that do not match, so you never have to scroll past twenty healthy rows to find the one that is wrong.

The big ones:

• The orange cloud on your website records. This is the one that hides your server. A, AAAA and CNAME records are all handled — if your storefront address is a CNAME pointing at your admin address, which is a normal way to set up subdomains, the panel follows it and switches it too. Records it does not touch are named with the reason: your mail records (Cloudflare's proxy does not apply to mail at all), the panel's own address, any record that points at a different machine, and any record Cloudflare itself refuses to proxy. If you moved your storefront or your websocket address to another server, the panel leaves that record alone and tells you why on the row.
• Cache rules for 6ammart. The most valuable item on the page. Product photos, uploads and built CSS/JS are cached hard at Cloudflare; the API, /admin, /vendor (on 6ammart that is the store sign-up funnel, not a folder), login and anything carrying a session cookie are marked never-cache. Both halves matter: caching without the second rule could show one customer another customer's screen.
• A skip rule for your payment provider's callbacks. After a customer pays, the payment company calls your server back to confirm the order. That call comes from a machine, not a browser, so a security check can quietly eat it — and the customer's money is taken while the order stays unpaid. The panel adds a rule that lets those callback addresses through, and pins it first so none of the other rules can reach them. Your app still checks every callback's signature, and nothing on those addresses is ever cached.
• Encryption between Cloudflare and your server. The panel looks at the certificate your server actually holds and picks Full (Strict) or Full accordingly. With the token connected the answer is normally Full (Strict), because the panel then issues a real certificate.
• Always use HTTPS, TLS 1.2 minimum, TLS 1.3, 0-RTT off — the safe TLS set.
• Brotli, HTTP/3, early hints — free speed.
• WebSockets on — live order updates travel over the same 443, through the proxy.
• Security level, browser integrity check, and a small blocking ruleset for paths like /wp-login.php, /.env and /phpmyadmin that no real customer ever asks for.
• Scrape Shield — hides email addresses on your pages from spam harvesters.
• DMARC — if your domain has no _dmarc record at all, the panel adds a watch-only one. It never edits a record you already have.

Four rows are marked "Read before turning this on" and are skipped by Set this up for me. Each carries the warning that explains what it can cost, and the report at the end of the bulk run names them so you know they are waiting:

• HSTS is hard to undo. Once a browser has seen it, it refuses plain http for your domain for six months even if you switch HSTS off. Turn it on only when HTTPS works on every one of your names.
• Bot fight mode cannot be aimed at part of your site, so it also sees the calls your customer, store and rider apps make and the call your payment provider makes to confirm a paid order. See the footnote above before you switch it on.
• Hotlink protection blocks images requested by other websites. If your storefront runs on a domain in a different Cloudflare site, its product photos will stop loading.
• Cipher list deletes the list of ciphers pinned on your Cloudflare site and goes back to Cloudflare's own maintained one. That is the right answer for a list copied from a blog post years ago, and the wrong one if somebody pinned it on purpose — the panel keeps no copy of the old list. Write it down first if you are not sure.

Your own rules are safe. If you added Cache Rules or WAF rules in the Cloudflare dashboard, the panel keeps them exactly as they are. It only writes rules whose description starts with sixpanel:.

If you change something in Cloudflare by hand, the panel notices. That row turns orange and says changed in Cloudflare. It never quietly puts your change back. You then have three options and the row shows all three: press Fix this to take the recommendation, press Keep Cloudflare's value to tell the panel your version is the right one here, or leave it and decide later. Press Refresh from Cloudflare any time to re-read everything.

That check also watches the order of your rules, not only their contents. A rule you dragged above the payment-callback skip in the Cloudflare dashboard would otherwise be invisible here, and it is exactly the change that stops orders confirming.

Empty Cloudflare's copy does exactly that: Cloudflare throws away the copies it holds and fetches fresh ones. Use it when you replaced a logo or a banner and still see the old one. It empties every Cloudflare site of the project you are looking at, and nobody else's. The panel also does this automatically at the end of a deploy, so a new version of your CSS is never served from an old copy.

Cloudflare plans. Three items — tiered cache, Polish and Mirage — need a paid Cloudflare plan. On a free plan the panel shows them greyed out with the reason and never tries them. Nothing is broken; you are simply not paying for them.

A Cloudflare site with no project on it. If your panel is on a domain of its own, that Cloudflare site still gets every HTTPS, speed and security setting — but the two 6ammart rule sets (the cache rules and the payment-callback and attack-path rules) are greyed out with the reason, because they describe addresses like /storage/, /payment/ and /admin that only exist where a project runs. The rows stay visible so you can see they were considered.

What stays manual

The panel does not, and should not, do these:

• Changing your nameservers at your registrar. Only you can do that.
• Buying a Cloudflare plan.
• Deleting old Page Rules. Page Rules are Cloudflare's older system and they win over cache rules. If the page says some are active and your caching behaves strangely, look at them in the Cloudflare dashboard.
• Super Bot Fight Mode on paid plans — it is configured in Cloudflare.
• Tightening DMARC from watch-only to quarantine or reject. Do that yourself, after reading a few weeks of reports, and only with your mail provider's advice.
• Your provider's firewall. That is the firewall page — the two work together: Cloudflare in front, and your provider dropping everything that did not come from Cloudflare.

Subdomains

A project that serves dash-myshop.com, myshop.com and ws-myshop.com is one Cloudflare site, not three. They all end with myshop.com, so Cloudflare keeps them together and so does the panel:

• One card, not three, listing all the addresses.
• One token covers all of them.
• The orange cloud row counts every one of those records — whether they are A records or CNAME records pointing at each other.
• The cache rules and the payment and attack rules apply to the whole Cloudflare site, which is exactly right: all the addresses are the same project.
• Empty Cloudflare's copy empties all of them.

This is the simplest layout there is, and it is also the shape the panel suggests when you create a project from one domain. If you are still choosing your addresses, choose this one.

Two different projects on one domain (project A on shop-mydomain.com, project B on store-mydomain.com) is also one Cloudflare site, and the panel handles it carefully:

• each project writes its own copy of the cache and firewall rules, matching only its own addresses;
• writing one project's rules never removes the other project's — the page says so on the row;
• Empty Cloudflare's copy on one project empties only that project's addresses and leaves the neighbour's cache alone;
• if your panel shares that domain too, the panel's own view shows the HTTPS, speed and security rows for the whole site, but leaves the two 6ammart rule rows to whichever project actually runs the shop, and names it.

What the page can tell you, and what to do about it

Every state below produces a plain sentence on the page rather than an error. This is the complete list.

If something looks wrong

"This token has no Cloudflare site for <your address>." The token is valid, but it cannot see that domain. There are only three causes, and they are worth checking in this order:

1. The domain has not been added to Cloudflare yet — do the Add your site to Cloudflare steps above.
2. The domain is in a different Cloudflare account from the one the token was made in. A token never crosses accounts. Create a token in the account that holds the domain and paste it on that project.
3. The token's Zone Resources list is missing that domain. Edit the token in Cloudflare and add it — or make a new token; the panel replaces the old one when you paste it.

"This looks like an account token…". Your token is fine. It was made under Manage Account → Account API tokens, and Cloudflare will only confirm that kind against the account it belongs to. The panel opens the Account ID box for you and puts the cursor in it — paste the 32-character Account ID from the same Cloudflare page and press the button again. Do not create a new token; the one you have is correct.

A project says "uses the panel's token". That is normal and nothing to fix: the project has no token of its own, the panel's token can see its Cloudflare site, so the panel uses it and says so. Give the project its own token only when its domains live in a different Cloudflare account.

Visitors see error 526. The encryption mode is Full (Strict) but your server's certificate is one the server signed itself. Either set that row back to Full, or — better — press Get free SSL again on the Domain & SSL page now that a token is connected, and the panel issues a real certificate.

Visitors see error 521 or 522. Cloudflare cannot reach your server. Your provider's firewall is blocking Cloudflare, or the server is down. Check the firewall page and the project's services.

Visitors see an HTTPS handshake error on one name only. That name is more than one level below your domain, where Cloudflare's free certificate does not reach. Use the hyphenated spelling the panel offers — the panel refuses to create such a name for exactly this reason, so this only happens to a record somebody added by hand.

A page shows old content. Press Empty Cloudflare's copy.

Someone is logged in as someone else. Stop and check the cache rules row — the never-cache rule must be present. Press Fix this on that row, then empty the cache. The panel writes that rule after any cache rule you added yourself, and the caching rule it writes also refuses to touch anything with a login cookie, so this needs two things to go wrong at once — but check it anyway.

Your payment provider's callback stopped arriving. Orders are paid but stay unconfirmed. The panel already writes a rule that lets the callback addresses through ahead of every other rule, so first press Set this up for me and look for the changed in Cloudflare mark on the rules row — a rule dragged above the skip in the Cloudflare dashboard is the usual cause, and the panel flags it by name.

If your provider calls back on an address 6ammart does not use, add a Skip rule for that path yourself in Cloudflare → Security → WAF → Custom rules, and put it above the others. Rules you add there are kept by the panel. Switching Browser integrity check off is a way to test the theory, not a fix to leave in place.

The panel says the token is no longer accepted. Somebody deleted it in Cloudflare, or it reached its expiry date. Nothing on Cloudflare changed and your site is unaffected — but the panel can no longer read or write Cloudflare, so it stops emptying the cache after a deploy and, more seriously, it can no longer prove your names for certificate renewal that way. Create a new API token in the same Cloudflare account and paste it. The Health tab watches for this and warns you two weeks before an expiry date.

Remove the token whenever you want. Nothing on Cloudflare changes; the panel just stops being able to read or set anything, and falls back to proving names over port 80 for certificates.