PowerShellでURLへの接続を確認するときは、「DNSで名前を解決できる」「TCP 443へ到達できる」「TLSを確立できる」「HTTP応答を受け取れる」「期待したコンテンツである」を別々に判定します。Invoke-WebRequestだけの成功・失敗では、どの段階に問題があるか分からない場合があります。本記事ではTest-NetConnectionとInvoke-WebRequestを使い、認証情報や証明書検証を安易に弱めずに接続を切り分ける方法を解説します。
テスト対象と成功条件を先に決める
URLはhttps://service.example.com/healthのように、実際に監視してよいエンドポイントを使います。トップページが認証へ転送されるサービス、GETで重い処理を行うAPI、アクセス回数に制限があるサイトもあります。担当者と、期待する状態コード、転送、応答時間、本文、認証要否、実行頻度を決めてからテストします。
URLにAPIキー、セッショントークン、メールアドレスなどをクエリ文字列で含めると、コンソール履歴、ログ、プロキシへ残る可能性があります。秘密情報はコードへ直接書かず、組織のシークレット管理を利用します。外部サイトへ過剰な頻度でアクセスせず、利用規約と監視許可を確認します。
TCP到達性はTest-NetConnectionで分ける
HTTPSの一般的なポートならTest-NetConnection -ComputerName service.example.com -Port 443を実行します。ComputerNameにはURL全体ではなくホスト名を指定します。TcpTestSucceededがTrueならTCP接続は成立していますが、TLS証明書、HTTP、認証、アプリの正常性までは確認していません。FalseならDNS、経路、プロキシ、ファイアウォール、サービス待受を調べます。
HTTPプロキシ経由だけ許可される環境では、Test-NetConnectionが直接経路を試すためFalseでもブラウザーは開ける場合があります。反対に443へ直接到達できても、HTTPプロキシ設定やTLS検査でInvoke-WebRequestが失敗することがあります。ブラウザー、PowerShell 5.1、PowerShell 7で使うネットワークスタックが異なる可能性も記録します。
Invoke-WebRequestでHTTP応答を取得する
基本例は$response = Invoke-WebRequest -Uri "https://service.example.com/health" -Method Get -TimeoutSec 15です。成功するとStatusCode、Headers、Contentなどを持つ応答オブジェクトが返ります。PowerShellの版によって表示やパラメーター動作が異なるため、$PSVersionTable.PSVersionを一緒に記録します。
負荷を減らすためHEADを使えるサイトもありますが、HEADを実装していない、GETと別経路になる、認証後だけ許可するサービスがあります。HEADが失敗しただけで停止と判断せず、監視仕様に合うメソッドを選びます。状態コード200以外でも、301や302は意図した転送、401や403はサービス到達後の認証・認可結果である場合があります。
tryとcatchで失敗を構造化する
例外を処理するには$url = 'https://service.example.com/health'; try { $response = Invoke-WebRequest -Uri $url -TimeoutSec 15 -ErrorAction Stop; $response.StatusCode } catch { $_.Exception.Message }のようにします。-ErrorAction Stopにより非終端エラーもcatchへ渡しやすくなります。catchではメッセージだけでなく、例外型、StatusCode、対象URL、実行時刻を安全に記録します。レスポンス本文へ秘密情報が含まれる可能性もあります。
すべての例外を「接続失敗」と一文にまとめると、名前解決、タイムアウト、証明書、認証、HTTP 500を区別できません。ユーザー向け表示と管理者向け診断を分け、ログには必要最小限の詳細を残します。例外オブジェクトを丸ごと公開チャットへ貼り付けず、Cookie、Authorizationヘッダー、内部ホスト名を確認します。
転送と最終URLを確認する
WebサービスはHTTPからHTTPS、旧URLから新URL、未認証からサインインへ転送することがあります。Invoke-WebRequestが自動的に転送を追うと、最終応答が200でも途中の構成変更を見落とします。応答のBaseResponseや履歴、Locationヘッダーを版に応じた方法で確認し、期待するホスト外へ転送されていないかを見ます。
監視URLがログインページへ転送されて200を返す場合、単にStatusCodeだけを見ると正常と誤判定します。本文の固定識別子、Content-Type、最終ホスト、応答時間を組み合わせます。ただし本文全体を毎回保存すると個人情報や容量問題が生じるため、ハッシュや必要な短い識別子だけを扱います。
TLS証明書エラーを無効化して回避しない
証明書名不一致、期限切れ、信頼されない発行者、失効確認失敗ではInvoke-WebRequestがTLS確立に失敗します。テストのために証明書検証を無効化すると、中間者攻撃や誤接続を見逃します。接続先ホスト名、証明書のSubjectとSAN、有効期限、チェーン、端末時刻、企業のTLS検査証明書を管理者が確認します。
自己署名証明書を使う内部サービスでは、必要な信頼を端末へ正規の方法で配布します。スクリプト内で「すべて信頼」にする方法は採用しません。古いTLS版しか使えないサービスは、クライアント側の安全設定を下げる前にサービス更新を優先します。PowerShellや.NETの版も記録し、同じ端末のブラウザーとの差を比較します。
プロキシ・認証・ユーザー差を確認する
Windows統合認証、明示プロキシ、PAC、VPN、条件付きアクセスがあると、対話ブラウザーと無人PowerShellで結果が違うことがあります。現在のユーザー、実行端末、サービスアカウント、ネットワーク位置を記録します。-UseDefaultCredentialsなどの利用は対象サーバーと組織方針を確認し、外部サイトへ意図せず資格情報を送らないようにします。
基本認証やBearerトークンを使うAPIでは、資格情報の保管、更新、失効、最小権限を設計します。ヘッダーを画面出力しない、トランスクリプトへ残さない、エラー時にURLやトークンを連結しないことが重要です。無人監視では個人アカウントを使わず、用途が明確なサービスIDと監査可能な認証を利用します。
監視へ発展させる場合の設計
単発確認から監視へ広げる場合は、開始時刻、DNS/TCP/HTTPの段階、状態コード、応答時間、最終URL、判定、例外分類を構造化してCSVや監視基盤へ送ります。一回の失敗で障害通知せず、再試行回数と間隔を決めます。ただし短時間に大量再試行すると障害を悪化させるため、指数的な待機や上限を設けます。
監視元が一台だけでは、その端末やネットワークの障害をサービス障害と誤認します。必要なら社内外や複数拠点から測定し、DNS、プロキシ、CDNの差を考慮します。成功率、応答時間、証明書期限など目的別の指標を分け、テスト用エンドポイントが業務データを更新しないことを確認します。
実務での確認チェックリスト
- URLと許可されたテスト用エンドポイントを確認する
- Test-NetConnectionでホストとポートのTCP到達性を分けて測る
- Invoke-WebRequestで状態コード、最終URL、本文識別子を確認する
- try/catchでDNS、タイムアウト、TLS、HTTPを分類する
- 証明書検証を無効化せず原因を修正する
- 資格情報、Cookie、トークンをログへ残さない
コメント