IIS での HTTP 404 Not Found のトラブルシューティング - システム管理者のガイド

IIS で詳細エラーを有効にし、正確に要求された URL を取得し、次にサイト バインディングと比較して、どのサイトまたは vdir が意図されているかを特定します。 この最初のアクションは、しばしばリソースが欠落しているか、失われているか、またはインフラストラクチャ上で異なる場所にあるかどうかを明らかにし、マッピングの所有者と正しいパスを迅速に特定するのに役立ちます。

404 が欠落したファイル、誤設定された仮想ディレクトリ、または存在しない場所を指すリダイレクトに起因するかどうかを特定します。IIS マネージャーで vdir 設定を検査し、ディスク上の物理パスを確認し、次にワーカープロセスが異なるサイト間で継続できるようにフォルダーのアクセス許可をチェックします。複数のサイトがある場合、それらのルートフォルダーとそれらが提供する場所をリストアップして、クロスサイトの混乱を防ぎます。

パーマリンクを使用するウェブアプリの場合、URL 書き換え ルールまたは ハンドラーマッピング が実際の 404 をフレンドリーなページでマスクしないようにします。web.config または URL 書き換え ルールを更新し、ブラウザとサーバーサイドのログからインターネットパスをテストして、結果の URL が実際のファイルまたは有効なルートに解決することを確認します。

リソースが存在しない場合、プレースホルダーを作成するか、ファイルを意図された場所に移動するか、適切な静的/ASP.NET ルートを構成してリソースを提供します。各サイトについて、所有者 と意図されたコンテンツの場所の記録を保持して、将来の特定を迅速化します。パーマリンクを使用して、正規 URL が既存のリソースにマップされることを検証し、将来の失われた 404 を減らします。

次に、体系的な検証を続けます: インターネット向け URL をチェックし、DNS とホストヘッダーが正しいサイトを指していることを確認し、パーマリンクを実際のファイルパスにマップします。まだ 404 が表示される場合、IIS リクエストログからリクエストをトレースし、パスが失われる場所を特定し、適切に調整し、変更を所有者とチームにドキュメント化します。

IIS ログを分析して 404 パターンと失敗した URL を特定

最新の IIS ログをエクスポートし、404 レスポンスでフィルタリングします。頻繁な URL パスと最初に見られたタイムスタンプを探して、サイトにアクセスしようとする人々に影響を与える繰り返しの問題を特定します。

404 のパターンは一般的な原因を明らかにします: 欠落したリソース、誤設定された vdir エントリ、リンクのタイポ。一部の問題はリダイレクトまたは移動されたコンテンツに起因し、他のものは内部ナビゲーションまたは外部参照から来ます。インデックスを一貫して保つために、メモに vdir 値を記録します。トップの違反者のリストを作成し、時間を追跡して、偶発的なミスと定期的に繰り返す問題を区別します。

リファラーとユーザーエージェント フィールドを使用して、問題が検索、他のサイト、または直接ルックアップから来るかどうかを評価します。これにより、根本原因の解決を優先し、摩擦の少ないユーザーエクスペリエンスを改善できます。

404 のテーブル形式のビューをエクスポートし、URL パス、カウント、最初に見られた、リファラー、メモを含みます。この印刷可能な形式は、ステークホルダーの更新をサポートし、パスとインデックスの最適化のための単一の真実のソースを維持します。

URL パス	ステータス	カウント	初見	リファラー	メモ
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	ディスク上のファイル欠落
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	/docs/user-guide.html に移動; リンクを更新
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	VDir 誤設定; パスを確認

404 を解決および防止するためのアクション

欠落したリソースの場合、ファイルを復元するか、正しい URL への 301 リダイレクトを作成します。誤設定された vdir の場合、IIS マネージャーで vdir パスを確認し、applicationHost.config をチェックし、既存の物理パスを確保します。タイポの場合、リンクを修正し、ページに関するコンテンツを更新し、内部検索インデックスを定期的に更新します。

