Lỗi 500 WordPress: tái hiện, dò debug.log và gỡ khi không vào wp-admin

Lỗi 500 WordPress thường khiến bạn bị kéo vào vòng thử ngẫu nhiên: sửa .htaccess, tăng memory rồi tắt toàn bộ plugin mà chưa biết nguyên nhân nằm ở đâu. Quy trình dưới đây giúp bạn ghi lại triệu chứng trên ba địa chỉ, lấy dấu vết từ log, và thu hẹp dần thành phần khả nghi — chứ không hứa lần nào cũng chỉ ra đúng một plugin. Nguyên nhân có thể nằm ở giao diện, đoạn mã tự thêm, cấu hình máy chủ hay hạn mức bộ nhớ; điểm chung là bạn cần dấu vết trước khi sửa. Phần dưới nói chắc nhất về nhánh plugin gây lỗi nghiêm trọng, vì đó là nhánh tôi tái hiện được từ đầu đến cuối trên một bản WordPress 7.1 dựng riêng để làm hỏng.

Tái hiện WordPress bị lỗi 500 an toàn và kiểm tra đồng thời ba URL

Mở một cửa sổ riêng tư hoặc một trình duyệt khác để kiểm tra lần lượt trang chủ, /wp-admin/ và /wp-login.php. Với mỗi URL, ghi lại mã HTTP nhìn thấy, thời điểm theo múi giờ của máy chủ nếu biết, và thao tác xảy ra ngay trước lỗi: vừa cập nhật plugin, đăng nhập, lưu bài, tải ảnh hay chỉ mở trang. Nếu có thể, lưu ảnh chụp màn hình nhưng đừng chỉ dựa vào dòng “Internal Server Error”; lỗi 500 internal server error WordPress là phản hồi tổng quát, chưa cho biết thủ phạm.

Không sửa gì giữa các lần kiểm tra đầu tiên. Một plugin có thể gọi hàm không tồn tại trong hook init, khiến PHP dừng ở thời điểm WordPress khởi tạo; tuy vậy ba URL không nhất thiết hiển thị giống nhau. Trang chủ có thể đang được bộ nhớ đệm phục vụ, có đường chạy không kích hoạt phần mã đó, hoặc máy chủ chỉ giấu thông báo lỗi ở giao diện này. /wp-admin/ và /wp-login.php lại đi qua các bước xác thực, tải thêm tệp hoặc hook khác nên vẫn có thể trả 500. Vì vậy, “wordpress bị lỗi 500” không đồng nghĩa mọi URL đang hỏng theo cùng một cách. Bản ghi ba URL cho bạn biết lỗi là toàn cục, chỉ nằm ở khu vực quản trị, hay thay đổi theo thao tác.

Bật debug mode WordPress tạm thời mà không đưa thông tin lỗi ra màn hình

Sao lưu wp-config.php trước khi sửa và mở đúng tệp cấu hình của website, không phải bản mẫu wp-config-sample.php. Đặt các dòng cấu hình debug trước dòng chú thích yêu cầu dừng chỉnh sửa, thường là câu có nội dung tương tự “That’s all, stop editing”. Dùng WP_DEBUG để bật ghi nhận lỗi, WP_DEBUG_LOG để ghi vào tệp log, và WP_DEBUG_DISPLAY để KHÔNG in lỗi ra trang cho khách xem. Ba dòng cần dán, đúng thứ tự:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Ba hằng số này có thể đã có sẵn trong tệp. Nếu có, sửa giá trị đang có thay vì khai báo trùng — khai báo hai lần thì PHP báo lỗi và bạn có thêm một lỗi nữa để gỡ.

Dấu hiệu đã xong: gọi lại trang đang lỗi một lần, rồi thấy tệp wp-content/debug.log xuất hiện hoặc có dòng mới mang đúng mốc thời gian vừa gọi. Không có dòng mới thì đừng sửa tiếp ba dòng này — chuyển sang nhật ký lỗi của hosting.

Tài liệu WordPress mô tả WP_DEBUG_LOG dùng để ghi lỗi vào wp-content/debug.log khi debug được bật; bản WordPress hoặc cấu hình hosting có thể làm vị trí log khác đi nếu đã tùy biến. Sau khi lưu, tải lại đúng một URL đang lỗi và lặp lại thao tác vừa gây lỗi một lần. Việc này làm log dễ đọc hơn. Đừng bấm qua nhiều trang hoặc cập nhật thêm plugin trong lúc truy vết, vì các dòng phát sinh sau đó có thể che mất sự kiện cần tìm.

