Laman Web Tidak Boleh Dibuka? Bezakan Ralat DNS, Hosting dan…

Kenal pasti lapisan kegagalan dahulu

Permintaan membuka laman web melalui beberapa sistem yang berasingan: pendaftaran domain, DNS berautoriti, penyelesai DNS pengguna, laluan rangkaian, rundingan TLS, pelayan web dan kadangkala aplikasi bersama pangkalan data. Kerosakan pada mana-mana lapisan boleh menghasilkan halaman kosong. Catat URL tepat, masa tempatan dan mesej pelayar sebelum mencuba pembetulan. Uji halaman utama serta satu halaman dalaman yang diketahui. Jika e-mel masih berfungsi, itu hanya menunjukkan laluan mel mungkin sihat; keadaan tersebut tidak mengesahkan DNS laman atau pelayan asal berfungsi.

Bezakan masalah seorang pengguna dengan gangguan meluas

Tanya sama ada ralat muncul pada satu peranti, rangkaian pejabat, data mudah alih dan sambungan luar yang bebas. Bandingkan keputusan tanpa membuka akaun pelanggan pada peranti yang tidak dipercayai. Kegagalan terhad kepada satu pelayar mungkin berkaitan pengalihan tersimpan, sambungan pelayar atau DNS setempat; kegagalan merentasi rangkaian bebas memerlukan siasatan pada bahagian pelayan. Satu cubaan yang berjaya juga tidak membuktikan semua pengguna selamat kerana cache dan laluan mengikut lokasi berbeza. Rekodkan rangkaian, nama hos, masa serta hasil setiap ujian.

Semak pendaftaran dan delegasi secara berasingan

Domain yang berdaftar dan langganan hosting yang aktif ialah dua aset berbeza. Semak status serta tarikh luput domain melalui akaun pendaftar yang dibenarkan atau carian pendaftaran yang boleh dipercayai. Kemudian semak nameserver yang didelegasikan oleh zon induk, bukan sekadar papan pemuka DNS yang diingati kakitangan. Masalah pembaharuan domain boleh menjejaskan nama, manakala domain aktif masih boleh menunjuk ke pelayan yang telah ditamatkan. Jangan anggap notis luput bermaksud fail laman sudah dipadam. Rujuk isu pemilikan atau bil kepada pentadbir sah sebelum mengubah DNS.

Tafsir ralat resolusi DNS dengan tepat

Mesej seperti NXDOMAIN atau ERR_NAME_NOT_RESOLVED menunjukkan nama hos yang diminta tidak berjaya diselesaikan dalam keadaan ujian tersebut. Semak ejaan, subdomain tepat, nameserver berautoriti serta rekod A, AAAA atau CNAME yang berkaitan. Bandingkan jawapan daripada sumber berautoriti dengan satu atau beberapa penyelesai rekursif. Panduan DNS Cloudflare turut menerangkan cache negatif: penyelesai mungkin masih mengingati nama baharu yang sebelum ini tiada. Menurunkan TTL rekod baharu berulang kali tidak memadam jawapan negatif lama. Catat jawapan dan tempoh cache sebelum mencadangkan perubahan.

Fahami batas bukti daripada DNS

Carian DNS yang berjaya memberikan jawapan, bukannya bukti aplikasi web sihat. Apabila nama hos mendapat alamat, persoalan seterusnya ialah sama ada sambungan sampai kepada perkhidmatan yang dimaksudkan. Bandingkan alamat asal yang dikonfigurasi dengan rekod hosting pentadbir sah, termasuk IPv6 jika digunakan. Rekod AAAA lama boleh menyebabkan pengalaman berlainan kepada pengguna IPv6. Bagi nama hos yang diproksikan melalui Cloudflare, DNS awam mungkin memulangkan alamat Cloudflare dan bukan alamat pelayan asal; itu perkara biasa. Jangan dedahkan IP asal sulit semata-mata untuk menunjukkan keputusan diagnostik.

Bezakan sambungan ditolak daripada respons lambat

Sambungan yang segera ditolak berbeza daripada sambungan yang menunggu sehingga tamat masa. Penolakan mungkin menunjukkan tiada perkhidmatan mendengar pada port diperlukan atau komponen rangkaian menolak sambungan. Tamat masa boleh berpunca daripada paket hilang, penapisan, penghalaan atau destinasi yang terlalu sibuk. Uji titik akhir HTTPS yang dijangka dan jangan membuat kesimpulan berdasarkan ping berjaya; sesetengah hos sihat tidak menjawab ICMP. Simpan cap masa mentah dan nama hos yang diuji untuk penyedia. Jangan longgarkan firewall atau membuka port secara meluas demi meluluskan satu ujian.

