Как найти слой ожидания при 504, проверить завершение записи, измерить этапы долгой операции и безопасно разделить её на наблюдаемые партии вместо слепого увеличения лимитов.
Что сообщает 504 и чего он не доказывает
504 Gateway Timeout означает, что шлюз не получил своевременный ответ от следующего сервера, необходимый для обработки запроса. Причина может быть в ожидании соединения, занятом обработчике, базе или внешнем API. Код не показывает, какой именно участок занял время, и не гарантирует прекращение приложения. Поэтому сначала выясняют состояние операции, затем исследуют длительность.
Важное различие: ограничение браузерного ожидания, лимит CDN, ожидание прокси, время работы PHP и тайм-аут внешнего клиента могут быть независимыми. Для Nginx read_timeout соответствующего модуля описывает интервал между последовательными чтениями, а не просто универсальный максимум всей передачи. Не подставляйте одно число из панели во все слои. Реальную схему подтверждает администратор.
Не повторяйте запись вслепую
После таймаута создание заказа, импорт или изменение записи могли продолжиться на сервере. Прежде чем нажимать кнопку ещё раз, проверьте результат в приложении и внешней системе. Дублирование особенно опасно для платежей, складских операций и массовых отправок.
Запишите время начала, время ошибки, URL и тип операции. Сравните длительность нескольких случаев: одинаковый интервал может указать на определённый лимит, но сам по себе не доказывает его расположение.
Постройте цепочку ожидания
| Участок | Что может задерживать |
|---|---|
| CDN → origin | Соединение или обработка на origin |
| Прокси → PHP | Очередь обработчиков или долгий код |
| PHP → БД | Запрос, блокировка, соединение |
| Приложение → API | Медленный внешний ответ |
| Фоновая обработка | Слишком большая партия или повторные попытки |
Разделите проблему по маршрутам
Проверьте статическую страницу, обычную запись и конкретное действие. Если медленный только импорт, не перенастраивайте весь сайт по результату одной операции. Если задерживаются все PHP-запросы, исследуйте процессы, ресурсы и общую зависимость.
Сопоставьте журнал прокси, PHP и приложения по времени. У внешнего API сохраняйте статус и длительность без токенов и персональных данных. Ошибка сети, отказ сервиса и успешный медленный ответ требуют разной обработки.
Учебный разбор импорта с неизвестным результатом
Представьте импорт тестового каталога: интерфейс показал 504, но часть товаров уже обновилась. Это учебный сценарий, а не выполненное испытание. Первым действием остановите автоматический повтор. Прочитайте журнал импорта и выборку по устойчивым SKU. Определите, какие строки приняты, какие отклонены, есть ли идентификатор партии и сохраняется ли прогресс. Число строк в исходном файле не равно числу успешно записанных товаров.
| Проверка | Зачем нужна |
|---|---|
| SKU и идентификатор партии | Различить продолжение и новый импорт |
| Цены и остатки выборки | Увидеть частично применённые данные |
| Ошибки отдельных строк | Не повторять неверные данные без исправления |
| Внешние уведомления | Понять, ушли ли события при первой попытке |
| Повтор одной тестовой строки | Проверить отсутствие дубля на стенде |
Если инструмент не сохраняет понятный прогресс, разработчик должен определить безопасную стратегию продолжения. Нельзя просто уменьшить файл и начать заново, не зная, будут ли товары обновлены по ключу или созданы повторно. Проверка должна включать вариации, связи изображений и связанные фоновые действия, если импорт их создаёт.
Как собрать профиль ожидания
Для одного воспроизводимого запроса сохраните момент начала, этапы приложения и завершение либо отказ. Согласуйте единый часовой пояс. Полезно отделить очередь до начала PHP, запросы базы, обращения к внешнему API и обработку ответа. Идентификатор запроса позволяет связать журналы; секреты и содержимое клиентских данных для этого обычно не нужны.
Запрос: внутренний ID
Старт на шлюзе: ...
Начало обработчика: ...
Обращение к внешнему API: начало / конец / статус
Запись результата: подтверждена / неизвестна
Ответ шлюза: 504 в ...
Итог приложения после ошибки: ...На VPS администратор может использовать штатный slowlog PHP-FPM по отдельному плану. Подробная диагностика сама расходует ресурсы и может раскрывать контекст, поэтому у неё должны быть область, срок и место хранения. На shared запросите у поставщика данные по конкретному времени. Отсутствие доступа к внутреннему журналу не даёт основания придумать причину.
Долгие задачи лучше делать управляемыми
Если инструмент поддерживает партии, разделите импорт или обработку на меньшие части и сохраняйте прогресс. Проверьте повторный запуск после прерывания: он должен продолжать или безопасно повторять работу по правилам приложения, а не создавать дубликаты.
Для фонового задания нужен наблюдаемый статус, журнал и ответственный. Перенос работы из HTTP-запроса в очередь не гарантирует успех: очередь тоже может не запускаться или постоянно падать. После изменения проверьте реальное завершение и итоговые данные.
Когда обсуждать таймауты
Сначала подтвердите, что операция корректна и ожидаемо длительна, а ресурсы достаточны. Затем согласуйте лимиты каждого промежуточного слоя. Если внешний прокси ждёт меньше, изменение только PHP не решит проблему. На shared-площадке доступные значения определяются регламентом.
Не ставьте бесконечное ожидание как универсальное исправление. Оно может удерживать процессы и ухудшать доступность остальных запросов. Оценивайте одновременность и ресурс на случай, когда внешняя зависимость не отвечает.
Проверка партии и восстановления после прерывания
Размер партии выбирают по фактическому времени и памяти своего обработчика. Не существует универсального числа товаров, подходящего любому каталогу: один товар с вариациями и изображениями может требовать другой работы, чем простая строка цены. На стенде начните с малого обезличенного набора и наблюдайте завершение каждой партии, затем проверьте последовательность нескольких запусков.
- Подготовьте стабильные тестовые ключи и ожидаемые значения.
- Выполните одну партию и сверяйте данные, журнал и внешние эффекты.
- Повторите ту же партию по предусмотренным правилам идемпотентности.
- Смоделируйте контролируемое прерывание в изолированной среде.
- Проверьте продолжение и отсутствие лишних записей.
- Только затем согласуйте рабочую последовательность и наблюдение.
Не создавайте искусственные отказы на рабочем платёжном потоке. Для внешней зависимости используйте её тестовый режим или предусмотренную разработчиком имитацию. Перенос в очередь считается успешным, когда задачи реально завершаются и данные согласованы, а не когда браузер перестал ждать. Отдельно подтвердите запуск очереди при отсутствии посетителей.
Пример приёмки
После разделения импорта проверьте небольшую выборку товаров, затем повторный запуск и отказ внешнего сервиса на стенде. Сверьте цены, остатки и количество записей. Прогресс без HTTP-ошибки не заменяет проверку результата.
Для пользовательского действия проверьте понятное состояние после сбоя: создан ли заказ, можно ли безопасно повторить запрос, получено ли подтверждение. Запишите границы проверки. Если найден только временный обход, не называйте причину устранённой.
Возврат временной настройки и закрытие инцидента
Если увеличивали тайм-аут как временный обход, запишите исходное значение, область и срок возврата. После исправления кода проверьте поведение при медленном или недоступном внешнем сервисе: процессы не должны бесконтрольно удерживаться, а посетитель должен видеть понятный статус операции. Настройка одного маршрута не обязана распространяться на весь сайт.
Возврат тайм-аута не отменяет созданные товары, письма и заказы. Согласование данных выполняют отдельно по журналам и устойчивым идентификаторам. Не восстанавливайте всю вчерашнюю базу ради отмены одного импорта, если за это время появились новые рабочие записи. Сохраните итоговую сверку и перечень нерешённых строк.
FAQ и вывод
504 доказывает, что сервер ничего не сохранил?
Нет. Обработчик мог продолжить работу или завершить запись до потери ответа. Сначала прочитайте реальное состояние.
Почему увеличение PHP-лимита не помогло?
Ограничение могло находиться в CDN, прокси или внешнем клиенте. Нужно подтвердить всю цепочку ожидания.
Можно ли поставить бесконечный тайм-аут?
Это удерживает ресурсы при зависимостях и может ухудшить доступность. Предпочтителен ограниченный наблюдаемый режим по реальной задаче.
Очередь автоматически решает проблему?
Нет. Нужны работающий запуск, журнал, безопасный повтор и проверка итоговых данных.
Считайте проблему разобранной после установления слоя ожидания, приёмки результата и проверки повторного выполнения. Если пока применён только обход, обозначьте его как временный и сохраните план дальнейшего исследования.
Источники и дата
- RFC 9110: 504
- Nginx: proxy_read_timeout
- Nginx: fastcgi_read_timeout
- PHP-FPM: slowlog
- HTTP 504
- Action Scheduler
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
