Website không vào được — Danh sách kiểm tra theo thứ tự

Bước 1 — Chỉ mình bạn hay tất cả mọi người

Đừng bỏ qua bước này. Rất nhiều giờ đã bị lãng phí để sửa một máy chủ hoàn toàn khỏe mạnh.

• Mở website bằng dữ liệu di động với Wi-Fi đã tắt. Nếu vào được, máy chủ vẫn ổn và vấn đề nằm ở mạng, DNS hoặc trình duyệt của bạn.
• Thử một công cụ kiểm tra "down for everyone" bất kỳ. Nó truy cập từ máy chủ bên ngoài và cho câu trả lời khách quan.
• Mở bằng cửa sổ ẩn danh, rồi bằng một trình duyệt khác. Loại bỏ cache và tiện ích mở rộng khỏi danh sách nghi ngờ.
• Nếu chỉ mình bạn không vào được, hãy xóa DNS cache của máy và thử lại. Trên macOS: "sudo dscacheutil -flushcache"; trên Windows: "ipconfig /flushdns".

Bước 2 — Đọc chính xác thứ bạn nhận được

Thông báo hiện ra đã thu hẹp vấn đề rất nhiều trước cả khi bạn đăng nhập vào bất cứ đâu.

Bước 3 — DNS và tên miền

• Kiểm tra tên miền còn hạn không. Tên miền hết hạn là nguyên nhân bị bỏ qua nhiều nhất và cũng dễ xảy ra nhất khi email gia hạn rơi vào hộp thư rác.
• Chạy "dig trangcuaban.com +short" hoặc "nslookup trangcuaban.com". Không có kết quả nghĩa là DNS chính là vấn đề và mọi thứ ở dưới không cần kiểm tra.
• So sánh địa chỉ IP trả về với IP thật của máy chủ. Khác nhau nghĩa là bản ghi DNS trỏ nhầm chỗ, thường sót lại sau một lần chuyển nhà.
• Kiểm tra nameserver có đúng nhà cung cấp DNS bạn đang dùng không. Đổi bản ghi ở một nơi trong khi tên miền lại dùng nameserver ở nơi khác là tình huống rất thường gặp.
• Nếu vừa đổi DNS, hãy chờ. Bản ghi có TTL, và các resolver trên thế giới sẽ giữ giá trị cũ tới hết khoảng thời gian đó.

Bước 4 — Máy chủ có sống không

• Ping địa chỉ IP của máy chủ. Có phản hồi nghĩa là máy đang chạy và có mạng; điều đó chưa nói gì về web server nhưng loại bỏ được khả năng máy đã tắt.
• Thử SSH vào máy. Vào được nghĩa là hệ điều hành khỏe mạnh và bạn có thể kiểm tra tiếp từ bên trong.
• Nếu ping được mà mọi cổng đều hết giờ, khả năng cao là tường lửa đang chặn bạn chứ không phải máy chủ sập. Trình chặn brute-force chặn IP sau vài lần đăng nhập sai là nguyên nhân rất phổ biến — thử bằng mạng khác để xác nhận.
• Kiểm tra bảng điều khiển của nhà cung cấp xem có thông báo bảo trì, sự cố hay vượt hạn mức không. Đôi khi câu trả lời nằm ngay trên trang trạng thái của họ.
• Nếu vào được máy, chạy "df -h" và "free -m" trước tiên. Đầy đĩa và cạn RAM là hai nguyên nhân gốc gây ra phần lớn các sự cố khác trong danh sách này.

Bước 5 — Dịch vụ và ứng dụng

• Kiểm tra web server đang chạy: "systemctl status nginx" hoặc "systemctl status apache2".
• Kiểm tra tầng ứng dụng: "systemctl status php8.2-fpm", hoặc tiến trình Node, Gunicorn tương ứng với stack của bạn.
• Kiểm tra cơ sở dữ liệu: "systemctl status mysql" hoặc "mariadb".
• Đọc error log trong lúc tải lại trang. Đây là bước có giá trị nhất trong toàn bộ danh sách — "tail -f /var/log/nginx/error.log" thường trả lời câu hỏi trong vài giây.
• Nếu sự cố bắt đầu ngay sau một thay đổi, hãy hoàn tác thay đổi đó trước khi chẩn đoán thêm. Cập nhật plugin, sửa cấu hình và triển khai code mới là nguyên nhân của phần lớn sự cố đột ngột.
• Kiểm tra hạn chứng chỉ SSL nếu lỗi liên quan tới HTTPS. Tác vụ tự động gia hạn thất bại trong im lặng là chuyện xảy ra thường xuyên hơn nhiều so với hình dung.

Sau khi khôi phục

Website chạy lại không có nghĩa là công việc đã xong. Phần có giá trị nhất thường nằm ở mười phút sau đó.

Ghi lại nguyên nhân thật sự chứ không chỉ cách sửa. "Khởi động lại MySQL" là hành động; "MySQL bị OOM killer giết vì VPS 1GB không có swap" mới là nguyên nhân, và chỉ cái thứ hai mới ngăn được lần sau.

Đặt giám sát uptime nếu chưa có. Biết website sập từ một cảnh báo tốt hơn nhiều so với biết từ khách hàng, và các dịch vụ cơ bản đều miễn phí.

Thêm cảnh báo cho những thứ đã gây ra sự cố lần này: dung lượng đĩa, bộ nhớ, hạn chứng chỉ và hạn tên miền. Bốn cảnh báo này bao phủ phần lớn các sự cố có thể dự đoán trước.

Kiểm tra Search Console sau vài ngày. Nếu sự cố kéo dài, báo cáo Crawl stats sẽ cho biết Googlebot gặp bao nhiêu lỗi và bạn có cần yêu cầu lập chỉ mục lại hay không.