Baca amaran sijil TLS mengikut maksudnya

Amaran sijil pada pelayar mungkin menandakan sijil luput, nama hos tidak sepadan, pengeluar tidak dipercayai atau masalah rantaian kepercayaan. Periksa nama hos, tempoh sah dan rantaian yang ditunjukkan oleh alat diagnostik dipercayai; jangan suruh kakitangan mengabaikan amaran pada halaman log masuk atau bayaran. Bezakan sijil antara pelawat dengan CDN daripada sijil antara CDN dengan pelayan asal. Ikon mangga pada satu nama hos tidak membuktikan semua subdomain dilindungi. Pembaharuan sijil perlu disahkan melalui sambungan TLS baharu dan pemeriksaan pelayan yang menyampaikan sijil tersebut.

Kenali gelung pengalihan tanpa meneka

Mesej ERR_TOO_MANY_REDIRECTS menunjukkan pelayar diarahkan berkali-kali. Periksa urutan pengalihan dan catat langkah yang berulang, sama ada HTTP bertukar kepada HTTPS, serta sama ada nama www berselang dengan domain utama. Mod TLS proksi boleh bercanggah dengan arahan HTTPS pada pelayan asal; Cloudflare memberi amaran bahawa mod Flexible bersama pengalihan HTTP-ke-HTTPS di pelayan asal boleh menghasilkan gelung. Mengosongkan kuki mungkin membantu mengasingkan masalah pelayar tetapi tidak membaiki gelung di pelayan. Jangan mematikan HTTPS atau menukar mod keselamatan secara sembarangan; rancang pembetulan yang boleh diundur setelah puncanya dikenal pasti.

Bezakan kod 404 dengan 500

Respons 404 bermaksud sumber yang diminta tidak ditemui pada URL itu; ia tidak semestinya bermakna seluruh pelayan terhenti. Semak sama ada hanya halaman produk yang dinamakan semula atau laluan bahasa tertentu terjejas. Respons 500 menunjukkan ralat dalaman pelayan yang mungkin berpunca daripada konfigurasi aplikasi, kod atau kebergantungan. Bandingkan fail statik, halaman utama dan halaman dinamik bermasalah. Jika kandungan statik berfungsi tetapi proses pesanan gagal, utamakan bukti aplikasi dan pangkalan data. Bezakan kod status sebenar daripada reka bentuk halaman ralat kerana paparan tersuai boleh menyembunyikan status yang dihantar.

Gunakan 502, 503 dan 504 sebagai petunjuk berlainan

Respons 502 Bad Gateway lazimnya bermaksud perantara menerima jawapan tidak sah daripada sistem di belakangnya. Kod 504 menunjukkan perantara tidak mendapat respons tepat pada masanya. Kod 503 pula bermaksud pelayan buat sementara tidak mampu mengendalikan permintaan, contohnya semasa penyelenggaraan atau beban tinggi. Label ini membantu siasatan tetapi tidak terus menentukan penyedia yang bersalah. Catat komponen yang menghasilkan kod serta sama ada aplikasi belakang sempat dihubungi. MDN dan cPanel menerangkan perbezaannya. Jangan anggap semua mesej 5xx membuktikan pelan hosting terlalu kecil; deployment rosak juga boleh memberi gejala sama.

Tafsir kod Cloudflare 521 dan 522

Bagi laman yang menggunakan proksi Cloudflare, 521 bermaksud pelayan asal menolak sambungan Cloudflare; perkhidmatan web terhenti atau alamat Cloudflare disekat ialah kemungkinan yang didokumenkan. Ralat 522 pula bermaksud sambungan ke pelayan asal tamat masa, mungkin berkaitan penghalaan, penapisan, beban atau alamat asal lama. Kedua-duanya tidak sama dengan keputusan DNS NXDOMAIN. Minta pentadbir hosting menyemak kesihatan perkhidmatan dan bukti firewall sambil mengekalkan kawalan keselamatan. Catat Ray ID jika dipaparkan, URL terjejas dan zon masa. Tangkapan skrin tanpa maklumat ini mungkin sukar dipadankan dengan log penyedia.

Tafsir kod Cloudflare 523 dan 524

Kod Cloudflare 523 menunjukkan pelayan asal tidak dapat dicapai, jadi siasat alamat asal dan laluan penghalaan bersama pasukan rangkaian atau hosting. Kod 524 berbeza: Cloudflare berjaya bersambung tetapi pelayan asal tidak memberikan respons HTTP dalam had masa proksi yang berkenaan. Pertanyaan pangkalan data lambat, eksport besar atau proses pekerja yang penuh boleh menjelaskan corak kedua. Bandingkan titik akhir bermasalah dengan halaman ringan sebelum memutuskan perubahan infrastruktur. Tetapan tamat masa serta kelayakan pelan berbeza antara penyedia; jangan menjanjikan peningkatan had masa tersedia kepada semua pelanggan.

