ERR_SSL_PROTOCOL_ERROR: Cara Mengatasi di Chrome & Localhost

Apa Itu ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR berarti koneksi aman terputus saat handshake TLS, sebelum browser Anda sempat memuat apa pun. Chrome dan Edge menampilkannya sebagai “Situs ini tidak dapat menyediakan sambungan aman. example.com mengirimkan tanggapan yang tidak valid.” Jika alamatnya localhost, server pengembangan Anda hampir pasti hanya berbicara HTTP biasa: buka http://localhost sebagai gantinya (lihat bagian untuk developer di bawah).

Setiap koneksi HTTPS diawali handshake TLS, tempat browser dan server menyepakati versi protokol (TLS 1.2 atau 1.3) dan cipher, lalu bertukar sertifikat. ERR_SSL_PROTOCOL_ERROR berarti negosiasi itu gagal: pihak seberang menjawab dengan sesuatu yang bukan TLS yang valid, atau menolak handshake dengan cara yang tidak bisa dikenali browser.

Error ini muncul sebelum permintaan HTTP apa pun dikirim, jadi bukan kode status HTTP. Daftar error Chromium mendefinisikannya sebagai error -107 dengan satu baris, “An SSL protocol error occurred”: error serba-guna untuk handshake yang rusak, berbeda dari error spesifik -113 (“tidak ada versi protokol atau cipher yang sama”).

Tampilan ERR_SSL_PROTOCOL_ERROR

Chrome dan browser berbasis Chromium lainnya menampilkan error ini sebagai peringatan layar penuh dengan pesan “Situs ini tidak dapat menyediakan sambungan aman”. Di bawahnya tertera kode error yang spesifik. Berikut variasi yang paling sering muncul.

• localhost mengirimkan tanggapan yang tidak valid (dalam bahasa Inggris “localhost sent an invalid response”) — versi yang dilihat developer: https:// dibuka pada server lokal yang hanya berbicara HTTP biasa
• ERR_SSL_PROTOCOL_ERROR — kode error yang dicetak Chrome dengan huruf kecil di bawah pesan
• net::ERR_SSL_PROTOCOL_ERROR — kode error internal lengkap yang tampil di konsol Chrome DevTools
• Situs ini tidak dapat menyediakan sambungan aman — pesan judul yang dilihat pengguna di Chrome
• [domain] mengirimkan tanggapan yang tidak valid — teks error terperinci yang ditampilkan Chrome di bawah judul
• ERR_SSL_PROTOCOL_ERROR di semua browser — ketika error muncul sekaligus di Chrome, Edge, Brave, dan Opera (menandakan masalah di sisi server atau seluruh sistem, bukan bug khusus satu browser)

Apa Penyebab ERR_SSL_PROTOCOL_ERROR?

Error ini punya penyebab di sisi klien (perangkat Anda) maupun sisi server (website). Langkah pertama adalah mengetahui di sisi mana masalahnya. Jika error muncul di setiap website, masalahnya ada di sisi Anda. Jika hanya muncul di satu website tertentu, penyebabnya kemungkinan besar di server.

• HTTPS dikirim ke server yang berbicara HTTP — kasus yang paling banyak dicari: https://localhost pada server pengembangan, atau situs yang port 443-nya tidak disiapkan untuk TLS. Browser memulai handshake dan menerima teks biasa, yang dilaporkan Chrome sebagai “mengirimkan tanggapan yang tidak valid”.
• Pemindaian SSL/HTTPS antivirus — perangkat lunak keamanan yang menyadap HTTPS (Avast, Kaspersky, Bitdefender, ESET) menyisipkan diri ke handshake dan bisa merusaknya di semua situs sekaligus.
• VPN atau proxy — VPN dan proxy perusahaan yang memeriksa lalu lintas HTTPS dapat merusak handshake, terutama tepat setelah berpindah jaringan.
• Jaringan yang memfilter situs — filter ISP, sekolah, kantor, dan negara, serta pemblokir berbasis DNS, sengaja merusak handshake untuk situs yang mereka blokir. Cirinya: situs dimuat dengan data seluler atau Wi-Fi lain.
• Pengaturan TLS server yang rusak — port 443 menjawab dengan HTTP biasa (blok server di 443 tanpa TLS diaktifkan), atau program lain mendengarkan di port 443.
• Ekstensi browser — add-on privasi, pemblokir iklan, dan keamanan yang menulis ulang permintaan HTTPS dapat mengganggu handshake.
• Status browser yang usang — data sesi tersimpan yang tidak lagi cocok dengan server.
• Sering tertukar dengan error ini — server yang masih memakai TLS 1.0 atau 1.1 menampilkan ERR_SSL_VERSION_OR_CIPHER_MISMATCH (“menggunakan protokol yang tidak didukung”), sertifikat kedaluwarsa, salah nama, atau self-signed serta jam yang salah menampilkan error sertifikat (NET::ERR_CERT_…), dan masalah QUIC (HTTP/3) menampilkan ERR_QUIC_PROTOCOL_ERROR. Lihat ERR_SSL_VERSION_OR_CIPHER_MISMATCH dan “Koneksi Anda tidak pribadi”.

