ブラウザ使用プロキシ設定: セッションごとの出口IP

ブラウザ使用プロキシを検索すると、GoogleはChromeの設定ダイアログを表示します。これがもう一つの方法です: 認証済みの住宅IPを通じてブラウザ使用AIエージェントライブラリをルーティングし、エージェントごとに1つのIPを割り当てます。

ブラウザ使用プロキシを検索すると、GoogleはChromeの設定ダイアログ、chrome.proxy拡張API、そして企業向けPACファイルのチュートリアルを表示します。それはあなたが探していたものではありません。あなたはブラウザ使用 - LLMが実際のブラウザを駆動することを可能にする108k GitHubスターのPythonライブラリ - を認証済みプロキシを通じてルーティングしたいのです。これにより、エージェントがオフィスのIPからターゲットを叩くことがなくなります。これがそのガイドです: パラメータが実際にどこにあるのか、アップグレード後に静かに動作を停止する理由、並行エージェントごとに独自の出口IPを与える方法、そしてIPがその下で移動すると長いタスクに何が起こるのか。

ブラウザ使用プロキシパラメータが実際にどこにあるのか

プロキシはブラウザセッションのプロパティであり、エージェントのものではありません。現在のライブラリでは、BrowserはBrowserSessionの別名であり、ドキュメントではそれらが完全に同じクラスであることが明示されています。したがって、どちらかの名前を使用するチュートリアルはもう一方にも適用されます。パラメータはproxyであり、ドキュメントではProxySettingsとして4つのフィールドを持つとタイプされています: server, bypass, username, password。同等の辞書も機能し、ほとんどの人がそれを渡します:

import asyncio
from browser_use import Agent, Browser
# llm = ...  your model of choice; see the browser-use docs for the import

PROXY = {
    "server": "http://gate.quantumproxies.io:8000",  # scheme is mandatory
    "username": "USER",
    "password": "PASS",
    "bypass": "localhost,127.0.0.1",                  # keep local calls off the proxy
}

browser = Browser(proxy=PROXY, headless=False)

async def main():
    agent = Agent(
        task="Open https://api.ipify.org?format=json and report the IP you see",
        llm=llm,
        browser_session=browser,
    )
    await agent.run()

asyncio.run(main())

人々が間違える2つの詳細。まず、資格情報はusernameとpasswordフィールドに属し、serverに詰め込まれるべきではありません - ChromiumはURLに埋め込まれたパスワードからのプロキシ認証チャレンジに応答しませんし、ブラウザ使用にはそれを入力するためのダイアログはありません。次に、serverにはスキームが必要です。gate.quantumproxies.io:8000はプロキシURLではありません; http://gate.quantumproxies.io:8000がそうです。資格情報が問題を引き起こしている場合は、サーバーのIPをホワイトリストに登録することで、ユーザー名とパスワードを完全に排除できます - ゲートウェイが発信者を認識し、ブラウザは407を受け取りません。

なぜブラウザ使用プロキシ設定が静かに何もしないのか

このトピックに関する最も訪問されたページは、2025年7月に提出されたGitHub issue #2445です: 0.1.45で動作していたプロキシが0.5.4で効果を失い、唯一の手がかりはエージェントが自分の要約でDNS_PROBE_FINISHED_NXDOMAINを陽気に報告していたことでした。この失敗モード - エージェントがネットワークエラーをウェブサイトについての事実のように語る - は半分構成されたプロキシの特徴です。トークンをさらに消費する前に、このリストを確認してください:

エージェントが受け取らなかったセッションにproxy=を渡しました。1つのBrowserを作成し、その正確なオブジェクトを渡し、デフォルトセッションが背後で作成されないようにしてください。
cdp_urlを設定しました。既に実行中のChromeに接続するということは、プロキシがそのブラウザの起動フラグ（--proxy-server=...）に属し、セッション設定には属さないことを意味します - ブラウザ使用はそれを後付けできません。
グローバルなHTTP_PROXYまたはHTTPS_PROXY環境変数がセッション設定と競合しているか、さらに悪いことに、LLM APIコールを計測された帯域幅を通じて静かにルーティングしています。
プロキシ自体が死んでいます。エージェントの外でテストしてください - それは何も費用がかからず、検索空間の半分を除外します。

import requests

PROXY_URL = "http://USER:PASS@gate.quantumproxies.io:8000"
r = requests.get(
    "https://api.ipify.org?format=json",
    proxies={"http": PROXY_URL, "https": PROXY_URL},
    timeout=20,
)
print(r.status_code, r.text)   # must NOT be your own IP

