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.

RFC 9110 định nghĩa như sau: «Mã trạng thái 504 (Gateway Timeout) cho biết máy chủ, khi đóng vai trò gateway hoặc proxy, không nhận được phản hồi kịp thời từ máy chủ upstream mà nó cần truy cập để hoàn tất yêu cầu» (RFC 9110 §15.6.5).

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

Nội dung hiển thị tùy thuộc vào lớp nào đã bỏ cuộc:

• 504 Gateway Time-out kèm dòng «nginx» bên dưới — nginx (viết có dấu gạch ngang)
• 504 Gateway Time-out · The server didn't respond in time. — trang mặc định của HAProxy
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application. — Apache đứng trước PHP-FPM (mod_proxy_fcgi). Apache làm proxy cho backend HTTP thì hiện Proxy Error · Error reading from remote server (là 502).
• ERROR · The request could not be satisfied · 504 ERROR — Amazon CloudFront
• Error 524: A timeout occurred — phiên bản của Cloudflare: đã tới được máy chủ của bạn nhưng phản hồi không về kịp
• Trang này hiện không hoạt động · example.com mất quá nhiều thời gian để phản hồi. · Lỗi HTTP 504 — Chrome, khi lỗi 504 không có trang riêng

Dù hiển thị thế nào, nguyên nhân vẫn như nhau: một proxy chờ máy chủ phía sau và phản hồi không đến kịp. (Chrome dùng cùng câu «mất quá nhiều thời gian để phản hồi» khi trình duyệt của bạn hoàn toàn không kết nối được, nhưng khi đó tiêu đề là «Không thể truy cập trang web này» và mã là ERR_CONNECTION_TIMED_OUT, không phải Lỗi HTTP 504: xem ERR_CONNECTION_TIMED_OUT.)

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à máy chủ origin. 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 còn fastcgi_read_timeout của nginx là 60 giây, nginx ngừng chờ và trả 504 cho load balancer, rồi nó chuyển ngược qua CDN tới trình duyệt của bạn.

Máy chủ trả về 504 thường là một proxy ở giữa chứ không phải bản thân ứng dụng. Ứng dụng có thể vẫn đang xử lý yêu cầu, hoặc đã bị treo.

Nguồn: Cloudflare 524, cài đặt origin của CloudFront, Google Cloud và tài liệu của từng máy chủ. max_execution_time của PHP (30 giây) không gây ra 504: script chạm giới hạn này sẽ dừng với lỗi nghiêm trọng, hiển thị dưới dạng 500. Và trên Linux nó không tính thời gian chờ cơ sở dữ liệu hay I/O khác, nên một script mắc kẹt ở truy vấn chậm có thể chạy lâu hơn nhiều.

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

Những lý do thường gặp khiến proxy ngừng chờ:

• Một yêu cầu chậm — truy vấn cơ sở dữ liệu nặng, một báo cáo hoặc lệnh gọi tới API bên thứ ba chậm mất nhiều thời gian hơn timeout của proxy.
• Máy chủ quá tải — CPU 100%, thiếu bộ nhớ hoặc mọi worker PHP-FPM đều bận, nên yêu cầu mới phải xếp hàng cho tới khi proxy bỏ cuộc.
• Nút thắt cơ sở dữ liệu — truy vấn chậm, thiếu index, bảng bị khóa hoặc cạn pool kết nối.
• Timeout đặt quá thấp — 60 giây của nginx là quá ngắn với backend thực sự cần lâu hơn (xuất dữ liệu, nhập dữ liệu, tải lên lớn).
• Sự cố mạng giữa proxy và origin — mất gói tin hoặc tường lửa lặng lẽ bỏ gói của proxy (tường lửa từ chối gói tin thì cho 502).
• Giới hạn cố định của CDN — Cloudflare chờ 125 giây ở gói Free, Pro và Business, bất kể nginx của bạn cho phép bao lâu, rồi hiện Error 524.
• Lưu lượng tăng đột biến — đợt tăng đột ngột hoặc một cuộc tấn công chiếm hết worker, nên các yêu cầu bình thường không được trả lời kịp. (Máy chủ biết mình đang quá tải có thể trả lời 503 thay vào đó.)

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

Nếu bạn thấy lỗi 504 trên website của người khác, vấn đề nằm ở máy chủ của họ, không phải thiết bị của bạn. Tuy vậy vẫn có vài việc đáng thử.

