Blog

Mã Trạng Thái 504 Gateway Timeout Là Gì: Chờ Đợi

INEZA Felin-Michel

INEZA Felin-Michel

24 tháng 10 2025

Mã Trạng Thái 504 Gateway Timeout Là Gì: Chờ Đợi

Bạn đang duyệt một trang web, và thay vì trang tải, bạn lại nhìn chằm chằm vào một thông báo có nội dung "504 Gateway Timeout." Biểu tượng tải đã quay trong một khoảng thời gian dường như vô tận. Bạn nhấn làm mới, nhưng lỗi tương tự lại xuất hiện. Trang web không thực sự "sập," nhưng một phần nào đó trong hạ tầng của nó đã từ bỏ việc chờ đợi phản hồi.

Trải nghiệm khó chịu này là do một trong những lỗi phía máy chủ phổ biến nhất trên web hiện đại gây ra: mã trạng thái 504 Gateway Timeout.

Không giống như các lỗi phía máy khách như 404 Not Found, thường là "lỗi" của người dùng, hoặc các lỗi phía máy chủ như 500 Internal Server Error, xảy ra bên trong ứng dụng, lỗi 504 là sự cố giao tiếp giữa các máy chủ. Nó tương đương với việc một người trung gian giơ tay đầu hàng và nói, "Tôi đã đợi quá lâu người mà bạn thực sự muốn nói chuyện, và tôi bỏ cuộc."

Nhưng chính xác thì Mã trạng thái HTTP 504: Gateway Timeout là gì, và tại sao nó lại xảy ra? Quan trọng hơn, làm thế nào bạn có thể khắc phục hoặc ngăn chặn nó xuất hiện trong ứng dụng, API hoặc trang web của mình?

Nếu bạn là nhà phát triển, quản trị viên hệ thống hoặc chỉ là một người dùng web tò mò, việc hiểu nguyên nhân gây ra lỗi 504 và cách khắc phục nó là vô cùng quý giá.

Chúng ta sẽ đi sâu vào chi tiết tất cả những điều đó, từ ý nghĩa của mã này, đến các nguyên nhân phổ biến, và các cách khắc phục thực tế.

💡
Xây dựng hoặc thử nghiệm các hệ thống phân tán với nhiều phụ thuộc dịch vụ, bạn cần một công cụ có thể giúp bạn xác định các vấn đề về thời gian chờ này. Tải Apidog miễn phí; đây là một nền tảng API tất cả trong một giúp bạn kiểm tra hiệu suất API, thiết lập giám sát cho các điểm cuối chậm và gỡ lỗi các phụ thuộc dịch vụ phức tạp trước khi chúng gây ra lỗi 504 cho người dùng của bạn.

Tải ứng dụng

Bây giờ, hãy cùng khám phá điều gì xảy ra đằng sau hậu trường khi bạn gặp phải lỗi 504 Gateway Timeout.

Kiến trúc Web hiện đại: Không bao giờ chỉ là một máy chủ

Để hiểu về lỗi 504, chúng ta cần hiểu cách các trang web và ứng dụng hiện đại được xây dựng. Rất ít ứng dụng chạy trên một máy chủ duy nhất nữa. Hầu hết sử dụng kiến trúc đa tầng trông như thế này:

  1. Trình duyệt của người dùng: Gửi yêu cầu ban đầu.
  2. Bộ cân bằng tải / Reverse Proxy: Phân phối lưu lượng truy cập đến nhiều máy chủ backend (ví dụ: NGINX, HAProxy, AWS ALB).
  3. Máy chủ Web/Ứng dụng: Chạy mã ứng dụng thực tế (ví dụ: Node.js, Python/Django, PHP).
  4. Dịch vụ Backend / API: Xử lý các tác vụ cụ thể như xác thực, thanh toán hoặc xử lý dữ liệu (thường là microservices).
  5. Cơ sở dữ liệu / Bộ nhớ đệm: Lưu trữ và truy xuất dữ liệu.

