私はしばらくLaravel 4サイトに取り組んでおり、会社はそれをロードバランサーの背後に置きました。ログインしようとすると、基本的にページが更新されます。https://github.com/fideloper/proxyで fideloper のプロキシ パッケージを使用してみましたが、変化は見られません。proxies => '*' を実行して、すべての IP アドレスを許可するようにしました。Laravel をロードバランサーの背後で、特にセッションで動作させるには、何をする必要があるかを知るための助けが必要です。データベースの Laravel セッション ドライバーを使用していることに注意してください。
ロードバランサーは KEMP LM-3600 です。
有益な情報を提供してくださった皆様、ありがとうございました。さらにテストした結果、これが機能しない理由は、ロード バランサーを介して https を強制しているが、ロード バランサーを介していないときは http を許可しているためであることがわかりました。ログイン フォームは、実際には https ではなく http に投稿していました。これにより、フォームは投稿できましたが、セッション データはクライアントに返されませんでした。フォームを https に投稿するように変更すると、この問題が修正されました。
Laravel 4 でのセッション処理は Symfony 2 コードを使用していることに注意してください。これは、「files」、「memcached」などの PHP 提供のセッション保存ハンドラーを使用しないすべての自己コーディングされたハンドラーで適切なセッション ロックを欠いていることに注意してください。
これは、Ajax などの並列リクエストを使用する Web アプリケーションで使用するとエラーが発生しますが、これはロード バランサーとは関係なく発生するはずです。
あなたは本当にもう少し調査を行う必要があります。HTTP ロード バランサーは情報の流れにある程度の影響を与えますが、PHP アプリケーションへの唯一の影響は、サイトを閲覧している 1 人のユーザーが接続されたサーバーのいずれかにランダムに要求を送信することであり、常に同じサーバーに送信されるとは限りません。
また、マスター/スレーブ レプリケーションなどの高度なデータベース セットアップも使用しますか? 書き込みがマスターでのみ行われ、読み取りがスレーブでのみ行われ、このスレーブが最後の書き込み操作を更新してマスターの背後にある場合、これはセッションに影響を与える可能性が高くなります。このような構成は、セッション ストレージとしては推奨されません。代わりに Memcached を使用したいと思います。PHP セッション保存ハンドラも適切なロックを実装しています...
fideloper のプロキシを使用しても意味がありません。ロード バランサーは、Web サーバーに対して透過的である必要があります。つまり、そのように構成されていない限り、リバース プロキシとして機能するべきではありません。
私は仕事でロードバランサーを使用していますが、cPanel ダッシュボードにアクセスする際に、セクションにアクセスしようとするたびにページがリロードされ、IP アドレスが変更されたときにログオフするという同様の問題に遭遇しました。解決策は、cPanel が使用しているポートを見つけ、そのポートを 1 つの WAN にバインドするようにロード バランサーを構成することでした。申し訳ありませんが、私は laravel に詳しくありません。ポート 80 を使用しているだけの場合、これは解決策ではない可能性があります。
TrustedProxyをしばらく使用していますが、正常に動作しています。
ロード バランサーの主な問題は、プロキシ ルーティングです。次はreadmeファイルからのもので、私が探していたものです。
サイトがロード バランサー、ゲートウェイ キャッシュ、またはその他の「リバース プロキシ」の背後にある場合、各 Web リクエストは、クライアントがサイトで実際にリクエストを行うのではなく、常にそのプロキシから送信されているように見える可能性があります。
これを修正するために、このパッケージを使用すると、プロキシに関する Symfony の知識を活用できます。「信頼できるプロキシ」のトピックの詳細については、以下を参照してください。
共有リソースを使用してセッション データを保存します。ファイルと memcached は確実に機能しません。DB は問題ないはずです。それが、共通データベースを使用した負荷分散セットアップで使用しているものです。