Chuyện gì đang thực sự xảy ra?Bạn mở bảng điều khiển Tình trạng Trang web (Site Health) của WordPress với hy vọng thấy một màu xanh mướt, nhưng thay vào đó, một lỗi nghiêm trọng đập vào mắt: The loopback request to your site failed.
Đây không chỉ là một thông báo gây khó chịu. Hãy coi yêu cầu loopback như việc WordPress tự gọi vào số điện thoại của chính mình để kiểm tra xem đường dây có hoạt động không. Khi yêu cầu này thất bại, hậu quả sẽ đến ngay lập tức. Các bài viết đã lên lịch có thể kẹt ở trạng thái "Đã lên lịch" (Scheduled) mãi mãi. Trình chỉnh sửa Block (Gutenberg) có thể bị treo khi bạn nhấn lưu. Ngay cả REST API, xương sống của WordPress hiện đại, về cơ bản cũng sẽ bị tê liệt.
Bước 1: Chẩn đoán bằng cURLTrước khi bắt đầu đi sâu vào các cài đặt WordPress, hãy xác định xem máy chủ của bạn có thể tự truy cập vào chính nó về mặt vật lý hay không. Truy cập máy chủ của bạn qua SSH và chạy lệnh cURL tới điểm cuối (endpoint) API của chính bạn. Sử dụng cờ -I để chỉ xem các tiêu đề (headers).
# Thay thế yourdomain.com bằng URL trang web thực tế của bạn
curl -I https://yourdomain.com/wp-json/
Quan sát kỹ kết quả đầu ra. Nếu bạn thấy lỗi 403 Forbidden hoặc 500 Internal Server Error, máy chủ đang chủ động chặn chính nó. Nếu bạn thấy curl: (60) SSL certificate problem, máy chủ không tin tưởng chứng chỉ bảo mật của chính nó—một vấn đề thường gặp sau khi chuyển sang VPS mới.
Bước 2: Kiểm tra tệp /etc/hostsNhiều nhà cung cấp VPS như DigitalOcean hoặc AWS Lightsail không tự động cấu hình "hairpin NAT." Điều này có nghĩa là máy chủ cố gắng tra cứu tên miền của chính nó qua DNS công cộng, nhận được IP công cộng của chính nó, và sau đó không thể kết nối với chính mình. Bạn có thể bỏ qua điều này bằng cách ánh xạ tên miền cục bộ.
sudo nano /etc/hosts
Thêm một dòng để buộc máy chủ tìm kiếm giao diện cục bộ (127.0.0.1) cho tên miền của bạn:
127.0.0.1 yourdomain.com www.yourdomain.com
Lưu và thoát (Ctrl+O, Enter, Ctrl+X). Chạy lại lệnh cURL từ Bước 1. Nếu bây giờ nó trả về 200 OK, bạn đã giải quyết được xung đột định tuyến.
Bước 3: Giải quyết sự tin tưởng chứng chỉ SSLWordPress sử dụng thư viện PHP cURL cho các cuộc gọi loopback. Ngay cả khi trình duyệt của bạn hiển thị biểu tượng ổ khóa xanh, PHP phía máy chủ có thể thất bại nếu gói CA (Certificate Authority) của bạn đã quá cũ hoặc chứng chỉ của bạn là tự ký (self-signed).
Nếu bạn đang sử dụng Let's Encrypt, đảm bảo các chứng chỉ của bạn không chỉ hợp lệ mà còn được cài đặt đúng cách trong chuỗi (chain). Bạn có thể cập nhật kho lưu trữ tin cậy của máy chủ bằng một lệnh duy nhất:
# Cho hệ thống Ubuntu hoặc Debian
sudo apt-get update
sudo apt-get install --only-upgrade ca-certificates
Hãy tránh cám dỗ sử dụng các plugin để "tắt xác minh SSL" (disable SSL verification). Điều đó giống như việc sửa đèn 'kiểm tra động cơ' bằng cách dán băng dính đè lên—nó che giấu vấn đề nhưng để lại máy chủ của bạn trong tình trạng dễ bị tấn công.
Bước 4: Bỏ qua Xác thực Cơ bản (Basic Authentication)Bạn đang thử nghiệm trên một trang staging được bảo vệ bằng mật khẩu (Basic Auth)? WordPress không đủ thông minh để biết thông tin đăng nhập của bạn. Khi nó cố gắng ping REST API, nó sẽ gặp lời nhắc đăng nhập và nhận được lỗi 401 Unauthorized.
Bạn cần thông báo cho máy chủ web rằng các yêu cầu đến từ chính máy chủ thì không cần mật khẩu. Đối với Nginx:
location / {
satisfy any;
allow 127.0.0.1;
allow 192.168.1.100; # Thay thế bằng IP máy chủ thực tế của bạn
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
Bước 5: Kiểm tra Tường lửa và các Plugin bảo mậtCác công cụ bảo mật thường nhầm lẫn các yêu cầu loopback thường xuyên là một cuộc tấn công DDoS hoặc quét bot. Vì WordPress có thể kích hoạt hàng chục yêu cầu này chỉ trong vài giây, bạn có thể đang bị giới hạn tốc độ (rate-limited) bởi chính phần mềm của mình.
- **Wordfence:** Tạm thời chuyển Tường lửa sang 'Learning Mode'. Nếu lỗi biến mất, Wordfence đã chặn 127.0.0.1.
- **Cloudflare:** Nếu bạn sử dụng Orange Cloud, hãy đảm bảo IP máy chủ của bạn được đưa vào danh sách trắng trong Bảng điều khiển Cloudflare tại mục 'Security > WAF > IP Access Rules.'
- **Fail2Ban:** Kiểm tra xem máy chủ của bạn có vô tình tự "nhốt" chính mình hay không: `sudo fail2ban-client status nginx-http-auth`.
Bước 6: Kiểm tra xung đột bằng WP-CLINếu nhật ký máy chủ trông sạch sẽ nhưng lỗi vẫn tiếp diễn, có khả năng một plugin đang can thiệp vào bộ lọc http_request_args. Thay vì nhấp chuột qua giao diện người dùng, hãy sử dụng WP-CLI để chẩn đoán việc này trong vài giây.
# Hủy kích hoạt tất cả cùng lúc
wp plugin deactivate --all
# Kiểm tra Tình trạng Trang web. Nếu vượt qua, hãy kích hoạt lại từng plugin một.
Xác minhQuay trở lại Công cụ → Tình trạng Trang web. Lỗi nghiêm trọng đó bây giờ sẽ biến mất. Để chắc chắn 100% rằng các tác vụ chạy ngầm đã hoạt động trở lại, hãy kiểm tra lịch trình cron của bạn:
wp cron event list --format=table
Nếu cột 'Next Run' hiển thị thời gian trong tương lai thay vì quá khứ, các yêu cầu loopback của bạn đã chính thức khỏe mạnh.
Mẹo nhanh
- Luôn liếc qua `/var/log/nginx/error.log` hoặc tệp tương đương của Apache. Nhật ký không bao giờ nói dối về lý do tại sao một kết nối bị ngắt.
- Nếu bạn sử dụng Docker, hãy đảm bảo container WordPress có thể giao tiếp với container Nginx qua mạng bridge nội bộ.
- Đừng hài lòng với một dấu tích xanh nếu các tính năng cơ bản như WP-Cron vẫn thất bại. Chức năng quan trọng hơn trạng thái trên bảng điều khiển.