Если видео лежит в /wp-content/uploads/ и отдается напрямую, его URL легко утащить из исходника страницы, медиабиблиотеки или логов. Для публичного сайта это обычно не критично, но на практике появляются три проблемы: хотлинк с чужих доменов, лишняя нагрузка на сервер и обход ограничений, если видео должно быть доступно только на страницах сайта.
Ниже — рабочий сценарий для WordPress: сначала разберем, как понять, что именно у вас открыто, потом закроем прямой доступ к файлам на уровне Apache или Nginx, а затем проверим, что сайт не сломался.
Когда это действительно нужно
Не стоит закрывать видео «на всякий случай», если файл должен свободно индексироваться, встраиваться в другие страницы или раздаваться через CDN без ограничений. Но защита прямых ссылок оправдана, если:
- видео используется только внутри сайта и не должно открываться по прямому URL;
- на сервере растет трафик из-за хотлинка;
- файлы лежат в медиабиблиотеке, но доступны без проверки прав;
- нужно уменьшить число случайных скачиваний из папки uploads;
- вы хотите хотя бы частично ограничить доступ к внутренним материалам без перехода на полноценное хранилище с подписанными URL.
Диагностика: что именно сейчас открыто
Сначала проверьте, как отдается файл. Возьмите прямой URL видео из медиабиблиотеки и откройте его в браузере в режиме инкогнито. Если файл скачивается или проигрывается без авторизации, значит доступ открыт. Для проверки заголовков удобно использовать curl:
curl -I https://example.com/wp-content/uploads/2026/01/video.mp4Смотрите на три вещи:
200 OK— файл доступен напрямую;Content-Type: video/mp4илиvideo/webm— сервер отдает файл как видео;- отсутствие редиректа на страницу-заглушку или ошибку
403— значит защита не включена.
Если у вас Nginx, проверьте еще и конфиг сайта: иногда прямой доступ закрыт для части путей, но /uploads/ остается открытым по умолчанию.
Что выбрать: .htaccess, Nginx или код в WordPress
| Подход | Когда подходит | Минус |
|---|---|---|
.htaccess | Apache / LiteSpeed, нужен быстрый запрет по расширению | Не защищает от всех сценариев, если файл уже отдается через другой обработчик |
| Nginx | Сайт на Nginx, нужен контроль на уровне сервера | Требует доступа к конфигу и перезагрузки сервиса |
| PHP/WordPress | Нужна проверка прав пользователя перед выдачей файла | Нагрузка выше, чем у серверного решения |
Если задача именно в том, чтобы закрыть прямые ссылки, начинайте с сервера. Код в WordPress имеет смысл только когда доступ зависит от авторизации, роли или подписки.
Решение для Apache: запрет прямого доступа к видеофайлам
На Apache можно ограничить доступ к конкретным расширениям в папке uploads. Самый простой вариант — добавить правила в .htaccess в корне сайта или в отдельный .htaccess внутри wp-content/uploads, если хостинг это позволяет.
<IfModule mod_rewrite.c>
RewriteEngine On
# Запрет прямого доступа к видеофайлам
RewriteCond %{REQUEST_URI} ^/wp-content/uploads/.*\.(mp4|webm|mov|m4v)$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com/ [NC]
RewriteRule .* - [F,L]
</IfModule>Этот вариант работает как базовая защита от хотлинка: если запрос пришел не с вашего домена, сервер вернет 403 Forbidden. Но у него есть ограничение — Referer можно не передавать вообще. Поэтому правило не стоит считать полноценной защитой приватного контента.
Если нужно полностью закрыть прямой доступ к файлам, а не только хотлинк, используйте более жесткое правило:
<IfModule mod_authz_core.c>
<FilesMatch "\.(mp4|webm|mov|m4v)$">
Require all denied
</FilesMatch>
</IfModule>Такой вариант блокирует открытие файла по прямому URL. Но он сломает обычное встраивание видео из медиабиблиотеки, если плеер пытается читать тот же файл напрямую. Для публичных страниц это обычно не подходит без дополнительной логики выдачи.
Решение для Nginx: закрыть доступ к uploads по расширению
На Nginx правило обычно добавляют в конфиг сайта. Это надежнее, чем пытаться решать задачу на уровне WordPress. Пример для видеофайлов в /wp-content/uploads/:
location ~* ^/wp-content/uploads/.*\.(mp4|webm|mov|m4v)$ {
valid_referers none blocked example.com *.example.com;
if ($invalid_referer) {
return 403;
}
}Если вы хотите именно запретить прямое открытие, а не только хотлинк, можно вернуть 404 или 403 для всех запросов к этим расширениям:
location ~* ^/wp-content/uploads/.*\.(mp4|webm|mov|m4v)$ {
return 403;
}После изменения конфига не забудьте проверить синтаксис и применить настройки:
nginx -t
systemctl reload nginxЕсли сайт на управляемом хостинге, эти команды могут быть недоступны. Тогда правило нужно вносить через панель хостинга или писать в поддержку.
Если доступ должен зависеть от авторизации
Когда видео должно быть доступно только зарегистрированным пользователям, серверного запрета недостаточно. В этом случае файл лучше не хранить как обычный публичный URL в uploads, а отдавать через PHP после проверки прав. Это медленнее, но контролируемо.
Пример простого обработчика в теме или мини-плагине:
<?php
add_action('template_redirect', function () {
if (!isset($_GET['protected_video'])) {
return;
}
if (!is_user_logged_in()) {
status_header(403);
exit('Access denied');
}
$file = WP_CONTENT_DIR . '/uploads/protected/video.mp4';
if (!file_exists($file)) {
status_header(404);
exit('Not found');
}
nocache_headers();
header('Content-Type: video/mp4');
header('Content-Length: ' . filesize($file));
readfile($file);
exit;
});Это не замена CDN с подписанными ссылками, но для внутреннего видеоархива или закрытого раздела сайта такой подход работает. Главное — не хранить путь к файлу в открытом HTML и не отдавать его напрямую из медиабиблиотеки.
Пошагово: как внедрить без поломки сайта
- Сделайте резервную копию
.htaccessили конфига Nginx. - Проверьте, какие расширения реально используются:
mp4,webm,mov,m4v. - Добавьте правило только для видео, не трогая изображения и документы.
- Проверьте страницу с видео в обычном браузере и в инкогнито.
- Проверьте прямой URL файла через
curl -I. - Если нужен хотлинк-защитный сценарий, убедитесь, что ваш домен и поддомены не попали под блокировку.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужны три теста:
- открыть страницу с видео на сайте — плеер должен работать как раньше;
- открыть прямую ссылку на файл в новой вкладке — должен быть
403или другой ожидаемый ответ; - проверить чужой домен или пустой
Referer— если вы закрывали хотлинк, поведение должно соответствовать правилу.
Для быстрой диагностики полезно смотреть логи веб-сервера. Если после внедрения пошли массовые 403 на легитимные запросы, значит правило слишком широкое и зацепило нужные ресурсы.
Частые ошибки и как их исправить
Блокируют все файлы в uploads
Типичная ошибка — правило написано слишком грубо и режет не только видео, но и изображения, PDF, CSS. Исправление простое: ограничьте правило только нужными расширениями и проверьте путь.
Проверяют только Referer
Referer легко отсутствует или подменяется. Если вам нужна реальная защита приватного файла, используйте авторизацию и выдачу через PHP, а не только серверный фильтр.
Забывают про CDN
Если видео уже раздается через CDN, правило на origin-сервере может не дать ожидаемого эффекта. Нужно отдельно проверить, как CDN кэширует и отдает файл, и не публикуется ли его прямой URL в кеше.
Ломают встроенный плеер
Если плеер на странице берет тот же URL, который вы закрыли, видео перестанет загружаться. В таком случае либо ослабляйте правило для своего домена, либо переводите выдачу на защищенный endpoint.
Безопасность и производительность: что учесть заранее
Серверный запрет на прямые ссылки — это не шифрование и не DRM. Он снижает случайный доступ и хотлинк, но не защищает от пользователя, который уже может открыть страницу и получить URL из сети браузера. Если нужен строгий контроль, смотрите в сторону приватного хранилища, подписанных URL или отдельного видеосервиса.
С точки зрения производительности лучше не отдавать большие файлы через PHP без необходимости. Для публичных видео безопаснее и дешевле использовать серверные правила, а для закрытых материалов — отдельное хранилище или CDN с ограниченными ссылками.
Если на сайте много технических правок, удобно держать чистку дублей, лишних скриптов и SEO-мелочей под контролем через Clearfy Pro, но саму защиту видео все равно лучше настраивать на уровне сервера, а не плагином.
После внедрения еще раз откройте несколько видео с разных страниц сайта, проверьте логи и убедитесь, что прямой URL больше не отдается без нужных условий. Это тот случай, когда одна лишняя проверка экономит часы на разборе «почему видео пропало».