Lỗi HTTP 503 Service Unavailable: nguyên nhân và cách khắc phục

Lỗi HTTP 503 là gì?

503 Service Unavailable nghĩa là máy chủ, hoặc thứ gì đó phía trước nó, không thể xử lý yêu cầu của bạn lúc này: quá tải, đang bảo trì, đang giới hạn tốc độ, hoặc không có backend khỏe mạnh để chuyển yêu cầu tới. RFC 9110 định nghĩa đây là tình trạng tạm thời, nhiều khả năng sẽ hết sau một khoảng thời gian.

Máy chủ có thể thêm header Retry-After cho biết cần chờ bao lâu. Khác với 500, nghĩa là có thứ gì đó bị hỏng, 503 nói "chưa phải lúc này", nên các website dùng nó cho bảo trì có kế hoạch.

Thường người trả lời không phải web server của bạn mà là một lớp phía trước: load balancer như HAProxy, cache như Varnish, CDN như Cloudflare, hoặc Kubernetes ingress. Cách diễn đạt chính xác của thông báo cho biết đó là lớp nào (xem bên dưới).

Lỗi 503 trông như thế nào

Thông báo cho biết lớp nào đã trả lời. Dưới đây là những thông báo phổ biến cùng phần mềm tạo ra chúng:

Dù thông báo viết thế nào, ý nghĩa vẫn như nhau: yêu cầu này lúc này không thể phục vụ, và lớp được nêu trong bảng là nơi cần kiểm tra.

Nguyên nhân phổ biến của lỗi HTTP 503

Những lý do thường gặp khiến máy chủ hoặc một lớp phía trước trả về 503:

• Quá tải — chạm giới hạn CPU, bộ nhớ hoặc số kết nối khi lưu lượng tăng đột biến, bài viết lan truyền hoặc một crawler hung hăng
• Bảo trì có kế hoạch — website cố ý ngừng để cập nhật hoặc di chuyển; nếu làm đúng thì kèm header Retry-After
• Không có backend khỏe mạnh — load balancer, proxy hoặc ingress không có máy chủ nào hoạt động để chuyển yêu cầu tới (ứng dụng crash, health check thất bại, không có pod sẵn sàng)
• Giới hạn tốc độ và số kết nối — limit_req và limit_conn của nginx mặc định trả về 503, nên một client hoặc crawler bận rộn có thể gây ra lỗi này
• Ứng dụng bị crash hoặc dừng — PHP-FPM, Node.js hay Python ngừng chạy phía sau một web server vẫn hoạt động; trên IIS là một application pool đã dừng
• Giới hạn tài nguyên của hosting — hosting chia sẻ giới hạn CPU, bộ nhớ và số tiến trình theo từng tài khoản
• Plugin, theme hoặc bản cập nhật — trên WordPress và các CMS khác, một bản cập nhật lỗi có thể làm ứng dụng crash hoặc để website kẹt ở chế độ bảo trì
• Tấn công — DDoS hoặc bot tràn vào làm cạn đúng những tài nguyên mà một đợt tăng lưu lượng sẽ làm cạn

Cách khắc phục cho người truy cập

Nếu bạn đang truy cập website của người khác, vấn đề nằm ở phía họ. Những việc bạn có thể làm:

• Chờ rồi thử lại — 503 được thiết kế để tạm thời; hãy chờ một phút rồi tải lại một lần. Nếu trang hiện thời gian Retry-After hoặc thông báo bảo trì, hãy chờ đúng khoảng đó
• Kiểm tra xem trang có sập với mọi người không — Kiểm tra web sập của DNS Robot kiểm tra trang từ bên ngoài mạng của bạn
• Xem trang trạng thái hoặc tài khoản mạng xã hội của website — bảo trì có kế hoạch và sự cố thường được thông báo
• Thử mạng khác — nếu trang tải được bằng dữ liệu di động, thì hoặc VPN/proxy trên mạng quen thuộc của bạn đang trả về 503, hoặc website đang giới hạn địa chỉ IP của bạn

Cách 1: tìm xem lớp nào đã gửi lỗi 503

Trước khi khởi động lại bất cứ thứ gì, hãy xem thông báo và các header phản hồi: chúng cho biết lớp nào đã trả lời. Kiểm tra từ bên ngoài bằng Kiểm tra HTTP Header của DNS Robot hoặc curl -sI, rồi xem header server và nội dung trang (xem bảng ở trên).

Sau đó hãy khởi động lại đúng lớp đang lỗi, không chỉ web server:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Nếu 503 quay lại chỉ vài phút sau khi khởi động lại, nguyên nhân vẫn còn: chuyển sang kiểm tra tài nguyên và nhật ký.

Cách 2: kiểm tra tài nguyên máy chủ (CPU, RAM, Ổ đĩa)

