ERR_SSL_PROTOCOL_ERROR の直し方（Chrome・Edge・全ブラウザ対応）

ERR_SSL_PROTOCOL_ERROR とは？

ERR_SSL_PROTOCOL_ERROR は、ブラウザとWebサーバー間のSSL/TLSハンドシェイクが失敗したときに表示されるブラウザエラーです。ブラウザが安全な暗号化接続を確立できないため、安全でないチャネルでデータが送信されるのを防ぐためにページ全体をブロックします。

すべてのHTTPS接続はTLSハンドシェイクから始まります。これはブラウザとサーバーが暗号化プロトコル（TLS 1.2または1.3）に合意し、証明書を交換し、相互の身元を確認するネゴシエーションです。ERR_SSL_PROTOCOL_ERROR は、このネゴシエーションが完了する前に中断されたことを意味します。

このエラーはサーバー側のHTTPステータスコードではありません — HTTPリクエストが送信される前に、ブラウザ内部で発生します。Chromiumの内部エラーコードは net::ERR_SSL_PROTOCOL_ERROR（エラーコード -107）で、Chromiumのソースコードではセキュリティパラメータの合意に失敗したことと定義されています。

ERR_SSL_PROTOCOL_ERROR の表示画面

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

• 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サイトでのみ表示される場合は、サーバー側の問題である可能性が高いです。

• システムの日付/時刻が正しくない — ユーザー側の最も一般的な原因です。SSL証明書は時間に敏感で、コンピュータの時計がわずか数分ずれているだけでも証明書の検証が失敗し、TLSハンドシェイクが中断されます。

• SSL証明書の期限切れまたは無効 — WebサイトのSSL証明書が期限切れ、自己署名、または別のドメイン用に発行されたものです。当サイトのSSL Checkerで証明書を即座に確認できます。

• 古いTLSプロトコル — サーバーが非推奨のプロトコル（SSL 3.0、TLS 1.0、TLS 1.1）のみをサポートしており、最新のブラウザが使用を拒否しています。Chrome、Edge、Firefoxは2020年にTLS 1.0/1.1のサポートを終了しました。

• ブラウザのSSL状態の破損 — ブラウザが古いSSLセッションデータ、HSTS設定、または現在の接続試行と競合する証明書情報をキャッシュしています。

• QUICプロトコルの競合 — Chromeの実験的なQUICプロトコル（HTTP/3）が、適切にサポートしていないサーバーとのTLSネゴシエーションを妨げることがあります。

• ウイルス対策ソフトのSSL/HTTPSスキャン — HTTPS通信を傍受するセキュリティソフト（Avast、Kaspersky、Bitdefender、ESET）が、独自の証明書を接続に挿入することでTLSハンドシェイクを破壊することがあります。

• 不完全な証明書チェーン — サーバーがSSL証明書は送信するものの、ルート認証局まで信頼の連鎖を検証するために必要な中間証明書を送信していません。

• VPNまたはプロキシの干渉 — HTTPS通信を検査するVPNや企業プロキシがTLSハンドシェイクを破壊することがあります。特にネットワークを切り替えた際に発生しやすいです。

• ブラウザ拡張機能 — HTTPSリクエストを変更するプライバシー拡張機能、広告ブロッカー、セキュリティアドオンがSSLハンドシェイクを妨げることがあります。

• ファイアウォールがポート443をブロック — ネットワークファイアウォールまたはルーターが標準のHTTPSポート（443）をブロックしており、TLSハンドシェイクの完了を妨げています。

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

ブラウジング中にこのエラーが表示された場合は、最も簡単な修正方法から試してください。ほとんどのケースは、以下の最初の3つの方法で解決します。

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

システム時計が正しくないことは、ERR_SSL_PROTOCOL_ERROR の最も一般的な原因です。SSL証明書には有効期間（Not Before / Not After の日付）があり、システムの時刻がこの範囲外の場合、ハンドシェイクが失敗します。厳密な証明書検証では、数分のずれでも問題が発生することがあります。

