Skip to main content
You configure these settings in a task in Octoparse Desktop, and they apply to local and cloud runs unless a page says otherwise. Anti-blocking in Octoparse is a set of settings and testing practices for diagnosing why a page or result fails, then testing the smallest necessary change to the network, browser identity, session, verification handling, or task pacing. Together, these capabilities support an access-reliability workflow; they can improve a task’s chance of loading and extracting the expected data, but do not guarantee access to every website.
Most templates come with proxies built in, so a template task usually works without these settings.
When a task can’t open a website or returns incomplete data, diagnose the page before you change settings. Capture the final URL, error text, screenshot, time, run environment, and several output rows. That evidence separates access failures from task-design or data-quality issues.

​
Start with the symptom

​
The six parts of access reliability

  1. Network and location. Cloud IP pools, Octoparse built-in proxies, and supported custom proxies determine the network path available to a task.
  2. Browser identity. User-Agent and browser-mode choices affect how a page is requested and rendered.
  3. Session. Login state and cookies must remain usable for pages that require authentication.
  4. Verification. Some supported CAPTCHA and Cloudflare flows have automatic paths; Browse Mode and Local runs also provide manual control in the applicable workflow.
  5. Pacing and recovery. Waits, timeouts, and action retries help a task handle slow or asynchronous pages.
  6. Evidence. Screenshots, run events, the final page, and a small output sample show whether a change actually helped.

​
Test, validate, and monitor

1

Reproduce the issue with a small test

Record the final page, time, environment, error message, screenshot, and a sample of the returned fields.
2

Identify the likely cause

Distinguish access errors from a changed selector, expired login, incomplete loading, or a regional difference.
3

Change one setting at a time

Use the least disruptive change first. For example, add a wait before changing the IP path for a page that simply loads slowly.
4

Validate the page and data

A successful page load alone is not enough. Check the expected page state, several output rows, and missing or duplicated values.
5

Monitor or stop

Keep the tested configuration only if the result is stable. Pause or stop when repeated attempts add cost or do not improve access.

​
When to stop and contact Support

Stop the run when a small, controlled test still returns an access, CAPTCHA, or login page. Also stop when retries add cost but do not return valid data. When you contact Support, include:
  • Whether the run was Local or Cloud, and when it ran
  • The target URL and error message
  • A screenshot and the relevant event-log excerpt, with secrets removed
  • What you expected to happen and what happened instead

​
Check availability by environment

Task editing, Local runs, and Cloud runs do not always expose the same controls. For example, Public IP Pool is a Cloud-run setting, while custom proxy is currently available for Local runs only. Before applying a configuration in another environment, check the relevant page.
Do not use access-reliability settings to evade a site’s rules or collect data you are not permitted to access. Challenge support, billing, regions, browser modes, and version availability can change; confirm the current product setting before a production run.