Статический сайт на сервере: частые ошибки и решения

MAATRIX

Статический сайт максимально прост, но при размещении на сервере всё равно всплывают типичные ошибки: вместо сайта показывается дефолтная страница Nginx, отдаётся 404 или 403 Forbidden, битые пути к стилям и картинкам, не выпускается SSL или файлы отдаются с неверным типом. Практически все частые ошибки статического сайта объясняются понятными причинами — конфиг Nginx, права, пути, DNS, SSL — и решаются проверенным набором действий. Разберём их по порядку, начиная с самых частых, с командами и указанием, где искать логи. Где искать причины. Главный источник — логи Nginx: ошибки в /var/log/nginx/error.log, запросы в /var/log/nginx/access.log. При любой проблеме сначала загляните в error.log — Nginx пишет туда конкретную причину: не найден файл, нет прав, ошибка конфига. Второй незаменимый инструмент — проверка синтаксиса конфига командой nginx -t, которая укажет файл и строку с ошибкой ещё до перезагрузки. Эти два инструмента закрывают большинство диагностики статического сайта, потому что вся его логика — это отдача файлов веб-сервером.

Показывается дефолтная страница Nginx

Частая ситуация: вместо вашего сайта открывается стандартная приветственная страница Nginx «Welcome to nginx». Это значит, что запрос не попал в ваш виртуальный хост, и его обработал сайт по умолчанию. Причин две. Первая — не активирован ваш конфиг: проверьте, что в /etc/nginx/sites-enabled/ есть симлинк на ваш файл. Вторая — конфликт с дефолтным сайтом. Удалите симлинк сайта по умолчанию и перезагрузите Nginx:

rm /etc/nginx/sites-enabled/default
nginx -t && systemctl reload nginx

Также проверьте, что в вашем конфиге правильно указан server_name с вашим доменом, а сам домен резолвится на сервер (dig +short vashdomen.ru). Если домен ещё не разошёлся по DNS или указывает на другой сервер, запрос до вашего хоста просто не дойдёт.

Ошибка 404 Not Found

Сайт открывается, но отдаёт 404 — файл не найден. Первая причина — в каталоге сайта нет файла index.html, который Nginx отдаёт по умолчанию. Убедитесь, что точка входа на месте:

ls -l /var/www/vashdomen.ru/html/index.html

Вторая причина — неверный путь root в конфиге: он должен указывать точно на каталог, где лежат файлы сайта. Опечатка в пути или указание на родительскую папку вместо html даёт 404. Третья — регистр имён файлов: Linux чувствителен к регистру, и ссылка на About.html не откроет файл about.html. Проверьте соответствие имён в ссылках и на диске. После исправления пути в конфиге перезагрузите Nginx.

Ошибка 403 Forbidden

Сайт отдаёт 403 Forbidden — нет доступа к файлам. Причина почти всегда в правах или владельце. Nginx работает от пользователя www-data и должен иметь право читать файлы сайта. Восстановите владельца и корректные права:

chown -R www-data:www-data /var/www/vashdomen.ru/html
find /var/www/vashdomen.ru/html -type d -exec chmod 755 {} \;
find /var/www/vashdomen.ru/html -type f -exec chmod 644 {} \;

Каталоги должны быть 755 (нужно право на выполнение, чтобы «войти» в папку), файлы — 644. Ещё одна причина 403 — права на вышестоящие каталоги: если сам путь /var/www/vashdomen.ru закрыт, Nginx не доберётся до html. Проверьте всю цепочку каталогов. Также 403 возникает, если в каталоге нет index.html, а листинг директорий отключён (это правильно с точки зрения безопасности) — тогда добавьте индексный файл.

Битые пути к стилям, скриптам и картинкам

Страница открывается, но без оформления: не подгружаются CSS, JS, изображения. Причина — неверные пути к ресурсам в HTML. Частая ошибка — абсолютные пути с диска разработчика (например, file:///C:/...) или ссылки на localhost, оставшиеся от локальной разработки. Используйте относительные пути (css/style.css) или пути от корня сайта (/css/style.css). Откройте инструменты разработчика в браузере (вкладка Network) — там видно, какие файлы не загрузились и по какому адресу их искали.

Вторая причина битых ресурсов — регистр имён файлов, как и с 404: ссылка на Logo.PNG не найдёт logo.png на Linux-сервере. Приведите имена в ссылках и на диске к единому регистру. Третья — смешанный контент после подключения SSL: если страница открыта по https, но ресурсы прописаны с http, браузер их заблокирует. Замените http-ссылки на ресурсы на https или относительные.

Не выпускается SSL Let's Encrypt

Certbot не может выпустить сертификат. Let's Encrypt проверяет домен по HTTP, поэтому нужны условия. Первое: A-запись домена указывает на этот сервер. Проверьте:

dig +short vashdomen.ru

Адрес должен совпадать с IP сервера. Если домен недавно перенаправили, дайте DNS разойтись. Второе: порт 80 открыт в фаерволе (ufw allow 'Nginx Full') и Nginx корректно обслуживает домен по HTTP. Третье: server_name в конфиге точно содержит домен, для которого выпускаете сертификат, — certbot с плагином nginx находит нужный блок именно по нему. Если ранее было много неудачных попыток, можно упереться в лимит Let's Encrypt — подождите час. После исправления повторите команду certbot.

Неверный тип файла (MIME) и кэш

Иногда браузер не применяет стили или скрипты, хотя файлы загружаются, — в консоли ошибка о неверном MIME-типе. Причина в том, что Nginx отдаёт файл не с тем Content-Type. Обычно это лечится подключением стандартного файла типов в конфиге — убедитесь, что в основном nginx.conf есть строка include mime.types;. Без неё нестандартные расширения (например, шрифты .woff2) отдаются как обычный текст, и браузер их игнорирует.

Отдельная частая жалоба — «я обновил файл, а на сайте старая версия». Это кэширование на стороне браузера или CDN. Сделайте жёсткое обновление страницы (Ctrl+F5), а если настроен длительный кэш заголовками expires, добавляйте версию к имени файла ресурса (style.css?v=2) при обновлении, чтобы браузер скачал новую версию. При использовании CDN сбросьте его кэш после изменения файлов. Правильная стратегия кэша — длинный срок для неизменных файлов и версионирование при обновлении.

Частые вопросы