Best Proxies for Puppeteer – Web Scraping at Scale
Integrate our residential proxies with Puppeteer for reliable web scraping. Reduce blocks and collect data from protected websites with real residential IPs.
Puppeteer scraping benefits from rotating IPs that change on every new connection. This reduces detection and blocks during large-scale data collection.
Easy integration via launch options
Rotate IPs automatically
Handle JavaScript-heavy sites
Household IPs for protected sites
Alternative Options
ISP Proxies
For consistent sessions on account-based tasks
Datacenter Proxies
For high-speed scraping of permissive sites
Setup guide
How to Set Up Proxies in Puppeteer
1
Install Puppeteer
Install Puppeteer in your Node.js project if not already done.
Use our rotating mode: each new connection gets a different IP automatically. Browsers reuse open connections, so start a new page or browser when you need a fresh IP.
Can I use with Puppeteer-extra?
Yes, our proxies work with puppeteer-extra and all its plugins including stealth plugin.
How to handle proxy errors?
Implement try-catch blocks and retry logic. Failed requests should retry with a new IP from the rotation pool.
Does it work with headless mode?
Yes, proxies work identically in both headless and headed modes.
Integrations
Works With Your Tools
Any tool that accepts an HTTP or SOCKS5 proxy works. These have their own setup guides.
A card is required. A paid 10 GB plan starts after 7 days unless you cancel. View trial terms.
Connect your proxy to a script or browser
Find connection settings, plan comparisons and checks you can run with your own pages before a larger order. Open the guide to choose a topic or follow the setup steps.
Read moreRead lessin this guide
Before and after: a saved proxy setup
These examples show which settings and checks to keep when you want to use the same setup again.
What to save
Before
After
Settings
An endpoint is pasted without notes.
Save the country, protocol and session settings with the application.
Page check
Only the connection status is checked.
Open the page and check its location and required fields.
Errors
The full page list is rerun after an error.
Save failed URLs and retry the ones that need another attempt.
How do you add a proxy to your script or browser tool?
Open the proxy settings for the client you use, such as a browser automation tool, HTTP library or desktop application. Copy the host, port, username and password from the dashboard, using the selected protocol's endpoint. First request an IP-check page. Then request one of your target pages and inspect the response. This gives you a simple working example before you add page navigation, form interactions or a queue of URLs.
Check the client's documentation for where the proxy applies. A setting may cover one browser instance or profile, while another instance keeps its own connection. For a script, confirm that both the initial request and later requests use the same configuration. Add the fields you need to extract and compare them with the page manually. After that, test a small list that includes pagination or a missing page if those occur in your project. Increase simultaneous requests gradually and follow the destination's limits. Keep the minimal working example with its password removed. When updating the client or changing the proxy settings, rerun that example first; it helps you locate a problem without working through the entire application.
Get one page working before adding pagination, browser actions or simultaneous requests.
Should you use HTTP, HTTPS or SOCKS5?
Fusion Proxy supports HTTP, HTTPS and SOCKS5 connections. For a browser or web request library, start with the proxy type supported in that application's settings. HTTPS websites can be reached through an HTTP proxy using an HTTPS tunnel. SOCKS5 is useful when the application has a SOCKS5 option. Copy the host and port for that protocol from the dashboard; changing the protocol without updating the port can leave you with a connection that fails.
Check the format expected by the client. Some tools ask for the proxy server and credentials separately, while others accept one connection URL. Keep HTTPS certificate verification enabled. If the client reports a proxy authentication error, recheck the username and password; if it times out, confirm the host, port and network access. Fusion Proxy carries TCP traffic and does not relay UDP. That distinction matters for games and other applications whose website uses HTTPS but whose live connection uses UDP. Test the exact application you want to route. A successful IP check in a browser confirms the browser configuration and gives you a useful starting point for checking another client.
Use the protocol and port shown for your selected endpoint and supported by your application.
Where should you store your proxy username and password?
Save your proxy username and password in the application's protected settings, an environment configuration or your team's password manager. Keep them out of public repositories and shared reports. If a tool stores a full proxy URL, remember that the URL may contain the password. Check screenshots and copied error messages before sharing them, especially when they show the endpoint generator or a browser's proxy settings.
To help someone reproduce a connection problem, send the client name and version, selected protocol, proxy host and port, approximate time with timezone, and the error message. Replace the password with a clear placeholder. A simple IP-check request is often enough to show an authentication or connection error without sharing customer data. If credentials were exposed, change them through the supported account controls and update every application that uses them. Test one connection before restarting a queue of jobs. For a shared setup, record who maintains it and where the current credentials are stored. That lets another teammate make a planned change without searching through chat messages or copying an outdated password from an old script.
Keep working credentials private and remove the password from screenshots and support examples.
Do you need a browser check or an API connection?
Check whether the service already offers an API for the information you need. Product identifiers, stock fields or other structured records may be easier to retrieve through a supported API than by reading a page. Look at the available fields, account access, update schedule and request limits. A browser remains useful when you need to see the actual page, such as its layout, language, images or the offer shown after selecting a delivery area.
For a shop review, you might use an API to maintain a product list and then open selected products in a browser to inspect their presentation. Keep the two parts connected with the product identifier. Check the permitted uses and retention terms of the source before collecting data. If you use a proxy with a browser or API client, test that client's connection settings and authentication separately from the destination's own login or API key. Include maintenance in the choice: a page redesign can change selectors, while an API version change can alter fields. Keep a short test that checks the fields your application depends on so you can spot either kind of change before a full run.
Use an API for the fields it provides and a browser when you need to inspect the rendered page.
When should the proxy IP rotate?
Choose rotating residential connections for checks that can finish independently, such as reading separate public product pages. Generate a rotating endpoint in the dashboard and use it in the application making those requests. Each result should include the page address and the time it was fetched, so you can find the original page if something looks wrong. Check how your client reuses network connections when you need a fresh exit for a new request.
A login, shopping basket or multi-page form usually needs more continuity. Choose a sticky session for those steps and keep the same browser profile until the task is finished. Switching the IP during a login can cause another verification prompt or interrupt the session. When a request fails, read the error before changing the IP. Incorrect credentials need correcting, and a broken page selector needs updating. For a temporary timeout, retry a limited number of times with a delay. Keep the destination's rate limits in place across all connections. Rotating addresses should be part of a planned request schedule, with unfinished URLs saved so you can retry them without downloading the whole list again.
Use rotating connections for separate requests and keep related steps in one session.
How long can you keep a residential session?
Fusion Proxy's standard residential product offers sticky sessions from 1 to 120 minutes. In the endpoint generator, choose Sticky, set the duration and copy the generated connection details into your application. Use those details throughout the visit. This suits a series of connected actions, such as signing in to an account you manage, opening several account pages and checking a setting. Keep the browser's cookies and storage in the same profile during the session.
Choose a duration that leaves time for the whole visit, including typing and normal pauses. For example, if your own test normally takes around ten minutes, allow some extra time for a slow page or a verification step. Check the public IP at the beginning and end when troubleshooting an unexpected change. Household connections can become unavailable, so save progress before any step that is difficult to repeat. If a connection is lost during a form submission, check whether the submission succeeded before sending it again. When you need an address to remain assigned across several days, use the static ISP or datacenter options rather than extending a short residential visit.
Set a sticky duration from 1 to 120 minutes and use the same session for each connected step.
What should you check when a proxy request fails?
Check the error returned by your client before starting another request. A proxy authentication error usually points to the credentials or the way they were entered. A timeout can involve the proxy connection, the destination or your own network. If a website loads but the expected price or heading is missing, inspect the page content and the selector used by your script. Keeping these errors separate makes the next step much clearer.
For a temporary connection failure, use a small retry limit and a delay between attempts. Save the failed URL so it can be retried later without running the whole list again. If the destination returns a rate limit, follow its retry instructions and reduce the request rate. Stop and review access when the site rejects the requested operation. Be especially careful with forms, orders and account changes: a timeout after submission can occur even though the change succeeded. Check the account before submitting the same action again. When contacting support, include the time, client, protocol and response message, with the password removed. A single request that reproduces the problem is more useful than a log full of repeated failures.
Read the response first: a timeout, incorrect password and blocked page each need a different fix.
Which pages should you test before a larger order?
Choose a short list of pages that reflects your project. For a shopping-site check, include a category page, a product with several variants and a product that is unavailable. For a localized website, include the homepage and a page where language or delivery options change. If you need several countries, run the same checks in each one. These examples show whether the setup handles the parts of the site your project actually uses.
Write down the fields you expect before running the test. Open a few results manually and compare them with the values saved by the script. Look for missing prices, unexpected currencies, duplicate products and pages that show a login prompt. Repeat a small part of the test after changing just one setting, such as the requested city or session type, so you can see its effect. Save the working endpoint configuration with the password removed. Also try a deliberately unavailable page to check that your application records the error and moves on. Once the sample works, use its traffic consumption and completion time to estimate the size and schedule of the full run.
Include the kinds of pages your application will visit, including one that shows how it handles an error.
Before and after: save a setup you can use again
Before saving a setup, a team may paste a proxy into a browser, open a page and leave the settings in that one window. The next person then has to find the endpoint, choose a location and repeat the checks. A saved setup is easier to use again: give the profile a clear name, keep the credentials in protected settings and record the country, session type and test page beside it.
For example, a shop team checking its German catalogue could save a German residential endpoint, a browser profile with German language settings and a delivery postcode used for the test. Keep a product URL and the fields to check, such as price, currency and stock status. On the next visit, open that profile and repeat the same check before starting the full product list. If a result differs, you can inspect the saved settings and the page instead of guessing which connection was used. Update the notes when the shop changes its page layout or the team changes its test location. This also gives a colleague enough information to continue while the original operator is away.
Save the settings with a tested page so your next run starts from a configuration you already know.
How can you tell whether a scheduled job is still working?
For a scheduled collection job, keep a short summary of each run: pages attempted, pages completed, errors and the fields that were missing. A price-monitoring script should tell you when it saved a product without a price or currency. A localized website check should report an unexpected country or language. These checks catch problems such as a changed page layout that can leave the network connection working while the saved data becomes incomplete.
Keep the application version and selected location with the run summary. When a result changes, compare it with a recent run using the same page list and settings. If the new run includes many more pages, allow for that difference before treating a longer completion time as a problem. Choose alerts that tell someone what to do next: update expired credentials, inspect a changed product page or pause a queue that is repeatedly receiving rate limits. Keep a few redacted error examples to help with diagnosis. Review the dashboard's traffic usage alongside the completed page count, especially after changing retries or adding browser resources. A sudden increase can reveal repeated downloads that deserve attention.
Watch for missing fields and unexpected pages as well as connection errors.
Need help choosing or connecting?
Check current plans and available locations before ordering. For setup help, use the connection documentation or tell support which application and website you want to connect. Include any error message and the selected protocol, with the password removed.