Chromeは、ローカルホストWebサイトをhttpではなくhttpsとしてロードし、エラーが発生しました（ubuntuの更新後に発生しました）
作業中のローカルwordpressプロジェクトがあり、通常、URLバーにexample.devと入力してWebサイトを開きます。作業中のWebサイトは正しく表示されます。
私はapt-get updateとapt-get upgrade私のubuntuコンピューターで、再起動を要求しました。再起動後-ローカルWebサイトを開こうとするとエラーが表示されます。
このサイトにアクセスできませんexample.devは接続を拒否しました。試してください：
接続の確認プロキシとファイアウォールの確認ERR_CONNECTION_REFUSED ReloadHIDE詳細インターネット接続の確認ケーブルを確認し、使用しているルーター、モデム、またはその他のネットワークデバイスを再起動します。 Chromeがファイアウォールまたはウイルス対策設定でネットワークにアクセスできるようにします。ネットワークへのアクセスが許可されているプログラムとして既にリストされている場合は、リストから削除して再度追加してみてください。プロキシサーバーを使用している場合…プロキシ設定を確認するか、ネットワーク管理者に連絡して、プロキシサーバーが機能していることを確認してください。プロキシサーバーを使用する必要があると思わない場合：Chromeメニュー> [設定]> [詳細設定を表示…]> [プロキシ設定を変更...]に移動し、構成が[プロキシなし]に設定されていることを確認します"直接。"
「https」を「http」に編集するたびに「Enter」を押した後、「https」ではなく「https」としてWebサイトにサービスを提供していることに気付きました。
私はこれが問題だとは確信していなかったので、Firefoxを開いて同じことをしました。そして、「https」ではなく「http」を最初に持つ私のウェブサイトの適切な出力を得ました。
Chromeでこれが発生する原因は何ですか？
私のWebサイトはApache2サーバーで実行されています。これは、更新前には発生しませんでした。
編集：私はこの投稿に出くわしました- https://superuser.com/a/1251483/414388 そして、ドメイン名を変更する必要がある理由を本当に理解していない-私は本当にしたくないこの方法に従うこと。これは解決策ではありません。
スーパーユーザーの投稿に投稿された the article に移動すると、tl; drが説明します。
tl; dr：Chrome 63（2017年12月以降）、. dev（および.foo）で終わるすべてのドメインを、プリロードされたHTTP Strict Transport Security（HSTS）ヘッダーを介してHTTPSにリダイレクトします。
したがって、唯一の解決策は、.dev TLD以外に変更するか、証明書を作成し、ローカル開発用に 仮想ホスト構成 にHTTPSを実装することです。
それがあなたの唯一のソリューションである理由を説明するために、HSTSの意味とその仕組みから始めなければなりません。
HSTS全般
HSTSは比較的新しいHTTPヘッダーであり、設定すると、ブラウザに、誰かが次回ドメインに移動したときに、サーバー側のリダイレクトを必要とせずにHTTPSを使用してのみアクセスすることを通知します。
たとえば、http://example.comに移動したとしましょう。応答ヘッダーで、次を受け取ります：
Strict-Transport-Security: max-age=31536000
このヘッダーは、翌年（31536000秒）にユーザーがhttp://example.comにアクセスすると、サーバーのリダイレクトを必要とせずにそのURLをhttps://example.comにローカルにリダイレクトすることをブラウザーに伝えます。それから、https://example.comでサイトにアクセスします。
サブドメインのHSTS
上記は単一のドメインに対してのみ有効です。たとえば、http://subdomain.example.comにアクセスしようとすると、サイトはリダイレクトなしで機能します。
これを解決するには、前のヘッダーを次のように変更する必要があります。
Strict-Transport-Security: max-age=31536000; includeSubdomains
これで、example.comのサブドメインにアクセスしたことがない場合でも、ブラウザーはリクエストを行う前に常にサブドメインをhttpsにリダイレクトします。
HSTSプリロード
最後のステップは、最後の1つの問題を修正することです。初めてサイトにアクセスするときは、HTTPを使用してアクセスしているため、HTTPSにリダイレクトされ、HSTSヘッダーが送信されます。前のものは安全ではありませんが、依然としてセキュリティの問題です。
これを解決するために、主要なブラウザーはChromeのHTTP Strict Transport Security（HSTS）プリロードリストを使用して、HTTPSでのみアクセスできるドメインをハードコードします。提出フォームはこちらにあります： https://hstspreload.org/
ドメインを送信する前に行う必要がある唯一の変更は、少なくとも2年間ブラウザにキャッシュされるようにヘッダーを変更し、preloadオプションを追加することです。
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
ドメインを送信し、Chromeの新しいバージョン（または、ChromeのHSTSプリロードリストを実装しているブラウザであり、必ずしも次のバージョンではない）がリリースされると、ドメインはChrome HTTPSのみ。
TLDのHSTSプリロード
TLDの所有者は、 HSTSプリロード用にTLD全体を送信 を許可（および推奨）されます。
GTLD、ccTLD、またはその他のパブリックサフィックスドメインの所有者は、登録可能なすべてのドメインにHSTSをプリロードしてください。これにより、TLD全体の堅牢なセキュリティが確保され、個々のドメインをプリロードするよりもはるかに簡単になります。
また、Googleは.dev TLDを所有しているため、まさにそれを行いました。そのため、すべての*.devドメインはChromeのHTTPSでのみ機能します。また、ほとんどのブラウザは同じプリロードリストを使用しているため、これらのブラウザも機能しなくなります。
プリロードされたドメインのリスト （CAUTION：ページを検索する場合40MB以上で、レンダリングに時間がかかります。そのため、コンピューターが十分に強力でないとフリーズする可能性があります！）、TLDがプリロードされていることがわかります：google、dev、foo、page 、app、chrome。
// eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
現在の.devドメインを変更するオプションを使用できない場合は、Chromeをバージョン61にダウングレードできます（正常に完了しました=> here ）