Website WordPress lúc vào được lúc không, wp-admin lỗi 500: kiểm tra nguyên nhân theo 7 tầng

Trang chủ có lúc mở bình thường, vài phút sau lại lỗi. Khu vực /wp-admin trả về HTTP 500, trong khi dung lượng hosting vẫn còn và SSL chưa hết hạn. Những dấu hiệu này chưa đủ để kết luận hosting yếu, plugin lỗi hay server có sự cố.

Mã 500 chỉ cho biết máy chủ đã gặp một tình huống ngoài dự kiến khi xử lý yêu cầu. Theo RFC 9110, server không thể hoàn thành request vì một điều kiện bất ngờ. Thông báo này không chỉ ra file, plugin hoặc tài nguyên nào là nguyên nhân. Muốn xử lý đúng, cần kiểm tra từ ngoài vào trong và đối chiếu lỗi với đúng thời điểm phát sinh.

Một trường hợp được chia sẻ trong Cộng đồng WordPress Việt Nam ngày 22/07/2026 có biểu hiện trang chủ lúc vào được lúc không và /wp-admin báo 500, dù người đăng chưa thấy dấu hiệu dung lượng, PHP, SSL hay domain có vấn đề. Đây là ví dụ điển hình cho việc triệu chứng bề mặt chưa đủ để chẩn đoán. Không thể suy ra nguyên nhân của website đó nếu thiếu status, log và dữ liệu tài nguyên.

Trước khi sửa: giữ lại bằng chứng và tạo điểm quay lại

Khi website vừa hoạt động trở lại, phản xạ thường thấy là cập nhật tất cả plugin, đổi PHP hoặc nâng hosting ngay. Cách này có thể làm mất dấu vết và tạo thêm biến số.

Trước tiên, hãy lưu:

• URL bị lỗi, gồm trang chủ, một trang con và /wp-admin.
• Thời điểm lỗi chính xác đến phút, kèm múi giờ.
• Ảnh chụp trang lỗi và response headers nếu lấy được.
• Thao tác diễn ra ngay trước lỗi, chẳng hạn cập nhật plugin, import dữ liệu, chạy backup hoặc gửi chiến dịch quảng cáo.
• Ảnh Resource Usage trong khoảng thời gian đó.
• Một bản backup file và database trước khi chỉnh mã nguồn, .htaccess, PHP hoặc database.

Các bước như thử trình duyệt khác, kiểm tra từ mạng di động, xem status code và chụp Resource Usage khá an toàn với người mới. Đổi tên plugin, sửa .htaccess, thay PHP version hoặc bật log cũng có thể làm được nếu có backup và ghi lại thay đổi. Sửa database, quyền sở hữu file, cấu hình PHP-FPM, web server hoặc xóa mã nghi nhiễm nên giao cho người có kinh nghiệm.

Tầng 1: xác định phạm vi lỗi

Câu hỏi đầu tiên không phải “plugin nào lỗi?” mà là “lỗi xảy ra ở đâu và với ai?”.

Một người hay mọi người đều gặp?

Thử bốn đường truy cập:

1. Trình duyệt ẩn danh trên máy hiện tại.
2. Một trình duyệt khác.
3. Điện thoại dùng 4G/5G, không dùng cùng Wi-Fi.
4. Một dịch vụ kiểm tra HTTP từ bên ngoài hoặc nhờ người ở mạng khác truy cập.

Nếu chỉ một thiết bị hoặc một mạng gặp lỗi, hãy kiểm tra cache trình duyệt, DNS resolver, extension, VPN, proxy và firewall cục bộ. Nếu nhiều mạng cùng gặp, khả năng lỗi nằm ở DNS/CDN/origin hoặc ứng dụng cao hơn.

Frontend hay wp-admin?

Kiểm tra ít nhất ba URL:

• Trang chủ.
• Một bài viết hoặc trang tĩnh.
• /wp-admin/ hoặc /wp-login.php.

