私はいくつかの質問が投稿されているのを見ましたが、彼らはこの特定の項目に合格したか未回答のままになりました。
基本的に、私はnginx
を前面にして、同じワードプレスWebサイトの2つのインスタンス間でロードバランスを設定しました。正常にログインするには、/wp-admin
または/wp-login.php
に対するすべての要求を特定のサーバーに固定する必要があります。すべての要求が同じサーバーに送信される限り、どのサーバーでもかまいません。
最初は1台のサーバーがセッションデータを保存していると思いましたが、PHPセッションをクラスタ化して保存していないことを確認しました。私はクッキーをチェックしましたが、そこにはサーバ依存のものは何も表示されません(静的な値を持つWPテストクッキーだけ)。ファイルシステムを継続的に監視して、ファイルがバックエンドアプリケーションサーバーの1つで作成されているかどうかを確認しましたが、役に立ちませんでした。私は彼らが来るのと同じくらい基本的に思えるログインフォームさえチェックしました。
WPが実際にどのサーバがPOST
リクエストを実際に受け取ったのかを気にすることさえないのか、私は文字通りまったくわかりません。
あなたが望むなら、私はnginxの設定を供給することができますが、それはかなり簡単です、そして、私はこの記事を雑然とさせたくありません。
確認すべき点がいくつかあります。
wp_salt
を確認してください。すべてのWebサーバーがwp-config.php
ファイル内の同じ一連のソルトで実行されていることを確認してください。理想的には、これらは単一の場所からミラーリングされるべきです。
is_ssl()
を確認して、この機能がすべてのWebサーバーでSSLを正しく検出していることを確認してください。ロードバランサがポート80
でWebサーバーに内部接続するときに、この小さな関数が多くの頭痛の種を引き起こすのを見ました。 is_ssl()
が(負荷分散のために)これを検出しない場合、それはこの問題を引き起こすかもしれません。すなわち、可能なクッキープロトコルの変更。
簡単な解決策の1つは、転送されたプロトコルをwp-config.php
で確認することです。
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
&& strcasecmp( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) === 0 ) {
$_SERVER['HTTPS'] = 'on'; // Convince WordPress.
}
$_SERVER['REMOTE_ADDR']
環境変数を調べて、これがすべてのWebサーバーで同じ方法で取り込まれていることを確認してください。これを使用するWordPress用のプラグインは多数ありますが、負荷分散のシナリオは考慮されていません。
確認する最も簡単な方法は、いくつかのWebサーバーに<?php phpinfo();
をダンプし、それらがすべてこれを正しく設定しているかどうかを確認することです。それとも、実際のIPアドレスはHTTP_X_FORWARDED_FOR
、HTTP_CLIENT_IP
、またはその他のものになっていますか?一言で言えば、REMOTE_ADDR
を修正することによってプラグインを混同しないでください。
システム時刻がすべてのWebサーバー間で同期していることを確認してください。
ブルートフォース攻撃を防ぐことを目的としているプラグインは、厳密な検証を行っている可能性が高いため、もっと詳しく調べてください。たとえば、ユーザエージェント、IPアドレス、IPアドレスの変更などをテストします。彼らの仕事はだまされてはいけませんが、誤検出を引き起こすことがあります。
問題が解決しない場合は、実行中のアクティブなプラグインとあなたが言及したNginxの設定のリストを投稿してください。 FastCGI paramsは、あなたが持っているかもしれないし持っていないかもしれないどんなプロキシ構成とも一緒に見るのが良いでしょう。