Skip to main content
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.

​
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.

​
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.