ERR_SSL_PROTOCOL_ERROR di Localhost (Untuk Developer)

localhost mengirimkan tanggapan yang tidak valid. ERR_SSL_PROTOCOL_ERROR hampir selalu berarti Anda membuka https://localhost pada server pengembangan yang hanya berbicara HTTP biasa. Browser memulai handshake TLS, server menjawab dengan teks HTTP biasa, dan Chrome melaporkan jawaban itu sebagai tidak valid. Firefox melaporkan kesalahan yang sama sebagai SSL_ERROR_RX_RECORD_TOO_LONG.

• Gunakan alamat yang dicetak server — ubah https://localhost:3000 menjadi http://localhost:3000. Server pengembangan Next.js, Vite, React, Django, Rails, dan Flask melayani HTTP kecuali Anda mengaktifkan HTTPS
• Periksa port — https://localhost tanpa port berarti port 443. Jika aplikasi Anda berjalan di 3000 atau 5173, permintaan sampai ke program lain, atau tidak ke mana-mana
• Chrome terus beralih ke https:// — pengalihan yang tersimpan dari aplikasi sebelumnya di port yang sama bisa menyebabkannya: hapus gambar dan file dalam cache atau uji di jendela Samaran. (Chrome versi sebelum 132 juga bisa menyimpan entri HSTS untuk localhost, yang Anda hapus di chrome://net-internals/#hsts pada Delete domain security policies)
• Anda butuh HTTPS secara lokal (callback OAuth, cookie aman) — next dev --experimental-https membuat sertifikat tepercaya lokal dengan mkcert; Vite menerima opsi sertifikat di server.https, atau @vitejs/plugin-basic-ssl untuk sertifikat self-signed cepat; di tempat lain, mkcert -install && mkcert localhost 127.0.0.1 membuat file yang bisa dimuat server Anda
• Sertifikat self-signed memberi error yang berbeda — NET::ERR_CERT_AUTHORITY_INVALID, bukan yang ini. Klik Lanjutan → Lanjutkan ke localhost (tidak aman), atau lebih baik, pakai sertifikat mkcert (flag lama allow-insecure-localhost sudah kedaluwarsa)

Cara Memperbaiki ERR_SSL_PROTOCOL_ERROR (Untuk Pengguna)

Mulailah dari Perbaikan 1: dalam dua menit, langkah ini memberi tahu apakah masalahnya ada di browser, perangkat atau jaringan Anda, atau di situsnya. Setelah itu telusuri daftar ke bawah.

Perbaikan 1: Coba Mode Samaran dan Jaringan Lain

Jendela Samaran dimulai tanpa cookie, tanpa cache, dan tanpa ekstensi (kecuali Anda mengizinkannya di sana). Buka situs di jendela Samaran (Ctrl+Shift+N di Chrome dan Edge, Ctrl+Shift+P di Firefox), lalu di jaringan lain, misalnya data seluler ponsel Anda.

Jika dimuat di mode Samaran, penyebabnya ada di browser: ekstensi atau data usang (Perbaikan 4 dan 5). Jika hanya dimuat di jaringan lain, jaringan Anda atau VPN atau proxy memfilter atau menyadapnya (Perbaikan 3). Jika gagal di mana-mana, uji situs dengan Cek SSL: jika itu juga gagal, hanya pemilik situs yang bisa memperbaikinya.

