nginx

Просто удалить файлы в папке с кэшем:
find /var/cache/nginx/proxy/ -type f -delete

По-русски:
Такая ошибка может быть если nginx работает как прокси (например, к apache), и от бэкенда пришел ответ со слишком большим заголовком.

Часто наблюдаю этот вопрос, посему ответ:

504 - значит скрипт (бэкенд) слишком долго отвечал или скрипт завершается раньше, чем получен ответ.
Причин может быть много: недостаток ресурсов (чаще всего - оперативной памяти), кривые скрипты, проблемы с базой данных и файловой системой, кривая настройка сервера...

Публикую статью, написанную it-специалистом.
Учитывайте чужой опыт, господа. Думайте мозгом сразу, а не кидайтесь от технологии к технологии.

---
Узнать, как отмасштабировать Ваше приложение, не имея при этом никакого опыта, — это очень нелегко. Сейчас есть много сайтов, посвященных этим вопросам, но, к сожалению, не существует решения, которое подходит для всех случаев. Вам по-прежнему необходимо самому находить решения, которые подойдут под Ваши требования. Так же, как и мне.

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

ПО сайта представляло собой CMS на PHP, с применением MySQL и Smarty. Первым делом была найдена хостинговая компания, которая имела опыт высоконагруженных проектов. Мы предоставили им свою требуемую конфигурацию:
Балансировка нагрузки (с запасом)
2 веб-сервера
MySQL сервер (с запасом)
машина для разработки

Что мы получили (хостер сказал, что этого будет достаточно):
Балансировка нагрузки — Single core, 1 Гб RAM, Pound
2 веб-сервера — Dual core, 4 Гб RAM, Apache
MySQL сервер — Quad core, 8 Гб RAM
машина для разработки — Single core, 1 Гб RAM

Для синхронизации файлов хостер установил DRBD в конфигурации active-active.

Наконец, время переноса пришло. Рано утром мы переключили домен на новые IP и начали мониторить наши скрипты. Трафик мы получили практически сразу и казалось, что все работает хорошо. Страницы загружались быстро, MySQL обрабатывал кучу запросов и все были счастливы.

Затем неожиданно прозвонил телефон: «Мы не можем зайти на веб-сайт, что происходит?!» Мы посмотрели в наше ПО для мониторинга и увидели, что сервера упали и сайт не работал. Конечно, первым делом мы позвонили хостеру и сказали: «все наши сервера упали. Что происходит?!» Они пообещали проверить сервера и перезвонить после этого. Спустя некоторое время они позвонили: «Ваша файловая система безнадежно испорчена. Что Вы делали?!» Они остановили балансер и и сказали мне посмотреть на один из веб-серверов. Открыв index.php, я был шокирован. Он содержал непонятные куски кода на Си, сообщения об ошибках и что-то, похожее на лог-файлы. После небольшого расследования мы установили, что причиной этому была наша DRBD.

Исходная статья годовалой давности, но всё равно весьма полезный приём, например
если апач жрёт много ресурсов, не хватает памяти на сервере, тормозит база данных и т.д.
Просто положить готовые страницы в виде файлов и всё.
Притом даже если будет сбой бэкенда (ошибки HTTP 500, 502, 503, 504) - всё равно nginx сможет вернуть рабочую страницу.
---
23 марта вышел nginx 0.7.44, в нем наконец то появилось обещенное кеширование в модуле проксирования. Что нам это дает?
Как правило nginx используют для проксирования на всевозможные тяжеловесные веб сервера, которые долго и тяжело обрабатывают запросы. Не даром среди модулей nginx присутствует замечательно выполненный модуль upstream, который позволяет гибко балансировать нагрузку при проксировании. Теперь же, при наличии большого дискового кеша, nginx сможет сам обрабатывать такие запросы, не беспокоя при этом бекэнды.

teerex, Сегодня 16:08:32:
нгинкс рулит
KYbik, Сегодня 16:09:46:
почта России не рулит