Giữ WP_DEBUG_DISPLAY ở trạng thái tắt trên website đang có khách. Hiển thị lỗi trực tiếp có thể làm lộ đường dẫn máy chủ, tên plugin, tệp mã và stack trace; đó là thông tin không nên gửi cho mọi người truy cập. Nếu màn hình vẫn hiện lỗi dù đã tắt, hãy kiểm tra xem hosting, PHP hoặc một plugin có cơ chế hiển thị riêng hay không. Bật debug mode WordPress ở môi trường thật chỉ nên là thao tác tạm thời: sau khi lấy dấu vết, ghi lại thời điểm, rồi tắt các cờ debug khi ca đã được xử lý.

Đọc log theo dấu vết: tên hàm, tệp, số dòng rồi mới đến stack trace

Mở wp-content/debug.log bằng File Manager, FTP hoặc SSH, rồi tìm nhóm dòng gần thời điểm bạn vừa tái hiện lỗi. Tập trung vào dòng mới nhất có chữ Fatal error, Uncaught Error hoặc thông báo tương tự. Trước hết, chép riêng ba chi tiết: tên hàm hoặc class bị lỗi, đường dẫn tệp, và số dòng. Nếu dòng báo “Call to undefined function”, điều đó chỉ ra mã đang gọi một hàm mà PHP không tìm thấy; nếu báo class hoặc method không tồn tại, hướng điều tra sẽ khác. Đừng vội kết luận chỉ vì một plugin xuất hiện ở dòng đầu tiên.

Có một nhánh phải dừng sớm, đừng cố suy luận tiếp. Nếu sau khi tái hiện mà không thấy tệp `debug.log`, hoặc tệp có sẵn nhưng không có dòng mới nào ứng với lúc bạn vừa gọi trang, thì dấu vết không nằm ở đây và mọi suy đoán về plugin sau đó đều là đoán mò. Điều đó xảy ra khi lỗi bật ra trước lúc WordPress kịp đọc wp-config.php, khi thư mục wp-content không cho ghi, hoặc khi thứ hỏng nằm ở tầng máy chủ web và PHP chứ không phải trong mã WordPress. Lúc đó chuyển thẳng sang nhật ký lỗi của hosting hoặc của PHP — đó là đường điều tra song song, không phải bước cuối cùng khi đã hết cách.

Sau đó đọc stack trace từ điểm lỗi ngược ra nơi gọi nó. Tệp chứa hàm hoặc class bị thiếu thường là nơi PHP dừng lại, còn plugin ở các dòng phía trên có thể chỉ là bên kích hoạt chuỗi gọi. Hãy đối chiếu đường dẫn: thư mục wp-content/plugins/ten-plugin/ thường cho biết mã thuộc plugin nào; đường dẫn trong wp-includes hoặc wp-admin chưa đủ để kết luận WordPress lõi là nguyên nhân. Nếu trace đi qua một plugin rồi kết thúc ở mã của plugin khác, cần xem dòng lỗi và luồng gọi cụ thể thay vì chọn tên xuất hiện nhiều nhất.

Ghi lại nguyên văn đoạn lỗi, nhưng che tên miền nội bộ hoặc thông tin nhạy cảm nếu gửi cho người khác. Một dòng mới không có nghĩa nguyên nhân mới; nhiều lần tải trang có thể lặp lại cùng một fatal error. Khi tên tệp và số dòng đã chỉ rõ plugin, chuyển sang cô lập plugin đó. Nếu log chỉ báo lỗi ở một tệp tự chỉnh sửa, mã trong theme, hoặc phần mở rộng do hosting chèn vào, đừng đổi tên plugin hàng loạt: việc đó làm mất thêm tín hiệu và có thể khiến triệu chứng thay đổi.

WordPress lỗi 500 không vào được admin: đổi tên đúng thư mục plugin trước

Khi trang chủ, /wp-admin/ và /wp-login.php đều trả 500, dùng File Manager của hosting, FTP hoặc SSH để vào thư mục wp-content/plugins. Đổi tên riêng thư mục của plugin được đường dẫn trong log chỉ ra, chẳng hạn thêm hậu tố .off; không đổi tên tệp bên trong và không xóa dữ liệu. Tên thư mục mới khiến WordPress không còn nhận plugin đó theo đường dẫn cũ, nhưng việc này không gỡ dữ liệu cấu hình của plugin. Sau đó kiểm tra lại URL vừa lỗi và một URL khác trong bản ghi ban đầu.