Perbaikan 2: Nonaktifkan Pemindaian SSL/HTTPS Antivirus

Banyak antivirus (Avast, Kaspersky, Bitdefender, ESET, Norton) memiliki fitur “pemindaian HTTPS” atau “inspeksi SSL” yang menyadap koneksi terenkripsi dengan bertindak sebagai proxy man-in-the-middle. Ketika fitur ini salah menangani handshake sebuah situs, semua browser di komputer gagal pada situs itu.

Cari pengaturan bernama Web Shield, HTTPS Scanning, SSL Scanning, atau Encrypted connections scanning di antivirus Anda dan nonaktifkan sementara. Jika error hilang, Anda bisa menambahkan domain yang terdampak ke daftar pengecualian antivirus.

Perbaikan 3: Nonaktifkan VPN atau Proxy

VPN dan proxy HTTP berada di antara browser Anda dan server web. Sebagian VPN memeriksa lalu lintas HTTPS atau mengarahkan koneksi melalui server dengan TLS yang rusak. Proxy perusahaan sering memakai penyadapan SSL (mirip pemindaian HTTPS antivirus) yang dapat merusak handshake TLS.

Putuskan VPN Anda sementara dan coba muat situs. Jika berhasil tanpa VPN, masalahnya ada pada cara VPN Anda menangani koneksi SSL. Coba server VPN lain atau hubungi penyedia VPN Anda.

Perbaikan 4: Nonaktifkan Ekstensi Browser

Ekstensi yang memfilter atau mengalihkan lalu lintas, seperti ekstensi VPN dan proxy serta add-on keamanan, dapat merusak koneksi aman.

Buka chrome://extensions/, matikan semua ekstensi, lalu muat ulang halaman. Jika error hilang, aktifkan kembali satu per satu untuk menemukan penyebabnya.

Perbaikan 5: Bersihkan Cache dan Cookie Browser

Cookie atau data cache yang usang kadang mengganggu, dan membersihkannya hanya butuh satu menit.

• Langkah 1: Tekan Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) untuk membuka Hapus data penjelajahan
• Langkah 2: Pilih Lainnya → Semua sebagai rentang waktu
• Langkah 3: Centang Cookie dan data situs lainnya dan Gambar dan file dalam cache
• Langkah 4: Klik Hapus data (Hapus dari perangkat ini jika Anda belum login) dan mulai ulang Chrome

Untuk satu situs, buka chrome://settings/content/all, cari domainnya, lalu hapus datanya.

Perbaikan 6: Singkirkan QUIC (HTTP/3) sebagai Penyebab

Chrome mencoba QUIC (HTTP/3 lewat UDP) berdampingan dengan koneksi TCP biasa dan kembali ke TCP saat QUIC gagal, sehingga QUIC jarang menyebabkan ERR_SSL_PROTOCOL_ERROR. Jika halaman atau DevTools menampilkan ERR_QUIC_PROTOCOL_ERROR sebagai gantinya, mematikan QUIC adalah solusinya (lihat ERR_QUIC_PROTOCOL_ERROR):

• Langkah 1: Ketik chrome://flags/#enable-quic di bilah alamat
• Langkah 2: Cari Experimental QUIC protocol
• Langkah 3: Ubah dari Default menjadi Disabled
• Langkah 4: Klik Relaunch untuk memulai ulang Chrome

Halaman tetap dimuat tanpa QUIC, lewat HTTP/2 di atas TCP; aktifkan kembali QUIC setelah jaringan atau situs diperbaiki.

Perbaikan 7: Perbarui Browser Anda

Versi browser lama bisa kekurangan fitur TLS dan cipher yang diharapkan situs modern, dan pembaruan memperbaiki bug TLS.

Perbarui Chrome: buka chrome://settings/help atau Menu → Bantuan → Tentang Google Chrome. Chrome mengunduh pembaruan secara otomatis tetapi memerlukan restart untuk menerapkannya. Untuk Edge: edge://settings/help. Untuk Firefox: Menu → Help → About Firefox.

Perbaikan 8: Bersihkan Cache DNS

