Skip to main content
Cloud IP pools determine the public IP region used when an Octoparse task runs in the Cloud. They are useful when a website serves different content by location, restricts access from certain countries, or reacts differently to cloud traffic. An IP pool changes the network origin of a cloud run. It does not change the task workflow, browser settings, login credentials, or the target site’s access rules.

​
Default and available IP pools

Octoparse provides public Cloud IP pools for the US, UK, Germany, Japan, Australia, France, Canada, and China, plus a Default pool. Default uses the cloud group assigned to your account; for most accounts, that group is US-based. If your account needs a different default region, contact Octoparse Support to request a change. The selector may show more than one named pool for a country, including legacy or region-specific groups. The available names depend on your account and the task’s cloud environment. Choose by country or region unless Support asks you to use a specific named group. Choose a specific region when the target site:
  • Is available only from a particular country.
  • Shows different pages, prices, language, or inventory by region.
  • Blocks requests from the default cloud location.
  • Requires the cloud request to match the target market.
Start with Default when the target site loads and returns the expected content. Change the pool only when the target’s location behavior gives you a reason to do so.

​
Switch the pool for a cloud task

  1. Open the task in the Task List.
  2. Open Task Settings and go to Run Settings.
  3. Find Public IP Pool.
  4. Select Default or the required country/region.
  5. Save the task settings.
  6. Run a small Cloud test and verify the page and output before scheduling or scaling the task.
Public IP Pool applies to Cloud runs. It does not change the IP used by a local run. If the required country is not available in the public pools, use an Octoparse proxy with a supported location instead.

​
Verify the result in cloud logs

Do not assume that changing the dropdown changed the content you received. Verify the run from Cloud Run Details:
  1. Open the task’s cloud run details after the test starts.
  2. Check the event log for connection, loading, or access errors.
  3. Open an affected subtask’s screenshot and compare the page with the local test.
  4. Check whether the expected regional content, fields, and record count appear in Data List.
  5. Compare the result with a run using Default or another region when the behavior is still unclear.
The screenshot confirms what the cloud browser received. It can reveal a regional redirect, an access-denied page, a login page, or a CAPTCHA that the extracted data alone may not explain.

​
Cloud IP pools vs paid proxies

These settings solve different problems: To use a built-in proxy, open the task’s anti-blocking settings, enable access through proxies, choose Use Octoparse proxies, select Default or a country/region, and set the rotation interval if needed. Proxy traffic is charged by page-loading traffic, and proxies do not work for every website. Cloud runs are compatible with Octoparse’s built-in proxies. Your own proxy works with local runs only. Do not treat a public IP pool as a free replacement for metered proxy traffic: a pool selects a cloud IP region, while a proxy adds a separate proxy service and traffic cost.

​
What changing the pool can help with

Changing the pool can help when:
  • The site blocks the default cloud region.
  • The site redirects users to a regional domain or page.
  • Required content is visible only to visitors from a target country.
  • A cloud run loads a different page from the local test because of location.
  • The task needs a different cloud IP group for repeated access.
Use a small test after every change. A new region can change page structure, language, prices, login behavior, or available fields, so a task that worked in one region may need validation in another.

​
What an IP pool cannot solve

An IP pool is not a general anti-blocking or CAPTCHA solution. It cannot by itself:
  • Fix an incorrect selector, pagination rule, or wait condition.
  • Renew an expired login or repair invalid cookies.
  • Guarantee access to a site that blocks automated browsers.
  • Remove CAPTCHA or prove that a CAPTCHA was solved.
  • Make a sequential task parallel or improve a site-side rate limit.
  • Make a page load when the target server, JavaScript, or API is failing.
  • Guarantee that every request in a run comes from one fixed IP.
If the screenshot shows a CAPTCHA, access-denied page, or login challenge after changing the region, inspect the task’s login, browser, pacing, and proxy settings. If the site still requires a local session or local IP, test Local extraction instead.
  1. Reproduce the issue with a small Cloud run using Default.
  2. Inspect the screenshot and event log to confirm a location or IP-related cause.
  3. Select the closest available public IP pool to the target market.
  4. Run the same small test and compare page content and output.
  5. Use a built-in proxy only when the public pool does not provide the required location or access path.
  6. Keep the region that produces stable, complete data, then monitor later runs for blocking or content changes.
For broader anti-blocking guidance, see Anti-bot detection and Proxy. For setup steps, see Switch IP Pools for Cloud Runs, Set up IP Proxies, and What is IP rotation? in the Help Center.