Views: 100

Error 1003 Direct IP Access Not Allowed (Cloudflare)

Error 1003 means a request hit Cloudflare by raw IP, not the hostname. Check the client, DNS proxy state, and origin exposure in 3 steps. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

You get a Cloudflare error page: Error 1003, Direct IP access not allowed, served with an HTTP 403. Here’s the thing to understand first — this error does not come from your server. It comes from Cloudflare’s edge, and it fires for one specific reason: something addressed a Cloudflare IP by its raw numeric address instead of by a hostname. Cloudflare’s edge is shared infrastructure. A single anycast IP fronts millions of different sites, and Cloudflare figures out which one you want from the Host header of your request. Send a bare IP with no usable hostname and there’s no zone to route to. So it stops you with 1003. The fix is almost never on the origin — it’s wherever the raw IP got used.

Symptoms

  • The Cloudflare interstitial reads Error 1003 / Direct IP access not allowed, returned as HTTP 403.
  • The same site loads perfectly through its normal domain name in a browser — only the IP-addressed path fails.
  • It shows up in scripts, monitors, webhooks, or API clients while human traffic is unaffected.
  • Switching your network, IP, or VPN makes no difference, because the error isn’t about your IP’s reputation.

Top 3 Causes

  1. A client hardcoded an IP instead of the hostname - The overwhelmingly common cause. An API client, uptime monitor, cron job, CI step, or webhook was configured with a numeric IP — sometimes a stale origin IP that now resolves to Cloudflare, sometimes a Cloudflare edge IP copied from a dig result. It connects, sends the IP as the host, and Cloudflare has nothing to route it to. Browsers don’t hit this because they always carry the hostname.
  2. Someone browsed to the IP directly - A bookmark, a copied link, or a person typing https://104.x.x.x/ into the address bar. The connection lands on a Cloudflare edge with an IP for a host, and 1003 comes straight back. Harmless, but it generates support tickets.
  3. A server-to-server integration pinned the wrong address - A plugin, health check, or internal service configured to call the origin “by IP for speed” ends up hitting a Cloudflare IP (because the record is proxied) and fails. Note the precise boundary: 1003 only happens when the IP you contacted belongs to Cloudflare. If you hit your true origin IP directly — say the record is DNS-only — you bypass Cloudflare entirely and won’t see 1003 at all; you’ll reach the origin (or its own error). 1003 is specifically the edge saying “you addressed me by number.”

Diagnose with DechoNet

  • HTTP Check against the hostname should return the site’s real response. If the hostname works and only the IP fails, you’ve confirmed the site is healthy and the raw IP is the entire problem — now hunt down whatever is using it.
  • DNS Check shows what the hostname resolves to. A proxied record returns Cloudflare’s anycast ranges (for example 104.16.0.0/13 or 172.64.0.0/13). If a client hardcoded one of those, that’s your 1003 source — and it’s why the address looks like “your server” but answers as Cloudflare.

Resolution Checklist

  • Find what used the IP. Search app configs, monitoring, webhooks, CI, and cron for the numeric address that’s failing. That’s where the fix lives.
  • Replace the IP with the hostname everywhere — API base URLs, monitor targets, webhook endpoints, bookmarks. Cloudflare routes by Host; give it a real one.
  • If a server-to-server call must pin an IP (rare, and usually a mistake), send the correct Host header and SNI for the real hostname, and pin the origin’s IP, not a Cloudflare edge IP. Better: resolve the hostname so anycast can pick a healthy edge.
  • Confirm with curl -I https://yourdomain.com (works) versus curl -I https://CLOUDFLARE_IP (1003). The contrast proves the diagnosis in two commands.
  • If you actually want to block direct IP access to your origin — the healthy default — lock the origin firewall to Cloudflare’s published IP ranges and enable Authenticated Origin Pulls. Then IP-level probes never reach your server, by design.

When to Escalate

  • If you’ve removed every hardcoded IP and legitimate traffic still trips 1003, capture the exact request — the Host header is the tell. An empty or IP-valued host is the smoking gun and points straight at the misconfigured client.
  • If a third-party integration you can’t edit insists on connecting by IP, that’s the vendor’s bug to fix; give them the hostname and the --resolve pattern rather than exposing your origin IP to make their shortcut work.
  • If you’re seeing 1003 where you expected a different Cloudflare error — a WAF block (1020), a rate limit (1015), or an IP ban (1006–1008) — you’re diagnosing the wrong thing. 1003 is only ever “you addressed the edge by IP.” The others are policy decisions about who you are, not how you connected.

Related Tools

Related Guides

Share this guide

[Ad] Guide Detail Inline
← Back to All Guides