DNS yang usang bisa mengarahkan browser ke server lama yang tidak lagi melayani situs lewat TLS. Membersihkan cache DNS memaksa pencarian baru.

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

Setelah dibersihkan, pastikan domain teresolusi ke IP yang benar dengan alat Cek DNS DNS Robot. Jika alamat IP tampak salah, situs mungkin pindah penyedia hosting dan DNS belum sepenuhnya terpropagasi.

Perbaikan 9: Periksa Tanggal dan Waktu Sistem

Jam yang salah biasanya muncul sebagai error lain, NET::ERR_CERT_DATE_INVALID (“Setelan jam terlalu cepat” atau “Setelan waktu Anda terlalu lambat”), karena sertifikat hanya berlaku di antara dua tanggal. Memastikannya hanya butuh sepuluh detik:

• Windows: Settings → Time & Language → Date & time → aktifkan “Set time automatically” dan “Set time zone automatically”
• Mac: Pengaturan Sistem → Umum → Tanggal & Waktu → aktifkan “Atur waktu dan tanggal secara otomatis”
• Linux: Jalankan sudo timedatectl set-ntp true untuk mengaktifkan sinkronisasi NTP

Perbaikan 10: Bersihkan Status SSL (Windows)

Banyak panduan menyarankan Clear SSL state di Internet Options Windows (inetcpl.cpl → Content → Clear SSL state). Ini membersihkan cache sesi dari pustaka TLS bawaan Windows, yang dipakai aplikasi berbasis jaringan Windows. Chrome dan Edge memakai pustaka TLS sendiri, sehingga ini jarang mengubah apa pun bagi keduanya.

Padanannya untuk browser lebih sederhana: tutup semua jendela browser (periksa system tray untuk Chrome yang berjalan di latar belakang) lalu buka lagi. Ini membuang semua sesi TLS yang tersimpan. Jika error bertahan setelah restart penuh, lanjut ke perbaikan berikutnya.

Perbaikan 11: Reset Pengaturan Jaringan (Langkah Terakhir)

Jika tidak ada yang berhasil, reset tumpukan jaringan Anda. Di Windows, perintah ini mereset Winsock dan TCP/IP, termasuk alamat IP statis dan server DNS yang Anda atur manual; di macOS dan Linux, perintahnya hanya membersihkan cache DNS atau memulai ulang layanan jaringan.

# 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

Cara Memperbaiki ERR_SSL_PROTOCOL_ERROR (Untuk Pemilik Website)

Jika banyak pengunjung melaporkan ERR_SSL_PROTOCOL_ERROR, masalahnya ada di server: biasanya port 443 menjawab dengan HTTP biasa, atau program lain menempati port itu. Masalah sertifikat menampilkan error sendiri, tetapi periksa sekalian. (Sertifikat dan kunci yang tidak cocok membuat server tidak memuat konfigurasi baru sama sekali: periksa dengan nginx -t atau apachectl configtest setelah mengubah.)

Periksa Sertifikat SSL Anda

Langkah pertama adalah memastikan sertifikat SSL Anda valid, terpasang dengan benar, dan belum kedaluwarsa. Gunakan Cek SSL DNS Robot untuk langsung melihat status sertifikat, tanggal kedaluwarsa, penerbit, dan rantai sertifikat.

Masalah sertifikat berikut menampilkan error sendiri, bukan ERR_SSL_PROTOCOL_ERROR, tetapi perbaiki sekalian:

• Sertifikat kedaluwarsa (NET::ERR_CERT_DATE_INVALID) — sertifikat Let's Encrypt berlaku 90 hari (64 hari mulai Februari 2027), jadi perpanjangan harus berjalan otomatis; jika gagal (timer certbot tidak berjalan, tantangan DNS rusak), sertifikat kedaluwarsa tanpa disadari.
• Domain salah (NET::ERR_CERT_COMMON_NAME_INVALID) — sertifikat diterbitkan untuk example.com tetapi situs dilayani di www.example.com (atau sebaliknya). Sertifikat harus cocok dengan domain yang tepat atau mencakup wildcard (*.example.com).
• Sertifikat self-signed (NET::ERR_CERT_AUTHORITY_INVALID) — tidak masalah untuk development, tetapi tidak pernah dipercaya browser di produksi.
• Sertifikat dicabut (NET::ERR_CERT_REVOKED) — certificate authority mencabutnya setelah kunci bocor atau salah terbit.
• Sertifikat salah untuk nama tersebut (NET::ERR_CERT_COMMON_NAME_INVALID) — beberapa situs berbagi satu alamat IP dan server tidak memakai SNI (Server Name Indication) untuk memilih sertifikat tiap situs.