コンピュータが自動的に時刻を同期するように設定されていることを確認してください。

• Windows： 設定 → 時刻と言語 → 日付と時刻 → 「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」をオンにする

• Mac： システム設定 → 一般 → 日付と時刻 → 「日付と時刻を自動的に設定」をオンにする

• Linux： sudo timedatectl set-ntp true を実行してNTP同期を有効にする

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

WindowsはブラウザとはSSL証明書キャッシュを管理しています。このキャッシュ内の古いまたは破損したエントリが、ブラウザのキャッシュをクリアした後でも持続的なERR_SSL_PROTOCOL_ERRORを引き起こすことがあります。

WindowsでSSL状態をクリアするには：インターネットオプションを開き（スタートメニューで検索するか、「ファイル名を指定して実行」で inetcpl.cpl と入力）→ コンテンツ タブをクリック → SSL状態のクリア をクリック → OKをクリックします。その後、ブラウザを再起動してください。

修正方法3：ブラウザのキャッシュとCookieをクリアする

破損したキャッシュデータや古いHSTS（HTTP Strict Transport Security）エントリが、ブラウザに古いパラメータでの接続を強制し、SSLプロトコルエラーを引き起こすことがあります。

• ステップ1： Chromeの設定 → プライバシーとセキュリティ → 閲覧履歴データの削除を開く（または Ctrl+Shift+Delete を押す）

• ステップ2： 詳細設定 タブに切り替える

• ステップ3： 期間を 全期間 に設定する

• ステップ4： キャッシュされた画像とファイル、Cookieと他のサイトデータ、ホストされたアプリデータ にチェックを入れる

• ステップ5： データを削除 をクリックしてChromeを再起動する

特定のサイトのみデータをクリアすることもできます。chrome://settings/content/all にアクセス → ドメインを検索 → ゴミ箱アイコンをクリックしてください。

修正方法4：QUICプロトコルを無効にする

Chromeはデフォルトで、より高速な接続のためにQUICプロトコル（UDP上のHTTP/3）を使用しています。しかし、一部のサーバー、ファイアウォール、ネットワーク機器はQUICを適切に処理できず、SSLハンドシェイクの失敗を引き起こすことがあります。QUICを無効にすると、Chromeは標準のTCPベースのTLS接続を使用するようになります。

• ステップ1： アドレスバーに chrome://flags/#enable-quic と入力する

• ステップ2： Experimental QUIC protocol を見つける

• ステップ3： Default から Disabled に変更する

• ステップ4： Relaunch をクリックしてChromeを再起動する

QUICを無効にした後にエラーが消えた場合、問題はサーバーのHTTP/3実装またはネットワークがUDPポート443をブロックしていることにあります。QUICを無効のままにしても悪影響はありません — ページは標準のHTTPS（TCP上のHTTP/2）で読み込まれます。

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

Webトラフィックを傍受または変更する拡張機能 — 広告ブロッカー、VPN拡張機能、プライバシーシールド、HTTPS Everywhere — はTLSハンドシェイクを妨げることがあります。一部の拡張機能は独自の証明書を挿入したり、リクエストヘッダーを変更してSSLネゴシエーションを破壊します。

chrome://extensions/ にアクセスし、すべての拡張機能を無効にしてからページを再読み込みしてください。エラーが消えたら、拡張機能を1つずつ有効に戻して原因を特定してください。よくある原因は、uBlock Origin（まれ）、Avast Online Security、Norton Safe Web、HTTPS Everywhereです。

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

多くのウイルス対策ソフト（Avast、Kaspersky、Bitdefender、ESET、Norton）には、中間者プロキシとして動作し暗号化接続を傍受する「HTTPSスキャン」や「SSLインスペクション」機能が含まれています。これにより、特に証明書ピニングや新しいTLS 1.3の機能を使用しているサイトで、TLSハンドシェイクが破壊されることがあります。

