WordPress AI接続のリダイレクトループを診断する

リダイレクトがスキーム、ホスト、パスを変更し、認証ヘッダーも失う場合があります。

すべてのリダイレクトを追跡し、スキーム、ホスト、パス、Authorizationの維持を確認します。

考えられる原因

  • リダイレクトがスキーム、ホスト、パスを変更し、認証ヘッダーも失う場合があります。
  • WordPress Home URLとSite URLでスキーム、ホスト、またはパスが一致していません。
  • ブラウザーはHTTPSですが、オリジン側のWordPressが安全なリクエストとして認識していません。
  • クライアントが誤ったドメイン、ベースパス、RESTエンドポイント、またはMCPエンドポイントを呼び出しています。
  • ホスティング、リバースプロキシ、リダイレクト、またはWAFがWordPress到達前にAuthorizationヘッダーを削除しています。

診断手順

  1. すべてのリダイレクトを追跡し、スキーム、ホスト、パス、Authorizationの維持を確認します。
  2. Home URL、Site URL、公開正規ホスト、RESTベースアドレスを比較します。
  3. ブラウザーだけでなく、WordPress自体がリクエストをHTTPSとして認識することを確認します。
  4. 秘密を除去したサーバー証拠でAuthorizationヘッダーがWordPressへ届くか確認します。
  5. クライアント設定のスキーム、ホスト、ベースパス、エンドポイントを確認します。
  6. 変更前にWordPress、プラグイン、クライアント、コネクター、サーバーのバージョンを記録します。

最小限の修正を適用する

  1. 認証済みリクエストを予期せず変更するリダイレクトを削除または修正します。
  2. Home URL、Site URL、公開ホスト、HTTPSスキーム、RESTベースを一致させます。
  3. 信頼済みプロキシとオリジンの処理を修正し、WordPressが元のHTTPSリクエストを認識できるようにします。
  4. 信頼済みサーバーまたはプロキシがAuthorizationヘッダーをWordPressへ渡すようにします。
  5. WordPress権限を広げず、エンドポイント、transport、ツール名、認証情報参照を修正します。

結果を検証する

  • 認証済みリクエストが予期しないリダイレクトなしで正規エンドポイントに到達します。
  • 秘密除去済みサーバー証拠でAuthorizationヘッダーがWordPressへ届くことを確認できます。
  • 認証済みリクエストが意図した専用WordPressユーザーに対応します。
  • 承認された限定的な読み取りが再現可能な応答で成功します。

避けるべき対応

  • 信頼経路を確認する前に、未検証の恒久的なプロキシ回避策を追加しないでください。
  • 一つのリクエストを通すためにWAFやセキュリティプラグイン全体を無効にしないでください。
  • 最初の診断手順としてWordPressコアや第三者プラグインのファイルを編集しないでください。
  • 接続テストを通す目的だけで管理者権限を付与しないでください。
  • Application Password、Authorizationヘッダー、トークン、Cookieをプロンプト、チケット、ログ、画像に含めないでください。

関連ガイド

情報源と検証

このページは、以下の一次情報源に基づいて確認されています。 情報源の最終確認日: .