Lỗi 504 thường xảy ra giữa bước 2 và 3, hoặc giữa bước 3 và 4. "Gateway" trong "Gateway Timeout" đề cập đến máy chủ đóng vai trò trung gian - bộ cân bằng tải hoặc reverse proxy.

Mã trạng thái HTTP 504 Gateway Timeout thực sự có nghĩa là gì?

Mã trạng thái 504 Gateway Timeout cho biết rằng một máy chủ đóng vai trò gateway hoặc proxy đã không nhận được phản hồi kịp thời từ một máy chủ upstream mà nó cần truy cập để hoàn thành yêu cầu.

Nói một cách đơn giản hơn: "Tôi (gateway) đã yêu cầu một máy chủ khác giúp đỡ, nhưng máy chủ đó mất quá nhiều thời gian để trả lời tôi, vì vậy tôi bỏ cuộc và báo cho bạn biết có vấn đề."

Một phản hồi 504 điển hình khá tối giản:

HTTP/1.1 504 Gateway TimeoutContent-Type: text/htmlContent-Length: 125
<html><head><title>504 Gateway Timeout</title></head><body><center><h1>504 Gateway Timeout</h1></center></body></html>

Không giống như một số lỗi khác, thường không có nội dung tùy chỉnh vì bản thân gateway thường là một phần hạ tầng đơn giản không biết cách tạo các trang lỗi đẹp mắt.

Hãy hình dung như thế này:

Bạn nhờ bạn mình kiểm tra xem một nhà hàng có mở cửa không. Bạn của bạn gọi điện đến nhà hàng, nhưng không ai nhấc máy. Sau khi đợi một lúc, bạn của bạn nói với bạn:

“Xin lỗi, họ không trả lời - tôi bị hết thời gian chờ.”

Đó chính xác là những gì xảy ra với lỗi 504 Gateway Timeout.

Gateway (thường là một reverse proxy như NGINX hoặc bộ cân bằng tải) cố gắng kết nối với một máy chủ upstream (như ứng dụng web hoặc cơ sở dữ liệu của bạn). Nếu máy chủ upstream đó mất quá nhiều thời gian để phản hồi, gateway sẽ báo lỗi 504 và hủy bỏ yêu cầu.

Chuỗi trách nhiệm: Lỗi 504 xảy ra như thế nào

Hãy cùng xem xét một ví dụ cụ thể sử dụng kiến trúc thương mại điện tử phổ biến.

1. Yêu cầu: Người dùng tìm kiếm một sản phẩm. Trình duyệt của họ gửi yêu cầu đến https://shop.example.com/search?q=laptop.

2. Vai trò của Bộ cân bằng tải: Yêu cầu đầu tiên đến bộ cân bằng tải (gateway). Nhiệm vụ của bộ cân bằng tải là chuyển tiếp yêu cầu này đến một trong số các máy chủ ứng dụng có sẵn. Bộ cân bằng tải có cài đặt thời gian chờ là, ví dụ, 30 giây.

3. Nhiệm vụ của Máy chủ ứng dụng: Máy chủ ứng dụng nhận yêu cầu. Để hoàn thành nó, nó cần gọi hai dịch vụ khác:

4. Vấn đề: Dịch vụ hồ sơ người dùng đang gặp tải cao hoặc bị deadlock cơ sở dữ liệu. Nó bị kẹt và không phản hồi.

5. Hết thời gian chờ: Máy chủ ứng dụng đợi... 25 giây... 28 giây... 29 giây... Bộ cân bằng tải, vẫn đang chờ phản hồi từ máy chủ ứng dụng, đạt đến giới hạn thời gian chờ 30 giây của nó.

6. Phản hồi 504: Bộ cân bằng tải từ bỏ. Nó không thể trả về kết quả tìm kiếm vì nó chưa bao giờ nhận được chúng từ máy chủ ứng dụng. Vì vậy, nó trả về lỗi 504 Gateway Timeout cho trình duyệt của người dùng.

