ERR_SSL_PROTOCOL_ERRORの原因と解決方法｜無効な応答が送信されました

ERR_SSL_PROTOCOL_ERROR とは？

ERR_SSL_PROTOCOL_ERRORは、ブラウザが何かを読み込む前に、安全な接続がTLSハンドシェイクの途中で壊れたことを意味します。 Chromeでは「このサイトは安全に接続できません」「example.com から無効な応答が送信されました。」と表示され、Edgeでも同じERR_SSL_PROTOCOL_ERRORが表示されます。アドレスが localhost の場合は、開発サーバーがほぼ確実に暗号化なしのHTTPで応答しています。代わりに http://localhost を開いてください（下の開発者向けセクションを参照）。

すべてのHTTPS接続はTLSハンドシェイクから始まります。ブラウザとサーバーはここでプロトコルバージョン（TLS 1.2または1.3）と暗号方式に合意し、証明書を交換します。ERR_SSL_PROTOCOL_ERRORは、この交渉が決裂したこと、つまり相手側が正しいTLSではないデータを返してきたか、ブラウザが分類できない形でハンドシェイクを拒否したことを意味します。

HTTPリクエストが送信される前に起きるため、HTTPステータスコードではありません。Chromiumのエラー一覧では、エラー -107 として「An SSL protocol error occurred（SSLプロトコルエラーが発生しました）」の一行だけで定義されています。ハンドシェイクが壊れた場合の総称で、「共通のプロトコルバージョンまたは暗号がない」ことを示す具体的なエラー -113 とは別物です。

ERR_SSL_PROTOCOL_ERROR の表示画面

ChromeおよびChromiumベースのブラウザでは、「このサイトは安全に接続できません」 というメッセージとともにフルページの警告が表示されます。その下に特定のエラーコードが表示されます。以下は、よく見られるバリエーションです。

• localhost から無効な応答が送信されました。（英語版: localhost sent an invalid response） — 開発者が目にするパターンです。暗号化なしのHTTPで動くローカルサーバーを https:// で開いています
• ERR_SSL_PROTOCOL_ERROR — Chromeがメッセージの下に小さな文字で表示するエラーコード
• net::ERR_SSL_PROTOCOL_ERROR — Chrome DevToolsコンソールに表示される完全な内部エラーコード
• このサイトは安全に接続できません — Chromeに表示されるユーザー向けの見出しメッセージ
• [ドメイン] から無効な応答が送信されました。 — Chromeが見出しの下に表示する詳細なエラーテキスト
• すべてのブラウザでERR_SSL_PROTOCOL_ERROR — Chrome、Edge、Brave、Operaで同時にエラーが表示される場合（ブラウザ固有のバグではなく、サーバー側またはシステム全体の問題を示しています）

ERR_SSL_PROTOCOL_ERROR の原因

このエラーには、クライアント側（あなたのデバイス）とサーバー側（Webサイト）の両方に原因があります。どちら側の問題かを特定することが、修正への第一歩です。すべてのWebサイトでエラーが表示される場合は、あなたの側に問題があります。特定のWebサイトでのみ表示される場合は、サーバー側の問題である可能性が高いです。