# 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

Aktifkan TLS 1.2 dan TLS 1.3

Semua browser modern mensyaratkan minimal TLS 1.2: TLS 1.0 dan 1.1 resmi dinyatakan usang lewat RFC 8996 pada 2021. Pihak yang menolak versi pihak lain mengakhiri handshake dengan alert TLS 70, protocol_version (RFC 8446 §6.2). Server yang hanya mendukung TLS 1.0 atau 1.1 menampilkan ERR_SSL_VERSION_OR_CIPHER_MISMATCH, bukan error ini, tetapi tetap gagal. TLS 1.3 tersambung dalam satu putaran, bukan dua seperti TLS 1.2: aktifkan keduanya.

# 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

Setelah memperbarui konfigurasi TLS, mulai ulang web server (sudo systemctl restart nginx atau sudo systemctl restart apache2) dan uji dengan Cek SSL DNS Robot untuk memastikan protokolnya aktif.

Pasang Rantai Sertifikat yang Lengkap

Rantai yang tidak lengkap tampil sebagai error sertifikat (NET::ERR_CERT_AUTHORITY_INVALID) di browser dan aplikasi yang tidak bisa melengkapi sertifikat intermediate yang hilang, jadi pasang rantai lengkap sekalian saat memeriksa. Server Anda harus mengirim sertifikat Anda beserta sertifikat intermediate yang menghubungkannya ke root tepercaya.

Sebagian besar certificate authority menyediakan file “CA bundle” atau “full chain”. Untuk Let's Encrypt, gunakan fullchain.pem (bukan hanya cert.pem). Untuk CA lain, unduh sertifikat intermediate dari dokumentasi mereka dan gabungkan dengan sertifikat Anda.

# 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

Periksa Konfigurasi HSTS

HSTS (HTTP Strict Transport Security) memerintahkan browser untuk selalu memakai HTTPS bagi domain Anda. Jika kebijakan HSTS Anda memiliki max-age panjang dan pengaturan TLS Anda kemudian rusak, browser tidak bisa kembali ke HTTP: pengunjung melihat halaman error tanpa cara untuk melanjutkan.

Periksa header HSTS Anda dengan alat Cek HTTP Header DNS Robot. Jika Anda mengatur max-age yang sangat panjang (misalnya 2 tahun) dan sertifikat Anda kedaluwarsa, pengguna yang pernah mengunjungi situs Anda terkunci pada HTTPS tanpa jalan kembali. Untuk memperbaikinya, perbaiki dulu sertifikat SSL Anda, lalu browser akan tersambung normal lagi.

Verifikasi Konfigurasi Server

Kesalahan server ini merusak handshake meski sertifikatnya valid, dan satu lagi menampilkan error yang berbeda:

• Port 443 melayani HTTP biasa — penyebab klasik di sisi pemilik: di nginx, listen 443; tanpa ssl (harus listen 443 ssl;), atau layanan lain terikat ke port 443.
• Cipher suite tidak cocok — server yang hanya menawarkan cipher yang ditolak browser menampilkan ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Gunakan cipher AEAD modern (AES-GCM, ChaCha20).

Uji dari luar dengan openssl s_client -connect example.com:443 -servername example.com </dev/null: “wrong version number” (OpenSSL) atau “tlsv1 alert protocol version” (openssl bawaan macOS) berarti port 443 tidak berbicara TLS, dan tampilan sertifikat berarti handshake berfungsi.

ERR_SSL_PROTOCOL_ERROR di Android

Pengguna Android menemui ERR_SSL_PROTOCOL_ERROR baik di Chrome untuk Android maupun di aplikasi berbasis WebView. Perbaikannya sedikit berbeda dari desktop karena Android mengelola sertifikat dan pengaturan jaringan dengan cara lain.

