一度デプロイに成功したアプリケーションが常時SSL化をしたところ、pcからならアクセスできるけどスマホからだとアクセスできない、なんてことになりました。
ものすっごい初歩的なところで１日かけてしまったので、自分への戒めも含めて投稿しようかと思います。
前提
・EC2インスタンスランニング状態(ポート：HTTP 80を開き、ソースはロードバランサのセキュリティグループを指定)
・ロードバランサのターゲットグループのステータスはHealty(ポート：HTTP 80を設定)
・ロードバランサのDNS名にはAレコードが設定されている
・ロードバランサのリスナー：HTTPS 443 (SSL認証書も紐づいている)
・コンソールからec2-userにログイン可能
・本番環境内のproduction.logにはFatalやErrorの記述なし
・Capistranoの自動デプロイにエラーなし
しかしアプリにアクセスできたりできなかったりする！！
結論
ELBのセキュリティグループインバウンドでソースにマイIPを指定していた
つまり、自宅のWifiなら接続できるけど、スマホの通信やカフェのWifiじゃ条件が違うからアクセスできなかっただけのこと！
時間経過でだめになってるのかと思っていました…
なんて愚かなんでしょう…
概念図(これが超重要！)
一番の敗因は概念図を理解していなかったことだと思います。
自分の構築した設定が、どんな構造をしているのかわかっていなかった。
ちなみに今回の場合の概念図は下図です。
最終的にはこんな設定になりました
①ロードバランサーのリスナー設定
②ロードバランサーのインバウンド設定
③ターゲットグループの基本設定
④ターゲットグループのEC2インスタンス設定
⑤EC2インスタンスのインバウンド設定
⑥Route53のロードバランサー設定
成功パターン
上記の設定をしたものを概念図に書き起こすと、こうなります。
クライアントからEC2まで適切なポートと信号を設定してあげて通信をする、というイメージでしょうか。
失敗パターン
今回の場合僕は、②の時にロードバランサーのインバウンド設定の時にソースとして自宅のIPアドレスを指定していたということです。
つまり概念図に書き起こすとこんな感じです。ちょっと見にくいですね、編集能力なくてごめんなさい・・・。
なんと頑固なロードバランサーであろうか・・・。
この設定をしてしまっていたので、自宅Wifiを使った環境のものならばアプリケーションにアクセスできるけど、場所を移動してカフェから繋いだり、スマホからアクセスしようとすると繋がらなかった、ということみたいです。
まとめ
とにかく一度手を動かしてみるという信条で勉強していて、その方針は間違っていないんじゃないかなと思います。
ただ本を読んだだけで理解できるほど頭も良くないので・・・。
しかしこうして詰まった時に一度俯瞰してみたりとか、実装段階でちょっとずつでも概念を噛み砕いていく癖をつけないとなと思いました。
Qiitaに書いてあったから、ブログに書いてあったから、その結果動いたからこれでOK！というのは危険だなと感じました。
反省です・・
補足
ちなみにデプロイの際にはNginxを使っているのですが、Nginxのconfファイルの設定で、listen 80;にしています。
ここが違っているのであれば、概念図とそのポート番号とかはまた変わってくるかと思います。