504 Hết thời gian chờ Gateway

Tóm tắt — 504 Gateway Timeout nghĩa là một thành phần phía trước website — CDN, load balancer hoặc proxy — đã chờ máy chủ trả lời rồi bỏ cuộc vì phản hồi mất quá nhiều thời gian. Đây là timeout, không phải phản hồi bị hỏng. Một lỗi 504 lẻ tẻ thường không đáng lo; vấn đề xuất hiện khi chúng lặp lại, vì công cụ tìm kiếm sẽ crawl ít hơn và cuối cùng có thể loại trang.

504 thực sự có nghĩa gì

Khi bạn tải một trang, yêu cầu thường không đi thẳng tới web server. Nó thường qua một gateway trước — CDN, load balancer hoặc reverse proxy. Gateway chuyển yêu cầu đến máy chủ phía sau, tức upstream hoặc origin, chờ phản hồi rồi chuyển lại cho bạn.

504 Gateway Timeout là phản hồi gateway gửi khi đã chờ upstream nhưng không nhận được câu trả lời kịp thời. Origin có thể đang vật lộn với truy vấn cơ sở dữ liệu, chờ API bên thứ ba hoặc đơn giản là quá tải; nhìn từ gateway, thời gian chờ đã hết. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

Từ khóa là timeout. Không nhất thiết có thứ gì “bị hỏng”; phản hồi chỉ không đến đủ nhanh.

Khác các mã 5xx họ hàng thế nào

Mọi người thường xuyên nhầm các mã này:

• 502 Bad Gateway — gateway đã nhận phản hồi từ origin nhưng phản hồi không hợp lệ hoặc bị lỗi định dạng.
• 503 Service Unavailable — máy chủ tuyên bố “hiện tại tôi không khả dụng”, thường có chủ đích như trong cửa sổ bảo trì.
• 504 Gateway Timeout — gateway không nhận được phản hồi kịp thời từ upstream. Nhận định này hẹp hơn “không có gì trả về”: upstream có thể vẫn đang xử lý, chỉ là không trả lời trong cửa sổ chờ.

Vì vậy, 504 gần như luôn là triệu chứng hiệu năng: một thành phần upstream quá chậm.

504 có gây hại SEO không?

Không trực tiếp, và đây không phải hình phạt. Google không đánh giá nội dung của bạn — họ thực sự không thể truy xuất trang. Nhưng có chi phí gián tiếp rõ ràng:

• Nếu Googlebot liên tục gặp phản hồi chậm và timeout, nó giảm nhịp và crawl website ít hơn để không làm tình trạng quá tải trầm trọng.
• Một lỗi 504 đơn lẻ trong đợt tăng lưu lượng sẽ được thử lại và phần lớn bị bỏ qua.
• 504 lặp lại nhiều ngày mới có thể khiến trang bị loại khỏi chỉ mục, vì Google không thể truy xuất ổn định. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Cần làm gì

• Reload một hoặc hai lần — 504 đơn lẻ có thể chỉ là trục trặc thoáng qua.
• Kiểm tra log máy chủ và log lỗi để biết thứ gì chậm: truy vấn cơ sở dữ liệu, API bên ngoài hay tiến trình ứng dụng quá tải.
• Đừng chỉ tăng giá trị timeout rồi coi như xong; cách đó che giấu phản hồi chậm thay vì sửa nó. Phần Nâng cao giải thích vì sao.
• Duy trì máy chủ nhanh bằng cache, truy vấn hiệu quả hơn và đủ dung lượng; đó mới là cách phòng ngừa thật.

Muốn xem phiên bản kỹ thuật đầy đủ — 504 phát sinh ở đâu trong chuỗi yêu cầu, cơ chế Googlebot giảm crawl và vì sao TTFB là chỉ số cần theo dõi? Hãy chuyển sang thẻ Nâng cao.