• HTTPしか話さないサーバーにHTTPSで接続している — 最も検索されているケースです。開発サーバーを https://localhost で開いた場合や、ポート443がTLS用に設定されていないサイトが該当します。ブラウザがハンドシェイクを始めても平文が返ってくるため、Chromeはそれを「無効な応答が送信されました」と報告します。
• ウイルス対策ソフトのSSL/HTTPSスキャン — HTTPS通信を傍受するセキュリティソフト（Avast、Kaspersky、Bitdefender、ESET）はハンドシェイクに割り込むため、すべてのサイトで一斉にハンドシェイクを壊すことがあります。
• VPNまたはプロキシの干渉 — HTTPS通信を検査するVPNや企業プロキシはハンドシェイクを壊すことがあり、特にネットワークを切り替えた直後に起こりやすくなります。
• サイトをフィルタリングしているネットワーク — プロバイダー、学校、職場、国によるフィルタリングやDNSベースのブロッカーは、ブロック対象のサイトでハンドシェイクを意図的に失敗させます。見分け方は、モバイルデータや別のWi-Fiならサイトが開けることです。
• サーバーのTLS設定の不備 — ポート443が平文のHTTPで応答している（TLSを有効にしないまま443番ポートでサイトを設定している）か、別のプログラムがポート443を使っている状態です。
• ブラウザ拡張機能 — HTTPSリクエストを書き換えるプライバシー保護、広告ブロック、セキュリティ系のアドオンがハンドシェイクを妨げることがあります。
• 古いブラウザの状態 — サーバーの現状と合わなくなった、キャッシュ済みのセッションデータ。
• このエラーと間違えやすいもの — TLS 1.0や1.1のままのサーバーではERR_SSL_VERSION_OR_CIPHER_MISMATCH（「サポートされていないプロトコルが使用されています」）、期限切れ・名前違い・自己署名の証明書や時計のずれでは証明書エラー（NET::ERR_CERT_…）、QUIC（HTTP/3）の問題ではERR_QUIC_PROTOCOL_ERRORが表示されます。ERR_SSL_VERSION_OR_CIPHER_MISMATCHと「この接続ではプライバシーが保護されません」を参照してください。

localhost での ERR_SSL_PROTOCOL_ERROR（開発者向け）

「localhost から無効な応答が送信されました。ERR_SSL_PROTOCOL_ERROR」（英語版Chromeでは localhost sent an invalid response.）は、ほぼ確実に、HTTPしか話さない開発サーバーを https://localhost で開いたことを意味します。 ブラウザがTLSハンドシェイクを始め、サーバーが普通のHTTPのテキストで答えるため、Chromeはその応答を無効と報告します。Firefoxでは同じミスが SSL_ERROR_RX_RECORD_TOO_LONG と表示されます。

• サーバーが表示するアドレスを使う — https://localhost:3000 を http://localhost:3000 に変更します。Next.js、Vite、React、Django、Rails、Flaskの開発サーバーは、HTTPSを有効にしない限りHTTPで配信します
• ポートを確認する — ポートを付けない https://localhost はポート443を意味します。アプリが3000や5173で動いている場合、リクエストは別のプログラムに届くか、どこにも届きません
• Chromeが勝手にhttps://に切り替わる — 同じポートで以前動かしていたアプリのリダイレクトがキャッシュされていると、こうなることがあります。キャッシュされた画像とファイル を削除するか、シークレット ウィンドウで試してください。（Chrome 132より前のバージョンでは、localhostのHSTSエントリが残ることもありました。その場合は chrome://net-internals/#hsts の Delete domain security policies（この画面は英語表記です）で削除します）
• ローカルでもHTTPSが必要な場合（OAuthのコールバック、Secure属性付きCookieなど） — next dev --experimental-https は mkcert でローカルで信頼される証明書を作成します。Viteは server.https で証明書を指定するか、手早く自己署名証明書を使うなら @vitejs/plugin-basic-ssl を使います。それ以外の環境では、mkcert -install && mkcert localhost 127.0.0.1 でサーバーが読み込める証明書ファイルを作れます
• 自己署名証明書では別のエラーになる — このエラーではなく NET::ERR_CERT_AUTHORITY_INVALID が表示されます。詳細設定 → localhost にアクセスする（安全ではありません） をクリックするか、より確実な方法としてmkcertで作った証明書を使ってください（以前の allow-insecure-localhost フラグは期限切れで使えなくなっています）

ERR_SSL_PROTOCOL_ERROR の直し方（ユーザー向け）

まず修正方法1から始めてください。2分ほどで、問題がブラウザにあるのか、端末やネットワークにあるのか、それともサイト側にあるのかがわかります。そのあとはリストの順に試してください。

修正方法1：シークレット モードと別のネットワークで試す

シークレット モードは、Cookie、キャッシュ、拡張機能なし（シークレット モードでの実行を許可した拡張機能を除く）で起動します。サイトをシークレット ウィンドウ（ChromeとEdgeは Ctrl+Shift+N、Firefoxは Ctrl+Shift+P）で開き、次にスマホのモバイルデータなど別のネットワークでも開いてみてください。

