Cloudflare error 1002 has prohibited-IP and restricted variants. Keep the complete message and compare the affected DNS record with the origin destination confirmed by the hosting provider. A populated record can still contain a Cloudflare edge IP, incorrect CNAME target or unsupported destination.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Identify the prohibited or restricted DNS target
| Evidence | Check | Repair direction |
|---|---|---|
| Prohibited IP message | Configured target and provider instructions | Use the verified origin destination |
| Restricted message | Whether the address belongs to the supported setup | Have the provider confirm the origin |
| CNAME record | Exact target and custom-domain process | Verify target and service association |
| Server-side request only | Internal versus public request path | Ask the hosting administrator to review resolution |
Compare the record with your provider’s instructions
Find the affected hostname and its relevant A or CNAME record. Ask the current hosting provider to confirm the origin IP or target hostname for this installation. Use that confirmed information for the comparison.
An A record holds an address, while a CNAME points to another hostname. Cloudflare lists a record pointing to a Cloudflare IP and an incorrect CNAME target among documented causes. Looking only at whether the DNS panel contains a value will miss those differences.
For example, a site owner may copy the IP returned by a lookup of a proxied public domain. That value can represent Cloudflare’s edge rather than the WordPress host. Copying it into the ordinary origin record is not a shortcut to the server.
Review the “Restricted” message in its own context
Cloudflare describes the restricted version in connection with a local, disallowed, or unrelated address. A private address copied from a local development setup is not automatically a supported public origin for a conventional hosted site.
Do not substitute a random public address simply to avoid the message. The destination needs to belong to the installation and be configured by the responsible provider. A different response from someone else’s server would not restore your site.
If your architecture uses a managed platform or another supported connection method, have its maintainer verify that arrangement. A simple A-record recipe should not be imposed on a setup that requires a provider-managed custom domain.
Check a CNAME connection beyond its spelling
A CNAME target should match the provider’s instructions exactly, but spelling is only one part of the review. The provider also needs to support your custom domain at that target. Cloudflare documents unsupported relationships between an external domain and a Cloudflare domain as another possible context for 1002.
Give the provider the affected hostname and current target. Ask it to confirm the intended domain-connection process rather than copying a platform address from an unrelated website.
Keep the old record and the provider’s verified correction in your notes before changing anything. This makes the adjustment reversible and gives support a clear record of what was tested.
Include server-side resolution only when it is relevant
State whether the failure is a browser visit or a request from the hosting server to its own public domain. Those paths can use different resolution arrangements. Give the administrator that context before adjusting local resolution or proxy handling.
Cloudflare’s support guidance also discusses how an origin resolves requests to its own Cloudflare-proxied domain. If the error occurs in a server-side request rather than an ordinary visitor request, tell the hosting administrator that distinction.
The administrator can review the internal and public destination arrangement for that server. Do not edit local resolution or proxy configuration without understanding the intended path. A hosting-specific loopback design is a separate task from correcting the public DNS record.
Confirm the domain reaches the intended site
After a supported correction, open the exact hostname that failed and an ordinary WordPress page beneath it. Check the actual content. The disappearance of 1002 is useful evidence, but the site must still be the intended installation.
Check the root and www hostnames if both are part of the setup. A successful request to one does not verify a separate record used by the other. Note any unexpected redirect to an old provider address.
If another error appears, keep its complete message and investigate that next stage separately. The DNS correction may have restored the path to a server that now reports a different problem.
For a continuing 1002, give support the complete error text, affected hostname, record type, sanitized target, provider-confirmed destination, and recent changes. Those details focus the review on the actual record instead of sending you through unrelated plugin or database changes.
Reference: Cloudflare error 1002 documentation.
Record the corrected DNS record and provider destination
Retest the exact hostname, an ordinary article and expected root/www behavior. Confirm your WordPress installation appears. Preserve any new error as evidence of the next stage. If 1002 remains, provide the complete variant, record type and verified destination for support review.