Patchrightプロキシ設定：起動、コンテキスト、認証とDocker
Patchrightは、Playwrightがブラウザを起動する前にCDPの漏洩を修正します。IPの評判には影響を与えず、推奨されるステルス設定はプロキシの回転方法を静かに変更します。
Patchrightは、Playwrightのパッチが適用された検出されないビルドで、ドロップインの代替として機能します：インポートを変更し、コードをそのままにします。パッチはブラウザプロセスが開始する前に適用され、サイトがPlaywrightセッションを最初の数ミリ秒で指紋認識するための自動化フラグとChrome DevTools Protocolの呼び出しを削除します。ネットワークには影響を与えません。すべてのPatchrightプロキシの質問はその分割に戻り、READMEが埋もれている1つの詳細に戻ります：最大のステルスを得るためにプロジェクトが推奨する設定は永続コンテキストであり、出口の回転方法を静かに変更します。これはプロキシに焦点を当てたガイドです—起動対コンテキスト、認証ゲートウェイ、Docker、そして天井の正直な説明。
インストールとドロップインプロキシ
PatchrightはPython、Node、.NET用に提供され、Chromiumのみをパッチします—FirefoxとWebKitは明示的にサポートされていません。インストールして、バンドルされたChromiumではなく実際のGoogle Chromeを取得します。プロジェクトはステルスのためにこれを推奨しています：
pip install patchright
patchright install chrome
# Node: npm i patchright && npx patchright install chromeプロキシAPIはPlaywrightのもので、変更されていません。プロキシはPatchrightが意図的に手を付けない数少ないものの1つです。認証情報は専用のフィールドに入力され、サーバーURL内にはありません—これが、Seleniumや生のPuppeteerとは異なり、ここで認証プロキシが拡張シムを必要としない理由です：
from patchright.sync_api import sync_playwright
PROXY = {
"server": "http://gate.quantumproxies.io:PORT",
"username": "USER",
"password": "PASS",
}
with sync_playwright() as p:
browser = p.chromium.launch(channel="chrome", proxy=PROXY)
page = browser.new_page()
page.goto("https://httpbin.org/ip")
print(page.text_content("body")) # the exit IP
browser.close()これが「Patchrightはプロキシをサポートしていますか」という質問の全てです：はい、上流のPlaywrightと同じように、bypassリストやChromiumのループバックアドレスがプロキシを完全にスキップするという特異性を含めて—ローカルモックサーバーに対してテストする場合、プロキシが無視されているように見えるでしょう。基礎モデルに不慣れな場合、当社のPlaywrightプロキシ統合ガイドが基本動作をカバーし、アンチディテクトフレームワークプロキシマップがどのスタックが認証情報をネイティブに受け入れるかを比較します。
コンテキストごとのプロキシとグローバルスタブ
コンテキストは安価な回転単位です：別々のクッキー、ストレージ、キャッシュがミリ秒で作成され、ブラウザの起動にかかる秒数を節約します。各コンテキストは独自のproxyオプションを持ち、1つのプロセスで米国のアイデンティティとドイツのアイデンティティを同時に保持できます。ここで人々をつまずかせるPlaywrightの1つのドキュメント化された注意点があります—ブラウザはグローバルプロキシで起動されなければならず、Chromiumでコンテキストごとのプロキシが機能します。すべてのコンテキストがそれを上書きすると、グローバル値は決して使用されず、任意のプレースホルダ文字列にすることができます：
const { chromium } = require('patchright');
(async () => {
// the global proxy is never used — it only enables the per-context option
const browser = await chromium.launch({
channel: 'chrome',
proxy: { server: 'http://per-context' },
});
for (const job of jobs) {
const context = await browser.newContext({
proxy: {
server: 'http://gate.quantumproxies.io:PORT',
username: 'USER-country-' + job.country, // geo in the username
password: 'PASS',
},
});
const page = await context.newPage();
try {
await page.goto(job.url, { timeout: 30000 });
// ...extract...
} finally {
await context.close(); // burns the cookies with the exit
}
}
await browser.close();
})();回転ゲートウェイに向けられると、各コンテキストは90M+の住宅プールの異なるアドレスから出発し、リスト管理は不要です—それが回転プロキシがサーバー側で行うことです。そのスニペットで地理とセッションコントロールがどこにあるかに注意してください：カスタムヘッダーではなく、ユーザー名にあります。それはPatchrightでは通常のPlaywrightよりも重要です。プロジェクト自身のガイダンスは、カスタムヘッダーとユーザーエージェントの上書きを避けることを推奨しています。注入された値自体が検出面であるためです。ユーザー名パラメータ制御はブラウザのリクエスト形状をそのままに保ちます。
永続コンテキストのトレードオフ
Patchrightの推奨ステルス構成はlaunch()ではありません。それはlaunch_persistent_context()で、実際のChromeチャネル、ユーザーデータディレクトリ、ビューポートの上書きなし、ヘッドモードであり、カスタムヘッダーや偽装されたユーザーエージェントは明示的にありません。その設定は、チャレンジが渡すクリアランスクッキーを保持するため、解決されたチャレンジは実行間で再利用可能です。プロキシの結果は構造的です：永続コンテキストはコンテキストそのものです。newContext()を使用して2番目のプロキシを掛けることはできないので、1つのプロセスは1つの出口アイデンティティに等しいです。
from patchright.sync_api import sync_playwright
with sync_playwright() as p:
ctx = p.chromium.launch_persistent_context(
user_data_dir="profiles/it-01", # one profile per identity
channel="chrome",
headless=False,
no_viewport=True,
proxy={
"server": "http://gate.quantumproxies.io:PORT",
"username": "USER-country-it-session-it01", # sticky, pinned to the profile
"password": "PASS",
},
# do NOT pass user_agent or extra_http_headers here
)
page = ctx.new_page()
page.goto("https://example.com")
ctx.close()したがって、回転はプロセスレベルの決定になります：1つのアイデンティティごとに1つのプロファイルディレクトリ、そこに固定された1つのスティッキーセッション、コンテキストループの代わりにワーカープール。ペアリングを安定させてください—イタリアの出口の背後でクッキーを蓄積したプロファイルがブラジルのものの背後に再出現するのは、どのCDPパッチも隠せない矛盾です。実践的なルール：ディレクトリをセッションIDで命名し、セッションを燃やすときにディレクトリを削除し、2つの出口間でプロファイルを共有しないでください。
プロキシの背後でDockerでPatchrightを実行する
ステルスブラウザをコンテナ化することには2つの罠があり、どちらもプロキシに影響を与えます。1つ目は--no-sandboxです：ルートとしてChromeが起動を拒否する通常の修正であり、アンチボットベンダーが喜んで読むフラグです。代わりに非ルートユーザーとして実行します。2つ目はヘッドレスモードです—プロジェクトはヘッドモードを推奨しているので、ヘッドレススイッチに手を伸ばすのではなく仮想ディスプレイを使用します：
# Dockerfile
FROM python:3.12-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
xvfb ca-certificates && rm -rf /var/lib/apt/lists/*
RUN pip install --no-cache-dir patchright \
&& patchright install --with-deps chrome
RUN useradd -m app
USER app
WORKDIR /home/app
COPY --chown=app:app scrape.py .
# headed under a virtual display: no --no-sandbox, no HeadlessChrome tell
CMD ["xvfb-run", "-a", "python", "scrape.py"]
# build & run:
# docker build -t patchright-worker .
# docker run --ipc=host --shm-size=1g patchright-worker--ipc=hostと大きな/dev/shmは、負荷がかかったときにタブがクラッシュするChromium-in-Dockerの標準修正で、Playwrightコンテナドキュメントから直接引用されています。1つのプロキシ固有の罠：SOCKS5エンドポイントに認証情報を追加するためにローカルリレーを実行する場合、コンテナ内の127.0.0.1はコンテナであり、ホストではありません。リレーを同じコンテナに配置するか、ホストを明示的にアドレス指定するか、共有ネットワークでサイドカーとしてリレーを実行します。そして、永続コンテキストを使用している場合、プロファイルディレクトリをボリュームに保持してください。そうしないと、コンテナを再起動するたびに取得したクリアランスクッキーが失われます。
パッチがカバーするものと決してカバーしないもの
何を購入しているのか正確に知っておく価値があります。Patchrightの見出し修正はRuntime.enableの漏洩です—ゲームを明かすドメインを有効にする代わりに、JavaScriptを隔離された実行コンテキストで実行します。Console.enableを閉じるためにConsole APIを無効にします（したがって、page.on("console")のログはなくなり、プロキシの失敗をデバッグするときに実際のコストになります）。Playwrightのデフォルトフラグを書き換えます：--disable-blink-features=AutomationControlledを追加し、--enable-automationを削除し、--disable-popup-blocking、--disable-component-update、--disable-default-apps、--disable-extensionsを戻します。また、通常のロケーターで閉じたシャドウルートにアクセスします。
そのフラグリストを帯域幅のラインアイテムとしても読んでください。コンポーネントの更新とデフォルトアプリを復元することは、バックグラウンドでホームに電話するブラウザを意味します—計測された出口を通じて。スケールする前にセッションの転送を測定し、コンテキストで画像、フォント、メディアリソースタイプをブロックしてページごとのコストを抑えます。どれも他の壁には触れません：焼かれたデータセンターIP上のパッチが適用されたブラウザは依然として焼かれたIPであり、この巧妙さが評価される前に評判でリクエストが拒否されます。パッチが失敗したと結論付ける前に、無料のIP品質チェッカーでアドレスを確認し、ブラウザの下に住宅プロキシを置いて、2つのレイヤーが異なる問題を解決するようにします。
よくある質問
Patchrightでプロキシを設定するにはどうすればいいですか？
Playwrightと同じように：proxy={"server": "http://host:port", "username": "USER", "password": "PASS"}をchromium.launch()、launch_persistent_context()またはnew_context()に渡します。Patchrightはプロキシレイヤーをパッチしないため、すべての上流の動作—バイパスリスト、ループバック例外—は変更されずに適用されます。
PatchrightはSOCKS5プロキシ認証をサポートしていますか？
いいえ、それはPatchrightの制限ではなくChromiumの制限です：ChromiumにはSOCKS認証情報のメカニズムがないため、認証されたSOCKS5エンドポイントは失敗します。同じゲートウェイのHTTPポートをユーザー名とパスワードフィールドで使用するか、IPホワイトリストで認証してSOCKS5スキームを維持します—すべてのQuantumProxiesプランはユーザー:パスの代替としてホワイトリストをサポートしています。完全な回避策セットは、当社のPlaywright SOCKS5認証ガイドにあり、ここでも変更なく適用されます。
Patchrightはコンテキストごとに異なるプロキシを使用できますか？
はい、ブラウザをグローバルプロキシ値で起動した場合—プレースホルダーでも—Chromiumは1つが起動時に存在する場合にのみコンテキストごとのプロキシを有効にします。例外はPatchrightがステルスのために推奨する永続コンテキスト設定です：それは1つのコンテキストを提供するので、回転は独自のプロファイルディレクトリを持つ別のプロセスを意味します。
PatchrightはChromium専用ですか？
はい。プロジェクトは明確にChromiumベースのブラウザのみがパッチされると述べています。FirefoxとWebKitはサポートされていません。プロキシ出口から派生した地理を持つFirefoxエンジンのステルスが必要な場合、それは異なるツールです—当社のCamoufoxプロキシとgeoipガイドをご覧ください。
Patchrightを使用してもブロックされますか？
難しいターゲットでは、はい。独立したテストでは、ヘッドレスモードが依然としてHeadlessChromeの兆候を漏らしていること、パッチが適用されたブラウザが到達するがクリアできないチャレンジページが示されています。パッチは安価な自動化チェックを閉じます；IPの評判、TLSの指紋、チャレンジ解決は別の問題であり、別の回答が必要です。
Patchrightをそのまま扱ってください：Playwrightの1行も書き直すことなく提供される、特定の漏洩クラスに対する非常に優れた修正です。アイデンティティが重要な場合はクリーンでスティッキーな出口とペアリングし、実行前に検証してください—そうすれば、残りの失敗は実際にはターゲットに関するものであり、あなたの設定に関するものではありません。これは技術的なガイダンスであり、法的なアドバイスではありません：法律とサイトの利用規約に従って自動化してください。