新機能
エグジットノードのローテーションは誰もが自動化する部分です。しかし、その下にあるブラウザシグネチャは通常固定されたままです。
Single と Proxy Finder で、リクエストが提示するブラウザを決定する4つのオプションフィールド（browser、os、version、profile）が利用可能になりました。その基盤となるカタログは GET /api/profiles で公開されており、API キーは不要です。現在、Windows、macOS、Android、iOS 上の Chrome、Edge、Safari、Firefox、Tor にわたる79のプロファイルを収録しています。
プロファイルを指定しない場合、Proxy Finder が自動的に変更します。ただし、送信したプロファイルがサイトによって2回連続で拒否された場合にのみ変更されます。
動作の仕組み
フィールドのうち3つは人間用、1つは機械用です。
browser、os、version はカタログを絞り込むためのもので、任意の組み合わせで送信できます。os はファミリーでマッチングするため、macOS を指定するとリスト内のすべての macOS リリースが対象となり、正確なリリースラベルを指定するとそのリリースに絞り込まれます。条件に一致するプロファイルが複数ある場合は、最新バージョンが優先されます。常に最新であることこそが重要だからです。古いメジャーバージョンはブロックリストの標的になります。
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://example.com/listing/42",
"browser": "Safari",
"os": "iOS"
}'
これはカタログ内の最新のiOS版Safariへと解決され、それに紐づくUser-Agent、client hints、headerの順序をそのまま送信します。headerの順序自体がシグナルとなるため、送信時に並べ替えられることはありません。
profileは4つ目のフィールドです。新しいバージョンがリリースされた後も同じクライアントを送信し続ける必要があるコード向けに、カタログの正確なIDを指定します。Proxy Finderはこれら4つすべてをrequestオブジェクト内で受け取ります。パラメータの完全なリストはAPIリファレンスにあり、Playgroundも同一のカタログを参照しているため、ドロップダウンにはコードから要求可能な選択肢のみが表示されます。同じ4つのフィールドはMCPサーバーのfoura_singleおよびfoura_proxy内でも利用できるため、エージェントは単なる403を返す代わりに、別のブラウザとしてリトライできます。
設計上、意図的に行わない処理が2つあります。
カタログに存在しない組み合わせが指定された場合はエラーとなり、そのブラウザで利用可能な設定を提示します。デフォルトにフォールバックしてしまうと、意図せず指定もしておらずレスポンスからも確認できないクライアントを送信することになります。unblocker: falseを併用したプロファイル選択も拒否されます。このフラグがheaderを運ぶ役割を果たすためです (このフラグが実際に行う処理)。中途半端なプロファイル設定は、何もしないより悪影響を及ぼします。
カタログ自体は手作業で作成されたものではなく、実測に基づいています。スクリプトが実際のrequestパスを通じて全プロファイルを実行し、ワイヤ上に実際に流れたデータを記録します。これは想像以上に重要です。あるブラウザの最近の2つのメジャーバージョンの間では、プレースホルダーのブランド文字列が変更され、ブランドの順序が逆転しました。これこそが、検知サービスが読み取る詳細なシグナルです。
影響
予想外だった点は次のとおりです。
デフォルト設定は、全ユーザー共通のデフォルトです。指定なしのrequestが提示するクライアントは、同じく指定なしのすべてのrequestが提示するものと同一であり、安価なシグナルで遮断したい防御システムはまさにそこを狙います。この場合の失敗パターンも特徴的です。特定のブラウザを拒絶するサイトは、手持ちのすべての出口IPにおいてそれを拒絶します。結果として、同じクライアントが拒絶されることを確認するためだけにリトライ予算を使い果たすことになります。
3つのベンダーで3回計測を行いましたが、結果の傾向は毎回同じでした。
PerimeterX背後の不動産ポータルは、デフォルト設定での試行を9回拒否しました。requestが主張するプラットフォームのみを変更したところ (他の条件やプロキシプールは同一)、6回中6回すべてでページが返されました。Akamai背後のサプリメント通販サイトはデフォルト設定を拒絶し、他の2つのブラウザファミリーからのrequestには問題なく応答しました。DataDome背後の金融ニュースサイトは、デフォルト設定に対して401と774バイトのインタースティシャルページを返しましたが、他の3つのプロファイルでは約760 KBの実ページを各12回取得できました。順序による影響を排除するため、このテストは前後を入れ替えても実行しました。
これにより、Proxy Finderはイグジットだけでなく、ブラウザファミリーもローテーションするようになりました。1つの拒否は単一のイグジットによる判断にすぎないため、2つの独立したイグジットが拒否して初めてローテーションが実行されます。その後、プラットフォームという最小限の変更から始まるラダーを順に進み、その後にのみ他のファミリーを試行します。
追加コストは発生しません。ローテーションはリトライ時に送信する内容を変更するだけであり、リトライ自体の実行有無には影響しないため、タスクあたりのリクエスト数やクレジット消費は従来と完全に同一です。
パワーユーザー向け
このローテーションはユーザーの構成を妨げません。その動作ルールを把握しておく価値はあります。
プロファイル名を自身で指定した場合は決して実行されません。また、独自の user-agent または cookie ヘッダーを送信した場合も実行されません。後者は特に重要です。クリアランス cookie はそれを取得したクライアントに紐づくため、動作しているセッションリプレイの背後でシグネチャをローテーションすると、成功していたリクエストが失敗してしまいます。固定したい設定はそのまま維持されます。
すべての失敗がプロファイルを切り替える根拠として扱われるわけでもありません。認識されたセキュリティベンダーによる遮断は対象となります。ベンダーが特定されていない単純な拒否ステータス（401、403、429、503）も対象となり、これが重要であることが判明しました。あるタスクでは8回のステータス拒否が返され、そのいずれにもベンダー情報は含まれていませんでした。ローテーション機能が検出器のみを信頼していたため、これら実際のリクエスト拒否を無視していたのです。存在しないページや国単位のブロックは対象外です。これらはクライアントではなく、URLや地理的条件に起因するレスポンスだからです。
動作状況はすべて確認可能です。Proxy Finderの成功レスポンスには、システム側で選択された場合にのみ profile が付与され、ユーザーが指定した場合には付与されません。失敗したタスクには attemptReport.profilesTried が付与されます。これには試行順のファミリー一覧が含まれ、変更なしで送信されたリクエストには default が設定されます。このフィールドがなければ、「4つのブラウザを試してすべて拒否された」ケースと「ブラウザを一度も変更しなかった」ケースが外部から判別できません。
実践すべき習慣として、プロファイルが有効かどうかをテストする際は、他のすべての条件を固定してください。Scrapflyの2026年フィンガープリントテストツールのまとめでも的確に指摘されている通り、実行ごとに3つの変数を変更すると、何かが機能したことは分かっても、どの変更が寄与したのかが特定できなくなります。同一ターゲット、同一イグジットで、変更するフィールドは1つだけにします。上記のすべての測定結果も同様の手法で算出されています。
今後の展望
候補ラダーは、ターゲットごとに実測を重ねることによってのみ拡張されます。ファミリーの追加は、推測に基づくものではなく、デフォルトではアクセスできなかったターゲットを実際に開けたことを確認した上で行われます。また、カタログはそのまま引き継がれるのではなく、エンジン更新のたびに再計測されます。
これがこの問題の難しさです。最適なクライアントシグネチャは常に変化しており、その追跡は一度リリースして終わるものではなく継続的な作業です。前四半期に有効だったものは、すでに誰かのブロックリストに載っています。だからこそ、システム側で固定値を選ぶのではなく、ユーザーが設定可能なフィールドとし、参照可能なカタログとして提供しています。