Tafsir kod Cloudflare 525 dan 526

Ralat 525 berkaitan kegagalan rundingan TLS antara Cloudflare dan pelayan asal apabila mod penyulitan berkaitan digunakan. Ralat 526 menunjukkan Cloudflare tidak dapat mengesahkan sijil pelayan asal apabila pengesahan ketat berkuat kuasa. Periksa rantaian sijil asal, nama hos, tarikh luput, konfigurasi TLS dan port HTTPS yang aktif melalui pasukan hosting yang dibenarkan. Kegagalan ini berbeza daripada amaran sijil setempat pada pelayar walaupun kedua-duanya berkaitan keselamatan. Elakkan melemahkan pengesahan sijil ketat hanya untuk menyembunyikan mesej; baiki sijil atau konfigurasi pelayan dahulu, kemudian sahkan sambungan terlindung dari hujung ke hujung.

Siasat kod 520 tanpa mengandaikan punca

Cloudflare menerangkan 520 sebagai respons kosong, tidak diketahui atau luar jangka daripada pelayan asal. Antara kemungkinan ialah pelayan terhenti, respons rosak, pengepala terlalu besar atau tingkah laku protokol asal yang tidak serasi. Kod itu tidak semestinya membuktikan CDN bersalah. Bandingkan status di pinggir rangkaian dengan rekod pelayan asal dan minta padanan berdasarkan masa permintaan tepat. Jika tiada entri sepadan dalam log asal, pertimbangkan perantara serta cache dan jangan terus mengisytiharkan aplikasi tidak bermasalah. Perubahan proksi, firewall atau protokol memerlukan penilaian terkawal kerana boleh mendedahkan pelayan asal atau mengurangkan perlindungan.

Cari kegagalan aplikasi pada laluan tertentu

Laman boleh memaparkan halaman utama tetapi gagal hanya pada log masuk, pembayaran, carian atau laluan Bahasa Melayu. Uji URL awam yang mewakili setiap fungsi tanpa menghantar data pelanggan sebenar. Catat sama ada kegagalan berlaku sebelum atau selepas pengesahan pengguna, dan sama ada permintaan POST gagal sedangkan halaman GET berfungsi. Ralat aplikasi boleh melibatkan sambungan pangkalan data, kebenaran fail, pemboleh ubah persekitaran yang hilang atau pemalam tidak serasi. Satu fungsi rosak tidak membuktikan DNS perlu diubah. Berikan pembangun langkah ulangan, pengecam permintaan tanpa identiti dan versi terakhir yang berfungsi, bukan token sesi sulit.

Gunakan log sebagai bukti, bukan tekaan

Minta pengendali sah memadankan log akses, ralat aplikasi, peristiwa pelayan web dan metrik infrastruktur pada minit yang sama. Lonjakan respons 500 selepas keluaran kod menunjukkan arah siasatan berbeza daripada peningkatan sambungan tamat masa ketika trafik bertambah. Bandingkan CPU, memori, had proses, sambungan pangkalan data dan ruang cakera hanya apabila pelan hosting menyediakan ukuran yang boleh dipercayai. Simpan cap masa serta zon masa. Jangan siarkan log mentah yang mengandungi alamat, token, maklumat peribadi atau isi permintaan. Jika akses terhad, beri penyedia tempoh insiden yang tepat dan minta dapatan yang telah disanitasi, bukannya kelayakan akaun.

Pertimbangkan cache dan perbezaan pinggir dengan pelayan asal

CDN mungkin menghantar halaman daripada cache ketika pelayan asal gagal, atau ralat tersimpan masih kelihatan selepas pembaikan. Bandingkan status cache dengan status pelayan asal jika diagnostik itu tersedia. Uji laluan tanpa cache yang selamat bersama pentadbir dan bukannya mengosongkan semua cache tanpa kawalan. Wilayah berlainan mungkin mencapai lokasi pinggir berbeza lalu menerima hasil berlainan. Cache hit yang berjaya hanya membuktikan objek tersimpan dihantar, bukan borang baharu atau penulisan pangkalan data berfungsi. Dokumentasikan laluan dinamik secara berasingan daripada imej dan fail gaya statik kerana keperluan ketersediaannya tidak sama.

Semak perubahan terkini dan syarat rollback

