Cloudflare error 1004 says the host is not configured to serve web traffic. Review recent DNS or activation changes, the provider-confirmed origin destination and any actual account notice. A Cloudflare edge address copied from a public lookup is different from the hosting origin an ordinary WordPress record should identify.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Verify the hostname’s proxy and origin destination
| Clue | Inspect | Next step |
|---|---|---|
| Started after a DNS edit | Record and current provider instructions | Verify the intended origin |
| Copied a public lookup IP | Whether it is an edge address | Obtain the hosting destination from the provider |
| Recent activation | Configuration and change time | Check correctness while reviewing propagation |
| Account notice exists | Specific restriction and review instructions | Follow the service’s account process |
Start with the last domain change
Write down when the error began and what changed shortly beforehand. A new activation, DNS edit, provider move, or account change is useful context. Keep the affected hostname exact; a root domain and a www address can have different records.
For example, a hosting move might include copying a DNS result from the old public site into a new A record. That result may be a Cloudflare edge address rather than the actual hosting destination. A populated record can therefore look convincing while representing the wrong part of the connection.
This is an example to inspect, not a diagnosis based solely on the error code. Compare the record with the origin details supplied by the current provider.
Confirm which destination belongs in DNS
Compare source and value. Record whether the destination came from the hosting provider or from a lookup of a proxied public hostname. For a conventional origin, verify the provider-issued address. For a managed custom-domain service, use its supported connection instructions instead of forcing a generic record.
For an ordinary hosted WordPress site, use the hosting provider’s verified destination. Do not assume that an IP returned when looking up a proxied public domain is the server where WordPress runs.
Cloudflare’s edge and your hosting origin play different roles. Visitors can reach the edge, which then connects to the configured destination. Copying an edge address back as the ordinary origin record can create a configuration problem instead of connecting the installation.
Save the existing record and obtain the provider’s current instructions before correcting it. If the provider uses a supported custom-domain arrangement rather than a conventional origin IP, follow that arrangement’s instructions instead of forcing an A-record solution.
Check account notices without assuming a violation
Cloudflare’s reference includes staff-disabled proxying as another possible cause. That does not mean every site displaying 1004 has violated a policy. Review any actual account notices and distinguish them from guesses based on a general error article.
If a notice identifies a restriction, follow the review process described by the service and keep the relevant message for support. Repeatedly changing DNS records cannot necessarily resolve an account-side restriction.
Likewise, a recently changed configuration can take time to be reflected, but waiting should be paired with checking that the configuration is correct. Cloudflare’s 1004 support page recommends contacting support if the problem persists beyond five minutes.
Give support a small, clear record of the failure
Include the exact hostname, first failure time, last configuration change, relevant record, provider-confirmed target and any actual notice. State observed facts separately from conclusions. Cloudflare’s support reference recommends escalation when 1004 persists beyond five minutes; do not treat that as a guarantee that every valid setup recovers within that time.
Prepare the affected domain, exact hostname, failure time, recent configuration changes, and error screenshot or Ray ID where shown. Include the provider-confirmed destination and the relevant record type. Keep account credentials out of the report.
Describe what is known: whether the site was newly activated, which record changed, and whether an account notice exists. Avoid adding unsupported conclusions about WordPress corruption or a policy violation.
If a provider created the connection for you, ask it to review that setup. The party controlling the domain connection may have information unavailable from the WordPress dashboard.
Verify the corrected public address
After the responsible administrator makes a supported correction, open the original hostname and an ordinary page beneath it. Confirm that the content is your intended WordPress installation rather than a temporary provider screen.
Check the expected root and www behavior if both are used. A successful alternate hostname is not a substitute for the address that originally failed.
If another error replaces 1004, preserve the new message. The configuration may now reach the next stage of the request, which deserves its own investigation. Keep the final verified domain connection in your hosting notes so that a future migration does not repeat an old edge-address mistake.
Reference: Cloudflare error 1004 documentation.
Record the provider-confirmed origin and proxy state
Check the failed hostname and an article beneath it, then root and www behavior where used. Confirm the final content belongs to your installation. If a different error appears, record it as the next connection stage. Retain the verified domain and origin configuration for the next migration.