HTTP 410 Goneとは？意味と対処方法

このエラーの意味と見分け方

• ブラウザ、APIクライアント、クローラー、監視ツール、死活監視サービスが 410 Gone を報告する。
• レスポンスの影響はWebサイト全体ではなく、1つのURL、パスパターン、HTTPメソッド、APIバージョンに限られる場合がある。
• リクエストがHTTPエンドポイントに到達しているため、DNSは解決し、TLSも成功することがある。
• レスポンスヘッダーから、キャッシュの動作、リダイレクト先、認証コンテキスト、プロキシやCDNの情報、リクエストを処理したサーバーが分かる場合がある。
• リソースが意図的に削除されている場合、同じリクエストを繰り返すと通常は同じ結果が返る。

可能性の高い順の主な原因

主な原因

1. リソースの意図的な削除または非推奨化 — 管理者がページ、ファイル、APIエンドポイント、バージョンを恒久的に削除し、古いアドレスが410を返すように設定している。
2. アプリケーションまたはルーティングルール — アプリケーションが、廃止されたルート、削除済みレコード、サポート対象外のAPIバージョンに対して410を返している。
3. Webサーバーのrewriteまたはバーチャルホスト設定 — ルートルール、デプロイの変更、サイト設定の誤りにより、本来は動作するはずのURLに対して410を返している。
4. リバースプロキシまたはCDNの動作 — 中間レイヤーが、ルーティング、キャッシュ、エッジ設定に基づいてレスポンスをキャッシュまたは生成している。
5. リクエストの不一致 — URL自体は特定のメソッドやパス形式では有効でも、使用したメソッドでは削除済み、またはサポート対象外になっている。
6. カスタムのセキュリティまたはリクエスト処理ロジック — WAF、ゲートウェイ、アプリケーションポリシーが意図的に410を使用している。ただし、認証、認可、レート制限の問題には通常、別のステータスコードが使われる。

ステータスコードだけでは、どのコンポーネントがレスポンスを生成したのかを特定できません。意図した削除なのか、誤ったルールや古い中間レイヤーのレスポンスなのかを見分けるには、レスポンスヘッダー、時刻、ログが必要です。

修正方法

サイトを閲覧している場合

1. ホスト名、パス、スペル、大文字・小文字、バージョン部分などを含め、アドレスを慎重に確認します。
2. 正確なURLを何度も再読み込みせず、1回だけ再試行します。アカウントが必要なページの場合は、サイトの通常の手順でサインインしてから再試行します。
3. 古いブックマーク、検索結果、外部リンクからURLにアクセスした場合は、サイトの現在のナビゲーションや告知された移転先を確認します。410に同等の移転先があるとは限りません。
4. リソースがまだ存在するはずなのにレスポンスが続く場合は、URL、リクエスト時刻、HTTPメソッド、表示された410の結果をサイト管理者に伝えます。パスワード、Cookie、アクセストークンは送らないでください。

サイトを所有または開発している場合

1. 正確なリクエストを再現します。 URL、HTTPメソッド、ホスト、クエリパラメーター、ステータス、レスポンスヘッダー、リクエストが認証済みだったかどうかを記録します。失敗するリクエストを、正常に動作する関連ルートまたはメソッドと比較します。
2. 410が意図したものか判断します。 ページ、ファイル、レコード、APIバージョンが意図的に削除されたか確認します。意図した削除であれば、その削除を文書化し、適切な代替先が必要でない限りレスポンスを維持します。
3. レスポンスを生成したレイヤーを特定します。 ヘッダーとリクエストパスから、アプリケーション、Webサーバー、リバースプロキシ、CDN、WAFのどれがレスポンスを生成したかを確認します。リクエスト経路上の各レイヤーを調べ、すべてを一度に変更しないでください。
4. 該当するログを調べます。 時刻、ルート、リクエストIDを使って、関連するアクセスログ、アプリケーションログ、プロキシログ、CDNログ、セキュリティログを検索します。削除ルール、削除済みレコード、rewrite、デプロイの変更、キャッシュされたレスポンスを確認します。
5. 最近の変更とキャッシュ状態を確認します。 ルーティング、APIバージョン、認証、rewrite、エッジキャッシュの設定を、最後に正常だったデプロイと比較します。中間レイヤーが誤ったレスポンスをキャッシュしていた場合は、キャッシュを広範囲に無効化するのではなく、文書化された認可済みのキャッシュ無効化手順に従います。
6. 認可された範囲で、最小限の修正を行います。 リソースを提供すべき場合にだけ、ルートを復元するか誤ったルールを削除します。同等の代替先が存在する場合は、意図したリダイレクトを設定してテストします。410を隠すために、無関係なURLや存在しないURLまでリダイレクトしないでください。
7. 同じリクエストを再テストします。 関連するクライアントから、また必要に応じて影響を受けたネットワークやエッジロケーションから、ステータス、ヘッダー、レスポンスボディを確認します。意図的に削除したルートが文書どおりに動作し、関連ルートが意図したステータスを維持していることを確認します。
8. 監視とドキュメントを見直します。 ルート一覧、APIの非推奨化に関する告知、リダイレクト、テストを更新し、今後のリリースで有効なリソースが誤って削除されないようにします。

予防と修正確認

• 重要なWebルート、ファイル、APIバージョンの一覧を管理し、それぞれの意図した削除時の動作も記録します。
• 意図的な削除をリリース変更として扱い、文書化、テストを行い、承認済みの代替URLがあれば明記します。
• アプリケーション、Webサーバー、プロキシ、CDN、WAFの設定をバージョン管理し、デプロイ前にルートの変更をレビューします。
• リリース、移行、非推奨化の後に、重要なURLとAPIメソッドをテストします。
• ルート、メソッド、デプロイごとにHTTPステータスの割合を監視し、想定外の410レスポンスと計画的な削除を区別できるようにします。
• レスポンスと原因となったレイヤーを関連付けられる期間、アクセスログとアプリケーションログを保持します。
• エッジやプロキシで誤ったレスポンスが発生した場合に備え、キャッシュ無効化とロールバックの手順を定めます。

よくある質問