Tóm tắt — 504 là gateway/proxy báo rằng upstream không phản hồi trong cửa sổ timeout — một timeout, khác 502 (phản hồi xấu) và 503 (chủ động không khả dụng). Đây là vấn đề khả năng truy cập, không phải hình phạt. Timeout nằm cùng nhóm với 429/500/503: Googlebot giảm nhịp khi gặp chúng, và 504 kéo dài tạo rủi ro mất chỉ mục. Cách sửa bền vững cho nguyên nhân phía origin là thời gian phản hồi máy chủ (TTFB), không phải timeout dài hơn; tăng timeout thường che giấu upstream chậm và có thể làm quá tải tệ hơn.

504 phát sinh ở đâu trong chuỗi yêu cầu

Đường đi hiện đại của yêu cầu thường là: trình duyệt → CDN/edge → load balancer → reverse proxy (ví dụ Nginx) → app server (PHP-FPM, Node…) → cơ sở dữ liệu / API bên thứ ba. 504 được tạo bởi thành phần đang chờ thành phần phía sau khi timeout hết hạn. Đây là câu hỏi chẩn đoán đầu tiên. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• CDN/edge hết thời gian chờ origin → cần cải thiện hiệu năng origin hoặc thận trọng tăng timeout upstream của CDN.
• Load balancer hết thời gian chờ app server → kiểm tra sức khỏe app server và autoscaling.
• Reverse proxy hết thời gian chờ tiến trình ứng dụng → xem proxy_read_timeout / fastcgi_read_timeout của Nginx và truy vấn hay tiến trình chậm phía sau.

Xác định đúng tầng rất quan trọng, vì “sửa timeout ở edge” và “sửa truy vấn cơ sở dữ liệu chậm ở origin” là hai công việc hoàn toàn khác.

Nguyên nhân gây 504

Bản thân mã trạng thái không chứng minh nguyên nhân; nó chỉ cho biết gateway hết thời gian chờ upstream. Những mục sau là nghi phạm phổ biến đáng kiểm tra, không phải sự thật mà 504 đã xác lập. Hãy xác nhận bằng log và trace trước khi hành động:

• Truy vấn cơ sở dữ liệu hoặc lời gọi API upstream chậm. Một truy vấn chưa có index hoặc dependency bên thứ ba ì ạch có thể đẩy thời gian phản hồi vượt timeout.
• Máy chủ/ứng dụng quá tải và cạn tài nguyên. Khi đủ nhiều yêu cầu đồng thời, hàng đợi dài ra, worker kín chỗ và phản hồi không đến kịp.
• Giá trị timeout cấu hình sai giữa Nginx, Apache, load balancer hoặc CDN; các tầng thường không khớp nên một tầng bỏ cuộc trước tầng khác.
• Đỉnh lưu lượng, bot flood hoặc DDoS tạm thời vượt quá dung lượng.

504 thường gián đoạn và phụ thuộc tải

Đây là điều khiến chúng khó chịu. Khác outage cứng, 504 thường chỉ xuất hiện khi có tải: monitor uptime ping trong lúc yên tĩnh có thể báo xanh 100%, trong khi Googlebot crawl theo đợt nặng hơn âm thầm gặp timeout. Trong Kiểm tra URL của Google Search Console, hiện tượng này có thể xuất hiện dưới điều kiện “Hostload exceeded” (bản dịch) «tải máy chủ vượt ngưỡng» thay vì lỗi liên tục rõ ràng. Nếu hệ thống giám sát nói mọi thứ ổn nhưng Crawl Stats không đồng ý, 504 phụ thuộc tải là nghi phạm hàng đầu.

Googlebot và Bingbot xử lý timeout thế nào

Google không xem 504 là đánh giá chất lượng nội dung; đó là tín hiệu khả dụng và phản ứng là tự động giảm nhịp. Tài liệu crawl viết rõ: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (bản dịch) «Googlebot sẽ giảm hoạt động crawl nếu phát hiện máy chủ gặp khó khăn khi phản hồi yêu cầu crawl». Hướng dẫn crawl budget cho website lớn diễn đạt tương tự: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (bản dịch) «Nếu website chậm hoặc trả lỗi máy chủ, giới hạn giảm và Google crawl ít hơn». Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Cách diễn đạt mới nhất liên hệ trực tiếp với phản hồi chậm/timeout nằm trong bài Inside Googlebot tháng 3 năm 2026 của Google, nơi Gary Illyes được trích: “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (bản dịch) «Nếu máy chủ chật vật gửi dữ liệu, crawler sẽ tự động giảm nhịp để tránh làm hạ tầng quá tải, khiến tần suất crawl giảm». Đây là thông tin do Search Engine Land thuật lại; nếu trích ở nơi khác, nên đối chiếu bản ghi hoặc transcript gốc. 504 chính là biểu hiện hữu hình của sự chật vật đó.

