The page is almost aggressively plain. A heading, "Access Denied", one sentence, "You don't have permission to access "http://www.example.com/" on this server.", and a line that reads like a serial number: "Reference #18." followed by three groups of hexadecimal characters. No logo, no explanation, no button. It appears on airline sites, big retailers, banks, ticket sellers, and government portals, often on a device that loaded the same site yesterday.
The design is the clue. The site's own error pages have the site's branding. This one has none, because it did not come from the site. It came from Akamai, the content delivery and security network that sits in front of the site, and it means Akamai refused the request before the site's servers ever saw it. The "permission" wording is a template. The reference number is a log key. And the reason you were refused is, in most cases, the address you arrived from or the shape of the request, neither of which has anything to do with permission in the usual sense.
Where the page comes from
Akamai delivers a large share of the world's biggest sites, and it sells them a security layer: a web application firewall, bot detection, rate limiting, and geographic controls. Every request to such a site passes through an Akamai edge server first. When one of the site's rules matches the request, the edge answers with this page and logs the event under the reference number, and the site's origin never learns the request existed.
That order matters for what you can do about it. You cannot fix a rule you cannot see, and the site's support staff cannot always see it either, since Akamai's configuration is usually run by a security team. What everyone can see is the reference number, which is why the single most effective thing a stuck visitor can do is send it.
Your browser
sends the request
Akamai edge
rule matches: Access Denied, Reference #18
The site's servers
never reached
The rules that produce it
The denial is one of a handful of rule types, and the pattern of when it appears tells you which.
An address rule. Akamai keeps reputation data on addresses and networks, and sites can deny traffic from VPN exits, proxy services, Tor, hosting providers, and addresses that have recently been used for scraping or fraud. A person on a VPN inherits the score of every other customer on that exit; a person on a mobile carrier can inherit the score of the thousands sharing the carrier's address (our explainer on CGNAT covers that sharing). The tell: the page appears with the VPN on and not off, or on one network and not another.
A geographic rule. Sites deny regions they do not serve. A VPN exit in that region, or a real visit from it, gets the page. The tell: it appears from one country's address and not another's.
A bot-detection verdict. Akamai's Bot Manager scores the request itself: the TLS handshake, the order and content of headers, whether the browser ran Akamai's sensor script and returned its cookies, and how quickly pages are being requested. Automation tools, very old browsers, extensions that strip headers or spoof the user agent, and simply loading pages faster than a person all lower the score. The tell: it appears in one browser and not another, or after you disabled a script blocker, or after a burst of quick page loads. The sensor side is described in how the _abck cookie works.
A firewall rule on the request. Something in the URL or the form data matched a pattern the web application firewall watches for, such as text that resembles a database command or a script tag. The tell: it appears only when you submit a particular search or form.
A rate rule. Too many requests from one address in a window. The tell: it appears after fast browsing and clears on its own.
What to change, in order
- Turn off the VPN, proxy, or relay, and reload. If the page is gone, the address rule was the cause. Reconnect to a server in another location if you need the VPN; a different exit has a different history. For a proxy on the device that you never configured, how to turn off a proxy shows where it lives and what the address means.
- Change networks. Load the site over mobile data, then over Wi-Fi. A page that follows one network and not the other confirms the address, and tells you which one.
- Try a clean browser. A private window with all extensions disabled removes header stripping, user-agent spoofing, and script blocking, which are the browser-side triggers for the bot verdict. If the page loads there, switch the extensions back on one by one to find the culprit.
- Clear the site's cookies. Akamai's sensor cookies carry the score of the session. A session that went bad, for instance after a burst of quick loads, can stay bad until the cookies are gone.
- Update the browser. A browser version old enough to be rare reads as unusual, and unusual is what the detector looks for.
- Wait an hour if you were loading pages quickly, comparing prices in many tabs, or refreshing for a release. Rate rules expire.
- Send the reference number. From a clean browser, on a normal connection, still denied: the rule catches more than it should, and the site's support team can look up the reference number and see exactly which rule fired. Include the time, your country, and the page you were opening.
Arriving from somewhere else on purpose
Some readers need an address in a specific region for a legitimate reason: checking a regional price, testing a site from a market you serve, using a service from the country you hold an account in while travelling. A shared VPN exit is the worst tool for that against Akamai, because it carries the reputation of the crowd. One person's address on a consumer ISP reads to Akamai as a household, and a static ISP proxy is exactly that: a fixed address in the region you need, assigned to you alone. It does not override a geographic rule aimed at the region itself, and no address does, but it removes the crowd from the equation.
Scrapers, read this part instead
Scrapers meet this page for the address reasons above and for one more: the request does not satisfy Akamai's sensor. A Python default TLS fingerprint, headers in the wrong order, and no _abck cookie from a real sensor run each produce a denial from a fresh residential address just as reliably as from a datacenter one. Changing the exit fixes the address layer and nothing else. Scraping past Akamai covers what Bot Manager checks, where residential proxies fit, the sticky-session rule that keeps the sensor cookie and the address together, and the two ways to satisfy the sensor. The short version: residential exits with sessions that hold, a browser-grade client, and a request rate that a person could plausibly produce.
For site operators reading from the other side
If your customers are sending you reference numbers, look them up in the security events before assuming abuse. Rules that deny whole hosting providers also deny corporate users behind cloud gateways; rules that deny VPN ranges deny travellers; and an aggressive bot-score threshold denies people on old corporate browsers. Prefer a challenge to a hard deny where the traffic might be human, and keep an allowlist for partners and monitoring tools.
Quick order of operations
VPN off, reload. Other network. Private window without extensions. Clear the site's cookies and update the browser. If it still says Access Denied, the reference number is the site's problem to look up, not yours to guess at. And when you need to be somewhere else on the map, use an address that belongs to you alone rather than to a crowd.