Lỗi 504 Gateway Timeout: Nguyên nhân và Cách khắc phục

Lỗi 504 Gateway Timeout là gì?

504 Gateway Timeout là mã trạng thái HTTP cho biết máy chủ đang hoạt động như gateway hoặc proxy không nhận được phản hồi kịp thời từ upstream server. Proxy đã chờ upstream phản hồi, nhưng quá lâu nên proxy từ bỏ và trả về lỗi 504 cho trình duyệt của bạn.

Định nghĩa chính thức đến từ RFC 9110 (HTTP Semantics), Mục 15.6.5: "Mã trạng thái 504 (Gateway Timeout) cho biết máy chủ, khi hoạt động như gateway hoặc proxy, không nhận được phản hồi kịp thời từ upstream server mà nó cần truy cập để hoàn thành yêu cầu."

Từ khóa quan trọng là gateway. Lỗi 504 luôn liên quan đến ít nhất hai máy chủ: máy chủ bạn kết nối đến (proxy/gateway) và máy chủ phía sau nó (upstream/origin) đã không phản hồi. Các proxy phổ biến bao gồm Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB) và CloudFront.

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

Thông báo lỗi 504 khác nhau tùy thuộc vào trình duyệt, web server và CDN. Dưới đây là những thông báo phổ biến nhất bạn sẽ gặp.

• 504 Gateway Timeout

• 504 Gateway Time-out (Nginx mặc định -- có dấu gạch ngang)

• HTTP Error 504 — Gateway Timeout

