> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Proxies and IP rotation

> Choose an Octoparse or custom proxy, select a location, configure IP rotation, and verify whether it improves a task's access and data quality.

Proxies route a task's website traffic through a different IP address. In Octoparse, use them when a controlled test shows that the target site blocks your current IP, serves the wrong regional content, or behaves differently in the Cloud. They can change the network path; they do not fix an invalid workflow, expired login, unavailable website, or a site that does not permit automated access.

## Choose the proxy that matches the task

| Option | Best for | Available in | What to know first |
| - | - | - | - |
| **Octoparse built-in proxies** | A target site that is sensitive to IP reputation, or content that needs a selected country or region | Task editing, Local runs, and Cloud runs | Octoparse-managed residential IPs; usage is metered by page-loading traffic |
| **Your own proxy** | A Local-run workflow that must use an IP path you operate or source separately | Task editing and Local runs | HTTP `IP:port` only; authenticated proxies and Cloud-run use are not currently supported |
| **Public IP Pool** | Selecting one of the available Octoparse cloud regions without adding a built-in proxy | Cloud runs only | It is a Cloud-run region setting, not a substitute for the built-in proxy service; see [Cloud IP pools](/docs/en/platform/cloud-ip-pools) |

### Use Octoparse built-in proxies when

Octoparse built-in proxies are residential IPs. They are the right starting point when a page loads with your local connection but returns an access error, CAPTCHA, redirect, or different content during a representative task test. They are also useful when the target content is specific to a country or region and the selected proxy location must match that market.

In **Task Settings → Anti-blocking**, select **Access website via proxies**, choose **Use Octoparse proxies**, then select **Default** or a country/region and set a rotation interval. Default uses IPs from random countries; choose a specific location when the target's availability, language, prices, inventory, or rules depend on geography. Octoparse states that built-in proxies support most countries and regions; use the current selector to confirm the location you need before configuring a production run.

Built-in proxies can also be enabled from the editor's **Proxy** control when your local IP cannot load the target page. Select **Use the same proxies for task runs** only after the editor test, the Local or Cloud test, and the resulting data all match expectations.

### Use your own proxy when

Use your own proxy only when you already operate or obtain the required network path and intend to run the task locally. In the task settings, choose **Use my own proxies**, then enter each proxy as `IP:port`.

The current public support scope is deliberately narrow:

* HTTP proxies only
* Address and port in `IP:port` format
* Local runs only
* No username/password authentication

You can select a custom proxy while editing a task, but that does not make it available to a Cloud run. A Cloud run can use Octoparse's built-in proxies instead. Do not rely on internal implementation fields or an unverified UI state as evidence of Cloud support.

## What built-in proxies cost

Octoparse built-in proxy traffic costs **\$3 per GB**. Proxy usage is measured from page-loading traffic, not from the number of extracted rows. To enable the service, the account needs at least **\$3 in credits**. Based on Octoparse testing, 1 GB can typically cover about **500 web pages**; actual usage varies with page size, images, scripts, redirects, and retries.

Proxy credits cannot be refunded. Start with a small test, inspect the resulting page and data, then review usage before increasing task volume.

## How IP rotation works

IP rotation changes the proxy used by an applicable task at the interval you choose. It is useful when repeated requests from one IP are a likely cause of blocking, but it is not a guarantee that every request receives a new IP or that a target site will allow the task.

When a task starts, Octoparse uses the proxy you selected. If you set a rotation interval, it switches proxies at that interval while the task runs. Custom proxies are selected from your list; built-in proxies are provided by Octoparse for the location you choose. Switching pauses when the task is paused.

When you configure a rotation interval, use these rules:

| Situation | Rotation choice | Why |
| - | - | - |
| Public, low-volume pages that load normally | Do not add a proxy or rotation by default | A simpler, stable configuration is easier to validate |
| Repeated requests from one IP trigger access errors | Test a built-in proxy with a bounded rotation interval | It changes the network path without changing unrelated task logic |
| Regional pages or country-specific pricing | Select the required country/region; rotate only after testing | A new IP or country can change content, language, and layout |
| Logged-in pages | Keep the IP stable unless the full session survives a controlled rotation test | An IP change can invalidate a Cookie session or trigger a security check |
| A failed Go to Web Page or Click action | Use a bounded retry policy and inspect the recovered page | Retry-driven rotation is not evidence that the data is correct |

The proxy, User-Agent, and Cookie settings can be coordinated. When configured, Octoparse can switch a User-Agent or clear Cookies when the IP changes. That may be useful for a new anonymous session, but it can break an authenticated one. Change one setting at a time and test the complete path to the target data.

## Validate the effect before scaling

<Steps>
  <Step title="Capture a baseline">Run a small, representative task without changing several settings at once. Record the final URL, screenshot, error text, and sample output.</Step>
  <Step title="Select the smallest suitable option">Use Public IP Pool for a Cloud region, a built-in proxy for managed residential IPs, or your own HTTP proxy for a Local run.</Step>
  <Step title="Test the connection and page">Where the UI offers Test Connection, use it. Then load the actual target page; a successful connection alone does not prove the target accepts the IP.</Step>
  <Step title="Validate page and data">Check redirects, login state, challenge pages, expected fields, multiple rows, missing values, and duplicates.</Step>
  <Step title="Monitor usage and stop when needed">Review the event log and traffic cost. Stop retries when they repeatedly return an access page, consume credits, or fail to improve data quality.</Step>
</Steps>

## What a proxy can and cannot change

| A proxy can help with | A proxy cannot reliably do |
| - | - |
| IP-based access errors, regional content, and distributing repeated requests | Guarantee access to every website or bypass a site's rules |
| Testing whether network origin is causing a Local/Cloud difference | Renew an expired login or ensure a rotating IP keeps a session valid |
| Providing a supported country or region for a test | Prove that a CAPTCHA, challenge, or incomplete page has been resolved |

For managed Cloud-region selection, see [Cloud IP pools](/docs/en/platform/cloud-ip-pools). For a page that still fails after a controlled proxy test, use [Troubleshoot access and blocking](/docs/en/platform/troubleshoot-access-and-blocking) and [Waits, timeouts, and retries](/docs/en/platform/waits-timeouts-retries).

<Warning>
  Use proxies only where you have permission to access the target website and data. Before a production run, verify the selected proxy, location, and cost.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.