تنظیم پروکسی در Puppeteer: احراز هویت، چرخش IP و SOCKS5

مقدار --proxy-server=http://user:pass@host:port را همان‌طور که پروکسی را برای cURL می‌نویسید به آرگومان‌های اجرا اضافه می‌کنید و نخستین page.goto() با net::ERR_NO_SUPPORTED_PROXIES متوقف می‌شود. اطلاعات ورود را برمی‌دارید و خطا به net::ERR_INVALID_AUTH_CREDENTIALS تبدیل می‌شود. Puppeteer گزینه پروکسی جداگانه‌ای ندارد. این کتابخانه Chrome را اجرا می‌کند و Chrome است که تصمیم می‌گیرد پروکسی چگونه به کار رود؛ برای همین پاسخ بیشتر پرسش‌ها در قواعد Chrome است، نه در API خود Puppeteer.

این نوشته پرچم اجرا (launch flag) و page.authenticate()، پروکسی جداگانه برای هر browser context، نشست‌های ثابت (sticky) و چرخشی، SOCKS5، فهرست استثنا (bypass list)، بررسی IP خروجی، خطاهایی که با آن‌ها روبه‌رو می‌شوید و یک اسکریپت کامل با تلاش دوباره را در بر می‌گیرد. همه نمونه‌ها را در 6 اکتبر 2026 با ⁦Puppeteer 25.12.0⁩ و نسخه ⁦Chrome 154⁩ که همراه آن دانلود می‌شود اجرا کردیم. طرف دیگر آزمون‌ها یک پروکسی HTTP محلی بود که نام کاربری و رمز عبور می‌خواهد، به‌علاوه یک سرور SOCKS5 محلی. پیام‌های خطایی که نقل می‌کنیم همان‌هایی است که خودمان گرفتیم.

Puppeteer ترافیک را چگونه از پروکسی عبور می‌دهد؟#

Puppeteer یک کتابخانه Node.js است که یک مرورگر واقعی را از درون کد هدایت می‌کند. خودش اتصال شبکه باز نمی‌کند؛ این کار را مرورگر انجام می‌دهد. پس پروکسی یکی از تنظیمات Chrome است که یا هنگام اجرای مرورگر به شکل پرچم خط فرمان داده می‌شود یا هنگام ساختن یک browser context به شکل یک گزینه. browser context نشستی جدا درون یک مرورگر است با کوکی‌ها، حافظه نهان و فضای ذخیره‌سازی خودش؛ چیزی شبیه پنجره ناشناس.

ورود به پروکسی گام جداگانه‌ای است، چون Chrome اطلاعات ورود را از نشانی پروکسی نمی‌خواند. پروکسی آزمایشی ما برای یک صفحه HTTPS این ترتیب را ثبت کرد:

1. Chrome درخواست CONNECT httpbin.org:443 را می‌فرستد و از پروکسی می‌خواهد تونلی به سایت باز کند. برای صفحه http:// خود درخواست را می‌فرستد.
2. درخواست اطلاعات ورود ندارد، پس پروکسی با 407 Proxy Authentication Required پاسخ می‌دهد. ⁦RFC 9110⁩ کد 407 را همتای 401 در سمت پروکسی تعریف می‌کند.
3. Puppeteer این درخواست احراز هویت (challenge) را می‌گیرد و با نام کاربری و رمز عبوری که به page.authenticate() داده شده پاسخ می‌دهد.
4. Chrome درخواست را با هدر Proxy-Authorization تکرار می‌کند، پروکسی 200 برمی‌گرداند و اتصال رمزگذاری‌شده به سایت درون تونل ساخته می‌شود. پروکسی نام میزبان را می‌بیند، نه محتوای صفحه را.
5. Chrome اطلاعات ورود را در حافظه نهان احراز هویت همان context نگه می‌دارد و در اتصال‌های بعدی بی‌درنگ می‌فرستد.