• Trang này không hoạt động -- [tên miền] mất quá nhiều thời gian để phản hồi (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — The server didn't respond in time (Apache với mod_proxy)

• Error 524: A timeout occurred (Riêng Cloudflare -- về mặt kỹ thuật không phải 504, nhưng cùng nguyên nhân gốc)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Bất kể nội dung thông báo là gì, nguyên nhân cơ bản luôn giống nhau: proxy server đã chờ upstream server phản hồi và upstream server đã không phản hồi trong khoảng thời gian timeout được cấu hình.

Lỗi 504 Gateway Timeout xảy ra như thế nào

Để hiểu lỗi 504, bạn cần hiểu chuỗi timeout giữa trình duyệt và origin server. Một yêu cầu web thông thường đi qua nhiều lớp, và mỗi lớp có cài đặt timeout riêng.

Luồng yêu cầu điển hình: Trình duyệt → CDN (Cloudflare) → Load Balancer → Nginx → PHP-FPM → Cơ sở dữ liệu. Nếu truy vấn cơ sở dữ liệu mất 90 giây và proxy_read_timeout của Nginx được đặt là 60 giây, Nginx sẽ ngừng chờ và trả về 504 cho load balancer, rồi truyền lại cho trình duyệt của bạn.

Máy chủ trả về 504 luôn là máy chủ trung gian (proxy hoặc gateway), không bao giờ là origin server. Origin server đơn giản là không phản hồi kịp thời -- nó có thể vẫn đang xử lý yêu cầu, hoặc có thể đã bị crash hoàn toàn.

Nguyên nhân phổ biến của lỗi 504 Gateway Timeout

Hiểu rõ nguyên nhân gốc là con đường nhanh nhất để khắc phục. Dưới đây là những lý do phổ biến nhất khiến máy chủ trả về 504, được xếp theo tần suất xuất hiện.

• Origin server chậm -- Script PHP chạy truy vấn cơ sở dữ liệu phức tạp, tạo báo cáo hoặc gọi API bên thứ ba chậm có thể vượt quá timeout của proxy. Đây là nguyên nhân số 1 gây lỗi 504.

• Quá tải máy chủ -- CPU 100%, hết bộ nhớ (OOM kill), hoặc tất cả worker PHP-FPM đều bận. Origin server vẫn hoạt động nhưng quá tải để phản hồi kịp thời.

• Tắc nghẽn cơ sở dữ liệu -- Truy vấn SQL chậm, thiếu index, khóa bảng hoặc cạn kiệt connection pool. Ứng dụng bị treo khi chờ cơ sở dữ liệu, và proxy hết thời gian chờ.

• Cấu hình timeout sai -- proxy_read_timeout của Nginx được đặt quá thấp cho backend thực sự cần nhiều thời gian hơn (ví dụ: trình tạo báo cáo hoặc xử lý upload tệp).

• Vấn đề mạng giữa proxy và origin -- Mất gói tin, độ trễ cao hoặc sự cố định tuyến giữa các data center. Phổ biến trong môi trường đa vùng hoặc hybrid cloud.

• Firewall hoặc security group chặn lưu lượng -- AWS security group không cho phép lưu lượng trên cổng tạm thời, quy tắc iptables chặn kết nối nội bộ, hoặc WAF chặn các yêu cầu upstream hợp lệ.

• DNS resolution thất bại tại proxy -- Proxy không thể phân giải hostname upstream. Trong Nginx, điều này xảy ra khi sử dụng biến trong proxy_pass mà không có chỉ thị resolver.

• CDN timeout -- Cloudflare có giới hạn cứng 100 giây trên gói Free/Pro/Business. Nếu origin mất hơn 100 giây, Cloudflare trả về Error 524 bất kể cấu hình Nginx của bạn.

• Tấn công DDoS -- Lượng lớn yêu cầu làm cạn kiệt tài nguyên máy chủ, khiến origin quá chậm để phản hồi lưu lượng hợp lệ trong thời gian timeout của proxy.

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

Nếu bạn thấy lỗi 504 trên trang web của người khác, vấn đề nằm ở phía máy chủ -- không phải thiết bị của bạn. Tuy nhiên, có một vài điều bạn có thể thử.

• Đợi và tải lại -- Hầu hết lỗi 504 là tạm thời. Đợi 30-60 giây, sau đó tải lại cứng bằng Ctrl+Shift+R (Windows/Linux) hoặc Cmd+Shift+R (Mac).

• Kiểm tra trang web có bị sập cho mọi người không -- Sử dụng công cụ HTTP Headers của DNS Robot để kiểm tra mã phản hồi của máy chủ từ vị trí bên ngoài. Nếu trả về 504 cho mọi người, vấn đề nằm ở phía máy chủ.

• Thử chế độ ẩn danh hoặc trình duyệt khác -- Loại trừ tiện ích mở rộng trình duyệt, trang lỗi đã cache và các vấn đề cấu hình cục bộ.

• Thử mạng khác -- Chuyển từ Wi-Fi sang dữ liệu di động, hoặc tắt VPN. Vấn đề định tuyến giữa ISP và máy chủ đôi khi có thể gây ra 504.

• Xóa bộ nhớ đệm DNS -- Bản ghi DNS cũ có thể định tuyến yêu cầu đến sai máy chủ. Trên Windows: ipconfig /flushdns. Trên Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Kiểm tra trang trạng thái hoặc mạng xã hội của trang web -- Có thể đã có thông báo về sự cố hoặc bảo trì đã biết.

Cách 1: Tăng cài đặt Timeout (Nginx & Apache)

Cách sửa phổ biến nhất cho lỗi 504 là tăng giá trị timeout trên reverse proxy. Nếu backend thực sự cần hơn 60 giây (mặc định), proxy cần được cấu hình để chờ lâu hơn.

# Nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_connect_timeout 300;
    proxy_send_timeout    300;
    proxy_read_timeout    300;
    send_timeout          300;
}

# Nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_read_timeout    300;
    fastcgi_send_timeout    300;
    fastcgi_connect_timeout 300;
    include fastcgi_params;
}

Với Apache sử dụng mod_proxy, thêm ProxyTimeout 300 trong VirtualHost hoặc sử dụng ProxyPass / http://backend:8080/ timeout=300 cho cấu hình riêng từng backend.

