ERR_CONNECTION_TIMED_OUT — Nguyên nhân và cách khắc phục

Lỗi này thực sự nói lên điều gì

Timeout không phải là từ chối. Khi một máy chủ chủ động từ chối bạn, kết nối hỏng ngay lập tức và thông báo sẽ khác. ERR_CONNECTION_TIMED_OUT nghĩa là trình duyệt đã gửi yêu cầu, chờ hết thời gian quy định, và không nhận được bất kỳ phản hồi nào — im lặng, chứ không phải "không".

Khác biệt đó thu hẹp phạm vi rất nhiều. Im lặng thường có nghĩa là gói tin bị chặn lại giữa đường thay vì được trả lời: một tường lửa loại bỏ chúng mà không hồi đáp, một máy chủ quá tải không nhận thêm kết nối, một tuyến đường không dẫn tới đâu, hoặc một máy đang tắt.

Hai phút để biết lỗi thuộc về ai

Làm ba bước này trước khi thay đổi bất kỳ cài đặt nào. Chúng gần như không tốn gì và quyết định nửa nào của bài viết mới thực sự cần cho bạn.

• Mở đúng trang đó bằng dữ liệu di động, tắt Wi-Fi. Nếu vào được bình thường, máy chủ vẫn khỏe và vấn đề nằm ở mạng của bạn. Nếu vẫn lỗi, khả năng cao vấn đề ở máy chủ hoặc tuyến đường tới đó.
• Mở một trang web bất kỳ khác. Nếu mọi trang khác vẫn bình thường, đây là chuyện của riêng một trang, không phải kết nối của bạn.
• Kiểm tra trang từ ngoài mạng của bạn bằng dịch vụ kiểm tra "is it down", hoặc nhờ người ở nơi khác mở giúp. Nếu họ vào được còn bạn thì không, bạn đang gặp chặn cục bộ, bản ghi DNS cũ, hoặc vấn đề định tuyến.

Nếu lỗi nằm ở phía bạn

Làm theo thứ tự này. Danh sách được sắp xếp để những cách nhanh và vô hại đứng trước.

• Khởi động lại router. Rút điện 30 giây thay vì chỉ bấm nút reboot — việc rút điện xóa bảng NAT và thiết lập lại kết nối với nhà mạng. Cách này thực sự xử lý được phần lớn trường hợp.
• Tắt VPN hoặc proxy rồi tải lại. Một VPN có exit node đã chết tạo ra đúng triệu chứng này, proxy còn sót cấu hình của mạng cũ cũng vậy.
• Xóa bộ nhớ đệm DNS. Trên Windows chạy "ipconfig /flushdns" trong Command Prompt; trên macOS chạy "sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder"; trên Android và iOS chỉ cần bật rồi tắt chế độ máy bay.
• Đổi DNS sang 8.8.8.8 (Google) hoặc 1.1.1.1 (Cloudflare). Một số DNS của nhà mạng giữ bản ghi cũ hoặc chặn địa chỉ rất lâu sau khi dữ liệu thật đã thay đổi.
• Tạm tắt tường lửa hoặc lớp bảo vệ web của phần mềm diệt virus rồi tải lại một lần. Các bộ bảo mật khá thường xuyên chặn nhầm cả dải IP. Bật lại ngay sau đó — đây chỉ là phép thử, không phải cách sửa.
• Kiểm tra file hosts xem có dòng cũ nào trỏ tên miền tới IP sai không. Đường dẫn là C:\Windows\System32\drivers\etc\hosts trên Windows và /etc/hosts trên macOS, Linux. Lập trình viên tự gây ra chuyện này cho mình liên tục.
• Thử trình duyệt khác hoặc cửa sổ ẩn danh. Nếu ẩn danh vào được, có tiện ích mở rộng đang can thiệp — tắt hết rồi bật lại từng cái.

Nếu lỗi nằm ở phía máy chủ

Nếu trang lỗi trên mọi mạng bạn thử, các bước trên không giúp gì — vấn đề nằm ở chính máy chủ, hoặc bạn phải chờ người quản trị nó.

• Xác nhận máy chủ có đang chạy không. Nếu đó là VPS của bạn, đăng nhập qua console của nhà cung cấp thay vì SSH: một máy đã tắt hoặc hết bộ nhớ sẽ không trả lời cả hai.
• Kiểm tra quy tắc tường lửa trên máy chủ. Tường lửa DROP gói tin gây ra timeout, còn REJECT gây ra từ chối tức thì. Nếu bạn vừa thêm quy tắc, đó là nghi phạm đầu tiên.
• Tìm giới hạn theo IP hoặc trình chặn brute-force. Các công cụ như CSF, fail2ban và brute-force monitor của DirectAdmin sẽ chặn một IP mở quá nhiều kết nối trong thời gian ngắn, và kết quả trông đúng như thế này — mọi cổng đều chết với một địa chỉ trong khi trang vẫn bình thường với người khác.
• Xác nhận tiến trình web server còn sống. Apache, Nginx hay LiteSpeed có thể chết trong khi máy vẫn bật, nên máy chủ vẫn phản hồi ping nhưng không có gì lắng nghe ở cổng 80 hay 443.
• Kiểm tra tài nguyên máy chủ. Máy hết RAM hoặc chạm trần CPU sẽ nhận kết nối chậm đến mức chúng hết thời gian trước khi hoàn tất.
• Xác nhận bản ghi DNS trỏ đúng IP nơi trang thực sự được lưu trữ. Bản ghi còn trỏ về máy chủ cũ sau khi chuyển nhà sẽ gây timeout mà không cách sửa nào ở phía người dùng chữa được.

Những lỗi trông giống nhưng khác hẳn

Nhóm này bị nhầm lẫn liên tục, và đuổi theo nhầm lỗi làm mất hàng giờ. Câu hỏi hữu ích luôn là: kết nối đã đi được tới đâu trước khi hỏng?