ウイルス対策ソフトで Web Shield、HTTPS Scanning、SSL Scanning、暗号化された接続のスキャン などの設定を探し、一時的に無効にしてください。エラーが解決した場合は、影響を受けたドメインをウイルス対策の除外リストに追加できます。

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

古いバージョンのブラウザは、最新のWebサイトが要求するTLSプロトコルや暗号スイートをサポートしていない場合があります。Chromeはセキュリティ要件を定期的に更新しており、例えばChrome 98ではTLS 1.0と1.1のサポートが完全に廃止されました。

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

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

古いDNSレコードが、ブラウザを誤ったサーバーや有効なSSL証明書を持たなくなった古いIPアドレスに誘導することがあります。DNSキャッシュをフラッシュすると、新しいDNSルックアップが強制されます。

# Windows (Command Prompt as Admin)
ipconfig /flushdns

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

# Linux
sudo systemd-resolve --flush-caches

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

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

修正方法9：シークレットモード/プライベートモードを試す

シークレットモードはクリーンなブラウザ状態で起動します — キャッシュデータなし、Cookieなし、拡張機能なし（シークレットモードで明示的に許可した場合を除く）。Webサイトがシークレットモードでは読み込めるが通常モードでは読み込めない場合、問題はブラウザ拡張機能、キャッシュデータ、または破損したブラウザプロファイルが原因です。

シークレットウィンドウを開く：Ctrl+Shift+N（Chrome/Edge）または Ctrl+Shift+P（Firefox）。同じWebサイトにアクセスしてください。読み込めた場合は、ブラウザのキャッシュをクリア（修正方法3）するか、拡張機能を確認（修正方法5）してください。

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

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

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

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

他のすべての方法がうまくいかない場合は、ネットワークスタックをリセットしてください。これにより、すべてのカスタムネットワーク設定がクリアされ、DNS設定、プロキシ構成、ソケット接続を含むすべてがデフォルトに戻ります。

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

# Then restart your computer

# macOS — reset DNS settings
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

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

複数のユーザーからWebサイトでERR_SSL_PROTOCOL_ERRORが報告された場合、問題はサーバー側にあります。最も一般的なサーバー側の原因は、証明書の期限切れ、中間証明書の欠如、古いTLS設定です。

SSL証明書を確認する

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

ERR_SSL_PROTOCOL_ERROR を引き起こす一般的な証明書の問題：

• 期限切れの証明書 — Let's Encryptの証明書は90日ごとに期限が切れます。自動更新に失敗した場合（certbotのcronが実行されていない、DNSチャレンジが壊れている）、証明書は静かに期限切れになります。

• ドメインの不一致 — 証明書が example.com 用に発行されているが、サイトが www.example.com で提供されている（またはその逆）。証明書は正確なドメインに一致するか、ワイルドカード（*.example.com）を含む必要があります。

• 自己署名証明書 — 開発用証明書は本番環境ではブラウザに信頼されません。

• 失効した証明書 — 認証局が証明書を失効させた（キーの漏洩、誤発行、またはドメイン所有権の変更による）。

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

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "(depth|verify)"

# Renew Let's Encrypt certificate
sudo certbot renew --force-renewal

TLS 1.2 と TLS 1.3 を有効にする

すべての最新ブラウザはTLS 1.2以上を要求します。サーバーがTLS 1.0または1.1のみをサポートしている場合、ブラウザは接続を拒否し、ERR_SSL_PROTOCOL_ERRORを表示します。TLS 1.3は最新の標準で、TLS 1.2よりも大幅に高速です — 最大限の互換性とパフォーマンスのために両方を有効にしてください。

# 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 on;

# 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 on

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

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

不完全な証明書チェーンは、ERR_SSL_PROTOCOL_ERRORの一般的ですが診断が難しい原因です。サーバーはSSL証明書だけでなく、証明書を信頼されたルート認証局に接続する中間証明書も送信する必要があります。これがないと、一部のブラウザやデバイスは証明書を検証できません。