それが外国のIPを印刷する場合、資格情報とゲートウェイは正常であり、問題はセッション配線にあります。それがあなた自身のアドレスを印刷するか、407を印刷する場合、それを最初に修正してください。私たちの無料のIPチェッカーは、他の側から出口がどのように見えるかを教えてくれます - ASN、タイプ、評判 - これはページが読み込まれるがすべてがCAPTCHAである場合に確認する2番目のことです。

ブラウザ使用プロキシの症状（DNSエラー、実際のIPの漏洩、古いバージョンで機能した設定）と確認する修正を一致させるチェックリスト — 設定は通常正しく見えます。失敗はほとんどの場合、エージェントが実際に受け取ったセッション、欠落したスキーム、またはグローバル環境変数です。

セッションごとに1つのプロキシ、並行エージェントが出口IPを共有しないように

これがパラメータがセッションにある理由の全てです。1つの共有Browserを通じて10のエージェントを実行すると、ターゲットは1つのアドレスから10倍のトラフィックを受け取ります。これは住宅IPを焼き尽くす最速の方法です。代わりにコルーチン内でセッションを構築し、それぞれに独自のスティッキーセッション識別子を与えて、ゲートウェイがタスクの期間中に単一の出口に固定するようにします。

import asyncio, secrets
from browser_use import Agent, Browser

def session_proxy(sid: str, country: str = "us"):
    return {
        "server": "http://gate.quantumproxies.io:8000",
        "username": f"USER-country-{country}-session-{sid}",
        "password": "PASS",
    }

async def run_task(task: str, country: str):
    sid = secrets.token_hex(3)                  # e.g. a1b2c3
    browser = Browser(
        proxy=session_proxy(sid, country),
        user_data_dir=None,                     # incognito: no shared cookies
        allowed_domains=["*.example.com"],      # keep the agent on target
    )
    agent = Agent(task=task, llm=llm, browser_session=browser)
    return await agent.run()

async def main():
    await asyncio.gather(
        run_task("Find the price of SKU-1", "us"),
        run_task("Find the price of SKU-1", "de"),
        run_task("Find the price of SKU-1", "gb"),
    )

asyncio.run(main())

そこでは3つのフラグが実際に機能しています。user_data_dir=Noneはシークレットモードで実行されるため、エージェントが互いのクッキーを継承し、静かに2つのアイデンティティを1つのプロファイルに統合することはできません。allowed_domainsはナビゲーションをパターンリストに制限します - TLD位置でのワイルドカード、例えばexample.*は意図的に拒否され、100エントリを超えるリストはパターンマッチングがオフになったセットに最適化されます。そして、ユーザー名のセッション識別子が出口IPを安定させる要因です; 国とセッションの正確なフラグ名はダッシュボードにありますが、形はどこでも同じです。

タスクごとに出口国を選択する

ショッピング、価格比較、在庫確認を行うエージェントは、間違った国からブラウズするとデフォルトで間違っています。プロキシはセッションごとなので、国はタスクごとの引数です - country-usをcountry-deに交換すると、同じタスクがドイツの価格を返します。プールにある200以上の国から選び、それに一致する言語をargsを通じて渡してブラウザ全体を一貫させます（Chromiumは--lang=de-DEを受け入れます）。モバイル専用のサーフェスや最も信頼性の高い出口については、モバイルIPは再び異なる動作をします。キャリアNATが同じアドレスの背後に何千もの実際のユーザーを配置するためです。

各エージェントに独自の住宅出口IPを与える

タスクキューがエージェントごとに1つのブラウザ使用セッションにファンアウトし、それぞれが独自のスティッキープロキシセッションを持ち、ターゲットサイトが異なる住宅IPを確認するフロー — タスクの内部ではなく外部でセッションを構築します。エージェントごとに1つのBrowser、Browserごとに1つのスティッキーセッション、アイデンティティごとに1つのIP。

タスク中にIPが回転するとどうなるか

エージェントはスクレイパーとは異なり遅いです。各アクション後のデフォルト0.5秒のポーズ、0.25秒の最小ページ状態待機、0.5秒のネットワークアイドル待機の間に、ブラウザ使用はモデルが何かを言う前にステップごとに1秒以上を費やします - そしてモデルの往復は通常さらに数秒かかります。したがって、15ステップのタスクは1〜2分の壁時計時間で実行されます。出口IPがリクエストごとに回転する場合、サイトはそれぞれのステップで異なるアドレスを確認します: ログインが切れ、カートが空になり、エージェントはチェックアウトボタンが消えたと報告します。