گام 5 دلیل آن است که اطلاعات ورود به context تعلق پیدا می‌کند؛ آزمون‌های پایین‌تر این را نشان می‌دهند.

پروکسی را چگونه با ⁦--proxy-server⁩ و ⁦page.authenticate()⁩ تنظیم کنیم؟#

فرمان npm i puppeteer کتابخانه را نصب می‌کند و یک Chrome سازگار هم دانلود می‌کند؛ puppeteer-core همان API است بدون این دانلود. ساده‌ترین تنظیم این است:

import puppeteer from "puppeteer";

const browser = await puppeteer.launch({
  args: ["--proxy-server=http://pr.proxynet.io:8000"],
});
const page = await browser.newPage();
await page.authenticate({ username: "user", password: "pass" });

await page.goto("https://httpbin.org/ip");
console.log(await page.$eval("body", (el) => el.innerText)); // the exit IP the site sees

await browser.close();

بخش http:// در پرچم، اتصال به خود پروکسی را توصیف می‌کند، نه صفحه‌ها را. پروکسی HTTP سایت‌های https:// را هم از درون تونل جابه‌جا می‌کند و محتوای آن‌ها میان Chrome و سایت رمزگذاری‌شده می‌ماند. مرجع page.authenticate() اضافه می‌کند که Puppeteer برای این کار در پشت صحنه رهگیری درخواست (request interception) را روشن می‌کند که ممکن است کمی از کارایی بکاهد؛ دادن null آن را خاموش می‌کند.

در آزمون‌های ما سه چیز خراب شد و از هر کدام قاعده‌ای ثابت به دست آمد:

• page.authenticate() را پیش از نخستین goto() فراخوانی کنید. وقتی بعد از آن فراخوانی شد، نخستین ناوبری با net::ERR_INVALID_AUTH_CREDENTIALS شکست خورد و فقط ناوبری بعدی گذشت.
• اطلاعات ورود را در پرچم ننویسید. با user:pass@ در نشانی، ⁦Chrome 154⁩ کل مقدار را با net::ERR_NO_SUPPORTED_PROXIES رد کرد. راهنماهای قدیمی‌تر در اینجا از 407 می‌گویند؛ امروز درخواست اصلاً به پروکسی نمی‌رسد.
• Proxy-Authorization را خودتان نفرستید. تنظیم آن با page.setExtraHTTPHeaders() باعث شد Chrome ناوبری را با net::ERR_INVALID_ARGUMENT رد کند.

چگونه برای هر browser context پروکسی جداگانه به کار ببریم؟#

در ⁦Puppeteer 22⁩ نام createIncognitoBrowserContext()، که راهنماهای قدیمی هنوز به کار می‌برند، به browser.createBrowserContext() تغییر کرد. BrowserContextOptions آن دو فیلد پروکسی دارد: proxyServer و proxyBypassList. مرورگر می‌تواند بدون پروکسی اجرا شود و هر context پروکسی خودش را بگیرد:

import puppeteer from "puppeteer";

const PROXY = "http://pr.proxynet.io:8000";
// One sticky session per context: same session ID -> same exit IP for up to 600 seconds
const sessions = ["a1b2c3", "d4e5f6"];

const browser = await puppeteer.launch(); // the browser itself starts without a proxy
for (const id of sessions) {
  const context = await browser.createBrowserContext({ proxyServer: PROXY });
  const page = await context.newPage();
  await page.authenticate({ username: `user-session-${id}-ttl-600`, password: "pass" });

  for (let i = 0; i < 2; i++) {
    await page.goto("https://httpbin.org/ip");
    console.log(id, await page.$eval("body", (el) => el.innerText));
  }
  await context.close(); // cookies, cache and the proxy setting go with the context
}
await browser.close();

پروکسی آزمایشی ما مانند یک گیت‌وی، نقطه خروج را بر پایه شناسه نشست می‌دهد. دو context از دو نشانی متفاوت خارج شدند و هر کدام نشانی خود را در درخواست دوم هم نگه داشت. دو نتیجه دیگر در کارهای واقعی اهمیت دارد:

• اطلاعات ورود به context تعلق دارد، نه به صفحه. صفحه دومی در همان context تابع page.authenticate() را با نام کاربری دیگری فراخوانی کرد، اما همه درخواست‌هایش باز هم نام کاربری نخست را داشتند. صفحه‌ای هم که اصلاً آن را فراخوانی نکرد با همان اطلاعات ورود ذخیره‌شده گذشت.
• context بدون proxyServer پروکسی پرچم اجرا را به ارث می‌برد، اما اطلاعات ورود خودش را نگه می‌دارد. با --proxy-server روی مرورگر، دو context با شناسه‌های نشست جداگانه باز هم از دو نقطه خروج متفاوت خارج شدند.

قاعده عملی این است: یک نشست، یک context، یک نام کاربری.

چرخشی یا sticky: کدام نوع نشست به کار مرورگر می‌آید؟#

مرورگر برای هر صفحه فقط یک درخواست نمی‌فرستد. یک صفحه محصول سند HTML، اسکریپت‌ها، فایل‌های سبک، تصویرها و فراخوانی‌های API پس‌زمینه را می‌گیرد، اغلب از چند میزبان و روی چند اتصال. در گیت‌وی چرخشی هر اتصال تازه می‌تواند IP خروجی تازه‌ای بگیرد؛ در آزمون ما حتی آیکون زبانه (favicon) یک صفحه از نشانی دیگری جز خود صفحه خارج شد. برای صفحه‌هایی که به هم ربطی ندارند این بی‌ضرر است. اما در ورود به حساب، سبد خرید یا فرم چندمرحله‌ای، سایت می‌بیند که یک بازدیدکننده میان نشانی‌ها جابه‌جا می‌شود و ممکن است نشست را پایان دهد.

گیت‌وی نوع نشست را از نام کاربری می‌خواند و سازنده نقطه اتصال در پنل کاربری آن را برایتان می‌نویسد. بخش‌های آن به‌راحتی خوانده می‌شوند: -country-de کشور خروج را انتخاب می‌کند (شهر هم در همان سازنده انتخاب می‌شود)، -session-a1b2c3-ttl-600 یک نقطه خروج را برای آن شناسه نشست به تعداد ثانیه‌ای که می‌نویسید نگه می‌دارد، در بازه 1 تا 60 دقیقه، و نام کاربری بدون بخش نشست چرخشی است.

برای صفحه‌های مستقل مانند فهرست دسته‌بندی یا نتیجه جست‌وجو که در context‌های کوتاه‌عمر باز می‌شوند، از پروکسی چرخشی استفاده کنید.

برای هر کاری که وضعیت نگه می‌دارد از پروکسی با نشست ثابت استفاده کنید: یک context، یک شناسه نشست، با مدتی بلندتر از زمانی که آن روند طول می‌کشد. وقتی کار تمام شد context را ببندید تا کوکی‌ها و IP با هم پایان یابند.

چرخش، کارهای مستقل را میان نقطه‌های خروج پخش می‌کند؛ راهی برای گذشتن از محدودیت‌های یک سایت نیست. پاسخ 429 Too Many Requests یا 403 Forbidden از شما می‌خواهد آهسته‌تر پیش بروید و IP تازه این پاسخ را عوض نمی‌کند.

آیا Puppeteer با پروکسی SOCKS5 کار می‌کند؟#

بله، اما بدون نام کاربری و رمز عبور. مستندات پروکسی Chromium می‌گوید که برای SOCKSv5 هیچ روش احراز هویتی پشتیبانی نمی‌شود. سرور SOCKS5 محلی ما همین را از سوی دیگر دید: پیام آغازین Chrome فقط روش 0x00 یعنی «بدون احراز هویت» را پیشنهاد کرد. سروری که روش نام کاربری و رمز عبور (0x02) را الزامی می‌دانست ناچار بود این پیشنهاد را رد کند و ناوبری با net::ERR_SOCKS_CONNECTION_FAILED شکست خورد. page.authenticate() هم تفاوتی ایجاد نکرد، چون در SOCKS5 درخواست احراز هویتی از نوع 407 وجود ندارد که Puppeteer به آن پاسخ دهد.