Nếu máy chủ bị quá tải, khởi động lại chỉ giúp tạm thời. Hãy kiểm tra xem tài nguyên nào đang bị tiêu thụ.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Nếu CPU hoặc RAM đạt trên 90%, bạn cần tối ưu hóa ứng dụng, tắt các tiến trình chạy lạc hoặc nâng cấp máy chủ. Nếu ổ đĩa đầy, hãy xóa tệp nhật ký, bản sao lưu cũ hoặc tệp tạm.

Cách 3: kiểm tra nhật ký lỗi

Nhật ký cho biết chính xác vì sao 503 xảy ra. Hãy đọc những dòng mới nhất bằng các lệnh bên dưới, rồi tìm trong đó các mục sau:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

"limiting requests" hoặc "limiting connections" (nginx) — limit_req hoặc limit_conn đã từ chối yêu cầu; nó trả về 503 trừ khi bạn đặt limit_req_status hoặc limit_conn_status.

"max_children" (PHP-FPM, ví dụ "server reached pm.max_children setting") — mọi worker PHP đều đang bận: Apache trả về 503, còn nginx trả về 502 hoặc 504.

"AH01114" / "failed to make connection to backend" (Apache mod_proxy) — Apache không kết nối được tới backend và trả về 503.

"Too many connections" (MySQL) — đã dùng hết giới hạn kết nối của cơ sở dữ liệu.

"no live upstreams" và "upstream timed out" của nginx thuộc về 502 Bad Gateway và 504 Gateway Timeout, không phải 503.

Cách 4: tắt plugin và theme (WordPress / CMS)

Trên WordPress và các CMS khác, một plugin nặng có thể làm cạn worker PHP hoặc giới hạn tài nguyên của hosting, dẫn đến 503 (plugin bị crash thì cho 500). Nếu 503 bắt đầu sau khi cập nhật hoặc cài plugin, hãy bắt đầu từ plugin đó.

Nếu không vào được trang quản trị WordPress, hãy tắt plugin qua hệ thống tệp hoặc cơ sở dữ liệu.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Sau khi tìm ra plugin lỗi, hãy cập nhật nó, thay bằng plugin khác hoặc liên hệ nhà phát triển. Cũng hãy kiểm tra phiên bản PHP có tương thích không: một số plugin hỏng khi máy chủ nâng cấp PHP.

Bị kẹt ở "Briefly unavailable for scheduled maintenance"? WordPress tạo tệp .maintenance trong thư mục gốc của website khi cập nhật và bỏ qua nó khi tệp đã quá 10 phút. Hãy xóa tệp này để trở lại sớm hơn; nếu thông báo vẫn còn, hãy tìm tệp wp-content/maintenance.php hoặc bản sao đã cache của trang.

Cách 5: tăng giới hạn PHP và máy chủ

Nếu máy chủ hết PHP worker hoặc đạt giới hạn bộ nhớ, bạn cần tăng các giới hạn trong cấu hình.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Sau đó hãy khởi động lại PHP-FPM (sudo systemctl restart php8.2-fpm, với phiên bản của bạn) để các giới hạn mới có hiệu lực.

Cách 6: kiểm tra CDN hoặc load balancer

Nếu bạn dùng Cloudflare, một CDN khác hoặc load balancer, lỗi 503 có thể đến từ chúng chứ không phải từ máy chủ của bạn.

Quy tắc của Cloudflare (hướng dẫn về lỗi 503):

• Trang có chứa "cloudflare" hoặc "cloudflare-nginx" — Cloudflare đã tạo ra trang này: hãy kiểm tra xem có Worker nào vượt giới hạn CPU hoặc bộ nhớ không, rồi liên hệ hỗ trợ Cloudflare kèm kết quả của /cdn-cgi/trace
• Không có dấu hiệu của Cloudflare — máy chủ origin của bạn đã trả về 503 và Cloudflare chỉ chuyển tiếp: hãy kiểm tra nhật ký origin và hỏi nhà cung cấp hosting xem họ có giới hạn các địa chỉ IP của Cloudflare không

Với HAProxy, load balancer trên đám mây hoặc Kubernetes ingress, hãy kiểm tra các backend: ở đó 503 thường nghĩa là không backend nào nhận được yêu cầu (với AWS Application Load Balancer là target group chưa đăng ký target nào). Tra Cứu DNS của DNS Robot xác nhận tên miền của bạn vẫn trỏ đúng nơi bạn mong đợi.

Cách 7: kiểm tra tấn công DDoS hoặc bot

Đột biến lưu lượng từ bot hoặc tấn công DDoS có thể làm quá tải máy chủ. Kiểm tra nhật ký truy cập để tìm các mẫu đáng ngờ.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Nếu một địa chỉ hoặc một dải nhỏ gửi hàng nghìn yêu cầu, hãy chặn nó ở tường lửa. Phía sau Cloudflare hoặc CDN khác, trước hết hãy làm cho nhật ký hiển thị IP thật của khách truy cập (set_real_ip_from cùng real_ip_header CF-Connecting-IP trong nginx), nếu không bạn sẽ chặn nhầm CDN thay vì kẻ tấn công. Với cuộc tấn công lớn, chế độ "I'm Under Attack" của Cloudflare hoặc dịch vụ chống DDoS của nhà cung cấp hosting sẽ lọc lưu lượng trước khi nó đến máy chủ của bạn.

