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

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

1

Capture a baseline

Run a small, representative task without changing several settings at once. Record the final URL, screenshot, error text, and sample output.
2

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

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

Validate page and data

Check redirects, login state, challenge pages, expected fields, multiple rows, missing values, and duplicates.
5

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.

​
What a proxy can and cannot change

For managed Cloud-region selection, see Cloud IP pools. For a page that still fails after a controlled proxy test, use Troubleshoot access and blocking and Waits, timeouts, and retries.
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.