Frontend hoạt động nhưng wp-admin lỗi thường hướng tới code chỉ chạy trong admin, plugin quản trị, PHP memory khi tải dashboard, cron hoặc truy vấn nặng. Nếu toàn bộ website lỗi, phạm vi rộng hơn: web server, PHP-FPM, .htaccess, tài nguyên, database hoặc mã nguồn được nạp ở mọi request.

Lỗi liên tục hay theo thời điểm?

Ghi lại tần suất. Lỗi cứ 5 phút hoặc trùng một khung giờ có thể liên quan tới cron, backup, scan bảo mật, import, bot hoặc đợt traffic. Lỗi xuất hiện ngay sau một thay đổi thì thay đổi đó là manh mối, chưa phải bằng chứng kết luận.

An toàn cho người mới: thử nhiều mạng, ghi URL và thời điểm, chụp màn hình.
Nên nhờ kỹ thuật: phân tích HAR, proxy chain hoặc lỗi chỉ tái hiện theo tài khoản và request cụ thể.

Tầng 2: DNS, CDN, proxy và SSL

DNS hoặc SSL thường tạo ra thông báo riêng, nhưng CDN và proxy có thể làm người quản trị nhìn thấy một trang 5xx không phản ánh trực tiếp lỗi WordPress.

Kiểm tra DNS có trả về đúng origin không

Đối chiếu bản ghi A/AAAA/CNAME hiện tại với máy chủ đang chạy website. Nếu vừa đổi DNS, một số resolver có thể còn cache bản ghi cũ. Trường hợp “mạng này vào được, mạng kia không” sau khi đổi IP rất đáng kiểm tra ở tầng này.

Nếu website có cả A và AAAA, đừng bỏ qua IPv6. A record đúng nhưng AAAA trỏ sai có thể tạo lỗi theo mạng hoặc thiết bị.

Phân biệt lỗi ở CDN và lỗi từ origin

Trong DevTools, mở tab Network, chọn request lỗi và lưu:

• HTTP status.
• Response headers.
• Server header, cache status và mã định danh như Cloudflare Ray ID nếu có.
• Nội dung trang lỗi, có thương hiệu CDN hay của web server.

Cloudflare lưu ý rằng 5xx có thể do edge tạo ra hoặc do origin trả về rồi được chuyển tiếp. Vì vậy cần kiểm tra cả edge status, origin status và các lớp load balancer, cache, proxy hoặc firewall. Không nên thấy logo Cloudflare rồi kết luận Cloudflare là nguyên nhân, cũng không nên mặc định mọi 500 đều từ WordPress.

Có thể tạm bypass CDN theo hướng dẫn của nhà cung cấp hoặc kiểm tra trực tiếp origin bằng phương pháp an toàn. Không sửa file hosts, pause CDN hay đổi DNS trên website đang có traffic nếu chưa hiểu tác động và chưa có kế hoạch hoàn tác.

Kiểm tra SSL theo từng chặng

Một website qua proxy có thể có hai kết nối TLS: người dùng tới CDN và CDN tới origin. Chứng chỉ ngoài trình duyệt còn hạn không chứng minh kết nối origin hoàn toàn bình thường. Hãy kiểm tra hostname, chuỗi chứng chỉ, ngày hết hạn và chế độ SSL/TLS tại proxy.

An toàn cho người mới: xem DNS công khai, chứng chỉ trên trình duyệt, DevTools và Ray ID.
Nên nhờ kỹ thuật: bypass origin, thay chế độ SSL, đổi nameserver hoặc chỉnh proxy đang phục vụ production.

Tầng 3: HTTP status, access log và error log

Đây là tầng thường rút ngắn thời gian chẩn đoán nhiều nhất. Một ảnh “HTTP ERROR 500” có ít giá trị hơn một dòng log đúng phút, đúng URL và đúng request.

Xác nhận status thực tế

Trình duyệt có thể hiện trang trắng, redirect loop hoặc trang lỗi tùy biến. Hãy xác nhận request cuối cùng thật sự là 500, 502, 503, 504 hay một mã khác. Các mã này dẫn tới hướng kiểm tra khác nhau.