Điểm mấu chốt ở đây là máy chủ ứng dụng có thể vẫn đang hoạt động, cố gắng lấy phản hồi từ Dịch vụ hồ sơ người dùng. Nhưng bộ cân bằng tải đã hủy yêu cầu từ góc độ của nó.

Khi nào nên dự kiến lỗi 504

Lỗi 504 phổ biến nhất trong các trường hợp mà:

Vì lỗi 504 thường chỉ là tạm thời, các chiến lược thử lại và ngắt mạch thường được sử dụng như một phần của kế hoạch phục hồi mạnh mẽ.

Khi nào lỗi 504 có thể chấp nhận được

Có những trường hợp hợp lệ mà thời gian chờ gateway được mong đợi hoặc chấp nhận được:

Trong những trường hợp này, giao tiếp minh bạch và các chính sách thử lại được thiết kế tốt giúp giảm thiểu tác động đến người dùng.

Ví dụ thực tế về lỗi 504 Gateway Timeout

Hãy tưởng tượng bạn đang xây dựng một trang web thương mại điện tử. Quy trình thanh toán của bạn gọi nhiều API: thanh toán, kho hàng, vận chuyển và xác thực người dùng.

Bây giờ, nếu API thanh toán đột nhiên chậm lại hoặc không khả dụng, máy chủ của bạn (đóng vai trò gateway) sẽ chờ phản hồi. Nếu nó không nhận được phản hồi trong giới hạn thời gian chờ (ví dụ, 30 giây), nó sẽ báo lỗi:

504 Gateway Timeout

Đối với người dùng, có vẻ như trang web của bạn bị hỏng. Nhưng về mặt kỹ thuật, vấn đề nằm ở chuỗi giao tiếp giữa các dịch vụ.

504 so với các lỗi 5xx khác: Biết sự khác biệt

Rất dễ nhầm lẫn các lỗi máy chủ, nhưng mỗi lỗi lại kể một câu chuyện khác nhau về những gì đã sai.

504 Gateway Timeout so với 502 Bad Gateway:

504 Gateway Timeout so với 500 Internal Server Error:

504 Gateway Timeout so với 408 Request Timeout:

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

Hiểu các nguyên nhân là bước đầu tiên để phòng ngừa và giải quyết.

1. Máy chủ Backend bị quá tải

Đây là nguyên nhân phổ biến nhất. Các máy chủ ứng dụng của bạn có thể đang chịu tải nặng, khiến chúng phản hồi chậm hoặc không phản hồi. Điều này có thể do:

2. Các vấn đề về mạng

Các vấn đề kết nối giữa gateway và các máy chủ backend của bạn có thể gây ra thời gian chờ.

3. Các hoạt động tốn nhiều tài nguyên

Một số hoạt động tự nhiên mất nhiều thời gian:

Nếu các hoạt động này vượt quá ngưỡng thời gian chờ của gateway, chúng sẽ gây ra lỗi 504.

4. Các phụ thuộc dịch vụ

Nếu ứng dụng của bạn phụ thuộc vào các API hoặc microservices bên ngoài đang chậm hoặc không hoạt động, máy chủ ứng dụng của bạn sẽ chờ đợi chúng, có khả năng kích hoạt thời gian chờ gateway.

5. Cấu hình thời gian chờ sai

Đôi khi thời gian chờ đơn giản là được đặt quá thấp. Một gateway có thể có thời gian chờ 10 giây, nhưng một hoạt động phức tạp hợp lệ có thể mất 15 giây.

Kiểm tra và gỡ lỗi API với Apidog

Xác định nguyên nhân gốc rễ của các lỗi 504 không liên tục có thể giống như mò kim đáy bể. Khi gỡ lỗi 504, các nhà phát triển thường gặp khó khăn trong việc nhìn rõ - tìm ra máy chủ, dịch vụ hoặc yêu cầu nào là nguyên nhân. Apidog cung cấp một số tính năng giúp việc này dễ dàng hơn nhiều.

