Cloudflareまたはリバースプロキシ経由でWordPressがHTTPSを検出しない
ブラウザーはHTTPSですが、オリジン側のWordPressが安全なリクエストとして認識していません。
アシスタントが使用する正確なURLが有効なHTTPSで開くことを確認します。
考えられる原因
- ブラウザーはHTTPSですが、オリジン側のWordPressが安全なリクエストとして認識していません。
- WordPressがHTTPSを認識するためのスキーム情報をプロキシが転送していません。
- WordPress Home URLとSite URLでスキーム、ホスト、またはパスが一致していません。
- リダイレクトがスキーム、ホスト、パスを変更し、認証ヘッダーも失う場合があります。
- 別のプラグインがHTTPS検出、RESTアクセス、またはApplication Passwordの可用性を変更しています。
診断手順
- アシスタントが使用する正確なURLが有効なHTTPSで開くことを確認します。
- ブラウザーだけでなく、WordPress自体がリクエストをHTTPSとして認識することを確認します。
- 元のHTTPSスキームをWordPressへ伝える信頼済みプロキシヘッダーを確認します。
- Home URL、Site URL、公開正規ホスト、RESTベースアドレスを比較します。
- すべてのリダイレクトを追跡し、スキーム、ホスト、パス、Authorizationの維持を確認します。
- 変更前にWordPress、プラグイン、クライアント、コネクター、サーバーのバージョンを記録します。
最小限の修正を適用する
- 信頼済みプロキシとオリジンの処理を修正し、WordPressが元のHTTPSリクエストを認識できるようにします。
- Home URL、Site URL、公開ホスト、HTTPSスキーム、RESTベースを一致させます。
- 認証済みリクエストを予期せず変更するリダイレクトを削除または修正します。
- 保護全体を無効にせず、確認済みの誤検知ルール、パス、メソッドだけを調整します。
- プラグイン固有の動作が残る場合、秘密を除去したバージョン付き証拠でサポートへ連絡します。
結果を検証する
- 修正条件でのみ通知が消え、無関係な管理画面には再表示されません。
- 認証済みリクエストが予期しないリダイレクトなしで正規エンドポイントに到達します。
- RESTインデックスが正規HTTPS URLから応答し、期待するnamespaceを公開します。
- 認証済みリクエストが意図した専用WordPressユーザーに対応します。
避けるべき対応
- 信頼経路を確認する前に、未検証の恒久的なプロキシ回避策を追加しないでください。
- 一つのリクエストを通すためにWAFやセキュリティプラグイン全体を無効にしないでください。
- 最初の診断手順としてWordPressコアや第三者プラグインのファイルを編集しないでください。
- 接続テストを通す目的だけで管理者権限を付与しないでください。
- Application Password、Authorizationヘッダー、トークン、Cookieをプロンプト、チケット、ログ、画像に含めないでください。
よくある質問
恒久的なコードでHTTPSを強制すべきですか?
ホスティングとプロキシの構成を理解してからにしてください。汎用コードはオリジン設定の誤りを隠したり、未検証の転送ヘッダーを信頼したりする可能性があります。
関連ガイド
- HTTPSサイトでWAP AI AssistantのHTTPS警告が表示される理由
- WordPressのApplication Passwordが無効な場合の原因と確認
- WordPressアドレスとサイトアドレスの不一致がAI接続を壊す
- WordPress AI接続のリダイレクトループを診断する
- WordPressのAuthorizationヘッダーが欠落または削除される
情報源と検証
このページは、以下の一次情報源に基づいて確認されています。 情報源の最終確認日: .
- is_ssl() · WordPress Developer Resources
- home_url() · WordPress Developer Resources
- site_url() · WordPress Developer Resources
- Cloudflare SSL/TLS Encryption Modes · Cloudflare