Trong DevTools, bật Preserve log rồi tải lại trang. Kiểm tra request tài liệu chính và các request AJAX/REST. Có trường hợp trang chủ trả 200 nhưng /wp-admin/admin-ajax.php hoặc REST API trả 500, khiến dashboard trông như hỏng.

Ghép access log với error log

Tìm request theo thời điểm, URL, IP hoặc request ID. Sau đó đọc error log ở cùng giây. Tùy môi trường, log có thể nằm trong cPanel Metrics > Errors, file error_log, log PHP, PHP-FPM, LiteSpeed, Apache hoặc Nginx.

Một số mẫu có giá trị:

• Allowed memory size exhausted: script chạm giới hạn memory.
• Maximum execution time exceeded: xử lý quá thời gian cho phép.
• PHP Fatal error, Uncaught Error, TypeError: thường kèm file và dòng gây lỗi.
• upstream timed out, connection reset, Primary script unknown: xem PHP-FPM, proxy và đường dẫn cấu hình.
• Too many connections, server has gone away, lock timeout: xem database.
• Không có error log nhưng access log có 500: kiểm tra đúng log file, đúng virtual host và các lớp proxy phía trước.

WordPress có thể ghi lỗi vào wp-content/debug.log bằng WP_DEBUG_LOG. Trên production, không hiển thị lỗi ra màn hình. Bật log trong thời gian ngắn, tái hiện lỗi, lưu file rồi tắt khi xong để tránh log phình to hoặc chứa thông tin nhạy cảm.

An toàn cho người mới: xem log qua control panel, tải log về và che IP/token trước khi chia sẻ công khai.
Cần backup hoặc kỹ thuật: sửa wp-config.php, đổi cấu hình log của PHP/web server, thao tác log trên VPS.

Tầng 4: PHP version, PHP-FPM, memory limit và timeout

PHP “vẫn hoạt động” chỉ cho biết một request PHP đơn giản có thể chạy. WordPress có thể lỗi vì extension thiếu, plugin không tương thích, worker PHP-FPM bận hoặc script chạm giới hạn.

Đối chiếu PHP của web với PHP CLI

Trên VPS, phiên bản php -v ở terminal có thể khác phiên bản PHP phục vụ website. Trên hosting, kiểm tra PHP Selector hoặc MultiPHP Manager cho đúng domain. Đọc log trước khi đổi version. Nếu lỗi xuất hiện sau khi nâng PHP, hãy kiểm tra plugin/theme không tương thích rồi mới cân nhắc rollback có kiểm soát.

Memory limit không phải dung lượng hosting

Disk còn trống không có nghĩa PHP còn memory. Theo PHP Manual, memory_limit giới hạn lượng bộ nhớ một script được phép cấp phát. Một request có thể chạm giới hạn này dù tài khoản còn nhiều dung lượng ổ đĩa.

Tăng memory chỉ hợp lý khi log cho thấy Allowed memory size exhausted, và nên xem đó là biện pháp xác nhận hoặc giảm gián đoạn. Nếu phải tăng liên tục, cần tìm plugin, query, import, image processing hoặc vòng lặp đang tiêu thụ bất thường.

Timeout nằm ở nhiều lớp

max_execution_time của PHP chỉ là một giới hạn. Web server, PHP-FPM, reverse proxy và CDN có thể có timeout riêng. Tăng một con số lên rất cao có thể chỉ làm request treo lâu hơn và giữ worker lâu hơn.

Kiểm tra PHP-FPM

Trên VPS, kỹ thuật cần xem trạng thái service, worker pool, hàng đợi, pm.max_children, slow log và lần worker bị kill. Restart PHP-FPM có thể làm website hoạt động lại nhưng xóa mất triệu chứng tạm thời. Hãy lưu log và thông số trước khi restart nếu tình trạng cho phép.