راه‌حل این است که هویت خود را با آدرس IP ثابت کنید. IP عمومی دستگاهی را که Chrome روی آن اجرا می‌شود در پنل کاربری به لیست سفید IP اضافه کنید (حداکثر 10 نشانی)، پورت SOCKS5 را که سازنده نقطه اتصال نشان می‌دهد بردارید و مرورگر را بدون اطلاعات ورود اجرا کنید:

import puppeteer from "puppeteer";

// No username or password: this machine's public IP must be on the IP whitelist.
// SOCKS5_PORT: the SOCKS5 port shown in the endpoint builder.
const { SOCKS5_PORT } = process.env;

const browser = await puppeteer.launch({
  args: [`--proxy-server=socks5://pr.proxynet.io:${SOCKS5_PORT}`],
});
const page = await browser.newPage();
await page.goto("https://httpbin.org/ip");
console.log(await page.$eval("body", (el) => el.innerText));
await browser.close();

Chrome به سرور SOCKS5 نام میزبان فرستاد، نه آدرس IP؛ پس DNS در سمت پروکسی تحلیل می‌شود و عادت socks5h:// که از cURL می‌شناسید در اینجا لازم نیست. برای صفحه‌های وب، پروکسی HTTP معمولاً گزینه ساده‌تری است، چون با page.authenticate() کار می‌کند.

چگونه برخی نشانی‌ها را از پروکسی بیرون نگه داریم؟#

پرچم --proxy-bypass-list، یا proxyBypassList به شکل آرایه در یک context، میزبان‌هایی را فهرست می‌کند که Chrome مستقیم به آن‌ها وصل می‌شود. در پرچم، قاعده‌ها با نقطه‌ویرگول یا ویرگول از هم جدا می‌شوند: --proxy-bypass-list=*.internal.example;192.168.0.0/16. در آزمون ما میزبانی که در فهرست بود اصلاً از پروکسی نگذشت و نامش روی همان دستگاه محلی تحلیل شد.

Chrome قاعده‌های ضمنی هم دارد: localhost، *.localhost، 127.0.0.1/8 و [::1] حتی با فهرست خالی هرگز از پروکسی استفاده نمی‌کنند. اگر در برابر یک سرور محلی آزمون می‌گیرید و گزارش پروکسی ساکت می‌ماند، دلیلش همین است. قاعده ویژه <-loopback> این قاعده‌های ضمنی را برمی‌دارد؛ با آن، درخواست ما به 127.0.0.1 از پروکسی گذشت.

IP خروجی را چگونه بررسی کنیم؟#

یک context مستقیم را با یک context دارای پروکسی در همان مرورگر مقایسه کنید. اگر نشانی‌ها متفاوت باشند، ترافیک از پروکسی می‌گذرد:

import puppeteer from "puppeteer";

async function exitIp(context, credentials) {
  const page = await context.newPage();
  if (credentials) await page.authenticate(credentials);
  await page.goto("https://httpbin.org/ip");
  const { origin } = JSON.parse(await page.$eval("body", (el) => el.innerText));
  await page.close();
  return origin;
}

const browser = await puppeteer.launch();
const direct = await browser.createBrowserContext();
const proxied = await browser.createBrowserContext({ proxyServer: "http://pr.proxynet.io:8000" });

const own = await exitIp(direct);
const viaProxy = await exitIp(proxied, { username: "user", password: "pass" });
console.log({ own, viaProxy, proxyWorks: own !== viaProxy });
await browser.close();