シークレット ウィンドウで開ける場合、原因はブラウザにあり、拡張機能か古いデータです（修正方法4と5）。別のネットワークでだけ開ける場合は、今のネットワークかVPN、プロキシが通信をフィルタリングまたは傍受しています（修正方法3）。どこでも失敗する場合はSSLチェッカーでサイトを検査してください。そこでも失敗するなら、修正できるのはサイトの管理者だけです。

修正方法2：ウイルス対策ソフトのSSL/HTTPSスキャンを無効にする

多くのウイルス対策ソフト（Avast、Kaspersky、Bitdefender、ESET、Norton）には、中間者プロキシとして動作し暗号化された接続を傍受する「HTTPSスキャン」や「SSLインスペクション」機能があります。この機能がサイトのハンドシェイクをうまく処理できないと、そのパソコンのどのブラウザでもそのサイトが開けなくなります。

ウイルス対策ソフトで Web Shield、HTTPS Scanning、SSL Scanning、Encrypted connections scanning といった名前の設定（日本語版では表記が異なる場合があります）を探し、一時的に無効にしてください。エラーが解決した場合は、影響を受けたドメインをウイルス対策ソフトの除外リストに追加できます。

修正方法3：VPNまたはプロキシを無効にする

VPNとHTTPプロキシは、ブラウザとWebサーバーの間に位置します。一部のVPNはHTTPS通信を検査したり、TLSが正しく動作しないサーバーを経由して接続をルーティングしたりします。企業プロキシは、TLSハンドシェイクを破壊する可能性のあるSSLインターセプション（ウイルス対策のHTTPSスキャンと同様）を使用することがよくあります。

一時的にVPNを切断し、Webサイトの読み込みを試してください。VPNなしで正常に動作する場合、問題はVPNのSSL接続の処理方法にあります。別のVPNサーバーを試すか、VPNプロバイダーに問い合わせてください。

修正方法4：ブラウザ拡張機能を無効にする

VPNやプロキシの拡張機能、セキュリティ系のアドオンなど、通信をフィルタリングしたり経路を変えたりする拡張機能は、安全な接続を壊すことがあります。

chrome://extensions/ を開いてすべての拡張機能をオフにし、ページを再読み込みしてください。エラーが消えたら、1つずつオンに戻して原因の拡張機能を特定します。

修正方法5：ブラウザのキャッシュとCookieを削除する

古いCookieやキャッシュデータが邪魔をすることがまれにあり、削除は1分で済みます。

• ステップ1： Ctrl+Shift+Delete（Macは Cmd+Shift+Delete）を押して 閲覧履歴データを削除 を開く
• ステップ2： 期間で もっと見る → 全期間 を選ぶ
• ステップ3： Cookie と他のサイトデータ と キャッシュされた画像とファイル にチェックを入れる
• ステップ4： データを削除（ログインしていない場合は このデバイスから削除）をクリックし、Chromeを再起動する

1つのサイトだけなら、chrome://settings/content/all でドメインを検索し、そのサイトのデータを削除します。

修正方法6：QUIC（HTTP/3）が原因でないか確かめる

ChromeはQUIC（UDP上のHTTP/3）を通常のTCP接続と並行して試し、QUICが失敗するとTCPに切り替えます。そのため、QUICがERR_SSL_PROTOCOL_ERRORの原因になることはまれです。ページやDevToolsに ERR_QUIC_PROTOCOL_ERROR と表示されている場合は、QUICをオフにするのが解決策です（ERR_QUIC_PROTOCOL_ERRORを参照）：

• ステップ1： アドレスバーに chrome://flags/#enable-quic と入力する
• ステップ2： Experimental QUIC protocol を見つける
• ステップ3： Default から Disabled に変更する
• ステップ4： Relaunch をクリックしてChromeを再起動する

QUICをオフにしても、ページはTCP上のHTTP/2で読み込まれます。ネットワークやサイトの問題が解決したら、元に戻してください。

修正方法7：ブラウザを更新する

古いバージョンのブラウザには、最新のサイトが前提とするTLSの機能や暗号スイートがないことがあります。また、更新でTLS関連のバグも修正されます。

Chromeの更新方法：chrome://settings/help にアクセスするか、メニュー → ヘルプ → Google Chrome について をクリックします。Chromeは更新を自動でダウンロードしますが、適用するには再起動が必要です。Edgeの場合：edge://settings/help。Firefoxの場合：メニュー → ヘルプ → Firefox について。