要約レポートを印刷し、サポートチームと共有します。変更の実行リストを更新して、何が機能し、何が機能しなかったかを追跡します。複数の頻繁な違反者の場合、対象のリダイレクトを実装し、デッドリンクを削除して将来のエラーを減らします。

収集したパターンを定期的にレビューし、404 の処理を最適化し、本番に更新を適用する前にステージング環境でリダイレクトをテストします。このアプローチはミスを最小限に抑え、サイトをナビゲートする際のスムーズなエクスペリエンスを人々に提供するのに役立ちます。

サイト バインディング、ホストヘッダー、仮想ディレクトリを確認

バインディングを即座にレビューおよび修正: ホストヘッダー、IP、ポートがクライアントのリクエストに一致し、サイト名が使用中の URL に対応していることを確認します。

バインディング チェック

• IIS マネージャーを開き、Sites > [your site] > Bindings に移動します。http (使用されている場合の https) のバインディングが正しい IP とポートで存在することを確認します。複数のサイトが同じ IP:port を共有する場合、現在の URL に一致するホスト名 (ホストヘッダー) 値を追加してリクエストを適切にルーティングします。

• 正確なホストヘッダーでリクエストをテスト: curl -I -H "Host: example.com" http://server/ またはブラウザを使用します。404 が続く場合、バインディングは正しいが、要求されたパスが別のサイトによって処理されている可能性があります。

• https の場合、バインディングのホスト名に証明書が一致することを確認します。サブジェクトと SAN をチェックし、バインディングがポート 443 で正しい証明書を使用していることを確認します。不一致は、リソースが欠落しているように見える失敗したリクエストを引き起こす可能性があります。

• DNS とプロキシ層を検査: 受信リクエストが期待されるホストヘッダーを運んでいることを確認; プロキシの誤設定は、有効なパスで 404 を引き起こすリクエストを間違ったサイトに着陸させる可能性があります。

仮想ディレクトリとパス設定

1. 仮想ディレクトリアリウスがサイトの下に存在することを確認; アリウスは URL セグメントとして表示されるはずです (例: /files)。右ペインで物理パスをレビューし、フォルダーが存在し、アプリプール ID によってアクセス可能であることを確認します。

2. ディレクトリがコードを実行すべき場合、アプリケーションに変換します。仮想ディレクトリを右クリック > Convert to Application を選択し、正しいアプリケーション プールを選択し、プール ID が物理パスに読み取り権限を持っていることを確認します。

3. ディレクトリレベルの URL に依存する場合、デフォルトドキュメントをチェック; 有効なデフォルトドキュメント (index.html, default.aspx など) があることを確認するか、リンクで明示的なファイルパスを提供します。

4. 存在しないパスにリダイレクトする可能性のある web.config ルールと URL 書き換えをレビューします。悪いルールは、さもなければ有効なページで欠落リソースの 404 を生成する可能性があります; 競合するルールを調整または削除します。

5. アクセス許可を検証: 物理パスで IIS_IUSRS とアプリプール ID に読み取り/実行を付与し、期待されるユーザーの NTFS ACL がアクセスを許可することを確認します。アクセス許可の欠落は、コンテンツがなくなったように見える 404 を引き起こすことがよくあります。

6. 変更後に再テスト: 問題のある URL をリクエストし、200 または適切なリダイレクトを確認; リダイレクトがループするかリソースが欠落し続ける場合、書き換えルールとアプリケーションプールのスタートアップログをレビューします。

バインディングまたは仮想ディレクトリによって引き起こされる欠落ページの問題を明らかにするための基本的なクロールを活用します。IIS ログを grep して 404 エントリを見つけ、どのリクエストが失敗しているかを特定し、根本原因に対処し、新鮮なクロールで再テストします。結果を保存し、問題を処理する間、LinkedIn で管理者と同僚に簡潔な要約を共有して全員を一致させます。

ファイルパス、物理的存在、ファイルアクセス許可を検証