An toàn cho người mới: xem PHP version, memory limit và lỗi trong control panel.
Nên backup: đổi PHP version, chỉnh .user.ini, php.ini hoặc wp-config.php.
Nên nhờ kỹ thuật: PHP-FPM pool, worker limits, slow log và restart service trên production.

Tầng 5: CPU, RAM, I/O, Entry Processes và tài nguyên hosting

Dung lượng ổ đĩa chỉ là một loại giới hạn. Shared hosting thường còn giới hạn CPU, physical memory, I/O, IOPS, số process và Entry Processes.

Đọc Resource Usage theo đúng thời điểm

Trong cPanel/CloudLinux, mở Resource Usage và chọn khung giờ chứa lỗi. Đừng chỉ nhìn trạng thái hiện tại sau khi website đã bình thường. Cần xem biểu đồ và số lần chạm giới hạn.

• CPU chạm trần: request xử lý chậm, hàng đợi tăng.
• Physical Memory chạm trần: process có thể bị kill hoặc không khởi tạo được.
• I/O hoặc IOPS chạm trần: đọc file, cache, backup và database trên disk bị chậm.
• Entry Processes chạm trần: tài khoản không nhận thêm đủ request đồng thời.
• Processes/NPROC chạm trần: tác vụ mới không tạo được như bình thường.

Một đợt backup, quét malware, import sản phẩm, cron hoặc bot crawl có thể làm biểu đồ tăng mạnh dù traffic người thật không đổi.

Đừng nâng hosting chỉ vì thấy một đỉnh tải

Một đỉnh đơn lẻ cần được ghép với access log và tác vụ tại thời điểm đó. Nếu một bot tạo hàng nghìn request vào URL tìm kiếm, nâng RAM không xử lý gốc vấn đề. Nếu plugin backup chạy cùng lúc với cron import, đổi lịch hoặc chuyển tác vụ ra ngoài giờ có thể hiệu quả hơn.

Ngược lại, nếu website đã tối ưu, tải hợp lệ tăng đều, các giới hạn CPU/RAM/EP bị chạm lặp lại và request không có lỗi code, nâng tài nguyên là quyết định có dữ liệu.

An toàn cho người mới: chụp toàn bộ Resource Usage theo 24 giờ hoặc 7 ngày, ghi lại giờ chạm giới hạn.
Nên nhờ kỹ thuật: phân tích process, slow request, I/O và phân bổ worker.

Tầng 6: plugin, theme, .htaccess, WordPress core và file permissions

Chỉ đến tầng này mới bắt đầu thay đổi mã nguồn WordPress. Lý do là lúc này đã có phạm vi lỗi, status, log và dữ liệu tài nguyên để kiểm tra có mục tiêu.

Khi không vào được wp-admin, vô hiệu plugin bằng File Manager

WordPress Documentation hướng dẫn có thể đổi tên thư mục wp-content/plugins để vô hiệu toàn bộ plugin khi không vào được màn hình quản trị.

Quy trình an toàn:

1. Tạo backup file và database.
2. Ghi lại tên thư mục hiện tại.
3. Đổi plugins thành plugins.hold.
4. Thử lại trang chủ và /wp-admin.
5. Đổi tên lại thành plugins.
6. Nếu lỗi biến mất, kích hoạt hoặc kiểm tra từng plugin để tìm plugin gây lỗi.

Đừng xóa thư mục plugin. Một số plugin có drop-in, MU plugin, cache hoặc rule ngoài thư mục plugin nên việc đổi tên không loại trừ được mọi trường hợp.

Kiểm tra theme

Nếu log trỏ vào theme hoặc tắt plugin không thay đổi gì, có thể đổi tên thư mục theme đang dùng để WordPress chuyển sang theme mặc định đã cài sẵn. Chỉ làm khi đã có backup và chắc chắn website có một theme mặc định hợp lệ.

Kiểm tra .htaccess