Một sắc thái cần hiểu: Google không phải lúc nào cũng nhìn thấy mã “504” như trình duyệt. Nếu timeout xảy ra trước khi Googlebot nhận bất kỳ dòng trạng thái nào, Crawl Stats ghi nhận là timeout/lỗi mạng thay vì 5XX rõ ràng. Nhưng khi proxy hoặc CDN trung gian hết thời gian và tự tạo phản hồi 504, Googlebot nhận lỗi máy chủ 5XX tiêu chuẩn. Dù trường hợp nào, tác động giống nhau: tốc độ crawl bị giảm và nếu kéo dài, URL bị loại khỏi chỉ mục.

Bing ghi nhận timeout thành một nhóm lỗi crawl riêng, tách khỏi lỗi máy chủ; Bingbot ngừng cố truy cập trang khi phản hồi quá chậm. Khuyến nghị của Bing là kiểm tra thời gian phản hồi máy chủ, cập nhật phần mềm, tối ưu tài nguyên chậm và đọc log để tìm mẫu hệ thống thay vì trục trặc đơn lẻ. Bing không công bố chi tiết giảm nhịp và phục hồi như Google, nên chỉ xem mục đích của hai bên là tương đồng rộng, không khẳng định hành vi giống hệt.

Vòng phản hồi giảm nhịp rồi phục hồi

Điểm đáng yên tâm: vòng lặp này tự động và tự điều chỉnh. Google giảm crawl khi gặp lỗi và timeout, rồi từ từ tăng trở lại sau khi phản hồi khỏe. Không có nút “bỏ giới hạn” thủ công cần bấm khi vấn đề gốc đã được sửa. John Mueller nói: “Once things settle down on the server, the crawl rate will return to normal automatically.” (bản dịch) «Khi tình hình trên máy chủ ổn định, tốc độ crawl sẽ tự động trở lại bình thường». Ông cũng nêu tính bất đối xứng: giảm nhịp diễn ra nhanh để giải quyết vấn đề tức thời, còn tăng lại được thực hiện thận trọng.

Thời lượng biến trục trặc thành vấn đề lập chỉ mục

504 ngắn và thỉnh thoảng — vài lỗi trong đợt tăng tải rồi được xử lý nhanh — sẽ được thử lại và phần lớn chấp nhận được. Rủi ro mất chỉ mục đến từ mẫu timeout kéo dài trong một cửa sổ rộng. Cơ chế “quay lại sau” được Google ghi nhận, khi bạn chủ động trả 503 hoặc 429 lúc quá tải, mô tả mốc khoảng hai ngày trước khi URL bắt đầu bị loại; nhưng con số đó dành đích danh cho 503/429, không phải 504. Hướng dẫn 5xx rộng hơn nói tốc độ crawl giảm theo tỷ lệ URL lỗi rồi phục hồi khi phản hồi khỏe, không nêu thời hạn cố định riêng cho 504. Áp mốc hai ngày cho 504 là suy luận hợp lý, không phải sự thật được ghi nhận: 504 ngắn có thể sống sót, còn mẫu kéo dài nhiều ngày là vùng cần lo — không phải ngày kích hoạt được bảo đảm.

Vì sao điều này quan trọng hơn với website lớn và thương mại điện tử

Với website nhỏ có trang được crawl ngay ngày xuất bản, bạn hầu như không nhận ra. Nhưng trên website lớn hoặc thay đổi nhanh — catalog thương mại điện tử, tin tức, marketplace — crawl budget vốn đã là ràng buộc; một làn sóng 504 lúc cao tải có thể làm các trang thật sự cần được crawl lại không còn tài nguyên crawl. Ở quy mô lớn, timeout và crawl budget là cùng một cuộc thảo luận.

