ハイライト
Proxy Finderはホスト単位で学習するようになりました。全体的に高速なプロキシを単に選択するのではなく、アクセス先のサイトで実績のあるものを選択します。Browserには、コールドスタート時の特定のエラーを捕捉する安定性の修正が適用されました。また、DashboardのMetricsおよびActivityビューをプロダクトごとに絞り込めるようになりました。
新機能と変更点
Proxy Finderがターゲットで実際に機能するプロキシを選択
これは今週最大の変更であり、実装までに数回のイテレーションを要しました。
以前: Proxy Finderは全体的な適合度に基づいてグローバルプールからプロキシを選択していました。同じターゲットサイトへの2つのリクエストは同じ広範なプールから選択されており、そのプールのほとんどのプロキシは特定のサイトで機能しませんでした。
現在: クエリ対象のターゲットホストごとに、Proxy Finderは実際に機能したプロキシを追跡します。新しいリクエストは実績のあるセットからいくつかサンプリングし、学習を継続するために少数の未知のプロキシへフォールバックし、すでに失敗したものを回避します。実績のあるセットはホストごとに管理され、再起動後も保持されます。
ごく一部のプロキシしか機能しない保護されたサイトをスクレイピングする場合、この効果を実感できるはずです。無効な選択、再試行、そして無駄な予算の消費が減少します。
この機能はフラグの背後で展開され、問題点を修正するために6回のイテレーションを実行し(そのうちの1つである、低トラフィック下で安定性を保つための学習ロジックの制御には、さらに2回のパスが必要でした)、今週本番環境のデフォルトを切り替えました。
アイドル期間後のBrowserの信頼性が向上
2つの修正により、1つの結果が得られました。
1つ目として、Browserにはコールドスタート時に古い状態が残るバグがありました。十分なアイドル時間の後、基盤となるディスプレイレイヤーがロックを保持し、次の起動が成功するのを妨げていました。静かな期間の後の最初のリクエストが失敗またはハングアップする可能性がありました。現在では、起動前にロックを解除しています。
2つ目として、BrowserへルーティングするパブリックAPIパスが、一部の環境で誤った宛先を指していました。トラフィックが暗黙のうちに誤ってルーティングされていました。現在、ルーティング設定は修正されています。
低ボリューム時にBrowserで不安定な初回リクエストの動作を確認していた場合、原因はこれです。
プロダクトによるMetricsおよびActivityのフィルタリング
DashboardのMetricsおよびActivityページに、プロダクトチップのフィルターが追加されました。Single、Browser、またはProxy Finderをクリックすると、チャートの範囲がそのプロダクトのトラフィックのみに絞り込まれます。集約されたビューではなく、使用状況の一部からレイテンシやエラーのみを確認したい場合に便利です。
サイトの小規模な更新
/jobsページを公開しました。Founding EngineerとEngineerを募集しています。両方のページで、スコープ、最初の1か月の様子、および応募方法を説明しています。
また、ホームページのDashboardプレビューにおけるモバイルレンダリングの強化、9つのパブリックルートでのページごとのソーシャルシェア画像の更新、2026年のAI時代に向けたrobots.txtの更新(検索およびソーシャルシェアプレビューアは許可、トレーニング用クローラーはブロック)、そして許容利用条項の明確化とEUの消費者例外を伴うソフィア管轄の注記による利用規約の更新を行いました。
内部の変更
顧客向けではない名称変更について: サイト全体で「anti-bot bypass」が「anti-bot resilience」になりました。プロダクトと動作は同じです。古い表現が広告プラットフォームのポリシーフィルターに引っかかっていました。
新しい選択ロジックに関する数値はまだ公開していません。成功率についての結果を報告する前に、本番環境での2週間のクリーンなトラフィックデータを必要としています。実際の数値が得られ次第お知らせします。
過去1か月間、どのターゲットにどのプロキシを使用するかを決定するレイヤーの再構築に費やしました。困難なのはアルゴリズム自体ではなく、実際のワークロードにおいてそれが実際に役立つかどうかを測定することです。それが5月の状況です。