# Cloudflare

> Source: https://www.allsweb.com/sixpanel/docs/cloudflare
> Markdown for agents: https://www.allsweb.com/sixpanel/docs/cloudflare.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: SixPanel documentation

**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:

| Instead of | The panel uses |
|---|---|
| `dash.shop.example.com` | `dash-shop.example.com` |
| `ws.shop.example.com` | `ws-shop.example.com` |
| `panel.shop.example.com` | `panel-shop.example.com` |

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:

| | One Cloudflare account | Several Cloudflare accounts |
|---|---|---|
| API tokens to create | **one** | one per account |
| Where you paste it | once, on **This panel** | on each project that owns those domains |
| Tokens to renew if they expire | one | one per account |
| Where you look when something is wrong | one place | one per account |

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":

| Your setup | Cloudflare sites | Tokens |
|---|---|---|
| Everything on one domain and its subdomains (`example.com`, `dash-example.com`… ) | **1** | **1** |
| Several separate domains, all in **one** Cloudflare account | one per domain | **1** |
| Domains spread over **different** Cloudflare accounts | one per domain | **one per account** — paste it on the project that owns those domains |

- **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.

| Where you made it | What it is called | Needs an Account ID? |
|---|---|---|
| Your profile menu → **API Tokens** | a **user** token | **no** |
| **Manage Account → Account API tokens** | an **Account API token** | **yes** |

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.

   | Middle box | Level | What this one buys you |
   |---|---|---|
   | **Zone** | Read | Finds your Cloudflare site and reads which plan it is on. Without this the panel sees nothing at all. |
   | **Zone Settings** | Edit | Every switch on the page: the HTTPS mode, Always Use HTTPS, TLS 1.2/1.3, Brotli, Early Hints, HTTP/3, 0-RTT, security level, ScrapeShield, HSTS and the cipher list. |
   | **DNS** | Edit | Creates your records, keeps them proxied, and adds a watch-only DMARC record when your domain has none. It is also what lets certificates be issued by writing a DNS record instead of over port 80. |
   | **Cache Rules** | Edit | Writes the three 6ammart cache rules — cache `/storage` and the built CSS/JS hard, keep the service worker fresh, and never cache `/api`, `/admin` or anything carrying a login cookie. |
   | **Cache Purge** | Purge | Empties Cloudflare's copy of your files after every deploy, so customers get the new CSS and images instead of yesterday's. |
   | **Zone WAF** | Edit | Writes the payment-callback exemption (the most important rule on the page) and the two rules that block scanner paths like `/wp-login.php` and `/.env`. |
   | **Page Rules** | **Read** | Read only — the panel never writes a Page Rule. It reads them to warn you when an old Page Rule is quietly overriding the cache rules. See the note below. |
   | **Bot Management** | Edit | Bot fight mode. Optional, and off unless you choose it — see the note below. |

   **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.

5. **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.

6. 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.
7. Press **Continue to summary**, check the line it shows you, then **Create
   Token**.
8. Copy the token. **Cloudflare shows it once.**
9. 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](https://www.allsweb.com/sixpanel/docs/firewall) —
  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.

| What is going on | What the page says | What to do |
|---|---|---|
| The domain is not in this token's Cloudflare account | names the address, and says whether the domain is on Cloudflare at all (it checks the nameservers) | paste a token from the account that holds it, or add the domain to Cloudflare |
| The domain is not on Cloudflare at all | "its nameservers are somebody else's" | add the site to Cloudflare, change the nameservers, wait for *Active* |
| The domain does not exist yet | "does not resolve anywhere yet" | register it and set up its DNS first |
| Cloudflare is **paused** for the site | a clear note: traffic goes straight to your server, nothing is cached or filtered | un-pause it in Cloudflare → Overview. Settings still save while paused |
| The nameserver change is not finished (*pending*) | "Cloudflare is waiting for the nameserver change" | finish it at your registrar, then press Refresh |
| **Development Mode** is on | says caching is deliberately off for the next N minutes | wait, or switch it off in Cloudflare → Caching. Your cache rules are fine |
| The site is a **partial (CNAME) setup** | says so, and that the orange cloud cannot be switched from here | a full setup (Cloudflare nameservers) is simpler if you can |
| Your Cloudflare plan is too low for a row | greyed out, names the plan needed | nothing — it is skipped, never attempted |
| A record points at a different machine | greyed with the address it points at | fix the DNS record, or leave it if that is on purpose |
| Cloudflare will not proxy a record | greyed, "Cloudflare does not offer the orange cloud for this" | usually a partial-setup site |
| A name is deeper than one level below the domain | refused, with the hyphenated spelling that works | use the name the panel offers |
| A rule you wrote sits in the same phase | kept, in your order — and if one moved above the payment skip or below the never-cache rule, the row says so | press *Fix this* to put ours back in place; yours keep their order |
| The token **expired or was deleted** | says the token is no longer accepted, not that Cloudflare is down | create a new token and paste it |
| The token expires soon | warns 14 days ahead, on this page and on the Health tab | make a new one now; a token with no expiry never needs this |
| The token lacks a permission | says Cloudflare refused the request | edit the token in Cloudflare and add it |
| You pasted an account token with no Account ID | asks for the Account ID and opens the box — it does **not** call your token invalid | paste the 32-character Account ID shown beside the token |
| The old **Page Rules** could not be read | says so on the site's card, and why | nothing, unless caching misbehaves — then check Cloudflare → Rules → Page Rules by hand |
| **Bot fight mode** will not switch on after you chose it | the panel names the Free-plan API refusal and points at the dashboard | switch it on in Cloudflare → Security → Bots, and watch your orders afterwards |
| No project runs on that Cloudflare site | the two 6ammart rule rows are greyed with the reason | nothing — everything else still applies |
| The **payment-callback rule is missing** and you try to switch on *Security level* or *Browser integrity check* | the panel refuses and names the addresses that are unprotected | apply the payment-callback row first. Those two settings apply to your whole Cloudflare site, and without the exemption a customer can pay and the order never confirms |

## 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](https://www.allsweb.com/sixpanel/docs/firewall) 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.