Bandingkan masa kegagalan pertama dengan keluaran perisian, suntingan DNS, pembaharuan sijil, peraturan firewall dan notis penyelenggaraan penyedia. Perubahan yang berlaku hampir serentak ialah petunjuk, bukan bukti punca. Tanya versi atau konfigurasi mana yang diketahui berfungsi serta sama ada rollback boleh menghilangkan transaksi sah atau kandungan baharu. Sahkan kesegaran sandaran dan keserasian pangkalan data sebelum mengundur keluaran aplikasi. Catat syarat tepat yang mencetuskan rollback serta ujian selepasnya. Jangan mengubah DNS, TLS dan kod aplikasi serentak kerana keputusan selepas itu sukar dikaitkan dengan satu punca.

Asingkan e-mel perniagaan daripada eksperimen membaiki laman

Perniagaan mungkin menggunakan domain sama untuk e-mel dan laman web tetapi kedua-duanya berada pada sistem berlainan. Rekod A atau nama hos web berproksi bukan pengganti rekod MX dan rekod pengesahan mel. Menukar nameserver untuk menyiasat laman boleh menggantikan zon berautoriti secara tidak sengaja lalu mengganggu penghantaran e-mel. Inventorikan MX, SPF, DKIM, DMARC dan rekod perkhidmatan lain sebelum migrasi DNS yang dibenarkan. Jika mel masih diterima, simpan bukti tersebut dan jangan ubah rekodnya. Asingkan pemulihan laman daripada pemulihan peti mel dalam komunikasi insiden kerana kesan dan pemilik sistem mungkin berbeza.

Utamakan insiden berdasarkan kesan perniagaan

Bagi PKS Malaysia, halaman maklumat yang gagal dan aliran tempahan atau bayaran yang tidak boleh digunakan membawa kesan berlainan. Rekodkan sama ada pertanyaan, sokongan pelanggan, transaksi atau maklumat diterbitkan terjejas. Lantik seorang penyelaras insiden untuk mengumpul bukti dan pemilik teknikal sah bagi setiap komponen. Notis sementara melalui saluran sedia ada yang diluluskan boleh dipertimbangkan, tetapi jangan menerbitkan janji pemulihan yang belum disahkan. Jika terdapat tanda pendedahan data atau pengambilalihan akaun, ikut prosedur keselamatan berkaitan dan jangan menganggapnya gangguan biasa. Keutamaan perlu berdasarkan kesan sebenar kepada pelanggan, bukan mesej pelayar yang paling dramatik.

Fahami kesan terhadap keterlihatan carian

Ralat pelayan berpanjangan boleh menjejaskan perayapan dan pengindeksan carian, tetapi gangguan singkat tidak secara automatik menghapuskan semua kedudukan. Panduan perayap Google menyatakan respons 5xx berulang boleh mengurangkan perayapan dan akhirnya menyebabkan URL terjejas dikeluarkan jika kegagalan berterusan. Setelah perkhidmatan pulih, sahkan halaman penting memberi respons berjaya yang sesuai dan robots.txt masih boleh dicapai. Jangan memadam halaman daripada sitemap atau menambah noindex semata-mata kerana gangguan pelayan tanpa alasan lain. Jejak URL terjejas serta tarikh pemulihan supaya analisis SEO kemudian dapat membezakan insiden teknikal daripada perubahan kandungan atau permintaan.

Sediakan maklumat lengkap untuk sokongan penyedia

Permintaan sokongan yang ringkas perlu menyertakan URL penuh yang gagal, masa kejadian pertama dan terkini, zon masa, mesej pelayar, kod HTTP atau Cloudflare serta sama ada masalah berulang pada beberapa rangkaian. Sertakan Ray ID jika ada, huraian perubahan terkini yang telah disanitasi dan pengecam perkhidmatan berkaitan melalui saluran sokongan selamat. Tanya penyedia lapisan mana yang gagal serta bukti yang menyokong kesimpulan itu. Jangan menghantar kata laluan, kunci peribadi, rekod pelanggan penuh atau log tanpa tapisan melalui e-mel biasa. Tiket yang boleh diambil tindakan membantu memisahkan tanggungjawab pendaftar, DNS, CDN, hosting dan aplikasi tanpa mendakwa diagnosis yang belum dibuktikan.

Sahkan pemulihan melalui perjalanan pelanggan sebenar

