在 Playwright 與 Puppeteer 中使用代理：Python 與 Node（2026）

無頭瀏覽器會渲染 JavaScript，所以能處理純 HTTP 用戶端無法應付的現代站台。但瀏覽器仍然從同一個 IP 送出每個請求，而一旦站台對該位址做速率限制或指紋辨識，自動化就會當場被抓。搭配 Playwright 與 Puppeteer 使用代理能把流量分散到多個 IP，而且做得好的話，會讓你的自動化看起來像一般使用者。以下是兩者在 Python 與 Node 中的可用設定。

Playwright 搭配代理（Python）

在瀏覽器啟動時設定代理。把驗證資訊以獨立的 username 與 password 欄位傳入 — 別把憑證內嵌在伺服器 URL 裡：

from playwright.sync_api import sync_playwright

PROXY = {
    "server": "http://gate.jibaoproxy.com:10001",
    "username": "USERNAME",
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY, headless=True)
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.inner_text("body"))
    browser.close()

JIBAO 在閘道上同時提供 HTTP 與 SOCKS5。瀏覽器自動化請用 HTTP 端點：Playwright 與 Puppeteer 不支援需驗證的 SOCKS5 代理，所以帶驗證的 HTTP 才是可靠選擇。

Playwright 搭配代理（Node）

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch({
    headless: true,
    proxy: {
      server: 'http://gate.jibaoproxy.com:10001',
      username: 'USERNAME',
      password: 'PASSWORD',
    },
  });
  const page = await browser.newPage();
  await page.goto('https://httpbin.org/ip');
  console.log(await page.innerText('body'));
  await browser.close();
})();

每個瀏覽器 Context 輪換 IP

在 Playwright 中最乾淨的輪換方式，是每個 BrowserContext 一個 IP。每個 context 都是獨立的工作階段（有自己的 cookie 與快取），所以把每一個綁定到不同的出口 IP，就能在單一瀏覽器程序內取得並行的多重身分：

from playwright.sync_api import sync_playwright

def ctx_proxy(session_id):
    return {
        "server": "http://gate.jibaoproxy.com:10001",
        "username": f"USERNAME-session-{session_id}",
        "password": "PASSWORD",
    }

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    for i in range(3):
        context = browser.new_context(proxy=ctx_proxy(f"ctx{i}"))
        page = context.new_page()
        page.goto("https://httpbin.org/ip")
        print(i, page.inner_text("body"))
        context.close()
    browser.close()

每個 context 使用不同的黏滯工作階段權杖，所以 IP 在 context 內保持穩定（適合登入流程），但在不同 context 之間有所差異（適合並行執行多個帳號）。這正是像 GoLogin 與 Dolphin Anty 這類反偵測瀏覽器自動化的模式 — 參見我們的 反偵測代理設定指南。

Puppeteer 搭配代理（Node）

Puppeteer 把代理伺服器設為 Chromium 的啟動旗標，然後在 page 物件上進行驗證：

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: 'new',
    args: ['--proxy-server=http://gate.jibaoproxy.com:10001'],
  });
  const page = await browser.newPage();
  await page.authenticate({ username: 'USERNAME', password: 'PASSWORD' });

  await page.goto('https://httpbin.org/ip');
  console.log(await page.evaluate(() => document.body.innerText));
  await browser.close();
})();

由於代理是程序層級的旗標，單一 Puppeteer 瀏覽器只使用一個 IP。要輪換的話，就每個身分啟動一個全新的瀏覽器（較吃資源），或透過一個每次連線都更換 IP 的閘道來驅動輪換。

登入流程用黏滯工作階段

任何會建立工作階段 cookie 的流程，都必須在它的整個生命週期裡維持同一個 IP。在 IP-A 上鑄造的 cookie 突然從 IP-B 出現，會被解讀為工作階段劫持，並觸發重新驗證或封鎖。每個已登入的帳號維持一個 context（或一個瀏覽器），固定在一個黏滯工作階段權杖上，貫穿整個工作階段。

別忘了指紋

住宅 IP 是必要的，但並不充分。站台也會讀取你瀏覽器的 TLS/JA4 交握、HTTP/2 框架順序、canvas、WebGL，以及 navigator 屬性。原生無頭 Chromium 會洩漏 navigator.webdriver = true 以及一個能擊垮最佳 IP 的無頭指紋。用隱身外掛與貼近真實的啟動旗標來緩解：

// Node: puppeteer-extra + stealth
const puppeteer = require('puppeteer-extra');
const Stealth = require('puppeteer-extra-plugin-stealth');
puppeteer.use(Stealth());

// Realistic launch flags
const browser = await puppeteer.launch({
  headless: 'new',
  args: [
    '--proxy-server=http://gate.jibaoproxy.com:10001',
    '--disable-blink-features=AutomationControlled',
    '--window-size=1920,1080',
  ],
});

要確切看出你正在洩漏哪些訊號，就用你的自動化瀏覽器去跑 JIBAO 免費的 JA3/JA4 指紋檢測工具。想深入了解交握為何會被標記的機制，請閱讀 繞過 TLS 指紋辨識以及完整的 Cloudflare 繞過配方。

驗證與除錯

• 確認 IP。在信任一次長時間執行之前，先導向一個回顯端點，把 IP 讀回來。
• 除錯時用有頭模式跑。設定 headless=False，親眼觀察目標站台實際呈現給你的機器人什麼。
• 受保護的目標用住宅。機房 IP（$0.8/GB）對開放站台沒問題；Cloudflare 後面的站台需要 住宅代理（$2/GB）。
• 一個身分 = 一個 context + 一個黏滯 IP。絕不要在多個帳號之間共用同一個 context。