Quan trọng: Các timeout này đo thời gian giữa hai thao tác đọc/ghi liên tiếp, không phải tổng thời gian truyền tải. proxy_read_timeout 300 có nghĩa là "nếu không có dữ liệu nào đến trong 300 giây", không phải "toàn bộ phản hồi phải hoàn thành trong 300 giây". Sau khi thay đổi giá trị timeout, hãy reload cấu hình: sudo nginx -t && sudo systemctl reload nginx.

Cách 2: Tối ưu hóa Script chậm và Truy vấn cơ sở dữ liệu

Nếu backend liên tục vượt quá timeout, việc tăng giá trị timeout chỉ che giấu vấn đề. Giải pháp thực sự là làm cho backend phản hồi nhanh hơn.

• Tìm truy vấn chậm -- Bật slow query log của MySQL (slow_query_log = 1, long_query_time = 1) hoặc sử dụng EXPLAIN ANALYZE cho các truy vấn nghi ngờ. Thêm index bị thiếu, tránh SELECT * và phân trang cho tập kết quả lớn.

• Thêm bộ nhớ đệm -- Sử dụng Redis hoặc Memcached để cache kết quả truy vấn tốn kém. Truy vấn mất 5 giây mỗi lần tải trang nên được cache.

• Chuyển công việc nặng sang background job -- Tạo báo cáo, gửi email, xử lý hình ảnh và nhập dữ liệu nên chạy trong hàng đợi công việc (Celery, Sidekiq, Bull), không phải trong chu kỳ HTTP request.

• Tối ưu hóa lời gọi API -- Nếu backend gọi API bên thứ ba chậm, thêm timeout cho các lời gọi đó và triển khai circuit breaker để một API chậm không chặn tất cả các yêu cầu.

• Giảm truy vấn N+1 -- Truy vấn do ORM tạo ra thường tạo hàng trăm lời gọi cơ sở dữ liệu riêng lẻ. Sử dụng eager loading hoặc batch query để giảm số lượng round trip.

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

Nếu origin server bị quá tải, nó không thể xử lý yêu cầu đủ nhanh và proxy hết thời gian chờ. Hãy kiểm tra xem thứ gì đang tiêu thụ tài nguyên.

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

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

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

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

# Check active network connections
ss -s

Nếu CPU hoặc RAM đạt 90% trở lên, bạn cần tối ưu hóa ứng dụng, dừng các tiến trình chạy quá mức hoặc nâng cấp máy chủ. Nếu ổ đĩa đầy, hãy xóa các tệp log cũ, bản sao lưu hoặc tệp tạm -- ổ đĩa đầy có thể làm crash cơ sở dữ liệu và gây ra lỗi 504 dây chuyền.

Cách 4: Kiểm tra nhật ký lỗi

Nhật ký lỗi cho bạn biết chính xác tại sao proxy trả về 504. Luôn kiểm tra log trước khi đoán nguyên nhân.

# Nginx error log (look for "upstream timed out")
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

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Các thông báo log phổ biến gây ra 504:

"upstream timed out (110: Connection timed out)" (Nginx) -- Upstream server không phản hồi trong proxy_read_timeout. Tăng timeout hoặc sửa upstream chậm.

"server reached pm.max_children" (PHP-FPM) -- Tất cả tiến trình worker PHP đều bận. Tăng pm.max_children trong cấu hình pool PHP-FPM.

"connect() failed (111: Connection refused)" (Nginx) -- Upstream server không chạy hoặc không lắng nghe trên cổng mong đợi. Khởi động lại backend.

"Too many connections" (MySQL) -- Giới hạn kết nối cơ sở dữ liệu đã cạn kiệt. Tăng max_connections trong cấu hình MySQL hoặc tối ưu connection pooling.

Cách 5: Điều chỉnh cài đặt PHP-FPM