IIS マネージャーでサイトの物理パスを検証し、パスがディスク上に存在することを確認します。サイトまたは仮想ディレクトリの Basic Settings で、指しているフォルダーが期待するコンテンツを含むことを確認します。パスが変更された場合、元の場所を復元するか、スナップインでマッピングを修正して、リクエストが正しいフォルダーをアドレスするようにします; さもなければ IIS は何もロードせず、404 が表示されます。

ファイルがファイルシステム上に実際に存在し、アプリプール ID がトラバースおよび読み取り権限を持っていることを確認します。File Explorer または icacls を使用して、フォルダーとすべての親フォルダーの ACL を検証します。コンテンツルートとその中のファイルで、アプリプール ID (例: IIS APPPOOLYourAppPool) に読み取りとフォルダー内容のリスト表示とトラバースを付与します。アクセス許可が正しくない場合、IIS はアクセス拒否を示し、エンジンはファイルが存在する場合でも 404 を返す可能性があります。ACL を適切に調整し、再テストします。不確かな場合、一時的に既知のユーザーに読み取りアクセスを割り当てて、ファイルがロードされることを確認します。

提供する拡張子の MIME タイプ マッピングをチェックします。サイトの MIME タイプを開き、拡張子に関連付けられた MIME タイプがあることを確認; 欠落したマッピングはしばしば 404 を引き起こします。必要に応じて、一般的なタイプ (.html, .css, .js, 画像, フォント) を追加し、正しい content-type が送信されることを確認します。また、パーマリンクスタイルの URL が正しいフォルダーからロードされることを確認; パーマリンク ルートと物理パスの不一致は、静的および動的アセットの両方で 404 をトリガーする可能性があります。

サイトのリクエスト認証設定をレビューします。スナップインでサイトの Authorization Rules に移動し、クライアント ID が要求されたフォルダーの読み取りを許可されていることを確認します。拒否ルールがファイルをブロックする場合、エンジンは一部のパスで 404 を返す可能性があります; ルールを削除するか狭めて助けます。公開アクセスに依存する場合、Anonymous Authentication が有効であることを確認し、複数のサイトが同じコンテンツルートを共有する場合、ドメイン レベルまたはサイト レベルの設定をチェックします。

ログとトレースを有効にし、チェックします。404 エラーの Failed Request Tracing をオンにし、または IIS ログをレビューして、ヒット数と要求アドレスを特定します。エンジンからの正確な URL、マップされたパス、ファイルパスを探します; この識別データはソースを特定するのに役立ちます。情報を活用して正しいパスを復元し、ロード順序を修正し、苛立たしい再発を防ぎます。インターネット向けサイトでは、ドメイン プロファイルと物理パスが一致することを確認; 小さな不一致は複数のサイトのアクセスを破壊する可能性があります。変更後、アプリプールをリサイクルして新しいマッピングとアクセス許可を適用します。一貫した 404 を対処する場合、まず根本原因に対処し、次にすべてのサイトでのユーザー ジャーニーを検証します。

URL 書き換えルールとカスタム エラー設定をレビュー

各サイトの IIS から現在の URL 書き換えルールをエクスポートし、既知の良好なベースラインと比較して、404 結果を引き起こす誤設定を特定します。これにより、問題が書き換えられた URL、欠落したリソース、または不適切なカスタム エラーパスに起因するかどうかが明らかになります。

検査する内容

web.config または各サイトの URL Rewrite モジュールでルールを見つけます。書き換えまたはリダイレクトをトリガーするパターンと条件をレビューし、ターゲット URL が既存のリソースまたは Custom Errors で定義された適切な HTML ページを指していることを確認します。404 エントリが定義されており、エラーページで使用されるパスがサイトルートの下に存在することを確認します。同じパスをマップする単一のアプリプールを共有するサイト間の競合をチェックします。

評価の順序を監査: 最初に一致するルールがさらなる処理を停止します。カスタム エラーハンドラーが実行される前に 404 をキャプチャする可能性のあるインバウンドまたはアウトバウンド ルールを探し、構成された場所にフォールバックの 404 ページがあることを確認します。サイトごとの構成をオーバーライドする可能性のあるグローバルまたはサイト レベルの設定をレビューします。

