Introduction

In this step-by-step guide, you'll learn how to launch stable multithreaded automation in Browser Automation Studio (BAS) using mobile proxies. We'll meticulously set up the environment, connect mobile proxies, create a multithreaded script, and check the results. By the end, you’ll have a ready-to-use BAS project that runs in multiple threads, utilizes unique mobile IPs per thread, logs actions correctly, and can recover from errors. We’ll break down each step in detail to minimize the risk of mistakes and save your time.

This material is aimed at beginners, while also containing elements for advanced users. Even if you’ve never worked with BAS before, you’ll be able to follow all the steps thanks to detailed instructions. If you already have a basic understanding of automation, you’ll discover ready-to-use practices for optimizing multithreading, safely working with mobile proxies, and reliable error handling.

Before you start, it’s essential to have foundational computer skills, such as installing programs and understanding basic terms like "proxy," "thread," and "timeout." No complex programming skills are required; the entire process is built on visual BAS blocks, clear settings, and checks.

Time allocation for all steps should be around 2 to 4 hours. More time may be needed if this is your first time installing tools and setting up mobile proxies. However, after the initial setup, you’ll be able to quickly scale scripts and run them on different machines.

Tip: If you want to jump straight to proxy configuration, use the internal link to the section 'Step 3: Connecting and Configuring Mobile Proxies in BAS' — see below. If you’re interested in troubleshooting, head to the section 'Common Issues and Solutions' — see below.

Preparation

To succeed, you’ll need several essential tools and preparatory steps. Follow the list to ensure nothing is missed. Here we’ll also outline system requirements and explain what to download and how to install it correctly.

Required Tools, Programs, and Access

  • A computer running Windows 10 or newer. BAS is officially designed for Windows; running on Linux via compatibility is possible but is not covered in this guide.
  • The latest version of Browser Automation Studio (BAS) for 2026. You need to download and install it.
  • An account with a mobile proxy provider. Various providers are acceptable; for instance, mobile proxies with flexible rotation, such as mobileproxy.space, are often used.
  • A text editor for notes (like the standard Notepad) and a spreadsheet application (like Excel) to store proxy data and logins.
  • At least 5 GB of free disk space for installing BAS, temporary data, and logs.

System Requirements

  • Operating System: Windows 10/11 (64-bit).
  • RAM: minimum 8 GB (recommended 16 GB and above for intensive multithreading).
  • Processor: 4+ cores (recommended 6-8+ cores for stable multithreading).
  • Free disk space: at least 5 GB.
  • Stable Internet connection: minimum 20 Mbps; low latency preferred.

What to Download, Install, and Configure

  1. Download the BAS installer package from the official developer resource. Ensure that the version is current (2026) and suitable for your OS.
  2. Install BAS following the standard setup wizard: click “Next,” “Agree,” “Install.” Launch BAS after the installation is complete.
  3. Get access to mobile proxies from your provider. Make sure you have the IP/domain, port, authentication type (username/password or IP authentication), and documentation for IP switching (rotation).
  4. Create a folder for your BAS project, logs, and backups. For example: C:\BAS\Projects\MobileProxyMultithread.
  5. Prepare a CSV file with test data (if your script requires it), such as a list of URLs to visit. Example file: urls.csv with lines formatted like https://example.org/test1, https://example.org/test2.

Creating Backups

Backups allow you to quickly revert to a working state if something goes wrong.

  • Create a copy of the installed BAS project folder after each major change: added proxies — make a backup; added multithreading — make a backup.
  • Store copies in subfolders with the date: C:\BAS\Backups\2026-06-xx\.
  • Duplicate BAS script files (.xml) and resources (CSV, JSON, logos) in a separate folder named 'Backup_Resources.'

⚠️ Attention: If you’re running scripts on a work computer, ensure that your antivirus is not blocking BAS activity. Add the BAS folder to exclusions if necessary. Before doing this, confirm the safety of your sources.

✅ Check: You have BAS installed, there’s active access to mobile proxies (username/password or IP authentication), project and backup folder structures are created, and test data is prepared.

Basic Concepts

Before setting everything up, let’s touch on the theory at a practical level. A clear understanding of terms will save you time in the following steps.

What is BAS in Simple Terms

Browser Automation Studio is a visual tool for automating actions in a web browser. You build a script from blocks like a constructor. Each action is a block: "Open URL," "Click," "Enter Text," "Change Proxy," "Run in Thread," and so on. BAS does not require deep programming knowledge but offers flexibility to solve both simple and complex tasks: parsing, form checking, monitoring, account management, and testing.

