Edge Routing · WP Engine

Fix a WP Engine site that Cloudflare bypasses

Worker installed, heartbeat healthy, but it never handles a request? On WP Engine that is almost always the apex DNS record. Two records fix it, with no downtime and an instant undo.

What is happening

WP Engine serves your site through its own Cloudflare network. When your own Cloudflare zone points the apex (your-domain.com) at WP Engine with A records, Cloudflare hands the hostname straight to WP Engine's network. Your zone still answers DNS, but nothing configured in it — routes, Workers, firewall rules — is in the request path. The NORG worker is installed and alive (its scheduled heartbeat still fires), yet it never sees a visitor.

Cloudflare's supported way to run your zone in front of WP Engine's is called Orange-to-Orange (O2O), and it only engages for a proxied CNAME record — in Cloudflare's words, "it does not apply when an A record is used". Once the apex is a proxied CNAME to WP Engine's O2O target, your zone runs first (where the worker lives) and WP Engine serves the site exactly as before. It works on every Cloudflare plan, including free.

How to tell this is your situation

In Cloudflare, open DNS → Records for your zone and look at the apex rows (Name shows as @ or your bare domain). This is the shape that causes the problem:

Type    Name   Content                 Proxy status
A       @      141.193.213.10          Proxied
A       @      141.193.213.11          Proxied
CNAME   www    yoursite.wpenginepowered.com   Proxied

141.193.213.10 / .11 are WP Engine's Advanced Network addresses; Global Edge Security accounts use 141.193.213.20 and 141.193.213.21 instead. Either way, an A record at the apex is the tell. You can also confirm who serves the site from a terminal:

curl -sI https://your-domain.com/ | grep -i x-powered-by
# x-powered-by: WP Engine
1

Back up the zone first (2 minutes)

Nothing below is risky — the public DNS answer does not change and the undo is instant — but take the backup anyway so the exact records are never in doubt.

  1. In Cloudflare go to DNS → Records and click Export. This downloads the whole zone as a text (BIND) file. Keep it somewhere safe.
  2. Write down or screenshot the apex A records exactly as they are: type A, name @, both IP addresses, and that they are Proxied. Step 4 puts these back if needed.

Prefer a terminal? The same export via the API (a token with DNS: Read on the zone):

curl -s -H "Authorization: Bearer $CF_TOKEN" \
  https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export \
  > your-domain.com-backup.txt
2

Make the change (apex only)

Only the apex changes. Leave www, MX, TXT and every other record exactly as they are.

StepTypeNameContentProxy
DeleteA@141.193.213.10—
DeleteA@141.193.213.11—
AddCNAME@wp.wpenginepowered.com (Advanced Network) — or your GES targetProxied

Cloudflare will not let a CNAME sit beside an A record with the same name, so delete the two A records first, then add the CNAME:

Type:    CNAME
Name:    @                        (the apex — your-domain.com)
Target:  wp.wpenginepowered.com   (Advanced Network)
         — or your own GES target from WP Engine, e.g. xxxx.wpeproxy.com
Proxy:   Proxied (orange cloud)

Which target? If your A records were 141.193.213.10 / .11 you are on WP Engine's Advanced Network and the target is wp.wpenginepowered.com. If they were 141.193.213.20 and 141.193.213.21 you are on Global Edge Security: use the CNAME WP Engine gives you in User Portal → Domains → View DNS Details (it looks like xxxx.wpeproxy.com).

Why this is safe. Both before and after, the apex is a proxied record in the same zone, so visitors keep resolving the same Cloudflare addresses. There is nothing to propagate and no downtime; only Cloudflare's internal routing changes, which is exactly what switches O2O on. Cloudflare flattens a CNAME at the apex automatically on every plan.

3

Verify (within a minute)

  • Open the site in a private browser window. It should look and behave exactly as before.
  • From a terminal, ask for a path only the NORG worker answers. Before the change this prints nothing; after it, the worker's header appears:
    curl -sI https://your-domain.com/.norg/theme.css | grep -i x-norg-edge
# x-norg-edge: ...   ← the NORG worker answered
  • In NORG, run cdn_install_status (or ask your NORG contact to run a route check). It should report the route reaching the worker and the install as live.
4

Undo if anything looks wrong

Signs you want to undo: a Cloudflare error page (1014, 1001 or 1016), or a certificate warning on the site right after the change. Both mean the CNAME target does not match your WP Engine network — see troubleshooting. The undo is as instant as the change was:

Delete:  CNAME  @   wp.wpenginepowered.com
Add:     A      @   141.193.213.10   Proxied
Add:     A      @   141.193.213.11   Proxied
  1. In DNS → Records, delete the CNAME @.
  2. Add the two A records back exactly as in your backup — type A, name @, each IP, Proxied.

The exported file is your reference. Cloudflare's Import button can re-create records from it, but Import only adds — it never deletes — so the CNAME must be removed first, and the two-record re-add above is the simpler path.

Never done a DNS restore in Cloudflare before? This short walkthrough shows both the export and the restore from that file, step by step: How to Backup and Restore DNS Records in Cloudflare (video) →

Troubleshooting

  • Error 1014 / 1016 right after the change — wrong target for your network type. Undo (step 4), check the network in WP Engine's User Portal → Domains, and use that target.
  • www points at something.wpenginepowered.com — that site-specific hostname is not an O2O target, so www still bypasses your zone. It only matters if www is the host visitors actually use; most WP Engine sites redirect it to the apex, which is what this guide fixes. If www is your real host, point its CNAME at the same target as the apex.
  • Site still loads, but no x-norg-edge header — confirm the CNAME is orange-clouded (Proxied) and that the NORG route your-domain.com/* still exists under Workers Routes.
  • WP Engine's own bot protection keeps applying to normal visitors and to health checks — that is expected and fine. AI agents are answered by the NORG worker on the first hop and never reach it.
  • Free Workers plan — the account-wide 100,000 requests/day cap now applies to your traffic. See Upgrade to Cloudflare Workers Paid.

Coming soon

The NORG installer will detect this apex shape during its checks and offer to make the change for you, verify it, and undo it automatically if the route does not come up. That path needs one extra permission on the Cloudflare token — DNS: Edit — which can be removed again afterwards. Until then, the steps above are the supported route. For the full install guide see Install a Cloudflare Worker mirror →