Thời gian phản hồi máy chủ và TTFB là đòn bẩy phòng ngừa mạnh — cho nguyên nhân phía origin

Điểm nhiều bài 504 bỏ qua: chờ lỗi xuất hiện rồi grep log là phản ứng bị động. Theo dõi liên tục thời gian phản hồi máy chủ để thấy xu hướng trượt trước khi chạm timeout mới là chủ động. Máy chủ hôm nay chậm nhưng chưa timeout có thể tạo 504 ngày mai khi tải tăng nhẹ hoặc dependency chậm hơn chút. Theo dõi TTFB (time to first byte) như tín hiệu cảnh báo sớm liên tục, không chỉ số liệu hậu kiểm, giúp phát hiện độ trượt đó.

Lưu ý: giám sát TTFB xử lý độ chậm phía origin. Nó không phát hiện CDN timeout với origin khỏe, load balancer cấu hình bỏ cuộc quá sớm hay vấn đề đường mạng giữa các hop; các trường hợp đó cần xác định hop phát lỗi trước. TTFB là cách sửa bền vững cho tình huống upstream thật sự chậm, không phải phương thuốc chung. Sau khi xác nhận origin là nút thắt, hãy tối ưu cache trang/object/CDN, truy vấn cơ sở dữ liệu và index, autoscaling theo tải cùng cấu hình upstream CDN hợp lý.

Vì sao “chỉ cần tăng timeout” là phản xạ sai

Tăng proxy_read_timeout hoặc timeout upstream của CDN có thể làm 504 không còn hiển thị, nhưng không khiến phản hồi upstream nhanh hơn. Tệ hơn, cửa sổ timeout dài khi tải cao khiến yêu cầu tích tụ và giữ worker/kết nối lâu hơn, có thể làm vòng xoáy quá tải trầm trọng. Thỉnh thoảng tăng timeout là đúng cho tác vụ dài đã hiểu rõ; dùng như phản xạ chỉ che giấu vấn đề thật.

Khi thời gian ngừng có kế hoạch hoặc bạn chủ động giảm tải, công cụ đúng không phải để trang trả 504; hãy trả 503 kèm header Retry-After để gửi công cụ tìm kiếm tín hiệu “hãy quay lại sau” rõ ràng, có chủ đích thay vì timeout lộn xộn.

Chẩn đoán 504 trong thực tế

Xác định hop phát lỗi trước khi đoán nguyên nhân — đây là khác biệt giữa sửa vấn đề thật và sửa triệu chứng:

• Tái hiện và xác định hop trả lời. Mở trong trình duyệt; dùng curl và theo dõi time_starttransfer cho TTFB; chạy qua crawler như Ahrefs Site Audit hoặc Screaming Frog để biết lỗi toàn site hay cô lập. Nếu có thể, kiểm tra trực tiếp origin, bỏ qua CDN/proxy, để xem origin có hoàn tất không.
• Đọc log. Log máy chủ và proxy cho biết tầng nào timeout và lý tưởng là do việc gì: truy vấn chậm, upstream mắc kẹt hay worker cạn. Đối chiếu timestamp và request ID giữa các tầng thay vì giả định.
• Kiểm tra Search Console. Crawl Stats hiển thị đỉnh mã phản hồi và thời gian phản hồi trung bình; báo cáo Lập chỉ mục trang và Kiểm tra URL cho biết Google có gặp timeout hay không, gồm trạng thái “Hostload exceeded” (bản dịch) «tải máy chủ vượt ngưỡng».

Việc đối chiếu công cụ rất quan trọng: 504 trong trình duyệt, lỗi 5xx của Ahrefs Site Audit và timeout trong GSC có thể cùng mô tả một origin chậm nhìn từ các vị trí khác nhau. Đừng mặc định ba công cụ nghĩa là ba vấn đề.

Các mã liên quan

504 nằm trong một nhóm nhỏ. 500 là lỗi máy chủ chung khi không có mã cụ thể hơn; 502 là phản hồi upstream xấu/lỗi định dạng; 503 là trạng thái “không khả dụng” rõ ràng, thường có chủ đích. Xác định đúng mã đang trả — và chủ động trả mã đúng khi có thời gian ngừng theo kế hoạch — đã giải quyết một nửa vấn đề.