修正方法8：DNSキャッシュをフラッシュする

古いDNS情報のせいで、そのサイトをもうTLSで提供していない古いサーバーにブラウザが向かうことがあります。DNSキャッシュをフラッシュすると、名前解決がやり直されます。

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

フラッシュ後、DNS RobotのDNS確認を使用してドメインが正しいIPに解決されていることを確認してください。IPアドレスが正しくない場合、Webサイトがホスティングプロバイダーを変更し、DNSがまだ完全に伝播していない可能性があります。

修正方法9：システムの日付と時刻を確認する

時計のずれは通常、別のエラー NET::ERR_CERT_DATE_INVALID（「時計が進んでいます」または「時計が遅れています」）として表示されます。証明書は2つの日付の間でしか有効でないためです。それでも10秒で確認できるので、念のため除外しておきましょう：

• Windows： 設定 → 時刻と言語 → 日付と時刻 → 「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」をオンにする
• Mac： システム設定 → 一般 → 日付と時刻 → 「日付と時刻を自動的に設定」をオンにする
• Linux： sudo timedatectl set-ntp true を実行してNTP同期を有効にする

修正方法10：SSL状態をクリアする（Windows）

多くの解説記事は、Windowsのインターネット オプションにある SSL 状態のクリア（Clear SSL state。inetcpl.cpl → コンテンツ タブ → SSL 状態のクリア）を勧めています。これが消去するのはWindows自身のTLSライブラリのセッションキャッシュで、Windowsの通信機能を使うアプリが利用するものです。ChromeとEdgeは独自のTLSライブラリで動いているため、この操作で状況が変わることはほとんどありません。

ブラウザ側で同じことをする方法はもっと簡単です。ブラウザのウィンドウをすべて閉じ（システムトレイにバックグラウンドで動くChromeが残っていないかも確認）、もう一度開いてください。これでキャッシュされたTLSセッションがすべて破棄されます。完全に再起動してもエラーが消えない場合は、次の方法に進んでください。

修正方法11：ネットワーク設定をリセットする（最終手段）

ほかの方法でも解決しない場合は、ネットワークスタックをリセットします。Windowsでは、以下のコマンドがWinsockとTCP/IPをリセットし、手動で設定した固定IPアドレスやDNSサーバーも消えます。macOSとLinuxでは、DNSキャッシュをフラッシュするか、ネットワークサービスを再起動するだけです。

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

ERR_SSL_PROTOCOL_ERROR の直し方（Webサイト管理者向け）

多くの訪問者からERR_SSL_PROTOCOL_ERRORが報告される場合、問題はサーバー側にあります。よくあるのは、ポート443が平文のHTTPで応答しているか、別のプログラムがそのポートを使っているケースです。証明書の問題はそれぞれ別のエラーとして表示されますが、ついでに確認しておきましょう。（証明書と秘密鍵が一致しない場合、サーバーは新しい設定をそもそも読み込みません。変更後は nginx -t または apachectl configtest で確認してください。）

SSL証明書を確認する

最初のステップは、SSL証明書が有効で、適切にインストールされ、期限が切れていないことを確認することです。DNS RobotのSSLチェッカーを使用して、証明書のステータス、有効期限、発行者、証明書チェーンを即座に確認できます。

次の証明書の問題は、ERR_SSL_PROTOCOL_ERRORではなくそれぞれ別のエラーを表示しますが、確認のついでに直しておきましょう：

• 期限切れの証明書（NET::ERR_CERT_DATE_INVALID） — Let's Encryptの証明書の有効期間は90日（2027年2月からは64日）なので、更新は自動で行う必要があります。自動更新に失敗すると（certbotのタイマーが動いていない、DNSチャレンジが壊れているなど）、証明書は気づかないうちに期限切れになります。
• ドメインの不一致（NET::ERR_CERT_COMMON_NAME_INVALID） — 証明書が example.com 用に発行されているのに、サイトが www.example.com で提供されている（またはその逆）。証明書は正確なドメインに一致するか、ワイルドカード（*.example.com）を含む必要があります。
• 自己署名証明書（NET::ERR_CERT_AUTHORITY_INVALID） — 開発用なら問題ありませんが、本番環境ではブラウザに信頼されません。
• 失効した証明書（NET::ERR_CERT_REVOKED） — 鍵の漏洩や誤発行のため、認証局が証明書を失効させた状態です。
• ホスト名に合わない証明書（NET::ERR_CERT_COMMON_NAME_INVALID） — 複数のサイトが1つのIPアドレスを共有しているのに、サーバーがSNI（Server Name Indication）で各サイトの証明書を選んでいない状態です。

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

