504 Gateway Timeout: какво означава и как да я поправите

Какво означава грешката

504 е уеб сървърът отпред (nginx, Apache, балансьор на натоварването, CDN), който се отказва от приложението зад себе си. Заявката е била предадена, бекендът е започнал работа и таймерът на предния сървър е изтекъл, преди да дойде отговор. Разликата спрямо 502 Bad Gateway е, че бекендът е достъпен; просто е твърде бавен. Типичните таймери са 60 секунди в nginx (fastcgi_read_timeout, proxy_read_timeout), 60 секунди в Apache (ProxyTimeout) и 100 секунди при Cloudflare, които не можете да промените при безплатния план.

Повишаването на времето за изчакване рядко е поправката. Нещо отнема твърде дълго и именно него трябва да намерите.

Чести причини

1. Бавна заявка към базата данни. Плъгин на WordPress, който брои редовете в огромна таблица при всяко зареждане на страница, липсващ индекс, таблица wp_options, пълна с изтекли transient-и. Всяка заявка чака и под натоварване чакането се натрупва.
2. Външно обаждане, което увисва. Приложението се свързва с платежен доставчик, пощенска услуга, API за времето или лицензен сървър и тази услуга е бавна или не работи. Без таймаут за това обаждане страницата Ви го чака.
3. Твърде малко работници. Всички PHP-FPM работници са заети с бавни заявки; новите чакат на опашка, докато предният сървър се откаже. Отвън това изглежда като таймаут, макар всяка отделна заявка да би била бърза.
4. Cron или резервно копие, изпълнявани на преден план. Плъгин за резервни копия, импорт, карта на сайта от 50 000 URL: генерирани в рамките на уеб заявка, те надхвърлят всеки таймаут.
5. Дисков I/O или swap. На сървъра му свършва паметта и започва да ползва swap; всичко се забавя десетократно. Вижда се като високо натоварване с ниско използване на процесора.
6. Мрежата между предния и задния сървър. Балансьор в един център за данни, бекенд в друг, защитна стена, която мълчаливо губи пакети. Рядко, но 504 при всяка заявка при бездействащ бекенд сочи към това.

Ако сте посетител

Презаредете след минута. Ако сайтът е бавен, а не недостъпен, опитайте друга страница; таймаутът може да е свързан с една тежка страница.

Ако е Вашият сайт: проверете първо

Пуснете проверката дали сайтът не работи: тя отчита кода на състоянието и времето за отговор отвън. Сайт, който днес отговаря за 30 секунди, е сайт, който утре ще покаже 504 под натоварване.

На Ваш собствен сървър намерете къде отива времето:

# are workers piling up?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# what is PHP doing right now? (needs pm.status_path in the pool)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB: which queries are running, and for how long?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# memory and swap
free -m
vmstat 1 5

Списък с процеси, пълен с една и съща заявка, или колони si/so във vmstat, които не са нула, назовават причината.

Поправки на Вашия собствен сървър

1. Включете лога за бавни заявки и поправете заявката

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

След няколко минути sudo mysqldumpslow -s t /var/log/mysql/slow.log | head изброява най-лошите заявки. Добавете липсващия индекс или намерете плъгина, който изпълнява заявката, и го заменете. В WordPress раздутата таблица с опции е класика:

wp transient delete --all
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Всичко от порядъка на стотици килобайти, което се зарежда автоматично при всяка заявка, е кандидат за премахване.

2. Сложете таймаут на външните обаждания

Всяко HTTP обаждане, което приложението Ви прави, се нуждае от собствен таймаут, по-кратък от този на уеб сървъра. В PHP с cURL: CURLOPT_CONNECTTIMEOUT 5 и CURLOPT_TIMEOUT 10. В WordPress wp_remote_get() приема аргумент timeout; много плъгини го оставят по подразбиране и чакат вечно. Ако услуга на трета страна не работи, страницата трябва да се влоши плавно (да покаже формата без актуалната цена за доставка), не да умре.

3. Изнесете дългата работа извън заявката

Резервните копия, импортите, експортите, големите карти на сайта и изпращането на поща принадлежат в cron задача или опашка, не в преглед на страница. За WordPress изключете псевдо-cron и пуснете истинския:

// wp-config.php
define('DISABLE_WP_CRON', true);

# crontab -e
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

4. Нагласете времената за изчакване, внимателно

Ако една отделна страница легитимно се нуждае от повече време (администраторски експорт, отчет), повишете таймаута само за това място, не глобално:

location = /wp-admin/export.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
}

Apache с PHP-FPM: ProxyTimeout 300 в блок <Location>. Самият PHP има max_execution_time; задайте го на същата стойност, иначе PHP спира първи и получавате 500 вместо това. После sudo nginx -t && sudo systemctl reload nginx.

5. Спрете swap-а

ps aux --sort=-%mem | head

Ако всеки PHP-FPM работник ползва 150 MB и пускате 30 от тях на сървър с 4 GB, сметката не излиза. Намалете pm.max_children, увеличете паметта или поправете плъгина, който ползва паметта. Сървър, който не ползва swap, е сървър, чиито 504 повечето изчезват.

6. Кеш

Кеш на цели страници (FastCGI кеш на nginx, плъгин за кеширане на WordPress, Varnish) обслужва повтарящите се посетители, без да докосва PHP или базата данни. Повечето 504 под натоварване изчезват, щом началната страница и най-посещаваните страници идват от кеша.

Когато е проблем на Вашия хостинг

При споделен хостинг можете да поправяте бавни заявки и плъгини, но не и таймаутите на сървъра или натоварването на съседите. Изпратете на хостинга си:

Здравейте, сайтът ми example.com връща „504 Gateway Timeout“ от около 16:00 UTC. Страници, които се зареждаха за под две секунди, сега изтичат. Не съм променял нищо. Моля, проверете дали сървърът на базата данни или PHP пулът на акаунта ми е претоварен, или друг акаунт на сървъра причинява високо натоварване, и ми кажете какво установите.

Как да предотвратите следващата

504 е бавен сайт, който е станал по-бавен, а времето за отговор е измеримо много преди таймаута. Проверките на сайта записват времето за отговор на всяка проверка; задайте сигнал за него и ще видите тенденцията седмици преди посетителите да видят грешка. Сървърният агент добавя натоварване, памет и swap отвътре. На Ваш собствен сървър Deep Fix намира бавната заявка или увисналото обаждане и го поправя, таксуван на блокове от 15 минути, цена преди поръчка.