概要

Railsアプリを本番環境(AWS/EC2)にデプロイしようとIPアドレスでサーバーへ接続した際、「このサイトにアクセスできません。応答時間が長すぎます」とのエラーで長時間ハマったため、備忘録　兼　同じ境遇の方の参考になればと思い投稿しました。

実行環境

・Rails v5.1.7
・Ruby v2.7.0
・mysql
・AWS, EC2(本番環境)
・unicorn
・nginx

結論 : config.force_ssl = true を有効にしていたことが原因

config.force_ssl = true

を

config.force_ssl = false

に変更することで改善出来ました。

config.force_ssl って何?

ずばり、IPアドレスへのアクセスを全てhttps形式として通信させる設定です。

つまり、意図せずとも自動でhttps形式になるということ。

こちらのコードは本番環境上の設定を決めるconfig/production.rbファイル内にあります。　config.force_ssl = true のコードは通常コメントアウトされているのですが、開発中に外したことが原因となっていました。

今回私が立てたAWSのEC2サーバーは、通信形式をhttp形式のポート範囲でのみ設定しており、許可していないhttps形式で延々とアクセスしていたことで、「応答時間が長すぎます」とのエラーが発生したのです。同じ症状で悩んでいる方は、一度EC2のセキュリティグループ設定と上記のファイルを確認してみるといいかもしれません。

解決までにやったこと

余談ですが、今回の件でエラー解消に関する知見が深まったので、自分なりに学んだポイントを書かせて頂きます。

サーバー通信エラー解決のポイント
①問題が起きているサーバーがどこなのかを特定する
②問題が起きているサーバーのログを読む
③ログを読んでもわからない場合は怪しいところをコピペしてひたすらググる！笑

もう少しだけ掘り下げて書いていきます。

①について
クライアントがwebサイトにアクセスしてからアプリケーションが表示されるまでにどのような処理が行われているのか調べ以下の構造になっていることを学習しました。上から順に接続していき、アプリケーションを起動するようです。
色々な記事で、Nginx➡︎Unicornの順に起動すると書いていることに対して何も考えていませんでしたが、調べてやっと理解することが出来ました。

・開発環境(今回の場合EC2)
　⬇︎
・webサーバー(今回の場合Nginx)
　⬇︎
・アプリケーションサーバー(今回の場合Unicorn。このサーバーの中にアプリがあります)

そして、正しくアクセス出来ているか上記の順番で1つずつ確認しました。

結果として、記事前半の内容が原因でEC2➡︎Nginxへの通信が出来ていないことを突き止めることが出来ました。

②について
・開発環境
ローカル環境の場合ここは問題ないかなと思います。EC2等クラウドサーバーの場合、インターネットゲートウェイ/ルートテーブル/セキュリティグループ等、通信の設定によりこのサーバーと接続出来ないことも。まだ十分に理解出来ていないので詳細は控えます。

・webサーバー(私の場合ここが原因でした)
Nginx、Unicorn、デプロイするアプリ全てインストールし、2つともサーバー上で起動出来ているにも関わらずエラー発生。何度見直しても間違いがわからず手詰まりでしたが、Nginxログが解決の糸口となりました！

・nginx.access.log
・nginx.error.log
・Unicorn.log
・production.log

nginxやunicorn、railsアプリも、リアルタイムでアクセス履歴を記録してくれる上記ファイルが自動作成されています。私自身最近まで知らなかったのですが、ローカル環境のターミナルでrails s したあとに出るアレと同じものが用意されているのですね。私の場合、クローンしたアプリ直下のlogディレクトリ内にありました。
(nginxのconfファイルで設定している場所に生成されるようなので、人によって違うかもしれません)
それでは中身を確認しましょう！

tail -f /var/www/rails/アプリ名/log/nginx.access.log

※tail -f :ファイルの最後に追加される文字を表示するコマンド
(エラーが特定しづらい場合はcatコマンドで全て表示させて確認してください)

上記コマンドでnginx.access.logを表示し、ブラウザでアクセスしながら再度logを確認。
すると、何度試みてもlogの内容が更新されていないことに気付きました。
ここで初めて、Nginxに接続出来ていないこと(EC2サーバー➡︎webサーバーの通信が上手くいっていないこと)がわかり、ググって記事を漁り、なんとか解決に至りました。
ログを確認することの大切さをここでやっと理解しました。
また、今回は活用する機会がありませんでしたが、Nginxにアクセス出来ていると確認出来た場合は
同ディレクトリのnginx.error.logの中身を確認。

tail -f /var/www/rails/アプリ名/log/nginx.error.log

エラーが起きている場合、Nginxのサーバー内での問題の可能性があります。
(Webサーバー➡︎アプリケーションサーバーの通信)

エラーがない場合は、アプリケーションサーバーもしくはアプリ内で問題が起きている可能性があります。
同ディレクトリのunicorn.log、production.log(アプリ内のログ)それぞれ、同様の方法で確認しましょう。

あとは③の通り、ログで見つけた怪しい部分をひたすら読む、ググるの繰り返しです笑
それでも解決出来ないことは多々あると思いますが、これが今回学んだエラーの解決フローです。

最後に

拙い記事にも関わらずここまで読んで頂きありがとうございます！
この記事が少しでも誰かのエラー解決の手助けになれば幸いです。
また、まだまだ勉強不足で間違っている部分があるかもしれません。何かあればコメントでご指摘頂ければと思います。

参考記事

railsアプリをAWSへデプロイするうえで、こちらの記事を参考にさせて頂き、完遂することが出来ました！どちらの記事も画像や細かいポイント付きでとてもわかりやすかったので、実行環境がマッチしている方は是非参考にしてみてください！

https://qiita.com/naoki_mochizuki/items/f795fe3e661a3349a7ce
https://qiita.com/Yuki_Nagaoka/items/975b7598806d6ae0c0b2