Proxies and Mobile Proxies

A proxy is an intermediary server between your computer and the website you are accessing. When you use a proxy, the site sees the proxy’s IP instead of your own. Mobile proxies are those provided through cellular networks (3G/4G/5G), so their IP addresses belong to a “mobile” pool. This is useful for enhancing trust in the traffic and reducing false blocks if tasks are completed correctly and legally. Various providers offer IP switching (rotation) features on a timer or on request. For example, consider mobileproxy.space, which offers convenient rotation and different exit points.

Multithreading

Multithreading in BAS is the simultaneous execution of multiple copies of the same script. Each thread operates independently: with its own data, proxies, and logs. This speeds up the execution of repetitive tasks. It’s important to wisely separate resources: assign a unique proxy for each thread, configure timeouts, queues, and limits to avoid conflicts and overload.

What’s Important to Understand Before Starting

  • One thread — one proxy. This is a basic rule for stability and minimizing overlaps.
  • IP rotation should be predictable. Set IP changing at safe intervals and only when necessary to avoid triggering extra suspicions on websites.
  • Logs and reports are your best friends. Document key events and errors. This greatly simplifies debugging.
  • Any automation should comply with the laws and rules of the targeted websites. Work only with allowed tasks and data.

Tip: If you’re setting up mobile proxies for the first time, start with 1-2 threads. Once you confirm stability, move to 5, 10, and beyond. This way, you’ll clearly understand your machine's and proxies’ limits.

✅ Check: You understand that each thread works with a separate proxy, why rotation is necessary, and why logging events is critical. You are ready to move on to installation and project assembly.

Step 1: Installing and First Launch of BAS

Stage Goal

Install and correctly launch the current version of BAS, confirm that the interface and basic functions are operational.

Step-by-Step Instructions

  1. Open the BAS installer and follow the wizard’s steps ("Next," "Agree," "Install").
  2. Run BAS. On the first screen, you’ll see the main window with a menu, a list of projects, action panels, and a log console.
  3. Create a project folder: C:\BAS\Projects\MobileProxyMultithread. In BAS’s File menu, select "Save Project As…" and save an empty project as MobileProxyMultithread.xml in the specified folder.
  4. Open the actions section (on the left). Find the blocks "Browser," "Network," "Flow" — we’ll need these later.
  5. Check the browser module: add the block "Open URL" and specify https://example.org. Click "Run." Ensure that BAS opens the embedded browser and loads the page.

Important Points

  • Do not close the browser window during the test run. It’s part of the process.
  • If the page does not open, check the internet connection and firewall settings.

Expected Result

The page is successfully loaded, there are no critical errors in the logs, and the project is saved in the chosen folder.

Possible Problems and Solutions

  • Problem: BAS won’t launch. Cause: blocked by antivirus. Solution: add BAS to exclusions.
  • Problem: the test page doesn’t open. Cause: network restrictions. Solution: check internet access and proxy settings in the OS (they are not needed during the test).

✅ Check: In the BAS window, you see the loaded page, and there are green statuses in the logs. The project file MobileProxyMultithread.xml is saved.

Step 2: Project Structure and Resources

Stage Goal

Create a clear project structure in BAS with resources (data files, logs, results) so that scaling and maintenance are straightforward.

Step-by-Step Instructions

  1. Create subfolders in the project folder: data, logs, output, backups.
  2. Create the file data\urls.csv with 5-10 test addresses. Format: one URL per line. For example: https://httpbin.org/ip, https://example.org.
  3. In BAS, add a "Resource" to read from urls.csv: in the "Resources" section, click "Add Resource," select the type "File," specify the path to data\urls.csv, mode "Line by line" (per line).
  4. Add a block "Load From Resource" to read URLs from the resource into a variable, for instance, url_current.
  5. Add a block "Log" and output the value {{url_current}} for monitoring.
  6. Save the project (Ctrl+S).

Important Points

  • Name each resource clearly: res_urls, res_accounts, etc. This will simplify maintenance.
  • If you’re planning multiple scripts, keep resources in separate folders by tasks.

Expected Result

The project reads line-by-line from the urls.csv file, logs the value, and is ready to open pages from the list.