• Đợi một phút rồi tải lại — nhiều lỗi 504 chỉ kéo dài bằng một đợt bận của máy chủ.
• Kiểm tra xem site có sập với mọi người không — Website Down Checker mở trang từ 11 địa điểm. Nếu họ cũng gặp 504 thì lỗi nằm ở site.
• Thử mạng khác — dùng dữ liệu di động thay cho Wi-Fi, hoặc tắt VPN, phòng trường hợp proxy hay VPN của chính bạn là gateway đang hết thời gian.
• Xem trang trạng thái hoặc mạng xã hội của site — các site đông khách thường thông báo khi có sự cố.

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

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

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

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

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Với Apache, thêm ProxyTimeout 300 vào VirtualHost hoặc dùng ProxyPass / http://backend:8080/ timeout=300 cho một backend.

Quan trọng: timeout đọc và gửi đo khoảng trống giữa hai thao tác đọc hoặc ghi liên tiếp, không phải tổng thời gian truyền. Vì vậy proxy_read_timeout 300 nghĩa là «nếu không có dữ liệu nào đến trong 300 giây», chứ không phải «toàn bộ phản hồi phải xong trong 300 giây». Tải lại cấu hình sau khi đổi: sudo nginx -t && sudo systemctl reload nginx.

Phía sau CDN, giới hạn riêng của CDN vẫn áp dụng: Cloudflare cắt ở 125 giây (từ Free đến Business) và CloudFront ở 30 giây theo mặc định, nên nâng nginx vượt các mức đó không thay đổi gì với khách truy cập đi qua CDN.

Cách 2: tối ưu script chậm và truy vấn cơ sở dữ liệu

Nếu backend liên tục vượt timeout, việc tăng giá trị timeout chỉ che giấu vấn đề. Cách sửa thật 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 dùng EXPLAIN ANALYZE cho các truy vấn đáng ngờ. Thêm index còn thiếu, tránh SELECT * và phân trang các tập kết quả lớn.
• Thêm caching — Dùng Redis hoặc Memcached để cache kết quả của các truy vấn tốn kém. Một truy vấn mất 5 giây ở mỗi lần tải trang thì nên được cache.
• Chuyển việc nặng sang tác vụ nền — Tạo báo cáo, gửi email, xử lý ảnh và nhập dữ liệu nên chạy trong hàng đợi tác vụ (Celery, Sidekiq, Bull), không phải trong chu kỳ yêu cầu HTTP.
• Tối ưu lệnh gọi API — Nếu backend gọi các API bên thứ ba chậm, hãy thêm timeout cho các lệnh gọi đó và dùng circuit breaker để một API chậm không chặn mọi yêu cầu.
• Giảm truy vấn N+1 — Truy vấn do ORM sinh ra thường tạo hàng trăm lệnh gọi cơ sở dữ liệu riêng lẻ. Dùng eager loading hoặc truy vấn theo lô để giảm số lượt đi về.

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

Nếu máy chủ origin quá tải, nó không xử lý yêu cầu đủ nhanh và proxy sẽ hết thời gian chờ. Hãy kiểm tra thứ gì đang tiêu tốn 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 ở mức trên 90%, bạn cần tối ưu ứng dụng, tắt các tiến trình mất kiểm soát hoặc nâng cấp máy chủ. Nếu ổ đĩa đầy, hãy dọn file log cũ, bản sao lưu hoặc file tạm; ổ đĩa đầy có thể làm cơ sở dữ liệu sập trong im lặng và gây ra một chuỗi lỗi 504.

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

Log lỗi cho biết chính xác vì sao proxy trả về 504. Hãy luôn xem 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.3-fpm.log

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

Các thông báo log thường gặp đằng sau lỗi 504:

«upstream timed out (110: Connection timed out) while reading response header from upstream» (nginx) — backend mất nhiều thời gian hơn proxy_read_timeout (hoặc fastcgi_read_timeout). Hãy làm nó nhanh hơn, hoặc tăng timeout nếu việc chờ là hợp lý.

«upstream timed out (110: Connection timed out) while connecting to upstream» (nginx) — nginx thậm chí không kết nối kịp: tường lửa đang bỏ gói tin, hoặc backend quá bận để nhận kết nối.