ほとんどの認証局は「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が長く設定されており、その後SSL証明書に問題が発生した場合、ブラウザは接続を拒否します — HTTPにフォールバックできず、壊れたHTTPSがERR_SSL_PROTOCOL_ERRORを引き起こします。

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

サーバー設定を確認する

Webサーバーの設定ミスは、有効な証明書があってもERR_SSL_PROTOCOL_ERRORを引き起こすことがあります。一般的なサーバー設定の問題：

• ポートの間違い — SSL/TLSはポート443で動作するべきです。サーバーが異なるポートでリッスンしている場合、ブラウザはハンドシェイクに失敗する可能性があります。

• HTTP/HTTPSの混在 — HTTPSページで一部のリソースをHTTPで提供すると、混在コンテンツの警告が発生し、サブリソースのハンドシェイクが破壊される可能性があります。

• SNI（Server Name Indication）が設定されていない — 複数のドメインが1つのIPアドレスを共有している場合、サーバーは各ドメインに正しい証明書を提供するためにSNIをサポートする必要があります。

• 暗号スイートの不一致 — サーバーがブラウザが受け入れない暗号スイートのみをサポートしています。AES-GCMやChaCha20などの強力な最新の暗号を使用してください。

DNS RobotのHTTP Headers Checkerを使用して、サーバーのレスポンスヘッダーを検査し、SSL設定が正しいヘッダーを送信していることを確認してください。

Android での ERR_SSL_PROTOCOL_ERROR

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

• 日付と時刻を確認 — 設定 → システム → 日付と時刻 → 「日付と時刻の自動設定」と「タイムゾーンの自動設定」を有効にする

• Chromeのデータをクリア — 設定 → アプリ → Chrome → ストレージ → キャッシュを消去（キャッシュで解決しない場合はデータを消去）

• Chromeを更新 — Google Playストアを開く → マイアプリ → Chromeを最新バージョンに更新

• ネットワーク認証情報をクリア — 設定 → セキュリティ → 認証情報をクリア（ユーザーがインストールしたすべての証明書が削除されます）

• ネットワーク設定をリセット — 設定 → システム → リセットオプション → Wi-Fi、モバイル、Bluetoothをリセット

• WebViewアプリの場合 — 開発者は android:usesCleartextTraffic="false" が設定されていること、およびネットワークセキュリティ構成が正しい認証局を信頼していることを確認する必要があります

他のブラウザでの ERR_SSL_PROTOCOL_ERROR

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

すべてのブラウザで同時にエラーが表示される場合、問題はシステム全体（日付/時刻の誤り、ウイルス対策、ネットワーク）またはサーバー側（証明書の期限切れ、TLSの設定ミス）にあります。1つのブラウザでのみ表示される場合は、ブラウザ固有の問題です — そのブラウザのキャッシュとSSL状態をクリアしてみてください。

localhost での ERR_SSL_PROTOCOL_ERROR（開発者向け）

開発者はローカル開発サーバーを実行する際に localhost sent an invalid response. ERR_SSL_PROTOCOL_ERROR に頻繁に遭遇します。これは、ブラウザがHTTPS接続に有効なSSL証明書を期待しているのに対し、localhostは自己署名証明書または証明書なしで動作しているためです。

• ローカル開発にはHTTPを使用する — 特にHTTPSが必要でない限り、https://localhost:3000 を http://localhost:3000 に変更してください

• ローカル証明書を生成する — mkcert を使用してローカルで信頼されるSSL証明書を作成します：mkcert -install && mkcert localhost 127.0.0.1

• Node.js — 開発環境でのみ NODE_TLS_REJECT_UNAUTHORIZED=0 を設定します（本番環境では絶対に使用しないでください）

• Chromeフラグ — chrome://flags/#allow-insecure-localhost にアクセスし、「Allow invalid certificates for resources loaded from localhost」を有効にします

• Next.js / Vite / Webpack — これらのフレームワークは開発証明書を自動生成する --https フラグをサポートしています

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

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

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