Possible Problems and Solutions

  • Problem: file reading error. Cause: incorrect path or encoding. Solution: check the path and use UTF-8 without BOM.
  • Problem: resource does not switch lines. Cause: mode set incorrectly. Solution: set to "Line by line" and enable auto-increment.

✅ Check: When you run it, you see lines from urls.csv in the logs and the value of the variable url_current.

Step 3: Connecting and Configuring Mobile Proxies in BAS

Stage Goal

Connect mobile proxies to the BAS project so that each thread uses its own IP. Set up safe rotation and connection checks.

Step-by-Step Instructions

  1. Determine the proxy access format. Usually, it is one of the following: http(s)://user:pass@host:port or socks5://user:pass@host:port. If using IP authentication, ensure your external IP is whitelisted with the provider.
  2. Prepare a list of proxies. Create the file data\proxies.csv, where each line is one proxy. Example: http://user1:pass1@mp1.example.net:3000, http://user2:pass2@mp2.example.net:3000. If you're using mobileproxy.space, indicate the hosts and ports provided to you in this format.
  3. In BAS, create a resource res_proxies to read from data\proxies.csv. Mode "Line by line."
  4. Before opening the browser, insert the "Set Proxy" block from the "Network" or "Browser/Proxy" section. In the proxy field, specify a variable read from the resource, for example {{proxy_current}}.
  5. Add an "HTTP Request" or "Open URL" block to a service check for the IP, like https://httpbin.org/ip. The goal is to ensure the traffic is routed through the proxy. Log the response and check that the IP differs from your actual IP.
  6. IP rotation. If your provider offers an API for IP switching (which is often the case with mobile providers), create a separate "HTTP Request" block for calling rotation. Do not call rotation too often. It’s recommended to perform it: a) at the start of a thread, b) upon specific connection errors, c) at safe intervals (e.g., every 10-20 minutes), if permitted by the provider’s documentation.
  7. Add a result check after rotation. Re-invoke the IP check and ensure that it has changed if rotation was initiated.
  8. Save the project (Ctrl+S) and back it up to the backups folder with a timestamp.

Important Points

  • One thread — one proxy. Do not share one proxy between threads. This reduces stability and hinders debugging.
  • Do not exceed rotation limits. Consult your provider for the allowable frequency. Excessive rotation can lead to errors.
  • Connection logs are mandatory. Always log which proxy was assigned to the thread and which IP was determined after the check.

Tip: If you are using mobileproxy.space, set up separate rotation endpoints for each modem/slot to manage IP changes individually without affecting other threads.

Tip: With IP authentication, regularly check the current external IP of your machine. If you change networks, update the whitelist with the provider.

Expected Result

The project picks up proxies from the file, sets it up before launching the browser, successfully passes the IP check, and can call rotation as needed.

Possible Problems and Solutions

  • Problem: “Proxy authentication required.” Cause: incorrect username/password. Solution: check login details and the format of the line in proxies.csv.
  • Problem: IP doesn’t change after rotation. Cause: too frequent requests or delays from the provider. Solution: wait 30-120 seconds, increase the rotation interval.
  • Problem: unstable connection. Cause: weak signal from the provider’s modem. Solution: switch the exit point or use another slot from the mobile provider.

✅ Check: In the logs, you see the proxy assigned to the thread, successful page loading for the IP check, and the IP changing correctly upon rotation. No authorization errors.

Step 4: Basic Multithreading — Launch Template

Stage Goal

Set up multithreaded launching in BAS with resource isolation: each thread gets its own line from proxies.csv and its own set of URLs.

Step-by-Step Instructions

  1. Determine the number of threads for the test. Start with 2-3 threads.
  2. Add "Threads" blocks to the project or use "Run In Threads" (depends on the version of the interface). Specify the variable threads_count, defaulting to 3.
  3. Create a resource res_proxies with the mode "Take row and lock," if available, or manually organize line delivery by index so each thread gets a unique line. Alternative: use "Take Line" with automatic transition to the next line and locking.
  4. For URL data, create independent distribution: if you want threads to take different URLs, use a separate resource res_urls with "Take Line" and locking. If each thread must access the same list, work with a copy of the array in memory.
  5. Within the thread body, set the proxy from a unique line res_proxies, perform the IP check, then loop through the URLs: open a page, wait for it to load, log the status.
  6. Add timeouts and delays. Use "Sleep" for 2-5 seconds between opening pages to reduce load spikes and avoid excessive suspicion on the site's side.
  7. Log per thread. In the log filename, use the thread variable, like logs\thread_{{thread_id}}.log, for easy debugging.
  8. Save the project and run it in 3 threads for testing.