اگر کشور خاصی را هدف گرفته‌اید، IP خروجی را در یک سرویس موقعیت‌یابی جغرافیایی هم بررسی کنید. وقتی بررسی شکست می‌خورد، Chrome را از ماجرا کنار بگذارید: آزمون‌های خط فرمانی که مشکل شبکه را از مشکل کد جدا می‌کنند در نوشته آیا پروکسی کار می‌کند؟ چگونه پروکسی را آزمایش کنیم آمده است.

با چه خطاهایی روبه‌رو می‌شوید و معنای هر کدام چیست؟#

هر یک از این خطاها را در محیط آزمایشی محلی خودمان پدید آوردیم:

سطر رمز عبور نادرست از همه دیرتر خود را نشان می‌دهد: هیچ خطایی پرتاب نمی‌شود و اسکریپت با صفحه 407 پروکسی به کار ادامه می‌دهد. در مرورگر دسکتاپ خطای تونل علت‌های بیشتری دارد، از اسکن HTTPS آنتی‌ویروس تا تنظیم پروکسی سیستمی کهنه؛ نوشته خطای ⁦err_tunnel_connection_failed⁩ چیست و چگونه رفع می‌شود؟ را ببینید. در زمان توسعه، این دو شنونده خطای واقعی پشت یک پایان مهلت را نشان می‌دهند:

page.on("requestfailed", (req) => console.log("FAILED", req.url(), req.failure()?.errorText));
page.on("response", (res) => res.status() >= 400 && console.log(res.status(), res.url()));

نمونه کامل: context‌های موازی، نشست‌های ثابت و تلاش دوباره#

این اسکریپت شش صفحه را که با JavaScript ساخته می‌شوند باز می‌کند و هم‌زمان حداکثر سه context باز نگه می‌دارد. هر تلاش یک context تازه و یک نشست ثابت تازه می‌گیرد تا کوکی‌ها و IP خروجی با هم عوض شوند. تصویر، رسانه و فونت برای صرفه‌جویی در ترافیک مسدود می‌شوند؛ page.setRequestInterception() این کار را بدون خراب کردن page.authenticate() انجام می‌دهد. پایان مهلت و شکست تونل با انتظار نمایی (exponential backoff) دوباره تلاش می‌شوند، اما خطاهای پیکربندی و پاسخ 403 یا 429 از سوی سایت کار را متوقف می‌کنند.

import puppeteer from "puppeteer";

const PROXY = "http://pr.proxynet.io:8000";
const USER = "user";
const PASS = "pass";
const URLS = Array.from({ length: 6 }, (_, i) => `https://quotes.toscrape.com/js/page/${i + 1}/`);
const CONCURRENCY = 3; // contexts open at the same time
const ATTEMPTS = 3;
const BLOCKED = new Set(["image", "media", "font"]);
// Configuration errors: waiting and retrying will not fix them
const FATAL = ["ERR_PROXY_CONNECTION_FAILED", "ERR_NO_SUPPORTED_PROXIES", "ERR_INVALID_AUTH_CREDENTIALS"];

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function scrape(browser, url) {
  for (let attempt = 1; attempt <= ATTEMPTS; attempt++) {
    // One context per attempt: its own cookies and its own sticky session (one exit IP)
    const context = await browser.createBrowserContext({ proxyServer: PROXY });
    try {
      const page = await context.newPage();
      const session = crypto.randomUUID().slice(0, 8);
      await page.authenticate({ username: `${USER}-session-${session}-ttl-300`, password: PASS });
      await page.setRequestInterception(true);
      page.on("request", (req) => (BLOCKED.has(req.resourceType()) ? req.abort() : req.continue()));

      const res = await page.goto(url, { waitUntil: "domcontentloaded", timeout: 30_000 });
      const status = res ? res.status() : 0;
      if (status === 403 || status === 429) {
        // The site is refusing or slowing you down: a new IP is not the answer
        throw Object.assign(new Error(`HTTP ${status}: stop and lower the request rate`), { fatal: true });
      }
      if (status >= 400) throw new Error(`HTTP ${status}`);

      await page.waitForSelector("div.quote span.text", { timeout: 10_000 }); // JavaScript-rendered
      return await page.$$eval("div.quote span.text", (els) => els.map((el) => el.textContent));
    } catch (err) {
      err.fatal ||= FATAL.some((code) => err.message.includes(code));
      if (err.fatal || attempt === ATTEMPTS) throw err;
      await sleep(2 ** attempt * 1000 + Math.random() * 1000); // back off before the next attempt
    } finally {
      await context.close();
    }
  }
}

