How to Fix Cloudflare Error 1034 (Edge IP Restricted)

By ErrorFix · Updated October 23, 2026 · 5 min read

What Cloudflare Error 1034 means

Cloudflare's 1xxx family covers DNS, proxy, and security-configuration problems, and Error 1034 sits in the DNS corner. The page reads "Edge IP Restricted" and serves an HTTP 403, with a Ray ID printed at the bottom. The plain-English version: your domain's DNS record points at an IP address that Cloudflare's edge IP validation considers restricted — an address reserved for specific Cloudflare accounts, such as BYOIP prefixes, dedicated or static IP allocations, or other customer-associated ranges. Cloudflare checks whether incoming traffic to those IPs is associated with an authorized account before allowing the request through. If it is not, the edge refuses the request instead of serving the site.

The classic trigger is a domain pointed at 1.1.1.1. Some people set their A record to 1.1.1.1 years ago as a placeholder, and after Cloudflare tightened edge validation, those domains started showing the 1034 page. The same thing happens after migrations, when a record still points at a previous host's IP or at a Cloudflare-owned address from a different setup. Because the decision happens at Cloudflare's edge before any request reaches an origin server, the block is total: nobody can load the site until the DNS records are corrected.

Common causes

• The A record points to 1.1.1.1 or another Cloudflare-owned address: the most common trigger. Someone set the record to 1.1.1.1 as a placeholder or by mistake, and Cloudflare's edge IP validation now rejects the domain because that address belongs to Cloudflare itself, not to the account. Any Cloudflare-owned or restricted address in the record produces the same page.
• Stale records left behind after a host migration: moving a site to a new platform or host changes the correct origin IP, but the old A record often survives. If the old IP was reassigned into restricted space — or the record was never actually an IP you controlled — the domain starts showing 1034 after the move, sometimes days later as caches expire.
• A placeholder IP in an originless setup: parked domains, redirect-only setups, and sites mid-migration sometimes point at a dummy address just to have a record. If that dummy address falls in restricted IP space, edge validation blocks it. Cloudflare's documented placeholders are 192.0.2.0 (IPv4) and 100:: (IPv6), not 1.1.1.1.
• BYOIP or dedicated IP misconfiguration: the deeper case from Cloudflare's docs. Edge IP Validation exists to protect restricted IP space — BYOIP prefixes, dedicated or static IP allocations — so that only traffic for the owning account is accepted. If the domain points at one of these addresses but the account association is wrong, 1034 is the expected answer.
• A record edited on the wrong DNS provider: when DNS is managed outside Cloudflare — a registrar, another DNS host, or a platform that manages records on the site's behalf — the fix has to happen there. Editing records inside the Cloudflare dashboard while another provider actually answers DNS queries changes nothing, so the 1034 page persists and the real cause looks mysterious.

How to fix Error 1034 — step by step

Step 2 is for visitors. Steps 3 through 6 are for site owners.

1. Confirm the page is really Error 1034, not a lookalike Cloudflare block. Cloudflare's Error 1034 page reads Edge IP Restricted, serves an HTTP 403, and prints a Ray ID at the bottom. That wording matters because several neighbors look similar: 1000 and 1002 mean the DNS points to a prohibited IP in general, 1009 bans your country or region, 1014 bans a CNAME that crosses into another account, 1020 matches a custom WAF rule the owner wrote, and the 5xx family (521, 522, 523) means Cloudflare reached the edge but the origin server failed. If the page says Edge IP Restricted, these steps apply; if it says anything else, look up that exact code instead.
2. Visitor: accept that only the site owner can fix this — capture the Ray ID. Error 1034 is a DNS-misconfiguration block on the owner's side, so no visitor-side trick — clearing cache, switching browsers, disabling a VPN, or flushing DNS — will clear it. The fastest useful move is to copy the Ray ID and the IP address shown at the bottom of the error page, then contact the site owner through their contact email, social accounts, or support form. Tell them you are seeing Cloudflare Error 1034 (Edge IP Restricted), include the Ray ID, and ask them to check that the domain's A and AAAA records point to IP addresses they control. The Ray ID lets the owner find the exact blocked request in their Security Events log.
3. Owner: open the domain's DNS records in the Cloudflare dashboard. Log in to the Cloudflare dashboard, select the domain showing the error, and go to DNS, then Records. Look at the A and AAAA records for the root domain and for www. Error 1034 almost always comes from one record pointing at an address the account is not authorized to use — most often 1.1.1.1, another Cloudflare-owned address, or a leftover IP from a previous host. Note each record's current content before you change anything, so you can roll back if needed.
4. Owner: repoint the A record at an IP address you actually control. Edit the offending A record and replace its content with the real public IP address of your origin server — the web host's IP, shown in your hosting control panel. Delete any record that still points to 1.1.1.1 or to a Cloudflare-owned address. If the AAAA record has the same problem, fix it the same way. Keep the record proxied (the orange cloud) if you want Cloudflare's protection; the restriction is about the underlying IP, not the proxy setting. DNS changes usually take effect within minutes, though some resolvers cache longer.
5. Owner: for originless or placeholder setups, use the documented reserved addresses. If the domain intentionally has no origin yet — a parked page, a redirect-only setup, or a placeholder during a migration — Cloudflare's own documentation says to use the IPv4 reserved address 192.0.2.0 or the IPv6 reserved address 100:: instead of 1.1.1.1 or any other Cloudflare address. Set the A record to 192.0.2.0 (or AAAA to 100::) and leave it proxied. These documentation addresses exist precisely so edge IP validation passes while the site has no real origin.
6. Owner: after a host migration, verify the new records actually took effect. Error 1034 frequently survives a migration because the old record was never replaced or the new one never saved. In the dashboard, confirm the A record shows exactly the IP addresses your new host gave you, with no stale entry left beside it. Then check from the outside with an online DNS lookup tool or nslookup / dig on your own computer: the answers for your domain should match the new IPs. If the lookup still shows the old address, you are looking at cached DNS or an unsaved change, not a new problem — wait out the record's TTL and recheck.

Did this fix it? Quick checklist

• The error page says Edge IP Restricted — you confirmed it is Error 1034, not 1000, 1002, 1009, or a 5xx origin error
• As a visitor, you sent the site owner the Ray ID and IP from the error page and asked them to check the domain's DNS records
• As the owner, every A and AAAA record points to an IP you control — no 1.1.1.1, no Cloudflare-owned address, no stale IP from an old host
• An external DNS lookup returns the new IPs, and the site loads without the 1034 page after the record's TTL expires

If the error persists after the DNS looks right everywhere, the restriction may be tied to a BYOIP prefix or a dedicated IP allocation on the account — that is the deeper Edge IP Validation case from Cloudflare's docs. Contact Cloudflare support with the Ray ID; only they can confirm whether the IP your domain points at is restricted for your account. And if you run the site through a platform that manages DNS records on your behalf, check their side too: a record they maintain can quietly reintroduce the old IP after you fixed it.