Important Points

  • Resource isolation is critical. Ensure that two threads do not take the same line from proxies.csv simultaneously.
  • Stabilize delays. The higher the number of threads, the greater the likelihood of network collisions. Moderate delays increase stability.

Tip: Start testing with 1 thread, then 2, then 3. At each step, check the logs and resource consumption (CPU, RAM, Network). This will help prevent sudden failures when scaling.

Tip: Name the thread with a number and a brief description, like "T3_Parse." This is useful for analyzing logs.

Expected Result

The script starts simultaneously in several threads. Each thread takes its proxy and processes its portion of URLs without conflicts. Logs are saved separately.

Possible Problems and Solutions

  • Problem: two threads received the same proxy. Cause: resource locking not set. Solution: enable line locking mode upon issuance.
  • Problem: threads get "stuck." Cause: overly strict timeouts. Solution: increase the timeouts for page loads and network requests.

✅ Check: Reports for each thread are created in the logs folder. The logs show correct proxy assignments and the proper sequence of actions.

Step 5: Script Logic and Robust Error Handling

Stage Goal

Add resilience to the project: restarts on failure, handling network errors, reasonable retries, and notifications.

Step-by-Step Instructions

  1. Inside the thread body, add a "Try/Catch" block (or a similar mechanism in BAS). Wrap key operations: setting proxies, checking IPs, opening URLs.
  2. In the "Catch" block, log details: thread name, step, error text. Add a "Sleep for 5–15 seconds" action before retrying.
  3. Implement a retry counter: a variable retries with a limit of 2-3. If the limit is exceeded — log the failure and move to the next task, so the thread does not stall.
  4. On network errors (e.g., proxy not responding), add an alternative route: change the IP through rotation (if permitted) and retry checking the IP. Only after that, repeat the main action.
  5. If the site responds too slowly, use "Wait For" with a longer timeout and an intermediate check for DOM readiness. Blindly increasing timeouts without checking could slow down the threads, so combine "Wait For Element" with reasonable limits.
  6. Log specific codes and metrics: HTTP response status, load duration. Record them in a timestamped file.
  7. Save the project and test: artificially specify one non-working proxy in data\proxies.csv and ensure that error handling works correctly.

Important Points

  • Don’t loop endlessly. Limit the number of retries; otherwise, you may get stuck on one URL for a long time.
  • Segment errors. A network error is one action (change IP, retry), a business error in the script is another (skip and continue).

Tip: Add levels to your logs: INFO for ordinary events, WARNING for non-standard situations, ERROR for critical failures. This will help you quickly locate relevant fragments.

Tip: Capture screenshots only for significant errors to avoid cluttering the disk. For example, the path could be logs\screenshots\thread_{{thread_id}}_{{timestamp}}.png.

Expected Result

The script is stable: upon network failures, it restarts steps, and upon exceeding the retry limit, it correctly completes the handling of the current element and proceeds to the next. Logs are informative.

Possible Problems and Solutions

  • Problem: excessive retries. Cause: failing to differentiate error types. Solution: condition on response codes and exception types for varied behaviors.
  • Problem: log overflow. Cause: overly detailed records. Solution: reduce detail for INFO logs and keep details for errors.

✅ Check: During tests with invalid proxies and "slow" URLs, the script does not crash overall, but rather recovers and moves on.

Step 6: Logging, Reporting, and Progress Saving

Stage Goal

Set up thoughtful logging to quickly understand what each thread is doing and why. Configure results preservation and progress control.

Step-by-Step Instructions

  1. Add a main log file for summary events: logs\main.log. Record start/stop of the script, the number of threads, stage headers.
  2. Log a separate file for each thread: logs\thread_{{thread_id}}.log. Write values for proxies, IPs after checks, each target URL, and operation results there.
  3. Create a results file output\results.csv. Line format: timestamp;thread_id;proxy;ip;url;status;elapsed_ms. Append a line after processing each URL via "Append to file."
  4. Save progress in case BAS crashes: periodically write to the file output\checkpoint.json current resource indexes (which URL was processed, which is next). This simplifies restarting from the correct point.
  5. Add a final report: upon completion of all threads, execute a summary entry in main.log with the number of successfully processed URLs and the number of errors.