Với Apache hoặc LiteSpeed, đổi tên .htaccess để kiểm tra là cách có thể hoàn tác. Hãy giữ bản cũ, không xóa. Nếu website hoạt động lại, tạo rule WordPress mới và khôi phục có chọn lọc các rule bảo mật, cache hoặc redirect cần thiết. Với Nginx thuần, .htaccess không được sử dụng nên thao tác này không giúp chẩn đoán.

WordPress core

Nếu checksum hoặc log cho thấy file core hỏng, có thể thay lại wp-admin và wp-includes từ đúng bản WordPress sạch. Không ghi đè wp-content hoặc wp-config.php. Việc này nên làm ở staging hoặc có backup và người biết cách rollback.

File permissions và ownership

WordPress không yêu cầu chmod 777. Tài liệu WordPress cảnh báo quyền 777 cho phép đối tượng khác ghi hoặc thực thi file, làm tăng rủi ro chiếm quyền website. Quyền phù hợp còn phụ thuộc web server, PHP handler, owner và group. Không chạy lệnh find ... chmod hàng loạt nếu chưa xác định đúng document root và ownership.

An toàn tương đối: đổi tên một thư mục plugin hoặc .htaccess khi đã backup và biết cách đổi lại.
Nên nhờ kỹ thuật: sửa core, ownership, permission hàng loạt, MU plugin, object cache drop-in và rule web server.

Tầng 7: database, cron, bot và mã độc

Đây là tầng dễ bị bỏ qua khi website chỉ lỗi theo lúc.

Database

Kiểm tra log kết nối và slow query. Database có thể vẫn “up” nhưng hết connection, có query khóa bảng, query kéo dài hoặc bảng lỗi. Không tự chạy repair/optimize hàng loạt trên database production. WordPress khuyến nghị luôn có backup database hiện hành trước khi sửa bảng.

Dấu hiệu cần xem sâu:

• Error establishing a database connection xuất hiện xen kẽ.
• Too many connections.
• MySQL server has gone away.
• Lock wait timeout hoặc deadlock.
• /wp-admin chậm hơn frontend do dashboard chạy nhiều query.

WP-Cron và tác vụ nền

WP-Cron được kích hoạt theo lượt truy cập. Một lịch chạy dày, job bị kẹt hoặc nhiều plugin cùng lên lịch có thể tạo tải đột biến. Đối chiếu thời điểm lỗi với backup, email queue, đồng bộ tồn kho, import feed, tạo thumbnail và quét bảo mật.

Không tắt WP-Cron chỉ để thử rồi bỏ quên. Nếu chuyển sang system cron, cần chắc rằng cron mới chạy đúng và có theo dõi lỗi.

Bot và traffic bất thường

Xem top URL, user agent và IP trong access log. Bot có thể đánh vào trang tìm kiếm, XML-RPC, endpoint REST, trang đăng nhập hoặc URL tạo query nặng. Chặn theo dữ liệu và theo phạm vi, tránh chặn toàn bộ crawler hợp lệ hoặc người dùng thật.

Mã độc

Mã độc có thể chèn code vào plugin, theme, wp-config.php, .htaccess, MU plugin hoặc cron. Dấu hiệu gồm file lạ mới xuất hiện, tài khoản admin không rõ nguồn, redirect ngẫu nhiên, process bất thường và file core sai checksum.

Quét malware chỉ là bước phát hiện. Nếu nhiễm thật, cần cô lập, lưu bằng chứng, đổi toàn bộ credential liên quan, thay file sạch, rà tài khoản và xác định đường xâm nhập. Khôi phục một file bị chèn mà không đóng lỗ hổng sẽ khiến mã độc quay lại.

An toàn cho người mới: xuất danh sách cron, xem access log và tài khoản admin.
Nên nhờ kỹ thuật: repair database, xử lý lock, chặn bot ở server/CDN và làm sạch mã độc.

Quy trình xử lý nhanh khi không vào được wp-admin

Nếu cần đưa website về trạng thái truy cập được để tiếp tục chẩn đoán, hãy đi theo thứ tự này:

1. Chụp lỗi, ghi URL và thời điểm.
2. Thử bằng 4G/5G và một trình duyệt ẩn danh để xác định phạm vi.
3. Mở DevTools, xác nhận status của tài liệu chính, /wp-admin và request AJAX/REST bị lỗi.
4. Kiểm tra Resource Usage đúng khung giờ.
5. Đọc error log và debug.log nếu đã bật an toàn.
6. Tạo backup file và database.
7. Nếu log hoặc thời điểm thay đổi hướng tới plugin, đổi tên wp-content/plugins rồi thử lại.
8. Nếu vẫn lỗi và server dùng Apache/LiteSpeed, đổi tên .htaccess, thử lại rồi hoàn tác nếu không có thay đổi.
9. Kiểm tra PHP version, memory/timeout từ log và sự kiện update gần nhất.
10. Gửi support gói dữ liệu đã thu thập. Không tiếp tục thay nhiều thứ cùng lúc.

Mỗi lần chỉ thay một biến. Ghi lại kết quả và hoàn tác trước khi thử bước khác. Cách này chậm hơn vài phút nhưng tránh biến một lỗi có log rõ ràng thành nhiều lỗi chồng lên nhau.

Dữ liệu nên gửi cho support

Một ticket tốt giúp kỹ thuật đi thẳng vào đúng log và đúng tài khoản:

• Domain và URL cụ thể bị lỗi.
• Frontend, wp-admin hay cả hai.
• Thời điểm gần nhất xảy ra lỗi, ghi rõ múi giờ.
• Lỗi liên tục hay chập chờn, tần suất ước tính.
• Ảnh trang lỗi và HTTP status.
• Response headers hoặc Ray ID nếu dùng Cloudflare.
• IP public của người gặp lỗi, nếu chính sách hỗ trợ yêu cầu.
• Ảnh Resource Usage bao gồm CPU, memory, I/O, IOPS, EP và process.
• 20 đến 50 dòng log quanh thời điểm lỗi, đã che token, cookie và dữ liệu nhạy cảm.
• Thay đổi gần nhất: plugin/theme/core, PHP, DNS/CDN, import, backup hoặc code deploy.
• Những bước đã thử và kết quả từng bước.
• Xác nhận đã có backup và phạm vi support được phép can thiệp.

Không gửi mật khẩu WordPress, cPanel, database hoặc API key qua bình luận công khai. Dùng kênh hỗ trợ bảo mật do nhà cung cấp chỉ định.

Khi nào tối ưu, khi nào nâng hosting, khi nào cần VPS hoặc Cloud?

Tối ưu mã nguồn trước khi nâng

Ưu tiên tối ưu khi log chỉ ra một plugin, query, cron, bot hoặc tác vụ cụ thể gây tải. Các việc thường có hiệu quả gồm thay plugin nặng, sửa query, giảm cron trùng, cache đúng lớp, chặn bot có dữ liệu, tối ưu ảnh và tách tác vụ import/backup khỏi giờ cao điểm.

Nếu request lỗi vì fatal error hoặc code không tương thích PHP, thêm CPU và RAM không sửa được code.

Nâng hosting khi bottleneck đã được đo

Nâng gói hợp lý khi workload là hợp lệ, website đã được rà lỗi, và Resource Usage cho thấy CPU, RAM, I/O hoặc Entry Processes chạm giới hạn lặp lại trong giờ có traffic thật. Nên so sánh trước và sau bằng cùng một chỉ số: tỷ lệ 5xx, thời gian phản hồi, lượt chạm giới hạn và thời gian xử lý request.

Với website WordPress nhỏ và vừa cần tài nguyên cao hơn nhưng chưa cần quyền root, có thể xem cấu hình hiện hành của Pro Platinum Hosting. Trang live của AZDIGI mô tả đây là shared hosting hiệu năng cao cho blog, website doanh nghiệp, cửa hàng nhỏ và website ưu tiên hiệu năng. Việc chuyển gói không bảo đảm xử lý mọi lỗi 500, nhất là lỗi code, database hoặc cấu hình.