«server reached pm.max_children setting» (PHP-FPM) — mọi worker đều bận nên yêu cầu phải xếp hàng. Chỉ tăng pm.max_children khi còn đủ RAM; nếu không, hãy tìm các yêu cầu chậm đang giữ worker.

«Too many connections» (MySQL) — đã dùng hết giới hạn kết nối. Kết nối mới thất bại ngay (một lỗi 500, như «Error establishing a database connection» của WordPress), còn các truy vấn đang giữ kết nối thường chính là những truy vấn chậm đứng sau các lỗi 504 của bạn.

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

Với ứng dụng PHP (WordPress, Laravel, Magento), hãy giữ các timeout theo chuỗi, mỗi lớp dài hơn lớp phía sau một chút: fastcgi_read_timeout của nginx ≥ request_terminate_timeout của PHP-FPM ≥ max_execution_time của PHP.

Sau khi đổi cài đặt PHP-FPM, hãy khởi động lại nó (sudo systemctl restart php8.3-fpm, chỉnh theo phiên bản của bạn). Nếu fastcgi_read_timeout của nginx ngắn hơn các giới hạn của PHP, nginx sẽ bỏ cuộc trước và khách truy cập thấy 504 trong khi PHP vẫn đang làm việc.

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

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

Cloudflare: ở gói Free, Pro và Business, nếu origin của bạn chưa bắt đầu trả lời trong 125 giây, Cloudflare bỏ cuộc và hiện Error 524 (Cloudflare). Lời khuyên của chính Cloudflare: làm yêu cầu nhanh hơn, chuyển các tác vụ dài sang chạy nền, hoặc phục vụ chúng từ một subdomain chỉ dùng DNS (đám mây xám); gói Enterprise có thể nâng giới hạn.

CloudFront: tăng response timeout của origin trong phần cài đặt origin của distribution (AWS). AWS khuyên sửa origin chậm trước. Với yêu cầu GET và HEAD, CloudFront thử lại origin (mặc định 3 lần kết nối), nên origin có thể thấy cùng một yêu cầu nhiều lần trước khi khách truy cập nhận 504.

Để biết lớp nào đã gửi 504, hãy xem header phản hồi trong HTTP Header Checker: server: awselb/2.0 là load balancer của AWS, x-cache: Error from cloudfront là CloudFront, còn server: nginx là nginx. Phía sau Cloudflare mọi phản hồi đều ghi server: cloudflare, nên ở đó manh mối là chính mã lỗi (524 hoặc 504).

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.
• 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.
• Chuyển wp-cron sang cron thật — mỗi lượt truy cập trang đều kích hoạt WP-Cron, chạy các tác vụ đến hạn trong một yêu cầu loopback chiếm riêng một worker PHP. Thêm define('DISABLE_WP_CRON', true); vào wp-config.php, rồi cho máy chủ chạy wp cron event run --due-now mỗi 5 phút.

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ã.

Điểm khác biệt then chốt: 502 nghĩa là proxy nhận được phản hồi hỏng, hoặc kết nối bị từ chối hay bị đóng; 504 nghĩa là đồng hồ của proxy hết giờ trong khi upstream vẫn im lặng. 503 không cần proxy: máy chủ nào cũng có thể gửi khi quá tải. 408 là timeout phía client (nhóm 4xx), khi máy chủ chán chờ client.

Nếu bạn thấy 502 và 504 cùng lúc, backend nhiều khả năng đang gặp khó: yêu cầu hết thời gian cho 504, còn worker bị sập hoặc bị kết thúc cho 502.

Nếu bạn gặp 502 chứ không phải 504, hướng dẫn 502 Bad Gateway của chúng tôi đi qua các thông báo trong log lỗi nginx giải thích lỗi đó, kèm một trường hợp thực tế từ chính site này.

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

Tài liệu của Google mô tả tác động của lỗi 5xx (tài liệu thu thập dữ liệu của Google):

• Việc thu thập chậm lại trên toàn site, tương ứng với số URL trả về lỗi máy chủ.
• Các trang đã lập chỉ mục lúc đầu được giữ lại, nhưng URL liên tục trả về lỗi máy chủ cuối cùng sẽ bị loại bỏ.
• Việc thu thập phục hồi dần khi máy chủ trả lời lại bằng mã 2xx.

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 — một công cụ giám sát uptime tải các trang quan trọng vài phút một lần sẽ phát hiện 504 trước khi người dùng báo cho bạn.
• Đồ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.