Với các ứng dụng PHP (WordPress, Laravel, Magento), PHP-FPM thường là điểm tắc nghẽn. Chuỗi timeout phải nhất quán: Nginx timeout ≥ PHP-FPM timeout ≥ PHP max_execution_time.

Sau khi thay đổi cài đặt PHP-FPM, khởi động lại dịch vụ: sudo systemctl restart php8.2-fpm. Đảm bảo fastcgi_read_timeout của Nginx luôn lớn hơn hoặc bằng max_execution_time của PHP. Nếu không, Nginx sẽ từ bỏ trước khi PHP hoàn thành, tạo ra lỗi 504.

Cách 6: Kiểm tra cấu hình CDN và Proxy

Nếu trang web của bạn nằm sau CDN như Cloudflare hoặc AWS CloudFront, CDN có cài đặt timeout riêng có thể ghi đè cấu hình máy chủ của bạn.

Người dùng Cloudflare: Nếu bạn đang dùng gói Free, Pro hoặc Business và origin mất hơn 100 giây, bạn sẽ luôn nhận Error 524. Các lựa chọn duy nhất là: tối ưu backend để phản hồi trong 100 giây, chuyển tác vụ chạy lâu sang background job, hoặc nâng cấp lên Enterprise.

Người dùng AWS CloudFront: Tăng origin response timeout trong cài đặt origin của distribution. Mặc định 30 giây thường quá thấp cho nội dung động.

Sử dụng công cụ HTTP Headers của DNS Robot để kiểm tra response header và xác định lớp nào đang trả về 504. Tìm các header như server: cloudflare, server: awselb/2.0, hoặc server: nginx để xác định proxy.

Cách 7: Giải pháp dành riêng cho WordPress

Trang WordPress đặc biệt dễ gặp lỗi 504 do plugin nặng, cơ sở dữ liệu phình to và giới hạn shared hosting. Dưới đây là các giải pháp nhắm mục tiêu cụ thể.

• Xác định plugin chậm -- Tắt tất cả plugin, sau đó bật lại từng cái một. Nếu không thể truy cập wp-admin, đổi tên thư mục plugins qua SSH: mv wp-content/plugins wp-content/plugins_disabled. Sử dụng plugin Query Monitor để xác định truy vấn cơ sở dữ liệu chậm.

• Tăng bộ nhớ PHP -- Thêm define('WP_MEMORY_LIMIT', '512M'); vào wp-config.php. Nhiều plugin cần hơn mức mặc định 128MB.

• Cài đặt plugin caching -- WP Super Cache, W3 Total Cache hoặc WP Rocket giảm xử lý phía máy chủ bằng cách phục vụ HTML tĩnh thay vì chạy PHP cho mỗi yêu cầu.

• Sử dụng object caching -- Cài đặt Redis hoặc Memcached và plugin WordPress object cache. Điều này cache kết quả truy vấn cơ sở dữ liệu trong bộ nhớ, giảm tải cho MySQL.

• Dọn dẹp cơ sở dữ liệu -- Xóa các bản sửa đổi bài viết cũ, transient, bình luận spam và metadata mồ côi. Sử dụng WP-Optimize hoặc WP-Sweep. Thêm define('WP_POST_REVISIONS', 5); để giới hạn số bản sửa đổi trong tương lai.

• Tắt wp-cron -- Cron ảo của WordPress chạy mỗi lần tải trang và có thể tích tụ các tác vụ. Thêm define('DISABLE_WP_CRON', true); vào wp-config.php và thiết lập cron job thực trên máy chủ: */5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1.

So sánh 504 với 502, 503 và 408: Sự khác biệt là gì?

Các mã lỗi HTTP này thường bị nhầm lẫn. Dưới đây là ý nghĩa thực sự của từng mã.