Important Points

  • Log structure should be consistent. A single line format with the same fields simplifies analysis.
  • Protect the disk. Rotate logs: move old files to an archive folder or delete them based on age.

Tip: Use date prefixes in log names: logs\2026-06-22\thread_3.log. This will organize storage and speed up searches.

Tip: During debugging, enable extended logging level. In production mode, switch to standard to reduce overhead.

Expected Result

You have a clear picture of operations: who, when, with which proxy and IP processed which URL and with what result. In case of failure, you can understand the causes and quickly recover.

Possible Problems and Solutions

  • Problem: logs interfere with operation due to large volume. Cause: overly detailed records. Solution: reduce detail and enable log rotation.
  • Problem: inconsistent formats in different threads. Cause: unclear logging logic. Solution: isolate a log writing module and use it in all locations.

✅ Check: In logs and output folders, files with clear lines appeared. You can filter events by thread_id and quickly find failed requests.

Step 7: Sample Script — Visiting Pages and Collecting Basic Metrics

Stage Goal

Gather a minimally viable script (MVP) that visits a list of pages in multithreaded mode, checks responses, records load times, and returns results. This step is the basis for your own tasks.

Step-by-Step Instructions

  1. Thread initialization: read a unique proxy from res_proxies and set it. Perform an IP check and log ip_current.
  2. Get the next URL: read a line from res_urls, save it to the variable url_current. If lines run out, finish the thread correctly.
  3. Open the browser block "Open URL" with url_current. Set a timeout, e.g., 30000 ms. Before opening, add a timestamp t_start.
  4. Wait for the key element on the page using "Wait For Element" (if known to be stable). Otherwise, use the broad "Wait Document Loaded" with a timeout.
  5. Record the timestamp t_end and calculate elapsed_ms = t_end – t_start. Write the result in output\results.csv.
  6. In case of loading error, apply the logic from Step 5: up to 2 retries, in case of network errors — optional rotation, then retry. If it fails after the limit — log status=failed and move on to the next URL.
  7. Organize a loop through URLs: after logging the result, proceed to the next line in resource res_urls until exhausted.
  8. At the end of the thread, write a final record in thread_{{thread_id}}.log with the final statistics.

Important Points

  • Define clear success criteria. For example, status success — if the page loaded within 30 seconds and the element was found.
  • Ensure safety. Do not perform any actions that violate the rules of targeted websites or laws. The script should be ethical and transparent.

Tip: If you analyze public pages, add "User-Agent" and "Accept-Language" to BAS browser settings to make traffic appear natural. Do not change them too frequently without necessity.

Tip: Break the list of URLs into thematic groups and assign each thread its group. This will simplify result analysis and caching.

Expected Result

The script navigates the list of URLs in multiple threads, records load time and statuses, logs, and properly completes threads.

Possible Problems and Solutions

  • Problem: some pages load too slowly. Cause: overload or non-optimal timeouts. Solution: slightly increase timeouts and add "Wait For Element" for a stable selector.
  • Problem: metrics are not being recorded. Cause: calculation error or incorrect variables. Solution: log t_start and t_end, ensure you are taking time in one format.

✅ Check: In results.csv, there are lines with various URLs, actual IPs of threads, statuses, and load times. The logs correspond to each thread.

Step 8: Optimizing Multithreading and Working with Mobile Proxies

Stage Goal

Enhance the stability and performance of the project: scale the number of threads smoothly and distribute proxies sensibly.

Step-by-Step Instructions

  1. Conduct a load test: increase threads from 3 to 5, then to 7-10. At each step, monitor CPU, RAM, network load, and error percentages.
  2. Monitor the quality of mobile proxies: periodically run a short script for checking IPs and latencies (ping/latency through available sources). If a specific proxy yields more errors, temporarily exclude it from res_proxies.
  3. Organize proxy pools: fast, medium, slow. Assign threads proxies from the corresponding pool based on task criticality.
  4. Synchronize rotation with task duration: if one task averages 3-5 minutes, don’t set rotation more frequent than every 7-10 minutes unless necessary.
  5. Set up automatic "health" for threads: if a thread receives 3 consecutive network errors, change the proxy and pause for 60-120 seconds.
  6. Evaluate the limits of the mobile proxy provider: how many simultaneous connections are supported and how quickly rotation is available. For example, providers like mobileproxy.space often offer flexible rotation and clear limits — adhere to these.

