プロキシの健全性:どのウェブサイトと操作をテストしましたか?
再利用可能なプロキシプールを維持するときは、プロキシの全般的な到達性と宛先固有の失敗を切り分けてください。
プロキシはIP確認ページを取得できても、アプリケーションが必要とするAPIで失敗することがあります。「健全」か「死んでいる」かと呼ぶと、最も有用な事実を失います。二つのリクエストは異なっていたのです。
エンドポイントについて、トランスポート全体の記録から始めましょう。そのリスナーに到達し、必要なプロキシ交渉を完了できますか。宛先固有の観察は、その記録を上書きするのではなく、記録の横に置いてください。
| 観察 | 調査すべき範囲 |
|---|---|
| プロキシのリスナーが接続を拒否する | エンドポイントとそこへの経路 |
| プロキシが一つの宛先ポートを拒否する | その宛先に対して許可された操作 |
| 一つのウェブサイトがアカウントエラーを返す | 宛先のアプリケーションと資格情報 |
| 大きな応答は停滞し、小さな応答は完了する | 転送の作業負荷とタイムアウトの方針 |
HTTP応答は、リクエスト経路が何かを返したことを示せても、アプリケーションにとっては依然として使えない場合があります。トランスポートの成功、HTTPステータス、そして期待される内容を別々の結果として保ってください。
一つの宛先が繰り返し失敗するなら、そのエンドポイントと宛先の組を一時停止するか調査してください。無関係なすべての作業に対してプロキシを無効にすると、有用な容量を捨ててしまうかもしれません。逆に、全体的な接続失敗が一つのウェブサイトの孤立した記録の陰に隠れたままではいけません。
実用的な健全性キーには、プロキシ識別子、宛先サービス、操作の種類を含められます。資格情報を含むURL全体や、すべての固有のリソースパスを際限なく増えるキーとして使うのは避けてください。次回のリクエストについて意味のある予測ができる場合にだけグループ化します。
目的はより良いルーティングの証拠であり、緑のバッジをより多く集めることではありません。健全性の結果は、何をいつ試み、実際に何を立証したのかを語るべきです。