const browser = await puppeteer.launch();
const queue = [...URLS];
const results = new Map();
await Promise.all(
  Array.from({ length: CONCURRENCY }, async () => {
    while (queue.length) {
      const url = queue.shift();
      try {
        results.set(url, `${(await scrape(browser, url)).length} quotes`);
      } catch (err) {
        results.set(url, `ERROR ${err.message.split("\n")[0]}`);
        if (err.fatal) queue.length = 0; // stop the whole job, not just this page
      }
    }
  }),
);
await browser.close();
for (const url of URLS) console.log(url, results.get(url) ?? "skipped");

از طریق پروکسی آزمایشی محلی، هر شش صفحه در کمتر از پنج ثانیه و هر کدام با ده نقل‌قول برگشتند. وقتی پورت پروکسی را عمداً نادرست نوشتیم، سه صفحه‌ای که در جریان بودند بی‌درنگ با net::ERR_PROXY_CONNECTION_FAILED متوقف شدند و سه صفحه دیگر با برچسب skipped کنار گذاشته شدند؛ یک صفحه آزمایشی محلی که با 429 پاسخ می‌داد هم کار را به همین شکل پایان داد. با CONCURRENCY کم آغاز کنید: هر context حافظه نگه می‌دارد و سایت مقصد هم محدودیت‌های خودش را دارد.

کاربردها#

• صفحه‌های کاتالوگ و قیمت که با JavaScript ساخته می‌شوند و یک کلاینت ساده HTTP آن‌ها را خالی می‌بیند.
• بررسی اینکه سایت، قیمت‌ها یا بنرهای رضایت کوکی خودتان از کشوری دیگر چگونه دیده می‌شوند؛ برای هر کشور یک context.
• تصویر صفحه و PDF از صفحه‌های عمومی، به همان شکلی که بازدیدکننده‌ای در کشوری مشخص آن‌ها را می‌بیند.
• پایش صفحه‌ها و روندهای پرداخت خودتان از بیرون شبکه‌تان.

چارچوب همه این کارها یکی است: به robots.txt و شرایط استفاده سایت پایبند باشید، اگر API رسمی وجود دارد از آن استفاده کنید و سرعت درخواست‌ها را در سطحی نگه دارید که سایت تاب بیاورد.

اشتباهات رایج#

• نوشتن user:pass@ در --proxy-server. Chrome مقدار را با net::ERR_NO_SUPPORTED_PROXIES رد می‌کند.
• انتظار نام کاربری تازه برای هر صفحه. Chrome نخستین اطلاعات ورود را برای کل context نگه می‌دارد؛ برای هر نشست یک context به کار ببرید.
• امتحان کردن رمز عبور در SOCKS5. Chrome فقط «بدون احراز هویت» را پیشنهاد می‌کند؛ از لیست سفید IP یا پورت HTTP استفاده کنید.
• آزمودن در برابر localhost و اعتماد به نتیجه. نشانی‌های loopback از پروکسی نمی‌گذرند، مگر اینکه <-loopback> را اضافه کنید.
• صفحه دانستن پاسخ 407. رمز عبور نادرست خطا پرتاب نمی‌کند؛ response.status() را بررسی کنید.
• عوض کردن IP پس از 429 یا 403. به جای آن آهسته‌تر پیش بروید؛ محدودیت به رفتار شما مربوط است، نه به نشانی‌تان.
• باز گذاشتن context‌ها. هر کدام حافظه نگه می‌دارد؛ آن‌ها را در بلوک finally ببندید.

راهنمای انتخاب#

پرسش‌های متداول#

