Cloudflare Error 1003: Direct IP Access Not Allowed. Use the Hostname

Cloudflare's text is short: "This error indicates that direct access to a Cloudflare IP address is not allowed", caused when "a client or browser directly accesses a Cloudflare IP address" (Cloudflare: Error 1003). The page title reads "Direct IP access not allowed", and the HTTP status is 403; the 1003 code is in the page body (Cloudflare 1xxx errors).

The reason is how Cloudflare works. Millions of websites share the same anycast addresses, and Cloudflare decides which site you want from the host name: the Host header for HTTP and the SNI field for HTTPS. A request to http://104.16.x.x/ carries an IP where the host name should be, so Cloudflare has no site to serve and answers 1003 instead. Nothing is broken on the website; the request is addressed wrongly.

A reverse lookup of the IP or a WHOIS on it shows Cloudflare as the owner, which confirms you are talking to the edge rather than to a site's server.

1. Use the hostname. https://www.example.com/, never https://104.16.x.x/. For a visitor this is the whole fix.
2. To force a specific edge IP (for debugging, or to test a data center), keep the hostname and override resolution, so the request carries both the right SNI and the right Host:

   curl -sv --resolve www.example.com:443:104.16.0.1 https://www.example.com/ -o /dev/null

   A manual -H 'Host: www.example.com' on an IP URL fixes HTTP but not HTTPS, because the TLS layer then sends no SNI.
3. In application code, replace IP literals with hostnames. If you need fixed addresses for allow-listing, allow Cloudflare's published ranges instead of single IPs.
4. To reach your origin without Cloudflare, use the origin server's own IP (from the hosting panel, not from dig, which returns Cloudflare for proxied records) with --resolve, or a separate DNS-only hostname.
5. On a local machine, a hosts-file line such as 104.16.0.1 www.example.com works because the browser still uses the hostname; an IP in the address bar does not.

Automated clients are the most common source of 1003 after a site moves behind Cloudflare. Before the move, a monitor or partner integration pointed at the server's IP worked; after it, the old IP may still be the origin, while anything that was re-pointed at the new DNS answer now targets Cloudflare's addresses. Check three places. Uptime monitors and load-balancer health checks: they must request the full URL with the hostname, otherwise every check reports 403 while real visitors are fine. API clients and webhooks configured with an IP literal: replace it with the hostname, and if the partner needs fixed addresses for their own firewall, give them Cloudflare's published ranges. Embedded devices with an IP in firmware: these fail all at once and are slow to update, so keep a DNS name in the configuration from the start. In every case the request must carry the hostname both in the TLS handshake and in the HTTP Host header.

curl -s -o /dev/null -w '%{http_code}\n' http://104.16.0.1/
# 403
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/
# 200

The first request shows what any bare-IP request gets; the second, with the hostname, must return the site. For monitors and integrations, check their logs for 403s after the change. The HTTP status checker requests a URL by name and shows the status code and headers it receives.

• Cloudflare 1020 Access denied — blocked by a firewall rule
• Cloudflare 1015 — rate limited
• Cloudflare 1016 — the origin hostname does not resolve
• 403 Forbidden — the status that carries 1003
• SNI — how the host name travels in the TLS handshake