Cara Memperbaiki Error ERR_CONNECTION_TIMED_OUT: Panduan Teknis Lengkap
Kesalahan ERR_CONNECTION_TIMED_OUT berarti browser Anda mengirimkan permintaan koneksi ke server jarak jauh tetapi tidak menerima respons dalam jangka waktu yang ditentukan — biasanya 30 detik pada browser berbasis Chromium. Handshake TCP tidak pernah selesai, sehingga browser membatalkan percobaan dan menampilkan kesalahan ini alih-alih halaman yang dimuat.
Ini bukan kegagalan dengan satu penyebab tunggal. Ini dapat berasal dari sisi klien (mesin Anda, jaringan Anda, browser Anda), dari infrastruktur perantara (resolver DNS, proxy, firewall), atau dari sisi server (origin yang kelebihan beban, web server yang salah dikonfigurasi, SSL kedaluwarsa, atau kegagalan routing upstream). Mendiagnosisnya dengan benar memerlukan penelusuran setiap lapisan secara sistematis.
Apa yang Sebenarnya Terjadi Selama Timeout Koneksi
Ketika Anda mengetik URL dan menekan Enter, browser Anda menjalankan urutan yang tepat: resolusi DNS, koneksi TCP (SYN / SYN-ACK / ACK), handshake TLS opsional, kemudian siklus permintaan/respons HTTP. Kesalahan timeout berarti proses terhenti di suatu tempat dalam rantai tersebut — paling umum pada tahap koneksi TCP, sebelum data HTTP apa pun dipertukarkan.
Memahami tahap mana yang gagal memberi tahu Anda di mana harus memfokuskan perbaikan. Kegagalan DNS menghasilkan kode kesalahan yang berbeda (`ERR_NAME_NOT_RESOLVED`). Kegagalan TLS menghasilkan `ERR_SSL_PROTOCOL_ERROR`. Ketika Anda melihat `ERR_CONNECTION_TIMED_OUT` secara khusus, pencarian DNS berhasil, tetapi socket TCP tidak pernah menerima SYN-ACK dari IP target. Hal ini mempersempit kemungkinan secara signifikan.
Penyebab Utama: Mengapa Kesalahan Ini Terjadi
| Kategori | Penyebab Spesifik | Sisi Klien atau Server |
|---|
| — | — | — |
|---|
| Jaringan | Masalah routing ISP, kehilangan paket, tautan yang padat | Klien |
|---|
| DNS | Cache usang, resolver salah, keterlambatan propagasi | Klien |
|---|
| Firewall / Keamanan | Windows Firewall, antivirus, proxy korporat memblokir port 80/443 | Klien |
|---|
| Browser | Cache rusak, ekstensi bermasalah, konfigurasi proxy yang salah | Klien |
|---|
| TCP/IP Stack | Katalog Winsock rusak, pengaturan IP yang salah | Klien |
|---|
| Kelebihan Beban Server | CPU/RAM tinggi, antrean koneksi habis, DDoS | Server |
|---|
| Konfigurasi Web Server | `KeepAliveTimeout` terlalu rendah, `MaxClients` terlampaui, virtual host yang salah dikonfigurasi | Server |
|---|
| Infrastruktur Hosting | Akun ditangguhkan, aturan firewall pada VPS, IP server salah setelah migrasi | Server |
|---|
| CDN / Reverse Proxy | Origin tidak dapat dijangkau dari edge node CDN | Infrastruktur |
|---|
Metode 1: Verifikasi Koneksi Internet Anda di Lapisan Jaringan
Jangan hanya "memeriksa apakah internet berfungsi." Jalankan pengujian terstruktur:
- Ping gateway: Buka Command Prompt dan jalankan `ping 192.168.1.1` (atau IP router Anda). Jika ini gagal, masalahnya ada di antara mesin Anda dan router.
- Ping IP publik secara langsung: Jalankan `ping 8.8.8.8`. Jika ini berhasil tetapi situs web gagal, masalahnya adalah DNS, bukan konektivitas.
- Jalankan traceroute: `tracert google.com` di Windows atau `traceroute google.com` di Linux/macOS. Cari di mana hop berhenti merespons — itu mengidentifikasi segmen jaringan yang gagal.
- Restart router Anda: Matikan daya selama 30 detik. Ini memaksa pembaruan lease DHCP dan membangun kembali sesi PPPoE/PPPoA dengan ISP Anda.
- Uji pada hotspot seluler: Jika situs dimuat melalui LTE tetapi tidak melalui broadband rumah Anda, kesalahannya ada di upstream router Anda — kemungkinan ISP Anda atau jalur routing tertentu yang mereka gunakan.
Metode 2: Flush dan Bangun Ulang Cache DNS
Cache DNS yang tercemar atau usang dapat menyimpan alamat IP lama yang tidak dapat dijangkau untuk sebuah domain, menyebabkan setiap percobaan koneksi timeout terhadap server yang tidak lagi ada di alamat tersebut.
Di Windows:
“`
ipconfig /flushdns
ipconfig /registerdns
“`
Di macOS (Ventura / Sonoma):
“`
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
“`
Di Linux (systemd-resolved):
“`
sudo systemd-resolve –flush-caches
“`
Setelah melakukan flush, verifikasi cache sudah bersih di Windows dengan `ipconfig /displaydns` — outputnya seharusnya minimal. Kemudian coba koneksi lagi sebelum membuat perubahan lain, sehingga Anda dapat mengisolasi apakah cache DNS adalah satu-satunya penyebab.
Metode 3: Beralih ke Resolver DNS Publik yang Andal
Resolver DNS default ISP Anda bisa lambat, tidak andal, atau tunduk pada pemfilteran geografis. Menggantinya dengan resolver publik yang cepat sering kali menyelesaikan kesalahan timeout yang disebabkan oleh kegagalan pencarian DNS yang secara diam-diam mengembalikan catatan yang salah atau tidak ada.
Di Windows (IPv4):
- Buka Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings.
- Klik kanan adapter aktif Anda dan pilih Properties.
- Pilih Internet Protocol Version 4 (TCP/IPv4) dan klik Properties.
- Pilih Use the following DNS server addresses dan masukkan resolver pilihan Anda.
Resolver DNS publik yang direkomendasikan:
| Penyedia | DNS Primer | DNS Sekunder | Dukungan Protokol |
|---|
| — | — | — | — |
|---|
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | DNS-over-HTTPS, DNS-over-TLS |
|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | DNS-over-HTTPS, DNS-over-TLS |
|---|
| OpenDNS | 208.67.222.222 | 208.67.220.220 | DNSCrypt |
|---|
| Quad9 | 9.9.9.9 | 149.112.112.112 | DNS-over-HTTPS, pemblokiran malware |
|---|
Kasus tepi kritis: Jika Anda baru saja memigrasikan situs web ke server baru atau mengubah rekaman A-nya, propagasi DNS dapat memakan waktu hingga 48 jam. Selama jendela waktu ini, beberapa pengguna akan diarahkan ke IP lama. Menjalankan `nslookup yourdomain.com 8.8.8.8` versus `nslookup yourdomain.com 1.1.1.1` memungkinkan Anda membandingkan apa yang dikembalikan oleh resolver yang berbeda — jika IP berbeda, Anda berada dalam jendela propagasi, bukan kesalahan timeout yang sebenarnya.
Metode 4: Hapus Cache Browser, Cookie, dan Ekstensi
Chrome dan browser berbasis Chromium lainnya menyimpan respons DNS secara independen dari cache DNS tingkat OS. Cache DNS internal browser ini dapat menyimpan catatan usang bahkan setelah Anda melakukan flush cache sistem.
Hapus cache DNS internal Chrome secara langsung:
- Navigasikan ke `chrome://net-internals/#dns`
- Klik Clear host cache
- Navigasikan ke `chrome://net-internals/#sockets`
- Klik Flush socket pools
Hapus data penjelajahan:
- Buka Chrome dan tekan `Ctrl + Shift + Delete`
- Atur rentang waktu ke All time
- Centang Cookies and other site data dan Cached images and files
- Klik Clear data
Uji terlebih dahulu di jendela Incognito. Jika situs dimuat di Incognito tetapi tidak di jendela normal, ekstensi browser adalah penyebabnya. Nonaktifkan semua ekstensi melalui `chrome://extensions/` dan aktifkan kembali satu per satu untuk mengidentifikasi pelakunya. Ad blocker, ekstensi VPN, dan alat keamanan adalah sumber gangguan yang paling umum.
Metode 5: Nonaktifkan Pengaturan Proxy
Konfigurasi proxy yang salah atau usang adalah salah satu penyebab kesalahan ini yang paling sering diabaikan, terutama pada mesin korporat atau setelah menghapus instalan perangkat lunak VPN yang meninggalkan pengaturan proxy.
Melalui Chrome:
- Buka Settings > System > Open your computer's proxy settings
- Di bawah Manual proxy setup, pastikan Use a proxy server dimatikan (Off)
- Di bawah Automatic proxy setup, pastikan Use setup script dimatikan (Off) kecuali Anda sengaja menggunakan file PAC
Melalui Windows Settings secara langsung:
- Buka Settings > Network & Internet > Proxy
- Nonaktifkan semua entri proxy manual
- Aktifkan Automatically detect settings hanya jika jaringan Anda memerlukannya
Melalui Command Prompt (metode tercepat):
“`
netsh winhttp reset proxy
“`
Ini mengatur ulang pengaturan proxy WinHTTP ke koneksi langsung, melewati proxy di seluruh sistem yang mungkin telah diatur oleh perangkat lunak.
Metode 6: Reset TCP/IP Stack dan Katalog Winsock
Kerusakan pada katalog Winsock — implementasi Windows dari Berkeley sockets API — dapat menyebabkan kegagalan koneksi intermiten atau persisten yang terlihat identik dengan timeout sisi server. Ini sangat umum terjadi setelah penghapusan malware, pembaruan driver jaringan yang gagal, atau aktivitas antivirus yang agresif.
Buka Command Prompt sebagai Administrator dan jalankan perintah-perintah ini secara berurutan:
“`
netsh winsock reset
netsh int ip reset resetlog.txt
ipconfig /release
ipconfig /flushdns
ipconfig /renew
“`
Restart mesin Anda setelah menjalankan semua perintah. File `resetlog.txt` akan dibuat di direktori kerja Anda dan mencatat setiap kunci registry yang direset — berguna untuk mengaudit apa yang rusak.
Di Linux, perintah yang setara untuk mereset status jaringan adalah:
“`
sudo systemctl restart NetworkManager
sudo ip route flush cache
“`
Metode 7: Audit Aturan Firewall dan Antivirus
Windows Defender Firewall dan suite keamanan pihak ketiga dapat secara diam-diam memblokir koneksi keluar ke port, rentang IP, atau domain tertentu. Pemblokiran tidak menghasilkan kesalahan "connection refused" secara langsung — sebaliknya, paket dijatuhkan, dan browser menunggu hingga ambang batas timeout tercapai.
Uji diagnostik sementara:
- Buka Control Panel > System and Security > Windows Defender Firewall
- Klik Turn Windows Defender Firewall on or off
- Nonaktifkan sementara untuk jaringan privat dan publik
- Coba koneksi
Jika situs dimuat dengan firewall dinonaktifkan, aktifkan kembali segera dan kemudian buat aturan outbound khusus untuk mengizinkan lalu lintas ke domain atau IP yang terpengaruh daripada membiarkan firewall mati. Navigasikan ke Advanced Settings > Outbound Rules > New Rule untuk mengonfigurasi ini dengan tepat.
Untuk perangkat lunak antivirus: Sebagian besar suite modern menyertakan fitur inspeksi HTTPS atau "web shield" yang melakukan intersep man-in-the-middle pada lalu lintas TLS. Ini dapat memutus koneksi jika sertifikat root antivirus tidak dipercaya oleh browser, atau jika antivirus secara salah menandai server target. Menonaktifkan sementara komponen web shield (bukan seluruh antivirus) adalah pengujian yang lebih tepat sasaran daripada menonaktifkan semua perlindungan.
Metode 8: Reset Flag Chrome dan Network Predictor
Flag eksperimental Chrome dan fitur prediksi jaringan terkadang dapat menyebabkan masalah koneksi, terutama setelah pembaruan browser yang mengubah cara fitur-fitur ini berperilaku.
Nonaktifkan prediksi jaringan:
- Buka Settings > Privacy and security > Cookies and other site data
- Gulir ke Preload pages for faster browsing and searching dan nonaktifkan
Reset semua flag Chrome ke default:
- Navigasikan ke `chrome://flags`
- Klik Reset all di sudut kanan atas
- Luncurkan ulang Chrome
Reset seluruh pengaturan network stack Chrome:
- Buka Settings > Advanced > Reset and clean up > Restore settings to their original defaults
Ini tidak menghapus bookmark atau kata sandi tetapi mereset halaman startup, pengaturan tab baru, tab yang disematkan, pengaturan konten, cookie, dan ekstensi — secara efektif memberi Anda baseline konfigurasi jaringan yang bersih.
Metode 9: Tingkatkan Timeout Koneksi TCP (Lanjutan)
Secara default, Windows menunggu sekitar 21 detik sebelum menyatakan percobaan koneksi TCP gagal (berdasarkan nilai registry `TcpMaxConnectRetransmissions`, yang defaultnya adalah 2 retransmisi dengan exponential backoff). Pada jaringan yang lambat atau padat, ini mungkin terlalu singkat.
Sesuaikan melalui Registry Editor (Windows):
- Buka `regedit`
- Navigasikan ke `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
- Temukan atau buat nilai DWORD bernama `TcpMaxConnectRetransmissions`
- Atur ke `3` atau `4` (heksadesimal) untuk mengizinkan lebih banyak percobaan retransmisi
Penting: Ini meningkatkan waktu tunggu Windows sebelum menyerah pada koneksi TCP. Ini tidak memperbaiki penyebab mendasar — ini hanya memberikan lebih banyak waktu bagi server yang lambat atau rute yang padat untuk merespons. Gunakan ini hanya sebagai alat diagnostik atau untuk kasus penggunaan tertentu seperti menghubungkan ke server yang jauh secara geografis.
Metode 10: Verifikasi Apakah Server Benar-Benar Dapat Dijangkau
Sebelum menghabiskan lebih banyak waktu pada perbaikan sisi klien, konfirmasikan apakah masalahnya ada di sisi server. Sebuah situs web bisa sepenuhnya tidak dapat dijangkau karena akun hosting yang ditangguhkan, aturan firewall sisi server, atau web server yang salah dikonfigurasi — tidak satu pun dari ini yang dapat Anda perbaiki dari browser Anda.
Alat untuk memeriksa keterjangkauan server dari titik pandang eksternal:
- downforeveryoneorjustme.com — Pemeriksaan naik/turun sederhana dari satu lokasi
- downdetector.com — Mengumpulkan laporan pengguna untuk layanan utama
- tools.pingdom.com — Menguji waktu respons dari beberapa lokasi global
- mxtoolbox.com/SuperTool — Menguji DNS, header HTTP, dan konektivitas
- check-host.net — Ping dan pemeriksaan HTTP dari puluhan node geografis secara bersamaan
Jalankan `curl -v https://yourdomain.com` dari terminal untuk melihat titik kegagalan yang tepat — apakah koneksi TCP ditolak, timeout, atau berhasil tetapi mengembalikan kode kesalahan HTTP. Satu perintah ini memberi tahu Anda lebih banyak daripada alat GUI mana pun.
Penyebab Sisi Server: Apa yang Harus Diperiksa Jika Anda Memiliki Situs Web
Jika Anda adalah pemilik situs web dan pengunjung Anda melaporkan `ERR_CONNECTION_TIMED_OUT`, masalahnya hampir pasti ada pada infrastruktur Anda. Penyebab sisi server yang paling umum adalah:
Kelelahan antrean koneksi web server:
Di Apache, direktif `MaxClients` (atau `MaxRequestWorkers` di Apache 2.4+) membatasi koneksi simultan. Ketika batas ini tercapai, koneksi baru mengantri dan akhirnya timeout. Periksa konfigurasi Anda saat ini:
“`
apache2ctl -V | grep -i mpm
grep -i maxrequestworkers /etc/apache2/apache2.conf
“`
Di Nginx, yang setara adalah `worker_connections` di blok `events` dan `worker_processes`. Kesalahan konfigurasi yang umum adalah mengatur `worker_processes` ke `1` pada server multi-core, menciptakan bottleneck.
Firewall memblokir lalu lintas masuk pada port 80/443:
Jika Anda mengelola lingkungan VPS Hosting, periksa aturan iptables atau nftables Anda:
“`
iptables -L INPUT -n -v | grep -E "80|443"
“`
Aturan ACCEPT yang hilang untuk port 80 dan 443 akan menyebabkan semua koneksi browser timeout secara diam-diam. Juga verifikasi bahwa firewall panel kontrol hosting Anda (CSF, UFW, atau Firewalld) tidak secara tidak sengaja memblokir port-port ini setelah pembaruan keamanan.
Masalah sertifikat SSL yang menyebabkan timeout handshake TLS:
Sertifikat SSL yang kedaluwarsa atau salah dikonfigurasi dapat menyebabkan handshake TLS terhenti, yang termanifestasi sebagai timeout koneksi daripada kesalahan sertifikat dalam beberapa kasus tepi — terutama saat menggunakan versi TLS yang lebih lama atau cipher suite yang salah dikonfigurasi. Verifikasi sertifikat Anda dengan:
“`
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com
“`
Kelelahan sumber daya pada server:
Penggunaan CPU atau RAM yang tinggi dapat menyebabkan proses web server menjadi tidak responsif. Pada server Linux, periksa:
“`
top -b -n 1 | head -20
free -h
ss -s
“`
Perintah `ss -s` menampilkan ringkasan status socket — sejumlah besar koneksi dalam status `TIME-WAIT` atau `CLOSE-WAIT` mengindikasikan masalah penanganan koneksi yang akan menyebabkan koneksi baru timeout.
Kesalahan konfigurasi DNS setelah migrasi server:
Jika Anda baru saja memindahkan situs ke Dedicated Server atau mengganti penyedia hosting, verifikasi bahwa rekaman A domain Anda menunjuk ke alamat IP yang benar dan bahwa TTL pada rekaman lama telah kedaluwarsa. Gunakan `dig yourdomain.com +trace` untuk mengikuti rantai resolusi DNS lengkap dari server root ke bawah.
Membandingkan ERR_CONNECTION_TIMED_OUT dengan Kesalahan Browser Serupa
| Kode Kesalahan | Artinya | Penyebab Paling Mungkin |
|---|
| — | — | — |
|---|
| ERR_CONNECTION_TIMED_OUT | TCP SYN dikirim, tidak ada SYN-ACK yang diterima dalam timeout | Firewall menjatuhkan paket, kelebihan beban server, kegagalan routing |
|---|
| ERR_CONNECTION_REFUSED | TCP SYN menerima RST sebagai respons | Tidak ada layanan yang mendengarkan pada port tersebut, firewall mengirim RST |
|---|
| ERR_NAME_NOT_RESOLVED | Pencarian DNS tidak mengembalikan hasil | Kesalahan konfigurasi DNS, domain tidak terdaftar, NXDOMAIN |
|---|
| ERR_SSL_PROTOCOL_ERROR | Handshake TLS gagal | Sertifikat kedaluwarsa, ketidakcocokan protokol, ketidakcocokan cipher suite |
|---|
| ERR_EMPTY_RESPONSE | TCP terhubung, tetapi server tidak mengirim data | Web server crash, respons kosong dari aplikasi |
|---|
| ERR_CONNECTION_RESET | Koneksi direset di tengah sesi | Gangguan jaringan, batas koneksi sisi server, reset proxy |
|---|
| 504 Gateway Timeout | Reverse proxy timeout menunggu origin | Server origin terlalu lambat, kegagalan koneksi upstream |
|---|
Memahami tabel ini penting secara operasional: jika Anda memecahkan masalah server Anda sendiri, kesalahan spesifik yang dilihat pengguna Anda memberi tahu Anda dengan tepat lapisan stack mana yang harus diselidiki terlebih dahulu.
Matriks Keputusan Praktis: Perbaikan Mana yang Harus Diterapkan Terlebih Dahulu
Gunakan urutan ini untuk meminimalkan waktu diagnostik:
- Bisakah Anda menjangkau situs web lain? Tidak — perbaiki jaringan lokal atau koneksi ISP Anda terlebih dahulu (Metode 1, 6). Ya — lanjutkan ke langkah 2.
- Apakah situs dimuat di perangkat atau jaringan yang berbeda? Ya — masalahnya ada di sisi klien (Metode 2, 3, 4, 5, 7). Tidak — masalahnya kemungkinan ada di sisi server atau propagasi DNS.
- Apakah pemeriksa eksternal (check-host.net) menunjukkan situs tidak aktif dari beberapa lokasi? Ya — hubungi administrator server atau penyedia hosting Anda. Tidak — masalahnya adalah routing regional atau ISP spesifik Anda.
- Apakah situs dimuat dalam mode Incognito? Ya — ekstensi browser atau data yang di-cache adalah penyebabnya (Metode 4). Tidak — lanjutkan ke perbaikan tingkat DNS dan jaringan.
- Apakah Anda baru saja mengubah rekaman DNS atau memigrasikan server? Ya — tunggu propagasi DNS dan verifikasi rekaman dengan `dig` atau `nslookup`. Tidak — periksa firewall sisi server dan konfigurasi web server.
Jika Anda menjalankan infrastruktur server sendiri — baik di VPS dengan cPanel atau lingkungan bare-metal — selalu periksa log server sebelum menghabiskan waktu pada perbaikan sisi klien. Log kesalahan Apache (`/var/log/apache2/error.log`) dan log kesalahan Nginx (`/var/log/nginx/error.log`) akan berisi catatan eksplisit tentang kegagalan koneksi, peristiwa kelelahan sumber daya, dan kesalahan konfigurasi.
Bagi tim yang mengelola beberapa domain, menjaga Pendaftaran Domain dan manajemen DNS terpusat di bawah satu penyedia secara signifikan mengurangi risiko kesalahan timeout terkait propagasi yang disebabkan oleh konfigurasi DNS terpisah atau pendaftaran domain yang kedaluwarsa.
Poin Teknis Utama
- `ERR_CONNECTION_TIMED_OUT` secara khusus mengindikasikan kegagalan tingkat TCP — paket SYN dikirim tetapi tidak ada SYN-ACK yang diterima. Ini membedakannya dari kesalahan DNS, kesalahan TLS, dan kesalahan tingkat HTTP.
- Selalu uji dari titik pandang eksternal (check-host.net, curl dari server jarak jauh) sebelum mengasumsikan masalah ada di mesin lokal Anda.
- Chrome mempertahankan cache DNS internal sendiri yang terpisah dari OS. Melakukan flush hanya cache OS melalui `ipconfig /flushdns` tidak cukup — Anda juga harus menghapus `chrome://net-internals/#dns`.
- Di sisi server, penjatuhan paket secara diam-diam dari aturan firewall adalah penyebab tunggal paling umum dari kesalahan spesifik ini. Koneksi yang ditolak (`RST`) akan menghasilkan kode kesalahan yang berbeda.
- Keterlambatan propagasi DNS setelah migrasi server sering salah didiagnosis sebagai kesalahan timeout. Selalu verifikasi dengan `nslookup` terhadap beberapa resolver sebelum menyelidiki lebih lanjut.
- Untuk web server produksi, pantau output `ss -s` secara teratur. Jumlah `CLOSE-WAIT` yang terus bertambah mengindikasikan bug penanganan socket tingkat aplikasi yang pada akhirnya akan menyebabkan timeout koneksi di bawah beban.
Pertanyaan yang Sering Diajukan
Mengapa ERR_CONNECTION_TIMED_OUT hanya muncul pada satu situs web tertentu tetapi tidak pada yang lain?
Ini hampir selalu berarti server target tidak dapat dijangkau dari jaringan Anda secara khusus — baik server sedang down, IP-nya telah berubah karena propagasi DNS, atau aturan firewall pada server memblokir rentang IP Anda. Gunakan pemeriksa eksternal seperti check-host.net untuk mengonfirmasi apakah situs tidak dapat dijangkau secara global atau hanya tidak dapat dijangkau dari lokasi Anda.
Apakah melakukan flush cache DNS memperbaiki ERR_CONNECTION_TIMED_OUT?
Bisa, tetapi hanya jika penyebabnya adalah rekaman DNS usang yang menunjuk ke IP server lama. Jika rekaman DNS sudah benar dan server benar-benar tidak dapat dijangkau, melakukan flush cache tidak akan membantu. Selalu verifikasi alamat IP yang diselesaikan oleh domain menggunakan `nslookup` sebelum dan sesudah melakukan flush.
Bisakah VPN menyebabkan ERR_CONNECTION_TIMED_OUT?
Ya. VPN merutekan lalu lintas Anda melalui server dan resolver DNS-nya sendiri. Jika server VPN kelebihan beban, jauh secara geografis, atau memiliki masalah routing ke situs target, Anda akan melihat kesalahan timeout. Putuskan koneksi VPN dan uji secara langsung. Sebaliknya, beberapa situs memblokir rentang IP exit node VPN di tingkat firewall, yang juga akan menghasilkan kesalahan ini.
Bagaimana cara memperbaiki ERR_CONNECTION_TIMED_OUT pada server yang saya kelola?
Periksa dalam urutan ini: (1) konfirmasikan proses web server sedang berjalan (`systemctl status nginx` atau `apache2`), (2) verifikasi port 80 dan 443 terbuka di firewall Anda (`iptables -L` atau `ufw status`), (3) periksa penggunaan sumber daya server dengan `top` dan `free -h`, (4) tinjau log kesalahan web server untuk pesan penolakan koneksi atau kelelahan worker, (5) konfirmasikan sertifikat SSL Anda valid dan belum kedaluwarsa.
Apakah ERR_CONNECTION_TIMED_OUT sama dengan 504 Gateway Timeout?
Tidak. 504 Gateway Timeout adalah kesalahan tingkat HTTP yang dikembalikan oleh reverse proxy (seperti Nginx atau CDN) ketika tidak dapat mendapatkan respons dari server origin upstream dalam timeout yang dikonfigurasi. `ERR_CONNECTION_TIMED_OUT` adalah kesalahan tingkat browser yang terjadi sebelum respons HTTP apa pun diterima — koneksi TCP itu sendiri tidak pernah selesai. Keduanya mengindikasikan timeout, tetapi pada lapisan stack jaringan yang berbeda.
