TL;DR: Cách xử lý nhanh
Nếu bạn đang vội, bạn có thể giúp máy chủ của mình có thêm không gian để "thở" bằng cách tăng giới hạn thời gian chờ (timeout). Hãy thêm đoạn mã này vào file functions.php của giao diện hoặc một plugin chức năng để kéo dài thời gian từ mặc định 5 giây lên 30 giây:
add_filter('http_request_args', function($args, $url) {
$args['timeout'] = 30;
return $args;
}, 10, 2);
Lưu ý rằng điều này thường chỉ che giấu một vấn đề sâu xa hơn. Nó ngăn chặn lỗi hiển thị, nhưng sẽ không khắc phục được tường lửa bị cấu hình sai hoặc trình giải phân giải DNS (DNS resolver) chậm chạp.
Tại sao WordPress gặp lỗi cURL Error 28
WordPress cần phải tự giao tiếp với chính nó để duy trì hoạt động ổn định. Nó sử dụng "Loopback Requests" để kích hoạt các tác vụ nền như wp-cron.php hoặc để xác minh các endpoint của REST API. Khi bạn thấy cURL error 28, điều đó có nghĩa là WordPress đã gửi một yêu cầu đến URL của chính nó, đợi phản hồi, nhưng cuối cùng đã bỏ cuộc sau giới hạn mặc định 10 giây.
Đây không chỉ là một lỗi nhỏ về hiển thị. Một yêu cầu loopback không thành công sẽ ngăn các bài đăng đã lên lịch được xuất bản, làm hỏng tính năng tự động lưu của Block Editor và thậm chí có thể làm treo một số tích hợp vận chuyển của WooCommerce.
Các nguyên nhân gốc rễ phổ biến
- **Tường lửa quá khắt khe:** Các công cụ như UFW hoặc IPTables có thể đang chặn máy chủ kết nối với địa chỉ IP công cộng của chính nó.
- **Sự can thiệp của plugin bảo mật:** Những plugin lớn như Wordfence hoặc NinjaFirewall có thể nhầm lẫn các yêu cầu ping nội bộ này là một cuộc tấn công từ bot.
- **Vòng lặp DNS:** Máy chủ có thể thất bại trong việc giải phân giải tên miền của chính nó, khiến yêu cầu bị treo vô thời hạn.
- **Cạn kiệt tài nguyên máy chủ:** Nếu CPU của bạn luôn ở mức 100% hoặc bạn đã hết RAM, PHP-FPM sẽ không có đủ chu kỳ để xử lý yêu cầu kịp thời.
- **Thư viện cũ:** Chạy một phiên bản cURL lỗi thời (bất kỳ bản nào dưới 7.50) hoặc OpenSSL có thể gây ra sự chậm trễ lớn trong quá trình bắt tay SSL (SSL handshake).
Các bước khắc phục từng bước
1. Mở tường lửa của bạn
Trong môi trường VPS, tường lửa là thủ phạm có khả năng nhất. Bạn cần đảm bảo máy chủ có thể giao tiếp với chính nó qua cổng 80 và 443. Nếu bạn đang chạy UFW trên Ubuntu, trước tiên hãy xác định IP công cộng của bạn, sau đó đưa nó vào danh sách trắng (whitelist):
# Tìm IP công cộng của máy chủ
curl -4 icanhazip.com
# Whitelist IP của chính bạn (thay thế 1.2.3.4 bằng IP thực tế của bạn)
sudo ufw allow from 1.2.3.4
Người dùng hosting được quản lý (Managed hosting) nên bỏ qua bước này và yêu cầu bộ phận hỗ trợ "kích hoạt kết nối loopback cho IP cục bộ".
2. Khắc phục vấn đề "tự nhận diện" DNS
Đôi khi máy chủ không biết nó đang ở đâu. Hãy kiểm tra điều này bằng cách SSH vào máy và thử kết nối tới trang web của chính bạn:
ping yourdomain.com
Nếu lệnh ping bị treo hoặc trả về lỗi 'Destination Host Unreachable', bạn có thể ép buộc ánh xạ cục bộ. Hãy chỉnh sửa file hosts và trỏ tên miền của bạn trực tiếp đến địa chỉ loopback cục bộ:
sudo nano /etc/hosts
# Thêm đoạn này vào cuối file
127.0.0.1 yourdomain.com
3. Kiểm tra các plugin của bạn
Các plugin bảo mật và bộ nhớ đệm (caching) thường nằm giữa các yêu cầu này. Để tìm ra xung đột:
- Tạm thời vô hiệu hóa các bộ bảo mật như Wordfence hoặc All In One WP Security.
- Xóa Object Cache (Redis/Memcached) nếu bạn đang sử dụng. Một bản ghi cache cũ đôi khi có thể làm kẹt một yêu cầu trong một vòng lặp.
- Tải lại Site Health. Nếu lỗi biến mất, bạn đã tìm thấy xung đột và có thể cần điều chỉnh cài đặt tường lửa nội bộ của plugin đó.
4. Bắt buộc cập nhật thư viện
Ubuntu 18.04 và CentOS 7 nổi tiếng với việc có các phiên bản cURL lỗi thời, gặp khó khăn với các quá trình bắt tay TLS 1.3 hiện đại. Hãy chạy các lệnh sau để đảm bảo hệ thống của bạn được cập nhật:
# Đối với Ubuntu/Debian
sudo apt update && sudo apt install --only-upgrade curl openssl php-curl
# Đối với CentOS/RHEL
sudo yum update curl openssl
Đừng quên khởi động lại các dịch vụ của bạn: sudo systemctl restart nginx php8.1-fpm (điều chỉnh theo phiên bản cụ thể của bạn).
5. Kiểm tra ModSecurity
ModSecurity là một Tường lửa Ứng dụng Web (WAF) mạnh mẽ, nhưng nó thường quá khắt khe. Nó có thể chặn User-Agent WordPress/X.X theo mặc định. Hãy kiểm tra kỹ các bản ghi log tại /var/log/nginx/error.log. Nếu bạn thấy lỗi 403 Forbidden hoặc 406 Not Acceptable cùng với các lần thử Site Health, bạn sẽ cần tạo một quy tắc whitelist cho IP máy chủ của mình.
Cách xác minh bản sửa lỗi
- Truy cập vào Bảng điều khiển WordPress.
- Đi tới **Công cụ > Tình trạng trang web**.
- Đợi quá trình phân tích hoàn tất.
- Kiểm tra các **Bài kiểm tra đã vượt qua**. "REST API khả dụng" và "Trang web của bạn có thể thực hiện các yêu cầu loopback" bây giờ sẽ hiển thị dấu kiểm màu xanh.
Vẫn còn bị kẹt? Kiểm tra wp-config.php để xem các cài đặt WP_PROXY_HOST. Nếu máy chủ của bạn nằm sau một proxy, WordPress cần biết về nó để định tuyến các lệnh gọi cURL một cách chính xác.
Đọc thêm
- [Hướng dẫn chính thức về Site Health](https://wordpress.org/documentation/article/site-health-screen/)
- [Khắc phục sự cố PHP cURL](https://www.php.net/manual/en/book.curl.php)
- [Tài liệu về WordPress REST API](https://developer.wordpress.org/rest-api/)