rails,nginx,pumaでのhttps通信がうまくいかない

rails6で作成したアプリをec2内のnginx,puma4.3で起動したいのですが、
ALB、ACMを使用したhttps化がうまくいっておりません。
puma導入時には正常にhttps通信が行えていたのですが、
数時間後にふとページを開こうとすると、ERR_CONNECTION_REFUSEDのページが表示されており、
pumaのログを見ると

HTTP parse error, malformed request (127.0.0.1): #<Puma::HttpParserError: Invalid HTTP format, parsing fails

と表示されていました。
色々と調べて試してみた結果、
手持ちのスマートフォン接続では正常にhttpsで接続されるのですが、
pcのChromeからだとERR_CONNECTION_REFUSEDとなる奇妙な環境になってしまいました。
Chromeのクッキー削除などもちろん試しているのですが、同様です。
おそらくnginxやALBの設定がうまくいっていないのかなと思うのですが、かなりの時間手詰まりなためアドバイスいただければ幸いです。
以下に設定を記述します。
他に必要な情報があれば追記いたします。

追記：手持ちのwindowsPCのchromeでアクセスした場合や遠方の知人がアクセスした場合も正常に表示されており、
開発環境で使用中のMacでのみchrome,firefox共に表示されません。

##/etc/nginx/nginx.conf

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    server_names_hash_bucket_size  64;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    #include /etc/nginx/conf.d/*.conf;

    upstream puma {
        server unix:///var/www/rails/myapp/shared/tmp/sockets/puma.sock;
    }

    server {
        listen       80;
        server_name  myapp.com;
        root         /var/www/rails/myapp/current/public;

        # Load configuration files for the default server block.
        #include /etc/nginx/default.d/*.conf;

        try_files $uri $uri/index.html $uri.html @webapp;
        location @webapp {
            proxy_read_timeout 300;
            proxy_connect_timeout 300;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://puma;
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

###config_force_ssl=true

###ALBリスナー
HTTP 80
HTTPS 443 証明書：ACMで取得した証明書

##curl結果追記
sudo curl -v https://ドメイン
EC2から確認→Trying （見覚えの無いIP）...
成功
Macから確認→Trying （インスタンスと紐づけられたEIP）...
connect to (インスタンスと紐づけられたEIP) port 443 failed: Connection refused

＃＃＃dig結果追記
ec2

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> https://myapp.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59882
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;https://myapp.com.		IN	A

;; AUTHORITY SECTION:
com.			60	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1577639153 1800 900 604800 86400

;; Query time: 111 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: 月 12月 30 02:06:23 JST 2019
;; MSG SIZE  rcvd: 122

Mac

; <<>> DiG 9.10.6 <<>> https://myapp.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17607
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;https://myapp.com.		IN	A

;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1577639108 1800 900 604800 86400

;; Query time: 757 msec
;; SERVER: s.s.s.1#53(192.168.11.1)
;; WHEN: Mon Dec 30 02:05:21 JST 2019
;; MSG SIZE  rcvd: 122

Macのdig結果のSERVERにある「s」部分は今使用しているMacのIPアドレスと一致しています

winterboum

2019/12/21 21:26

ブラウザー、OSで違う結果というのも不思議です。仮説も持てない状態ですが、状況をもう少し知りたいので１）HTTP parse error, malformed request 　はまだ続いていますか 2)ALB（ELB?)からのhelthcheckには正常に答えていますか 3)HTTP 80のリスナーのredirect先はどう定義してありますか

garta

2019/12/21 22:23