Với Apidog, bạn có thể:

  1. Kiểm tra hiệu suất: Sử dụng Apidog để gửi nhiều yêu cầu đồng thời đến API của bạn và đo thời gian phản hồi. Điều này có thể giúp bạn xác định xem các điểm cuối nhất định có chậm dưới tải hay không, điều này có thể dẫn đến lỗi 504.
  2. Thiết lập giám sát: Tạo các trình giám sát tự động trong Apidog định kỳ kiểm tra các điểm cuối của bạn. Nếu một yêu cầu mất nhiều thời gian hơn ngưỡng bạn đặt (ví dụ: 25 giây khi thời gian chờ gateway của bạn là 30), Apidog có thể cảnh báo bạn trước khi người dùng bắt đầu thấy lỗi 504.
  3. Kiểm tra phụ thuộc dịch vụ: Nếu API của bạn gọi các dịch vụ khác, hãy sử dụng Apidog để kiểm tra các phụ thuộc đó một cách độc lập. Điều này giúp bạn cô lập xem vấn đề nằm ở ứng dụng của bạn hay ở một dịch vụ hạ nguồn.
  4. Mô phỏng phản hồi chậm: Sử dụng máy chủ giả lập của Apidog để mô phỏng các phản hồi backend chậm. Điều này cho phép bạn kiểm tra cách gateway và ứng dụng của bạn xử lý thời gian chờ mà không thực sự làm quá tải hệ thống sản xuất của bạn.
  5. Tài liệu hóa các kỳ vọng về thời gian chờ: Sử dụng các tính năng tài liệu của Apidog để ghi chú các điểm cuối nào được dự kiến là chạy lâu, giúp nhóm của bạn đặt các giá trị thời gian chờ phù hợp trong hạ tầng.

Tải ứng dụng

Và vâng, bạn có thể tải Apidog miễn phí. Nó không chỉ là một giải pháp thay thế Postman khác mà còn là một hệ sinh thái hoàn chỉnh để thiết kế, kiểm thử và giám sát hiệu suất API.

Khắc phục sự cố và sửa lỗi 504

Các bước tức thời:

  1. Kiểm tra tài nguyên máy chủ: Xem xét CPU, bộ nhớ và I/O đĩa trên các máy chủ ứng dụng của bạn.
  2. Xem lại nhật ký: Kiểm tra nhật ký ứng dụng và gateway của bạn để tìm lỗi xung quanh thời điểm xảy ra lỗi 504.
  3. Xác minh các phụ thuộc bên ngoài: Đảm bảo bất kỳ API hoặc dịch vụ bên thứ ba nào mà ứng dụng của bạn sử dụng đều hoạt động tốt.

Các giải pháp dài hạn:

  1. Tối ưu hóa hiệu suất ứng dụng: Xác định và khắc phục các truy vấn cơ sở dữ liệu chậm, tối ưu hóa mã và triển khai bộ nhớ đệm.
  2. Điều chỉnh cài đặt thời gian chờ: Tăng giá trị thời gian chờ trên gateway của bạn nếu bạn có các hoạt động chạy lâu hợp lệ.
  3. Triển khai ngắt mạch: Sử dụng các mẫu ngừng gọi một dịch vụ bị lỗi sau nhiều lần thất bại, ngăn chặn các lỗi thời gian chờ xếp tầng.
  4. Mở rộng hạ tầng của bạn: Thêm nhiều máy chủ ứng dụng hoặc nâng cấp lên các phiên bản mạnh hơn.
  5. Triển khai xử lý bất đồng bộ: Đối với các tác vụ chạy lâu, hãy sử dụng hàng đợi công việc (như Redis Queue hoặc AWS SQS) và trả về ngay lập tức với mã 202 Accepted, sau đó thông báo cho người dùng khi tác vụ hoàn thành.