Nếu website hoạt động trở lại, ghi nhận kết quả trước khi đổi lại tên thư mục. Bạn đã có một dấu hiệu mạnh, chưa phải bằng chứng plugin chắc chắn có lỗi trong mọi cấu hình: phiên bản PHP, bản WordPress, theme hoặc một plugin khác có thể là yếu tố tương tác. Có thể giữ plugin ở trạng thái vô hiệu hóa để kiểm tra bản cập nhật và xem lại log, hoặc khôi phục tên rồi thử một thay đổi có kiểm soát nếu cần. Khi khôi phục, chỉ đổi lại tên thư mục cũ và kiểm tra URL; không đồng thời cập nhật nhiều thành phần.

Chỉ khi chưa có dấu vết đủ rõ mới cân nhắc cô lập toàn bộ thư mục plugins, bằng cách đổi tên plugins thành một tên tạm, rồi tạo lại thư mục plugins rỗng nếu WordPress hoặc hướng dẫn hosting yêu cầu. Đây là phương án chẩn đoán cuối hơn là cách sửa mặc định, vì nó vô hiệu hóa tất cả plugin và làm mất khả năng so sánh từng plugin. Không xóa plugin để thử: xóa có thể làm mất tệp, cấu hình hoặc dữ liệu liên quan, trong khi chưa chắc đó là nguyên nhân của lỗi 500 không vào được wp-admin. Sau khi có bằng chứng, khôi phục thư mục và kích hoạt từng phần theo kế hoạch riêng.

Lỗi 500 WordPress cPanel: khi nào mới thử .htaccess và khi nào dừng lại

Trong cPanel, mở phần Errors, Error Log hoặc công cụ tương đương mà nhà cung cấp hosting công bố, rồi đối chiếu thời điểm trong log với lần bạn tải URL lỗi. Cách này hữu ích hơn việc đoán từ tên lỗi 500. Chỉ thử đổi tên .htaccess khi website chạy trên Apache hoặc LiteSpeed và cấu hình đó thực sự đọc tệp này; nếu máy chủ dùng Nginx, .htaccess không phải nơi điều khiển rewrite theo cách của Apache. Khi thử, đổi tên tệp thành một tên tạm để có thể khôi phục, kiểm tra lại URL, và không sửa nhiều quy tắc cùng lúc.

Các bài hướng dẫn và nhà cung cấp hosting có thể xếp nguyên nhân lỗi 500 theo thứ tự khác nhau: nguồn này nhấn mạnh .htaccess, nguồn khác nói về plugin, PHP hoặc giới hạn tài nguyên. Đó không phải mâu thuẫn cần chọn một bên bằng cảm tính; chúng có thể đang nói về các môi trường khác nhau. Nếu debug.log đã chỉ ra hàm không tồn tại trong một plugin, việc đổi .htaccess không giải thích được dòng fatal đó. Cũng đừng chmod hàng loạt chỉ vì thấy lỗi 500: quyền tệp phải đối chiếu với cấu hình hosting, và thay đổi rộng có thể tạo thêm lỗi.

Sửa lỗi 500 WordPress khi log báo hết memory — và đóng ca sau khi sửa

Nếu log ghi rõ PHP đã hết bộ nhớ, tăng PHP memory limit có thể giúp tiến trình có đủ tài nguyên để hoàn tất; mức phù hợp tùy gói hosting, phiên bản PHP và giới hạn nhà cung cấp cho phép. Thay đổi tại đúng nơi hosting áp dụng, chẳng hạn cPanel, cấu hình PHP của tên miền hoặc tệp cấu hình được nhà cung cấp hỗ trợ. Không coi tăng memory là cách sửa mọi lỗi 500: nó không biến một hàm không tồn tại thành hàm hợp lệ. Sau khi thay đổi, tái hiện đúng URL cũ, kiểm tra thời gian phản hồi và đọc dòng log mới. Nếu log vẫn báo cạn memory hoặc chuyển sang fatal khác, dừng tăng tiếp và xem thành phần đang tiêu thụ tài nguyên.

Khi triệu chứng đã thay đổi theo hướng mong đợi, tắt WP_DEBUG, WP_DEBUG_LOG và giữ WP_DEBUG_DISPLAY ở trạng thái tắt; nếu hệ thống cần giữ log lỗi riêng, làm theo cơ chế của hosting. Lưu lại bản chụp hoặc đoạn log cần thiết cho hồ sơ sự cố, rồi xóa hoặc làm rỗng wp-content/debug.log an toàn theo quyền truy cập của máy chủ, không xóa nhầm thư mục wp-content. Cuối cùng, tự mở đường dẫn log bằng trình duyệt riêng tư, nếu máy chủ cho phép truy cập trực tiếp, để kiểm tra nó không còn tải công khai; nếu vẫn mở được, chặn quyền truy cập bằng cấu hình hosting phù hợp. Mở lại ba URL ban đầu và ghi thời điểm kết thúc ca.