を渡すが、これは設定ガットhttps://support.cloud.engineyard.com/entries/21715452-use-elastic-load-balancing-with-engine-yard-cloudエンジンヤードのRailsアプリ - 弾性ロードバランサ（ELB）でSSLを終了し、X-転送さ-プロトHTTPヘッダー
でエンジンヤードのドキュメントを踏襲し、に私たちをうまく機能できるように登場しましたSSLを使用します。サーバーではなくELBで終了します。理論的には、単一の環境で複数のSSL証明書を使用することができます。
この設定は、ブラウザとELBロードバランサ間のトラフィックがSSLであることを意味しますが、ELBからアプリケーションサーバーへの以降のトラフィックは復号化されます。これは、3.2.8アプリケーション強制SSLの問題を引き起こしました。すべての復号化された要求をhttpsにリダイレクトし、ロードバランサから解読された要求を再度アプリケーションサーバーに送信し、無限ループ状態を引き起こします。
私たちのアプリでSSLの強制を無効にした場合、SSL接続からのものであるかどうかを確認するために各リクエストをテストする必要があります。
このリリースノート（http://aws.amazon.com/releasenotes/7778622769836370）によると、ELBはトラフィックがhttps接続から渡されたときに「https」を含むX-Forwarded-Protoヘッダーを渡します。
最初にEngine Yardのリクエストに「X-Forwarded-Proto」というヘッダーはありません。 'HTTP_X-FORWARDED_PROTO'は存在しますが、トラフィックがSSL経由でELBに送信されても、常に 'http'が含まれます。
回避策として、誰でもこのアイデアやアイデアを洞察できますか？私はこれまで多くの運がなかったEYサポートを試みました。
EngineYardに連絡すると、アプリのstunnel機能フラグを有効にすることができます。これにより、x-proto-forwardを所定の位置に保持し、取り除くことはありません。 –