Các phương pháp hay nhất để ngăn chặn lỗi 504 dài hạn

Hãy kết thúc phần kỹ thuật với một số chiến lược phòng ngừa sẽ giúp bạn tránh khỏi những rắc rối về sau.

1. Sử dụng bộ nhớ đệm bất cứ khi nào có thể

Lưu trữ phản hồi vào bộ nhớ đệm (ở cấp độ ứng dụng, CDN hoặc proxy) giúp giảm tải backend và thời gian phản hồi.

2. Tối ưu hóa truy vấn cơ sở dữ liệu

Các truy vấn SQL được tối ưu hóa kém thường gây ra tắc nghẽn backend – hãy điều chỉnh chỉ mục và tránh các phép nối lớn.

3. Giám sát tình trạng API

Sử dụng các công cụ như Apidog, Datadog hoặc Pingdom để liên tục giám sát thời gian hoạt động và hiệu suất API.

4. Triển khai ngắt mạch

Thêm một mẫu ngắt mạch vào API của bạn để tạm thời dừng các yêu cầu đến các dịch vụ bị lỗi.

5. Tự động mở rộng

Sử dụng tính năng tự động mở rộng trong các môi trường đám mây như AWS hoặc Azure để xử lý các đợt tăng đột biến lưu lượng truy cập.

6. Ghi nhật ký mọi thứ

Ghi nhật ký tập trung giúp bạn phát hiện các điểm cuối chậm trước khi chúng trở thành sự cố ngừng hoạt động hoàn toàn.

Khía cạnh con người: Giao tiếp trong thời gian ngừng hoạt động

Giao tiếp minh bạch trong thời gian chờ gateway là rất quan trọng. Thông báo cho người dùng khi một dịch vụ đang gặp sự cố chậm trễ, đưa ra thời gian phục hồi dự kiến nếu có thể và cung cấp các cập nhật trạng thái. Một kế hoạch ứng phó sự cố được quản lý tốt sẽ giảm sự khó chịu của người dùng và xây dựng lòng tin.

Các mẫu kiến trúc để giảm thiểu lỗi Gateway

Các mẫu này giúp bạn hạn chế tác động của sự chậm trễ upstream và giữ cho trải nghiệm người dùng không bị gián đoạn.

Kết luận: Cái giá của hệ thống phân tán

Mã trạng thái HTTP 504 Gateway Timeout là một hệ quả tự nhiên của kiến trúc web phân tán, hiện đại. Mặc dù gây khó chịu cho người dùng, nó phục vụ một mục đích quan trọng: ngăn chặn các yêu cầu bị treo vô thời hạn và đảm bảo hệ thống tổng thể vẫn phản hồi.

Hiểu rằng lỗi 504 về cơ bản là một vấn đề giao tiếp giữa các máy chủ – không nhất thiết là lỗi ứng dụng – là chìa khóa để khắc phục sự cố hiệu quả. Bằng cách giám sát hiệu suất, tối ưu hóa các hoạt động chậm và cấu hình hạ tầng của bạn đúng cách, bạn có thể giảm thiểu những lỗi này và cung cấp trải nghiệm tốt hơn cho người dùng của mình.

Lần tới khi bạn thấy lỗi 504, bạn sẽ biết đó là câu chuyện về một máy chủ gateway kiên nhẫn cuối cùng phải từ bỏ việc chờ đợi. Và khi bạn đang xây dựng các hệ thống cần tránh những lỗi thời gian chờ này, một công cụ như Apidog có thể là đồng minh tốt nhất của bạn trong việc xác định các nút thắt cổ chai về hiệu suất và đảm bảo API của bạn phản hồi kịp thời.

Tải ứng dụng

Thực hành thiết kế API trong Apidog

Khám phá cách dễ dàng hơn để xây dựng và sử dụng API

Đăng ký miễn phíTải xuống