Раздача видео и больших файлов в Nginx: чек-лист

Большой файл, который Nginx отдаёт напрямую с диска, не обязан проходить через PHP, Python или Node.js. Но если путь настроен неверно, видео не перематывается, а при скачивании Nginx упирается в диск или сетевой канал. Этот чек-лист рассчитан на Nginx Open Source 1.24–1.26: он поможет проверить конфигурацию и нагрузочный сценарий до продакшена. Для другой версии сверьте директивы с документацией.

Сначала выберите способ раздачи

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

X-Accel-Redirect — механизм, при котором приложение возвращает специальный заголовок, а Nginx передаёт управление внутреннему location и отдаёт файл сам.

Проверяйте не только скорость скачивания, но и то, кто имеет право получить файл. Быстрая раздача закрытого видео всем подряд — не оптимизация.

Чек-лист конфигурации

1. Сопоставьте URL с каталогом

Для обычного статического файла можно начать с такого location. Пример подходит для Nginx Open Source 1.24–1.26; перед применением проверьте его в своей конфигурации и выполните проверку синтаксиса.

server {
    listen 80;
    server_name media.example.com;

    location /media/ {
        alias /srv/media/;
        sendfile on;
        tcp_nopush on;
        max_ranges 1;
    }
}

При запросе /media/film.mp4 Nginx ищет файл /srv/media/film.mp4. Завершающий слеш в URI и в пути alias здесь важен: если изменить один из них, проверьте итоговое сопоставление. Убедитесь, что пользователь, от имени которого работает Nginx, может читать каталог и файлы.

• Проверьте конфигурацию командой nginx -t. Успех — сообщение о корректном синтаксисе и успешной проверке.
• После изменения примените конфигурацию штатным способом для вашего окружения и проверьте журнал ошибок Nginx.
• Запросите известный файл по URL. Если получаете 404, проверьте соответствие URI, alias и фактического пути.

root и alias не взаимозаменяемы по правилу построения пути. При root Nginx добавляет URI к заданному каталогу; при alias заменяет часть URI, совпавшую с location. Для вложенных location и сложной структуры каталогов проверьте результат на реальном пути, а не по аналогии.

2. Проверьте перемотку и докачку

Видеоплееру обычно нужны запросы диапазона байтов: клиент просит не весь файл, а его часть. Это позволяет перематывать ролик и продолжать загрузку после обрыва. Проверьте ответ на Range-запрос: сервер должен корректно обработать диапазон и вернуть частичный ответ. Например, в заголовках ответа ожидаются статус 206 Partial Content и Content-Range. Не ориентируйтесь только на то, что файл открывается целиком.

Проверить заголовки можно через клиент HTTP, поддерживающий запросы диапазона. Зафиксируйте результат для видео и для файла, который предполагается докачивать. Директива max_ranges 1 ограничивает число диапазонов в одном запросе, но не отключает одиночный диапазон, нужный для обычной перемотки. Если ваш клиент использует несколько диапазонов, проверьте совместимость до включения ограничения.

3. Не включайте дисковые оптимизации наугад

sendfile on позволяет Nginx использовать механизм ОС для передачи файлов. Это разумная отправная точка для обычной статической раздачи. tcp_nopush on имеет смысл при включённом sendfile: настройка влияет на отправку TCP-пакетов, но не заменяет тестирование на вашей ОС и сетевом тракте.

Не добавляйте aio, directio и нестандартные настройки буферов только потому, что файл большой. Эффект зависит от ОС, файловой системы, размера файлов и диска; на одной системе настройка может помочь, на другой — ухудшить задержки. Сначала измерьте исходное поведение, затем меняйте по одному параметру.

4. Проверьте доступ и заголовки

Если файлы публичные, убедитесь, что в каталоге нет служебных документов, резервных копий и исходников. Не давайте URL-путь к закрытому каталогу через публичный location. Для авторизованной раздачи используйте проверку доступа в приложении и передачу файла через внутренний location, недоступный напрямую извне.

Проверьте тип содержимого, кеширование и поведение CDN, если он стоит перед Nginx. Заголовок кеширования, подходящий для неизменяемого файла с версией в имени, может быть опасен для файла, который обновляют по прежнему URL. Согласуйте срок кеша с тем, как вы публикуете новые версии.

Что измерить до запуска

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

• Запишите скорость передачи одного файла и нескольких параллельных файлов.
• Наблюдайте за загрузкой CPU, дисковой задержкой и сетевым трафиком на сервере.
• Проверьте долю ответов 4xx и 5xx, а также ошибки чтения файлов в журнале Nginx.
• Повторите тест с перемоткой и продолжением загрузки после разрыва соединения.
• Проверьте, что обычные запросы сайта не начинают отвечать медленнее во время скачиваний.

Запишите условия теста вместе с результатом: конфигурацию, размер файла, число клиентов, сервер и сеть. Без этих данных сравнение «до и после» мало что говорит. Меняйте за один прогон только одну настройку.

Где подход ломается

Перемотка работает, но приложение занято

Если запрос проксируется через приложение, оно может оставаться занятым на время передачи большого ответа. Это влияет на его соединения и ресурсы. Решение — не обязательно менять всю схему: для подходящего сценария приложение может авторизовать запрос, а передавать файл будет Nginx. Проверьте документацию вашей версии Nginx и приложения перед настройкой X-Accel-Redirect.

404 или 403 после переноса файлов

404 обычно указывает на несовпадение URL и пути; 403 может означать запрет доступа к файлу или одному из родительских каталогов. Проверьте путь на сервере, права чтения для пользователя Nginx и журнал ошибок. Не исправляйте проблему выдачей прав на запись всем пользователям.

Сервер отвечает быстро, а зрители жалуются

Причиной может быть не Nginx, а пропускная способность канала, дальность до клиента, CDN или плеер. Сопоставьте время ответа сервера и фактическую скорость загрузки у клиентов. Для большой аудитории перенос раздачи на CDN может снять нагрузку с канала origin-сервера, но добавит стоимость хранения и трафика, а также требования к кешированию и очистке устаревших файлов.

Что делать дальше

Начните с прямой раздачи тестового файла, проверки диапазонов и теста параллельных скачиваний. Затем решите, должны ли файлы быть публичными или доступ к ним проверяет приложение. Если используете CDN, отдельно проверьте кеширование диапазонных запросов и обновление файла по прежнему URL. Следующий полезный шаг — включить метрики диска и сети и сохранить базовые значения до выхода на рабочую нагрузку.