修正は、最悪のケースのタスク期間を快適に超えるスティッキーセッションです。いくつかの実際の実行をタイムし、最も遅いものを取り、マージンを追加します - エージェントは再試行し、再試行は時計を倍にします。タスクが本当にどのスティッキーウィンドウよりも長く続く必要がある場合、それを分割します: ログインして状態をエクスポートし、storage_stateを介して保存したクッキーで新しいセッションで再開します。そして、リクエストごとの回転とスティッキーの間で選択している場合、AIエージェントのためのインフラストラクチャチェックリストはこの決定の周りのレイヤーの残りをカバーしています。

プロキシをLLMコールから外す

これは実際にお金がかかり、ほとんど誰も気づきません。環境変数としてHTTPS_PROXYを設定してプロキシを"どこにでも適用"させることは、すべてのモデルAPIコールを住宅ゲートウェイを通じてルーティングすることも意味します - プロンプトとレスポンス、すべてのステップで、遠回りする特権のためにギガバイトごとに請求されます。プロキシをBrowserのみに設定し、プロセス環境には触れないでください。バイトを数えている間に、ブラウザ使用がenable_default_extensionsを通じてデフォルトでuBlock Originをロードすることに注意してください: それをオンにしておいてください、それが殺す広告リクエストはあなたが支払わないものであるからです。完全な算術はAIエージェントの帯域幅コストの内訳にあり、従来のスクレイピングバージョンのトレードオフはヘッドレスブラウザ対HTTPリクエストにあります。

よくある質問

ブラウザ使用でプロキシを設定するにはどうすればよいですか？

Browser（BrowserSessionとしてもエクスポートされます）を構築するときにproxy=を渡し、そのオブジェクトをAgentに渡します。値はserverに明示的なhttp://スキームを持ち、username、password、およびオプションのbypassリストを含みます。エージェントレベルのプロキシ設定はありません - それはセッションに属します。

なぜブラウザ使用プロキシ設定が機能しないのですか？

可能性の順に: エージェントが構成したセッションとは異なるセッションで実行されている、serverがスキームを欠いている、cdp_urlを設定してプロキシフラグなしで他の場所でブラウザが起動された、またはグローバルプロキシ環境変数があなたを上書きしている。まずはプレーンなHTTPクライアントでプロキシを確認してください - エージェントログ内のDNSエラーは通常、プロキシが全くアタッチされていないことを意味します。

各ブラウザ使用エージェントは異なるIPを使用できますか？

はい、そしてそうすべきです。各タスクコルーチン内でBrowserを作成し、プロキシ資格情報を共有するのではなく、それぞれに独自のものを持たせます。ゲートウェイのユーザー名にユニークなセッション識別子を追加すると、各エージェントが実行中に異なる出口に固定されるため、10の並行エージェントが10人のユーザーのように見えます。

ブラウザ使用エージェントに最適なプロキシタイプはどれですか？

各タスクが独立している研究や価格チェックには回転住宅、ログインやカートがあるものにはスティッキー住宅、ターゲットが敵対的またはモバイル専用の場合にはモバイル。データセンターIPは内部ターゲットや保護されていないページには問題ありませんし、ギガバイトあたりのコストがはるかに安いです - これは、ブラウザエージェントが多くのギガバイトを移動するため重要です。

プロキシはブラウザ使用が検出されるのを防ぎますか？

いいえ。プロキシはIPレイヤーのみを修正します; 自動化されたChromiumのフィンガープリントは別の問題であり、ミリ秒単位でクリックするエージェントの動作も同様です。信頼できる住宅出口は最も簡単なシグナルを取り除きますが、ターゲットが本格的なボット管理を行っている場合は、ステルス指向のブラウザビルドと組み合わせてください。

ここには珍しいものはありません: プロキシはセッションのプロパティであり、それを壊す2つの要因は、欠落したスキームと渡されなかったセッションです。それらを正しく設定し、各並行エージェントに独自のスティッキー出口を与え、ゲートウェイをモデルAPIコールから遠ざけてください。より広い視野については、アンチディテクトフレームワークと認証プロキシのマップをご覧ください。

200以上の国にわたる90M以上の住宅IPでブラウザ使用を実行