Important Points

  • Balance speed and reliability. Too many threads can reduce overall success.
  • Avoid sharp spikes. Scale gradually while monitoring metrics.

Tip: Introduce a metric for "success rate over 10 minutes" per thread. If it falls below a threshold, automatically switch the thread to another proxy pool.

Tip: Maintain a blacklist of "bad" website-proxy combinations. If a particular website often rejects requests from the same proxy, avoid reusing that pair.

Expected Result

Increasing the number of threads does not break the script. The error percentage remains stable or decreases due to managing pools and rotation. The system predictably reacts to a degradation in proxy quality.

Possible Problems and Solutions

  • Problem: errors increase with more threads. Cause: lack of resources. Solution: reduce the number of threads, increase hardware resources, optimize delays.
  • Problem: too frequent rotation does not yield stable IP. Cause: aggressive intervals. Solution: increase intervals and use rotation only on events.

✅ Check: When increasing the threads to the target number, load tests show stable success, and the logs are not cluttered with network error retries.

Step 9: Final Assembly, Launch, and Portability

Stage Goal

Complete the project: tie all blocks together, create configuration parameters, and prepare for portability to another machine.

Step-by-Step Instructions

  1. Extract configuration into parameters: threads_count, timeouts, retry_limits, proxy_rotation_interval. In BAS, use "Variables" and "Settings" (if available) for centralized storage.
  2. Create a master script: structure initialization blocks for logs, resource loading, thread starting, and final reporting sequentially and add comments.
  3. Check paths: use relative paths (relative to the project folder) to simplify portability. For example, data\proxies.csv instead of C:\BAS\Projects\….
  4. Assemble a “clean” copy of the project folder: without unnecessary logs and temporary files. Place it in backups\release_YYYYMMDD.
  5. Test the portability to another machine: copy the folder, open the project in BAS, run it with 1-2 threads, check proxy and log functionality.
  6. Document the launch instructions: a short README.txt at the root of the project detailing parameters, requirements, and procedures for updating the proxy list.

Important Points

  • Configuration should be outside the code. The less "hardcoded" into blocks, the easier it is to change behavior without editing the script.
  • Test portability in advance. Don’t wait until the project is needed on another machine.

⚠️ Attention: Before transferring, ensure that no passwords are stored in open view in the project. Use BAS secure variables if possible, and permissions only within necessary rights.

Tip: For team project exchanges, use archives with hash sums and a checklist of files. This helps avoid accidental omissions.

Expected Result

A ready-to-run project with clear settings, a convenient structure, and the ability to transfer to another machine without needing to "fix paths."

Possible Problems and Solutions

  • Problem: resources are not read on the new machine. Cause: absolute paths. Solution: switch to relative paths and adjust folder structure.
  • Problem: no access to proxies. Cause: IP authentication, no whitelist. Solution: add the new machine's IP to the whitelist with the mobile proxy provider.

✅ Check: The project successfully launches on another machine, recognizes resources, connects to mobile proxies, and generates logs and results.

Result Verification

Checklist

  • BAS is installed and runs without errors.
  • The project structure is created, and resources are read correctly.
  • Mobile proxies connect; IP is verified and corresponds to the thread.
  • Multithreading works: 2-3+ threads process data in parallel.
  • Logs and results are written to separate files with a consistent format.
  • Error and retry handling is configured and predictable.
  • The project is portable to another machine.

How to Test

  1. Run 1 thread with 3 URLs, check the log and results.csv.
  2. Increase to 3 threads, check proxy uniqueness and IP matching with thread.
  3. Intentionally add 1 non-working proxy, see how retries and error logs work.
  4. Run on another machine (if available) and repeat the test.

Success Metrics

  • The percentage of successful attempts is stable (e.g., 95%+ on test pages).
  • No proxy collisions between threads.
  • Logs are intuitive and allow you to reconstruct the sequence of events.
  • Script execution time decreases proportionally with the number of threads.