修正の適用方法

ルールが誤設定されている場合、マッチパターン、書き換えアクション、宛先を調整します。欠落したリソースが非 404 レスポンスを返す既存のパスに書き換えられないようにします。Custom Errors セクションを更新して、404 リクエストが実際の HTML ファイルにルーティングされるようにし、ファイルが正しいアクセス許可でデプロイされていることを確認します。変更後、アプリプールをリサイクルし、異なるクライアント環境からテストして一貫した結果を確認します。サーバーログと Failed Request Tracing (FRT) データを使用して、正確なルールと最終レスポンスページを特定します。

対象テストで障害を再現し、レスポンスを監視

推奨: 対象テストで 404 を再現し、共有ダッシュボードでレスポンスを監視します。アクセスログに証拠をキャプチャし、各パターンに所有者を割り当てて修復を迅速化します。このアプローチは、管理が現在の影響を確認し、サイト スコープ全体で修正を優先するのに役立ちます。

サイトのアクセスログから最後の 200 の 404 エントリをエクスポートします。各エントリについて、時間、クライアント IP、ホスト名、要求 URL、リファラー、ユーザーエージェント、ステータス、レスポンス サイズを記録します。関連パス下の欠落アセットを観察した場合、これは孤立したケースではなくパターンを示します。これらのシグナルから簡潔なテストリストを作成して次のステップを進めます。

パス変動をテスト: 末尾スラッシュの有無で既知の欠落 URL をリクエスト; セグメントのケースを変更; クエリ文字列を追加または削除; 静的アセットに対する動的ルートのレスポンスを比較します。意図しないリダイレクトまたは書き換えが発生する前にサーバーが 404 を返すことを確認するために、GET と HEAD メソッドの両方を含めます。

利用可能な場合、Failed Request Tracing (FRT) を使用し、同じタイムスタンプでアクセスログとクロスチェックします。これらのトレースは、どのルールまたはモジュールがリソースをブロックしたか、またはリソースが実際に欠落しているかを示します。結果をダッシュボード メトリクスに結び付け: ルート別、ホスト別、アカウント別の 404 カウント。この優れた相関は調査を迅速化し、現在のホットスポットを明らかにします。

書き換えまたはルーティング層の背後にあるリソースの場合、関連する web.config、URL 書き換えルール、および IIS が書き換えモジュール経由で尊重する可能性のある htaccess 風の設定をチェックします。404 がマッピングの問題を示す場合、ルールまたはファイルパスを調整し、本番に進む前にテストを再実行して修正を確認します。404 がブロックされたリソースを指す場合、ブロックリストまたはアクセス制限を検証し、意図されたアクセス パターンに一致することを確認します。

ダッシュボードに調査結果をドキュメント化し、サイト所有者と管理に要約を共有します。必要に応じて、クロスチームの可視化のために LinkedIn に洞察を公開します。プロセスは繰り返し可能であるべきです: テスト入力を保存し、レスポンスをキャプチャし、アクセスログからの関連ログを添付して、アカウント所有者またはセキュリティチームがレビューできるようにします。

レジリエンスを改善する方法: テストリストをイテレートし、ステータスコードを記録し、スパイクをフラグする小さなテストハーネスを構築します。これらのシグナルを使用して、欠落アセットに対処し、コンテンツ在庫を更新し、正当化された場合のみ IP でノイジーなプローブをブロックします。常に現在のテストスイートをサイト在庫と MIME タイプ マッピングに一致させて、回帰を防ぎます。

変更前に、所有者の承認とロールバック計画を確保します。継続的な監視ダッシュボードは、404 レートが安定しているか、上昇しているか、ベースラインに戻っているかを示すべきです。うまく実行されたテスト体制はインシデント対応を加速し、チームがスムーズなユーザーエクスペリエンスを提供するのに役立ちます。