プロキシ監視のステータスと終了コードを読み解く
プロキシ経由のウェブサイト検査で、コマンド実行・HTTP 結果・証明書検証をそれぞれ分けて記録します。
ラッパーは、ダウンローダの終了コード 0 を「観測された HTTP 200 OK」に変えることはできません。各層が実際に何を報告したかを記録します。
| 項目 | 答える問い |
|---|---|
| ツールまたはプラグインの終了 | 検査は実行されたか、どの失敗クラスを報告したか |
| プロキシのネゴシエーション | 転送または要求したトンネルは許可されたか |
| オリジンのステータスと期待する内容 | アプリケーションは意図した結果を返したか |
| TLS 検証 | 設定された身元検証は成功したか |
curl は通常、HTTP エラー応答の後でも 0 を返せます。fail オプションは終了時の挙動を変えますが、失敗終了は依然としてステータスを一意に特定しません。Wget の終了値も分類です。認証の失敗は HTTP 401 専用の値ではなく、サーバーエラーの分類はその中のすべての応答を特定しません。401 を期待する検査は、その応答を観測しなければなりません。
プロキシのエンドポイントとウェブサイト名は分けて扱います。HTTP プロキシ検査の TCP の相手はプロキシです。CONNECT が宛先を指定し、その TLS セッションがトンネル内で動きます。HTTPS プロキシでは、外側のプロキシへの信頼はもう一つの証明書検証です。
SSL フラグを検証とみなす前に、プラグインの保証を確認します。Monitoring Plugins は check_http を非推奨とし、check_curl を推奨しています。check_http の文書は、SSL を選ぶだけではホスト名も発行者の信頼も検証されないと警告しています。check_curl の文書化された verify-peer オプションはその検証を含みます。
想定された認証済みの経路も使います。ポート監視が正常なまま、運用アカウントが 407 を受け取ることがあります。その秘密はデプロイの適切な仕組みで渡し、実際に失敗した段階を報告します。拒否されたトンネルは、想定外のウェブサイトのステータスとは別の対処を要します。