Tóm tắt cho AI

Bản cô đọng của phần Nâng cao:

• 504 = timeout, không phải phản hồi hỏng. Gateway/proxy (CDN, load balancer, reverse proxy) chờ upstream nhưng không nhận phản hồi kịp thời; không nhất thiết là “không bao giờ trả lời”. Khác 502 (phản hồi xấu) và 503 (chủ động không khả dụng). Mã trạng thái không tự chứng minh hop hay nguyên nhân; xác định hop phát lỗi trước khi sửa.
• Đây không phải hình phạt. Đây là vấn đề khả năng truy cập: Google không lấy được trang, nên mất xếp hạng/chỉ mục là hệ quả phía sau chứ không phải trừng phạt.
• Timeout kích hoạt giảm crawl. Google nói Googlebot giảm crawl khi máy chủ khó phản hồi. Gary Illyes được Search Engine Land dẫn lời tháng 3 năm 2026 rằng máy chủ chật vật khiến crawler “automatically back off … which will drop your crawl frequency.” (bản dịch) «tự động giảm nhịp… khiến tần suất crawl giảm».
• Thời lượng quan trọng, nhưng “2 ngày” không phải con số Google ghi riêng cho 504. Mốc đó dành cho 503/429 được chủ động trả khi quá tải. Hướng dẫn 5xx chung nói crawl giảm theo tỷ lệ và phục hồi từ từ, không nêu lịch cố định riêng cho 504; 504 đơn lẻ được thử lại, còn mẫu kéo dài mới có nguy cơ mất chỉ mục.
• Vòng lặp tự điều chỉnh. Khi phản hồi phục hồi, tốc độ crawl tự trở lại; không cần bỏ giới hạn thủ công.
• Thường gián đoạn/phụ thuộc tải — monitor trong cửa sổ yên tĩnh có thể bỏ lỡ; Kiểm tra URL có thể hiển thị “Hostload exceeded” (bản dịch) «tải máy chủ vượt ngưỡng».
• TTFB là đòn bẩy phòng ngừa mạnh cho nguyên nhân phía origin, nhưng không phải chung cho mọi trường hợp; 504 cũng có thể phát sinh ở CDN, load balancer hoặc proxy. Xác nhận hop timeout trước. Tăng timeout chỉ che giấu upstream chậm và có thể làm quá tải tệ hơn.
• Khi thời gian ngừng có kế hoạch, hãy trả 503 kèm Retry-After, không phải 504.

Tài liệu chính thức

Tài liệu nguồn sơ cấp về timeout, lỗi máy chủ và cách crawler phản ứng.

Định nghĩa

• MDN — 504 Gateway Timeout — định nghĩa có thẩm quyền và khác biệt với 502.

Google

• Khắc phục lỗi crawl — cách Googlebot giảm nhịp khi máy chủ gặp vấn đề và thời điểm trả 503/429 lúc quá tải.
• Tối ưu crawl budget — phản hồi chậm và lỗi máy chủ làm giảm giới hạn crawl thế nào.
• Báo cáo Crawl Stats — các nhóm “Server error (5XX)” và “Page timeout”, cùng cách Googlebot giảm nhịp để tránh quá tải.

Bing / Microsoft

• Bing Webmaster Tools — cảnh báo lỗi crawl — cách Bing tách lỗi máy chủ và timeout thành hai nhóm lỗi crawl.

Trích dẫn từ nguồn

Các phát biểu công khai. Mỗi liên kết dẫn thẳng đến đoạn được trích trên trang nguồn.

MDN — định nghĩa

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (bản dịch) «Mã lỗi máy chủ HTTP 504 Gateway Timeout cho biết máy chủ, khi hoạt động như gateway hoặc proxy, không nhận phản hồi kịp thời từ upstream để hoàn tất yêu cầu; khác 502 ở chỗ proxy/gateway không nhận bất kỳ phản hồi HTTP nào từ origin trong khoảng thời gian nhất định.» Đi đến trích dẫn