Chọn Business Hosting khi muốn môi trường managed

Business Hosting phù hợp khi website doanh nghiệp quan trọng cần môi trường hosting được quản lý, dùng control panel và không muốn tự vận hành hệ điều hành. Đây vẫn là hosting có giới hạn theo gói. Hãy dựa vào workload và phạm vi hỗ trợ, không dựa vào tên gói.

Chọn VPS hoặc Cloud khi cần quyền kiểm soát hệ thống

VPS hoặc Cloud phù hợp khi cần quyền root, phần mềm riêng, worker nền, queue, cấu hình web server/PHP-FPM đặc thù, tách database hoặc kiểm soát tài nguyên ở mức máy chủ. Đổi lại, bạn phải tự quản trị hoặc thuê dịch vụ managed. Chuyển một website chưa được tối ưu sang VPS có thể chỉ chuyển bottleneck sang một máy chủ khó vận hành hơn.

FAQ

Lỗi 500 Internal Server Error trên WordPress là gì?

Đây là phản hồi cho biết server gặp một điều kiện ngoài dự kiến và không thể hoàn thành request. Mã 500 không tự chỉ ra plugin, file hay tài nguyên nào gây lỗi, vì vậy cần đọc log và khoanh vùng theo request.

Vì sao trang chủ vào được nhưng wp-admin báo lỗi 500?

Code chỉ chạy trong khu vực quản trị, plugin dashboard, AJAX/REST, cron, memory hoặc query nặng có thể chỉ được kích hoạt khi mở wp-admin. Hãy kiểm tra request lỗi trong DevTools và error log đúng thời điểm.

Không vào được wp-admin thì tắt plugin bằng cách nào?

Sau khi backup, dùng File Manager hoặc FTP đổi tên thư mục wp-content/plugins thành tên tạm như plugins.hold, thử truy cập lại rồi đổi tên về. Nếu lỗi biến mất, kiểm tra từng plugin. Đây cũng là phương pháp được WordPress Documentation hướng dẫn.

Lỗi 500 có phải do hosting yếu không?

Có thể, nhưng chưa đủ dữ liệu để kết luận. Hãy xem Resource Usage và log cùng thời điểm. Lỗi code, plugin, .htaccess, PHP, database, CDN hoặc mã độc vẫn có thể tạo status 500 dù tài nguyên chưa chạm trần.

Tăng PHP memory limit có sửa được lỗi 500 không?

Chỉ nên tăng khi log cho thấy script đã hết memory. Nếu tăng memory làm lỗi biến mất, vẫn cần tìm tác vụ tiêu thụ bất thường. Tăng giới hạn không sửa được fatal error, query lỗi, plugin không tương thích hay database mất kết nối.

Có nên đặt chmod 777 để hết lỗi 500 không?

Không. WordPress cảnh báo 777 cho phép đối tượng khác ghi hoặc thực thi file, làm tăng rủi ro bảo mật. Quyền đúng phụ thuộc owner, group, web server và PHP handler. Hãy nhờ kỹ thuật kiểm tra ownership và permission thay vì mở toàn bộ quyền.

Kết luận và CTA

Lỗi 500 chập chờn cần được xử lý như một bài toán thu thập bằng chứng. Bắt đầu từ phạm vi lỗi, đi qua DNS/CDN, status và log, PHP, tài nguyên, mã nguồn rồi mới tới database, cron, bot và mã độc. Khi đã biết bottleneck nằm ở đâu, quyết định tối ưu hay nâng hạ tầng sẽ rõ ràng hơn.

Nếu cần AZDIGI hỗ trợ khoanh vùng, hãy gửi URL bị lỗi, thời điểm phát sinh, ảnh Resource Usage và đoạn log liên quan. Đội ngũ kỹ thuật có thể dựa trên các dữ liệu này để kiểm tra trước khi tư vấn nâng gói. Chuyển hosting hoặc tăng cấu hình không được xem là cách sửa mặc định cho mọi lỗi 500.