Apify Screenshot Actor Fails on Cloudflare-Protected Pages: What to Try

If an Apify screenshot run returns a Cloudflare challenge, the browser captured the challenge page rather than the destination. If it returns an error or times out, the cause may instead be a site block, slow load, Actor configuration, or another run problem. Start by inspecting the returned image and output row; do not assume every failed screenshot is a Cloudflare block.

The title does not identify an Actor ID, and Apify has multiple screenshot Actors with different inputs and behavior. This guide uses accountable_eel/website-screenshot as the closest matching listing found. It is community-maintained, not an Apify-owned Actor. Confirm the Actor ID and version in your run, then follow that Actor’s current README and input schema. Its documented defaults and behavior may not apply to another Actor.

1. Identify the Actor and inspect the result

Open the Apify run details and record the Actor ID and build or version. Compare them with the Actor listing you intended to run.
Open the screenshot itself. Check whether it shows the requested page, a Cloudflare interstitial, a blank or partial page, or an unrelated redirect destination.
Inspect the output row fields documented by the identified Actor: statusCode, error, note, and finalUrl. Read them together with the image rather than treating any one field as a definitive diagnosis.
Review the run log for the URL and the point where navigation, waiting, or capture failed.

Cloudflare describes an interstitial challenge as a gate that holds the request while it evaluates browser signals; the destination is not served until the challenge is resolved. A screenshot of that interstitial is therefore not a successful capture of the requested content. See Cloudflare’s explanation of interstitial challenge pages.

2. Interpret the output before changing settings

What you see	Likely interpretation	Next step
Screenshot shows a Cloudflare “checking” or challenge page	The browser reached a challenge response, not the intended content. The Actor may have captured before the challenge cleared, or the challenge may require interaction.	Check `note`, `finalUrl`, status, and logs. Do not treat the image as the target page.
HTTP status and an `error` are present	The request may have been blocked, or a challenge may not have cleared. The identified listing documents an error row for these cases.	Save the row and screenshot, and confirm the Actor-specific error details.
Partial page plus an error	The page may have rendered only partly before the Actor’s per-URL time limit.	Check elapsed time and the Actor’s current timeout setting, if it has one. Test a longer timeout only for evidence of a slow page.
Blank image or unexpected page	Possibilities include a redirect, delayed or dynamic content, a failed navigation, a changed site, or a capture issue.	Compare `finalUrl`, logs, and a saved page snapshot if available.
No useful output row	The run may have failed before the Actor produced a per-URL result, or the wrong dataset or run may be open.	Check the run status and logs, then verify the output dataset and Actor ID.

The identified listing documents a 45-second default hard limit per URL. It says a slow page can return whatever rendered with an error; a cloud-server block or check that never clears also produces an error row. It describes failed rows as free for that Actor. These details are specific to that listing, not a general Apify billing rule.

3. Follow a controlled troubleshooting sequence

Step 1: Confirm the input and target

Check the exact URL sent to the run, including scheme, path, and query string. Compare it with finalUrl to see whether the site redirected the browser. Confirm that the run used the intended Actor and the input fields documented for that Actor. Do not copy timeout, proxy, or browser settings from a different screenshot Actor without checking its schema.

Step 2: Classify challenge, block, and timeout separately

A challenge image points to a page-verification response. An HTTP status paired with an error may indicate a block or an uncleared check. A partial render that ends around the Actor’s time limit is more consistent with a slow page, although the output and logs are needed to tell. Increasing a supported timeout can test a slow-load hypothesis; more time alone does not make a site-side block go away.

Step 3: Look for ordinary Actor or site failures

Apify’s guidance for Actor errors recommends using logs and page snapshots to distinguish site changes, dynamic content, access or proxy problems, and code or dependency errors. If available, save the page snapshot alongside the screenshot. Include the requested URL in your notes and correlate it with the log entries so you can tell whether navigation completed and what the browser rendered. See Apify’s Actor error troubleshooting guidance.

Step 4: Reproduce a human-browser challenge when useful