آیا ⁦puppeteer.launch()⁩ گزینه پروکسی دارد؟#

خیر. پروکسی به شکل پرچم --proxy-server در Chrome درون args قرار می‌گیرد و ورود در page.authenticate() انجام می‌شود. API خود Puppeteer فقط در browser.createBrowserContext() فیلد پروکسی دارد: proxyServer و proxyBypassList.

آیا هر صفحه می‌تواند پروکسی خودش را داشته باشد؟#

درون یک context نه. پروکسی و اطلاعات ورود ذخیره‌شده به context تعلق دارند، به همین دلیل در آزمون ما صفحه دوم با اطلاعات ورود متفاوت باز هم از اطلاعات نخست استفاده کرد. به هر صفحه‌ای که نقطه خروج جداگانه می‌خواهد context خودش را بدهید؛ یک context بسیار ارزان‌تر از یک مرورگر تازه است.

proxy-chain چیست و آیا به آن نیاز دارید؟#

proxy-chain یک بسته متن‌باز Node.js است که تابع anonymizeProxy() آن یک پروکسی محلی بدون رمز عبور راه می‌اندازد و ترافیک را به یک پروکسی بالادستی دارای اطلاعات ورود می‌فرستد؛ به این ترتیب Chrome یک نشانی ساده http://127.0.0.1:<port> می‌گیرد. در آزمون ما هم با پروکسی بالادستی HTTP و هم با SOCKS5 که هر دو رمز عبور می‌خواستند کار کرد. اگر از page.authenticate() یا لیست سفید IP استفاده می‌کنید به آن نیازی ندارید.

آیا می‌توان پروکسی را بدون راه‌اندازی دوباره مرورگر عوض کرد؟#

بله، از راه context‌ها. context را ببندید، یکی تازه با proxyServer یا شناسه نشست دیگری باز کنید و page.authenticate() را دوباره فراخوانی کنید. فقط پرچم --proxy-server در تمام عمر مرورگر ثابت می‌ماند.

چرا گزارش پروکسی درخواست‌هایی را نشان می‌دهد که شما نفرستاده‌اید؟#

ترافیک پس‌زمینه خود Chrome، مانند بررسی به‌روزرسانی و درخواست‌های سرویس‌های گوگل، به همان پروکسی می‌رود. در گزارش ما بیشتر این درخواست‌ها بدون اطلاعات ورود رسیدند و 407 گرفتند، چون page.authenticate() فقط به درخواست‌های احراز هویتی پاسخ می‌دهد که از ترافیک صفحه می‌آیند. این موضوع روی صفحه‌های شما اثری ندارد.

آیا پروکسی جلوی CAPTCHA را در Puppeteer می‌گیرد؟#

خیر. پروکسی فقط جایی را که ترافیک از آن می‌آید عوض می‌کند، در حالی که CAPTCHA به سرعت درخواست‌ها، نشانه‌های مرورگر و نشست‌های ناسازگار هم واکنش نشان می‌دهد. علت‌ها و راه‌های مشروع کم کردن آن در نوشته Puppeteer و CAPTCHA: چرا ظاهر می‌شود و چگونه کم می‌شود؟ آمده است.

خلاصه#

در Puppeteer پروکسی یکی از تنظیمات Chrome است: پرچم --proxy-server برای کل مرورگر یا proxyServer برای یک context، و ورود با page.authenticate() پیش از نخستین ناوبری. اطلاعات ورود برای هر context جداگانه ذخیره می‌شود؛ پس هر نشست را به شکل یک context بسازید، ثابت یا چرخشی بودن را با نام کاربری انتخاب کنید و برای SOCKS5 از لیست سفید IP استفاده کنید. response.status() را بررسی کنید و سرعت درخواست‌ها را در حدی مؤدبانه نگه دارید. برای صفحه‌هایی که باید از اتصال‌های خانگی معمولی باز شوند، نقطه‌های خروج از استخر پروکسی مسکونی می‌آیند.