Common Issues and Solutions

  • Problem: “Proxy authentication required.” Cause: incorrect credentials. Solution: check login/password and the format of the line in proxies.csv.
  • Problem: Two threads received the same proxy. Cause: resource without locking. Solution: enable “Take and lock” or a similar line locking feature.
  • Problem: IP doesn’t change after rotation. Cause: too frequent rotation requests or delays from the provider. Solution: increase interval, wait 30–120 seconds after the request and check rotation rules.
  • Problem: Threads stall during page loading. Cause: non-optimal timeouts or a heavy page. Solution: increase timeouts, use “Wait For Element,” add reasonable pauses.
  • Problem: A sharp increase in errors when increasing threads. Cause: lack of CPU/RAM/network resources. Solution: reduce the number of threads, optimize the script, add resources.
  • Problem: Logs overflow the disk. Cause: high detail level. Solution: enable log rotation, reduce detail level in production.
  • Problem: Unable to transfer the project. Cause: absolute paths. Solution: use relative paths and a uniform folder structure.
  • Problem: Proxy access errors on another machine. Cause: IP authorization, no whitelist. Solution: add the new machine’s IP to the mobile proxy provider's whitelist.

Advanced Features

Advanced Settings

  • Dynamic proxy pools: keep separate CSV files for different regions or tasks and switch between them based on conditions.
  • Complex thread orchestration: at the BAS level, you can structure task queues, prioritization, and limits on concurrent operations.
  • Custom headers and browser profiles: configure User-Agent and languages, enable or disable images/JS for load optimization, if it doesn't interfere with the script's goals.

Optimization

  • Caching: if your task allows it, use cache for immutable resources to speed up repeated calls.
  • Task separation: separate heavy steps (like analyzing large pages) into distinct stages, run them in queues.
  • Monitoring: external CPU/RAM/disk/network metrics and your own success rate metrics per thread will allow you to catch degradation in time.

What Else Can Be Done

  • Integration with notifications: upon completing the script, send an email or push notification with the results.
  • Automatic updating of proxy lists: if your provider supports issuing current hosts/ports, implement periodic synchronization.
  • Flexible rotation through the mobile provider’s API: for instance, services like mobileproxy.space often provide convenient requests to change IPs on schedule or by event.

⚠️ Attention: Any integrations and extensions should consider the laws and rules of targeted websites. Do not use automation for tasks that violate legislation or terms of resource usage.

FAQ

  • How to understand if the proxy is indeed being used? Open an IP check page (e.g., via httpbin), compare the visible IP with the IP from your network. It should match the proxy's IP.
  • How many threads can be launched? It depends on the CPU/RAM, proxy quality, and script complexity. Start with 2-3 and gradually increase while monitoring success.
  • Is mobile IP rotation necessary all the time? No. Rotate on an event (network error, block) or at reasonable intervals. Frequent rotation may hinder stability.
  • Which is better: login/password authentication or IP authentication? Using login/password makes transferring scripts between machines easier. IP authentication requires maintaining the whitelist when changing networks, but it involves fewer manual entries.
  • Can one proxy be used across multiple threads? Not recommended. This increases the risk of conflicts and reduces manageability. It’s advised to have one thread — one proxy.
  • How to store proxies without revealing passwords? Use BAS secure variables (if available), restrict access to files, and encrypt secret storage.
  • Why do some pages load slowly? Network delays, website overload, or heavy content may cause this. Use "Wait For Element," optimize timeouts, and reduce simultaneous operations.
  • What to do if the proxy provider is temporarily unstable? Have a backup pool from another provider, reduce the number of threads, and adapt rotation intervals until stability is restored.
  • Can a script be run without GUI? Yes, BAS supports running projects via a scheduler and console modes. Initially, debugging via GUI is recommended.
  • Where to look if something goes wrong? Check logs\main.log first, then thread_*.log, then results.csv. Verify the proxy matches the thread and check for authorization errors.

Conclusion

You've completed the full journey: from installing BAS to configuring mobile proxies and running a multithreaded script. We’ve created a project structure, integrated error handling logic, established logging and reporting systems, and checked portability. Now you have a basic yet reliable foundation: you can expand it for your tasks, add complex checks, enrich reporting, and scale multithreading as your needs and resources grow.

Next, you can: a) improve the accuracy of scripts through more refined conditions and selectors, b) introduce advanced thread orchestration, c) set up automatic replenishment and validation of the mobile proxy list using your provider's API (e.g., from mobileproxy.space), d) integrate notifications and monitoring for real-time stability control.

The key principle is gradualism. Scale cautiously, measure metrics, and document changes. Thus, automation on BAS with mobile proxies can become a predictable, safe, and effective tool for you. If you doubt your setup — revisit the sections 'Step 3: Connecting and Configuring Mobile Proxies in BAS' and 'Common Issues and Solutions' through the internal links at the beginning of the guide. Good luck with your practical automation!