Cách 8: khắc phục sự cố kết nối cơ sở dữ liệu

Khi cơ sở dữ liệu hết kết nối hoặc ngừng hoạt động, ứng dụng phía trước nó có thể lỗi. Một số ứng dụng trả về 503; WordPress thì hiện "Error establishing a database connection". Hãy kiểm tra trực tiếp cơ sở dữ liệu:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Nếu bạn thấy nhiều kết nối đang ở trạng thái sleeping, ứng dụng của bạn không đóng kết nối cơ sở dữ liệu đúng cách. Nếu các truy vấn chạy quá lâu đang chặn các truy vấn khác, hãy tối ưu hóa chúng hoặc tắt chúng để giải phóng cơ sở dữ liệu.

Cách 9: liên hệ nhà cung cấp hosting

Nếu bạn sử dụng hosting chia sẻ, hosting WordPress quản lý, hoặc nền tảng như Squarespace, Wix hay Shopify, bạn có thể không có quyền truy cập nhật ký máy chủ hoặc khả năng khởi động lại dịch vụ. Trong trường hợp này, lỗi 503 có thể do hạ tầng của nhà cung cấp hosting.

Hãy liên hệ bộ phận hỗ trợ của nhà cung cấp hosting và cung cấp:

• URL chính xác trả về lỗi 503
• Thời điểm lỗi bắt đầu — ghi rõ ngày và giờ
• Những gì đã thay đổi — bạn có cài plugin, cập nhật theme hoặc thay đổi cài đặt DNS không?
• Lỗi xảy ra liên tục hay ngắt quãng — lỗi 503 ngắt quãng gợi ý giới hạn tài nguyên; lỗi 503 liên tục gợi ý crash hoặc cấu hình sai

So sánh 503 với các lỗi HTTP khác

Lỗi 503 thường bị nhầm lẫn với các lỗi máy chủ khác. Dưới đây là sự khác biệt giữa chúng.

Điểm khác biệt chính: 503 được thiết kế để tạm thời, và header Retry-After có thể cho biết tình trạng kéo dài bao lâu. Với việc thu thập dữ liệu, Google xử lý lỗi 5xx và 429 tương tự nhau: crawler chậm lại, các URL đã lập chỉ mục được giữ một thời gian nhưng cuối cùng sẽ bị loại nếu lỗi kéo dài (Google Search Central).

Với các lỗi phía proxy, xem 502 Bad Gateway và 504 Gateway Timeout; với giới hạn tốc độ, xem 429 Too Many Requests.

Cách phòng ngừa lỗi 503

Phòng bệnh hơn chữa bệnh. Dưới đây là các phương pháp tốt nhất để tránh lỗi 503.

• Giám sát tài nguyên máy chủ — Thiết lập cảnh báo khi CPU > 80%, RAM > 85% và ổ đĩa > 90%. Các công cụ như UptimeRobot, Pingdom hoặc Grafana cung cấp thông báo tức thì.
• Sử dụng CDN — Cloudflare, Fastly hoặc AWS CloudFront lưu cache tài nguyên tĩnh và hấp thụ đột biến lưu lượng, giảm tải cho máy chủ origin.
• Bật bộ nhớ đệm — Sử dụng Redis, Memcached hoặc Varnish để cache truy vấn cơ sở dữ liệu và trang đã render. Người dùng WordPress: cài plugin cache như WP Super Cache hoặc W3 Total Cache.
• Tự động mở rộng — Nếu bạn sử dụng hosting đám mây (AWS, GCP, Azure, DigitalOcean), cấu hình auto-scaling để thêm máy chủ khi có đột biến lưu lượng.
• Giới hạn tốc độ bot — Cấu hình Nginx hoặc Cloudflare để giới hạn tốc độ cho crawler và scraper trước khi chúng làm quá tải máy chủ.
• Tối ưu hóa truy vấn cơ sở dữ liệu — truy vấn chậm giữ kết nối và worker ở trạng thái mở. Thêm chỉ mục, tối ưu join và cache kết quả trong Redis hoặc Memcached.
• Sử dụng trang bảo trì đúng cách — Trong quá trình triển khai, trả về 503 kèm header Retry-After thay vì để máy chủ crash. Điều này giữ được SEO và thông báo cho người dùng.
• Cập nhật phần mềm — Cập nhật CMS, plugin, PHP và cơ sở dữ liệu lên phiên bản ổn định mới nhất để tránh bug và lỗ hổng bảo mật đã biết.