TLS 1.2 と TLS 1.3 を有効にする

最新のブラウザはすべてTLS 1.2以上を要求します。TLS 1.0と1.1は2021年にRFC 8996で正式に非推奨となりました。相手のバージョンを受け入れない側は、TLSアラート70の protocol_version でハンドシェイクを終了します（RFC 8446 §6.2）。TLS 1.0または1.1しかサポートしていないサーバーでは、このエラーではなくERR_SSL_VERSION_OR_CIPHER_MISMATCHが表示されますが、どちらにしても接続できません。TLS 1.3はTLS 1.2の2往復に対して1往復で接続できるので、両方を有効にしてください。

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

TLS設定を更新した後、Webサーバーを再起動し（sudo systemctl restart nginx または sudo systemctl restart apache2）、DNS RobotのSSLチェッカーでプロトコルが有効になっていることを確認してください。

完全な証明書チェーンをインストールする

チェーンが不完全だと、欠けている中間証明書を補えないブラウザやアプリでは証明書エラー（NET::ERR_CERT_AUTHORITY_INVALID）になります。確認のついでに、完全なチェーンをインストールしておきましょう。サーバーは自分の証明書に加えて、それを信頼されたルートにつなぐ中間証明書も送る必要があります。

ほとんどの認証局は「CAバンドル」または「フルチェーン」ファイルを提供しています。Let's Encryptの場合は fullchain.pem（cert.pem だけではなく）を使用してください。他のCAの場合は、そのドキュメントから中間証明書をダウンロードし、自分の証明書と連結してください。

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

HSTS設定を確認する

HSTS（HTTP Strict Transport Security）は、ブラウザにドメインで常にHTTPSを使用するよう指示します。HSTSポリシーのmax-ageを長くしたあとでTLSの設定が壊れると、ブラウザはHTTPにフォールバックできず、訪問者にはクリックして先に進む手段のないエラーページが表示されます。

DNS RobotのHTTPヘッダーチェッカーでHSTSヘッダーを確認してください。非常に長い max-age（2年など）を設定し、証明書が期限切れになった場合、以前サイトを訪問したユーザーはHTTPSにロックされ、代替手段がありません。解決するには、まずSSL証明書を修正してください。そうすれば、ブラウザは再び正常に接続できるようになります。

サーバー設定を確認する

次のサーバー側のミスは、証明書が有効でもハンドシェイクを壊します。もう1つは別のエラーとして表示されます：

• ポート443が平文のHTTPを返している — サイト管理者側の典型的な原因です。nginxで ssl を付けずに listen 443; と書いている（正しくは listen 443 ssl;）か、別のサービスがポート443を使っています。
• 暗号スイートの不一致 — ブラウザが受け入れない暗号スイートしか提供しないサーバーでは、ERR_SSL_VERSION_OR_CIPHER_MISMATCHが表示されます。AES-GCMやChaCha20などの最新のAEAD暗号を使ってください。

外部から openssl s_client -connect example.com:443 -servername example.com </dev/null でテストします。「wrong version number」（OpenSSL）や「tlsv1 alert protocol version」（macOS標準のopenssl）と表示されたら、ポート443はTLSで応答していません。証明書の内容が表示されれば、ハンドシェイクは正常です。

Android での ERR_SSL_PROTOCOL_ERROR

AndroidユーザーはChrome for AndroidおよびWebViewベースのアプリの両方でERR_SSL_PROTOCOL_ERRORに遭遇します。Androidは証明書とネットワーク設定の管理方法がデスクトップとは異なるため、修正方法も若干異なります。

