#Симптом и границы применимости
На многосайтовом Nginx один домен долго ожидает первый байт, тогда как соседние домены быстрые. Время запроса, задержка подключения и отдача содержимого — разные показатели. Сначала отделите медленную статику от динамики и замерьте один и тот же URL без пользовательских данных.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Ожидание конкретного upstreamNginx может простаивать, ожидая PHP или отдельный сервис. | Только URL через proxy_pass медленные; статика быстро отвечает | Измерить upstream и журналы приложения |
| Домен ведёт на иной узелМедленный узел может находиться до Nginx. | DNS, IPv6 или CDN отличаются от соседних сайтов | Сравнить прямой адрес узла и публичный домен |
| Один каталог или хранилище тормозитФайлы на сетевом томе и ошибки диска влияют на отдельный сайт. | Медленна даже статика этого сайта, iowait повышен | Проверить путь root/alias и дисковую подсистему |
#Пошаговая диагностика и исправление
- Повторите симптом на безопасном адресеОткройте терминал на клиентском компьютере, выберите публичный URL без входа и персональных данных. Выполните несколько последовательных GET-запросов. Время time_connect показывает соединение, time_starttransfer — ожидание первого байта, time_total — весь ответ. Сравните с таким же небольшим статическим файлом соседнего сайта.
- curl: Linux, macOS или Windows с установленной утилитой; замените доменLinux · Терминал (Bash)Командаcurl: Linux, macOS или Windows с установленной утилитой; замените домен. Только чтение.
curl -sS -o /dev/null -w "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} status=%{http_code}\n" https://example.com/
- Проверьте путь запроса и отдельный виртуальный серверЧерез SSH проверьте действующую конфигурацию, найдите server_name проблемного домена и его root, alias, proxy_pass или fastcgi_pass. Не редактируйте пока ничего: Nginx может быть первым прокси перед Apache и PHP-FPM.Linux · Терминал (Bash)КомандаНужен sudoВывод может раскрывать внутренние имена; не публикуйте его целиком.
sudo nginx -T 2>&1 | grep -nE "server_name|root |alias |proxy_pass|fastcgi_pass"
- Сравните обработку статики и динамикиЗапросите заранее известный существующий статический файл, затем динамический адрес без изменения данных. Если статика быстра, а динамика нет, смотрите медленные запросы PHP, базы данных и upstream. Если оба медленные, изучайте DNS, TLS, файлы и сеть; не увеличивайте лимиты процессов вслепую.
- Сопоставьте время и сообщения журналовВыполните тестовый запрос и сразу просмотрите журнал именно этого server-блока. Ищите upstream timed out, connect() failed, open() failed. При отсутствии записей проверьте, какой журнал активен; не делайте вывод из одного общего файла.
- Systemd может не хранить журналы HTTP-доступа: пути задаются access_log/error_logLinux · Терминал (Bash)КомандаНужен sudoSystemd может не хранить журналы HTTP-доступа: пути задаются access_log/error_log.
sudo journalctl -u nginx -n 100 --no-pager
- Снимите безопасные метрики ресурсовВ момент задержки посмотрите память, процессоры, свободное место и ожидание диска. Для дисков используйте iostat при наличии пакета sysstat; установка нового пакета сама по себе необязательна. Если ожидает только база конкретного сайта, исследуйте её журнал медленных запросов.
- Дополнительная команда по темеLinux · Терминал (Bash)КомандаКоманды чтения в SSH; недостаток свободной памяти или места — повод разобраться с причиной, а не удалять файлы.
uptime; free -h; df -h; ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
- Исправьте только найденную причинуЕсли виноват upstream, устраните ошибку приложения и проверьте отдельный пул; если хранилище — восстановите его доступность. Перед настройками сохраните исходный файл; изменяйте лишь параметры проблемного сайта и проверяйте nginx -t, затем reload. Если проблема с базой — исправления выполняются на уровне базы, а не Nginx.Linux · Терминал (Bash)С осторожностьюНужен sudoReload выполняйте только если конфигурация менялась и проверка успешна.
sudo nginx -t && sudo systemctl reload nginxКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как проверить результат
Повторите исходный curl для проблемного и контрольного сайта 3–5 раз; сравните медианное time_starttransfer, коды и журнал ошибок. Проверьте, что соседние сайты не замедлились.
#Если проблема не устранена
Если первый байт медленный только из внешней сети, проверяйте DNS, IPv4/IPv6 и CDN. Если только динамика — соберите трассировку PHP/базы с ответственным администратором; не повышайте тайм-ауты как замену устранению задержки.