ドメイン変更後、イベントサイトで「リダイレクト回数が多すぎます」と出たら

来場者用の確認済み経路を残す

リダイレクト循環の追跡・修復シートをダウンロード（Markdown、英語）

公開イベントページ、登録、チケットリンクのどれが影響を受けるか確認します。直接のチケット先が機能するなら、サイト担当者が修復する間、確認済みの公式連絡経路で案内します。日時、会場、問い合わせ先も承認済みの経路で見られるようにします。ブラウザー警告の無視や、開けない決済の再試行を来場者に求めないでください。

失敗したURLと比較結果を残す

ホスト名、パス、言語、安全なクエリ項目名、エラー表示、時刻、端末を記録します。共有シートではトークン、チケットコード、個人情報を伏せ、完全なURLは担当者のアクセス制限付き診断システムだけに残してください。個人情報や支払情報を送らず、同じ公開GETページを新しいブラウザーか承認済みの別端末で開きます。一方だけ失敗するなら共有設定を変える前にCookieやキャッシュの違いを記録します。両方失敗するなら、制限付きシステム内で正確なURLの短い転送記録を依頼します。

転送の連鎖を追跡する

HTTP転送は3xx状態と転送先Locationを返します。ブラウザーのNetwork記録か回数を制限したGET追跡で、安全なURLの形、状態、Locationを短い上限回数まで記録します。最初にURLが繰り返された時点、または繰り返しがなければ最後の観測地点で止めます。共有シートへ写す前にトークンを含む値を伏せてください。最後のエラーだけでなく最初の応答も残し、`http`/`https`、`www`/ルート、旧/新ドメイン、言語、末尾のスラッシュを比べます。DNSレコードはサービスへの到達先を示しますが、どのウェブ規則がLocationを返したかは示しません。[1]

購入やフォーム送信を、操作を繰り返す恐れのあるコマンドで追跡しないでください。公開GETページを使い、決済後に循環する場合はチケット提供元に安全な診断方法を確認します。

競合する規則の管理層を特定する

ドメイン、CDN、ホスティング、CMS、アプリ、言語経路の最近の変更を並べます。すべての転送を削除するのではなく、最初の反復箇所を担当規則に結び付けます。たとえばCDNがHTTPSに転送し、元サーバーがHTTPへ戻すと循環し得ます。Cloudflareは特定の暗号化モードと元サーバーの組合せでこの問題を説明しています。製品固有の例です。構成を確認せずTLSを弱めたりHSTSを無効にしたりしないでください。[2]

元に戻せる一件の修正をレビューする

担当者が現行規則、意図する最終URL、戻し方を記録します。確認できた競合だけを、提供元の通常の変更手順で直します。Cookieやキャッシュの削除は一台の古い状態には役立つ可能性がありますが、サーバー側でLocationが繰り返される問題は直せません。二社をまたぐなら同じ時刻付き記録を渡し、どちらが最終転送を管理するか合意します。

来場者が使うリンクを再確認する

旧告知URL、新イベントページ、各言語の経路、公開チケットボタンをスマートフォンとPCで開きます。いずれも正しい開催回と日付に循環せず到達することを確認し、購入前の安全な段階で止めます。元の失敗URLの追跡をやり直し、最終到達先、状態、担当者、時刻を記録します。壊れた経路を使う管理下のメール、QR先、協力先リンクも更新します。