• ネットワークを切り替える — Wi-Fiをオフにしてモバイルデータで試します（またはその逆）。サイトが開けば、そのネットワークがサイトをフィルタリングまたは傍受しています
• プライベート DNSをオフにして試す — 設定 → ネットワークとインターネット → プライベート DNS → 「OFF」（Chromeでも 設定 → プライバシーとセキュリティ → 「セキュア DNS を使用する」をオフ）。広告ブロックやペアレンタルコントロールなどのフィルタリング型DNSサービスは、ブロックしたサイトへの接続を、ハンドシェイクを完了できないサーバーに向けます
• Chromeのデータを消去 — 設定 → アプリ → Chrome → ストレージ → 「キャッシュを削除」（それで解決しない場合は「容量を管理」）
• Chromeを更新 — Playストア → プロフィール アイコン → アプリとデバイスの管理 → Chromeを更新
• ネットワーク認証情報を消去 — 設定 → セキュリティ（新しい機種では「セキュリティの詳細設定」→「暗号化と認証情報」）→「認証情報の消去」。ユーザーがインストールした証明書がすべて削除されます
• 日付と時刻を確認 — 設定 → システム → 日付と時刻 → 自動設定をオン。時計のずれは証明書エラーとして表示されますが、すぐに確認できます
• ネットワーク設定をリセット — 設定 → システム → リセット オプション → Wi-Fiとモバイル ネットワークのリセット（名称はAndroidのバージョンによって異なります）

iPhone・iPad での ERR_SSL_PROTOCOL_ERROR

iPhoneでは、ChromeはERR_SSL_PROTOCOL_ERRORを表示し、Safariはサーバーへの安全な接続を確立できないという趣旨のメッセージ（英語表示: "Safari can't establish a secure connection to the server"）を表示します。原因はパソコンと同じですが、スマホでは設定の場所が異なります：

• ネットワークを切り替える — Wi-Fiをオフにしてモバイルデータで試します。サイトが開けば、Wi-Fiネットワークがサイトをフィルタリングまたは傍受しています
• 心当たりのないVPNやプロファイルを削除 — 「設定」→「一般」→「VPNとデバイス管理」。独自の証明書やVPNをインストールするプロファイルはHTTPS通信を傍受できます
• iCloud プライベートリレーをオフにして試す — 「設定」→［ユーザ名］→「iCloud」→「プライベートリレー」をオフにして再試行
• スクリーンタイムの制限を確認 — 「設定」→「スクリーンタイム」→「コンテンツとプライバシーの制限」から、Webコンテンツの設定を確認します。ブロックされたサイトは表示されずにエラーになります
• 時計を自動設定にする — 「設定」→「一般」→「日付と時刻」→「自動設定」をオン

他のブラウザでの ERR_SSL_PROTOCOL_ERROR

ERR_SSL_PROTOCOL_ERROR はChromium固有のエラーコードです。他のブラウザでは、同じSSLハンドシェイクの失敗に対して異なるエラーメッセージが表示されます。

すべてのブラウザで同時にエラーが表示される場合、問題はあなたのシステム（ウイルス対策ソフトのHTTPSスキャン、VPNやプロキシ、ネットワーク）か、サーバー側（ポート443がTLSを正しく提供していない）にあります。1つのブラウザだけで失敗する場合は、そのブラウザの拡張機能とキャッシュデータを確認してください。

関連するSSL/TLSエラーコード

ChromeにはSSL関連のエラーコードがいくつかあります。すべて異なるTLSハンドシェイクまたは証明書の問題を示しています。

すべてのSSLエラーについて、DNS RobotのSSLチェッカーを使用して問題を素早く診断できます — 証明書のステータス、チェーンの完全性、サポートされているTLSバージョン、有効期限を1回のスキャンで確認できます。

画面に「〇〇 ではサポートされていないプロトコルが使用されています。」や「サポートされていないプロトコルです」と表示されている場合、それはこのエラーではなくERR_SSL_VERSION_OR_CIPHER_MISMATCHです。ERR_SSL_VERSION_OR_CIPHER_MISMATCHの直し方を参照してください。

画面に「example.com により途中で接続が切断されました。」（ERR_CONNECTION_CLOSED）と表示されている場合は、ハンドシェイクが壊れたのではなく、接続が途中で切られています。その場合はERR_CONNECTION_CLOSEDを参照してください。