Halaman utama yang kembali berfungsi belum cukup untuk menerima pemulihan laman perniagaan. Uji semula URL yang gagal, navigasi utama, versi bahasa, imej, HTTPS, borang dan aliran pertanyaan atau tempahan yang dibenarkan menggunakan data ujian tidak sensitif. Bandingkan hasil pada sekurang-kurangnya dua rangkaian bebas jika praktikal. Pastikan pelayan tidak menghantar halaman ralat yang kelihatan mesra tetapi menggunakan kod HTTP salah. Jika gangguan menjejaskan transaksi, buat semakan bersama pemilik sistem bertanggungjawab dan jangan menghantar semula permintaan pelanggan secara membuta tuli. Rekod masa pemulihan disahkan serta gejala berselang yang belum selesai, kemudian teruskan pemantauan mengikut proses sedia ada.

Contoh insiden: halaman utama baik, pembayaran gagal

Bayangkan sebuah kedai tempatan secara hipotetikal: halaman utama dan imej produk boleh dibuka, tetapi pembayaran memulangkan kod 500 selepas kemas kini pemalam. DNS menyelesaikan nama secara konsisten, sijil sah dan fail statik dihantar daripada cache. Pemerhatian itu menjadikan gangguan DNS menyeluruh kurang mungkin, walaupun tidak menolak semua masalah rangkaian. Bukti seterusnya yang berguna ialah ID permintaan pembayaran, ralat aplikasi pada masa sepadan serta keserasian pemalam yang berubah. Rollback terkawal mungkin sesuai selepas risiko transaksi dan pangkalan data dinilai. Membeli pelan hosting lebih besar tanpa bukti tersebut hanyalah tekaan.

Contoh insiden: keputusan rangkaian berbeza

Pertimbangkan perniagaan andaian yang boleh membuka laman melalui data mudah alih tetapi gagal melalui rangkaian pejabat selepas subdomain baharu dicipta. Pentadbir mengesahkan rekod wujud pada nameserver berautoriti, sedangkan penyelesai pejabat masih melaporkan NXDOMAIN. Ini menunjukkan kemungkinan maklumat DNS negatif tersimpan dan bukannya keperluan memasang semula laman. Rekodkan penyelesai serta baki hayat cache negatif, kemudian uji semula selepas tempoh berkaitan. Jika sumber berautoriti sendiri tiada rekod itu, siasat konfigurasi zon. Kedua-dua pemerhatian tidak membenarkan pertukaran nameserver atau perubahan rekod mel secara berulang.

Bina rekod keputusan diagnostik yang boleh digunakan semula

Bagi setiap insiden, simpan garis masa ringkas: gejala, URL terjejas, rangkaian terlibat, jawapan DNS, keputusan TLS, status HTTP, bukti pelayan asal atau aplikasi, sejarah perubahan, tindakan serta ujian penerimaan akhir. Tandakan dapatan tidak pasti sebagai hipotesis sehingga disokong bukti. Rekod ini membantu juruteknik kemudian memahami bahawa ralat yang kelihatan sama mungkin mempunyai punca berbeza. Simpan butiran sensitif dalam sistem terhad dan berikan pelanggan hanya kemas kini perkhidmatan yang sesuai. Jika bantuan diperlukan, minta pentadbir domain, hosting atau laman mentafsir bukti sebelum perubahan dibenarkan. Penyelesaian masalah ialah urutan ujian, bukannya perlumbaan mengubah tetapan.

Siasat kelembapan aplikasi sebelum mencadangkan VPS

Apabila laman web berulang kali memulangkan ralat 503 semasa pembayaran atau tempahan, sahkan sama ada puncanya had proses PHP, kekurangan memori, pertanyaan pangkalan data perlahan atau perkhidmatan pembayaran luar. Naik taraf daripada akaun berkongsi sederhana kepada awan terurus mungkin menyediakan ruang pemprosesan tambahan, tetapi pertanyaan atau integrasi yang rosak boleh tetap gagal pada pelayan lebih besar. Simpan log aplikasi, masa kejadian dan aliran kerja terlibat sebagai bukti. Jangan membuat kesimpulan VPS diperlukan hanya berdasarkan jumlah pengunjung bulanan atau hasil jualan.

Pakej Biz/Power biasa OnHypp sesuai untuk keperluan e-mel dan laman web lazim. Pelan tersebut tidak memberikan akses root VPS dan tidak secara automatik merangkumi sokongan aplikasi khusus. Sebelum migrasi, sahkan sandaran serta pelan pengunduran, uji aliran pembayaran atau portal ketika beban sebenar dan lindungi penghalaan e-mel pelanggan.

Sumber & bacaan lanjut

Jadikan panduan ini tindakan

E-mel & hosting Domain Reka bentuk web

Laman Web Tidak Boleh Dibuka? Bezakan Ralat DNS, Hosting dan Aplikasi