Sự khác biệt quan trọng: 502 nghĩa là proxy nhận được phản hồi sai, trong khi 504 nghĩa là proxy không nhận được phản hồi nào. 503 không cần proxy -- bất kỳ máy chủ nào cũng có thể trả về khi bị quá tải. 408 là timeout phía client (nhóm 4xx), khi máy chủ bỏ cuộc chờ client gửi yêu cầu.

Nếu bạn thấy 502 và 504 cùng lúc, upstream server có thể đang bị crash. Lỗi 502 xảy ra khi proxy nhận phản hồi một phần hoặc bị hỏng từ tiến trình đang chết, và 504 xảy ra khi tiến trình hoàn toàn không phản hồi.

Lỗi 504 có ảnh hưởng đến SEO không?

Câu trả lời ngắn: lỗi 504 ngắn hạn không ảnh hưởng SEO. Lỗi 504 kéo dài có thể dẫn đến việc bị xóa chỉ mục.

Vài phút đến vài giờ: Không ảnh hưởng. Google hiểu các lỗi máy chủ tạm thời và không phạt ngay lập tức. Nếu Googlebot không thu thập trong thời gian sự cố, nó sẽ không nhận ra.

Vài giờ đến vài ngày: Google giảm tần suất thu thập cho các trang web trả về lỗi 5xx để tránh tăng tải cho máy chủ đang gặp sự cố. Các trang có thể xuất hiện là "Server error (5xx)" trong báo cáo Page Indexing của Google Search Console.

Vài ngày đến vài tuần: Lỗi 504 kéo dài có thể dẫn đến xóa chỉ mục các trang bị ảnh hưởng. Thứ hạng giảm đáng kể. Theo John Mueller của Google: nếu máy chủ bị sập một ngày, tình hình có thể "bất ổn" trong một đến ba tuần sau khi phục hồi.

Phục hồi: Khi máy chủ ổn định trở lại, Google tự động thu thập lại và tái lập chỉ mục. Sử dụng công cụ URL Inspection trong Google Search Console để yêu cầu tái lập chỉ mục cho các trang quan trọng. Thời gian phục hồi phụ thuộc vào quy mô trang web và thời gian lỗi kéo dài.

Cách phòng ngừa lỗi 504 Gateway Timeout

Phòng bệnh hơn chữa bệnh. Các phương pháp tốt nhất dưới đây sẽ giúp máy chủ của bạn phản hồi trong giới hạn timeout.

• Thiết lập giám sát -- Sử dụng giám sát uptime (UptimeRobot, Pingdom hoặc công cụ Ping của DNS Robot) để phát hiện lỗi 504 trước khi người dùng báo cáo.

• Đồng bộ chuỗi timeout -- Đảm bảo CDN timeout ≥ proxy timeout ≥ application timeout. Giá trị không khớp gây ra lỗi 504 không thể dự đoán.

• Triển khai health check -- Load balancer và proxy nên kiểm tra sức khỏe upstream server và chuyển hướng lưu lượng khỏi các instance không phản hồi.

• Sử dụng caching tích cực -- Cache tài nguyên tĩnh, phản hồi API và truy vấn cơ sở dữ liệu. Phản hồi đã cache không bao giờ chậm đến mức gây ra 504.

• Tự động mở rộng -- Sử dụng mở rộng ngang (thêm instance) để đột biến lưu lượng không làm quá tải một máy chủ duy nhất.

• Chuyển công việc nặng ra ngoài -- Xử lý tệp, tạo báo cáo, gửi email và nhập dữ liệu hàng loạt nên chạy trong hàng đợi background job. Không bao giờ thực hiện công việc tốn kém bên trong HTTP request.

• Giám sát truy vấn chậm -- Bật slow query logging trong MySQL/PostgreSQL. Thiết lập cảnh báo cho truy vấn vượt quá 1 giây.

• Giữ cho các dependency khỏe mạnh -- Giám sát API bên thứ ba mà backend phụ thuộc. Thêm timeout và circuit breaker để một API chậm không gây ra lỗi 504 dây chuyền cho tất cả người dùng.