Amazon CloudFront's error page has a house style: a bold "ERROR: The request could not be satisfied." at the top, a second line that varies, a paragraph of boilerplate about too much traffic or a configuration error, a note to site owners about the CloudFront documentation, and a footer that reads "Generated by cloudfront (CloudFront)" with a Request ID. People search for the first line, because it is the biggest, and the first line means almost nothing on its own. The second line is the diagnosis.
CloudFront sits in front of a large share of the web, from small sites hosted on S3 to the largest streaming and retail services, and it generates this page itself whenever it cannot or will not return the site's content. The "cannot" cases are about the site's own servers or configuration, and a visitor can do nothing but wait. The "will not" cases are security rules and geographic restrictions, and those are the ones where what you change on your side decides whether the page goes away. Telling the two apart takes one look at the second line.
The variants, and what each one means
| Second line on the page | Status | What happened | Who can change it |
|---|---|---|---|
| Request blocked. We can't connect to the server for this app or website at this time. | 403 | An AWS WAF rule attached to the distribution blocked the request | The owner adjusts the rule; you can change what it sees |
| The Amazon CloudFront distribution is configured to block access from your country. | 403 | A geographic restriction denied your country | The owner; you can arrive from an allowed country |
| Bad request. We can't connect to the server for this app or website at this time. | 400 or 403 | The request was malformed, or the distribution is not set up for the hostname you used | The owner (an alternate domain name not added to the distribution is a documented cause) |
| This distribution is not configured to allow the HTTP request method that was used for this request. | 403 | A method such as POST on a distribution that only allows GET | The owner, or the developer of the app making the request |
| Missing Key-Pair-Id query parameter or cookie value. | 403 | The content is private and needs a signed URL or cookie that your request did not carry | Reload from the site itself; the link you used is expired or incomplete |
| CloudFront attempted to establish a connection with the origin, but... / CloudFront wasn't able to connect to the origin. | 502, 503, 504 | The site's own server did not answer CloudFront | The owner; wait and retry |
Amazon's own troubleshooting page for 403s lists the causes from the owner's side: an alternate domain name not configured on the distribution, AWS WAF on the distribution or at the origin, a custom origin or S3 bucket returning its own 403, geographic restrictions, signed URLs or cookies, and stacked distributions. One line from that page is worth quoting for visitors, because it explains why support sometimes cannot tell you what happened: when AWS WAF sits in front, "CloudFront can't distinguish between a 403 error code that's returned by your origin and a 403 error code that's returned by AWS WAF when a request is blocked". The owner has to look at the web ACL to know which rule fired, and the Request ID is what makes that lookup fast.
"Request blocked": the security variant
This is the one that brings VPN users, travellers, and scrapers to the same page. AWS WAF lets the site owner block by address reputation, by country, by rate, by request pattern, and, with its Bot Control rules, by how much the request looks like a browser. A person on a shared VPN exit, a corporate gateway that exits from a cloud range, or a mobile carrier's shared address can be blocked by a reputation or rate rule that was never aimed at them.
Work through it in order:
- VPN or proxy off, reload. The block following the VPN is the common case. Reconnect elsewhere if you need it.
- Another network. Phone on mobile data, then Wi-Fi. If one works and the other does not, the address is the cause.
- A clean browser. Private window, extensions off. Header-stripping and user-agent spoofing extensions change what Bot Control sees.
- Slow down. Rate-based rules count requests per address over a few minutes and expire on their own. Refreshing a checkout page or a drop page rapidly is exactly what they watch for.
- Send the Request ID. Still blocked with no VPN and no extensions? The rule reaches further than the owner intended, and the Request ID lets them find it.
If a proxy was configured on your device by something else, read the address before you remove it; our guide on turning a proxy off explains what a local or unfamiliar address means.
"Configured to block access from your country": the geographic variant
There is no rule to argue with here. The owner drew a map, and your address is on the wrong side of it. Amazon's documentation says only that blocked users receive a 403. On a VPN, the exit is the wrong country: disconnect, or pick a server in a country the site serves. Travelling, the same applies to the hotel Wi-Fi. If you live in the blocked country, the site is declining to serve your region, and the only way to see it is an address in a served one. People with a legitimate reason to do that, such as accessing a service from the country they hold an account in, are best served by a fixed address rather than a shared VPN node, because the WAF variant above is waiting behind the geographic one, and shared exits trip it. A static ISP proxy in the served country is a single household address assigned to one user.
"Bad request", "not configured to allow the HTTP request method", and the key-pair line: the configuration variants
These are not about you. "Bad request" appears when the request is malformed or when the hostname you typed is not one the distribution knows, which Amazon lists as a CNAME that was added in DNS but not to the distribution; the fix is on the owner's side, and a visitor can only try the site's canonical address (with or without www) in case the other is the configured one. The method line appears when an app sends a POST or PUT to a distribution that only permits reads, which is a developer's problem. The key-pair line appears on private content that requires a signed URL or cookie: the link you followed is expired or was copied incompletely, and reloading the content from the site's own navigation issues a fresh one. None of these change with a VPN, a different network, or a different browser.
The origin variants: 502, 503, and 504
When the second line says CloudFront could not connect to the origin, or the origin returned an error, the site's own server is the failure. The visitor's connection worked all the way to CloudFront, which is why the page renders at all. Wait and retry. Scrapers that see these in bulk should read our guides to 502 Bad Gateway and 504 Gateway Timeout explain how to tell a struggling origin from a proxy problem and how to back off without making it worse.
For automation
Scrapers meet "Request blocked" for the address reasons and for the request itself. AWS WAF's Bot Control rules read the TLS fingerprint and headers, and at the targeted level run a browser challenge, so a datacenter address with a Python fingerprint is refused on both counts. Changing the exit to a residential address clears the address rules; the rest needs a browser-grade client and sessions that hold one address for the length of a flow. Bypassing AWS WAF covers what Bot Control checks, where residential proxies fit, and the setup that gets through, and how websites detect proxies covers the address side.
Read the second line, then act
Read the second line. "Request blocked" is a security rule: VPN off, other network, clean browser, slow down, then send the Request ID. The country line is a map: arrive from a served country. "Bad request", the method line, and the key-pair line are the site's configuration or an expired link, and nothing on your side changes them. Origin errors are the site's server, and the fix is patience.