Google — crawl và timeout

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (bản dịch) «Googlebot sẽ giảm hoạt động crawl nếu phát hiện máy chủ gặp khó khăn khi phản hồi yêu cầu crawl.» — Google Search Central, Khắc phục lỗi crawl. Đi đến trích dẫn
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (bản dịch) «Nếu website chậm hoặc trả lỗi máy chủ, giới hạn giảm và Google crawl ít hơn.» — Google Search Central, Tối ưu crawl budget. Đi đến trích dẫn

Gary Illyes, Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (bản dịch) «Nếu máy chủ chật vật gửi dữ liệu, crawler sẽ tự động giảm nhịp để tránh làm hạ tầng quá tải, khiến tần suất crawl giảm.» Đi đến trích dẫn

John Mueller, Google (trên Reddit, được Search Engine Journal thuật lại, tháng 8 năm 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (bản dịch) «Tôi chỉ kỳ vọng tốc độ crawl phản ứng nhanh như vậy nếu website trả 429 / 500 / 503 / timeout.» Đi đến trích dẫn Search Engine Journal đăng lại phản hồi Reddit của Mueller cùng ngữ cảnh xung quanh.

Checklist thời gian phản hồi máy chủ / TTFB

Mục tiêu là giữ phản hồi đủ nhanh để 504 không bao giờ kích hoạt — và phát hiện xu hướng trượt trước khi nó xảy ra. Thực hiện từ trên xuống:

• Thiết lập đường cơ sở TTFB bằng curl -w "%{time_starttransfer}" hoặc monitor tổng hợp, ghi lại mức “bình thường” cho từng template.
• Theo dõi TTFB liên tục, không chỉ sau sự cố; cảnh báo khi xu hướng tăng, không chỉ lúc lỗi cứng.
• Load test ở mức đồng thời thực tế và cao điểm; 504 thường phụ thuộc tải nên kiểm tra lúc yên tĩnh không phát hiện được.
• Profile công việc upstream chậm nhất: truy vấn DB thiếu index, truy vấn N+1 và API bên thứ ba chặn là các thủ phạm quen thuộc.
• Cache mạnh tay ở tầng trang, object và edge CDN để phần lớn yêu cầu không chạm đường chậm.
• Kiểm tra giá trị timeout nhất quán giữa các tầng (CDN, load balancer, Nginx proxy_read_timeout / fastcgi_read_timeout, ứng dụng) để một tầng không bỏ cuộc trước tầng khác.
• Xác nhận autoscaling / dung lượng dự phòng đủ cho đỉnh lưu lượng và crawl.
• Xem GSC Crawl Stats để tìm đỉnh timeout, 5XX và thời gian phản hồi trung bình tăng.
• Kiểm tra log máy chủ + proxy để biết tầng nào timeout và vì việc gì.
• Xác minh monitor uptime bao phủ tải cao điểm, không chỉ ping ngoài giờ.
• Dùng 503 + Retry-After cho thời gian ngừng có kế hoạch thay vì để trang trả 504.

Ngộ nhận và lỗi 504 cần tránh

Những bẫy thường gặp nhất — gồm nhiều ngộ nhận được lặp lại rộng rãi cần sửa:

• “504 là hình phạt của Google.” Không. Đây là vấn đề khả năng truy cập/crawl, không phải hành động thuật toán. Google không đánh giá nội dung; họ không thể lấy trang. Mất xếp hạng là hệ quả phía sau của việc không truy cập được, không phải trừng phạt.
• “Bất kỳ 504 nào cũng khiến trang bị loại ngay.” Không. 504 ngắn, thỉnh thoảng được thử lại và chấp nhận; 504 kéo dài, thường xuyên trong cửa sổ rộng mới tạo rủi ro.
• “504 và 503 cơ bản giống nhau — dùng thay thế được.” Không. 503 có thể là tín hiệu chủ động, có kiểm soát cho thời gian ngừng theo kế hoạch; 504 là timeout, gần như luôn ngoài kế hoạch và biểu hiện upstream chậm. Khi ngừng có kế hoạch, trả 503 kèm Retry-After, đừng để trang 504.
• “Googlebot quá hung hăng.” Thường là nhìn ngược. Máy chủ thường xuyên trả 504 dưới tốc độ crawl của Googlebot cũng suy giảm với người dùng thật ở mức tải tương tự. Timeout phơi bày vấn đề dung lượng/hiệu năng thật; trường hợp “Hostload exceeded” (bản dịch) «tải máy chủ vượt ngưỡng» có tồn tại nhưng là ngoại lệ.
• “Sửa chỉ là tăng timeout.” Tăng proxy_read_timeout che upstream chậm và giữ worker lâu hơn khi tải cao, có thể làm quá tải tệ hơn. Hãy sửa phản hồi chậm thay vì kéo dài sự kiên nhẫn.
• “Monitor uptime xanh nên không có 504.” 504 thường phụ thuộc tải. Monitor ping lúc yên tĩnh có thể bỏ lỡ timeout Googlebot gặp trong đợt crawl nặng. Hãy tin Crawl Stats và log hơn ping ngoài giờ.

Tầng nào đang timeout?

Prompt: phân loại hàng loạt sự cố 504

Dán các hàng đã làm sạch gồm URL, timestamp, header phản hồi, TTFB hoặc tổng thời gian, kết quả public-edge, kết quả origin trực tiếp, trace ứng dụng, thời gian cơ sở dữ liệu và tín hiệu tài nguyên. Không dán thông tin đăng nhập, cookie, địa chỉ riêng hay dữ liệu người dùng.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

Hãy coi kết quả là hàng đợi giả thuyết. Xác nhận bằng telemetry của gateway, ứng dụng, cơ sở dữ liệu và hạ tầng.

Đo trạng thái và thời gian đến byte đầu tiên

Chạy lệnh này trong shell macOS/Linux. Nó báo mã phản hồi cuối và TTFB của một yêu cầu mà không in body.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

Lặp lại vài lần để biết timeout có ổn định hay phụ thuộc tải:

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

Lệnh PowerShell tương đương:

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

Phiên bản PowerShell đo tổng thời gian yêu cầu, không phải TTFB. Dùng lệnh shell hoặc telemetry ứng dụng khi cần tách thời gian byte đầu tiên.

Công cụ tái hiện và xác định phạm vi 504

• Website Down Checker — kiểm tra khả năng truy cập từ vị trí bên ngoài và ghi thời gian phản hồi, redirect cùng bằng chứng DNS giới hạn. Dùng để xác lập sự cố có tái hiện công khai không.
• Bulk HTTP Status Code Checker — kiểm tra nhóm route đại diện, so sánh độ trễ và xuất tập con lỗi. Cách này tách một endpoint chậm khỏi vấn đề upstream toàn site.
• Log CDN/load balancer — tìm gateway phát 504 và đối chiếu request ID cùng timeout với lần thử upstream.
• Trace ứng dụng và log truy vấn chậm cơ sở dữ liệu — cho biết yêu cầu dành thời gian ở đâu sau khi đến origin.
• Giám sát hạ tầng — đối chiếu cửa sổ sự cố với CPU, bộ nhớ, worker pool, kết nối và mức bão hòa dependency thay vì đoán từ mã trạng thái.

TTFB theo route và phân vị

Chỉ số: Thời gian đến byte đầu tiên cho các route đại diện, được chia theo phân vị hữu ích thay vì chỉ giá trị trung bình.

Cho biết gì: Độ trễ phần đuôi tăng là cảnh báo sớm rằng yêu cầu đang tiến gần timeout gateway, ngay cả trước khi bắt đầu trả 504.

Cách lấy: Dùng giám sát người dùng thật/máy chủ hoặc log gateway; dùng script curl trong thẻ Script để kiểm tra nhanh, không thay telemetry production.

Mốc chuẩn / khoảng thực tế: Thiết lập đường cơ sở cho từng route và đường hạ tầng. Cảnh báo có ý nghĩa là thay đổi kéo dài so với đường cơ sở hoặc tiến gần timeout gateway thật đã cấu hình, không phải một con số SEO chung.

Tần suất: Theo dõi liên tục; xem xu hướng cấp route hằng tuần và trong mỗi sự cố 504.

Tỷ lệ phản hồi 504

Chỉ số: Số yêu cầu trả 504 chia cho tổng yêu cầu, phân theo route, gateway, origin và nhóm crawler/user-agent nếu có.

Cho biết gì: Timeout cô lập, tập trung trên một đường hay đủ rộng để ảnh hưởng crawler và người dùng.

Cách lấy: Tổng hợp log truy cập CDN, load balancer hoặc máy chủ theo mã trạng thái và chiều yêu cầu.

Mốc chuẩn / khoảng thực tế: Mục tiêu khỏe là không có 504 không giải thích được. Độ nhạy cảnh báo nên dựa vào đường cơ sở không sự cố của chính bạn vì cơ cấu lưu lượng và retry khác nhau theo stack.

Tần suất: Cảnh báo liên tục; xem hằng ngày trong phục hồi và trong báo cáo độ tin cậy hằng tuần.

Thời gian hoàn tất upstream so với timeout gateway

Chỉ số: Phân bố thời gian hoàn tất upstream so với timeout đã cấu hình ở từng hop.

Cho biết gì: Công việc chậm có thật sự tiến gần giới hạn hay timeout gateway ngắn hơn đang cắt các phản hồi upstream vốn khỏe.

Cách lấy: Ghép trường thời gian gateway với trace ứng dụng bằng request ID hoặc trace ID.

Mốc chuẩn / khoảng thực tế: Giữ thời gian hoàn tất bình thường nằm thoải mái trong giới hạn đã cấu hình, có khoảng trống cho biến thiên dự kiến. Xác định khoảng trống từ phân bố production thực, không bịa tỷ lệ chung.

Tần suất: Xem sau thay đổi cấu hình/dependency và bất cứ khi nào độ trễ phần đuôi hoặc tỷ lệ 504 tăng.

Tự kiểm tra: 504 Gateway Timeout

Năm câu hỏi nhanh về ý nghĩa 504 và ảnh hưởng đến crawl. Chọn đáp án rồi kiểm tra.

Tài nguyên đáng xem

Bài viết liên quan của tôi

• Hướng dẫn nhập môn SEO kỹ thuật — sức khỏe máy chủ và khả năng crawl nằm ở đâu trong bức tranh lớn.
• Gặp các web crawler mới: Bot AI đang tiến gần bot công cụ tìm kiếm — ai thực sự truy cập máy chủ và vì sao tải quan trọng.

Bài thuyết trình của tôi

• Cách Search hoạt động (SlideShare) — phần trình bày về crawl, render, lập chỉ mục và xếp hạng, gồm cách phản hồi máy chủ chi phối tốc độ crawl. Tuyên bố miễn trừ thường trực của tôi vẫn áp dụng: “This is my understanding of systems… not going to be 100% complete or accurate.” (bản dịch) «Đây là cách tôi hiểu các hệ thống… sẽ không đầy đủ hoặc chính xác 100%».

Nguồn trong ngành

• MDN — 504 Gateway Timeout — định nghĩa chuẩn và khác biệt với 502.
• Google — Khắc phục lỗi crawl — cách Googlebot giảm nhịp khi máy chủ gặp vấn đề.
• Google — Quản lý crawl budget cho website lớn — phản hồi chậm làm giảm giới hạn crawl thế nào.
• Google giải thích cách crawl hoạt động năm 2026 (Search Engine Land) — trích dẫn Illyes liên hệ máy chủ chật vật với tần suất crawl giảm.
• Googlebot giảm crawl? Mueller chỉ ra lỗi máy chủ (Search Engine Journal) — Mueller nhóm timeout với 429/500/503 là lỗi làm tốc độ crawl giảm nhanh.
• Cách sửa lỗi 504 Gateway Timeout (Kinsta) — hướng dẫn kỹ thuật vững chắc từ phía hosting về chuỗi yêu cầu và chẩn đoán log.

Video

• Google Search Central (YouTube) — loạt How Google Search Works và các video giải thích crawl của Martin Splitt, hữu ích để thấy phản hồi máy chủ tương tác với tốc độ crawl thế nào. Kênh

Nhật ký thay đổi