If a person opening the same URL sees a challenge or challenge loop, Cloudflare’s troubleshooting steps can help isolate browser and network issues: update the browser, enable JavaScript, temporarily disable extensions, try a private session or another browser and device, check whether a VPN or proxy interferes, and test another network. For a persistent loop, preserve the browser log while reproducing it, then export a HAR and console log if you need to report the issue.

These steps help diagnose a human-browser reproduction. They do not guarantee that a cloud Actor will be allowed through the site’s protections. Cloudflare recommends contacting the website administrator when challenge troubleshooting does not resolve the problem. See Cloudflare’s challenge-solve troubleshooting.

Step 5: Escalate with evidence

If the failure persists, provide the site owner or Actor maintainer with:

Target URL and approximate run time.
Actor ID, version or build, and the input used.
The relevant output row, including statusCode, error, note, and finalUrl when present.
The returned image, relevant logs, and a page snapshot if available.
A concise note saying whether a human browser reaches the content, sees a challenge, or also fails.

This evidence helps separate a site-side access decision from a timeout or Actor problem. Avoid sending secrets from headers, cookies, or authorization values in a public issue.

4. Should you change proxies or switch Actors?

Proxy changes are not a proven universal fix for this screenshot Actor. Apify documents proxy configuration in a separate custom Playwright/Camoufox tutorial and has discussed a region suggestion for a separate Website Content Crawler issue. Neither establishes that the same control is available in this Actor or that it will clear a particular site’s challenge.

A separate community Web Unblocker Actor advertises HTML extraction, optional screenshots, browser rendering, and retries with a fresh residential proxy IP. That is a different product and its listing does not establish that it will clear any particular site’s protection. Choose a different workflow only after checking its current documentation, inputs, and failure behavior. See the Web Unblocker listing and Apify’s proxy tutorial.

When evaluating another route, compare whether it returns the requested page or just a challenge image, what diagnostic status and error details it exposes, how it handles timeouts and retries, which browser or proxy controls it documents, whether it is built for screenshots or extraction, and what it charges for failures. Do not infer reliability or access from marketing claims alone.

5. When a dedicated screenshot API fits better

If your task is repeatable page capture rather than a custom scraping workflow, ScreenshotNeo is a screenshot API and MCP server for developers. It returns screenshots or PDFs from a single GET request. Its clean-shot flow accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. It bills only clean shots: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and responses include X-Page-Verdict and X-Billed headers. This is an alternative to try first for screenshot capture; no service should be assumed to bypass every site’s access controls.

Or skip the browser setup

Make one GET request with the URL and your API key. See the ScreenshotNeo API documentation for the full request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as f:
    f.write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners, popups, and chat widgets are removed before the shot.
Bot checks, blank pages, and failed loads are never billed.
An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf.
1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

6. Performance, reliability, and cost

Timeouts: Use a longer timeout only when the evidence points to a slow page and the Actor supports changing it. More waiting consumes run time and will not resolve an access block.
Retries: Retry only after identifying what failed. Repeating the same request against a persistent challenge can add delay without changing the result. Keep the original run output for comparison.
Diagnostics: Save output rows, images, and relevant logs. An image alone may not distinguish a challenge, redirect, partial load, or empty page.
Cost: Check the current Actor listing and your Apify plan before running large batches. The identified Actor listing says its failed rows are free; do not generalize this to other Actors. ScreenshotNeo bills only clean shots and exposes billing and page-verdict headers.
Reliability: A screenshot workflow depends on the target site, rendering behavior, network and access policy, and Actor implementation. A successful human-browser visit does not guarantee a cloud run will receive the same page.

FAQ

Does a Cloudflare challenge screenshot mean the Actor captured the site?

No. It means the image contains the challenge response rather than the requested destination content.

Will increasing the timeout fix a Cloudflare block?

Not by itself. A longer timeout can test whether a slow page needed more time, but it does not resolve a site-side block or a challenge that never clears.

Can I assume all Apify screenshot Actors use the same fields?

No. Confirm the Actor ID and use its own current input schema and output documentation.

Is a proxy change guaranteed to work?

No. The cited proxy guidance covers separate workflows and does not establish a fix for this Actor or a particular protected site.