When visitors see Cloudflare error 1034 after a hosting or provider change, verify the domain’s destination and provider registration. The code concerns an IP restricted by Cloudflare edge validation. A working WordPress installation can remain unreachable if DNS or a previous service association sends traffic to infrastructure the domain is not authorized to use.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Confirm the domain’s authorized destination
| Configuration | Evidence to compare | Responsible next step |
|---|---|---|
| Ordinary WordPress hosting | Provider-issued destination against the affected DNS record | Confirm the current hosting target |
| Cloudflare for SaaS | DNS instructions and provider domain validation | Ask the platform to verify registration |
| Prior account or service migration | Previous address-map association | Have the account owner or provider review it |
| Intentionally originless service | Its documented architecture | Use setup-specific instructions |
Confirm the destination your provider expects
Check each hostname separately. Record the provider’s required destination for the apex domain and any used subdomain. A public lookup of a proxied record may show Cloudflare edge addresses, so it is not a substitute for reading the configured origin record and provider instructions. Keep migration notes alongside the comparison.
Open the current provider’s domain-connection instructions and record the required hostname or IP address. Compare that information with the DNS record for the affected hostname. Be careful to compare the homepage hostname and any relevant subdomain separately; they may use different records.
A practical example is a site moved from a managed platform to an ordinary WordPress host. If a record still contains a destination copied from the former platform, the new WordPress installation may be working while visitors continue toward the old service. The recent move is useful context, but the record needs to be checked rather than assumed to be wrong.
Do not copy an IP address from another site just because it loads successfully. Hosting destinations should come from the provider managing your site, and shared infrastructure may require the domain to be registered with that provider as well.
Distinguish a normal origin from an originless setup
Cloudflare documents 1034 for configurations that previously pointed domains to 1.1.1.1. An ordinary WordPress site needs its actual hosting destination. A placeholder is not a replacement for the server where WordPress runs.
Cloudflare separately documents placeholder addresses for intentionally originless configurations. That is a different design, such as a service that does not rely on a conventional hosting origin. If your site uses one, review its specific setup instructions with the maintainer rather than applying a placeholder to a normal WordPress record.
This distinction avoids a repair that only changes the error screen. The intended result is a domain that reaches the right service, not merely a different address that passes one configuration check.
Review provider validation and previous service connections
A useful support question is: “Does this hostname still belong to a previous service’s address map, or is its domain registration incomplete on the current platform?” Include the former and current providers and the change time. The responsible account owner should confirm the association before changing it.
With a Cloudflare for SaaS provider, confirm that the domain has been registered and validated on the provider’s platform and that its DNS matches the provider’s instructions. A correct-looking IP alone may not complete the connection.
Cloudflare also describes account-related edge IP restrictions involving BYOIP address maps. A domain moved between accounts or away from a third-party service can retain an association that needs review. If those terms are unfamiliar and your site uses standard hosting, ask the provider whether this situation applies before changing advanced networking settings.
Keep a short timeline of the move: former provider, current provider, date of the switch, and the first observed error. That helps support staff connect the domain with any old configuration without requiring you to speculate about the network.
Make one supported correction and check the site
Save the existing DNS configuration before correcting a destination confirmed by the provider. If the problem is provider-side domain validation or an address-map association, give the relevant provider the evidence so that the responsible account can be reviewed.
After the change, check the affected hostname and an ordinary WordPress page beneath it. Verify the content belongs to your site. A successful response from an unrelated destination would not be a valid repair.
Include the login page or a harmless form test if those are part of the site’s normal use. A homepage returning correctly does not show that every hostname or application path was connected as intended.
If 1034 remains, share the domain, current provider’s required destination, relevant DNS record, recent change timeline, and any Ray ID from the error page. Account-specific restrictions may require the provider or Cloudflare to inspect information you cannot see from WordPress.
Keeping the verified domain-connection details beside your hosting notes makes the next migration easier. It also reduces the chance that a retired provider’s destination is reused when someone later recreates a DNS record.
Reference: Cloudflare error 1034 documentation.
Confirm the connection is to your site
Open the affected hostname and an article underneath it. Verify the content, relevant login or form workflow, and any separately configured subdomain. If 1034 persists, send the provider the required destination, actual record, change timeline and error evidence. Preserve the corrected connection details for the next migration.