• Ganti jaringan — matikan Wi-Fi dan coba data seluler (atau sebaliknya). Jika situs dimuat, jaringan memfilter atau menyadapnya
• Matikan DNS Pribadi untuk pengujian — Setelan → Jaringan & internet → DNS Pribadi → Nonaktif (dan di Chrome: Setelan → Privasi dan keamanan → Gunakan DNS aman). Layanan DNS yang memfilter (pemblokir iklan, kontrol orang tua) mengarahkan situs yang diblokirnya ke server yang tidak bisa menyelesaikan handshake
• Hapus data Chrome — Setelan → Aplikasi → Chrome → Penyimpanan & cache → Hapus cache (lalu “Manage space” jika belum membantu)
• Perbarui Chrome — Play Store → foto profil Anda → Kelola aplikasi & perangkat → perbarui Chrome
• Hapus kredensial jaringan — Setelan → Keamanan (di ponsel yang lebih baru: Setelan keamanan lainnya → Enkripsi & kredensial) → Hapus kredensial. Ini menghapus semua sertifikat yang dipasang pengguna
• Periksa tanggal dan waktu — Setelan → Sistem → Tanggal & waktu → otomatis. Jam yang salah menampilkan error sertifikat, tetapi cepat disingkirkan
• Reset pengaturan jaringan — Setelan → Sistem → Opsi reset, lalu reset Wi-Fi dan jaringan seluler (namanya berbeda menurut versi Android)

ERR_SSL_PROTOCOL_ERROR di iPhone dan iPad

Di iPhone, Chrome menampilkan ERR_SSL_PROTOCOL_ERROR dan Safari menyatakan tidak dapat membuat sambungan aman ke server (“can't establish a secure connection to the server”). Penyebabnya sama dengan di komputer; hanya tombolnya yang berada di tempat lain:

• Ganti jaringan — matikan Wi-Fi dan coba data seluler. Jika situs dimuat, jaringan Wi-Fi memfilter atau menyadapnya
• Hapus VPN dan profil yang tidak Anda kenal — Pengaturan → Umum → Manajemen VPN & Perangkat. Profil yang memasang sertifikat atau VPN sendiri dapat menyadap HTTPS
• Uji tanpa Relai Pribadi iCloud — Pengaturan → [nama Anda] → iCloud → Relai Pribadi → matikan, lalu coba lagi
• Periksa batasan Durasi Layar — Pengaturan → Durasi Layar → Pembatasan Konten & Privasi, lalu pengaturan konten web. Situs yang diblokir gagal alih-alih dimuat
• Setel jam otomatis — Pengaturan → Umum → Tanggal & Waktu → Atur Secara Otomatis

ERR_SSL_PROTOCOL_ERROR di Browser Lain

ERR_SSL_PROTOCOL_ERROR adalah kode error khusus Chromium. Browser lain menampilkan pesan error berbeda untuk kegagalan handshake SSL yang sama.

Jika error muncul di semua browser sekaligus, masalahnya ada di sistem Anda (pemindaian HTTPS antivirus, VPN atau proxy, jaringan Anda) atau di server (port 443 tidak melayani TLS dengan benar). Jika hanya satu browser yang gagal, periksa ekstensi dan data tersimpan browser itu.

Kode Error SSL/TLS Terkait

Chrome memiliki beberapa kode error terkait SSL. Semuanya menunjukkan masalah handshake TLS atau sertifikat yang berbeda.

Untuk semua error SSL, Anda bisa cepat mendiagnosis masalah dengan Cek SSL DNS Robot — alat ini menampilkan status sertifikat, kelengkapan rantai, versi TLS yang didukung, dan tanggal kedaluwarsa dalam satu pemindaian.

Jika halaman Anda menyatakan situs “menggunakan protokol yang tidak didukung”, yang Anda alami adalah ERR_SSL_VERSION_OR_CIPHER_MISMATCH, bukan error ini: lihat cara memperbaiki ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Jika halaman justru menyatakan “example.com tiba-tiba menutup sambungan” (ERR_CONNECTION_CLOSED), koneksi diputus, bukan rusak. Untuk kasus itu lihat ERR_CONNECTION_CLOSED.