おはようございます。いつもありがとうございます。 chrome以外にもfirefoxで試しましたが、やはり開発環境で使用しているMacでのみアクセスができない状態のようです。 1)現在は正常に動作しているようで、parseerrorはありませんでした。　parseerrorが発生していた状況は以下になります。　昨日の朝まではスマホ、Macからも正常アクセス、　昼頃もスマホから正常アクセス、　日付を跨いだ夜中帰宅してMacでアクセスし直すと繋がらず、ログを見るとparseerrorが発生。　現在はスマホ、windowsPCからはアクセスできるものの、開発環境として使用のMacからはいずれのブラウザからもアクセスできず、ログにエラーも出力されない。 2)ALBのターゲットグループからのヘルスチェックに使用中のEC2インスタンスは合格しています。 3)転送先は使用中のEC2、ALB、VPCと紐づけられたターゲットグループとなっています。

garta

2019/12/21 22:50

また、遠方の知人にアクセスしてもらったところ正常にアクセスできたようで、やはり私の開発環境Macだけの問題のようです。。。あまり関係ないかもしれませんが追記しておきます。

take88

2019/12/25 17:40

ALB → ターゲットグループへの通信プロトコルは http になってますか？

garta

2019/12/26 06:14

今確認しましたが、http通信で設定されています

garta

2019/12/26 06:35 編集

また、今一度確認したところ、以前までクリアしていた ALBのインスタンスヘルスチェックがunhealthyになっていました。相変わらず開発環境のMac以外からはアクセスできますが、当面こちらのヘルスチェック問題から取り組んでいきます。以降も些細な指摘やアドバイスいただければと思います。年末のお忙しい中恐縮です。

garta

2019/12/27 22:20

sudo curl -v https://ドメイン　で接続を確認してみたところ、 EC2から確認→Trying （見覚えの無いIP）... 　　　　　　　成功 Macから確認→Trying （インスタンスと紐づけられたEIP）... 　　　　　　　connect to (インスタンスと紐づけられたEIP) port 443 failed: Connection refused と返事が返ってきました。こちらのエラーを調べつつ作業しようと思います。アドバイスいただければ幸いです。

take88

2019/12/28 04:23

DNSの問題のように思えますね。 MacでDNSキャッシュをクリアしてみてください。

garta

2019/12/29 04:48

>>take88さんアドバイスありがとうございます、ご指摘通りMac,chrome共にDNSキャッシュクリアを行いましたが同様に、開発環境のMacでのみアクセスできない状態です。

winterboum

2019/12/29 07:13

もうひとつの質問にも書きましたが「ドメイン」とは example.com のような大本のものですか？sub.example.comのようなサブドメインになっていますか？

winterboum

2019/12/29 08:06

ああ、そちらにサブドメインではない、と回答ありました。そちらに書きましたので見てください

take88

2019/12/29 12:35

Macからcurl実行した結果、接続先が、EC2のEIPになってるのがおかしいですね。 ALBにアクセスが行かず、EC2に直接アクセスしてるのでエラーになってる可能性を考えています。 DNSの問題を先に切り分けしたいので、EC2とMacの両方で「dig www.example.com」コマンドを実行して、返ってきた結果を書いてもらえますか？

garta

2019/12/29 17:24 編集

>>take88さんただいま帰宅しました、遅くなり申し訳ありません。回答ありがとうございます。 digの結果を追記いたします。確認よろしくお願いいたします。

take88

2019/12/30 04:26

自己解決したようですね。蛇足にはなりますが、dig の引数は「https://」は不要です。

garta

2019/12/30 17:57

>>take88さんおかげさまで解決しました。いえ、勉強になります。ありがとうございます。

行動規範の内容に同意します

回答1件

自己解決

ALBにアクセスが行かず、EC2に直接アクセスしている点がおかしいとのご指摘をいただき、
Macの/private/etc/hostsを確認してみたところ、
お恥ずかしながら
EIP　　　myapp.comの記述があり、
こちらを削除すると正常にページにアクセスできるようになりました。
take88さんのご指摘で気づくことができました。
自分はエンジニアを目指してポートフォリオ作成中で、１０日ほどこちらの問題に悩まされていました。
自分一人では年を明けても解決できなかったと思います。
本当にありがとうございました。
良いお年をお過ごしください。